Imagine you’re a photography buff in the market for a new camera. When you mention this to a friend who is not into photography, they respond: “But your smartphone has a camera. Isn’t that enough?”
NO! (But try not to yell at your friend. They don’t know any better.)
When any product or service tries to be a catch-all solution, inevitably many of the individual parts will not be as good as a dedicated solution for just that aspect. A smartphone’s camera will not be as good as a high-quality dedicated camera - and the more you know about photography, the more you’ll appreciate the difference.
When you’re in the market for a CASB, it’s tempting to settle for the CASB bundled with your SASE. But you will inevitably get a less effective CASB that way. And if your CASB is intended to protect your SaaS data, you may end up creating more problems than you solve. To explain why, let’s delve into the differences between a dedicated CASB vs SASE that includes a CASB.
First, a little bit of technical background. (If you just want to cut right to the comparison of dedicated CASB vs SASE with bundled CASB, you can skip this section.)
A cloud access security broker (CASB) is a security policy enforcement solution for data moving through cloud applications. CASBs monitor user access and behavior, detect and protect against data exfiltration or exposure, and often also protect against over-permissioned or data-leaking OAuth apps.
Secure access service edge (SASE) is a service that provides network capabilities with built-in security features. Security aspects of SASE include:
SASE evolved out of the convergence of vendors who offered the individual parts. It made sense - and was usually economical and convenient for customers - to offer them as a bundle.
Now, sometimes interdependence can create synergy. Other times it can hold back the development and potential excellence of the dependent parts. For any developing SASE solution, effort usually goes into helping the system as a whole get better while keeping all the parts compatible. This often means, however, that no individual part can be kept at the cutting edge of technological advancement.
When comparing a cutting-edge CASB vs SASE with CASB included, it becomes obvious that the SASE’s CASB is based on older technology that can’t keep up with the pace of data flow in SaaS. And if you can’t keep up with moving data, you definitely can’t secure it.
The technology lag of the standard SASE solution’s CASB is evident in two primary areas:
How does a CASB monitor the data flowing from users to cloud applications? One option is to use an inline, proxy-based architecture. An inline CASB acts as a virtual security checkpoint. All data must go through the CASB and be checked to see that it does not violate any security policies.
The benefit of inline CASBs is that they work in real-time, ostensibly stopping problems before they turn into threats.
The problem with inline CASBs is that they weren’t built for SaaS data scale and speed. Inline CASBs use the SASE’s SWG proxies as the “checkpoint” where data needs to undergo inspection. But SWG proxies were designed to secure web browsing sessions, not SaaS. Modern SaaS platforms create 10 to 25 times the number of unique sessions that web browsing does!
When you try to use inline, proxy-based CASBs to secure SaaS systems and assets, you get sluggish SaaS. And then you get irate users, because the whole point of SaaS is speed, efficiency and productivity!
If you don’t want to slow down your SaaS data flow to an unacceptable pace, the other common deployment method for a SASE’s CASB is to use a traditional API-based architecture.
Traditional API CASBs have a “pull”-style architecture. They poll the SaaS application at regular intervals (ranging from seconds, to minutes, to hours, or even to days and weeks) to “ask” which files have changed and then to request the contents of those files.
While this doesn’t slow down the speed of data flow, it does slow down the pace of detection. The time gaps in between pull windows create outdated pictures, where information security is unaware of what the attack surface currently looks like. And by the time they do get an updated picture, corporate and customer data may have been overexposed for long enough to do damage.
Is the answer to run API queries every few seconds? Well, just as the proxy-based CASBs weren’t built for SaaS data scale, neither were traditional API-based CASBs. APIs have rate limits for event queries. The average SaaS user creates 467 unique SaaS events per SaaS app per day. The more frequently you run event queries in order to stay on top of the changing data (and the more events there are for the query to return), the faster you will run up against the rate limit.
The standard SASE solution’s CASB bases its detection of data exposure on traditional DLP (data loss prevention). Data assets are scanned for sensitive content either at the moment of potential exposure or in advance, and the relevant policies applied.
There are two problems with this situation. The first is speed. The second is accuracy.
Scanning the complete content of assets is slow. If it is done at the moment of potential exposure, it will delay the actual sharing or downloading for longer than is acceptable for the SaaS user experience.
If scanning is done in advance and sensitivity labels applied for evaluation at the moment of potential exposure, you run the risk of the content changing in between the last scan and the actual share. In a SaaS environment, the assets (and therefore the attack surface) are changing constantly. And the more frequently you check for changes, the more likely it is you’ll run up against the API rate limit.
Traditional DLP also has a significant chance of returning inaccurate results, reporting both false positives and false negatives. False negatives mean that real security issues slip under the radar. False positives mean wasted time chasing shadows for information security. In addition, too many false alerts create alert fatigue, leading again to real security issues being missed.
While many independent, non-SASE-linked CASBs also labor under the limitations described above, there are dedicated CASBs that have moved into the next generation of data protection.
These next-gen CASBs are designed for the fast-paced environment of SaaS applications, building on deep knowledge of SaaS rate limitations, data modeling and permission models. They provide fast and highly scalable detection and remediation.
The SASE-based CASBs fell short because of their architecture and threat detection mechanism; these next-gen CASBs succeed because of theirs. Let’s see why:
Instead of polling the SaaS applications for changes (as in the pull-style API described above), event-driven architecture has the SaaS applications themselves sending updates to the CASB whenever any significant event (e.g. viewing, editing, downloading, sharing) happens to any SaaS asset.
Because the SaaS applications are sending change data instead of being asked for data, the API query limits are not a hindrance. And because the changes are reported as soon as they happen instead of waiting for the next polling interval, the CASB’s awareness of the changing attack surface is near real-time.
A CASB with this type of API architecture can detect and respond to emerging threats much faster than one with a “pull”-type API architecture.
Next-generation CASBs like DoControl have and use traditional DLP scans - but they are not restricted to DLP and its limitations.
These advanced CASBs can analyze and act based on multiple contexts that could indicate an information security issue, including:
The ability to take all these data, identity, business and security contexts into account makes these dedicated CASBs much faster and much more accurate.
If you understand photography, you won’t be content with the camera in your smartphone. And if you understand information security in the age of SaaS, you can’t be content with the CASB that comes bundled with your SASE.
Take a hard look at the capabilities of a next generation CASB vs SASE with CASB included - and make the choice that will truly protect your SaaS data assets.
.webp)
Research-based benchmarks to assess risk across critical threat model
Discover why sensitive data discovery tools often trigger false alarms, causing frustration for InfoSec teams. Learn why this happens and how to find tools for accurate detections.
Learn about the three primary types of Zoom vulnerabilities: in-meeting, data storage, and system access risks. Safeguard your organization effectively against these threats.
SaaS solutions are integral for workflows, granting anytime access to critical data. Yet, without robust SaaS Access Control Management, businesses face significant security risks.
