SaaS governance and security is gaining attention among IT and security leaders. This is good, given that organizations are using exponentially more software-as-a-service (SaaS) than infrastructure-as-a-service (IaaS) offerings. Large enterprises are using upwards of 200 different SaaS offerings, compared to two or three IaaS providers, and only about 30% of organizations have any sort of SaaS security solutions in place.
Despite the pervasive use of SaaS, it is overwhelmingly ungoverned with little insight into use, data storage or access control. That’s why the Cloud Security Alliance (CSA) created the SaaS Governance Best Practices for Cloud Customers whitepaper, for which I was honored to serve as its co-lead. These are some of the key security takeaways from the SaaS governance best practices guidance.
SaaS governance pillars: Discovery, management, security
SaaS governance revolves around three key pillars: discovery, management and security. The first step is inventorying the SaaS used across the enterprise. As the old adage goes, you can’t secure what you don’t see or don’t know exists. The SaaS paradigm makes this significantly harder since there are no physical systems like in legacy data center environments, and nearly anyone across the organization can start consuming SaaS with a credit card and a few clicks of a mouse.
Once organizations have an inventory in place, they can start managing their SaaS consumption. This means getting processes in place to vet SaaS vendors for suitability with organizational or industry requirements around security and compliance, often with frameworks such as HIPAA, SOC2, FedRAMP and others as well as internal organizational security requirements.
Lastly, organizations need to take steps to secure the SaaS they’re consuming. While much of the shared responsibility model for cloud may belong to the SaaS provider, it is still your organizational data, customer trust, and regulatory ramifications. Ultimately, you’re still held accountable for any security incidents. This manifests itself as understanding the data involved, who has access and using modern tooling like SaaS security posture management (SSPM) tools to scan the environments for misconfigurations, vulnerabilities and compliance deviations. Thinking the SaaS provider is securing everything is a foolish mistake, but one made all too often. These activities need to occur throughout the SaaS consumption lifecycle of evaluation, adoption, usage and decommissioning.
Develop SaaS information security policies
Organizations consuming SaaS need to take steps to develop relevant policies and processes that help govern their SaaS consumption. This includes key activities from evaluation, acceptable risk, privacy requirements, and risk management. It’s strongly recommended to conduct a risk assessment before placing organizational assets into the SaaS provider’s environment. This includes organizational and especially customer data. SaaS consumers must understand what industry certifications the SaaS provider has, whether they undergone third-party assessments, and what the SaaS providers supply chain looks like. We’ve seen SaaS providers suppliers and supply chain entities cause cascading incidents that ultimately impact the SaaS consumer.
It is also critical to understand the level of support the SaaS provider will offer, under what timelines – service level agreements (SLAs), for example — and how the SaaS provider manages and secures their own infrastructure. It is also important to understand the SaaS provider’s software supply chain practices and software delivery — such as continuous integration/continuous delivery (CI/CD) and their adherence to industry best practices like Supply chain Levels for Software Artifacts (SLSA) — to avoid tampering and poisoning their software releases.
Consumers want to request key artifacts such as vulnerability and penetration test reports to understand the security of the SaaS providers infrastructure and hosting environment. Organizations will also want clarity on how the SaaS provider uses their data. Who at the organization has access to it and under what circumstances? Are they sharing that data with anyone else, and if so, why? Key items such as data encryption and key management practices can provide insight into the confidentiality of your data in a SaaS providers environment.
Termination is an often-overlooked aspect of SaaS usage. Consumers must understand how the SaaS providers handle termination of services and ultimately sanitization of the consumers data in their environment.
Internal SaaS security controls
Security considerations related to SaaS consumption don’t pertain to only the SaaS provider. Organizations must establish their own roles and responsibilities related to SaaS consumption. Key technical and administrative controls must be implemented to ensure access control is put into place related to SaaS environments. Everything from system application and audit logging, multi-factor authentication (MFA), and monitoring the use of privileged accounts comes into play.
Another key area is incident response and business continuity (IR/BC). Organizations have become reliant on external as-a-service providers, including SaaS, yet few have updated their IR/BC policies and plans to account for SaaS usage to know what to do if an SaaS service is disrupted or a security incident occurs. This is despite the fact that, particularly for remote-focused organizations, SaaS is often the lynchpin that facilitates business continuity and operations.
SaaS supplier relationships
CSA’s SaaS governance guidance has a section dedicated to understanding SaaS supplier relationships. It cites the need for a SaaSBOM, which is a software bill of materials (SBOM) in the context of SaaS and its extended chain of third-party services and dependencies. The guidance recommends the SBOM format CycloneDX, which can facilitate an SBOM in the context of SaaS and its underlying components. The case for SBOMs grows stronger with guidance from organizations such as the U.S. National Telecommunications and Information Administration NTIA, Cybersecurity and Infrastructure Security Agency (CISA), National Institute of Standards and Technology (NIST), and Open Source Security Foundation (OpenSSF). It is critical to understand the software components involved in the applications you’re consuming and their associated vulnerabilities, and this need still exists in the SaaS consumption model.
The guidance also emphasizes the complexity of the modern digital environment and myriad supply chain relationships that exist. This requires organizational policies that address SaaS products as part of the broader organizational cybersecurity supply chain risk management (C-SCRM) program, per guidance such as NIST’s 800-161 r1. In the context of SaaS, some key considerations are having a single accountable role within the organization for each relationship with a third party, methodologies for evaluating the likelihood of incidents related to those SaaS providers, and even using securing scoring and rating tools for vendors.
Moving SaaS governance and security forward
While most organizations are in their infancy as it relates to establishing mature SaaS governance and security plans, the CSA SaaS Governance Best Practices guide offers robust vendor-agnostic SaaS governance advice. Organizations should dive into this rich resource and align their organizational practices and policies with these best practices to mitigate risks related to their SaaS consumption.
Copyright © 2022 IDG Communications, Inc.
