Target Breach – Part II: What Does This Say About The PCI DSS?

As I stated in my previous article Target Breach: What Does This Say About Their QSA?, the more naive questions that inevitably follow a major breach like this revolve around a couple of things:

  1. What good is the PCI Data Security Standard if this kind of thing still happens, and;
  2. What did the QSA do wrong?

Both of these questions are the WRONG questions to ask, and display an ignorance of good security practices, the PCI compliance assessment process, and the intent of the PCI standard itself.

First, the intent of the standard was never to prevent beaches from happening entirely, that’s impossible, so the intent was always to REDUCE the instances of breaches to a point that can be considered ‘best efforts’. Every other standard or security framework out there use phrases like ‘reasonable’ or ‘appropriate’, and make absolutely no effort whatsoever to help you figure out what these things mean in your environment.

PCI went the other way, and explicitly implied (by the very nature of the DSS) that if you implement all of the controls, that the resulting risk reduction was good enough. Not once did they ever say PCI compliance was actual security, and not once did they ever say that you should stop your security program AT compliance. The PCI DSS has always been, and will always BE a minimum set of controls around a single form of data, and should NEVER have been seen as enough security for your business.

So, ANY individual who is surprised when a company that has achieved compliance is breached, should do their homework before pointing fingers. Target was an enormously valuable prize for thieves, and warranted an effort far above anything PCI compliance, or maybe even good security, could have hoped to prevent.

As for the QSA, you just have to look at the assessment process itself to see that the PCI DSS should never be confused with either a comprehensive security framework, or even a reasonable assessment of compliance. Any standard that allows both sampling, AND point-in-time validation, can only ever be seen as scratching the surface, especially with an organisation the size, distribution, and complexity of Target. There is simply far too much that the QSA will not see in a given year to point fingers in that direction.

Sampling is a privilege, not a right, and has to be earned. You start at 100%, and work down from there, and to even allow sampling in the first place, a few things must be in place:

  1. Standardised Builds: Just because every Windows system is built from the same base image (for example), does not mean that all Windows systems can be sampled randomly. Every system function, location, admin team, etc. must be taken into account, and a justifiable cross section of systems included.
  2. Centralised Maintenance/Management: For sampling to be valid, it must be shown that ALL systems in the environment are maintained identically. From patching, to updates, to anything else that affects the ‘like’ systems, uniformity must be demonstrated.
  3. Centralised Monitoring: Unless all systems in the estate where sampling is proposed are monitored centrally, each distinct monitoring unit must be handled separately.

In other words, unless you can show how the systems are configured identically, managed identically, and monitored identically, sampling is not an option. Even with this in place, the potential gaps are significant.

As for the point-in-time aspect, even the cards brands themselves don’t understand that at the time of compliance, the assessment process allows validation evidence that’s 364 days old. There is nothing in the DSS, or any other document produced by the SSC, that states that validation evidence cannot be more than x days/months old.

Instead, it seems to be assumed that the RE-certification process, including evidence gathering, happens in the last few weeks of the compliance cycle. It simply does not work that way. Unless you provide a list of evidence / remediation requirements MONTHS in advance of your client’s compliance deadline, any surprises can either prevent re-compliance, and/or create significant internal re-tasking. So, generally, this will involve collecting evidence 6 months old at a minimum.

A lot can happen in 6 months.

As I stated at the end of my previous blog on the Target breach, the fault – IF there is any – lies with Target stopping their security program at just PCI compliance. If they didn’t stop there, and had gone above and beyond, then it’s just one of those things, hopefully a lesson learned, and we should all focus on something a little more constructive.

Like getting away from the use of credit cards for example…

10 thoughts on “Target Breach – Part II: What Does This Say About The PCI DSS?

  1. The current model for PCI compliance validation is flawed.

    The card brands, in their infinite wisdom, have decided to make everyone on the planet that touches cardholder data follow a very prescriptive set of rules that dictate what controls must be in place. There is very little wiggle room with the rules, and if followed, risk of data breach will be reduced overall.

    What they did not consider was that going about validating compliance should be an oversight mechanism with appropriate checks and balances. They instead created a cottage industry of very competitive assessor company’s, who have in their best interest, the customer’s compliance status. Regardless of the SSC’s AQM efforts, the truth is, that as long as the customer is footing the bill, and can control who assesses them, the customer is ultimately dictating their own compliance status regardless of the effectiveness of their controls.

    The SSC and the card brands must take the following steps in order to make a difference.

    1. PCI QSAC’s must be audited (not assessed) annually, in great detail, for all of their processes, procedures and training. The 2 day training class and associated documents are not enough to validate that all of the required activities are taking place.

    2. Those in scope for PCI assessment must not be allowed to select their own assessors, and ideally, the QSAC should be changed from year to year. Or, the SSC manages all of the QSAs and they fund all activity through a tax to the card brands which they pass along.

    3. You must get out of the one size fits all business. Clearly big box merchants carry significantly more risk than smaller merchants. I am not stating that the bar be lowered for anyone, I am saying that in certain circumstances, it must be raised. Bigger targets (no pun intended) need bigger protection independently validate by someone who has no interest in the outcome.

    • Some good comments and I would agree with your thoughts. However I think the biggest issue would be the implementation of such a system. As a QSA (and someone who worked with Mr Froud), I know how long we both (and still do) spent explaining to clients about the limitations of PCI compliance. Given that we still have very large multinational clients, who after 3 or 4 years of trying are still not PCI compliant, it does really make me wonder about the inherent state of their wider IT security program. I too would have liked to have seen the Council introduce mandatory time limits for any one QSA being the assessor for a client, but client’s love their QSA’s because they know their environment. It is an ongoing struggle…

      • Many thanks Chris, but I feel that if a QSA was doing their job properly, they would be making themselves replaceable (teachers, not auditors). Clients hate changing QSAs because too much of the relevant knowledge goes with them, and the client usually has to start from scratch with the new one. If the assessment process was performed correctly, any QSA can provide almost seamless continuity. In this case, it’s the assessment process more than the standard itself which is to blame.

      • Sometimes you can try to be the teacher, but I would say 8/10 companies don’t care about security.

        All they want is that tick in the compliance checkbox, anything beyond that is uninteresting and unnecessary, thereby ignoring the teacher.

        Which brings us back to the core of the problem.

      • @JH: You’re assuming a uniform quality of QSAs. In my experience a large portion of QSAs are not equipped to perform a PCI assessment, let alone discuss real security. The fault lies more with the quality of the SSC’s training, and the lack of validation guidance for the DSS itself, than it does with organisations not caring.

  2. I also don’t like that ISA can now assess the environment and write ROC. I am An ISA and I don’t think that 2 days of class and very simple exam makes me security pro. ISA is good to have to lieason between QSA and the internal IT group. Not that any of this is related to target, but just another risk that I see.

  3. Good post David, being a QSA myself and having large clients, it will always put you in a position were you can push back, but only so far. Large clients are well aware of the ‘I’ll pull the switch-QSA card’ whenever things get rough, which leaves you with a choice of fighting your client or your boss. There are many QSA’s out there that plainly don’t care or even understand compliance, let alone security, and yet they sign the report in the end feeling good about themselves for making the client happy.

    Is Target happy now?

    Security is about preventing incidents and data loss, the benefit is not clear until something happens. Will Target’s CEO or CFO feel good about themselves with the security budget they sat for 2013? No, they won’t, but will they take the blame? Most likely not…

    I bet the budget for Target’s 2014 security budget will skyrocket though.

    I doubt the QSA intentionally or blatantly left something out of the report or the assessment of Target, compliance is a baseline, and as long as it remains a baseline and allows for compensating controls even for large companies, there will always be holes and gaps.

If you think I'm wrong, please tell me why!

This site uses Akismet to reduce spam. Learn how your comment data is processed.