If you've been paying attention closely over the last year or so, you will have noticed louder-than-normal sucking sounds coming from the virtualization sausage machine as it grinds the various ingredients driving virtualization's re-emergence and popularity together to form the ideal tube of tasty technology bologna.
{I rather liked that double entendre, but if you find it too corrosive, feel free to substitute your own favorite banger marque in its stead. ;) }
Virtualization is a hot topic; from clients to servers applications to datastores, and networking to storage, virtualization is coming back full-circle from its MULTICS and LPAR roots and promises to change everything. Again.
Unfortunately, one of the things virtualization isn't changing quickly enough (for my liking) and in enough visible ways is the industry's approach to engineering security into the virtualization product lifecycle early enough to allow us to deploy a more secure product out of the box.
Sadly, most of the commercial virtualization offerings as well as the open source platforms have lacked much in the way of guidance as how to secure VMs beyond the common sense approach of securing non-virtualized instances, and the security industry has been slow to see any more than a few innovative solutions to the problems virtualization introduces or in some way intensifies.
You can imagine then the position that leaves customers.
I'm from the Government and I'm here to help...
However, here's where some innovation from what some might consider an unlikely source may save this go-round from another security wreck stacked in the IT boneyard: the DoD and Intelligence communities and a high-profile partnering strategy for virtualized security.
Both the DoD and Intel agencies are driven, just like the private sector, to improve efficiency, cut costs, consolidate operationally and still maintain an ever vigilant high level of security.
An example of this dictate is the Global Information Grid (GIG.) The GIG represents:
"...a net-centric system operating in a global context to provide processing, storage, management, and transport of information to support all Department of Defense (DoD), national security, and related Intelligence Community missions and functions-strategic, operational, tactical, and business-in war, in crisis, and in peace.
GIG capabilities will be available from all operating locations: bases, posts, camps, stations, facilities, mobile platforms, and deployed sites. The GIG will interface with allied, coalition, and non-GIG systems.
One of the core components of the GIG is building the capability and capacity to securely collapse and consolidate what are today physically separate computing enclaves (computers, networks and data) based upon the classification, sensitivity and clearances of information and personnel which govern the access to data by those who try to access it.
Multi-Level Security Marketing...
This represents the notion of multilevel security or MLS. I am going to borrow liberally from this site authored by Dr. Rick Smith to provide a quick overview, as the concepts and challenges of MLS are really critical to fully appreciate what I'm about to describe. Oddly enough, the concept and work is also 30+ years old and you'd recognize the constructs as being those you'll find in your CISSP test materials...You remember the Bell-LaPadula model, don't you?
The MLS Problem
We use the term multilevel because the defense community has classified both people and information into different levels of trust and sensitivity. These levels represent the well-known security classifications: Confidential, Secret, and Top Secret. Before people are allowed to look at classified information, they must be granted individual clearances that are based on individual investigations to establish their trustworthiness. People who have earned a Confidential clearance are authorized to see Confidential documents, but they are not trusted to look at Secret or Top Secret information any more than any member of the general public. These levels form the simple hierarchy shown in Figure 1. The dashed arrows in the figure illustrate the direction in which the rules allow data to flow: from "lower" levels to "higher" levels, and not vice versa.
When speaking about these levels, we use three different terms:
- Clearance level indicates the level of trust given to a person with a security clearance, or a computer that processes classified information, or an area that has been physically secured for storing classified information. The level indicates the highest level of classified information to be stored or handled by the person, device, or location.
- Classification level indicates the level of sensitivity associated with some information, like that in a document or a computer file. The level is supposed to indicate the degree of damage the country could suffer if the information is disclosed to an enemy.
- Security level is a generic term for either a clearance level or a classification level.
The defense community was the first and biggest customer for computing technology, and computers were still very expensive when they became routine fixtures in defense organizations. However, few organizations could afford separate computers to handle information at every different level: they had to develop procedures to share the computer without leaking classified information to uncleared (or insufficiently cleared) users. This was not as easy as it might sound. Even when people "took turns" running the computer at different security levels (a technique called periods processing), security officers had to worry about whether Top Secret information may have been left behind in memory or on the operating system's hard drive. Some sites purchased computers to dedicate exclusively to highly classified work, despite the cost, simply because they did not want to take the risk of leaking information.
Multiuser systems, like the early timesharing systems, made such sharing particularly challenging. Ideally, people with Secret clearances should be able to work at the same time others were working on Top Secret data, and everyone should be able to share common programs and unclassified files. While typical operating system mechanisms could usually protect different user programs from one another, they could not prevent a Confidential or Secret user from tricking a Top Secret user into releasing Top Secret information via a Trojan horse.
When a user runs the word processing program, the program inherits that user's access permissions to the user's own files. Thus the Trojan horse circumvents the access permissions by performing its hidden function when the unsuspecting user runs it. This is true whether the function is implemented in a macro or embedded in the word processor itself. Viruses and network worms are Trojan horses in the sense that their replication logic is run under the context of the infected user. Occasionally, worms and viruses may include an additional Trojan horse mechanism that collects secret files from their victims. If the victim of a Trojan horse is someone with access to Top Secret information on a system with lesser-cleared users, then there's nothing on a conventional system to prevent leakage of the Top Secret information. Multiuser systems clearly need a special mechanism to protect multilevel data from leakage.
Think about the challenges of supporting modern-day multiuser Windows Operating Systems (virtualized or not,) together onto a single compute platform while also consolidating multiple networks of various classifications (including the Internet) into a single network transport while providing ZERO tolerance for breach.
What's also different here from the compartmentalization requirements of "basic" virtualization is that the segmentation and isolation is critically driven by the classification and sensitivity of the data itself and the clearance of those trying to access it.
To wit:
VMware and General Dynamics are partnering to provide the NSA with the next evolution of their High Assurance Platform (HAP) to solve the following problem:
... users with multiple security clearances, such as members of the U.S. Armed Forces and Homeland Security personnel, must use separate physical workstations. The result is a so-called "air gap" between systems to access information in each security clearance level in order to uphold the government's security standards.
VMware said it will provide an extra layer of security in its virtualization software, which lets these users run the equivalent of physically isolated machines with separate levels of security clearance on the same workstation.
HAP builds on the current solution based on VMware, called NetTop, which allows simultaneous access to classified information on the same platform in what the agency refers to as low-risk environments.
For HAP, VMware has added a thin API of fewer than 5,000 lines of code to its virtualization software that can evolve over time. NetTop is more static and has to go through a lengthy re-approval process as changes are made. "This code can evolve over time as needs change and the accreditation process is much quicker than just addressing what's new."
HAP encompasses standard Intel-based commercial hardware that could range from notebooks and desktops to traditional workstations. Government agencies will see a minimum 60 percent reduction in their hardware footprints and greatly reduced energy requirements.
HAP will allow for one system to maintain up to six simultaneous virtual machines. In addition to Windows and Linux, support for Sun's Solaris operating system is planned."
This could yield some readily apparent opportunities for improving the security of virtualized environments in many sensitive applications. There are also other products on the market that offer this sort of functionality such as Googun's Coccoon and Raytheon's Guard offerings, but they are complex and costly and geared for non-commercial spaces. Also, with VMware's market-force dominance and near ubiquity, this capability has the real potential of bleeding over into the commerical space.
Today we see MLS systems featured in low risk environments, but it's still not uncommon to see an operator tasked with using 3-4 different computers which are sometimes located in physically isolated facilities.
While this offers a level of security that has physical air gaps to help protect against unauthorized access, it is costly, complex, inefficient and does not provide for the real-time access needed to support the complex mission of today's intelligence operatives, coalition forces or battlefield warfighters.
It may sound like a simple and mundane problem to solve, but in today's distributed and collaborative Web2.0 world (which is one the DoD/Intel crowd are beginning to utilize) we find it more and more difficult to achieve. Couple the information compartmentalization issue with the recent virtualization security grumblings: breaking out of VM Jails, Hypervisor
Rootkits and exploiting VM API's for fun and profit...
This functionality has many opportunities to provide for more secure virtualization deployments that will utilize MLS-capable OS's in conjunction with strong authentication, encryption, memory firewalling and process isolation. We've seen the first steps toward that already.
I look forward to what this may bring to the commercial space and the development of more secure virtualization platforms in general. It's building on decades of work in the information assurance space, but it's getting closer to being cost-effective and reasonable enough for deployment.
/Hoff