Document Diff - PCI Watch

Added p. 5

This document, PCI Data Security Standard Requirements and Security Assessment Procedures, combines the 12 PCI DSS requirements and corresponding testing procedures into a security assessment tool. It is designed for use during PCI DSS compliance assessments as part of an entity’s validation process. The following sections provide detailed guidelines and best practices to assist entities prepare for, conduct, and report the results of a PCI DSS assessment. The PCI DSS Requirements and Testing Procedures begin on page 19.

Added p. 6

 Attestations of Compliance  Navigating PCI DSS: Understanding the Intent of the Requirements  The PCI DSS and PA-DSS Glossary of Terms, Abbreviations and Acronyms  Frequently Asked Questions (FAQs)  Information Supplements and Guidelines Please refer to www.pcisecuritystandards.org for more information.

Note: Information Supplements complement the PCI DSS and identify additional considerations and recommendations for meeting PCI DSS requirements

• they do not change, eliminate or supersede the PCI DSS or any of its requirements.

PCI DSS applies wherever account data is stored, processed or transmitted. Account Data consists of Cardholder Data plus Sensitive Authentication Data, as follows:

Cardholder Data includes: Sensitive Authentication Data includes:

 Primary Account Number (PAN)  Cardholder Name  Expiration Date  Service Code  Full magnetic stripe data or equivalent on a chip  CAV2/CVC2/CVV2/CID  PINs/PIN blocks The primary account number is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are …

Added p. 8

PCI DSS requirements 3.3 and 3.4 apply only to PAN. If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.4.

PCI DSS only applies if PANs are stored, processed and/or transmitted.

Added p. 9

The requirements for the Payment Application Data Security Standard (PA-DSS) are derived from the PCI DSS Requirements and Security Assessment Procedures (this document). The PA-DSS details what a payment application must support to facilitate a customer’s PCI DSS compliance.

Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of full magnetic stripe data, card verification codes and values (CAV2, CID, CVC2, CVV2), and PINs and PIN blocks, along with the damaging fraud resulting from these breaches.

Just a few of the ways payment applications can prevent compliance include:

 Storage of magnetic stripe data and/or equivalent data from the chip in the customer's network after authorization;  Applications that require customers to disable other features required by the PCI DSS, like anti-virus software or firewalls, in order to get the payment application to work properly; and  Vendors’ use of unsecured methods …

Added p. 11

If network segmentation is in place and being used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment. At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not. However, the adequacy of a specific implementation of network segmentation is highly variable and dependent upon a number of factors, such as a given network's configuration, the technologies deployed, and other controls that may be implemented.

Appendix D: Segmentation and Sampling of Business Facilities/System Components provides more information on the effect of network segmentation and sampling on the scope of a PCI DSS assessment.

Added p. 12

See the bullet beginning ―For managed service provider (MSP) reviews,‖ in Item 3, ―Details about Reviewed Environment,‖ in the ―Instructions and Content for Report on Compliance‖ section, below, for more information.

Sampling of Business Facilities/System Components Sampling is not a PCI DSS requirement. However, after considering the overall scope and complexity of the environment being assessed, the assessor may independently select representative samples of business facilities/system components in order to assess PCI DSS requirements. These samples must be defined first for business facilities and then for system components within each selected business facility. Samples must be a representative selection of all of the types and locations of business facilities, as well as types of system components within selected business facilities. Samples must be sufficiently large to provide the assessor with assurance that controls are implemented as expected.

Sampling of business facilities/system components for an assessment does not reduce the scope of the …

Added p. 13

For each instance where sampling is used, the assessor must:

 Document the rationale behind the sampling technique and sample size,  Document and validate the standardized PCI DSS processes and controls used to determine sample size, and  Explain how the sample is appropriate and representative of the overall population.

Assessors must revalidate the sampling rationale for each assessment. If sampling is to be used, different samples of business facilities and system components must be selected for each assessment.

 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.

- What types of payment channels they serve, such as card-not-present (for example, mail-order-telephone-order (MOTO), e- Commerce), or …

Added p. 18

3. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Attestations of Compliance are available on the PCI SSC website (www.pcisecuritystandards.org).

 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 the controls which were validated as ―in place‖ for each requirement, including descriptions of controls found to be in place as a result of compensating controls, or as a result of a requirement being ―Not Applicable.‖  Not in Place

• This column must be used by the assessor to provide a brief description of controls that are not in place. Note that a non- compliant report should not be submitted to a payment brand or acquirer unless specifically requested. , For further instructions on non- …

Added p. 21

Note: An ―untrusted network‖ is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 1.2.2 Secure and synchronize router configuration files.

Added p. 23

Note: Methods to obscure IP addressing may include, but are not limited to:

 Network Address Translation (NAT)  Placing servers containing cardholder data behind proxy servers/firewalls or content caches,  Removal or filtering of route advertisements for private networks that employ registered addressing,  Internal use of RFC1918 address space instead of registered addresses.

1.3.8.a Verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet.

1.3.8.b Verify that any disclosure of private IP addresses and routing information to external entities is authorized.

Added p. 24

2.1.1.a Verify encryption keys were changed from default at installation, and are changed anytime anyone with knowledge of the keys leaves the company or changes positions 2.1.1.b Verify default SNMP community strings on wireless devices were changed.

2.1.1.c Verify default passwords/passphrases on access points were changed.

2.1.1.d Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks.

2.1.1.e Verify other security-related wireless vendor defaults were changed, if applicable.

 Center for Internet Security (CIS)  International Organization for Standardization (ISO)  SysAdmin Audit Network Security (SANS) Institute  National Institute of Standards Technology (NIST) 2.2.a Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards.

2.2.d Verify that system configuration standards include each item below (2.2.1

• 2.2.4).

Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

2.2.1.a For …

Added p. 28

3.1.1.b Verify that policies and procedures include provisions for secure disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data.

3.1.1.c Verify that policies and procedures include coverage for all storage of cardholder data.

3.1.1.d Verify that policies and procedures include at least one of the following: A programmatic process (automatic or manual) to remove, at least quarterly, stored cardholder data that exceeds requirements defined in the data retention policy Requirements for a review, conducted at least quarterly, to verify that stored cardholder data does not exceed requirements defined in the data retention policy.

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 3.1.1.e For a sample of system components that store cardholder data, verify that the data stored does not exceed the requirements defined in the data retention policy.

Note: It is permissible for issuers and companies that support issuing services to store …

Added p. 30

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas  Database contents 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.

Added p. 30

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas  Database contents 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

 This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN.  This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, for point-of-sale (POS) receipts.

 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

Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have …

Added p. 33

Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key encryption key). Archived cryptographic keys should only be used for decryption/verification purposes.

3.6.5.c If retired or replaced cryptographic keys are retained, verify that these keys are not used for encryption operations.

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 3.6.6 If manual clear-text cryptographic key management operations are used, these operations must be managed using split knowledge and dual control (for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key).

Note: Examples of manual key management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.

Added p. 35

4.1.a Select a sample of transactions as they are received and observe transactions as they occur to verify that cardholder data is encrypted during transit.

4.1.b Verify that only trusted keys and/or certificates are accepted.

4.1.c Verify that the protocol is implemented to use only secure configurations, and does not support insecure versions or configurations.

4.1.d Verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.) 4.1.e For SSL/TLS implementations:

 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.

Note: The use of WEP as a security control was prohibited as of 30 June 2010.

Added p. 39

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.

 Risk rankings should be based on industry best practices. For example, criteria for ranking ―High‖ risk vulnerabilities may include a CVSS base score of 4.0 or above, and/or a vendor-supplied patch classified by the vendor as ―critical,‖ and/or a vulnerability affecting a critical system component.

 The ranking of vulnerabilities as defined in 6.2.a is considered a best practice until June 30, 2012, after which it becomes a requirement.

Added p. 39

6.3.b Examine written software development processes to verify that information security is included throughout the life cycle.

6.3.c Examine written software development processes to verify that software applications are developed in accordance with PCI DSS.

Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle.

6.3.2.a Obtain and review policies to confirm that all custom application code changes must be reviewed (using either manual or automated processes) as follows:

Added p. 41

6.4.5.3.a For each sampled change, verify that functionality testing is performed to verify that the change does not adversely impact the security of the system.

Added p. 41

Note: The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.

Added p. 42

Note: This requirement is considered a best practice until June 30, 2012, after which it becomes a requirement.

Added p. 42

Note: Requirements 6.5.7 through 6.5.9, below, apply to web applications and application interfaces (internal or external):

Added p. 43

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:

- 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 …

Added p. 46

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. However, Requirements 8.1, 8.2 and 8.5.8 through 8.5.15 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

 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 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:

 Obtain and examine documentation describing the authentication method(s) used.

 For each type of authentication method used and for each type …

Added p. 48

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.5.2 Verify user identity before performing password resets.

8.5.6.b Verify that vendor remote access accounts are monitored while being used.

Added p. 48

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 8.5.8.b Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited.

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.5.9 Change user passwords at least every 90 days.

8.5.9.a For a sample of system components, obtain and inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.

8.5.9.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non- consumer users are given guidance …

Added p. 50

8.5.16.b Verify that database and application configuration settings ensure that 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).

8.5.16.c Verify that database and application configuration settings restrict user direct access or queries to databases to database administrators.

Requirement 9: Restrict physical access to cardholder data Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, ―onsite personnel‖ refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity’s premises. A ―visitor‖ refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more …

Added p. 52

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 9.1.3 Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines.

Added p. 52

 Granting new badges,  Changing access requirements, and  Revoking terminated onsite personnel and expired visitor badges 9.2.b Verify that access to the badge system is limited to authorized personnel.

9.2.c Examine badges in use to verify that they clearly identify visitors and it is easy to distinguish between onsite personnel and visitors.

Added p. 52

9.3.2.a Observe people within the facility to verify the use of visitor ID badges, and that visitors are easily distinguishable from onsite personnel.

9.3.2.b Verify that visitor badges expire.

9.5.b Verify that the storage location security is reviewed at least annually.

Added p. 56

Note: One example of time synchronization technology is Network Time Protocol (NTP).

Added p. 56

10.4.1.a Verify that only designated central time servers receive time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

10.4.1.b Verify that the designated central time servers peer with each other to keep accurate time, and other internal servers receive time only from the central time servers.

Added p. 56

10.4.2.b Review system configurations and time synchronization settings and processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed.

Added p. 58

Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6.

Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS.

Whichever methods are used, they must be sufficient to detect and identify any unauthorized devices.

11.1.a Verify that the entity has a documented process to detect and identify wireless access points on a quarterly basis.

11.1.b Verify that the methodology is adequate to detect and identify any unauthorized wireless access points, including at least the following:

 WLAN cards inserted into system components  Portable wireless devices connected to system components (for example, by USB, etc.)  Wireless devices attached to a network port or network device 11.1.c Verify that the documented process to identify unauthorized wireless access points is performed at least quarterly for all system …

Added p. 60

11.2.1.a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12-month period.

11.2.1.b Review the scan reports and verify that the scan process includes rescans until passing results are obtained, or all ―High‖ vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.

11.2.1.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

11.2.3.c Validate that the scan was performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 11.2.2 Perform quarterly external vulnerability scans via an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

Note: Quarterly external …

Added p. 61

Note: Scans conducted after changes may be performed by internal staff.

11.2.3.a Inspect change control documentation and scan reports to verify that system components subject to any significant change were scanned.

11.2.3.b Review scan reports and verify that the scan process includes rescans until:

 For external scans, no vulnerabilities exist that are scored greater than a 4.0 by the CVSS,  For internal scans, a passing result is obtained or all ―High‖ vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.

11.3.b Verify that noted exploitable vulnerabilities were corrected and testing repeated.

11.5.a Verify the use of file-integrity monitoring tools within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities.

12.1.2.b Review risk assessment documentation to verify that the risk assessment process is performed at least annually.

12.3.10.b For personnel with proper authorization, verify that usage policies require the protection of cardholder data in accordance …

Added p. 67

Note: Methods can vary depending on the role of the personnel and their level of access to the cardholder data.

Added p. 71

 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. 1

Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version ~~1.2.1~~

Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 2.0

Removed p. 6

PCI DSS Applicability Information The following table illustrates commonly used elements of cardholder and sensitive authentication data; whether storage of each data element is permitted or prohibited; and whether each data element must be protected. This table is not exhaustive, but is presented to illustrate the different types of requirements that apply to each data element.

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.

Data Element Storage Permitted Protection

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 …

Removed p. 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 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 internal network firewalls, routers with strong access control lists or other technology that restricts access to a particular segment of a network. An important prerequisite to reduce the scope of the cardholder data environment is a clear understanding of business needs and processes related to …

Removed p. 8

Sampling of Business Facilities and System Components The assessor may select representative samples of business facilities and system components in order to assess PCI DSS requirements. These samples must include both business facilities and system components, must be a representative selection of all of the types and locations of business facilities as well as types of system components, and must be sufficiently large to provide the assessor with assurance that controls are implemented as expected.

Modified p. 8 → 11

Third Parties/Outsourcing For service providers required to undergo an annual onsite assessment, compliance validation must be performed on all system components ~~where~~ cardholder data ~~is stored, processed, or transmitted.~~

Third Parties/Outsourcing For service providers required to undergo an annual onsite assessment, compliance validation must be performed on all system components in the cardholder data environment.

Modified p. 8 → 11

A service provider or merchant may use a third-party provider to store, process, or transmit cardholder data on their behalf, or to manage components such as routers, firewalls, databases, physical security, and/or servers. If so, there may be an impact on the security of the cardholder data environment.

A service provider or merchant may use a third-party service provider to store, process, or transmit cardholder data on their behalf, or to manage components such as routers, firewalls, databases, physical security, and/or servers. If so, there may be an impact on the security of the cardholder data environment.

Modified p. 8 → 11

For those entities that outsource storage, processing, or transmission of cardholder data to third-party service providers, the Report on Compliance (ROC) must document the role of each service provider, clearly identifying which requirements apply to the ~~reviewed~~ entity and which apply to the service provider. There are two options for third-party service providers to validate compliance: ~~1) They can undergo a PCI DSS assessment on their own and provide evidence to their customers to demonstrate their compliance, or 2) If …~~

For those entities that outsource storage, processing, or transmission of cardholder data to third-party service providers, the Report on Compliance (ROC) must document the role of each service provider, clearly identifying which requirements apply to the assessed entity and which apply to the service provider. There are two options for third-party service providers to validate compliance:

Modified p. 8 → 12

Additionally, merchants and service providers must manage and monitor the PCI DSS compliance of all associated ~~third parties~~ with access to cardholder data. Refer to Requirement 12.8 in this document for details.

Additionally, merchants and service providers must manage and monitor the PCI DSS compliance of all associated third-party service providers with access to cardholder data. Refer to Requirement 12.8 in this document for details.

Modified p. 8 → 12

Examples of business facilities include corporate offices, stores, franchise ~~merchants,~~ and ~~business facilities~~ in different locations. Sampling should include system components ~~for~~ each business facility. For example, for each business ~~facility,~~ include a variety of operating systems, functions, and applications that are applicable to the area under review. Within each business facility, the reviewer could choose Sun servers running Apache WWW, Windows servers running Oracle, mainframe systems running legacy card processing applications, data transfer servers running HP-UX, and Linux Servers …

Examples of business facilities include but are not limited to: corporate offices, stores, franchise locations, processing facilities, data centers, and other facility types in different locations. Sampling should include system components within each selected business facility. For example, for each business facility selected, include a variety of operating systems, functions, and applications that are applicable to the area under review.

Removed p. 9

Please also refer to Appendix F: PCI DSS Reviews

• Scoping and Selecting Samples.

Modified p. 9 → 13

See the above-mentioned Appendices B and C for more details on ~~“compensating controls.”~~

See the above-mentioned Appendices B and C for more details on ―compensating controls.‖ Please also refer to: Appendix D: Segmentation and Sampling of Business Facilities/System Components.

Removed 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. 11 → 15

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 …

- Description of 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 …

Removed p. 12

• List all of the elements of stored cardholder data

• How data is secured

Modified p. 12 → 16

• 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 …

 List all of the elements of stored cardholder data  How data is secured  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 third parties with which the entity shares cardholder data Note: These entities are subject to PCI DSS Requirement 12.8.)  List of third-party payment application products and versions numbers …

Modified p. 12 → 17

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 ASV scan results in the Executive Summary as well as in comments at Requirement 11.2.2.

Modified p. 12 → 17

Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verifies 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring quarterly scanning going forward, and 3) any vulnerabilities noted in the initial scan 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.

Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the assessor verifies:

Removed p. 13

See Compensating Controls section above and Appendices B and C for more details on “compensating controls.” Revalidation of Open Items A “controls in place” report is required to verify compliance. The report is considered non-compliant if it contains “open items,” or items that will be finished at a future date. The merchant/service provider must address these items before validation is completed. After these items are addressed by the merchant/service provider, the assessor will then reassess to validate that the remediation occurred and that all requirements are satisfied. After revalidation, the assessor will issue a new Report on Compliance, verifying that the cardholder data environment is fully compliant, and submit it consistent with instructions (see below).

3. Complete the Attestation of Compliance, for either Service Providers or Merchants as applicable, in its entirety. See Appendices D and E for Attestations of Compliance.

Modified p. 13 → 17

~~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.

 Use the Detailed PCI DSS Requirements and Security Assessment Procedures template to provide detailed report descriptions and findings on each requirement and sub-requirement.  Ensure that all N/A responses are clearly explained.  Review and document any compensating controls considered to conclude that a control is in place.

Modified p. 13 → 18

1. Complete the Report on Compliance (ROC) according to the section above entitled ~~“Instructions~~ and Content for Report on ~~Compliance.”~~

1. Complete the Report on Compliance (ROC) according to the section above entitled ―Instructions and Content for Report on Compliance.‖

Removed p. 14

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 at a future date.) Not in Place

• This column must be used by the assessor to provide a brief description controls that are not in place. Note that a non- compliant report should not be submitted to a payment brand or acquirer unless specifically requested. See Appendix D and Appendix E: Attestations of Compliance for further instructions on non-compliant reports.

Modified p. 14 → 19

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.

 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.

Modified p. 14 → 19

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.

 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.

Modified p. 15 → 20

Requirement 1: Install and maintain a firewall configuration to protect cardholder data Firewalls are ~~computer~~ devices that control computer traffic allowed between ~~a company’s network~~ (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within ~~a company’s~~ internal trusted ~~network.~~ The cardholder data environment is an example of a more sensitive area within ~~the~~ trusted ~~network of a company. A firewall examines all network traffic and blocks those transmissions that do not meet …~~

Requirement 1: Install and maintain a firewall configuration to protect cardholder data Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholder data environment is an example of a more sensitive area within an entity’s trusted network.

Modified p. 15 → 20

PCI DSS Requirements Testing Procedures In Place Not in ~~Place~~ Target Date/ 1.1 Establish firewall and router configuration standards that include the following:

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 1.1 Establish firewall and router configuration standards that include the following:

Removed p. 16

Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.

Modified p. 16 → 21

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.

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 → 21

1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service. ~~An example of an insecure service, protocol, or port is FTP, which passes user credentials in clear-text.~~

1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and implemented by examining firewall and router configuration standards and settings for each service.

Modified p. 16 → 21

1.2.1.b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit ~~“deny all”~~ or an implicit deny after allow statement.

1.2.1.b Verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit ―deny all‖ or an implicit deny after allow statement.

Modified p. 18 → 23

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 …~~

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.) 1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the …

Modified p. 18 → 23

1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by mobile ~~computer users.~~

1.4.b Verify that the personal firewall software is configured by the organization to specific standards and is not alterable by users of mobile and/or employee-owned computers.

Modified p. 19 → 24

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Malicious individuals (external and internal to ~~a company)~~ often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

Modified p. 19 → 24

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.

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 2.1 Always change vendor-supplied defaults before installing a system on the network, including but not limited to passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.

Removed p. 20

2.2.a Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry- accepted hardening standards•for example, SysAdmin Audit Network Security (SANS), National Institute of Standards Technology (NIST), and Center for Internet Security (CIS).

Modified p. 20 → 25

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.

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. Sources of industry-accepted system hardening standards may include, but are not limited to:

Modified p. 20 → 25

2.2.b Verify that system configuration standards include each item below (at 2.2.1

• 2.2.4).

2.2.b Verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.2.

Modified p. 21 → 27

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.

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 2.3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web- based management and other non- console administrative access.

Modified p. 22 → 28

Requirement 3: Protect stored cardholder data Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other ~~network~~ security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating …

Requirement 3: Protect stored cardholder data Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder …

Modified p. 22 → 28

Please refer to the PCI DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of ~~“strong cryptography”~~ and other PCI DSS terms.

Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of ―strong cryptography‖ and other PCI DSS terms.

Modified p. 22 → 28

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.~~

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes, as follows.

Removed p. 23

Note: See PCI DSS Glossary of Terms, Abbreviations, and Acronyms for additional information.

Modified p. 23 → 29

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:

Modified p. 24 → 30

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.~~

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 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.

Modified p. 25 → 31

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: …

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

Modified p. 25 → 31

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 …

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 any of the following methods:

Modified p. 25 → 31

3.4.d Examine a sample of audit logs to confirm that the PAN is ~~sanitized~~ or removed from the logs.

3.4.d Examine a sample of audit logs to confirm that the PAN is rendered unreadable or removed from the logs.

Modified p. 26 → 32

PCI DSS Requirements Testing Procedures In Place Not in ~~Place~~ Target Date/ ~~Comments not be tied~~ to ~~user accounts. 3.4.1.c Verify that~~ cardholder data ~~on removable media is encrypted wherever stored. Note: Disk encryption often cannot encrypt removable media, so data stored on this media will need to be encrypted separately.~~

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 3.5 Protect any keys used to secure cardholder data against disclosure and misuse:

Modified p. 26 → 32

~~3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data.~~ Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

Modified p. 26 → 32

3.6.b For service providers only: If the service provider shares keys with their customers for transmission of cardholder data, verify that the service provider provides documentation to customers that includes guidance on how to securely store and ~~change~~ customer’s ~~keys (used to transmit data between customer and service provider).~~

3.6.b For service providers only: If the service provider shares keys with their customers for transmission or storage of cardholder data, verify that the service provider provides documentation to customers that includes guidance on how to securely transmit, store and update customer’s keys, in accordance with Requirements 3.6.1 through 3.6.8 below.

Removed p. 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.

Removed p. 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: - 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. 28 → 35

Requirement 4: Encrypt transmission of cardholder data across open, public networks Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols ~~can~~ be ~~continued~~ targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

Requirement 4: Encrypt transmission of cardholder data across open, public networks Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.

Modified p. 28 → 35

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:~~

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS include but are not limited to:

Modified p. 28 → 35

The ~~Internet, ~~ Wireless technologies, Global System for Mobile communications ~~(GSM), and ~~ General Packet Radio Service (GPRS).

 The Internet  Wireless technologies,  Global System for Mobile communications (GSM)  General Packet Radio Service (GPRS).

Removed p. 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.

Modified p. 29 → 36

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.

PCI DSS Requirements Testing Procedures In Place Not in 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. 29 → 36

4.2.a Verify that strong cryptography ~~is used~~ whenever ~~cardholder data~~ is sent via end-user messaging technologies.

4.2.a Verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

Modified p. 29 → 36

4.2.b Verify the existence of a policy stating that ~~unencrypted~~ PANs are not to be sent via end-user messaging technologies.

4.2.b Verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies.

Modified p. 30 → 37

Requirement 5: Use and regularly update anti-virus software or programs Malicious software, commonly referred to as ~~“malware”~~

•including viruses, worms, and Trojans

•enters the network during many ~~business~~ approved activities including ~~employees’~~ e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.

Requirement 5: Use and regularly update anti-virus software or programs Malicious software, commonly referred to as ―malware‖

•including viruses, worms, and Trojans

•enters the network during many business- approved activities including employee e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats.

Modified p. 30 → 37

PCI DSS Requirements Testing Procedures In Place Not in ~~Place~~ Target Date/ ~~Comments~~ 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Modified p. 30 → 37

~~5.2d~~ For a sample of system components, verify that ~~antivirus~~ software log generation is enabled and that such logs are retained in accordance with PCI DSS Requirement ~~10.7~~

5.2.d For a sample of system components, verify that anti-virus software log generation is enabled and that such logs are retained in accordance with PCI DSS Requirement 10.7.

Removed p. 31

6.2.b Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information and updating the system configuration standards reviewed in Requirement 2.2 as new vulnerability issues are found.

Modified p. 31 → 38

PCI DSS Requirements Testing Procedures In Place Not in ~~Place~~ Target Date/ ~~Comments~~ 6.1 Ensure that all system components and software ~~have~~ the latest vendor-supplied security patches installed. Install critical security patches within one month of release. Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are addressed within one month, …

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 6.1 Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release. Note: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than less-critical internal devices, to ensure high-priority systems and devices are …

Modified p. 31 → 39

6.2.a Interview responsible personnel to verify that processes are implemented to identify new security vulnerabilities.

6.2.a Interview responsible personnel to verify that processes are implemented to identify new security vulnerabilities, and that a risk ranking is assigned to such vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be ranked as ―High.‖ 6.2.b Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information.

Modified p. 32 → 39

6.3.a Obtain and examine written software development processes to verify that the processes are based on industry ~~standards, security is included throughout the life cycle, and software applications are developed in accordance with PCI DSS.~~

6.3.a Obtain and examine written software development processes to verify that the processes are based on industry standards and/or best practices.

Modified p. 32 → 39

~~6.3.b~~ From an examination of written software development processes, interviews of software developers, ~~and examination of relevant data (network configuration documentation, production and test data, etc.),~~ verify that:

6.3.d From an examination of written software development processes, and interviews of software developers, verify that:

Modified p. 32 → 40

PCI DSS Requirements Testing Procedures In Place Not in ~~Place~~ Target Date/ ~~Comments 6.3 Develop software applications~~ in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices, and incorporate information security throughout the software development life cycle. These processes must include the following:

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 6.3.2 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.

Removed p. 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: 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. 33 → 40

~~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). …

 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 (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. 33 → 40

~~6.3.7.c~~ Select a sample of recent custom application changes and verify that custom application code is reviewed according to ~~6.3.7a and 6.3.7b~~ above.

6.3.2.b Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.3.2.a, above.

Modified p. 34 → 41

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:

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 6.4.5 Change control procedures for the implementation of security patches and software modifications. Procedures must include the following:

Modified p. 34 → 41

~~6.4.a Obtain and examine company~~ change-control procedures related to implementing security patches and software ~~modifications,~~ and ~~verify that the procedures~~ require items ~~6.4.1~~

• ~~6.4.4~~ below.

6.4.5.a Verify that change-control procedures related to implementing security patches and software modifications are documented and require items 6.4.5.1

• 6.4.5.4 below.

Modified p. 34 → 41

~~6.4.b~~ For a sample of system components and recent changes/security patches, trace those changes back to related change control documentation. For each change examined, perform the following:

6.4.5.b For a sample of system components and recent changes/security patches, trace those changes back to related change control documentation. For each change examined, perform the following:

Modified p. 34 → 41

6.5.a Obtain and review software development ~~processes for any web-based applications.~~ Verify that processes require training in secure coding techniques for developers, ~~and are~~ based on ~~guidance such as the OWASP guide (http://www.owasp.org).~~

6.5.a Obtain and review software development processes. Verify that processes require training in secure coding techniques for developers, based on industry best practices and guidance.

Modified p. 34 → 41

~~6.5.c~~ Verify that processes are in place to ensure that ~~web~~ applications are not vulnerable to the following:

6.5.c. Verify that processes are in place to ensure that applications are not vulnerable to, at a minimum, the following:

Modified p. 35 → 42

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.

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

Removed p. 36

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, 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: - 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 …

Modified p. 37 → 44

~~“Need~~ to ~~know”~~ is when access rights are granted to only the least amount of data and privileges needed to perform a job.

―Need to know‖ is when access rights are granted to only the least amount of data and privileges needed to perform a job.

Modified p. 37 → 44

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:

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:

Removed p. 39

Requirement 8: Assign a unique ID to each person with computer access.

Modified p. 39 → 46

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Requirement 8: Assign a unique ID to each person with computer access Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Modified p. 39 → 46

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.

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.

Modified p. 40 → 47

~~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.

 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. 41

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.

8.5.8.b Examine password policies/procedures to verify that group and shared passwords are explicitly prohibited.

Modified p. 41 → 48

8.5.8.c Interview system administrators to verify that group and shared passwords are not distributed, even if requested.

8.5.8.c Interview system administrators to verify that group and shared passwords or other authentication methods are not distributed, even if requested.

Removed p. 42

PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 8.5.11 Use passwords containing both numeric and alphabetic characters. 8.5.11 For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to contain both numeric and alphabetic characters. For service providers only, review internal processes and customer/user documentation to verify that customer passwords are required to contain both numeric and alphabetic characters.

Modified p. 43 → 50

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.

8.5.16.a Review database and application configuration settings and verify that all users are authenticated prior to access.

Modified p. 43 → 50

~~8.5.16.b~~ Review database applications and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes).

8.5.16.d Review database applications and the related application IDs to verify that application IDs can only be used by the applications (and not by individual users or other processes).

Modified p. 43 → 51

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.~~

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.

Removed p. 44

Requirement 9: Restrict physical access to cardholder data.

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. 45

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 the facility for a short duration, usually not more than one day.

Modified p. 45 → 52

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.

9.2.a Review processes and procedures for assigning badges to onsite personnel and visitors, and verify these processes include the following:

Modified p. 45 → 53

9.4.b Verify that the log contains the visitor’s name, the firm represented, and the ~~employee~~ authorizing physical access, and is retained for at least three months.

9.4.b Verify that the log contains the visitor’s name, the firm represented, and the onsite personnel authorizing physical access, and is retained for at least three months.

Modified p. 47 → 54

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:

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 9.10 Destroy media when it is no longer needed for business or legal reasons as follows:

Modified p. 47 → 54

9.10.1.a Verify that hard-copy materials are ~~cross-cut~~ shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.

9.10.1.a Verify that hard-copy materials are crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed.

Modified p. 47 → 54

9.10.1.b Examine storage containers used for information to be destroyed to verify that the containers are secured. For example, verify that a ~~“to-be-shredded”~~ container has a lock preventing access to its contents.

9.10.1.b Examine storage containers used for information to be destroyed to verify that the containers are secured. For example, verify that a ―to-be-shredded‖ container has a lock preventing access to its contents.

Removed p. 48

Requirement 10: Track and monitor all access to network resources and cardholder data.

Modified p. 48 → 55

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very ~~difficult~~ without system activity logs.

Requirement 10: Track and monitor all access to network resources and cardholder data Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

Removed p. 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 (to prevent a malicious individual from changing the clock). Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the NTP service (to prevent unauthorized use of internal time servers). See www.ntp.org for more information 10.5 Secure audit trails so they cannot be altered. 10.5 Interview system administrator and examine …

Modified p. 49 → 56

10.4.a Verify that ~~a known, stable version of NTP (Network Time Protocol) or similar technology,~~ kept current per PCI DSS Requirements 6.1 and ~~6.2, is used for time synchronization.~~

10.4.a Verify that time-synchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and 6.2.

Modified p. 50 → 57

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.~~

PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 10.4.3 Time settings are received from industry-accepted time sources.

Modified p. 50 → 58

10.7.b Verify that audit logs are available for at least one year and processes are in place to restore at least the last three months’ logs for ~~immediate~~ analysis.

10.7.b Verify that audit logs are available for at least one year and processes are in place to immediately restore at least the last three months’ logs for analysis.

Removed p. 51

11.1.a Verify that a wireless analyzer is used at least quarterly, or that a wireless IDS/IPS is implemented and configured to identify all wireless devices.

11.2.a Inspect output from the most recent four quarters of internal network, host, and application vulnerability scans to verify that periodic security testing of the devices within the cardholder data environment occurs. Verify that the scan process includes rescans until passing results are obtained. Note: External scans conducted after network changes, and internal scans, may be performed by the company’s qualified internal personnel or third parties.

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, …

Modified p. 51 → 59

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.~~

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 11.1 Test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis.

Modified p. 51 → 59

~~11.1.b~~ If a wireless ~~IDS/IPS is implemented,~~ verify the configuration will generate alerts to personnel.

11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to personnel.

Removed p. 52

11.2.c Verify that internal and/or external scanning is performed after any significant change in the network, by inspecting scan results for the last year. Verify that the scan process includes rescans until passing results are obtained.

Modified p. 52 → 60

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.

Note: It is not required that four passing quarterly scans must be completed for initial PCI DSS compliance if the 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 → 62

11.3.a Obtain and examine the results from the most recent penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment. ~~Verify that noted vulnerabilities were corrected and testing repeated.~~

11.3.a Obtain and examine the results from the most recent penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment.

Modified p. 52 → 62

~~11.3.b~~ Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

11.3.c Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).

Modified p. 52 → 62

11.4.a Verify the use of intrusion-detection systems and/or intrusion-prevention systems and that all traffic in the cardholder data environment is monitored.

11.4.a Verify the use of intrusion-detection systems and/or intrusion-prevention systems and that all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment is monitored.

Modified p. 53 → 62

~~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.

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. 53 → 63

~~Examples of files that should be monitored: ~~ System executables Application executables Configuration and parameter files Centrally stored, historical or archived, log and audit files

 System executables  Application executables  Configuration and parameter files  Centrally stored, historical or archived, log and audit files 11.5.b Verify the tools are configured to alert personnel to unauthorized modification of critical files, and to perform critical file comparisons at least weekly.

Modified p. 54 → 64

Requirement 12: Maintain a policy that addresses information security for ~~employees and contractors.~~

Requirement 12: Maintain a policy that addresses information security for all personnel.

Modified p. 54 → 64

A strong security policy sets the security tone for the whole ~~company~~ and informs ~~employees~~ what is expected of them. All ~~employees~~ should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of ~~this requirement, “employees”~~ refers to full-time and part-time employees, temporary ~~employees and personnel, and~~ contractors and consultants who are ~~“resident”~~ on the ~~company’s site.~~

A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of Requirement 12, ―personnel‖ refers to full-time and part-time employees, temporary employees, contractors and consultants who are ―resident‖ on the entity’s site or otherwise have access to the cardholder data environment.

Modified p. 54 → 64

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:

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:

Modified p. 55 → 65

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:

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.3 Develop usage policies for critical technologies (for example, remote- access technologies, wireless technologies, removable electronic media, laptops, tablets, personal data/digital assistants (PDAs), e-mail usage and Internet usage) and define proper use of these technologies. Ensure these usage policies require the following:

Modified p. 56 → 66

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.~~

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need.

Modified p. 57 → 67

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.

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 12.6 Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security.

Modified p. 57 → 67

12.6.a Verify the existence of a formal security awareness program for all ~~employees.~~

12.6.a Verify the existence of a formal security awareness program for all personnel.

Modified p. 57 → 67

12.6.1.b Verify that ~~employees~~ attend awareness training upon hire and at least annually.

12.6.1.b Verify that personnel attend awareness training upon hire and at least annually.

Removed p. 58

(12.9 continued on next page)

Modified p. 58 → 68

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.

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.

Modified p. 61 → 70

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 …

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:

Modified p. 61 → 70

A.1 Specifically for a PCI DSS assessment of a shared hosting provider, to verify that shared hosting providers protect entities’ (merchants and service providers) hosted environment and data, select a sample of servers (Microsoft Windows and Unix/Linux) across a representative sample of hosted merchants and service providers, and perform A.1.1 through A.1.4 ~~below.~~

A.1 Specifically for a PCI DSS assessment of a shared hosting provider, to verify that shared hosting providers protect entities’ (merchants and service providers) hosted environment and data, select a sample of servers (Microsoft Windows and Unix/Linux) across a representative sample of hosted merchants and service providers, and perform A.1.1 through A.1.4 below:

Modified p. 61 → 70

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.

Modified p. 62 → 71

A.1.2.b Verify each entity (merchant, service provider) has read, write, or execute permissions only for files and directories it owns or for necessary system files (restricted via file system permissions, access control lists, chroot, jailshell, ~~etc.). IMPORTANT:~~ An entity’s files may not be shared by group.

A.1.2.b Verify each entity (merchant, service provider) has read, write, or execute permissions only for files and directories it owns or for necessary system files (restricted via file system permissions, access control lists, chroot, jailshell, etc.) Important: An entity’s files may not be shared by group.

Modified p. 62 → 71

A.1.2.c Verify an entity’s users do not have write access to shared system binaries.

A.1.2.c Verify that an entity’s users do not have write access to shared system binaries.

Modified p. 62 → 71

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.~~

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:

Modified p. 62 → 71

~~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.

A.1.3 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. 63 → 72

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.) 3. Be ~~“above~~ and ~~beyond”~~ other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.) When evaluating ~~“above~~ and ~~beyond”~~ for compensating controls, consider the following:

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.) 3. Be ―above and beyond‖ other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.) When evaluating ―above and beyond‖ for compensating controls, consider the following:

Modified p. 63 → 72

b) Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review. For example, two-factor authentication is a PCI DSS requirement for remote access. Two-factor authentication from within the internal network can also be considered as a compensating control for non-console administrative access when transmission of encrypted passwords cannot be supported. Two- factor authentication may be an acceptable compensating control ~~if;~~ (1) it meets the …

b) Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area, but are not required for the item under review. For example, two-factor authentication is a PCI DSS requirement for remote access. Two-factor authentication from within the internal network can also be considered as a compensating control for non-console administrative access when transmission of encrypted passwords cannot be supported. Two- factor authentication may be an acceptable compensating control if: (1) it meets the …

Modified p. 63 → 72

c) Existing PCI DSS requirements may be combined with new controls to become a compensating control. For example, if a company is unable to render cardholder data unreadable per ~~requirement~~ 3.4 (for example, by encryption), a compensating control could consist of a device or combination of devices, applications, and controls that address all of the following: (1) internal network segmentation; (2) IP address or MAC address filtering; and (3) two-factor authentication from within the internal network.

c) Existing PCI DSS requirements may be combined with new controls to become a compensating control. For example, if a company is unable to render cardholder data unreadable per Requirement 3.4 (for example, by encryption), a compensating control could consist of a device or combination of devices, applications, and controls that address all of the following: (1) internal network segmentation; (2) IP address or MAC address filtering; and (3) two-factor authentication from within the internal network.

Modified p. 64 → 73

Note: Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance. ~~Requirement Number and Definition:~~

Note: Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.

Modified p. 65 → 74

Company XYZ employs stand-alone Unix Servers without LDAP. As such, they each require a ~~“root”~~ login. It is not possible for Company XYZ to manage the ~~“root”~~ login nor is it feasible to log all ~~“root”~~ activity by each user.

Company XYZ employs stand-alone Unix Servers without LDAP. As such, they each require a ―root‖ login. It is not possible for Company XYZ to manage the ―root‖ login nor is it feasible to log all ―root‖ activity by each user.

Modified p. 65 → 74

Company XYZ is going to require all users to log into the servers from their desktops using the SU command. SU allows a user to access the ~~“root”~~ account and perform actions under the ~~“root”~~ account but is able to be logged in the SU-log directory. In this way, each ~~user’s~~ actions can be tracked through the SU account.

Company XYZ is going to require all users to log into the servers from their desktops using the SU command. SU allows a user to access the ―root‖ account and perform actions under the ―root‖ account but is able to be logged in the SU-log directory. In this way, each user‘s actions can be tracked through the SU account.

Modified p. 65 → 74

Company XYZ demonstrates to assessor that the SU command being executed and that those individuals utilizing the command are logged to identify that the individual is performing actions under root ~~privileges~~

Company XYZ demonstrates to assessor that the SU command being executed and that those individuals utilizing the command are logged to identify that the individual is performing actions under root privileges.

Modified p. 65 → 74

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

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.

Removed p. 67

Part 1. Qualified Security Assessor Company Information Company Name:

Lead QSA Contact Name: Title:

Removed p. 67

Part 2. Merchant Organization Information Company Name: DBA(s):

Part 2a. Type of Merchant Business (check all that apply) Retailer Telecommunication Grocery and Supermarkets Petroleum E-Commerce Mail/Telephone-Order Travel & Entertainment Others (please specify):

List facilities and locations included in PCI DSS review:

Part 2b. Relationships Does your company have a relationship with one or more third-party agents (for example, gateways, web- hosting companies, airline booking agents, loyalty program agents, etc)? Yes No Does your company have a relationship with more than one acquirer? Yes No Part 2c. Transaction Processing Payment Application in use: Payment Application Version:

Removed p. 68

Compliant: All requirements in the ROC are marked “in place4,” and a passing scan has been completed by the PCI SSC Approved Scanning Vendor (ASV Name) thereby (Merchant Company Name) has demonstrated full compliance with the PCI DSS (insert version number).

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 brand(s) before completing Part 4, since not all payment brands require this section.

Part 3a. Confirmation of Compliant Status QSA/Merchant confirms:

The ROC was completed according to the PCI DSS Requirements and …

Removed p. 69

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.

Removed p. 70

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

Part 1. Qualified Security Assessor Company Information Company Name:

Lead QSA Contact Name: Title:

List facilities and locations included in PCI DSS review:

Removed p. 71

Part 2. Service Provider Organization Information Company Name: DBA(s):

Part 2a. Services Provided (check all that apply) Authorization Loyalty Programs 3-D Secure Access Control Server Switching IPSP (E-commerce) Process Magnetic-Stripe Transactions Payment Gateway Clearing & Settlement Process MO/TO Transactions Hosting Issuing Processing Others (please specify):

Part 2b. Relationships Does your company have a relationship with one or more third-party service providers (for example, gateways, web-hosting companies, airline booking agents, loyalty program agents, etc)? Yes No Part 2c. Transaction Processing How and in what capacity does your business store, process and/or transmit cardholder data? Payment Application in use: Payment Application Version:

The ROC was completed according to the PCI DSS Requirements and Security Assessment Procedures, Version (insert version number), and was completed according to the instructions therein.

All information within the above-referenced ROC and in this attestation fairly represents the results of the assessment in all material respects.

Lead QSA Name: Title:

Removed p. 72

Compliant: All requirements in the ROC are marked “in place8,” and a passing scan has been completed by the PCI SSC Approved Scanning Vendor (ASV Name) thereby (Service Provider Name) has demonstrated full compliance with the PCI DSS (insert version number).

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 Part 4, since not all payment brands require this section.

Part 3a. Confirmation of Compliant Status QSA and Service Provider confirm:

The Service Provider has read the PCI DSS and recognizes that …

Removed p. 73

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.

Document Comparison

Content Changes