Pulling Security out of your SaaS
The SaaS threat landscape
Securing software as a service (SaaS) platforms and monitoring their posture feels like an ever-changing endeavor. SaaS is an attractive option for anyone looking to offload the management and overhead of hosting an application, even if there is a commercial-off-the-shelf (COTS) software alternative. There are SaaS platforms of all hosting types, presenting applications providing services that range from email and messaging to social media and ticketing systems. When it comes to securing this ever-changing landscape, it is important to remember that most platforms provide services to our end users, and they just so happen to be our biggest threat vector.
"Cloud" changed how enterprise IT and security teams operate. That single word continues to challenge our policies, stretch our resources and expose weaknesses in our security posture. Cloud changes with no pattern and at an untenable pace, especially for those of us based on rules and standards…those of us in information security. If your first foray into cloud security was with AWS, Azure and GCP and you thought the scale of migrations, speed of change, and time required to research and review changes was bad with IaaS, I have some bad news: SaaS is MUCH worse.
Cloud makes everything easier, but with IaaS (infrastructure as a service), the journey from idea to app is not a single step. With SaaS, if you have a credit card and internet access, you have an app, and there is very little you can do to stop the consumption of it or, (more importantly) data exfil to it. This is why SaaS security should be a top priority for all Information Security departments.
Addressing SaaS threats
In general, cloud computing is about abstracting the barriers present in getting data to customers. SaaS abstracts everything, including the security of the platform, leaving everyday app administration and identity security to the customer. As mentioned before, users (including administrative users) are our biggest threat vector, and that is where SaaS security must begin.
We start at the source of the user's authentication process, their identity and the identity store. We must look at the security of the directory, the IdP integration, the roles and groups assigned, MFA requirements and more. When a SaaS platform is introduced, the IdP is integrated and the same checks are extended to include the SaaS: MFA requirements for the app, impossible travel, compromised auth token checks, over permissive roles, etc. All of which can be monitored by an SSPM tool.
When it comes to IaaS, 95 percent of breaches are due to misconfigurations and 62 percent of those misconfigurations were due to negligence*. SaaS platforms, on the other hand, present an app with only the ability to configure how we use the app and basic security controls; therefore, the risk of misconfiguration is not the same. For SaaS platforms, we must address threats to the IdP and the use of identities to change key integration and security alert functions. It is crucial to choose an SSPM product that focuses on threats and not just misconfigurations.
(We must also address the risk of users accessing unapproved SaaS platforms and tenants, often addressed with a SWG and/or a CASB. Both are outside the scope of this document.)
When it comes to SaaS consumption, perhaps the biggest threat of all is not being able to recognize a threat. SaaS platforms generate an unbelievable number of events, and some of our customers report having more than 1000 SaaS-delivered applications across their org. To add to this, every SaaS platform tied to an IdP causes the IdP to generate more events, further saturating your SIEM tool. All these apps, logging different actions from different sources tied to the same IDP, create an event storm that SOC teams become numb to. It is too many events with little to no context, and new event sources show up monthly for some customers. An SSPM can help here as well.
The more SaaS platforms you monitor with an SSPM, the more context it gains. The more context, the more it can deduplicate, prioritize and bubble up the events your SOC team needs to address first. SSPMs can be used as a SaaS event filter, ensuring only the relevant events are sent to the SIEM, reducing cost. But they are not just forwarded, they are enriched with remediation tags, IP addresses names and other data, which also increases security awareness and incident response time.
The SSPM landscape
SaaS Security Posture Management (SSPM) tools can be divided into two categories or types: standalone and SSE-reliant. Both achieve similar functionality; however, they use different technologies and approaches to get there. Standalone SSPM tools will connect to the SaaS platform and enterprise IdP to gain insights into security posture and, for the most part, remain out-of-band (OOB) so as not to disrupt the SaaS platform or the user experience it. SSE-reliant SSPM tools leverage the SSE client and the routing/filtering/proxy service to gain insight into user actions and data transmitted to and from the SaaS platforms. This activity is in-line and when combined with a SaaS platform connection, can block or prevent certain user actions.
"Which type is better?" depends on your use cases. Typically, SSE reliant SSPM tools do not have anywhere near the breadth of coverage their standalone counterparts have. On the other hand, SSE-reliant SSPMs can inspect actions and data in real-time, preventing data exfil, while the standalone tools can only report and alert after the fact.
The gap between the SSPM types becomes smaller each year with the reliant tools adding more SaaS platforms to their portfolio and the standalone tools (especially the market leaders) getting alerting in near real-time. The bottom line is the standalone tools provide more insight into posture, misconfigurations, and threats (especially identity and token-related issues) and cover more modules within the SaaS platforms, but they will never be in line with the SSE-reliant tools.
Supporting tools
It is important to note that securing SaaS applications require more than just an SSPM tool. The tools listed below are required for enterprise SaaS consumption and are used by SSPM tools to contextualize events. Without them, prioritizing risk and monitoring user behavior is difficult.
- A properly configured IdP and directory service
- Logging platform or SIEM
- EDR tool with integration capabilities
As mentioned, SaaS platforms are designed to provide services to end users and they are the biggest threat vector in the enterprise. Enterprises should plan on installing the tools below to protect data and monitor cloud platform usage.
- CASB with an endpoint agent capable of SSL inspection and tenant-based SaaS routing
- Browser isolation tool
The pivot
Most of the current data exposures and breaches originate in SaaS platforms, especially where identities are shared, yet the SaaS app is often not the ultimate target. To make things easy for our users and our application owners, security teams have approved one IdP to rule them all. That approach has not aged well. The little control consumers have over SaaS platforms does not provide visibility into authentication mechanisms, token caching and transports, and third-party dependencies.
SaaS platforms are globally available, with few authentication restrictions, and logging is limited and eventually consistent. Attackers take advantage of these observability blind spots to gather credentials and tokens for use in other, more lucrative platforms. Do not sleep on your SaaS security, it can be the gateway to your critical systems.
*This information is from the Ponemon Institute, Verizon Breach reports, Gartner and IBM