Category: Regulatory Compliance

After last week’s blog, where I challenged the relevance of the PCI DSS v3.2 (and basically the relevance of the entire standard itself), I received a number of comments questioning my reasoning. As is always the case, opinions differ, and while I have no intention of trying to change the mind of those who disagree with me, I will at least attempt to put together a more lucid argument around my position. This will consist of a summary of the various points I have made on this topic in numerous blogs over the last 2.5 years.

First though, let me stress that I do not believe the PCI DSS is all bad. I do believe it is managed poorly, and that it in no way represents a valid security program / framework, but in reality, it was never designed as such. It was a minimal set of security controls the cards brands wanted in place around their data in order to keep government regulators off their backs. Basically smoke and mirrors with some minimal risk reduction thrown in for appearances.

These are my Top 10 arguments for the irrelevance of PCI:

  1. 50+ Year Old Technology: You wouldn’t gut-refurbish a house you intend to knock down would you? So why would you spend a fortune on PCI compliance when it’s clear you’ll need whole new payment channels for mobile, the Internet of Things, and whatever comes after that? Cardholder data cannot be protected at a reasonable cost …ever, and as the influence of the card schemes wanes, the thieves will move on to whatever is most popular.
    o
  2. QSA Training: Almost, but not quite, an oxymoron, and one of the biggest reasons PCI became such a waste of time. The requirement for 5 years of security experience on a resume/CV was completely inadequate (and often faked). QSAs needed to be security consultants first and foremost, what we got was a bunch of auditors who completely missed the point. The point should have been that the DSS was a MINIMUM set of controls, and that real security was never to be found in compliance alone. The QSA training is absolutely pitiful.
    o
    Why does no-one question the fact that not one QSA on the planet is an expert in all 12 requirements? Every assessor has skills and weaknesses, yet they are permitted to assess the compliance of all areas. No client wants to pay for TWO assessors, and a minuscule number of QSAs actually sub the validation of their weaker subjects. Why? Because they don’t have to.
    o
  3. Conflict of Interest: There is still a LOT of money in PCI, billions in fact, and there are many QSA companies out there that can credit their entire existence on the back of that money. The competition is fierce, and given the fact that every organisation going through compliance has 100% control over the commercials, means that QSAs have to be extremely ‘pragmatic’. I have personally had organisations tell me that if I did not loosen my interpretation they would find someone who would. They were dumped as clients immediately of course.
    o
    The second conflict of interest is that you can sell your client a firewall [for example], manage it for them, monitor the output, vulnerability scan and penetration test it, AND assess it for compliance. No due diligence required on how you perform checks and balances, all you have to do is be up front about it. Utterly ridiculous.
    o
  4. Risk Assessment: The PCI DSS is the result OF a risk assessment, one performed by the card schemes themselves. That’s what the control requirements ARE! If it was a true risk assessment, the PCI assessment itself would be a choice, not mandatory, and there would exist an ability to accept residual risk. There isn’t. In fact, the only point of the risk assessment in PCI is to decide if you need to go above and beyond, and who in their right mind would do that if they didn’t have to?
    o
  5. Scope: It is the role of any good QSA to help a client reduce the scope of their assessment as much as humanly possible. This makes perfect sense from a risk-to-cardholder-data perspective, but when ALL a client’s focus is on the remaining CDE, the rest of the business suffers. In most organisations personal data is far more prevalent, and with the GDPR looming, a much more sensitive asset. Only an organisation-wide security program makes sense, one that’s in line with business goals, not just a single set of commercial obligations.
    o
  6. Governance: Easy, there isn’t any, and the word does not even appear in the PCI DSS. Not once. How are you supposed to run a risk assessment, determine control implementation in line with business continuity plans AND enforce repeatable processes to keep the controls in place without some form of governance?
    o
  7. Weak Controls: I have covered these ad nauseam; from the continued use of the word ‘periodic’, to lack of management systems framework, to logging and monitoring, the control requirements have always been, and will always be inadequate for real security. Perhaps this wouldn’t be so bad if the SSC didn’t keep saying things like; “[PCI] provides the most complete set of data security standards available globally.”, which in my view is nothing short of irresponsible.
    o
  8. Validation & Sampling: Sampling is supposed to be a privilege, not a right, and sampling starts at 100% until a client has earned a reduction. Systems that are installed the same, kept the same, managed the same, monitored centrally, ALL must be in place before sampling is an option, but try telling a client they must provide 10,000 pieces of evidence to achieve compliance (see 3. Conflict of Interest above).
    o
    Don’t get me started on the annual ‘point-in-time’ aspect. What security standard could possibly accept validation evidence that’s 364 days old? Nothing in the PCI DSS says you can’t.
    o
  9. Disaster Recovery & Business Continuity: These receive the very barest of lip-service, and frankly, even that is none of the card brand’s business. Beyond incident response, a company’s ability to get back online and stay in business is their own affair, so why even put “* Business recovery and continuity procedures” in 12.10.1 if not to create another illusion of best practice?
    o
  10. Threat Landscape: With a 3 year life-cycle and a complete inability to change radically, the PCI DSS is, and will always be inadequate to address current, and especially zero-day, threats. PCI compliance would spit out the back of a security program done well, ‘just compliance’ will always fall well short.

Basically PCI compliance is like being pressured into hiring the CEO’s son, no matter how lazy or incompetent the kid is, you can’t fire them. All you can do is marginalise them so they don’t actually do any real harm.

I have used the phrase “I hate PCI!” for almost 10 years now, and given that PCI has been directly responsible for funding my career, I may seem more than a little ungrateful. But it’s not about hating PCI, or even the SSC, it’s about making those who need help most pause, hopefully laugh, and above all, listen.

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

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:

  1. 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.
    o
  2. 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.
    o
  3.  Clarifying masking criteria – This one stumps me, how do you clarify the exposure of ‘first 6 and last 4’ only?
    o
  4. 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.

You can almost feel it happening, can’t you? Every time there is an introduction of, or a change to some regulation or another, the vultures of the legal, security consulting, and even security product vendors spin up their marketing machines to invent new promises on how they will ‘guide you through the pending minefield’.

The thing is, I in no way blame them. I’ve likened selling security to selling insurance, in that no-one WANTS to buy something that seems to have absolutely no tangible benefit to the bottom line (it does though; How Information Security Enables Transformational Change). This results in a vast majority of organisations taking extreme liberties with the terms ‘reasonable’ and ‘appropriate’, which is as specific as most regulations go in terms of meeting their requirements.

Unfortunately, regulations are written by lawyers, who have a language all of their own. How is an IT Director supposed to translate legal-ese into geek-speak without some help? That’s where a PROPERLY run security program comes in; the translation become almost unnecessary.

I have made statements like this many times; “If an organisation was doing security properly, they would already be [enter regulation name here] compliant.”

Bold statement, but think about it this way:

  1. ALL information security and most compliance regimes relate [at least in part] to the protection of data
  2. The principles of information security have not, and will not ever change
  3. NOT doing these basics is the fault of the organisations, not the regulators (except PCI)

The only thing that’s different from one compliance regime to the next is how you report what you’re doing. PCI requires a very detailed (though mostly meaningless) controls-based Report on Compliance, SoX and HIPAA require something else, and the old Safe Harbor just required a SELF-assessment (and you wonder why it failed…).

Regardless, the underlying validation evidence is the same; policies, procedures, standards, operational integrity, incident response and so on. You are either doing these things or you’re not. And let’s be clear, you should be.

“But they’re moving the goal posts!” is a complaint I frequently hear, and is usually the foundation of an excuse to do nothing. Just because YOU don’t know where the goal posts are doesn’t mean they’ve moved. All that really happened is that every time a regulation comes out and they ask for more and more detail / accountability / transparency etc, it further exposes the fact that you weren’t doing things properly in the first place.

The General Data Protection Directive (GDPR) for example is freaking organisations out with its potentially enormous penalties. Penalties for what? Not using data for its original intent? Not obtaining explicit customer consent? Not LOSING the data in a breach? How is ANY of that unreasonable!?

OK, so the above is a gross simplification of the GDPR, but it’s not far off, and frankly, Privacy Shield will be even easier. If your organisation is not in a position to meet the intent of these data privacy regulations, then you are part of the reason they exist in the first place. And if your security program is in such a state that the vultures have easy picking over the carcass of your IT budget, that’s your fault too.

Non-compliance with any regulatory requirement relevant to data protection is just a symptom of the same underlying problem; a crap security program. Fix that, worry about the reporting afterwards.

In my continuing crusade against greedy and self-serving biometrics vendors – which is absolutely NOT all of them – I figured I would give them a little taste of their own medicine with a ridiculous assertion in the title.

Of course biometrics isn’t dead [I believe it’s still in its infancy] and of course it will only continue to grow in distribution and influence. Its adoption will sky-rocket as mobile devices take over the world and IoT makes thinking for yourself redundant, and I for one am more than happy for it to spend time more in the sun.

What I cannot / will not accept from biometrics:

  1. Its growth at the expense of ANY other form of authentication (without appropriate justification),
    o
  2. Its false and irresponsible claims to its security, and;
    o
  3. Its blatant disregard for its ultimate benefactor; the mobile phone

Put to one side for a minute that not ONE legislation / regulation in payments actually requires biometrics (where “strong authentication” is primarily defined as 2-factor), and focus for a second on how biometrics has even made it as far as it has. Simply put, without the mobile phone, there would BE no biometrics in the mainstream.

It’s not like we would all carry around a separate device to perform biometric authentication, would we? No, we wouldn’t, so it’s only because biometrics is so readily available that we even consider it an alternative to passwords. That’s right, an ALTERNATIVE, and for the foreseeable future, one completely driven by consumer preference. No financial institution in their right mind will make biometrics mandatory, probably ever. I certainly wouldn’t.

So if the mobile phone is so all-powerful, why aren’t they attacking passwords? Simple, a) they have no need to, they are the dominant factor, and b) they are smart enough to realise that without the OTHER two factors they are not providing the best solutions possible.

In other words, they get it.

Rather a bleak picture, isn’t it? 1) not required for regulatory compliance, 2) will never be mandatory, only a consumer preference, 3) will never be suitable for some forms of authentication due to false ‘positives’, and; 4) it completely reliant on something else for its distribution. But even with all of this against it, I will embrace biometrics, in all its forms, if it provides me the convenience I crave, with ENOUGH security to transfer the risk to someone else (my bank for example).

And that’s really what it all boils down to; risk. A simple word but one completely misunderstood, and usually handled poorly. Bottom line; if the effort to steal something is greater than its value, it’s safe …enough. That’s all biometrics and passwords provide; security enough, and the amount of security you have to provide for a transaction is directly proportional to the value of the transaction.

For example, why would you use Apple Pay when it requires authentication that the contactless card does not? Is it more convenient? No. Does it provide more value-add services? No. Does it have anywhere near the distribution of plastic? No. Do YOU have to care about the security of contactless? No, you don’t.

Biometrics is, and will always be only a player in the game. While mobile holds most of the cards, any form of biometrics will be beholden to it, so they should play nice.

In a recent article in SC Magazine; “An Inconvenient Truth: New Customer Data Regulations Coming” Jeremy King of the SSC suggests that Payment Card Industry (PCI) “provides the most complete set of data security standards available globally.” I can only assume he means that the PCI Data Security Standard (DSS) contains a list of basic security controls every organisation should have in place, and not that the PCI DSS in any way resembles real-world security.

Because it doesn’t, and you only have to look at the number of breaches involving ‘PCI compliant’ merchants and service providers to see that PCI, by itself, does little to prepare organisations against the challenges they face.

PCI compliance is a commercial obligation, nothing more, and any fines levied are only paid because the merchant or service provider who was breached wants to keep taking plastic. The Payments Services Directive 2 (PSD2) and the General Data Protection Regulation (GDPR) will be LAW in the 28 countries of the EU, and attract both legal and financial repercussions that could potentially cripple even the largest of businesses. No standard based on a bare minimum set of controls will ever protect personal data in a meaningful way.

Nor will any ISO standard, or COBIT, or any other information security framework for that matter. At least the PCI DSS puts its money where its mouth is and tells you what controls to implement, all security frameworks do is tell you something is a good idea, never how to do it a manner appropriate to your business.

Because they can’t, only the individual organisation can ever provide definition, and business justification, around the horribly inexact – but regulation standard – phrases; ‘appropriate’ and/or ‘reasonable security’.

The implementation of a security program that can meet the intent of ANY regulation includes very specific processes that the PCI DSS does not cover, and if they do, it’s in a very limited fashion with no-where near the emphasis required to express the importance. For example;

  1. The Risk Assessment (RA) is way down in section 12, when it should have been the very first thing performed before PCI compliance was even contemplated. An RA performed in-line with the PCI DSS would not be sufficient.
  2. The only nod to Disaster Recovery and Business Continuity Planning is a single bullet in 12.10.1, when these processes are absolutely central to any organisation staying in business responsibly.
  3. The requirements related to 3rd party due diligence are entirely inadequate relative to the risk involved.

…and so on. I have addressed the inadequacy of the actual PCI controls many times, so I won’t bother repeating them here. Suffice to say, the majority of the controls would be no-where near enough.

There are only 3 main ways to appropriately address the current and new tranche of regulations / directives:

  1. Make the CEO legally responsible for security breaches, and apply criminal penalties in-line with the egregiousness of the negligence – Clearly fines don’t worry CEOs enough, perhaps some jail time would.
  2. Ensure the policies, procedures, and standards are world-class – There is no security program without the application of accurate corporate knowledge
  3. Training & Education – This should be self-explanatory

Compliance with any of the upcoming regulations is no different from any regulation already in place. There is nothing outside of an appropriate security program that will ever be required, so just do the things you should have been doing from the very beginning.

Security is not easy, but it IS simple.