Software as a Service (SaaS) is an increasingly favored method for delivering security solutions, but also an increasingly favored attackers’ playground. The cause of the latter may be the shared security responsibility model.
Security for SaaS is delivered by the shared responsibility model. The provider is responsible for the security of the cloud – it secures the core application and the infrastructure it runs on. The customer is responsible for security in the cloud – their own data, user accounts and access, and correctly configuring the security settings offered by the individual provider.
The problem is little conformity from the providers. Each may offer different settings in a different manner requiring a different level of effort from the customer – and this applies to each SaaS in use, placing a heavy load on the customer. If the customer uses just one SaaS product, it is manageable. But most companies have adopted many, and sometimes hundreds of, SaaS applications – each of which must be configured separately. The complexity of effort is enormous, and complexity is often antonymous with security.
The Cloud Security Alliance (CSA) SaaS Working Group (established by the CSA in 2011) is aiming to solve, or at least ameliorate, this complexity by developing a SaaS Security Capability Framework (SSCF). If customers have access to a standardized set of configuration hooks in all SaaS offerings, the effort, time and complexity of successfully securing their SaaS usage would be much reduced.
“The scope of the SaaS Security Controls Framework [PDF] focuses on customer-facing security controls within SaaS platforms and services. These are controls that can be directly influenced, managed, or utilized by SaaS customers… in fulfilling their security implementation responsibilities under the Shared Security Responsibility Model,” explains the CSA.
Fundamentally, the SaaS providers are being asked to provide customer-facing tools to help the customer comply with its responsibility for configuring and using the SaaS app – the purpose is to help SaaS vendors standardize SaaS customer controls.
Version 1.0 of the SSCF defines six primary SaaS security domains aligned with the CSA’s domain naming conventions. Each domain is listed with a description of its purpose and use.
Each domain has its own number of required controls, ranging from just one in DSP and SEF, through 7 in LOG to 21 in IAM. Examples include DSP-SaaS-01 (the ability to block malicious uploads), and IAM-SaaS-01 (user access visibility). Each control is supported by a more detailed specification of what it must include, and a recommendation of what it should also include.
The SSCF asks the provider to implement these security controls and make them available to the customer. The customer retains the responsibility to use them. This separation maintains the basic premise of shared security responsibility, but in a manner likely to improve the entire SaaS ecosphere.
It places a new burden on the SaaS provider, but one that should be accepted. Given a choice between an SSCF-compliant option and a non-compliant option, the customer will almost certainly choose the compliant option. “On the SaaS vendor side,” adds the CSA, “it provides a standardized approach to controls required by larger enterprise customers. For smaller SaaS vendors, this can translate into fewer resources required for supporting varying customer requirements.”
“For too long, a critical part of the SaaS security story has been a black box,” writes Brian Soby (CTO at AppOmni, and one of the SSCF authors) in an accompanying blog. “Organizations have built sophisticated Zero Trust architectures around their on-prem and IaaS environments, but when it comes to the SaaS applications that hold their most sensitive data, the controls we rely on are often stuck in the past. This disconnect creates a massive, unnecessary risk.”
The primary objective of the SSCF is to reduce this risk and foster trust, efficiency, and integrity within the global SaaS ecosystem by establishing standardized security practices. “The SSCF addresses a critical gap in SaaS security by establishing the first industry standard for customer-facing security controls,” explains Lefteris Skoutaris (AVP of GRC solutions at the CSA). “This framework exemplifies CSA’s mission to unite diverse industry partners (from SaaS providers to enterprise customers) in creating practical solutions that translate compliance requirements into actionable security capabilities that organizations can actually configure and enforce.”
The CCSF is a win for both provider and customer. Both sides can concentrate on the quality of the product’s service without overly worrying about its implementation details.
Related: Thousands of SaaS Apps Could Still Be Susceptible to nOAuth
Related: When Convenience Costs: CISOs Struggle With SaaS Security Oversight
Related: Stolen Credentials Have Turned SaaS Apps Into Attackers’ Playgrounds
