I'd like to frame this little ditty with a quote that Marcus Ranum gave in a face-off between he and Bruce Schneier in this month's Information Security Magazine wherein he states:
"Will the future be more secure? It'll be just as insecure as it possibly can, while still continuing to function. Just like it is today."
Keep that in mind as you read this post on virtualization security, won't you?
Over the last few months we've had a serious malfunction in the supply chain management of Common Sense. It's simply missing from the manifest in many cases.
Such is the case wherein numerous claims of undelivered security common sense are being filed as instead of shipping clue in boxes filled with virtualization goodness, all we get are those styrofoam marketing peanuts suggesting that we're either "more" or "less" secure instead. More or less compared to what, exactly?
It's unfortunate that it's still not clear enough at this point that we're at a crossroads with virtualization.
I believe it's fair to suggest that the majority of us know that the technology represents fantastic opportunities, but vendors and customers alike continue to cover their ears, eyes and mouths and ignore certain realities inherent in the adoption of any new application or technology when it comes to assessing the risk associated with deploying this technology.
Further, generalizations regarding virtualization as being "more" or "less" secure than non-virtualized platforms represents an exercise in tail-chasing that seems more and more to be specious claims delivered in many cases without substantiated backing...
Here's a perfect example of this sort of thing from a CMP ChannelWeb story titled "Plotting Security Strategy in a Virtual World":
"In many ways, securing virtual servers is little different from securing physical servers, said Patrick Lin, senior director of product management at VMware."
We've talked about this before. This is true, except (unfortunately) for the fact that we've lost a tremendous amount of visibility from the network security practitioner's perspective as now the "computer is the network" and many of the toolsets and technologies are not adapted to a accomodate a virtualized instantiation of controls and detection mechanisms such as Firewalls, IDS/IPS and other typical gateway security functions.
"At the end of the day, they are just Windows machines," Lin said. "When you turn a physical server into a virtual server, it's no more vulnerable that it was before. There are not new avenues of attack all of a sudden."
That statement is false, misleading and ironic given the four vulnerabilities we just saw reported over the last 3 days that are introduced onto a virtual host thanks to the VMware software which enables the virtualization capabilities.
If you aren't running VMWare's software, then you're not vulnerable to exploit from these vulnerabilities. This is an avenue of attack. This represents a serious vulnerability. This is a new threat/attack surface "all of a sudden."
[Ed: I simply had to add this excerpt from Kris Lamb's fantastic blog post (IBM/ISS X-Force) that summarized empirically the distribution of VMware-specific vulnerabilities from 1999-2007.]
We pulled all known vulnerabilities across all of VMware’s products since 1999. I then focused on categorizing by year, by severity, by impact, by vector and by whether the vulnerability was in VMware's proprietary first-party components or in third-party components that they use in their products.
Once I pulled all the data, sorted and structured it in various ways, it summarized like this:
VMware Vulns by Year Total Vulns High Risk Vulns Remote Vulns Vulns in First Party Code Vulns in 3rd Party Code Vulns in 1999 1 1 0 1 0 Vulns in 2000 1 1 0 1 0 Vulns in 2001 2 0 0 2 0 Vulns in 2002 1 1 1 1 0 Vulns in 2003 9 5 5 5 4 Vulns in 2004 4 2 0 2 2 Vulns in 2005 10 5 5 4 6 Vulns in 2006 38 13 27 10 28 Vulns in 2007 34 18 19 22 12 TOTALS 100 46 57 48 52
So what are some of the interesting trends?
- There have been 100 vulnerabilities disclosed across all of VMware’s virtualization products since 1999.
- 57% of the vulnerabilities discovered in VMware products are remotely accessible, while 46% are high risk vulnerabilities.
- 72% of all the vulnerabilities in VMware virtualization products have been discovered since 2006.
- 48% of the vulnerabilities in VMware virtualization products are in first-party code and 62% are in third-party code that their non-hosted Linux-based products use.
- Starting in 2007, the number of vulnerabilities discovered in first-party VMware components almost doubled that of vulnerabilities discovered in third-party VMware components. 2007 is the first time where first-party VMware vulnerabilities were greater than third-party VMware vulnerabilities.
How do I interpret these trends?
- It is clear that with the increase in popularity, relevance and deployment of virtualization starting in 2006, vulnerability discovery energies have increasingly focused on finding ways to exploit virtualization technologies.
- Combine the vulnerabilities in virtualization software, vulnerabilities in operating systems and applications that still exist independent of the virtualization software, the new impact of virtual rootkits and break-out attacks with the fact that in a virtual environment all your exploitation risks are now consolidated into one physical target where exploiting one system could potentially allow access and control of multiple systems on that server (or the server itself). In total, this adds up to a more complex and risky security environment.
- Virtualization does not equal security!
I've already blog-leeched enough of Kris' post, so please read his blog entry to see the remainder of his findings, but I think this does a really good job of putting to rest some of the FUD associated with this point.
Let's continue to deconstruct at Mr. Lin's commentary:
Even so, server virtualization vendors are taking steps to ensure that their technology is itself up-to-date in terms of security.
OK, I'll buy that based upon my first hand experience thus far. However, here's where the example takes a bit of a turn as it seeks to prove that a certification somehow suggests that a virtualization platform is more secure:
Lin said VMware Server ESX is currently certified at Common Criteria Level 2 (CCL2), a security standard, and is in the process of applying for CCL4 for its Virtual Infrastructure 3 (VI3) product suite.
Just to be clear, Common Criteria Evaluation Assurance Levels don't guarantee the security of a product; they demonstrate that under controlled evaluation, a product configured in a specific way meets certain assurance requirements that relay a higher level of confidence that a product's security functions will be performed correctly and effectively.
CC certification does not mean that a system is not vulnerable to or resilient against many prevalent classes of attack. Also, in many ways, CC provides the opposite of being "up-to-date" from a security perspective because once a system has been certified, modifying it substantially with security code additions or even patches, renders the certification invalid and requires re-test.
If you're interested, here's a story describing some interesting aspects of CC certification and what it may mean for a product's security and resilience titled "Common Criteria is Bad for You."
I'm working very hard to pull together a document which outlines exposure and risk associated with deploying virtualization with as much contextual and temporal relevance as I can muster. Numerous other people are, also. This way we can quantify the issues at hand rather than listening to marketing squawk boxes yelp from their VoxHoles about how secure/insecure virtualization platforms are without examples or solutions...
In the meantime, as a friendly piece of advice, might I suggest that the virtualization vendors such as VMWare kindly limit the outflow of how security information regarding virtualization is communicated?
Statements like those above made by product managers who are not security domain experts only seeks to erode the trust and momentum you're trying to gain.
There are certainly areas in which virtualization provides interesting, useful, unique and (in some cases) enhanced security over those in non-virtualized environments. The converse can also be held as true.
Let's work on communicating these differences in specifics instead of generalities.
/Hoff
