QIR Training Part 1

POI Devices

A POI device can take many different forms. There's everything from simple 'dumb' card readers that just read a magnetic stripe card and output encrypted data, to complex multi-application devices that have fast embedded processors and multi-tasking operating systems, where payment transactions are almost an ancillary function. And, of course, between these two extremes exist a whole spectrum of different devices of different shapes, sizes, and purposes. There is a common misconception that these are hardware-only devices. All POI devices have software in them - even a simple encrypting mag-stripe reader will have a little micro-controller in the read-head that is running a tiny bit of code. In PCI PTS terminology, any body of code that impacts, or is used to comply with, the PTS requirements is called 'firmware'. Finally, there are different classes of POI devices to address the different uses and purposes of such devices.

Cardholder Verification

Cardholder verification" validates that the person trying to make a purchase is authorized to do so - that is, that they are the person to whom the card belongs. EMV supports three primary cardholder verification methods or CVM: Offline PIN, Online PIN, and Signature. Additionally, there may be no cardholder verification method for some transactions. The issuer prioritizes CVMs based on the associated risk of the transaction. For example, no CVM is sometimes used where the transaction value is low.

three types of validation methods that are commonly used with an EMV chip

First is the Chip-and-PIN transaction, where the consumer slides the card into an EMV-enabled card reader, and the cardholder and transaction is then authenticated with the use of the cardholder-supplied PIN. In a chip and signature transaction, the consumer slides the card into an EMV-enabled device and the merchant's cashier or clerk authenticates the cardholder by physically observing the cardholder's signature provided at the time of purchase, and comparing it to the signature on the back of the card. Third, there is the chip-only method. You may find this when a merchant is using a contactless reader or near field communication (or NFC) terminal. In this scenario, the customer either inserts their card into the device or places the card near the NFC reader to perform the transaction. There is generally no additional verification in chip-only transactions. To accommodate these transaction methods, there are typically three types of deployments of EMV-enabled devices. First is simply the EMV card reader that reads the chip on the card. Next are card-reading devices that include a PIN-entry keypad - these are also known as PIN-entry devices or PEDs. And third, there are chip and PIN-enabled devices that also accept a card swipe. Of these three hardware implementations, Chip and PIN without a magnetic card reader offers the highest level of protection against fraud.

P2PE Requirements

For example, the POI devices used in P2PE solutions must be PCI-approved PTS devices. The cryptographic key operations for both encryption and decryption environments must meet key management practices that were derived from the PCI PIN Security standard, and applications on POI devices must meet requirements derived from PA-DSS. Additionally, the decryption environment must be PCI DSS compliant. It's important to note that the PCI PIN Security requirements are an independent set of control requirements for the protection of PIN and PIN block data, and the P2PE standard does not supersede or replace the PCI PIN Security requirements.

What are some of the acquirers responsibilities?

For working with merchants and their service providers to ensure that they: Review and understand PCI DSS Understand their compliance and validation requirements Validate and report compliance to the acquirer Maintain on-going compliance Read and incorporate on-going communications

QSA Responsibility

In all cases, the QSA must first evaluate and document how the compensating control meets the intent of the requirement.

What happens in the clearing process?

In the Clearing process, the acquirer and issuer need to exchange purchase information to complete the transaction. The process includes: 1. The acquirer sends purchase information to the payment brand network. 2. The payment brand network sends purchase information to the issuer, which prepares data for the cardholder's statement. 3. The payment brand network provides complete reconciliation to the acquirer. This process usually occurs within one day in North America and may vary in other countries.

Which is the following responsibility of a QIR?

Install payment applications in a manner which supports the customers PCS DSS compliance.

Network Scanning Tool?

NMAP, a free network scanning tool available online as a stand-alone program, or as part of many hacker toolkits. He scans the Toasty Tavern's IP address and finds some open ports. Ports number ​80 and 443 allow connections to a web server that hosts the Toasty Tavern's website. Port 25 allows emails to come in. No surprises so far. But Evil Rick gets excited when he sees port 5900 open, because that port is associated with VNC, an application which is commonly used by administrators to remotely access systems for support or configuration. This is a dangerous situation, because insecure remote access is one of *THE* most common ways that hackers get into a merchant environment. From the comfort of their own homes, hackers can use automated tools to find these remote access servers, and then attack them for days or months until they gain access. It's very low risk, and all it costs is time and an internet connection, so attackers are constantly scanning every system connected to the Internet like this. As with physical access, once an attacker can remotely login, it is often "game over".

Is network segmentation a PCI DSS requirement?

Network segmentation, or isolating of the cardholder data environment, is not a PCI DSS requirement. This is important to remember, because it means assessors cannot force an entity to segment their network in order to find them compliant. Even if segmentation would help an entity to become compliant (for example, by isolating compliant systems from non-compliant systems), the assessor cannot tell them that they must segment to be PCI DSS compliant. However, without adequate network segmentation, the entire network is in scope for PCI DSS. Segmentation is recommended as a method that may reduce not only the scope and cost of a PCI DSS assessment, but also the ongoing overhead of maintaining PCI DSS compliance. By consolidating cardholder data into fewer, more controlled locations, the risk of data breach is also reduced. Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technology that restricts access to a particular segment of a network

Payment Card Data

Outline Transcript A payment card contains data in several places. First, on the front of the card is the full account number or Primary Account Number (or PAN), the expiry date, and the cardholder's name. On American Express payment cards, the front also contains a Card Identification Number, or CID, which is used for card-not-present transactions. Many cards also contain an EMV chip, which contains track-equivalent data. The chip is also a cryptographic processor, which can be used to generate cryptograms to authenticate transactions. On the back of the card is a magnetic stripe, containing several tracks of data. Only the first two tracks contain payment data. There is also a signature strip, as well as a card verification number. Many cards also have various security features, such as holograms, on either the front or back. Many people refer to all account data as "Cardholder Data". This has become the colloquial term to mean both cardholder data and sensitive authentication data. Remember, PCI DSS requirements are applicable wherever primary account number (PAN) or sensitive authentication data (SAD) is stored, processed, or transmitted. Account data—including cardholder data and/or sensitive authentication data—is contained in the information printed or embossed on the physical card as well as information encoded in the magnetic stripe or chip, depending on the type of card. Cardholder data includes the PAN, cardholder name, service code, and expiration date. Sensitive authentication data includes full magnetic-stripe or track data, including track-equivalent data encoded on a chip. It also includes the card validation codes or values printed on the back or front of a card, and the PIN and PIN block. Sensitive authentication data cannot be stored after authorization, even if it's encrypted. Note that encrypting cardholder data does not necessarily remove it from scope. Remember there are requirements around encrypting cardholder data including the management of encryption keys.

How does PCI DSS applies to system components?

PCI DSS applies to system components included in or connected to the cardholder data environment. Examples of system components that may be in scope for PCI DSS include: systems that provide security services (such as authentication servers), systems that facilitate segmentation (like internal firewalls), and systems that could otherwise impact the security of the CDE (for example, name resolution or web redirection servers). Virtualization components, such as virtual machines, virtual appliances, or virtual desktops, that are within or connected to the CDE would also be in scope, as would network components like firewalls, routers, wireless access points, and other security appliances. The types of applications and servers that you may come across include Web servers, databases, authentication servers, e-mail repositories, and network management systems, to name just a few. These are just some examples of the types of system components that the assessor may need to review. The key point to remember is that any component or device located within or connected to the CDE will need to be looked at to determine how PCI DSS requirements apply.

Where do you find Verification Codes or Values?

Paper, database files, flat files, log files, and debug files. Where to look? The same locations that you would look for track data, plus in any card-not-present processes. For example, mail order forms, faxes, phone order processes, etc. It is important to note that card verification codes or values are not required for recurring card-not-present transactions. These values are only needed the first time such a transaction is authorized. They are not required for subsequent authorizations. If you're working with an organization that believes they are required to retain the card verification value, we recommend that they talk to their acquirer to find out how to properly submit these subsequent transactions without using the card verification code or value. It is a common misconception that recurring payments require retention of card verification values; this is not the case.

Track Equivalent Data

Remember that track-equivalent data is stored on the chip. Track-equivalent data found on the chip differs from the track data found on the magnetic stripe, as the chip track data contains a unique Chip CVV/CVC code. However, there is a danger that the PAN and the expiration date in the chip may be used for fraudulent card-not-present transactions. So in summary, while chip-and-pin can help reduce the risk of fraudulent transactions within that environment, data captured from a chip may still be used for fraudulent transactions in other environments.

Storing Track Data After Authorization

Storing track data after authorization is never permitted. It doesn't matter what an organization is doing with the track data, they are not permitted to store it after authorization. The only exception may apply to issuers and/or issuer processors. Issuers or issuer processors are allowed to retain sensitive authentication data, but only for legitimate business reasons. A legitimate reason is one that is necessary for the performance of the function being provided and not one of convenience. Specific issuer requirements are defined according to the payment card brand that they're issuing on behalf of. At their discretion, the payment card brands may also impose additional requirements for issuers regarding handling of sensitive authentication data.

What does the Councils Standards Include?

The Council's standards include the PCI Data Security Standard, the Payment Application Data Security Standard, the Point-to-Point Encryption Standard, the PIN Transaction Security Point of Interaction, Hardware Security Module and PIN standards, the Card Production standards, and all of their supporting documents.

Tool that can guess every possibly password combo?

Tools that can try guessing every possible password combination, which is called a brute-force attack. In his hacker toolkit is a program called 'Hydra', which can perform brute force attacks against all kinds of systems, including VNC. ​

When a system connects to the internet

it allows an attacker from anywhere on Earth to test its security, which they do on a constant basis. Unpatched systems connected to the Internet are quickly found and compromised. Criminals are constantly searching for potential victims by scanning the Internet for vulnerable systems. They have tools which can automatically find and compromise systems, which is why all critical security patches must be installed within one month, in accordance with PCI DSS requirement 6.2

Acquirer Roles

it is the acquirer who is responsible for the compliance validation of their merchants. This could involve determining the merchant's reporting method, accepting compensating controls, as well as any necessary actions resulting from data breaches such as passing on fines and supporting forensic investigations.

A defense against modified terminals

A defense against rogue or modified terminals is good terminal inspection and inventory practices. If a new terminal appears or a terminal disappears from one store and shows up at another, this should be noticed when the device is inspected and serial numbers are checked. The inspection should also detect the skimmer. She told them they would need to periodically inspect the devices as instructed in requirement 9.9.2, looking for any signs of tampering. Beth also helped train the staff to be aware of suspicious behavior, per requirement 9.9.3. The Toasty Tavern employees know repairmen need to show ID before touching the registers, and to report anything suspicious that they see.

What is a Point-to-Point Encryption, or P2PE, Solution?

A validated P2PE solution is one that has been verified as meeting the PCI P2PE standard and program requirements, and that is listed by the Council. A P2PE solution requires that payment card data be secured and encrypted at the point-of-interaction (or POI) using approved devices and P2PE-validated applications. P2PE also requires the secure management of encryption and decryption devices, the decryption environment, and all decrypted account data. Additionally, secure encryption methodologies must be in place for all key generation, distribution, loading, injection, and administration, as well as other key usage activities throughout the solution.

ISA Responsibility

As compliance is an ongoing process, internal assessors should help their stakeholders to understand PCI DSS requirements, meet compliance obligations and increase their security awareness if needed.

PCI DSS Requirement

As the QIR is installing or interacting with these devices, they have the opportunity to assist the customers with inspections and to help customers identify methods of detection to identify possible modification. Attackers are known to replace legitimate payment terminals with compromised devices, and if not detected, the compromised devices could remain in place indefinitely. The Guidance column for PCI DSS Requirement 9.9 includes a number of examples and suggestions for detecting potential tampering or substitution. If the QIR suspects something isn't right with a device, the customer should be notified immediately. Merchants must also include processes to ensure that inventories and inspections are performed as required by their security policy. Additionally, using secure technologies and physically securing devices and systems from unauthorized access is a critical component of a security strategy.

QIR Installation

Assessors are encouraged to review any QIR documentation for information that may help with the PCI DSS assessment. However, it's important to remember that, while the QIR documentation may provide useful information about what to look for, the application or environment may have changed since the installation took place, and the information documented by the QIR may no longer represent the current configuration. A Qualified Installation, therefore, does not remove the need for a proper PCI DSS assessment or reduce the level of testing to be performed.

Hardening?

Before these systems can be used we must configure them securely to remove vulnerabilities and resist attacks. This process is called 'hardening'.changing default settings and configurations, especially default passwords. Often software comes with default passwords so users can log in for the first time during installation. But if these passwords aren't changed, it's like leaving the front door unlocked. Attackers have lists of default passwords for every type of system, and have even written automated programs to try them on every system on the Internet. The bad guys may not be targeting a small restaurant by name, but if their router is using a default password, you can bet someone is going to find it and take control of it. Another principle of hardening is changing default configurations to more secure values. Software often comes configured for operability, compatibility, and permissiveness. By default, all users may have access to administrative menus. By default, support for insecure protocols may be enabled. By default, all users may be able to change or delete files.

Methods of Data Retrieval from Skimming

Compromised devices have been found with GSM or CDMA cell phones embedded within them that were sending card data via text message to the perpetrator. Other devices have been identified with store-and-forward capabilities, where the perpetrator used a Bluetooth device to wirelessly connect to the skimmer and download the skimmed data. Implementing PCI DSS controls and using secure payment terminals and applications makes it more difficult for attackers. However, as attackers are always looking for ways to overcome these controls, ongoing monitoring and due diligence is also critical.

How does EMV impact PCI DSS?

EMV is a valuable mechanism that reduces fraudulent transactions from counterfeit and lost or stolen cards: The authentication provided by the chip verifies that the card is genuine, which protects against counterfeit card fraud for both online and offline card-present transactions. And when combined with a PIN for cardholder verification, EMV also protects against the fraudulent use of lost and stolen cards. Now let's think about how EMV and PCI DSS work together. The EMV standard does not protect the confidentiality of cardholder data, and the account number - the PAN - is not encrypted during transmission. EMV also cannot prevent account data being stored in the merchant environment. Compromised EMV data may also be used to commit card-not-present fraud - that is, e-commerce, mail-order, or telephone-order fraud - as these types of transactions don't use the authentication mechanisms that are part of the EMV card-present transaction. This is why PCI DSS and EMV complement each other, as they protect different aspects of card-present environments.

Entities using third party service provider?

Entities often use third-party service providers to store, process, or transmit cardholder data on their behalf, or to manage system components - such as routers, firewalls, databases, physical security, and/or servers - in their CDE. Entities should clearly identify the services and system components which are included in the scope of their service provider's PCI DSS assessment, as well as the PCI DSS requirements covered by the service provider and any requirements which need to be covered by the entity itself. There are two options for third-party service providers to validate compliance: They can undergo a PCI DSS assessment on their own and provide evidence to their customers to demonstrate their compliance; or, if they do not undergo their own PCI DSS assessment, they can have their services reviewed during the course of each of their customers' PCI DSS assessments. If the third party undergoes their own PCI DSS assessment, they should provide sufficient evidence to their customers to verify that the scope of the service provider's PCI DSS assessment covered the services applicable to the customer and that the relevant PCI DSS requirements were examined and determined to be in place. The specific type of evidence provided by the service provider to their customers will depend on the agreements and/or contracts in place between those parties. Entities using third party service providers will also need to apply PCI DSS Requirement 12.8 to each service. We will look at this requirement in more detail later in the course. Requirement 12.9 states that a service provider must maintain a template, to provide to their clients that states they will agree to maintain all applicable PCI DSS controls. This template will vary depending on the type of service provider the entity is and the type of services purchased by the service provider's client.

P2PE Solutions

Firstly, the merchant has no access to account data, either within the point of interaction device or the decryption environment, which is managed by the P2PE Solution Provider. The merchant also has no involvement in any encryption or decryption operations, or in cryptographic key management, as all cryptographic operations are managed by the P2PE Solution Provider. To be eligible for reduced PCI DSS scope through use of a validated P2PE solution, merchants must ensure that any other payment channels within their environment are adequately segmented (or isolated) from the P2PE environment. Version 2 of the P2PE standard is intended to provide more flexibility for solution providers, as well as additional options for merchants who wish to install and manage their own P2PE solutions.

Reducing Impact of Breach

It is important to understand that even if it is difficult to *prevent* such an attack, controls should be in place to help *detect* the skimmer and reduce the impact of the breach.

Skimming Devices

Methods of attack are often very difficult to identify and can remain in place for long periods of time. Attackers have been known to physically modify payment card readers to read the card values in tandem with the legitimate device, or attach physical components to capture data after it's been read by the legitimate device. This first image demonstrates an example of a skimming device that attackers physically place over a legitimate magnetic-stripe card-reading mechanism. When the cardholder inserts their card, this device reads the track data from the magnetic stripe as it slides through, and before the card is passed to the legitimate card-reading device. The second graphic demonstrates a small video camera which was installed in the proximity of the PIN pad to record the cardholder's PIN as it was entered. While methods for capturing data varies between systems, one thing remains constant; attackers need to get access to skimmed data in order for it to be monetized.

How can network segmentation be achieved?

Network segmentation can be achieved through multiple means. Adequate network segmentation is anything that isolates systems that store, process, or transmit cardholder data from those that do not. The assessor has to evaluate whether the segmentation is sufficient to isolate systems in the cardholder data environment from the rest of the network. No matter what types of devices, technologies or mechanisms are used, the assessor must evaluate that the segmentation is functioning properly and is providing isolation as intended. Appendix D in the PCI DSS provides an illustration of how segmentation can help reduce scope.

Where should you look for track data?

Obvious locations include database files, flat files, log files, and debug logs—the big one being debug logs because they are often missed. Remember to examine development and testing systems as they often do not have the same stringent controls on their debugging logs as do production systems. Key systems to look at include point-of-sale systems, point-of-sale servers, and authorization servers. Generally speaking, if there's not a mechanism to read a payment card, such as through swiping or dipping, then it's unlikely that there will be track data in that location. However, keep in mind that an organization may have previously accepted cardholder data through different payment channels, or may have legacy files or log data from earlier versions of an application. Or, they could be providing services to other entities that do have card swipes and/or dips, which could result in track data being present in both environments. It is unlikely an e-commerce vendor will have track data and much more likely they may have card verification codes or values

Mod 10 Check

Once an inventory has been completed, additional steps may be desired to verify that the inventory is complete and to confirm that cardholder data is not present in other systems or locations. If you need to search for data, using regular expressions (or "reg-ex") is one method you can use to help with the process. The problem with reg-ex searching is that it may return false positives, so additional verification may be required—for example, by validating the number that it finds using the Mod 10. First, you double the value of the alternate digits of the primary account number, beginning with the second digit from the right. Don't start from the left. If an answer is 10 or more, subtract 9 because you need single-digit numbers across the bottom. Also move each number that you did not double to the bottom, with no change to the original number. Finally, add the bottom row of numbers (this row includes both doubled numbers and original numbers). If the results of the bottom numbers are divisible by 10, it passes the Mod 10 test. If it passes the test, this means that it is a possible PAN, but it is not guaranteed that it is an actual PAN—for example, it may not have been assigned to a card yet.

Security Control

Remote access is very useful, and is not prohibited by the PCI DSS. But Beth knows more security controls are needed. She sets up a unique user ID and complex password for herself, and configures the system to lock after too many incorrect attempts. But the most important protection is "multi-factor authentication". Multi-factor authentication means that a password alone will not give Beth access. She will need another factor. Traditionally, the three types of factors are: something you know, something you have, or something you are. For example: A password is something you know. A token that shows a code that changes every minute is something you have. A fingerprint is something you are.

Sampling

Sampling is not a PCI DSS requirement. However, an assessor may independently select representative samples of business facilities and system components in order to assess PCI DSS requirements. Samples must be defined first for business facilities and then for system components within each selected business facility. Samples must be a representative selection of all of the types and locations of business facilities, as well as types of system components within selected business facilities. Samples must be sufficiently large to provide the assessor with assurance that controls are implemented as expected. We wish we could tell you exactly what and how many should be included in an assessment sample. The assessor must determine an appropriate sampling method based on the particular environment and whether there are standard, centralized PCI DSS security and operational processes and controls in place. The assessor must also document the rationale for the sampling methodology and sample size in the Description of Scope of Work section of the Report on Compliance.

Drown Attack

Support for insecure protocols is also a problem. When web browsers and servers communicate, they are smart enough to pick a strong protocol, like TLS version 1.2, to protect the data. But by default, web servers include support for insecure protocols and even weak encryption. To be compatible with all web browsers, web servers can come with SSL version 2.0 enabled, even though SSL 2 is broken and has been prohibited since 2011. This is what led to the 2016 DROWN vulnerability. During a DROWN attack, the bad guy watches network traffic protected by the TLS protocol, which may be secure by itself. But if the victim hasn't disabled support for SSL 2, the attacker can send probes using SSL 2, and use the information to decrypt the TLS connection! In March 2016, it was estimated that 28% of web sites had not disabled SSL 2, and were vulnerable to DROWN.To prevent the DROWN attack, all support for SSL version 2 must be disabled. SSL versions 2 and 3 have been deprecated because they are old and have many vulnerabilities. The best practice is to explicitly disable all old protocols, and only enable TLS version 1.2 or higher. All web-based products must be hardened against vulnerabilities such as DROWN. Here we see some possible configuration changes for two popular web servers. As we mentioned previously, this is only an example. Refer to vendor documentation and industry hardening standards before making configuration changes.

An inventory should include:

System Name - The name of the system component storing, processing, or transmitting the cardholder data (for example, workstation, server, network attached storage). Networking devices, such as routers, switches, and firewalls that only route cardholder data and do not store or process the data should also be identified as part of the PCI DSS scoping process. Data Stored - This is the list of all cardholder data that is stored. Although the only pertinent pieces of information are the PAN, cardholder name, service code, expiration date, card verification code or value, PIN/PIN block and track data, organizations are encouraged to document all other relevant stored information, such as address and transaction details, to make sure that nothing is missed. Remember if it is determined that card verification code or value, PIN/PIN block, or track data are stored, this would automatically raise a red flag because storage of these data elements is prohibited after authorization. Remember to look for cardholder data on portable media, backup media, and in logs, as well as data received from or stored by wireless networks. Reason for storage - For each system that stores cardholder data, a reason why such storage is required or desirable should be included. Retention Period - Data retention policy and practices are also addressed in PCI DSS requirement 3.1, and here is the best time to collect information on retention periods for different systems, data elements, etc. The retention period should be defined in terms of days, weeks, months, quarters, or years. Protection Mechanism - This identifies how the cardholder data, and in particular the PAN, is secured in its location. These methods may include truncation, one-way hashes based on strong cryptography, encryption, or compensating controls

EMV Standard

The EMV standard defines the interaction at the physical, electrical, data and application levels between the card processing device and the information being read off of the integrated circuit card, or ICCThe EMV standard reduces fraud in card-present transactions by producing a device - the chip - that cannot be fully replicated by fraudsters.

PA QSA Roles

The PA-QSA's role is to perform assessments according to the PA-DSS security assessment procedures and per their PA-QSA validation requirements, to render opinions about an application's compliance status, to adequately document the results of their review, and to submit all required documentation to PCI SSC. Both QSAs and PA-QSAs are required to maintain an internal quality assurance program to ensure their work meets expectations.

PTS Standards

The PTS standards were originally created in 2004, when two of the payment brands merged their PIN Entry Device compliance requirements into a single program, which they called PCI PED (for PIN Entry Device). These standards are now managed by PCI SSC, and the program has been renamed to PCI PTS. Current versions of the PTS standards have been updated to cover the security of non-PIN data, such as PAN and other account data, as well as addition of 'SRED' modules. Testing of devices against the PTS requirements is performed by PCI-approved PTS labs. The labs submit their evaluation reports to the PCI SSC, where each report is reviewed by PCI SSC staff and payment brand representatives, before being approved and the product listed on the PCI SSC website.

Service Provider

The definition for a service provider is a business entity directly involved in the processing, storage, or transmission of transaction data or cardholder data on behalf of another merchant or service provider. Service providers also include companies that provide services which control or could impact the security of cardholder data. Examples may include providers of managed firewalls, IDS and other security services, as well as hosting providers and other entities. So to confirm, when an entity is processing, storing or transmitting cardholder data on behalf of another entity, or they have access to another entity's cardholder data, they are a service provider.

Reducing the scope of PCI DSS

The fastest way to reduce the scope of PCI DSS is to not store cardholder data. If cardholder data is not removed altogether, it is subject to Requirement 3.4 requiring that it be rendered unreadable wherever it is stored. Methods for meeting Requirement 3.4 include truncation and hashing. If there is no need to recover the clear-text PAN data, our recommendation is that entities consider truncation or hashing, as this may reduce the overhead associated with maintaining and securing cryptographic keys required for encryption and decryption of data. Remember that systems that receive cardholder data before it is truncated or hashed, as well as systems that perform the actual hashing or truncation, or that are connected to the systems performing the truncation or hashing, are always in scope for the assessment.

While use of a validated, listed P2PE solution can help to reduce the scope of a merchant's cardholder data environment, it does not remove the need for PCI DSS in the merchant environment.

The merchant environment is still in scope for PCI DSS because they are still involved in the processing of payment card data. For example, in face-to-face environments, payment cards are physically present in order for a transaction to be performed, and the merchant may also have paper reports or receipts containing account data. Similarly, in card-not-present environments—such as mail-order or telephone-order, payment card details are provided to the merchant for entry into the P2PE POI, and these methods will need to be evaluated and protected according to applicable PCI DSS requirements. Only Council-listed P2PE solutions are recognized as meeting the requirements necessary for merchants to reduce the scope of their cardholder data environment through use of a P2PE solution. Merchants using encryption solutions that are not included on the Council's List of Validated P2PE Solutions should consult with their acquirer or payment brand about use of these solutions

Transaction Authorization

The transaction is authorized either online or offline. For an online authorization, transactions proceed as they do with magnetic stripe cards. The transaction information is sent to the issuer, along with a transaction-specific cryptogram, and the issuer either authorizes or declines the transaction. In an offline EMV transaction, the card and terminal communicate with each other, and use issuer-defined risk parameters that are contained within the card to determine whether the transaction can be authorized without additional issuer involvement. A transaction may be forced online for authorization if certain conditions are identified - for example, if the offline transaction limit is exceeded. EMV also has card data storage features that help secure the account data. EMV cards store payment information in a secure chip rather than on a magnetic stripe, and the personalization of EMV cards uses issuer-specific cryptographic keys. Unlike a magnetic stripe card, it is virtually impossible to create a counterfeit EMV card that can be used to conduct an EMV payment transaction successfully. Aside from the noted security features, there are additional benefits for merchants when implementing EMV into their environment, and we will look at some of these shortly.

Track 1 vs Track 2

There are two types of track containing payment data located within the magnetic stripe - Track 1 and Track 2. Track 1 contains all fields of Track 2 plus the cardholder's name and additional fields for proprietary use by the card issuer. It is the longer track, up to 79 characters, where Track 2 is the shorter, up to 40 characters and mainly used for the older dial-up transmissions. Here is a sample Track 1 layout. Find the service code here and remember it's generally a violation to store anything to the right of the service code, because that area contains sensitive authentication data. Track 2 is similar to Track 1. Again, find where the service code is—generally, everything to the right of that is a violation to store.

Scoping Study- E Commerce

This screen shows the cardholder data environment for an e-commerce vendor: data comes into the Web server and is then sent to the e-commerce server. Obviously, these systems are involved in processing of cardholder data. The e-commerce server is processing cardholder data, and the database server is storing it. Let's say there's also an application and database server, which processes inventory and pricing information, and the organization is sure that this system doesn't have cardholder data. One of the first systems to search is the Web server. Perhaps it is writing a history file that had PAN and card verification codes and values. The e-commerce server may not have the database on it, but again, it could have transaction files or other types of files that store cardholder data. Any time there is up-stream or down-stream communication, you would need to verify if there is cardholder data in that connected environment.

Sensitive Authentication Data

We just said an organization cannot store sensitive authentication data, but the reality is that there are times when doing so may be necessary for troubleshooting purposes, and it is often these circumstances that can get organizations into trouble. Organizations should concentrate on how they troubleshoot their systems. Do they ever put systems into a debug mode, and if so, what do they do with that data? If the organization needs to temporarily store sensitive authentication data such as track data as a result of troubleshooting, they should follow documented procedures to reduce their risk, including these steps: Only enable storage when needed for troubleshooting and disable storage when troubleshooting is completed Ensure that all data is securely deleted as soon as troubleshooting is complete, and include a destruction practice, and Ensure only the data specifically required for troubleshooting is captured- organizations should not store more data than needed when troubleshooting.

How can you see if a network is in scope?

What is in scope? The external-facing devices are still in scope. Whether the corporate LAN router is in scope would depend on the flow of cardholder data. Even if there is no traffic between the corporate LAN and the PCI LAN, the rule-set on the corporate LAN router would need to be reviewed to verify the segmentation. The e-commerce servers are still in scope as they store, process, or transmit cardholder data. The question then becomes, what about the other network environments? If there is no access from those other network environments into the cardholder data environment, then the segmentation may be sufficient for them to be considered out of scope. However, this can only be verified by reviewing data flows and rule sets on each of the routing and firewall devices.

Data Discovery Tool

While use of a data discovery tool is not required by PCI DSS, they may be able to assist with the scoping process. There are many different tools available that can be used for cardholder data discovery. The tool (or tools) you use is dependent on a number of factors including budget, environment, and resources available, to name just a few. There are commercial products and open source solutions available. Your organization may already have a tool that could be used for cardholder data discovery either by itself or in conjunction with another tool. Many organizations have data loss prevention products installed and while they may not be currently configured to detect cardholder data, with some minor adjustments they may provide a viable solution.

PCI DSS does not require that the merchants use a PCI approved PED

use of a PTS-approved device can assist with maintaining PCI DSS compliance. Additionally, some payment brands may have their own compliance requirements or mandates for using PTS-approved devices. The PCI SSC recommends that merchants check with their acquirer or the Payment Brands for any specific requirements around the use of a PCI PTS validated device. During a Qualified Installation, the QIR will often have intimate knowledge of their customers' point-of-sale environment, and will be able to assist customers to understand whether the devices they use are PCI approved. The PCI SSC List of PTS Approved Devices includes identification of device approvals that have reached their expiry date. It's important for customers using PTS-approved devices to be aware of the expiry date for the devices they're using. QIRs are in a unique position to help their customers find the information they need to make informed decisions about their point-of-interaction devices. Customers using expired PTS devices should also be encouraged to consult with their acquirer or applicable payment brands to determine any brand requirements or restrictions around the use of expired devices.

When does PCI DSS apply?

wherever cardholder data is being stored, processed or transmitted. It therefore applies to all entities involved in payment card processing, including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process, or transmit cardholder data or sensitive authentication data.