While Software as a Service (SaaS) and Infrastructure as a Service (IaaS) environments are similar in that they include outsourced services, the strategy as a customer for securing a SaaS application is more complex. Because the major difference in IaaS and SaaS environments is that there is lower control in a SaaS environment, the strategy for securing SaaS applications is much different. In a companion article, I examined delineating responsibilities in an IaaS environment.
In a SaaS environment, the vendor has the majority of control and access -- in essence, the vendor controls the entire stack, from the hypervisor to the application and security monitoring. Rarely does a vendor provide access beyond the application's core functionality, and convincing a vendor to prove their claims of security design, implementation and configuration is challenging. While a customer of IaaS services takes a very technical approach to securing their cloud instance, a customer of SaaS applications takes a contractual and procedural approach, with a heavy emphasis on assessment.
The customer's initial task is evaluating the security design, implementation and configuration of a SaaS offering. The questions asked are wide-reaching, from reviewing and evaluating security policy to ensuring the code behind the SaaS offering is written securely. In evaluating the offering, the objective is to understand the maturity of process, policy and technology that is aimed at securing your SaaS instance (and the data associated with it). Document the details of the conversation, especially policies and controls that aren't publicly available. This documentation will be used soon.
Once the SaaS instance is functional, work with the vendor to perform an initial compliance assessment. The goal is not to "catch" the vendor in anything, not to be adversarial. The goal is to ensure policies are followed, controls implemented and functional, and expected outcomes are achievable.
When the assessment is completed and remediation implemented, your diligence needs to remain high. Vendor updates in the environment can result in controls being disabled and overlooked. Your SaaS vendor may also fall behind on updates or fail to respond to trends in the threatscape. It's important to remain engaged: Request the vendor update you on changes in the environment, and ensure assessments are performed on a regular basis. (You can alternate between self-assessments the vendor performs, assessments you perform as a customer, and third-party assessments; this keeps the cost down and spreads the impact across both parties.)
Keep in mind, the level of security should be commensurate with the sensitivity of data or importance of functionality in the SaaS application. Don't set the bar too high if the SaaS application simply serves up your company's lunch menu. But if you plan to store your company's strategy operations plans, take your time evaluating the vendor, and ensure they will protect your data and the service as well as you would do it yourself.
This was first published in February 2013