Key Takeaways from CSA’s SaaS Governance Best Practices Guide


SaaS governance and security are attracting the attention of IT and security managers. This is a good thing, given that organizations are exponentially using more software as a service (SaaS) than infrastructure as a service (IaaS) offerings. Large enterprises use over 200 different SaaS offerings, compared to two or three IaaS vendors, and only about 30% of organizations have SaaS security solutions in place.

Despite the ubiquitous use of SaaS, it is extremely loosely governed with little insight into usage, data storage, or access control. That’s why the Cloud Security Alliance (CSA) created the SaaS Governance Best Practices for Cloud Customers white paper, for which I had the honor of being co-responsible. Here are some of the key security elements from the SaaS governance best practices guide.

Pillars of SaaS governance: discovery, management, security

SaaS governance is built around three key pillars: discovery, management, and security. The first step is to inventory the SaaS used in the company. As the old saying goes, you can’t secure what you can’t see or know exists. The SaaS paradigm makes this much more difficult because there are no physical systems like in legacy data center environments, and almost anyone in the organization can start using SaaS with a credit card and a few mouse clicks.

Once organizations have an inventory in place, they can start managing their SaaS consumption. This means having processes in place to check SaaS vendors for adequacy with organizational or industry security and compliance requirements, often with frameworks such as HIPAA, SOC2, FedRAMP and others, as well as organizational security requirements. internal.

Finally, organizations must take steps to secure the SaaS they use. While much of the shared responsibility model for the cloud may belong to the SaaS provider, it’s still about your organizational data, customer trust, and regulatory ramifications. Ultimately, you are still held accountable for any security incident. This manifests in understanding the data involved, who has access to and using modern tools such as SaaS Security Posture Management (SSPM) tools to scan environments for misconfigurations, vulnerabilities and gaps. compliance. Thinking that the SaaS provider secures everything is a stupid mistake, but too often made. These activities should occur throughout the SaaS consumption lifecycle of evaluation, adoption, use, and retirement.

Develop SaaS information security policies

Organizations using SaaS should take steps to develop relevant policies and processes that help govern their consumption of SaaS. This includes the key activities of assessment, acceptable risk, confidentiality requirements and risk management. It is highly recommended to perform a risk assessment before placing organizational assets in the SaaS provider’s environment. This includes organizational data and especially customer data. SaaS consumers should understand what industry certifications the SaaS vendor has, whether it has undergone third-party assessments, and what the SaaS vendor supply chain looks like. We’ve seen SaaS vendors and supply chain entities cause cascading incidents that ultimately impact the SaaS consumer.

It’s also critical to understand what level of support the SaaS vendor will offer, in what time frame — service level agreements (SLAs), for example — and how the SaaS vendor manages and secures its own infrastructure. It is also important to understand the SaaS vendor’s software supply chain practices and software delivery – such as continuous integration/continuous delivery (CI/CD) and their adherence to industry best practices like the levels of supply chain for software artifacts (SLSA) – to avoid tampering and poisoning their software releases.

Consumers want to request key artifacts such as vulnerability and penetration testing reports to understand the security of infrastructure and hosting environment from SaaS providers. Organizations will also want clarification on how the SaaS provider uses their data. Who in the organization has access and under what circumstances? Do they share this data with anyone else, and if so, why? Key elements such as data encryption and key management practices can provide insight into your data privacy in a SaaS vendor environment.

Termination is an often overlooked aspect of using SaaS. Consumers need to understand how SaaS providers handle termination of services and ultimately sanitization of consumer data in their environment.

SaaS internal security controls

SaaS consumer security considerations are not just for the SaaS provider. Organizations should establish their own roles and responsibilities related to SaaS consumption. Key technical and administrative controls should be implemented to ensure that access control is in place for SaaS environments. Everything from system application and audit logging, multi-factor authentication (MFA) and privileged account usage monitoring comes into play.

Another key area is incident response and business continuity (IR/BC). Organizations have become dependent on external service-as-a-service providers, including SaaS, but few have updated their IR/BC policies and plans to account for SaaS usage to know what to do if a SaaS service is interrupted or if a security incident occurs. This despite the fact that, especially for remote organizations, SaaS is often the keystone that facilitates business continuity and operations.

SaaS vendor relationships

CSA’s SaaS Governance Guidelines include a section dedicated to understanding relationships with SaaS vendors. He 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 guide recommends the CycloneDX SBOM format, which can facilitate an SBOM in the context of SaaS and its underlying components. The case for SBOMs is growing stronger with advice 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). Understanding the software components involved in the applications you consume and their associated vulnerabilities is essential, and this need still exists in the SaaS consumption model.

The guidance also emphasizes the complexity of the modern digital environment and the myriad of relationships that exist in the supply chain. This requires organizational policies that address SaaS products as part of the broader organizational cybersecurity supply chain risk management (C-SCRM) program, according to guidelines such as NIST 800-161 r1. In the context of SaaS, some key considerations are having a single accountable role within the organization for each third-party relationship, methodologies for assessing the likelihood of incidents related to these SaaS vendors, and even using secure rating and evaluation tools for suppliers.

Advancing SaaS Governance and Security

While most organizations are in their infancy when it comes to establishing mature SaaS governance and security plans, CSA’s SaaS Governance Best Practices Guide offers solid governance guidance. SaaS, vendor-neutral. Organizations should dive into this rich resource and align their organizational practices and policies with these best practices to mitigate the risks associated with their SaaS consumption.

Copyright © 2022 IDG Communications, Inc.


Comments are closed.