Rational Survivability

It’s no doubt apparent that trafficking in the ideas and concepts surrounding both virtualized security and securing virtualized environments really honks my horn.  I’ve been writing about it a lot lately, and it’s starting to garner some very interesting amounts of attention from lots of different sources.

One of those sources sent me an email after reading some of my ramblings and framed a discussion point that I was writing about anyway, so I thought it a perfect opportunity to discuss it.

Specifically, when a disruptive emerging technology bursts onto the scene with many of the threats and vulnerabilities associated with said technology being mostly theoretical, conceptual and virtual in nature, how does one have a very real conversation with management regarding what should be done proactively to (and please forgive me both ISS and ISS-naysayers) "get ahead of the threat."

That is, how do you start talking about the need to assess and make actionable, if possible, the things necessary to secure such an impacting technology?  Asked not to be identified when I quoted him, I believe one of my readers summed this up quite nicely:

"I really enjoy your blog posts about virtualization security, since it’s a challenge I’m dealing with right now. The real problem I’m finding is explaining the security issues to people who don’t get security in general, and double-don’t-get-it in the context of virtualization.

The two points I really try to get across are:

1. the fact that there aren’t any common, well-known attacks specific to virtualization in the wild (guest hopping etc) is not a good thing, it’s a BAD thing; they’re coming!

2. a virtual server is like a little mini-network where essentially none of our existing security measures apply (I guess I’m mostly thinking of IDS here)

Am I hitting the right points, do you think? Where else can I go with this, since the "threat" is pretty much "I don’t know but something someday?"

My response is straightforward.   I think that he’s dead-on inasmuch as explaining virtualization and the risks associated with it is difficult, mostly because the "threats" are today mostly theoretical and the surface area for attack — or the vulnerabilities for that matter — just aren’t perceived as being there.

So the normal thing to do is just suggest that what we have will be applied to solve the "same" problems in the virtualized context and we’ll deal with the virtualization-specific threats and vulnerabilities when they become more "real." <sigh>

We can shout to the treetops about what is coming, but people don’t generally invest in security proactively because in many cases we’ve seemed to accept that the war is lost and we’re just looking to win a battle every once and a while.  <sigh^2>

It doesn’t help that we’re trying to build business cases to start thinking about investing in securing virtualized environments when the threats and vulnerabilities are so esoteric and by manner of omission executives are basically told that security is something they do not need to focus on any differently in their virtualization deployments.

So I only have a few suggestions for now:

1. I’d use my preso. to help lubricate the conversation a little; it sums most of this up nicely
2. Don’t make the mistake of suggesting the sky is falling — it may be, but that’s not going to get you timeshare or share of wallet
3. In this nascent market, we have to communicate the potential exposure and elevated risk in
   the language of and terms associated with business; why should you spend time and money on this versus, say, patch management.
4. You better have an answer to this one: "Virtualization is going to save us money, now you want to spend more to secure it!?"
5. Abstract the discussion related to investment in terms of pushing vendors in your portfolio (by spending time/money) on making sure they will have something to offer you when you need it and start assessing your business and IT plans to see how they align to policy today
6. Start to build what will be the best practices for what your virtualized environments ought to look like with what you know now, BEFORE you start having to put them into production next week
7. Talk with your auditors — make them your allies.  Ask them how they expect to audit and assess your virtual environments (be careful what you ask for, however)
8. Use what you have; you’re going to have to for a while anyway.
9. Start testing now; demonstrate empirically how existing compensating controls will/will not satisfy your security policies in a virtualized construct
10. Keep calm.  By the time we get around to cleaning this mess up, we’ll have another pile right around the corner.  This is a continuum, remember?  Same crap, different decade. At least we have twitter and facebook now.

In closing, and without sounding like a clucking chicken, check out this summary of a recent vulnerability disclosure on how to run arbitrary code on a VMware GuestOS thanks to a "feature" in VMware’s scripting automation API. Dennis Fisher over at SearchSecurity did a nice write-up about Mark Burnett’s recent discovery:

The folks at VMware have been in the news quite a bit of late,
thanks to their big IPO and their discreet acquisition of Determina a
couple of weeks ago. Now, the company’s core virtualization product is
getting some attention, but not the kind company executives will like.
Mark Burnett, an independent security consultant and author, recently
posted a long description of a vulnerability in VMware’s scripting automation API that he found.

The vulnerability comes down to this: The API allows any script on
the host machine to execute code and take other actions on any virtual
machine that’s running on the PC, without requiring any credentials on
the guest operating system. This presents a number of problems, as
Burnett points out:

The problem is that a malicious script running within
the context of a regular user on my desktop can run administrator-level
scripts on any guest I am currently logged in to. Using Ctrl+Alt+Del to
lock the desktop of those machines does not prevent VIX from executing
commands on the guest. Even if I log out of each guest machine the
malware can just queue the command to run the next time I log in at the
console of the guest OS.

However, this is in fact a feature that the VMware developers
intentionally included. VMware told Burnett that, in essence, anyone
who can access the virtual machine APIs on a machine can access the
virtual hard disks anyway and would be able to attack the PC from that
direction. But it seems to me that Burnett is on to something here.
Sure, there are plenty of other methods for attacking virtual machines,
but that doesn’t mean this should be ignored.

Burnett also has found a way to mitigate the problem by adding a switch to the VMX config file.