The adoption of SaaS in the enterprise has been staggering in recent years. While this trend has had a dramatic impact on user productivity and business agility, it has opened new avenues for data breaches and exposures. Clearly, the turnkey aspect of SaaS is alluring to customers, however, it can ultimately be deceptive when security risks that customers are unaware of get introduced.
A large enterprise typically uses 100 or more sanctioned SaaS apps. Each one of these apps comes with unique settings, features, versions and updates. Even if each sanctioned app is properly configured at any given moment, threat actors can still come looking for security vulnerabilities created by a new feature, or a configuration change made by an app administrator. If that wasn’t enough, when a new SaaS app is added to the existing portfolio of sanctioned apps without prior approvals and oversight, security teams are left to deal with a slew of new security blind spots. All things considered, every SaaS app — regardless of the degree of use and protections — is still at risk of vulnerabilities.
Misconfigurations Are a Leading Cause of SaaS Vulnerabilities
Gartner predicted that more than 99% of cloud breaches will have a root cause of preventable misconfigurations or mistakes by end users. Today, SaaS misconfigurations are fast becoming a leading cause of data breaches in SaaS apps. Let’s talk about why traditional CASBs have failed to address this issue.
Traditional CASBs are designed to protect sensitive data first using a data loss prevention (DLP) engine. The problem with this “protect the data first” approach is that the bulk of the SaaS attack surface gets skipped over — the attack surface that constitutes the security and integrity of the SaaS app itself. Focusing on securing data while neglecting the security posture of the app itself is like building on a cracked foundation. The app itself should be protected first from vulnerabilities so that it can be relied on to provide any security assurances, including data security.
When a SaaS app is compromised due to a vulnerability created by a misconfiguration, its overall security posture is adversely affected, putting the apps’ data at risk of a breach. To address the problem, SaaS Security Posture Management (SSPM) has quickly become fundamental to protecting the security posture of SaaS apps.
What are some major SaaS challenges that make SSPM critical to enterprise SaaS security? Let’s examine in detail.
First Pain Point: Securely configuring thousands of settings across hundreds of sanctioned SaaS apps is not an easy task.
Security teams are already struggling to keep pace with the ever-increasing consumption of sanctioned SaaS apps in the enterprise. With that they must also deal with ensuring that every SaaS app is securely configured. In order to do that, security teams must understand the basics. First, there are too many apps and each app has tens to hundreds of settings that impact security. Second, all of the settings of each app must be understood and set correctly so they can be made compliant with industry and company policies. Third, security teams must understand the risks posed even if one setting is inadvertently left misconfigured.
To understand this better, let’s talk about a popular video conferencing app. While it seems fairly straightforward, in reality, the app has over 50 settings that can impact the security posture — with settings ranging from password requirements for meetings, to settings for sharing recordings. All these settings have to be understood from across different sections of the admin console and span multiple different documentations.
Second Pain Point: Fixing security misconfigurations in SaaS is hard—keeping them fixed is even harder.
SaaS apps are typically owned and operated by not one, but many stakeholders across the enterprise. While these teams are focused on enabling the business and improving collaboration, not all of them are fully aware of the security repercussions of the app’s numerous settings, especially when changes to the app are made without each other’s knowledge. Furthermore, stakeholders can easily introduce new SaaS and become the de facto owner even though they might not have the expert knowledge to ensure a secure deployment. In the end, the lack of coordination between stakeholders from various business units, IT, Infosec and GRC teams leads to what is known as a configuration “drift.”
The drift results in a remediation approach that is inefficient, time consuming and unscalable in the long term as more and more SaaS apps continue to get sanctioned for enterprise use. When security admins lose visibility into the changes being made to a SaaS app’s security settings, identifying misconfigurations becomes comparable to finding a needle in the haystack, and they can’t ensure it’s security. They must then perform manual app assessments to look for the possibility of a misconfiguration. As one would expect, the audit process is slow and laborious, providing only point-in-time views when hundreds of sanctioned apps are involved.
To use an example, if an app assessment took one person one week, at 200 apps, it would take 200 weeks to do a full evaluation of all apps. Even if you had four people doing app assessments every day, it would still take a full year. By the time this team gets through all the apps, they have to repeat this cycle all over again as those audits only provided a point in time assessment — if something changed, InfoSec wouldn't find out until the next review cycle.
Needless to say, there is no efficient solution in place today that automates the SaaS assessment process across several apps while continuously and simultaneously monitoring the audit.
Third Pain Point: Securing SaaS is different from securing traditional software.
The SaaS model has many advantages over traditional software, providing out-of-the-box global availability and automatic updates to the latest and greatest features. However, the very same attributes also make them challenging to secure. While traditional software is deployed from the data center, SaaS apps are directly accessible from the internet, significantly raising the stakes for any misconfigurations.
There's a good example where a popular issue tracking app gave users the option to share their dashboards with "everyone," which was misinterpreted as “everyone in the organization,” when in reality it was “everyone on the internet.”
Upgrades to traditional software are overseen and handled directly by the IT team. But SaaS apps dynamically update themselves to add new features and functionalities. The frequent updates revamp the functionality of the app but in turn affect its security. Additionally, when a SaaS app is customized, its settings no longer provide the level of security needed, thereby creating conflict with the organization’s compliance and security policies. And it's not just that customizations lead to security weaknesses — oftentimes, even default settings aren't good enough. Enterprise IT teams should abide by the core of "zero trust" and never assume that the SaaS app ships in a secure-by-default state.
Palo Alto Networks’ Approach to SSPM is Next Level
At Palo Alto Networks, disruptive SSPM is synonymous with going beyond compliance to examine all settings that have an impact on the security posture of the app. Our approach to posture security provides a complete view into all the settings that have a security impact on the app, enables single click remediation and averts drift prevention. Not only that, we believe SSPM is so important that it shouldn't be limited to a handful of apps — all of them could add risk to the enterprise — which is why we secure over 40 apps, with plans to secure over a 100 by year-end.
At the SASE Converge virtual event on September 13 and 14, we will dive deep into how our SSPM solution ensures your essential SaaS apps are bolstered and protected against dangerous misconfigurations and security hygiene issues that put users and data at risk. Join us for our session, Cover Your SaaS with the Next Evolution of CASB, at the virtual event! See you there!