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.
The lack of operational visibility has historically been an unaddressed gap in SaaS security.
So You Want to CDR
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.
STEP 1: Data Aggregation
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.
STEP 2: Data Normalization
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.
STEP 3: Enrichment
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.
STEP 4 Analytics
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.
Should You Do It?
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.
- Are you ready to invest in ongoing data engineering? CDR has a lot of external dependencies on third party APIs. Your team needs to stay on top of changes and fine tune extraction frequencies and data architectures. You also need to monitor and troubleshoot data extraction failures.
- Are you willing to wait for months to build every app integration? According to CISOs we have spoken with, each new application requires several months of development and testing. Engineers need to understand the SaaS application’s identity and access model, API structure and quirks. Even with tools like Splunk that offer integrations with popular SaaS applications, you need to normalize and enrich the data.
- How will you handle team churn? We have seen many successfully operating security projects go into disrepair when a key engineer or architect leaves the team. Maintaining a software project like this requires planning for organizational transitions. Will the project be an investment priority in the years to come? Keep in mind that you are taking on the risk associated with a big software project.
- Do you have security experts with cycles to spare? With an in-house solution, you are starting with a blank slate when it comes to security detections. You need security experts to spend time in the data to do threat hunting and building new detections of policy violations, suspicious insider activity, data exfiltration, and other threats. With new threats emerging every day, security teams will need to do this on an ongoing basis.
- Does your environment have special needs that a turnkey solution cannot address? Before committing to the heavy lift of building your own DIY CDR capabilities, take a look at what third party CDR solutions like Obsidian offer. There are many benefits to using an API-based SaaS-delivered solution. You can get started in minutes and use out-of-the-box detections and alerts to improve your security almost immediately. With a trusted solution partner, you get an engineering team that is dedicated to doing the work of keeping up with API changes and building new integrations and security alerts. You are not taking on any additional software risk. Your team can devote their attention to protecting their users and data rather than maintaining security software.
Conclusion
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.