Category: PCI

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.
    o
  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..

Or perhaps the question should be; “Can’t be bothered to change your QSA?”

Or an even worse scenario; you know you can’t change your QSA because the new one might discover things you’ve been hiding from the last one!

I can almost empathise with the first two, but if it’s the third scenario you deserve the bad things that will happen when you get breached.

The fact is, if you have been working with a good QSA, not one of the challenges I list below will apply to you, Changing QSAs, or even QSA companies will not be an issue. You will have been doing security properly, and not just faking compliance.

Challenges:

A significant number of organisations are faced with at least 1 of these 5 main challenges;

  1. Lack of Continuity – Employee attrition is inevitable. QSAs have historically bounced from one QSA company to the next following the money. Which has been abundant for almost a decade now. This has left many clients in the unfortunate position of having to start all over again with another QSA. Often one who has received little to no hand-over.
    o
  2. Lack of Guidance – This is the QSA’s only real job. Other than writing the second half of the Report on Compliance, ALL of the remediation work belongs to the client. The role of the QSA is to ensure that the client NEVER hits a roadblock. QSAs are supposed to have ‘been-there-done-that’, so “What’s next?” should never be a question the client has to ask.
    o
  3. Inconsistent Opinions – Every security consultant has a different skill-set. Some are network wizards, others know encryption, most should be very familiar with policies and procedures. What happens when your last QSA agreed something that your current QSA won’t accept? Who is accountable for the loss of resource and/or capital cost?
    o
  4. Starting Over Again Every Year – Too many  QSAs are ‘just QSAs‘, with little experience or capability in fitting PCI into sustainable security processes. If your PCI compliance looks like an annual project, it is. Validation of compliance should be a simple process that should fit neatly into your BAU program. If it doesn’t, there’s a very good chance your QSA is at least partially to blame.
    o
  5. Black-Hole Communications – If you expect your QSA to be a project manager, you have completely misunderstood the dynamic. But if you expect them to respond to emails requesting guidance in a timely fashion, you should. A QSA is there to tell you everything you have to do to achieve compliance, that’s their job, they must be readily available.

Mitigation:

OK, so those are all the bad things, how do you fix them? Easy, choose the right QSA in the first place!

Facetious yes, and likely a moot point, but it’s never too late to change:

  1. For Lack of Continuity – All good QSAs have a methodology; Have you seen it? Does you QSA even have one? If the answer is no, you don’t have a good QSA. Continuity is simple, it just requires discipline, and a plan.
    o
  2. For Lack of Guidance – As stated above, this is the QSA’s only purpose, if they can’t provide it, find someone who can. Interview your QSA(s) before letting them onsite, but have your questions prepared. Insist on having access to QSAs suitably qualified in ALL 12 DSS Requirements. You’ll never find this in a single QSA, unless it’s one of the 3 that I know that come close (I’m not one of them).
    o
  3. For Inconsistent Opinions – Agree a process whereby the QSA company accepts mitigation plans or compensating controls, not individual QSAs. Agree, in writing, that ALL QSAs they send will accept a company approved option.
    o
  4. For Starting All Over Again – This is as much your fault as the theirs. If you had a security program in place that appropriately covered your business, PCI would fit into it, not the other way around.
    o
  5. Black-Hole Communications – Vendor Due Diligence + Service Level Agreements + Vendor Management. Period / Full Stop.

Changing QSAs every few years is a best practice, you should ALWAYS want fresh eyes on such a critical process. If changing your QSA is too difficult or inconvenient, it says a lot about both your current QSA, and your organisation’s attitude toward security;

They both leave a lot to be desired.

Here’s some old guidance I threw together a while back; Selecting the Right QSA for Your Business

Like this Article? Don’t forget to subscribe!

In a recent CSO Online article; “The National Retail Federation is dead wrong about PCI“, the author made, in my opinion, one the most reprehensible defences of PCI I’ve ever seen. Even the SSC have not been so bold as to make these kinds of off-the-mark and clearly self-serving assertions.

After an innocuous 2 paragraph preamble, the author(s) state;

“Despite NRF assertions to the contrary, the payment card industry has asserted that their card security standards are voluntary. Merchants have a definite choice if they want to accept credit and debit cards or not. It’s quite safe to say if retail establishments couldn’t accept payment cards; most would see massive sales reductions, and a large number would simply go out of business.“

How can he possibly say that merchants have a choice, when he says it himself that most would see “massive sales reductions”!? Call that a choice!? That’s right up there with ‘face or gut?’!

The fact remains that the card brands STILL have merchants by the short-and-curlies when it comes to non-cash payments. You only have to look at the anti-competition or unfair business practice suits that card brands have had to fight over the years to see how distastefully are their business practices perceived.

And quite frankly, this all shows a complete lack of understanding of the NRF’s main issue; They don’t CARE how they receive payment, payments are NOT core to their business. Being paid for their product / services is.

The author goes on to say;

“Given the significance of payment cards, we would have expected the NRF to be at the forefront of PCI advocacy and compliance. Yet the reality is that they have an extremely disdainful view towards PCI.“

Seriously? Ask me to pick up the cost of fixing your crappy service and I’ll be equally ‘disdainful’. Sod that, I’d be thoroughly pissed-off, but I still wouldn’t have a choice, not if I wanted to stay in business.

The NRF have every right to expect the card brands to do something more appropriate, THEY are the ones providing the service and THEY (and their associated middle-men) are the ones who’ve made billions through merchant transactions over the course of 50+ years.

But it’s the merchants who are the ones who are paying the interchange rates. And it’s the merchants who have to spend billions on infrastructures that do absolutely NOTHING to help them improve their customer’s shopping experience.

Guess who pays for this in the end? Yep, us, the consumers.

As I have written (or at least allude to) many times in the past, the very technology behind payment cards is past its usefulness. Anyone trying to prolong this ancient, inherently insecure, and zero-value-add technology clearly has a vested interest in doing so. Card Brands, Issuers, Acquirers, Payment Service Providers (PSPs), and Terminal Manufacturers are obvious stakeholders. However, QSA companies exist to a large degree on the budgets that PCI compliance extorts. Call them PCI War Profiteers if you wish, I’ve heard worse, and I have also benefited.

In the card brand’s defence, they have done a truly astonishing job over the course of 5 decades in bringing trust into non-cash payments. That’s what their logos are; a symbol of trust. The next generation of payment providers owe them an enormous debt of gratitude. That said, we didn’t keep horses around because we felt sorry for the ferriers, we jumped head first into the automobile.

Mobile phones are now more ubiquitous, and can be infinitely more secure and ‘value-add’ than branded plastic (even while tokenised in ‘[X] Pay’ services). All we need now are the banks to get their acts together and provide the trust and there will be little need for the innumerable middle-men.

Which brings me to my final point on the article; yes the NRF and all other retail associations have the right to be angry, but they have done next to nothing to help themselves. They played a game whose rules were set by the card brands and used none of their extraordinary power and influence to tip the balance in their favour.

For example, I have estimated that the Top 10 retailers in the US alone account for almost 1 TRILLION USD in branded transactions. If we assume an average of 1.75% interchange, that’s 1.75 BILLION in fees the retailers have paid to ‘middle-men’. How much influence would you exert over those middle-men if it was your business?

So in summary;

QSA Companies: Keep your opinions of retail to yourselves, your self-serving diatribes are inappropriate. Serve your clients, don’t brown-nose the brands.

Card Schemes/Issuers/Acquirers: Use your incredible knowledge and combined talent-pool to lead the way in the removal of plastic, and therefore the need for PCI. It’s time to move on.

Retailers: Put aside your differences, stop bitching to the wrong people in the wrong way, and do something useful with your power. Focus on what you WANT, not want you DON’T want.

All of this boils down to one thing; what do consumers want? Most have no idea, but I do, as do thousands of others like me. Ask us.

…and it had better not involve yet another piece of plastic.

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.
    o
  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.
    o
  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.
    o
  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.
    o
  3. Requirement 11.3.4.1 – 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.
    o
  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.
    o
  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.

 

 

First, I have only been ‘doing’ Agile stuff for a little over 2 weeks, so this will be less about project management and more about how achieving PCI compliance should be done. Or or this case, could be done …potentially …unless I’m completely off the mark.

Like any project, PCI is just a whole bunch of action items, assigned to an individual, with a due date. That’s it. Unlike frameworks such as ISO 27001, PCI is written down for you, so it makes sense that a methodology like Agile would be well suited to keep a PCI project moving.

The reason that PCI compliance is so difficult for a lot of organisations, is that regardless of the seeming simplicity, determining what those actions ARE, or which to start first, or even knowing when to stop, can be more of an art form that a science. This is why there are so few good QSAs, as they are the ones who are supposed to be providing the guidance on every question you may have, even before you know enough to ask them.

We’ll leave, budget, resources, and having having management who give a crap aside.

So, if you agree that because the DSS is written down for you that you can determine the list of action items required to validate compliance WELL before you begin, then my theory makes a little more sense.

For example; for every operating system you have, the DSS requirements and the actions items are very clear:

  1. Requirement 2: Have a configuration standard, show evidence that your systems follow it
  2. Requirement 5: Have AV, show evidence that it’s running, or have a compensating control
  3. Requirement 6: Document your vulnerability management process, show evidence that your servers are patched accordingly
  4. Requirement 7: Have some form of LDAP, show evidence that access control lists are enforced accordingly
  5. Requirement 8: Extension of Req 7., show authentication and ID management are enforced
  6. Requirement 10: Turn logging on, demonstrate that your SIEM is reacting accordingly, and that all times are synched
  7. Requirement 11: Have FIM, show that’s running

So for an Agile project, you just create a series of issues in the backlog that correspond to the above, and duplicate EVERY issue for all subsequent operating systems in your environment. Simple huh?

And you don’t need a dedicated project manager, just a scrum master who can run all of the daily stand-ups and bi-weekly / monthly sprints. Of course, getting all of the action items right will take a significant PCI expertise, but once this is done for your environment, there’s really no excuse for a stalled project.

The benefits seem to be;

  1. The level of effort required to achieve compliance is obvious very quickly, so resources can be applied in the most efficient manner
  2. Those not pulling their weight become obvious to everyone from the very first sprint, and a determination of anything from individual employee overload to utter incompetence can be determined
  3. You have to think about PCI in the only way that makes sense, and keeps things moving forward; bite-sized chunks of action items
  4. Workloads can be spread around, with current print tasks reassigned to those with more available time
  5. The process becomes repeatable when every action is recorded during the project’s lifecycle.

Anyone who’s ever seen a PCI project drag on for years, or had people on whom you were dependant make excuse after excuse for months on end, something like Agile could be the edge you’re looking for.

Unless I’ve completely missed the point.