Cloud Access Security Brokers are becoming increasingly important to enterprises as these businesses adopt an increasing number of cloud applications and services. Many vendors offer out-of-the-box support for a handful of the top cloud services (like Box, Dropbox, Salesforce, G Suite, Microsoft Office 365), but have not extended native support to “long tail” cloud apps. With enterprises using applications beyond the market leaders, how can a CASB vendor grow revenue and gain a competitive advantage in the market by natively supporting more software integrations?
Definition of a Cloud Access Security Broker (CASB)
A CASB provides usage visibility, data security, and threat protection for your business’ cloud apps. It can be a cloud or on-premises software service that sits between cloud service providers and their consumers in order to insert the business’ security policies in real-time as activity occurs and resources are accessed.
With enterprises adopting cloud services at an accelerating rate, the need to secure the data and access to these cloud services from users both within and outside the organization is also growing rapidly. Examples of enterprise cloud services include Microsoft Office 365, Box, Salesforce, and Amazon Web Services (AWS).
When compared to securing legacy on-premises software, securing cloud services has two major challenges: awareness and control. Hence, the primary needs driving the growth in demand for CASBs are data loss prevention (DLP), real-time activity monitoring, and increased regulatory and data privacy requirements. Gartner expects that by 2022, over 60% of enterprises will use a CASB to govern some cloud services, up from just 20% in 2018.
Some of the key players in the CASB market include McAfee, Symantec, Netskope, Bitglass, Microsoft, Proofpoint, Cisco, and Palo Alto Networks.
The Proxy approach vs. the API approach
There are two primary CASB deployment modes today: the Proxy approach and the API approach.
A CASB deployed in the Proxy approach is also referred to as “inline.” It sits in the middle of the traffic from end user to cloud service, checking HTML-based traffic through a gateway. This enables the CASB to take security action in real time, but it can only secure known users.
The API approach does not sit in the traffic path of end user to cloud service or cloud service to cloud service. Instead, it uses asynchronous, out-of-band APIs to retrieve cloud service traffic such as user activity, files and objects, and configuration states for the CASB platform to analyze and take the necessary security actions.
While both approaches have their positives and negatives, the API approach enables the tightest integration with the cloud services that the CASB is protecting. It can secure both managed and unmanaged cloud services, leaving no security gaps.
Ultimately an enterprise will require both Proxy and API deployment modes in order to get comprehensive data security coverage. However, given the increase in application adoption across businesses of all sizes, the API approach provides the greatest immediate ROI by offering the most robust security coverage of all cloud apps, regardless of whether they are managed or not.
Growth in application adoption necessitates the API approach
In Okta’s 2019 Businesses @ Work Report, they found that enterprises have increased their application adoption by 68% over the past four years to a total of 129 apps per company in 2018. Small and Medium Businesses increased at a 38% growth rate to 73 apps per company.
Businesses of all sizes are using an increasing number of applications. This poses an accelerating challenge for CASB vendors and their customers.
From the buyer’s perspective, enterprise IT and InfoSec teams need to build support across business units when selecting a CASB. This includes aligning on not only governance and defined processes (data classification, metadata, labels, etc.), but also generally making sure that the BU’s apps are supported out-of-the-box by the CASB vendor.
For the CASB vendor, this means figuring out how to natively support the cloud applications that customers want. Most vendors offer out-of-the-box integrations for a handful of the top cloud apps. But what if a customer is using a cloud service that is not natively supported?
As a solution for this, some CASB vendors offer an “Any App” connector for their customers to build in support for any cloud application. In their 2018 CASB Magic Quadrant, Gartner notes that modifying a default “Any App” connector or writing a custom plug-in is often complex and requires professional services. Some methods for supporting custom applications are not viable long-term solutions as applications change over time.
The best-case scenario for buyers is for CASBs to provide out-of-the-box support for every cloud application and service used in the enterprise. However, it’s very costly for CASB vendors to integrate hundreds of APIs one by one and maintain all the bespoke connections.
A better way to natively support what the customer needs
Kloudless helps CASB vendors deliver all the integrations that their customers ask for without building and maintaining each one individually. This greatly reduces time-to-market, engineering costs, and the risk of APIs changing in the future. Using our Unified APIs, CASB vendors can code once and integrate many applications at once.
We provide solutions that are designed for CASB use cases:
- Activity monitoring – Real-time event notifications via webhooks for user activity (like creating, modifying, or deleting resources) and Audit Events for all users in an organization
- Remediation – Access/modify/delete files, folders, and objects
- White-labeled user experience – We built Kloudless to be embedded in your product, so your customers won’t even know we’re there.
- Self-hosted, on-premises – Run Kloudless privately as Docker containers, OVAs, or AMIs to meet performance and compliance requirements.
To learn more about how Kloudless can help your CASB offering stand out in the market, talk to an expert today!