Does virtualization spell the end of good DMZ security?

Analysis
Jan 17, 20084 mins

Now that the high level view of virtualization is done, I wanted to look at some of the real network impacts that I think virtualization is going to have. There are various schools of thought on the subject that range from “no real impact” to “it’s going to fundamentally change the way we manage networks and systems”. One thing is sure though, everyone is trying to get into the virtualization game right now and its inevitable that sooner or later you are probably going to need to start thinking about how virtualization is going to impact your network.

My take on it all falls fairly well in the middle, especially as it relates to the network. I think there are certain cases where the impact is essentially irrelevant. I think there are other cases where the impact can potentially change the how network administrators design and manage the network. One situation that I think falls into that latter category is the impact that virtualization will have on DMZ resources.DMZ’s have always been that “no man’s land” in the network. Not quite “the internet” but definitely not “the inside network” either. A question I have been asking network admins is “how comfortable are you with using virtualization for DMZ resources”? The vast majority of responses I have received tend to fall between “I’m not comfortable at all” to “I could see virtualizing resources exclusively in the DMZ, but not spanning security domains like a DMZ and inside network on the same ESX server”. For the “I’m not comfortable” side of the house, the reasons consistently cited are that the ability to physically isolate resources is too important to good security. They like that they can have different physical servers, each isolated physically. If someone manages to compromise server A, the rest of the servers are still [potentially] protected. This philosophy also gets expanded into the DMZ where multiple DMZ’s may be implemented to ensure that if one is compromised, the others remain untouched. This is the classic isolationist security posture, and in many cases it is a simple matter of “this is how it has always been done and it’s been successful, so I’m just not willing to change”. For the folks who are comfortable with the idea, the one security concern I have consistently seen cited is the concern that if a single ESX server is used for both internal and DMZ resources, that a backdoor might exist that can be exploited to bypass all the security barriers that are built around the DMZ. The most commonly cited reference is using VLANs in the exact same fashion. Historically there have been issues where traffic on one VLAN could inadvertently be delivered to another VLAN, and in some high security environments the potential risk was deemed too high, and thus VLANs were not allowed to be used to segment DMZ traffic. The network admins I have spoken with most frequently refer to that as their basis for “I could see an ESX server in the DMZ hosting nothing but VMs for DMZ resources, but definitely not hosting both DMZ and internal VMs”.I like to try to use eye catching (inflammatory?) subjects to grab folks attention. I opened by asking does virtualization spell the end of good DMZ security? Given the above general points I don’t think it has to, however if not implemented properly it certainly can undermine even the best security policies you have for your DMZ (though this is really true of just about any technology).In my next blog post I’m going to take a more detailed look at some of the things that you should consider if you are going to use virtualization in your DMZ, and offer some general security recommendations that will help to mitigate many of the risks virtualization can introduce to your environment.

Wes

http://www.netiq.com