Rational Survivability

My goal in the next couple of posts is to paint some little vignettes highlighting some of the more interesting points I raise in my presentation series "Virtualization: Floor Wax, Dessert Topping and the End Of Information Security As We Know It."

The first issue up for discussion is the need to recognize and separate two concerns which are unfortunately most often intertwined when companies are considering virtualization and its impact to their IT operations and security programs. 

My goal here is not to try and explain away every nuance of this slide or push a conclusion on anybody, but instead plant the seeds and set the premise for discussion’s sake.

The slide to the left sums up the point reasonably well, but here’s the associated scaled-down narrative that accompanies this slide:

Companies need to approach addressing each of these issues by assessing the risk associated with each separately and then juxtaposed.

Treating them as a single concern — as most do — leads to an unfortunate series of chicken-egg debates that usually do not address the things that really matter in the first place.

The point here is that while these concerns are very much related and both important, the order in which they are addressed is often critical.

Specifically, one can take an incredibly secure solution and yet still manage to deploy it in an incredibly insecure manner.  Even if the virtualization platform one chooses is (by some mythical standard) impervious to
compromise (*cough*,) given specific configuration constraints,
deviations from those constraints can lead to exposure.

If the manner in which virtualization platforms are configured, managed, monitored and secured after you’ve already deployed them are not consistent with the rigor and diligence we’ve applied to our non-virtualized infrastructure (and by observation they are not,) worrying about how secure or insecure your VMM platforms are is a waste of synaptic processes.

My experience has shown that most organizations have simply plowed ahead
and accepted or ignored the risk associated with deploying virtualization
platforms, accepting on blind faith the claims of virtualization vendors and assuming that the VMM providing the abstraction layer between
hardware and software is at least as secure (if not more so) as a non-virtualized installation of the operating system.

This is usually done because the economic benefits of virtualization which are absolutely quantifiable far outweigh the perceived risks associated with virtualization which are not (or are at least difficult to produce.)

I’m unsure how exactly most companies are assessing risk against their virtualized environments formally
since many of them admit to not having a risk assessment methodology in
place to do so.

It would seem that most folks simply look at the
known vulnerabilities associated with a vendor’s VMM and the current
threatscape and make a swag as to the resultant residual risk given any
compensating controls that might be in place.  In many cases, however, the "risk" we’re debating is based upon threats and vulnerabilities that may not even exist, so we’re academically making judgment calls based on possibility versus probability.

Yikes.

How many times have you entered into debate with *someone* in IT, security, audit or the business arguing about "securing virtualization" after someone’s seen a "Blue Pill" presentation when in all honestly the company has already deployed hundreds of VM’s and still hasn’t segmented the network or built a risk assessment framework to quantify the business impact?

See what I mean?

/Hoff