« Security 3.0 and the Perimeter Myth | Main | MAC Attacks and Disguise »

Wired Scenes -- Netsec and Virtualization

Greg Ness continues to develop a narrative that hits close to home.  It's clear that his lunchtime conversations with Allwyn Sequeira get into the "deep tech."

Greg and Allwyn arrive at some interesting conclusions with respect to network security and virtual machine migration.  In response to a comment on his Archimedius blog, Greg characterizes the idea of limiting VM movement to specific security domains as a short term fix.  In a sense I agree, but my consideration of the long term brings me to the conclusion that the solution lies in policy implemented by "smart" constraints.

Greg hits one key issue when he states:

There is also the issue of lock-stepping server and network policies, at a time where virtualization is enabling more responsiveness.

Right.   But, what if the independently established network policies and the independently established server requirements could be reconciled? What if we could identify a solution that satisfies the requirements of both, a workable compromise?  That's an approach we're pursuing at Replicate Technologies, the company I officially joined last month.

Consider this:  It's not only network security, but also network integrity that must be maintained when supporting the group migration of VMs.  If one wants to move an N-tier application using VMware's VMotion, one wants a management framework that permits movement only when the requirements of the VM "flock" making up the application are met by the network that underpins the secondary (destination) location.  By that, I mean:

  • First, the assemblage of VMs need to arrive intact. 

If, because of a change in the underpinning network, a migration "flight plan" no longer results in a successful move by all the piece parts, that's trouble.  If disaster strikes, you don't want to find that out when invoking the data center's business continuity procedure.  All the VMs that take off from the primary location, need to land at the secondary.

  • Second, the assemblage's internal connections as well as connections external to the "flock" must continue to be as resilient in their new location as they were in their original home. 

If the use of VMotion for an N-tier application results in the a new instance of the application that ostensibly runs as intended, but is susceptible to an undetected, single point of network failure in its new environment, someone in the IT group's network management team will be looking for a new job.

The "containers" I'm speaking of are both security containers and network integrity containers.  In order to be useful in a production computing environment, these containment areas must have identified permeabilities ... connections with peers, customers, and providers.   

I'll take the opportunity in the coming weeks to write more about the nature of the containers we (Replicate) foresee putting into place.  In the meantime, be assured that, like Greg and Allwyn, the last thing we want to put into place is a brittle, overly restrictive sandbox that incarcerate VMs.  In addition, we want to make best use of VMs and VLANs, while simultaneously restraining any VM under management from making VLAN connections that would compromise network security.

Virtsec in the Trenches | AlwaysOn



At my Archimedius blog one of the visitors shared his strategy, which involved limiting VMs to movement within specific security domains. While this is a smart short term step, over the medium and long term it still represents limiting the infrastructure agility enabled by virtualization at the heart of the business case. There is also the issue of lock-stepping server and network policies, at a time where virtualization is enabling more responsiveness.

Even if you constrain movement the VMs behind well-tuned intrusion protection systems and firewalls may still be vulnerable. Unpatched instances can appear minutes after signature tunes or vulnerability scans. As I mentioned in The Beginning of the End, the heightened flexibility of virtualization introduces change factors that hasten the obsolescence of any static security measure. You may limit VM traffic within security domains, but you still have the issue or percolating vulnerabilities within each domain microcosm. Adding more domains means more management and observation resources and less flexibility.


A similar notion is to architect the network around security (and other constraints). This may be tolerable in the short term, but over time you could offset some of the benefits and flexibility of virtualization by constraining traffic to cordoned off VLANs. In his NGDC deep dive presentation (which inspired this blog series about) Blue Lane CTO Allwyn Sequeira notes the eventual outcome “VLAN spaghetti”, a term used long before virtsec. Taking it a step further you get heightened complexity and constrained mobility.  ...

Powered by ScribeFire.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.