4 Reasons CASB Fails

You are moving to business-led IT and modern work. You want a true security solution that adapts to shifting SaaS requirements, centered on the four key verbs of SaaS security—discover, prioritize, secure, and orchestrate. It’s only natural to presume the best place to start is with a cloud access security broker (CASB).

CASB makes SaaS security available for managed applications and managed devices for approved cloud and SaaS apps. This helps control SaaS risk as it funnels users through infrastructure (hardware and software) gateways that give the CASB an opportunity to enforce security policy, authorization, and authentication. Channeling users through CASB mechanism is the key design element (i.e., security architecture) that defines the means and methods CASB uses to secure SaaS apps. 

This CASB playbook has failed. It failed to live up to the hype, punctuated in the era of business-led IT and modern work when CASB is undermined by cold, hard reality.

If the playbook would have worked, the playbook would have worked. It hasn’t worked. Not for lack of trying, but the game changed when the internet became the new network and identities became the new enforcement point—and the CASB playbook has no answer for it.

‍

CASB Playbook: 4 Reasons the CASB Playbook Fails

‍1. Discovery. CASB discovers logs and events, not User-SaaS relationships.

The CASB playbook depends on events generated as users pass through the CASB infrastructure. If a user is accessing a potential SaaS application, after traversing through CASB proxies, an event or log indicates a user-SaaS connection.

CASB discovery fails because of its design that does not account for the way SaaS is consumed in today’s enterprise. In 2021, 83 percent of organizations reported the value of business-led IT strategies—characterized by business teams identifying and sourcing technology, especially SaaS. And in 2022, 36 percent of SaaS spending was outside core IT budgets, selection, procurement, support, and security oversight.

The CASB playbook for discovery has failed. Not because of anything malicious or careless, but simply because what ‘SaaS’ means today is not what it meant in 2012. In 2012, the SaaS attack surface meant Salesforce, Office 365, and Box—many of which are still with us. Today, the SaaS attack surface means 1,100+ apps in the average enterprise, hundreds of duplicate passwords, and 60 percent of apps wholly outside of IT control.

The CASB playbook failed because the game changed—pause to consider what we once called shadow SaaS is now a business strategy called business-led SaaS—leaving CASB with an impressively inaccurate base rate, blind to most of the real-world SaaS attack surface.

2. Prioritization. CASB prioritizes what it knows, ignoring everything else.

As with discovery, the CASB playbook is confined to what it can route through its infrastructure dependencies. This design flaw gives CASB the bias to seek and destroy, taking what limited SaaS it sees as something to curtail, block, stop, or restrict with more of that infrastructure CASB depends on. And at the same time CASB is hyperactively alerting on user activity and hand-slap-stop enforcement for apps it can see, work-from-home and work-from-everywhere transitions put users completely outside the CASB lens—it simply does not know and cannot prioritize relevant SaaS risks.

CASB prioritization fails because it is blissfully unaware of the greatest SaaS security risk—business-led SaaS that accounts for more than 60 percent of the SaaS attack surface. If CASB ignores 60 percent or more of SaaS apps accessed directly, outside of CASB controls, then it is clear that CASB priorities are meaningless and barely relevant to my real-world SaaS attack surface.

3. Secure. CASB protects pathways, not people.

CASB secures predictable situations with managed devices, clouds, apps, and employee users. The game changed with the onslaught of modern work and shifts in how people (not devices) access SaaS applications.The hypothetical world of CASB security may exist in analyst reports and academic theory, but in practice, dramatic holes plague nearly every CASB deployment.

In the imaginary world depicted by CASB vendors, no one accesses SaaS apps outside of network infrastructure (cloud or on-prem) and every device is under lock-and-key. A lot of things must go ‘right’ for CASB to secure even potential pathways to SaaS apps:

a)    all clouds and SaaS apps are approved and/or sanctioned

b)    all SaaS apps are accessed from managed devices by employee users

c)    identity providers managed identities, with more help from EDR, EPP, and UEBA

d)    all user traffic is routed through secure web gateways (SWG) or proxies (forward and reverse)

e)    unchanging SaaS inventory, no churn (turnover) for apps or users

CASB is designed and deployed for approved clouds and apps on managed devices running through secure web gateways (SWG), forward or reverse proxies, and unnatural user-SaaS behavior. Unnatural user-SaaS behavior? Yes, in 2022, it is unnatural for users to access SaaS through gateways artificially constructed in the internet. CASB built an extravagant seat for the wrong parade—the real action is happening elsewhere, but it’s too late,CASB is locked in for life, inert to secure most user-SaaS relationships in the real-world SaaS attack surface.

CASB’s own design interferes with its ability to deliver meaningful SaaS security. This makes it clear that SaaS a CASB can secure it does so by accident.

4. Orchestrate. CASB fails to deliver secure SaaS lifecycle.

For anything transitioning through a lifecycle, there is a necessary start and finish—birth and death, cradle and grave. These two ends of the process are precisely the moments in the secure SaaS lifecycle when CASB fails to deliver. For starters, if you deployed a CASB today, provided you have millions in loose funds and a team of security engineers to babysit it, the best you could hope for is visibility to SaaS apps used today on managed devices in approved clouds.

What about SaaS used in the past? CASB is unaware of SaaS before it showed up, and this leaves thousands of users for hundreds of apps with dangling access, zombie accounts, and duplicate passwords—all invisible to CASB. This makes it clear how the CASB playbook fails at the beginning of the lifecycle. What about the end?

CASB fails to effectively off board most SaaS users and decommission most SaaS apps, because of the lopsided ratio of SaaS estate. Most SaaS apps are accessed by users outside of CASB control, creating a whole new challenge to operate two SaaS lifecycles—inside of CASB for traditional apps, roughly 40 percent, and manual outside of CASB for the other 60 percent.

What?!? Spend millions, hire teams, demand unnatural architecture and user behavior, invest in infrastructure dependencies, hold onto tech debt, and….drum roll please, you might get 40 percent of your SaaS securely off boarded and decommissioned.

The CASB playbook fails to orchestrate and enable the secure SaaS lifecycle, because it missed most of the SaaS it is designed to protect.

Conclusion

After a decade of CASB deployments, iterations, enhancements, and acquisitions, we still find 6-out-of-10 security leaders do not trust CASB to secure SaaS apps. As I said at the beginning of this post, the game changed and the CASB playbook has failed to achieve real-world SaaS security for the real-world SaaS attack surface. If the playbook doesn’t work, it’s time to do something different. The same can be said for SASE and similar software.

The CASB playbook failed, and along the way became alienated to the very problem it was intended to solve—mitigate the risk of cloud services threatening the organization. And the way CASB solves it comes from where the world was, not where it is going.

The SaaS Security Control Plane

A better approach to SaaS security is a control plane, designed and deployed for modern security architecture. A SaaS Security Control Plane (SSCP) is an essential element of modern security architectures—identifying risks and threats within the SaaS estate and orchestrating security throughout the SaaS lifecycle. It allows security teams to discover, prioritize, secure, and orchestrate SaaS security across multiple systems and control points, for both core-IT and business-led SaaS.

Today’s business-led IT strategies demand an architectural rethinking, one that ensures SaaS can be secure everywhere and on-demand, past, present, and future. To do that, it is necessary to inject the essential architectural element to secure modern work—guided by the true North Star built for the real-world, and the world it will become.

Get started with a free SaaS risk assessment -- it's time for a new playbook for SaaS security.

‍