Chris Hoff at Rational Irrationality asks a few questions about Burton Group’s Five Immutable Laws of Virtualization Security. He’s right that I think that some of his concern is nitpicking about words (yes, Chris, people debate the intent and meaning of the Constitution and even amend it from time to time). On the other hand, I agree that the wording used in Baseline Magazine is confusing. I am not sure whether that is my fault or the magazine’s fault.
In any case, the intent behind Immutable Law 1 is very straightforward. It derives from folks periodically suggesting that because a VM runs in ring 3, a compromise of the VM’s kernel is less significant than a compromise of the kernel of a physical system, since the VM kernel runs in ring 3.
This is wrong in a very important way. Immutable Law 1 tries to describe this. If you take a physical box running an OS and a set of applications, then port it into a VM, a compromise at the kernel level of the VM has the same impact as a compromise at the kernel level of the physical box (even though it is running in ring 3).
Immutable Law 2 addresses the "virtual is more secure than real" approach that tries to compare a hypervisor’s attack profile to the OS attack surface. Since the hypervisor attack surface is additive (.e. the OS is still there), this comparison is inappropriate.
Hope this helps.
Hey Pete:
This is where I have a problem with law #1 because I believe this logic is flawed from the perspective of exploring the delta in “risk” associated with a potential compromise.
Specifically, given your very example, the “damage potential” to the system if a VM is compromised could lead to a compromise of the underlying VMM or other VM’s running on the same system. Hence, the “impact” is not the same, it is greater.
Per your law in #2, you already state that the hypervisor’s attack surface (which could be exposed in a compromise of a VM) is additive. The word “additive” does not imply sameness,
Further, since you were not specific, I’d suggest that the damage potential and risk is even higher in a hosted virtualization platform as opposed to a bare metal install.
I’m not looking for a pissing match, I would simply like to understand how they can be framed as laws that are immutable when it’s not clear to me that they are.
I’m honestly not interested in painting 20 corner case exceptions that are reductions to the ridiculous, but just issues like the ones above.
So, if we can dispense with the “Rational Irrationality” stuff that would be swell.
Thanks,
/Hoff
@Chris -
I don’t know what to say. If I try to explain the Laws, then you say I am using different words, which is exactly what I am doing. These are Immutable Laws and not immutable words.
It would be great if you decided to help me pick words that work… if you can ever figure out what I mean.
[Anyone else out there in the blogosphere having trouble understanding my points?]
My point for Immutable Law 1 is that all existing attacks still work in the same way when you move from physical to VM.
The potential for attacking of the VMM in your example is downstream and different, since it could never be successfully used against a physical system. That is also the reason for Law 2.
Hope this helps.
Pete
I’m not trying to be difficult for difficulty’s sake, Pete.
However…
I’m flattered that you’re suggesting you wrote the entire Baseline Magazine article using different words to explain this differently JUST FOR MY SAKE since you obviously think nobody else is having trouble understanding them… [roll eyes here]
If they were self-evident and infallible, I don’t see why you’d need to explain them any differently, besides just making this an ego thing which is not the reason I’m interested in resolving it.
I’m simply waiting on you to explain it to the point that the lightbulb goes on (or doesn’t.) Now, you’ll prolly take that path where you suggest you have no reason to, but given the fact that you’re going to all that effort to re-write your laws JUST FOR ME, I suppose you can see it through to the end?
There are at least 2 other people who commented on my blog that suggest there are more than one way to interpret your wording…that doesn’t mean you’re wrong or I am right, it just means there is opportunity for clarity.
I don’t think I’ve got answers to some of the important questions I have, and this isn’t the best medium to seek those answers…we’ll continue via voice and email and then at the end, when you’ve explained it to me, I will honestly reply with the outcome.
Honestly, I’ll get over the “immutable” word — just like I did when Oracle marketed their “unbreakable” database…I’m just allergic to (and you should be, too) anything in security or technology that is “marketed” as such.
/Hoff
@Chris -
My point about getting others involved was to see if they could figure out how we are miscommunicating. I honestly don’t see what is so hard about “all the same attacks work the same way.”
If you think that is wrong, simply give an example of an attack against a physical system that doesn’t work against that system in a VM. There may be one out there, but I can’t think of one and I’ve asked dozens of others to come up with the contra-example.
I think you already agree that the hypervisor risk is additive – any added software increases risk in a system.
We haven’t even mentioned separating resources (Law 3) or aggregating resources (Law 4), but they are as straightforward as the principle behind a DMZ.
And forget about 5 for now.
Btw, I didn’t read the Baseline Mag article and don’t really plan to. It may be an excerpt of what I’ve written or a complete rewrite. Please feel free to ignore it.
Pete:
I owe you the use cases I’m thinking about, and I will endeavor to write them in the next couple of days.
To give you a taste of what I mean (although it’s depending upon stuff that’s coming — that I have seen work, however):
>> If you think that is wrong, simply give an example of an attack
>> against a physical system that doesn’t work against that
>> system in a VM. There may be one out there, but I can’t think
>> of one and I’ve asked dozens of others to come up with the
>> contra-example.
…I offer up the example of the VMsafe demo given at VMworld. A physical server was susceptible to malware infection where a VM with the VMsafe hooks enabled was not.
Same OS/App. combination between the physical server and the VM, the only difference was the VMM and VMsafe.
That meets the challenge above, does it not?
/Hoff
@Chris -
No, it doesn’t satisfy the criteria.
You can come up with many different scenarios where configuration and architecture changes from one to the other (yes, it is the ceteris parabus thing).
Putting a new control in place is exactly what you should do to leverage virtualization (see, e.g., When Virtual is Better Than Real by Chen and Noble) but that changes the equation.
The ability to add controls to leverage virtualization is indicated in Law 4 as well.
Just so I understand, you’re lumping every single virtualization approach and technology into a single bucket (including application/OS virtualization, storage virtualization, client virtualization, parititions, hosted/bare metal virtualization, etc.) and then when I offer up a concrete example of a feature in a single vendor’s platform, it doesn’t qualify!?
I’m sorry, but I maintain that VMsafe (being part API, part integrated function built into the VMM) is a function of the hypervisor and thus satisfies your challenge, invalidating your law.
Specifically, as a function of the VMM, an attack against the VM protected by virtualization platform was resilient against attack where the same physical instantiation of software sans VMM was not.
You can’t ask for specifics and then paint them as corner cases.
/Hoff
@Chris -
You are welcome to see it any way you want.
At some point, you might want to describe the imaginary function that was applied via VMsafe to satisfy your conditions, the class of attack it automatically, persistently protects against, and the reason why no physical system could ever protect itself from the same attack class.