Well, here it is, and I just can’t figure out why I’m actually disappointed. I saw the draft, I knew there could be no radical changes, yet somehow I was expecting a little more than this. I guess the phrase; “It is what it is.” is actually appropriate this time, and not just the recourse of people who have neither the vision nor the abilities to make positive change.
In the downloads section is the spreadsheet PCI DSS v3.0 – Mapping to v2.0_v07NOV13.xlsx, which is the final v3.0 standard, mapped back to v2.0 (my mapping, not the SSC’s), with my comments. Help yourself.
For those of you who helped take your organisation through v2.0, and are worried about what v3.0 means to you, don’t be. You may have seen a bunch of articles about how it’s so much more detailed, how it’s going to take longer to assess, or how you should be taking every training course under the sun to get to grips with it. Don’t believe them.
It’s not that different, and if any organisation tries to gouge you for more money off the back of it, fire them. The ONLY reason to accept more services from your security service providers it to meet your BUSINESS goals as dictated by your risk and business continuity management programmes. As I have stated too many times; in terms of a security programme done properly, PCI compliance starts in the wrong place, ends in the wrong place, and is only relevant to cardholder data, which means the rest of your business may left exposed. So if you DO buy more pen testing / scanning / consultancy etc, do so for your business, not for PCI.
The less scrupulous QSAs and QSACs may point to the additional validation effort as a reason for raising their prices, but if they had been doing their jobs properly under v2.0, the difference is minimal. This effort has been required for at least 2 years under the SSC’s RoC scoring mechanism, not to mention the intent of the standard in the first place.
So what this really means to for the next three years is business as usual (BAU). Not the; we’re-doing-the-right-thing-for-our-business BAU, but the; this-is-no-different-so-let’s-ignore-the-opportunity-to-do-the-right-thing-for-our-business BAU. If there is any lesson that has been ignored more than the need to automatically cover compliance in a business-wide security programme, I don’t know what it is.
Service providers, payment gateways, PSPs, and of course, QSAs, all have a vested interest in the status quo when it comes to PCI. Whether it’s for marketing purposes, competitive advantage, or nearly the entire revenue source, PCI now has a life of its own. Given its 3 year life-cycle, and the impossibility of radical changes DURING that cycle, it will never break out of its limitations and be the driver for enterprise-wide good security practices that it could so easily have been.
Just a few small adjustments could have brought it more in line with what every business SHOULD be doing:
- Risk Assessment – Bring it to the very forefront in terms of importance. Instead of shoving down in section 12, the so-called ‘paperwork’ section, it should be a prerequisite to even begin the compliance program. Every known good practice, enterprise-wide, business saving security framework starts with a risk assessment, why not PCI?
- Policies and Procedures – If you don’t know how policies and procedures not only form the foundation upon which any security programme is founded, and how they represent the entire security CULTURE of an organisation, maybe you should consider changing fields.
- Security Awareness Training – Built on the policy and procedure foundation, and represents the single most effective way to reduce risk in ANY organisation. It can also be one of the cheapest.
- Formation of a Governance Committee – This does not have to be the enormously complicated structure it may sound, it can be just one representative from each department meeting on a monthly basis to discuss the business. The business side wants more profits, the technical side wants to help enable that profit. If BOTH sides are made aware of each other’s needs, security will finally be performed appropriately, and not because of some external driver.
- Make the CEO accountable for compliance – I cannot believe this one has never been introduced. It’s the CEO who could solve almost every issue experienced by organisations faced with achieving PCI compliance, yet it’s delegated to the people without either the influence, the budget, and often the expertise to do so. As much as possible in a non-government regulation, make the CEO personally accountable for compliance failures, or don’t be surprised when organisations lie to their assessor to make the whole thing go away.
Except for the last two, these things are IN the standard, and have been from the beginning. All, that needed to be done was increase their importance, provide PROPER guidance related to their position within accepted good security practice frameworks, and let the CEO know that if they fail to provide the correct support for the programme that THEY will be responsible for losing their credit card acceptance ‘privileges’. Maybe that will get their attention.
Gone way over my word limit, so I’ll end with my favourite phrase; Security is not easy, but it CAN be simple.
PCI compliance is no different, not ‘even’ v3.0.