Document Diff - PCI Watch

Added p. 5

PCI Data Security Standard

• High Level Overview Build and Maintain a Secure Network and Systems

1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program

5. Protect all systems against malware and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications Implement Strong Access Control Measures

7. Restrict access to cardholder data by business need to know 8. Identify and authenticate access to system components 9. Restrict physical access to cardholder data Regularly Monitor and Test Networks

PCI DSS comprises a minimum set of requirements for protecting cardholder data, and may be enhanced by additional controls and practices to further mitigate risks, as well as local, regional and sector laws and regulations. …

Added p. 7

PCI DSS applies to all entities involved in payment card processing•including merchants, processors, financial institutions, and service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.

Cardholder data and sensitive authentication data are defined as follows:

PCI DSS requirements apply to organizations and environments where account data (cardholder data and/or sensitive authentication data) is stored, processed or transmitted. Some PCI DSS requirements may also be applicable to organizations that have outsourced their payment operations or management of their CDE1. Additionally, organizations that outsource their CDE or payment operations to third parties are responsible for ensuring that the account data is protected by the third party per the applicable PCI DSS requirements.

Added p. 8

Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment. Organizations should contact their acquirer or the individual payment brands directly to understand whether SAD is permitted to be stored prior to authorization, for how long, and any related usage and protection requirements.

Added p. 9

All applications that store, process, or transmit cardholder data are in scope for an entity’s PCI DSS assessment, including applications that have been validated to PA-DSS. The PCI DSS assessment should verify the PA-DSS validated payment application is properly configured and securely implemented per PCI DSS requirements. If the payment application has undergone any customization, a more in-depth review will be required during the PCI DSS assessment, as the application may no longer be representative of the version that was validated to PA-DSS.

Applicability of PCI DSS to Payment Application Vendors

PCI DSS may apply to payment application vendors if the vendor stores, processes, or transmits cardholder data, or has access to their customers’ cardholder data (for example, in the role of a service provider).

Added p. 10

 Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE.

 Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

 Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances.

 Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS).

 Applications including all purchased and custom applications, including internal and external (for example, Internet) applications.

For each PCI DSS assessment, the assessor is required to validate that the scope of the assessment is accurately defined and documented.

Parties should clearly identify the services and system components which are included in the scope of the service provider’s PCI DSS assessment, the specific PCI DSS requirements covered …

Added p. 13

1. Monitoring of security controls•such as firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), file-integrity monitoring (FIM), anti-virus, access controls, etc.•to ensure they are operating effectively and as intended.

2. Ensuring that all failures in security controls are detected and responded to in a timely manner. Processes to respond to security control failures should include:

 Restoring the security control  Identifying the cause of failure  Identifying and addressing any security issues that arose during the failure of the security control  Implementing mitigation (such as process or technical controls) to prevent the cause of the failure recurring  Resuming monitoring of the security control, perhaps with enhanced monitoring for a period of time, to verify the control is operating effectively

3. Review changes to the environment (for example, addition of new systems, changes in system or network configurations) prior to completion of the change, and perform the following:

 Determine the potential impact to PCI …

Added p. 15

While it is acceptable for an assessor to sample business facilities/system components as part of their review of an entity’s PCI DSS compliance, it is not acceptable for an entity to apply PCI DSS requirements to only a sample of their environment (for example, requirements for quarterly vulnerability scans apply to all system components). Similarly, it is not acceptable for an assessor to only review a sample of PCI DSS requirements for compliance.

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 the entity’s compliance with 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 all of the types of system …

Added p. 17

The PCI DSS ROC Reporting Template must be used as the template for creating the Report on Compliance. The assessed entity should follow each payment brand’s respective reporting requirements to ensure each payment brand acknowledges the entity’s compliance status. Contact each payment brand or the acquirer to determine reporting requirements and instructions.

PCI DSS Assessment Process

1. Confirm the scope of the PCI DSS assessment.

2. Perform the PCI DSS assessment of the environment, following the testing procedures for each requirement.

3. If required, perform remediation for any not-in-place items.

4. Complete the applicable report for the assessment (i.e., Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC), including documentation of all compensating controls, according to the applicable PCI guidance and instructions.

Added p. 18

 Testing Procedures

• This column shows processes to be followed by the assessor to validate that PCI DSS requirements have been met and are “in place.”  Guidance

• This column describes the intent or security objective behind each of the PCI DSS requirements. This column contains guidance only, and is intended to assist understanding of the intent of each requirement. The guidance in this column does not replace or extend the PCI DSS Requirements and Testing Procedures.

Note: PCI DSS requirements are not considered to be in place if controls are not yet implemented or are scheduled to be completed at a future date. After any open or not-in-place items are addressed by the entity, the assessor will then reassess to validate that the remediation is completed and that all requirements are satisfied.

Please refer to the following resources (available on the PCI SSC website) to document the PCI DSS assessment:

 For …

Added p. 20

Network diagrams describe how networks are configured, and identify the location of all network devices.

Without current network diagrams, devices could be overlooked and be unknowingly left out of the security controls implemented for PCI DSS and thus be vulnerable to compromise.

Added p. 20

 Shows all cardholder data flows across systems and networks.  Is kept current and updated as needed upon changes to the environment.

Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network.

Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices.

Using a firewall on every Internet connection coming into (and out of) the network, and between any DMZ and the internal network, allows the organization to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection.

1.1.4.c Observe network configurations to verify that a firewall is in place at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone, per the documented configuration …

Added p. 23

1.2.3.a Examine firewall and router configurations to verify that there are perimeter firewalls installed between all wireless networks and the cardholder data environment.

The known (or unknown) implementation and exploitation of wireless technology within a network is a common path for malicious individuals to gain access to the network and cardholder data. If a wireless device or network is installed without the entity’s knowledge, a malicious individual could easily and “invisibly” enter the network. If firewalls do not restrict access from wireless networks into the CDE, malicious individuals that gain unauthorized access to the wireless network can easily connect to the CDE and compromise account information.

Firewalls must be installed between all wireless networks and the CDE, regardless of the purpose of the environment to which the wireless network is connected. This may include, but is not limited to, corporate networks, retail stores, guest networks, warehouse environments, etc.

A firewall's intent is to …

Added p. 26

If cardholder data is located within the DMZ, it is easier for an external attacker to access this information, since there are fewer layers to penetrate. Securing system components that store cardholder data in an internal network zone that is segregated from the DMZ and other untrusted networks by a firewall can prevent unauthorized network traffic from reaching the system component.

Note: This requirement is not intended to apply to temporary storage of cardholder data in volatile memory.

Restricting the disclosure of internal or private IP addresses is essential to prevent a hacker “learning” the IP addresses of the internal network, and using that information to access the network.

Methods used to meet the intent of this requirement may vary depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks.

 Specific configuration settings are defined for …

Added p. 27

Personnel need to be aware of and following security policies and operational procedures to ensure firewalls and routers are continuously managed to prevent unauthorized access to the network.

This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, Simple Network Management Protocol (SNMP) community strings, etc.).

2.1.a Choose a sample of system components, and attempt to log on (with system administrator help) to the devices and applications using default vendor-supplied accounts and passwords, to verify that ALL default passwords (including those on operating systems, software that provides security services, application and system accounts, POS terminals, and Simple Network Management Protocol (SNMP) community strings) have been changed. (Use vendor manuals and sources on the Internet to find vendor-supplied accounts/passwords.) Malicious individuals (external and internal to an organization) often use vendor default settings, account names, and …

Added p. 31

Enabling security features before new servers are deployed will prevent servers being installed into the environment with insecure configurations.

Ensuring that all insecure services, protocols, and daemons are adequately secured with appropriate security features makes it more difficult for malicious individuals to take advantage of commonly used points of compromise within a network.

System configuration standards and related processes should specifically address security settings and parameters that have known security implications for each type of system in use.

Added p. 32

PCI DSS Requirements Testing Procedures Guidance 2.2.4.c Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards.

In order for systems to be configured securely, personnel responsible for configuration and/or administering systems must be knowledgeable in the specific security parameters and settings that apply to the system.

Unnecessary functions can provide additional opportunities for malicious individuals to gain access to a system. By removing unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited.

Including this in server-hardening standards and processes addresses the specific security implications associated with unnecessary functions (for example, by removing/disabling FTP or the web server if the server will not be performing those functions).

If non-console (including remote) administration does not use secure authentication and encrypted communications, sensitive administrative or operational level …

Added p. 33

Personnel need to be aware of and following security policies and daily operational procedures to ensure vendor defaults and other security parameters are continuously managed to prevent insecure configurations.

This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client's data and thereby gain access to all other clients' data. See Appendix A for details of requirements.

 Legal, regulatory, and business requirements for data retention, including  Specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period …

Added p. 35

 There is a business justification and  The data is stored securely.

Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions.

3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured.

Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support issuing services to store sensitive authentication data ONLY IF they have a legitimate business need to store such data.

It should be noted that all PCI DSS requirements apply to …

Added p. 37

3.3.a Examine written policies and procedures for masking the display of PANs to verify:

 A list of roles that need access to displays of full PAN is documented, together with a legitimate business need for each role to have such access.  PAN must be masked when displayed such that only personnel with a legitimate business need can see the full PAN.  All other roles not specifically authorized to see the full PAN must only see masked PANs.

The display of full PAN on items such as computer screens, payment card receipts, faxes, or paper reports can result in this data being obtained by unauthorized individuals and used fraudulently. Ensuring that full PAN is only displayed for those with a legitimate business need to see the full PAN minimizes the risk of unauthorized persons gaining access to PAN data.

This requirement relates to protection of PAN displayed on screens, paper receipts, …

Added p. 40

 Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key  Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device)  As at least two full-length key components or key shares, in accordance with an industry- accepted method

Note: It is not required that public keys be stored in one of these forms.

3.5.2.a Examine documented procedures to verify that cryptographic keys used to encrypt/decrypt cardholder data must only exist in one (or more) of the following forms at all times.

 Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key  Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of- interaction device)  As key components or key …

Added p. 43

The encryption solution should not allow for or accept substitution of keys coming from unauthorized sources or unexpected processes. 3.6.7.b Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented.

This process will help ensure individuals that act as key custodians commit to the key-custodian role and understand and accept the responsibilities.

3.6.8.b Observe documentation or other evidence showing that key custodians have acknowledged (in writing or electronically) that they understand and accept their key- custodian responsibilities.

Added p. 43

Personnel need to be aware of and following security policies and documented operational procedures for managing the secure storage of cardholder data on a continuous basis.

 Only trusted keys and certificates are accepted.  The protocol in use only supports secure versions or configurations.  The encryption strength is appropriate for the encryption methodology in use.

Examples of open, public networks include but are not limited to:

4.1.a Identify all locations where cardholder data is transmitted or received over open, public networks. Examine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for all locations.

Sensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit.

Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection …

Added p. 45

 Weak encryption (for example, WEP, SSL version 2.0 or older) is not used as a security control for authentication or transmission.

Malicious users use free and widely available tools to eavesdrop on wireless communications. Use of strong cryptography can help limit disclosure of sensitive information across wireless networks.

Strong cryptography for authentication and transmission of cardholder data is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data.

E-mail, instant messaging, and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. Do not utilize these messaging tools to send PAN unless they are configured to provide strong encryption.

Added p. 45

Personnel need to be aware of and following security policies and operational procedures for managing the secure transmission of cardholder data on a continuous basis.

There is a constant stream of attacks using widely published exploits, often called "zero day" (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. Without an anti-virus solution that is updated regularly, these new forms of malicious software can attack systems, disable a network, or lead to compromise of data.

Added p. 46

It is important to protect against ALL types and forms of malicious software.

PCI DSS Requirements Testing Procedures Guidance 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software.

Added p. 47

Typically, mainframes, mid-range computers (such as AS/400) and similar systems may not currently be commonly targeted or affected by malware. However, industry trends for malicious software can change quickly, so it is important for organizations to be aware of new malware that might affect their systems•for example, by monitoring vendor security notices and anti-virus news groups to determine whether their systems might be coming under threat from new and evolving malware.

Trends in malicious software should be included in the identification of new security vulnerabilities, and methods to address new trends should be incorporated into the company's configuration standards and protection mechanisms as needed 5.2 Ensure that all anti-virus mechanisms are maintained as follows:

 Are kept current,  Perform periodic scans  Generate audit logs which are retained per PCI DSS Requirement 10.7.

Even the best anti-virus solutions are limited in effectiveness if they are not maintained and kept current with the …

Added p. 48

Personnel need to be aware of and following security policies and operational procedures to ensure systems are protected from malware on a continuous basis.

Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected.

Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk- assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the environment. In addition to the risk ranking, vulnerabilities may be considered “critical” if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems …

Added p. 50

 In accordance with PCI DSS (for example, secure authentication and logging)  Based on industry standards and/or best practices.  Incorporating information security throughout the software-development life cycle

Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.

Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment.

Understanding how sensitive data is handled by the application

•including when stored, transmitted, and when in memory

•can help identify where data needs to be protected.

6.3.d Interview software developers to verify that written software-development processes are implemented.

PCI DSS Requirements Testing Procedures Guidance 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.

Added p. 51

Development, test and/or custom application accounts, user IDs, and passwords should be removed from production code before the application becomes active or is released to customers, since these items may give away information about the functioning of the application. Possession of such information could facilitate compromise of the application and related cardholder data.

 Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.

 Code reviews ensure code is developed according to secure coding guidelines  Appropriate corrections are implemented prior to release.  Code-review results are reviewed and approved by management prior to release.

(Continued on next page) 6.3.2.a Examine written software-development procedures and interview responsible personnel to verify that all custom application code changes must be reviewed (using either manual or automated processes) as follows:

 Code changes are reviewed by individuals other than the originating code author, …

Added p. 52

 Development/test environments are separate from production environments with access control in place to enforce separation.  A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.  Production data (live PANs) are not used for testing or development.  Test data and accounts are removed before a production system becomes active.  Change control procedures related to implementing security patches and software modifications are documented.

Without properly documented and implemented change controls, security features could be inadvertently or deliberately omitted or rendered inoperable, processing irregularities could occur, or malicious code could be introduced.

6.4.1.a Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s).

Due to the constantly changing state of development and test environments, they tend to be less secure than the production environment. Without adequate separation between environments, it may be possible for …

Added p. 53

Test data and accounts should be removed from production code before the application becomes active, since these items may give away information about the functioning of the application or system. Possession of such information could facilitate compromise of the system and related cardholder data.

 Documentation of impact  Documented change approval by authorized parties  Functionality testing to verify that the change does not adversely impact the security of the system  Back-out procedures If not properly managed, the impact of software updates and security patches might not be fully realized and could have unintended consequences.

The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes.

Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by the organization.

For each change, there should be documented back-out procedures in case the change fails or adversely affects the security …

Added p. 56

 Validating input to verify user data cannot modify meaning of commands and queries.

 Utilizing parameterized queries.

Injection flaws, particularly SQL injection, are a commonly used method for compromising applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data, and allows the attacker to attack components inside the network through the application, to initiate attacks such as buffer overflows, or to reveal both confidential information and server application functionality.

Information should be validated before being sent to the application•for example, by checking for all alpha characters, mix of alpha and numeric characters, etc.

Added p. 56

 Validating buffer boundaries.

 Truncating input strings.

Buffer overflows occur when an application does not have appropriate bounds checking on its buffer space. This can cause the information in the buffer to be pushed out of the buffer’s memory space and into executable memory space. When this occurs, the attacker has the ability to insert malicious code at the end of the buffer and then push that malicious code into executable memory space by overflowing the buffer. The malicious code is then executed and often enables the attacker remote access to the application and/or infected system.

Added p. 56

 Prevent cryptographic flaws.

 Use strong cryptographic algorithms and keys.

Applications that do not utilize strong cryptographic functions properly to store data are at increased risk of being compromised, and exposing authentication credentials and/or cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain clear-text access to encrypted data.

PCI DSS Requirements Testing Procedures Guidance 6.5.4 Insecure communications 6.5.4 Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications.

Applications that fail to adequately encrypt network traffic using strong cryptography are at increased risk of being compromised and exposing cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain control of an application or even gain clear-text access to encrypted data.

Added p. 57

Applications can unintentionally leak information about their configuration or internal workings, or expose privileged information through improper error handling methods. Attackers use this weakness to steal sensitive data or compromise the system altogether. If a malicious individual can create errors that the application does not handle properly, they can gain detailed system information, create denial- of-service interruptions, cause security to fail, or crash the server. For example, the message "incorrect password provided" tells an attacker the user ID provided was accurate and that they should focus their efforts only on the password. Use more generic error messages, like "data could not be verified." 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).

Added p. 57

All vulnerabilities identified by an organization’s vulnerability risk-ranking process (defined in Requirement 6.1) to be “high risk” and that could affect the application should be identified and addressed during application development.

Web applications, both internally and externally (public) facing, have unique security risks based upon their architecture as well as the relative ease and occurrence of compromise.

Added p. 57

XSS flaws occur whenever an application takes user-supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser, which can hijack user sessions, deface web sites, possibly introduce worms, etc.

PCI DSS Requirements Testing Procedures Guidance 6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).

Added p. 58

 Proper authentication of users  Sanitizing input  Not exposing internal object references to users  User interfaces that do not permit access to unauthorized functions.

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

Consistently enforce access control in presentation layer and business logic for all URLs. Frequently, the only way an application protects sensitive functionality is by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

An attacker may be able to enumerate and navigate the directory structure of a website (directory traversal) thus gaining access to unauthorized information as well as gaining further insight into the workings of the …

Added p. 58

A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then enables the attacker to perform any state-changing operations the victim is authorized to perform (such as updating account details, making purchases, or even authenticating to the application).

PCI DSS Requirements Testing Procedures Guidance 6.5.10 Broken authentication and session management

Added p. 59

 Flagging session tokens (for example cookies) as  Not exposing session IDs in the URL  Incorporating appropriate time-outs and rotation of session IDs after a successful login.

Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user.

Note: This assessment is not the same as the vulnerability scans performed for Requirement 11.2.

 Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.

Added p. 59

Requirement 6.5 are included in the assessment - That all vulnerabilities are corrected - That the application is re-evaluated after the corrections.  Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:

- Is situated in front of public-facing web applications to detect and prevent web-based attacks. - Is actively running and up to date as applicable. - Is generating audit logs. - Is configured to either block web-based attacks, or generate an alert.

Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. The requirement for reviewing applications or installing web-application firewalls is intended to reduce the number of compromises on public-facing web applications due to poor coding or application management …

Added p. 60

Personnel need to be aware of and following security policies and operational procedures to ensure systems and applications are securely developed and protected from vulnerabilities on a continuous basis.

Added p. 61

 Defining access needs and privilege assignments for each role  Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities  Assignment of access based on individual personnel’s job classification and function  Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved.

The more people who have access to cardholder data, the more risk there is that a user’s account will be used maliciously. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through inexperience or malice.

Added p. 61

 System components and data resources that each role needs to access for their job function  Level of privilege required (for example, user, administrator, etc.) for accessing resources.

Added p. 61

 System components and data resources that each role needs to access for their job function  Identification of privilege necessary for each role to perform their job function.

In order to limit access to cardholder data to only those individuals who need such access, first it is necessary to define access needs for each role (for example, system administrator, call center personnel, store clerk), the systems/devices/data each role needs access to, and the level of privilege each role needs to effectively perform assigned tasks. Once roles and corresponding access needs are defined, individuals can be granted access accordingly.

7.1.2.a Interview personnel responsible for assigning access to verify that access to privileged user IDs is:

 Assigned only to roles that specifically require such privileged access  Restricted to least privileges necessary to perform job responsibilities.

When assigning privileged IDs, it is important to assign individuals only the privileges they need to perform their …

Added p. 62

Once needs are defined for user roles (per PCI DSS requirement 7.1.1), it is easy to grant individuals access according to their job classification and function by using the already-created roles.

Added p. 62

 Documented approval exists for the assigned privileges  The approval was by authorized parties  That specified privileges match the roles assigned to the individual.

Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function.

Without a mechanism to restrict access based on user’s need to know, a user may unknowingly be granted access to cardholder data. An access control system automates the process of restricting access and assigning privileges. Additionally, a default “deny-all” setting ensures no one is granted access until and unless a rule is established specifically granting such access.

Note: Some access control systems are set by default to “allow-all,” thereby permitting access unless/until a rule is written to specifically deny it.

Added p. 63

PCI DSS Requirements Testing Procedures Guidance 7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

Added p. 63

Personnel need to be aware of and following security policies and operational procedures to ensure that access is controlled and based on need- to-know and least privilege, on a continuous basis.

The effectiveness of a password is largely determined by the design and implementation of the authentication system•particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of entry, during transmission, and while in storage.

However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 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).

PCI DSS Requirements Testing Procedures Guidance 8.1 Define and implement policies and procedures to ensure proper user identification management for non- consumer users and administrators on all system …

Added p. 64

To ensure that user accounts granted access to systems are all valid and recognized users, strong processes must manage all changes to user IDs and other authentication credentials, including adding new ones and modifying or deleting existing ones.

Added p. 64

8.1.3.a Select a sample of users terminated in the past six months, and review current user access lists

•for both local and remote access

•to verify that their IDs have been deactivated or removed from the access lists.

If an employee has left the company and still has access to the network via their user account, unnecessary or malicious access to cardholder data could occur•either by the former employee or by a malicious user who exploits the old and/or unused account. To prevent unauthorized access, user credentials and other authentication methods therefore need to be revoked promptly (as soon as possible) upon the employee’s departure.

8.1.3.b Verify all physical authentication methods

•such as, smart cards, tokens, etc.

•have been returned or deactivated.

PCI DSS Requirements Testing Procedures Guidance 8.1.4 Remove/disable inactive user accounts at least every 90 days.

Added p. 65

Accounts that are not used regularly are often targets of attack since it is less likely that any changes (such as a changed password) will be noticed. As such, these accounts may be more easily exploited and used to access cardholder data.

Added p. 65

 Enabled only during the time period needed and disabled when not in use.

 Monitored when in use.

8.1.5.a Interview personnel and observe processes for managing accounts used by vendors to access, support, or maintain system components to verify that accounts used by vendors for remote access are:

 Disabled when not in use  Enabled only when needed by the vendor, and disabled when not in use.

Allowing vendors to have 24/7 access into your network in case they need to support your systems increases the chances of unauthorized access, either from a user in the vendor’s environment or from a malicious individual who finds and uses this always-available external entry point into your network. Enabling access only for the time periods needed, and disabling it as soon as it is no longer needed, helps prevent misuse of these connections.

Monitoring of vendor access provides assurance that vendors are accessing only the systems …

Added p. 65

8.1.6.a For a sample of system components, inspect system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than six invalid logon attempts.

Without account-lockout mechanisms in place, an attacker can continually attempt to guess a password through manual or automated tools (for example, password cracking), until they achieve success and gain access to a user’s account. 8.1.6.b Additional testing procedure for service providers: Review internal processes and customer/user documentation, and observe implemented processes to verify that non- consumer user accounts are temporarily locked-out after not more than six invalid access attempts.

Added p. 65

If an account is locked out due to someone continually trying to guess a password, controls to delay reactivation of these locked accounts stops the malicious individual from continually guessing the password (they will have to stop for a minimum of 30 minutes until the account is reactivated). Additionally, if reactivation must be requested, the admin or help desk can validate that it is the actual account owner requesting reactivation.

PCI DSS Requirements Testing Procedures Guidance 8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Added p. 66

When users walk away from an open machine with access to critical system components or cardholder data, that machine may be used by others in the user’s absence, resulting in unauthorized account access and/or misuse.

The re-authentication can be applied either at the system level to protect all sessions running on that machine, or at the application level.

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

These authentication methods, when used in addition to unique IDs, help protect users’ IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used). Note that a digital certificate is a valid option for “something you have” as long as it is unique for a particular user.

Since one of the first steps …

Added p. 67

Many malicious individuals use "social engineering”

•for example, calling a help desk and acting as a legitimate user

•to have a password changed so they can utilize a user ID. Consider use of a “secret question” that only the proper user can answer to help administrators identify the user prior to re-setting or modifying authentication credentials.

PCI DSS Requirements Testing Procedures Guidance 8.2.3 Passwords/phrases must meet the following:

Added p. 68

Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.

8.2.3a For a sample of system components, inspect system configuration settings to verify that user password parameters are set to require at least the following strength/complexity:

Strong passwords/phrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non- existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.

This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/phrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. NIST SP 800- 63-1 defines “entropy” as “a measure …

Added p. 68

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

Passwords/phrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.

8.2.4.b Additional testing procedure for service providers: Review internal processes and customer/user documentation to verify that:

 Non-consumer user passwords are required to change periodically; and  Non-consumer users are given guidance as to when, and under what circumstances, passwords must change.

PCI DSS Requirements Testing Procedures Guidance 8.2.5 Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she has used.

8.2.5.a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords cannot be …

Added p. 69

If the same password is used for every new user, an internal user, former employee, or malicious individual may know or easily discover this password, and use it to gain access to accounts.

Added p. 69

Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication.

8.3.a Examine system configurations for remote access servers and systems to verify two-factor authentication is required for:

 All remote access by personnel  All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).

Two-factor authentication requires two forms of authentication for higher-risk accesses, such as those originating from outside the network This requirement is intended to apply to all personnel

•including general users, administrators, and vendors (for support or maintenance) with remote access to the network

•where that remote access could lead to access to the cardholder data environment.

If remote access is to an entity’s network that has appropriate segmentation, such that remote users cannot access or impact the cardholder data environment, two-factor authentication for remote access to that …

Added p. 71

To prevent the compromise of multiple customers through the use of a single set of credentials, vendors with remote access accounts to customer environments should use a different authentication credential for each customer.

Technologies, such as two-factor mechanisms, that provide a unique credential for each connection (for example, via a single-use password) could also meet the intent of this requirement.

Added p. 71

 Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.  Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.

8.6.a Examine authentication policies and procedures to verify that procedures for using authentication mechanisms such as physical security tokens, smart cards, and certificates are defined and include:

 Authentication mechanisms are assigned to an individual account and not shared among multiple accounts.  Physical and/or logical controls are defined to ensure only the intended account can use that mechanism to gain access.

If user authentication mechanisms such as tokens, smart cards, and certificates can be used by multiple accounts, it may be impossible to identify the individual using the authentication mechanism. Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely identify the user of the account will prevent …

Added p. 74

For example, network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks.

Added p. 74

Restricting access to network jacks (or network ports) will prevent malicious individuals from plugging into readily available network jacks and gain access into internal network resources.

Whether logical or physical controls, or a combination of both, are used, they should be sufficient to prevent an individual or device that is not explicitly authorized from being able to connect to the network.

Without security over access to wireless components and devices, malicious users could use an organization’s unattended wireless devices to access network resources, or even connect their own devices to the wireless network to gain unauthorized access. Additionally, securing networking and communications hardware prevents malicious users from intercepting network traffic or physically connecting their own devices to wired network resources.

 Identifying new onsite personnel or visitors (for example, assigning badges)  Changes to access requirements  Revoking or terminating onsite personnel and expired visitor identification (such as ID badges).

9.2.a Review documented processes …

Added p. 75

 Access must be authorized and based on individual job function.  Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled.

9.3.a For a sample of onsite personnel with physical access to the CDE, interview responsible personnel and observe access control lists to verify that:

 Access to the CDE is authorized.  Access is required for the individual’s job function.

Controlling physical access to the CDE helps ensure that only authorized personnel with a legitimate business need are granted access.

When personnel leave the organization, all physical access mechanisms should be returned or disabled promptly (as soon as possible) upon their departure, to ensure personnel cannot gain physical access to the CDE once their employment has ended.

9.3.b Observe personnel access the CDE to verify that all personnel are authorized before being granted access.

9.3.c Select a sample of recently terminated employees and …

Added p. 76

9.4.4.b Verify that the log contains:

 The visitor’s name,  The firm represented, and  The onsite personnel authorizing physical access.

9.4.4.c Verify that the log is retained for at least three months.

Controls for physically securing media are intended to prevent unauthorized persons from gaining access to cardholder data on any type of media. Cardholder data is susceptible to unauthorized viewing, copying, or scanning if it is unprotected while it is on removable or portable media, printed out, or left on someone’s desk.

If stored in a non-secured facility, backups that contain cardholder data may easily be lost, stolen, or copied for malicious intent.

Periodically reviewing the storage facility enables the organization to address identified security issues in a timely manner, minimizing the potential risk.

Procedures and processes help protect cardholder data on media distributed to internal and/or external users. Without such procedures data can be lost or stolen and used for fraudulent purposes.

It …

Added p. 78

Without a firm process for ensuring that all media movements are approved before the media is removed from secure areas, the media would not be tracked or appropriately protected, and its location would be unknown, leading to lost or stolen media.

Without careful inventory methods and storage controls, stolen or missing media could go unnoticed for an indefinite amount of time.

 Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard- copy materials cannot be reconstructed.  Storage containers used for materials that are to be destroyed must be secured.  Cardholder data on electronic media must be rendered unrecoverable via a secure wipe program (in accordance with industry-accepted standards for secure deletion), or by physically destroying the media.

If steps are not taken to destroy information contained on hard disks, portable drives, CD/DVDs, or paper prior to disposal, malicious individuals may be able to …

Added p. 79

Criminals attempt to steal cardholder data by stealing and/or manipulating card-reading devices and terminals. For example, they will try to steal devices so they can learn how to break into them, and they often try to replace legitimate devices with fraudulent devices that send them payment card information every time a card is entered. Criminals will also try to add “skimming” components to the outside of devices, which are designed to capture payment card details before they even enter the device•for example, by attaching an additional card reader on top of the legitimate card reader so that the payment card details are captured twice: once by the criminal’s component and then by the device’s legitimate component. In this way, transactions may still be completed without interruption while the criminal is “skimming” the payment card information during the process.

This requirement is recommended, but not required, for manual key-entry components such as …

Added p. 79

 Make, model of device  Location of device (for example, the address of the site or facility where the device is located)  Device serial number or other method of unique identification.

 Make, model of device  Location of device (for example, the address of the site or facility where the device is located)  Device serial number or other method of unique identification.

9.9.1.a Examine the list of devices to verify it includes:

Keeping an up-to-date list of devices helps an organization keep track of where devices are supposed to be, and quickly identify if a device is missing or lost.

The method for maintaining a list of devices may be automated (for example, a device-management system) or manual (for example, documented in electronic or paper records). For on-the-road devices, the location may include the name of the personnel to whom the device is assigned.

9.9.1.b Select a sample of devices from …

Added p. 81

Personnel need to be aware of and following security policies and operational procedures for restricting physical access to cardholder data and CDE systems on a continuous basis.

 Audit trails are enabled and active for system components.  Access to system components is linked to individual users.

It is critical to have a process or system that links user access to system components accessed. This system generates audit logs and provides the ability to trace back suspicious activity to a specific user.

Generating audit trails of suspect activities alerts the system administrator, sends data to other monitoring mechanisms (like intrusion detection systems), and provides a history trail for post- incident follow-up. Logging of the following events enables an organization to identify and trace potentially malicious activities 10.2.1 All individual user accesses to cardholder data 10.2.1 Verify all individual access to cardholder data is logged. Malicious individuals could obtain knowledge of a user account …

Added p. 83

Without knowing who was logged on at the time of an incident, it is impossible to identify the accounts that may have been used. Additionally, malicious users may attempt to manipulate the authentication controls with the intent of bypassing them or impersonating a valid account.

10.2.5.b Verify all elevation of privileges is logged.

10.2.5.c Verify all changes, additions, or deletions to any account with root or administrative privileges are logged.

 Initialization of audit logs  Stopping or pausing of audit logs.

Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions.

Malicious software, such as malware, often creates or replaces system level objects on the target system in order to control a particular function or operation on that system. By logging …

Added p. 86

File-integrity monitoring or change-detection systems check for changes to critical files, and notify when such changes are noted. For file- integrity monitoring purposes, an entity usually monitors files that don’t regularly change, but when changed indicate a possible compromise.

Added p. 86

Regular log reviews by personnel or automated means can identify and proactively address unauthorized access to the cardholder data environment.

The log review process does not have to be manual. The use of log harvesting, parsing, and alerting tools can help facilitate the process by identifying log events that need to be reviewed.

PCI DSS Requirements Testing Procedures Guidance 10.6.1 Review the following at least daily:

 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD  Logs of all critical system components  Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

 All security events  Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD …

Added p. 87

10.6.2.a Examine security policies and procedures to verify that procedures are defined for reviewing logs of all other system components periodically

•either manually or via log tools

•based on the organization’s policies and risk management strategy.

Logs for all other system components should also be periodically reviewed to identify indications of potential issues or attempts to gain access to sensitive systems via less-sensitive systems. The frequency of the reviews should be determined by an entity’s annual risk assessment. 10.6.2.b Examine the organization’s risk-assessment documentation and interview personnel to verify that reviews are performed in accordance with organization’s policies and risk management strategy.

PCI DSS Requirements Testing Procedures Guidance 10.6.3 Follow up exceptions and anomalies identified during the review process.

10.6.3.a Examine security policies and procedures to verify that procedures are defined for following up on exceptions and anomalies identified during the review process.

If exceptions and anomalies identified during the log-review process are not investigated, the …

Added p. 88

Personnel need to be aware of and following security policies and daily operational procedures for monitoring all access to network resources and cardholder data on a continuous basis.

11.1.a Examine policies and procedures to verify processes are defined for detection and identification of both authorized and unauthorized wireless access points on a quarterly basis.

Implementation and/or exploitation of wireless technology within a network are some of the most common paths for malicious users to gain access to the network and cardholder data. If a wireless device or network is installed without a company’s knowledge, it can allow an attacker to easily and “invisibly” enter the network. Unauthorized wireless devices may be hidden within or attached to a computer or other system component, or be attached directly to a network port or network device, such as a switch or router. Any such unauthorized device could result in an unauthorized access point into the …

Added p. 90

For example: In the case of a single standalone retail kiosk in a shopping mall, where all communication components are contained within tamper-resistant and tamper-evident casings, performing a detailed physical inspection of the kiosk itself may be sufficient to provide assurance that a rogue wireless access point has not been attached or installed. However, in an environment with multiple nodes (such as in a large retail store, call center, server room or data center), detailed physical inspection is difficult. In this case, multiple methods may be combined to meet the requirement, such as performing physical system inspections in conjunction with the results of a wireless analyzer.

Added p. 90

11.1.2.b Interview responsible personnel and/or inspect recent wireless scans and related responses to verify action is taken when unauthorized wireless access points are found.

Note: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed.

A vulnerability scan is an automated tool run against external and internal network devices and servers, designed to expose potential vulnerabilities that could be found and exploited by malicious individuals.

There are three types of vulnerability scanning required for PCI DSS:

 Internal quarterly vulnerability scanning by qualified personnel (use of a PCI SSC Approved Scanning Vendor (ASV) is not required)  External quarterly vulnerability scanning, which must be performed by an ASV  Internal and external scanning as needed after significant changes Once these weaknesses are identified, …

Added p. 91

An established process for identifying vulnerabilities on internal systems requires that vulnerability scans be conducted quarterly. Vulnerabilities posing the greatest risk to the environment (for example, ranked “High” per Requirement 6.1) should be resolved with the highest priority.

Internal vulnerability scans can be performed by qualified, internal staff that are reasonably independent of the system component(s) being scanned (for example, a firewall administrator should not be responsible for scanning the firewall), or an entity may choose to have internal vulnerability scans performed by a firm specializing in vulnerability scanning.

Added p. 92

Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.

As external networks are at greater risk of compromise, quarterly external vulnerability scanning must be performed by a PCI SSC Approved Scanning Vendor (ASV).

The determination of what constitutes a significant change is highly dependent on the configuration of a given environment. If an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment, then it could be considered significant.

Scanning an environment after any significant changes are made ensures that changes were completed appropriately such that the security of the environment was not compromised as a result of the change. All system components affected by the change will need to be scanned.

 For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.

Added p. 93

 Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)  Includes coverage for the entire CDE perimeter and critical systems  Includes testing from both inside and outside the network  Includes testing to validate any segmentation and scope-reduction controls  Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5  Defines network-layer penetration tests to include components that support network functions as well as operating systems  Includes review and consideration of threats and vulnerabilities experienced in the last 12 months  Specifies retention of penetration testing results and remediation activities results.

Note: This update to Requirement 11.3 is a best practice until June 30, 2015, after which it becomes a requirement. PCI DSS v2.0 requirements for penetration testing must be followed until v3.0 is in place.

Added p. 93

 Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)  Includes coverage for the entire CDE perimeter and critical  Testing from both inside and outside the network  Includes testing to validate any segmentation and scope- reduction controls  Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5  Defines network-layer penetration tests to include components that support network functions as well as operating systems  Includes review and consideration of threats and vulnerabilities experienced in the last 12 months  Specifies retention of penetration testing results and remediation activities results.

The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment. This allows an entity to gain a better understanding of their potential exposure and develop a strategy to defend against …

Added p. 94

11.3.2.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).

Added p. 95

PCI DSS Requirements Testing Procedures Guidance 11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.

11.3.4.a Examine segmentation controls and review penetration-testing methodology to verify that penetration- testing procedures are defined to test all segmentation methods to confirm they are operational and effective, and isolate all out-of-scope systems from in-scope systems.

Penetration testing is an important tool to confirm that any segmentation in place to isolate the CDE from other networks is effective. The penetration testing should focus on the segmentation controls, both from outside the entity’s network and from inside the network but outside of the CDE, to confirm that they are not able to get through the segmentation controls to access the CDE. For example, network …

Added p. 96

Personnel need to be aware of and following security policies and operational procedures for security monitoring and testing on a continuous basis.

A company's information security policy creates the roadmap for implementing security measures to protect its most valuable assets. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it.

Security threats and protection methods evolve rapidly. Without updating the security policy to reflect relevant changes, new protection measures to fight against these threats are not addressed.

Added p. 97

 Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.),  Identifies critical assets, threats, and vulnerabilities, and  Results in a formal risk assessment.

Examples of risk-assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.

12.2.a Verify that an annual risk-assessment process is documented that identifies assets, threats, vulnerabilities, and results in a formal risk assessment.

A risk assessment enables an organization to identify threats and associated vulnerabilities with the potential to negatively impact their business. Resources can then be effectively allocated to implement controls that reduce the likelihood and/or the potential impact of the threat being realized.

Performing risk assessments at least annually and upon significant changes allows the organization to keep up to date with organizational changes and evolving threats, trends, and technologies.

Note: Examples of critical technologies include, but are not limited to, remote access and …

Added p. 100

 The following information security responsibilities are specifically and formally assigned:

Each person or team with responsibilities for information security management should be clearly aware of their responsibilities and related tasks, through specific policy. Without this accountability, gaps in processes may open access into critical resources or cardholder data.

PCI DSS Requirements Testing Procedures Guidance 12.5.4 Administer user accounts, including additions, deletions, and modifications.

12.6.a Review the security awareness program to verify it provides awareness to all personnel about the importance of cardholder data security.

If personnel are not educated about their security responsibilities, security safeguards and processes that have been implemented may become ineffective through errors or intentional actions. 12.6.b Examine security awareness program procedures and documentation and perform the following:

If the security awareness program does not include periodic refresher sessions, key security processes and procedures may be forgotten or bypassed, resulting in exposed critical resources and cardholder data. 12.6.1.b Verify that personnel …

Added p. 102

If a merchant or service provider shares cardholder data with a service provider, certain requirements apply to ensure continued protection of this data will be enforced by such service providers.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.

Added p. 103

The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.

In conjunction with Requirement 12.9, this requirement for written agreements between organizations and service provides is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.

The process ensures that any engagement of a service provider is thoroughly vetted internally by an organization, which should include a risk analysis prior to establishing a formal relationship with the service provider.

Specific due-diligence processes and goals will vary for each organization. Examples of considerations may include the provider’s reporting practices, breach-notification and incident response procedures, details of how PCI DSS responsibilities are assigned between each party, how the provider validates their PCI DSS compliance and what evidence …

Added p. 104

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

Added p. 104

This requirement applies when the entity being assessed is a service provider. In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.

The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.

Without a thorough security incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of a unified response could create further downtime for the business, unnecessary public media exposure, as well as new legal liabilities.

12.10.1.a Verify that the incident response plan includes:

The incident response plan should be thorough and contain all the key elements to allow your company to respond effectively in the event …

Added p. 106

Without a trained and readily available incident response team, extended damage to the network could occur, and critical data and systems may become “polluted” by inappropriate handling of the targeted systems. This can hinder the success of a post-incident investigation.

These monitoring systems are designed to focus on potential risk to data, are critical in taking quick action to prevent a breach, and must be included in the incident-response processes.

Incorporating “lessons learned” into the incident response plan after an incident helps keep the plan current and able to react to emerging threats and security trends.

Added p. 107

Appendix A of PCI DSS is intended for shared hosting providers who wish to provide their merchant and/or service provider customers with a PCI DSS compliant hosting environment.

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

If a merchant or service provider is allowed to run their own applications on the shared server, these should run with the user ID of the merchant or service provider, rather than as a privileged user.

To ensure that access and privileges are restricted such that each merchant or service provider has access only to their own environment, consider the following:

1. Privileges of the merchant’s or service provider’s web server user ID;

2. Permissions granted to read, write, and execute files;

3. Permissions granted to write to system binaries;

4. Permissions granted to merchant’s and service …

Added p. 109

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

10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes Maintain an Information Security Policy 12. Maintain a policy that addresses information security for all personnel 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 …

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

Modified p. 6

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.

Note: Information Supplements complement the PCI DSS and identify additional considerations and recommendations for meeting PCI DSS requirements•they do not supersede, replace or extend the PCI DSS or any of its requirements.

Removed p. 7

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

If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with all PCI DSS requirements except Requirements 3.3 and 3.4, which apply only to PAN.

PCI DSS represents a minimum set of control objectives which may be enhanced by local, regional and sector laws and regulations. Additionally, legislation or regulatory requirements may require specific protection of personally identifiable information or other data elements (for example, cardholder name), or define an entity’s disclosure practices related to consumer information. Examples include legislation related to consumer data protection, privacy, identity theft, or data security. PCI DSS does not supersede local or regional laws, government regulations, or other legal requirements.

Modified p. 7

Cardholder Data includes: Sensitive Authentication Data includes:

Account Data Cardholder Data includes: Sensitive Authentication Data includes:

Modified p. 7

 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 applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed or transmitted, PCI DSS requirements do not apply.~~

 Primary Account Number (PAN)  Cardholder Name  Expiration Date  Service Code  Full track data (magnetic-stripe data or equivalent on a chip)  CAV2/CVC2/CVV2/CID  PINs/PIN blocks The primary account number is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with applicable PCI DSS requirements.

Modified p. 7

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.

The table on the following page 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.

Removed p. 8

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

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

Removed p. 9

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 to connect to the application to provide support to the customer.

The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties.

Please note the following regarding PA-DSS applicability:

 PA-DSS does apply to payment applications that are typically sold and installed ―off the shelf‖ without much customization by software vendors.

 PA-DSS does not apply to payment applications developed by merchants and …

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

The PA-DSS requirements are derived from the PCI DSS Requirements and Security Assessment Procedures (defined in this document). The PA-DSS details the requirements a payment application must meet in order to facilitate a customer’s PCI DSS compliance.

Modified p. 9

Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of 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.

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

Modified p. 9

~~For detailed guidance on determining~~ whether PA-DSS applies to a given payment application, please refer to the PA-DSS ~~Requirements and Security Assessment Procedures,~~ which can be found at www.pcisecuritystandards.org.

To determine whether PA-DSS applies to a given payment application, please refer to the PA-DSS Program Guide, which can be found at www.pcisecuritystandards.org.

Modified p. 10

The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope. To confirm the accuracy and appropriateness of PCI DSS scope, perform the following:

 Any other component or device located within or connected to the CDE The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope. To confirm the accuracy and appropriateness of PCI DSS scope, …

Modified p. 10

 The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined ~~cardholder data environment (CDE).~~

 The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined CDE.

Modified p. 10

 The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the ~~CDE unless~~ such data ~~is deleted or migrated/consolidated~~ into the currently defined ~~CDE.~~

 The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE. If the entity identifies data that is not currently included in the CDE, such data should be securely deleted, migrated into the currently defined CDE, or the CDE redefined to include this data.

Modified p. 10

 The entity retains documentation that shows how PCI DSS scope was ~~confirmed and the results,~~ for assessor review and/or for reference during the next annual PCI ~~SCC~~ scope confirmation activity.

 The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity.

Modified p. 10 → 11

 The scope of the PCI DSS assessment  The cost of the PCI DSS assessment  The cost and difficulty of implementing and maintaining PCI DSS controls  The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)

 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 a number of physical or logical means, such as properly …

Removed p. 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 assessed entity and which apply to the service provider. There are two options for third-party service providers to validate compliance:

Modified p. 11

If wireless technology is used to store, process, or transmit cardholder data (for example, point-of-sale transactions, ~~―line-busting‖),~~ or if a wireless local area network (WLAN) is ~~connected to, or~~ part of, the cardholder data ~~environment (for example, not clearly separated by a firewall),~~ the PCI DSS requirements and testing procedures for wireless environments apply and must be performed (for example, Requirements 1.2.3, 2.1.1, and 4.1.1). Before wireless technology is implemented, an entity should carefully evaluate the need for the technology …

If wireless technology is used to store, process, or transmit cardholder data (for example, point-of-sale transactions, “line-busting”), or if a wireless local area network (WLAN) is part of, or connected to the cardholder data environment, the PCI DSS requirements and testing procedures for wireless environments apply and must be performed (for example, Requirements 1.2.3, 2.1.1, and 4.1.1). Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider deploying wireless technology only …

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

Modified p. 12 → 15

As an example, the assessor may define a sample at a business facility to include 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 running ~~MYSQL.~~ If all applications run from a single version of an OS (for example, Windows 7 or Solaris 10), ~~then~~ the sample should still include a variety of applications (for example, database servers, web servers, ~~data transfer~~ servers).

As an example, the assessor may define a sample at a business facility to include Sun servers running Apache, Windows servers running Oracle, mainframe systems running legacy card processing applications, data-transfer servers running HP-UX, and Linux Servers running MySQL. If all applications run from a single version of an OS (for example, Windows 7 or Solaris 10), the sample should still include a variety of applications (for example, database servers, web servers, data-transfer servers).

Modified p. 12 → 15

 If there are ~~standard,~~ centralized PCI DSS security and operational processes and controls in place that ensure consistency and that each business facility/system component must follow, the sample can be smaller than if there are no standard processes/controls in place. The sample must be large enough to provide the assessor with reasonable assurance that all business facilities/system components are configured per the standard processes.

 If there are standardized, centralized PCI DSS security and operational processes and controls in place that ensure consistency and that each business facility/system component must follow, the sample can be smaller than if there are no standard processes/controls in place. The sample must be large enough to provide the assessor with reasonable assurance that all business facilities/system components are configured per the standard processes. The assessor must verify that the standardized, centralized controls are implemented and working effectively.

Modified p. 13 → 16

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.

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

Report Content and Format Follow these instructions for report content and format when completing a Report on Compliance:

1. Executive Summary Include the following:

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

Modified p. 18 → 17

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

5. Complete the Attestation of Compliance for Service Providers or Merchants, as applicable, in its entirety. Attestations of Compliance are available on the PCI SSC website.

Modified p. 18 → 17

4. Submit the ROC, ~~evidence of a passing scan,~~ and the Attestation of Compliance, along with any other requested ~~documentation,~~ to the acquirer (for merchants) or to the payment brand or other requester (for service providers).

6. Submit the SAQ or ROC, and the Attestation of Compliance, along with any other requested documentation

•such as ASV scan reports to the acquirer (for merchants) or to the payment brand or other requester (for service providers).

Removed p. 19

 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- compliant reports, please refer to the Attestations of Compliance, available on the PCI SSC website (www.pcisecuritystandards.org).

 Target Date/Comments

• For those controls ―Not in Place‖ the assessor …

Modified p. 19 → 18

 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 requirements; PCI DSS compliance is validated against these requirements.

Modified p. 20 → 19

Other system components may provide firewall functionality, ~~provided~~ they meet the minimum requirements for firewalls as ~~provided~~ in Requirement 1. Where other system components are used within the cardholder data environment to provide firewall functionality, these devices must be included within the scope and assessment of Requirement 1.

Other system components may provide firewall functionality, as long as they meet the minimum requirements for firewalls as defined in Requirement 1. Where other system components are used within the cardholder data environment to provide firewall functionality, these devices must be included within the scope and assessment of Requirement 1.

Modified p. 20 → 19

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

PCI DSS Requirements Testing Procedures Guidance 1.1 Establish and implement firewall and router configuration standards that include the following:

Modified p. 20

1.1.2.b ~~Verify~~ that the diagram is kept current.

1.1.2.b Interview responsible personnel to verify that the diagram is kept current.

Modified p. 20

~~1.1.3.b~~ Verify that the current network diagram is consistent with the firewall configuration standards.

1.1.4.b Verify that the current network diagram is consistent with the firewall configuration standards.

Removed p. 21

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 1.1.4 Description of groups, roles, and responsibilities for logical management of network components 1.1.4 Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components.

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

~~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.6.a Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each•for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.

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

1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that security features are documented for each service.

Modified p. 21 → 22

~~1.1.6.b Obtain~~ and ~~examine documentation~~ to verify that the rule sets are reviewed at least every six months.

1.1.7.b Examine documentation relating to rule set reviews and interview responsible personnel to verify that the rule sets are reviewed at least every six months.

Modified p. 21 → 22

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.

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

~~1.2.1.a Verify~~ that inbound and outbound traffic is limited to that which is necessary for the cardholder data ~~environment, and that the restrictions are documented.~~

1.2.1.b Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Modified p. 22 → 23

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

PCI DSS Requirements Testing Procedures Guidance 1.2.2 Secure and synchronize router configuration files.

Removed p. 23

1.4.a Verify that mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), and which are used to access the organization’s network, have personal firewall software installed and active.

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. 23 → 26

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 …

PCI DSS Requirements Testing Procedures Guidance 1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.

Modified p. 23 → 26

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

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

Modified p. 23 → 26

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.a Examine firewall and router configurations to verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet.

Modified p. 23 → 26

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

1.3.8.b Interview personnel and examine documentation to verify that any disclosure of private IP addresses and routing information to external entities is authorized.

Modified p. 24 → 28

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

PCI DSS Requirements Testing Procedures Guidance 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

Modified p. 24 → 29

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

 Encryption keys were changed from default at installation  Encryption keys are changed anytime anyone with knowledge of the keys leaves the company or changes positions.

Modified p. 24 → 29

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

 Default passwords/passphrases on access points are not used.

Modified p. 24 → 29

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.d Examine vendor documentation and observe wireless configuration settings to verify firmware on wireless devices is updated to support strong encryption for:

Modified p. 24 → 29

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

2.1.1.e Examine vendor documentation and observe wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable.

Removed p. 25

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

• 2.2.4).

Modified p. 25 → 30

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

PCI DSS Requirements Testing Procedures Guidance 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Modified p. 25 → 30

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

Modified p. 25 → 30

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

2.2.b Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.1.

Modified p. 25 → 30

~~2.2.c~~ Verify that system configuration standards ~~are applied when new systems are configured.~~

2.2.d Verify that system configuration standards include the following procedures for all types of system components:

Modified p. 25 → 31

2.2.1.a ~~For~~ a sample of system ~~components,~~ verify that only one primary function is implemented per server.

2.2.1.a Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server.

Modified p. 25 → 31

2.2.1.b If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device.

2.2.1.b If virtualization technologies are used, inspect the system configurations to verify that only one primary function is implemented per virtual system component or device.

Modified p. 26 → 31

2.2.2.a ~~For~~ a sample of system ~~components,~~ inspect enabled system services, daemons, and ~~protocols. Verify~~ that only necessary services or protocols are enabled.

2.2.2.a Select a sample of system components and inspect enabled system services, daemons, and protocols to verify that only necessary services or protocols are enabled.

Modified p. 26 → 31

2.2.2.b Identify any enabled insecure services, daemons, or ~~protocols. Verify~~ they are justified ~~and that security features are~~ documented ~~and implemented.~~

2.2.2.b Identify any enabled insecure services, daemons, or protocols and interview personnel to verify they are justified per documented configuration standards.

Modified p. 26 → 31

~~2.2.3.a~~ Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.

2.2.4.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components.

Modified p. 26 → 31

~~2.2.3.b Verify~~ that common security parameter settings are ~~included in the system configuration standards.~~

2.2.4.b Examine the system configuration standards to verify that common security parameter settings are included.

Modified p. 26 → 32

~~2.2.4.a For~~ a sample of system ~~components,~~ verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.

2.2.5.a Select a sample of system components and inspect the configurations to verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed.

Modified p. 26 → 32

~~2.2.4.b. Verify~~ enabled functions are documented and support secure configuration.

2.2.5.b. Examine the documentation and security parameters to verify enabled functions are documented and support secure configuration.

Modified p. 26 → 32

~~2.2.4.c. Verify~~ that only documented functionality is present on the sampled system components.

2.2.5.c. Examine the documentation and security parameters to verify that only documented functionality is present on the sampled system components.

Removed p. 27

2.3.c Verify that administrator access to the web-based management interfaces is encrypted with strong cryptography.

Modified p. 27 → 32

~~2.3.a~~ Observe an administrator log on to each system to verify that a strong ~~encryption method is invoked before the administrator’s password is requested.~~

2.3.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography.

Modified p. 27 → 32

2.3.b Review services and parameter files on systems to determine that Telnet and other ~~remote login~~ commands are not available for ~~use internally.~~

2.3.b Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.

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

Modified p. 28 → 34

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 …

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 also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating …

Modified p. 28 → 34

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.

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. 28 → 34

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

PCI DSS Requirements Testing Procedures Guidance 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:

Removed p. 29

3.2.c For each item of sensitive authentication data below, perform the following steps:

Modified p. 29 → 35

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

PCI DSS Requirements Testing Procedures Guidance 3.1.c For a sample of system components that store cardholder data:

Modified p. 29 → 35

~~Note:~~ It is permissible for issuers and companies that support issuing services to store sensitive authentication data ~~if there is a business justification and the data is stored securely.~~

It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:

Modified p. 29 → 35

3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, verify there is a business justification for the storage of sensitive authentication ~~data, and that the data is secured.~~

3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, review policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data.

Modified p. 29 → 36

~~3.2.b~~ For all other entities, if sensitive authentication data is ~~received~~ and ~~deleted, obtain and review~~ the processes for securely deleting the data to verify that the data is unrecoverable.

PCI DSS Requirements Testing Procedures Guidance 3.2.d For all other entities, if sensitive authentication data is received, review procedures and examine the processes for securely deleting the data to verify that the data is unrecoverable.

Modified p. 29 → 36

 The ~~cardholder‘s~~ name  Primary account number (PAN)  Expiration date  Service code To minimize risk, store only these data elements as needed for business.

 The cardholder’s name  Primary account number (PAN)  Expiration date  Service code To minimize risk, store only these data elements as needed for business.

Modified p. 29 → 36

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas  Database ~~contents~~

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas  Database contents.

Modified p. 30 → 36

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

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas  Database contents.

Modified p. 30 → 37

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

 Incoming transaction data  All logs (for example, transaction, history, debugging, error)  History files  Trace files  Several database schemas  Database contents.

Modified p. 30 → 37

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

Note: This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment card brand requirements for point-of-sale (POS) receipts.

Removed p. 31

3.4.1.a If disk encryption is used, verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating systems mechanism (for example, not using local user account databases).

Modified p. 31 → 38

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:

PCI DSS Requirements Testing Procedures Guidance 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. 31 → 38

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

 One-way hashes based on strong cryptography, (hash must be of the entire PAN)  Truncation (hashing cannot be used to replace the truncated segment of PAN)  Index tokens and pads (pads must be securely stored)  Strong cryptography with associated key-management processes and procedures.

Modified p. 31 → 38

Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an ~~entity‘s~~ environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

Modified p. 31 → 38

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:

3.4.a Examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the following methods:

Modified p. 31 → 38

 One-way hashes based on strong ~~cryptography ~~ Truncation  Index tokens and pads, with the pads being securely stored  Strong cryptography, with associated key-management processes and ~~procedures 3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text).~~

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

Modified p. 31 → 39

3.4.1.b ~~Verify~~ that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).

3.4.1.b Observe processes and interview personnel to verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).

Modified p. 31 → 39

3.4.1.c ~~Verify~~ that cardholder data on removable media is encrypted wherever stored.

3.4.1.c Examine the configurations and observe the processes to verify that cardholder data on removable media is encrypted wherever stored.

Removed p. 32

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.

Modified p. 32 → 39

Note: This requirement also applies to key-encrypting keys used to protect ~~data- encrypting keys•such~~ key-encrypting keys must be at least as strong as the data-encrypting key.

Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys• such key-encrypting keys must be at least as strong as the data-encrypting key.

Modified p. 32 → 40

~~3.5.2.a Examine system configuration files to verify that~~ keys are ~~stored in encrypted format and that key-encrypting~~ keys are stored separately from ~~data-encrypting~~ keys.

 Key-encrypting keys are at least as strong as the data- encrypting keys they protect  Key-encrypting keys are stored separately from data- encrypting keys.

Modified p. 32 → 41

~~3.6.a Verify~~ the ~~existence of~~ key-management procedures for keys used for encryption of cardholder ~~data.~~

3.6.b Examine the key-management procedures and processes for keys used for encryption of cardholder data and perform the following:

Modified p. 32 → 42

~~3.6.c Examine the~~ key-management procedures ~~and perform~~ the following:

3.6.5.a Verify that key-management procedures specify processes for the following:

Removed p. 33

3.6.5.a Verify that key-management procedures are implemented to require the retirement of keys when the integrity of the key has been weakened.

Modified p. 33 → 42

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/~~ 3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher- text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

PCI DSS Requirements Testing Procedures Guidance 3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher- text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

Modified p. 33 → 42

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.

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.

Modified p. 33 → 42

~~3.6.5.b Verify that~~ the ~~key-management procedures are implemented to require~~ the replacement of known or suspected compromised keys.

 The retirement or replacement of keys when the integrity of the key has been weakened  The replacement of known or suspected compromised keys.

Modified p. 33 → 42

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

 Any keys retained after retiring or replacing are not used for encryption operations.

Modified p. 34 → 43

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

PCI DSS Requirements Testing Procedures Guidance 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.

Modified p. 34 → 43

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

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

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

Modified p. 35 → 44

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

PCI DSS Requirements Testing Procedures Guidance 4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:

Modified p. 35 → 44

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

 The Internet  Wireless technologies, including 802.11 and Bluetooth  Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)  General Packet Radio Service (GPRS).  Satellite communications.

Modified p. 35 → 44

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

4.1.d Examine keys and certificates to verify that only trusted keys and/or certificates are accepted.

Modified p. 35 → 44

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

4.1.e Examine system configurations to verify that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations.

Modified p. 35 → 45

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

 “HTTPS” appears as the browser Universal Record Locator (URL) protocol, and  Cardholder data is only requested if “HTTPS” appears as part of the URL.

Modified p. 36 → 45

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

Note: The use of WEP as a security control is prohibited.

Modified p. 36 → 45

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

4.2.a If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

Modified p. 36 → 45

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

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

Removed p. 37

5.2.b Verify that the master installation of the software is enabled for automatic updates and periodic scans.

Modified p. 37 → 46

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.

Requirement 5: Protect all systems against malware 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. Additional anti-malware solutions may be considered …

Modified p. 37 → 46

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

PCI DSS Requirements Testing Procedures Guidance 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Modified p. 37 → 47

5.2.a ~~Obtain~~ and ~~examine the policy and~~ verify that ~~it requires updating of~~ anti-virus software and ~~definitions.~~

5.2.a Examine policies and procedures to verify that anti-virus software and definitions are required to be kept up to date.

Modified p. 37 → 47

5.2.c ~~For~~ a sample of system ~~components~~ including all operating system types commonly affected by malicious software, verify ~~that automatic updates and periodic scans are enabled.~~

5.2.c Examine a sample of system components, including all operating system types commonly affected by malicious software, to verify that:

Modified p. 37 → 47

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

 Anti-virus software log generation is enabled, and  Logs are retained in accordance with PCI DSS Requirement 10.7.

Removed p. 38

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 addressed within one month, and addressing less critical devices and systems within three months.

Modified p. 38 → 49

Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor- provided security patches, which must be installed by the entities that manage the systems. All ~~critical~~ systems must have ~~the most recently released,~~ appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software.

Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor- provided security patches, which must be installed by the entities that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

Modified p. 38 → 50

~~6.1.a~~ For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor ~~security patch~~ list, to verify ~~that current vendor patches are installed.~~

6.2.b For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security-patch list, to verify the following:

Modified p. 38 → 50

~~6.1.b~~ Examine policies related to ~~security~~ patch installation to verify ~~they require installation of all critical new security patches within one month.~~

6.2.a Examine policies and procedures related to security- patch installation to verify processes are defined for:

Removed p. 39

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

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.

Removed p. 39

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

Modified p. 39 → 49

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.

PCI DSS Requirements Testing Procedures Guidance 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

Modified p. 39 → 50

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

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

Modified p. 39 → 50

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

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

Modified p. 39 → 50

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

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

Removed p. 40

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:

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

Code reviews can be conducted by knowledgeable internal personnel or third parties. ~~Web~~ applications are also subject to additional controls, ~~if they are public facing,~~ to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

Modified p. 41 → 54

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:

PCI DSS Requirements Testing Procedures Guidance 6.4.5 Change control procedures for the implementation of security patches and software modifications must include the following:

Modified p. 41 → 54

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.

6.4.5.a Examine documented change control procedures related to implementing security patches and software modifications and verify procedures are defined for:

Modified p. 41 → 54

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:

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

Modified p. 41 → 54

6.4.5.3.b For custom code changes, verify that all updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production.

Thorough testing should be performed to verify that the security of the environment is not reduced by implementing a change. Testing should validate that all existing security controls remain in place, are replaced with equally strong controls, or are strengthened after any change to the environment. 6.4.5.3.b For custom code changes, verify that all updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production.

Modified p. 41 → 55

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.

Note: The vulnerabilities listed at 6.5.1 through 6.5.10 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.

Modified p. 41 → 55

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.

6.5.a Examine software-development policies and procedures to verify that training in secure coding techniques is required for developers, based on industry best practices and guidance.

Modified p. 41 → 55

6.5.b Interview a sample of developers ~~and obtain evidence~~ that they are knowledgeable in secure coding techniques.

6.5.b Interview a sample of developers to verify that they are knowledgeable in secure coding techniques.

Modified p. 41 → 55

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

6.5.d. Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities:

Modified p. 42 → 57

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

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

Modified p. 42 → 59

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

Note: Requirement 6.5.10 is a best practice until June 30, 2015, after which it becomes a requirement.

Modified p. 43 → 59

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

 Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

Modified p. 43 → 59

~~ Verify~~ that public-facing web applications are reviewed ~~(using~~ either manual or automated vulnerability security assessment tools or ~~methods), as~~ follows:

 Examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed •using either manual or automated vulnerability security assessment tools or methods

•as follows:

Modified p. 43 → 59

- At least annually - After any changes - By an organization that specializes in application security - ~~That~~ all vulnerabilities ~~are corrected - That the application is re-evaluated after the corrections  Verify that a web-application firewall is~~ in ~~place in front of public-facing web applications to detect and prevent web-based attacks.~~

- At least annually - After any changes - By an organization that specializes in application security - That, at a minimum, all vulnerabilities in

Modified p. 43 → 59

Note: ~~―An~~ organization that specializes in application ~~security‖~~ can be either a third-party company or an internal organization, as long as the reviewers specialize in application security and can demonstrate independence from the development team.

Note: “An organization that specializes in application security” can be either a third-party company or an internal organization, as long as the reviewers specialize in application security and can demonstrate independence from the development team.

Modified p. 44 → 61

~~―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. 44 → 61

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/~~ 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. ~~Access limitations must include the following:~~

PCI DSS Requirements Testing Procedures Guidance 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

Removed p. 45

Note: Some access control systems are set by default to ―allow-all,‖ thereby permitting access unless/until a rule is written to specifically deny it.

Removed p. 46

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

Modified p. 46 → 64

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

Requirement 8: Identify and authenticate access to system components Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their 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 and processes.

Modified p. 46 → 64

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

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. This includes accounts used by vendors and other third parties (for example, for support or maintenance).

Modified p. 46 → 66

 For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s).

 Examine documentation describing the authentication method(s) used.  For each type of authentication method used and for each type of system component, observe an authentication to verify authentication is functioning consistent with documented authentication method(s).

Removed p. 47

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. (For example, remote authentication and dial- in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; or other technologies that facilitate two-factor authentication.)

Removed p. 47

8.4.b For service providers only, observe password files to verify that customer passwords are encrypted.

Removed p. 47

 Obtain and examine an authorization form for each ID.  Verify that the sampled user IDs are implemented in accordance with the authorization form (including with privileges as specified and all signatures obtained), by tracing information from the authorization form to the system.

Modified p. 47 → 70

~~8.4.a~~ For a sample of system components, examine ~~password files~~ to verify ~~that passwords are unreadable during transmission and storage.~~

8.5.a For a sample of system components, examine user ID lists to verify the following:

Removed p. 48

8.5.6.a Verify that any accounts used by vendors to access, support and maintain system components are disabled, and enabled only when needed by the vendor.

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

8.5.8.a For a sample of system components, examine user ID lists to verify the following:

Modified p. 48 → 70

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

 Generic user IDs are disabled or removed.  Shared user IDs for system administration activities and other critical functions do not exist.  Shared and generic user IDs are not used to administer any system components.

Modified p. 48 → 70

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

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

Modified p. 48 → 72

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

PCI DSS Requirements Testing Procedures Guidance 8.6.b Interview security personnel to verify authentication mechanisms are assigned to an account and not shared among multiple accounts.

Removed p. 49

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 as to when, and under what circumstances, passwords must change.

Removed p. 49

8.5.10.a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require passwords to be at least seven characters long.

8.5.10.b For service providers only, review internal processes and customer/user documentation to verify that that non-consumer user passwords are required to meet minimum length requirements.

Removed p. 49

8.5.11.a 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.

8.5.11.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to contain both numeric and alphabetic characters.

Removed p. 49

8.5.12.a For a sample of system components, obtain and inspect system configuration settings to verify that password parameters are set to require that new passwords cannot be the same as the four previously used passwords.

8.5.12.b For service providers only, review internal processes and customer/user documentation to verify that new non-consumer user passwords cannot be the same as the previous four passwords.

Removed p. 49

8.5.13.a For a sample of system components, obtain and inspect system configuration settings to verify that authentication parameters are set to require that a user’s account be locked out after not more than six invalid logon attempts.

Modified p. 49 → 70

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

PCI DSS Requirements Testing Procedures Guidance 8.4 Document and communicate authentication procedures and policies to all users including:

Removed p. 50

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 8.5.13.b For service providers only, review internal processes and customer/user documentation to verify that non-consumer user accounts are temporarily locked-out after not more than six invalid access attempts.

Modified p. 50 → 72

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

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

Modified p. 50 → 72

~~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.7.b Examine database and application configuration settings to verify 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).

Modified p. 50 → 72

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

8.7.c Examine database access control settings and database application configuration settings to verify that user direct access to or queries of databases are restricted to database administrators.

Modified p. 50 → 72

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

8.7.d Examine database access control settings, database application configuration settings, 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).

Removed p. 51

 Verify that access is controlled with badge readers or other devices including authorized badges and lock and key.

Modified p. 51 → 73

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

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

Modified p. 51 → 73

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/~~ 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.

PCI DSS Requirements Testing Procedures Guidance 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.

Modified p. 51 → 73

 Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder environment and verify that they are ~~―locked‖~~ to prevent unauthorized use.

 Verify that access is controlled with badge readers or other devices including authorized badges and lock and key.  Observe a system administrator’s attempt to log into consoles for randomly selected systems in the cardholder environment and verify that they are “locked” to prevent unauthorized use.

Modified p. 51 → 73

Note: ~~―Sensitive areas‖~~ refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes ~~the~~ areas where only ~~point-of-sale~~ terminals are present, such as the cashier areas in a retail store.

Note: “Sensitive areas” refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of- sale terminals are present, such as the cashier areas in a retail store.

Modified p. 51 → 73

9.1.1.b Verify that video cameras and/or access control mechanisms are protected from tampering or disabling.

(Continued on next page) 9.1.1.b Verify that video cameras and/or access control mechanisms are protected from tampering or disabling.

Modified p. 51 → 74

9.1.1.c Verify that video cameras and/or access control mechanisms are monitored and that data from cameras or other mechanisms is stored for at least three months.

PCI DSS Requirements Testing Procedures Guidance 9.1.1.c Verify that video cameras and/or access control mechanisms are monitored and that data from cameras or other mechanisms is stored for at least three months.

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

Modified p. 52 → 75

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

9.2.b Observe processes for identifying and distinguishing between onsite personnel and visitors to verify that:

Modified p. 52 → 75

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

9.2.d Examine identification methods (such as ID badges) in use to verify that they clearly identify visitors and it is easy to distinguish between onsite personnel and visitors.

Modified p. 52 → 76

~~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.4.2.a Observe people within the facility to verify the use of visitor badges or other identification, and that visitors are easily distinguishable from onsite personnel.

Modified p. 52 → 76

~~9.3.2.b~~ Verify that visitor badges expire.

9.4.2.b Verify that visitor badges or other identification expire.

Removed p. 53

PCI DSS Requirements Testing Procedures In Place Not in Target Date/ 9.4 Use a visitor log to maintain a physical audit trail of visitor activity. Document the visitor’s name, the firm represented, and the onsite personnel authorizing physical access on the log. Retain this log for a minimum of three months, unless otherwise restricted by law.

Modified p. 53 → 76

~~9.4.a~~ Verify that a visitor log is in use to record physical access to the facility as well as ~~for~~ computer rooms and data centers where cardholder data is stored or transmitted.

9.4.4.a Verify that a visitor log is in use to record physical access to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted.

Modified p. 53 → 76

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

Document the visitor’s name, the firm represented, and the onsite personnel authorizing physical access on the log.

Modified p. 53 → 77

~~9.5.a~~ Observe the storage location’s physical security to confirm that backup media storage is secure.

9.5.1.a Observe the storage location’s physical security to confirm that backup media storage is secure.

Modified p. 53 → 77

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

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

Modified p. 54 → 78

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

9.8.1.a Interview personnel and examine procedures to 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. 54 → 78

~~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.8.1.b Examine storage containers used for materials that contain information to be destroyed to verify that the containers are secured.

Modified p. 55 → 82

PCI DSS Requirements Testing Procedures ~~In Place Not in Place Target Date/~~ 10.1 ~~Establish a process for linking~~ all access to system components ~~(especially access done with administrative privileges such as root)~~ to each individual user.

PCI DSS Requirements Testing Procedures Guidance 10.1 Implement audit trails to link all access to system components to each individual user.

Removed p. 56

PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 10.3.1 User identification 10.3.1 Verify user identification is included in log entries.

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.

Modified p. 56 → 84

~~10.4.b Obtain and review~~ the process for acquiring, distributing and storing the correct time within the ~~organization, and review the time-related system-parameter settings for a sample of system components. Verify the following is included in the process and implemented:~~

10.4.1.a Examine the process for acquiring, distributing and storing the correct time within the organization to verify that:

Modified p. 56 → 84

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

 Only the designated central time server(s) receives time signals from external sources, and time signals from external sources are based on International Atomic Time or UTC.

Modified p. 56 → 85

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.

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

Removed p. 58

PCI DSS Requirements Testing Procedures In Place Not in Place Target Date/ 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).

10.6.b Through observation and interviews, verify that regular log reviews are performed for all system components.

Modified p. 58 → 86

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

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

Modified p. 58 → 87

~~10.6.a Obtain and examine~~ security policies and procedures to verify that ~~they include~~ procedures ~~to review security logs~~ at least ~~daily and that follow-up to exceptions is required.~~

10.6.1.a Examine security policies and procedures to verify that procedures are defined for reviewing the following at least daily, either manually or via log tools:

Modified p. 58 → 88

~~10.7.a Obtain~~ and examine ~~security policies and procedures and~~ verify that ~~they include~~ audit ~~log retention policies and require audit log retention~~ for at least one year.

10.7.b Interview personnel and examine audit logs to verify that audit logs are available for at least one year.

Modified p. 58 → 88

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

10.7.c Interview personnel and observe processes to verify that at least the last three months’ logs can be immediately restored for analysis.

Removed p. 59

 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 components and facilities.

Modified p. 59 → 89

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.

PCI DSS Requirements Testing Procedures Guidance 11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.

Modified p. 59 → 89

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

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

Modified p. 59 → 89

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

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

Modified p. 59 → 89

11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), 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 notify personnel.

Modified p. 59 → 90

~~11.1.e Verify~~ the organization’s incident response plan (Requirement ~~12.9) includes~~ a response in the event unauthorized wireless ~~devices are~~ detected.

11.1.2.a Examine the organization’s incident response plan (Requirement 12.10) to verify it defines and requires a response in the event that an unauthorized wireless access point is detected.

Modified p. 60 → 91

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/~~ 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

PCI DSS Requirements Testing Procedures Guidance 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

Modified p. 60 → 91

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

For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed 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(s). For subsequent years after the initial PCI DSS review, four quarters of passing scans must have occurred.

Modified p. 60 → 91

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.a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12- month period.

Modified p. 60 → 91

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.b Review the scan reports and verify that the scan process includes rescans until all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

Modified p. 60 → 92

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

PCI DSS Requirements Testing Procedures Guidance 11.2.1.c Interview personnel to verify 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).

Removed p. 61

Note: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by internal staff.

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

Modified p. 61 → 92

~~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 vulnerability scans must be performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC).

Modified p. 61 → 92

11.2.2.a Review output from the four most recent quarters of external vulnerability scans and verify that four quarterly scans occurred in the most recent ~~12-month~~ period.

11.2.2.a Review output from the four most recent quarters of external vulnerability scans and verify that four quarterly external vulnerability scans occurred in the most recent 12- month period.

Modified p. 61 → 92

11.2.2.b Review the results of each quarterly scan to ~~ensure~~ that ~~they satisfy~~ the ASV Program Guide requirements (for example, no vulnerabilities rated higher ~~than a 4.0~~ by the ~~CVSS~~ and no automatic failures).

11.2.2.b Review the results of each quarterly scan and rescan to verify that the ASV Program Guide requirements for a passing scan have been met (for example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic failures).

Modified p. 61 → 92

11.2.2.c Review the scan reports to verify that the scans were completed by an Approved Scanning Vendor ~~(ASV), approved by the PCI SSC.~~

11.2.2.c Review the scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).

Modified p. 61 → 92

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.a Inspect and correlate change control documentation and scan reports to verify that system components subject to any significant change were scanned.

Modified p. 61 → 92

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

 For internal scans, all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

Modified p. 61 → 93

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 Guidance 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).

Removed p. 62

11.4.b Confirm IDS and/or IPS are configured to alert personnel of suspected compromises.

Modified p. 62 → 94

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/ 11.3~~ Perform external ~~and internal~~ penetration testing at least ~~once a year~~ and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a ~~sub- network~~ added to the environment, or a web server added to the environment). ~~These penetration tests must include the following:~~

PCI DSS Requirements Testing Procedures Guidance 11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).

Modified p. 62 → 94

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

11.3.2.a Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed at least annually and after any significant changes to the environment.

Modified p. 62 → 94

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

11.3.1.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).

Modified p. 62 → 95

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

 At the perimeter of the cardholder data environment  At critical points in the cardholder data environment.

Modified p. 62 → 95

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 vendor documentation to verify intrusion-detection and/or intrusion- prevention techniques are configured, maintained, and updated per vendor instructions to ensure optimal protection.

Modified p. 63 → 96

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/~~ 11.5 Deploy file-integrity monitoring ~~tools~~ to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

PCI DSS Requirements Testing Procedures Guidance 11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Modified p. 63 → 96

Note: For ~~file-integrity monitoring~~ purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. ~~File-integrity~~ monitoring products usually come ~~pre-configured~~ with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

Note: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change-detection mechanisms such as file-integrity monitoring products usually come pre- configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

Modified p. 63 → 96

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.

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

Modified p. 63 → 96

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

 System executables  Application executables  Configuration and parameter files  Centrally stored, historical or archived, log and audit files  Additional critical files determined by entity (for example, through risk assessment or other means).

Modified p. 64 → 97

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.

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. 64 → 97

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/~~ 12.1 Establish, publish, maintain, and disseminate a security ~~policy that accomplishes the following:~~

PCI DSS Requirements Testing Procedures Guidance 12.1 Establish, publish, maintain, and disseminate a security policy.

Modified p. 64 → 97

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

12.2.b Review risk-assessment documentation to verify that the risk-assessment process is performed at least annually and upon significant changes to the environment.

Modified p. 65 → 98

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

PCI DSS Requirements Testing Procedures Guidance 12.3 Develop usage policies for critical technologies and define proper use of these technologies.

Modified p. 66 → 100

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.

PCI DSS Requirements Testing Procedures Guidance 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need.

Removed p. 67

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

12.6.b Obtain and examine security awareness program procedures and documentation and perform the following:

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

Modified p. 67 → 101

12.6.1.a Verify that the security awareness program provides multiple methods of communicating awareness and educating personnel (for example, posters, letters, memos, ~~web based~~ training, meetings, and promotions).

12.6.1.a Verify that the security awareness program provides multiple methods of communicating awareness and educating personnel (for example, posters, letters, memos, web-based training, meetings, and promotions).

Modified p. 68 → 103

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/~~ 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers ~~possess.~~

PCI DSS Requirements Testing Procedures Guidance 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 or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Modified p. 68 → 105

 Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum  Specific incident response procedures  Business recovery and continuity procedures  Data ~~back-up~~ processes  Analysis of legal requirements for reporting compromises  Coverage and responses of all critical system components  Reference or inclusion of incident response procedures from the payment ~~brands 12.9.1.a Verify that the incident response plan includes:~~

 Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum  Specific incident response procedures  Business recovery and continuity procedures  Data backup processes  Analysis of legal requirements for reporting compromises  Coverage and responses of all critical system components  Reference or inclusion of incident response procedures from the payment brands.

Modified p. 68 → 105

 Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a ~~minimum: ~~ Specific incident response procedures  Business recovery and continuity procedures  Data ~~back-up~~ processes  Analysis of legal requirements for reporting compromises (for example, California Bill ~~1386~~ which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database)  Coverage and responses for all critical …

 Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum  Specific incident response procedures  Business recovery and continuity procedures  Data backup processes  Analysis of legal requirements for reporting compromises (for example, California Bill 1386, which requires notification of affected consumers in the event of an actual or suspected compromise for any business with California residents in their database)  Coverage and responses for all critical …

Modified p. 69 → 106

PCI DSS Requirements Testing Procedures ~~In Place Not in Target Date/ 12.9.2 Test the plan at least annually.~~

PCI DSS Requirements Testing Procedures Guidance 12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts.

Modified p. 70 → 107

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:

Requirements Testing Procedures Guidance 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. 70 → 107

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

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:

Modified p. 71 → 108

A.1.2.e To ensure each entity cannot monopolize server resources to exploit vulnerabilities (for example, error, race, and restart ~~conditions,~~ resulting in, for example, buffer overflows), verify restrictions are in place for the use of these system resources:

A.1.2.e To ensure each entity cannot monopolize server resources to exploit vulnerabilities (for example, error, race, and restart conditions resulting in, for example, buffer overflows), verify restrictions are in place for the use of these system resources:

Modified p. 71 → 108

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

 Disk space  Bandwidth 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. 71 → 108

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

A.1.3 Verify the shared hosting provider has enabled logging as follows, for each merchant and service provider environment:

Modified p. 72 → 109

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

Modified p. 74 → 111

Requirement Number: ~~8.1•Are~~ all users identified with a unique user ~~name~~ before allowing them to access system components or cardholder data? Information Required Explanation

Requirement Number: 8.1.1

• Are all users identified with a unique user ID before allowing them to access system components or cardholder data? Information Required Explanation

Modified p. 74 → 111

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. 74 → 111

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” (substitute user) command. This allows a user to access the “root” account and perform actions under the “root” account but is able to be logged in the SU-log directory. In this way, each user’s actions can be tracked through the SU account, without the “root” password being shared with the users.

Modified p. 74 → 111

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 is being executed and that all activities performed by those individuals utilizing the command are logged to identify that the individual is performing actions under root privileges.

Modified p. 74 → 111

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.

Company XYZ documents processes and procedures to ensure SU configurations are not changed, altered, or removed to allow individual users to execute root commands without being individually identified, tracked and logged.

Document Comparison

From Revision History

Content Changes