The Five Laws Of Virtualization – Not Immutable Any More?
Update: Please read the comments section. Rather than force playing blog pong, I’ve cross-posted some of the comment thread from Lindstrom’s blog.
I believe I’ve offered up a clear present and future case that invalidates "immutable" law #1. Pete, of course, disagrees…
—
I’ve commented a couple of times about the confusingly contradictory nature of Lindstrom’s Burton’s "Five Immutable Laws of Virtualization." I go back every once and a while and try to utilize them as suggested by their author to see what pops out the other end:
When combining the standard risk principles with an understanding of the use cases of virtualization, a set of immutable laws can be derived to assist in securing virtual environments
I’m not sure I really ever got an answer to what those "…standard risk principles" are and as such, there seems to exist a variability based upon interpretation that again makes me scratch my head when staring at the word "immutable."
So I try and overlook the word (as did the author/editor in the title of the Baseline magazine article below — it was omitted) and I find myself back where I started which sort of makes sense given the somewhat reflexive and corollary nature of these "laws."
This is where I get stuck. I don’t know whether to interpret each law as though it can stand on its own or the group as a whole.
Basically, I have a hard time seeing how they enable making more effective risk management decisions any easier. I will admit, it could just be me…
Further, I’ve noticed the very careful choice of words used in these laws, and interestingly they don’t appear to be consistently referenced which would defeat the purpose of calling them "immutable," no?
Take for example the original wording of the five laws from Burton’s original minting and compare it against an article appearing in Baseline magazine from the same author(s) — Lindstrom in this case:
Original Burton Article Example:
Law 1: Attacks against the OS and applications of a physical system have the exact same damage potential against a duplicate virtual system.
Baseline Magazine Article Example:
Law 1. Attacking a virtual combination of operating systems and applications is exactly the same as attacking the physical system it replicates.
This example may seem subtle and unimportant, but I maintain it is not. I suggest that they mean very different things indeed. I mean, if these are "laws," they’re not something you get to reword at a whim. I trust I don’t have to explain why.
One could have lots of fun with the Constitution if that were the case. 😉
There are additional differences scattered throughout the two articles. See if they appeal differently to you as they did to me.
Now, I’m sure Pete’s going to suggest I’m picking nits and that I’m missing the spirit and intent of these "laws," but before he does, I’m going to remind him that I didn’t come up with the title, he did. I’m merely stuck on trying to assess whether these are actually "immutable" or "refutable" but I am admittedly still having trouble getting past step #1.
Help a brother out. Explain these to me to where they make sense. Pete tried and it didn’t stick. Maybe you can help?
/Hoff
Five Immutable Laws of Virtualization Security: Clarifications
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 …
Hmmm. I think if there was to be a "rewrite" as such, it would be:
"The attack vectors for a combination of virtualised operating systems and applications are identical to those of the physical system"
which obviously makes sense. That would be immutable, to my mind.
They are actually not the same to me really because the interactions are more complicated.
What you could say is that the attack vectors specifically applicable to the OS that is virtualized do not necessarily exceed the vectors present in a physical system.
Reading the two laws though, the first is principally concerned with risk and/or loss and the second seems more concerned with simply opportunity.
Actually the first law in the first article is a much sounder statement or is at least written such that it can be defended a bit better. It is also blander with less of a root system. The problem with the law as espoused in the second article is the fact that it is fairly ambiguous and therefore open to review by a "higher court". 😉
They look like a simple rewrite for two different audiences in all actuality. Maybe it was intentional.
–David
@Colin and @David – This is the discussion I'm having offline with Pete…I think I have a number of cases that invalidate or at least complicate the laws, and I'm having trouble verbalizing them.
I'll update this post with some of my points once I speak to Pete again because something just isn't clicking for me and I can't properly articulate why just yet.
I think that the ambiguity is there to make for better sound bites; I just don't see how it makes it easier or more helpful to assess risk. I know Pete's working on some things to illustrate the use cases, but I'm going to get to the bottom of this without simply making it sound like I just don't like the idea without merit.
Thanks for the feedback as it at least suggests that I maybe suffering from the split-brain personality in assessing these laws…
/Hoff
Good stuff Hoff.
I think maybe you need a set of Laws from the Operations and a set from the Risk/Audit side etc…
Mixing them is maybe not possible since they do cover some nearly mutually exclusive concepts.
I look forward to reading more. You make me think and I especially appreciate your ability to call BS on something only after making sure it is BS instead of going for the neon flashing blog headlines.
–David
@All –
Please don't read the Baseline Mag article – I don't know where it came from (yet). It should be straightforward to find the things I've written at Burton Group's blog or Spire Security. I am also happy to forward you the report I wrote on virtualization security that included the five immutable laws.
In short, Law 1 is simply that every attack against a physical (non-virtualized) system works the same way against that physical system in a VM.
Law 2 says the hypervisor risk is additive – anytime you add software to a system, you increase risk.
There is some discussion on my blog about this as well – I tracked back to this post but it doesn't seem to have worked.
Pete Lindstrom
[I am cross-posting this from Pete's blog in the comments section, because it gets to some of the meat of my points…]
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):
Pete >> If you think that is wrong, simply give an example of an attack
Pete >> against a physical system that doesn't work against that
Pete >> system in a VM. There may be one out there, but I can't think
Pete >> of one and I've asked dozens of others to come up with the
Pete >> 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
They are actually not the same to me really because the interactions are more complicated.
What you could say is that the attack vectors specifically applicable to the OS that is virtualized do not necessarily exceed the vectors present in a physical system.
Reading the two laws though, the first is principally concerned with risk and/or loss and the second seems more concerned with simply opportunity.
Actually the first law in the first article is a much sounder statement or is at least written such that it can be defended a bit better. It is also blander with less of a root system. The problem with the law as espoused in the second article is the fact that it is fairly ambiguous and therefore open to review by a “higher court”. 😉
They look like a simple rewrite for two different audiences in all actuality. Maybe it was intentional.
–David
Good stuff Hoff.
I think maybe you need a set of Laws from the Operations and a set from the Risk/Audit side etc…
Mixing them is maybe not possible since they do cover some nearly mutually exclusive concepts.
I look forward to reading more. You make me think and I especially appreciate your ability to call BS on something only after making sure it is BS instead of going for the neon flashing blog headlines.
–David
Over on his blog, Pete suggests that my example does not qualify as a refutation of Law #1:
@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.
VMsafe and the emerging INTEGRATED functions that are being and will continue to be built into many vendor's hypervisors/virtualization platforms will clearly demonstrate that virtualization platforms will offer *some* security functionality that is not present in non-virtualized environments. Regardless of whether you consider this more or less "secure" is certainly a product of how it's implemented.
As features such as VMsafe and other security-enhancing capabilities INTEGRATED into the VMM become standard practice, you can't suggest they are a "compensating" control.
However, dismissing what is an obvious trend in VMM architectures across the industry as an "architecture" change that is a one-off additional "control" is short-sighted and silly. The "ceteris parabus" crutch is a cop-out.
/Hoff