Pci-Dss V3.0

Front 1

1.0

Back 1

Install and maintain a firewall configuration to protect cardholder data

Hint 1

How a secure network starts

Front 2

1.1

Back 2

Establish and implement firewall and router configuration standards that include the following:

Hint 2

Inspect the firewall and router configuration standards and other documentation specified below and verify that standards are complete and implemented as follows:

Front 3

1.1.1

Back 3

A formal process for approving and testing all network connections and changes to the firewall and router configurations

Hint 3

(Formal Process)

1.1.1.a
Examine documented procedures to verify there is a formal process for testing and approval of all:

* Network connections and

* Changes to firewall and router configurations

1.1.1.b
For a sample of network connections, interview responsible personnel and examine records to verify that network connections were approved and tested.

1.1.1.c
Identify a sample of actual changes made to firewall and router configurations, compare to the change records, and interview responsible personnel to verify the changes were approved and tested.

Front 4

1.1.2

Back 4

Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks

Hint 4

(Network Diagram)

1.1.2.a
Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections to cardholder data, including any wireless networks.

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

Front 5

1.1.3

Back 5

Current diagram that shows all cardholder data flows across systems and networks

Hint 5

(Diagram)

Examine data-flow diagram and interview personnel to verify the diagram:
* Shows all cardholder data flows across systems and networks.
* Is kept current and updated as needed upon changes to the environment.

Front 6

1.1.4

Back 6

Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone

Hint 6

1.1.4.a
Examine the firewall configuration standards and verify that they include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.

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

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 standards and network diagrams.

Front 7

1.1.5

Back 7

Description of groups, roles, and responsibilities for management of network components

Hint 7

(Groups, roles , responsibilities)

1.1.5.a
Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components.

1.1.5.b
Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented.

Front 8

1.1.6

Back 8

Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.
Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2.

Hint 8

(FTP, Telnet, POP3, IMAP, SNMP v1 and v2, etc)

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.

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

1.1.6.c
Examine firewall and router configurations to verify that the documented security features are implemented for each insecure service, protocol, and port.

Front 9

1.1.7

Back 9

Requirement to review firewall and router rule sets at least every six months

Hint 9

(Six month review)

1.1.7.a
Verify that firewall and router configuration standards require review of firewall and router rule sets 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.

Front 10

1.2

Back 10

Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

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.

Hint 10

(FW & Router Sampling Configs)

1.2 Examine firewall and router configurations and perform the following to verify that connections are restricted between untrusted networks and system components in the cardholder data environment:

Front 11

1.2.1

Back 11

Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.

Hint 11

1.2.1.a
Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.

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.

1.2.1.c
Examine firewall and router configurations to 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.

Front 12

1.2.2

Back 12

Secure and synchronize router configuration files.

Hint 12

1.2.2.a
Examine router configuration files to verify they are secured from unauthorized access.

1.2.2.b
Examine router configurations to verify they are synchronized—for example, the running (or active) configuration matches the start-up configuration (used when machines are booted).

Front 13

1.2.3

Back 13

Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.

Hint 13

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.

1.2.3.b
Verify that the firewalls deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.

Front 14

1.3

Back 14

Prohibit direct public access between the Internet and any system component in the cardholder data environment.

Hint 14

(DMZ)

1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—and perform the following to determine that there is no direct access between the Internet and system components in the internal cardholder network segment:

Front 15

1.3.1

Back 15

Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

Hint 15

(Firewall & Router sampling)

1.3.1 Examine firewall and router configurations to verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

Front 16

1.3.2

Back 16

Limit inbound Internet traffic to IP addresses within the DMZ.

Hint 16

1.3.2 Examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ.

Front 17

1.3.3

Back 17

Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.

Hint 17

1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.

Front 18

1.3.4

Back 18

Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.
(For example, block traffic originating from the Internet with an internal source address.)

Hint 18

1.3.4 Examine firewall and router configurations to verify that anti-spoofing measures are implemented, for example internal addresses cannot pass from the Internet into the DMZ.

Front 19

1.3.5

Back 19

Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

Hint 19

1.3.5 Examine firewall and router configurations to verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized.

Front 20

1.3.6

Back 20

Implement stateful inspection, also known as dynamic packet filtering. (That is, only “established” connections are allowed into the network.)

Hint 20

1.3.6 Examine firewall and router configurations to 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.)

Front 21

1.3.7

Back 21

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

Hint 21

1.3.7 Examine firewall and router configurations to verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks.

Front 22

1.3.8

Back 22

Do not disclose private IP addresses and routing information to unauthorized parties.

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

* Network Address Translation (NAT)

* Placing servers containing cardholder data behind proxy servers/firewalls,

* Removal or filtering of route advertisements for private networks that employ registered addressing,

* Internal use of RFC1918 address space instead of registered addresses.

Hint 22

(NAT'ing; Firewall & Router sampling)

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.

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.

Front 23

1.4

Back 23

Install personal firewall software on any mobile and/or employee-owned devices that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the network. Firewall configurations include:

* Specific configuration settings are defined for personal firewall software.

* Personal firewall software is actively running.

* Personal firewall software is not alterable by users of mobile and/or employee-owned devices.

Hint 23

(Personal Firewall)

1.4.a Examine policies and configuration standards to verify:

* Personal firewall software is required for all mobile and/or employee-owned devices that connect to the Internet (for example, laptops used by employees) when outside the network, and which are also used to access the network.

* Specific configuration settings are defined for personal firewall software.

* Personal firewall software is configured to actively run.

* Personal firewall software is configured to not be alterable by users of mobile and/or employee-owned devices.

1.4.b Inspect a sample of mobile and/or employee-owned devices to verify that:

* Personal firewall software is installed and configured per the organization’s specific configuration settings.

* Personal firewall software is actively running.

* Personal firewall software is not alterable by users of mobile and/or employee-owned devices.

Front 24

1.5

Back 24

Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

Hint 24

1.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing firewalls are:

* Documented,
* In use, and
* Known to all affected parties.

Front 25

2.0

Back 25

Do not use vendor-supplied defaults for system passwords and other security parameters

Hint 25

Default passwords

Front 26

2.1

Back 26

Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on 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.).

Hint 26

(Default Password)

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

2.1.b For the sample of system components, verify that all unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled.

2.1.c Interview personnel and examine supporting documentation to verify that:
 All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network.
 Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled before a system is installed on the network.

Front 27

2.1.1

Back 27

For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.

Hint 27

(Wireless)

2.1.1.a Interview responsible personnel and examine supporting documentation to verify that:

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

2.1.1.b Interview personnel and examine policies and procedures to verify:

* Default SNMP community strings are required to be changed upon installation.

* Default passwords/phrases on access points are required to be changed upon installation.

2.1.1.c Examine vendor documentation and login to wireless devices, with system administrator help, to verify:

* Default SNMP community strings are not used.

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

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:

* Authentication over wireless networks

* Transmission over wireless networks.

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

Front 28

2.2

Back 28

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:

* Center for Internet Security (CIS)

* International Organization for Standardization (ISO)

* SysAdmin Audit Network Security (SANS) Institute

* National Institute of Standards Technology (NIST).

Hint 28

(Configurations Standards; Best Practices)

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

2.2.c Examine policies and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network.

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

* Changing of all vendor-supplied defaults and elimination of unnecessary default accounts

* Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server

* Enabling only necessary services, protocols, daemons, etc., as required for the function of the system

* Implementing additional security features for any required services, protocols or daemons that are considered to be insecure

* Configuring system security parameters to prevent misuse

* Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

Front 29

2.2.1

Back 29

Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

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

Hint 29

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.

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.

Front 30

2.2.2

Back 30

Enable only necessary services, protocols, daemons, etc., as required for the function of the system.

Hint 30

(SSH, S-FTP, SSL, IPSec VPN, etc.)

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.

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

Front 31

2.2.3

Back 31

Implement additional security features for any required services, protocols, or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Hint 31

Inspect configuration settings to verify that security features are documented and implemented for all insecure services, daemons, or protocols.

Front 32

2.2.4

Back 32

Configure system security parameters to prevent misuse.

Hint 32

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.

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

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.

Front 33

2.2.5

Back 33

Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

Hint 33

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.

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

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

Front 34

2.3

Back 34

Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

Hint 34

(Non-console Administrative Access)

2.3 Select a sample of system components and verify that non-console administrative access is encrypted by performing the following:

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

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

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.

2.3.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations.

Front 35

2.4

Back 35

Maintain an inventory of system components that are in scope for PCI-DSS.

Hint 35

2.4.a Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each.

2.4.b Interview personnel to verify the documented inventory is kept current.

Front 36

2.5

Back 36

Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.

Hint 36

2.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing vendor defaults and other security parameters are:
* Documented,
* In use, and
* Known to all affected parties.

Front 37

2.6

Back 37

Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.

Hint 37

2.6 Perform testing procedures A.1.1 through A.1.4 detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared hosting providers, to verify that shared hosting providers protect their entities’ (merchants and service providers) hosted environment and data.

Front 38

3.0

Back 38

Protect stored cardholder data

Hint 38

Stored Data

Front 39

3.1

Back 39

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:

* Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements

* Processes for secure deletion of data when no longer needed

* Specific retention requirements for cardholder data

* A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

Hint 39

(Data Retention)

3.1.a Examine the data retention and disposal policies, procedures and processes to verify they include at least the following:

* 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 for Y business reasons).

* Secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons

* Coverage for all storage of cardholder data

* A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

3.1.b Interview personnel to verify that:

* All locations of stored cardholder data are included in the data retention and disposal processes.

* Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data.

* The quarterly automatic or manual process is performed for all locations of cardholder data.

3.1.c For a sample of system components that store cardholder data:

* Examine files and system records to verify that the data stored does not exceed the requirements defined in the data retention policy

* Observe the deletion mechanism to verify data is deleted securely.

Front 40

3.2

Back 40

Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process. 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.
Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:

Hint 40

(Sensitive Authentication Data [SAD])

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.

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.

3.2.c For all other entities, if sensitive authentication data is received, review policies and procedures, and examine system configurations to verify the data is not retained after authorization.

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.

Front 41

3.2.1

Back 41

Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained:

* The cardholder’s name
* Primary account number (PAN)
* Expiration date
* Service code

To minimize risk, store only these data elements as needed for business.

Hint 41

3.2.1 For a sample of system components, examine data sources including but not limited to the following, and verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored after authorization:
* Incoming transaction data
* All logs (for example, transaction, history, debugging, error)
* History files
* Trace files
* Several database schemas
* Database contents.

Front 42

3.2.2

Back 42

Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.

Hint 42

3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization:
* Incoming transaction data
* All logs (for example, transaction, history, debugging, error)
* History files
* Trace files
* Several database schemas
* Database contents.

Front 43

3.2.3

Back 43

Do not store the personal identification number (PIN) or the encrypted PIN block.

Hint 43

3.2.3 For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored after authorization:

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

Front 44

3.3

Back 44

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN. 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.

Hint 44

(Mask PAN)

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.

3.3.b Examine system configurations to verify that full PAN is only displayed for users/roles with a documented business need, and that PAN is masked for all other requests.

3.3.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see full PAN.

Front 45

3.4

Back 45

Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:
 One-way hashes based on strong cryptography, (hash must be of the entire PAN)
 Truncation (hashing cannot be used to replace the truncated segment of PAN)
 Index tokens and pads (pads must be securely stored)
 Strong cryptography with associated key-management processes and procedures. Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have 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.

Hint 45

(PAN Encryption)

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

3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm that the PAN is rendered unreadable.

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

Front 46

3.4.1

Back 46

If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.

Hint 46

3.4.1.a If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials).

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

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

Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method.

Front 47

3.5

Back 47

Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:

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.

Hint 47

(Protecting Data & KEK Keys)

3.5 Examine key-management policies and procedures to verify processes are specified to protect keys used for encryption of cardholder data against disclosure and misuse and include at least the following:

* Access to keys is restricted to the fewest number of custodians necessary.
* Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
* Key-encrypting keys are stored separately from data-encrypting keys.
* Keys are stored securely in the fewest possible locations and forms.

Front 48

3.5.1

Back 48

Restrict access to cryptographic keys to the fewest number of custodians necessary.

Hint 48

3.5.1 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary.

Front 49

3.5.2

Back 49

Store secret and private keys used to encrypt/decrypt cardholder data 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 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.

Hint 49

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 shares, in accordance with an industry-accepted method

3.5.2.b Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt cardholder data exist in one (or more) of the following form at all times.

* Encrypted with a key-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 shares, in accordance with an industry-accepted method

3.5.2.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify:

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

Front 50

3.5.3

Back 50

Store cryptgraphic keys in the fewest possible locations.

Hint 50

3.5.3 Examine key storage locations and observe processes to verify that keys are stored in the fewest possible locations.

Front 51

3.6

Back 51

Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:

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

Hint 51

3.6.a Additional testing procedure for service providers: If the service provider shares keys with their customers for transmission or storage of cardholder data, examine the documentation that the service provider provides to their customers to verify that it includes guidance on how to securely transmit, store, and update customers’ keys, in accordance with Requirements 3.6.1 through 3.6.8 below.

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

Front 52

3.6.1

Back 52

Generation of strong cryptographic keys

Hint 52

3.6.1.a Verify that key-management procedures specify how to generate strong keys.

3.6.1.b Observe the method for generating keys to verify that strong keys are generated.

Front 53

3.6.2

Back 53

Secure cryptographic key distribution

Hint 53

3.6.2.a Verify that key-management procedures specify how to securely distribute keys

3.6.2.b Observe the method for distributing keys to verify that keys are distributed securely.

Front 54

3.6.3

Back 54

Secure cryptographic key storage

Hint 54

3.6.3.a Verify that key-management procedures specify how to securely store keys

3.6.3.b Observe the method for storing keys to verify that the keys are stored securely.

Front 55

3.6.4

Back 55

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

Hint 55

(Key Management Procedure)

3.6.4.a Verify that key-management procedures include a defined cryptoperiod for each key type in use and define a process for key changes at the end of the defined cryptoperiod(s).

3.6.4.b Interview personnel to verify that keys are changed at the end of the defined cryptoperiod(s).

Front 56

3.6.5

Back 56

Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.

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.

Hint 56

(Key Rotation)

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

* The retirement or replacement of keys when the integrity of the key has been weakened
* The replacement of known or suspected compromised keys.
* Any keys retained after retiring or replacing are not used for encryption operations

3.6.5.b Interview personnel to verify the following processes are implemented:
* Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company.
* Keys are replaced if known or suspected to be compromised.
* Any keys retained after retiring or replacing are not used for encryption operations.

Front 57

3.6.6

Back 57

If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.

If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.

Hint 57

(Split Knowledge)

3.6.6.a Verify that manual clear-text key-management procedures specify processes for the use of the following:

* Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND
* Dual control of keys, such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example, passwords or keys) of another.

3.6.6 b Interview personnel and/or observe processes to verify that manual clear-text keys are managed with:

* Split knowledge, AND
* Dual control

Front 58

3.6.7

Back 58

Prevention of unauthorized substitution of cryptographic keys.

Hint 58

3.6.7.a Verify that key-management procedures specify processes to prevent unauthorized substitution of keys.

3.6.7.b Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented.

Front 59

3.6.8

Back 59

Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities

Hint 59

3.6.8.a Verify that key-management procedures specify processes for key custodians to acknowledge (in writing or electronically) that they understand and accept their key-custodian 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.

Front 60

3.7

Back 60

Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties

Hint 60

3.7 Examine documentation interview personnel to verify that security policies and operational procedures for protecting stored cardholder data are:
* Documented,
* In use, and
* Known to all affected parties.

Front 61

4.0

Back 61

Encrypt transmission of cardholder data across open, public networks

Hint 61

What you do with moving data

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

Front 62

4.1

Back 62

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:

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

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

Hint 62

(Encryption For Network)

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.

4.1.b Review documented policies and procedures to verify processes are specified for the following:

* For acceptance of only trusted keys and/or certificates
* For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported)
* For implementation of proper encryption strength per the encryption methodology in use

4.1.c Select and observe a sample of inbound and outbound transmissions as they occur to verify that all cardholder data is encrypted with strong cryptography during transit.

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

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.

4.1.f Examine system configurations to verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.)

4.1.g For SSL/TLS implementations, examine system configurations to verify that SSL/TLS is enabled whenever cardholder data is transmitted or received.
For example, for browser-based implementations:

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

Front 63

4.1.1

Back 63

Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission.

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

Hint 63

(Wireless)

4.1.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings to verify the following for all wireless networks identified:

* Industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission.
* Weak encryption (for example, WEP, SSL version 2.0 or older) is not used as a security control for authentication or transmission.

Front 64

4.2

Back 64

Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

Hint 64

(Email PAN)

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.

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.

Front 65

4.3

Back 65

Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.

Hint 65

4.3 Examine documentation interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are:

* Documented,
* In use, and
* Known to all affected parties.

Front 66

5.0

Back 66

Use and regularly update anti-virus software or programs

Hint 66

Fight malware, virus, worms, spyware, etc.

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 as a supplement to the anti-virus software; however, such additional solutions do not replace the need for anti-virus software to be in place.

Front 67

5.1

Back 67

Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).

Hint 67

(Master Installation)

For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists.

Front 68

5.1.1

Back 68

Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software.

Hint 68

5.1.1 Review vendor documentation and examine anti-virus configurations to verify that anti-virus programs;

* Detect all known types of malicious software,
* Remove all known types of malicious software, and
* Protect against all known types of malicious software.

Examples of types of malicious software include viruses, Trojans, worms, spyware, adware, and rootkits.

Front 69

5.1.2

Back 69

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.

Hint 69

5.1.2 Interview personnel to verify that evolving malware threats are monitored and evaluated for systems not currently considered to be commonly affected by malicious software, in order to confirm whether such systems continue to not require anti-virus software.

Front 70

5.2

Back 70

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.

Hint 70

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

5.2.b Examine anti-virus configurations, including the master installation of the software to verify anti-virus mechanisms are:
* Configured to perform automatic updates, and
* Configured to perform periodic scans.

5.2.c Examine a sample of system components, including all operating system types commonly affected by malicious software, to verify that:
* The anti-virus software and definitions are current.
* Periodic scans are performed.

5.2.d Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that:

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

Front 71

5.3

Back 71

Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active.

Hint 71

5.3.a Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify the anti-virus software is actively running.

5.3.b Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that the anti-virus software cannot be disabled or altered by users.

5.3.c Interview responsible personnel and observe processes to verify that anti-virus software cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period.

Front 72

5.4

Back 72

Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.

Hint 72

5.4 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting systems against malware are:
* Documented,
* In use, and
* Known to all affected parties.

Front 73

6.0

Back 73

Develop and maintain secure systems and applications

Hint 73

Protect Software Development

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.

Note: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

Front 74

6.1

Back 74

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.

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 that store, process, or transmit cardholder data.

Hint 74

(Patching; Obsolete hardware/software systems in use and no longer supported by its vendor constitutes an automatic failure)

6.1.a Examine policies and procedures to verify that processes are defined for the following:

* To identify new security vulnerabilities
* To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.
* To use reputable outside sources for security vulnerability information.

6.1.b Interview responsible personnel and observe processes to verify that:

* New security vulnerabilities are identified.
* A risk ranking is assigned to vulnerabilities that includes identification of all “high” risk and “critical” vulnerabilities.
* Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

Front 75

6.2

Back 75

Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

Hint 75

(Risk Ranking)

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

* Installation of applicable critical vendor-supplied security patches within one month of release.
* Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months).

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:

* That applicable critical vendor-supplied security patches are installed within one month of release.
* All applicable vendor-supplied security patches are installed within an appropriate time frame (for example, within three months).

Front 76

6.3

Back 76

Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:

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

Hint 76

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

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

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

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

Front 77

6.3.1

Back 77

Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.

Hint 77

6.3.1 Examine written software-development procedures and interview responsible personnel to verify that pre-production and/or custom application accounts, user IDs and/or passwords are removed before an application goes into production or is released to customers.

Front 78

6.3.2

Back 78

Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:

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

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

Hint 78

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

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

Front 79

6.4

Back 79

Follow change control processes and procedures for all changes to system components. the processes must include the following:

Hint 79

(Change Control)

6.4 Examine policies and procedures to verify the following are defined:

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

Front 80

6.4.1

Back 80

Separate development/test environments from production environments, and enforce the separation with access controls.

Hint 80

(Apply access controls to SOD)

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

6.4.1.b Examine access controls settings to verify that access controls are in place to enforce separation between the development/test environments and the production environment(s).

Front 81

6.4.2

Back 81

Separation of duties between development/test and production environments

Hint 81

(Separate development and production environments)

6.4.2 Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment.

Front 82

6.4.3

Back 82

Production data (live PANs) are not used for testing or development

Hint 82

(Should not be used in testing or development environment)

6.4.3.a Observe testing processes and interview personnel to verify procedures are in place to ensure production data (live PANs) are not used for testing or development.

6.4.3.b Examine a sample of test data to verify production data (live PANs) is not used for testing or development.

Front 83

6.4.4

Back 83

Removal of test data and accounts before production systems become active

Hint 83

6.4.4.a Observe testing processes and interview personnel to verify test data and accounts are removed before a production system becomes active.

6.4.4.b Examine a sample of data and accounts from production systems recently installed or updated to verify test data and accounts are removed before the system becomes active.

Front 84

6.4.5

Back 84

Change control procedures for the implementation of security patches and software modifications must include the following:

Hint 84

(Change Control Procedures)

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

* 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

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:

Front 85

6.4.5.1

Back 85

Documentation of impact

Hint 85

6.4.5.1 Verify that documentation of impact is included in the change control documentation for each sampled change.

Front 86

6.4.5.2

Back 86

Documented change approval by authorized parties.

Hint 86

(Change Approval documentation)

6.4.5.2 Verify that documented approval by authorized parties is present for each sampled change.

Front 87

6.4.5.3

Back 87

Functionality testing to verify that the change does not adversely impact the security of the system.

Hint 87

(No adverse impact; SAMPLING required)

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

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.

Front 88

6.4.5.4

Back 88

Back-out procedures.

Hint 88

6.4.5.4 Verify that back-out procedures are prepared for each sampled change.

Front 89

6.5

Back 89

Address common coding vulnerabilities in software-development processes as follows:

* Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.
* Develop applications based on secure coding guidelines.

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.

Hint 89

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.

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

6.5.c Examine records of training to verify that software developers received training on secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.

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

Front 90

6.5.1

Back 90

Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.

Hint 90

6.5.1 Examine software-development policies and procedures and interview responsible personnel to verify that injection flaws are addressed by coding techniques that include:

* Validating input to verify user data cannot modify meaning of commands and queries.
* Utilizing parameterized queries.

Front 91

6.5.2

Back 91

Buffer overflows

Hint 91

6.5.2 Examine software-development policies and procedures and interview responsible personnel to verify that buffer overflows are addressed by coding techniques that include:

* Validating buffer boundaries.
* Truncating input strings.

Front 92

6.5.3

Back 92

Insecure cryptographic storage

Hint 92

6.5.3 Examine software-development policies and procedures and interview responsible personnel to verify that insecure cryptographic storage is addressed by coding techniques that:

* Prevent cryptographic flaws.
* Use strong cryptographic algorithms and keys.

Front 93

6.5.4

Back 93

Insecure communications

Hint 93

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.

Front 94

6.5.5

Back 94

Improper error handling

Hint 94

6.5.5 Examine software-development policies and procedures and interview responsible personnel to verify that improper error handling is addressed by coding techniques that do no leak information via error messages (for example, by returning generic rather than specific error details.).

Front 95

6.5.6

Back 95

All "high risk" vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).

Hint 95

6.5.6 Examine software-development policies and procedures and interview responsible personnel to verify that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PCI DSS Requirement 6.1.

Front 96

6.5.7

Back 96

Cross-site scripting (XSS)

Hint 96

6.5.7 Examine software-development policies and procedures and interview responsible personnel to verify that cross-site scripting (XSS) is addressed by coding techniques that include

* Validating all parameters before inclusion
* Utilizing context-sensitive escaping.

Front 97

6.5.8

Back 97

Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).

Hint 97

6.5.8 Examine software-development policies and procedures and interview responsible personnel to verify that improper access control—such as insecure direct object references, failure to restrict URL access, and directory traversal—is addressed by coding technique that includes:

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

Front 98

6.5.9

Back 98

Cross-site request forgery (CSRF)

Hint 98

6.5.9 Examine software development policies and procedures and interview responsible personnel to verify that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers.

Front 99

6.5.10

Back 99

Broken authentication and session management

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

Hint 99

6.5.10 Examine software development policies and procedures and interview responsible personnel to verify that broken authentication and session management are addressed via coding techniques that commonly include:

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

Front 100

6.6

Back 100

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

* Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes 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.

Hint 100

6.6 For public-facing web applications, ensure that either one of the following methods is in place 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:
- At least annually
- After any changes
- By an organization that specializes in application security
- That, at a minimum, all vulnerabilities in 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.

Front 101

6.7

Back 101

Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.

Hint 101

6.7 Examine documentation and interview personnel to verify that security policies and operational procedures for developing and maintaining secure systems and applications are:

* Documented,
* In use, and
* Known to all affected parties.

Front 102

7.0

Back 102

Restrict access to cardholder data by business need to know

Hint 102

Need-to-know; Separation of Duty

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.
“Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.

Front 103

7.1

Back 103

Limit access to system components and cardholder data to only those individuals whose job requires such access.

Hint 103

7.1 Examine written policy for access control, and verify that the policy incorporates 7.1.1 through 7.1.4 as follows:

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

Front 104

7.1.1

Back 104

Define access needs for each role, including:

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

Hint 104

Select a sample of roles and verify access needs for each role are defined and include:

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

Front 105

7.1.2

Back 105

Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.

Hint 105

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.

7.1.2.b Select a sample of user IDs with privileged access and interview responsible management personnel to verify that privileges assigned are:

* Necessary for that individual’s job function
* Restricted to least privileges necessary to perform job responsibilities.

Front 106

7.1.3

Back 106

Assign access based on individual personnel’s job classification and function.

Hint 106

(Access control by job classification)

Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function.

Front 107

7.1.4

Back 107

Require documented approval by authorized parties specifying required privileges.

Hint 107

7.1.4 Select a sample of user IDs and compare with documented approvals to verify that:

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

Front 108

7.2

Back 108

Establish an access control system for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
This access control system must include the following:

Hint 108

7.2 Examine system settings and vendor documentation to verify that an access control system is implemented as follows:

Front 109

7.2.1

Back 109

Coverage of all system components

Hint 109

Confirm that access control systems are in place on all system components.

Front 110

7.2.2

Back 110

Assignment of privileges to individuals based on job classification and function.

Hint 110

7.2.2 Confirm that access control systems are configured to enforce privileges assigned to individuals based on job classification and function.

Front 111

7.2.3

Back 111

Default "deny-all" setting.

Hint 111

Confirm that the access control systems have a default "deny-all" setting.

Front 112

7.3

Back 112

Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

Hint 112

7.3 Examine documentation interview personnel to verify that security policies and operational procedures for restricting access to cardholder data are:

* Documented,
* In use, and
* Known to all affected parties.

Front 113

8.0

Back 113

Assign a unique ID to each person with computer access

Hint 113

Usernames/Passwords

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

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

Front 114

8.1

Back 114

Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows:

Hint 114

8.1.a Review procedures and confirm they define processes for each of the items below at 8.1.1 through 8.1.8

8.1.b Verify that procedures are implemented for user identification management, by performing the following:

Front 115

8.1.1

Back 115

Assign all users a unique ID before allowing them to access system components or cardholder data.

Hint 115

8.1.1 Interview administrative personnel to confirm that all users are assigned a unique ID for access to system components or cardholder data.

Front 116

8.1.2

Back 116

Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

Hint 116

8.1.2 For a sample of privileged user IDs and general user IDs, examine associated authorizations and observe system settings to verify each user ID and privileged user ID has been implemented with only the privileges specified on the documented approval.

Front 117

8.1.3

Back 117

Immediately revoke access for any terminated users.

Hint 117

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.

8.1.3.b Verify all physical authentication methods—such as, smart cards, tokens, etc.—have been returned or deactivated.

Front 118

8.1.4

Back 118

Remove/disable inactive user accounts at least every 90 days.

Hint 118

8.1.4 Observe user accounts to verify that any inactive accounts over 90 days old are either removed or disabled.

Front 119

8.1.5

Back 119

Manage IDs used by vendors to access, support, or maintain system components via remote access as follows:

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

Hint 119

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.

8.1.5.b Interview personnel and observe processes to verify that vendor remote access accounts are monitored while being used.

Front 120

8.1.6

Back 120

Limit repeated access atempts by locking out the user ID after not more than six attempts.

Hint 120

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.

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.

Front 121

8.1.7

Back 121

Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.

Hint 121

8.1.7 For a sample of system components, inspect system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until a system administrator resets the account.

Front 122

8.1.8

Back 122

If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

Hint 122

8.1.8 For a sample of system components, inspect system configuration settings to verify that system/session idle time out features have been set to 15 minutes or less.

Front 123

8.2

Back 123

In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:

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

Hint 123

8.2 To verify that users are authenticated using unique ID and additional authentication (for example, a password/phrase) for access to the cardholder data environment, perform the following:

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

Front 124

8.2.1

Back 124

8.2 To verify that users are authenticated using unique ID and additional authentication (for example, a password/phrase) for access to the cardholder data environment, perform the following:
 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).

Hint 124

8.2.1.a Examine vendor documentation and system configuration settings to verify that passwords are protected with strong cryptography during transmission and storage.

8.2.1.b For a sample of system components, examine password files to verify that passwords are unreadable during storage.

8.2.1.c For a sample of system components, examine data transmissions to verify that passwords are unreadable during transmission.

8.2.1.d Additional testing procedure for service providers: Observe password files to verify that customer passwords are unreadable during storage.

8.2.1.e Additional testing procedure for service providers: Observe data transmissions to verify that customer passwords are unreadable during transmission.

Front 125

8.2.2

Back 125

Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys.

Hint 125

8.2.2 Examine authentication procedures for modifying authentication credentials and observe security personnel to verify that, if a user requests a reset of an authentication credential by phone, e-mail, web, or other non-face-to-face method, the user’s identity is verified before the authentication credential is modified.

Front 126

8.2.3

Back 126

Passwords/phrases must meet the following:

* Require a minimum length of at least seven characters.
* Contain both numeric and alphabetic characters.
Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above.

Hint 126

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:

* Require a minimum length of at least seven characters.
* Contain both numeric and alphabetic characters.

8.2.3.b Additional testing procedure for service providers: Review internal processes and customer/user documentation to verify that non-consumer user passwords are required to meet at least the following strength/complexity:
* Require a minimum length of at least seven characters.
* Contain both numeric and alphabetic characters.

Front 127

8.2.4

Back 127

Change user passwords/passphrases at least every 90 days

Hint 127

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.

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.

Front 128

8.2.5

Back 128

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.

Hint 128

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 the same as the four previously used passwords.

8.2.5.b Additional testing procedure for service providers: Review internal processes and customer/user documentation to verify that new non-consumer user passwords cannot be the same as the previous four passwords.

Front 129

8.2.6

Back 129

Set passwords/phrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use.

Hint 129

8.2.6 Examine password procedures and observe security personnel to verify that first-time passwords for new users, and reset passwords for existing users, are set to a unique value for each user and changed after first use

Front 130

8.3

Back 130

Incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance).

Note: Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication. 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.

Hint 130

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

8.3.b Observe a sample of personnel (for example, users and administrators) connecting remotely to the network and verify that at least two of the three authentication methods are used.

Front 131

8.4

Back 131

Document and communicate authentication procedures and policies to all users including:

* Guidance on selecting strong authentication credentials
* Guidance for how users should protect their authentication credentials
* Instructions not to reuse previously used passwords
* Instructions to change passwords if there is any suspicion the password could be compromised.

Hint 131

8.4.a Examine procedures and interview personnel to verify that authentication procedures and policies are distributed to all users.

8.4.b Review authentication procedures and policies that are distributed to users and verify they include:

* Guidance on selecting strong authentication credentials
* Guidance for how users should protect their authentication credentials.
* Instructions for users not to reuse previously used passwords
* Instructions to change passwords if there is any suspicion the password could be compromised.

8.4.c Interview a sample of users to verify that they are familiar with authentication procedures and policies.

Front 132

8.5

Back 132

Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:

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

Hint 132

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

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

8.5.b Examine authentication policies/procedures to verify that use of group and shared IDs and/or passwords or other authentication methods are explicitly prohibited.

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.

Front 133

8.5.1

Back 133

Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

Note: This requirement is not intended to apply to shared hosting providers accessing their own hosting environment, where multiple customer environments are hosted.

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

Hint 133

8.5.1 Additional testing procedure for service providers: Examine authentication policies and procedures and interview personnel to verify that different authentication are used for access to each customer.

Front 134

8.6

Back 134

Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows:

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

Hint 134

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.

8.6.b Interview security personnel to verify authentication mechanisms are assigned to an account and not shared among multiple accounts.

8.6.c Examine system configuration settings and/or physical controls, as applicable, to verify that controls are implemented to ensure only the intended account can use that mechanism to gain access.

Front 135

8.7

Back 135

All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows:

* All user access to, user queries of, and user actions on databases are through programmatic methods.
* Only database administrators have the ability to directly access or query databases.
* Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes).

Hint 135

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

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

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.

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

Front 136

8.8

Back 136

Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.

Hint 136

8.8 Examine documentation interview personnel to verify that security policies and operational procedures for identification and authentication are:

* Documented,
* In use, and
* Known to all affected parties.

Front 137

9.0

Back 137

Restrict physical access to cardholder data

Hint 137

Locks, Gates, Key Pads, Fences

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

Front 138

9.1

Back 138

Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.

Hint 138

(Facility Entry Controls)

9.1 Verify the existence of physical security controls for each computer room, data center, and other physical areas with systems in the cardholder data environment.

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

Front 139

9.1.1

Back 139

Use video cameras and/or access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.

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.

Hint 139

9.1.1.a Verify that video cameras and/or access control mechanisms are in place to monitor the entry/exit points to sensitive areas.

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

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.

Front 140

9.1.2

Back 140

Implement physical and/or logical controls to restrict access to publicly accessible network jacks.

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.

Hint 140

9.1.2 Interview responsible personnel and observe locations of publicly accessible network jacks to verify that physical and/or logical controls are in place to restrict access to publicly accessible network jacks.

Front 141

9.1.3

Back 141

Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines

Hint 141

9.1.3 Verify that physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines is appropriately restricted.

Front 142

9.2

Back 142

Develop procedures to easily distinguish between onsite personnel and visitors, to include:

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

Hint 142

9.2.a Review documented processes to verify that procedures are defined for identifying and distinguishing between onsite personnel and visitors.
Verify procedures include the following:

* Identifying new onsite personnel or visitors (for example, assigning badges),
* Changing access requirements, and
* Revoking terminated onsite personnel and expired visitor identification (such as ID badges)

9.2.b Observe processes for identifying and distinguishing between onsite personnel and visitors to verify that:
* Visitors are clearly identified, and
* It is easy to distinguish between onsite personnel and visitors.

9.2.c Verify that access to the identification process (such as a badge system) is limited to authorized personnel.

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.

Front 143

9.3

Back 143

Control physical access for onsite personnel to the sensitive areas as follows:
 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.

Hint 143

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.

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 review access control lists to verify the personnel do not have physical access to the CDE.

Front 144

9.4

Back 144

Implement procedures to identify and authorize visitors.
Procedures should include the following:

Hint 144

9.4 Verify that visitor authorization and access controls are in place as follows:

Front 145

9.4.1

Back 145

Visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained.

Hint 145

9.4.1.a Observe procedures and interview personnel to verify that visitors must be authorized before they are granted access to, and escorted at all times within, areas where cardholder data is processed or maintained.

9.4.1.b Observe the use of visitor badges or other identification to verify that a physical token badge does not permit unescorted access to physical areas where cardholder data is processed or maintained.

Front 146

9.4.2

Back 146

Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel.

Hint 146

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.

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

Front 147

9.4.3

Back 147

Visitors are asked to surrender the badge or identification before leaving the facility or at the date of expiration.

Hint 147

9.4.3 Observe visitors leaving the facility to verify visitors are asked to surrender their badge or other identification upon departure or expiration.

Front 148

9.4.4

Back 148

A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted.
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.

Hint 148

(Visitor Log)

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.

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.

Front 149

9.5

Back 149

Physically secure all media

Hint 149

(Secure All Media)

9.5 Verify that procedures for protecting cardholder data include controls for physically securing all media (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes).

Front 150

9.5.1

Back 150

Store media backups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually.

Hint 150

(Media Backups)

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

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

Front 151

9.6

Back 151

Maintain strict control over the internal or external distribution of any kind of media, including the following:

Hint 151

9.6 Verify that a policy exists to control distribution of media, and that the policy covers all distributed media including that distributed to individuals.

Front 152

9.6.1

Back 152

Classify media so the sensitivity of the data can be determined.

Hint 152

9.6.1 Verify that all media is classified so the sensitivity of the data can be determined.

Front 153

9.6.2

Back 153

Send the media by secured courier or other delivery method that can be accurately tracked.

Hint 153

9.6.2.a Interview personnel and examine records to verify that all media sent outside the facility is logged and sent via secured courier or other delivery method that can be tracked.

9.6.2.b Select a recent sample of several days of offsite tracking logs for all media, and verify tracking details are documented.

Front 154

9.6.3

Back 154

Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals).

Hint 154

9.6.3 Select a recent sample of several days of offsite tracking logs for all media. From examination of the logs and interviews with responsible personnel, verify proper management authorization is obtained whenever media is moved from a secured area (including when media is distributed to individuals).

Front 155

9.7

Back 155

Maintain strict control over the storage and accessibility of media.

Hint 155

9.7 Obtain and examine the policy for controlling storage and maintenance of all media and verify that the policy requires periodic media inventories.

Front 156

9.7.1

Back 156

Properly maintain inventory logs of all media and conduct media inventories at least annually.

Hint 156

9.7.1 Review media inventory logs to verify that logs are maintained and media inventories are performed at least annually.

Front 157

9.8

Back 157

Destroy media when it is no longer needed for business or legal reasons as follows:

Hint 157

9.8 Examine the periodic media destruction policy and verify that it covers all media and defines requirements for the following:

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

Front 158

9.8.1

Back 158

Shred, incinerate, or pulp hard-copy materials so that cardholder data cannot be reconstructed. Secure storage containers used for materials that are to be destroyed.

Hint 158

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.

9.8.1.b Examine storage containers used for materials that contain information to be destroyed to verify that the containers are secured.

Front 159

9.8.2

Back 159

Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed.

Hint 159

9.8.2 Verify that cardholder data on electronic media is rendered unrecoverable via a secure wipe program in accordance with industry-accepted standards for secure deletion, or otherwise physically destroying the media).

Front 160

9.9

Back 160

Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.

Note: These requirements apply to card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads.

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

Hint 160

9.9 Examine documented policies and procedures to verify they include:

* Maintaining a list of devices
* Periodically inspecting devices to look for tampering or substitution
* Training personnel to be aware of suspicious behavior and to report tampering or substitution of devices.

Front 161

9.9.1

Back 161

Maintain an up-to-date list of devices. The list should include the following:

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

Hint 161

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

* 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.b Select a sample of devices from the list and observe device locations to verify that the list is accurate and up to date.

9.9.1.c Interview personnel to verify the list of devices is updated when devices are added, relocated, decommissioned, etc.

Front 162

9.9.2

Back 162

Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device).

Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings.

Hint 162

9.9.2.a Examine documented procedures to verify processes are defined to include the following:

* Procedures for inspecting devices
* Frequency of inspections.

9.9.2.b Interview responsible personnel and observe inspection processes to verify:

* Personnel are aware of procedures for inspecting devices.
* All devices are periodically inspected for evidence of tampering and substitution.

Front 163

9.9.3

Back 163

Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following:

* Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices.
* Do not install, replace, or return devices without verification.
* Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices).
* Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

Hint 163

9.9.3.a Review training materials for personnel at point-of-sale locations to verify they include training in the following:

* Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices
* Not to install, replace, or return devices without verification
* Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices)
* Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

9.9.3.b Interview a sample of personnel at point-of-sale locations to verify they have received training and are aware of the procedures for the following:

* Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices
* Not to install, replace, or return devices without verification
* Being aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices)
* Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

Front 164

9.10

Back 164

Ensure that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties.

Hint 164

9.10 Examine documentation and interview personnel to verify that security policies and operational procedures for restricting physical access to cardholder data are:
* Documented,
* In use, and
* Known to all affected parties.

Front 165

10.0

Back 165

Track and monitor all access to network resources and cardholder data

Hint 165

Logs, Audit Trails

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

Front 166

10.1

Back 166

Implement audit trails to link all access to system components to each individual user.

Hint 166

10.1 Verify, through observation and interviewing the system administrator, that:

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

Front 167

10.2

Back 167

Implement automated audit trails for all system components to reconstruct the following events:

Hint 167

10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following:

Front 168

10.2.1

Back 168

All individual user accesses to cardholder data

Hint 168

10.2.1 Verify all individual access to cardholder data is logged.

Front 169

10.2.2

Back 169

All actions taken by any individual with root or administrative privileges

Hint 169

10.2.2 Verify all actions taken by any individual with root or administrative privileges are logged.

Front 170

10.2.3

Back 170

Access to all audit trails

Hint 170

10.2.3 Verify access to all audit trails is logged.

Front 171

10.2.4

Back 171

Invalid logical access attempts

Hint 171

10.2.4 Verify invalid logical access attempts are logged.

Front 172

10.2.5

Back 172

Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges

Hint 172

10.2.5.a Verify use of identification and authentication mechanisms is logged.

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.

Front 173

10.2.6

Back 173

Initialization, stopping, or pausing of audit logs

Hint 173

10.2.6 Verify the following are logged:

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

Front 174

10.2.7

Back 174

Creation and deletion of system-level objects

Hint 174

10.2.7 Verify creation and deletion of system level objects are logged.

Front 175

10.3

Back 175

Record at least the following audit trail entries for all system components for each event:

Hint 175

10.3 Through interviews and observation of audit logs, for each auditable event (from 10.2), perform the following:

Front 176

10.3.1

Back 176

User identification

Hint 176

10.3.1 Verify user identification is included in log entries

Front 177

10.3.2

Back 177

Type of event

Hint 177

10.3.2 Verify type of event is included in log entries.

Front 178

10.3.3

Back 178

Date and time

Hint 178

10.3.3 Verify date and time stamp is included in log entries.

Front 179

10.3.4

Back 179

Success or failure indication

Hint 179

10.3.4 Verify success or failure indication is included in log entries.

Front 180

10.3.5

Back 180

Origination of event

Hint 180

10.3.5 Verify origination of event is included in log entries.

Front 181

10.3.6

Back 181

Identity or name of affected data, system component, or resource.

Hint 181

10.3.6 Verify identity or name of affected data, system component, or resources is included in log entries.

Front 182

10.4

Back 182

Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.

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

Hint 182

Examine configuration standards and processes to verify that time-synchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and 6.2.

Front 183

10.4.1

Back 183

Critical systems have the correct and consistent time.

Hint 183

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

* 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.
* Where there is more than one designated time server, the time servers peer with one another to keep accurate time,
* Systems receive time information only from designated central time server(s).

10.4.1.b Observe the time-related system-parameter settings for a sample of system components to verify:

* 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.
* Where there is more than one designated time server, the designated central time server(s) peer with one another to keep accurate time.
* Systems receive time only from designated central time server(s).

Front 184

10.4.2

Back 184

Time data is protected.

Hint 184

10.4.2.a Examine system configurations and time-synchronization settings to verify that access to time data is restricted to only personnel with a business need to access time data.

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.

Front 185

10.4.3

Back 185

Time settings are received from industry-accepted time sources.

Hint 185

10.4.3 Examine systems configurations to verify that the time server(s) accept time updates from specific, industry-accepted external sources (to prevent a malicious individual from changing the clock).

Optionally, those updates can be encrypted with a symmetric key, and access control lists can be created that specify the IP addresses of client machines that will be provided with the time updates (to prevent unauthorized use of internal time servers).

Front 186

10.5

Back 186

Secure audit trails so they cannot be altered.

Hint 186

10.5 Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered as follows:

Front 187

10.5.1

Back 187

Limit viewing of audit trails to those with a job-related need.

Hint 187

10.5.1 Only individuals who have a job-related need can view audit trail files.

Front 188

10.5.2

Back 188

Protect audit trail files from unauthorized modifications.

Hint 188

10.5.2 Current audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation.

Front 189

10.5.3

Back 189

Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

Hint 189

10.5.3 Current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter.

Front 190

10.5.4

Back 190

Write logs for external-facing technologies onto a secure, centralized, internal log server or media device.

Hint 190

10.5.4 Logs for external-facing technologies (for example, wireless, firewalls, DNS, mail) are written onto a secure, centralized, internal log server or media.

Front 191

10.5.5

Back 191

Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

Hint 191

10.5.5 Examine system settings, monitored files, and results from monitoring activities to verify the use of file-integrity monitoring or change-detection software on logs.

Front 192

10.6

Back 192

Review logs and security events for all system components to identify anomalies or suspicious activity.

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

Hint 192

Perform the following:

Front 193

10.6.1

Back 193

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

Hint 193

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

10.6.1.b Observe processes and interview personnel to verify that the following are reviewed 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.).

Front 194

10.6.2

Back 194

Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.

Hint 194

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.

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.

Front 195

10.6.3

Back 195

Follow up exceptions and anomalies identified during the review process.

Hint 195

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.

10.6.3.b Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed.

Front 196

10.7

Back 196

Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).

Hint 196

10.7.a Examine security policies and procedures to verify that they define the following:

* Audit log retention policies
* Procedures for retaining audit logs for at least one year, with a minimum of three months immediately available online.

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

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

Front 197

10.8

Back 197

Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.

Hint 197

10.8 Examine documentation interview personnel to verify that security policies and operational procedures for monitoring all access to network resources and cardholder data are:

* Documented,
* In use, and
* Known to all affected parties.

Front 198

11.0

Back 198

Regularly test security systems and processes

Hint 198

Making sure security controls reflect a changing environment

Front 199

11.1

Back 199

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.

Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices.

Hint 199

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.

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

* WLAN cards inserted into system components
* Portable or mobile devices attached to system components to create a wireless access point (for example, by USB, etc.)
* Wireless devices attached to a network port or network device.

11.1.c Examine output from recent wireless scans to verify that:

* Authorized and unauthorized wireless access points are identified, and
* The scan is performed at least quarterly for all system components and facilities.

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

Front 200

11.1.1

Back 200

Maintain an inventory of authorized wireless access points including a documented business justification.

Hint 200

11.1.1 Examine documented records to verify that an inventory of authorized wireless access points is maintained and a business justification is documented for all authorized wireless access points.

Front 201

11.1.2

Back 201

Implement incident response procedures in the event unauthorized wireless access points are detected.

Hint 201

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.

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.

Front 202

11.2

Back 202

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

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

Hint 202

11.2 Examine scan reports and supporting documentation to verify that internal and external vulnerability scans are performed as follows:

Front 203

11.2.1

Back 203

Perform quarterly internal vulnerability scans and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.

Hint 203

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

11.2.1.b Review the scan reports and verify that the scan process includes rescans until all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

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

Front 204

11.2.2

Back 204

Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

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). Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.

Hint 204

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.

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

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

Front 205

11.2.3

Back 205

Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.

Hint 205

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.

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

* For external scans, no vulnerabilities exist that are scored 4.0 or higher by the CVSS.
* For internal scans, all “high-risk” vulnerabilities as defined in PCI DSS Requirement 6.1 are resolved.

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

Front 206

11.3

Back 206

Implement a methodology for penetration testing that includes the following:

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

Hint 206

11.3 Examine penetration-testing methodology and interview responsible personnel to verify a methodology is implemented that includes the following:

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

Front 207

11.3.1

Back 207

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

Hint 207

11.3.1.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed as follows:

* Per the defined methodology
* At least annually
* After any significant changes to the environment.

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

Front 208

11.3.2

Back 208

Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).

Hint 208

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.

* Per the defined methodology
* At least annually
* After any significant changes to the environment.

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

Front 209

11.3.3

Back 209

Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections.

Hint 209

11.3.3 Examine penetration testing results to verify that noted exploitable vulnerabilities were corrected and that repeated testing confirmed the vulnerability was corrected.

Front 210

11.3.4

Back 210

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.

Hint 210

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.

11.3.4.b Examine the results from the most recent penetration test to verify that penetration testing to verify segmentation controls:

* Is performed at least annually and after any changes to segmentation controls/methods.
* Covers all segmentation controls/methods in use.
* Verifies that segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.

Front 211

11.4

Back 211

Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.

Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.

Hint 211

11.4.a Examine system configurations and network diagrams to verify that techniques (such as intrusion-detection systems and/or intrusion-prevention systems) are in place to monitor all traffic:

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

11.4.b Examine system configurations and interview responsible personnel to confirm intrusion-detection and/or intrusion-prevention techniques alert personnel of suspected compromises.

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.

Front 212

11.5

Back 212

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.

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

Hint 212

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.
Examples of files that should be monitored:

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

11.5.b Verify the mechanism is configured to alert personnel to unauthorized modification of critical files, and to perform critical file comparisons at least weekly.

Front 213

11.5.1

Back 213

Implement a process to respond to any alerts generated by the change-detection solution.

Hint 213

11.5.1 Interview personnel to verify that all alerts are investigated and resolved.

Front 214

11.6

Back 214

Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties.

Hint 214

11.6 Examine documentation interview personnel to verify that security policies and operational procedures for security monitoring and testing are:

* Documented,
* In use, and
* Known to all affected parties.

Front 215

12.0

Back 215

Maintain a policy that addresses information security for all personnel

Hint 215

Applies to all personnel

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.

Front 216

12.1

Back 216

Establish, publish, maintain, and disseminate a security policy.

Hint 216

12.1 Examine the information security policy and verify that the policy is published and disseminated to all relevant personnel (including vendors and business partners).

Front 217

12.1.1

Back 217

Review the security policy at least annually and update the policy when the environment changes.

Hint 217

12.1.1 Verify that the information security policy is reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment.

Front 218

12.2

Back 218

Implement a risk-assessment process that:

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

Hint 218

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

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.

Front 219

12.3

Back 219

Develop usage policies for critical technologies and define proper use of these technologies.

Note: Examples of critical technologies include, but are not limited to, remote access and wireless technologies, laptops, tablets, removable electronic media, e-mail usage and Internet usage.

Ensure these usage policies require the following:

Hint 219

12.3 Examine the usage policies for critical technologies and interview responsible personnel to verify the following policies are implemented and followed:

Front 220

12.3.1

Back 220

Explicit approval by authorized parties

Hint 220

12.3.1 Verify that the usage policies include processes for explicit approval from authorized parties to use the technologies.

Front 221

12.3.2

Back 221

Authentication for use of the technology

Hint 221

12.3.2 Verify that the usage policies include processes for all technology use to be authenticated with user ID and password or other authentication item (for example, token).

Front 222

12.3.3

Back 222

A list of all such devices and personnel with access

Hint 222

12.3.3 Verify that the usage policies define a list of all devices and personnel authorized to use the devices.

Front 223

12.3.4

Back 223

A method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices)

Hint 223

12.3.4 Verify that the usage policies define a method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices).

Front 224

12.3.5

Back 224

Acceptable uses of the technology

Hint 224

12.3.5 Verify that the usage policies define acceptable uses for the technology.

Front 225

12.3.6

Back 225

Acceptable network locations for the technologies

Hint 225

12.3.6 Verify that the usage policies define acceptable network locations for the technology.

Front 226

12.3.7

Back 226

List of company-approved products

Hint 226

Verify that the usage policies include a list of company-approved products.

Front 227

12.3.8

Back 227

Automatic disconnect of sessions for remote access technologies after a specific period of inactivity.

Hint 227

12.3.8.a Verify that the usage policies require automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.

12.3.8.b Examine configurations for remote access technologies to verify that remote access sessions will be automatically disconnected after a specific period of inactivity.

Front 228

12.3.9

Back 228

Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use

Hint 228

12.3.9 Verify that the usage policies require activation of remote-access technologies used by vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use.

Front 229

12.3.10

Back 229

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.
Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.

Hint 229

12.3.10.a Verify that the usage policies prohibit copying, moving, or storing of cardholder data onto local hard drives and removable electronic media when accessing such data via remote-access technologies.

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

Front 230

12.4

Back 230

Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.

Hint 230

12.4.a Verify that information security policies clearly define information security responsibilities for all personnel.

12.4.b Interview a sample of responsible personnel to verify they understand the security policies.

Front 231

12.5

Back 231

Assign to an individual or team the following information security management responsibilities:

Hint 231

12.5 Examine information security policies and procedures to verify:

* The formal assignment of information security to a Chief Security Officer or other security-knowledgeable member of management.
* The following information security responsibilities are specifically and formally assigned:

Front 232

12.5.1

Back 232

Establish, document, and distribute security policies and procedures.

Hint 232

12.5.1 Verify that responsibility for establishing, documenting and distributing security policies and procedures is formally assigned.

Front 233

12.5.2

Back 233

Monitor and analyze security alerts and information, and distribute to appropriate personnel.

Hint 233

12.5.2 Verify that responsibility for monitoring and analyzing security alerts and distributing information to appropriate information security and business unit management personnel is formally assigned.

Front 234

12.5.3

Back 234

Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.

Hint 234

12.5.3 Verify that responsibility for establishing, documenting, and distributing security incident response and escalation procedures is formally assigned.

Front 235

12.5.4

Back 235

Administer user accounts, including additions, deletions, and modifications

Hint 235

12.5.4 Verify that responsibility for administering (adding, deleting, and modifying) user account and authentication management is formally assigned.

Front 236

12.5.5.

Back 236

Monitor and control all access to data

Hint 236

12.5.5 Verify that responsibility for monitoring and controlling all access is formally assigned.

Front 237

12.6

Back 237

Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security.

Hint 237

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

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

Front 238

12.6.1

Back 238

Educate personnel upon hire and at least annually.

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

Hint 238

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.b Verify that personnel attend security awareness training upon hire and at least annually.

12.6.1.c Interview a sample of personnel to verify they have completed awareness training and are aware of the importance of cardholder data security.

Front 239

12.6.2

Back 239

Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures.

Hint 239

12.6.2 Verify that the security awareness program requires personnel to acknowledge, in writing or electronically, at least annually, that they have read and understand the information security policy.

Front 240

12.7

Back 240

Screen potential personnel prior to hire to minimize the risk of attacks from internal sources. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.)

Note: For those potential personnel to be hired for certain positions such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only.

Hint 240

12.7 Inquire with Human Resource department management and verify that background checks are conducted (within the constraints of local laws) prior to hire on potential personnel who will have access to cardholder data or the cardholder data environment.

Front 241

12.8

Back 241

Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows:

Hint 241

12.8 Through observation, review of policies and procedures, and review of supporting documentation, verify that processes are implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data (for example, backup tape storage facilities, managed service providers such as web-hosting companies or security service providers, those that receive data for fraud modeling purposes, etc.), as follows:

Front 242

12.8.1

Back 242

Maintain a list of sevice providers

Hint 242

12.8.1 Verify that a list of service providers is maintained.

Front 243

12.8.2

Back 243

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.

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.

Hint 243

12.8.2 Observe written agreements and confirm they include an acknowledgement by service providers that they 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.

Front 244

12.8.3

Back 244

Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

Hint 244

12.8.3 Verify that policies and procedures are documented and implemented including proper due diligence prior to engaging any service provider.

Front 245

12.8.4

Back 245

Maintain a program to monitor service providers' PCI DSS compliance status at least annually.

Hint 245

12.8.4 Verify that the entity maintains a program to monitor its service providers' PCI DSS compliance status at least annually.

Front 246

12.8.5

Back 246

Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

Hint 246

12.8.5 Verify the entity maintains information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

Front 247

12.9

Back 247

Additional requirement for service providers: Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

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

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.

Hint 247

12.9 Additional testing procedure for service providers: Review service provider’s policies and procedures and observe written agreement templates to confirm the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer's cardholder data environment on behalf of a customer.

Front 248

12.10

Back 248

Implement an incident response plan. Be prepared to respond immediately to a system breach.

Hint 248

12.10 Examine the incident response plan and related procedures to verify entity is prepared to respond immediately to a system breach by performing the following:

Front 249

12.10.1

Back 249

Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:

* Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum
* Specific incident response procedures
* Business recovery and continuity procedures
* Data 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.

Hint 249

12.10.1.a Verify that the incident response plan includes:

* 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 system components
* Reference or inclusion of incident response procedures from the payment brands.

12.10.1.b Interview personnel and review documentation from a sample of previously reported incidents or alerts to verify that the documented incident response plan and procedures were followed.

Front 250

12.10.2

Back 250

Test the plan at least annually.

Hint 250

12.10.2 Verify that the plan is tested at least annually.

Front 251

12.10.3

Back 251

Designate the specific personnel to be available on a 24/7 basis to respond to alerts.

Hint 251

Verify through observation, review of policies, and interviews of responsible personnel that designated personnel are available for 24/7 incident response and monitoring coverage for any evidence of unauthorized activity, detection of unauthorized wireless access points, critical IDS alerts, and/or reports of unauthorized critical system or content file changes.

Front 252

12.10.4

Back 252

Provide appropriate training to staff with security breach response responsibilities.

Hint 252

12.10.4 Verify through observation, review of policies, and interviews of responsible personnel that staff with responsibilities for security breach response are periodically trained.

Front 253

12.10.5

Back 253

Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring systems.

Hint 253

12.10.5 Verify through observation and review of processes that monitoring and responding to alerts from security monitoring systems, including detection of unauthorized wireless access points, are covered in the incident response plan.

Front 254

12.10.6

Back 254

Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.

Hint 254

12.10.6 Verify through observation, review of policies, and interviews of responsible personnel that there is a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.

Front 255

Appendix A.1

Back 255

Shared hosting providers must protect the cardholder data environment

Hint 255

As referenced in Requirement 12.8 and 12.9, all service providers with access to cardholder data (including shared hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.6 states that shared hosting providers must protect each entity’s hosted environment and data. Therefore, shared hosting providers must additionally comply with the requirements in this Appendix.

Front 256

A.1

Back 256

Protect each entity’s (that is, merchant, service provider, or other entity) hosted environment and data, per A.1.1 through A.1.4:
A hosting provider must fulfill these requirements as well as all other relevant sections of the PCI DSS.

Note: Even though a hosting provider may meet these requirements, the compliance of the entity that uses the hosting provider is not guaranteed. Each entity must comply with the PCI DSS and validate compliance as applicable.

Hint 256

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

Front 257

A.1.1

Back 257

Ensure that each entity only runs processes that have access to that entity's cardholder data environment.

Hint 257

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.

Front 258

A.1.2

Back 258

Restrict each entity’s access and privileges to its own cardholder data environment only.

Hint 258

A.1.2.a Verify the user ID of any application process is not a privileged user (root/admin).

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

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

A.1.2.d Verify that viewing of log entries is restricted to the owning entity.

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

Front 259

A.1.3

Back 259

Ensure logging and audit trails are enabled and unique to each entity’s cardholder data environment and consistent with PCI DSS Requirement 10.

Hint 259

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.

Front 260

A.1.4

Back 260

Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider.

Hint 260

A.1.4 Verify the shared hosting provider has written policies that provide for a timely forensics investigation of related servers in the event of a compromise.