SAS 70, the auditing standard, is finding its way onto CSOs' desks. Used correctly, it's a nice start on verifying business partners' security controls.
Unfortunately, some people aren't using it correctly.
The SAS 70 audit—an increasingly popular examination of internal corporate controls—is the source of confusion and debate in the information security world.
There are those who swear by it. Jennifer Bayuk, managing director of IT security at Bear, Stearns & Co., calls a SAS 70 audit "probably the best you can get for a security test, especially when you compare it to something like a security penetration study."
Then there are those who swear about it. Jonathan G. Gossels, president of consultancy SystemExperts, wrote in a paper that "SAS 70 is neither a meaningful security metric nor worth the high cost of obtaining the SAS opinion."
They're both right—and that's not a dodge. SAS 70 (full name: Statement on Auditing Standards No. 70, Service Organizations) can indeed be very helpful in examining the quality of a potential business partner's information security controls. But SAS 70 can also be very damaging when it is misrepresented as simple proof of ironclad security, which some experts say is an unfortunately common occurrence. This article equips CSOs with an understanding of how to be helped, not hindered, by the rise of SAS 70.
Understanding SAS 70 starts with understanding internal
controls. Such controls, in the financial context, might
include, for example, a clear segregation of duties so that
Fred in accounting can't authorize himself to buy a Hummer.
The Sarbanes-Oxley Act is essentially a mandate to establish
internal controls so that corporate executives can't fudge
their numbers. Sarbox requires that companies verify the
accuracy of their financial statements, and establishes SAS
70 Type 2 audits as a way to verify that third-party
providers meet those needs. (SAS 70 Type 1 audits are not
relevant to this article.) If a company outsources some
transaction processing or data hosting that in any way
affects its financial reporting, the company has to verify
that its outsourcing providers' controls are also up to
snuff. SAS 70 can examine controls such as the processes for
assessing risk, managing third-party vendors and ensuring
systems security. In her book Stepping Through the IS Audit,
Bayuk includes a sample audit with a dozen ways to help
verify the controls for systems security, including aspects
like access controls, ways to report security breaches, and
even big-ticket items like how to ensure IT security is
aligned with business requirements.
So far, so simple. But there is a key nuance that CSOs
must understand. A SAS 70 audit does not rate a company's
security controls against a particular set of defined best
practices. In a SAS 70 audit, the service organization being
audited must first prepare a written description of its
goals and objectives. The auditor then examines the service
organization's description and says whether the auditor
believes those goals are fairly stated, whether the controls
are suitably designed to achieve the control objectives that
the organization has stated for itself, whether the controls
have been placed in operations (as opposed to existing only
on paper), and in a Type 2 engagement, whether these
controls are operating effectively. The fact that a company
has conducted a SAS 70 audit does not necessarily mean its
systems are secure. In fact, a SAS 70 may confirm that a
particular system is not secure, by design.
"You can have control objectives to make any statement
management may want to make," says Robert Aanerud, chief
risk officer and principal consultant at security
consultancy HotSkills. In effect, he says, management could
decide that the company is OK with bad access control, and
the auditor (who must be a CPA) then needs to ensure that
access control is at least bad. The SAS 70 opinion would
essentially say that, yes, the company has achieved its
stated control objectives.
Defining security-related objectives is not simple, and wading through SAS 70 audits to see where they do and don't cover what your firm needs to know takes substantial amounts of time. Because SAS 70 was meant to look at financial controls, a SAS 70 audit report may have plenty that has nothing to do with IT security. What CSOs care about may be buried somewhere on a page or two in the middle of a SAS 70 report, which can run hundreds of pages. And CSOs must further read a SAS 70 in context of how their company would establish controls and compare those to how the potential service provider does.
Unfortunately, consultants say many companies are
skipping the hard work and treating SAS 70 as a security
rubber stamp. Sharon O'Bryan, head of O'Bryan Advisory
Services, says she's aware of companies taking SAS 70
reports for potential service providers, sticking them
someplace and never reading them.
That's a failure of due diligence, and O'Bryan is working
with at least one company that has suffered the
consequences. The company hired a service provider without
looking in detail at the vendor's SAS 70. Later, a customer
called wanting to know about an account breach. Eventually
the financial services firm traced the breach to systems at
its outsourcer. Needless to say, it turns out that the
outsourcer had significant issues with its information
security practices, including people without the right
qualifications or experience handling key information
security positions. The outsourcer essentially wasn't
capable of protecting a key database, which was where the
breach ultimately occurred.
All of this information was contained in the SAS 70
write-up. O'Bryan says the report included the relevant
information on the outsourcing provider's control
objectives, and that the outsourcer did not have in place
what it needed to meet those objectives.
But the company did not read the report.
The incident also shows, however, that properly used, SAS 70
would have worked as a security buffer. Bear Stearns' Bayuk
says that in fact, SAS 70 audits generally are very
revealing. She notes that "often a SAS 70 will include
negative results. It's pretty comical...right on Page 46
it'll say, ‘We tested this control and it failed.'"
Shamla Naidoo, CISO at Northern Trust, agrees that while SAS 70s can't be treated as gospel, they nevertheless offer plenty of useful information. "SAS 70s should not be used to replace due diligence on a vendor's information security practices," says Naidoo, who came to Northern Trust in early 2005 after four years at ABN Amro. She says SAS 70 reports are best used primarily as a jumping-off point for validating security controls. "We need to use it for what it was designed for. It attests to adequate controls, not information security. Information security controls are much more granular, and you need to go deeper [than SAS 70]," she says.
Companies, then, must also expect to invest a certain amount of time in reviewing SAS 70s—Naidoo says she's seen 300-page SAS 70 write-ups, which makes for a challenging review. But even slogging through a big SAS 70 audit requires less time for Northern Trust than going out and doing its own security review from scratch on a potential provider. The main challenge with a SAS 70 is that there is no standard way of defining controls.
Mostly, that's by design—audits aren't supposed to force companies into cookie-cutter approaches. "Each organization defines control objectives uniquely," says Naidoo. "In some cases you may have to look at three objectives to make sure [a SAS 70] covers the areas you're concerned with. In others, it might be 15." Naidoo recommends that her teams first know what level of controls—such as access, authentication and intrusion detection—they would need in order to verify security for processes, and use that as a framework for comparison with a potential service provider's SAS 70.
In effect, Naidoo creates an internal map of how controls should work, something Bayuk also does at Bear Stearns. Bayuk pays special attention to the first page of a SAS 70 audit, where the auditor gives a summary of the process being audited. "Often you'll see that it doesn't cover the application you're processing, or the infrastructure, or vice versa," she says.
She also says SAS 70 is useful for controls because while it isn't standardized, it follows a set of well-established procedures and tests to see if a company has followed its own controls. "I would never use an ISO 17799—you can have the best process to assess risk and identify vulnerability and have it on your queue to implement and never implement it," she says.
Service providers say they're being asked more and more often for SAS 70 audits, often instead of governance standards like Cobit or ISO 17799. That's even true for companies that handle security functions, traditionally more oriented toward granular best-practice tests than the broad audit test of SAS 70. Michael Scher, general counsel and compliance architect at Nexum, a security product and service provider, says his company is preparing to undergo its first SAS 70 audit. "It's an efficiency-type move," Scher says. It will save his company the trouble of having to be audited by every potential client, or generate reams of documentation in answer to questions. Scher knows that SAS 70 objectives can be loosely written—something that does fine in an audit "could definitely have some big gaps in the real world," he notes. But he says the same is true for ISO 17799. In fact, he asks, rhetorically, "Is there any regime that's oh so wonderful?"
"All these things are slippery," agrees Richard E. Mackey Jr., a principal at SystemExperts. SystemExperts is the home of Gossels, the consultant who excoriates SAS 70 as ineffective makework for CPAs. But his colleague Mackey says SAS 70 is the de facto standard for checking out security. "If you have policies you want to maintain, the SAS 70 will check that you in fact met those policies and are compliant with them," he says.
There are issues with how to structure objective controls that are meaningful, and how to look for things that perhaps were left out of the control statement entirely, such as whether systems with passwords in fact have controls on who can access them, and what policies guide who can or cannot have access.
The bottom line with SAS 70, then, is this: There are no silver bullets for corporate IT security. SAS 70 is another weapon in the arsenal—one to wield with due care.