Not feeling very creative today, but luckily the Payment Card Industry can always be relied upon to dish out plenty of blodder.
With a stunning twist, the SCC announced the potential release of the DSS v3.2 as early as March. It was greeted by the industry with a resounding; “Meh”. And quite rightly, have you read the potential changes? They are;
“…evaluating additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE); incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers; clarifying masking criteria for primary account numbers (PAN) when displayed; and including the updated migration dates for SSL/early TLS that were published in December 2015.”
While I understand this is part of their new program to; “…[move] towards a system of smaller, more incremental modifications to address things like the EMV roll-out in the US, rather than larger, wholesale updates.“, when was the last time you saw a large update? You could point to the change from v2.0 to v3.0, but you would only be showing your ignorance of the ‘ROC Reporting Instructions for PCI DSS v2.0’, the incorporation of which accounted for 95% of the difference between the 2 versions (take a look at this if you don’t believe me; PCI DSS v3.0 – Mapping to v2.0_v07NOV13).
But let’s handle each of these ‘changes’ in turn:
- Evaluating additional multi-factor – Note the use of the word ‘evaluating’, meaning nothing will actually change for some time. Is multi-factor auth a good idea for all privileged access? Yes, so let’s hope they actually enforce this one properly.
- Incorporating some of the Designated Entities Supplemental Validation (DESV) – For ALL service providers, or just the ones to whom the DESV already applies? If the former, great, but the DESV is mostly a paperwork and process requirement, not additional controls. Not necessarily a terrible thing, but it depends on which requirements.
- Clarifying masking criteria – This one stumps me, how do you clarify the exposure of ‘first 6 and last 4’ only?
- Migration for SSL and early TLS – For to new date of 2018 to make ANY sense they should have left the requirement for offering TLS 1.2 by 2016, but allowing backwards compatibility until the later date. The way it’s written, merchants don’t even have to offer v1.2 of TLS until 2018 which is absolute nonsense.
The PCI DSS has always been, and will always be entirely inadequate to protect critical data assets, but frankly, what choice do the card brands have? They are fully aware of the inadequacy of their plastic in the face of current payment innovations, and the only saving grace delaying their rapid decline is the ignorance of the end consumer themselves. Henry Ford is often attributed the best phrase that sums this up perfectly; “If I had asked people what they wanted, they would have said faster horses.” The average consumer simply has no idea what could replace plastic, but when they do, the changes will be incredibly fast, and permanent.
The PCI DSS can never change dramatically, or the multi-billions spent on compliance to date would all be thrown away. Every organisation on the planet who is currently compliant (or reporting as such to be more accurate) would have to spend countless more billions to bring themselves up to the new standard. There is no way the card brands would survive the backlash. They have painted themselves into a compliance corner that cannot protect their 50 year old technology from the current threat landscape.
Yes of course implementing the PCI DSS controls on all forms of data is better than doing nothing, but barely, and can never and will never represent real security.