Document Comparison
PCI_DSS-QRG-v3_2_1.pdf
→
PCI_DSS-QRG-v4_0.pdf
20% similar
39 → 38
Pages
10788 → 9667
Words
76
Content Changes
Content Changes
76 content changes. 8 administrative changes (dates, page numbers) hidden.
Added
p. 4
Importance of Protecting Payment Account Data with the PCI Data Security Standard The global acceleration of cashless transactions puts payment systems in the crosshairs of criminals looking for easy money. Payment account data is their Number One attraction
• 84 percent of data breach caseloads entailed payment card data, according to Verizon. They all seek the simplest path to steal payment account data used by payment cards and related electronic payment systems.
As a payment system stakeholder, your company is on the front line of a high-stakes battle for keeping payment data safe from theft and exploitation. Occasional lax security enables criminals to easily steal and use personal consumer financial information from payment transactions and processing systems.
• cloud-based systems;
#1 ATTRACTION IS PAYMENT ACCOUNT DATA 84% of data breach caseloads entailed payment account data 93% of data breaches had financial motive by actors Source: Verizon 2022 Data Breach Investigations Report, pp. 18 and …
• 84 percent of data breach caseloads entailed payment card data, according to Verizon. They all seek the simplest path to steal payment account data used by payment cards and related electronic payment systems.
As a payment system stakeholder, your company is on the front line of a high-stakes battle for keeping payment data safe from theft and exploitation. Occasional lax security enables criminals to easily steal and use personal consumer financial information from payment transactions and processing systems.
• cloud-based systems;
#1 ATTRACTION IS PAYMENT ACCOUNT DATA 84% of data breach caseloads entailed payment account data 93% of data breaches had financial motive by actors Source: Verizon 2022 Data Breach Investigations Report, pp. 18 and …
Added
p. 17
Requirement 12.8 does not specify that the customer’s TPSPs must be PCI DSS compliant, only that the customer monitors their TPSPs’ compliance status. Therefore, a TPSP does not need to be PCI DSS compliant for its customer to meet Requirement 12.8.
Using TPSPs for services that meet customer’s PCI DSS requirements When the TPSP provides a service that meets PCI DSS requirements on the customer’s behalf or where that service may impact the security of the customer’s CDE, then those requirements are in scope for the customer’s assessment and the compliance of that service will impact the customer’s PCI DSS compliance. The TPSP must demonstrate it meets applicable PCI DSS requirements for those requirements to be in place for its customer.
Understanding responsibilities between customers and TPSPs Customers and TPSPs should clearly identify and understand the services and system components included in the scope of the TPSP’s PCI DSS assessment, the specific …
Using TPSPs for services that meet customer’s PCI DSS requirements When the TPSP provides a service that meets PCI DSS requirements on the customer’s behalf or where that service may impact the security of the customer’s CDE, then those requirements are in scope for the customer’s assessment and the compliance of that service will impact the customer’s PCI DSS compliance. The TPSP must demonstrate it meets applicable PCI DSS requirements for those requirements to be in place for its customer.
Understanding responsibilities between customers and TPSPs Customers and TPSPs should clearly identify and understand the services and system components included in the scope of the TPSP’s PCI DSS assessment, the specific …
Added
p. 23
• Requirement Description organizes and describes associated requirements.
• Defined Approach and associated Defined Approach Testing Procedures. These procedures are the traditional method for implementing and validating PCI DSS using the Requirements and Testing Procedures defined in the standard.
• Customized Approach Objective is the intended goal or outcome for the requirement. It must be met by entities using a Customized Approach.
• Defined Approach and associated Defined Approach Testing Procedures. These procedures are the traditional method for implementing and validating PCI DSS using the Requirements and Testing Procedures defined in the standard.
• Customized Approach Objective is the intended goal or outcome for the requirement. It must be met by entities using a Customized Approach.
Added
p. 23
• Guidance provides information, categorized into sections, to understand how to meet a requirement. Guidance is not required to be followed
• it does not replace or extend any PCI DSS requirement.
Summary of PCI DSS v4.0 Requirements 1•12 Build and Maintain a Secure Network and Systems In the past, theft of financial records required a criminal to physically enter an entity’s business site. Now, payment transactions occur with many different electronic devices, including traditional payment terminals, mobile devices, and other Internet connected computer systems. By using network security controls, entities can prevent criminals from virtually accessing payment system networks and stealing payment account data.
Click to see the full image of annotated details on “Understanding Information in PCI DSS Requirements” https://www.pcisecuritystandards. org/understanding-information-in- pci-dss-requirements_/ This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Requirement 1: Install and maintain network security controls Network security controls …
• it does not replace or extend any PCI DSS requirement.
Summary of PCI DSS v4.0 Requirements 1•12 Build and Maintain a Secure Network and Systems In the past, theft of financial records required a criminal to physically enter an entity’s business site. Now, payment transactions occur with many different electronic devices, including traditional payment terminals, mobile devices, and other Internet connected computer systems. By using network security controls, entities can prevent criminals from virtually accessing payment system networks and stealing payment account data.
Click to see the full image of annotated details on “Understanding Information in PCI DSS Requirements” https://www.pcisecuritystandards. org/understanding-information-in- pci-dss-requirements_/ This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Requirement 1: Install and maintain network security controls Network security controls …
Added
p. 24
Requirement 2: Apply secure configurations to all system components Malicious individuals, both external and internal to an entity, often use default passwords and other vendor default settings to compromise systems. These passwords and settings are well known and are easily determined via public information.
Applying secure configurations to system components reduces the means available to an attacker to compromise systems. Changing default passwords, removing unnecessary software, functions, and accounts, and disabling or removing unnecessary services all help to reduce the potential attack surface.
Applying secure configurations to system components reduces the means available to an attacker to compromise systems. Changing default passwords, removing unnecessary software, functions, and accounts, and disabling or removing unnecessary services all help to reduce the potential attack surface.
Added
p. 25
Protect Account Data Payment account data refers to any information printed, processed, transmitted, or stored in any form on a payment card. Account data refers to both cardholder data and sensitive authentication data, and protection of the account data is required where account data is stored, processed, or transmitted. Entities accepting payment cards are expected to protect account data and to prevent its unauthorized use
• whether the data is printed or stored locally, or transmitted over an internal or public network to a remote server or service provider.
Requirement 3: Protect stored account data Payment account data should not be stored unless it is necessary to meet the needs of the business. Sensitive authentication data must never be stored after authorization. If your organization stores PAN, it is crucial to render it unreadable. If your company stores sensitive authentication data prior to completion of authorization, that data must also be protected1.
• whether the data is printed or stored locally, or transmitted over an internal or public network to a remote server or service provider.
Requirement 3: Protect stored account data Payment account data should not be stored unless it is necessary to meet the needs of the business. Sensitive authentication data must never be stored after authorization. If your organization stores PAN, it is crucial to render it unreadable. If your company stores sensitive authentication data prior to completion of authorization, that data must also be protected1.
Added
p. 25
This is secret stuff, please do not… This is secret stuff, please do not… Illustration: Wikimedia Commons This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Elements of Account Data and Storage Requirements
Table 3 in PCI DSS (see below) identifies the elements of cardholder and sensitive authentication data, whether storage of each data element is permitted or prohibited, and whether each data element must be rendered unreadable
• for example, with strong cryptography
• when stored. This table is not exhaustive and is presented to illustrate only how the stated requirements apply to the different data elements.
Data Elements Storage Restrictions Required to Render Stored Data Unreadable Account Data Cardholder Data Primary Account Number (PAN) Storage is kept to a minimum as defined in Requirement 3.2 Yes, as defined in Requirement 3.5 Cardholder Name Storage is kept to a minimum as defined in Requirement …
Elements of Account Data and Storage Requirements
Table 3 in PCI DSS (see below) identifies the elements of cardholder and sensitive authentication data, whether storage of each data element is permitted or prohibited, and whether each data element must be rendered unreadable
• for example, with strong cryptography
• when stored. This table is not exhaustive and is presented to illustrate only how the stated requirements apply to the different data elements.
Data Elements Storage Restrictions Required to Render Stored Data Unreadable Account Data Cardholder Data Primary Account Number (PAN) Storage is kept to a minimum as defined in Requirement 3.2 Yes, as defined in Requirement 3.5 Cardholder Name Storage is kept to a minimum as defined in Requirement …
Added
p. 27
Maintain a Vulnerability Management Program Vulnerability management is the process of systematically and continuously finding and mitigating weaknesses in an entity’s payment card environment. This includes addressing threats from malicious software, routinely identifying and patching vulnerabilities, and ensuring that software is developed securely and without known coding vulnerabilities.
Requirement 5: Protect all systems and networks from malicious software Malicious software (malware) is software or firmware designed to infiltrate or damage a computer system without the owner’s knowledge or consent, with the intent of compromising the confidentiality, integrity, or availability of the owner’s data, applications, or operating system. Examples include viruses, worms, Trojans, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links. Malware can enter the network during many business-approved activities, including employee e-mail (for example, via phishing) and use of the internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities.
Requirement 5: Protect all systems and networks from malicious software Malicious software (malware) is software or firmware designed to infiltrate or damage a computer system without the owner’s knowledge or consent, with the intent of compromising the confidentiality, integrity, or availability of the owner’s data, applications, or operating system. Examples include viruses, worms, Trojans, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links. Malware can enter the network during many business-approved activities, including employee e-mail (for example, via phishing) and use of the internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities.
Added
p. 27
VULNERABILITY MANAGEMENT Create a policy governing security controls according to industry standards and best practices.
Regularly scan systems for vulnerabilities.
Create a remediation schedule based on risk and priority.
Pre-test and deploy patches.
Rescan to verify vulnerabilities are addressed.
Update all software with the most current signatures and technology.
Use only software or systems that are securely developed following industry standard best practices.
Regularly scan systems for vulnerabilities.
Create a remediation schedule based on risk and priority.
Pre-test and deploy patches.
Rescan to verify vulnerabilities are addressed.
Update all software with the most current signatures and technology.
Use only software or systems that are securely developed following industry standard best practices.
Added
p. 28
Requirement 6: Develop and maintain secure systems and software Security vulnerabilities in systems and applications may allow criminals to access payment data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches, which perform a quick-repair job for a specific piece of programming code. All system components must have the most recently released critical security patches installed to prevent exploitation. Entities must also apply patches to less-critical systems in an appropriate timeframe, based on a formal risk analysis. Applications must be developed according to secure development and coding practices, and changes to systems in the cardholder data environment must follow change control procedures.
Added
p. 28
Typically, bespoke software is developed by a third party on the entity’s behalf, while custom software is developed internally by the entity.
Implement Strong Access Control Measures Access to payment account data must be granted only on a business need-to-know basis. Logical access controls are technical means used to permit or deny access to data on computer systems. Physical access controls entail the use of locks or other physical means to restrict access to computer media, paper-based records, and computer systems.
Requirement 7: Restrict access to cardholder data by business need-to-know Unauthorized individuals may gain access to critical data or systems due to ineffective access control rules and definitions. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. “Need to know” refers to providing access to only the least amount …
Implement Strong Access Control Measures Access to payment account data must be granted only on a business need-to-know basis. Logical access controls are technical means used to permit or deny access to data on computer systems. Physical access controls entail the use of locks or other physical means to restrict access to computer media, paper-based records, and computer systems.
Requirement 7: Restrict access to cardholder data by business need-to-know Unauthorized individuals may gain access to critical data or systems due to ineffective access control rules and definitions. To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. “Need to know” refers to providing access to only the least amount …
Added
p. 29
Restrict access to cardholder data environments by employing physical and logical access controls.
Limit access to only those individuals whose job requires such access.
Formalize an access control policy that includes a list of who gets access to specific account data and systems.
Deny all access to anyone who is not specifically allowed to access cardholder data and systems.
Requirement 8: Identify users and authenticate access to system components Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. Unless otherwise stated in the requirement, these requirements apply to all accounts, including point-of-sale accounts, those with administrative capabilities, and all accounts used to view or access payment account data or systems with those data. These requirements do not apply to accounts used by consumers (cardholders).
Limit access to only those individuals whose job requires such access.
Formalize an access control policy that includes a list of who gets access to specific account data and systems.
Deny all access to anyone who is not specifically allowed to access cardholder data and systems.
Requirement 8: Identify users and authenticate access to system components Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. Unless otherwise stated in the requirement, these requirements apply to all accounts, including point-of-sale accounts, those with administrative capabilities, and all accounts used to view or access payment account data or systems with those data. These requirements do not apply to accounts used by consumers (cardholders).
Added
p. 30
IDENTIFY AND AUTHENTICATE ALL USERS Every user with access to the cardholder data environment must have a unique ID. This allows a business to trace every action to a specific individual. Every user should have a strong authentication mechanism
• such as a strong password, biometric, or access token
• and use multi-factor authentication for all access into the CDE4.
Photo: Wikimedia Commons 4 The requirement for use of multi-factor authentication for all access into the CDE is a best practice until 31 March 2025, after which it must be fully considered as part of a PCI DSS assessment.
Requirement 9: Restrict physical access to cardholder data Physical access to cardholder data or systems that store, process, or transmit cardholder data should be restricted so that unauthorized individuals cannot access or remove systems or hardcopies containing this data.
• such as a strong password, biometric, or access token
• and use multi-factor authentication for all access into the CDE4.
Photo: Wikimedia Commons 4 The requirement for use of multi-factor authentication for all access into the CDE is a best practice until 31 March 2025, after which it must be fully considered as part of a PCI DSS assessment.
Requirement 9: Restrict physical access to cardholder data Physical access to cardholder data or systems that store, process, or transmit cardholder data should be restricted so that unauthorized individuals cannot access or remove systems or hardcopies containing this data.
Added
p. 31
MERCHANTS MUST INSPECT PAYMENT DEVICES Criminals can steal payment account data by replacing and/ or manipulating card-reading devices and terminals. Merchants must periodically inspect payment devices for “skimming” components or other tampering (see PCI DSS Requirement 9.5.1).
• Maintain a list of point of interaction (POI) devices.
• Periodically inspect POI devices to look for tampering or unauthorized substitution.
• Train personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices.
Photo: Wikimedia Commons 33 This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Regularly Monitor and Test Networks Physical, virtual, and wireless networks are the glue connecting all endpoints and servers in the payment infrastructure. Vulnerabilities in network devices and systems present opportunities for criminals to gain unauthorized access to payment applications and payment account data. To prevent exploitation, entities must regularly monitor and test networks to find …
• Maintain a list of point of interaction (POI) devices.
• Periodically inspect POI devices to look for tampering or unauthorized substitution.
• Train personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices.
Photo: Wikimedia Commons 33 This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Regularly Monitor and Test Networks Physical, virtual, and wireless networks are the glue connecting all endpoints and servers in the payment infrastructure. Vulnerabilities in network devices and systems present opportunities for criminals to gain unauthorized access to payment applications and payment account data. To prevent exploitation, entities must regularly monitor and test networks to find …
Added
p. 32
MONITOR ALL ACTIVITIES 10.2.2 Audit logs record the following details for each auditable event:
• User identification
• Success and failure indication
• Origination of event
• Identity or name of affected data, system component, resource, or service (for example, name and protocol).
Requirement 11: Test security of systems and networks regularly Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.
• User identification
• Success and failure indication
• Origination of event
• Identity or name of affected data, system component, resource, or service (for example, name and protocol).
Requirement 11: Test security of systems and networks regularly Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.
Added
p. 33
TIPS FOR SCANNING Get Advice. Ask your acquiring bank about any partnerships they may have with PCI Approved Scanning Vendors (ASVs).
Talk to a PCI ASV. See PCI Council website for the list of PCI ASVs.
Select an ASV. Contact several PCI ASVs and select a suitable program.
Address Vulnerabilities. Ask your PCI ASV for help correcting issues found by scanning.
SEVERITY LEVELS FOR VULNERABILITY SCANNING CVSS Score Severity Level Scan Results 7.0 through 10.0 High Severity Fail 4.0 through 6.9 Medium Severity Fail 0.0 through 3.9 Low Severity Pass Note that external vulnerability scanning must be performed at least once every three months by a PCI Approved Scanning Vendor. To receive a “pass,” external scan reports must not include any vulnerability that has been assigned a Common Vulnerability Scoring System (CVSS) base score equal to or higher than 4.0 or any vulnerability that indicates features or configurations that are in violation of PCI …
Talk to a PCI ASV. See PCI Council website for the list of PCI ASVs.
Select an ASV. Contact several PCI ASVs and select a suitable program.
Address Vulnerabilities. Ask your PCI ASV for help correcting issues found by scanning.
SEVERITY LEVELS FOR VULNERABILITY SCANNING CVSS Score Severity Level Scan Results 7.0 through 10.0 High Severity Fail 4.0 through 6.9 Medium Severity Fail 0.0 through 3.9 Low Severity Pass Note that external vulnerability scanning must be performed at least once every three months by a PCI Approved Scanning Vendor. To receive a “pass,” external scan reports must not include any vulnerability that has been assigned a Common Vulnerability Scoring System (CVSS) base score equal to or higher than 4.0 or any vulnerability that indicates features or configurations that are in violation of PCI …
Added
p. 35
PCI SSC Blog Subscribe to the PCI Perspectives Blog Membership Information Merchant Resources Training Qualified PCI Products & Solutions Qualified PCI Professionals PCI Data Security Standard (PCI DSS) Glossary Threat Center 37 This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
The PCI SSC maintains, evolves, and promotes the Payment Card Industry Security Standards. It also provides critical tools needed for implementation of the standards, such as assessment and scanning qualifications, self-assessment questionnaires, training and education, and product certification programs.
The PCI SSC is led by a policy-setting Executive Committee composed of representatives from the Founding Members and Strategic Members: American Express, Discover Financial Services, JCB International, Mastercard, UnionPay, and Visa Inc.
Participating Organization membership in the PCI SSC is open globally to those affiliated with the payments industry, including merchants, banks, processors, hardware and software developers, and point-of-sale vendors.
Industry stakeholders are encouraged …
The PCI SSC maintains, evolves, and promotes the Payment Card Industry Security Standards. It also provides critical tools needed for implementation of the standards, such as assessment and scanning qualifications, self-assessment questionnaires, training and education, and product certification programs.
The PCI SSC is led by a policy-setting Executive Committee composed of representatives from the Founding Members and Strategic Members: American Express, Discover Financial Services, JCB International, Mastercard, UnionPay, and Visa Inc.
Participating Organization membership in the PCI SSC is open globally to those affiliated with the payments industry, including merchants, banks, processors, hardware and software developers, and point-of-sale vendors.
Industry stakeholders are encouraged …
Modified
p. 2
PCI DSS Quick Reference Guide: Understanding the Payment Card Industry Data Security Standard version 3.2.1.
PCI DSS Quick Reference Guide: Understanding the Payment Card Industry Data Security Standard version 4.0.
Modified
p. 2
This Quick Reference Guide to the PCI Data Security Standard (PCI DSS) is provided by the PCI Security Standards Council (PCI SSC) to inform and educate merchants and other entities involved in payment card processing. For more information about the PCI SSC and the standards we manage, please visit www.pcisecuritystandards.org.
This Quick Reference Guide to the PCI Data Security Standard (PCI DSS) is provided by the PCI Security Standards Council (PCI SSC) to inform and educate merchants and other entities involved in payment card processing. For more information about the PCI SSC and the standards we manage, please visit https://pcisecuritystandards.org.
Removed
p. 4
It’s a serious problem
• more than 10.9 billion records with sensitive information have been breached according to public disclosures between January 2005 and July 2018, according to PrivacyRights.org. As you are a key participant in payment card transactions, it is imperative that you use standard security procedures and technologies to thwart theft of cardholder data.
DATA TYPES COMPROMISED IN BREACHES 22% card track data 18% card-not-present (e-commerce) 16% financial/user credentials Source: 2018 Trustwave Global Security Report, p. 30 https://www2.trustwave.com/ GlobalSecurityReport.html (form to access report) This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 5 The intent of this PCI DSS Quick Reference Guide is to help you understand how the PCI DSS can help protect your payment card transaction environment and how to apply it.
• more than 10.9 billion records with sensitive information have been breached according to public disclosures between January 2005 and July 2018, according to PrivacyRights.org. As you are a key participant in payment card transactions, it is imperative that you use standard security procedures and technologies to thwart theft of cardholder data.
DATA TYPES COMPROMISED IN BREACHES 22% card track data 18% card-not-present (e-commerce) 16% financial/user credentials Source: 2018 Trustwave Global Security Report, p. 30 https://www2.trustwave.com/ GlobalSecurityReport.html (form to access report) This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 5 The intent of this PCI DSS Quick Reference Guide is to help you understand how the PCI DSS can help protect your payment card transaction environment and how to apply it.
Modified
p. 4
Vulnerabilities may appear anywhere in the card-processing ecosystem, including but not limited to:
Modified
p. 4
• mobile devices, personal computers or servers;
• mobile devices, personal computers, or servers;
Modified
p. 4
• in remote access connections.
• remote access connections.
Modified
p. 4
Compliance with the PCI DSS helps to alleviate these vulnerabilities and protect cardholder data.
Compliance with PCI DSS helps to alleviate these vulnerabilities and protect payment account data.
Removed
p. 5
PCI DSS follows common-sense steps that mirror security best practices. The PCI DSS globally applies to all entities that store, process or transmit cardholder data and/or sensitive authentication data. PCI DSS and related security standards are administered by the PCI Security Standards Council, which was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. Participating Organizations include merchants, payment card issuing banks, processors, developers and other vendors.
Modified
p. 5
There are three ongoing steps for adhering to the PCI DSS:
There are four ongoing steps to protecting payment account data with PCI DSS:
Modified
p. 5
Assess
• identifying all locations ofcardholder data, taking an inventory of your IT assets and business processes for payment card processing and analyzing them for vulnerabilities that could expose cardholder data.
• identifying all locations of
Assess
• identifying all locations of payment account data, taking an inventory of all IT assets and business processes associated with payment processing, analyzing them for vulnerabilities that could expose payment account data, implementing or updating necessary controls, and undergoing a formal PCI DSS assessment.
• identifying all locations of payment account data, taking an inventory of all IT assets and business processes associated with payment processing, analyzing them for vulnerabilities that could expose payment account data, implementing or updating necessary controls, and undergoing a formal PCI DSS assessment.
Modified
p. 5
• fixing identified vulnerabilities, securely removing any unnecessary
Remediate
• identifying and addressing any gaps in security controls, fixing identified vulnerabilities, securely removing any unnecessary payment data storage, and implementing secure business processes.
• identifying and addressing any gaps in security controls, fixing identified vulnerabilities, securely removing any unnecessary payment data storage, and implementing secure business processes.
Modified
p. 5
Report
• documenting assessment and remediation details, and submitting compliance reports to the acquiring bankand card brands you do business with (or other requesting entity if you’re a service provider).
• documenting assessment and remediation details, and submitting compliance reports to the acquiring bank
Report
• documenting assessment and remediation details, and submitting compliance reports to the compliance-accepting entity (typically, an acquiring bank or payment brands).
• documenting assessment and remediation details, and submitting compliance reports to the compliance-accepting entity (typically, an acquiring bank or payment brands).
Modified
p. 5
PCI DSS COMPLIANCE IS A CONTINUOUS PROCESS POS Merchant Acquirer Service Provider INTERNET PUBLIC NETWORKS INTERNET PUBLIC NETWORKS INTERNET PUBLIC NETWORKS This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
PCI DSS IS A CONTINUOUS PROCESS Overview of PCI SSC Standards This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Removed
p. 6
PCI Security Standards are technical and operational requirements set by the PCI Security Standards Council (PCI SSC) to protect cardholder data. The standards apply to all entities that store, process or transmit cardholder data
• with requirements for software developers and manufacturers of applications and devices used in those transactions. The Council is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover Financial Services, JCB, MasterCard and Visa Inc.
PAYMENT CARD INDUSTRY SECURITY STANDARDS Protection of Cardholder Payment Data Manufacturers Software Developers Merchants & Service Providers
PCI Security & Compliance PCI PTS Payment Applications Secure Environments PIN Entry Devices
• with requirements for software developers and manufacturers of applications and devices used in those transactions. The Council is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover Financial Services, JCB, MasterCard and Visa Inc.
PAYMENT CARD INDUSTRY SECURITY STANDARDS Protection of Cardholder Payment Data Manufacturers Software Developers Merchants & Service Providers
PCI Security & Compliance PCI PTS Payment Applications Secure Environments PIN Entry Devices
Removed
p. 7
PCI Security Standards Include: PCI Data Security Standard (PCI DSS) The PCI DSS applies to all entities that store, process, and/or transmit cardholder data. It covers technical and operational system components included in or connected to cardholder data. If you accept or process payment cards, PCI DSS applies to you.
PIN Transaction Security (PTS) Requirements The PCI PTS is a set of security requirements focused on characteristics and management of devices used in the protection of cardholder PINs and other payment processing related activities. The PTS standards include PIN Security Requirements, Point of Interaction (POI) Modular Security Requirements, and Hardware Security Module (HSM) Security Requirements. The device requirements are for manufacturers to follow in the design, manufacture and transport of a device to the entity that implements it. Financial institutions, processors, merchants and service providers should only use devices or components that are tested and approved by the PCI SSC, listed …
PIN Transaction Security (PTS) Requirements The PCI PTS is a set of security requirements focused on characteristics and management of devices used in the protection of cardholder PINs and other payment processing related activities. The PTS standards include PIN Security Requirements, Point of Interaction (POI) Modular Security Requirements, and Hardware Security Module (HSM) Security Requirements. The device requirements are for manufacturers to follow in the design, manufacture and transport of a device to the entity that implements it. Financial institutions, processors, merchants and service providers should only use devices or components that are tested and approved by the PCI SSC, listed …
Removed
p. 8
PCI Card Production Logical Security Requirements and Physical Security Requirements The Card Production Logical and Physical Security Requirements address card production activities including card manufacturing, chip embedding, data preparation, pre-personalization, card personalization, chip personalization, fulfillment, packaging, storage, mailing, shipping, PIN printing and mailing (personalized, credit or debit), PIN printing (non-personalized prepaid cards), and electronic PIN distribution.
PCI Token Service Provider Security Requirements The Token Service Provider (TSP) Security Requirements are intended for Token Service Providers that generate and issue EMV Payment Tokens, as defined under the EMV® Payment Tokenisation Specification Technical Framework.
The PCI Standards can all be downloaded from the PCI SSC Document Library: https://www.pcisecuritystandards.org/document_library This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 9 The PCI Data Security Standard
PCI Token Service Provider Security Requirements The Token Service Provider (TSP) Security Requirements are intended for Token Service Providers that generate and issue EMV Payment Tokens, as defined under the EMV® Payment Tokenisation Specification Technical Framework.
The PCI Standards can all be downloaded from the PCI SSC Document Library: https://www.pcisecuritystandards.org/document_library This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 9 The PCI Data Security Standard
Modified
p. 8 → 7
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
The PCI Standards can all be downloaded from the PCI SSC Document Library: https://pcisecuritystandards.org/document_library Introduction to PCI DSS This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Removed
p. 9
PCI DSS is the global data security standard adopted by the payment card brands for all entities that process, store or transmit cardholder data and/or sensitive authentication data. It consists of steps that mirror security best practices.
1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program
5. Protect all systems against malware and regularly update anti- virus software or programs 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need to know 8. Identify and authenticate access to system components 9. Restrict physical access to cardholder data Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data …
1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program
5. Protect all systems against malware and regularly update anti- virus software or programs 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need to know 8. Identify and authenticate access to system components 9. Restrict physical access to cardholder data Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data …
Removed
p. 10
Qualified Assessors. The Council manages programs that will help facilitate the assessment of compliance with PCI DSS: Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV). QSAs are approved by the Council to assess compliance with the PCI DSS. ASVs are approved by the Council to validate adherence to the PCI DSS scan requirements by performing vulnerability scans of Internet-facing environments of merchants and service providers. The Council also provides PCI DSS training for Internal Security Assessors (ISAs). Additional details can be found on our website at: www.pcisecuritystandards.org/approved_companies_providers/index.php.
Self-Assessment Questionnaire. The Self-Assessment Questionnaire (SAQ) is a validation tool for eligible organizations who self-assess their PCI DSS compliance and who are not required to submit a Report on Compliance (ROC). Different SAQs are available for various business environments; more details can be found on our website at: www.pcisecuritystandards.org/document_ library?category=saqs#. To determine whether you should complete a SAQ (and if so, which one), …
Self-Assessment Questionnaire. The Self-Assessment Questionnaire (SAQ) is a validation tool for eligible organizations who self-assess their PCI DSS compliance and who are not required to submit a Report on Compliance (ROC). Different SAQs are available for various business environments; more details can be found on our website at: www.pcisecuritystandards.org/document_ library?category=saqs#. To determine whether you should complete a SAQ (and if so, which one), …
Modified
p. 11 → 10
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 11 Security Controls and Processes for PCI DSS Requirements The goal of the PCI Data Security Standard (PCI DSS) is to protect cardholder data and sensitive authentication data wherever it is processed, stored or transmitted. The security controls and processes required by PCI DSS are vital for protecting all payment card account data, including the PAN
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Modified
p. 11 → 10
CID (American Express) Expiration Date Magnetic Stripe (data on tracks 1 & 2) CAV2/CID/CVC2/CVV2 (all other payment card brands) Types of Data on a Payment Card Cardholder This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
CID (American Express) Expiration Date Magnetic Stripe (data on tracks 1 & 2) CAV2/CID/CVC2/CVN2/CVV2 (all other payment card brands) Types of Data on a Payment Card Cardholder Name 11 This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Removed
p. 12
Requirement 1: Install and maintain a firewall configuration to protect cardholder data Firewalls are devices that control computer traffic allowed into and out of an organization’s network, and into sensitive areas within its internal network. Firewall functionality can also appear in other system components. Routers are hardware or software that connects two or more networks. All such networking devices are in scope for assessment of Requirement 1 if used within the cardholder data environment. 1.1 Establish and implement firewall and router configuration standards that formalize testing whenever configurations change; that identify all connections between the cardholder data environment and other networks (including wireless) with documentation and diagrams; that document business justification and various technical settings for each implementation; that diagram all cardholder data flows across systems and networks; and stipulate a review of configuration rule sets at least every six months. 1.2 Build firewall and router configurations that restrict all …
Removed
p. 14
Requirement 3: Protect stored cardholder data Cardholder data should not be stored unless it’s necessary to meet the needs of the business. Sensitive data on the magnetic stripe or chip must never be stored after authorization. If your organization stores PAN, it is crucial to render it unreadable (see 3.4, and table below for guidelines).
Removed
p. 15
Guidelines for Cardholder Data Elements Data Element Storage Permitted Render Stored Data Unreadable per Requirement 3.4 Cardholder Primary Account Number (PAN) Yes Yes Cardholder Name Yes No Service Code Yes No Expiration Date Yes No Sensitive Authentication Full Track Data2 No Cannot store per Requirement 3.2 CAV2/CVC2/CVV2/CID3 No Cannot store per Requirement 3.2 PIN/PIN Block4 No Cannot store per Requirement 3.2 1 Sensitive authentication data must not be stored after authorization (even if encrypted) 2 Full track data from the magnetic stripe, equivalent data on the chip, or elsewhere.
Removed
p. 16
Maintain a Vulnerability Management Program Vulnerability management is the process of systematically and continuously finding weaknesses in an entity’s payment card infrastructure system. This includes security procedures, system design, implementation, or internal controls that could be exploited to violate system security policy.
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs Malicious software (a.k.a “malware”) exploits system vulnerabilities after entering the network via users’ e-mail and other online business activities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti-malware solutions may supplement (but not replace) anti-virus software.
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 17 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). For systems not affected commonly by malicious software, …
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs Malicious software (a.k.a “malware”) exploits system vulnerabilities after entering the network via users’ e-mail and other online business activities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. Additional anti-malware solutions may supplement (but not replace) anti-virus software.
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 17 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). For systems not affected commonly by malicious software, …
Removed
p. 17
Requirement 6: Develop and maintain secure systems and applications Security vulnerabilities in systems and applications may allow criminals to access PAN and other cardholder data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches, which perform a quick-repair job for a specific piece of programming code. All critical systems must have the most recently released software patches to prevent exploitation. Entities should apply patches to less-critical systems as soon as possible, based on a risk-based vulnerability management program. Secure coding practices for developing applications, change control procedures and other secure software development practices should always be followed.
Removed
p. 17
VULNERABILITY MANAGEMENT Create policy governing security controls according to industry standard best practices Regularly scan systems for vulnerabilities Create remediation schedule based on risk and priority Pre-test and deploy patches Rescan to verify compliance Update security software with the most current signatures and technology Use only software or systems that were securely developed by industry standard best practices This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Removed
p. 18
Implement Strong Access Control Measures Access-controls allow merchants to permit or deny the use of physical or technical means to access PAN and other cardholder data. Access must be granted on a business need-to-know basis. Physical access controls entail the use of locks or other means to restrict access to computer media, paper-based records or system hardware. Logical access controls permit or deny use of payment devices, wireless networks, PCs and other computing devices, and also controls access to digital files containing cardholder data.
Requirement 7: Restrict access to cardholder data by business need-to-know To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
Requirement 7: Restrict access to cardholder data by business need-to-know To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job.
Removed
p. 18
Restrict Access to Cardholder Data Environments by employing access controls Limit access to only those individuals whose job requires such access Formalize an access control policy that includes a list of who gets access to specified cardholder data and systems Deny all access to anyone who is not specifically allowed to access cardholder data and systems Photo: Wikimedia Commons This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 19 7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
Requirement 8: Identify and authenticate access to system components Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. Requirements apply to all …
Requirement 8: Identify and authenticate access to system components Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. Requirements apply to all …
Removed
p. 19
IDENTIFY AND AUTHENTICATE ALL USERS Every user with access to the Cardholder Data Environment must have a unique ID. This allows a business to trace every action to a specific individual. Every user should have a strong password for authentication.
Removed
p. 20
Requirement 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data provides the opportunity for persons to access and/or remove devices, data, systems or hardcopies, and should be appropriately restricted. “Onsite personnel” are full- and part-time employees, temporary employees, contractors, and consultants who are physically present on the entity’s premises. “Visitors” are vendors and guests that enter the facility for a short duration
• usually up to one day. “Media” is all paper and electronic media containing cardholder data.
• usually up to one day. “Media” is all paper and electronic media containing cardholder data.
Removed
p. 20
PHYSICALLY SECURE THE PAYMENT SYSTEM Businesses must physically secure or restrict access to printouts of cardholder data, to media where it is stored, and devices used for accessing or storing cardholder data. It’s important to understand that PCI is about protecting both electronic data and paper receipts as well.
Illustration: Wikimedia Commons This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 21 9.4 Ensure all visitors are authorized before entering areas where cardholder data is processed or maintained, given a physical badge or other identification that expires and identifies visitors as not onsite personnel, and are asked to surrender the physical badge before leaving the facility or at the date of expiration. Use a visitor log to maintain a physical audit trail of visitor information and activity, including visitor name, company, and the onsite personnel authorizing physical access. Retain the log …
Illustration: Wikimedia Commons This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 21 9.4 Ensure all visitors are authorized before entering areas where cardholder data is processed or maintained, given a physical badge or other identification that expires and identifies visitors as not onsite personnel, and are asked to surrender the physical badge before leaving the facility or at the date of expiration. Use a visitor log to maintain a physical audit trail of visitor information and activity, including visitor name, company, and the onsite personnel authorizing physical access. Retain the log …
Removed
p. 21
Regularly Monitor and Test Networks Physical and wireless networks are the glue connecting all endpoints and servers in the payment infrastructure. Vulnerabilities in network devices and systems present opportunities for criminals to gain unauthorized access to payment card applications and cardholder data. To prevent exploitation, organizations must regularly monitor and test networks to find and fix vulnerabilities.
Requirement 10: Track and monitor all access to network resources and cardholder data Logging mechanisms and the ability to track user activities are critical for effective forensics and vulnerability management. The presence of logs in all environments allows thorough tracking and analysis if something goes wrong. Determining the cause of a compromise is very difficult without system activity logs.
Requirement 10: Track and monitor all access to network resources and cardholder data Logging mechanisms and the ability to track user activities are critical for effective forensics and vulnerability management. The presence of logs in all environments allows thorough tracking and analysis if something goes wrong. Determining the cause of a compromise is very difficult without system activity logs.
Removed
p. 22
MONITOR ALL ACTIVITY Organizations must track and monitor all access to cardholder data and related network resources
• in stores, regional offices, headquarters, and other remote access.
Photo: Wikimedia Commons This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 23
Requirement 11: Regularly test security systems and processes Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security is maintained over time. Testing of security controls is especially important for any environmental changes such as deploying new software or changing system configurations.
• in stores, regional offices, headquarters, and other remote access.
Photo: Wikimedia Commons This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 23
Requirement 11: Regularly test security systems and processes Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security is maintained over time. Testing of security controls is especially important for any environmental changes such as deploying new software or changing system configurations.
Removed
p. 23
SEVERITY LEVELS FOR VULNERABILITY SCANNING CVSS Score Scan Results 7.0 through High Severity Fail 4.0 through Severity Fail 0.0 through Low Severity Pass “To demonstrate compliance, internal scans must not contain high-risk vulnerabilities in any component in the cardholder data environment. For external scans, none of those components may contain any vulnerability that has been assigned a Common Vulnerability Scoring System (CVSS) base score equal to or higher than 4.0.” This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Removed
p. 24
Maintain an Information Security Policy A strong security policy sets the tone for security affecting an organization’s entire company, and it informs employees of their expected duties related to security. All employees should be aware of the sensitivity of cardholder data and their responsibilities for protecting it.
Requirement 12: Maintain a policy that addresses information security for all personnel 12.1 Establish, publish, maintain, and disseminate a security policy; review the security policy at least annually and update when the environment changes.
Requirement 12: Maintain a policy that addresses information security for all personnel 12.1 Establish, publish, maintain, and disseminate a security policy; review the security policy at least annually and update when the environment changes.
Removed
p. 24
TIPS FOR SCANNING Get Advice. Ask your merchant bank about partnerships with PCI Approved Scanning Vendors (ASV).
Talk to a PCI ASV. See PCI Council website for approved list.
Select a Scanner. Contact several PCI ASVs and select a suitable program.
Address Vulnerabilities. As your PCI ASV for help correcting issues found by scanning.
Source: Small Merchant Guide to Safe Payments, p. 16 This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 25 12.5 Assign to an individual or team information security responsibilities defined by 12.5 subsections.
Talk to a PCI ASV. See PCI Council website for approved list.
Select a Scanner. Contact several PCI ASVs and select a suitable program.
Address Vulnerabilities. As your PCI ASV for help correcting issues found by scanning.
Source: Small Merchant Guide to Safe Payments, p. 16 This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 25 12.5 Assign to an individual or team information security responsibilities defined by 12.5 subsections.
Removed
p. 25
Example screening includes previous employment history, criminal record, credit history, and reference checks.
Removed
p. 27
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 27 How to Comply with PCI DSS
PCI DSS applies to merchants and other entities that store, process, and/or transmit cardholder data. While the Council is responsible for managing the data security standards, each payment card brand maintains its own separate compliance enforcement programs. Each payment card brand has defined specific requirements for compliance validation and reporting, such as provisions for performing self- assessments and when to engage a QSA.
Depending on an entity’s classification or risk level (determined by the individual payment card brands), processes for compliance usually follow these steps:
1. Scope
• determine which system components and networks are in scope for PCI DSS
2. Assess
• examine the compliance of system components in scope following the testing procedures for each PCI DSS requirement
3. Report
• assessor and/or entity completes required documentation (e.g. Self-Assessment Questionnaire …
PCI DSS applies to merchants and other entities that store, process, and/or transmit cardholder data. While the Council is responsible for managing the data security standards, each payment card brand maintains its own separate compliance enforcement programs. Each payment card brand has defined specific requirements for compliance validation and reporting, such as provisions for performing self- assessments and when to engage a QSA.
Depending on an entity’s classification or risk level (determined by the individual payment card brands), processes for compliance usually follow these steps:
1. Scope
• determine which system components and networks are in scope for PCI DSS
2. Assess
• examine the compliance of system components in scope following the testing procedures for each PCI DSS requirement
3. Report
• assessor and/or entity completes required documentation (e.g. Self-Assessment Questionnaire …
Removed
p. 28
• American Express: www.americanexpress.com/datasecurity
• Discover: www.discovernetwork.com/fraudsecurity/disc.html
• JCB International: http://partner.jcbcard.com/security/jcbprogram
• MasterCard: www.mastercard.com/sdp
• Visa Inc: www.visa.com/cisp Visa Europe: www.visaeurope.com/ais Choosing a Qualified Security Assessor A Qualified Security Assessor (QSA) is a data security firm that is qualified by the PCI Security Standards Council to perform on-site PCI DSS assessments. The QSA will:
• Be onsite for the duration of the assessment as required
• Produce the final report ISA PROGRAM The PCI SSC Internal Security Assessor (ISA) Program provides an opportunity for eligible internal security assessment professionals of qualifying organizations to receive PCI DSS training and qualification that will improve the 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. Please see the PCI SSC website for details: www.pcisecuritystandards.org/ program_training_and_qualification/ internal_security_assessor_ certification This Guide provides …
• Discover: www.discovernetwork.com/fraudsecurity/disc.html
• JCB International: http://partner.jcbcard.com/security/jcbprogram
• MasterCard: www.mastercard.com/sdp
• Visa Inc: www.visa.com/cisp Visa Europe: www.visaeurope.com/ais Choosing a Qualified Security Assessor A Qualified Security Assessor (QSA) is a data security firm that is qualified by the PCI Security Standards Council to perform on-site PCI DSS assessments. The QSA will:
• Be onsite for the duration of the assessment as required
• Produce the final report ISA PROGRAM The PCI SSC Internal Security Assessor (ISA) Program provides an opportunity for eligible internal security assessment professionals of qualifying organizations to receive PCI DSS training and qualification that will improve the 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. Please see the PCI SSC website for details: www.pcisecuritystandards.org/ program_training_and_qualification/ internal_security_assessor_ certification This Guide provides …
Modified
p. 28 → 13
• Use independent judgment to confirm the standard has been met
• Use independent judgment to confirm whether the standard has been met
Modified
p. 28 → 13
• Adhere to the PCI DSS Security Assessment Procedures
• Adhere to the PCI DSS Requirements and Testing Procedures
Modified
p. 28 → 13
• Evaluate compensating controls
• Evaluate compensating controls and any customized approach implementations
Modified
p. 29 → 14
Choosing an Approved Scanning Vendor An Approved Scanning Vendor (ASV) is a data security firm using a scanning solution to determine whether or not the customer meets the PCI DSS external vulnerability scanning requirement. ASVs are qualified by the PCI Security Standards Council to perform external network and system scans as required by the PCI DSS. An ASV may use its own software or an approved commercial or open source solution. ASV solutions must be non-disruptive to customers’ systems and …
Choosing an Approved Scanning Vendor The ASV’s role is to determine whether the customer meets the PCI DSS external vulnerability scanning requirements. ASVs and their ASV scan solutions are qualified by the PCI Security Standards Council to perform external network and system scans as required by PCI DSS. An ASV may use its own software or a commercial or open-source solution that is PCI-approved as part of the ASV qualification process. An ASV scan solution includes the scanning procedures and …
Removed
p. 30
Scoping must occur at least annually and prior to the annual assessment. Merchants and other entities must identify all locations and flows of cardholder data, and identify all systems that are connected to or if compromised could impact the CDE (e.g. authentication servers) to ensure all applicable system components are included in scope for PCI DSS. All types of systems and locations should be considered as part of the scoping process, including backup/recovery sites and fail-over systems.
Entities should confirm the accuracy of the defined CDE by performing these steps:
• Identify and document the existence of all cardholder data in the environment, to verify that no cardholder data exists outside of the currently defined cardholder data environment (CDE).
• Once all locations of cardholder data are identified and documented, verify that PCI DSS scope is appropriate (for example, the results may be a diagram or an inventory of cardholder data locations).
• Consider …
Entities should confirm the accuracy of the defined CDE by performing these steps:
• Identify and document the existence of all cardholder data in the environment, to verify that no cardholder data exists outside of the currently defined cardholder data environment (CDE).
• Once all locations of cardholder data are identified and documented, verify that PCI DSS scope is appropriate (for example, the results may be a diagram or an inventory of cardholder data locations).
• Consider …
Removed
p. 31
Sampling of Business Facilities and System Components Sampling is an option for assessors to facilitate the assessment process where there are large numbers of system components. While it is acceptable for an assessor to sample systems as part of their review of an entity’s PCI DSS compliance, it is not acceptable for an entity to apply PCI DSS requirements to only a sample of their CDE, or for an assessor to only review a sample of PCI DSS requirements for compliance. The assessor may independently select representative samples of business facilities and system components to assess the entity’s compliance with PCI DSS requirements. Sampling is not required by PCI DSS. Sampling does not reduce scope of the cardholder data environment or the applicability of PCI DSS requirements. If sampling is used, each sample must be assessed against all applicable PCI DSS requirements. Samples must be sufficiently large to provide the …
Modified
p. 31 → 16
Segmentation The scope of a PCI DSS assessment can be reduced with the use of segmentation, which isolates the cardholder data environment from the remainder of an entity’s network. Reduction of scope can lower the cost of the PCI DSS assessment, lower the cost and difficulty of implementing and maintaining PCI DSS controls, and reduce risk for the entity. To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such …
Removed
p. 33
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 33 Using the Self-Assessment Questionnaire (SAQ) The “SAQ” is a validation tool for merchants and service providers to report the results of their PCI DSS self-assessment, if they are not required to submit a Report on Compliance (ROC). The SAQ includes a series of yes-or-no questions for each applicable PCI DSS requirement. If an answer is no, the organization may be required to state the future remediation date and associated actions. There are different SAQs available to meet different merchant environments. If you are not sure which SAQ would apply to you, contact your acquiring bank or payment card brand for assistance. The PCI DSS SAQ Instructions and Guidelines document provides more details on each SAQ type (see www.pcisecuritystandards.org/document_library?category=saqs#results).
SAQ Description A Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all …
SAQ Description A Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all …
Removed
p. 34
C-VT Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage. Not applicable to e-commerce channels.
C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
P2PE Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce channels.
D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types. SAQ D for Service Providers: All service providers defined by a payment card brand as eligible to complete a SAQ.
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 35 Reports are the official …
C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.
P2PE Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce channels.
D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types. SAQ D for Service Providers: All service providers defined by a payment card brand as eligible to complete a SAQ.
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 35 Reports are the official …
Removed
p. 36
Entities may also consider implementing separation of duties for their security functions so that security and/or audit functions are separated from operational functions.
Modified
p. 36 → 18
4. Changes to organization structure (for example, a company merger or acquisition) resulting in a formal review of the impact to PCI DSS scope and requirements.
4. Formally reviewing the impact to PCI DSS scope and requirements after changes to organization structure (for example, a company merger or acquisition).
Modified
p. 36 → 19
Each entity should consider implementing these best practices into their environment, even where the entity is not required to validate to them (for example, merchants undergoing self-assessment).
Removed
p. 37
PCI SSC Blog: https://blog.pcisecuritystandards.org Membership Information https://www.pcisecuritystandards.org/get_involved/join.php Webinars https://www.pcisecuritystandards.org/program_ training_and_qualification/webinars Merchant Resources: https://www.pcissc.org/merchant Training PCI Awareness: https://www.pcisecuritystandards.org/program_training_and_qualification/requirements_awareness QSA: https://www.pcisecuritystandards.org/program_training_and_qualification/qsa_certification ISA: https://www.pcisecuritystandards.org/program_training_and_qualification/internal_security_assessor_certification PCIP: https://www.pcisecuritystandards.org/program_training_and_qualification/pci_professional_qualification Other Training Programs: https://www.pcisecuritystandards.org/program_training_and_qualification
PCI SSC approved products, solutions and providers PIN Transaction Security (PTS) Devices: https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices Payment Applications: https://www.pcisecuritystandards.org/assessors_and_solutions/vpa_agreement P2PE Solutions: https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_solutions Approved QSAs: https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors Approved ASVs: https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors Qualified Integrators and Resellers: https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_integrators_and_resellers
PCI Data Security Standard (PCI DSS) The Standard: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf Supporting Documents: https://www.pcisecuritystandards.org/document_library Self-Assessment Questionnaires: www.pcisecuritystandards.org/document_library?category=saqs#results Glossary: https://www.pcisecuritystandards.org/pci_security/glossary 39 This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
PCI SSC approved products, solutions and providers PIN Transaction Security (PTS) Devices: https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices Payment Applications: https://www.pcisecuritystandards.org/assessors_and_solutions/vpa_agreement P2PE Solutions: https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_solutions Approved QSAs: https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors Approved ASVs: https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors Qualified Integrators and Resellers: https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_integrators_and_resellers
PCI Data Security Standard (PCI DSS) The Standard: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf Supporting Documents: https://www.pcisecuritystandards.org/document_library Self-Assessment Questionnaires: www.pcisecuritystandards.org/document_library?category=saqs#results Glossary: https://www.pcisecuritystandards.org/pci_security/glossary 39 This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Modified
p. 37 → 22
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents. 37 Web Resources
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Modified
p. 37 → 35
PCI Security Standards Council Web site: https://www.pcisecuritystandards.org Frequently Asked Questions (FAQs): https://www.pcisecuritystandards.org/faqs
PCI Security Standards Council Website Frequently Asked Questions (FAQs)
Removed
p. 38
The Council’s founding members, American Express, Discover Financial Services, JCB International, MasterCard, and Visa Inc., have agreed to incorporate the PCI Data Security Standard (PCI DSS) as part of the technical requirements for each of their data security compliance programs. Each founding member also recognizes the Qualified Security Assessors and Approved Scanning Vendors qualified by the PCI Security Standards Council.
All five payment brands, along with Strategic Members, share equally in the Council’s governance, have equal input into the PCI Security Standards Council and share responsibility for carrying out the work of the organization. Other industry stakeholders are encouraged to join the Council as Strategic or Affiliate members and Participating Organizations to review proposed additions or modifications to the standards. Participating Organizations may include merchants, banks, processors, hardware and software developers, and point-of-sale vendors.
All five payment brands, along with Strategic Members, share equally in the Council’s governance, have equal input into the PCI Security Standards Council and share responsibility for carrying out the work of the organization. Other industry stakeholders are encouraged to join the Council as Strategic or Affiliate members and Participating Organizations to review proposed additions or modifications to the standards. Participating Organizations may include merchants, banks, processors, hardware and software developers, and point-of-sale vendors.
Modified
p. 38 → 28
This Guide provides supplemental information that does not replace or supersede PCI SSC Security Standards or their supporting documents.
Modified
p. 38 → 37
About the PCI Security Standards Council The PCI Security Standards Council is a global forum for the industry to come together to develop, enhance, disseminate and assist with the understanding of security standards for payment account security. Read more about PCI SSC’s Global Payment Security Engagement Initiative at www.pcisecuritystandards.org/pdfs/PCI_SSC_Partnering_for_Global_Payment_Security.pdf The Council maintains, evolves, and promotes the Payment Card Industry Security Standards. It also provides critical tools needed for implementation of the standards such as assessment and scanning qualifications, self-assessment questionnaires, …
About the PCI Security Standards Council The PCI Security Standards Council (PCI SSC) is a global forum for the industry to come together to develop, enhance, disseminate, and assist with the understanding of security standards for payment account security.
Removed
p. 39
1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program
PCI Data Security Standard The PCI DSS is a set of comprehensive requirements for enhancing security of payment card account data. It represents common sense steps that mirror security best practices. Learn more about its requirements, security controls and processes, and steps to assess compliance inside this PCI DSS Quick Reference Guide.
5. Protect all systems against malware and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need to know 8. Identify and authenticate access to system components 9. Restrict physical access to cardholder data Regularly Monitor …
PCI Data Security Standard The PCI DSS is a set of comprehensive requirements for enhancing security of payment card account data. It represents common sense steps that mirror security best practices. Learn more about its requirements, security controls and processes, and steps to assess compliance inside this PCI DSS Quick Reference Guide.
5. Protect all systems against malware and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need to know 8. Identify and authenticate access to system components 9. Restrict physical access to cardholder data Regularly Monitor …