PCI Watch

Tracking changes across the Payment Card Industry

Document Comparison

PCI_DSS_v3.pdf → PCI_DSS_v3-1.pdf
94% similar
112 → 115 Pages
47529 → 49289 Words
116 Content Changes

Content Changes

116 content changes. 39 administrative changes (dates, page numbers) hidden.

Added p. 1
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.1
Added p. 12
Service providers are responsible for demonstrating their PCI DSS compliance, and may be required to do so by the payment brands. Service providers should contact their acquirer and/or payment brand to determine the appropriate compliance validation.
Added 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.
Added p. 32
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 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 …
Added p. 32
2.2.3.c For all other environments using SSL and/or early TLS:
Added p. 32
 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  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.

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- …
Added p. 40
3.4.e If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
Added p. 43
Note: Testing Procedure 3.6.a is an additional procedure that only applies if the entity being assessed is a service provider.
Added p. 46
Note that some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection•for example, by using only trusted certificates and supporting only strong encryption (not supporting weaker, insecure protocols or methods).

 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 …
Added p. 68
8.1.6.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation, and observe implemented processes to verify that non-consumer customer user accounts are temporarily locked-out after not more than six invalid access attempts.

Note: Testing Procedures 8.2.1.d and 8.2.1.e are additional procedures that only apply if the entity being assessed is a service provider.
Added p. 74
Note: This requirement applies only when the entity being assessed is a service provider.
Added p. 98
 The penetration testing covers all segmentation controls/methods in use.
Added p. 107
Note: This requirement applies only when the entity being assessed is a service provider.

The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include provision of an applicable PCI DSS acknowledgement to their customers. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.
Modified p. 5
PCI DSS comprises a minimum set of requirements for protecting cardholder data, and may be enhanced by additional controls and practices to further mitigate risks, as well as local, regional and sector laws and regulations. Additionally, legislation or regulatory requirements may require specific protection of personally identifiable information or other data elements (for example, cardholder name). PCI DSS does not supersede local or regional laws, government regulations, or other legal requirements.
PCI DSS comprises a minimum set of requirements for protecting account data, and may be enhanced by additional controls and practices to further mitigate risks, as well as local, regional and sector laws and regulations. Additionally, legislation or regulatory requirements may require specific protection of personal information or other data elements (for example, cardholder name). PCI DSS does not supersede local or regional laws, government regulations, or other legal requirements.
Modified p. 7
PCI DSS applies to all entities involved in payment card processing•including merchants, processors, financial institutions, and service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.
PCI DSS applies to all entities involved in payment card processing•including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.
Modified p. 7
PCI DSS requirements apply to organizations and environments where account data (cardholder data and/or sensitive authentication data) is stored, processed or transmitted. Some PCI DSS requirements may also be applicable to organizations that have outsourced their payment operations or management of their CDE1. Additionally, organizations that outsource their CDE or payment operations to third parties are responsible for ensuring that the account data is protected by the third party per the applicable PCI DSS requirements.
PCI DSS requirements apply to organizations where account data (cardholder data and/or sensitive authentication data) is stored, processed or transmitted. Some PCI DSS requirements may also be applicable to organizations that have outsourced their payment operations or management of their CDE1. Additionally, organizations that outsource their CDE or payment operations to third parties are responsible for ensuring that the account data is protected by the third party per the applicable PCI DSS requirements.
Modified p. 10
 Any other component or device located within or connected to the CDE 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 ensuring they are included in the PCI DSS scope. To confirm the accuracy and appropriateness of PCI DSS scope, …
 Any other component or device located within or connected to the CDE. 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 …
Modified p. 10
The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity.
The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity.
Modified p. 12
Parties should clearly identify the services and system components which are included in the scope of the service provider’s PCI DSS assessment, the specific PCI DSS requirements covered by the service provider, and any requirements which are the responsibility of the service provider’s customers to include in their own PCI DSS reviews. For example, a managed hosting provider should clearly define which of their IP addresses are scanned as part of their quarterly vulnerability scan process and which IP addresses …
Parties should clearly identify the services and system components which are included in the scope of the service provider’s PCI DSS assessment, the specific PCI DSS requirements covered by the service provider, and any requirements which are the responsibility of the service provider’s customers to include in their own PCI DSS reviews. For example, a managed hosting provider should clearly define which of their IP addresses are scanned as part of their quarterly vulnerability scan process and which IP addresses …
Modified p. 12
1) They can undergo a PCI DSS assessment on their own and provide evidence to their customers to demonstrate their compliance; or 2) If they do not undergo their own PCI DSS assessment, they will need to have their services reviewed during the course of each of their customers’ PCI DSS assessments. If the third party undergoes their own PCI DSS assessment, they should provide sufficient evidence to their customers to verify that the scope of the service provider’s PCI …
1) Annual assessment: Service providers can undergo an annual PCI DSS assessment(s) on their own and provide evidence to their customers to demonstrate their compliance; or 2) Multiple, on-demand assessments: If they do not undergo their own annual PCI DSS assessments, service providers must undergo assessments upon request of their customers and/or participate in each of their customer’s PCI DSS reviews, with the results of each review provided to the respective customer(s) If the third party undergoes their own PCI …
Modified p. 13
3. Review changes to the environment (for example, addition of new systems, changes in system or network configurations) prior to completion of the change, and perform the following:
3. Reviewing changes to the environment (for example, addition of new systems, changes in system or network configurations) prior to completion of the change, and perform the following:
Modified p. 13
4. Changes to organizational structure (for example, a company merger or acquisition) should result in formal review of the impact to PCI DSS scope and requirements.
4. Changes to organizational structure (for example, a company merger or acquisition) resulting in formal review of the impact to PCI DSS scope and requirements.
Modified p. 13
5. Periodic reviews and communications should be performed to confirm that PCI DSS requirements continue to be in place and personnel are following secure processes. These periodic reviews should cover all facilities and locations, including retail outlets, data centers, etc., and include reviewing system components (or samples of system components), to verify that PCI DSS requirements continue to be in place•for example, configuration standards have been applied, patches and AV are up to date, audit logs are being reviewed, and …
5. Performing periodic reviews and communications to confirm that PCI DSS requirements continue to be in place and personnel are following secure processes. These periodic reviews should cover all facilities and locations, including retail outlets, data centers, etc., and include reviewing system components (or samples of system components), to verify that PCI DSS requirements continue to be in place•for example, configuration standards have been applied, patches and AV are up to date, audit logs are being reviewed, and so on. …
Modified p. 14
6. Review hardware and software technologies at least annually to confirm that they continue to be supported by the vendor and can meet the entity’s security requirements, including PCI DSS. If it is discovered that technologies are no longer supported by the vendor or cannot meet the entity’s security needs, the entity should prepare a remediation plan, up to and including replacement of the technology, as necessary.
6. Reviewing hardware and software technologies at least annually to confirm that they continue to be supported by the vendor and can meet the entity’s security requirements, including PCI DSS. If it is discovered that technologies are no longer supported by the vendor or cannot meet the entity’s security needs, the entity should prepare a remediation plan, up to and including replacement of the technology, as necessary.
Modified p. 17
3. If required, perform remediation for any not-in-place items.
6. If required, perform remediation to address requirements that are not in place, and provide an updated report.
Modified p. 17
4. Complete the applicable report for the assessment (i.e., Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC), including documentation of all compensating controls, according to the applicable PCI guidance and instructions.
3. Complete the applicable report for the assessment (i.e., Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)), including documentation of all compensating controls, according to the applicable PCI guidance and instructions.
Modified p. 17
5. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Attestations of Compliance are available on the PCI SSC website.
4. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Attestations of Compliance are available on the PCI SSC website.
Modified p. 17
6. Submit the SAQ or ROC, and the Attestation of Compliance, along with any other requested documentation

•such as ASV scan reports to the acquirer (for merchants) or to the payment brand or other requester (for service providers).
5. Submit the SAQ or ROC, and the Attestation of Compliance, along with any other requested documentation

•such as ASV scan reports to the acquirer (for merchants) or to the payment brand or other requester (for service providers).
Modified p. 20
 Shows all cardholder data flows across systems and networks.  Is kept current and updated as needed upon changes to the environment.
 Shows all cardholder data flows across systems and networks.
Modified p. 22
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.) Implementing a rule that denies all inbound and outbound traffic that is not specifically needed helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic in or out.
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).
Modified p. 27
 Personal firewall software is required for all mobile and/or employee-owned devices that connect to the Internet (for example, laptops used by employees) when outside the network, 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 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.
Modified p. 29
2.1.1.e Examine vendor documentation and observe wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable.
2.1.1.e Examine vendor documentation and observe wireless configuration settings to verify other security- related wireless vendor defaults were changed, if applicable.
Modified p. 32 → 33
PCI DSS Requirements Testing Procedures Guidance 2.2.4.c Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards.
2.2.4.c Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards.
Modified p. 32 → 33
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.) 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.
(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.
Modified p. 34 → 36
 Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements  Processes for secure deletion of data when no longer needed  Specific retention requirements for cardholder data  A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.
 Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements  Specific retention requirements for cardholder data  Processes for secure deletion of data when no longer needed  A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.
Modified p. 34 → 36
3.1.a Examine the data retention and disposal policies, procedures and processes to verify they include at least the following:
3.1.a Examine the data retention and disposal policies, procedures and processes to verify they include the following for all cardholder data (CHD) storage:
Modified p. 34 → 36
Legal, regulatory, and business requirements for data retention, including  Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).  Secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons  Coverage for all storage of cardholder data  A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.
Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.  Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).  Processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons.  A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.
Modified p. 36 → 38
For non-issuing entities, retaining sensitive authentication data post-authentication is not permitted.
For non-issuing entities, retaining sensitive authentication data post-authorization is not permitted.
Modified p. 37 → 39
PCI DSS Requirements Testing Procedures Guidance 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
PCI DSS Requirements Testing Procedures Guidance 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.
Modified p. 38 → 40
Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
Modified p. 38 → 40
The intent of truncation is that only a portion (not to exceed the first six and last four digits) of the PAN is stored.
The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored.
Modified p. 40 → 42
 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 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. 40 → 42
 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 host security module (HSM) or PTS-approved point-of- interaction device)  As key components or key shares, in accordance with an industry-accepted method Cryptographic keys must be stored securely to prevent unauthorized or unnecessary access that could result in the exposure of cardholder data.
 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 key components or key shares, in accordance with an industry-accepted method Cryptographic keys must be stored securely to prevent unauthorized or unnecessary access that could result in the exposure of cardholder data.
Modified p. 40 → 42
 Encrypted with a key-encrypting key  Within a secure cryptographic device (such as a 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.2.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:
Modified p. 41 → 43
3.6.a Additional testing procedure for service providers: If the service provider shares keys with their customers for transmission or storage of cardholder data, examine the documentation that the service provider provides to their customers to verify that it includes guidance on how to securely transmit, store, and update customers’ keys, in accordance with Requirements 3.6.1 through 3.6.8 below.
3.6.a Additional testing procedure for service provider assessments only: If the service provider shares keys with their customers for transmission or storage of cardholder data, examine the documentation that the service provider provides to their customers to verify that it includes guidance on how to securely transmit, store, and update customers’ keys, in accordance with Requirements 3.6.1 through 3.6.8 below.
Removed p. 44
 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.

Note that some protocol implementations (such as SSL v2.0, SSH v1.0 and TLS 1.0) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection. For example, TLS v1.1, or later, certificates obtained from a recognized, public certificate authority and supporting only strong encryption, may be considered.
Modified p. 44 → 46
PCI DSS Requirements Testing Procedures Guidance 4.1 Use strong cryptography and security protocols (for example, SSL/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 (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
Modified p. 44 → 46
 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.
 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.
Modified p. 44 → 46
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 all locations.
(Continued on next page) 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 all locations.
Modified p. 44 → 46
4.1.b Review documented policies and procedures to verify processes are specified for the following:
(Continued on next page) 4.1.b Review documented policies and procedures to verify processes are specified for the following:
Modified p. 45 → 47
PCI DSS Requirements Testing Procedures Guidance 4.1.g For SSL/TLS implementations, examine system configurations to verify that SSL/TLS is enabled whenever cardholder data is transmitted or received.
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.
Modified p. 45 → 47
Generally, the web page URL should begin with "HTTPS" and/or the web browser display a padlock icon somewhere in the window of the browser. Many SSL certificate vendors also provide a highly visible verification seal
Generally, the web page URL should begin with "HTTPS" and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal
Modified p. 45 → 48
 Weak encryption (for example, WEP, SSL version 2.0 or older) is not used as a security control for authentication or transmission.
 Weak encryption (for example, WEP, SSL) is not used as a security control for authentication or transmission.
Modified p. 45 → 48
E-mail, instant messaging, and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. Do not utilize these messaging tools to send PAN unless they are configured to provide strong encryption.
E-mail, instant messaging, SMS, and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. Do not utilize these messaging tools to send PAN unless they are configured to provide strong encryption.
Modified p. 51 → 54
 Code reviews ensure code is developed according to secure coding guidelines  Appropriate corrections are implemented prior to release.  Code-review results are reviewed and approved by management prior to release.
 Code reviews ensure code is developed according to secure coding guidelines  Appropriate corrections are implemented prior to release.
Modified p. 51 → 54
 Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).  Appropriate corrections are implemented prior to release.
 Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).
Modified p. 59 → 62
 Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.
 Installing an automated technical solution that detects and prevents web- based attacks (for example, a web- application firewall) in front of public- facing web applications, to continually check all traffic.
Modified p. 59 → 62
- Is situated in front of public-facing web applications to detect and prevent web-based attacks. - Is actively running and up to date as applicable. - Is generating audit logs. - Is configured to either block web-based attacks, or generate an alert.
- Is situated in front of public-facing web applications to detect and prevent web-based attacks. - Is actively running and up to date as applicable. - Is generating audit logs. - Is configured to either block web-based attacks, or generate an alert that is immediately investigated.
Modified p. 59 → 62
 Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities  Web-application firewalls filter and block non- essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured.
 Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities  Web-application firewalls filter and block non- essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured. This can be achieved through a combination of technology and process. Process-based solutions must have mechanisms that facilitate timely responses to alerts in order to meet the intent …
Modified p. 65 → 68
PCI DSS Requirements Testing Procedures Guidance 8.1.4 Remove/disable inactive user accounts at least every 90 days.
PCI DSS Requirements Testing Procedures Guidance 8.1.4 Remove/disable inactive user accounts within 90 days.
Modified p. 65 → 68
Without account-lockout mechanisms in place, an attacker can continually attempt to guess a password through manual or automated tools (for example, password cracking), until they achieve success and gain access to a user’s account. 8.1.6.b Additional testing procedure for service providers: Review internal processes and customer/user documentation, and observe implemented processes to verify that non- consumer user accounts are temporarily locked-out after not more than six invalid access attempts.
Without account-lockout mechanisms in place, an attacker can continually attempt to guess a password through manual or automated tools (for example, password cracking), until they achieve success and gain access to a user’s account.
Modified p. 67 → 70
8.2.1.d Additional testing procedure for service providers: Observe password files to verify that customer passwords are unreadable during storage.
8.2.1.d Additional testing procedure for service provider assessments only: Observe password files to verify that non- consumer customer passwords are unreadable during storage.
Modified p. 67 → 70
8.2.1.e Additional testing procedure for service providers: Observe data transmissions to verify that customer passwords are unreadable during transmission.
8.2.1.e Additional testing procedure for service provider assessments only: Observe data transmissions to verify that non-consumer customer passwords are unreadable during transmission.
Modified p. 68 → 71
8.2.3.b Additional testing procedure for service providers: Review internal processes and customer/user documentation to verify that non-consumer user 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 are required to meet at least the following strength/complexity:
Modified p. 68 → 71
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 every 90 days.
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.
Modified p. 68 → 71
8.2.4.b Additional testing procedure for service providers: 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. 8.2.4.b Additional testing procedure for service provider assessments only: Review internal processes and customer/user documentation to verify that:
Modified p. 68 → 71
 Non-consumer user passwords are required to change periodically; and  Non-consumer users are given guidance as to when, and under what circumstances, passwords must change.
 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.
Modified p. 69 → 72
8.2.5.b Additional testing procedure for service providers: Review internal processes and customer/user documentation to verify that new non-consumer 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 cannot be the same as the previous four passwords.
Modified p. 70 → 73
PCI DSS Requirements Testing Procedures Guidance 8.4 Document and communicate authentication procedures and policies to all users including:
PCI DSS Requirements Testing Procedures Guidance 8.4 Document and communicate authentication policies and procedures to all users including:
Modified p. 70 → 73
8.4.a Examine procedures and interview personnel to verify that authentication procedures and policies are distributed to all users.
8.4.a Examine procedures and interview personnel to verify that authentication policies and procedures are distributed to all users.
Modified p. 70 → 73
Communicating password/authentication procedures to all users helps those users understand and abide by the policies.
Communicating password/authentication policies and procedures to all users helps those users understand and abide by the policies.
Modified p. 70 → 73
8.4.b Review authentication procedures and policies that are distributed to users and verify they include:
8.4.b Review authentication policies and procedures that are distributed to users and verify they include:
Modified p. 70 → 73
8.4.c Interview a sample of users to verify that they are familiar with authentication procedures and policies.
8.4.c Interview a sample of users to verify that they are familiar with authentication policies and procedures.
Modified p. 70 → 73
If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to trace system access and activities to an individual. This in turn prevents an entity from assigning accountability for, or having effective logging of, an individual’s actions, since a given action could have been performed by anyone in the group that has knowledge of the authentication credentials. 8.5.b Examine authentication policies/procedures to verify that use of group and shared IDs and/or passwords or …
If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to trace system access and activities to an individual. This in turn prevents an entity from assigning accountability for, or having effective logging of, an individual’s actions, since a given action could have been performed by anyone in the group that has knowledge of the authentication credentials. 8.5.b Examine authentication policies and procedures to verify that use of group and shared IDs and/or …
Modified p. 71 → 74
PCI DSS Requirements Testing Procedures Guidance 8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
PCI DSS Requirements Testing Procedures Guidance 8.5.1 Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
Modified p. 74 → 77
PCI DSS Requirements Testing Procedures Guidance 9.1.1.c Verify that video cameras and/or access control mechanisms are monitored and that data from cameras or other mechanisms is stored for at least three months.
PCI DSS Requirements Testing Procedures Guidance 9.1.1.c Verify that data from video cameras and/or access control mechanisms is reviewed, and that data is stored for at least three months.
Removed p. 75
9.2.d Examine identification methods (such as ID badges) in use to verify that they clearly identify visitors and it is easy to distinguish between onsite personnel and visitors.
Modified p. 75 → 78
 Identifying new onsite personnel or visitors (for example, assigning badges)  Changes to access requirements  Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).
 Identifying onsite personnel and visitors (for example, assigning badges)  Changes to access requirements  Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).
Modified p. 75 → 78
Verify procedures include the following:
Verify procedures include the following:
Modified p. 75 → 78
 Identifying new onsite personnel or visitors (for example, assigning badges),  Changing access requirements, and  Revoking terminated onsite personnel and expired visitor identification (such as ID badges) Identifying authorized visitors so they are easily distinguished from onsite personnel prevents unauthorized visitors from being granted access to areas containing cardholder data.
 Identifying onsite personnel and visitors (for example, assigning badges),  Changing access requirements, and  Revoking terminated onsite personnel and expired visitor identification (such as ID badges) Identifying authorized visitors so they are easily distinguished from onsite personnel prevents unauthorized visitors from being granted access to areas containing cardholder data.
Modified p. 75 → 78
9.2.b Observe processes for identifying and distinguishing between onsite personnel and visitors to verify that:
9.2.b Examine identification methods (such as ID badges) and observe processes for identifying and distinguishing between onsite personnel and visitors to verify that:
Modified p. 75 → 78
9.3.a For a sample of onsite personnel with physical access to the CDE, interview responsible personnel and observe access control lists to verify that:
9.3.a For a sample of onsite personnel with physical access to sensitive areas, interview responsible personnel and observe access control lists to verify that:
Modified p. 75 → 78
 Access to the CDE is authorized.  Access is required for the individual’s job function.
 Access to the sensitive area is authorized.  Access is required for the individual’s job function.
Modified p. 75 → 78
Controlling physical access to the CDE helps ensure that only authorized personnel with a legitimate business need are granted access.
Controlling physical access to sensitive areas helps ensure that only authorized personnel with a legitimate business need are granted access.
Modified p. 75 → 78
When personnel leave the organization, all physical access mechanisms should be returned or disabled promptly (as soon as possible) upon their departure, to ensure personnel cannot gain physical access to the CDE once their employment has ended.
When personnel leave the organization, all physical access mechanisms should be returned or disabled promptly (as soon as possible) upon their departure, to ensure personnel cannot gain physical access to sensitive areas once their employment has ended.
Modified p. 75 → 78
9.3.b Observe personnel access the CDE to verify that all personnel are authorized before being granted access.
9.3.b Observe personnel accessing sensitive areas to verify that all personnel are authorized before being granted access.
Modified p. 75 → 78
9.3.c Select a sample of recently terminated employees and review access control lists to verify the personnel do not have physical access to the CDE.
9.3.c Select a sample of recently terminated employees and review access control lists to verify the personnel do not have physical access to sensitive areas.
Modified p. 78 → 81
 Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard- copy materials cannot be reconstructed.  Storage containers used for materials that are to be destroyed must be secured.  Cardholder data on electronic media must be rendered unrecoverable via a secure wipe program (in accordance with industry-accepted standards for secure deletion), or by physically destroying the media.
 Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard- copy materials cannot be reconstructed.  Storage containers used for materials that are to be destroyed must be secured.  Cardholder data on electronic media must be rendered unrecoverable (e.g., via a secure wipe program in accordance with industry-accepted standards for secure deletion, or by physically destroying the media).
Modified p. 79 → 82
9.9.1.b Select a sample of devices from the list and observe device locations to verify that the list is accurate and up to date.
9.9.1.b Select a sample of devices from the list and observe devices and device locations to verify that the list is accurate and up to date.
Modified p. 80 → 83
 Personnel are aware of procedures for inspecting devices.  All devices are periodically inspected for evidence of tampering and substitution.
 All devices are periodically inspected for evidence of tampering and substitution.
Modified p. 81 → 84
 Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).  Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).
 Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
Modified p. 87 → 90
 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).
 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).
Modified p. 87 → 90
 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).
 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).
Modified p. 87 → 90
 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) Many breaches occur over days or months before being detected. Checking logs daily minimizes the amount of time and exposure …
 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) Checking logs daily minimizes the amount of time and exposure of a potential breach.
Modified p. 88 → 91
10.7.b Interview personnel and examine audit logs to verify that audit logs are available for at least one year.
10.7.b Interview personnel and examine audit logs to verify that audit logs are retained for at least one year.
Modified p. 88 → 91
10.7.c Interview personnel and observe processes to verify that at least the last three months’ logs can be immediately restored for analysis.
10.7.c Interview personnel and observe processes to verify that at least the last three months’ logs are immediately available for analysis.
Modified p. 89 → 92
11.1.c Examine output from recent wireless scans to verify that:
11.1.c If wireless scanning is utilized, examine output from recent wireless scans to verify that:
Modified p. 91 → 94
A vulnerability scan is an automated tool run against external and internal network devices and servers, designed to expose potential vulnerabilities that could be found and exploited by malicious individuals.
A vulnerability scan is a combination of automated or manual tools, techniques, and/or methods run against external and internal network devices and servers, designed to expose potential vulnerabilities that could be found and exploited by malicious individuals.
Modified p. 93 → 96
 Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)  Includes coverage for the entire CDE perimeter and critical  Testing from both inside and outside the network  Includes testing to validate any segmentation and scope- reduction controls  Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5  Defines network-layer penetration tests to include components that support network functions as well as operating systems  Includes review and consideration …
 Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)  Includes coverage for the entire CDE perimeter and critical systems  Testing from both inside and outside the network  Includes testing to validate any segmentation and scope- reduction controls  Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5  Defines network-layer penetration tests to include components that support network functions as well as operating systems  Includes review and …
Modified p. 94 → 97
11.3.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment.
11.3.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed as follows.
Modified p. 95 → 98
PCI DSS Requirements Testing Procedures Guidance 11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.
PCI DSS Requirements Testing Procedures Guidance 11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.
Modified p. 95 → 98
11.3.4.a Examine segmentation controls and review penetration-testing methodology to verify that penetration- testing procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out-of-scope systems from in-scope systems.
11.3.4.a Examine segmentation controls and review penetration-testing methodology to verify that penetration- testing procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out-of-scope systems from systems in the CDE.
Modified p. 95 → 98
11.3.4.b Examine the results from the most recent penetration test to verify that penetration testing to verify segmentation controls:
11.3.4.b Examine the results from the most recent penetration test to verify that:
Modified p. 95 → 98
Is performed at least annually and after any changes to segmentation controls/methods.
Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods.
Modified p. 95 → 98
Covers all segmentation controls/methods in use.  Verifies that segmentation methods are operational and effective, and isolate all out-of-scope systems from in- scope systems.
The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE.
Removed p. 96
11.5.b Verify the mechanism is configured to alert personnel to unauthorized modification of critical files, and to perform critical file comparisons at least weekly.
Modified p. 96 → 99
PCI DSS Requirements Testing Procedures Guidance 11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.
PCI DSS Requirements Testing Procedures Guidance 11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.
Modified p. 96 → 99
System executables Application executables Configuration and parameter files Centrally stored, historical or archived, log and audit files Additional critical files determined by entity (for example, through risk assessment or other means).
System executables Application executables Configuration and parameter files Centrally stored, historical or archived, log and audit files Additional critical files determined by entity (for example, through risk assessment or other means).
Modified p. 96 → 99
Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes 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 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.
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 …
Modified p. 97 → 100
 Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),  Identifies critical assets, threats, and vulnerabilities, and  Results in a formal risk assessment.
 Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),  Identifies critical assets, threats, and vulnerabilities, and  Results in a formal, documented analysis of risk.
Modified p. 97 → 100
12.2.a Verify that an annual risk-assessment process is documented that identifies assets, threats, vulnerabilities, and results in a formal risk assessment.
12.2.a Verify that an annual risk-assessment process is documented that:
Modified p. 97 → 100
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. 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. 104 → 107
This requirement applies when the entity being assessed is a service provider. In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.
In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.
Modified p. 111 → 114
Company XYZ is going to require all users to log into the servers from their desktops using the “SU” (substitute user) command. This allows a user to access the “root” account and perform actions under the “root” account but is able to be logged in the SU-log directory. In this way, each user’s actions can be tracked through the SU account, without the “root” password being shared with the users.
Company XYZ is going to require all users to log into the servers using their regular user accounts, and then use the “sudo” command to run any administrative commands. This allows use of the “root” account privileges to run pre-defined commands that are recorded by sudo in the security log. In this way, each user’s actions can be traced to an individual user account, without the “root” password being shared with the users.
Modified p. 111 → 114
Company XYZ demonstrates to assessor that the SU command is being executed and that all activities performed by those individuals utilizing the command are logged to identify that the individual is performing actions under 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.
Modified p. 111 → 114
Company XYZ documents processes and procedures to ensure SU configurations are not changed, altered, or removed to allow individual users to execute root commands without being individually identified, tracked and logged.
Company XYZ documents processes and procedures to ensure sudo configurations are not changed, altered, or removed to allow individual users to execute root commands without being individually identified, tracked and logged.