Document Comparison
PCI_DSS_v3-1.pdf
→
PCI_DSS_v3-2.pdf
85% similar
115 → 139
Pages
49289 → 57812
Words
165
Content Changes
Content Changes
165 content changes. 56 administrative changes (dates, page numbers) hidden.
Added
p. 14
Note: For some entities, these best practices are also requirements to ensure ongoing PCI DSS compliance. For example, PCI DSS includes these principles in some requirements, and the Designated Entities Supplemental Validation (PCI DSS Appendix A3) requires designated entities to validate to these principles.
All organizations should consider implementing these best practices into their environment, even where the organization is not required to validate to them.
All organizations should consider implementing these best practices into their environment, even where the organization is not required to validate to them.
Added
p. 17
PCI DSS Assessment Process The PCI DSS assessment process includes completion of the following steps:
Added
p. 18
PCI DSS Versions As of the published date of this document, PCI DSS v3.1 is valid until October 31, 2016, after which it is retired. All PCI DSS validations after this date must be to PCI DSS v3.2 or later.
The following table provides a summary of PCI DSS versions and their effective dates6.
Version Published Retired
The following table provides a summary of PCI DSS versions and their effective dates6.
Version Published Retired
Added
p. 22
Approvals should be granted by personnel independent of the personnel managing the configuration.
For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (e.g., NIST, ENISA, OWASP, etc.).
For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (e.g., NIST, ENISA, OWASP, etc.).
Added
p. 26
A firewall that maintains the "state" (or the status) for each connection through the firewall knows whether an apparent response to a previous connection is actually a valid, authorized response (since it retains each connection’s status) or is malicious traffic trying to trick the firewall into allowing the connection.
Specific configuration settings are defined. Personal firewall (or equivalent functionality) is actively running. Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices.
Note: This requirement applies to employee- owned and company-owned portable computing devices. Systems that cannot be managed by corporate policy introduce weaknesses and provide opportunities that malicious individuals may exploit. Allowing untrusted systems to connect to an organization’s CDE could result in access being granted to attackers and other malicious users.
Personal firewall (or equivalent functionality) is installed and configured per the organization’s specific configuration settings. Personal firewall (or equivalent functionality) …
Specific configuration settings are defined. Personal firewall (or equivalent functionality) is actively running. Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices.
Note: This requirement applies to employee- owned and company-owned portable computing devices. Systems that cannot be managed by corporate policy introduce weaknesses and provide opportunities that malicious individuals may exploit. Allowing untrusted systems to connect to an organization’s CDE could result in access being granted to attackers and other malicious users.
Personal firewall (or equivalent functionality) is installed and configured per the organization’s specific configuration settings. Personal firewall (or equivalent functionality) …
Added
p. 32
2.2.3.b If SSL/early TLS is used, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS.
PCI DSS Requirements Testing Procedures Guidance 2.3 Encrypt all non-console administrative access using strong cryptography.
To be considered “strong cryptography,” industry- recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. (Refer to "strong cryptography” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, and industry standards and best practices such as NIST SP 800-52 and SP 800-57, OWASP, etc.) 2.3.a Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested.
2.3.e If SSL/early TLS is used, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS.
PCI DSS Requirements Testing Procedures Guidance 2.3 Encrypt all non-console administrative access using strong cryptography.
To be considered “strong cryptography,” industry- recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. (Refer to "strong cryptography” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, and industry standards and best practices such as NIST SP 800-52 and SP 800-57, OWASP, etc.) 2.3.a Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested.
2.3.e If SSL/early TLS is used, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS.
Added
p. 39
The masking approach should always ensure that only the minimum number of digits is displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, mask the PAN so that individuals performing that function can view only the last four digits. As another example, if a function needs access to the bank identification number (BIN) for routing purposes, unmask only the BIN digits (traditionally the first six digits) during that function.
Note: This requirement applies in addition to all other PCI DSS encryption and key- management requirements.
PCI DSS Requirements Testing Procedures Guidance 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes:
Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date Description of the key usage for each …
Note: This requirement applies in addition to all other PCI DSS encryption and key- management requirements.
PCI DSS Requirements Testing Procedures Guidance 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes:
Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date Description of the key usage for each …
Added
p. 42
Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date Description of the key usage for each key Inventory of any HSMs and other SCDs used for key management
Added
p. 42
Maintaining current documentation of the cryptographic architecture enables an entity to understand the algorithms, protocols, and cryptographic keys used to protect cardholder data, as well as the devices that generate, use and protect the keys. This allows an entity to keep pace with evolving threats to their architecture, enabling them to plan for updates as the assurance levels provided by different algorithms/key strengths changes. Maintaining such documentation also allows an entity to detect lost or missing keys or key-management devices, and identify unauthorized additions to their cryptographic architecture.
Added
p. 48
Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.) 4.1.h If SSL/early TLS is used, perform testing procedures in Appendix A2: Additional PCI DSS Requirements for Entities using SSL/Early TLS.
Added
p. 59
PCI DSS Requirements Testing Procedures Guidance 6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.
Added
p. 59
Having processes to analyze significant changes helps ensure that all appropriate PCI DSS controls are applied to any systems or networks added or changed within the in-scope environment.
Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed.
A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process. Examples of PCI DSS requirements that could be impacted include, but are not limited to:
Network diagram is updated to reflect changes. Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled. Systems are protected with required controls• e.g., file-integrity monitoring (FIM), anti-virus, patches, audit logging. Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data- retention policy and procedures …
Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed.
A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process. Examples of PCI DSS requirements that could be impacted include, but are not limited to:
Network diagram is updated to reflect changes. Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled. Systems are protected with required controls• e.g., file-integrity monitoring (FIM), anti-virus, patches, audit logging. Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data- retention policy and procedures …
Added
p. 74
Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication (as described in Requirement 8.2), before access is granted.
Multi-factor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multi-factor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk.
Multi-factor authentication is not required at both the system-level and application-level for a particular system component. Multi-factor authentication can be performed either upon authentication to the particular network or to the system component.
PCI DSS Requirements Testing Procedures Guidance 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
8.3.1.a Examine network and/or system configurations, as applicable, to verify multi-factor authentication is required for …
Multi-factor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multi-factor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk.
Multi-factor authentication is not required at both the system-level and application-level for a particular system component. Multi-factor authentication can be performed either upon authentication to the particular network or to the system component.
PCI DSS Requirements Testing Procedures Guidance 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
8.3.1.a Examine network and/or system configurations, as applicable, to verify multi-factor authentication is required for …
Added
p. 94
Firewalls IDS/IPS FIM Anti-virus Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used)
Firewalls IDS/IPS FIM Anti-virus Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used)
10.8.a Examine documented policies and procedures to verify that processes are defined for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.
The specific types of failures may vary depending on the function of the device and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner; …
Firewalls IDS/IPS FIM Anti-virus Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used)
10.8.a Examine documented policies and procedures to verify that processes are defined for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.
The specific types of failures may vary depending on the function of the device and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner; …
Added
p. 98
(Continued on next page) 11.2.1.b Review the scan reports and verify that all “high risk” vulnerabilities are addressed and the scan process includes rescans to verify that the “high risk” vulnerabilities (as defined in PCI DSS Requirement 6.1) are resolved.
Added
p. 102
11.3.4.c Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
Added
p. 102
11.3.4.1.a Examine the results from the most recent penetration test to verify that:
Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.
The penetration testing covers all segmentation controls/methods in use.
The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.
For service providers, validation of PCI DSS scope should be performed as frequently as possible to ensure PCI DSS scope remains up to date and aligned with changing business objectives.
PCI DSS Requirements Testing Procedures Guidance 11.3.4.1.b Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.
The penetration testing covers all segmentation controls/methods in use.
The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.
For service providers, validation of PCI DSS scope should be performed as frequently as possible to ensure PCI DSS scope remains up to date and aligned with changing business objectives.
PCI DSS Requirements Testing Procedures Guidance 11.3.4.1.b Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
Added
p. 106
A list of all critical devices, and A list of personnel authorized to use the devices.
Added
p. 108
Overall accountability for maintaining PCI DSS compliance Defining a charter for a PCI DSS compliance program and communication to executive management
12.4.1.a Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance.
Executive management assignment of PCI DSS compliance responsibilities ensures executive- level visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities. Overall responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.
Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure. The level of detail provided to executive management should be appropriate for the particular organization and the intended audience.
12.4.1.b Examine the company’s PCI DSS charter to verify it outlines the conditions under …
12.4.1.a Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance.
Executive management assignment of PCI DSS compliance responsibilities ensures executive- level visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities. Overall responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.
Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure. The level of detail provided to executive management should be appropriate for the particular organization and the intended audience.
12.4.1.b Examine the company’s PCI DSS charter to verify it outlines the conditions under …
Added
p. 114
Daily log reviews Firewall rule-set reviews Applying configuration standards to new Responding to security alerts Change management processes
12.11.a Examine policies and procedures to verify that processes are defined for reviewing and confirming that personnel are following security policies and operational procedures, and that reviews cover:
Daily log reviews Firewall rule-set reviews Applying configuration standards to new systems Responding to security alerts Change management processes
Regularly confirming that security policies and procedures are being followed provides assurance that the expected controls are active and working as intended. The objective of these reviews is not to re-perform other PCI DSS requirements, but to confirm whether procedures are being followed as expected. 12.11.b Interview responsible personnel and examine records of reviews to verify that reviews are performed at least quarterly.
PCI DSS Requirements Testing Procedures Guidance 12.11.1 Additional requirement for service providers only: Maintain documentation of …
12.11.a Examine policies and procedures to verify that processes are defined for reviewing and confirming that personnel are following security policies and operational procedures, and that reviews cover:
Daily log reviews Firewall rule-set reviews Applying configuration standards to new systems Responding to security alerts Change management processes
Regularly confirming that security policies and procedures are being followed provides assurance that the expected controls are active and working as intended. The objective of these reviews is not to re-perform other PCI DSS requirements, but to confirm whether procedures are being followed as expected. 12.11.b Interview responsible personnel and examine records of reviews to verify that reviews are performed at least quarterly.
PCI DSS Requirements Testing Procedures Guidance 12.11.1 Additional requirement for service providers only: Maintain documentation of …
Added
p. 115
The intent of these independent checks is to confirm whether security activities are being performed on an ongoing basis. These reviews can also be used to verify that appropriate evidence is being maintained
• for example, audit logs, vulnerability scan reports, firewall reviews, etc.
•to assist the entity’s preparation for its next PCI DSS assessment.
• for example, audit logs, vulnerability scan reports, firewall reviews, etc.
•to assist the entity’s preparation for its next PCI DSS assessment.
Added
p. 116
Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS Appendix A3: Designated Entities Supplemental Validation Guidance and applicability information is provided within each section.
Added
p. 119
The PCI DSS requirements directly affected are:
Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.
Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
SSL and early TLS should not be used as a security control to meet these requirements. To support entities working to migrate away from SSL/early TLS, the following provisions are included:
New implementations must not use SSL or early TLS as a security control.
All service providers must provide a secure service offering by June 30, 2016.
After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol (an allowance for certain POS POI terminals is described in the last bullet below).
Prior to June …
Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.
Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
SSL and early TLS should not be used as a security control to meet these requirements. To support entities working to migrate away from SSL/early TLS, the following provisions are included:
New implementations must not use SSL or early TLS as a security control.
All service providers must provide a secure service offering by June 30, 2016.
After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol (an allowance for certain POS POI terminals is described in the last bullet below).
Prior to June …
Added
p. 120
Confirm the devices are not susceptible to any known exploits for those protocols.
Have a formal Risk Mitigation and Migration Plan in place.
A2.1 For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS:
Confirm the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.
Complete A2.2 below.
POIs can continue using SSL/early TLS when it can be shown that the POI is not susceptible to the currently known exploits. However, SSL is an outdated technology and may be subject to additional security vulnerabilities in the future; it is therefore strongly recommended that POI environments upgrade to a secure protocol as soon as possible. If SSL/early TLS is not needed in the environment, use of and fallback to these versions should be disabled.
If the POS POI environment …
Have a formal Risk Mitigation and Migration Plan in place.
A2.1 For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS:
Confirm the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.
Complete A2.2 below.
POIs can continue using SSL/early TLS when it can be shown that the POI is not susceptible to the currently known exploits. However, SSL is an outdated technology and may be subject to additional security vulnerabilities in the future; it is therefore strongly recommended that POI environments upgrade to a secure protocol as soon as possible. If SSL/early TLS is not needed in the environment, use of and fallback to these versions should be disabled.
If the POS POI environment …
Added
p. 121
Note: Prior to June 30, 2016, the service provider must either have a secure protocol option included in their service offering, or have a documented Risk Mitigation and Migration Plan (per A2.2) that includes a target date for provision of a secure protocol option no later than June 30, 2016. After this date, all service providers must offer a secure protocol option for their service.
A2.3 Examine system configurations and supporting documentation to verify the service provider offers a secure protocol option for their service.
Refer to "Service Providers” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for further guidance.
A2.3 Examine system configurations and supporting documentation to verify the service provider offers a secure protocol option for their service.
Refer to "Service Providers” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for further guidance.
Added
p. 122
Those storing, processing, and/or transmitting large volumes of cardholder data, Those providing aggregation points for cardholder data, or Those that have suffered significant or repeated breaches of cardholder data.
These supplemental validation steps are intended to provide greater assurance that PCI DSS controls are maintained effectively and on a continuous basis through validation of business-as-usual (BAU) processes, and increased validation and scoping consideration.
The additional validation steps in this document are organized into the following control areas:
A3.1 Implement a PCI DSS compliance program.
A3.2 Document and validate PCI DSS scope.
A3.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities.
A3.4 Control and manage logical access to the cardholder data environment.
A3.5 Identify and respond to suspicious events.
Note: Some requirements have defined timeframes (for example, at least quarterly or every six months) within which certain activities are to be performed. For initial assessment to this document, it is not required that an activity …
These supplemental validation steps are intended to provide greater assurance that PCI DSS controls are maintained effectively and on a continuous basis through validation of business-as-usual (BAU) processes, and increased validation and scoping consideration.
The additional validation steps in this document are organized into the following control areas:
A3.1 Implement a PCI DSS compliance program.
A3.2 Document and validate PCI DSS scope.
A3.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities.
A3.4 Control and manage logical access to the cardholder data environment.
A3.5 Identify and respond to suspicious events.
Note: Some requirements have defined timeframes (for example, at least quarterly or every six months) within which certain activities are to be performed. For initial assessment to this document, it is not required that an activity …
Added
p. 123
Overall accountability for maintaining PCI DSS compliance Defining a charter for a PCI DSS compliance program Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least annually
PCI DSS Reference: Requirement 12 A3.1.1.a Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance.
A3.1.1.b Examine the company’s PCI DSS charter to verify it outlines the conditions under which the PCI DSS compliance program is organized.
A3.1.1.c Examine executive management and board of directors meeting minutes and/or presentations to ensure PCI DSS compliance initiatives and remediation activities are communicated at least annually.
A3.1.2 A formal PCI DSS compliance program must be in place to include:
Definition of activities for maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities Annual PCI DSS assessment processes Processes for the continuous validation of PCI DSS …
PCI DSS Reference: Requirement 12 A3.1.1.a Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance.
A3.1.1.b Examine the company’s PCI DSS charter to verify it outlines the conditions under which the PCI DSS compliance program is organized.
A3.1.1.c Examine executive management and board of directors meeting minutes and/or presentations to ensure PCI DSS compliance initiatives and remediation activities are communicated at least annually.
A3.1.2 A formal PCI DSS compliance program must be in place to include:
Definition of activities for maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities Annual PCI DSS assessment processes Processes for the continuous validation of PCI DSS …
Added
p. 124
Maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities Annual PCI DSS assessment(s) Continuous validation of PCI DSS requirements Business-impact analysis to determine potential PCI DSS impacts for strategic business decisions Maintaining and monitoring an organization’s overall PCI DSS compliance includes identifying activities to be performed daily, weekly, monthly, quarterly, or annually, and ensuring these activities are being performed accordingly (for example, using a security self-assessment or PDCA methodology).
Examples of strategic business decisions that should be analyzed for potential PCI DSS impacts may include mergers and acquisitions, new technology purchases, or new payment- acceptance channels.
A3.1.3 PCI DSS compliance roles and responsibilities must be specifically defined and formally assigned to one or more personnel, including at least the following:
Managing PCI DSS business-as-usual activities Managing annual PCI DSS assessments Managing continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. as applicable …
Examples of strategic business decisions that should be analyzed for potential PCI DSS impacts may include mergers and acquisitions, new technology purchases, or new payment- acceptance channels.
A3.1.3 PCI DSS compliance roles and responsibilities must be specifically defined and formally assigned to one or more personnel, including at least the following:
Managing PCI DSS business-as-usual activities Managing annual PCI DSS assessments Managing continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. as applicable …
Added
p. 125
PCI DSS Reference: Requirement 12 A3.1.4.a Examine information security policies and procedures to verify that PCI DSS and/or information security training is required at least annually for each role with PCI DSS compliance responsibilities.
Personnel responsible for PCI DSS compliance have specific training needs exceeding that which is typically provided by general security awareness training. Individuals with PCI DSS compliance responsibilities should receive specialized training that, in addition to general awareness of information security, focuses on specific security topics, skills, processes, or methodologies that must be followed for those individuals to perform their compliance responsibilities effectively.
Training may be offered by third parties
•for example, SANS or PCI SSC (PCI Awareness, PCIP, and ISA), payment brands, and acquirers
• or training may be internal. Training content should be applicable for the particular job function and be current to include the latest security threats and/or version of PCI DSS.
For additional guidance on developing appropriate security …
Personnel responsible for PCI DSS compliance have specific training needs exceeding that which is typically provided by general security awareness training. Individuals with PCI DSS compliance responsibilities should receive specialized training that, in addition to general awareness of information security, focuses on specific security topics, skills, processes, or methodologies that must be followed for those individuals to perform their compliance responsibilities effectively.
Training may be offered by third parties
•for example, SANS or PCI SSC (PCI Awareness, PCIP, and ISA), payment brands, and acquirers
• or training may be internal. Training content should be applicable for the particular job function and be current to include the latest security threats and/or version of PCI DSS.
For additional guidance on developing appropriate security …
Added
p. 126
Identifying all in-scope networks and system components Identifying all out-of-scope networks and justification for networks being out of scope, including descriptions of all segmentation controls implemented Identifying all connected entities•e.g., third-party entities with access to the cardholder data environment (CDE)
PCI DSS Reference: Scope of PCI DSS Requirements A3.2.1.a Examine documented results of scope reviews and interview personnel to verify that the reviews are performed:
At least quarterly After significant changes to the in-scope environment Validation of PCI DSS scope should be performed as frequently as possible to ensure PCI DSS scope remains up to date and aligned with changing business objectives.
A3.2.1.b Examine documented results of quarterly scope reviews to verify the following is performed:
Identification of all in-scope networks and system components Identification of all out-of-scope networks and justification for networks being out of scope, including descriptions of all segmentation controls implemented Identification of …
PCI DSS Reference: Scope of PCI DSS Requirements A3.2.1.a Examine documented results of scope reviews and interview personnel to verify that the reviews are performed:
At least quarterly After significant changes to the in-scope environment Validation of PCI DSS scope should be performed as frequently as possible to ensure PCI DSS scope remains up to date and aligned with changing business objectives.
A3.2.1.b Examine documented results of quarterly scope reviews to verify the following is performed:
Identification of all in-scope networks and system components Identification of all out-of-scope networks and justification for networks being out of scope, including descriptions of all segmentation controls implemented Identification of …
Added
p. 127
Network diagram is updated to reflect changes. Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled. Systems are protected with required controls•e.g., file-integrity monitoring (FIM), anti-virus, patches, audit logging. Verify that sensitive authentication data (SAD) is not stored and that all cardholder data (CHD) storage is documented and incorporated into data- retention policy and procedures New systems are included in the quarterly vulnerability scanning process.
PCI DSS Reference: Scope of PCI DSS Requirements; Requirement 1-12 A3.2.2.1 For a sample of systems and network changes, examine change records, interview personnel and observe the affected systems/networks to verify that applicable PCI DSS requirements were implemented and documentation updated as part of the change.
It is important to have processes to analyze all changes made to ensure that all appropriate PCI DSS controls are applied to any systems or networks added to the in-scope …
PCI DSS Reference: Scope of PCI DSS Requirements; Requirement 1-12 A3.2.2.1 For a sample of systems and network changes, examine change records, interview personnel and observe the affected systems/networks to verify that applicable PCI DSS requirements were implemented and documentation updated as part of the change.
It is important to have processes to analyze all changes made to ensure that all appropriate PCI DSS controls are applied to any systems or networks added to the in-scope …
Added
p. 128
• for example, a company merger or acquisition, change or reassignment of personnel with responsibility for security controls
•result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls.
PCI DSS Reference: Requirement 12 A3.2.3 Examine policies and procedures to verify that a change to organizational structure results in formal review of the impact to PCI DSS scope and applicability of controls.
An organization’s structure and management define the requirements and protocol for effective and secure operations. Changes to this structure could have negative effects to existing controls and frameworks by reallocating or removing resources that once supported PCI DSS controls or inheriting new responsibilities that may not have established controls in place. Therefore, it is important to revisit PCI DSS scope and controls when there are changes to ensure controls are in place and active.
A3.2.4 If segmentation is used, confirm PCI DSS scope by performing penetration …
•result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls.
PCI DSS Reference: Requirement 12 A3.2.3 Examine policies and procedures to verify that a change to organizational structure results in formal review of the impact to PCI DSS scope and applicability of controls.
An organization’s structure and management define the requirements and protocol for effective and secure operations. Changes to this structure could have negative effects to existing controls and frameworks by reallocating or removing resources that once supported PCI DSS controls or inheriting new responsibilities that may not have established controls in place. Therefore, it is important to revisit PCI DSS scope and controls when there are changes to ensure controls are in place and active.
A3.2.4 If segmentation is used, confirm PCI DSS scope by performing penetration …
Added
p. 129
Data-discovery methodology must take into consideration the potential for clear-text PAN to reside on systems and networks outside of the currently defined CDE.
PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.a Examine documented data-discovery methodology to verify the following:
Data-discovery methodology includes processes for identifying all sources and locations of clear-text PAN.
Methodology takes into consideration the potential for clear-text PAN to reside on systems and networks outside of the currently defined CDE.
PCI DSS requires that, as part of the scoping exercise, assessed entities must identify and document the existence of all clear-text PAN in their environments. Implementing a data- discovery methodology that identifies all sources and locations of clear-text PAN, and takes into consideration the potential for clear-text PAN to reside on systems and networks outside of the currently defined CDE or in unexpected places within the defined CDE
•for example, in an error log or memory dump file
• helps …
PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.a Examine documented data-discovery methodology to verify the following:
Data-discovery methodology includes processes for identifying all sources and locations of clear-text PAN.
Methodology takes into consideration the potential for clear-text PAN to reside on systems and networks outside of the currently defined CDE.
PCI DSS requires that, as part of the scoping exercise, assessed entities must identify and document the existence of all clear-text PAN in their environments. Implementing a data- discovery methodology that identifies all sources and locations of clear-text PAN, and takes into consideration the potential for clear-text PAN to reside on systems and networks outside of the currently defined CDE or in unexpected places within the defined CDE
•for example, in an error log or memory dump file
• helps …
Added
p. 130
Procedures for determining what to do if clear-text PAN is discovered outside of the CDE, including its retrieval, secure deletion and/or migration into the currently defined CDE, as applicable Procedures for determining how the data ended up outside of the CDE Procedures for remediating data leaks or process gaps that resulted in the data being outside of the CDE Procedures for identifying the source of the data Procedures for identifying whether any track data is stored with the PANs A3.2.5.2.a Examine documented response procedures to verify that procedures for responding to the detection of clear-text PAN outside of the CDE are defined and include:
Procedures for determining what to do if clear- text PAN is discovered outside of the CDE, including its retrieval, secure deletion and/or migration into the currently defined CDE, as applicable Procedures for determining how the data ended up outside the …
Procedures for determining what to do if clear- text PAN is discovered outside of the CDE, including its retrieval, secure deletion and/or migration into the currently defined CDE, as applicable Procedures for determining how the data ended up outside the …
Added
p. 131
Procedures for the timely investigation of alerts by responsible personnel Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss A3.2.6.1.a Examine documented response procedures to verify that procedures for responding to the attempted removal of clear-text PAN from the CDE via an unauthorized channel, method, or process include:
Procedures for the timely investigation of alerts by responsible personnel Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss Attempts to remove clear-text PAN via an unauthorized channel, method, or process may indicate malicious intent to steal data, or may be the actions of an authorized employee who is unaware of or simply not following the proper methods. Timely investigation of these occurrences can identify where remediation needs to be applied and provides valuable information to help understand where the threats are coming from. A3.2.6.1.b Interview personnel …
Procedures for the timely investigation of alerts by responsible personnel Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss Attempts to remove clear-text PAN via an unauthorized channel, method, or process may indicate malicious intent to steal data, or may be the actions of an authorized employee who is unaware of or simply not following the proper methods. Timely investigation of these occurrences can identify where remediation needs to be applied and provides valuable information to help understand where the threats are coming from. A3.2.6.1.b Interview personnel …
Added
p. 132
Restoring security functions Identifying and documenting the duration (date and time start to end) of the security failure Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause Identifying and addressing any security issues that arose during the failure Performing a risk assessment to determine whether further actions are required as a result of the security failure Implementing controls to prevent cause of failure from reoccurring Resuming monitoring of security controls
PCI DSS Reference: Requirements 1-12 A3.3.1.1.a Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to respond to a security control failure, and include:
Restoring security functions Identifying and documenting the duration (date and time start to end) of the security failure Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root …
PCI DSS Reference: Requirements 1-12 A3.3.1.1.a Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to respond to a security control failure, and include:
Restoring security functions Identifying and documenting the duration (date and time start to end) of the security failure Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root …
Added
p. 133
PCI DSS Reference: Requirements 2, 6 A3.3.2.a Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to review hardware and software technologies to confirm whether they continue to meet the organization’s PCI DSS requirements.
Hardware and software technologies are constantly evolving, and organizations need to be aware of changes to the technologies they use, as well as the evolving threats to those technologies. Organizations also need to be aware of changes made by technology vendors to their products or support processes, to understand how such changes may impact the organization’s use of the technology.
Regular reviews of technologies that impact or influence PCI DSS controls can assist with purchasing, usage, and deployment strategies, and ensure controls that rely on those technologies remain effective.
A3.3.2.b Review the results of the recent reviews to verify reviews are performed at least annually.
A3.3.2.c For any technologies that have been determined to …
Hardware and software technologies are constantly evolving, and organizations need to be aware of changes to the technologies they use, as well as the evolving threats to those technologies. Organizations also need to be aware of changes made by technology vendors to their products or support processes, to understand how such changes may impact the organization’s use of the technology.
Regular reviews of technologies that impact or influence PCI DSS controls can assist with purchasing, usage, and deployment strategies, and ensure controls that rely on those technologies remain effective.
A3.3.2.b Review the results of the recent reviews to verify reviews are performed at least annually.
A3.3.2.c For any technologies that have been determined to …
Added
p. 134
Confirmation that all BAU activities (e.g., A3.2.2, A3.2.6, and A3.3.1) are being performed Confirmation that personnel are following security policies and operational procedures (for example, daily log reviews, firewall rule-set reviews, configuration standards for new systems, etc.) Documenting how the reviews were completed, including how all BAU activities were verified as being in place.
Collection of documented evidence as required for the annual PCI DSS assessment Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program (as identified in A3.1.3) Retention of records and documentation for at least 12 months, covering all BAU activities
PCI DSS Reference: Requirements 1-12 A3.3.3.a Examine policies and procedures to verify that processes are defined for reviewing and verifying BAU activities. Verify the procedures include:
Confirming that all BAU activities (e.g., A3.2.2, A3.2.6, and A3.3.1) are being performed Confirming that personnel are following security policies …
Collection of documented evidence as required for the annual PCI DSS assessment Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program (as identified in A3.1.3) Retention of records and documentation for at least 12 months, covering all BAU activities
PCI DSS Reference: Requirements 1-12 A3.3.3.a Examine policies and procedures to verify that processes are defined for reviewing and verifying BAU activities. Verify the procedures include:
Confirming that all BAU activities (e.g., A3.2.2, A3.2.6, and A3.3.1) are being performed Confirming that personnel are following security policies …
Added
p. 135
PCI DSS Reference: Requirement 7 A3.4.1 Interview responsible personnel and examine supporting documentation to verify that:
User accounts and access privileges are reviewed at least every six months.
Reviews confirm that access is appropriate based on job function, and that all access is authorized.
Access requirements evolve over time as individuals change roles or leave the company, and as job functions change. Management needs to regularly review, revalidate, and update user access, as necessary, to reflect changes in personnel, including third parties, and users’ job functions.
A3.5 Identify and respond to suspicious events A3.5.1 Implement a methodology for the timely identification of attack patterns and undesirable behavior across systems
•for example, using coordinated manual reviews and/or centrally managed or automated log- correlation tools
•to include at least the following:
Identification of anomalies or suspicious activity as it occurs Issuance of timely alerts upon detection of suspicious activity or anomaly to responsible personnel …
User accounts and access privileges are reviewed at least every six months.
Reviews confirm that access is appropriate based on job function, and that all access is authorized.
Access requirements evolve over time as individuals change roles or leave the company, and as job functions change. Management needs to regularly review, revalidate, and update user access, as necessary, to reflect changes in personnel, including third parties, and users’ job functions.
A3.5 Identify and respond to suspicious events A3.5.1 Implement a methodology for the timely identification of attack patterns and undesirable behavior across systems
•for example, using coordinated manual reviews and/or centrally managed or automated log- correlation tools
•to include at least the following:
Identification of anomalies or suspicious activity as it occurs Issuance of timely alerts upon detection of suspicious activity or anomaly to responsible personnel …
Modified
p. 1
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.1
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.2
Modified
p. 7
Primary Account Number (PAN) Cardholder Name Expiration Date Service Code Full track data (magnetic-stripe data or equivalent on a chip) CAV2/CVC2/CVV2/CID PINs/PIN blocks The primary account number is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with applicable PCI DSS requirements.
Primary Account Number (PAN) Cardholder Name Expiration Date Service Code Full track data (magnetic-stripe data or equivalent on a chip) CAV2/CVC2/CVV2/CID PINs/PIN blocks The primary account number is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment (CDE), they must be protected in accordance with applicable PCI DSS requirements.
Modified
p. 9
The PA-DSS requirements are derived from the PCI DSS Requirements and Security Assessment Procedures (defined in this document). The PA-DSS details the requirements a payment application must meet in order to facilitate a customer’s PCI DSS compliance.
The PA-DSS requirements are derived from the PCI DSS Requirements and Security Assessment Procedures (defined in this document). The PA-DSS details the requirements a payment application must meet in order to facilitate a customer’s PCI DSS compliance. As security threats are constantly evolving, applications that are no longer supported by the vendor (e.g., identified by the vendor as “end of life”) may not offer the same level of security as supported versions.
Modified
p. 10
The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in the PCI DSS scope.
The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in the PCI DSS scope. All types of systems …
Removed
p. 14
Note: These best practices for implementing PCI DSS into business-as-usual processes are provided as recommendations and guidance only, and they do not replace or extend any PCI DSS requirement.
Removed
p. 21
Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.
Modified
p. 21 → 22
1.1.6.a Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each•for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.
1.1.6.a Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification and approval for each.
Modified
p. 22 → 23
This requirement is intended to prevent malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they've obtained from within your network out to an untrusted server).
Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, thus preventing unfiltered access between untrusted and trusted environments. This prevents malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they've obtained from within the entity’s network out to an untrusted server).
Removed
p. 24
Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, as well as inspection and blocking of unwanted content, thus preventing unfiltered access between untrusted and trusted environments. This helps prevent, for example, malicious individuals from sending data they've obtained from within your network out to an external untrusted server in an untrusted network.
Modified
p. 24 → 25
A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise.
While there may be legitimate reasons for untrusted connections to be permitted to DMZ systems (e.g., to allow public access to a web server), such connections should never be granted to systems in the internal network. A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, …
Modified
p. 25
(For example, block traffic originating from the Internet with an internal source address.) 1.3.4 Examine firewall and router configurations to verify that anti-spoofing measures are implemented, for example internal addresses cannot pass from the Internet into the DMZ.
(For example, block traffic originating from the Internet with an internal source address.) 1.3.3 Examine firewall and router configurations to verify that anti-spoofing measures are implemented, for example internal addresses cannot pass from the Internet into the DMZ.
Modified
p. 26 → 27
1.3.7.a Examine firewall and router configurations to verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet.
Modified
p. 26 → 27
1.3.7.b Interview personnel and examine documentation to verify that any disclosure of private IP addresses and routing information to external entities is authorized.
Removed
p. 27
Specific configuration settings are defined for personal firewall software. Personal firewall software is actively running. Personal firewall software is not alterable by users of mobile and/or employee-owned devices.
Note: The intent of this requirement applies to employee-owned and company-owned computers. Systems that cannot be managed by corporate policy introduce weaknesses to the perimeter and provide opportunities that malicious individuals may exploit. Allowing untrusted systems to connect to an organization’s network could result in access being granted to attackers and other malicious users.
Personal firewall software is installed and configured per the organization’s specific configuration settings. Personal firewall software is actively running. Personal firewall software is not alterable by users of mobile and/or employee-owned devices.
Note: The intent of this requirement applies to employee-owned and company-owned computers. Systems that cannot be managed by corporate policy introduce weaknesses to the perimeter and provide opportunities that malicious individuals may exploit. Allowing untrusted systems to connect to an organization’s network could result in access being granted to attackers and other malicious users.
Personal firewall software is installed and configured per the organization’s specific configuration settings. Personal firewall software is actively running. Personal firewall software is not alterable by users of mobile and/or employee-owned devices.
Modified
p. 27 → 28
PCI DSS Requirements Testing Procedures Guidance 1.4 Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network. Firewall configurations include:
PCI DSS Requirements Testing Procedures Guidance 1.4 Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE. Firewall (or equivalent) configurations include:
Modified
p. 27 → 28
Personal firewall software is required for all mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network. Specific configuration settings are defined for personal firewall software. Personal firewall software is configured to actively run. Personal firewall software is configured to not be alterable by users of mobile and/or employee-owned devices.
Personal firewall software or equivalent functionality is required for all portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE. Specific configuration settings are defined for personal firewall (or equivalent functionality). Personal firewall (or equivalent functionality) is configured to actively run. Personal firewall (or equivalent functionality) is configured to not be alterable by users of …
Modified
p. 27 → 28
Portable computing devices that are allowed to connect to the Internet from outside the corporate firewall are more vulnerable to Internet-based threats. Use of a personal firewall helps to protect devices from Internet-based attacks, which could use the device to gain access the organization’s systems and data once the device is re-connected to the network.
Portable computing devices that are allowed to connect to the Internet from outside the corporate firewall are more vulnerable to Internet-based threats. Use of firewall functionality (e.g., personal firewall software or hardware) helps to protect devices from Internet-based attacks, which could use the device to gain access the organization’s systems and data once the device is re-connected to the network.
Modified
p. 27 → 28
1.4.b Inspect a sample of mobile and/or employee-owned devices to verify that:
1.4.b Inspect a sample of company and/or employee-owned devices to verify that:
Modified
p. 28 → 29
This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.).
This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.).
Modified
p. 29 → 30
Default passwords/phrases on access points are required to be changed upon installation.
Default passwords/passphrases on access points are required to be changed upon installation.
Removed
p. 32
Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
Removed
p. 32
Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Additionally, SSL and/or early TLS must not be introduced into environments where they don’t already exist. At the time of publication, the known vulnerabilities are difficult to exploit in POS POI payment environments. However, new vulnerabilities could emerge at any time, and it is up to the organization to remain up-to-date with vulnerability trends and determine whether or not they are susceptible to any known exploits.
Refer to the PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.
2.2.3.b For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols:
2.2.3.c For all other environments using …
Refer to the PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.
2.2.3.b For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols:
2.2.3.c For all other environments using …
Removed
p. 33
(Continued on next page) 2.3.a Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested.
Removed
p. 34
Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
Refer to the PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.
To be considered “strong cryptography,” industry- recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. (Refer to "strong cryptography” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, and industry standards and best practices such as NIST SP 800-52 and SP 800-57, OWASP, etc.) Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Additionally, …
Refer to the PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.
To be considered “strong cryptography,” industry- recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. (Refer to "strong cryptography” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, and industry standards and best practices such as NIST SP 800-52 and SP 800-57, OWASP, etc.) Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Additionally, …
Modified
p. 35
This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client's data and thereby …
This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client's data and thereby …
Modified
p. 37
3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured.
(Continued on next page) 3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured.
Modified
p. 38
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: The cardholder’s name Primary account number (PAN) Expiration date Service code To minimize risk, store only these data elements as needed for business.
Modified
p. 39
Note: This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment card brand requirements for point-of-sale (POS) receipts.
Note: This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment card brand requirements for point- of-sale (POS) receipts.
Modified
p. 39
A list of roles that need access to displays of full PAN is documented, together with a legitimate business need for each role to have such access. PAN must be masked when displayed such that only personnel with a legitimate business need can see the full PAN. All other roles not specifically authorized to see the full PAN must only see masked PANs.
A list of roles that need access to displays of more than the first six/last four (includes full PAN) is documented, together with a legitimate business need for each role to have such access. PAN must be masked when displayed such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN. All roles not specifically authorized to see the full PAN must only see masked PANs.
Modified
p. 39
3.3.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see full PAN.
3.3.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see more than the first six/last four digits of the PAN.
Modified
p. 40
3.4.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable or removed from the logs.
3.4.d Examine a sample of audit logs, including payment application logs, to confirm that PAN is rendered unreadable or is not present in the logs.
Modified
p. 41
Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys• such key-encrypting keys must be at least as strong as the data-encrypting key.
Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys•such key- encrypting keys must be at least as strong as the data-encrypting key.
Modified
p. 42 → 43
Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS- approved point-of-interaction device) As at least two full-length key components or key shares, in accordance with an industry- accepted method
Encrypted with a key-encrypting key that is at least as strong as the data- encrypting key, and that is stored separately from the data-encrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) As at least two full-length key components or key shares, in accordance with an industry- accepted method
Modified
p. 42 → 43
3.5.3.a Examine documented procedures to verify that cryptographic keys used to encrypt/decrypt cardholder data must only exist in one (or more) of the following forms at all times.
Modified
p. 42 → 43
3.5.3.b Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt cardholder data exist in one (or more) of the following form at all times.
Modified
p. 42 → 43
Encrypted with a key-encrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) As key components or key shares, in accordance with an industry-accepted method 3.5.2.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:
Encrypted with a key-encrypting key Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) As key components or key shares, in accordance with an industry-accepted method 3.5.3.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:
Modified
p. 43 → 44
The encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under "strong cryptography." Use of strong cryptographic keys significantly increases the level of security of encrypted cardholder data.
The encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under "Cryptographic Key Generation." Use of strong cryptographic keys significantly increases the level of security of encrypted cardholder data.
Modified
p. 43 → 44
3.6.1.b Observe the method for generating keys to verify that strong keys are generated.
3.6.1.b Observe the procedures for generating keys to verify that strong keys are generated.
Modified
p. 45 → 46
Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of the original cryptographic key).
Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of the original cryptographic key.
Modified
p. 46 → 47
PCI DSS Requirements Testing Procedures Guidance 4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
PCI DSS Requirements Testing Procedures Guidance 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
Modified
p. 46 → 47
Only trusted keys and certificates are accepted. The protocol in use only supports secure versions or configurations. The encryption strength is appropriate for the encryption methodology in use. Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
Only trusted keys and certificates are accepted. The protocol in use only supports secure versions or configurations. The encryption strength is appropriate for the encryption methodology in use.
Modified
p. 46 → 47
Examples of open, public networks include but are not limited to: The Internet Wireless technologies, including 802.11 and Bluetooth Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA) General Packet Radio Service (GPRS) Satellite communications 4.1.a Identify all locations where cardholder data is transmitted or received over open, public networks. Examine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for …
Modified
p. 46 → 47
For acceptance of only trusted keys and/or certificates For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported) For implementation of proper encryption strength per the encryption methodology in use 4.1.c Select and observe a sample of inbound and outbound transmissions as they occur to verify that all cardholder data is encrypted with strong cryptography during transit.
For acceptance of only trusted keys and/or certificates For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported) For implementation of proper encryption strength per the encryption methodology in use 4.1.c Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all cardholder data is encrypted with strong cryptography during transit.
Removed
p. 47
Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment; Risk-assessment results and risk-reduction controls in place; Description of processes to monitor for new vulnerabilities associated with SSL/early TLS; Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments; Overview of migration project plan including target migration completion date no later than June 30, 2016.
Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g. NIST SP 800-52 and SP 800-57, OWASP, etc.) Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Additionally, SSL and/or early TLS must not be introduced into environments where they don’t already exist. At the time of publication, the …
Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g. NIST SP 800-52 and SP 800-57, OWASP, etc.) Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Additionally, SSL and/or early TLS must not be introduced into environments where they don’t already exist. At the time of publication, the …
Modified
p. 47 → 48
PCI DSS Requirements Testing Procedures Guidance Examples of open, public networks include but are not limited to: The Internet Wireless technologies, including 802.11 and Bluetooth Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA) General Packet Radio Service (GPRS) Satellite communications 4.1.g For TLS implementations, examine system configurations to verify that TLS is enabled whenever cardholder data is transmitted or received.
PCI DSS Requirements Testing Procedures Guidance 4.1.g For TLS implementations, examine system configurations to verify that TLS is enabled whenever cardholder data is transmitted or received.
Removed
p. 48
Note: The use of WEP as a security control is prohibited.
Modified
p. 48
Industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission.
Industry best practices are used to implement strong encryption for authentication and transmission.
Modified
p. 52 → 53
New security vulnerabilities are identified. A risk ranking is assigned to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities. Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.
New security vulnerabilities are identified. A risk ranking is assigned to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities. Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.
Modified
p. 53 → 54
This requirement applies to applicable patches for all installed software.
This requirement applies to applicable patches for all installed software, including payment applications (both those that are PA-DSS validated and those that are not).
Modified
p. 56 → 57
Test data and accounts should be removed from production code before the application becomes active, since these items may give away information about the functioning of the application or system. Possession of such information could facilitate compromise of the system and related cardholder data.
Test data and accounts should be removed before the system component becomes active (in production), since these items may give away information about the functioning of the application or system. Possession of such information could facilitate compromise of the system and related cardholder data.
Modified
p. 57 → 58
PCI DSS Requirements Testing Procedures Guidance 6.4.5 Change control procedures for the implementation of security patches and software modifications must include the following:
PCI DSS Requirements Testing Procedures Guidance 6.4.5 Change control procedures must include the following:
Modified
p. 57 → 58
6.4.5.a Examine documented change control procedures related to implementing security patches and software modifications and verify procedures are defined for:
6.4.5.a Examine documented change control procedures and verify procedures are defined for:
Modified
p. 57 → 58
Documentation of impact Documented change approval by authorized parties Functionality testing to verify that the change does not adversely impact the security of the system Back-out procedures If not properly managed, the impact of software updates and security patches might not be fully realized and could have unintended consequences.
Documentation of impact Documented change approval by authorized parties Functionality testing to verify that the change does not adversely impact the security of the system Back-out procedures If not properly managed, the impact of system changes
•such as hardware or software updates and installation of security patches •might not be fully realized and could have unintended consequences.
•such as hardware or software updates and installation of security patches •might not be fully realized and could have unintended consequences.
Modified
p. 57 → 58
6.4.5.b For a sample of system components, interview responsible personnel to determine recent changes/security patches. Trace those changes back to related change control documentation. For each change examined, perform the following:
6.4.5.b For a sample of system components, interview responsible personnel to determine recent changes. Trace those changes back to related change control documentation. For each change examined, perform the following:
Modified
p. 57 → 58
Thorough testing should be performed to verify that the security of the environment is not reduced by implementing a change. Testing should validate that all existing security controls remain in place, are replaced with equally strong controls, or are strengthened after any change to the environment. 6.4.5.3.b For custom code changes, verify that all updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production.
Thorough testing should be performed to verify that the security of the environment is not reduced by implementing a change. Testing should validate that all existing security controls remain in place, are replaced with equally strong controls, or are strengthened after any change to the environment.
Removed
p. 58
6.5.b Interview a sample of developers to verify that they are knowledgeable in secure coding techniques.
Modified
p. 58 → 60
Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory. Develop applications based on secure coding guidelines.
Train developers at least annually in up- to-date secure coding techniques, including how to avoid common coding vulnerabilities. Develop applications based on secure coding guidelines.
Modified
p. 58 → 60
6.5.a Examine software-development policies and procedures to verify that training in secure coding techniques is required for developers, based on industry best practices and guidance.
6.5.a Examine software-development policies and procedures to verify that up-to-date training in secure coding techniques is required for developers at least annually, based on industry best practices and guidance.
Modified
p. 58 → 60
6.5.b Examine records of training to verify that software developers receive up-to-date training on secure coding techniques at least annually, including how to avoid common coding vulnerabilities.
Modified
p. 58 → 60
6.5.c Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities:
Removed
p. 62
Note: Requirement 6.5.10 is a best practice until June 30, 2015, after which it becomes a requirement.
Modified
p. 62 → 64
PCI DSS Requirements Testing Procedures Guidance 6.5.10 Broken authentication and session management
PCI DSS Requirements Testing Procedures Guidance 6.5.10 Broken authentication and session management.
Modified
p. 65 → 67
This access control system must include the following:
This access control system(s) must include the following:
Modified
p. 65 → 67
Without a mechanism to restrict access based on user’s need to know, a user may unknowingly be granted access to cardholder data. An access control system automates the process of restricting access and assigning privileges. Additionally, a default “deny-all” setting ensures no one is granted access until and unless a rule is established specifically granting such access.
Without a mechanism to restrict access based on user’s need to know, a user may unknowingly be granted access to cardholder data. Access control systems automate the process of restricting access and assigning privileges. Additionally, a default “deny-all” setting ensures no one is granted access until and unless a rule is established specifically granting such access. Entities may have one or more access controls systems to manage user access.
Modified
p. 67 → 69
Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance).
Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance). These requirements do not apply to accounts used by consumers (e.g., cardholders).
Modified
p. 68 → 70
8.1.5.a Interview personnel and observe processes for managing accounts used by vendors to access, support, or maintain system components to verify that accounts used by vendors for remote access are:
8.1.5.a Interview personnel and observe processes for managing accounts used by third parties to access, support, or maintain system components to verify that accounts used for remote access are:
Modified
p. 68 → 70
Disabled when not in use Enabled only when needed by the vendor, and disabled when not in use.
Disabled when not in use Enabled only when needed by the third party, and disabled when not in use.
Modified
p. 68 → 70
8.1.5.b Interview personnel and observe processes to verify that vendor remote access accounts are monitored while being used.
8.1.5.b Interview personnel and observe processes to verify that third-party remote access accounts are monitored while being used.
Modified
p. 71 → 73
PCI DSS Requirements Testing Procedures Guidance 8.2.3 Passwords/phrases must meet the following:
PCI DSS Requirements Testing Procedures Guidance 8.2.3 Passwords/passphrases must meet the following:
Modified
p. 71 → 73
Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.
Alternatively, the passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above.
Modified
p. 71 → 73
8.2.3a For a sample of system components, inspect system configuration settings to verify that user password parameters are set to require at least the following strength/complexity:
8.2.3a For a sample of system components, inspect system configuration settings to verify that user password/passphrase parameters are set to require at least the following strength/complexity:
Modified
p. 71 → 73
Strong passwords/phrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non- existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.
Strong passwords/passphrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non- existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.
Modified
p. 71 → 73
This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/phrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. NIST SP 800- 63-1 defines “entropy” as “a measure of the difficulty of guessing or determining a password or key.” This document and others that discuss “password entropy” can be referred to for more information on applicable entropy value …
This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.)
Modified
p. 71 → 73
8.2.3.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that non-consumer customer passwords are required to meet at least the following strength/complexity:
8.2.3.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that non-consumer customer passwords/passphrases are required to meet at least the following strength/complexity:
Modified
p. 71 → 73
8.2.4.a For a sample of system components, inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least once every 90 days.
8.2.4.a For a sample of system components, inspect system configuration settings to verify that user password/passphrase parameters are set to require users to change passwords at least once every 90 days.
Modified
p. 71 → 73
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.
Modified
p. 71 → 73
Note: Testing Procedure 8.2.4.b is an additional procedure that only applies if the entity being assessed is a service provider. 8.2.4.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that:
Note: Testing Procedure 8.2.4.b is an additional procedure that only applies if the entity being assessed is a service provider.
Modified
p. 71 → 73
Non-consumer customer user passwords are required to change periodically; and Non-consumer customer users are given guidance as to when, and under what circumstances, passwords must change.
Non-consumer customer user passwords/passphrases are required to change periodically; and Non-consumer customer users are given guidance as to when, and under what circumstances, passwords/passphrases must change.
Removed
p. 72
Two-factor authentication requires two forms of authentication for higher-risk accesses, such as those originating from outside the network This requirement is intended to apply to all personnel
•including general users, administrators, and vendors (for support or maintenance) with remote access to the network
•where that remote access could lead to access to the cardholder data environment.
•including general users, administrators, and vendors (for support or maintenance) with remote access to the network
•where that remote access could lead to access to the cardholder data environment.
Modified
p. 72 → 74
PCI DSS Requirements Testing Procedures Guidance 8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.
PCI DSS Requirements Testing Procedures Guidance 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used.
Modified
p. 72 → 74
8.2.5.a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords cannot be the same as the four previously used passwords.
8.2.5.a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords/passphrases cannot be the same as the four previously used passwords/passphrases.
Modified
p. 72 → 74
8.2.5.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that new non-consumer customer user passwords cannot be the same as the previous four passwords.
8.2.5.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that new non-consumer customer user passwords/passphrase cannot be the same as the previous four passwords.
Modified
p. 72 → 74
Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication.
Examples of multi-factor technologies include but are not limited to remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate multi- factor authentication.
Modified
p. 72 → 75
8.3.2.a Examine system configurations for remote access servers and systems to verify multi-factor authentication is required for:
Modified
p. 72 → 75
All remote access by personnel All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).
All remote access by personnel, both user and administrator, and All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).
Modified
p. 72 → 75
If remote access is to an entity’s network that has appropriate segmentation, such that remote users cannot access or impact the cardholder data environment, two-factor authentication for remote access to that network would not be required. However, two-factor authentication is required for any remote access to networks with access to the cardholder data environment, and is recommended for all remote access to the entity’s networks.
This requirement is intended to apply to all personnel
•including general users, administrators, and vendors (for support or maintenance) with remote access to the network
•where that remote access could lead to access to the CDE. If remote access is to an entity’s network that has appropriate segmentation, such that remote users cannot access or impact the cardholder data environment, multi-factor authentication for remote access to that network would not be required. However, multi- factor authentication is required for any remote access …
•including general users, administrators, and vendors (for support or maintenance) with remote access to the network
•where that remote access could lead to access to the CDE. If remote access is to an entity’s network that has appropriate segmentation, such that remote users cannot access or impact the cardholder data environment, multi-factor authentication for remote access to that network would not be required. However, multi- factor authentication is required for any remote access …
Modified
p. 72 → 75
8.3.2.b Observe a sample of personnel (for example, users and administrators) connecting remotely to the network and verify that at least two of the three authentication methods are used.
Removed
p. 74
Note: Requirement 8.5.1 is a best practice until June 30, 2015, after which it becomes a requirement.
Modified
p. 74 → 77
Technologies, such as two-factor mechanisms, that provide a unique credential for each connection (for example, via a single-use password) could also meet the intent of this requirement.
Technologies, such as multi-factor mechanisms, that provide a unique credential for each connection (for example, via a single-use password) could also meet the intent of this requirement.
Modified
p. 75 → 77
8.6.b Interview security personnel to verify authentication mechanisms are assigned to an account and not shared among multiple accounts.
Modified
p. 76 → 79
Verify that access is controlled with badge readers or other devices including authorized badges and lock and key. Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder environment and verify that they are “locked” to prevent unauthorized use.
Verify that access is controlled with badge readers or other devices including authorized badges and lock and key. Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder data environment and verify that they are “locked” to prevent unauthorized use.
Modified
p. 76 → 79
9.1.1.a Verify that video cameras and/or access control mechanisms are in place to monitor the entry/exit points to sensitive areas.
9.1.1.a Verify that either video cameras or access control mechanisms (or both) are in place to monitor the entry/exit points to sensitive areas.
Modified
p. 76 → 79
(Continued on next page) 9.1.1.b Verify that video cameras and/or access control mechanisms are protected from tampering or disabling.
(Continued on next page) 9.1.1.b Verify that either video cameras or access control mechanisms (or both) are protected from tampering or disabling.
Removed
p. 80
9.5.1.b Verify that the storage location security is reviewed at least annually.
Removed
p. 82
Note: Requirement 9.9 is a best practice until June 30, 2015, after which it becomes a requirement.
Removed
p. 94
11.2.1.b Review the scan reports and verify that the scan process includes rescans until all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.
Modified
p. 95 → 99
PCI DSS Requirements Testing Procedures Guidance 11.2.1.c Interview personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
PCI DSS Requirements Testing Procedures Guidance 11.2.1.c Interview personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
Modified
p. 95 → 99
11.2.2.b Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures).
A robust scanning program ensures that scans are performed and vulnerabilities addressed in a timely manner. 11.2.2.b Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures).
Modified
p. 95 → 99
For internal scans, all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.
For internal scans, all “high risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.
Modified
p. 96 → 100
PCI DSS Requirements Testing Procedures Guidance 11.2.3.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
PCI DSS Requirements Testing Procedures Guidance 11.2.3.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
Modified
p. 97 → 101
11.3.1.b Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
11.3.1.b Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
Modified
p. 97 → 101
11.3.2.b Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
11.3.2.b Verify that the test was performed by a qualified internal resource or qualified external third party and, if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
Modified
p. 99 → 103
11.5.a Verify the use of a change-detection mechanism within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities.
(Continued on next page) 11.5.a Verify the use of a change-detection mechanism by observing system settings and monitored files, as well as reviewing results from monitoring activities.
Modified
p. 99 → 103
Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected. If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing. 11.5.b Verify the …
Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected. If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.
Modified
p. 100 → 105
Identifies critical assets, threats, and vulnerabilities Results in a formal, documented analysis of risk A risk assessment enables an organization to identify threats and associated vulnerabilities with the potential to negatively impact their business. Resources can then be effectively allocated to implement controls that reduce the likelihood and/or the potential impact of the threat being realized.
Identifies critical assets, threats, and vulnerabilities Results in a formal, documented analysis of risk A risk assessment enables an organization to identify threats and associated vulnerabilities with the potential to negatively impact their business. Examples of different risk considerations include cybercrime, web attacks, and POS malware. Resources can then be effectively allocated to implement controls that reduce the likelihood and/or the potential impact of the threat being realized.
Modified
p. 101 → 106
Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e- mail usage and Internet usage.
Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.
Modified
p. 104 → 109
12.6.a Review the security awareness program to verify it provides awareness to all personnel about the importance of cardholder data security.
12.6.a Review the security awareness program to verify it provides awareness to all personnel about the cardholder data security policy and procedures .
Modified
p. 106 → 111
The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.
The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. The extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.
Modified
p. 106 → 111
In conjunction with Requirement 12.9, this requirement for written agreements between organizations and service provides is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.
In conjunction with Requirement 12.9, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.
Removed
p. 107
Note: This requirement is a best practice until June 30, 2015, after which it becomes a requirement.
Modified
p. 110 → 117
Requirements Testing Procedures Guidance A.1 Protect each entity’s (that is, merchant, service provider, or other entity) hosted environment and data, per A.1.1 through A.1.4:
A1 Requirements Testing Procedures Guidance A1 Protect each entity’s (that is, merchant, service provider, or other entity) hosted environment and data, per A1.1 through A1.4:
Modified
p. 110 → 117
A1 Specifically for a PCI DSS assessment of a shared hosting provider, to verify that shared hosting providers protect entities’ (merchants and service providers) hosted environment and data, select a sample of servers (Microsoft Windows and Unix/Linux) across a representative sample of hosted merchants and service providers, and perform A1.1 through A1.4 below:
Modified
p. 110 → 117
A1.1 Ensure that each entity only runs processes that have access to that entity’s cardholder data environment.
Modified
p. 110 → 117
A1.1 If a shared hosting provider allows entities (for example, merchants or service providers) to run their own applications, verify these application processes run using the unique ID of the entity. For example:
Modified
p. 111 → 118
A1.2.a Verify the user ID of any application process is not a privileged user (root/admin).
Modified
p. 111 → 118
A1.2.b Verify each entity (merchant, service provider) has read, write, or execute permissions only for files and directories it owns or for necessary system files (restricted via file system permissions, access control lists, chroot, jailshell, etc.) Important: An entity’s files may not be shared by group.
Modified
p. 111 → 118
A1.2.c Verify that an entity’s users do not have write access to shared system binaries.
Modified
p. 111 → 118
A1.2.d Verify that viewing of log entries is restricted to the owning entity.
Modified
p. 111 → 118
A1.2.e To ensure each entity cannot monopolize server resources to exploit vulnerabilities (for example, error, race, and restart conditions resulting in, for example, buffer overflows), verify restrictions are in place for the use of these system resources:
Modified
p. 111 → 118
Disk space Bandwidth A.1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.
Disk space Bandwidth A1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.
Modified
p. 111 → 118
A1.3 Verify the shared hosting provider has enabled logging as follows, for each merchant and service provider environment:
Modified
p. 111 → 118
A1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.
Modified
p. 111 → 118
A1.4 Verify the shared hosting provider has written policies that provide for a timely forensics investigation of related servers in the event of a compromise.
Modified
p. 112 → 136
b) Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review. For example, two-factor authentication is a PCI DSS requirement for remote access. Two-factor authentication from within the internal network can also be considered as a compensating control for non-console administrative access when transmission of encrypted passwords cannot be supported. Two- factor authentication may be an acceptable compensating control if: (1) it meets the …
b) Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review. For example, multi-factor authentication is a PCI DSS requirement for remote access. Multi-factor authentication from within the internal network can also be considered as a compensating control for non-console administrative access when transmission of encrypted passwords cannot be supported. Multi- factor authentication may be an acceptable compensating control if: (1) it meets the …
Modified
p. 112 → 136
c) Existing PCI DSS requirements may be combined with new controls to become a compensating control. For example, if a company is unable to render cardholder data unreadable per Requirement 3.4 (for example, by encryption), a compensating control could consist of a device or combination of devices, applications, and controls that address all of the following: (1) internal network segmentation; (2) IP address or MAC address filtering; and (3) two-factor authentication from within the internal network.
c) Existing PCI DSS requirements may be combined with new controls to become a compensating control. For example, if a company is unable to render cardholder data unreadable per Requirement 3.4 (for example, by encryption), a compensating control could consist of a device or combination of devices, applications, and controls that address all of the following: (1) internal network segmentation; (2) IP address or MAC address filtering; and (3) multi-factor authentication from within the internal network.
Modified
p. 114 → 138
Company XYZ demonstrates to assessor that the sudo command is configured properly using a “sudoers” file, that only pre-defined commands can be run by specified users, and that all activities performed by those individuals using sudo are logged to identify the individual performing actions using “root” privileges.
Company XYZ demonstrates to assessor that the sudo command is configured properly using a “sudoers” file, that only pre- defined commands can be run by specified users, and that all activities performed by those individuals using sudo are logged to identify the individual performing actions using “root” privileges.