Virtualization Automation – A Proper Virtual World

Fear for the Sake Of Fear? Hyper-Jacking Myths?

September 10th, 2008

Virtualization Critical Evaluation – Chapter 07

I ran straight into a brick wall this week. Not to worry, no injuries, much to the displeasure of some I am sure. However, I do this upon occasion, and some times I enjoy it, some times I don’t. Walls, of the virtual brick variety, in the computing industry are unique, because they often are built upon bad ideas, bad assumptions, bad conjectures, and mortared together with bad logic. Moreover, it has been my experience, that if you pull just the right brick, just the right way, then the entire structure is exposed as flawed, and comes down like, well, a ton of bricks onto the original builders. Hyper jacking myths are such brick walls. Hyper jacking is reality? Or is it? What are we afraid of? We know some day someone or some entity will hi-jack a hypervisor? Right? Or do we? Depends on who you asked, but to some, it is all the rage in the press right now, and has been since about the same time last year. Even the motives for discussing threats to hypervisors are suspect, based on my research. Although, not an article, but a thread, that illustrates the discussion of hyper-jacking as motive driven, is http://www.wilderssecurity.com/showthread.php?t=179419. And of course, Google is just spilling over with topical discussions, about hyper-jacking, but seem to be all words and no real substance. There is so much misinformation about what can and can not be done in reference to hacking that security teams both public and private are having nervous breakdowns just trying to understand the risks and threats never mind formulating plans of action or as some like to call it, remediation of risk. One of my favorite articles that does nothing more than generate fog, or mild panic, is http://rationalsecurity.typepad.com/blog/vm_hyperjacking/index.html. Unfortunately, this article is misleading. The key virtualization platforms that dominate the industry have been certified and vetted, against known methods and techniques, something this article, among others,never explains and thus never provides a balanced view of the issue. Of course, no one is secure against new techniques and methods, but this article does not explain that point well either, it raises questions, nothing more.

From my perspective, I have never liked the term, remediation, it smacks of re-active tasking. And mediation alone is still perceptive classification as post facto resultant state. But, then again, just what is a threat? When is a concept become a threat? Or even more than theory? We have so many threats to our existence, virtual reality is no different, but fear of threats that may never materialize? I am not saying you don’t plan for threats, but what I am saying, is that threats are just that, potentials, not impacts. What was the key concept in the Matrix? Neo had to believe he was the one, the reality, in all that was, is, and had been dominated by virtual reality? Or to explain it in a historical context, what is the quote…We have nothing to fear, but fear itself . So why you ask, did I say I hit a brick wall? Fear of what could happen was the wall this time. Fear has caused may a good idea to die on paper. Security teams are exceptionally susceptible to this scenario, the fear of what could happen, no matter how remote or indiscrete. Opinion can make what is rare or even not probable; appear to be a rather solid, a wall to success use of technology, no less. The specific wall that I ran straight into was built by a group of security experts, which had the best of intentions, but had a serious lack of foundation, just fears based on potential issues, causes with no realistic materialization that could someday be effects, nothing more.

For example, just because there maybe someday, a virus that can attack NICs directly, and just because someday someone may hyper-jack a hypervisor, therefore, virtualization is not as safe as traditional hardware. To repeat, because of the potential to be hacked at the physical NIC, or the virtual NIC, or the virtual switch, and subvert the hypervisor, by definition, virtualization is not as safe as traditional hardware. To which my response was…What? Do you know what circular logic is? These are potentials not realities. So you decide what reality is, based on what casual fantasies you see as potentials? That is like saying you never will use a horse and cart to deliver carrots to market because the horse might die from pulling the cart, because the cart may break down, because the left rear wheel may fall off, because you loaded 27 carrots not 270? Therefore, horses are dangerous?

Trying to get to the bottom of this line of thinking as urban legend or not, I found a number of articles that all discuss what the new threats to corporate entities must be, yes I say must be, because the articles all promote their authoritative position, with little or not objective explanation. One that stood out as such, hyperjacking the latest threat to servers. To me this type of article is less than useful, it hints at a possibility and nothing more, talk about true hype, just to get a hit on a web page? Looking for threats is fine, but we don’t see a flood of articles discussing real results, real attacks, now do we? Hackers tend to brag about what other hackers have done, Even if some professional hacking group, from China or Russia, has done, or some defense contractor has done it in a lab, or worse in the real world, the word would get out, in short order, that is fact, the web is horrible for hiding the truth, just as it is horrible at only reporting the truth. At the risk of being connected to the X-Files franchise…The Truth Is Out There…if it exists, the internet always gives up its secrets, even if, the secrets are buried under a ton of garbage.

What is the goal of some of these articles? I am not sure, other than to generate headaches, and as I said before, generating web page hits. The results however, are real, when this type of hyped vague popinjaying is believed; inaction due to threat results, and is a classic psychological warfare technique, as well. Bully for the conspiracy theorist. A less militaristic context for the same basic situation is called analysis paralysis. The lack of action because of fear of the consequences of taking said action. This is never rational or logical? Good point, when is a potential issue deemed a true threat that needs to be acted upon? What an idea, action to offset threats, rather than inaction. This is a good thing, because when action is taken; the technology is actually used, leveraged, what have you. So how do we put this into the context of a security strategy and still use the technology? This is not trivial to be sure, but a large dose of common sense is a key to rational success.

First, threats will continue to emerge and develop, just as methods to eliminate threats will be soon to follow, if not offset by changes in theory, design, and implementation. The only constant here is that change always happens. Second, being offensive is not always possible, and being defensive is reasonable, as long as the technology is used, at some point. Early adoption of technology is a risk. However, never adapting a technology for us, is just giving into the fear of potential threats. Third, trust that ideas, solutions, methods, etc. to combat real attacks will come, or can be implemented before impact occurs. Fourth, no matter how good, how strong, how extensive the strategy implemented to protect the environment, there will be some event or situation that will compromise the environment at some time. To believe otherwise is foolish, or worse to believe that it is impossible, is irrational.

Keeping the above concepts in mind, and looking at the hypervisors of today, which are safer than others? That is a rational question, a proactive one, not a reactive one. Saying that all are unsafe is not rational. True, all have some level of risk, but so does using every operating system, and we still use operating systems in everything, from servers to cell phones. Never using an operating system, because it may someday be hacked, is defensive, and irrational. Focusing on the proactive aspect, and agreeing that hypervisors should be used, there are a few basic design features that offset risk, not quasi threats.

• An embedded solution is safer than any generic operating system based solution. This is straight-forward. Operating systems, in the traditional sense, have a large surface area of attack because they are designed to be flexible. Flexibility is difficult to manage. Embedded models are focused functional elements. Easier to manage.
• Hypervisors should be designed to never allow themselves to be executed by themselves in abstracted context. This is obvious no? It takes only a few lines of code to validate that a hypervisor is hosting a hypervisor. This is true of multiple vendor or different vendor stacking, say Hyper-V refuses to execute ESX, and ESX refuses to execute Hyper-V. No hypervisor should ever host another hypervisor, therefore, nesting is forbidden.
• Never violate the context of function versus access. What does this mean? It means that virtual instances should never have access to the hypervisor, nor know they are hosted, and the hypervisor should never inform a virtual instance that it is hosted. There should never be any inter-process communication between virtual worlds and the framework that hosts the worlds. This is a pain at times, because we sometimes want to cheap as developers, but don’t do it.
• Never ask a hypervisor to be a firewall. This is similar to the point above, but is an external design issue to the hypervisor. Never connect the hypervisor management functions to a less secure environment, than the virtual instances. This import in the case of a DMZ environment, but should be true for any environment. Is it a real risk? Today maybe not, but if someone, some day actually does figure out how to effectively hyper-jack a hypervisor? The environment design should be strong as possible and still be useful.

There is one guaranteed way to address fear, specifically the fear of hyper jacking as security teams today feel they must. However, these same security teams need to understand, they can not deny or disqualify solutions because of fear of the unknown or the future. They need to understand a concept that I coined in a meeting about 4 years ago, Engineering-By-Fact. This is based on a concept a former boss, of my boss at the time, coined, Management-By-Fact. In explanation of Management-By-Fact and Engineering-By-Fact, as well, this boss of my boss stated that he never wanted anyone in his organization say…I Think, I Believe, It Should, Most Likely, Maybe, or Most of the Time, or any variation of the same expression of opinion, in the same sentence as voicing a solution to an issue. Solutions, like problems, are black and white, if you don’t know for a fact, that you have the right, correct, and factual solution, or even worse you really do not understand the problem, don’t venture opinion over facts. Now, if we could only get the people which express opinions as facts to honor this concept, the poor security teams out there, which seem to be afraid of their own shadows, at times, could spend less time building brick-walls, and more time configuring fire-walls, right?

Entry Filed under: A Proper Virtual World