Should/Can/Will Virtual Firewalls Replace Physical Firewalls?
Simulação da participação de um Firewall entre uma LAN e uma WAN Français : Schéma d’un pare-feu entre un LAN et un WAN (Photo credit: Wikipedia)
“Should/Can/Will Virtual Firewalls Replace Physical Firewalls?”
The answer is, as always, “Of course, but not really, unless maybe, you need them to…” 🙂
This discussion crops up from time-to-time, usually fueled by a series of factors which often lack the context to appropriately address it.
The reality is there exists the ever-useful answer of “it depends,” and frankly it’s a reasonable answer.
Back in 2008 when I created “The Four Horsemen of the Virtualization Security Apocalypse” presentation, I highlighted the very real things we needed to be aware of as we saw the rapid adoption of server virtualization…and the recommendations from virtualization providers as to the approach we should take in terms of securing the platforms and workloads atop them. Not much has changed in almost five years.
However, each time I’m asked this question, I inevitably sound evasive when asking for more detail when the person doing the asking references “physical” firewalls and what it is they mean. Normally the words “air-gap” are added to the mix.
The very interesting thing about how people answer this question is that in reality, the great many firewalls that are deployed today have the following features deployed in common:
- Heavy use of network “LAG” (link aggregation group) interface bundling/VLAN trunking and tagging
- Heavy network virtualization used, leveraging VLANs as security boundaries, trunked across said interfaces
- Increased use of virtualized contexts and isolated resource “virtual systems” and separate policies
- Heavy use of ASIC/FPGA and x86 architectures which make use of shared state tables, memory and physical hardware synced across fabrics and cluster members
- Predominant use of “stateful inspection” at layers 2-4 with the addition of protocol decoders at L5-7 for more “application-centric” enforcement
- Increasing use of “transparent proxies” at L2 but less (if any) full circuit or application proxies in the classic sense
So before I even START to address the use cases of the “virtual firewalls” that people reference as the comparison, nine times out of ten, that supposed “air gap” with dedicated physical firewalls that they reference usually doesn’t compute.
Most of the firewall implementations that people have meet most of the criteria mentioned in items 1-6 above.
Further, most firewall architectures today aren’t running full L7 proxies across dedicated physical interfaces like in the good old days (Raptor, etc.) for some valid reasons…(read the postscript for an interesting prediction.)
Failure domains and the threat modeling that illustrates cascading impact due to complexity, outright failure or compromised controls is usually what people are interested in when asking this question, but this gets almost completely obscured by the “physical vs. virtual” concern and we often never dig deeper.
There are some amazing things that can be done in virtual constructs that we can’t do in the physical and there are some pretty important things that physical firewalls can provide that virtual versions have trouble with. It’s all a matter of balance, perspective, need, risk and reward…oh, and operational simplicity.
I think it’s important to understand what we’re comparing when asking that question before we conflate use cases, compare and mismatch expectations, and make summary generalizations (like I just did 🙂 about that which we are contrasting.
I’ll actually paint these use cases in a follow-on post shortly.
/Hoff
POSTSCRIPT:
I foresee that we will see a return of the TRUE application-level proxy firewall — especially with application identification, cheap hardware, more security and networking virtualized in hardware. I see this being deployed both on-premise and as part of a security as a service offering (they are already, today — see CloudFlare, for example.)
If you look at the need to terminate SSL/TLS and provide for not only L4-L7 sanity, protect applications/sessions at L5-7 (web and otherwise) AND the renewed dependence upon XML, SOAP, REST, JSON, etc., it will drive even more interesting discussions in this space. Watch as the hybrid merge of the WAF+XML security services gateway returns to vogue… (see also Cisco EOLing ACE while I simultaneously receive an email from Intel informing me I can upgrade to their Intel Expressway Service Gateway…which I believe (?) was from the Cervega Sarvega acqusition?)
Related articles
Recent Comments