The new version of PCI-DSS 3.2 has just been released, so having been through it with a fine toothcomb here are the most noteworthy changes, additions and clarifications, in the order in which they appear in the report. This new standard 3.2 is due to become fully operational in October of this year so you’ve got a few months to take on these changes and make sure you’re compliant.
Clarified relationship between PCI and PA-DSS applications
‘Added guidance that security threats are constantly evolving, and payment applications that are not supported by the vendor may not offer the same level of security as supported version.’
This is not part of the official PCI requirements, rather a new piece of guidance added in the opening sections of the report. Many vendors might use a payment application which is PA-DSS compliant (an appendix to the full PCI-DSS requirements) and here the PCI Council are pointing out that this alone is not sufficient to meet the PCI requirements, as this application must also be configured within a PCI-DSS compliant environment.
Updating of SSL and TLS (Appendix A2)
In December of last year the PCI Council released an advisory about the phasing out of SSL and early TLS protocols in order to improve encryption security measures. This is particularly important in light of the serious vulnerabilities uncovered in the last couple of years such as HeartBleed and POODLE. While this was given with a far off deadline of June 2018, it has been included as an appendix to version 3.2 of the requirements and is linked to several aspects of them, namely:
Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.
Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
The PCI Council has urged that these protocols should not be used in any new builds and must be phased out as soon as possible.
Clarified scope of PCI requirements
Also included in the introductory sections of the new report is a piece about the scope of the PCI requirements and an emphasis that they apply to all systems and connected systems which cardholder data passes through. Before a PCI audit is carried out companies are usually required to document all the areas of their network which should be subject to the inspection so this item reinforces the extent to which they must document their systems and processes.
Listed in particular as also being subject to PCI compliance are authentication servers, segmentation mechanisms such as firewalls, virtualization components such as VMs, all server types, all applications whether purchased or custom built and any other components or devices.
Now we move on to the actual changes made to the requirements themselves.
Documenting of cryptographic architecture (3.5.1)
This is a completely new requirement, added to 3.5 which concerns the protection of cryptographic keys. 3.5.1 is required only of service providers and asks them to maintain documentation of the cryptographic architecture they have in place. This includes details of the algorithms, protocols and keys used, description of each keys usage and when it expires and creating an inventory of HSMs and SCDs used for managing the keys.
This new requirement comes into effect at the end of January 2018, after which it will be mandatory.
Clarification of patching requirements for vulnerability management (6.2)
Requirement 6 is usually the one of most interest to cybersecurity staff as it concerns vulnerability management. An update has been made to point 6.2, which requires critical security patches to be applied within one month of release. The update made stresses that this applies also to any payment applications, both PCI approved or otherwise.
Removal of test data in production (6.4.4)
This requirement was already in place but has been updated to clarify that prior to entering production phase, all test data and accounts must be completely removed from the system. The guidance notes explain that this is to prevent anyone accessing the data from being able to gain intelligence about how the application works.
Below follow the most significant changes and additions to the regulations.
Change Control Processes (6.4.6)
This new requirement, 6.4.6 has been added to highlight the importance of constant maintenance of security measures in order to remain PCI DSS compliant. It requires entities to reassess and document the changes, check their configurations and update documentation such as network diagrams. It also mentions the importance of making sure any new additions such as new hardware and applications be subject to regular security testing such as monthly vulnerability scanning. They describe this as a ‘change management process’ and the requirement to perform these becomes mandatory in January 2018.
Expanded Multi-Factor Identification Requirements (8.3)
The reasons for this one are quite apparent. Requirement 8.3 was an existing point regarding access to the Cardholder Data Environment, and used to state that two factor authentication was required. This has now been reworded to say ‘multi-factor authentication’ and has been expanded to include points 8.3.1 and 8.3.2. The crux of this lengthy addition is that anyone accessing a point which would allow them access to the cardholder data must pass a minimum of two stages of authentication to reduce the chance of an attacker gaining entry.
Poor authentication processes are well known to be one of the leading causes of data breaches so the expansion of this requirement comes as no surprise. Its sub-articles go on to detail the exact requirements surrounding the authentication process, including remote access, third parties and any other circumstances where access to the same environment that holds the cardholder data is required.
Service Providers to report failures of critical security control systems (10.8)
This new addition concerns service providers alone, requiring them to report critical security control failures as soon as they occur, to allow action to be taken as soon as possible before an attacker has an opportunity to steal data. The security control measures described include firewalls, IPs, antivirus software, access controls, audit logging mechanisms and segmentation controls.
10.8.1 Also goes into detail of the actions which should be taken when one of these failures occurs including documenting the cause, duration and remediation required, restoring functionality and performing a risk assessment to prevent future occurrences. This basically requires service providers to establish a documented process to be followed in case of these incidents.
Service providers to perform penetration testing on segmentation controls (11.3.4.1)
This is another new addition to the requirements, building on the existing requirement that organizations must annually demonstrate that their segmented environment was successfully isolated. This new point now includes the need for penetration testing of fact, at a minimum of once every six months.
Many of the new requirements become mandatory in either February or June or of 2018 but as they represent best practice in cybersecurity, both the PCI Council and security experts would recommend that the actions are taken sooner.
This new version of PCI DSS will come into force in October this year, replacing version 3.1.
Acunetix v10.5 build 20160504 includes an updated PCI report to reflect the changes implemented in PCI DSS 3.2. Update to the latest build of Acunetix to start checking your systems against the new PCI requirements now. This will ensure you have enough time to take the recommendations before October 2016 when the PCI DSS 3.2 requirements come in full force.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
