An essential component of enterprise security, a CASB functions as a broker or a middleman between enterprise business users and the cloud applications provided by Software-as-a-Service (SaaS) providers. Placed between an organization’s network security architecture and the third-party SaaS vendor’s environment, a CASB secures the flow of data between the two ecosystems in accordance with the enterprise’s security policies.
CASBs have been on the market for nearly ten years, and in a cloud-driven world, have undoubtedly become vital to enterprise security, allowing businesses to protect and govern the usage of SaaS applications to a considerable extent. Nonetheless, at a time when the rapid adoption of software-as-a-service (SaaS) is radically changing user access patterns and levels of security risks in cloud-driven enterprises, can legacy CASB’s be trusted as before to provide holistic visibility and security policy enforcement that keeps pace with the SaaS explosion?
With countless SaaS apps moving to the cloud and business user mobility becoming ubiquitous like never seen before, the way SaaS security is delivered through CASBs must also change. And to that point, much like any other technology, legacy CASB technologies present notable drawbacks that demand a departure from their inherent operating models.
Let’s explore the point I’m making in greater detail:
- Like most emerging technologies, legacy CASBs are layered into existing environments. Since CASBs are architected in the cloud and independently managed as standalone solutions that remain detached from the organization’s core security architecture, they create operational complexity downstream for security analysts and practitioners who are required to synchronize their data protection and security policies across a separate layer of the stack.
- Legacy CASBs are deployed differently depending on the use case. For inline control and visibility of SaaS applications’ usage, a forward proxy and a reverse proxy deployment is required. Reverse proxies lack visibility into unknown, unsanctioned applications because their implementation takes place in front of known applications. Forward proxies do provide visibility into many applications whether sanctioned or not but this model requires log collectors, PAC agents and traffic to be routed from users through the CASB before reaching the application. An additional issue with the proxy model is that visibility is limited to web-based protocols only.For applications sanctioned by the organization, legacy CASBs can also sit out-of-band and use API integrations to exercise granular control and enforce data security policy within the application itself. But inline threat prevention and policy enforcement is not possible in this model.
- Signature-based approaches of legacy CASBs rely on static application libraries. They lack a large dataset required to crowdsource intelligence that enables security teams to understand the risks from emerging apps before they become a problem. Manual assignments of SaaS application signatures simply can’t keep pace with the growing rate of SaaS apps and the risks involved. The resultant gap delays the identification, evaluation and control of all the cloud apps in use, whether sanctioned, tolerated or unsanctioned, preventing security teams from preventing SaaS related risks and enforcing security policies in a manner that is timely.
- Legacy CASB’s don’t provide an amalgamated data protection policy that enforces protection for sensitive data for the entire enterprise bound to compliance regulations. As a matter of fact, the overlap of CASB and data security has given way to an additional element of confusion with CASBs being increasingly positioned as self-contained DLP tools. While more and more data now resides in the cloud, a significant percentage of enterprise data still remains on-premises and flows through user devices. A DLP approach too heavily weighted towards only CASB can reduce the effectiveness of data governance, compliance and security. Trying to create consistent security policies across a standalone point control such as a CASB that delivers autonomous data loss prevention for cloud applications, and trying to replicate them through other DLP control points through the network, remote connections and endpoints is inefficient, time consuming and can be prone to errors.
- Legacy CASB’s don’t support simpler and leaner deployment as they require log collectors, proxy auto-configs (PACs) and other components to add significant deployment and management complexity that eventually leads to a lower return on investment (ROI) and a higher total cost of ownership (TCO) for the enterprise. In fact, transforming a CASB from a go-between to an integrated technology can result in higher operational efficiency, faster deployment, and a much lower TCO compared to a legacy CASB.
A fresh approach to CASB is what enterprises need today to be in lockstep with the exponential growth of SaaS. Palo Alto Networks’ SaaS Security represents an updated approach to CASB, designed to align with these changing enterprise needs. Through integrations with Palo Alto’s cloud, software, and appliance-based next-generation firewalls and its cloud-delivered enterprise DLP, SaaS Security provides a simpler and more cost-effective approach to CASB, while maintaining the broad application visibility and accurate threat and content inspection organizations require to secure the usage of cloud applications.
For an in-depth analysis by senior analyst John Grady (ESG Global) on how our integrated CASB addresses core cloud application challenges most organizations face today, get a copy of the "Evolution of Cloud Access Security Brokers" white paper.