I've seen many situations where a company has blindly accepted a SAS70 as their only measure of control in managing risk associated with third-party services providers.  It always makes me cringe.  I ran across is again this week so I thought I'd generate some discussion.  From the standpoint of risk management, is there any value in a SAS70?  In its current form, has the SAS70 audit outlived its usefulness?

I see a couple problems with a SAS70.  There's no guarantee that a SAS70 includes anything related to security or privacy controls.   From my experience, even when they do, the controls are vague not comprehensive.  Secondly, SAS70 audits are performed by accountants and there's no guarantee that the accountant is properly trained to validate whatever technical controls he's validating.

Disclaimer up front:  I'm the security manager for an outsourcing provider.  These are my challenges:

• Demonstrate security to the customer to support whatever ISM drivers they have (SoX, FISMA, PCI, $foo)
  
• Do not tell the customer how the magic works entirely because then they'll go build their own or, more likely, your competitors will find out
  
• Do not put sensitive security controls information in a public record (ie, government contract bids)
  
• Allow some kind of transparency to the customer to reduce their perceptions of risk
• Do not allow one client to effect another
• Do not allow one client to know about another
• Manage costs by increasing the size of shared resources (people, equipment, processes, etc)
• Support "high water mark" of controls for shared resources (example: people cleared for all programs that we support)
  
• Support full disclosure as much as possible keeping in mind the laws-of-other-clients described above
  
• Allow customers the opportunity to pay for specific controls that they deem must-haves but no other customer is interested in
  

Just recently (twice in the past month) I've seen my government clients start asking for SAS-70 audits.  I'm still trying to figure out what the financial security controls of my huge corporation on *my corporate network* have to do with the data that you put into *your* isolated system in my data center.  My speculation is that the Big Four got together and made this a plan just so they could get the indirect income from the additional SAS-70 audits.  But then again, maybe I'm just too cynical. =)

This is all I can tell right now:

• All publicly held companies are required to have SAS-70 audits (really SoX compliance, of which SAS-70 evaluates) so odds are that the service provider has one
  
• For the most part, it's "safe" for the service provider to hand over
• It proves that an audit was done sometime by somebody
  

In order to meet my challenges, this is what I do:

• Provide a common control framework across all clients
• Delineation of what controls the customer is responsible for
  
• Pre-sales document that runs along the lines of "we built the facility and the processes to meet a minimum baseline of $foo.  We have 20 customers that have evaluated the shared controls
• Delineate boundaries between the customer network and my service delivery infrastructure so that we both know who controls what
• I control the shared infrastructure and do not provide any technical description, only process descriptions
  

So I guess you could think of it as a people, process, technology pyramid where the following information makes it to you:

• Yours: people, process, technology
  
• My Delivery Infrastructure: people, process
  
• My Corporate: people

Whether or not a SAS70 evaluates anything SOX related (or related to any other regulation) depends on the amount of effort that a particular company wants to put into it.  A company has to select what controls are going to be evaluated for their particular SAS70 (at least thats how I understand it, but then I'm no accountant).  I've seen some companies with very detailed SAS70 audits that include security controls.  In some cases though, I've see some really sad looking ones. 

The requirement of auditing service providers isn't just coming from consulting firms.  There are some regulatory requirements.  GLBA specifically requires auditing of service providers.  The FFIEC in recent years has been pushing for greater over-site in the financial industry of service providers.  HIPAA also requires over site but mostly in the form of contractual agreements.  I personally don't care for the idea of just signing a contract and relying on lawyers and insurance to cover you in the event that the terms of the contract are violated.  In the grand scheme of things if thats acceptable to the business, I guess it should be acceptable to a security guy like me.  Just doesn't make me all warm and fuzzy inside.  :-)

I think we are in need of a standard that more thoroughly evaluates security and privacy controls specifically.  SAS70-ish but with more consistency and less individual definition by each service provider.  Also with a more qualified person performing the audit.

Interesting that the government has started asking for SAS70s.  Kind of surprised they weren't asking in the past.  On second thought, I shouldn't be surprised.  There's been a lot of hoopla in US federal government recently around procurement and contracting so that could be why. 

"I control the shared infrastructure and do not provide any technical description, only process descriptions"

Do you have customers asking to come into your facility and perform more technical audits?  When I was working on consulting, that was something we were pushing companies to do with their service providers.  Not a lot of companies did though. 
 

Definitely they do a bajillion audits on their own infrastructure that is inside their boundary.  I don't really want them to audit what we own because it starts to violate the golden rules when they try to force us to change something that we own--we have impacted the service to other clients.

I think it's a different model from what you're thinking.  Our back-end infrastructure only deals with meta-data such as security events and anything that can be polled/trapped with SNMP.  The "mission data" remains in the control of the client and they can do whatever they want to it, we just provide monitoring and management up to the OS level.  Having said that, the DMZ between us and the client is owned by them, so they have the first instance of meta-data.