min read
May 29, 2024

SSPM vs CASB: How We Leaped Over the Chasm

SSPM vs CASB

When you hear the word “identity” mentioned around the DoControl offices, it’s usually someone talking about end-user identity, identity security, identity threat detection and response, or some related SaaS security topic. 

A few months ago, however, “identity” was the topic of conversation at DoControl, and it wasn’t referring to any of the above subjects. It was about OUR identity. About identifying as a SSPM vs CASB. About what DoControl is - and about what we could be. 

Having made it through that period of identity-searching, we thought it was time to share some of our takeaways. Here’s how we went from defining ourselves as a CASB to a SSPM solution, what that entailed, and why we did it. 

DoControl’s CASB origins

DoControl was born years ago after our founder Adam Gavish was witness to how the data cybersecurity standard bogged down the rapid sharing, productivity and collaboration of SaaS. (And this was what Adam experienced working at Google, the tech titan! So how much worse it must be everywhere else!) 

Of course SaaS data assets needed protection from security risks, threats and vulnerabilities. The rapid adoption of SaaS applications, proliferation of data assets, and interconnectivity between SaaS systems make SaaS a top target for attackers

But SaaS was being “protected” by cloud data protection mechanisms that weren’t designed for SaaS, observed Adam. 

Broad-sweeping information policies frustrated business users and generated irrelevant security warnings or delays for the security team. Risk detection and remediation lagged behind the pace at which SaaS assets were exposed.

A next-generation CASB (cloud access security broker) was needed - and fast. 

DoControl was built expressly for SaaS security, as a smart tool that understands what information is being shared through a SaaS application, the identities and roles of the people being shared with, and the relative sensitivity of the information. It was a CASB designed for modern, pervasive SaaS and could therefore keep up with the pace of SaaS data change and exposure. 

Since the biggest and most exploitable attack surface in SaaS is the data, DoControl focused on protecting data assets, leveraging user identity and business contextual information for enriched understanding. Third-party connected apps also became a key focus of DoControl’s advanced CASB solution.

That was our identity: a next-generation CASB. We had achieved a great thing for SaaS security: risk identification and remediation that is proactive, transparent, automated and functions in real time. We should be satisfied, right?

But… the only thing constant is change

The same trait that led to the birth of DoControl - not being satisfied with the status quo when we see there’s something lacking - kept us from sitting on our laurels. 

As SaaS evolved, we saw how other aspects of SaaS systems were becoming critical attack surfaces, specifically:

  • SaaS identities
  • SaaS configurations

If our clients are coming to us for SaaS security, we mused, then we should provide them with a next-generation solution that covers more than just a partial list of attack surfaces (no matter how well it does that). It should provide everything they need to secure their SaaS. 

Which new pieces of the SaaS security puzzle did that entail developing solutions for?

SaaS identities from a SSPM vs CASB perspective

In DoControl’s role as a CASB, SaaS user identities played a very important role. It was, however, a supporting role for the lead role of data assets. 

As a CASB, DoControl evaluated potential risk from the asset perspective: Did it make sense for this asset to be interacted with (e.g. viewed, edited, shared) in this way?

In order to answer that question accurately, DoControl’s risk evaluation took into account the user identity which had performed the interaction, analyzing aspects like:

  • what level of access the identity has
  • the identity’s department, group or role and whether this asset interaction would be normal for those groupings 
  • the identity’s HR status and whether that calls this asset interaction into question

But risk detection and remediation was always about securing the data asset. 

SaaS identities, however, are their own attack surface. In a SaaS environment, after all, all access is dependent on identity. If you can make the SaaS ecosystem think that you are Jane Doe, you’ll have free and easy access to everything that Jane Doe has access to. No need to search for vulnerabilities or sneak around firewalls; with the right user identity, locked doors will open at your touch.

It’s unsurprising that over the past 10 years, user credentials - stolen, stuffed, brute-forced or otherwise - were involved in about a third of all data breaches analyzed in this Verizon report.

In order to give our clients full SaaS protection, therefore, we needed to develop and integrate best-in-class ITDR (identity threat detection and response) tools, including:

  • User identity behavior benchmarking and anomaly detection
  • Identity risk profiles
  • User-level remediation: permission changes for assets and apps on a per-user basis

Configurations: the foundation of secure SaaS

Configurations in SaaS are not as large an attack surface as they are in PaaS or IaaS, because the provider takes care of many of the higher-level configurations. But when it comes to SaaS security, we felt, even a small attack surface is too big.

As seen by programs like the SCuBA (Secure Cloud Business Applications) Project, the US government feels strongly enough about secure SaaS configurations to develop entire frameworks.

To close this SaaS security hole for our clients, we would need to integrate the capabilities to:

  • Compare SaaS applications’ configurations to the app provider-recommended settings, industry regulatory requirements or industry best practices 
  • Make and implement recommendations to remediate configurations
  • Monitor and alert to configuration drift

Was this critical? Were these changes and additions necessary? Did they reflect our goals and who we are at DoControl? 

Do we see ourselves as a CASB or as a full SSPM (SaaS security posture management) solution?

Those are the questions you would have heard echoing in our office corridors months ago.

SSPM vs CASB: DoControl identity redefined

After SSPM vs CASB discussions at the watercooler and SSPM vs CASB debates in the boardroom, we emerged with a new definition of DoControl’s identity: a next-generation, best-in-class SSPM. 

Our decision was to integrate these Identity and Configuration security aspects into DoControl. 

Like everything else about DoControl, these pieces would be designed for the scale and pace of the modern, pervasive SaaS environment

  • A user identity interacts with a SaaS asset in a suspicious way? Their identity risk profile is immediately updated to reflect the increased risk. 
  • A connected SaaS app changes a SaaS configuration away from the recommended setting? Automated workflows commence immediately to notify information security teams and/or to remediate the configuration drift.

More than anything else, we discovered, the identity of DoControl is to keep pushing the limits on what’s possible for SaaS security. 

For now, that led us from being a next-gen CASB to a cutting-edge SSPM. For the future? Only time will tell.

Get updates to your inbox

Our latest tips, insights, and news