Security Basics mailing list archives

Re: Virtualisation of two security domains


From: John Morrison <john.morrison101 () gmail com>
Date: Mon, 25 Jul 2011 20:34:19 +0100

William,

Generally I would not be "comfortable" with this. The VMWare document says

   The impact of the potential loss of separation of duties — and
   the associated risk that an unqualified individual might be in a
   position to introduce vulnerabilities through misconfiguration
   — is greater in this case than when you have separate physical
   trust zones, but the potential impact is minimized by the fact
   that network security is still physically enforced.

   Most security issues do not arise from the virtualization infrastructure
   itself but from administrative and operational challenges.
   The primary risks are caused by a loss of separation of
   duties. When this occurs, individuals who lack the necessary
   experience and capabilities are given an opportunity to introduce
   vulnerabilities through misconfiguration.

This highlights my concern. If the security team had control over the
VMs and the ESX servers I would be comfortable with it. However, as it
is a server the server team normally would be responsible for this
layer. The server team's primary concern is not security. The
temptation would be always there to reduce the security (as a
temporary fix - that never gets properly resolved once the system is
live) to get it up and running. VM sprawl already occurs in most
environments. Virtual servers appear without appropriate justification
and no trail for the auditors to see what each does or why.

If the (second and third) models proposed in the VMWare paper are
implemented the security boundary is inside the ESX and between the
VMs. This boundary is where the security team's responsibility lies.
Unfortunately putting the security team in charge of the VMWare
infrastructure (vCenter, vSwitches, service console) would cause
friction that would lead, in my opinion, to political infighting (or
even open war fare between the teams, auditors and operational
management) and gradually erode security to the point where it is
completely ineffective.

As a disadvantage of "Fully Collapsed Trust Zones" the VMWare document says

   Greatest complexity, which in turn creates highest chance of
   misconfiguration

To me this neatly sums up why not to do it. Complexity is the devil's
tool. Complexity and security do not mix. If it is complex to
understand, complex to implement, complex to troubleshoot, complex to
maintain, complex to audit, complex to enforce, complex to test then
it is broken. You cannot be confident that it is adequately secure.
And it will not be adequately secure.

John

On 23 July 2011 00:34, Wilmar Sulaiman <wilmar.sulaiman () gmail com> wrote:
Hi all,

Over the number of years, the most common / acceptable security
architecture to separate two security domains e.g. DMZ and Internal
Zone is through fully segregated physical server and network hardware.
For example, a Web Server (in DMZ) will sit on different physical
hardware to its database server that sits on Internal Zone.

As Server virtualisation is now a proven de-factor standard for any
significant server infrastructure deployment, in general are
compliance/risk/auditor comfortable of using virtualisation technology
to separate these two domains?
(http://www.vmware.com/files/pdf/network_segmentation.pdf). Any point
of view and thought about this topic?

PS: Note that I use the word 'comfortable' rather than 'Is this
solution secure?" because I can do risk assessment and put more
controls in if required to reduce the risk of server consolidation.

Wilmar

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, 
how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, 
purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for 
set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital 
certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------



------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------


Current thread: