Home > Cloud Computing, Cloud Security, Virtualization > Oh Great Security Spirit In the Cloud: Have You Seen My WAF, IPS, IDS, Firewall…

Oh Great Security Spirit In the Cloud: Have You Seen My WAF, IPS, IDS, Firewall…

December 10th, 2008 Leave a comment Go to comments

SearchingI'm working on the sequel to my Four Horsemen of the Virtualization Security Apocalypse presentation.

It's called "The Frogs Who Desperately Wanted a King: An Information Security Fable of Virtualization, RTI and Cloud Computing Security." (Okay, it also has the words "interpretive dance" in it, but that's for another time…)

Many of the interesting issues from the Four Horsemen regarding the deficiencies of security solutions and models in virtualized environments carries over directly to operationalizing security in the Cloud. 

As a caveat, let's focus on a cost-burdened "large" enterprise who's involved in moving from physical to virtual to cloud-based services.

I'm not trying to make a habit of picking on Amazon AWS, but it's just such a fantastic example for my point, which is quite simply:

While the cloud allows you to obviate the need for physical compute, network and storage infrastructure, it requires a concerted build-out and potential reinvestment in a software-based security infrastructure which, for most large enterprises, does not consist of the same solutions deployed today.

Why?  Let me paint the picture…

In non-virtualized environments, we generally use dedicated appliances or integrated solutions that provide one of more discrete security functions. 

These solutions are built generally on hardened OS's, sometimes using custom hardware and sometimes COTS boxes which are tarted up.  They are plumbed in between discretely segregated (physical or logical) zones to provide security boundaries defined by arbitrary policies based upon asset classification, role, function, access, etc.  We've been doing this for decades.  It's the devil we know.

In virtualized environments, we currently experience some real pain when it comes to replicating the same levels of security, performance, resiliency, and scale using software-based virtual appliances to take the place of the hardware versions in our physical networks when we virtualize the interconnects within these zones.

There are lots of reasons for this, but the important part is realizing that many of the same hardware solutions are simply not available as virtual appliances and even when they are, they are often not 1:1 in terms of functionality or capability.  Again, I've covered this extensively in the Four Horsemen.

So if we abstract this to its cloudy logical conclusion, and use AWS as the "platform" example, we start to face a real problem for an enterprise that has a decade(s) of security solutions, processes and talent that is focused on globalizing, standardizing and optimizing their existing security infrastructure and are now being forced to re-evaluate not only the technology selection but the overall architecture and operational model to support it.

Now, it's really important that you know, dear reader, that I accept that one can definitely deploy security controls instantiated as both network and host-based instances in AWS.  There are loads of options, including the "firewall" provided by AWS.

However, the problem is that in the case of building an AMI for AWS supporting a particular function (firewall, WAF, IPS, IDS, etc.) you may not have the same solutions available to you given the lack of support for a particular distro, lack of "port" to a VA/VM, or issues surrounding custome kernels, communication protocols, hardware, etc…  You may be limited in many cases to having to rely on open source solutions.

In fact, when one looks at most of the examples given when describing securing AWS instances, they almost always reference OSS solutions such as Snort, OSSEC, etc.  There's absolutely NOTHING wrong with that, but it's only one dimension.

That's going to have a profound effect across many dimensions.  In many cases, enterprises have standardized on a particular solution not because it's special from a "security" perspective, but because it's the easiest to manage when you have lots of them and they are supportable 24/7 by vendors with global reach and SLA's that represent the criticality of their function.

That is NOT to say that OSS solutions are not easy to manage or supportable in this fashion, but I believe it's a valid representation of the state of things.

(Why am I getting so defensive about OSS? ;)

Taking it further, and using my favorite PCI in the Cloud argument, what if the web application firewall that you've spent hundreds of thousands of dollars purchasing, tuning and deploying in support of PCI DSS throughout the corporate enterprise simply isn't available as a software module installable in an AMI in the cloud?  Or the firewall?  Or the IPS? 

In the short term this is a real problem for customers.  In the long term, it's another potential life preserver for security ISV's and an opportunity for emerging startups to think about new ways of solving this problem.

/Hoff

  1. Roland Dobbins
    December 10th, 2008 at 19:32 | #1

    A point that's missing from this dicussion is the fact that from a performance perspective, software running on general-purpose computing platforms simply cannot match the performance of ASICs in physical network infrastructure devices. This has considerable security implications in the context of DoS, deliberate or inadvertent.
    The obvious solution is control-plane integration of virtutalized software-based OSes/apps/services with virtualized hardware, so that detection, classification, mitigation, and policy-enforcement functions can be supported by devices which have the necessary performance characteristics to handle these functions at speeds in the mpps.

  2. Roland Dobbins
    December 11th, 2008 at 01:42 | #2

    I saw the references in the 'Four Horesemen' preso (great stuff!), but didn't see it here. You say 'real pain', when the operative term is 'impossible', heh.
    ;>
    Correct – the virtual hosts running general-purpose OSes on general-purpose hardware simply cannot scale to keep up with hundreds of thousands, much less millions of pps and cps (which is why we have ASIC-based network gear in the first place). So, the idea is to tie them logically into hardware which can do so, hardware which is virtualized and multi-tenant-capable and which ties into the concepts of VM/app/service identity and entitlement.

  3. December 11th, 2008 at 00:03 | #3

    Actually, it’s not missing at all. That’s one of the Four Horsemen in the presentation referenced throughout. It’s also what I was talking about when I said the following:
    “In virtualized environments, we currently experience some real pain when it comes to replicating the same levels of security, performance, resiliency, and scale using software-based virtual appliances to take the place of the hardware versions in our physical networks when we virtualize the interconnects within these zones.”
    One could also mount an argument that certainly for *some* functions ASICs and FPGA’s have a definite performance advantage, but not all. That’s a debate for another context.
    However, to your point about the “obvious solution,” can you expand upon what you mean by “…virtualized hardware?” I understand the control plane integration, but are you referring to offloading security functions to boxen external to the virtual hosts?
    I’m not asking in order to disagree with that postulate, but I want to ensure I understand your point…especially since the obvious in reality often doesn’t meet perception ;)
    /Hoff

  4. December 11th, 2008 at 03:37 | #4

    Hoff would also like to mention that he LOVES OSSEC :P

  1. September 30th, 2009 at 07:15 | #1