The Final Frontier(?): Virtualizing the DMZ…
Alessandro from virtualization.info and I were chatting today regarding VMware’s latest best-practices document titled "DMZ Virtualization with VMware Infrastructure."
This is a nine page overview that does a reasonably good job of laying out many of the architectural/topological options available when thinking about taking the steps toward virtualizing what some consider the "final frontier" in the proving grounds of production-level virtualization — the (Internet-facing) DMZ.
The whitepaper was timely because I was just finishing up my presentation for Blackhat and was busy creating a similar set of high-level architectural examples to use in my presentation. I decided to reference those in the document because they quite elegantly represent the starting points that many folks would use as a stepping off point in their virtual DMZ adventures.
…and I think it will be an adventure punctuated perhaps by evolutionary steps as documented in the options presented in the whitepaper.
As I read through the document, I had to remind myself of the fact that this was intended to be a high-level document and not designed to cover the hairy edges of network and security design.
The whitepaper highlighted some of the reasonable trade-off’s in complexity, resiliency, management, functionality, operational expertise, and cost but given where my head and focus are today, I have to admit that it still gnawed at me from a security perspective which is still too weak for my liking.
I’ve hinted at why in my original Four Horsemen slide, and I’m going to be speaking for 75 minutes on the topic at Blackhat, so come get your VirtSec boogie on there for a full explanation…
Alessandro got dinged in a comment on his blog for a statement in which he suggested that partially-collapsed as well as fully-collapsed DMZ’s with virtual separation of trust zones "…should be avoided at all costs because they imply the inviolability of the hypervisor (at any level: from the virtual networking to the kernel) something that nor VMware neither any other virtualization vendor can grant."
This appears contradictory to his initial assessment of DMZ virtualization wherein he stated that "…there [is] nothing bad in virtualizing the DMZ as long as we are fully aware of the risks." In a way, I think I understand exactly where Alessandro is coming from, even if I don’t completely agree with him (or at least I partially do…)
This really paints an altogether unfortunate and yet accurate picture of the circular arguments folks engage in when they combine the following topics in a single argument:
- Securing virtualization
- Virtualizing security
- Security via virtualization
In the same way that we trust our operating system vendors who provide us with the operational underpinnings of our datacenters with the hope that they will approach a reasonable level of "security" in their products, we are basically at the same point with our virtualization (OS) platform providers.
Hope is not a strategy, but it seems we’ve at least accepted it for the time being… ;(
Sure there are new attack vectors and operational risks, but the slippery slope of not being able to really quantify whether you are more or less at risk based solely on the one-dimensional data point of the infallibility of the hypervisor and then write the whole concept off seems a little odd to me.
If you’re truly assessing risk in the potential virtualization of your DMZ, you’ll take the operational/architectural guidelines as well as the subjective business impacts into consideration. Simply stating that one should or should not virtualize a DMZ without a holistic approach is myopic.
To circle back on the topic, the choice of whether to — and how to — virtualize your DMZ is really starting to gain traction. I think the whitepaper took a decent first-pass stab at exploring how one might approach it, but the devil’s in the details — or at least the devil’s 4 horsemen are 😉
/Hoff
I think that you can trust the hypervisor layer to be secure in the same way we trust in the security of any "logical" security layer. (I think it's very much like the physical access layer)
It's very easy to show that even a bare-metal hypervisor adds to the attack surface — but ultimately this is not the issue.
Hyperjacking is not the issue either. With virtualization, either you build security into the architecture … or you don't.
If you choose "don't" then we are done here. I wish you good luck and I hope you're not doing anything more important than Scrabulous.
If you choose "do" then it's time to exhume all of those security audits and architecture reviews that you've been ignoring and finally get serious about defense-in-depth, separation of duties and dual controls.
If you choose “do” then you need automatic enforcement of change, configuration, patch and vulnerability management policies.
If you choose “do” then you must segment, monitor, audit and control access to your host consoles, virtual networks and management services and applications.
If you choose “do” you should go to /hoff’s preso, listen very carefully and then follow his advice 🙂
More virtualization fun..
There's an interesting post at Hoffs blog around virtualization and DMZs and to what level it's "ok" to virtualize a given DMZ environment, following on from a white paper by VMware on the subject As Hoff mentions you need to…
I agree that the paper is interesting, though don't really think it was quite forthcoming enough in some areas. Page 3 was funny when they say "As shown in figures 1 and 2, the introduction of virtual technology into a DMZ does not have to change the DMZ topology significantly." but the difference between figs 1 and 2 are quite significant, at least from a complexity perspective.
Pete
Great blog site. Great comments.
The paper seems to build heavily from the Gartner research paper published in May 07, and mentioned in the reference. It is pretty easy to agree, companies virtualizing across network zones that do not have the configuration management maturity and the defense in depth items in place, as described by Michael's post, will have administrative errors allowing traffic to flow between those zones. In addition, the SoD in place between the server administrators and the network administrators is lost, more so in the fully virtualized environment (I also can't see the PIX/Check Point admin anxious to manage the Virtualized Security Appliance du jour).
On a seperate note, it would be interesting to see the discussion on virtualization also include IBM environments found in the large Fortune X environments (z/VM, LPARs, etc.).
Here is an IBM article from last year where it references the full virtualized DMZ approach (Figure 3). http://www.ibmsystemsmag.com/mainframe/januaryfeb…
Although that being said I think that many of the security points around virtualization can be extrapolated to include such environments.
Too bad for IBM they can't virtualize Windows on their zSeries, or maybe their working on it (j/k)…
VMware and Virtual DMZs
Chris Hoff posts about VMware's recently released DMZ whitepaper. It shows three different approaches to DMZ architectures and discusses their strengths and weaknesses: