You remember agents, right? Those ‘lightweight’ pieces of code vendors provided to install on all your servers? The code you pushed out to endpoints? The stuff that gathered all sorts of data and provided analysis without any impact on server performance? Agents monitored activity, enforced policies, killed viruses, and foiled botnets, all from a central location, while making you a steaming espresso? Yeah, marketing hyperbole aside, agents are the ubiquitous pieces of code that got installed on every server to perform any and all security tasks on the local hosts. For tasks where network-based intelligence and protection were inappropriate – which are more common than not – agents do much of the heavy lifting. They’re installed on endpoints and servers. And they are a pain in the ass – many enterprises instituted “no more agents” moratoria when they were multiplying like rabbits, and once you get to say 20 or so agents on a machine, things get out of hand…
In terms of cloud services, what does that all mean? For the last two years we have been hearing security vendors say, “Yes, we offer a cloud solution.” When we dug in, it always seemed to be the same old agent, deployed the same as before, now on an Amazon AWS instance. Best case you get the same agent proliferation/performance/management problem in your shiny new IaaS cloud; worst case you cannot deploy these agents because the PaaS or SaaS service provider won’t let you. So where does that leave customers, who have embraced SaaS far more than IaaS? Security is largely a bolt-on proposition, so where exactly do you bolt it on in the cloud? We go back to the network.
I see a proliferation of vendors announcing, or about to announce, proxy-based security implementations. Delivered – surprise, surprise – as SaaS to secure other SaaS services. One cloud secures another.
The proxy model seems to have (finally?) caught hold – because it gives security vendors a suitable deployment model. The vendors insert themselves into the network stream, essentially by redirecting network traffic through their cloud-based security service, to filter and monitor activity before it gets to your cloud service. For those of you familiar with programmable shells (csh, bash, etc.), it’s like linking two commands with pipes (‘|’): the output of one service is passed into the next in the chain for further processing. Anti-spam vendors have been doing this for years. Anti-DDoS, IAM, and WAF vendors are gaining traction, and now stuff like content masking and DLP for mobile devices is popping up.
Rich talked about some of the downsides of this approach last year with Proxies and the Cloud, but that was specifically addressing some solutions that just don’t work in this model, such as proxy-based encryption for SaaS applications. The issues Rich raised by hold for some products, especially as they pertain to SaaS-based services, and I expect to see other problems. That said, there are significant advantages to proxies beyond the a viable deployment model. You’re not installing and managing agents on your virtual platforms. You’re not opening holes in or across your network to allow them to communicate – instead the service is in line with the business process. And you’re not scaling by adding a bunch of appliances to your data center – in fact you get many of the standard cloud services advantages: self service, elasticity, metered, and pay as you go. And some evolutionary changes jump-started by cloud computing make some security products obsolete – such as AV proxies for smartphones. Just because the model enables a service to exist does not mean that service is necessary.
Comments