PCI DSS 3.2 includes clarification to existing requirements, new or evolving requirements, and additional guidance.
Within the 12 core requirements of the PCI DSS, there are five new sub-requirements for service providers affecting requirements: 3, 10, 11 and 12. New sub-requirements have been added to requirement 8 to ensure multi-factor authentication is used for all non-console administrative access and all remote access in the cardholder data environment. There are also two new appendices. Appendix A2 incorporates new migration deadlines for removal of Secure Sockets Layer (SSL) /early Transport Layer Security (TLS). Appendix A3 incorporates the “Designated Entities Supplemental Validation” (DESV ), which was previously a separate document.
The table below provided the list of changes by change types
Note: Get this list as part of the your PCI Compliance Dashboard 3.2
Within the 12 core requirements of the PCI DSS, there are five new sub-requirements for service providers affecting requirements: 3, 10, 11 and 12. New sub-requirements have been added to requirement 8 to ensure multi-factor authentication is used for all non-console administrative access and all remote access in the cardholder data environment. There are also two new appendices. Appendix A2 incorporates new migration deadlines for removal of Secure Sockets Layer (SSL) /early Transport Layer Security (TLS). Appendix A3 incorporates the “Designated Entities Supplemental Validation” (DESV ), which was previously a separate document.
The table below provided the list of changes by change types
- New requirements, testing procedures and appendix
- Clarification
- Alignment
- Guidance
- Removed items
- Renumbering
Note: Get this list as part of the your PCI Compliance Dashboard 3.2
|
Item
|
Description
|
|
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 Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement. |
New requirement for service providers to maintain a documented description of the cryptographic architecture.
Effective February 1, 2018 |
|
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. Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
|
New requirement for change control processes to include verification of PCI DSS requirements impacted by a change.Effective February 1, 2018
|
|
NEW 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement. 8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network. |
Expanded Requirement 8.3 into sub- requirements, to require multi-factor authentication for all personnel with non-console administrative access, and all personnel with remote access to the CDE.
New Requirement 8.3.2 addresses multi-factor authentication for all personnel with remote access to the CDE (incorporates former Requirement 8.3). New Requirement 8.3.1 addresses multi-factor authentication for all personnel with non-console administrative access to the CDE. Requirement 8.3.1 effective February 1, 2018 New Requirement 8.3.1 addresses multi-factor authentication for all personnel with non-console administrative access to the CDE. Requirement 8.3.1 effective February 1, 2018 |
|
10.8 Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:
Firewalls, IDS/IPS, FIM, Anti-virus, Physical access controls, Logical access controls, Audit logging mechanisms, Segmentation controls (if used) 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include: Restoring security functions Identifying and documenting the duration (date and time start to end) of the security failure Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause Identifying and addressing any security issues that arose during the failure Performing a risk assessment to determine whether further actions are required as a result of the security failure Implementing controls to prevent cause of failure from reoccurring Resuming monitoring of security controls |
New requirement for service providers to detect and report on failures of critical security control systems.
Effective February 1, 2018 |
|
11.3.4.c TEST Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV).
|
Added Testing Procedure 11.3.4.c to confirm penetration test is performed by a qualified internal resource or qualified external third party.
|
|
11.3.4.1 Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods. Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement.
|
New requirement for service providers to perform penetration testing on segmentation controls at least every six months.
Effective February 1, 2018 |
|
12.4.1 Additional requirement for service providers only: Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:
Overall accountability for maintaining PCI DSS compliance Defining a charter for a PCI DSS compliance program and communication to executive management |
New requirement for service providers’ executive management to establish responsibilities for the protection of cardholder data and a PCI DSS compliance program.
Effective February 1, 2018 |
|
12.11 Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:
· Daily log reviews · Firewall rule-set reviews · Applying configuration standards to new systems · Responding to security alerts · Change management processes Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement. 12.11.1 Additional requirement for service providers only: Maintain documentation of quarterly review process to include: Documenting results of the reviews Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program Note: This requirement is a best practice until January 31, 2018, after which it becomes a requirement. |
New requirement for service providers to perform reviews at least quarterly, to confirm personnel are following security policies and operational procedures.
Effective February 1, 2018 |
|
NEW A2.1 Where POS POI terminals (and the SSL/TLS termination points to which they connect) use SSL and/or early TLS, the entity must either:
· Confirm the devices are not susceptible to any known exploits for those protocols. Or: · Have a formal Risk Mitigation NEW A2.2 Entities with existing implementations (other than as allowed in A2.1) that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. NEW A2.3 Additional Requirement for Service Providers Only: All service providers must provide a secure service offering by June 30, 2016. Note: Prior to June 30, 2016, the service provider must either have a secure protocol option included in their service offering, or have a documented Risk Mitigation and Migration Plan (per A2.2) that includes a target date for provision of a secure protocol option no later than June 30, 2016. After this date, all service providers must offer a secure protocol option for their service. |
New Appendix with additional requirements for entities using SSL/early TLS, incorporating new migration deadlines for removal of SSL/early TLS.
|
|
Appendix 3
|
New Appendix to incorporate the “Designated Entities Supplemental Validation” (DESV), which was previously a separate document.
|
|
item
|
Description
|
|
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.
|
Clarified that approval of business use is included in the justification.
Removed examples of “insecure” protocols as these may change in accordance with industry standards. |
|
1.3.5 Permit only “established” connections into the network.
|
Updated to clarify intent of requirement rather than use of a particular type of technology.
|
|
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. |
Increased flexibility by including or equivalent functionality as alternative to personal firewall software. Clarified requirement applies to all portable computing devices that connect to the Internet when outside the network and that also access the CDE.
|
|
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.) |
Clarified requirement applies to payment applications.
|
|
3.3Mask 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 |
Updated requirement to clarify that any displays of PAN greater than the first six/last four digits of the PAN requires a legitimate business need. Added guidance on common masking scenarios.
|
|
3.4.d Test Examine a sample of audit logs, including payment application logs, to confirm that PAN is rendered unreadable or is not present in the logs.
|
Updated testing procedure to clarify the examination of audit logs includes payment application logs.
|
|
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. |
Added note to requirement to clarify the requirement applies in addition to all other PCI DSS encryption and key management requirements.
|
|
3.6.1.b Test Observe the procedures for generating keys to verify that strong keys are generated.
|
Updated testing procedure language to clarify testing involves observation of procedures rather than key-generation method itself, as this should not be observable. Added guidance referring to Glossary definition for “Cryptographic Key Generation”
|
|
6.2 Guidance - 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). |
Added clarification to Guidance column that requirement to patch all software includes payment applications.
|
|
6.4.5 Guidance 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.
|
Clarified that change control processes are not limited to patches and software modifications.
|
|
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. |
Clarified that training for developers must be up to date and occur at least annually.
|
|
8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access as follows:
Enabled only during the time period needed and disabled when not in use. Monitored when in use |
Clarified requirement intended for all third parties with remote access, rather than only vendors.lue
|
|
8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.
Note: Multi-factor authentication requires that a minimum of two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication. |
Clarified correct term is multi-factor authentication rather than two-factor authentication, as two or more factors may be used.
|
|
9.1.1 Use either video cameras or access control mechanisms (or both) to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law.
|
Clarified that either video cameras or access controls mechanisms, or both, may be used.
|
|
9.5.1 - TEST Verify that the storage location security is reviewed at least annually to confirm that backup media storage is secure.
|
Combined testing procedures to clarify that assessor verifies the storage location is reviewed at least annually.
|
|
11.2.1 Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify all “high risk” vulnerabilities are resolved in accordance with the entity’s vulnerability ranking (per Requirement 6.1). Scans must be performed by qualified personnel.
|
Clarified that all “high risk” vulnerabilities must be addressed in accordance with the entity’s vulnerability ranking (as defined in Requirement 6.1), and verified by rescans.
|
|
12.6 Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures.
|
Clarified intent of security awareness program is to ensure personnel are aware of the cardholder data security policy and procedures.
|
|
12.8.1 Maintain a list of service providers including a description of the service provided.
|
Clarified that the list of service providers includes a description of the service provided.
|
|
12.10.2 Review and test the plan, including all elements listed in Requirement 12.10.1, at least annually.
|
Clarified that review of the incident response plan encompasses all elements listed in Requirement 12.10.1.
|
|
Item
|
Description
|
|
6.4.4 Removal of test data and accounts from system components before the system becomes active / goes into production.
|
Updated requirement to align with testing procedure.
|
|
Subject
|
Description
|
|
1.2.1 Guidance 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. |
Added guidance to clarify intent of requirement.
|
|
1.3 Guidance 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.
|
Added guidance to clarify intent of requirement.
|
|
7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
|
Updated requirement, testing procedures and Guidance column to clarify that one or more access control systems may be used.
|
|
8.2.3 Guidance - Strong passwords/passphrases are the first line of defense into a network since a malicious individual will often first try to find accounts with weak or non- existent passwords. If passwords are short or simple to guess, it is relatively easy for a malicious individual to find these weak accounts and compromise a network under the guise of a valid user ID.
This requirement specifies that a minimum of seven characters and both numeric and alphabetic characters should be used for passwords/ passphrases. For cases where this minimum cannot be met due to technical limitations, entities can use “equivalent strength” to evaluate their alternative. For information on variability and equivalency of password strength (also referred to as entropy) for passwords/passphrases of different formats, refer to industry standards (e.g., the current version of NIST SP 800-63.) |
Updated Guidance column to reflect changing industry standards.
|
|
12.8.2 Guidance The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. The extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.
In conjunction with Requirement 12.9, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service. |
Added guidance that service provider responsibility will depend on the particular service being provided and the agreement between the two parties.
|
|
Value
|
|
|
1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.
|
Removed requirement as intent is addressed via other requirements in 1.2 and 1.3.
|
|
2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure. Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed.
|
Removed note and testing procedures regarding removal of SSL/early TLS and moved to new Appendix A2.
|
|
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. Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be completed. 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 communication |
Removed note and testing procedures regarding removal of SSL/early TLS and moved to new Appendix A2.
|
|
6.5.b Interview a sample of developers to verify that they are knowledgeable in secure coding techniques.
|
Removed Testing Procedure 6.5.b
|
|
11.5.a Verify the use of a change-detection mechanism by observing system settings and monitored files, as well as reviewing results from monitoring activities.
|
Removed “within the cardholder data environment” from testing procedure for consistency with requirement, as requirement may apply to critical systems located outside the designated CDE.
|
|
Item
|
Description
|
|
1.3.4 - 1.3.8
|
Renumbered due to removal of former Requirement 1.3.3.
|
|
3.5.2 – 3.5.4
|
Renumbered due to addition of new Requirement 3.5.1.
|
RSS Feed
