Archive for October 23rd, 2010


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.


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