DMZ and segregation

[Dr_Virt]

As our infrastructure continues to consolidate, we have come accross two roadblocks for which no agreement has been reached. I would like to put this before the forums to gain insight from others who have wrestled with these isues:

1) Sharing hosts between security realms (DMZ & Internal) - Do you or don't you seperate your VMware hosts by security realms? What arguments for and against did you deal with? What justification was used for the final decision?

2) Is the DMZ valid any more - As more and more systems are both internal and external facing, is the DMZ valid anymore? There are so many holes in the firewall and IDS, would you ever see the compromised web host sucking all data from the SQL host? Is the truly flat network coming?

Starting with number 1, I will start with the statement that this is no longer a concern. VMware's ESX and vSphere have been thoroughly tested to this point and no known vulnerabilities have been found which can be executed in production (not including labs).

Regarding number 2, I believe the days of the DMZ are numbered. I have deployed both DMZ and DMZ'less infrastructures without security incident. I believe the DMZ has rarely been deployed securely and does little to prevent data loss and penetration. I place a greater confidence in trusting no system and isolating each according to needed protocols.

So, I would like to know your thoughts, and experiences with these matters when dealing with security issues within your virtualized infrastructure.

[AndreTheGiant]

There are some whitepapers about DMZ in virtual environment:

http://www.vmware.com/files/pdf/network_segmentation.pdf

http://www.vmware.com/files/pdf/dmz-vsphere-nexus-wp.pdf

[Texiwill]

Hello,

If you place the proper defense in depth within your environment and keep your DMZ network traffic separate than your non-DMZ traffic as you should then you will have no issues with everything within the same set of hosts. However, this is predicated on having a proper defense in depth and additional monitoring/auditing to ensure issue do not crop up. Common issues that have been brought up against this for which you will need an answer:

• DMZ VM appearing on Internal Network? -- Lockdown network changes and audit for changes and prevent these changes
• Internal VM appearing on DMZ Network? -- Lockdown network changes and audit for changes and prevent these changes
• DMZ Traffic seen by Internal as on same vSwitch, etc. -- Ensure you have portgroup isolation technology (vShield Edge) or use multiple vSwitches not just muliple portgroups and different types of vSwitches at that.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[JDLangdon]

Edward Haletky wrote:

• DMZ Traffic seen by Internal as on same vSwitch, etc. -- Ensure you have portgroup isolation technology (vShield Edge) or use multiple vSwitches not just muliple portgroups and different types of vSwitches at that.

Tex,

What kind of trouble am I going to run into by having all traffic on the same vSwitch?

jd

[michael_40catbi]

Hello Everyone,

@Dr.Virt

1)     I agree that you may share hosts between security realms but not for the  reasons you state. It is infeasible, to test any security product  sufficiently

to determine it ability to successfully resist attack.  Breaches are discovered continuously and I laud VMware's responsible behavior in closing these holes quickly.  As software defects remain a constant, we must design sustainable security that includes compensating controls.

If you implement compensating controls for the hypervisor, infrastructure, endpoint threat surfaces then and only then can you assure the safety and resiliancy of your virtualized systems. The true beauty is that virtualization enables security automation and resiliance that are far more economically feasible then in previous technology platforms.

2)     I completely agree, but note this further reinforces that you must not "absolutely" trust the hypervisor and any other virtualized component.

They are all software, well everything is software now, but I am sure you get the idea.

@Andre and Texiwil

These are great references, I can only add that CSI, NIST and others have good best practice and hardening guidence as well.  For example the NIST "Guide to Security for Full Virtualization Technologies" is here: http://csrc.nist.gov/publications/nistpubs/800-125/SP800-125-final.pdf.

@JDLangdon

It depends on the traffic and the sensitivity of the data and systems. A single switch increases risk from misconfiguration, defect, and attack. If you implement controls that are commensurate with the protection and risk requirements you'll be fine. I love single switch designs because it makes my product absolutely necessary in sensitive environments 😉 (and I am sure my competitors feel the same way)

[JDLangdon]

Michael Berman wrote:

@JDLangdon

I love single switch designs because it makes my product absolutely necessary in sensitive environments 😉 (and I am sure my competitors feel the same way)

What is your product?

[Texiwill]

Hello,

If you have data on the same vSwitch you could run into failed-open type issues between portgroups if there ever is a successful layer-2 attack. You also need to fully understand how traffic flows amoungst your VMs through the portgroups as well as understand the security settings. Promiscous VMs would be dangerous in this situation. Also consider one VM acting as a DoS against all VMs on the vSwitch....

The best approach if you want to use a single vSwitch is to get vShield Edge and enable portgroup isolation so that nothing can cross port-group boundaries. This level of defense in depth would be required. You may also want to use different vSwitch control planes (which means different vswitch constructs) such as a local VMware vSwitch, Nexus 1000V, or dvSwitch. This way traffic cannot cross the boundaries of the vSwitch constructs. Once more you need to think of defense in depth.

Michael's product is Catbird which would also provide isolation using multiple vSwitches even ones not connected to a pNIC, as well as across multiple portgroups.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[Dr_Virt]

Thank you all for your comments. Many have gone beyond my original intent to be descriptive and not prescriptive. While vShield, Nexus, and other tools are necessary to support “defense in depth”, they address the how while I am more focused on the why. I have not proposed a vSwitch architecture, nor a security requirement. I have asked what the architecture be concerned with.

We have, for many years, adhered to a pretty similar model with zone segregation and “network security”. As virtualization of all resources (hypervisor, network, security, storage, etc.) consumes once siloed architectures, how will the model adapt?

I chose the DMZ as my beginning point as it seems to be a point of contention with many architects with whom I discuss. Some hold to its use, others discard it quickly. The unanswered question is why. Is it truly needed? Can we be protected without it? How does is scale and flex in a virtual world? Is it even real as so many DMZ systems reach back for resources?

As for “defense in depth”, I believe that quite soon the endpoints will be the security focus and the various plumbing will be too dynamic to secure on a scalable basis. As networks, storage volumes, VMs, firewalls, and hosts are reconfigured to provide the demanded services, the security must be able to be as dynamic. The border firewall is most likely here to stay, but as IPv6 and virtualized endpoints become the norm with dynamic flexibility in between, the how will migrate toward the nodes.

[Texiwill]

Hello,

Why should you segregate your network traffic?

     * Because it is trivially easy to misconfigure the virtual network and out of the box it is misconfigured.

     * DMZ traffic on the same transport as other VMs can cause issues if you are not intimately familiar with how traffic flows with the virtual environment and through WHICH constructs they flow.

     * Even with VLANs in use, you may soon run out of VLANs for every network you need to use. Therefore a different type of segregation may be required.

     * While there has not been a vNetwork Layer-2 attack who is to say there will not be. Need to plan for the future not the current functionality

     * Use of VLANs may violate your existing security policy, should this change then it is not much of an issue.

     * Each vSwitch type has its own control plane. For dvSwitches that control plane is vCenter what happens if vCenter dies? For Nexus 1000V there is one control plane across the cluster. for VMware vSwitches there is a shared control plane (with segmentation) within a single host. Control planes fail-open not safe or closed.

Will security move to the Endpoint?

   * Some security will move to the endpoint. Ala vShield Endpoint, but vShield App and its ilk are actually a network filter within the vSwitch constructs not the VM.

   * If you move security to the endpoint then security of the vSwitch could be ignored. You are already in the network by the time you hit the endpoint. Does this imply that your vNetwork will not be attacked without attacking the endpoints. I think so. Endpoint security is one aspect, not where everything is going IMHO.

What about Trust Zones?

   * You need to know what data is within the trust zone and eventually how to protect the data.

   * Protect the data is paramount.

   * Protecting the transport will also protect the data.

Networking is not everything....

   * THe vNetwork is not everything to secure.

   * There is the hypervisor, the VM, the guest os

   * There is the console, etc.

   * Once in the environment any aspect could be attacked.

Multi-layer defense in depth is incredibly important within the virtual environment. When you go to the cloud the security risk multiplies quickly. So yes, I would still segregate my traffic. I do not know the future but I need to protect everything now and those protections should grow as we go forward. Perhaps it will all go to the interfaces (ie Edge and Endpoint) but once in the network how much damage could you do regardless of those types of protections?

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[JonathanG]

In my opinion network based firewalls and segregation are defunct in a virtual enviroment, especially as VMs vmotion around and can even move into the cloud. Host based security is an option to move firewall, DPI etc from the network to the host with a centrally managed console. Take a peak at:

http://us.trendmicro.com/us/products/enterprise/datacenter-security/deep-security/

[Texiwill]

Hello,

Actually Trend Micro's Deep Security 7.5 product is a combination firewall and endpoint security product that uses the VMsafe-Net and EPSec technologies to provide traditional firewall and anti-malware protection and also provides some nice Fail-Safe options. It acts and feels just like a firewall on the network, it is just placed differently. You are correct 'traditional' firewalls are problematic (unless you happen to use UCS Fabric extenders and the upcoming vmxnet3 driver to pass through the hypervisor -- which is another story all together). Trend Micro has a class of firewall that fits between the VM's vNIC and after the vSwitch portgroup just like any other VMsafe-Net firewall, which includes vShield Zones, vShield App, Altor, Reflex Systems vTrust, Checkpoint, IBM, etc.

It is still a network based firewall with the traditional rule sets and management approaches.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf