The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection…
- Image via Wikipedia
This is a revisitation of a blog I wrote last year: Incomplete Thought: Cloud Security IS Host-Based…At The Moment
I use my ‘Security Hamster Sine Wave of Pain” to illustrate the cyclical nature of security investment and deployment models over time and how disruptive innovation and technology impacts the flip-flop across the horizon of choice.
To wit: most mass-market Public Cloud providers such as Amazon Web Services rely on highly-abstracted and limited exposure of networking capabilities. This means that most traditional network-based security solutions are impractical or non-deployable in these environments.
Network-based virtual appliances which expect generally to be deployed in-line with the assets they protect are at a disadvantage given their topological dependency.
So what we see are security solution providers simply re-marketing their network-based solutions as host-based solutions instead…or confusing things with Barney announcements.
Take a press release today from SourceFire:
Snort and Sourcefire Vulnerability Research Team(TM) (VRT) rules are now available through the Amazon Elastic Compute Cloud (Amazon EC2) in the form of an Amazon Machine Image (AMI), enabling customers to proactively monitor network activity for malicious behavior and provide automated responses.
Leveraging Snort installed on the AMI, customers of Amazon Web Services can further secure their most critical cloud-based applications with Sourcefire’s leading protection. Snort and Sourcefire(R) VRT rules are also listed in the Amazon Web Services Solution Partner Directory, so that users can easily ensure that their AMI includes the latest updates.
As far as I can tell, this means you can install a ‘virtual appliance’ of Snort/Sourcefire as a standalone AMI, but there’s no real description on how one might actually implement it in an environment that isn’t topologically-friendly to this sort of network-based implementation constraint.*
Since you can’t easily “steer traffic” through an IPS in the model of AWS, can’t leverage promiscuous mode or taps, what does this packaging implementation actually mean? Also, if one has a few hundred AMI’s which contain applications spread out across multiple availability zones/regions, how does a solution like this scale (from both a performance or management perspective?)
I’ve spoken/written about this many times:
Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where… and
Dear Public Cloud Providers: Please Make Your Networking Capabilities Suck Less. Kthxbye
Ultimately, expect that Public Cloud will force the return to host-based HIDS/HIPS deployments — the return to agent-based security models. This poses just as many operational challenges as those I allude to above. We *must* have better ways of tying together network and host-based security solutions in these Public Cloud environments that make sense from an operational, cost, and security perspective.
/Hoff
Related articles by Zemanta
- Sourcefire Expands Real-Time Application Awareness, Extending Leadership of Intelligent Cybersecurity Solutions (eon.businesswire.com)
- Securing the public cloud (news.cnet.com)
- Amazon Security Groups for EC2 (kinlane.com)
- You Can’t Secure The Cloud… (rationalsurvivability.com)
- Security: In the Cloud, For the Cloud & By the Cloud… (rationalsurvivability.com)
- The Hypervisor Platform Shuffle: Pushing The Networking & Security Envelope (rationalsurvivability.com)
- Incomplete Thought: The DevOps Disconnect (rationalsurvivability.com)
- Dear SaaS Vendors: If Cloud Is The Way Forward & Companies Shouldn’t Spend $ On Privately-Operated Infrastructure, When Are You Moving Yours To Amazon Web Services? (rationalsurvivability.com)
- The Four Horsemen Of the Virtualization (and Cloud) Security Apocalypse… (rationalsurvivability.com)
- Incomplete Thought: The DevOps Disconnect (rationalsurvivability.com)
- Dear SaaS Vendors: If Cloud Is The Way Forward & Companies Shouldn’t Spend $ On Privately-Operated Infrastructure, When Are You Moving Yours To Amazon Web Services? (rationalsurvivability.com)
- The Four Horsemen Of the Virtualization (and Cloud) Security Apocalypse… (rationalsurvivability.com)
* I “spoke” with Marty Roesch on the Twitter and he filled in the gaps associated with how this version of Snort works – there’s a host-based packet capture element with a “network” redirect to a stand-alone AMI:
@Beaker AWS->Snort implementation is IDS-only at the moment, uses software packet tap off customer app instance, not topology-dependent
and…
they install our soft-tap on their AMI and send the traffic to our AMI for inspection/detection/reporting.
It will be interesting to see how performance nets out using this redirect model.
Valid.
This is still where portions of A6 (or whatever the current moniker is) ends up making a significant impact. Correct?
D
I believe in the *very* near future public clouds will emerge that provide a more configurable network topology and boundaries.
I hope this might create the 'goldilocks' public & private cloud architecture–to the point of your prior blog on the need to innovate on private clouds as well.
Right now the market is negotiating from extremes–perhaps a solution someplace in the middle will find a lot of buyers.
Valid point. Right now, we use HIDS and even if (and I agree w/James here, this will be a when) cloud providers give us more advanced out-of-the-box networking topologies, as a "little guy/cloud-consumer, I don't know that I'd want to pay to run a dedicated IPS AMI, would likely want to double-, triple-, or otherwise task it (bundling w/HAProxy is my first thought).
Of course, I'd posit that most of us would build these AMIs ourselves because our needs and security requirements are going to differ from what might be publicly provided (and/or we're a little bit paranoid). But I still think Sourcefire's AMI release is a good thing – publicly released AMIs are always great fun and good for testing/learning, so am happy that they exist and that security vendors are taking the time to make them available.
A security model that's sure to put smiles on the AWS accountants faces, with tripling of network charges (x2 for monitored AMI, +1 for monitoring AMI). 🙂
@nuclear-cowboy
Traffic inside the cloud is free, but the "atomization" of functionality into many separate VMs which each cost over $70/month is a problem. The concept of virtual appliances made sense in the private cloud (or ESX cluster as it used to be known) where VMs are free, but I think it's being over-applied in the public cloud.
Yeah, this has been interesting for us as we've gotten into the cloud; the tools we had in IT largely focused on network and eschewed host as kinda-redundant, nice to have for defense-in-depth but don't spend money on it… With the cloud we are focusing a lot more on secure code scanning and HIDS because those are the elements that are more implementable.
I'll also note that Amazon (understandably, I guess) makes a big fuss about you running nessus style security scans, and their stance is "you can do it but you have to email support before you do and let them get ready for it" – which of course means automated/scheduled scanning is a problem.
This actually has several uses. You can direct traffic through an instance, selectively capture traffic in a soft tap and inspect it at central sensors, or operate each as a network node IDS.