Document Comparison
PCI_DSS_v3-2.pdf
→
PCI-DSS-v3-2-1-r1.pdf
95% similar
139 → 139
Pages
57812 → 57964
Words
298
Content Changes
Content Changes
298 content changes. 70 administrative changes (dates, page numbers) hidden.
Added
p. 6
• Frequently Asked Questions (FAQs)
• PCI for Small Merchants website
• PCI training courses and informational webinars
• List of Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs)
• List of PTS approved devices and PA-DSS validated payment applications Please refer to www.pcisecuritystandards.org for information about these and other resources.
• Primary Account Number (PAN)
• Full track data (magnetic-stripe data or equivalent on a chip)
• CAV2/CVC2/CVN2/CVV2/CID
• PCI for Small Merchants website
• PCI training courses and informational webinars
• List of Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs)
• List of PTS approved devices and PA-DSS validated payment applications Please refer to www.pcisecuritystandards.org for information about these and other resources.
• Primary Account Number (PAN)
• Full track data (magnetic-stripe data or equivalent on a chip)
• CAV2/CVC2/CVN2/CVV2/CID
Added
p. 11
• The scope of the PCI DSS assessment
• The cost of the PCI DSS assessment
• The cost and difficulty of implementing and maintaining PCI DSS controls
• The cost of the PCI DSS assessment
• The cost and difficulty of implementing and maintaining PCI DSS controls
Added
p. 16
• Samples of system components must include every type and combination that is in use. For example, where applications are sampled, the sample must include all versions and platforms for each type of application.
• Document the rationale behind the sampling technique and sample size,
• Explain how the sample is appropriate and representative of the overall population.
• Document the rationale behind the sampling technique and sample size,
• Explain how the sample is appropriate and representative of the overall population.
Added
p. 19
• PCI DSS Requirements
• Network connections and
• Network connections and
Added
p. 30
• Encryption keys were changed from default at installation
• Transmission over wireless networks.
• Center for Internet Security (CIS)
• Transmission over wireless networks.
• Center for Internet Security (CIS)
Added
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.
Added
p. 37
• The data is stored securely.
• Primary account number (PAN)
• The cardholder’s name
• Service code To minimize risk, store only these data elements as needed for business.
• 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.
• One-way hashes based on strong cryptography,
• Index tokens and pads, with the pads being securely stored
• Description of the key usage for each
• Description of the key usage for each key
• Inventory of any HSMs and other SCDs used for key management
• 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.
• …
• Primary account number (PAN)
• The cardholder’s name
• Service code To minimize risk, store only these data elements as needed for business.
• 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.
• One-way hashes based on strong cryptography,
• Index tokens and pads, with the pads being securely stored
• Description of the key usage for each
• Description of the key usage for each key
• Inventory of any HSMs and other SCDs used for key management
• 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.
• …
Added
p. 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
• Network diagram is updated to reflect changes.
• Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled.
• Train developers at least annually in up- to-date secure coding techniques, 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.
Requirements 6.5.1 through 6.5.10 are the minimum controls that should be in place, and organizations should incorporate the relevant secure coding 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.
• Documented change approval by authorized parties
• Functionality testing to verify that the change does not adversely impact the security of the system
• Network diagram is updated to reflect changes.
• Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled.
• Train developers at least annually in up- to-date secure coding techniques, 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.
Requirements 6.5.1 through 6.5.10 are the minimum controls that should be in place, and organizations should incorporate the relevant secure coding 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.
Added
p. 62
• Validating all parameters before inclusion
• Utilizing context-sensitive escaping.
• Proper authentication of users
• Not exposing internal object references to users
• Flagging session tokens (for example cookies) as
• Not exposing session IDs in the URL
• Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities
• System components and data resources that each role needs to access for their job function
• Identification of privilege necessary for each role to perform their job function.
• Assigned only to roles that specifically require such privileged access
• Necessary for that individual’s job function
• Documented approval exists for the assigned privileges
• The approval was by authorized parties
• Utilizing context-sensitive escaping.
• Proper authentication of users
• Not exposing internal object references to users
• Flagging session tokens (for example cookies) as
• Not exposing session IDs in the URL
• Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities
• System components and data resources that each role needs to access for their job function
• Identification of privilege necessary for each role to perform their job function.
• Assigned only to roles that specifically require such privileged access
• Necessary for that individual’s job function
• Documented approval exists for the assigned privileges
• The approval was by authorized parties
Added
p. 70
• Disabled when not in use
Added
p. 73
• Non-consumer customer user passwords/passphrases are required to change periodically; and
• All remote access by personnel, both user and administrator, and
• Generic user IDs are disabled or removed.
• All remote access by personnel, both user and administrator, and
• Generic user IDs are disabled or removed.
Added
p. 81
• Identifying onsite personnel and visitors (for example, assigning badges)
• Changes to access requirements
• Identifying onsite personnel and visitors (for example, assigning badges),
• Changing access requirements, and
• Visitors are clearly identified, and
• Access to the sensitive area is authorized.
• The visitor’s name,
• The firm represented, and
• Changes to access requirements
• Identifying onsite personnel and visitors (for example, assigning badges),
• Changing access requirements, and
• Visitors are clearly identified, and
• Access to the sensitive area is authorized.
• The visitor’s name,
• The firm represented, and
Added
p. 85
• Maintaining a list of devices
• Periodically inspecting devices to look for tampering or substitution
• Make, model of device
• Make, model of device
• Device serial number or other method of unique identification.
• Device serial number or other method of unique identification.
• Frequency of inspections.
• Access to system components is linked to individual users.
• Initialization of audit logs
• Systems receive time information only from designated central time server(s).
• Periodically inspecting devices to look for tampering or substitution
• Make, model of device
• Make, model of device
• Device serial number or other method of unique identification.
• Device serial number or other method of unique identification.
• Frequency of inspections.
• Access to system components is linked to individual users.
• Initialization of audit logs
• Systems receive time information only from designated central time server(s).
Added
p. 94
• Audit log retention policies
• Identification of cause(s) of the failure, including root cause
• Duration (date and time start and end) of the security failure
• WLAN cards inserted into system components
• Wireless devices attached to a network port or network device.
• Authorized and unauthorized wireless access points are identified, and
• Internal quarterly vulnerability scanning by qualified personnel (use of a PCI SSC Approved Scanning Vendor (ASV) is not required)
• External quarterly vulnerability scanning, which must be performed by an ASV
• Identification of cause(s) of the failure, including root cause
• Duration (date and time start and end) of the security failure
• WLAN cards inserted into system components
• Wireless devices attached to a network port or network device.
• Authorized and unauthorized wireless access points are identified, and
• Internal quarterly vulnerability scanning by qualified personnel (use of a PCI SSC Approved Scanning Vendor (ASV) is not required)
• External quarterly vulnerability scanning, which must be performed by an ASV
Added
p. 101
• Per the defined methodology
• Per the defined methodology
• At the perimeter of the cardholder data environment
• Application executables
• Configuration and parameter files
• Centrally stored, historical or archived, log and audit files
• Identifies critical assets, threats, and vulnerabilities, and
• Results in a formal, documented analysis of risk.
• Identifies critical assets, threats, and vulnerabilities
• A list of all critical devices, and
• 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.
• Per the defined methodology
• At the perimeter of the cardholder data environment
• Application executables
• Configuration and parameter files
• Centrally stored, historical or archived, log and audit files
• Identifies critical assets, threats, and vulnerabilities, and
• Results in a formal, documented analysis of risk.
• Identifies critical assets, threats, and vulnerabilities
• A list of all critical devices, and
• 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.
Added
p. 113
• Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum
• Specific incident response procedures
• Business recovery and continuity procedures
• Data backup processes
• Coverage and responses for all critical system components
• Reference or inclusion of incident response procedures from the payment brands.
• Specific incident response procedures
• Business recovery and continuity procedures
• Data backup processes
• Coverage and responses for all critical system components
• Reference or inclusion of incident response procedures from the payment brands.
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 for Card-Present POS POI terminal connections
• Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS for Card-Present POS POI terminal connections
Added
p. 119
• POS POI terminals in card-present environments that can be verified as not being susceptible to any known exploits for SSL and early TLS, and the SSL/TLS termination points to which they connect, may continue using SSL/early TLS as a security control.
This Appendix only applies to entities using SSL/early TLS as a security control to protect POS POI terminals, including service providers who provide connections into POS POI terminals.
Note: This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant. This requirement is not intended for service providers who serve as the termination or connection point to those POS POI terminals. Requirements A2.2 and A2.3 apply to POS POI service providers.
POS POI terminals used in card-present environments can continue using SSL/early TLS when it can be shown that the POS POI terminal is not susceptible to the currently known exploits.
However, SSL is an …
This Appendix only applies to entities using SSL/early TLS as a security control to protect POS POI terminals, including service providers who provide connections into POS POI terminals.
Note: This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant. This requirement is not intended for service providers who serve as the termination or connection point to those POS POI terminals. Requirements A2.2 and A2.3 apply to POS POI service providers.
POS POI terminals used in card-present environments can continue using SSL/early TLS when it can be shown that the POS POI terminal is not susceptible to the currently known exploits.
However, SSL is an …
Added
p. 121
Service providers should communicate to all customers using SSL/early TLS about the risks associated with its use and need to migrate to a secure protocol.
A2.3 Requirement for Service Providers Only: All service providers must provide a secure service offering.
• Overall accountability for maintaining PCI DSS compliance
• Defining a charter for a PCI DSS compliance program
• Maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities
• Annual PCI DSS assessment(s)
• Continuous validation of PCI DSS requirements
• Managing PCI DSS business-as-usual activities
• Managing PCI DSS business-as-usual activities
• Managing annual PCI DSS assessments
• Managing annual PCI DSS assessments
• Managing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions
• Managing continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. as applicable per requirement)
A3.2 Document and validate PCI DSS scope A3.2.1 Document and confirm the accuracy of PCI DSS scope at least quarterly and upon significant changes to the …
A2.3 Requirement for Service Providers Only: All service providers must provide a secure service offering.
• Overall accountability for maintaining PCI DSS compliance
• Defining a charter for a PCI DSS compliance program
• Maintaining and monitoring overall PCI DSS compliance, including business-as-usual activities
• Annual PCI DSS assessment(s)
• Continuous validation of PCI DSS requirements
• Managing PCI DSS business-as-usual activities
• Managing PCI DSS business-as-usual activities
• Managing annual PCI DSS assessments
• Managing annual PCI DSS assessments
• Managing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions
• Managing continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. as applicable per requirement)
A3.2 Document and validate PCI DSS scope A3.2.1 Document and confirm the accuracy of PCI DSS scope at least quarterly and upon significant changes to the …
Added
p. 129
• The process includes verifying the methods are able to discover clear-text PAN on all types of system components and file formats in use. components in both the in-scope and out-of-scope networks should be included in the data-discovery process. Accuracy can be tested by placing test PANs on a sample of system components and file formats in use and confirming that the data- discovery method detected the test PANs.
• 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 remediating data leaks or process gaps that resulted in the data being outside of the CDE
• Procedures for identifying 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 of the CDE
• Procedures for remediating data leaks or process gaps that resulted in the data being 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 …
Added
p. 132
• Duration (date and time start and end) of the security failure
• Confirmation that all BAU activities (e.g., A3.2.2, A3.2.6, and A3.3.1) are being performed
• Confirming that all BAU activities (e.g., A3.2.2, A3.2.6, and A3.3.1) are being performed
• Documenting how the reviews were completed, including how all BAU activities were verified as being in place
• Collecting documented evidence as required for the annual PCI DSS assessment
• Reviewing and sign-off of results by executive management assigned responsibility for PCI DSS governance
• Retaining records and documentation for at least 12 months, covering all BAU activities Implementing PCI DSS controls into business-as- usual activities is an effective method to ensure security is included as part of normal business operations on an ongoing basis. Therefore, it is important that independent checks are performed to ensure BAU controls are active and working as intended.
• Documenting how the reviews were completed, including how all BAU activities …
• Confirmation that all BAU activities (e.g., A3.2.2, A3.2.6, and A3.3.1) are being performed
• Confirming that all BAU activities (e.g., A3.2.2, A3.2.6, and A3.3.1) are being performed
• Documenting how the reviews were completed, including how all BAU activities were verified as being in place
• Collecting documented evidence as required for the annual PCI DSS assessment
• Reviewing and sign-off of results by executive management assigned responsibility for PCI DSS governance
• Retaining records and documentation for at least 12 months, covering all BAU activities Implementing PCI DSS controls into business-as- usual activities is an effective method to ensure security is included as part of normal business operations on an ongoing basis. Therefore, it is important that independent checks are performed to ensure BAU controls are active and working as intended.
• Documenting how the reviews were completed, including how all BAU activities …
Added
p. 135
• Identification of anomalies or suspicious activity as it occurs
• Response to alerts in accordance with documented response procedures
• Response to alerts in accordance with documented response procedures
Modified
p. 1
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.2
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 3.2.1 Revision 1
Modified
p. 7
• 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. 7
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.
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 CDE.1 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. 8
Requirement 3.4 Account Data Cardholder Primary Account Number (PAN) Yes Yes Cardholder Name Yes No Service Code Yes No Expiration Date Yes No Sensitive Authentication Full Track Data3 No Cannot store per Requirement 3.2 CAV2/CVC2/CVV2/CID4 No Cannot store per Requirement 3.2 PIN/PIN Block5 No Cannot store per Requirement 3.2
Requirement 3.4 Account Data Cardholder Primary Account Number (PAN) Yes Yes Cardholder Name Yes No Service Code Yes No Expiration Date Yes No Sensitive Authentication Full Track Data3 No Cannot store per Requirement 3.2 CAV2/CVC2/CVN2/CVV2/CID4 No Cannot store per Requirement 3.2 PIN/PIN Block5 No Cannot store per Requirement 3.2
Modified
p. 9
Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of PAN, full track data, card verification codes and values (CAV2, CID, CVC2, CVV2), and PINs and PIN blocks, along with the damaging fraud resulting from these breaches.
Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of PAN, full track data, card verification codes and values (CAV2, CVC2, CVN2, CVV2, CID), and PINs and PIN blocks, along with the damaging fraud resulting from these breaches.
Modified
p. 10
• Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE.
Modified
p. 10
• Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.
Modified
p. 10
• Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.
Modified
p. 10
• Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).
Modified
p. 10
• Applications including all purchased and custom applications, including internal and external (for example, Internet) applications.
Modified
p. 10
• Any other component or device located within or connected to the CDE.
Modified
p. 10
• The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined CDE.
Modified
p. 10
• Once all locations of cardholder data are identified and documented, the entity uses the results to verify that PCI DSS scope is appropriate (for example, the results may be a diagram or an inventory of cardholder data locations).
Modified
p. 10
• The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE. If the entity identifies data that is not currently included in the CDE, such data should be securely deleted, migrated into the currently defined CDE, or the CDE redefined to include this data.
Modified
p. 11
• The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations) Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment. Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network. To be considered out of …
Modified
p. 13
• Restoring the security control • Identifying the cause of failure • Identifying and addressing any security issues that arose during the failure of the security control • Implementing mitigation (such as process or technical controls) to prevent the cause of the failure recurring • Resuming monitoring of the security control, perhaps with enhanced monitoring for a period of time, to verify the control is operating effectively
Modified
p. 13
• Determine the potential impact to PCI DSS scope (for example, a new firewall rule that permits connectivity between a system in the CDE and another system could bring additional systems or networks into scope for PCI DSS).
Modified
p. 13
• Identify PCI DSS requirements applicable to systems and networks affected by the changes (for example, if a new system is in scope for PCI DSS, it would need to be configured per system configuration standards, including FIM, AV, patches, audit logging, etc., and would need to be added to the quarterly vulnerability scan schedule).
Modified
p. 13
• Update PCI DSS scope and implement security controls as appropriate.
Modified
p. 14
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.
Modified
p. 15
• If there are standardized, centralized PCI DSS security and operational processes and controls in place that ensure consistency and that each business facility/system component must follow, the sample can be smaller than if there are no standard processes/controls in place. The sample must be large enough to provide the assessor with reasonable assurance that all business facilities/system components are configured per the standard processes. The assessor must verify that the standardized, centralized controls are implemented and working effectively.
Modified
p. 15
• If there is more than one type of standard security and/or operational process in place (for example, for different types of business facilities/system components), the sample must be large enough to include business facilities/system components secured with each type of process.
Modified
p. 15
• If there are no standard PCI DSS processes/controls in place and each business facility/system component is managed through non- standard processes, the sample must be larger for the assessor to be assured that each business facility/system component has implemented PCI DSS requirements appropriately.
Modified
p. 16
• Document and validate the standardized PCI DSS processes and controls used to determine sample size, and
Modified
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.
PCI DSS Versions As of the published date of this document, PCI DSS v3.2 is valid through December 31, 2018, after which it is retired. All PCI DSS validations after this date must be to PCI DSS v3.2.1 or later.
Modified
p. 18
The following table provides a summary of PCI DSS versions and their effective dates6.
The following table provides a summary of PCI DSS versions and their relevant dates.6 Version Published Retired
Removed
p. 19
Testing Procedures
• This column shows processes to be followed by the assessor to validate that PCI DSS requirements have been met and are “in place.” Guidance
• This column describes the intent or security objective behind each of the PCI DSS requirements. This column contains guidance only, and is intended to assist understanding of the intent of each requirement. The guidance in this column does not replace or extend the PCI DSS Requirements and Testing Procedures.
• This column shows processes to be followed by the assessor to validate that PCI DSS requirements have been met and are “in place.” Guidance
• This column describes the intent or security objective behind each of the PCI DSS requirements. This column contains guidance only, and is intended to assist understanding of the intent of each requirement. The guidance in this column does not replace or extend the PCI DSS Requirements and Testing Procedures.
Modified
p. 19
• This column defines the Data Security Standard requirements; PCI DSS compliance is validated against these requirements.
• This column defines the Data Security Standard requirements; PCI DSS compliance is validated against these requirements.
Modified
p. 19
• For instructions on completing reports on compliance (ROC), refer to the PCI DSS ROC Reporting Template.
Modified
p. 19
• For instructions on completing self-assessment questionnaires (SAQ), refer to the PCI DSS SAQ Instructions and Guidelines.
Modified
p. 19
• For instructions on submitting PCI DSS compliance validation reports, refer to the PCI DSS Attestations of Compliance.
Modified
p. 20
• Changes to firewall and router configurations A documented and implemented process for approving and testing all connections and changes to the firewalls and routers will help prevent security problems caused by misconfiguration of the network, router, or firewall.
Modified
p. 21
• Shows all cardholder data flows across systems and networks.
Modified
p. 21
• Is kept current and updated as needed upon changes to the environment.
Modified
p. 27
• Network Address Translation (NAT) • Placing servers containing cardholder data behind proxy servers/firewalls, • Removal or filtering of route advertisements for private networks that employ registered addressing, • Internal use of RFC1918 address space instead of registered addresses.
Modified
p. 28
• 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.
Modified
p. 28
• 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. 28
• Personal firewall (or equivalent functionality) is installed and configured per the organization’s specific configuration settings. • Personal firewall (or equivalent functionality) is actively running. • Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices.
Modified
p. 29
• All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network. • Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled before a system is installed on the network.
Modified
p. 30
• Encryption keys are changed anytime anyone with knowledge of the keys leaves the company or changes positions.
Modified
p. 30
• Default SNMP community strings are required to be changed upon installation.
Modified
p. 30
• Default passwords/passphrases on access points are required to be changed upon installation.
Modified
p. 30
• Default SNMP community strings are not used.
Modified
p. 30
• Default passwords/passphrases on access points are not used.
Modified
p. 30
• Authentication over wireless networks
Modified
p. 31
• International Organization for Standardization (ISO) • SysAdmin Audit Network Security (SANS) Institute • National Institute of Standards Technology (NIST).
Modified
p. 31
• Changing of all vendor-supplied defaults and elimination of unnecessary default accounts • Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server • Enabling only necessary services, protocols, daemons, etc., as required for the function of the system • Implementing additional security features for any required services, protocols or daemons that are considered to be insecure • Configuring system security parameters to prevent misuse • Removing all unnecessary …
Removed
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.
Removed
p. 34
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.
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.
Modified
p. 34
2.3.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography.
PCI DSS Requirements Testing Procedures Guidance 2.3.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography.
Modified
p. 36
• 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. 36
• Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements.
Modified
p. 36
• Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons).
Modified
p. 36
• Processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons.
Modified
p. 36
• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.
Modified
p. 36
• All locations of stored cardholder data are included in the data retention and disposal processes.
Modified
p. 36
• Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data.
Modified
p. 36
• The quarterly automatic or manual process is performed for all locations of cardholder data.
Modified
p. 37
• Examine files and system records to verify that the data stored does not exceed the requirements defined in the data retention policy • Observe the deletion mechanism to verify data is deleted securely.
Modified
p. 37
• There is a business justification and
Modified
p. 38
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.
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:
Modified
p. 39
• 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.
Modified
p. 40
• One-way hashes based on strong cryptography, (hash must be of the entire PAN) • Truncation (hashing cannot be used to replace the truncated segment of PAN) • Index tokens and pads (pads must be securely stored) • Strong cryptography with associated key-management processes and procedures.
Modified
p. 40
• Strong cryptography, with associated key-management processes and procedures.
Modified
p. 41
• Access to keys is restricted to the fewest number of custodians necessary. • Key-encrypting keys are at least as strong as the data- encrypting keys they protect. • Key-encrypting keys are stored separately from data- encrypting keys. • Keys are stored securely in the fewest possible locations and forms.
Modified
p. 42
• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
Modified
p. 42
• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
Removed
p. 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.3.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:
Modified
p. 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
Modified
p. 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 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. 43
• Key-encrypting keys are at least as strong as the data- encrypting keys they protect.
Modified
p. 44
The encryption solution must distribute keys securely, meaning the keys are distributed only to custodians identified in 3.5.1, and are never distributed in the clear. 3.6.2.b Observe the method for distributing keys to verify that keys are distributed securely.
The encryption solution must distribute keys securely, meaning the keys are distributed only to custodians identified in Requirement 3.5.2, and are never distributed in the clear. 3.6.2.b Observe the method for distributing keys to verify that keys are distributed securely.
Modified
p. 45
• The retirement or replacement of keys when the integrity of the key has been weakened.
Modified
p. 45
Keys that are no longer used or needed, or keys that are known or suspected to be compromised, should be revoked and/or destroyed to ensure that the keys can no longer be used. If such keys need to be kept (for example, to support archived, encrypted data) they should be strongly protected.
Modified
p. 45
• Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company.
Modified
p. 45
• Keys are replaced if known or suspected to be compromised.
Modified
p. 45
• Any keys retained after retiring or replacing are not used for encryption operations.
Modified
p. 46
• Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND
Modified
p. 46
• Dual control 3.6.7 Prevention of unauthorized substitution of cryptographic keys.
Modified
p. 47
• The encryption strength is appropriate for the encryption methodology in use.
Modified
p. 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 …
• Only trusted keys and certificates are accepted.
• The protocol in use only supports secure versions or configurations. Examples of open, public networks include but are not limited to: • 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 …
• The protocol in use only supports secure versions or configurations. Examples of open, public networks include but are not limited to: • 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 …
Modified
p. 47
• 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.
Modified
p. 48
• “HTTPS” appears as the browser Universal Record Locator (URL) protocol, and
Modified
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.
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.)
Modified
p. 48
• Industry best practices are used to implement strong encryption for authentication and transmission.
Modified
p. 48
• Weak encryption (for example, WEP, SSL) is not used as a security control for authentication or transmission.
Modified
p. 51
• Generate audit logs which are retained per PCI DSS Requirement 10.7.
Modified
p. 51
• Configured to perform automatic updates, and
Modified
p. 51
• The anti-virus software and definitions are current.
Modified
p. 51
• Logs are retained in accordance with PCI DSS Requirement 10.7.
Modified
p. 53
• To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities. • To use reputable outside sources for security vulnerability information.
Modified
p. 53
• 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. 54
• Installation of applicable critical vendor-supplied security patches within one month of release. • Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months).
Modified
p. 54
• That applicable critical vendor-supplied security patches are installed within one month of release. • All applicable vendor-supplied security patches are installed within an appropriate time frame (for example, within three months).
Modified
p. 54
• In accordance with PCI DSS (for example, secure authentication and logging) • Based on industry standards and/or best practices. • Incorporating information security throughout the software-development life cycle
Modified
p. 55
• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.
Modified
p. 55
• Code reviews ensure code is developed according to secure coding guidelines
Modified
p. 55
• Code-review results are reviewed and approved by management prior to release.
Modified
p. 55
• Code-review results are reviewed and approved by management prior to release.
Modified
p. 55
• Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices.
Modified
p. 55
• Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5).
Modified
p. 55
• Appropriate corrections are implemented prior to release.
Modified
p. 56
• Development/test environments are separate from production environments with access control in place to enforce separation. • A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment. • Production data (live PANs) are not used for testing or development. • Test data and accounts are removed before a production system becomes active. • Change control procedures related to implementing security patches and software modifications are documented.
Modified
p. 58
•such as hardware or software updates and installation of security patches
•might not be fully realized and could have unintended consequences.
• 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. 59
• 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 • New systems are included in the quarterly vulnerability scanning process.
Removed
p. 60
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. 60
PCI DSS Requirements Testing Procedures Guidance 6.5 Address common coding vulnerabilities in software-development processes as follows:
PCI DSS Requirements Testing Procedures Guidance including how to avoid common coding vulnerabilities.
• Develop applications based on secure coding guidelines.
• Develop applications based on secure coding guidelines.
Modified
p. 60
6.5.c Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities: practices as applicable to the particular technology in their environment.
Modified
p. 61 → 60
• Validating input to verify user data cannot modify meaning of commands and queries.
Modified
p. 61 → 60
• Utilizing parameterized queries.
Modified
p. 61
• Validating buffer boundaries.
Modified
p. 61
• Truncating input strings.
Modified
p. 61
• Prevent cryptographic flaws.
Modified
p. 61
• Use strong cryptographic algorithms and keys.
Modified
p. 63
• User interfaces that do not permit access to unauthorized functions.
Modified
p. 64
• Incorporating appropriate time-outs and rotation of session IDs after a successful login.
Modified
p. 64
• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
Modified
p. 64
• 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. 64
•using either manual or automated vulnerability security assessment tools or methods
•as follows:
• Examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed
•using either manual or automated vulnerability security assessment tools or methods
•as follows:
•using either manual or automated vulnerability security assessment tools or methods
•as follows:
Modified
p. 64
Requirement 6.5 are included in the assessment - That all vulnerabilities are corrected - That the application is re-evaluated after the corrections. Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:
Requirement 6.5 are included in the assessment - That all vulnerabilities are corrected - That the application is re-evaluated after the corrections. • Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:
Modified
p. 64
• 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 of this requirement, which is to prevent attacks.
Modified
p. 66
• Defining access needs and privilege assignments for each role • Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities • Assignment of access based on individual personnel’s job classification and function • Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved.
Modified
p. 66
• Level of privilege required (for example, user, administrator, etc.) for accessing resources.
Modified
p. 66
• System components and data resources that each role needs to access for their job function
Modified
p. 66
• Restricted to least privileges necessary to perform job responsibilities.
Modified
p. 67
• Restricted to least privileges necessary to perform job responsibilities.
Modified
p. 67
• That specified privileges match the roles assigned to the individual.
Modified
p. 70
• Enabled only during the time period needed and disabled when not in use.
Modified
p. 70
• Monitored when in use.
Modified
p. 70
• Enabled only when needed by the third party, and disabled when not in use.
Modified
p. 71
• Something you know, such as a password or passphrase • Something you have, such as a token device or smart card • Something you are, such as a biometric.
Modified
p. 71
• Examine documentation describing the authentication method(s) used. • For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s).
Modified
p. 73
• Non-consumer customer users are given guidance as to when, and under what circumstances, passwords/passphrases must change.
Modified
p. 75
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.
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.
Modified
p. 75
• All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).
Modified
p. 76
• Guidance on selecting strong authentication credentials • Guidance for how users should protect their authentication credentials • Instructions not to reuse previously used passwords • Instructions to change passwords if there is any suspicion the password could be compromised.
Modified
p. 76
• Guidance on selecting strong authentication credentials • Guidance for how users should protect their authentication credentials. • Instructions for users not to reuse previously used passwords • Instructions to change passwords if there is any suspicion the password could be compromised.
Modified
p. 76
• Generic user IDs are disabled or removed. • Shared user IDs do not exist for system administration and other critical functions. • Shared and generic user IDs are not used to administer any system components.
Modified
p. 76
• Shared user IDs for system administration activities and other critical functions do not exist. • Shared and generic user IDs are not used to administer any system components.
Modified
p. 77
• Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. • Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
Modified
p. 77
• Authentication mechanisms are assigned to an individual account and not shared among multiple accounts. • Physical and/or logical controls are defined to ensure only the intended account can use that mechanism to gain access.
Modified
p. 78
• All user access to, user queries of, and user actions on databases are through programmatic methods. • Only database administrators have the ability to directly access or query databases. • Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
Modified
p. 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 data environment and verify that they are “locked” to prevent unauthorized use.
Modified
p. 81
• Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).
Modified
p. 81
• Verify procedures include the following:
Modified
p. 81
• 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. 81
• It is easy to distinguish between onsite personnel and visitors.
Modified
p. 81
• Access must be authorized and based on individual job function. • Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.
Modified
p. 81
• Access is required for the individual’s job function.
Modified
p. 82
• The onsite personnel authorizing physical access.
Modified
p. 84
• 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. 85
• Training personnel to be aware of suspicious behavior and to report tampering or substitution of devices.
Modified
p. 85
• Location of device (for example, the address of the site or facility where the device is located)
Modified
p. 85
• Location of device (for example, the address of the site or facility where the device is located)
Modified
p. 86
• Procedures for inspecting devices
Modified
p. 86
• Personnel are aware of procedures for inspecting devices.
Modified
p. 86
• All devices are periodically inspected for evidence of tampering and substitution.
Modified
p. 87
• Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.
Modified
p. 87
• Do not install, replace, or return devices without verification.
Modified
p. 87
• Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
Modified
p. 87
• Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).
Modified
p. 87
• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices • Not to install, replace, or return devices without verification • Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices) • Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).
Modified
p. 87
• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices • Not to install, replace, or return devices without verification • Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices) • Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).
Modified
p. 88
• Audit trails are enabled and active for system components.
Modified
p. 89
• Stopping or pausing of audit logs.
Modified
p. 90
• Only the designated central time server(s) receives time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.
Modified
p. 90
• Where there is more than one designated time server, the time servers peer with one another to keep accurate time,
Modified
p. 91
• Only the designated central time server(s) receives time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.
Modified
p. 91
• Where there is more than one designated time server, the designated central time server(s) peer with one another to keep accurate time.
Modified
p. 91
• Systems receive time only from designated central time server(s).
Modified
p. 93
• 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. 93
• 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. 93
• 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.
Removed
p. 94
Firewalls IDS/IPS FIM Anti-virus Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used)
Modified
p. 94
• Procedures for retaining audit logs for at least one year, with a minimum of three months immediately available online.
Modified
p. 94
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:
• 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:
Modified
p. 94
• Physical access controls • Logical access controls • Audit logging mechanisms • Physical access controls
• Logical access controls
• Audit logging mechanisms
• Segmentation controls (if used)
• Logical access controls
• Audit logging mechanisms
• Segmentation controls (if used)
Removed
p. 95
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 Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
Modified
p. 95
10.8.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:
• Resuming monitoring of security controls 10.8.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:
Modified
p. 95
• 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 • …
Modified
p. 95
• Details of the remediation required to address the root cause 10.9 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.
Modified
p. 96
• Portable or mobile devices attached to system components to create a wireless access point (for example, by USB, etc.)
Modified
p. 96
• The scan is performed at least quarterly for all system components and facilities.
Modified
p. 98
• Internal and external scanning as needed after significant changes Once these weaknesses are identified, the entity corrects them and repeats the scan until all vulnerabilities have been corrected.
Modified
p. 99
• For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.
Modified
p. 99
• For internal scans, all “high risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.
Modified
p. 100
• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115) • Includes coverage for the entire CDE perimeter and critical systems • Includes 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. 100
• 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. 101
• After any significant changes to the environment.
Modified
p. 101
• After any significant changes to the environment.
Modified
p. 102
• Penetration testing to verify segmentation controls is performed at least annually and after any changes to segmentation controls/methods.
Modified
p. 102
• Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.
Modified
p. 103
• At critical points in the cardholder data environment.
Modified
p. 103
• Additional critical files determined by entity (for example, through risk assessment or other means).
Modified
p. 105
• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),
Modified
p. 105
• 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. 106
• A list of personnel authorized to use the devices.
Removed
p. 108
Overall accountability for maintaining PCI DSS compliance Defining a charter for a PCI DSS compliance program and communication to executive management
Modified
p. 108
• Overall accountability for maintaining PCI DSS compliance
Modified
p. 109
• The formal assignment of information security to a Chief Security Officer or other security-knowledgeable member of management.
Modified
p. 109
• The following information security responsibilities are specifically and formally assigned:
Modified
p. 113
• Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum • Specific incident response procedures • Business recovery and continuity procedures • Data backup processes • Analysis of legal requirements for reporting compromises • Coverage and responses of all critical system components • Reference or inclusion of incident response procedures from the payment brands.
Modified
p. 113
• Analysis of legal requirements for reporting compromises (for example, California Bill 1386, which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database)
Removed
p. 114
Daily log reviews Firewall rule-set reviews Applying configuration standards to new Responding to security alerts Change management processes
Modified
p. 114
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:
• 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:
Modified
p. 114
• Firewall rule-set reviews • Applying configuration standards to new
• Responding to security alerts
• Firewall rule-set reviews
• Applying configuration standards to new systems • Responding to security alerts • Change management processes
• Responding to security alerts
• Firewall rule-set reviews
• Applying configuration standards to new systems • Responding to security alerts • Change management processes
Modified
p. 114
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.
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.
Removed
p. 115
• for example, audit logs, vulnerability scan reports, firewall reviews, etc.
Modified
p. 115
• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program
Modified
p. 115
• Documenting results of the reviews • Documenting results of the reviews
Modified
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
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.
Modified
p. 116
• Appendix A3: Designated Entities Supplemental Validation Guidance and applicability information is provided within each section.
Modified
p. 117
• No entity on the system can use a shared web server user ID.
Modified
p. 117
• All CGI scripts used by an entity must be created and run as the entity’s unique user ID.
Modified
p. 118
• 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. 118
• Logs are enabled for common third-party applications.
Modified
p. 118
• Logs are active by default.
Modified
p. 118
• Logs are available for review by the owning entity.
Modified
p. 118
• Log locations are clearly communicated to the owning entity.
Removed
p. 119
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).
POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after June 30, 2018.
This Appendix applies to entities using SSL/early TLS as a security control to protect the CDE and/or CHD (for example, SSL/early TLS used to meet PCI DSS Requirement 2.2.3, 2.3, or 4.1), Refer to the current PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.
POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after June 30, 2018.
This Appendix applies to entities using SSL/early TLS as a security control to protect the CDE and/or CHD (for example, SSL/early TLS used to meet PCI DSS Requirement 2.2.3, 2.3, or 4.1), Refer to the current PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.
Modified
p. 119
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:
SSL and early TLS must not be used as a security control to meet these requirements, except in the case of POS POI terminal connections as detailed in this appendix. To support entities working to migrate away from SSL/early TLS on POS POI terminals, the following provisions are included:
Modified
p. 119
• New POS POI terminal implementations must not use SSL or early TLS as a security control.
Modified
p. 119
• All POS POI terminal service providers must provide a secure service offering.
Modified
p. 119
• Service providers supporting existing POS POI terminal implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
Removed
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:
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 is susceptible to known exploits, then planning for migration to a secure alternative should commence immediately.
A2.2 Entities with existing implementations (other than as allowed in A2.1) that …
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:
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 is susceptible to known exploits, then planning for migration to a secure alternative should commence immediately.
A2.2 Entities with existing implementations (other than as allowed in A2.1) that …
Modified
p. 120
A2.1 For POS POI terminals 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.
Modified
p. 120
Note: The allowance for POS POIs that are not currently susceptible to exploits is based on current, known risks. If new exploits are introduced for which POI environments are susceptible, the POI environments will need to be updated.
Note: The allowance for POS POI terminals that are not currently susceptible to exploits is based on current, known risks. If new exploits are introduced to which POS POI terminals are susceptible, the POS POI terminals will need to be updated immediately.
Modified
p. 120 → 121
• 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 to replace SSL/early TLS at a future date. POS POI …
Modified
p. 120 → 121
Refer to the current PCI SSC Information Supplement Migrating from SSL and Early TLS for further guidance on Risk Mitigation and Migration Plans.
Refer to the current PCI SSC Information Supplements on SSL/early TLS for further guidance on Risk Mitigation and Migration Plans.
Removed
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.
Refer to "Service Providers” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for further guidance.
Refer to "Service Providers” in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for further guidance.
Modified
p. 122 → 121
Service providers supporting SSL/early TLS connections for POS POI terminals should also provide a secure protocol option. Refer to the current PCI SSC Information Supplements on SSL/Early TLS for further guidance.
• 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.
• 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.
Modified
p. 123
• Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least annually
Modified
p. 123
• A process for performing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions PCI DSS Reference: Requirements 1-12 A3.1.2.a Examine information security policies and procedures to verify that processes are specifically defined for the following:
Modified
p. 123
• 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 requirements (for example: daily, weekly, quarterly, etc. as applicable per requirement)
• 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 A formal compliance program allows an …
• Annual PCI DSS assessment processes
• Processes for the continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. as applicable per requirement)
• 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 A formal compliance program allows an …
Modified
p. 124
• 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).
Modified
p. 124
• Managing continuous validation of PCI DSS requirements (for example: daily, weekly, quarterly, etc. as applicable per requirement)
Modified
p. 124
• Managing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions The formal definition of specific PCI DSS compliance roles and responsibilities helps to ensure accountability and monitoring of ongoing PCI DSS compliance efforts. These roles may be assigned to a single owner or multiple owners for different aspects. Ownership should be assigned to individuals with the authority to make risk- based decisions and upon whom accountability rests for the specific function. Duties should be formally defined …
Modified
p. 126 → 125
• 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.
Modified
p. 126
• Identification of all out-of-scope networks and justification for networks being out of scope, including descriptions of all segmentation controls implemented
Modified
p. 126
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:
PCI DSS Reference: Scope of PCI DSS Requirements A3.2.1.b Examine documented results of quarterly scope reviews to verify the following is performed:
Modified
p. 126
• Identification of all connected entities
•e.g., third- party entities with access to the CDE A3.2.2 Determine PCI DSS scope impact for all changes to systems or networks, including additions of new systems and new network connections. Processes must include:
•e.g., third- party entities with access to the CDE A3.2.2 Determine PCI DSS scope impact for all changes to systems or networks, including additions of new systems and new network connections. Processes must include:
Modified
p. 126
• Documented sign-off of the results of the impact assessment by responsible personnel (as defined in A3.1.3)
Modified
p. 126
• A formal PCI DSS impact assessment was performed.
Modified
p. 126
• PCI DSS requirements applicable to the system or network changes were identified.
Modified
p. 126
• PCI DSS scope was updated as appropriate for the change.
Modified
p. 126
• Sign-off by responsible personnel (as defined in A3.1.3) was obtained and documented.
Modified
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.
•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.
Modified
p. 128
• Penetration testing is performed to verify segmentation controls at least every six months and after any changes to segmentation controls/methods.
Removed
p. 129
The entity has a process in place to test the effectiveness of methods used for data discovery. The process includes verifying the methods are able to discover clear-text PAN on all types of system components and file formats in use.
A process to test the effectiveness of the methods used for data discovery ensures the completeness and accuracy of cardholder data detection. For completeness, at least a sampling of system components in both the in-scope and out-of-scope networks should be included in the data-discovery process. Accuracy can be tested by placing test PANs on a sample of system components and file formats in use and confirming that the data- discovery method detected the test PANs. A3.2.5.1.b Examine the results of recent effectiveness tests to verify the effectiveness of methods used for data discovery is confirmed at least annually.
A process to test the effectiveness of the methods used for data discovery ensures the completeness and accuracy of cardholder data detection. For completeness, at least a sampling of system components in both the in-scope and out-of-scope networks should be included in the data-discovery process. Accuracy can be tested by placing test PANs on a sample of system components and file formats in use and confirming that the data- discovery method detected the test PANs. A3.2.5.1.b Examine the results of recent effectiveness tests to verify the effectiveness of methods used for data discovery is confirmed at least annually.
Modified
p. 129 → 128
• Data-discovery methodology includes processes for identifying all sources and locations of clear-text PAN.
Modified
p. 129 → 128
• Methodology takes into consideration the potential for clear-text PAN to reside on systems and networks outside of the currently defined CDE.
Modified
p. 129 → 128
A3.2.5.1 Ensure effectiveness of methods used for data discovery
•e.g., methods must be able to discover clear-text PAN on all types of system components (forexample, on each operating system or platform) and file formats in use.
•e.g., methods must be able to discover clear-text PAN on all types of system components (for
A3.2.5.1 Ensure effectiveness of methods used for data discovery
•e.g., methods must be able to discover clear-text PAN on all types of system components (for A3.2.5.1.a Interview personnel and review documentation to verify:
•e.g., methods must be able to discover clear-text PAN on all types of system components (for A3.2.5.1.a Interview personnel and review documentation to verify:
Modified
p. 129
PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.1.a Interview personnel and review documentation to verify:
PCI DSS Reference: Scope of PCI DSS Requirements
Removed
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 …
Removed
p. 131
Firewalls Anti-virus Physical access controls Logical access controls Audit logging mechanisms Segmentation controls (if used)
PCI DSS Reference: Requirements 1-12 A3.3.1.a Examine documented policies and procedures to verify that processes are defined to immediately detect and alert on critical security control failures.
Without formal processes for the prompt (as soon as possible) detection and alerting of critical security control failures, failures may go undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.
PCI DSS Reference: Requirements 1-12 A3.3.1.a Examine documented policies and procedures to verify that processes are defined to immediately detect and alert on critical security control failures.
Without formal processes for the prompt (as soon as possible) detection and alerting of critical security control failures, failures may go undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.
Modified
p. 131 → 130
• 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:
Modified
p. 131 → 130
• 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 …
Modified
p. 131 → 130
A3.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities A3.3.1 Implement a process to immediately detect and alert on critical security control failures. Examples of critical security controls include, but are not limited to:
A3.3 Validate PCI DSS is incorporated into business-as-usual (BAU) activities A3.3.1 Implement a process to immediately detect and alert on critical security control A3.3.1.a Examine documented policies and procedures to verify that processes are defined to immediately detect and alert on critical security control failures.
Modified
p. 131
A3.3.1.b Examine detection and alerting processes and interview personnel to verify that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert.
PCI DSS Reference: Requirements 1-12 A3.3.1.b Examine detection and alerting processes and interview personnel to verify that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert. undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.
Modified
p. 132 → 131
• 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 • …
Removed
p. 134
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
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 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 Collecting documented evidence as required for the annual PCI DSS assessment Reviewing and sign-off of results by executive management assigned responsibility for PCI DSS governance Retaining records and documentation for at least 12 months, covering all BAU activities Implementing PCI DSS controls into …
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 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 Collecting documented evidence as required for the annual PCI DSS assessment Reviewing and sign-off of results by executive management assigned responsibility for PCI DSS governance Retaining records and documentation for at least 12 months, covering all BAU activities Implementing PCI DSS controls into …
Modified
p. 134 → 133
• Confirming that personnel are following security policies and operational procedures (for example, daily log reviews, firewall rule-set reviews, configuration standards for new systems, etc.)
Modified
p. 134 → 133
• Confirmation that personnel are following security policies and operational procedures (for example, daily log reviews, firewall rule-set reviews, A3.3.3.a Examine policies and procedures to verify that processes are defined for reviewing and verifying BAU activities. Verify the procedures include:
Modified
p. 134
A3.3.3.b Interview responsible personnel and examine records of reviews to verify that:
PCI DSS Reference: Requirements 1-12 A3.3.3.b Interview responsible personnel and examine records of reviews to verify that:
Modified
p. 134
• Reviews are performed by personnel assigned to the PCI DSS compliance program.
Modified
p. 134
• Reviews are performed at least quarterly.
Modified
p. 135 → 134
• User accounts and access privileges are reviewed at least every six months.
Modified
p. 135 → 134
• Reviews confirm that access is appropriate based on job function, and that all access is authorized.
Modified
p. 135 → 134
A3.5.1.a Review documentation and interview personnel to verify a methodology is defined and implemented to identify attack patterns and undesirable behavior across systems in a timely manner, and includes the following:
Modified
p. 135
• Issuance of timely alerts upon detection of suspicious activity or anomaly to responsible personnel
Modified
p. 135
• Response to alerts in accordance with documented response procedures difficult, if not impossible, without a process to corroborate information from critical system components, and systems that perform security functions
•such as firewalls, IDS/IPS, and file- integrity monitoring (FIM) systems. Thus, logs for all critical systems components and systems that perform security functions should be collected, correlated, and maintained. This could include the use of software products and service methodologies to provide real-time analysis, alerting, and reporting
•such as security information and …
•such as firewalls, IDS/IPS, and file- integrity monitoring (FIM) systems. Thus, logs for all critical systems components and systems that perform security functions should be collected, correlated, and maintained. This could include the use of software products and service methodologies to provide real-time analysis, alerting, and reporting
•such as security information and …
Modified
p. 135
• On-call personnel receive timely alerts.
Modified
p. 135
• Alerts are responded to per documented response procedures.
Removed
p. 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, 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 intent of the original requirement by addressing the risk of intercepting clear-text administrative passwords; and (2) it is set up properly and in a secure environment.
Modified
p. 136
2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See Navigating PCI DSS for the intent of each PCI DSS requirement.)
2. Provide a similar level of defense as the original PCI DSS requirement, such that the compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against. (See Guidance Column for the intent of each PCI DSS requirement.)
Modified
p. 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) multi-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) one-time passwords.