| wdt_ID | AID | Req. ID | Requirement | Goal | Control | Procedure | Guidance |
|---|---|---|---|---|---|---|---|
| 1 | 1 | R. 1 | 1.1 Establish and implement firewall and router configuration standards that include the following: | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.1 Inspect the firewall and router configuration standards and other documentation specified below and verify that standards are complete and implemented as follows: | Firewalls 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. |
| 2 | 2 | R. 1 | 1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.1.1.a Examine documented procedures to verify there is a formal process for testing and approval of all: . Network connections and . Changes to firewall and router configurations 1.1.1.b For a sample of network connections, interview responsible personnel and examine records to verify that network connections were approved and tested. 1.1.1.c Identify a sample of actual changes made to firewall and router configurations, compare to the change records, and interview responsible personnel to verify the changes were approved and tested. | A documented and implemented process for approving and testing all connections and changes to the firewalls and routers will help prevent security problems caused by misconfiguration of the network, router, or firewall. Without formal approval and testing of changes, records of the changes might not be updated, which could lead to inconsistencies between network documentation and the actual configuration. |
| 3 | 3 | R. 1 | 1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.1.2.a Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections to cardholder data, including any wireless networks. 1.1.2.b Interview responsible personnel to verify that the diagram is kept current. | Network diagrams describe how networks are configured, and identify the location of all network devices. Without current network diagrams, devices could be overlooked and be unknowingly left out of the security controls implemented for PCI DSS and thus be vulnerable to compromise. |
| 4 | 4 | R. 1 | 1.1.3 Current diagram that shows all cardholder data flows across systems and networks | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.1.3 Examine data-flow diagram and interview personnel to verify the diagram: . Shows all cardholder data flows across systems and networks. . Is kept current and updated as needed upon changes to the environment. | Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network. Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices. |
| 5 | 5 | R. 1 | 1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.1.4.a Examine the firewall configuration standards and verify that they include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone. 1.1.4.b Verify that the current network diagram is consistent with the firewall configuration standards. 1.1.4.c Observe network configurations to verify that a firewall is in place at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone, per the documented configuration standards and network diagrams. | Using a firewall on every Internet connection coming into (and out of) the network, and between any DMZ and the internal network, allows the organization to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection. |
| 6 | 6 | R. 1 | 1.1.5 Description of groups, roles, and responsibilities for management of network components | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.1.5.a Verify that firewall and router configuration standards include a description of groups, roles, and responsibilities for management of network components. 1.1.5.b Interview personnel responsible for management of network components to confirm that roles and responsibilities are assigned as documented. | This description of roles and assignment of responsibilities ensures that personnel are aware of who is responsible for the security of all network components, and that those assigned to manage components are aware of their responsibilities. If roles and responsibilities are not formally assigned, devices could be left unmanaged. |
| 7 | 7 | R. 1 | 1.1.6 Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.1.6.a Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols. 1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that security features are documented for each service. 1.1.6.c Examine firewall and router configurations to verify that the documented security features are implemented for each insecure service, protocol, and port. | Compromises often happen due to unused or insecure service and ports, since these often have known vulnerabilities and many organizations don’t patch vulnerabilities for the services, protocols, and ports they don't use (even though the vulnerabilities are still present). By clearly defining and documenting the services, protocols, and ports that are necessary for business, organizations can ensure that all other services, protocols, and ports are disabled or removed. Approvals should be granted by personnel independent of the personnel managing the configuration. If insecure services, protocols, or ports are necessary for business, the risk posed by use of these protocols should be clearly understood and accepted by the organization, the use of the protocol should be justified, and the security features that allow these protocols to be used securely should be documented and implemented. If these insecure services, protocols, or ports are not necessary for business, they should be disabled or removed. For guidance on services, protocols, or ports considered to be insecure, refer to industry standards and guidance (e.g., NIST, ENISA, OWASP, etc.). |
| 8 | 8 | R. 1 | 1.1.7 Requirement to review firewall and router rule sets at least every six months | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.1.7.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months. 1.1.7.b Examine documentation relating to rule set reviews and interview responsible personnel to verify that the rule sets are reviewed at least every six months. | This review gives the organization an opportunity at least every six months to clean up any unneeded, outdated, or incorrect rules, and ensure that all rule sets allow only authorized services and ports that match the documented business justifications. Organizations with a high volume of changes to firewall and router rule sets may wish to consider performing reviews more frequently, to ensure that the rule sets continue to meet the needs of the business. |
| 9 | 9 | R. 1 | 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. Note: An “untrusted network” is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 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: | It 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. |
| 10 | 10 | R. 1 | 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.2.1.a Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment. 1.2.1.b Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment. 1.2.1.c Examine firewall and router configurations to verify that all other inbound and outbound traffic is specifically denied, for example by using an explicit ~deny all~ or an implicit deny after allow statement. | Examination 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. |
| 11 | 11 | R. 1 | 1.2.2 Secure and synchronize router configuration files. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.2.2.a Examine router configuration files to verify they are secured from unauthorized access. 1.2.2.b Examine router configurations to verify they are synchronized—for example, the running (or active) configuration matches the start-up configuration (used when machines are booted). | While 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. |
| 12 | 12 | R. 1 | 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. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.2.3.a Examine firewall and router configurations to verify that there are perimeter firewalls installed between all wireless networks and the cardholder data environment. 1.2.3.b Verify that the firewalls deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment. | The known (or unknown) implementation and exploitation of wireless technology within a network is a common path for malicious individuals to gain access to the network and cardholder data. If a wireless device or network is installed without the entity’s knowledge, a malicious individual could easily and ~invisibly~ enter the network. If firewalls do not restrict access from wireless networks into the CDE, malicious individuals that gain unauthorized access to the wireless network can easily connect to the CDE and compromise account information. Firewalls must be installed between all wireless networks and the CDE, regardless of the purpose of the environment to which the wireless network is connected. This may include, but is not limited to, corporate networks, retail stores, guest networks, warehouse environments, etc. |
| 13 | 13 | R. 1 | 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 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: | While 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. |
| 14 | 14 | R. 1 | 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.3.1 Examine firewall and router configurations to verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports. | The 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. |
| 15 | 15 | R. 1 | 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.3.2 Examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ. | The 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. |
| 16 | 16 | R. 1 | 1.3.3 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network. (For example, block traffic originating from the Internet with an internal source address.) | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.3.3 Examine firewall and router configurations to verify that anti-spoofing measures are implemented, for example internal addresses cannot pass from the Internet into the DMZ. | Normally 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. |
| 17 | 17 | R. 1 | 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.3.4 Examine firewall and router configurations to verify that outbound traffic from the cardholder data environment to the Internet is explicitly authorized. | All 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). |
| 18 | 18 | R. 1 | 1.3.5 Permit only “established” connections into the network. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.3.5 Examine firewall and router configurations to verify that the firewall permits only established connections into the internal network and denies any inbound connections not associated with a previously established session. | A 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. |
| 19 | 19 | R. 1 | 1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.3.6 Examine firewall and router configurations to verify that system components that store cardholder data are on an internal network zone, segregated from the DMZ and other untrusted networks. | If cardholder data is located within the DMZ, it is easier for an external attacker to access this information, since there are fewer layers to penetrate. Securing system components that store cardholder data in an internal network zone that is segregated from the DMZ and other untrusted networks by a firewall can prevent unauthorized network traffic from reaching the system component. Note: This requirement is not intended to apply to temporary storage of cardholder data in volatile memory. |
| 20 | 20 | R. 1 | 1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties. Note: Methods to obscure IP addressing may include, but are not limited to: • Network Address Translation (NAT) • Placing servers containing cardholder data behind proxy servers/firewalls, • Removal or filtering of route advertisements for private networks that employ registered addressing, • Internal use of RFC1918 address space instead of registered addresses. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.3.7.a Examine firewall and router configurations to verify that methods are in place to prevent the disclosure of private IP addresses and routing information from internal networks to the Internet. 1.3.7.b Interview personnel and examine documentation to verify that any disclosure of private IP addresses and routing information to external entities is authorized. | Restricting the disclosure of internal or private IP addresses is essential to prevent a hacker ~learning~ the IP addresses of the internal network, and using that information to access the network. Methods used to meet the intent of this requirement may vary depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks. |
| 21 | 21 | R. 1 | 1.4 Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE. Firewall (or equivalent) configurations include: • Specific configuration settings are defined. • Personal firewall (or equivalent functionality) is actively running. • Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.4.a Examine policies and configuration standards to verify: . Personal firewall software or equivalent functionality is required for all portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE. . Specific configuration settings are defined for personal firewall (or equivalent functionality). . Personal firewall (or equivalent functionality) is configured to actively run. . Personal firewall (or equivalent functionality) is configured to not be alterable by users of the portable computing devices. 1.4.b Inspect a sample of company and/or employee-owned devices to verify that: . Personal firewall (or equivalent functionality) is installed and configured per the organization’s specific configuration settings. . Personal firewall (or equivalent functionality) is actively running. . Personal firewall (or equivalent functionality) is not alterable by users of the portable computing devices. | Portable computing devices that are allowed to connect to the Internet from outside the corporate firewall are more vulnerable to Internet-based threats. Use of firewall functionality (e.g., personal firewall software or hardware) helps to protect devices from Internet-based attacks, which could use the device to gain access the organization’s systems and data once the device is re-connected to the network. The specific firewall configuration settings are determined by the organization. Note: This requirement applies to employee-owned and company-owned portable computing devices. Systems that cannot be managed by corporate policy introduce weaknesses and provide opportunities that malicious individuals may exploit. Allowing untrusted systems to connect to an organization’s CDE could result in access being granted to attackers and other malicious users. |
| 22 | 22 | R. 1 | 1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties. | Build and Maintain a Secure Network | R1: Install and maintain a firewall configuration to protect cardholder data | 1.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing firewalls are: . Documented, . In use, and . Known to all affected parties. | Personnel need to be aware of and following security policies and operational procedures to ensure firewalls and routers are continuously managed to prevent unauthorized access to the network. |
| 23 | 23 | R. 2 | 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, Simple Network Management Protocol (SNMP) community strings, etc.). | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.1.a Choose a sample of system components, and attempt to log on (with system administrator help) to the devices and applications using default vendor-supplied accounts and passwords, to verify that ALL default passwords (including those on operating systems, software that provides security services, application and system accounts, POS terminals, and Simple Network Management Protocol (SNMP) community strings) have been changed. (Use vendor manuals and sources on the Internet to find vendor-supplied accounts/passwords.) 2.1.b For the sample of system components, verify that all unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled. 2.1.c Interview personnel and examine supporting documentation to verify that: . All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, POS terminals, Simple Network Management Protocol (SNMP) community strings, etc.) are changed before a system is installed on the network. . Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, etc.) are removed or disabled before a system is installed on the network. | 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. |
| 24 | 24 | R. 2 | 2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.1.1.a Interview responsible personnel and examine supporting documentation to verify that: . Encryption keys were changed from default at installation . Encryption keys are changed anytime anyone with knowledge of the keys leaves the company or changes positions. 2.1.1.b Interview personnel and examine policies and procedures to verify: . Default SNMP community strings are required to be changed upon installation. . Default passwords/phrases on access points are required to be changed upon installation. 2.1.1.c Examine vendor documentation and login to wireless devices, with system administrator help, to verify: . Default SNMP community strings are not used. . Default passwords/passphrases on access points are not used. 2.1.1.d Examine vendor documentation and observe wireless configuration settings to verify firmware on wireless devices is updated to support strong encryption for: . Authentication over wireless networks . Transmission over wireless networks. 2.1.1.e Examine vendor documentation and observe wireless configuration settings to verify other security- related wireless vendor defaults were changed, if applicable. | If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network. In addition, the key-exchange protocol for older versions of 802.11x encryption (Wired Equivalent Privacy, or WEP) has been broken and can render the encryption useless. Firmware for devices should be updated to support more secure protocols. |
| 25 | 25 | R. 2 | 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to: • Center for Internet Security (CIS) • International Organization for Standardization (ISO) • SysAdmin Audit Network Security (SANS) Institute • National Institute of Standards Technology (NIST). | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.2.a Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry- accepted hardening standards. 2.2.b Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.1. 2.2.c Examine policies and interview personnel to verify that system configuration standards are applied when new systems are configured and verified as being in place before a system is installed on the network. 2.2.d Verify that system configuration standards include the following procedures for all types of system components: . Changing of all vendor-supplied defaults and elimination of unnecessary default accounts . Implementing only one primary function per server to prevent functions that require different security levels from co-existing on the same server . Enabling only necessary services, protocols, daemons, etc., as required for the function of the system . Implementing additional security features for any required services, protocols or daemons that are considered to be insecure . Configuring system security parameters to prevent misuse . Removing all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. | 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. |
| 26 | 26 | R. 2 | 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.) Note: Where virtualization technologies are in use, implement only one primary function per virtual system component. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.2.1.a Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server. 2.2.1.b If virtualization technologies are used, inspect the system configurations to verify that only one primary function is implemented per virtual system component or device. | If server functions that need different security levels are located on the same server, the security level of the functions with higher security needs would be reduced due to the presence of the lower-security functions. Additionally, the server functions with a lower security level may introduce security weaknesses to other functions on the same server. By considering the security needs of different server functions as part of the system configuration standards and related processes, organizations can ensure that functions requiring different security levels don’t co-exist on the same server. |
| 27 | 27 | R. 2 | 2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.2.2.a Select a sample of system components and inspect enabled system services, daemons, and protocols to verify that only necessary services or protocols are enabled. 2.2.2.b Identify any enabled insecure services, daemons, or protocols and interview personnel to verify they are justified per documented configuration standards. | As 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. |
| 28 | 28 | R. 2 | 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.2.3 Inspect configuration settings to verify that security features are documented and implemented for all insecure services, daemons, or protocols. | Enabling security features before new servers are deployed will prevent servers being installed into the environment with insecure configurations. Ensuring that all insecure services, protocols, and daemons are adequately secured with appropriate security features makes it more difficult for malicious individuals to take advantage of commonly used points of compromise within a network. 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. |
| 29 | 29 | R. 2 | 2.2.4 Configure system security parameters to prevent misuse. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.2.4.a Interview system administrators and/or security managers to verify that they have knowledge of common security parameter settings for system components. 2.2.4.b Examine the system configuration standards to verify that common security parameter settings are included. 2.2.4.c Select a sample of system components and inspect the common security parameters to verify that they are set appropriately and in accordance with the configuration standards. | System configuration standards and related processes should specifically address security settings and parameters that have known security implications for each type of system in use. 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. |
| 30 | 30 | R. 2 | 2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.2.5.a Select a sample of system components and inspect the configurations to verify that all unnecessary functionality (for example, scripts, drivers, features, subsystems, file systems, etc.) is removed. 2.2.5.b. Examine the documentation and security parameters to verify enabled functions are documented and support secure configuration. 2.2.5.c. Examine the documentation and security parameters to verify that only documented functionality is present on the sampled system components. | Unnecessary functions can provide additional opportunities for malicious individuals to gain access to a system. By removing unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited. Including this in server-hardening standards and processes addresses the specific security implications associated with unnecessary functions (for example, by removing/disabling FTP or the web server if the server will not be performing those functions). |
| 31 | 31 | R. 2 | 2.3 Encrypt all non-console administrative access using strong cryptography. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.3 Select a sample of system components and verify that non-console administrative access is encrypted by performing the following: 2.3.a Observe an administrator log on to each system and examine system configurations to verify that a strong encryption method is invoked before the administrator’s password is requested. 2.3.b Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access. 2.3.c Observe an administrator log on to each system to verify that administrator access to any web-based management interfaces is encrypted with strong cryptography. 2.3.d Examine vendor documentation and interview personnel to verify that strong cryptography for the technology in use is implemented according to industry best practices and/or vendor recommendations. | If 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. To be considered ~strong cryptography,~ industry- recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use. (Refer to ~strong cryptography~ in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms, and industry standards and best practices such as 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. |
| 32 | 32 | R. 2 | 2.4 Maintain an inventory of system components that are in scope for PCI DSS. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.4.a Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each. 2.4.b Interview personnel to verify the documented inventory is kept current. | Maintaining 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. |
| 33 | 33 | R. 2 | 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.5 Examine documentation and interview personnel to verify that security policies and operational procedures for managing vendor defaults and other security parameters are: . Documented, . In use, and . Known to all affected parties. | Personnel need to be aware of and following security policies and daily operational procedures to ensure vendor defaults and other security parameters are continuously managed to prevent insecure configurations. |
| 34 | 34 | R. 2 | 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers. | Build and Maintain a Secure Network | R2: Do not use vendor-supplied defaults for system passwords and other security parameters | 2.6 Perform testing procedures A.1.1 through A.1.4 detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS assessments of shared hosting providers, to verify that shared hosting providers protect their entities’ (merchants and service providers) hosted environment and data. | This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client's data and thereby gain access to all other clients' data. See Appendix A for details of requirements. |
| 35 | 35 | R. 3 | 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage: • 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. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.1.a Examine the data retention and disposal policies, procedures and processes to verify 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. . A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements. 3.1.b Interview personnel to verify that: . All locations of stored cardholder data are included in the data retention and disposal processes. . Either a quarterly automatic or manual process is in place to identify and securely delete stored cardholder data. . The quarterly automatic or manual process is performed for all locations of cardholder data. 3.1.c For a sample of system components that store cardholder data: . Examine files and system records to verify that the data stored does not exceed the requirements defined in the data retention policy . Observe the deletion mechanism to verify data is deleted securely. | A formal data retention policy identifies what data needs to be retained, and where that data resides so it can be securely destroyed or deleted as soon as it is no longer needed. The only cardholder data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code. Understanding where cardholder data is located is necessary so it can be properly retained or disposed of when no longer needed. In order to define appropriate retention requirements, an entity first needs to understand their own business needs as well as any legal or regulatory obligations that apply to their industry, and/or that apply to the type of data being retained. (Continued on next page) 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! |
| 36 | 36 | R. 3 | 3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process. It is permissible for issuers and companies that support issuing services to store sensitive authentication data if: • There is a business justification and • The data is stored securely. Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3: | Protect Cardholder Data | R3: Protect stored cardholder data | 3.2.a For issuers and/or companies that support issuing services and store sensitive authentication data, review policies and interview personnel to verify there is a documented business justification for the storage of sensitive authentication data. 3.2.b For issuers and/or companies that support issuing services and store sensitive authentication data, examine data stores and system configurations to verify that the sensitive authentication data is secured. 3.2.c For all other entities, if sensitive authentication data is received, review policies and procedures, and examine system configurations to verify the data is not retained after authorization. 3.2.d For all other entities, if sensitive authentication data is received, review procedures and examine the processes for securely deleting the data to verify that the data is unrecoverable. | 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. For non-issuing entities, retaining sensitive authentication data post-authorization is not permitted. |
| 37 | 37 | R. 3 | 3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. Note: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: • The cardholder’s name • Primary account number (PAN) • Expiration date • Service code To minimize risk, store only these data elements as needed for business. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.2.1 For a sample of system components, examine data sources including but not limited to the following, and verify that the full contents of any track from the magnetic stripe on the back of card or equivalent data on a chip are not stored after authorization: . Incoming transaction data . All logs (for example, transaction, history, debugging, error) . History files . Trace files . Several database schemas . Database contents. | If full track data is stored, malicious individuals who obtain that data can use it to reproduce payment cards and complete fraudulent transactions. |
| 38 | 38 | R. 3 | 3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored after authorization: . Incoming transaction data . All logs (for example, transaction, history, debugging, error) . History files . Trace files . Several database schemas . Database contents. | The purpose of the card validation code is to protect ~card-not-present~ transactions—Internet or mail order/telephone order (MO/TO) transactions—where the consumer and the card are not present. If this data is stolen, malicious individuals can execute fraudulent Internet and MO/TO transactions. |
| 39 | 39 | R. 3 | 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.2.3 For a sample of system components, examine data sources, including but not limited to the following and verify that PINs and encrypted PIN blocks are not stored after authorization: . Incoming transaction data . All logs (for example, transaction, history, debugging, error) . History files . Trace files . Several database schemas . Database contents. | These 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). |
| 40 | 40 | R. 3 | 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN. Note: This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment card brand requirements for point-of-sale (POS) receipts. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.3.a Examine written policies and procedures for masking the display of PANs to verify: . A list of roles that need access to displays of more than the first six/last four (includes full PAN) is documented, together with a legitimate business need for each role to have such access. . PAN must be masked when displayed such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN. . All roles not specifically authorized to see the full PAN must only see masked PANs. 3.3.b Examine system configurations to verify that full PAN is only displayed for users/roles with a documented business need, and that PAN is masked for all other requests. 3.3.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displaying cardholder data, and that only those with a legitimate business need are able to see more than the first six/last four digits of the PAN. | The display of full PAN on items such as computer screens, payment card receipts, faxes, or paper reports can result in this data being obtained by unauthorized individuals and used fraudulently. Ensuring that full PAN is only displayed for those with a legitimate business need to see the full PAN minimizes the risk of unauthorized persons gaining access to PAN data. The masking approach should always ensure that only the minimum number of digits is displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, mask the PAN so that individuals performing that function can view only the last four digits. As another example, if a function needs access to the bank identification number (BIN) for routing purposes, unmask only the BIN digits (traditionally the first six digits) during that function. This requirement relates to protection of PAN displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.4 for protection of PAN when stored in files, databases, etc. |
| 41 | 41 | R. 3 | 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: • One-way hashes based on strong cryptography, (hash must be of the entire PAN) • Truncation (hashing cannot be used to replace the truncated segment of PAN) • Index tokens and pads (pads must be securely stored) • Strong cryptography with associated key-management processes and procedures. Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.4.a Examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the following methods: . One-way hashes based on strong cryptography, . Truncation . Index tokens and pads, with the pads being securely stored . Strong cryptography, with associated key-management processes and procedures. 3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text). 3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm that the PAN is rendered unreadable. 3.4.d Examine a sample of audit logs, including payment application logs, to confirm that PAN is rendered unreadable or is not present in the logs. 3.4.e If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify 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. |
| 42 | 42 | R. 3 | 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). Decryption keys must not be associated with user accounts. Note: This requirement applies in addition to all other PCI DSS encryption and key-management requirements. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.4.1.a If disk encryption is used, inspect the configuration and observe the authentication process to verify that logical access to encrypted file systems is implemented via a mechanism that is separate from the native operating system’s authentication mechanism (for example, not using local user account databases or general network login credentials). 3.4.1.b Observe processes and interview personnel to verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls). 3.4.1.c Examine the configurations and observe the processes to verify that cardholder data on removable media is encrypted wherever stored. Note: If disk encryption is not used to encrypt removable media, the data stored on this media will need to be rendered unreadable through some other method. | 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. |
| 43 | 43 | R. 3 | 3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse: Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys—such key-encrypting keys must be at least as strong as the data-encrypting key. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.5 Examine key-management policies and procedures to verify processes are specified to protect keys used for encryption of cardholder data against disclosure and misuse and include at least the following: . Access to keys is restricted to the fewest number of custodians necessary. . Key-encrypting keys are at least as strong as the data- encrypting keys they protect. . Key-encrypting keys are stored separately from data- encrypting keys. . Keys are stored securely in the fewest possible locations and forms. | 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. |
| 44 | 44 | R. 3 | 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes: • Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date • Description of the key usage for each key. • Inventory of any HSMs and other SCDs used for key management | Protect Cardholder Data | R3: Protect stored cardholder data | 3.5.1 Interview responsible personnel and review documentation to verify that a document exists to describe the cryptographic architecture, including: . Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date . Description of the key usage for each key . Inventory of any HSMs and other SCDs used for key management | Note: This requirement applies only when the entity being assessed is a service provider. Maintaining current documentation of the cryptographic architecture enables an entity to understand the algorithms, protocols, and cryptographic keys used to protect cardholder data, as well as the devices that generate, use and protect the keys. This allows an entity to keep pace with evolving threats to their architecture, enabling them to plan for updates as the assurance levels provided by different algorithms/key strengths changes. Maintaining such documentation also allows an entity to detect lost or missing keys or key-management devices, and identify unauthorized additions to their cryptographic architecture. |
| 45 | 45 | R. 3 | 3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.5.2 Examine user access lists to verify that access to keys is restricted to the fewest number of custodians necessary. | There 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. |
| 46 | 46 | R. 3 | 3.5.3 Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times: • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key • Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) • As at least two full-length key components or key shares, in accordance with an industry-accepted method Note: It is not required that public keys be stored in one of these forms. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.5.3.a Examine documented procedures to verify that cryptographic keys used to encrypt/decrypt cardholder data must only exist in one (or more) of the following forms at all times. . Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key . Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) . As key components or key shares, in accordance with an industry-accepted method 3.5.3.b Examine system configurations and key storage locations to verify that cryptographic keys used to encrypt/decrypt cardholder data exist in one (or more) of the following form at all times. . Encrypted with a key-encrypting key . Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) . As key components or key shares, in accordance with an industry-accepted method 3.5.3.c Wherever key-encrypting keys are used, examine system configurations and key storage locations to verify: . Key-encrypting keys are at least as strong as the data- encrypting keys they protect . Key-encrypting keys are stored separately from data- encrypting keys. | Cryptographic keys must be stored securely to prevent unauthorized or unnecessary access that could result in the exposure of cardholder data. It is not intended that the key-encrypting keys be encrypted, however they are to be protected against disclosure and misuse as defined in Requirement 3.5. If key-encrypting keys are used, storing the key-encrypting keys in physically and/or logically separate locations from the data- encrypting keys reduces the risk of unauthorized access to both keys. |
| 47 | 47 | R. 3 | 3.5.4 Store cryptographic keys in the fewest possible locations. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.5.4 Examine key storage locations and observe processes to verify that keys are stored in the fewest possible locations. | Storing cryptographic keys in the fewest locations helps an organization to keep track and monitor all key locations, and minimizes the potential for keys to be exposed to unauthorized parties. |
| 48 | 48 | R. 3 | 3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following: Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.a Additional testing procedure for service provider assessments only: If the service provider shares keys with their customers for transmission or storage of cardholder data, examine the documentation that the service provider provides to their customers to verify that it includes guidance on how to securely transmit, store, and update customers’ keys, in accordance with Requirements 3.6.1 through 3.6.8 below. 3.6.b Examine the key-management procedures and processes for keys used for encryption of cardholder data and perform the following: | 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. |
| 49 | 49 | R. 3 | 3.6.1 Generation of strong cryptographic keys | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.1.a Verify that key-management procedures specify how to generate strong keys. 3.6.1.b Observe the method for generating keys to verify that strong keys are generated. | The encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under ~strong cryptography.~ Use of strong cryptographic keys significantly increases the level of security of encrypted cardholder data. |
| 50 | 50 | R. 3 | 3.6.2 Secure cryptographic key distribution | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.2.a Verify that key-management procedures specify how to securely distribute keys. 3.6.2.b Observe the method for distributing keys to verify that keys are distributed securely. | The encryption solution must distribute keys securely, meaning the keys are distributed only to custodians identified in 3.5.2, and are never distributed in the clear. |
| 51 | 51 | R. 3 | 3.6.3 Secure cryptographic key storage | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.3.a Verify that key-management procedures specify how to securely store keys. 3.6.3.b Observe the method for storing keys to verify that keys are stored securely. | The encryption solution must store keys securely, for example, by encrypting them with a key- encrypting key. Storing keys without proper protection could provide access to attackers, resulting in the decryption and exposure of cardholder data. |
| 52 | 52 | R. 3 | 3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57). | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.4.a Verify that key-management procedures include a defined cryptoperiod for each key type in use and define a process for key changes at the end of the defined cryptoperiod(s). 3.6.4.b Interview personnel to verify that keys are changed at the end of the defined cryptoperiod(s). | A 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. |
| 53 | 53 | R. 3 | 3.6.5 Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised. Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key-encryption key). Archived cryptographic keys should only be used for decryption/verification purposes. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.5.a Verify that key-management procedures specify processes for the following: . The retirement or replacement of keys when the integrity of the key has been weakened . The replacement of known or suspected compromised keys. . Any keys retained after retiring or replacing are not used for encryption operations 3.6.5.b Interview personnel to verify the following processes are implemented: . Keys are retired or replaced as necessary when the integrity of the key has been weakened, including when someone with knowledge of the key leaves the company. . Keys are replaced if known or suspected to be compromised. . Any keys retained after retiring or replacing are not used for encryption operations. | Keys that are no longer used or needed, or keys that are known or suspected to be compromised, should be revoked and/or destroyed to ensure that the keys can no longer be used. If such keys need to be kept (for example, to support archived, encrypted data) they should be strongly protected. The encryption solution should provide for and facilitate a process to replace keys that are due for replacement or that are known to be, or suspected of being, compromised. |
| 54 | 54 | R. 3 | 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control. Note: Examples of manual key-management operations include, but are not limited to: key generation, transmission, loading, storage and destruction. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.6.a Verify that manual clear-text key-management procedures specify processes for the use of the following: . Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND . Dual control of keys, such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example, passwords or keys) of another. 3.6.6 b Interview personnel and/or observe processes to verify that manual clear-text keys are managed with: . Split knowledge, AND . Dual control | Split knowledge and dual control of keys are used to eliminate the possibility of one person having access to the whole key. This control is applicable for manual key-management operations, or where key management is not implemented by the encryption product. Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of the original cryptographic key). Dual control requires two or more people to perform a function, and no single person can access or use the authentication materials of another. |
| 55 | 55 | R. 3 | 3.6.7 Prevention of unauthorized substitution of cryptographic keys. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.7.a Verify that key-management procedures specify processes to prevent unauthorized substitution of keys. 3.6.7.b Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented. | The encryption solution should not allow for or accept substitution of keys coming from unauthorized sources or unexpected processes. |
| 56 | 56 | R. 3 | 3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.6.8.a Verify that key-management procedures specify processes for key custodians to acknowledge (in writing or electronically) that they understand and accept their key- custodian responsibilities. 3.6.8.b Observe documentation or other evidence showing that key custodians have acknowledged (in writing or electronically) that they understand and accept their key- custodian responsibilities. | This process will help ensure individuals that act as key custodians commit to the key-custodian role and understand and accept the responsibilities. |
| 57 | 57 | R. 3 | 3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties. | Protect Cardholder Data | R3: Protect stored cardholder data | 3.7 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting stored cardholder data are: . Documented, . In use, and . Known to all affected parties. | Personnel need to be aware of and following security policies and documented operational procedures for managing the secure storage of cardholder data on a continuous basis. |
| 58 | 58 | R. 4 | 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following: • Only trusted keys and certificates are accepted. • The protocol in use only supports secure versions or configurations. • The encryption strength is appropriate for the encryption methodology in use. Examples of open, public networks include but are not limited to: • The Internet • Wireless technologies, including 802.11 and Bluetooth • Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA) • General Packet Radio Service (GPRS). • Satellite communications. | Protect Cardholder Data | R4: Encrypt transmission of cardholder data across open, public networks | 4.1.a Identify all locations where cardholder data is transmitted or received over open, public networks. Examine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for all locations. 4.1.b Review documented policies and procedures to verify processes are specified for the following: . For acceptance of only trusted keys and/or certificates . For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported) . For implementation of proper encryption strength per the encryption methodology in use 4.1.c Select and observe a sample of inbound and outbound transmissions as they occur to verify that all cardholder data is encrypted with strong cryptography during transit. 4.1.d Examine keys and certificates to verify that only trusted keys and/or certificates are accepted. 4.1.e Examine system configurations to verify that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations. 4.1.f Examine system configurations to verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.) 4.1.g For TLS implementations, examine system configurations to verify that TLS is enabled whenever cardholder data is transmitted or received. For example, for browser-based implementations: . ~HTTPS~ appears as the browser Universal Record Locator (URL) protocol, and . Cardholder data is only requested if ~HTTPS~ appears as part of the URL. | 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. |
| 59 | 59 | R. 4 | 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission. | Protect Cardholder Data | R4: Encrypt transmission of cardholder data across open, public networks | 4.1.1 Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings to verify the following for all wireless networks identified: . Industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission. . Weak encryption (for example, WEP, SSL) is not used as a security control for authentication or transmission. | Malicious users use free and widely available tools to eavesdrop on wireless communications. Use of strong cryptography can help limit disclosure of sensitive information across wireless networks. Strong cryptography for authentication and transmission of cardholder data is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data. |
| 60 | 60 | R. 4 | 4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.). | Protect Cardholder Data | R4: Encrypt transmission of cardholder data across open, public networks | 4.2.a If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies. 4.2.b Review written policies to verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies. | E-mail, instant messaging, SMS, and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. Do not utilize these messaging tools to send PAN unless they are configured to provide strong encryption. Additionally, if an entity requests PAN via end- user messaging technologies, the entity should provide a tool or method to protect these PANs using strong cryptography or render PANs unreadable before transmission. |
| 61 | 61 | R. 4 | 4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties. | Protect Cardholder Data | R4: Encrypt transmission of cardholder data across open, public networks | 4.3 Examine documentation and interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are: . Documented, . In use, and . Known to all affected parties. | Personnel need to be aware of and following security policies and operational procedures for managing the secure transmission of cardholder data on a continuous basis. |
| 62 | 62 | R. 5 | 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). | Maintain a Vulnerability Management Program | R5: Use and regularly update anti-virus software or programs | 5.1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists. | There is a constant stream of attacks using widely published exploits, often called ~zero day~ (an attack that exploits a previously unknown vulnerability), against otherwise secured systems. Without an anti-virus solution that is updated regularly, these new forms of malicious software can attack systems, disable a network, or lead to compromise of data. |
| 63 | 63 | R. 5 | 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. | Maintain a Vulnerability Management Program | R5: Use and regularly update anti-virus software or programs | 5.1.1 Review vendor documentation and examine anti-virus configurations to verify that anti-virus programs; . Detect all known types of malicious software, . Remove all known types of malicious software, and . Protect against all known types of malicious software. Examples of types of malicious software include viruses, Trojans, worms, spyware, adware, and rootkits. | It is important to protect against ALL types and forms of malicious software. |
| 64 | 64 | R. 5 | 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software. | Maintain a Vulnerability Management Program | R5: Use and regularly update anti-virus software or programs | 5.1.2 Interview personnel to verify that evolving malware threats are monitored and evaluated for systems not currently considered to be commonly affected by malicious software, in order to confirm whether such systems continue to not require anti-virus software. | Typically, mainframes, mid-range computers (such as AS/400) and similar systems may not currently be commonly targeted or affected by malware. However, industry trends for malicious software can change quickly, so it is important for organizations to be aware of new malware that might affect their systems—for example, by monitoring vendor security notices and anti-virus news groups to determine whether their systems might be coming under threat from new and evolving malware. Trends in malicious software should be included in the identification of new security vulnerabilities, and methods to address new trends should be incorporated into the company's configuration standards and protection mechanisms as needed |
| 65 | 65 | R. 5 | 5.2 Ensure that all anti-virus mechanisms are maintained as follows: • Are kept current, • Perform periodic scans • Generate audit logs which are retained per PCI DSS Requirement 10.7. | Maintain a Vulnerability Management Program | R5: Use and regularly update anti-virus software or programs | 5.2.a Examine policies and procedures to verify that anti-virus software and definitions are required to be kept up to date. 5.2.b Examine anti-virus configurations, including the master installation of the software to verify anti-virus mechanisms are: . Configured to perform automatic updates, and . Configured to perform periodic scans. 5.2.c Examine a sample of system components, including all operating system types commonly affected by malicious software, to verify that: . The anti-virus software and definitions are current. . Periodic scans are performed. 5.2.d Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that: . Anti-virus software log generation is enabled, and . Logs are retained in accordance with PCI DSS Requirement 10.7. | 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. |
| 66 | 66 | R. 5 | 5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period. Note: Anti-virus solutions may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If anti-virus protection needs to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active. | Maintain a Vulnerability Management Program | R5: Use and regularly update anti-virus software or programs | 5.3.a Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify the anti-virus software is actively running. 5.3.b Examine anti-virus configurations, including the master installation of the software and a sample of system components, to verify that the anti-virus software cannot be disabled or altered by users. 5.3.c Interview responsible personnel and observe processes to verify that anti-virus software cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period. | Anti-virus that continually runs and is unable to be altered will provide persistent security against malware. Use of policy-based controls on all systems to ensure anti-malware protections cannot be altered or disabled will help prevent system weaknesses from being exploited by malicious software. Additional security measures may also need to be implemented for the period of time during which anti-virus protection is not active—for example, disconnecting the unprotected system from the Internet while the anti-virus protection is disabled, and running a full scan after it is re-enabled. |
| 67 | 67 | R. 5 | 5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties. | Maintain a Vulnerability Management Program | R5: Use and regularly update anti-virus software or programs | 5.4 Examine documentation and interview personnel to verify that security policies and operational procedures for protecting systems against malware are: . Documented, . In use, and . Known to all affected parties. | Personnel need to be aware of and following security policies and operational procedures to ensure systems are protected from malware on a continuous basis. |
| 68 | 68 | R. 6 | 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. Note: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected. Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk-assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the environment. In addition to the risk ranking, vulnerabilities may be considered “critical” if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing devices and systems, databases, and other systems that store, process, or transmit cardholder data. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.1.a Examine policies and procedures to verify that processes are defined for the following: . To identify new security vulnerabilities . To assign a risk ranking to vulnerabilities that includes identification of all ~high risk~ and ~critical~ vulnerabilities. . To use reputable outside sources for security vulnerability information. 6.1.b Interview responsible personnel and observe processes to verify that: . New security vulnerabilities are identified. . A risk ranking is assigned to vulnerabilities that includes identification of all ~high~ risk and ~critical~ vulnerabilities. . Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information. | The 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. |
| 69 | 69 | R. 6 | 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release. Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.2.a Examine policies and procedures related to security- patch installation to verify processes are defined for: . Installation of applicable critical vendor-supplied security patches within one month of release. . Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months). 6.2.b For a sample of system components and related software, compare the list of security patches installed on each system to the most recent vendor security-patch list, to verify the following: . That applicable critical vendor-supplied security patches are installed within one month of release. . All applicable vendor-supplied security patches are installed within an appropriate time frame (for example, within three months). | 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). |
| 70 | 70 | R. 6 | 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: • In accordance with PCI DSS (for example, secure authentication and logging) • Based on industry standards and/or best practices. • Incorporating information security throughout the software-development life cycle Note: This applies to all software developed internally as well as bespoke or custom software developed by a third party. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.3.a Examine written software-development processes to verify that the processes are based on industry standards and/or best practices. 6.3.b Examine written software-development processes to verify that information security is included throughout the life cycle. 6.3.c Examine written software-development processes to verify that software applications are developed in accordance with PCI DSS. 6.3.d Interview software developers to verify that written software-development processes are implemented. | 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. |
| 71 | 71 | R. 6 | 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.3.1 Examine written software-development procedures and interview responsible personnel to verify that pre- production and/or custom application accounts, user IDs and/or passwords are removed before an application goes into production or is released to customers. | Development, test and/or custom application accounts, user IDs, and passwords should be removed from production code before the application becomes active or is released to customers, since these items may give away information about the functioning of the application. Possession of such information could facilitate compromise of the application and related cardholder data. |
| 72 | 72 | R. 6 | 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) to include at least the following: • Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices. • Code reviews ensure code is developed according to secure coding guidelines • Appropriate corrections are implemented prior to release. • Code-review results are reviewed and approved by management prior to release. Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.3.2.a Examine written software-development procedures and interview responsible personnel to verify that all custom application code changes must be reviewed (using either manual or automated processes) as follows: . Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code-review techniques and secure coding practices. . Code reviews ensure code is developed according to secure coding guidelines (see PCI DSS Requirement 6.5). . Appropriate corrections are implemented prior to release. . Code-review results are reviewed and approved by management prior to release. 6.3.2.b Select a sample of recent custom application changes and verify that custom application code is reviewed according to 6.3.2.a, above. | 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. |
| 73 | 73 | R. 6 | 6.4 Follow change control processes and procedures for all changes to system components. The processes must include the following: | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4 Examine policies and procedures to verify the following are defined: . Development/test environments are separate from production environments with access control in place to enforce separation. . A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment. . Production data (live PANs) are not used for testing or development. . Test data and accounts are removed before a production system becomes active. . Change control procedures related to implementing security patches and software modifications are documented. | Without properly documented and implemented change controls, security features could be inadvertently or deliberately omitted or rendered inoperable, processing irregularities could occur, or malicious code could be introduced. |
| 74 | 74 | R. 6 | 6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.1.a Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s). 6.4.1.b Examine access controls settings to verify that access controls are in place to enforce separation between the development/test environments and the production environment(s). | Due to the constantly changing state of development and test environments, they tend to be less secure than the production environment. Without adequate separation between environments, it may be possible for the production environment, and cardholder data, to be compromised due to less- stringent security configurations and possible vulnerabilities in a test or development environment. |
| 75 | 75 | R. 6 | 6.4.2 Separation of duties between development/test and production environments | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.2 Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment. | Reducing the number of personnel with access to the production environment and cardholder data minimizes risk and helps ensure that access is limited to those individuals with a business need to know. The intent of this requirement is to separate development and test functions from production functions. For example, a developer may use an administrator-level account with elevated privileges in the development environment, and have a separate account with user-level access to the production environment. |
| 76 | 76 | R. 6 | 6.4.3 Production data (live PANs) are not used for testing or development | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.3.a Observe testing processes and interview personnel to verify procedures are in place to ensure production data (live PANs) are not used for testing or development. 6.4.3.b Examine a sample of test data to verify production data (live PANs) is not used for testing or development. | Security controls are usually not as stringent in test or development environments. Use of production data provides malicious individuals with the opportunity to gain unauthorized access to production data (cardholder data). |
| 77 | 77 | R. 6 | 6.4.4 Removal of test data and accounts from system components before the system becomes active/goes into production. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.4.a Observe testing processes and interview personnel to verify test data and accounts are removed before a production system becomes active. 6.4.4.b Examine a sample of data and accounts from production systems recently installed or updated to verify test data and accounts are removed before the system becomes active. | Test data and accounts should be removed before the system component becomes active (in production), since these items may give away information about the functioning of the application or system. Possession of such information could facilitate compromise of the system and related cardholder data. |
| 78 | 78 | R. 6 | 6.4.5 Change control procedures must include the following: | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.5.a Examine documented change control procedures and verify procedures are defined for: . Documentation of impact . Documented change approval by authorized parties . Functionality testing to verify that the change does not adversely impact the security of the system . Back-out procedures 6.4.5.b For a sample of system components, interview responsible personnel to determine recent changes. Trace those changes back to related change control documentation. For each change examined, perform the following: | If not properly managed, the impact of system changes—such as hardware or software updates and installation of security patches—might not be fully realized and could have unintended consequences. |
| 79 | 79 | R. 6 | 6.4.5.1 Documentation of impact. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.5.1 Verify that documentation of impact is included in the change control documentation for each sampled change. | The impact of the change should be documented so that all affected parties can plan appropriately for any processing changes. |
| 80 | 80 | R. 6 | 6.4.5.2 Documented change approval by authorized parties. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.5.2 Verify that documented approval by authorized parties is present for each sampled change. | Approval by authorized parties indicates that the change is a legitimate and approved change sanctioned by the organization. |
| 81 | 81 | R. 6 | 6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.5.3.a For each sampled change, verify that functionality testing is performed to verify that the change does not adversely impact the security of the system. 6.4.5.3.b For custom code changes, verify that all updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production. | Thorough testing should be performed to verify that the security of the environment is not reduced by implementing a change. Testing should validate that all existing security controls remain in place, are replaced with equally strong controls, or are strengthened after any change to the environment. |
| 82 | 82 | R. 6 | 6.4.5.4 Back-out procedures. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.5.4 Verify that back-out procedures are prepared for each sampled change. | For each change, there should be documented back-out procedures in case the change fails or adversely affects the security of an application or system, to allow the system to be restored back to its previous state. |
| 83 | 83 | R. 6 | 6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.4.6 For a sample of significant changes, examine change records, interview personnel, and observe the affected systems/networks to verify that applicable PCI DSS requirements were implemented and documentation updated as part of the change. | Having processes to analyze significant changes helps ensure that all appropriate PCI DSS controls are applied to any systems or networks added or changed within the in-scope environment. Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed. A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process. Examples of PCI DSS requirements that could be impacted include, but are not limited to: . Network diagram is updated to reflect changes. . Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled. . Systems are protected with required controls—e.g., file-integrity monitoring (FIM), anti-virus, patches, audit logging. . Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data-retention policy and procedures . New systems are included in the quarterly vulnerability scanning process. |
| 84 | 84 | R. 6 | 6.5 Address common 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. Note: Requirements 6.5.1 through 6.5.6, below, apply to all applications (internal or external). | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.a Examine software-development policies and procedures to verify that up-to-date training in secure coding techniques is required for developers at least annually, based on industry best practices and guidance. 6.5.b Examine records of training to verify that software developers receive up-to-date training on secure coding techniques at least annually, including how to avoid common coding vulnerabilities. 6.5.c Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities: | 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. |
| 85 | 85 | R. 6 | 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.1 Examine software-development policies and procedures and interview responsible personnel to verify that injection flaws are addressed by coding techniques that include: . Validating input to verify user data cannot modify meaning of commands and queries. . Utilizing parameterized queries. | Injection flaws, particularly SQL injection, are a commonly used method for compromising applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data, and allows the attacker to attack components inside the network through the application, to initiate attacks such as buffer overflows, or to reveal both confidential information and server application functionality. Information should be validated before being sent to the application—for example, by checking for all alpha characters, mix of alpha and numeric characters, etc. Note: Requirements 6.5.1 through 6.5.6, below, apply to all applications (internal or external). |
| 86 | 86 | R. 6 | 6.5.2 Buffer overflows | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.2 Examine software-development policies and procedures and interview responsible personnel to verify that buffer overflows are addressed by coding techniques that include: . Validating buffer boundaries. . Truncating input strings. | Buffer overflows occur when an application does not have appropriate bounds checking on its buffer space. This can cause the information in the buffer to be pushed out of the buffer’s memory space and into executable memory space. When this occurs, the attacker has the ability to insert malicious code at the end of the buffer and then push that malicious code into executable memory space by overflowing the buffer. The malicious code is then executed and often enables the attacker remote access to the application and/or infected system. Note: Requirements 6.5.1 through 6.5.6, below, apply to all applications (internal or external). |
| 87 | 87 | R. 6 | 6.5.3 Insecure cryptographic storage | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.3 Examine software-development policies and procedures and interview responsible personnel to verify that insecure cryptographic storage is addressed by coding techniques that: . Prevent cryptographic flaws. . Use strong cryptographic algorithms and keys. | Applications that do not utilize strong cryptographic functions properly to store data are at increased risk of being compromised, and exposing authentication credentials and/or cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain clear-text access to encrypted data. |
| 88 | 88 | R. 6 | 6.5.4 Insecure communications | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.4 Examine software-development policies and procedures and interview responsible personnel to verify that insecure communications are addressed by coding techniques that properly authenticate and encrypt all sensitive communications. | Applications that fail to adequately encrypt network traffic using strong cryptography are at increased risk of being compromised and exposing cardholder data. If an attacker is able to exploit weak cryptographic processes, they may be able to gain control of an application or even gain clear-text access to encrypted data. |
| 89 | 89 | R. 6 | 6.5.5 Improper error handling | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.5 Examine software-development policies and procedures and interview responsible personnel to verify that improper error handling is addressed by coding techniques that do not leak information via error messages (for example, by returning generic rather than specific error details). | Applications can unintentionally leak information about their configuration or internal workings, or expose privileged information through improper error handling methods. Attackers use this weakness to steal sensitive data or compromise the system altogether. If a malicious individual can create errors that the application does not handle properly, they can gain detailed system information, create denial-of-service interruptions, cause security to fail, or crash the server. For example, the message ~incorrect password provided~ tells an attacker the user ID provided was accurate and that they should focus their efforts only on the password. Use more generic error messages, like ~data could not be verified.~ |
| 90 | 90 | R. 6 | 6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1). | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.6 Examine software-development policies and procedures and interview responsible personnel to verify that coding techniques address any “high risk” vulnerabilities that could affect the application, as identified in PCI DSS Requirement 6.1. | All vulnerabilities identified by an organization’s vulnerability risk-ranking process (defined in Requirement 6.1) to be “high risk” and that could affect the application should be identified and addressed during application development. Web applications, both internally and externally (public) facing, have unique security risks based upon their architecture as well as the relative ease and occurrence of compromise. |
| 91 | 91 | R. 6 | 6.5.7 Cross-site scripting (XSS) Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces (internal or external): | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.7 Examine software-development policies and procedures and interview responsible personnel to verify that cross-site scripting (XSS) is addressed by coding techniques that include . Validating all parameters before inclusion . Utilizing context-sensitive escaping. Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces (internal or external): | XSS flaws occur whenever an application takes user-supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser, which can hijack user sessions, deface web sites, possibly introduce worms, etc. |
| 92 | 92 | R. 6 | 6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions). | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.8 Examine software-development policies and procedures and interview responsible personnel to verify that improper access control—such as insecure direct object references, failure to restrict URL access, and directory traversal—is addressed by coding technique that includes: . Proper authentication of users . Sanitizing input . Not exposing internal object references to users . User interfaces that do not permit access to unauthorized functions. | 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. |
| 93 | 93 | R. 6 | 6.5.9 Cross-site request forgery (CSRF) | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.9 Examine software development policies and procedures and interview responsible personnel to verify that cross-site request forgery (CSRF) is addressed by coding techniques that ensure applications do not rely on authorization credentials and tokens automatically submitted by browsers. | A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then enables the attacker to perform any state-changing operations the victim is authorized to perform (such as updating account details, making purchases, or even authenticating to the application). |
| 94 | 94 | R. 6 | 6.5.10 Broken authentication and session management | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.5.10 Examine software development policies and procedures and interview responsible personnel to verify that broken authentication and session management are addressed via coding techniques that commonly include: . Flagging session tokens (for example cookies) as ~secure~ . Not exposing session IDs in the URL . Incorporating appropriate time-outs and rotation of session IDs after a successful login. | Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user. |
| 95 | 95 | R. 6 | 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes 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. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.6 For public-facing web applications, ensure that either one of the following methods is in place as follows: . Examine documented processes, interview personnel, and examine records of application security assessments to verify that public-facing web applications are reviewed—using either manual or automated vulnerability security assessment tools or methods—as follows: - At least annually - After any changes - By an organization that specializes in application security - That, at a minimum, all vulnerabilities in Requirement 6.5 are included in the assessment - That all vulnerabilities are corrected - That the application is re-evaluated after the corrections. . Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows: - Is situated in front of public-facing web applications to detect and prevent web-based attacks. - Is actively running and up to date as applicable. - Is generating audit logs. - Is configured to either block web-based attacks, or generate an alert 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. |
| 96 | 96 | R. 6 | 6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties. | Maintain a Vulnerability Management Program | R6: Develop and maintain secure systems and applications | 6.7 Examine documentation and interview personnel to verify that security policies and operational procedures for developing and maintaining secure systems and applications are: . Documented, . In use, and . Known to all affected parties. | Personnel need to be aware of and following security policies and operational procedures to ensure systems and applications are securely developed and protected from vulnerabilities on a continuous basis. |
| 97 | 97 | R. 7 | 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. | Implement Strong Access Control Measures | R7: Restrict access to cardholder data by business need to know | 7.1 Examine written policy for access control, and verify that the policy incorporates 7.1.1 through 7.1.4 as follows: . Defining access needs and privilege assignments for each role . Restriction of access to privileged user IDs to least privileges necessary to perform job responsibilities . Assignment of access based on individual personnel’s job classification and function . Documented approval (electronically or in writing) by authorized parties for all access, including listing of specific privileges approved. | The more people who have access to cardholder data, the more risk there is that a user’s account will be used maliciously. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through inexperience or malice. |
| 98 | 98 | R. 7 | 7.1.1 Define access needs for each role, including: • System components and data resources that each role needs to access for their job function • Level of privilege required (for example, user, administrator, etc.) for accessing resources. | Implement Strong Access Control Measures | R7: Restrict access to cardholder data by business need to know | 7.1.1 Select a sample of roles and verify access needs for each role are defined and include: . System components and data resources that each role needs to access for their job function . Identification of privilege necessary for each role to perform their job function. | In order to limit access to cardholder data to only those individuals who need such access, first it is necessary to define access needs for each role (for example, system administrator, call center personnel, store clerk), the systems/devices/data each role needs access to, and the level of privilege each role needs to effectively perform assigned tasks. Once roles and corresponding access needs are defined, individuals can be granted access accordingly. |
| 99 | 99 | R. 7 | 7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities. | Implement Strong Access Control Measures | R7: Restrict access to cardholder data by business need to know | 7.1.2.a Interview personnel responsible for assigning access to verify that access to privileged user IDs is: . Assigned only to roles that specifically require such privileged access . Restricted to least privileges necessary to perform job responsibilities. 7.1.2.b Select a sample of user IDs with privileged access and interview responsible management personnel to verify that privileges assigned are: . Necessary for that individual’s job function . Restricted to least privileges necessary to perform job responsibilities. | When 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. (Continued on next page) Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID. |
| 100 | 100 | R. 7 | 7.1.3 Assign access based on individual personnel’s job classification and function. | Implement Strong Access Control Measures | R7: Restrict access to cardholder data by business need to know | 7.1.3 Select a sample of user IDs and interview responsible management personnel to verify that privileges assigned are based on that individual’s job classification and function. | Once needs are defined for user roles (per PCI DSS requirement 7.1.1), it is easy to grant individuals access according to their job classification and function by using the already-created roles. |
| Req. ID | Goal |
Information Technology & Cybersecurity Training and Consulting