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