The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection…

Snort Intrusion Detection System Logo
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.


Related articles by Zemanta

* 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


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.

Enhanced by Zemanta
  1. David O'Berry
    July 7th, 2010 at 05:23 | #1


    This is still where portions of A6 (or whatever the current moniker is) ends up making a significant impact. Correct?


  2. July 7th, 2010 at 05:29 | #2

    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.

  3. jen_h
    July 7th, 2010 at 06:07 | #3

    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.

  4. nuclear-cowboy
    July 8th, 2010 at 08:00 | #4

    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). :-)

  5. July 8th, 2010 at 09:51 | #5


    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.

  6. July 22nd, 2010 at 06:46 | #6

    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.

  7. Anon
    February 22nd, 2011 at 20:52 | #7

    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.

  1. July 7th, 2010 at 09:14 | #1
  2. July 9th, 2010 at 09:02 | #2
  3. July 17th, 2010 at 10:38 | #3
  4. August 21st, 2010 at 12:28 | #4
  5. February 1st, 2011 at 13:31 | #5