Who’s Responsible In A Breach

Based on comments I get from readers and clients, it seems everyone wants a scapegoat for their own shortcomings.  Whether it is Heartland’s CEO blaming their QSA for their cardholder data breach, it seems that a lot of people want anyone but themselves to take the heat for their mistakes.  Now before you all flame me, I am not saying that QSAs do not have a responsibility in a breach.  All I am saying is that QSAs typically have very little involvement in breaches.

Unfortunately, the card brands have not helped the situation.  The card brands approach to breaches boarders on childlike.  In their view, it is everyone’s fault – the organization that was breached, the QSA, anyone except, of course, the card brands.  After all, according to the card brands, they are the victim in a breach, never mind the fact that the card brands created the problem.  So they should really get off their high horse and fix the problem.

Much to the chagrin of most people, organizations do not get breached because of their QSA.  Regardless of whether a QSA is “bad” or “good”, no QSA can ensure that an organization will not be breached.  That is because a QSA is only assessing that an organization is following the requirements specified in the PCI DSS as of the point in time that the QSA conducts their assessment.  A QSA does not “live” with the organization 24x7x365 as that would be too costly and unproductive.  As a result, the QSA can only observe and evaluate an organization’s documentation and procedures as of the point in time of their assessment.  We do what we can to determine if there are gaps in coverage, but we do not have the time or budget to check every transaction, change or server to ensure that it is always compliant.

QSAs have to rely on the concept of reasonable assurance.  I discussed this concept earlier, so I will not bore you with the details contained in that entry.  In a nutshell, QSAs can only look at what has occurred in the past.  Changes such as those to procedures, technology, and people performing the procedures all occur over any given period of time.  Any of these changes can result in a gap in security.  And just because an organization has operated properly and securely in the past, does not mean that the same organization will continue to operate properly and securely going into the future.  Organizations are run by humans after all, and humans have a tendency to get sloppy over time in the execution of their duties.  In the end, there is too much outside of a QSA’s control to even think that they have a responsibility in a breach.

This leads me to the security problem that we seem to want to deny or at least underestimate.  That problem is our employees and they can be our worst enemy.  Go back and re-read the various reports on data breaches and you will see that the majority of breaches were all the result of people being human and fallible.  Whether it is the end user “borrowing” their computer account to someone, someone losing their laptop, tape or a CD/DVD, or a network engineer making a “minor” change to a firewall rule, if people are not following the rules, breaches can ultimately occur.

Some of these issues can be addressed by checklists, rigid change controls and management enforcing those checklists and controls.  Other problems need to be addressed by education and re-education of personnel.  But at the end of the day, it is not the QSA’s responsibility to address these problems; it is the organization’s management’s responsibility to address these problems.  It is management’s responsibility to ensure that appropriate controls are implemented and maintained and that includes management following up to ensure that the controls are effective.  Your QSA can only confirm that those controls have been appropriately implemented and maintained.  Your QSA can provide management feedback on the appropriateness of the controls, but the QSA is not responsible for ensuring that any recommendations on changes to controls are implemented.  Changes to controls and the proper functioning of those controls are the responsibility of an organization’s management not their QSA or anyone else.

If a QSA misses a reportable condition, then that is the QSA’s fault and the QSA needs to accept that responsibility.  If that condition results in a breach, then it is up to the courts to determine whether or not that condition could have been reasonably discovered by the QSA given the scope of the assessment, the documentation provided to the QSA, the cooperation of the client and other factors related to the assessment.

However, no QSA is responsible for a client that made a decision to change their control environment such that it opened a huge security hole.  That is the client’s responsibility, not the QSA’s.  And this my friends is what unfortunately causes the majority of breaches.  There is very little any QSA can do to stop this situation.


8 Responses to “Who’s Responsible In A Breach”

  1. October 27, 2010 at 3:10 PM

    One assumption that needs to be stressed: Breaches and/or security incidents will always happen. No one can guarantee they will not. A sub-assumption: PCI won’t guarantee you anything.

    Second assumption: Humans will pass the blame and avoid penalty whenever possible. At least in the US, this is our culture now.

    These two assumptions alone result in having no real answer. Breaches will happen, blame will be passed, until such time as a perfect solution is offered, which is not possible. The best we can hope for is a strong definition and observation on what is negligent or not.


    A quick 2 analogies: A candy bar is sitting on the counter and it is conveniently easy to snatch and run. Just because it was made an easier opportunity, does that lessen my theft if I take it and run? For insurance reasons, probably. For law reasons, probably not. What we’re probably talking about here is the insurance/penalty/monetary issues, and not the criminal ones. Then again, if I sell alcohol to a minor, does it matter that I made no effort or every effort to prevent it? Who gets in the most trouble?

    Third assumption: Criminal responsibility can be different from negligence.

    I’m not sure there is any one rule-of-thumb someone can go by for laying blame for a breach. I think it ends up being very situational, and it will vary on where the weak point(s) lay.

    most responsible: the criminal, when there is one
    next: leadership of the breached entity
    next: any employees involved in allowing the breach to happen (when negligent)
    next: card companies (and/or others in the event chain) for not having a more robust solution
    next: 3rd parties (QSAs) and those who have limited oversight into preventing negligence

    This is a really quick dump of thoughts for a discussion that certainly should be best had in person with several persons over beers. 🙂

  2. 2 David Griffiths
    October 26, 2010 at 4:05 AM

    Remarkable. Organisations make mistakes and QSAs shouldn’t be held responsible for them. I completely agree! Maintaining compliance is not a trivial task: it demands a considerable amount of effort, and even a small slip-up can have devastating effects. It would appear, and I agree, that our employees are our worst enemies, because collectively they will always tend towards the path of least resistance. We are told that the majority of breaches were the result of people being human and fallible. But being human and fallible is a good thing! Being human and fallible is what makes us what we are, and we are not machines! What the human and fallible employees are actually doing is rationalising and simplifying complex processes, which in a different environment would be seen as a mechanism for delivering productivity benefits.

    I am a firm believer in allowing humans to do what humans do best, and allowing machines to do the rest. Humans will always find shortcuts; machines will always follow processes to the letter. I am also a firm believer in developing systems that play to the strengths of the participants rather than the weaknesses. Impose a highly structured working environment on a human, and it will need to be supplemented by an ever-growing number of “checklists, rigid change controls and management enforcing those checklists and controls”. The control process then becomes a set of processes and procedures that in turn demands a higher level of control and enforcement. At some point, it will slip, so why set about building a process that includes built-in failure from the start?

    The PCI processes clearly do not work, or we would not be watching breaches in organisations that have been certified. We can argue all we like that it’s because people aren’t following the procedures or processes, but isn’t it really because we are attempting to deliver procedures and processes that are inappropriate for the job? We are, after all, attempting to secure data that exists in the real world in the clear! The real problem isn’t the fact that people are not good at following procedures and processes; the problem is that the procedures and processes are not appropriate. The human-ness and infallibility of the human is a smokescreen!

    One of the benefits of EMV is the fact that transaction decisions are taken away from the human participants and are handed off to the technology. This means that the 15-year old Saturday girl isn’t expected to take responsibility for cardholder authentication, or for retaining cards where it might be necessary. The technology takes responsibility and if the card status demands action, the issuer is able to de-activate the card remotely. The transaction security is also handled by the technology, leaving the check-out operator to attend to the customer. Since EMV data is also transaction specific (ie. it cannot be replayed, reused or rebuilt), the back-end systems do not require heavy-duty security procedures and the human operators can concentrate on delivering transactions and related business benefits.

    No one is at risk of allowing a data breach if there is no data worth breaching!

  3. 3 T. Anne
    October 25, 2010 at 11:32 AM

    To me this sounds like a “don’t blame your QSA” post than a “who is to blame” one… I do agree with you that often everyone just wants to blame someone else instead of accept blame when it’s due. I think more of what has to happen is each party realizing what is their responsibility and that they are liable for errors within their area. I would say the majority most likely lays with the merchant and/or those outsourced to take care of it for the merchant – simply because of human error or cutting corners for cost. But there are also times where the QSA or a third party should accept blame as well. However, in most cases, I would not say it’s the card brand’s issue when a merchant is breached. I think part of the reason for the PCI DSS is because they were tired of being blamed for the merchant leaks and therefore they gave them a set of best practices to help them prevent it going forward.

    Now yes, if the product is weak – then I suppose they could make a stronger product… but they did not create the security programs used by the merchants or banks, they did not set up the processing stations and leave data unencrypted or out in the open and easy for the taking. If one of their databases were hacked with all their customer details in it, then yes – I would say they are to blame… but to my knowledge that hasn’t happened. They are have shown us card data can be kept secure – it’s the others who accept the cards for transactions that are not handling the data they have been entrusted with with care. If you lend me some fireworks and I light one and it blows up in my hand and burns me – that is not your fault for not putting a safety on it or not teaching me about the fireworks… it’s my fault. Same as if I were to put the fireworks in an old shed and they somehow caught on fire… again, not your fault – mine… now if I had them secured and safe and someone broke in, went through my security measures, and torched the place by lighting the fireworks anyway – they are to blame. I believe the same can be said payment card data. In this case, you would be the card brand, I would be the merchant, and the person who broke in would be the hackers… If you and I are secure and they find a way around it – why are we to blame… shouldn’t legal action be taken against those who broke the law? Wouldn’t someone trespassing who commits arson be charged? Why aren’t more of those who do the same thing on the internet not charged?

    My point here is that yes – sometimes it’s the merchant’s fault, sometimes the QSA, sometimes a third party, even sometimes the bank… But when all parties involved have taken the necessary precautions to make the information reasonably safe from harm – ie untouchable without great, intentional effort on someone else’s part – why should they be to blame when someone else breaks in and takes what is not theirs? No it’s not the QSA’s fault, but is it really anyone else’s other than the thief? If everyone had their security measures in place (and not the bare minimum) it would be very difficult for them to be hacked – and blaming them for doing the best possible is not the correct answer either. Just because it’s not your fault, doesn’t automatically make it mine. I think it’s important for everyone to remember how many different parties are involved here – and start taking action against those who are truly responsible. We would if they did it in person, we just have to learn how to when it’s done online.

    • October 26, 2010 at 5:24 PM

      So, all of you that think my position is wrong, let me phrase it another way. You are the VP of Warehousing. The VP of Marketing places an order for a million “widgets” for the Christmas season that end up not being the hot seller for the season. As a result of this blunder, you are fired since you were responsible for storing the “widgets” but the VP of Marketing’s gets to keep his job.

      I agree with all of you saying that everyone can have a hand in a breach. However, the statistics do not support that the QSAs have a whole lot to do with a breach. Breaches are predominately caused by changes in the organization’s control environment or by human errors. How can a QSA be responsible for those issues when they are almost always not involved in the decisions nor are they even around when the changes and errors occur? That’s like saying it’s your doctor’s fault that you had a heart attack if all of your heart tests come back without any issues. Yes, you can sue your doctor, but what should your doctor have done? Cut you open to make sure? Not going to happen. QSA s can only do so much under the budget and time constraints that clients impose. Maybe you would all prefer that the PCI SSC mandate that a QSA be on-site 24x7x365 and must approve every change and review every procedure performed.

      In addition, to make any particular party the only party that has responsibility is what I am arguing against. As a QSA it seems that a lot of our clients want their QSA to be responsible for all of their mistakes as well as any of our own. That is what I don’t agree with and want people to recognize.

      • 5 T. Anne
        October 27, 2010 at 10:05 AM

        I don’t see where either of us saying that QSAs were often to blame. I did say that there are times where they may be – as did you in the article.

        As for the widget example… I’m not sure you’d be fired for storing them – and if you had proof that it was not your call to purchase that amount, and they fired you anyways – without anything else backing it up, there’d be a legal issue there. Unless you were told to do something that was against policy and you did it anyways – I don’t see how it could come back to burn you.

        I do not think that the PCI DSS is a process that doesn’t work as David suggests. There are plenty of statistics proving how the standards limit people’s chance of breach. I think it’s important to remember that just because you were compliant when checked – doesn’t mean you were compliant at the time of the breach. So saying that the PCI DSS doesn’t work because of those compliant that were breached is wrong – they weren’t compliant. If I remember correctly – according to Verizon’s study, only 22% of those deamed compliant were actually compliant at the time of their IROC. I may jump through hoops to get things to look just perfect for the QSA to say I’m compliant, but as soon as they’re out the door the smoke and mirrors go away and normal processing comes back and I’m at risk because I’m NOT compliant. Unless compliance is a daily thing – continuous instead of a point-in-time check list, you are not very safe. And that’s not because of the PCI DSS, it’s because the company does not take the requirements seriously or thinks it can’t happen to them so why bother.

        I think the recent arrests against the money-mules and people involved in taking the funds show that we’re headed in the right direction and finally going to take action and point blame to other parties involved.

        I do agree – that’s it’s not just one party to blame… but if I am super lax in my security and someone takes advantage of it… in some ways I think that’s more my fault for the low hanging fruit than it is their’s for taking it. And if a QSA signed off on it – without me making it look like I was compliant, while they’re not to blame for the breach – they should be blamed for saying I’m compliant when I’m not.

        In reality – I can think of very few reasons why I would think any blame would go to the QSA (unless they were being lax in their check list or knowingly passing someone who shouldn’t). But I don’t always think it’s the merchant’s fault either – and that was my point. Yes, there are probably more merchants that don’t take it serviously vs QSAs – but for those that do, it’s not right to blame them. Having the same penalties for someone who takes it seriously and works on continuous compliance vs someoen who doesn’t – isn’t right… it gives no motive for merchants to really try. So unless upper management realizes the ROI on compliance, then why would they bother?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

October 2010

%d bloggers like this: