The amount of misinformation being thrown around regarding cloud security tactics is staggering enough – and potentially dangerous enough if the falsehoods are not exposed – that someone has to say something.
With Cloud Access Security Brokers (CASB) being top of mind for many security professionals, many are aware of the range of approaches and strong opinions associated with the two major camps: 1) Proxy- and Gateway-based CASB solutions and 2) API-based CASB solutions.
Proxies = Network-Centric Security
There is a persistent – and inaccurate – notion that the corporate network is the major source of concern for security professionals. But the network-centric view of security is myopic and ineffective. Why?
- The volume of programmatic API traffic (cloud-to-cloud traffic, such as Marketo pushing data to Salesforce) outnumbers interactive user traffic.
- Most corporate data today is not on the corporate network. The majority of activity is happening outside the corporate network – think of business partners, unmanaged devices, or mobile apps with hardcoded URLs that cannot be rerouted.
- The notion that corporate users can be forced to go through a proxy or gateway should be thrown out of the window. When inconvenienced, users will just find a find away around it.
The Proxy Coverage Myth
While proxies can analyze and govern some traffic, they miss the majority of corporate traffic. In fact, proxies only secure a subset … of a subset … of a subset … of a subset of traffic.
While you’re rereading that sentence (it was four subsets), another one of your users enabled a third-party cloud application and granted permissions for it to view, edit, manage, delete, and share all of their records (and, yes, a proxy would miss that).
Proxies only inspect traffic if it meets four specific criteria:
- The traffic is in-transit (not data already at rest within cloud applications), and
- the session is being conducted by a managed users, and
- the session is occurring on a managed device, and
- the traffic is traversing the corporate network.
More than likely, organizations already have a solution for this traffic – a firewall.
Ironically, Proxies Decrease Security (and Functionality)
Adding a new layer into the stack always raises questions around the security risk versus reward balance. This is particularly true when a security startup is wedging themselves between users and a well-established cloud platform, as proxies do.
The reality is that cloud platforms are – more often than not – highly secure. Companies like Salesforce and Google make massive investments in security. Security startups that intercept and decode communications are likely to interfere with the inherent security of these services, while introducing new vulnerabilities of their own.
Additionally, proxies introduce negative performance issues, often breaking search and reporting functionality and preventing cloud software updates. These interruptions frustrate end users and make cloud platforms appear slow or buggy along the way. The performance downside counteracts the potential security gain. And again, it’s not you shouldn’t use a proxy – you already have an effective one in the form of a firewall.
Cloud Application Providers Don’t Buy The Proxy and Gateway Snake Oil
Don’t take our word for it. Google offers the following perspective in their “Networking Best Practices for Large Deployments” guide:
- “Avoid routing Google Apps data through a proxy that inspects the content of HTTP traffic, because this will reduce performance, and a great deal of Google Apps content is dynamic or encrypted…” (P. 10)
- “..We recommend that you do not route Google Apps traffic through a proxy server..” (P. 24)
- “..Avoid SSL inspection if possible. SSL inspection is effectively an SSL “man in the middle attack” on your own users to examine the contents of HTTPS traffic…” (P. 26)
And Google is not an exception: any security solution interfering with a platform’s built-in security or functionality is subject to question.
The Cloud-Native Approach to CASB
A philosophically different approach to cloud cybersecurity exists: Cloud-Native CASBs using the API approach, offering organizations a number of benefits:
- Achieve superior (and complete) coverage – monitor and protect traffic of all kinds, regardless of whether it is programmatic (cloud-to-cloud) or interactive (live user), from a managed or unmanaged user, on a managed or unmanaged device, from a web app or a native app, or at rest within the platform. Even historical data can be monitored retroactively via APIs.
- Deploy full functionality of the security solution instantaneously. No project, services fees, or trans-continental flights required.
- Work in tandem with functionality native to the monitored platform. For instance, in Salesforce, leverage Salesforce encryption and quarantining capabilities as an automated response when sensitive information is discovered within the environment.
- Inspect traffic at rest and traffic in motion. You want to be able to look at data from the time you deploy a CASB as well as data, files, and behavior that already existed before you deployed a security solution. Proxy and Gateway CASBs only see data from the time they are deployed. Cloud-Native CASBs see both.
Want to Learn More?
Read our featured eBook for a deeper dive into the world of cloud-native and proxy CASBs.