What impact will the latest version of the PCI DSS have on your organisation?
If you don’t store, process, or transmit payment card information, or provide a service that could impact your clients’ Cardholder Data Environment (Service Provider) [1], very little.
You’re in the clear, feel free to bail out now!
However, if you do, keep reading, I’ll provide you the low-down on what’s changing, along with a few initial pointers on how to work towards sustainable compliance.
It only feels like yesterday, when the first shiny new PCI DSS made its debut, December 15th 2004 to be precise.
12 years on, and we’re on the verge of celebrating (or dreading) the formal release of the latest update - version 3.2.
This isn’t simply the early release of yet another iteration of the standard though, this out-of-band release signifies the evolved maturity of the standard. Essentially, breaking-free from the traditional 3-year release cycle, to which we’ve all become accustomed.
It’s a new beginning, the standard has grown its foliage and, as spring commences, has started to show its early buds. As it grows into a recognised data security standard in its own right.
Do we now have the finished article?
Not at all!
Whilst ever we have payment cards and fraudsters seeking innovative ways of acquiring our assets, we’ll have ever-evolving PCI standards. In recognition of this ‘Way of Attrition’, as the criminals build more sophisticated assault weapons, the standard will react by mandating suitable countermeasures.
From this moment forward new versions will be developed and released as and when required in direct response to the emerging threats. Our friends at the PCI Security Standards Council will monitor the threat landscape, review breach reports, whilst keeping abreast of technology change, and feed the output from these worthy endeavours into future iterations of the standard.
What’s new in 3.2, I hear you shouting?
Here’s a quick summary:
- Two factor authentication is now called multi-factor authentication, it’s no longer only for remote access to the CDE, but all internal access too
- We’re going to be able to see more of the Primary Account Number (PAN) when displayed, if needed
- And the Secure Sockets Layer (SSL) (and early Transport Layer Security (TLS) to not so early TLS (version 1.2 and above) migration deadline is being extended (December 2015 to June 30, 2018)
WARNING: DO NOT USE THIS EXTENSION TO THE DEADLINE AS AN EXCUSE TO PUSH YOUR MIGRATION PROJECT TO THE RIGHT!
What’s the likely impact on your organisation?
It’s not so much the minor changes in version 3.2, but the move away from a three-year release cycle that will have the most noticeable longer term impact. Compliance requirements and the threat landscape are converging, with smaller frequent changes to our control architecture are now the order of the day. With this strategic shift comes a requirement to more quickly adapt to change.
If you’re an agile organisation that’s able to incorporate technology and process changes relatively seamlessly, then you’re in an enviable position, as the new approach is likely to have a lesser impact.
However, if you’re organisational change capability is more akin to the turning circle of an oil tanker, then the change of PCI DSS release frequency might be more challenging.
Here’s a few strategic pointers to take the pain out of maintaining compliance under the new regime:
- First and foremost:
Keep abreast of changes. Make it part of your routine to check for updates. This will keep you ahead of the game, and give you as much time as possible to incorporate any required changes into your environment - Make sure your programme and project lifecycles consider security and compliance at the outset, don’t leave it to the final stages of testing before realising your new web application for processing payments is non-compliant
- Recalibrate your Risk Register; the cost of non-compliance can have significant negative impact on your organisation; factor this in. Unlike some other risks, the likelihood of impact as a result of non-compliance can be confidently predicted (clue; it’s a near certainty). Don’t let the ‘techies’ influence your risk-ratings to get their hands on the latest sexy technology. Regularly review your risk register to ensure compliance efforts are given appropriate priority
- Check-out the latest technologies in areas that can reduce your PCI scope and compliance burden, such as tokenisation and encryption. The less you have to worry about, the less likely you are to suffer as a result of continually changing compliance goalposts
Dates for your calendar:
- April/May 2016 - PCI DSS version 3.2 release date
- May 2016 - PA DSS (Payment Application Data Security Standard) release date
- October 2016 – PCI DSS 3.1 is retired
- February 2018 - Changes introduced in version 3.2 (currently best practices) become requirements
- Today – Start preparing for the new release cycle by embedding security and compliance into your organisation as Business as Usual (BAU) activities
Final Word
The PCI Council’s decision to make incremental changes to the standard in response to shifts in the threat landscape is a step in the right direction. Organisations that adapt and deliver changes in accordance with the standard will almost inevitable be more secure, and be better protected from current and emerging threats.
Think how can I effectively achieve a Business As Usual (BaU) process with the resources that I have available to me?
Are there any tools that can assist me in this goal?
- Scheduling
- Knowledge Transfer
- Automation
- Internal auditing
- Project Management
- QSA assistance
Remember: Take It, Don’t Make It! (unless you absolutely have to).
PCI DSS v3.2 is now live. This includes a 6 month grace period for adoption!!
References
[1] Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).
[2] http://searchsecurity.techtarget.com/feature/The-history-of-the-PCI-DSS-standard-A-visual-timeline
[3] http://blog.pcisecuritystandards.org/preparing-for-pci-dss-32
[4] https://www.nettitude.co.uk/pie-farm-methodology/
To contact Nettitude's editor, please email media@nettitude.com.