Document Comparison
PCI_Security_Assessment_Procedures_v1-2.pdf
→
pci_dss_v1-2.pdf
98% similar
73 → 74
Pages
22864 → 23136
Words
100
Content Changes
Content Changes
100 content changes. 30 administrative changes (dates, page numbers) hidden.
Added
p. 6
PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.
Added
p. 10
Describe the entity’s payment card business, including: - Their business role with payment cards, which is how and why they store, process, and/or transmit cardholder data Note: This is not intended to be a cut-and-paste from the entity’s web site, but should be a tailored description that shows the assessor understands payment and the entity’s role. - How they process payment (directly, indirectly, etc.) - What types of payment channels they serve, such as card-not-present, (for example, mail-order-telephone-order (MOTO), e- Commerce), or card-present - Any entities that they connect to for payment transmission or processing, including processor relationships A high-level network diagram (either obtained from the entity or created by assessor) of the entity’s networking topography that includes: - Connections into and out of the network - Critical components within the cardholder data environment, including POS devices, systems, databases, and web servers, as applicable - Other necessary payment …
Modified
p. 1
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 1.2
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 1.2.1
Modified
p. 5 → 6
PCI DSS Req. 3.4 Cardholder Data Primary Account Number (PAN) Yes Yes Yes Cardholder Name 1 Yes Yes 1 No Service Code 1 Yes Yes 1 No Expiration Date 1 Yes Yes 1 No Sensitive Authentication Full Magnetic Stripe Data 3 No N/A N/A CAV2/CVC2/CVV2/CID No N/A N/A PIN/PIN Block No N/A N/A 1 These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the …
PCI DSS Req. 3.4 Cardholder Data Primary Account Number (PAN) Yes Yes Yes Cardholder Name 1 Yes Yes 1 No Service Code 1 Yes Yes 1 No Expiration Date 1 Yes Yes 1 No Authentication Full Magnetic Stripe Data 3 No N/A N/A CAV2/CVC2/CVV2/CID No N/A N/A PIN/PIN Block No N/A N/A 1 These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the cardholder …
Modified
p. 6 → 7
Network Segmentation Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of the corporate network is not a PCI DSS requirement. However, it is recommended as a method that may reduce: 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 risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations) Without …
Removed
p. 8
If there are standard, required PCI DSS processes in place that each facility must follow, the sample can be smaller than is necessary if there are no standard processes, to provide reasonable assurance that each facility is configured per the standard process.
If there is more than one type of standard process in place (for example, for different types of system components or facilities), then the sample must be large enough to include system components or facilities secured with each type of process.
If there are no standard PCI DSS processes in place and each facility is responsible for their processes, then sample size must be larger to be assured that each facility understands and implements PCI DSS requirements appropriately.
If there is more than one type of standard process in place (for example, for different types of system components or facilities), then the sample must be large enough to include system components or facilities secured with each type of process.
If there are no standard PCI DSS processes in place and each facility is responsible for their processes, then sample size must be larger to be assured that each facility understands and implements PCI DSS requirements appropriately.
Removed
p. 9
Describe the entity’s payment card business, including:
- Any entities that they connect to for payment transmission or processing, including processor relationships A high-level network diagram (either obtained from the entity or created by assessor) of the entity’s networking topography that includes:
- Any entities that they connect to for payment transmission or processing, including processor relationships A high-level network diagram (either obtained from the entity or created by assessor) of the entity’s networking topography that includes:
Removed
p. 10
Environment on which assessment focused (for example, client’s Internet access points, internal corporate network, processing connections) If network segmentation is in place and was used to reduce scope of the PCI DSS review, briefly explain that segmentation and how assessor validated the effectiveness of the segmentation Document and justify sampling used for both entities (stores, facilities, etc.) and system components selected, including:
A diagram of each piece of the communication link, including LAN, WAN or Internet Description of cardholder data environment, for example:
A diagram of each piece of the communication link, including LAN, WAN or Internet Description of cardholder data environment, for example:
Modified
p. 10 → 11
- Describe any locations or environments that store, process, or transmit cardholder data that were EXCLUDED from the scope of the review, and why these locations/environments were excluded List any wholly-owned entities that require compliance with the PCI DSS, and whether they are reviewed separately or as part of this assessment List any International entities that require compliance with the PCI DSS, and whether they are reviewed separately or as part of this assessment List any wireless …
Environment on which assessment focused (for example, client’s Internet access points, internal corporate network, processing connections) If network segmentation is in place and was used to reduce scope of the PCI DSS review, briefly explain that segmentation and how assessor validated the effectiveness of the segmentation Document and justify sampling used for both entities (stores, facilities, etc.) and system components selected, including: - Total population - Number sampled - Rationale for sample selected - Why sample size …
Removed
p. 11
List of individuals interviewed and their titles List of documentation reviewed For managed service provider (MSP) reviews, the assessor must clearly identify which requirements in this document apply to the MSP (and are included in the review), and which are not included in the review and are the responsibility of the MSP’s customers to include in their reviews. Include information about which of the MSP’s IP addresses are scanned as part of the MSP’s quarterly vulnerability scans, and which IP addresses are the responsibility of the MSP’s customers to include in their own quarterly scans.
4. Contact Information and Report Date Contact information for merchant or service provider and assessor Date of report
4. Contact Information and Report Date Contact information for merchant or service provider and assessor Date of report
Modified
p. 11 → 12
• How access to data stores are logged List of hardware and critical software in use in the cardholder data environment, along with description of function/use for each List of service providers and other entities with which the company shares cardholder data (Note: these entities are subject to PCI DSS Requirement 12.8) List of third-party payment application products and versions numbers in use, including whether each payment application has been validated according to PA-DSS. Even if a …
Modified
p. 11 → 12
5. Quarterly Scan Results Summarize the four most recent quarterly scan results in the Executive Summary as well as in comments at Requirement 11.2
5. Quarterly Scan Results Summarize the four most recent quarterly scan results in the Executive Summary as well as in comments at Requirement 11.2
Modified
p. 12 → 13
6. Findings and Observations Summarize in the Executive Summary any findings that may not fit into the standard Report on Compliance template format. All assessors must use the Detailed PCI DSS Requirements and Security Assessment Procedures template to provide detailed report descriptions and findings on each requirement and sub-requirement. The assessor must review and document any compensating controls considered to conclude that a control is in place.
6. Findings and Observations Summarize in the Executive Summary any findings that may not fit into the standard Report on Compliance template format. All assessors must use the Detailed PCI DSS Requirements and Security Assessment Procedures template to provide detailed report descriptions and findings on each requirement and sub-requirement. The assessor must review and document any compensating controls considered to conclude that a control is in place.
Modified
p. 13 → 14
• This column defines the Data Security Standard and lists requirements to achieve PCI DSS compliance; compliance will be validated against these requirements.
PCI DSS Requirements
• This column defines the Data Security Standard and lists requirements to achieve PCI DSS compliance; compliance will be validated against these requirements.
• This column defines the Data Security Standard and lists requirements to achieve PCI DSS compliance; compliance will be validated against these requirements.
Modified
p. 13 → 14
• This column shows processes to be followed by the assessor to validate that PCI DSS requirements are “in place”
• This column must be used by the assessor to provide a brief description of controls found in place, including those controls found to be in place as a result of compensating controls. (Note: that this column must not be used for items that are not yet in place or for open items to be completed …
Testing Procedures
• This column shows processes to be followed by the assessor to validate that PCI DSS requirements are “in place” In Place
• This column must be used by the assessor to provide a brief description of controls found in place, including those controls found to be in place as a result of compensating controls. (Note: that this column must not be used for items that are not yet in place or for open items to be completed …
• This column shows processes to be followed by the assessor to validate that PCI DSS requirements are “in place” In Place
• This column must be used by the assessor to provide a brief description of controls found in place, including those controls found to be in place as a result of compensating controls. (Note: that this column must not be used for items that are not yet in place or for open items to be completed …
Modified
p. 13 → 14
• For those controls “Not In Place” the assessor may include a target date that the merchant or service provider expects to have controls “In Place”. Any additional notes or comments may be included here as well.
Target Date/Comments
• For those controls “Not In Place” the assessor may include a target date that the merchant or service provider expects to have controls “In Place”. Any additional notes or comments may be included here as well.
• For those controls “Not In Place” the assessor may include a target date that the merchant or service provider expects to have controls “In Place”. Any additional notes or comments may be included here as well.
Modified
p. 14 → 15
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 1.1 Establish firewall and router configuration standards that include the following:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 1.1 Establish firewall and router configuration standards that include the following:
Modified
p. 15 → 16
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure 1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business•for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure 1.1.5.a Verify that firewall and router configuration standards include a documented list of services, protocols and ports necessary for business•for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.
Modified
p. 16 → 17
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.
Modified
p. 17 → 18
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only ”established” connections are allowed into the network.) 1.3.6 Verify that the firewall performs stateful inspection (dynamic packet filtering). [Only established connections should be allowed in, and only if they are associated with a previously established session (run a port scanner on all TCP ports with “syn reset” or ”syn ack” bits set•a response means packets are …
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only ”established” connections are allowed into the network.) 1.3.6 Verify that the firewall performs stateful inspection (dynamic packet filtering). [Only established connections should be allowed in, and only if they are associated with a previously established session (run a port scanner on all TCP ports with “syn reset” or ”syn ack” bits set•a response means packets …
Removed
p. 18
Encryption keys were changed from default at installation, and are changed anytime anyone with knowledge of the keys leaves the company or changes positions Default SNMP community strings on wireless devices were changed Default passwords/passphrases on access points were changed Firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks (for example, WPA/WPA2) Other security-related wireless vendor defaults, if applicable
Modified
p. 18 → 19
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ Comments 2.1 Always change vendor-supplied defaults before installing a system on the network•for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 2.1 Always change vendor-supplied defaults before installing a system on the network•for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.
Modified
p. 19 → 20
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Modified
p. 20 → 21
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 2.3 Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web- based management and other non-console administrative access.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 2.3 Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web- based management and other non-console administrative access.
Modified
p. 21 → 22
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
Removed
p. 22
Incoming transaction data All logs (for example, transaction, history, debugging, error) History files Trace files Several database schemas Database contents
Modified
p. 22 → 23
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 3.2 Do not store sensitive authentication data after authorization (even if encrypted). Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 3.2 Do not store sensitive authentication data after authorization (even if encrypted). Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:
Modified
p. 22 → 23
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, and 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: The cardholder’s name, Primary account number (PAN), Expiration date, and Service code To minimize risk, store only these data elements as needed for business.
Modified
p. 23 → 24
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ Comments 3.2.2 Do not store the card- verification code or value (three- digit or four-digit number printed on the front or back of a payment card) used to verify card-not- present transactions.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ Comments 3.2.2 Do not store the card- verification code or value (three- digit or four-digit number printed on the front or back of a payment card) used to verify card-not- present transactions. Note: See PCI DSS Glossary of Terms, Abbreviations, and Acronyms for additional information.
Removed
p. 24
One-way hashes based on strong cryptography Truncation Index tokens and pads (pads must be securely stored) Strong cryptography with associated key-management processes and procedures The MINIMUM account information that must be rendered unreadable is the PAN. Notes:
If for some reason, a company is unable render the PAN unreadable, refer to Appendix B: Compensating Controls. “Strong cryptography” is defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms.
One-way hashes based on strong cryptography Truncation Index tokens and pads, with the pads being securely stored Strong cryptography, with associated key- management processes and procedures 3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text).
If for some reason, a company is unable render the PAN unreadable, refer to Appendix B: Compensating Controls. “Strong cryptography” is defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms.
One-way hashes based on strong cryptography Truncation Index tokens and pads, with the pads being securely stored Strong cryptography, with associated key- management processes and procedures 3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text).
Modified
p. 24 → 25
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ Comments 3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ Comments 3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches: One-way hashes based on strong cryptography Truncation Index tokens and pads (pads must be securely stored) Strong cryptography with associated key-management processes and procedures The MINIMUM account information that must be rendered unreadable is the PAN. Notes: …
Modified
p. 24 → 25
3.4.a Obtain and examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable). Verify that the PAN is rendered unreadable using one of the following methods:
3.4.a Obtain and examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable). Verify that the PAN is rendered unreadable using one of the following methods: One-way hashes based on strong cryptography Truncation Index tokens and pads, with the pads being securely stored Strong cryptography, with associated key- management processes and procedures 3.4.b Examine several tables or files from a sample of data repositories …
Modified
p. 26 → 27
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ Comments 3.6.4 Periodic cryptographic key changes As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically At least annually 3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ Comments 3.6.4 Periodic cryptographic key changes As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically At least annually 3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.
Removed
p. 27
- Verify that the server supports the latest patched versions. - Verify that HTTPS appears as a part of the browser Universal Record Locator (URL). - Verify that no cardholder data is required when HTTPS does not appear in the URL. Select a sample of transactions as they are received and observe transactions as they occur to verify that cardholder data is encrypted during transit. Verify that only trusted SSL/TLS keys/certificates are accepted. Verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.)
Modified
p. 27 → 28
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS are:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS are:
Modified
p. 27 → 28
The Internet, Wireless technologies, Global System for Mobile communications (GSM), and General Packet Radio Service (GPRS).
Modified
p. 27 → 28
4.1.a Verify the use of encryption (for example, SSL/TLS or IPSEC) wherever cardholder data is transmitted or received over open, public networks Verify that strong encryption is used during data transmission For SSL implementations:
4.1.a Verify the use of encryption (for example, SSL/TLS or IPSEC) wherever cardholder data is transmitted or received over open, public networks Verify that strong encryption is used during data transmission For SSL implementations: - Verify that the server supports the latest patched versions. - Verify that HTTPS appears as a part of the browser Universal Record Locator (URL). - Verify that no cardholder data is required when HTTPS does not appear in the URL. Select a …
Modified
p. 28 → 29
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ Comments 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission.
Modified
p. 28 → 29
For new wireless implementations, it is prohibited to implement WEP after March 31, 2009. For current wireless implementations, it is prohibited to use WEP after June 30, 2010.
Removed
p. 32
Code changes are reviewed by individuals other then the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. Code reviews ensure code is developed according to secure coding guidelines such as the Open Web Security Project Guide (see PCI DSS Requirement 6.5). Appropriate corrections are implemented prior to release. Code review results are reviewed and approved by management prior to release.
Modified
p. 32 → 33
6.3.7.a Obtain and review policies to confirm all custom application code changes for internal applications must be reviewed (either using manual or automated processes), as follows:
6.3.7.a Obtain and review policies to confirm all custom application code changes for internal applications must be reviewed (either using manual or automated processes), as follows: 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. Appropriate corrections are implemented prior to release. Code review results are reviewed and approved by management prior to release.
Modified
p. 32 → 33
6.3.7.b Obtain and review policies to confirm that all custom application code changes for web applications must be reviewed (using either manual or automated processes) as follows: 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. Code reviews ensure code is developed according to secure coding guidelines such as the Open Web Security Project Guide (see PCI DSS Requirement 6.5). …
Modified
p. 33 → 34
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 6.4 Follow change control procedures for all changes to system components. The procedures must include the following:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 6.4 Follow change control procedures for all changes to system components. The procedures must include the following:
Modified
p. 34 → 35
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 6.5.1 Cross-site scripting (XSS) 6.5.1 Cross-site scripting (XSS) (Validate all parameters before inclusion.) 6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 6.5.1 Cross-site scripting (XSS) 6.5.1 Cross-site scripting (XSS) (Validate all parameters before inclusion.) 6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws.
Removed
p. 35
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes Installing a web-application firewall in front of public-facing web applications 6.6 For public-facing web applications, ensure that either one of the following methods are in place as follows:
Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:
Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes Installing a web-application firewall in front of public-facing web applications 6.6 For public-facing web applications, ensure that either one of the following methods are in place as follows:
Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:
Modified
p. 35 → 36
- At least annually - After any changes - By an organization that specializes in application security - That all vulnerabilities are corrected - That the application is re-evaluated after the corrections Verify that a web-application firewall is in place in front of public-facing web applications to detect and prevent web-based attacks. Note: “An organization that specializes in application security” can be either a third-party company or an internal organization, as long as the reviewers specialize in application security …
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes Installing a web-application firewall in front of public-facing web applications 6.6 For public-facing web applications, …
Modified
p. 36 → 37
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following:
Modified
p. 37 → 38
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed. This access control system must include the following:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 7.2 Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed. This access control system must include the following:
Removed
p. 38
Password or passphrase Two-factor authentication (for example, token devices, smart cards, biometrics, or public keys) 8.2 To verify that users are authenticated using unique ID and additional authentication (for example, a password) for access to the cardholder data environment, perform the following:
Modified
p. 38 → 39
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.1 Assign all users a unique ID before allowing them to access system components or cardholder data.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 8.1 Assign all users a unique ID before allowing them to access system components or cardholder data.
Removed
p. 39
Obtain and examine an authorization form for each ID. Verify that the sampled user IDs are implemented in accordance with the authorization form (including with privileges as specified and all signatures obtained), by tracing information from the authorization form to the system.
Modified
p. 39 → 40
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.5 Ensure proper user authentication and password management for non- consumer users and administrators on all system components as follows:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 8.5 Ensure proper user authentication and password management for non- consumer users and administrators on all system components as follows:
Modified
p. 39 → 40
8.5.1.a Select a sample of user IDs, including both administrators and general users. Verify that each user is authorized to use the system according to company policy by performing the following:
8.5.1.a Select a sample of user IDs, including both administrators and general users. Verify that each user is authorized to use the system according to company policy by performing the following: Obtain and examine an authorization form for each ID. Verify that the sampled user IDs are implemented in accordance with the authorization form (including with privileges as specified and all signatures obtained), by tracing information from the authorization form to the system.
Removed
p. 40
8.5.8.a For a sample of system components, examine user ID lists to verify the following Generic user IDs and accounts are disabled or removed. 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. 40 → 41
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.5.8 Do not use group, shared, or generic accounts and passwords.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 8.5.8 Do not use group, shared, or generic accounts and passwords. 8.5.8.a For a sample of system components, examine user ID lists to verify the following Generic user IDs and accounts are disabled or removed. 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.
Removed
p. 41
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.5.11 Use passwords containing both numeric and alphabetic characters.
Removed
p. 42
All users are authenticated prior to access. All user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures). Direct access or queries to databases are restricted to database administrators.
Modified
p. 42 → 43
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.
Modified
p. 42 → 43
8.5.16.a Review database and application configuration settings and verify that user authentication and access to databases includes the following:
8.5.16.a Review database and application configuration settings and verify that user authentication and access to databases includes the following: All users are authenticated prior to access. All user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures). Direct access or queries to databases are restricted to database administrators.
Removed
p. 43
Verify that access is controlled with badge readers or other devices including authorized badges and lock and key. Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder environment and verify that they are “locked” to prevent unauthorized use.
Modified
p. 43 → 44
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.
Removed
p. 44
Granting new badges, changing access requirements, and revoking terminated employee and expired visitor badges Limited access to badge system 9.2.b Observe people within the facility to verify that it is easy to distinguish between employees and visitors.
Modified
p. 44 → 45
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 9.2 Develop procedures to help all personnel easily distinguish between employees and visitors, especially in areas where cardholder data is accessible. For purposes of this requirement, “employee” refers to full-time and part- time employees, temporary employees and personnel, and contractors and consultants who are “resident” on the entity’s site. A “visitor” is defined as a vendor, guest of an employee, service personnel, or anyone who needs to enter the …
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 9.2 Develop procedures to help all personnel easily distinguish between employees and visitors, especially in areas where cardholder data is accessible. For purposes of this requirement, “employee” refers to full-time and part- time employees, temporary employees and personnel, and contractors and consultants who are “resident” on the entity’s site. A “visitor” is defined as a vendor, guest of an employee, service personnel, or anyone who needs to enter …
Modified
p. 44 → 45
9.2.a Review processes and procedures for assigning badges to employees, and visitors, and verify these processes include the following:
9.2.a Review processes and procedures for assigning badges to employees, and visitors, and verify these processes include the following: Granting new badges, changing access requirements, and revoking terminated employee and expired visitor badges Limited access to badge system 9.2.b Observe people within the facility to verify that it is easy to distinguish between employees and visitors.
Modified
p. 45 → 46
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location’s security at least annually.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location’s security at least annually.
Modified
p. 46 → 47
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 9.10 Destroy media containing cardholder data when it is no longer needed for business or legal reasons as follows:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 9.10 Destroy media containing cardholder data when it is no longer needed for business or legal reasons as follows:
Modified
p. 47 → 48
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
Modified
p. 48 → 49
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 10.3.4 Success or failure indication 10.3.4 Verify success or failure indication is included in log entries.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 10.3.4 Success or failure indication 10.3.4 Verify success or failure indication is included in log entries.
Modified
p. 48 → 49
10.4.b Verify that internal servers are not all receiving time signals from external sources. [Two or three central time servers within the organization receive external time signals [directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT)], peer with each other to keep accurate time, and share the time with other internal servers.] 10.4.c Verify that specific external hosts are designated from which the timeservers will accept NTP time updates …
10.4.b Verify that internal servers are not all receiving time signals from external sources. [Two or three central time servers within the organization receive external time signals [directly from a special radio, GPS satellites, or other external sources based on International Atomic Time and UTC (formerly GMT)], peer with each other to keep accurate time, and share the time with other internal servers.] 10.4.c Verify that specific external hosts are designated from which the timeservers will accept NTP time updates …
Modified
p. 49 → 50
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 10.5.1 Limit viewing of audit trails to those with a job-related need.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 10.5.1 Limit viewing of audit trails to those with a job-related need. 10.5.1 Verify that only individuals who have a job- related need can view audit trail files.
Removed
p. 50
Four quarterly scans occurred in the most recent 12- month period; The results of each scan satisfy the PCI Security Scanning Procedures (for example, no urgent, critical, or high vulnerabilities); The scans were completed by an Approved Scanning Vendor (ASV) qualified by PCI SSC. Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the
Modified
p. 50 → 51
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.
Modified
p. 50 → 51
11.2.b Verify that external scanning is occurring on a quarterly basis in accordance with the PCI Security Scanning Procedures, by inspecting output from the four most recent quarters of external vulnerability scans to verify that:
11.2.b Verify that external scanning is occurring on a quarterly basis in accordance with the PCI Security Scanning Procedures, by inspecting output from the four most recent quarters of external vulnerability scans to verify that: Four quarterly scans occurred in the most recent 12- month period; The results of each scan satisfy the PCI Security Scanning Procedures (for example, no urgent, critical, or high vulnerabilities); The scans were completed by an Approved Scanning Vendor (ASV) qualified by …
Modified
p. 51 → 52
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ Comments assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly scanning, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan. For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly scanning, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan. For subsequent years after the initial PCI DSS review, four passing quarterly scans must have occurred.
Modified
p. 52 → 53
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 11.4.c Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 11.4.c Examine IDS/IPS configurations and confirm IDS/IPS devices are configured, maintained, and updated per vendor instructions to ensure optimal protection.
Modified
p. 52 → 53
Examples of files that should be monitored: System executables Application executables Configuration and parameter files Centrally stored, historical or archived, log and audit files
Modified
p. 53 → 54
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.1 Establish, publish, maintain, and disseminate a security policy that accomplishes the following:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 12.1 Establish, publish, maintain, and disseminate a security policy that accomplishes the following:
Modified
p. 54 → 55
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.3 Develop usage policies for critical employee-facing technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, personal data/digital assistants (PDAs), e-mail usage and Internet usage) to define proper use of these technologies for all employees and contractors. Ensure these usage policies require the following:
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 12.3 Develop usage policies for critical employee-facing technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, personal data/digital assistants (PDAs), e-mail usage and Internet usage) to define proper use of these technologies for all employees and contractors. Ensure these usage policies require the following:
Modified
p. 55 → 56
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.3.10 When accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 12.3.10 When accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media.
Modified
p. 56 → 57
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.6 Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 12.6 Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.
Modified
p. 57 → 58
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.
Removed
p. 58
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.9.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:
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 back-up 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 12.9.1 Verify that the Incident Response Plan includes:
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 back-up 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 12.9.1 Verify that the Incident Response Plan includes:
Modified
p. 58 → 59
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 12.9.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum: 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 back-up processes Analysis of legal requirements for …
Modified
p. 59 → 60
PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.9.5 Include alerts from intrusion- detection, intrusion-prevention, and file-integrity monitoring systems.
PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 12.9.5 Include alerts from intrusion- detection, intrusion-prevention, and file-integrity monitoring systems.
Removed
p. 60
No entity on the system can use a shared web server user ID. All CGI scripts used by an entity must be created and run as the entity’s unique user ID.
Modified
p. 60 → 61
Requirements Testing Procedures In Place Not in Target Date/ A.1 Protect each entity’s (that is merchant, service provider, or other entity) hosted environment and data, per A.1.1 through A.1.4: A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS. Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and validate …
Requirements Testing Procedures In Place Not in Place Target Date/ A.1 Protect each entity’s (that is merchant, service provider, or other entity) hosted environment and data, per A.1.1 through A.1.4: A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS. Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and …
Modified
p. 60 → 61
A.1.1 If a shared hosting provider allows entities (for example, merchants or service providers) to run their own applications, verify these application processes run using the unique ID of the entity. For example:
A.1.1 If a shared hosting provider allows entities (for example, merchants or service providers) to run their own applications, verify these application processes run using the unique ID of the entity. For example: No entity on the system can use a shared web server user ID. All CGI scripts used by an entity must be created and run as the entity’s unique user ID.
Removed
p. 61
Disk space Bandwidth Memory CPU A.1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.
Logs are enabled for common third-party applications. Logs are active by default. Logs are available for review by the owning entity. Log locations are clearly communicated to the owning entity.
Logs are enabled for common third-party applications. Logs are active by default. Logs are available for review by the owning entity. Log locations are clearly communicated to the owning entity.
Modified
p. 61 → 62
A.1.2.e To ensure each entity cannot monopolize server resources to exploit vulnerabilities (for example, error, race, and restart conditions, resulting in, for example, buffer overflows), verify restrictions are in place for the use of these system resources:
A.1.2.e To ensure each entity cannot monopolize server resources to exploit vulnerabilities (for example, error, race, and restart conditions, resulting in, for example, buffer overflows), verify restrictions are in place for the use of these system resources: Disk space Bandwidth Memory CPU A.1.3 Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.
Modified
p. 61 → 62
A.1.3.a Verify the shared hosting provider has enabled logging as follows, for each merchant and service provider environment:
A.1.3.a Verify the shared hosting provider has enabled logging as follows, for each merchant and service provider environment: Logs are enabled for common third-party applications. Logs are active by default. Logs are available for review by the owning entity. Log locations are clearly communicated to the owning entity.
Modified
p. 64 → 65
Company XYZ documents processes and procedures to ensure SU configurations are not changed, altered, or removed to allow individual users to execute root commands without being individually tracked or logged Appendix D: Attestation of Compliance
• Merchants Payment Card Industry (PCI) Data Security Standard Attestation of Compliance for Onsite Assessments
• Merchants Version1.2
• Merchants Payment Card Industry (PCI) Data Security Standard Attestation of Compliance for Onsite Assessments
• Merchants Version
Company XYZ documents processes and procedures to ensure SU configurations are not changed, altered, or removed to allow individual users to execute root commands without being individually tracked or logged Appendix D: Attestation of Compliance
• Merchants Payment Card Industry (PCI) Data Security Standard Attestation of Compliance for Onsite Assessments
• Merchants Version 1.2.1
• Merchants Payment Card Industry (PCI) Data Security Standard Attestation of Compliance for Onsite Assessments
• Merchants Version 1.2.1
Modified
p. 67 → 68
Non-Compliant: Some requirements in the ROC are marked “not in place,” resulting in an overall NON-COMPLIANT rating, or a passing scan has not been completed by a PCI SSC Approved Scanning Vendor, thereby (Merchant Company Name) has not demonstrated full compliance with the PCI DSS.
Non-Compliant: Some requirements in the ROC are marked “not in place,” resulting in an overall NON-COMPLIANT rating, or a passing scan has not been completed by a PCI SSC Approved Scanning Vendor, thereby (Merchant Company Name) has not demonstrated full compliance with the PCI DSS. Target Date for Compliance: An entity submitting this form with a status of Non-Compliant may be required to complete the Action Plan in Part 4 of this document. Check with your acquirer or the payment …
Modified
p. 67 → 68
Part 3b. QSA and Merchant Acknowledgments Signature of Lead QSA Date:
Part 3b. QSA and Merchant Acknowledgments Signature of Lead QSA Ç Date:
Modified
p. 67 → 68
Signature of Merchant Executive Officer Date:
Signature of Merchant Executive Officer Ç Date:
Modified
p. 68 → 69
PCI Requirement Description Compliance Status (Select One) Remediation Date and Actions (if Compliance Status is “No”) Install and maintain a firewall configuration to protect cardholder data.
PCI Requirement Description Compliance Status (Select One) Remediation Date and Actions (if Compliance Status is “No”) 1 Install and maintain a firewall configuration to protect cardholder data.
Modified
p. 69 → 70
Appendix E: Attestation of Compliance
• Service Providers Payment Card Industry (PCI) Data Security Standard Attestation of Compliance for Onsite Assessments
• Service Providers Version1.2
• Service Providers Payment Card Industry (PCI) Data Security Standard Attestation of Compliance for Onsite Assessments
• Service Providers Version
Appendix E: Attestation of Compliance
• Service Providers Payment Card Industry (PCI) Data Security Standard Attestation of Compliance for Onsite Assessments
• Service Providers Version 1.2.1
• Service Providers Payment Card Industry (PCI) Data Security Standard Attestation of Compliance for Onsite Assessments
• Service Providers Version 1.2.1
Modified
p. 71 → 72
Non-Compliant: Some requirements in the ROC are marked “not in place,” resulting in an overall NON-COMPLIANT rating, or a passing scan has not been completed by a PCI SSC Approved Scanning Vendor, thereby (Service Provider Name) has not demonstrated full compliance with the PCI DSS.
Non-Compliant: Some requirements in the ROC are marked “not in place,” resulting in an overall NON-COMPLIANT rating, or a passing scan has not been completed by a PCI SSC Approved Scanning Vendor, thereby (Service Provider Name) has not demonstrated full compliance with the PCI DSS. Target Date for Compliance: An entity submitting this form with a status of Non-Compliant may be required to complete the Action Plan in Part 4 of this document. Check with the payment brand(s) before completing …
Modified
p. 71 → 72
Part 3b. QSA and Service Provider Acknowledgments Signature of Lead QSA Date:
Part 3b. QSA and Service Provider Acknowledgments Signature of Lead QSA Ç Date:
Modified
p. 71 → 72
Signature of Service Provider Executive Officer Date:
Signature of Service Provider Executive Officer Ç Date:
Modified
p. 72 → 73
PCI Requirement Description Compliance Status (Select One) Remediation Date and Actions (if Compliance Status is “No”) Install and maintain a firewall configuration to protect cardholder data.
PCI Requirement Description Compliance Status (Select One) Remediation Date and Actions (if Compliance Status is “No”) 1 Install and maintain a firewall configuration to protect cardholder data.