Cloud consumers interested in getting a glimpse into the state of a cloud service provider’s internal security
controls are likely familiar with the Statement on Auditing Standards No. 70 report, usually called SAS 70. This report served as an independent audit statement of an organization’s internal controls (financial and infrastructure-related). In 2011, however, the SAS 70 was retired in favor of the American Institute of Certified Public Accountants (AICPA) Statement on Standards for Attestation Engagements (SSAE) number 16 (SSAE 16).
While many CSPs touted their SAS 70 reports, many in the security community criticized the SAS 70, as the controls being audited were self-defined by the cloud service provider (CSP). What’s changed with the SSAE 16? Is it a better tool for evaluating CSP security?
SSAE 16 and SOC reports
The first key to understanding the new SSAE 16 standard is to recognize the various types of reports available. The SSAE 16 is very similar to the SAS 70, with the primary difference being the requirement for a written assertion by management that the controls included and audited are accurate and functioning properly. The SSAE 16 also aligns somewhat better with other international auditing standards. When a CSP is audited for SSAE 16 standards, the auditor will provide a Service Organization Control (SOC) 1 report at the culmination of the audit. This SOC 1 report can be a Type 1 or a Type 2 (much like SAS 70). Type 1 represents an attestation of controls efficacy and accuracy at a given point in time, while a Type 2 attests to the same over a period of time, usually six months or one year.
Unfortunately, the SSAE 16 SOC 1 report suffers from the same fundamental problem that the SAS 70 had before it: the controls are self-defined. Most security and risk management professionals would prefer to see more “best practices” standardization in independent audit reports for CSPs. Fortunately, there are two other types of SOC reports.
SOC 2 and SOC 3 reports are aligned with the AICPA Trust Services Principles and Criteria (TSPC). These principles are focused on five areas:
- Security: Unauthorized access to systems (both physical and logical) is prevented through controls.
- Confidentiality: Sensitive information labeled as confidential is protected with adequate controls (customer data and systems would likely fall into this category).
- Privacy: Personal information is collected and managed in accordance with the AICPA Generally Accepted Privacy Principles.
- Availability: Systems are designed with uptime and availability in mind, and continuity of system operations is maintained.
- Processing Integrity: All system processing activities are accurate, authorized, complete and authorized.
SOC 2 reports can also come in Type 1 and Type 2 variants. Most security professionals are pleased to see the evolution of the SOC 2, and view it as a more robust controls audit and attestation report for CSPs. SOC 2 is intended for internal consumption, with detailed technical information and sensitive audit data.
SOC 3 reports attest to the same standards as a SOC 2, but are issued with public consumption in mind. They’re much more general in nature and don’t reveal potentially dangerous technical security details that an attacker could leverage. The SOC 3 also has one very compelling advantage: It’s associated with a certification that CSPs can display for customers and prospects. This certification, known as the “SOC 3: SysTrust for Service Organizations” seal, is a big step in the right direction since security teams will know immediately that a CSP has conformed to the TSPC guidelines.
Not enough security details
Still, the TSPC guidelines go into nowhere enough detail for most security professionals. Compared to the Cloud Security Alliance (CSA) Cloud Controls Matrix and Consensus Assessments Initiative Questionnaire (CAIQ), the level of concrete security guidance and rigorous security controls is not there yet. Additionally, the TSPC does not encompass the realm of security domains that any mature CSP should cover, conforming to well-known standards like ISO 27001. At the same time, though, SOC 2 and SOC 3 reports can provide organizations with some insight into a cloud provider’s security.
However, most providers – at the moment -- do not seem eager to embrace the SOC 2 and SOC 3 reports. Procuring the SSAE 16 SOC 1 report is simpler and less expensive, and some CSPs are unlikely to voluntarily seek SOC 2 and/or SOC 3 reports unless pushed by customers. For this reason, it’s important that security teams educate the business unit management within their organizations about the differences between SOC 3 certified CSPs and those with only the SSAE 16 SOC 1 report. As these standards are still fairly new, SOC 2 and SOC 3 reports are still in the minority, and hopefully we’ll see this changing soon.
About the author:
Dave Shackleford is owner and principal consultant at Voodoo Security, senior vice president of research and CTO at IANS, and a SANS analyst, instructor, and course author. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. He is a VMware vExpert and has extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft, CTO for the Center for Internet Security, and as a security architect, analyst, and manager for several Fortune 500 companies. Dave is the co-author of Hands-On Information Security from Course Technology as well as the "Managing Incident Response" chapter in the Course Technology book Readings and Cases in the Management of Information Security. Recently, Dave co-authored the first published course on virtualization security for the SANS Institute. Dave currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance.