The acceleration of digital initiatives and SaaS adoption is raising concerns around SaaS security. CISOs realize that their technology stack will increasingly rely on SaaS. They expect their teams to be able to answer questions about SaaS risks, threats, and breaches — which accounts are compromised, which files are shared externally, whether there are unused admin privileges that can be removed, etc.
To effectively detect, hunt, investigate, and respond to cloud breaches and threats, threat-focused security teams need data. Just as endpoint detection and response (EDR) gives security teams the telemetry, contextual visibility, and automated detection capabilities they need to protect endpoints, SaaS security requires continuous, unified visibility and analytics for SaaS apps. The lack of operational visibility has historically been an unaddressed gap in SaaS security.
Security teams in more mature, SaaS-forward organizations built SaaS telemetry capabilities in-house by aggregating activity logs from SaaS applications to a central data lake or SIEM. Now, with turnkey cloud detection and response (CDR) solutions available, the question arises, should you continue to invest in building and maintaining your own CDR technology stack? And if you haven’t started down this path, is it an option worth pursuing? To answer this question, let’s first look at what it takes to build CDR capabilities in-house, then using that information, we’ll consider whether or not to go with a DIY approach.
Any team getting started with SaaS security is going to have to consider the same broad steps to begin to think about detection and investigation in your SaaS environments. This section provides a quick walkthrough of what’s involved.
The first step is to consolidate data from SaaS applications that you want to monitor. Most widely used SaaS applications provide API-based access to extract data related to accounts, privileges, roles, and activity. But each app has a custom API schema with rate limits. While some APIs are well architected and stable, others have serious limitations and may change frequently.
You need to extract data about accounts, privileges and roles (access data), events (activity data), and service configurations. Fetching this data will require multiple API calls. The data needs to be collected and stored centrally for analysis. Data lakes like Snowflake and SIEMs like Splunk offer good options for storage.
You have two options when it comes to data extraction: 1. Some of the leading SIEMs offer connectors that make it easy to dump logs from SaaS apps into the SIEM; 2. You can build your own connectors. To do this, you need to take into account the API design, lifecycle, and rate limits in designing the ingest.
Just dumping raw data from SaaS apps into a SIEM or data lake as a stream of JSON blobs is of limited use. A SIEM is an agnostic event aggregation and correlation engine. While some SIEMs may provide connectors for SaaS applications, the extracted data still needs to be cleaned and normalized. Activity data across services exist at different levels of granularity and uses platform-specific labels and nomenclature. So once the data is aggregated, it needs to be normalized so that a security analyst or incident responder is able to understand and use the data for detections and investigations, without worrying about all the nuances and application-specific differences. This requires you to create a platform-agnostic data model that makes it easy for security analysts to explore and analyze privileges and user behavior.
Data from different applications varies in the amount of context available. Enriching raw data with information about geolocation, ISP, user agents, threat intelligence, etc. is the next step. Tying a user’s accounts and privileges with their activity in cloud applications can be useful for detecting signs of suspicious activity and insider threats.
After centralizing and cleaning the data, the security team needs to be able to interact with it in order to obtain insights and value. This is where questions need to be asked around workflows and use cases. What types of threats is the team looking to detect? How can this accelerate incident response? Will this dataset enrich alerts and events from other parts of the security stack?
Regardless of the answers to these questions, it is likely the team will want to detect multi-event activity such as unusual login events, inspect spikes in activity related to file downloads or uploads, and audit administrator-level activity.
Malicious activity in SaaS applications don’t generally have simple indicators of compromise such as IPs or domains that represent command and control infrastructure, so most detection will require much more than simple queries for individual events, increasing the level of effort to detect.
Furthermore, teams will want to see activity as a timeline of events for triage and investigation situations. From a technical perspective, design decisions need to be made on how queries and jobs are executed against the dataset, as well as how analysts and investigators interact and pivot through the data.
Cloud detection and response offers powerful benefits for securing SaaS applications, but as we just saw from the brief conversation in the previous section, building and maintaining a system for CDR takes time, effort, and expertise.
So here are some questions to ask yourself if building CDR capabilities in-house is right for you.
Data is at the heart of SaaS security. As organizations increase their reliance on SaaS applications, security teams need continuous, unified visibility to detect, investigate, and respond to breaches and threats. While in the past these teams had to build their own detection and response capabilities for SaaS applications, turnkey cloud detection and response (CDR) solutions are now available that make the process of aggregating, normalizing, and analyzing the data easier, allowing security teams to focus on protecting their organization’s critical assets.