PCI DSS v3.0: What It Means To You

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:

  1. 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?
    o
  2. 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.
    o
  3. 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.
    o
  4. 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.
    o
  5. 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.

DSS v3.0

DSS v3.0 – Nothing New, If You Were Already Doing PCI Properly

Now that I’ve had the opportunity to review the full draft standard, it’s clear that there’s very little that’s difficult for you to achieve in the short term if, and I mean IF, you were doing PCI properly from v2.0 onwards. The majority of the changes are simple clarifications, and if your QSA was doing their validation and QA correctly, you would already be doing 99% of them.

That’s really all v3.0 is; a closer approximation to the Report on Compliance (RoC) scoring mechanism that’s been around for years. I understand the clarifications and the guidance are supposed to bring everyone’s understanding of the INTENT of each requirement into closer alignment, but all that does is reflect very badly on the current quality of the QSAs and the available guidance.  The corollary is that the QSA and ISA training needs some serious attention, and the DSS needs to focus less on the detail, and more on the senior management buy-in.

I also understand that it is VERY difficult to make dramatic changes to a standard when organisations have already invested significant capital and resources into achieving compliance. But even the SSC made it VERY clear from the beginning that the DSS was a MINIMUM set of controls around a single form of sensitive data, and should not be seen as a security programme that meets the entire business’s needs (per the PCI DSS v3.0: “PCI DSS comprises a minimum set of requirements for protecting cardholder data…“).

So why aren’t the changes in v3.0 more significant?  Or more in line with good practices?  I don’t really have a constructive (a.k.a. non-soapbox) answer to that, so I’ll focus on what I perceive to be the major flaws.

Here’s my Top 3 Flaws:

Governance:  This has as many definitions as there are people defining it, but in the end it’s very simple; Governance is the Business side and the IT side having conversations.  Business has the requirements (growth, profit, transformation etc.), IT has the enablement, and the organisation as a whole moves forward appropriately. Nothing should happen in an organisation outside of this framework if the business wants to grow/innovate/adapt effectively (for more see Security Core Concept 4: Governance & Change Control and Security Core Concepts: Tying it All Together)

Guess how many times the word ‘Governance’ (or equivalent) appears in v3.0?

Not once.

Risk Assessment (RA): The whole business/IT/security life-cycle starts with a risk assessment.  The business wants something, the RA determines the balance of risk/reward, and you move on to implementation if the balance is favourable.  The DSS calls for a RA, but it’s still woefully understated, and stuck down in the ‘paperwork’ section (Section 12).  This should have been performed even before you chose a QSA, should be intrinsic to services you eventually receive from them, and should have driven all purchase(s) of technology used to achieve both compliance and security in general (for more see Security Core Concept 1: Risk Assessment / Business Impact Analysis).

The Risk Assessment even had its own Special Interest Group (SIG) to improve the quality of the guidance, but the results were so watered down as to be ineffectual.

Sampling: MUCH better explanation than previously, but it’s missing the most important phrase; “There is no sampling in PCI DSS validation unless the client can reasonably demonstrate how all ‘like’ systems are configured and maintained identically, managed and monitored centrally, and are promoted into production through a well defined and documented  process.”

For too long sampling has been seen as a right, it’s not, it’s a privilege (like spandex). Saying “Sampling is an option…” is not enough to avoid clients demanding ‘pragmatism’ from their QSAs in the ‘this-is-too-difficult’ sense of the word.

I have so much more to say, and some of it is actually positive (like pushing policy enforcement validation), but I’ve already overrun my self-imposed word limit.

Finally, every organisation that relies totally on PCI for their security deserves to be hacked – sorry, but you do – but the SSC and the card brands still have an obligation to do more to evolve the standard into something that can be integrated seamlessly into an established, and comprehensive good-security-practice framework.  By the time the DSS catches up with the real world of security, payments will have moved on from payment cards.

Just ask any non-QSA security expert what you should be doing with your IT budget, I’ll bet it’s not PCI compliance.

[If you liked this article, please share! Want more like it, subscribe!]

PCI DSS v3.0 – First Impressions

Have you all seen the ‘sneak peek‘ yet?

I have to admit, that with 3 YEARS to accept and process feedback, I was hoping for a little more in the way of progress.  I’m optimistic that way, but I really should have known better.

Many changes were proposed, lots of the them good, some of them naive and bordering on the comical, but any that made it through are so watered down as to be virtually irrelevant.  And we won’t get any more for 3 more years?

The standard is already behind the times, and is only going to become more so if it does not keep up with payments innovation, and show a better integration with the needs of the business. i.e. STAYING in business.

I have taken the table of changes out of the SSC’s document and added my own thoughts.  Unfortunately they are overwhelmingly negative, and at times my frustration is clear. Go here if you want to download it.

I do however want to make it clear that I’m not against the PCI DSS as much as I appear.  No standard has raised security awareness as much before, or since, and it’s the only one that puts its money where its mouth is.  While there is still some vagueness and room for interpretation, it’s a damned-sight better that just saying ‘use appropriate security based on good practices’ like most do.

The reason I stick to the negative is I’m assuming the positive is self evident, and all I really care about is addressing the gaps to where it should be.  As Ego says in Ratatouille; “In many ways, the work of a critic is easy. We risk very little yet enjoy a position over those who offer up their work and their selves to our judgment. We thrive on negative criticism, which is fun to write and to read. But the bitter truth we critics must face is that, in the grand scheme of things, the average piece of junk is more meaningful than our criticism designating it so.”

This applies every bit as much to my blogs.

I have only addressed the PCI DSS stuff, PA-DSS is not my thing.  If someone wants to take a stab at that, I’ll be happy to post it here as a guest blog.