By Mark Hofman, CTO Shearwater
As you may be aware the security issues relating to SSL and early TLS prompted the Payment Card Industry Security Standards Council (PCI SSC) to issue a new version of the Payment Card Industry Data Security Standard (PCI DSS) and supporting documents. This release v3.1 (April 2015) included a deadline for moving away from SSL and early TLS by June 30, 2016.
After the release of version 3.1 of the standard, the industry as a whole provided feedback to the council regarding the deadline of this particular requirement and late 2015 the deadline for removal of these protocols was extended to June 2018. The council has now formalised this in a new version of the standard. There are however a number of other changes that have been introduced in this new version that you should be aware of and that will affect your compliance requirements, especially for service providers.
The new release of the standard is effective immediately, version 3.1 will be retired October 31, 2016. This means that your next assessment will likely be against the new version of the standard.
The new version of the standard has a number of new requirements. These are considered best practice until 1 February 2018, which means that you are encouraged to implement them as soon as possible, but they must be in place by the deadline. For those of you still using SSL or early TLS, there are a number of new requirements outlined in appendix 2 of the standard that must be in place, effective by June 30, 2016. Most of you will already have these, with the possible exception the requirement to have “All service providers must provide a secure service offering by June 30, 2016”. This particular requirement recognises that many service providers have customers that may not be able to change their systems to remove the weak protocols by June 30, but ensures that service providers have the capability to accept the stronger protocols. This should only affect you if you have systems that cannot communicate using TLS v1.1 or preferably TLS v1.2.
The highlights of the changes are as follows:
- 3.5.1 – Maintain a documented description of the cryptographic architecture.
This applies to service providers only and is something Shearwater has been encouraging clients to do for a while now. The requirement outlines what information is required.
- 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.
Whilst this was always implied in the standard this version calls it out as a specific activity and is designed to ensure PCI DSS compliance is part of BAU rather than an annual activity. For the majority of you this will be an additional step in the change control process, however it will now be an auditable event. The guidance for the requirement provides information on what is expected for this control.
- 10.8 – Implement a process for the timely detection and reporting of failures of critical security control systems
This relates to reporting of failures within the organisation. There must be processes place to detect failures with security controls and processes to address them. Similar to an incident response plan.
- 18.104.22.168 – 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.
This testing can be done by qualified internal resources or a qualified third party.
- 12.4 – Additional requirement for service providers only: Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program.
Most will already have this, but the standard is now enforcing it. PCI compliance must now be assigned to a specific role.
- 12.11 – Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures.
This requirement again goes towards ensuring PCI DSS compliance is an ongoing process rather than a once per year activity. Many of you will have this already. It basically requires you to have processes in place that once per quarter validates that daily tasks etc. are being performed.
Two new appendices are in place. Appendix 2 as mentioned previously outlines the SSL and weak TLS requirements. The final appendix addresses requirements for those that are explicitly told they must do this. This is based on volume and other criteria.
A few requirements have been removed as the item was generally already covered by another requirement.
The only other requirement that could have a significant impact is the changes to requirement 8.3. this requirement currently requires two-factor (now changed to multi-factor) authentication when administering the Cardholder Data Environment (CDE) remotely. This has now been changed that ALL administrative access must be multifactor authentication. This could be any form of multifactor authentication, but potentially this will have an impact on how you manage the CDE and CDE components.
Other changes in the standard are cosmetic. Clarifications for a number of requirements are provided, some dated examples are removed. The council’s “Summary of changes document from PCI DSS version 3.1 to 3.2” (https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2_Summary_of_Changes.pdf) outlines all of the changes.
It is recommended that you have a read of the summary of changes document. As always should you have any further questions feel free to reach out to your Shearwater contact, or directly to myself. We can certainly help you navigate the requirements.