Greg Shipley: Cloud Computing Risks and SAS-70
The following is excerpted from the April 12, 2010 Information Week article "Cloud Computing Risks", written by Greg Shipley. Data center certifications and data center compliance are not always what they seem.
Most IT pros are familiar with the Statement of Auditing Standard (SAS) No. 70 from The American Institute of Certified Public Accountants. Put simply, it’s an auditing standard for service organizations reporting on controls put into operation. While there are two types of SAS 70 audits, Type I and Type II, Type II is the most popular as it involves a minimal amount of testing for specified controls. The output of a SAS 70 Type II audit is typically a “letter of attestation” by the auditor and a report on the “control objectives” that were reviewed during the audit.
Unlike prescriptive standards such as PCI-DSS (Payment Card Industry Data Security Standards), SAS 70 defines the process – the how – in which an audit is performed, but not the criteria – the what – that must be included during that audit. There is certainly value to a SAS 70 Type II audit, but the relevance of that value heavily depends on the controls being investigated – the what. As any IT professional who has undergone a SAS 70 will attest, you can simply remove controls that you don’t want audited. Don’t have desktop patching? Strike it. No security integrated into the software development life cycle? Don’t have your auditor look at that. Don’t run vulnerability scanners? Keep it off the objectives list.
The practice of massaging SAS 70 control objectives is bad news for security, and unlike standard controls in the accounting world, we don’t have Generally Accepted Accounting Principles for IT Risk. Even worse, many of the templates that SAS 70 auditors use are based on outdated controls. For example, password strengths don’t matter when an attacker can gain administrative access to critical systems via unpatched vulnerabilities. The value of a report is only as good as the controls it examines and the scope of its coverage.
Aggravating the situation, we’ve seen cloud providers that will provide a letter of attestation but refuse to list the SAS 70 control objectives. This akin to saying: “Yes, we were audited, but no, we won’t tell you what the auditors looked at.” Fortunately, many IT professionals and mature cloud providers see the absurdity of this situation. “A SAS 70 letter of attestation without visibility into the control objectives is meaningless,” says Google’s Feigenbaum. We couldn’t agree more.
Just like technology evaluations, the value of an audit is all about the criteria and the testing methods. So how do we make sure the right controls are looked at? Build the beforehand using a standards-based formula.