Payment Card Industry Data Security Standard (PCI DSS) v3.2.1

pci_3.2.1_aws

PCIv3.2.1

OfficialVerified

The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard. It's administered by the PCI Security Standards Council, which was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. PCI DSS applies to entities that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD). This includes, but isn't limited to, merchants, processors, acquirers, issuers, and service providers. The PCI DSS is mandated by the card brands and administered by the Payment Card Industry Security Standards Council.

147requirements98checks

Prowler prowler-provider-aws

Run this compliance with Prowler

Run in Prowler Cloud

Run

prowler aws --compliance pci_3.2.1_aws

Requirements (147)

Requirement 1: Install and maintain a firewall configuration to protect cardholder data19166

1.1Firewalls and routers are key components of the architecture that controls entry to and exit from the network. These devices are software or hardware devices that block unwanted access and manage authorized access into and out of the network. Configuration standards and procedures will help to ensure that the organization's first line of defense in the protection of its data remains strong.3

Attributes

Item Id: 1.1
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data

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

Attributes

Item Id: 1.1.4
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 1.1 Establish and implement firewall and router configuration standards

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

Attributes

Item Id: 1.1.4.c
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone

1.2It is essential to install network protection between the internal, trusted network and any untrusted network that is external and/or out of the entity's ability to control or manage. Failure to implement this measure correctly results in the entity being vulnerable to unauthorized access by malicious individuals or software. For firewall functionality to be effective, it must be properly configured to control and/or limit traffic into and out of the entity's network.17

Attributes

Item Id: 1.2
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data

1.2.1Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, thus preventing unfiltered access between untrusted and trusted environments. This prevents malicious individuals from accessing the entity's network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they've obtained from within the entity's network out to an untrusted server). Implementing a rule that denies all inbound and outbound traffic that is not specifically needed helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic in or out.17

Attributes

Item Id: 1.2.1
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

1.2.1.aExamination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, thus preventing unfiltered access between untrusted and trusted environments. This prevents malicious individuals from accessing the entity's network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they've obtained from within the entity's network out to an untrusted server). Implementing a rule that denies all inbound and outbound traffic that is not specifically needed helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic in or out.16

Attributes

Item Id: 1.2.1.a
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic

1.2.1.bExamination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, thus preventing unfiltered access between untrusted and trusted environments. This prevents malicious individuals from accessing the entity's network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they've obtained from within the entity's network out to an untrusted server). Implementing a rule that denies all inbound and outbound traffic that is not specifically needed helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic in or out.16

Attributes

Item Id: 1.2.1.b
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic

1.2.1.cExamination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, thus preventing unfiltered access between untrusted and trusted environments. This prevents malicious individuals from accessing the entity's network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner (for example, to send data they've obtained from within the entity's network out to an untrusted server). Implementing a rule that denies all inbound and outbound traffic that is not specifically needed helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic in or out.16

Attributes

Item Id: 1.2.1.c
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic

1.2.2While the running (or active) router configuration files include the current, secure settings, the start- up files (which are used when routers are re- started or booted) must be updated with the same secure settings to ensure these settings are applied when the start-up configuration is run. Because they only run occasionally, start-up configuration files are often forgotten and are not updated. When a router re-starts and loads a start-up configuration that has not been updated with the same secure settings as those in the running configuration, it may result in weaker rules that allow malicious individuals into the network.0

Attributes

Item Id: 1.2.2
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

1.2.2.bWhile the running (or active) router configuration files include the current, secure settings, the start- up files (which are used when routers are re- started or booted) must be updated with the same secure settings to ensure these settings are applied when the start-up configuration is run. Because they only run occasionally, start-up configuration files are often forgotten and are not updated. When a router re-starts and loads a start-up configuration that has not been updated with the same secure settings as those in the running configuration, it may result in weaker rules that allow malicious individuals into the network.0

Attributes

Item Id: 1.2.2.b
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 1.2.2 Secure and synchronize router configuration files

1.2.3The known (or unknown) implementation and exploitation of wireless technology within a network is a common path for malicious individuals to gain access to the network and cardholder data. If a wireless device or network is installed without the entity's knowledge, a malicious individual could easily and “invisibly” enter the network. If firewalls do not restrict access from wireless networks into the CDE, malicious individuals that gain unauthorized access to the wireless network can easily connect to the CDE and compromise account information. Firewalls must be installed between all wireless networks and the CDE, regardless of the purpose of the environment to which the wireless network is connected. This may include, but is not limited to, corporate networks, retail stores, guest networks, warehouse environments, etc.4

Attributes

Item Id: 1.2.3
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

1.2.3.bThe known (or unknown) implementation and exploitation of wireless technology within a network is a common path for malicious individuals to gain access to the network and cardholder data. If a wireless device or network is installed without the entity's knowledge, a malicious individual could easily and “invisibly” enter the network. If firewalls do not restrict access from wireless networks into the CDE, malicious individuals that gain unauthorized access to the wireless network can easily connect to the CDE and compromise account information. Firewalls must be installed between all wireless networks and the CDE, regardless of the purpose of the environment to which the wireless network is connected. This may include, but is not limited to, corporate networks, retail stores, guest networks, warehouse environments, etc.4

Attributes

Item Id: 1.2.3.b
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 1.2.3 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

1.3While there may be legitimate reasons for untrusted connections to be permitted to DMZ systems (e.g., to allow public access to a web server), such connections should never be granted to systems in the internal network. A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise.24

Attributes

Item Id: 1.3
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data

1.3.1The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server). This functionality is intended to prevent malicious individuals from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner. The set of controls will 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.12

Attributes

Item Id: 1.3.1
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

1.3.2The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server). This functionality is intended to prevent malicious individuals from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner. The set of controls will limit inbound Internet traffic to IP addresses within the DMZ.12

Attributes

Item Id: 1.3.2
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

1.3.3Normally a packet contains the IP address of the computer that originally sent it so other computers in the network know where the packet came from. Malicious individuals will often try to spoof (or imitate) the sending IP address so that the target system believes the packet is from a trusted source. Filtering packets coming into the network helps to, among other things, ensure packets are not “spoofed” to look like they are coming from an organization's own internal network.0

Attributes

Item Id: 1.3.3
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

1.3.4All traffic outbound from the cardholder data environment should be evaluated to ensure that it follows established, authorized rules. Connections should be inspected to restrict traffic to only authorized communications (for example by restricting source/destination addresses/ports, and/or blocking of content). The set of controls will examine firewall and router configurations to verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized.9

Attributes

Item Id: 1.3.4
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

1.3.5A firewall that maintains the `state` (or the status) for each connection through the firewall knows whether an apparent response to a previous connection is actually a valid, authorized response (since it retains each connection's status) or is malicious traffic trying to trick the firewall into allowing the connection.2

Attributes

Item Id: 1.3.5
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

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

Attributes

Item Id: 1.3.6
Section: Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Sub Section: 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

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters1253

2.1This 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, payment applications, Simple Network Management Protocol (SNMP) community strings, etc. Malicious individuals (external and internal to an organization) often use vendor default settings, account names, and passwords to compromise operating system software, applications, and the systems on which they are installed. Because these default settings are often published and are well known in hacker communities, changing these settings will leave systems less vulnerable to attack. Even if a default account is not intended to be used, changing the default password to a strong unique password and then disabling the account will prevent a malicious individual from re-enabling the account and gaining access with the default password.2

Attributes

Item Id: 2.1
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

2.1.bMalicious individuals (external and internal to an organization) often use vendor default settings, account names, and passwords to compromise operating system software, applications, and the systems on which they are installed. Because these default settings are often published and are well known in hacker communities, changing these settings will leave systems less vulnerable to attack. Even if a default account is not intended to be used, changing the default password to a strong unique password and then disabling the account will prevent a malicious individual from re-enabling the account and gaining access with the default password.2

Attributes

Item Id: 2.1.b
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network

2.2Assure 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 and National Institute of Standards Technology (NIST). There are known weaknesses with many operating systems, databases, and enterprise applications, and there are also known ways to configure these systems to fix security vulnerabilities. To help those that are not security experts, a number of security organizations have established system-hardening guidelines and recommendations, which advise how to correct these weaknesses. Examples of sources for guidance on configuration standards include, but are not limited to: www.nist.gov, www.sans.org, and www.cisecurity.org, www.iso.org, and product vendors. System configuration standards must be kept up to date to ensure that newly identified weaknesses are corrected prior to a system being installed on the network.19

Attributes

Item Id: 2.2
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

2.2.2As stated in Requirement 1.1.6, there are many protocols that a business may need (or have enabled by default) that are commonly used by malicious individuals to compromise a network. Including this requirement as part of an organization's configuration standards and related processes ensures that only the necessary services and protocols are enabled.15

Attributes

Item Id: 2.2.2
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: 2.2 Develop configuration standards for all system components

2.2.4System configuration standards and related processes should specifically address security settings and parameters that have known security implications for each type of system in use. In order for systems to be configured securely, personnel responsible for configuration and/or administering systems must be knowledgeable in the specific security parameters and settings that apply to the system.1

Attributes

Item Id: 2.2.4
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: 2.2 Develop configuration standards for all system components

2.2.5Unnecessary functions can provide additional opportunities for malicious individuals to gain access to a system. By removing unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited. Including this in server-hardening standards and processes addresses the specific security implications associated with unnecessary functions (for example, by removing/disabling FTP or the web server if the server will not be performing those functions).1

Attributes

Item Id: 2.2.5
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: 2.2 Develop configuration standards for all system components

2.2.5.bUnnecessary functions can provide additional opportunities for malicious individuals to gain access to a system. By removing unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited. Including this in server-hardening standards and processes addresses the specific security implications associated with unnecessary functions (for example, by removing/disabling FTP or the web server if the server will not be performing those functions).1

Attributes

Item Id: 2.2.5.b
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: 2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers

2.2.aThere are known weaknesses with many operating systems, databases, and enterprise applications, and there are also known ways to configure these systems to fix security vulnerabilities. To help those that are not security experts, a number of security organizations have established system-hardening guidelines and recommendations, which advise how to correct these weaknesses. Examples of sources for guidance on configuration standards include, but are not limited to: www.nist.gov, www.sans.org, and www.cisecurity.org, www.iso.org, and product vendors. System configuration standards must be kept up to date to ensure that newly identified weaknesses are corrected prior to a system being installed on the network.2

Attributes

Item Id: 2.2.a
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: 2.2 Develop configuration standards for all system components

2.2.dSystem 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 and removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. There are known weaknesses with many operating systems, databases, and enterprise applications, and there are also known ways to configure these systems to fix security vulnerabilities. To help those that are not security experts, a number of security organizations have established system-hardening guidelines and recommendations, which advise how to correct these weaknesses. Examples of sources for guidance on configuration standards include, but are not limited to: www.nist.gov, www.sans.org, and www.cisecurity.org, www.iso.org, and product vendors. System configuration standards must be kept up to date to ensure that newly identified weaknesses are corrected prior to a system being installed on the network.2

Attributes

Item Id: 2.2.d
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: 2.2 Develop configuration standards for all system components

2.3If non-console (including remote) administration does not use secure authentication and encrypted communications, sensitive administrative or operational level information (like administrator's IDs and passwords) can be revealed to an eavesdropper. A malicious individual could use this information to access the network, become administrator, and steal data. Clear-text protocols (such as HTTP, telnet, etc.) do not encrypt traffic or logon details, making it easy for an eavesdropper to intercept this information. Select a sample of system components and verify that non-console administrative access is encrypted.4

Attributes

Item Id: 2.3
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

2.4Maintaining a current list of all system components will enable an organization to accurately and efficiently define the scope of their environment for implementing PCI DSS controls. Without an inventory, some system components could be forgotten, and be inadvertently excluded from the organization's configuration standards.3

Attributes

Item Id: 2.4
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

2.4.aMaintaining a current list of all system components will enable an organization to accurately and efficiently define the scope of their environment for implementing PCI DSS controls. Without an inventory, some system components could be forgotten, and be inadvertently excluded from the organization's configuration standards.1

Attributes

Item Id: 2.4.a
Section: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Sub Section: 2.4 Maintain an inventory of system components that are in scope for PCI DSS

Requirement 3: Protect stored cardholder data18152

3.1Procedures and processes should 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/or business requirements, specific retention requirements for cardholder data, processes for secure deletion of data when no longer needed, a quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention. Identifying and deleting stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated or manual or a combination of both. For example, a programmatic procedure (automatic or manual) to locate and remove data and/or a manual review of data storage areas could be performed. Implementing secure deletion methods ensure that the data cannot be retrieved when it is no longer needed. Remember, if you don't need it, don't store it!10

Attributes

Item Id: 3.1
Section: Requirement 3: Protect stored cardholder data
Sub Section: Requirement 3: Protect stored cardholder data

3.1.aprocedures and processes should they include the following for all cardholder data (CHD) storage: limiting data storage amount and retention time to that which is required for legal, regulatory, and/or business requirements, specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons), processes for secure deletion of cardholder data when no longer needed for legal, regulatory, or business reasons and a quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements. Identifying and deleting stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated or manual or a combination of both. For example, a programmatic procedure (automatic or manual) to locate and remove data and/or a manual review of data storage areas could be performed. Implementing secure deletion methods ensure that the data cannot be retrieved when it is no longer needed. Remember, if you don't need it, don't store it!1

Attributes

Item Id: 3.1.a
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes

3.1.cIdentifying and deleting stored data that has exceeded its specified retention period prevents unnecessary retention of data that is no longer needed. This process may be automated or manual or a combination of both. For example, a programmatic procedure (automatic or manual) to locate and remove data and/or a manual review of data storage areas could be performed. Implementing secure deletion methods ensure that the data cannot be retrieved when it is no longer needed. Remember, if you don't need it, don't store it!9

Attributes

Item Id: 3.1.c
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes

3.2If 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. Sensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions. Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support issuing services to store sensitive authentication data ONLY IF they have a legitimate business need to store such data. It should be noted that all PCI DSS requirements apply to issuers, and the only exception for issuers and issuer processors is that sensitive authentication data may be retained if there is a legitimate reason to do so. A legitimate reason is one that is necessary for the performance of the function being provided for the issuer and not one of convenience. Any such data must be stored securely and in accordance with all PCI DSS and specific payment brand requirements.7

Attributes

Item Id: 3.2
Section: Requirement 3: Protect stored cardholder data
Sub Section: Requirement 3: Protect stored cardholder data

3.2.3These values should be known only to the card owner or bank that issued the card. If this data is stolen, malicious individuals can execute fraudulent PIN-based debit transactions (for example, ATM withdrawals). 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 contents6

Attributes

Item Id: 3.2.3
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.2 Do not store sensitive authentication data after authorization (even if encrypted)

3.2.cSensitive authentication data consists of full track data, card validation code or value, and PIN data. Storage of sensitive authentication data after authorization is prohibited! This data is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions. Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support issuing services to store sensitive authentication data ONLY IF they have a legitimate business need to store such data. It should be noted that all PCI DSS requirements apply to issuers, and the only exception for issuers and issuer processors is that sensitive authentication data may be retained if there is a legitimate reason to do so. A legitimate reason is one that is necessary for the performance of the function being provided for the issuer and not one of convenience. Any such data must be stored securely and in accordance with all PCI DSS and specific payment brand requirements.1

Attributes

Item Id: 3.2.c
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.2 Do not store sensitive authentication data after authorization (even if encrypted)

3.4The following approaches should be used to render PAN unreadable anywhere it is stored: 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) and 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 must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN. PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception or troubleshooting logs) must all be protected. One-way hash functions based on strong cryptography can be used to render cardholder data unreadable. Hash functions are appropriate when there is no need to retrieve the original number (one-way hashes are irreversible). It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of pre- computed hash values. The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored. An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key. The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or `home- grown` algorithm) with strong cryptographic keys. By correlating hashed and truncated versions of a given PAN, a malicious individual may easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable.23

Attributes

Item Id: 3.4
Section: Requirement 3: Protect stored cardholder data
Sub Section: Requirement 3: Protect stored cardholder data

3.4.1Decryption keys must not be associated with user accounts. Note: This requirement applies in addition to all other PCI DSS encryption and key- management requirements. PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception or troubleshooting logs) must all be protected. One-way hash functions based on strong cryptography can be used to render cardholder data unreadable. Hash functions are appropriate when there is no need to retrieve the original number (one-way hashes are irreversible). It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of pre- computed hash values. The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored. An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key. The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or `home-grown` algorithm) with strong cryptographic keys. By correlating hashed and truncated versions of a given PAN, a malicious individual may easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable.16

Attributes

Item Id: 3.4.1
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using approaches like one-way hashes based on strong cryptography, truncation etc

3.4.1.aThe intent of this requirement is to address the acceptability of disk-level encryption for rendering cardholder data unreadable. Disk-level encryption encrypts the entire disk/partition on a computer and automatically decrypts the information when an authorized user requests it. Many disk- encryption solutions intercept operating system read/write operations and carry out the appropriate cryptographic transformations without any special action by the user other than supplying a password or pass phrase upon system startup or at the beginning of a session. Based on these characteristics of disk-level encryption, to be compliant with this requirement, the method cannot: 1) Use the same user account authenticator as the operating system, or 2) Use a decryption key that is associated with or derived from the system's local user account database or general network login credentials. Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.16

Attributes

Item Id: 3.4.1.a
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.4.1 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)

3.4.1.cNote: 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. The intent of this requirement is to address the acceptability of disk-level encryption for rendering cardholder data unreadable. Disk-level encryption encrypts the entire disk/partition on a computer and automatically decrypts the information when an authorized user requests it. Many disk- encryption solutions intercept operating system read/write operations and carry out the appropriate cryptographic transformations without any special action by the user other than supplying a password or pass phrase upon system startup or at the beginning of a session. Based on these characteristics of disk-level encryption, to be compliant with this requirement, the method cannot: 1) Use the same user account authenticator as the operating system, or 2) Use a decryption key that is associated with or derived from the system's local user account database or general network login credentials. Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.16

Attributes

Item Id: 3.4.1.c
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.4.1 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)

3.4.aVerify 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. PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception or troubleshooting logs) must all be protected. One-way hash functions based on strong cryptography can be used to render cardholder data unreadable. Hash functions are appropriate when there is no need to retrieve the original number (one-way hashes are irreversible). It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of pre- computed hash values. The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored. An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key. The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or `home-grown` algorithm) with strong cryptographic keys. By correlating hashed and truncated versions of a given PAN, a malicious individual may easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable.17

Attributes

Item Id: 3.4.a
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using approaches like one-way hashes based on strong cryptography, truncation etc

3.4.bPANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception or troubleshooting logs) must all be protected. One-way hash functions based on strong cryptography can be used to render cardholder data unreadable. Hash functions are appropriate when there is no need to retrieve the original number (one-way hashes are irreversible). It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of pre- computed hash values. The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored. An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key. The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or `home- grown` algorithm) with strong cryptographic keys. By correlating hashed and truncated versions of a given PAN, a malicious individual may easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable.17

Attributes

Item Id: 3.4.b
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using approaches like one-way hashes based on strong cryptography, truncation etc

3.4.dPANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception or troubleshooting logs) must all be protected. One-way hash functions based on strong cryptography can be used to render cardholder data unreadable. Hash functions are appropriate when there is no need to retrieve the original number (one-way hashes are irreversible). It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of pre- computed hash values. The intent of truncation is to permanently remove a segment of PAN data so that only a portion (generally not to exceed the first six and last four digits) of the PAN is stored. An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key. The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or 'home-grown` algorithm) with strong cryptographic keys. By correlating hashed and truncated versions of a given PAN, a malicious individual may easily derive the original PAN value. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable.10

Attributes

Item Id: 3.4.d
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using approaches like one-way hashes based on strong cryptography, truncation etc

3.5Note: 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. Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data. Key-encrypting keys, if used, must be at least as strong as the data-encrypting key in order to ensure proper protection of the key that encrypts the data as well as the data encrypted with that key. The requirement to protect keys from disclosure and misuse applies to both data-encrypting keys and key-encrypting keys. Because one key- encrypting key may grant access to many data- encrypting keys, the key-encrypting keys require strong protection measures.2

Attributes

Item Id: 3.5
Section: Requirement 3: Protect stored cardholder data
Sub Section: Requirement 3: Protect stored cardholder data

3.5.2There should be very few who have access to cryptographic keys (reducing the potential for rending cardholder data visible by unauthorized parties), usually only those who have key custodian responsibilities.0

Attributes

Item Id: 3.5.2
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse

3.6Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov. The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution. A good key- management process, whether it is manual or automated as part of the encryption product, is based on industry standards and addresses all key elements at 3.6.1 through 3.6.8. Providing guidance to customers on how to securely transmit, store and update cryptographic keys can help prevent keys from being mismanaged or disclosed to unauthorized entities. This requirement applies to keys used to encrypt stored cardholder data, and any respective key- encrypting keys. Note: Testing Procedure 3.6.a is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 3.6
Section: Requirement 3: Protect stored cardholder data
Sub Section: Requirement 3: Protect stored cardholder data

3.6.4A cryptoperiod is the time span during which a particular cryptographic key can be used for its defined purpose. Considerations for defining the cryptoperiod include, but are not limited to, the strength of the underlying algorithm, size or length of the key, risk of key compromise, and the sensitivity of the data being encrypted. Periodic changing of encryption keys when the keys have reached the end of their cryptoperiod is imperative to minimize the risk of someone's obtaining the encryption keys, and using them to decrypt data.0

Attributes

Item Id: 3.6.4
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data

3.6.4.aA cryptoperiod is the time span during which a particular cryptographic key can be used for its defined purpose. Considerations for defining the cryptoperiod include, but are not limited to, the strength of the underlying algorithm, size or length of the key, risk of key compromise, and the sensitivity of the data being encrypted. Periodic changing of encryption keys when the keys have reached the end of their cryptoperiod is imperative to minimize the risk of someone’s obtaining the encryption keys, and using them to decrypt data.0

Attributes

Item Id: 3.6.4.a
Section: Requirement 3: Protect stored cardholder data
Sub Section: 3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines

Requirement 4: Encrypt transmission of cardholder data across open, public networks629

4.1Following should be used to safeguard sensitive cardholder data during transmission over open, public networks: only trusted keys and certificates are accepted, the protocol in use only supports secure versions or configurations and 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) and satellite communications. Sensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted. Note that some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates and supporting only strong encryption (not supporting weaker, insecure protocols or methods). Verifying that certificates are trusted (for example, have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection. Generally, the web page URL should begin with `HTTPS` and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal— sometimes referred to as a “security seal,” `secure site seal,` or “secure trust seal”)—which may provide the ability to click on the seal to reveal information about the website. Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.) Note: SSL/early TLS is not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2.9

Attributes

Item Id: 4.1
Section: Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sub Section: Requirement 4: Encrypt transmission of cardholder data across open, public networks

4.1.aExamine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for all locations. Sensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted. Note that some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates and supporting only strong encryption (not supporting weaker, insecure protocols or methods). Verifying that certificates are trusted (for example, have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection. Generally, the web page URL should begin with `HTTPS` and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal— sometimes referred to as a “security seal,” `secure site seal,` or “secure trust seal”)—which may provide the ability to click on the seal to reveal information about the website. Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.) Note: SSL/early TLS is not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2.8

Attributes

Item Id: 4.1.a
Section: Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sub Section: 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks

4.1.dSensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted. Note that some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates and supporting only strong encryption (not supporting weaker, insecure protocols or methods). Verifying that certificates are trusted (for example, have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection. Generally, the web page URL should begin with `HTTPS` and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal— sometimes referred to as a “security seal,” `secure site seal,` or “secure trust seal”)—which may provide the ability to click on the seal to reveal information about the website. Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.) Note: SSL/early TLS is not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2.1

Attributes

Item Id: 4.1.d
Section: Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sub Section: 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks

4.1.eSensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted. Note that some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates and supporting only strong encryption (not supporting weaker, insecure protocols or methods). Verifying that certificates are trusted (for example, have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection. Generally, the web page URL should begin with `HTTPS` and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal— sometimes referred to as a “security seal,” `secure site seal,` or “secure trust seal”)—which may provide the ability to click on the seal to reveal information about the website. Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.) Note: SSL/early TLS is not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2.2

Attributes

Item Id: 4.1.e
Section: Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sub Section: 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks

4.1.fSensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted. Note that some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates and supporting only strong encryption (not supporting weaker, insecure protocols or methods). Verifying that certificates are trusted (for example, have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection. Generally, the web page URL should begin with `HTTPS` and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal— sometimes referred to as a “security seal,” `secure site seal,` or “secure trust seal”)—which may provide the ability to click on the seal to reveal information about the website. Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.) Note: SSL/early TLS is not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2.2

Attributes

Item Id: 4.1.f
Section: Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sub Section: 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks

4.1.gFor 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. Sensitive information must be encrypted during transmission over public networks, because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted. Note that some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates and supporting only strong encryption (not supporting weaker, insecure protocols or methods). Verifying that certificates are trusted (for example, have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection. Generally, the web page URL should begin with `HTTPS` and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal— sometimes referred to as a “security seal,” `secure site seal,` or “secure trust seal”)—which may provide the ability to click on the seal to reveal information about the website. Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.) Note: SSL/early TLS is not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2.7

Attributes

Item Id: 4.1.g
Section: Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sub Section: 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs33

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

Attributes

Item Id: 5.1
Section: Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Sub Section: Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

5.2Anti-virus mechanisms should be maintained as follows: are kept current, perform periodic scans and generate audit logs which are retained per PCI DSS Requirement 10.7. Even the best anti-virus solutions are limited in effectiveness if they are not maintained and kept current with the latest security updates, signature files, or malware protections. Audit logs provide the ability to monitor virus and malware activity and anti-malware reactions. Thus, it is imperative that anti-malware solutions be configured to generate audit logs and that these logs be managed in accordance with Requirement 10.1

Attributes

Item Id: 5.2
Section: Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Sub Section: Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

5.2.cEven the best anti-virus solutions are limited in effectiveness if they are not maintained and kept current with the latest security updates, signature files, or malware protections. Audit logs provide the ability to monitor virus and malware activity and anti-malware reactions. Thus, it is imperative that anti-malware solutions be configured to generate audit logs and that these logs be managed in accordance with Requirement 10.1

Attributes

Item Id: 5.2.c
Section: Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Sub Section: 5.2 Ensure that all anti-virus mechanisms are maintained

Requirement 6: Develop and maintain secure systems and applications1419

6.1The intent of this requirement is that organizations keep up to date with new vulnerabilities that may impact their environment. Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing list, or RSS feeds. Once an organization identifies a vulnerability that could affect their environment, the risk that the vulnerability poses must be evaluated and ranked. The organization must therefore have a method in place to evaluate vulnerabilities on an ongoing basis and assign risk rankings to those vulnerabilities. This is not achieved by an ASV scan or internal vulnerability scan, rather this requires a process to actively monitor industry sources for vulnerability information. Classifying the risks (for example, as “high,” “medium,” or “low”) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited.0

Attributes

Item Id: 6.1
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: Requirement 6: Develop and maintain secure systems and applications

6.1.bThe intent of this requirement is that organizations keep up to date with new vulnerabilities that may impact their environment. Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing list, or RSS feeds. Once an organization identifies a vulnerability that could affect their environment, the risk that the vulnerability poses must be evaluated and ranked. The organization must therefore have a method in place to evaluate vulnerabilities on an ongoing basis and assign risk rankings to those vulnerabilities. This is not achieved by an ASV scan or internal vulnerability scan, rather this requires a process to actively monitor industry sources for vulnerability information. Classifying the risks (for example, as “high,” “medium,” or “low”) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited.0

Attributes

Item Id: 6.1.b
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities

6.2Install 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. There is a constant stream of attacks using widely published exploits, often called `zero day` (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. If the most recent patches are not implemented on critical systems as soon as possible, a malicious individual can use these exploits to attack or disable a system, or gain access to sensitive data. Prioritizing patches for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released. Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days, and other lower-risk patches are installed within 2-3 months. This requirement applies to applicable patches for all installed software, including payment applications (both those that are PA-DSS validated and those that are not).3

Attributes

Item Id: 6.2
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: Requirement 6: Develop and maintain secure systems and applications

6.2.bThere is a constant stream of attacks using widely published exploits, often called `zero day` (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. If the most recent patches are not implemented on critical systems as soon as possible, a malicious individual can use these exploits to attack or disable a system, or gain access to sensitive data. Prioritizing patches for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released. Consider prioritizing patch installations such that security patches for critical or at-risk systems are installed within 30 days, and other lower-risk patches are installed within 2-3 months. This requirement applies to applicable patches for all installed software, including payment applications (both those that are PA-DSS validated and those that are not).3

Attributes

Item Id: 6.2.b
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor- supplied security patches

6.3Develop internal and external software application 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. Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. Understanding how sensitive data is handled by the application—including when stored, transmitted, and when in memory—can help identify where data needs to be protected.2

Attributes

Item Id: 6.3
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: Requirement 6: Develop and maintain secure systems and applications

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

Attributes

Item Id: 6.3.1
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely

6.3.2Custom code prior to release to production should include 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 and security vulnerabilities in custom code are commonly exploited by malicious individuals to gain access to a network and compromise cardholder data. An individual knowledgeable and experienced in code-review techniques should be involved in the review process. Code reviews should be performed by someone other than the developer of the code to allow for an independent, objective review. Automated tools or processes may also be used in lieu of manual reviews, but keep in mind that it may be difficult or even impossible for an automated tool to identify some coding issues. Correcting coding errors before the code is deployed into a production environment or released to customers prevents the code exposing the environments to potential exploit. Faulty code is also far more difficult and expensive to address after it has been deployed or released into production environments. Including a formal review and signoff by management prior to release helps to ensure that code is approved and has been developed in accordance with policies and procedures.0

Attributes

Item Id: 6.3.2
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely

6.3.2.bSecurity vulnerabilities in custom code are commonly exploited by malicious individuals to gain access to a network and compromise cardholder data. An individual knowledgeable and experienced in code-review techniques should be involved in the review process. Code reviews should be performed by someone other than the developer of the code to allow for an independent, objective review. Automated tools or processes may also be used in lieu of manual reviews, but keep in mind that it may be difficult or even impossible for an automated tool to identify some coding issues. Correcting coding errors before the code is deployed into a production environment or released to customers prevents the code exposing the environments to potential exploit. Faulty code is also far more difficult and expensive to address after it has been deployed or released into production environments. Including a formal review and signoff by management prior to release helps to ensure that code is approved and has been developed in accordance with policies and procedures.0

Attributes

Item Id: 6.3.2.b
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes)

6.3.aWithout the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. Understanding how sensitive data is handled by the application—including when stored, transmitted, and when in memory—can help identify where data needs to be protected.2

Attributes

Item Id: 6.3.a
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely

6.3.bWithout the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. Understanding how sensitive data is handled by the application—including when stored, transmitted, and when in memory—can help identify where data needs to be protected.2

Attributes

Item Id: 6.3.b
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely

6.3.cWithout the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. Understanding how sensitive data is handled by the application—including when stored, transmitted, and when in memory—can help identify where data needs to be protected.2

Attributes

Item Id: 6.3.c
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely

6.5Common coding vulnerabilities in software-development processes as follows: train developers at least annually in up- to-date secure coding techniques, including how to avoid common coding vulnerabilities, 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. The application layer is high-risk and may be targeted by both internal and external threats. Requirements 6.5.1 through 6.5.10 are the minimum controls that should be in place, and organizations should incorporate the relevant secure coding practices as applicable to the particular technology in their environment. Application developers should be properly trained to identify and resolve issues related to these (and other) common coding vulnerabilities. Having staff knowledgeable of secure coding guidelines should minimize the number of security vulnerabilities introduced through poor coding practices. Training for developers may be provided in-house or by third parties and should be applicable for technology used. As industry-accepted secure coding practices change, organizational coding practices and developer training should likewise be updated to address new threats—for example, memory scraping attacks. The vulnerabilities identified in 6.5.1 through 6.5.10 provide a minimum baseline. It is up to the organization to remain up to date with vulnerability trends and incorporate appropriate measures into their secure coding practices.0

Attributes

Item Id: 6.5
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: Requirement 6: Develop and maintain secure systems and applications

6.5.8Directory traversal—is addressed by coding technique should include: proper authentication of users, sanitizing input, not exposing internal object references to users and user interfaces that do not permit access to unauthorized functions. A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization. Consistently enforce access control in presentation layer and business logic for all URLs. Frequently, the only way an application protects sensitive functionality is by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. An attacker may be able to enumerate and navigate the directory structure of a website (directory traversal) thus gaining access to unauthorized information as well as gaining further insight into the workings of the site for later exploitation. If user interfaces permit access to unauthorized functions, this access could result in unauthorized individuals gaining access to privileged credentials or cardholder data. Only authorized users should be permitted to access direct object references to sensitive resources. Limiting access to data resources will help prevent cardholder data from being presented to unauthorized resources.0

Attributes

Item Id: 6.5.8
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: 6.5 Address common coding vulnerabilities in software-development processes like train developers at least annually in up-to-date secure coding techniques etc

6.6Verify 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 that is immediately investigated.Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. The requirement for reviewing applications or installing web-application firewalls is intended to reduce the number of compromises on public-facing web applications due to poor coding or application management practices. Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities, web-application firewalls filter and block non- essential traffic at the application layer. Used in conjunction with a network-based firewall, a properly configured web-application firewall prevents application-layer attacks if applications are improperly coded or configured. This can be achieved through a combination of technology and process. Process-based solutions must have mechanisms that facilitate timely responses to alerts in order to meet the intent of this requirement, which is to prevent attacks. Note: “An organization that specializes in application security” can be either a third-party company or an internal organization, as long as the reviewers specialize in application security and can demonstrate independence from the development team. 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.3

Attributes

Item Id: 6.6
Section: Requirement 6: Develop and maintain secure systems and applications
Sub Section: Requirement 6: Develop and maintain secure systems and applications

Requirement 7: Restrict access to cardholder data by business need to know535

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

Attributes

Item Id: 7.1
Section: Requirement 7: Restrict access to cardholder data by business need to know
Sub Section: Requirement 7: Restrict access to cardholder data by business need to know

7.1.2When assigning privileged IDs, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator.1

Attributes

Item Id: 7.1.2
Section: Requirement 7: Restrict access to cardholder data by business need to know
Sub Section: 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access

7.1.2.aWhen assigning privileged IDs, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator.1

Attributes

Item Id: 7.1.2.a
Section: Requirement 7: Restrict access to cardholder data by business need to know
Sub Section: 7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities

7.2Without a mechanism to restrict access based on user's need to know, a user may unknowingly be granted access to cardholder data. Access control systems automate the process of restricting access and assigning privileges. Additionally, a default “deny-all” setting ensures no one is granted access until and unless a rule is established specifically granting such access. Entities may have one or more access controls systems to manage user access. Note: Some access control systems are set by default to “allow-all,” thereby permitting access unless/until a rule is written to specifically deny it.17

Attributes

Item Id: 7.2
Section: Requirement 7: Restrict access to cardholder data by business need to know
Sub Section: Requirement 7: Restrict access to cardholder data by business need to know

7.2.1Without a mechanism to restrict access based on user's need to know, a user may unknowingly be granted access to cardholder data. Access control systems automate the process of restricting access and assigning privileges. Additionally, a default “deny-all” setting ensures no one is granted access until and unless a rule is established specifically granting such access. Entities may have one or more access controls systems to manage user access. Note: Some access control systems are set by default to “allow-all,” thereby permitting access unless/until a rule is written to specifically deny it.15

Attributes

Item Id: 7.2.1
Section: Requirement 7: Restrict access to cardholder data by business need to know
Sub Section: 7.2 Examine system settings and vendor documentation to verify that an access control system(s)

Requirement 8: Identify and authenticate access to system components3397

8.1By ensuring each user is uniquely identified— instead of using one ID for several employees—an organization can maintain individual responsibility for actions and an effective audit trail per employee. This will help speed issue resolution and containment when misuse or malicious intent occurs.4

Attributes

Item Id: 8.1
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: Requirement 8: Identify and authenticate access to system components

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

Attributes

Item Id: 8.1.2
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators

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

Attributes

Item Id: 8.1.4
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators

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

Attributes

Item Id: 8.1.5
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators

8.1.5.aAllowing vendors to have 24/7 access into your network in case they need to support your systems increases the chances of unauthorized access, either from a user in the vendor's environment or from a malicious individual who finds and uses this always-available external entry point into your network. Enabling access only for the time periods needed, and disabling it as soon as it is no longer needed, helps prevent misuse of these connections. Monitoring of vendor access provides assurance that vendors are accessing only the systems necessary and only during approved time frames.0

Attributes

Item Id: 8.1.5.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access by enabling only during the time period needed and disabled when not in use

8.2Verify users are authenticated using unique ID, 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). These authentication methods, when used in addition to unique IDs, help protect users' IDs from being compromised, since the one attempting the compromise needs to know both the unique ID and the password (or other authentication used). Note that a digital certificate is a valid option for “something you have” as long as it is unique for a particular user. Since one of the first steps a malicious individual will take to compromise a system is to exploit weak or nonexistent passwords, it is important to implement good processes for authentication management.23

Attributes

Item Id: 8.2
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: Requirement 8: Identify and authenticate access to system components

8.2.1Many network devices and applications transmit unencrypted, readable passwords across the network and/or store passwords without encryption. A malicious individual can easily intercept unencrypted passwords during transmission using a “sniffer,” or directly access unencrypted passwords in files where they are stored, and use this data to gain unauthorized access. Note: Testing Procedures 8.2.1.d and 8.2.1.e are additional procedures that only apply if the entity being assessed is a service provider.22

Attributes

Item Id: 8.2.1
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 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 methods like examine documentation describing the authentication method(s) used etc

8.2.1.aMany network devices and applications transmit unencrypted, readable passwords across the network and/or store passwords without encryption. A malicious individual can easily intercept unencrypted passwords during transmission using a “sniffer,” or directly access unencrypted passwords in files where they are stored, and use this data to gain unauthorized access. Note: Testing Procedures 8.2.1.d and 8.2.1.e are additional procedures that only apply if the entity being assessed is a service provider.20

Attributes

Item Id: 8.2.1.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components

8.2.1.bMany network devices and applications transmit unencrypted, readable passwords across the network and/or store passwords without encryption. A malicious individual can easily intercept unencrypted passwords during transmission using a “sniffer,” or directly access unencrypted passwords in files where they are stored, and use this data to gain unauthorized access. Note: Testing Procedures 8.2.1.d and 8.2.1.e are additional procedures that only apply if the entity being assessed is a service provider.0

Attributes

Item Id: 8.2.1.b
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components

8.2.1.cMany network devices and applications transmit unencrypted, readable passwords across the network and/or store passwords without encryption. A malicious individual can easily intercept unencrypted passwords during transmission using a “sniffer,” or directly access unencrypted passwords in files where they are stored, and use this data to gain unauthorized access. Note: Testing Procedures 8.2.1.d and 8.2.1.e are additional procedures that only apply if the entity being assessed is a service provider.0

Attributes

Item Id: 8.2.1.c
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components

8.2.3The passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above. Strong passwords/passphrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non- existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID. This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.) Note: Testing Procedure 8.2.3.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.3
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 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 methods like examine documentation describing the authentication method(s) used etc

8.2.3.aStrong passwords/passphrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non- existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID. This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.) Note: Testing Procedure 8.2.3.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.3.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.3 Passwords/passphrases require a minimum length of at least seven characters, contain both numeric and alphabetic characters

8.2.3.bStrong passwords/passphrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non- existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID. This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.) Note: Testing Procedure 8.2.3.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.3.b
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.3 Passwords/passphrases require a minimum length of at least seven characters, contain both numeric and alphabetic characters

8.2.4Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase. Note: Testing Procedure 8.2.4.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.4
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 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 methods like examine documentation describing the authentication method(s) used etc

8.2.4.aPasswords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase. Note: Testing Procedure 8.2.4.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.4.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.4 Change user passwords/passphrases at least once every 90 days

8.2.4.bPasswords/passphrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase. Note: Testing Procedure 8.2.4.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.4.b
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.4 Change user passwords/passphrases at least once every 90 days

8.2.5If password history isn't maintained, the effectiveness of changing passwords is reduced, as previous passwords can be reused over and over. Requiring that passwords cannot be reused for a period of time reduces the likelihood that passwords that have been guessed or brute-forced will be used in the future. Note: Testing Procedure 8.2.5.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.5
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 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 methods like examine documentation describing the authentication method(s) used etc

8.2.5.aIf password history isn't maintained, the effectiveness of changing passwords is reduced, as previous passwords can be reused over and over. Requiring that passwords cannot be reused for a period of time reduces the likelihood that passwords that have been guessed or brute-forced will be used in the future. Note: Testing Procedure 8.2.5.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.5.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used

8.2.5.bIf password history isn't maintained, the effectiveness of changing passwords is reduced, as previous passwords can be reused over and over. Requiring that passwords cannot be reused for a period of time reduces the likelihood that passwords that have been guessed or brute-forced will be used in the future. Note: Testing Procedure 8.2.5.b is an additional procedure that only applies if the entity being assessed is a service provider.1

Attributes

Item Id: 8.2.5.b
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used

8.3Note: Multi-factor authentication requires that a minimum of 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 multi-factor authentication. Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication (as described in Requirement 8.2), before access is granted. Multi-factor authentication provides additional assurance that the individual attempting to gain access is who they claim to be. With multi-factor authentication, an attacker would need to compromise at least two different authentication mechanisms, increasing the difficulty of compromise and thus reducing the risk. Multi-factor authentication is not required at both the system-level and application-level for a particular system component. Multi-factor authentication can be performed either upon authentication to the particular network or to the system component. Examples of multi-factor technologies include but are not limited to remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate multi- factor authentication.1

Attributes

Item Id: 8.3
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: Requirement 8: Identify and authenticate access to system components

8.3.1This requirement is intended to apply to all personnel with administrative access to the CDE. This requirement applies only to personnel with administrative access and only for non-console access to the CDE; it does not apply to application or system accounts performing automated functions. If the entity does not use segmentation to separate the CDE from the rest of their network, an administrator could use multi-factor authentication either when logging onto the CDE network or when logging onto a system. If the CDE is segmented from the rest of the entity’s network, an administrator would need to use multi- factor authentication when connecting to a CDE system from a non-CDE network. Multi-factor authentication can be implemented at network level or at system/application level; it does not have to be both. If the administrator uses MFA when logging into the CDE network, they do not also need to use MFA to log into a particular system or application within the CDE.1

Attributes

Item Id: 8.3.1
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication

8.3.1.aThis requirement is intended to apply to all personnel with administrative access to the CDE. This requirement applies only to personnel with administrative access and only for non-console access to the CDE; it does not apply to application or system accounts performing automated functions. If the entity does not use segmentation to separate the CDE from the rest of their network, an administrator could use multi-factor authentication either when logging onto the CDE network or when logging onto a system. If the CDE is segmented from the rest of the entity's network, an administrator would need to use multi- factor authentication when connecting to a CDE system from a non-CDE network. Multi-factor authentication can be implemented at network level or at system/application level; it does not have to be both. If the administrator uses MFA when logging into the CDE network, they do not also need to use MFA to log into a particular system or application within the CDE.1

Attributes

Item Id: 8.3.1.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access

8.3.2This requirement is intended to apply to all personnel—including general users, administrators, and vendors (for support or maintenance) with remote access to the network—where that remote access could lead to access to the CDE. If remote access is to an entity's network that has appropriate segmentation, such that remote users cannot access or impact the cardholder data environment, multi-factor authentication for remote access to that network would not be required. However, multi- factor authentication is required for any remote access to networks with access to the cardholder data environment, and is recommended for all remote access to the entity's networks.1

Attributes

Item Id: 8.3.2
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication

8.3.2.aThis requirement is intended to apply to all personnel—including general users, administrators, and vendors (for support or maintenance) with remote access to the network—where that remote access could lead to access to the CDE. If remote access is to an entity's network that has appropriate segmentation, such that remote users cannot access or impact the cardholder data environment, multi-factor authentication for remote access to that network would not be required. However, multi- factor authentication is required for any remote access to networks with access to the cardholder data environment, and is recommended for all remote access to the entity's networks.1

Attributes

Item Id: 8.3.2.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity's network

8.5Generic 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. If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to trace system access and activities to an individual. This in turn prevents an entity from assigning accountability for, or having effective logging of, an individual's actions, since a given action could have been performed by anyone in the group that has knowledge of the authentication credentials.0

Attributes

Item Id: 8.5
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: Requirement 8: Identify and authenticate access to system components

8.5.aGeneric 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. If multiple users share the same authentication credentials (for example, user account and password), it becomes impossible to trace system access and activities to an individual. This in turn prevents an entity from assigning accountability for, or having effective logging of, an individual's actions, since a given action could have been performed by anyone in the group that has knowledge of the authentication credentials.0

Attributes

Item Id: 8.5.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods

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

Attributes

Item Id: 8.6
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: Requirement 8: Identify and authenticate access to system components

8.6.cIf user authentication mechanisms such as tokens, smart cards, and certificates can be used by multiple accounts, it may be impossible to identify the individual using the authentication mechanism. Having physical and/or logical controls (for example, a PIN, biometric data, or a password) to uniquely identify the user of the account will prevent unauthorized users from gaining access through use of a shared authentication mechanism.1

Attributes

Item Id: 8.6.c
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned authentication mechanisms must be assigned to an individual account and not shared among multiple accounts, physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access

8.7Access to any database containing cardholder data 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). Without user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except for DBAs, who may need direct access to the database for their administrative duties).1

Attributes

Item Id: 8.7
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: Requirement 8: Identify and authenticate access to system components

8.7.aWithout user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except for DBAs, who may need direct access to the database for their administrative duties).1

Attributes

Item Id: 8.7.a
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted

8.7.bWithout user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except for DBAs, who may need direct access to the database for their administrative duties).1

Attributes

Item Id: 8.7.b
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted

8.7.cWithout user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except for DBAs, who may need direct access to the database for their administrative duties).1

Attributes

Item Id: 8.7.c
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted

8.7.dWithout user authentication for access to databases and applications, the potential for unauthorized or malicious access increases, and such access cannot be logged since the user has not been authenticated and is therefore not known to the system. Also, database access should be granted through programmatic methods only (for example, through stored procedures), rather than via direct access to the database by end users (except for DBAs, who may need direct access to the database for their administrative duties).1

Attributes

Item Id: 8.7.d
Section: Requirement 8: Identify and authenticate access to system components
Sub Section: 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted

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

10.1It is critical to have a process or system that links user access to system components accessed. This system generates audit logs and provides the ability to trace back suspicious activity to a specific user. This control verifies, 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.11

Attributes

Item Id: 10.1
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: Requirement 10: Track and monitor all access to network resources and cardholder data

10.2It is critical to have a process or system that links user access to system components accessed. This system generates audit logs and provides the ability to trace back suspicious activity to a specific user. This control verifies, 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.8

Attributes

Item Id: 10.2
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: Requirement 10: Track and monitor all access to network resources and cardholder data

10.2.1Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account in order to access cardholder data. A record of all individual accesses to cardholder data can identify which accounts may have been compromised or misused. This control verifies all individual access to cardholder data is loggedVerify all individual access to cardholder data is logged.5

Attributes

Item Id: 10.2.1
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings

10.2.2Accounts with increased privileges, such as the “administrator” or “root” account, have the potential to greatly impact the security or operational functionality of a system. Without a log of the activities performed, an organization is unable to trace any issues resulting from an administrative mistake or misuse of privilege back to the specific action and individual. This control verifies all actions taken by any individual with root or administrative privileges are logged.5

Attributes

Item Id: 10.2.2
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings

10.2.3Malicious users often attempt to alter audit logs to hide their actions, and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having access to logs identifying changes, additions, and deletions can help retrace steps made by unauthorized personnel. This control verifies access to all audit trails is logged.5

Attributes

Item Id: 10.2.3
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings

10.2.4Malicious users often attempt to alter audit logs to hide their actions, and a record of access allows an organization to trace any inconsistencies or potential tampering of the logs to an individual account. Having access to logs identifying changes, additions, and deletions can help retrace steps made by unauthorized personnel. This control verifies access to all audit trails is logged.5

Attributes

Item Id: 10.2.4
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings

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

Attributes

Item Id: 10.2.5
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings

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

Attributes

Item Id: 10.2.5.a
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.2.5 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

10.2.6Turning the audit logs off (or pausing them) prior to performing illicit activities is a common practice for malicious users wishing to avoid detection. Initialization of audit logs could indicate that the log function was disabled by a user to hide their actions. This control verifies the following are logged: initialization of audit logs, stopping or pausing of audit logs.5

Attributes

Item Id: 10.2.6
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings

10.2.7Malicious software, such as malware, often creates or replaces system level objects on the target system in order to control a particular function or operation on that system. By logging when system-level objects, such as database tables or stored procedures, are created or deleted, it will be easier to determine whether such modifications were authorized. This control verifies creation and deletion of system level objects are logged.5

Attributes

Item Id: 10.2.7
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings

10.3By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. Through interviews and observation of audit logs, for each auditable event (from 10.2), perform the following:5

Attributes

Item Id: 10.3
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: Requirement 10: Track and monitor all access to network resources and cardholder data

10.3.1By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. This control verifies user identification is included in log entries.5

Attributes

Item Id: 10.3.1
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.3 Record at least the following audit trail entries for all system components for each event

10.3.2By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. This control verifies event is included in log entries.5

Attributes

Item Id: 10.3.2
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.3 Record at least the following audit trail entries for all system components for each event

10.3.3By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. This verifies date and time stamp is included in log entries.5

Attributes

Item Id: 10.3.3
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.3 Record at least the following audit trail entries for all system components for each event

10.3.4By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. This control verifies success or failure indication is included in log entries.5

Attributes

Item Id: 10.3.4
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.3 Record at least the following audit trail entries for all system components for each event

10.3.5By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. This control verifies origination of event is included in log entries.5

Attributes

Item Id: 10.3.5
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.3 Record at least the following audit trail entries for all system components for each event

10.3.6By recording these details for the auditable events at 10.2, a potential compromise can be quickly identified, and with sufficient detail to know who, what, where, when, and how. This control verifies identity or name of affected data, system component, or resources is included in log entries.5

Attributes

Item Id: 10.3.6
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.3 Record at least the following audit trail entries for all system components for each event

10.5Often a malicious individual who has entered the network will attempt to edit the audit logs in order to hide their activity. Without adequate protection of audit logs, their completeness, accuracy, and integrity cannot be guaranteed, and the audit logs can be rendered useless as an investigation tool after a compromise. This control checks secure audit trails so they cannot be altered.9

Attributes

Item Id: 10.5
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: Requirement 10: Track and monitor all access to network resources and cardholder data

10.5.2Adequate protection of the audit logs includes strong access control (limit access to logs based on “need to know” only), and use of physical or network segregation to make the logs harder to find and modify. Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating the logs becomes compromised. Protect audit trail files from unauthorized modifications.3

Attributes

Item Id: 10.5.2
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.5 Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered

10.5.3Adequate protection of the audit logs includes strong access control (limit access to logs based on “need to know” only), and use of physical or network segregation to make the logs harder to find and modify. Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected even if the system generating the logs becomes compromised. Promptly back up audit trail files to a centralized log server or media that is difficult to alter.3

Attributes

Item Id: 10.5.3
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.5 Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered

10.5.4By writing logs from external-facing technologies such as wireless, firewalls, DNS, and mail servers, the risk of those logs being lost or altered is lowered, as they are more secure within the internal network. Logs may be written directly, or offloaded or copied from external systems, to the secure internal system or media.5

Attributes

Item Id: 10.5.4
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.5 Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered

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

Attributes

Item Id: 10.5.5
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.5 Interview system administrators and examine system configurations and permissions to verify that audit trails are secured so that they cannot be altered

10.7Retaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. Storing logs in off-line locations could prevent them from being readily available, resulting in longer time frames to restore log data, perform analysis, and identify impacted systems or data.2

Attributes

Item Id: 10.7
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: Requirement 10: Track and monitor all access to network resources and cardholder data

10.7.aRetaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. Storing logs in off-line locations could prevent them from being readily available, resulting in longer time frames to restore log data, perform analysis, and identify impacted systems or data.1

Attributes

Item Id: 10.7.a
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.7 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)

10.7.bRetaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. Storing logs in off-line locations could prevent them from being readily available, resulting in longer time frames to restore log data, perform analysis, and identify impacted systems or data.1

Attributes

Item Id: 10.7.b
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.7 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)

10.7.cRetaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. Storing logs in off-line locations could prevent them from being readily available, resulting in longer time frames to restore log data, perform analysis, and identify impacted systems or data.1

Attributes

Item Id: 10.7.c
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.7 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)

10.8Note: This requirement applies only when the entity being assessed is a service provider. Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment. The specific types of failures may vary depending on the function of the device and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner; for example, a firewall erasing all its rules or going offline.2

Attributes

Item Id: 10.8
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: Requirement 10: Track and monitor all access to network resources and cardholder data

10.8.1Processes for responding to failures in security controls must include restoring security functions, identifying and documenting the duration (date and time start to end) of the security failure, identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause, identifying and addressing any security issues that arose during the failure, performing a risk assessment to determine whether further actions are required as a result of the security failure, implementing controls to prevent cause of failure from reoccurring and resuming monitoring of security controls. Note: This requirement applies only when the entity being assessed is a service provider. If critical security control failures alerts are not quickly and effectively responded to, attackers may use this time to insert malicious software, gain control of a system, or steal data from the entity's environment. Documented evidence (e.g., records within a problem management system) should support that processes and procedures are in place to respond to security failures. In addition, personnel should be aware of their responsibilities in the event of a failure. Actions and responses to the failure should be captured in the documented evidence.0

Attributes

Item Id: 10.8.1
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.8 Additional requirement for service providers only to implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of firewalls, IDS/IPS, FIM, anti-virus, physical access controls, logical access controls, audit logging mechanisms and segmentation controls

10.8.1.aThis include restoring security functions, identifying and documenting the duration (date and time start to end) of the security failure, identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause, identifying and addressing any security issues that arose during the failure, performing a risk assessment to determine whether further actions are required as a result of the security failure, implementing controls to prevent cause of failure from reoccurring and resuming monitoring of security controls. Note: This requirement applies only when the entity being assessed is a service provider. If critical security control failures alerts are not quickly and effectively responded to, attackers may use this time to insert malicious software, gain control of a system, or steal data from the entity's environment. Documented evidence (e.g., records within a problem management system) should support that processes and procedures are in place to respond to security failures. In addition, personnel should be aware of their responsibilities in the event of a failure. Actions and responses to the failure should be captured in the documented evidence.0

Attributes

Item Id: 10.8.1.a
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner

10.8.bThe failure of a critical security control results in the generation of an alert.10.8.b Examine detection and alerting processes and interview personnel to verify that processes are implemented for all critical security controls, and that failure of a critical security control results in the generation of an alert. Note: This requirement applies only when the entity being assessed is a service provider. Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment. The specific types of failures may vary depending on the function of the device and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner; for example, a firewall erasing all its rules or going offline.2

Attributes

Item Id: 10.8.b
Section: Requirement 10: Track and monitor all access to network resources and cardholder data
Sub Section: 10.8 Additional requirement for service providers only to implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of firewalls, IDS/IPS, FIM, anti-virus, physical access controls, logical access controls, audit logging mechanisms and segmentation controls

Requirement 11: Regularly test security systems and processes77

11.4Monitor 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. Intrusion detection and/or intrusion prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools, Trojans, and other malware), and send alerts and/or stop the attempt as it happens. Without a proactive approach to unauthorized activity detection, attacks on (or misuse of) computer resources could go unnoticed in real time. Security alerts generated by these techniques should be monitored so that the attempted intrusions can be stopped.1

Attributes

Item Id: 11.4
Section: Requirement 11: Regularly test security systems and processes
Sub Section: Requirement 11: Regularly test security systems and processes

11.4.aIntrusion detection and/or intrusion prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools, Trojans, and other malware), and send alerts and/or stop the attempt as it happens. Without a proactive approach to unauthorized activity detection, attacks on (or misuse of) computer resources could go unnoticed in real time. Security alerts generated by these techniques should be monitored so that the attempted intrusions can be stopped.1

Attributes

Item Id: 11.4.a
Section: Requirement 11: Regularly test security systems and processes
Sub Section: 11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network

11.4.bIntrusion detection and/or intrusion prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools, Trojans, and other malware), and send alerts and/or stop the attempt as it happens. Without a proactive approach to unauthorized activity detection, attacks on (or misuse of) computer resources could go unnoticed in real time. Security alerts generated by these techniques should be monitored so that the attempted intrusions can be stopped.1

Attributes

Item Id: 11.4.b
Section: Requirement 11: Regularly test security systems and processes
Sub Section: 11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network

11.4.cIntrusion detection and/or intrusion prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools, Trojans, and other malware), and send alerts and/or stop the attempt as it happens. Without a proactive approach to unauthorized activity detection, attacks on (or misuse of) computer resources could go unnoticed in real time. Security alerts generated by these techniques should be monitored so that the attempted intrusions can be stopped.1

Attributes

Item Id: 11.4.c
Section: Requirement 11: Regularly test security systems and processes
Sub Section: 11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network

11.5Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected. If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.1

Attributes

Item Id: 11.5
Section: Requirement 11: Regularly test security systems and processes
Sub Section: Requirement 11: Regularly test security systems and processes

11.5.aExamples of files that should be monitored are system executables, application executables, configuration and parameter files, centrally stored, historical or archived, log and audit files and additional critical files determined by entity (for example, through risk assessment or other means). Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected. If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.1

Attributes

Item Id: 11.5.a
Section: Requirement 11: Regularly test security systems and processes
Sub Section: 11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly

11.5.b1

Attributes

Item Id: 11.5.b
Section: Requirement 11: Regularly test security systems and processes
Sub Section: 11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly