Andrea Danti - Fotolia
The pros and cons of proxy-based security in the cloud
Is proxy-based security in the cloud right for you? Expert Ed Moyle looks at the benefits and drawbacks of using proxies for Office 365 and other cloud platforms.
There can be times when something that's ordinarily risky is actually the safest course of action. For example, no cautious, unimpaired motorist would swerve across a double yellow line -- yet, a situation could arise, such as a pedestrian standing in the road where there is no oncoming traffic, for example, in which doing exactly that is the safest, least risky course of action.
Similar situations can sometimes arise in the technology realm, as well. For example, a man-in-the-middle (MitM) attack -- in which someone or something eavesdrops on messages between two communicating parties -- is not usually conducive to good security. However, it's also true that organizations have deliberately introduced a MitM in certain situations to satisfy security goals.
Earlier in 2018, Microsoft put out a blog post detailing its position on this approach as it relates to proxy-based security for Office365 and cloud access security brokers. In a nutshell, Microsoft doesn't recommend it. The company says that proxying can cause interoperability and performance issues, can negatively affect support, and can lead to undesirable or unexpected behavior.
This puts practitioners in a bit of a quandary though. For those considering proxy-based security, should they do it anyway? After all, Microsoft says in that same post that it doesn't explicitly disallow this approach -- so, for some, it could remain a legitimate consideration.
This leaves customers already using tools and services to do this with some questions. Should they switch to something else? Are they better off removing the control entirely or leaving it in place despite the warnings? Answering these questions can be more complicated than it might seem.
How proxy-based security approaches work
Before exploring in detail how a practitioner might evaluate these questions, let's look at how proxy-based security approaches work and how they can lead to those issues. Having a robust understanding of how and why the issues Microsoft described arise can help organizations evaluate their usage and ultimately decide whether continuing or starting to use these approaches is a good idea.
To do that, it's important to understand the methods by which cloud access security brokers (CASBs) operate and why. Recall that the fundamental purpose of a CASB is to enable the introduction of security functionality that a given SaaS does not offer natively. This can include enhanced authentication, logging, encryption of stored data or other security-relevant features. If an organization has a regulatory or business requirement for certain security measures and wants to use a SaaS that doesn't offer them, a solution that adds those features out of band can be highly compelling.
There are two primary ways that a CASB can add additional security features. One is to utilize the APIs offered within the SaaS to layer on the additional functionality. Another option is to proxy the application traffic -- either via reverse or forward proxying -- so that the CASB can operate on the underlying HTTP data stream directly. For those unfamiliar with proxies, this essentially means that they sit in between the user's browser and the SaaS, intercepting and acting upon requests and responses as they are transmitted.
There are pros and cons to each approach. Using APIs presupposes a particular SaaS solution -- meaning those APIs are tied to a particular service or set of services. So the APIs for Microsoft Office 365, for example, will only work there and not with another SaaS platform. This means that unless the CASB vendor has written functionality using the other SaaS platform's APIs, as well, the security features they provide won't work on that other service.
By contrast, proxy-based security can be more versatile. It still requires some customization, but that customization can be more easily adapted because the approach works generically, as almost every SaaS uses HTTP and thereby can address a broader range of SaaS services.
But that versatility also comes with challenges. For example, what happens if the proxy becomes unresponsive or overloaded? Or what happens if the SaaS -- which may or may not even be aware that its service is being proxied -- decides to change how its pages are laid out, makes large-scale changes to the application, or otherwise adapts in a way that the proxy isn't expecting?
As Microsoft outlined, proxy-based security can cause performance and usability issues. Likewise, how does a SaaS provider deal with those issues when they are caused by another product it doesn't control? In brief, it can't. Hence, the support issues Microsoft described.
What makes sense for your organization?
All of this points to the original questions facing the practitioner evaluating or using CASBs. It's complicated by the fact that not all CASB products operate the same way: some only support proxying, others only support API integration, and others support a combination of both. Understanding the architecture of the product or products in your organization's scope is a useful first step to evaluate the continued or initial suitability of a given product for your environment.
The second step is to evaluate the tradeoffs involved in using proxying or API integration on a service by service basis. For example, Microsoft doesn't say you can't use proxy-based security for Office 365, it just warned that it's not recommended and that it might have trouble supporting it, which means there's no one size fits all answer.
For some, the challenges associated with support will be a deal breaker for using the proxy-based security features in Office 365; for others, the availability of security features could mean the difference in enabling the organization to use SaaS. Ultimately, it comes down to a risk management decision based on your security goals, the services you use and the CASB products potentially in scope.
How can you make an informed decision? It starts with understanding your security goals. For example, you might employ a formalized approach like application threat modeling to understand your SaaS usage and how someone might attack you using those SaaS services as a vehicle.
That's a good first step, but making an informed decision also means understanding architecturally how the products you have in place, or that you are considering purchasing, operate. This may mean having some tough discussions and targeted Q&A with those vendors. Knowing how they work, how it affects the SaaS services in scope, and how risk goals can be met should provide you with sufficient data to analyze the tradeoff in consultation with the business teams actually employing the SaaS in the first place.
