Accounting for Cyber Security Part Four – Auditing Cloud Providers’ Security

Because evaluating a service provider’s security posture is more challenging in the cloud, in Part Three of this article we looked at ways to evaluate a cloud service provider’s security prior to signing the contract and some of the issues between customers and suppliers created by the SEC Guidance. In Part Four we’ll look at ways to monitor the provider’s security during the term of the agreement.

Auditing Security

For years customers of outsourced IT services have asked providers for a copy of their SAS 70 Type 2 audit report as a means of evaluating a supplier’s security. Since the SAS 70 wasn’t really designed to be a security audit, it isn’t really suited for this, but in the absence of a more security-specific standard, the SAS 70 was a suitable proxy.
Recognizing the need for a more security specific audit, in mid-2011, the American Institute of Certified Public Accountants (“AICPA”) established a Service Organization Controls (“SOC”) reporting framework in the hope of providing the public and CPAs with a clearer understanding of the reporting options for service organizations.

Additionally, the AICPA sought to reduce the risk of misuse of SSAE 16, which recently superseded SAS 70, as a mechanism for reporting on security, compliance, and operational controls.

To achieve these goals, the AICPA released the following reporting framework:

• SOC 1: Reporting on Controls at a Service Organization Relevant to User Entities’ Internal Control Over Financial Reporting (also known as the “SSAE 16”)
• SOC 2: Reporting on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy
• SOC 3: SysTrust for Service Organizations

Of the three, SOC 2 is the only new type of examination. Since the SSAE 16 has replaced the SAS 70, service providers are already offering to share their SSAE 16 audit report with customers. However, between the two reports, the SOC 2 is really what customers need to see to evaluate a cloud provider’s security. Unlike SOC 1 (SSAE 16), the focus of the SOC 2 is on controls related to security, compliance, and operations, rather than controls relevant to financial reporting. SOC 3 reports review a service provider’s controls related to security, availability, processing integrity, confidentiality, or privacy but do not provide the same level of detail as provided in a SOC 2 report. If data or processes that could create a material risk to the customer will be going into the cloud, then customers should expect to see both a service provider’s SOC 1 and SOC 2 reports. If the data going to the cloud is not sensitive and/or the processes going to the cloud are not important to a company’s operations (i.e., they don’t create a risk to the company), then it may be acceptable for a cloud provider to provide a SOC 3 instead of a SOC 2.

The AICPA provides a downloadable comparison of the three SOC reports in MS Word format here.

SOC 2 examinations report on controls that mitigate the risks of achieving the following “Trust Services” principles:

• Security – The system is protected against unauthorized physical and logical access.
• Availability – The system is available for operation and use as committed or agreed.
• Processing Integrity – System processing is complete, accurate, timely, and authorized.
• Confidentiality – Information designated as confidential is protected as committed or agreed.
• Privacy – Personal information is collected, used, retained, disclosed, and destroyed in conformity with the commitments in the entity’s privacy notice and with criteria set forth in generally accepted privacy principles (GAPP) issued by the AICPA and Canadian Institute of Chartered Accountants (CICA).

Companies are not required to be assessed on all five Trust Services principles. Cloud providers are permitted to select the Trust Services principle(s) that best meet their reporting objectives. While service providers are expected to base the selection of principles on the relevance of each principle to their services, as well as the interests of their customers, customers need to recognize that the service provider’s opinion on which Trust Services principles best meet the service provider’s reporting objectives may not be the same as the ones the customer wants to have evaluated.

When selecting a Trust Services principle, the cloud provider asserts its compliance with the principle and the underlying “criteria.” There are no “bright line” rules defining the specific controls that must be implemented to meet the criteria of selected principles. For example, item 3.4 of the Security Principle states: “Procedures exist to protect against unauthorized access to system resources.” The criteria provide illustrative controls that could be used to meet the requirement, including the use of VPNs, firewalls and intrusion detection systems, but none of the illustrative controls are specifically required. Cloud providers also can present their own internal controls as long as those controls meet the criteria for the selected Trust Services principle(s). This means that, just like the ISO 27001 certification and the Statement of Applicability, customers must dig deeper to understand how the supplier’s controls satisfy the relevant criteria.

The scope of a SOC 2 examination can be expanded or contracted based on the specific services being provided. Specific criteria can be omitted if they are not applicable to the service being reviewed, or the scope of a SOC 2 examination can be expanded to report on topics not specifically covered by the SOC 2 guidance. This gives cloud providers the ability to request that the auditor also report on compliance with other frameworks, such as the security requirements of HIPAA or the CSA CCM within a single SOC 2 report.

Unlike ISO 27001 and SOC 3, SOC 2 is not a certification. However, service providers that successfully complete a SOC 2 examination are entitled to display the AICPA’s service organization logo on their promotional material and website for 12 months following the date of the report.

As part of your contract with a cloud-based service provider, you should require the supplier to have a SOC 2 report prepared on a regular basis and that report should be shared with you along with a plan to address any issues identified by the SOC 2 audit.

Conclusion – So What?

As we discussed in Parts One and Two, the SEC’s new Guidance requires that companies not only disclose material cybersecurity events when they occur, but also disclose material risks that could occur. For those companies that outsource functions that have material risks, the Guidance also requires a description of those functions and how companies address those risks. In Parts Three and Four we looked at how you can evaluate and monitor the security posture of your cloud service providers.

The SEC has sent a message in no uncertain terms that it expects public companies to provide timely, accurate and complete-but-not-overly-disclosing information about cyber incidents and risks.

While, from the SEC’s perspective, this new Guidance merely clarifies the existing requirement that public companies disclose “material” information to investors, these new guidelines impose significant obligations that such companies would almost certainly consider new.

The impact of these new requirements is magnified when combined with the whistleblower provisions in the Dodd-Frank Wall Street Reform and Consumer Protection Act. The Dodd-Frank Act offers a reward of 10-30% of any recovery over $1 million to informants who provide certain types of information leading to successful securities actions — notably including failure-to-disclose actions.

Companies now face the unenviable task of deciding what aspects of cyber incidents or risks are “material” and disclosing them, with the knowledge that the sophisticated and determined nature of today’s cyber-attackers make predicting the nature of an attack and its consequences incredibly difficult. The nature of the cyber threat is one that is constantly adapting and evolving. For example, should RSA have anticipated that an attacker would target information about their tokens and disclosed the risk that if someone did somehow compromise the algorithms embedded in the tokens, then RSA might have to spend $52 million replacing all of the tokens? Almost by definition, once such an event happens it could be considered a “risk” that should have been disclosed. And if a company does not disclose an event, their IT staff could collect a $100,000 – $300,000 bounty (or more) for information leading to a successful failure-to-disclose action.

It’s considered axiomatic in the security community that it’s not a question of whether a company will have a cyber incident, but, rather, when it will happen. Once a company that has outsourced a function to a cloud provider (or any provider, for that matter) and that cloud provider suffers a cyber incident that creates a material issue for the company that must be disclosed, the company will be forced to defend itself against a claim that it should have disclosed the (now apparent) material risk associated with that outsourcing. The best defense in such circumstances will be the fact that the company did as much due diligence as possible, including selecting a supplier that was certified as ISO 27001 compliant with an acceptable SOA, and that was subject to ongoing SOC 2 audits.

Faced with these new disclosure obligations, companies should examine their own cybersecurity processes and procedures as well as those of their suppliers, look at their incident response plans, and examine their cyberinsurance coverage.