Document Comparison
Prioritized-Approach-for-PCI-DSS-v3_2_1.pdf
→
Prioritized_Approach_for_PCI_DSS_3.2.1r1.pdf
97% similar
24 → 24
Pages
11341 → 11584
Words
51
Content Changes
Content Changes
51 content changes. 3 administrative changes (dates, page numbers) hidden.
Modified
p. 2
PCI SSC FOUNDERS PARTICIPATING ORGANIZATIONS Merchants, banks, processors, developers and point of sale
PCI SSC PARTICIPATING PAYMENT BRANDS PARTICIPATING ORGANIZATIONS Merchants, banks, processors, developers and point of sale vendors
Modified
p. 3
PCI DSS Requirements v3.2.1 1 2 3 4 5 6
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6
Modified
p. 3
(For example, block traffic originating from the Internet with an internal source address.) 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
(For example, block traffic originating from the Internet with an internal source address.) 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet. 2 1.3.5 Permit only “established” connections into the network. 2
Removed
p. 4
y Specific configuration settings are defined.
y Personal firewall (or equivalent functionality) is actively running.
y Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices.
y Center for Internet Security (CIS) y International Organization for Standardization (ISO) y SysAdmin Audit Network Security (SANS) Institute y National Institute of Standards Technology (NIST).
y Personal firewall (or equivalent functionality) is actively running.
y Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices.
y Center for Internet Security (CIS) y International Organization for Standardization (ISO) y SysAdmin Audit Network Security (SANS) Institute y National Institute of Standards Technology (NIST).
Modified
p. 4
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks. 2 1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties.
Modified
p. 4
Note: Methods to obscure IP addressing may include, but are not limited to: y Network Address Translation (NAT) y Placing servers containing cardholder data behind proxy servers/firewalls, y Removal or filtering of route advertisements for private networks that employ registered addressing, y Internal use of RFC1918 address space instead of registered addresses.
Modified
p. 4
Sources of industry-accepted system hardening standards may include, but are not limited to:
Sources of industry-accepted system hardening standards may include, but are not limited to: y Center for Internet Security (CIS) y International Organization for Standardization (ISO) y SysAdmin Audit Network Security (SANS) Institute y National Institute of Standards Technology (NIST).
Removed
p. 5
y Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements y Specific retention requirements for cardholder data y Processes for secure deletion of data when no longer needed y A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.
y There is a business justification and y The data is stored securely.
y There is a business justification and y The data is stored securely.
Modified
p. 5
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
Modified
p. 5
Requirement 3: Protect stored cardholder data 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:
Requirement 3: Protect stored cardholder data 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage: y Limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements y Specific retention requirements for cardholder data y Processes for secure deletion of data when no longer needed y A quarterly process for identifying and …
Modified
p. 5
It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:
It is permissible for issuers and companies that support issuing services to store sensitive authentication data if: y There is a business justification and y The data is stored securely.
Removed
p. 6
y The cardholder’s name y Primary account number (PAN) y Expiration date y Service code To minimize risk, store only these data elements as needed for business.
y One-way hashes based on strong cryptography, (hash must be of the entire PAN) y Truncation (hashing cannot be used to replace the truncated segment of PAN) y Index tokens and pads (pads must be securely stored) y Strong cryptography with associated key-management processes and procedures.
y One-way hashes based on strong cryptography, (hash must be of the entire PAN) y Truncation (hashing cannot be used to replace the truncated segment of PAN) y Index tokens and pads (pads must be securely stored) y Strong cryptography with associated key-management processes and procedures.
Modified
p. 6
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.
Modified
p. 6
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:
Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: y The cardholder’s name y Primary account number (PAN) y Expiration date y Service code To minimize risk, store only these data elements as needed for business.
Modified
p. 7
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes: y Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date y Description of the key usage for each key. y Inventory of any HSMs and other SCDs used for key management 3.5.2 Restrict access to cryptographic keys to the …
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes: y Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date y Description of the key usage for each key. y Inventory of any HSMs and other SCDs used for key management 3.5.2 Restrict access to cryptographic keys to the fewest number …
Removed
p. 8
y Only trusted keys and certificates are accepted.
y The protocol in use only supports secure versions or configurations.
y The encryption strength is appropriate for the encryption methodology in use.
y Satellite communications.
y The protocol in use only supports secure versions or configurations.
y The encryption strength is appropriate for the encryption methodology in use.
y Satellite communications.
Modified
p. 8
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.
Modified
p. 8
Requirement 4: Encrypt transmission of cardholder data across open, public networks 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
Requirement 4: Encrypt transmission of cardholder data across open, public networks 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following: y Only trusted keys and certificates are accepted. y The protocol in use only supports secure versions or configurations. y The encryption strength is appropriate for the encryption methodology in use.
Modified
p. 8
Examples of open, public networks include but are not limited to: y The Internet y Wireless technologies, including 802.11 and Bluetooth y Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA) y General Packet Radio Service (GPRS). y Satellite communications.
Modified
p. 8
Requirement 5: Use and regularly update anti-virus software or programs 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).
Requirement 5: Use and regularly update anti-virus software or programs 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). 2 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. 2 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not …
Removed
p. 9
y Are kept current, y Perform periodic scans y Generate audit logs which are retained per PCI DSS Requirement 10.7.
y In accordance with PCI DSS (for example, secure authentication and logging) y Based on industry standards and/or best practices.
y Incorporating information security throughout the software-development life cycle
y In accordance with PCI DSS (for example, secure authentication and logging) y Based on industry standards and/or best practices.
y Incorporating information security throughout the software-development life cycle
Modified
p. 9
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 5.2 Ensure that all anti-virus mechanisms are maintained as follows:
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 5.2 Ensure that all anti-virus mechanisms are maintained as follows: y Are kept current, y Perform periodic scans y Generate audit logs which are retained per PCI DSS Requirement 10.7.
Removed
p. 10
y Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities.
y Develop applications based on secure coding guidelines.
y Develop applications based on secure coding guidelines.
Modified
p. 10
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: y Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices. y Code reviews ensure code is developed according to secure coding guidelines …
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: y Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices. y Code reviews ensure code is developed according to secure coding guidelines y Appropriate …
Removed
p. 11
y Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
y 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.
y 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. 11
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. 3 6.5.2 Buffer overflows 3 6.5.3 Insecure cryptographic storage 3 6.5.4 Insecure communications 3 6.5.5 Improper error handling 3 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1). 3
Modified
p. 11
Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.
Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2. y 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. 12
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 7.1.4 Require documented approval by authorized parties specifying required privileges.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 7.1.4 Require documented approval by authorized parties specifying required privileges. 4 7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
Removed
p. 13
y Require a minimum length of at least seven characters.
y Contain both numeric and alphabetic characters.
y Generic user IDs are disabled or removed.
y Shared user IDs do not exist for system administration and other critical functions.
y Shared and generic user IDs are not used to administer any system components.
y Contain both numeric and alphabetic characters.
y Generic user IDs are disabled or removed.
y Shared user IDs do not exist for system administration and other critical functions.
y Shared and generic user IDs are not used to administer any system components.
Modified
p. 13
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 8.2.3 Passwords/passphrases must meet the following:
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 8.2.3 Passwords/passphrases must meet the following: y Require a minimum length of at least seven characters. y Contain both numeric and alphabetic characters.
Removed
p. 14
y Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
y Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
y All user access to, user queries of, and user actions on databases are through programmatic methods.
y Only database administrators have the ability to directly access or query databases.
y Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
y Identifying onsite personnel and visitors (for example, assigning badges) y Changes to access requirements y Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).
y Access must be authorized and based on individual job function.
y Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, …
y Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
y All user access to, user queries of, and user actions on databases are through programmatic methods.
y Only database administrators have the ability to directly access or query databases.
y Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).
y Identifying onsite personnel and visitors (for example, assigning badges) y Changes to access requirements y Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).
y Access must be authorized and based on individual job function.
y Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, …
Modified
p. 14
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows: y Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. y Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
Modified
p. 14
Requirement 9: Restrict physical access to cardholder data 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.
Requirement 9: Restrict physical access to cardholder data 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. 2 9.1.1 Use either video cameras or access control mechanisms (or both) to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.
Removed
p. 15
y Make, model of device y Location of device (for example, the address of the site or facility where the device is located) y Device serial number or other method of unique identification.
Modified
p. 15
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 9.4 Implement procedures to identify and authorize visitors.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 9.4 Implement procedures to identify and authorize visitors.
Removed
p. 16
y 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.
y Do not install, replace, or return devices without verification.
y Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
y Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).
y Do not install, replace, or return devices without verification.
y Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
y Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).
Modified
p. 16
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).
Modified
p. 17
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
Removed
p. 18
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 10.8 Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:
y Firewalls y IDS/IPS y Anti-virus y Physical access controls y Logical access controls y Audit logging mechanisms y Segmentation controls (if used) 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:
y Firewalls y IDS/IPS y Anti-virus y Physical access controls y Logical access controls y Audit logging mechanisms y Segmentation controls (if used) 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:
Modified
p. 18
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 10.8 Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of: y Firewalls y Anti-virus y Physical access controls y Logical access controls y Audit logging mechanisms y Segmentation controls (if used) 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely …
Modified
p. 19
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
Removed
p. 20
y Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.), y Identifies critical assets, threats, and vulnerabilities, and y Results in a formal, documented analysis of risk.
Modified
p. 20
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
Modified
p. 20
Requirement 12: Maintain a policy that addresses information security for all personnel 12.1 Establish, publish, maintain, and disseminate a security policy. 6 12.1.1 Review the security policy at least annually and update the policy when the environment changes.
Requirement 12: Maintain a policy that addresses information security for all personnel 12.1 Establish, publish, maintain, and disseminate a security policy. 6 12.1.1 Review the security policy at least annually and update the policy when the environment changes. 6 12.2 Implement a risk-assessment process that: y Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.), y Identifies critical assets, threats, and vulnerabilities, and y Results in a formal, documented analysis of …
Removed
p. 21
y Overall accountability for maintaining PCI DSS compliance y Defining a charter for a PCI DSS compliance program and communication to executive management 12.5 Assign to an individual or team the following information security management responsibilities:
Modified
p. 21
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 12.3 Develop usage policies for critical technologies and define proper use of these technologies.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 12.3 Develop usage policies for critical technologies and define proper use of these technologies.
Modified
p. 22
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 12.6 Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures.
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 12.6 Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures. 6 12.6.1 Educate personnel upon hire and at least annually.
Removed
p. 23
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 12.10.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:
Modified
p. 23
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 12.10.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum: y Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum y Specific incident response procedures y Business recovery and continuity procedures y Data backup processes y Analysis of legal requirements for reporting …
Modified
p. 24
PCI DSS Requirements v3.2.1 1 2 3 4 5 6 A1.1 Ensure that each entity only runs processes that have access to that entity’s cardholder data environment. A1.2 Restrict each entity’s access and privileges to its own cardholder data environment only. 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. A1.4 Enable processes to provide for timely forensic investigation in the event of a compromise to …
PCI DSS Requirements v3.2.1 Milestone 1 2 3 4 5 6 A1.1 Ensure that each entity only runs processes that have access to that entity’s cardholder data environment. 3 A1.2 Restrict each entity’s access and privileges to its own cardholder data environment only. 3 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. 3 A1.4 Enable processes to provide for timely forensic investigation in the event …
Modified
p. 24
A2.3 Requirement for Service Providers Only: All service providers must provide a secure service offering.
A2.3 Requirement for Service Providers Only: All service providers must provide a secure service offering. 2