OVERVIEW
In April 2016, Version 3.2 of the Payment Card Industry Data Security Standard (PCI DSS) was released. This new version of the standard contains a number of new requirements which come into full force as of 1 February 2018. This document provides an overview of what is new in Version 3.2, separated by:
- Clarification of requirements that came into force for all Version 3.2 reports.
- New requirements that come into force for all parties (merchants and service providers) as of 1 February 2018.
- New requirements that come into force for service providers only as of 1 February 2018.
- Sunset date for SSL and Early TLS.
This document summarises what Confide has seen from assessments undertaken since Version 3.2 was released and the information that has been provided by the PCI Security Standards Council.
1. CLARIFICATION (APPLICABLE FOR ALL 3.2 REPORTS)
1.1.6.a: Identify the firewall and router configuration standards document(s) reviewed to verify the document(s) contain a list of all services protocols, and ports necessary, including a business justification and approval for each.
These approvals should be granted by someone other than a person who is responsible for managing the configuration. For example, this might include a Security Officer or other role who is responsible for overseeing the PCI DSS process internally, or by someone outside of the standard team of people who are responsible for performing the day to day management of network devices.
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.
The requirement for developer training is not new. However, in Version 3.2, it was clarified that this training must take place for all developers at least annually. We also recommend that testers attend this training as well to ensure that they are adequately equipped to test for basic security vulnerabilities.
11.3.4.c: Verify that the [segmentation penetration test] was performed by a qualified internal resource or qualified external third party, and if applicable, the organisational independence of the tester exists (not required to be a QSA or ASV).
The requirement for segmentation testing is not new. However, in Version 3.2, a clarification was made that brings the requirement for how segmentation penetration testing into line with the requirements for internal and external penetration testing. The person performing the segmentation testing must be either a qualified internal resource or external third party, and there must be sufficient organisational independence (e.g. the penetration testing should not be done by individuals who are responsible for the day to day management of the systems or who report directly to staff who are responsible for these teams).
12.3.3: Verify that the usage policies define:
- A list of all critical devices, and
- A list of personnel authorised to use the devices
The wording of this requirement has been adjusted to ensure that it is clear that the usage policies must include both a list of the critical devices in the environment and a list of the personnel authorised to use the devices. This needs to be documented and cannot be considered “self-documenting” as part of a system such as Active Directory or LDAP.
2. NEW REQUIREMENTS FOR ALL PARTIES (AS OF 1 FEBRUARY 2018)
There are several new requirements that come into force for both merchants and service providers.
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.
To ensure that this requirement is met, Confide recommends that a clear definition of what constitutes a “significant change” be defined within the processes so that it is possible for staff to identify when this level of review is required. While the PCI Council does not provide a definitive definition of what constitutes a significant change, guidance from Requirement 11.2 suggests this includes (but is not limited to):
- New system component installations
- Changes in network topology
- Firewall rule modifications
- Product upgrades
- Operating system upgrades
- Sub-networks being added to the environment
- New web servers
Once significant changes have been defined, we recommend developing a set of templates for reviewing the relevant PCI DSS requirements to ensure that both (1) the relevant requirements have been put in place prior to the system going live, and (2) sufficient testing has been done to meet the requirements for PCI DSS (e.g. penetration testing, vulnerability scanning, etc.) Incorporating this into the change control process is one option.
8.3.1: Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
The PCI Security Standards Council recently published a guidance document on what constitutes multi-factor authentication (see: https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf).
In this document they provide a number of examples of what does and does not constitute multi-factor authentication and where multi-factor can be placed in the environment. We also recommend reviewing the PCI Security Standards Council’s guidance on Segmentation and Scoping (see:https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf) as the way that multi-factor is implemented may be influenced by how you have decided to segment the environment.
3. NEW SERVICE PROVIDER REQUIREMENTS (AS OF 1 FEBRUARY 2018)
These new requirements are currently only applicable to service providers. As defined by the PCI DSS, a service provider is any business that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another organisation, or that otherwise impacts the security of cardholder data.
3.5.1: 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
While policies and procedures for key management and the management of encryption devices has long been required, this requirement set out a new level of detail that must be documented around how cardholder data is protected. In part, this also helps the organisation to keep up with evolving threats to the architecture, and to be able to detect lost or missing keys or associated devices.
10.8: 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)
This requirement is aimed at addressing the increased threat of intrusions going undetected for an extended amount of time. In order to ensure that there is a timely process for detecting failures in place, this requires a proactive process to be in place. There is not yet any clear guidance on what constitutes a timely manner. However, automated tools are likely to make this task significantly easier.
10.8.1: 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.
While this requirement relates directly to the incidents identified in Requirement 10.8, this requirement relates to the incident management procedures and extends the procedures in the event that a critical security control fails. Due to the newness of this requirement and the extensive reporting requirements that go along with it, we recommend that this process is tested as part of the process development to ensure that the processes can be embedded within the incident processes for the organisation.
11.3.4.1: 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.
While this is a new requirement, it extends the exiting requirement for organisations that use segmentation to test the effectiveness of that segmentation. This new requirement increases the frequency with which service providers must perform this testing. While there is no requirement for the testing to be done by an external, third party, any internal party must be both (1) able to demonstrate that they are appropriately qualified to perform the testing, and (2) that they are organisationally independent.
12.4.1: 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.
The remaining new requirements are focused on the overarching governance processes to help ensure that PCI DSS is not treated as a point-in-time event, but instead is integrated into the BAU processes. As part of that, there needs to be a commitment at the senior level to ensure that PCI DSS is visible at the executive level.
12.11: 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
This requirement and Requirement 12.11.1 help to ensure that processes are regularly reviewed to ensure that they are being followed. While this requirement is not meant to repeat the testing from the PCI DSS requirements, understanding the underlying intention of each of these requirements should guide how the review process is carried out. This also helps to ensure that failures in processes can be identified early, so as to minimise the risk to PCI DSS compliance.
12.11.1: Maintain documentation of quarterly review processes to include:
- Documenting results of the reviews
- Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance program.
This requirement ties together the review documentation from Requirement 12.11 and the governance processes from Requirement 12.4, and helps to ensure that there is a clear visibility into how processes that affect PCI DSS compliance are visible to senior management.
4. TLS REQUIREMENTS (1 JULY 2018)
After 30 June 2016, all service providers must offer a secure protocol (e.g. TLS 1.2) as an option.
After 30 June 2018, all merchants and service providers must only use a secure protocol for the transmission of cardholder data (e.g. TLS 1.2) and all insecure versions (e.g. SSL and early TLS) must be disabled.
Prior to 30 June 2018, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
Appendix 2 covers the requirements for SSL / Early TLS.
Given the impending deadline for disabling SSL and Early TLS, we recommend that reviewing the current need for these protocols is done on a more frequent basis to determine if it is possible to disable them prior to the deadline.
