When it comes to DMZ design, IT administrators often find themselves at odds with security and auditing folks. But it doesn’t have to be that way, thanks to the emergence of virtual LANs.
Administrators simply want to get the job done, and security and auditing sometimes just get in the way. Security officers, on the other hand, see themselves as the line of defense against an admin’s hurried design or poorly-executed configuration. Demilitarized zones (DMZs) are often the least-trusted parts of the network, so DMZ design requires the most cooperation between these two opposing teams.
How virtualization affects DMZ design
In 2009, I presented a seminar on Understanding Virtualization’s Role in Auditing and Security to an audience of IT auditors and security pros. I attempted to smooth over some of that natural friction and show that an evolved approach to DMZ design would make a better IT infrastructure for everyone. With colocated trust zones, your DMZ servers become part of your much-larger virtual infrastructure, and they can enjoy all the benefits of that environment such as high availability and backup services.
It was with trepidation, then, that I clicked to a slide with the DMZ setup shown below. I explained how virtualization moves networking into the virtual host, which means it’s possible to colocate multiple trust zones within a single box.
My security-minded audience thought I was crazy to suggest hybridizing trust zones in the DMZ configuration, but I wanted them to consider this DMZ design, even if it might never be implemented. It’s not that this design is any less secure than more common methods, it’s simply that security admins weren’t yet ready to accept consolidation.
Fast forward two years to May, 2011, when I’m presenting an updated version of this presentation to a similar crowd. During a break, an attendee approached me and explained how his company had implemented exactly the DMZ setup my slide suggested. Why was the idea of hybrid trust zones becoming more accepted? Because virtual LANs (VLANs) were becoming more trusted.
DMZ setup: From air gap to VLAN to colocation
DMZ design has traditionally relied on network segregation. In the earliest days, that segregation required an air gap, an actual physical separation of hardware and connections.
But it wasn’t long before VLANs and their logical traffic separation were considered secure enough that an air gap was no longer necessary. The security of VLANs remains debatable by a vocal minority of security professionals, but most IT shops find their ease of use far outweighs their potential risks.
VLANs at their core are the implementation of protocols such as 802.1q. The IEEE approves these protocols through a process that involves substantial community input. Technologies that support VLANs must follow the specification, which means those technologies are also approved tools when properly configured.
VLANs in VMware vSphere and Microsoft Hyper-V follow these protocol standards, making these platforms necessarily secure as well. Of course, it’s possible that exploits to the code used to implement the protocol may someday be found, but you could say that about a lot of code.)
To improve DMZ design, particularly in today’s evolving world of private cloud computing, our industry needs to take this approach a step further: by extending VLANs of different trust levels into virtual hosts. Some IT shops are already doing that today. DMZ consolidation makes management much easier for IT admins, and smarter management usually leads to better security.
Still, when extending VLANs, virtualization admins must take great pains to ensure that their hosts and VMs are properly configured. Technologies such as Cisco Systems’ Nexus 1000V and emerging protocols such as IEEE’s 802.1qbg and 802.1qbh can further reduce the risk by returning network configuration control to the network team.
Notwithstanding the technology you ultimately deploy, it’s important that security and IT admin teams work together and make this type of DMZ design potentially acceptable.
This was first published in July 2011