Hot off the presses. The PCI SSC’s Web site sports a new look and feel with the release of these new standards. Go to their Web site to download the new standards as well as updated supporting documents such as the Glossary and Summary of Changes.
Update: For a great review of the changes in PCI DSS v2.0, see Walt Conway’s analysis over at Store Front Back Talk.
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.
Long live SSAE 16 and ISAE 3402!
One of the most misunderstood things about SAS 70 was the fact that it was technically only a valid auditing standard in the United States, even though SAS 70 reports are done for non-US based service providers and are relied upon by businesses and auditors worldwide. However, on or before June 15, 2011, that will change. As of that date, Statement on Standards for Attestation Engagements (SSAE) 16 and International Standards on Attestation Engagements (ISAE) 3402 will replace the venerable SAS 70. SSAE 16 is issued by the American Institute of Certified Public Accountants (AICPA) and ISAE 3402 is issued by the International Federation of Accountants (IFAC).
The good news is that, for the most part, SSAE 16 and ISAE 3402 are essentially the same. There are a few differences that are important to financial auditors and lawyers, but should not have an impact on people relying on these reports for PCI compliance or other purposes. What is important is that now, no matter where you are in the world; you can obtain an independent assessment of a service provider’s controls.
There are three different types of AICPA Service Organization Control (SOC) reports. The SOC 1 (Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting) is what SAS 70 is now referred to and is conducted to the SSAE 16 standard. The SOC 2 (Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy) and SOC 3 (Trust Services Report for Service Organizations, formerly known as WebTrust) are conducted to Attest Engagements section 101 standards. The AICPA has indicated that SOC 1, SOC 2 and SOC 3 reports have to be issued as separate reports.
For PCI and other IT or non-financial purposes, the SOC 2 report is the one that should provide you the most benefit as it can include controls relevant to security, availability, processing integrity, confidentiality and/or privacy. SOC 2 reports must use all or a complete subset of the SOC 3 principles. While not ITIL, HIPAA, PCI or such, they should be more than adequate to ensure an organization is conducting business to ensure appropriate practices. Best of all, as with the SOC 1, the CPA firm can issue an opinion as to whether those controls are functioning as designed. Why is an opinion important? Because the CPA firm has conducted testing over a given period of time (usually six to 12 months) to ensure that the controls tested functioned as designed for the period of time being audited. ISO and PCI certifications do not provide such assurances as they are as of a certain date not over a period of time. Although I understand that ISO is considering changes to their processes that may change their certification processes to be similar to SOC 2.
Unfortunately, financial auditors outside of the United States are, for the most part, unfamiliar with conducting such an assessment of controls. As a result, they will need time to get up to speed on such attestation engagements. So those of you outside of the United States need to be patient while the auditors in your country get up to speed.
Guidance on SOC 1 and SOC 2 reports need to be structured is expected by April 2011. So please do not bug your friendly CPA until after April 2011 regarding these new reporting standards. The bottom line is that we are expecting to see a lot of SOC 2 reports that will cover ITIL, HIPAA and PCI requirements as part of their testing. So start asking your service providers now for an SSAE 16 or ISAE 3402 report now so that your service provider can start asking their auditor to prepare such a report.
PCI Guru 