In politics, there are issues that are known as “third rail” for being politically charged, even “untouchable.” This name relates to the third rail in many electrical railway systems — the one that is electrically charged to power the train. Like the rail, if a politician touches (or is lured into touching) a third-rail issue during an election, they risk electrocution (aka, political death). Think of taking away Social Security benefits, calling for a military draft, or debating agriculture subsidies — these are all things considered third-rail issues at some point in the last 50 years.
Third rails are not relegated to politics. Even in the world of enterprise IT and security, there are issues that can be just as charged. One example is the use of agents in managing endpoint devices like laptops and mobile devices. Agents have been on the third rail of enterprise security for many years , finally coming to a head as mobile device management (MDM) solutions took off in the early 2010s. In fact, the rise of enterprise MDM adoption correlates well with the growing aversion to agents and started the quest for “agentless” methods of managing and monitoring.
Frustration frequently spawns innovation, and that can be a good thing for vendors and customers. When it came to MDM, vendors reached deep to make deploying agents less painful. Integrations with SSO, SCCM, collaboration with OS providers, and so on, resulted in an easier deployment experience (amongst other things). Fast forward to the cloud access security broker market and you’ll find vendors who range the spectrum when it comes to deploying agents. Some have practically written manifestos professing they shall never require an agent, while others make them part of their strategy. At Netskope, we’ve offered both agent-based and agentless CASB deployments (depending on use case) from the beginning.
Since talking about third-rail issues can be such an intense experience, we shouldn’t be surprised to see a lot of misinformation purposefully being floated around about whether or not agents are required to control cloud apps. Let’s put that to an end, right now.
Here we go, we’re going to touch the third rail (gasp!)
Netskope takes great pride in covering every possible way of managing cloud apps without an agent on the endpoint. At the same time, we’re not so righteously set on saying we’re “agentless,” because, frankly, for some use cases, you just need an agent.
So when do you need an agent? To boil this down to its simplest form, the agent requirement is driven entirely by two things:
We’ll get to why we’ve separated these into two things later, but first, let’s outline these requirements.
|Use Case Requirements||Yes||No|
|Real-time visibility and control of unsanctioned app (shadow IT) usage by remote users||X|
|Real-time visibility and control of unsanctioned or sanctioned app usage by mobile device users||X|
|Real-time visibility and control of sync clients used by unsanctioned or sanctioned apps||X|
|Real-time access and control of a sanctioned app being used from a browser||X|
|Real-time access and control of unsanctioned apps being used from browser on the corporate network||X|
|The enterprise is only concerned with discovering shadow IT and doesn’t intend to put fine-grained controls around those apps||X|
|Out-of-band inspection of content in sanctioned apps||X|
|Out-of-band policy enforcement of sanctioned apps||X|
|Compressed timeline. An agent deployment can, believe it or not, save time and spare the team from navigating laborious network change control processes||X|
|Lack of access to network team or inability to implement changes. In some cases, the team requiring a CASB has little or no access to the networking team||X|
|Sanctioned apps where users are only going to access the app only from a browser and not from a mobile app or via a sync client||X|
|The enterprise has a rigid stance against agent usage||X|
Now for a discussion about the separation of these two drivers. In our opinion, the use case(s) should be the first consideration as they represent the needs of the enterprise. Deployment requirements are, in most cases, constraints imposed on the project by the enterprise (the business or IT). These constraints are important, but they need to be weighted appropriately and in most cases, secondary to the use case requirements. The rationale for this weighting really comes down to determining which requirement wins if they are at opposition. Let’s use a couple examples:
Ocean Blue corporation wants to control ServiceNow and prevent social media sharing during business hours for service and support personnel working from their Las Vegas call center. The team running the deployment is based in Las Vegas, but Ocean Blue’s networking team is based in Japan, making it difficult for the deployment team to engage. For this use case, the CASB will work fine with or without an agent and the deployment constraint (inability to engage the Networking team in Japan) is probably a strong enough driver to tip the decision towards using agents.
Red Engine corporation wants to control Box usage by remote users accessing the app from laptops, mobile devices and sync clients. The team running the deployment has a “no agent” deployment requirement. In this scenario, the use case and deployment requirements actually run in direct conflict — so much so that no CASB will be able to satisfy Red Engine’s needs. Either the use case will need to change or the deployment team will need to ease the “no agent” constraint.
If it sounds too good to be true, then it probably is…
The reality is that while the above table and scenarios are straightforward, there a plenty of vendors who gloss over the facts when it comes to what proxy or API-base architectures can control. Again, this is due to the third-rail nature of agents. There’s a cautionary note here.
There are a lot of use cases that simply can’t be addressed without an agent. The old adage, “if it sounds too good to be true, then it probably is” applies. Any CASB proclaiming they can cover every use case without an agent isn’t being honest with you.
Those vendors will also tell you that other vendors require agents to work. Their hope is to use the third rail and appeal to a base-level desire for simplicity. After all, who wouldn’t want to solve every use case without an agent? Unfortunately, it’s just not possible.
So what’s a confused security pro supposed to do about all of this?
It’s a good question. Check your deployment requirements to see if they’re important enough to outweigh your use case (and vice versa). Listen for vendors’ promises that sound too good to be true. In side-by-side comparisons, look for the truth tellers who will say things even though they know it’s not what you want to hear.
At Netskope we’ve been deploying with or without agents since the beginning. When do we deploy without an agent? When the use case or deployment requirements demand it. When do we deploy with agents? When the use case or deployment requirements demand it. Want an honest discussion about whether or not you need to use an agent based on your use cases and deployment requirements? So do we. Let’s talk.