Chapter 15
PCI Compliance for Merchants
Chapter Objectives
After reading this chapter and completing the exercises, you will be able to do the following:
Understand the Payment Card Industry Data Security Standard (PCI DSS).
Recognize merchant responsibilities.
Explain the 12 top-level requirements.
Understand the PCI DSS validation process.
Implement practices related to PCI compliance.
The ever-increasing volume of credit, debit, and gift card transactions makes the payment card channel an attractive target for cybercriminals.
FYI: Consumer Credit, Debit, and ATM Card Liability Limits
According to the Federal Trade Commission, consumers reported losses in excess of $900 million due to fraud per year during the last few years. This is expected to continue to rise. The balance of the loss is borne by the merchant, credit card processor, and the issuing bank.
The Fair Credit Billing Act (FCBA) and the Electronic Fund Transfer Act (EFTA) govern credit card, debit card, and ATM liability if a card is lost or stolen.
Under the FCBA, the maximum liability for unauthorized credit card use is $50. However, if the consumer reports a lost card before the credit card is used, the consumer is not responsible for any unauthorized charges. If a credit card number is stolen, but not the card, the consumer is not liable.
Under the EFTA, debit and ATM card liability depends on how quickly the loss or theft is reported. If the card is reported as lost or stolen before any unauthorized charges are made, the consumer is not responsible for any unauthorized charges. If the card is reported within two days after the consumer learns of the loss or theft, the consumer liability is limited to $50. If the card is reported more than two days but less than 60 days after the consumer learns of the loss or theft, the consumer liability is limited to $500. If the card is reported as lost or stolen more than 60 days after a bank statement is sent, the consumer bears all liability.
To protect cardholders against misuse of their personal information and to minimize payment card channel losses, the major payment card brands—Visa, MasterCard, Discover, JCB International, and American Express—formed the Payment Card Industry Security Standards Council and developed the Payment Card Industry Data Security Standard (PCI DSS). On December 15, 2004, the Council released version 1.0 of the PCI DSS. The latest version at the time of writing was PCI DSS version 3.2 published in April 2016. The standard and collateral documentation can be obtained at https://www.pcisecuritystandards.org.
The PCI DSS must be adopted by any organization that transmits, processes, or stores payment card data, or directly or indirectly affects the security of cardholder data. Any organization that leverages a third-party to manage cardholder data has the full responsibility to ensure that this third party is compliant with the PCI DSS. The payment card brands can levy fines and penalties against organizations that do not comply with the requirements, and/or revoke their authorization to accept payment cards.
In this chapter, we examine the PCI DSS standard. Although designed for a specific constituency, the requirements can serve as a security blueprint for any organization.
Protecting Cardholder Data
Before we proceed with the details about how to protect cardholder data, we must define several key terms that are used within this chapter and defined by the PCI Security Standards Council (PCI SSC) in their Glossary of Terms, Abbreviations, and Acronyms at https://www.pcisecuritystandards.org/documents/pci_glossary_v20.pdf.
Acquirer: Also referred to as “acquiring bank” or “acquiring financial institution.” Entity that initiates and maintains relationships with merchants for the acceptance of payment cards.
ASV: Acronym for “Approved Scanning Vendor.” An organization approved by the PCI SSC to conduct external vulnerability scanning services.
Merchant: For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard, or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers.
PAN: Primary account number (the up-to-19-digit payment card number).
Qualified Security Assessor (QSA): An individual trained and certified to carry out PCI DSS compliance assessments.
Service provider: Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS, and other services, as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.
To counter the potential for staggering losses, the payment card brands contractually require all organizations that store, process, or transmit cardholder data and/or sensitive authentication data to comply with the PCI DSS. PCI DSS requirements apply to all system components where account data is stored, processed, or transmitted.
As shown in Table 15-1, account data consists of cardholder data plus sensitive authentication data. System components are defined as any network component, server, or application that is included in, or connected to, the cardholder data environment. The cardholder data environment is defined as the people, processes, and technology that handle cardholder data or sensitive authentication data.
TABLE 15-1 Account Data Elements
Cardholder Data Includes… |
Sensitive Authentication Data Includes… |
|---|---|
Primary account number (PAN) |
Full magnetic stripe data or equivalent data on a chip |
Cardholder name |
CAV2/CVC2/CVV2/CID |
Expiration date |
PIN blocks |
Service code |
|
What Is the PAN?
The PAN is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements apply if the PAN is stored, processed, or transmitted. If the PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. If cardholder names, service codes, and/or expiration dates are stored, processed, or transmitted with the PAN, or are otherwise present in the cardholder data environment, they too must be protected.
Per the standards, the PAN must be stored in an unreadable (encrypted) format. Sensitive authentication data may never be stored post-authorization, even if encrypted.
The Luhn Algorithm
The Luhn algorithm or Luhn formula is an industry algorithm used to validate different identification numbers including credit card numbers, International Mobile Equipment Identity (IMEI) numbers, National Provider Identifier numbers in the United States, Canadian Social Insurance Numbers, and more. The Luhn algorithm was created by Hans Peter Luhn in 1954. This algorithm is now in the public domain.
Most credit cards and many government identification numbers use the Luhn algorithm to validate valid numbers. The Luhn algorithm is based around the principle of modulo arithmetic and digital roots. It uses modulo-10 mathematics.
FYI: The Elements of a Credit Card
Figure 15-1 shows the following elements located on the front of a credit card:
Embedded microchip: The microchip contains the same information as the magnetic stripe. Most non-U.S. cards have the microchip instead of the magnetic stripe. Some U.S. cards have both for international acceptance.
Primary account number (PAN).
Expiration date.
Cardholder name.
FIGURE 15-1 The Elements of the Front of a Credit Card
Figure 15-2 shows the following elements on the back of a credit card:
Magnetic stripe (mag stripe): The magnetic stripe contains encoded data required to authenticate, authorize, and process transactions.
CAV2/CID/CVC2/CVV2: All refer to card security codes for the different payment brands.
FIGURE 15-2 The Elements of the Back of a Credit Card
Eliminating the collection and storage of unnecessary data, restricting cardholder data to as few locations as possible, and isolating the cardholder data environment from the rest of the corporate network is strongly recommended. Physically or logically segmenting the cardholder data environment reduces the PCI scope, which in turn reduces cost, complexity, and risk. Without segmentation, the entire network must be PCI-compliant. This can be burdensome because the PCI-required controls may not be applicable to other parts of the network.
Utilizing a third party to store, process, and transmit cardholder data or manage system components does not relieve a covered entity of its PCI compliance obligation. Unless the third-party service provider can demonstrate or provide evidence of PCI compliance, the service provider environment is considered to be an extension of the covered entity’s cardholder data environment and is in scope.
What Is the PCI DDS Framework?
The PCI DSS framework includes stipulations regarding storage, transmission, and processing of payment card data, six core principles, required technical and operational security controls, testing requirements, and a certification process. Entities are required to validate their compliance. The number of transactions, the type of business, and the type of transactions determine specific validation requirements.
There are multiple points of access to cardholder data and varying technologies. PCI DSS is designed to accommodate the various environments where cardholder data is processed, stored, or transmitted—such as e-commerce, mobile acceptance, or cloud computing. PCI DSS also recognizes that security is a shared responsibility and addresses the obligations of each business partner in the transaction chain.
The PCI DSS consists of six core principles, which are accompanied by 12 requirements. The six core principles are illustrated in Figure 15-3.
FIGURE 15-3 PCI DSS Six Core Principles
Business-as-Usual Approach
PCI DSS version 3.2 emphasizes that compliance is not a point-in-time determination but rather an ongoing process. Business as usual is defined as the inclusion of PCI controls as part of an overall risk-based security strategy that is managed and monitored by the organization. According to the PCI Standards Council, a business-as-usual approach “enables an entity to monitor the effectiveness of their security controls on an ongoing basis, and maintain their PCI DSS compliant environment in between PCI DSS assessments.” This means that organizations must monitor required controls to ensure they are operating effectively, respond quickly to control failures, incorporate PCI compliance impact assessments into the change-management process, and conduct periodic reviews to confirm that PCI requirements continue to be in place and that personnel are following secure processes.
Per the PCI Council, the version 3.2 updates are intended to do the following:
Provide stronger focus on some of the greater risk areas in the threat environment.
Build greater understanding of the intent of the requirements and how to apply them.
Improve flexibility for all entities implementing, assessing, and building to the standards.
Help manage evolving risks/threats.
Align with changes in industry best practices.
The Designated Entities Supplemental Validation (DESV) has been incorporated into the PCI DSS standard.
Several new requirements were identified for service providers in PCI DSS 3.2. These include maintaining a documented description of the cryptographic architecture and reporting on failures of critical security control systems. Additionally, executive management must establish responsibility for protection of cardholder data and the PCI DSS compliance program.
Eliminate redundant subrequirements and consolidate policy documentation.
This approach mirrors best practices and reflects the reality that the majority of significant card breaches have occurred at organizations that were either self-certified or independently certified as PCI compliant.
What Are the PCI Requirements?
There are 12 top-level PCI requirements related to the six core principles. Within each requirement are subrequirements and controls. The requirements are reflective of cybersecurity best practices. Quite often, the requirement’s title is misleading in that it sounds simple, but the subrequirements and associated control expectations are actually quite extensive. The intent of and, in some cases, specific details of the requirements are summarized in the following sections. As you read them, you will notice that they parallel the security practices and principles we have discussed throughout this text.
The PCI DSS consists of 12 requirements. These requirements are listed in Figure 15-4.
FIGURE 15-4 PCI DSS Requirements
Build and Maintain a Secure Network and Systems
The first core principle—build and maintain a secure network and systems—includes the following two requirements:
Install and maintain a firewall configuration to protect cardholder data.
The basic objective of a firewall is ingress and egress filtering. The firewall does so by examining traffic and allowing or blocking transmissions based on a predefined rule set. The requirement extends beyond the need to have a firewall. It also addresses the following:
Identifying and documenting all connections.
Designing a firewall architecture that protects cardholder data.
Implementing consistent configuration standards.
Documenting firewall configuration and rule sets.
Having a formal change management process.
Requiring rule-set business justification.
Scheduling semi-annual firewall rule-set reviews.
Implementing firewall security controls, such as antispoofing mechanisms.
Maintaining and monitoring firewall protection on mobile or employee-owned devices.
Publishing perimeter protection policies and related operational procedures.
Do not use vendor-supplied defaults for system passwords and security parameters.
Although this seems obvious, there may be default accounts, especially service accounts, that aren’t evident or are overlooked. Additionally, systems or devices that are installed by third parties may be left at the default for ease of use. This requirement also extends far beyond its title and enters the realm of configuration management. Requirements include the following:
Maintaining an inventory of systems and system components.
Changing vendor-supplied default passwords on all operating systems, applications, utilities, devices, and keys.
Removing or disabling unnecessary default accounts, services, scripts, drivers, and protocols.
Developing consistent configuration standards for all system components that are in accordance with industry-accepted system-hardening standards (such as ISO and NIST).
Segregating system functions based on security levels.
Using secure technologies (for example, SFTP instead of FTP).
Encrypting all nonconsole administrative access.
PCI DSS version 3.2 introduces new requirements for organizations to migrate to modern and strong cryptographic algorithms and protocols. The PCI SSC refers to industry standards and best practices for information on strong cryptography and secure protocols, including the NIST SP 800-52 and SP 800-57 and the OWASP recommendations.
Publishing configuration management policies and related operational procedures.
Protect Cardholder Data
The second core principle—protect cardholder data—includes the following two requirements:
Protect stored card data.
This is a very broad requirement. As mentioned earlier, the cardholder data environment is defined as the people, processes, and technology that handle cardholder data or sensitive authentication data. Sited protection mechanisms include encryption, truncation, masking and hashing, secure disposal, and secure destruction. Requirements include the following:
Data retention policies and practices that limit the retention of cardholder data and forbid storing sensitive authentication data post-authorization as well as card-verification code or value.
Masking the PAN when displayed.
Rendering the PAN unreadable anywhere it is stored.
Protecting and managing encryption keys (including generation, storage, access, renewal, and replacement).
Publishing data-disposal policies and related operational procedures.
Publishing data-handling standards that clearly delineate how cardholder data is to be handled.
Training for all personnel that interact with or are responsible for securing cardholder data.
Encrypt transmission of cardholder data across open, public networks.
The objective here is to ensure that data in transit over public networks cannot be compromised and exploited. An open and/or public network is defined as the Internet, wireless technologies including Bluetooth, cellular technologies, radio transmission, and satellite communications. The requirements include the following:
Using strong cryptography and security transmission protocols.
Forbidding transmission of unprotected PANs by end-user messaging technologies, such as email, chat, instant message, and text.
Publishing transmission security policies and related operational procedures.
Maintain a Vulnerability Management Program
The third core principle—maintain a vulnerability management program—includes the following two requirements:
Protect all systems against malware and regularly update antivirus software or programs.
As discussed in previous chapters, malware is a general term used to describe any kind of software or code specifically designed to exploit or disrupt a system or device, or the data it contains, without consent. Malware is one of the most vicious tools in the cybercriminal arsenal. The requirement includes the following:
Selecting an antivirus/antimalware solution commensurate with the level of protection required.
Selecting an antivirus/antimalware solution that has the capacity to perform periodic scans and generate audit logs.
Deploying the antivirus/antimalware solution on all applicable in-scope systems and devices.
Ensuring that antivirus/antimalware solutions are kept current.
Ensuring that antivirus/antimalware solutions cannot be disabled or modified without management authorization.
Publishing antimalware security policies and related operational procedures.
Training for all personnel on the implications of malware, disruption of the distribution channel, and incident reporting.
Develop and maintain secure systems and architecture.
This requirement mirrors the best practices guidance in Section 14 of ISO 27002:2013: Information Systems Acquisition, Development, and Maintenance, which focuses on the security requirements of information systems, applications, and code, from conception to destruction. The requirement includes the following:
Keeping up-to-date on new vulnerabilities.
Assessing the risk of new vulnerabilities.
Maintaining a patch management process.
Adhering to security principles and best practices throughout the systems development life cycle (SDLC).
Maintaining a comprehensive change management process, including back-out and restore procedures.
Segregating the production environment from development, staging, and/or testing platforms.
Adopting and internally publishing industry-accepted secure coding techniques (for example, OWASP).
Implementing code testing procedures.
Training developers in secure coding and vulnerability management practices.
Publishing secure coding policies and related operational procedures.
FYI: Focus on Malware Controls
Malware has been the tool of choice for some of the most significant data card breaches:
January 2018: OnePlus announced that up to 40,000 customers were affected by a security breach that caused the company to shut down credit card payments for its online store.
June 2017: The Buckle, Inc. disclosed that its retail locations were hit by malicious software designed to steal customer credit card data.
April 2016: Wendy’s reported at least 1,025 store locations were hit by a malware-driven credit card breach that began in the fall of 2015.
September 2014: Criminals stole over 56 million credit, debit, and gift card data records from Home Depot.
November 2013: Criminals used malware to obtain unauthorized access to Target Corp’s point-of-sale terminals, resulting in the compromise of 40 million credit and debit cards.
January 2012: Criminals used an SQL injection attack to plant malware on the Global Payments, Inc.’s computer network and processing system, resulting in the compromise of 1.5 million credit and debit cards.
From 2005–2013, a hacking group from Russia and Ukraine targeted banks and companies, including Nasdaq, 7-11, JetBlue and JC Penney. Threat actors stole 160 million credit and debit card-numbers and breached 800,000 bank accounts.
Implement Strong Access Control Measures
The fourth core principle—implement strong access control measures—includes the following three requirements:
Restrict access to cardholder data by business need-to-know.
This requirement reflects the security best practices of default deny, need-to-know, and least privilege. The objective is to ensure that only authorized users, systems, and processes have access to cardholder data. The requirement includes the following:
Setting the default cardholder data access permissions to default deny.
Identifying roles and system processes that need access to cardholder data.
Determining the minimum level of access needed.
Assigning permissions based on roles, job classification, or function.
Reviewing permissions on a scheduled basis.
Publishing access control policies and related operational procedures.
Identify and authenticate access to system components.
There are three primary objectives to this requirement. The first is to ensure that every user, system, and process is uniquely identified so that accountability is possible and to manage the account through its life cycle. The second is to ensure that the strength of authentication credentials is commensurate with the access risk profile. The third is to secure the session from unauthorized access. This section is unique in that it sets specific implementation standards, including password length, password complexity, and session timeout. The requirement includes the following:
Assigning and requiring the use of unique IDs for each account (user or system) and process that accesses cardholder data and/or is responsible for managing the systems that process, transmit, or store cardholder data.
Implementing and maintaining a provisioning process that spans the account life cycle from creation through termination. This includes access reviews and removing/disabling inactive user accounts at least every 90 days.
Allowing single-factor authentication for internal access if passwords meet the following minimum criteria: seven alphanumeric characters, 90-day expiration, and no reuse of the last four passwords. The account lockout mechanism’s setting must lock out the user ID after six invalid login attempts and lock the account for a minimum of 30 minutes.
Requiring two-factor authentication for all remote network access sessions. Authentication mechanisms must be unique to each account.
Implementing session requirements, including a mandatory maximum 15-minute inactivity timeout that requires the user to reauthenticate, and monitoring remote vendor sessions.
Restricting access to cardholder databases by type of account.
Publishing authentication and session security policies and related operational procedures.
Training users on authentication-related best practices, including how to create and manage passwords.
Restrict physical access to cardholder data.
This requirement is focused on restricting physical access to media (paper and electronic), devices, and transmission lines that store, process, or transmit cardholder data. The requirement includes the following:
Implementing administrative, technical, and physical controls that restrict physical access to systems, devices, network jacks, and telecommunications lines within the scope of the cardholder environment.
Video monitoring physical access to sensitive areas, correlating with other entries, and maintaining evidence for a minimum of three months. The term sensitive areas refers to a data center, server room, or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of-sale terminals are present, such as the cashier areas in a retail store.
Having procedures to identify and account for visitors.
Physically securing and maintaining control over the distribution and transport of any media that has cardholder data.
Securely and irretrievably destroying media (that has cardholder data) when it is no longer needed for business or legal reasons.
Protecting devices that capture card data from tampering, skimming, or substitution.
Training point-of-sale personnel about tampering techniques and how to report suspicious incidents.
Publishing physical security policies and related procedures.
FYI: Stealing Card Information Using a Skimmer
According to Brian Krebs, “A greater number of ATM skimming incidents now involve so-called ‘insert skimmers,’ wafer-thin fraud devices made to fit snugly and invisibly inside a cash machine’s card acceptance slot. New evidence suggests that at least some of these insert skimmers—which record card data and store it on a tiny embedded flash drive—are equipped with technology allowing them to transmit stolen card data wirelessly via infrared, the same communications technology that powers a TV remote control.”
Skimming is theft of cardholder information by modifying a card swipe device and/or by attaching a card-reading device (AKA a skimmer) to a terminal or ATM. The prized target is debit cardholder data and PINs, which give the criminals the information they need to make counterfeit debit cards and withdraw cash from ATMs.
Skimming can be very lucrative. Before they were caught, a nine-month skimming operation in Oklahoma netted two men $400,000. According to their indictment, defendants Kevin Konstantinov and Elvin Alisuretove installed skimmers at Murphy’s gas pumps in the parking lots of Walmart retail stores in Arkansas, Oklahoma, and Texas. They would leave the skimming devices in place for between one and two months. Then they’d collect the skimmers and use the stolen data to create counterfeit cards, visiting multiple ATMs throughout the region and withdrawing large amounts of cash.
Skimming devices are readily available online from dozens of stores for under $50. These devices are usually disguised under the name of “card reader” because they can also serve legitimate purposes. Several of the devices include built-in storage and wireless connectivity, which allow the criminals to transmit the stolen data. According to U.S. Secret Service Special Agent Cynthia Wofford, “Thieves travel to the U.S. for the very purpose of stealing credit and debit card data. The arrests we’ve made so far have led us to believe they’re organized groups.”
It is important that merchants learn how to inspect for and recognize skimming devices. “All About Skimmers,” an excellent online primer (including pictures), is publicly available on the Krebs on Security site: http://krebsonsecurity.com/all-about-skimmers/.
Regularly Monitor and Test Networks
The fifth core principle—Regularly monitor and test networks—includes the following two requirements:
Track and monitor all access to network resources and cardholder data.
The nucleus of this requirement is the ability to log and analyze card data–related activity, with the dual objective of identifying precursors and indicators of compromise, and the availability of corroborative data if there is a suspicion of compromise. The requirement includes the following:
Logging of all access to and activity related to cardholder data, systems, and supporting infrastructure. Logs must identity the user, type of event, date, time, status (success or failure), origin, and affected data or resource.
Logging of user, administrator, and system account creation, modifications, and deletions.
Ensuring the date and time stamps are accurate and synchronized across all audit logs.
Securing audit logs so they cannot be deleted or modified.
Limiting access to audit logs to individuals with a need to know.
Analyzing audit logs to identify anomalies or suspicious activity.
Retaining audit logs for at least one year, with a minimum of three months immediately available for analysis.
Publishing audit log and monitoring policies and related operational procedures.
Regularly test security systems and processes.
Applications and configuration vulnerabilities are identified on a daily basis. Ongoing vulnerability scans, penetration testing, and intrusion monitoring are necessary to detect vulnerabilities inherent in legacy systems and/or have been introduced by changes in the cardholder environment. The requirement to test security systems and processes is specific in how often testing must be conducted. This requirement includes the following:
Implementing processes to detect and identify authorized and unauthorized wireless access points on a quarterly basis.
Running internal and external network vulnerability scans at least quarterly and whenever there is a significant change in the environment. External scans must be performed by a PCI Approved Scanning Vendor (ASV).
Resolving all high-risk issues identified by the vulnerability scans. Verifying resolution by rescanning.
Performing annual network and application layer external and internal penetration tests using an industry-accepted testing approach and methodology (for example, NIST SP 800-115, OWASP). If issues are identified, they must be corrected and the testing must be redone to verify the correction.
Using intrusion detection (IDS) or intrusion prevention (IPS) techniques to detect or prevent intrusions into the network.
Deploying a change detection mechanism to alert personnel to unauthorized modifications of critical system files, configuration files, and content files.
Publishing security testing policies and related operational procedures.
Maintain a Cybersecurity Policy
The sixth core principle—maintain a cybersecurity policy—includes the final requirement:
Maintain a policy that addresses cybersecurity for all personnel.
Of all the requirements, this may be the most inaptly named. A more appropriate title would be “Maintain a comprehensive cybersecurity program (including whatever we’ve forgotten to include in the first 11 requirements).” This requirement includes the following:
Establishing, publishing, maintaining, and disseminating a cybersecurity policy. The policy should include but not be limited to the areas noted in the other 11 PCI DSS requirements. The policy should be authorized by executive management or an equivalent body.
Annually reviewing, updating, and reauthorizing the cybersecurity policy.
Implementing a risk assessment process that is based on an industry-accepted approach and methodology (for example, NIST 800-30, ISO 27005).
Assigning responsibility for the cybersecurity program to a designated individual or team.
Implementing a formal security awareness program.
Educating personnel upon hire and then at least annually.
Requiring users to annually acknowledge that they have read and understand security policies and procedures.
Performing thorough background checks prior to hiring personnel who may be given access to cardholder data.
Maintaining a vendor management program applicable to service providers with whom cardholder data is shared or who could affect the security of cardholder data.
Requiring service providers to acknowledge in a written agreement their responsibility in protecting cardholder data.
Establishing and practicing incident response capabilities.
Establishing and practicing disaster response and recovery capabilities.
Establishing and practicing business continuity capabilities.
Annually testing incident response, disaster recovery, and business continuity plans and procedures.
The Designated Entities Supplemental Validation (DESV)
The Designated Entities Supplemental Validation (DESV) is a document that Qualified Security Assessors (QSAs) use to validate organizations that must be PCI DSS−compliant. PCI DSS version 3.2 incorporates DESV as an appendix primarily to merge requirements and to strengthen the importance of these requirements in establishing and maintaining ongoing cybersecurity processes. DESV is a list of resources and criteria that is designed to help service providers and merchants address key operational challenges while trying to protect payments and maintain compliance.
DESV includes the following requirements:
Compliance program oversight
Proper scoping of an environment
Guaranteeing that proper mechanisms are used to detect and alert on failures in critical security controls.
Many of the requirements are simply extensions of existing PCI DSS requirements that should be demonstratively tested more regularly, or require more evidence that the control is in place.
In Practice
PCI Topic Summary and Chapter Cross-Reference
Requirement |
Topic |
Chapter Cross-Reference |
|---|---|---|
Install and maintain a firewall configuration to protect cardholder data. |
Perimeter access controls |
|
Do not use vendor-supplied defaults for system passwords and security parameters. |
System inventory |
|
System configuration |
||
Protect stored cardholder data. |
Data handling standards |
|
Data retention standards |
|
|
User training |
||
Data and system disposal |
||
Key management |
Ch. 10: “Information Systems Acquisition, Development, and Maintenance” |
|
Encrypt transmission of cardholder data across open, public networks. |
Encryption |
Ch. 10: “Information Systems Acquisition, Development, and Maintenance” |
Secure transmission protocols |
||
Protect all systems against malware and regularly update antivirus software or programs. |
Malware protection |
|
User training |
||
Develop and maintain secure systems and applications. |
Standard operating procedures |
|
|
Patch management |
|
|
Change management |
|
|
Systems development life cycle (SDLC) Secure coding procedures |
Ch. 10: “Information Systems Acquisition, Development, and Maintenance” |
Restrict access to cardholder data by business need-to-know. |
Security principles Role-based access control Access reviews |
|
Identify and authenticate access to system components. |
Authentication |
|
|
User provisioning |
|
|
Session controls |
|
|
User training |
|
Restrict physical access to cardholder data. |
Physical access controls Data center monitoring Media security |
|
|
User training |
|
Track and monitor all access to network resources and cardholder data. |
Audit log collection Audit log analysis Audit log management |
|
Regularly test security systems and processes. |
Vulnerability scanning Penetration testing |
|
|
Detection and alerting |
|
Maintain a policy that addresses information security for all personnel. |
Security policy management Risk assessment Cybersecurity program management |
|
|
Secure awareness program Background checks Acceptable use agreements |
|
|
Vendor management program Service provider contracts |
|
|
Incident response capabilities |
|
Disaster response and recovery capabilities |
PCI Compliance
Complying with the PCI standards is a contractual obligation that applies to all entities involved in the payment card channel, including merchants, processors, financial institutions, and service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data. The number of transactions, the type of business, and the type of transactions determine specific compliance requirements.
It is important to emphasize that PCI compliance is not a government regulation or law. The requirement to be PCI-compliant is mandated by the payment card brands in order to accept card payments and/or be a part of the payment system. PCI standards augment but do not supersede legislative or regulatory requirements to protect personally identifiable information (PII) or other data elements.
Who Is Required to Comply with PCI DSS?
Merchants are required to comply with the PCI DSS. Traditionally, a merchant is defined as a seller. It is important to note that the PCI DSS definition is a departure from the traditional definition. For the purposes of the PCI DSS, a merchant is defined as any entity that accepts American Express, Discover, JCB, MasterCard, or Visa payment cards as payment for goods and/or services (including donations). The definition does not use the terms store, seller, and retail; instead, the focus is on the payment side rather than the transaction type. Effectively, any company, organization, or individual that accepts card payments is a merchant. The mechanism for collecting data can be as varied as an iPhone-attached card reader, a parking meter, a point-of-sale checkout, or even an offline system.
Compliance Validation Categories
PCI compliance validation is composed of four levels, which are based on the number of transactions processed per year and whether those transactions are performed from a physical location or over the Internet. Each payment card brand has the option of modifying its requirements and definitions of PCI compliance validation levels. Given the dominance of the Visa brand, the Visa categorization is the one most often applicable. The Visa brand parameters for determining compliance validation levels are as follows. Any entity that has suffered a breach that resulted in an account data compromise may be escalated to a higher level.
A Level 1 merchant meets one of the following criteria:
Processes over six million Visa payment card transactions annually (all channels).
A merchant that has been identified by any card association as a Level 1 merchant.
Any merchant that Visa, at its sole discretion, determines should meet the Level 1 requirements to minimize risk to the Visa system.
A Level 2 entity is defined as any merchant—regardless of acceptance channel—processing one million to six million Visa transactions per year.
A Level 3 merchant is defined as any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year.
A Level 4 merchant is defined as any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants—regardless of acceptance channel—processing up to one million Visa transactions per year.
An annual onsite compliance assessment is required for Level 1 merchants. Level 2 and Level 3 merchants may submit a self-assessment questionnaire (SAQ). Compliance validation requirements for Level 4 merchants are set by the merchant bank. Submission of an SAQ is generally recommended but not required. All entities with externally facing IP addresses must engage an ASV to perform quarterly external vulnerability scans.
What Is a Data Security Compliance Assessment?
A compliance assessment is an annual onsite evaluation of compliance with the PCI DSS conducted by either a Qualified Security Assessor (QSA) or an Internal Security Assessor (ISA). The assessment methodology includes observation of system settings, processes, and actions, documentation reviews, interviews, and sampling. The culmination of the assessment is a Report on Compliance (ROC).
Assessment Process
The assessment process begins with documenting the PCI DSS cardholder environment and confirming the scope of the assessment. Generally, a QSA/ISA will initially conduct a GAP assessment to identify areas of noncompliance and provide remediation recommendations. Post-remediation, the QSA/ISA conducts the assessment. To complete the process, the following must be submitted to either the acquiring financial institution or payment card brand:
ROC completed by a QSA or ISA
Evidence of passing vulnerability scans by an ASV
Completion of the Attestation of Compliance by the assessed entity and the QSA
Supporting documentation
FYI: What Are QSAs, ISAs, and ASVs?
The PCI Security Standards Council operates a number of programs to train, test, and certify organizations and individuals to assess and validate adherence to PCI Security Standards. These programs include QSA, ISA, and ASV.
Qualified Security Assessors (QSAs) are organizations that have been qualified by the PCI Security Standards Council to have their employees assess compliance to the PCI DSS standard. Employees of those organizations must be certified by the PCI Security Standards Council to validate an entity’s adherence to the PCI DSS.
Approved Scanning Vendors (ASVs) are organizations that validate adherence to certain DSS requirements by performing vulnerability scans of Internet-facing environments of merchants and service providers.
Internal Security Assessors (ISAs) are sponsor companies that have been qualified by the council. The PCI SSC ISA Program consists of internal security audit professionals of sponsor organizations who are qualified through training from the council to improve their organization’s understanding of the PCI DSS, facilitate the organization’s interactions with QSAs, enhance the quality, reliability, and consistency of the organization’s internal PCI DSS self-assessments, and support the consistent and proper application of PCI DSS measures and controls.
Source: PCI Security Standards Council (www.pcisecuritystandards.org/approved_companies_providers/).
Report on Compliance
As defined in the PCI DSS Requirements and Security Assessment Procedures, the ROC standard template includes the following sections:
Section 1: “Executive Summary”
Section 2: “Description of Scope of Work and Approach Taken”
Section 3: “Details about Reviewed Environment”
Section 4: “Contact Information and Report Date”
Section 5: “Quarterly Scan Results”
Section 6: “Findings and Observations”
Section 7: “Compensating Controls Worksheets” (if applicable)
Sections 1–5 provide a detailed overview of the assessed environment and establish the framework for the assessor’s findings. The ROC template includes specific testing procedures for each PCI DSS requirement.
Section 6, “Findings and Observations,” contains the assessor’s findings for each requirement and testing procedure of the PCI DSS as well as information that supports and justifies each finding. The information provided in “Findings and Observations” summarizes how the testing procedures were performed and the findings achieved. This section includes all 12 PCI DSS requirements.
What Is the PCI DSS Self-Assessment Questionnaire (SAQ)?
The SAQ is a validation tool for merchants that are not required to submit to an onsite data security assessment. Each PCI DSS SAQ includes the following components:
Questions correlating to the PCI DSS requirements, as appropriate for different environments.
Attestation of Compliance, which is your declaration of eligibility for completing the applicable SAQ and the subsequent results of a PCI DSS self-assessment.
Per the May 2016 PCI DSS SAQ Instructions and Guidelines, there are eight SAQ categories. The number of questions varies because the questionnaires are designed to be reflective of the specific payment card channel and the anticipated scope of the cardholder environment.
SAQ A: Applicable to merchants who retain only paper reports or receipts with cardholder data, do not store cardholder data in electronic format, and do not process or transmit any cardholder data on their systems or premises. This would never apply to face-to-face merchants.
SAQ A-EP: Applicable only to e-commerce channels who outsource all payment processing to PCI DSS validated third-party providers.
SAQ B: Applicable to merchants who process cardholder data only via imprint machines or standalone, dial-out terminals. This does not apply to e-commerce merchants.
SAQ B-IP: Applicable to merchants using only standalone payment terminals with IP connectivity to the payment processor with no electronic cardholder data storage. This does not apply to e-commerce merchants.
SAQ C-VT: Applicable to merchants who process cardholder data only via isolated virtual terminals on personal computers connected to the Internet. This does not apply to e-commerce merchants.
SAQ C: Applicable to merchants whose payment application systems are connected to the Internet either because the payment application system is on a personal computer that is connected to the Internet (for example, for email or web browsing) or the payment application system is connected to the Internet to transmit cardholder data.
SAQ P2PE: Applicable to merchants who process cardholder data only via payment terminals included in a validated and PCI SSC–listed Point-to-Point Encryption (P2PE) solution. This does not apply to e-commerce merchants.
SAQ D: Applicable to all other merchants not included in descriptions for SAQ types A through C as well as all service providers defined by a payment brand as eligible to complete an SAQ.
Completing the SAQ
To achieve compliance, the response to each question must either be “yes” or an explanation of a compensating control.
Compensating controls are allowed when an organization cannot implement a specification but has sufficiently addressed the intent using an alternate method. If an entity cannot provide affirmative responses, it is still required to submit an SAQ.
To complete the validation process, the entity submits the SAQ and an accompanying Attestation of Compliance stating that it is or is not compliant with the PCI DSS. If the attestation indicates noncompliance, a target date for compliance along with an action plan needs to be provided. The attestation must be signed by an executive officer.
Are There Penalties for Noncompliance?
There are three types of fines that can be applied to all organizations under PCI regulation:
PCI noncompliance
Account Data Compromise Recovery (ADCR) for compromised domestic-issued cards
Data Compromise Recovery Solution (DCRS) for compromised international-issued cards
Noncompliance penalties are discretionary and can vary greatly, depending on the circumstances. They are not openly discussed or publicized.
FYI: Two Major Credit Card Breach Reports in Less than Two Weeks
Nowadays, data breaches happen practically daily. For example, on March 20, 2018, CNN reported that threat actors stole information from more than 5 million credit and debit cards used at Saks Fifth Avenue, Saks Off 5th, and Lord & Taylor stores. The parent company, Hudson Bay, added that the cards were used for in-store purchases, and there is “no indication” online purchases were affected.
A cybersecurity firm called Gemini Advisory was the one that originally identified the breach. According to Gemini Advisory, the same threat actors that compromised Saks Fifth Avenue, Saks Off 5th, and Lord & Taylor stores were also behind data breaches that affected companies including Whole Foods, Chipotle, Omni Hotels & Resorts, and Trump Hotels.
Less than two weeks after this report, Orbitz disclosed a data breach that affected 880,000 credit cards from its consumers. Reports indicated that threat actors put credit and debit card information they obtained from the victims up for sale on the dark web almost immediately after they were exfiltrated.
Fines and Penalties
More financially significant than PCI noncompliance fines, a data compromise could result in ADCR and/or DCRS penalties. Due to the structure of the payment system, if there is a merchant compromise, the payment brands impose the penalties on the bank that issued the account. The banks pass all liability downstream to the entity. The fines may be up to $500,000 per incident. In addition, the entity may be liable for the following:
All fraud losses perpetrated using the account numbers associated with the compromise (from date of compromise forward)
Cost of reissuance of cards associated with the compromise (approximately $50 per card)
Any additional fraud prevention/detection costs incurred by credit card issuers associated with the compromise (that is, additional monitoring of system for fraudulent activity)
Increased transaction fees
At their discretion, the brands may designate any size compromised merchants as Level 1, which requires an annual onsite compliance assessment. Acquiring banks may choose to terminate the relationship.
Alternately, the payment brands may waive fines in the event of a data compromise if there is no evidence of noncompliance with PCI DSS and brand rules. According to Visa, “to prevent fines, a merchant must maintain full compliance at all times, including at the time of breach as demonstrated during a forensic investigation. Additionally, a merchant must demonstrate that prior to the compromise, the compromised entity had already met the compliance validation requirements, demonstrating full compliance.” This is an impossibly high standard to meet. In reality, uniformly when there has been a breach, the brands have declared the merchant to be noncompliant.
FYI: Home Depot Pays Banks $25 Million in Data Settlement
In March 2017, Home Depot agreed to pay $25 million to banks on a settlement in the federal court in Atlanta. The settlement also mandates that Home Depot must tighten its cybersecurity practices and overall security posture. According to Fortune Magazine, in addition to the $25 million settlement, Home Depot has also paid at least $134.5 million in compensation to consortiums made up of Visa, MasterCard, and various banks.
Summary
The Payment Card Industry Data Security Standard, known as PCI DSS, applies to all entities involved in the payment card channel, including merchants, processors, financial institutions, and service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data. The PCI DSS framework includes stipulations regarding storage, transmission, and processing of payment card data, six core principles, 12 categories of required technical and operational security controls, testing requirements, and a validation and certification process. Entities are required to validate their compliance. The number of transactions, the type of business, and the type of transactions determine specific validation requirements.
Compliance with PCI DSS is a payment card channel contractual obligation. It is not a government regulation or law. The requirement to be PCI-compliant is mandated by the payment card brands in order to accept card payments and/or be part of the payment system. PCI standards augment but do not supersede legislative or regulatory requirements to protect PII or other data elements. Overall, the PCI DSS requirements are reflective of cybersecurity best practices.
Test Your Skills
Multiple Choice Questions
1. The majority of payment card fraud is borne by __________.
A. consumers
B. banks, merchants, and card processors
C. Visa and MasterCard
D. all of the above
2. Which of the following statements best describes an acquirer?
A. Entity that acquires other banks and merchants
B. Entity that initiates and maintains relationships with consumers
C. Entity that initiates and maintains relationships with merchants for the acceptance of payment cards
D. Entity that protects consumers every time that they acquire services and goods
3. A skimmer can be used to read ____________.
A. the cardholder data
B. sensitive authentication data
C. the associated PIN
D. all of the above
4. According to PCI DDS, which of the following is true of the primary account number (PAN)?
A. It must never be stored.
B. It can be stored only in an unreadable (encrypted) format.
C. It should be indexed.
D. It can be stored in plain text.
5. Which of the following describes a merchant according to PCI DSS?
A. Any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC
B. Any entity that enforces the PCI DSS standard
C. Any entity that sells training about the PCI DSS standard
D. Any entity that works with banks and credit card companies to enhance the PCI DSS standard
6. Which of the following tasks is the PCI Security Standards Council not responsible for?
A. Creating a standard framework
B. Certifying ASVs and QSAs
C. Providing training and educational materials
D. Enforcing PCI compliance
7. Which of the following statements is not true about the Luhn algorithm?
A. The Luhn algorithm is an industry algorithm used to validate different identification numbers, including credit card numbers, International Mobile Equipment Identity (IMEI) numbers, National Provider Identifier numbers in the United States, Canadian Social Insurance Numbers, and more.
B. The Luhn algorithm is now in the public domain.
C. The Luhn algorithm is now obsolete.
D. The Luhn algorithm is used by many organizations to validate valid numbers and it uses modulo-10 mathematics.
8. Which of the following statements is not true about the business-as-usual approach?
A. PCI DSS version 3.2 emphasizes that compliance is not a point-in-time determination but rather an ongoing process.
B. Business-as-usual is defined as the inclusion of PCI controls as part of an overall risk-based security strategy that is managed and monitored by the organization.
C. Business-as-usual specifies that organizations must monitor required controls to ensure they are operating effectively, respond quickly to control failures, incorporate PCI compliance impact assessments into the change-management process, and conduct periodic reviews to confirm that PCI requirements continue to be in place and that personnel are following secure processes.
D. Business-as-usual specifies that organizations can optionally monitor cybersecurity controls and conduct periodic reviews for management to determine if they have the appropriate workforce to respond to cybersecurity incidents.
9. Per the PCI Council, the version 3.2 updates are intended to do which of the following?
A. Provide stronger focus on some of the greater risk areas in the threat environment.
B. Build greater understanding of the intent of the requirements and how to apply them.
C. Improve flexibility for all entities implementing, assessing, and building to the standards.
D. All of the above.
10. Which of the following statements best describes the PAN?
A. If the PAN is not stored, processed, or transmitted, then PCI DSS requirements do not apply.
B. If the PAN is not stored, processed, or transmitted, then PCI DSS requirements apply only to e-commerce merchants.
C. If the PAN is not stored, processed, or transmitted, then PCI DSS requirements apply only to Level 1 merchants.
D. None of the above.
11. Which of the following statements best describe the cardholder data environment?
A. The people, processes, and technology that handle cardholder data or sensitive authentication data
B. The bank that processes the cardholder information
C. The merchant that processes the cardholder information
D. The retailer that processes the cardholder information
12. The terms CAV2, CID, CVC2, and CVV2 all refer to the ___________.
A. authentication data
B. security codes
C. expiration date
D. account number
13. There are 12 categories of PCI standards. To be considered compliant, an entity must comply with or document compensating controls for _________.
A. all of the requirements
B. 90% of the requirements
C. 80% of the requirements
D. 70% of the requirements
14. Which of the following is not considered a basic firewall function?
A. Ingress filtering
B. Packet encryption
C. Egress filtering
D. Perimeter protection
15. Which of the following is considered a secure transmission technology?
A. FTP
B. HTTP
C. Telnet
D. SFTP
16. Which of the following statements best describes key management?
A. Key management refers to the generation, storage, and protection of encryption keys.
B. Key management refers to the generation, storage, and protection of server room keys.
C. Key management refers to the generation, storage, and protection of access control list keys.
D. Key management refers to the generation, storage, and protection of card manufacturing keys.
17. Which of the following methods is an acceptable manner in which a merchant can transmit a PAN?
A. Using cellular texting
B. Using an HTTPS/TLS session
C. Using instant messaging
D. Using email
18. Which of the following statements is not part of the “protect stored card data” requirement?
A. Protecting and managing encryption keys (including generation, storage, access, renewal, and replacement)
B. Publishing data-disposal policies and related operational procedures
C. Publishing data-handling standards that clearly delineate how cardholder data is to be handled
D. Selecting an antivirus/antimalware solution commensurate with the level of protection required
19. Which of the following documents lists injection flaws, broken authentication, and cross-site scripting as the top 10 application security vulnerabilities?
A. ISACA Top Ten
B. NIST Top Ten
C. OWASP Top Ten
D. ISO Top Ten
20. Which of the following security principles is best described as the assigning of the minimum required permissions?
A. Need-to-know
B. Default deny
C. Least privilege
D. Separation of duties
21. Which of the following is part of the “develop and maintain secure systems and architecture” PCI DSS requirement?
A. Keeping up-to-date on new vulnerabilities
B. Assessing the risk of new vulnerabilities
C. Maintaining a patch management process
D. All of the above
22. Skimmers can be installed and used to read cardholder data entered at ________.
A. point-of-sale systems
B. ATMs
C. gas pumps
D. all of the above
23. Which of the following is not part of the “track and monitor all access to network resources and cardholder data” PCI DSS requirement?
A. Keeping logs up-to-date to identify new security vulnerability patches
B. Ensuring the date and time stamps are accurate and synchronized across all audit logs
C. Securing audit logs so they cannot be deleted or modified
D. Limiting access to audit logs to individuals with a need to know
24. Quarterly external network scans must be performed by a __________.
A. managed service provider
B. PCI Approved Scanning Vendor (ASV)
C. Qualified Security Assessor
D. independent third party
25. In keeping with the best practices set forth by the PCI standard, how often should cybersecurity policies be reviewed, updated, and authorized?
A. Once
B. Semi-annually
C. Annually
D. Biannually
26. Which of the following is true of PCI requirements?
A. PCI standards augment but do not supersede legislative or regulatory requirements to protect personally identifiable information (PII) or other data elements.
B. PCI standards supersede legislative or regulatory requirements to protect personally identifiable information (PII) or other data elements.
C. PCI requirements invalidate regulatory requirements.
D. None of the above.
27. Which of the following is true about Level 1 merchants versus Levels 2–4 merchants?
A. Level 1 merchants process more than six million payment card transactions annually.
B. Level 1 merchants must pay a fee greater than $6 million.
C. Level 1 merchants must have biannual external penetration testing.
D. Level 1 merchants must complete a self-assessment questionnaire or pay a fine of more than $100,000.
28. PCI DSS version 3.2 incorporates DESV as an appendix primarily to merge requirements and to strengthen the importance of these requirements in establishing and maintaining ongoing cybersecurity processes. DESV is a list of resources and criteria that is designed to help service providers and merchants address key operational challenges while trying to protect payments and maintain compliance. Which of the following is not included in DESV?
A. Compliance program oversight
B. Proper scoping of an environment
C. Guaranteeing that proper mechanisms are used to detect and alert on failures in critical security control
D. The creation of public security vulnerability disclosure policies
29. Which of the following statements best describes the reason different versions of the SAQ are necessary?
A. The number of questions varies by payment card channel and scope of environment.
B. The number of questions varies by geographic location.
C. The number of questions varies by card brand.
D. The number of questions varies by dollar value of transactions.
30. Which of the following SAQs do not apply to e-commerce merchants?
A. SAQ-C
B. SAQ-B
C. SAQ C-VT
D. All of the above
Exercises
Exercise 15.1: Understanding PCI DSS Obligations
Compliance with PCI DSS is a contractual obligation. Explain how this differs from a regulatory obligation.
Which takes precedence—a regulatory requirement or a contractual obligation? Explain your answer.
Who enforces PCI compliance? How is it enforced?
Exercise 15.2: Understanding Cardholder Liabilities
What should a consumer do if he or she misplaces a debit card? Why?
Go online to your bank’s website. Does it post instructions on how to report a lost or stolen debit or credit card? If yes, summarize their instructions. If no, call the bank and request the information be sent to you. (If you don’t have a bank account, choose a local financial institution.)
Explain the difference between the Fair Credit Billing Act (FCBA) and the Electronic Fund Transfer Act (EFTA).
Exercise 15.3: Choosing an Authorized Scanning Vendor
PCI security scans are required for all merchants and service providers with Internet-facing IP addresses. Go online and locate three PCI Council Authorized Scanning Vendors (ASVs) that offer quarterly PCI security scans.
Read their service descriptions. What are the similarities and differences?
Recommend one of the ASVs. Explain your reasoning.
Exercise 15.4: Understanding PIN and Chip Technologies
Payment cards issued in the United States store sensitive authentication information in the magnetic stripe. What are the issues associated with this configuration?
Payment cards issued in Europe store sensitive authentication information in an embedded microchip. What is the advantage of this configuration?
Certain U.S. financial institutions will provide a chip-embedded card upon request. Identify at least one card issuer who will do so. Does it charge extra for the card?
Exercise 15.5: Identifying Merchant Compliance Validation Requirements
Complete the following table:
Merchant Level |
Criteria |
Validation Requirement |
|---|---|---|
|
Processes fewer than 20,000 e-commerce transactions annually |
|
Level 2 |
|
|
|
|
Required onsite annual audit |
Projects
Project 15.1: Applying Encryption Standards
Encryption is referenced a number of times in the PCI DSS standard. For each of the PCI requirements listed below:
Explain the rationale for the requirement.
Identify an encryption technology that can be used to satisfy the requirement.
Identify a commercial application that can be used to satisfy the requirement.
PCI DSS V3.2. 3.4.1: If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.
PCI DSS V3.2. 4.1.1: Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment are using strong encryption protocols for authentication and transmission and use industry best practices to implement strong encryption for authentication and transmission.
PCI DSS V3.2 6.1: Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, “high,” “medium,” or “low”) to newly discovered security vulnerabilities.
Project 15.2: Completing an SAQ
All major credit card companies have dedicated online portals to explain the way that they keep card member information safe and secure. The following are the links to the security portals for several major credit card companies:
American Express: https://merchant-channel.americanexpress.com//merchant/en_US/data-security
Discover Card: https://www.discovernetwork.com/en-us/business-resources/fraud-security/pci-rules-regulations/
VISA: https://usa.visa.com/support/small-business/security-compliance.html
What are the differences and similarities among the information provided by these credit card companies? Describe how they document and address PCI DSS compliance.
Explain how they document requirements that apply to both merchants and service providers.
Does each company clearly list how anyone can report a security incident?
Project 15.3: Reporting an Incident
Assume you are a Level 2 merchant and your organization suspects a breach of Visa cardholder information.
Go to http://usa.visa.com/merchants/risk_management/cisp_if_compromised.html. Document the steps you should take.
Does your state have a breach notification law? If so, would you be required to report this type of breach to a state authority? Would you be required to notify customers? What would you need to do if you had customers who lived in a neighboring state?
Have there been any major card breaches within the last 12 months that affected residents of your state? Summarize such an event.
Case Study
Payment Card Data Breaches
More than 140 million consumers were impacted by the Equifax breach in 2017. Personal information such as social security numbers, birth dates, addresses, and driver license numbers were exposed. In addition, more than 209,000 credit card numbers were also stolen.
Earlier in 2014, more than 56 million credit and debit card data records were stolen by threat actors from Home Depot. Point-of-sale systems were infected by malware.
Research both events and answer the following questions:
Equifax
What are the dates of the incident?
Who first reported the breach?
What information was compromised?
How many cardholders were affected?
How did Equifax notify cardholders?
Is there any indication of how the data was acquired?
Is there any evidence that the criminals used the card data?
Home Deport
Who first reported the incident?
What are the dates associated with the compromise?
What information was compromised?
How many cardholders were affected?
Is there any indication of how the data was acquired?
Were losses sustained by any organization other than Home Depot?
What type of notification was required?
Prior to the breach, both of these organizations were PCI-compliant organizations. Should a card data compromise be a trigger for decertification? Why or why not?
References
“The 17 Biggest Data Breaches of the 21st Century,” CSO Magazine, accessed 04/2018, https://www.csoonline.com/article/2130877/data-breach/the-biggest-data-breaches-of-the-21st-century.html.
Verizon Data Breach Investigations Reports, accessed 04/2018, http://www.verizonenterprise.com/verizon-insights-lab/dbir/.
“PCI Standards and Cardholder Data Security,” Wells Fargo, accessed 04/2018, https://www.wellsfargo.com/biz/merchant/manage/standards.
Krebs, Brian. “All about Skimmers,” accessed 04/2018, https://krebsonsecurity.com/all-about-skimmers.
“Genesco, Inc. v. VISA U.S.A., Inc., VISA Inc., and VISA International Service Association,” United States District Court for the Middle District of Tennessee, Nashville Division, filed March 7, 2013, Case 3:13-cv-00202.
Credit Freeze FAQs, The Federal Trade Commission, accessed 04/2018, https://www.consumer.ftc.gov/articles/0497-credit-freeze-faqs.
“Merchant PCI DSS Compliance,” Visa, accessed 04/2018, http://usa.visa.com/merchants/risk_management/cisp_merchants.html.
“Payment Card Industry Data Security Standard, Version 3.2,” PCI Security Standards Council, LLC, accessed 04/2018, https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf.
“Payment Card Industry Data Security Standard, SAQ documents,” PCI Security Standards Council LLC, accessed 04/2018, https://www.pcisecuritystandards.org/document_library?category=saqs#results.
“Payment Card Industry Data Security Standard, Training and Certification,” PCI Security Standards Council, LLC, accessed 04/2018, https://www.pcisecuritystandards.org/program_training_and_qualification/.
“Payment Card Industry Data Security Standard, Glossary of Terms, Abbreviations, and Acronyms,” accessed 04/2018, https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf.
“PCI DSS Quick Reference Guide”, PCI SSC, accessed 04/2018, https://www.pcisecuritystandards.org/documents/PCIDSS_QRGv3_2.pdf.
“Payment Card Industry Data Security Standard and Payment Application Data Security Standard, Version 3.2: Change Highlights,” PCI Security Standards Council, LLC, August 2013.
“Credit Card Breach at Buckle Stores,” Brian Krebs, accessed 04/2018, https://krebsonsecurity.com/2017/06/credit-card-breach-at-buckle-stores.
“Largest Hacking Fraud Case Launched After Credit Card Info Stolen from J.C. Penney, Visa Licensee,” The Huffington Post, accessed 04/2018, https://www.huffingtonpost.com/2013/07/25/credit-card-stolen-visa_n_3653274.html.
“Home Depot to Pay Banks $25 Million in Data Breach Settlement,” Fortune Magazine, accessed 04/2018, http://fortune.com/2017/03/09/home-depot-data-breach-banks.
“The Costs of Failing a PCI-DSS Audit,” Hytrust, accessed 04/2018, https://www.hytrust.com/wp-content/uploads/2015/08/HyTrust_Cost_of_Failed_Audit.pdf.
OWASP Top 10 Project, accessed 04/2018, https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.
“Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire, Instructions and Guidelines,” PCI SSC, accessed 04/2018, https://www.pcisecuritystandards.org/documents/SAQ-InstrGuidelines-v3_2.pdf.
“Saks, Lord & Taylor Breach: Data Stolen on 5 Million Cards,” CNN, accessed 04/2018, http://money.cnn.com/2018/04/01/technology/saks-hack-credit-debit-card/index.html.
“Orbitz Says a Possible Data Breach Has Affected 880,000 Credit Cards,” The Verge, accessed 04/2018, https://www.theverge.com/2018/3/20/17144482/orbitz-data-breach-credit-cards.