The Evolution of the PCI DSS, From v1.1 to v3.2

In honour of the SSC’s 10th year in power [oops!] business, I thought it would be interesting to run a little retrospective.

On December 15th, 2004, a day that will live in infamy, Visa released the Payment Card Industry Data Security Standard (PCI DSS) v1.0.

~2 years later, the PCI Security Standards Council (SSC) was formed, closely followed by the release of DSS v1.1.

Six iterations later, here we are at v3.2.

To emphasise yet again just how sad I am, I chose to map v1.1 against not just the v3.2 standard itself, but its corresponding Report on Compliance (RoC) Reporting Template . While this seems like an extreme comparison (download it here), I wanted to get the full flavour of just how PCI compliance assessments have evolved in the 10 years since v1.1’s debut.

At first blush, they would appear to be radically different. For a start, v1.1 was just 17 pages long, v3.2 is 139 pages, and the RoC Reporting Template is a whopping 198 pages! But what becomes clear very quickly is that most of the changes are related to assessment guidance, validation guidance, and wave after wave of clarifications.

I mean, seriously, excluding the Bill of Rights the US Constitution has only been amended 17 times in 227 years!

Take Requirement 1.1.1 for example, this is what v3.2 looks like in the v3.2 RoC Reporting Template:

Screen Shot 2016-08-10 at 10.46.04

This is from v1.1:

Screen Shot 2016-08-10 at 10.39.46

Radically different, right?

Not really, everything in 1.1.1.a – 1.1.1.c is validation guidance, nothing more. In other words, if the original v1.1 assessors were doing a good job, this is how they would have assessed their clients back in 2006.

But they weren’t doing a good job. Not even close. Even into v1.2 QSAs were still filling out ‘Yes’ for in-place and ‘No’ for not-in place.

What we have seen from v1.2 onwards is the gradual increase in detail related to the validation that has to be performed. From v2.0, a separate document was provided to QSAs, the ‘ROC Reporting Instructions for PCI DSS v2.0‘ that broke down what was expected during compliance validation.

This was also implemented poorly by a lot of QSA companies, while others were clearly unaware of its very existence.

Roll on DSS v3.0, the version that caused by far the biggest stir in the PCI community since the DSS’s initial release. There were shouts from the merchants that the SSC had just raised the bar to unacceptable heights. There were even complaints from QSAs that the ‘new’ instructions would increase the workload to the point assessments would be unprofitable. And worst of all, the more unscrupulous QSA companies actually raised their prices! Here are my thoughts on those companies; PCI DSS v3.0 – Do NOT Pay More For Your QSA Services!

The fact is that v3.0 was a consolidation of the DSS Requirements and the Reporting Instructions, and little more (detailed mapping here). If the QSAs and the organisations they were assessing had been performing assessments properly, the effects would have been minimal.

How Similar is v1.1 to v3.2?

About 82% according to my calculation. Obviously this is at the overarching control level, not the validation detail. v1.1 had exactly zero guidance in that regard.

Other than some wording and requirement numbering changes the controls have remained remarkably consistent.

…and the ‘major’ changes aren’t really that major. Certainly nothing outside of basic common sense:

  1. Req. 1.1.3  – Cardholder Data Flow Diagrams – [How would you determine scope in the first place?]
  2. Req. 2.4    – Asset Inventory – [Seriously, how could you possibly achieve PCI compliance without one?]
  3. Req. 5.x    – Make sure anti-virus are actively running etc. – [Really!?]
  4. Req. 7.x     – Additional requirements around job classification etc. – [RBAC is RBAC, this should never have needed changing.]
  5. Req. 8.6    – ‘Other’ Authentication Mechanisms – [About time non-password stuff was introduced.]
  6. Req. 9.3    – Physical access based on job function – [As opposed to?]
  7. Req. 9.9     – Protection of Terminals (only affects retail) – [Sigh…]
  8. …etc…

So What Are You Saying?

There are two ways to look at these results:

  1. The main controls of the DSS were correct from the very beginning and there has been no change in either the threat landscape, or security technology; and
  2.  The card schemes do not WANT to make significant changes, because they already consider the controls to be risk reduction enough. Not to mention the poo-storm that would descend on them if they did.

I think we all know that the first option isn’t true, so that leaves the second. And can you really blame them? Besides, what does it really matter, the DSS will never have the opportunity to improve much beyond minor clarifications. Payment cards just don’t have enough life-span to warrant anything else.

Nothing more to add really, now I need to go get a life.

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

PCI DSS v3.2 vs CIS Critical Security Controls v6.0

A few months ago, while incredibly bored, I decided to perform my own mapping of the PCI DSS v3.2 to ISO 27001:2013.

I know what you’re going to say; “You can’t compare the two, one’s a management framework, the other’s a controls-based assessment standard!” I agree with you, however, it IS possible to map PCI’s Control Requirements to the ISO’s Control Objectives.

The DSS did not fare well; PCI DSS v3.2 vs ISO 27001-2013

This is not surprising really, the PCI DSS was never designed to be a security framework. It was designed to reduce the risk of card holder data loss to acceptable levels, and nothing more. Whether or not it has succeeded is a debate for the ages, and any frequent readers of my blog will know where I stand.

This week I found myself bored yet again, so I decided to give the DSS another shot at matching up to an ‘industry-accepted’ standard. This time I chose the CIS Critical Security Controls (CSC) v6.0 which, by definition, should have given the DSS a shot at redeeming itself.

It didn’t; PCI DSS_v3.2 vs CIS Critical Security Controls_v6.0

In the DSS’s defence, this is not a fair apples-to-apples comparison either, for 2 main reasons:

  1. The DSS is not a 100% controls-based standard, the CIS CSC is. The DSS, quite rightly, includes a significant chunk of policy and procedure, only a reverse mapping would give the full picture.
  2. The CIS CSC includes a significant number of technologies ill-suited for all but the most advanced and mature environments. Not to mention those with unlimited budgets. The PCI DSS was written to be understood by as many people, and be as universally affordable, as possible.

That said, we can certainly make some observations that illuminate some of the PCI DSS’s more significant deficiencies:

  1.  Data Protection (CSC 13): 18% coverage – Rather ironic, but the entire raison d’être for the DSS; protection of card holder data, scores the lowest in terms of controls requirements. While CSC 13 does not include as much encryption as the DSS, the lack of Data Loss Prevention (DLP) techniques in the DSS is starkly transparent. The DSS has never even mentioned DLP in the main body, or even alluded to it in the “Scope of PCI DSS Requirements“. Only the Designated Entities Supplemental Validation (DESV) section mentions it, and that only in the Guidance as an option.

  2. Inventory of Authorized and Unauthorized Devices CSC 1 & Software (CSC 2)20% coverage – Asset Management is at the heart of every security program, nothing else can possibly function without it. The requirement for an asset register was not added to the DSS until v3.0. Along with Logging & Monitoring, the PCI minimums related to asset management are the most damaging to the overall program. Automation and alerting are both next to impossible without the baselines the asset register should provide.

  3. Malware Defences (CSC 8): 27% coverage – The DSS focuses almost entirely on anti-malware, and that almost exclusively on Windows. That’s what they mean by “…commonly affected by malicious software” in Requirement 5.1. Base-lining, white-listing, black-listing and so on aren’t featured in the DSS, because with asset management there is no way to track what should and should not be there.

  4. Security Skills Assessment and Appropriate Training to Fill Gaps (CSC 17): 28% coverage – This one is truly unconscionable given the enormous power of education and training. Security Awareness means nothing unless it’s in appropriate context to the individual taking it. One size does not fit all, and PCI would be wise to take note.

Clearly I have a significant bias against the PCI DSS in general, so I would welcome any counter-argument from others who are equally bored.

Now I have to go find something else to do..

PCI DSS v3.2 – What a Difference a ‘Dot’ Makes

In my continuing struggle to prove once and for all that I am the saddest bastard alive, I have spent an inordinate amount of time performing a side-by-side comparison of the PCI DSS changes from v3.1 to v3.2.

Not just the DSS itself, oh no, that would be too simple and nowhere near as pathetic, I have actually taken the Report on Compliance Reporting Templates and compared them instead! All 1,359 lines of it! You can download my initial draft here: PCI DSS v3.1 – v3.2 Mapping of Changes_v160526

Impressed? No, me neither.

Self deprecating humour aside, I actually had a very good reason for this; Only the validation of compliance really matters, the standard itself is not where the rubber meets the road, the RoC Template is. Even the ‘Summary of Changes from PCI DSS Version 3.1 to 3.2‘ cannot match the level of detail you can obtain from comparing the individual ‘Report Findings’.

I have written frequently on the inadequacy of the PCI DSS, so what is my overall opinion of the changes to v3.2? Actually, they are not that bad. I’m not saying the standard is starting to look like real security, but as far as it CAN go, it’s heading on the right direction in terms of how to both validate and report compliance.

Aside from the new requirements (which I address below), to me the biggest change was the significant reduction in the number of Report Findings for which you need to “describe how”. The consolidation of these descriptions puts the onus back on the assessor to properly validate the requirement, instead of having to spell out everything they did to do so.

However, the issue I can see with constant change from version to version is that it becomes next to impossible to even partially automate validation in centralised tool-sets (like GRC) because the RoC Template still focuses more on WHAT is written than HOW to actually perform the validation itself.

So, to the significant changes for everyone:

  1. Requirement 3.3 – Not sure why anyone would want to see any of the ‘middle 6’ digits and not the full PAN, but this requirement now helps to clarify things for those who do. Basically, you need to put the same controls around the middle six as you would the full PAN.
  2. Requirement 6.4.6 – It’s unfortunate that the SSC feels obligated to insist on validation that any changes to the CDE still conform to the PCI DSS, but it would not be have been added if organisations were actually doing it properly.
  3. Requirement 8.3 – Change from 2-Factor Authentication (2FA) to Multi-Factor Authentication (MFA), and now EVERY form of administrative access to systems must be via MFA, not just remote access (this is by far the biggest ‘blanket’ change). This has always been a best practice as far as I’m concerned, and I’m glad that the SSC has finally written this into the standard. If this is difficult for an organisation, or something they want to avoid, I have to wonder what else they don’t have in place.

…and for the poor Service Providers who rightfully bear the brunt of the changes:

  1. Requirement 3.5.1 – SPs must now provide a ‘cryptographic architecture’, but it’s not clear if it’s only to be given to the the QSA validating the SP’s compliance, or if it’s for client consumption as well. Have to assume the former.
  2. Requirement 10.8 – SPs must now detect and report on system failures. How this was not part of every organisation’s vendor due diligence process, and written into every SLA as a matter of course, is beyond me, but I know for a fact this stuff rarely is.
  3. Requirement – SPs must now perform semi-annual penetration testing on segmentation (if applicable). This should not be an issue for Cloud or VM providers IF, and ONLY if, they have configured their service correctly. However, this requirement does not cover those  SPs who have a bunch of servers on flat network and do not care about segmentation, which I would argue is far less secure.
  4. Requirement 12.4 – Pushing SPs to make protection of CHD an Executive responsibility. Unless there are some kind of penalties attached, SPs will pay limited lip-service to this and just write some kind of charter or policy. Smoke and mirrors basically, but good for the SSC for even trying.
  5. Requirement 12.11 – SPs must now perform QUARTERLY audits against several controls, which is a very good thing IF it’s done correctly. To perform this function well, SPs would need to institute some form of Internal Audit function, as well as a Governance-esque function to oversee it. Good luck with that.

So, overall, I’d say this was a pretty good change as the DSS goes, but with another 20 months until any of it is enforced, I sincerely doubt things will change for the better in the short-term.



On the Irrelevance of the PCI DSS

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.
  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.
    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 both 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.
  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.
    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.
  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?
  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.
  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?
  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.
  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).
    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.
  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?
  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.

Will the PCI DSS v3.2 Make Any Difference Whatsoever?

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