The why and how of SaaS Governance
A look at the neglected aspect of Cloud Security
(I originally wrote this article in CSO Online in August 2021. Since then, the conversation around SaaS governance and security has only continued to heat up. This is an updated version of the article, with relevant revisions over the past 18 months.)
SaaS adoption is far outpacing IaaS consumption. Despite that, organizations are focusing almost exclusively on infrastructure security. They must also consider a SaaS governance plan that implements security measures to reduce risk associated with their SaaS usage. That plan includes a combination of compliance frameworks, documentation/due diligence and technical measures for ongoing monitoring and risk reduction.
Much of the security discussion around cloud adoption focuses on infrastructure-as-a-service (IaaS)/platform-as-a-service (PaaS) providers such as Amazon Web Services (AWS), Microsoft Azure and Google Cloud, and for good reason. Organizations have experienced tremendous growth of IaaS adoption and seen countless security breach headlines associated with IaaS misconfigurations.
However, the risks that poorly implemented and secured SaaS present have been neglected. Gartner predicts SaaS will remain the largest public cloud market segment, and that prediction came prior to COVID-19, which facilitated an unprecedented SaaS boom. Furthermore, organizations typically tend to use only a few IaaS providers, such as the big three cloud service providers (CSPs), while consuming many more SaaS offerings. A 2020 study from Blissfully found that large enterprises use as many as 288 different SaaS apps, with small- to medium-sized businesses (SMBs) using more than 100.
While your organization may have started to mature its IaaS security, the same likely isn’t true for the more expansive and diverse SaaS landscape. This reality also makes shadow IT usage of SaaS providers much more prevalent than IaaS providers, due to the large array of SaaS offerings in the marketplace and the ease with which you can consume them, often with as little as a credit card.
A study conducted by Zylo found that organizations are adding, on average, ten SaaS offerings to the enterprise per month and IT only directly manages 25% of them. That is a lot of unmanaged SaaS risk. Despite this exponential growth in SaaS usage, a study by AppOmni found that only 32% of respondents employ any type of tooling to ensure data security in SaaS.
Despite this widespread SaaS adoption, why do organizations continue to focus almost exclusively on IaaS security concerns? Some of that is due to misunderstanding the shared responsibility model and assuming in a SaaS environment the CSP is responsible for everything. The other factor is that security teams are simply struggling to keep pace with their organizations’ cloud usage and with the fallout from widespread high-profile IaaS data breaches.
Major IaaS providers offer clear certification and learning paths, ensuring professionals can learn how to secure their platforms and attest to that. SaaS doesn’t offer that same scenario. As security professionals, we must continue to evolve, and SaaS security is ripe for maturing to the point where it can begin to mitigate this enormous amount of unaddressed risk.
SaaS use is pervasive and often in a manner that leaves a complicated web of integrations and interdependencies, which can lead to a cascading impact when a single SaaS provider is compromised. One clear example is the security incident in 2022 that targeted Okta, Twilio and Cloudflare by a malicious actor campaign dubbed “0ktapus”.
This incident impacted or involved not only the companies mentioned but also another 130+ organizations and 68 additional countries. Attackers are well aware of the web of complexity, integrations and interdependencies in the SaaS ecosystem and this is why it is a notable target in the realm of software supply chain attacks, similar to compromising OSS components.
The reality is that a single compromised SaaS provider may impact many other SaaS and cloud environments as well as on-premise enterprise environments where organizations have made integrations with as-a-Service providers such as IAM, Storage, Collaboration tools and more.
So what should organizations do to mitigate these risks?
An approach to SaaS risk
Implementing security for SaaS usage should be data driven. This means looking at the internal data that the SaaS offering has access to, the level of access within your enterprise, and the potential security and regulatory ramifications if that data was to be inadvertently exposed or maliciously compromised. This is especially true with today’s geographically dispersed workforce where individuals access data from everywhere, often from their own devices.
The first step in the process is capturing what SaaS your organization is using. The age of “you can’t protect what you don’t know you have” situation strikes again, but this time in the form of inventorying SaaS usage much like you create an on-premise/self-hosted software asset inventory, as recommended for a long time now via sources such as the CIS Critical Controls list.
Depending on the organization's maturity and technical architecture, this could be a manual inventory management process or require technical tools such as cloud access security brokers (CASBs), which can help identify shadow SaaS use.
When organizations start to put security rigor around their SaaS usage, they tend to take two approaches. One focuses on security frameworks such as SOC2, PCI and FedRAMP as well as documentation review. The other focuses on technical assessment, hardening and ongoing/continuous monitoring (ConMon).
The ideal approach involves a bit of both as discussed below.
Frameworks, documentation and reports
When organizations begin to vet SaaS offerings for their organization (ideally prior to purchasing and implementing them), it tends to involve popular frameworks such as SOC2, CSA CCM and STAR/CAIQ, or FedRAMP.
SOC2 has increasingly become a popular option for SaaS providers, since it helps to validate a company’s internal controls related to security, availability, confidentiality, integrity and privacy. Another popular option is CSA’s Consensus Assessment Initiative Questionnaire (CAIQ), which documents what controls exist in XaaS offerings and is tied to CSA’s Cloud Controls Matrix (CCM), a cloud specific security control framework. On the U.S. public sector side, the Federal Risk and Authorization Management Program (FedRAMP) is widely used as a way to authorize cloud service offerings (CSOs) for government consumption and uses NIST 800-53 security controls.
That said, many challenges exist for some of the larger more rigorous compliance assessment and authorization programs, such as FedRAMP, which can really limit the pool of available authorized SaaS/Cloud providers. I discuss some of that in this article about the recent FedRAMP Authorization Act, and how to improve the FedRAMP program.
That said, organizations often do and should ask for these certifications because they often include a third-party assessment organization (3PAO) process where a third party verifies that the SaaS organization and its offering meet a specific level of security rigor. This gives your organization a level of assurance that the SaaS offering isn’t fully insecure and that the organization is doing basic security activity around its own infrastructure and how they handle and store customer data.
The choice of which frameworks to use largely depends on the industry the organization is operating in as well as the maturity of the SaaS vendor. Given these frameworks can be time and resource intensive, newer SaaS vendors usually don’t pursue the certifications until they have matured a bit and their customers have asked for them. There is also the reality that due to the exponential number of SaaS offerings in the market, some of the major compliance programs simply haven’t kept pace, such as FedRAMP.
In cases where the SaaS vendor doesn’t have a certification or audit, or even if they do, and the data you will use them for them is highly sensitive, you may wish to dig into their documentation and other criteria to vet their suitability. This could include results from internal or external pen tests (which often require an NDA) and discussions around architecture, authentication, encryption and much more. These additional activities help give your organization a level of assurance related to the risk of using a specific SaaS offering.
SaaS Security platforms can help automatically enforce critical compliance controls related to widely applicable frameworks such as PCI, HIPAA, GDPR and NIST.
It’s untenable for an organization to maintain continuous compliance with these frameworks across potentially hundreds of SaaS apps, and this is where technical solutions to augment those efforts can really shine.
Technical SaaS coverage/capabilities
While frameworks are a great start in terms of vetting SaaS offerings, it is just a start. As we all know, compliance and security aren’t synonymous and your level of assurance should approach SaaS with this mindset.
You should also consider technical controls, configurations and monitoring as part of your SaaS governance strategy. Each SaaS offering comes with myriad unique features, configurations and settings, most of which your staff will be unfamiliar with from a security perspective.
This is due to the reality that unlike say AWS, Azure and GCP, there aren’t established learning paths and certifications such as Security Specialist exams nor do less mature SaaS providers tend to have robust documentation comparable to the hyper-scale IaaS providers. Even industry recognized credentials such as CSA CCSK or ISC2’s Certified Cloud Security Professional (CCSP) generally focus on securing cloud from the IaaS perspective.
Enter SaaS security posture management (SSPM) tools, which monitor your SaaS application’s security posture. Some of the most popular SSPM tools are AppOmni, and Obsidian and we’ve begun to see major industry players like Axonius bring innovation approaches and tooling to the SaaS Security space as well. These vendors support some of the leading SaaS offerings such as Box, GitHub, Salesforce, and Slack and can provide invaluable insights and context when you’re looking to secure SaaS environments that your enterprise uses.
They have crafted secure configurations, security scanning, best practices and recommendations for helping organizations harden their SaaS usage. Many of these offerings leverage industry resources where possible, such as CIS Benchmarks for SaaS offerings including Microsoft 365 and Google Workspace, which both can contain sensitive data and communications.
These hardening efforts can help protect your organization from prevalent security concerns such as account compromise, insecure configuration, compliance, and access management. They can also help with incident response.
This is incredibly valuable, as your workforce likely doesn’t have the specific security insight and expertise needed for each of your SaaS applications, given just how plentiful they are. SSPM vendors constantly add more SaaS offerings to their coverage and depending on the size of your organization, you may be able to help shape their product roadmap to cover SaaS that is widely used in your organization.
Another area that has seen a lot of interest since I originally authored this article in 2021 is Software Bill of Materials (SBOM), or more specifically SaaSBOM in context of this conversation. Fellow industry professional Walter Haydock and I coined the term SaaSBOM in a September 2021 article on CSO online and since then the concept has gotten attention from groups such as NTIA/CISA in the SBOM conversation as well as industry leaders OWASP, with their CycloneDX SBOM format, which includes support for SaaSBOM’s.
CycloneDX’s SaaSBOM allows organizations to inventory services, endpoints and data flows and classifications that power cloud-native applications. Having a SaaSBOM from your SaaS provider can help you understand the software components used in the delivery of the SaaS application and your risk to potentially vulnerable and exploitable components as well as provide clarity in activities such as Incident Response (IR), when you’re looking to understand where your organization is using impacted software.
OWASP CycloneDX points out that SaaSBOM’s are recommended by Cloud Security Alliance’s SaaS Governance Best Practices for Cloud Customers, which is a whitepaper I helped lead and author with tens of contributing members around the globe.
In this whitepaper in addition to conversations around SaaSBOM’s, you’ll find the most comprehensive vendor agnostic SaaS Governance and Security guidance that I am aware of anywhere in the industry currently.
Now What?
In addition to technical security and compliance concerns, organizations must also be concerned with responsibility in the SaaS paradigm. Remember that shared responsibility model? If not, I wrote an article about it that can be referenced for a deep dive on the topic.
It still applies here. However, unfortunately a large number of cloud consumers still strongly misunderstand what they are responsible for versus what the SaaS provider is responsible for.
They also fail to remember that while responsibilities may be shared, you can’t outsource accountability. Ultimately it is still your data or the data of your customers, business partners, stakeholders and so on that is at risk with the ungoverned and insecure use of SaaS.
The reality is that as an industry our conversation around cloud security still overwhelmingly revolves around securing workloads deployed in IaaS environments. This is despite the truth that mid to large enterprises are using hundreds of SaaS applications, storing sensitive data in those environments, integrating them with other SaaS apps and organizational enterprise services and environments and more.
It’s time for the industry to mature and consider SaaS governance and security on par with securing other service models of cloud such as IaaS and PaaS.
The consumption is certainly there, now let’s hope security can catch up.
The attackers certainly have.