As the economy worsens and corporate budgets tighten, there will be an increased pressure on CIOs and their staffs to use third-party service providers for various IT services. This will include everything from existing outsourcing of HR services, payment processing and CRM services to more cloud-based services such as Amazon Elastic Compute Cloud and Microsoft's Azure. Additionally, we will undoubtedly see an increase of privacy and security compliance regulations. Combine the increased flow of data outside the traditional corporate perimeter with the additional compliance needs, and the result is a much sharper focus on the security of third-party service providers.
But how are CISOs supposed to verify the security of a service provider meets their needs to avoid outsourcing security risks? This isn't exactly a new problem, yet it's not one we've had a good solution for in part because it's such a moving target, especially in the case of many of the new cloud-based offerings that aren't built with security in mind. In the end, what a security manager needs to do is perform a risk-based assessment of the business utility of the offering versus solely the security risk.
In order to do a full-on vendor risk assessment, the first step is to understand the security posture of the service provider. At a high level, you can generally get a feel for whether or not the vendor has the right mindset through interviews of its security staff and by reviewing its security and privacy policies to see if they are in line with your company's policies. When reviewing vendors in the past, I've used Request for Information (RFI)-style questionnaires to allow me to compare and contrast similar vendors when it comes to security. Ultimately, though, you will either need to audit the provider yourself to see if reality matches the vendor's claims or have a trusted third party perform that audit..
Now audit is a loaded word. Vendors hate to do them but love to use standardized ones as proof that they are secure. Just keep in mind that standard audits only cover specific domains, so if you need a vendor to be PCI compliant, it doesn't help if they pull out proof that they are HIPAA compliant or vice-versa. If you are going to just accept audits that the vendor has already done, be sure that those are actually in line with your needs and don't assume they're sufficient.
In particular, it is very important to remember that SAS 70 is not now, nor has it ever been, a security audit or proof of any real level of security. SAS 70 is a financial controls audit but has become popular due to the Gramm-Leach-Bliley Act (GLBA) of 1999. As a result of GLBA and similar legislation, most insurance companies are requiring SAS 70 audits from their financial services customers and also requiring those customers make their vendors perform SAS 70s.
The vendors now have a situation where for one reason -- customer demand from financials -- they have spent a large sum of money on one special type of audit such as a SAS 70. Audits quickly get expensive so they want to minimize the number of audits they perform and need to keep track of, which means that they try to use existing audits as much as possible. Be strong; don't accept only a SAS 70 unless what you are concerned with are the vendor's financial controls. Otherwise, demand that vendors provide the necessary proof of security so you can either have the comfort level you need or implement additional security controls to achieve it. [END MARK]
David Mortman is CSO-in-residence at information security research and consulting firm Echelon One. Send comments on this column to firstname.lastname@example.org.