We are looking into using VMware but are concerned with unintentional contamination of unclassified hard drives with classified data. As a US Government R&D facility, we work with all levels of information classifications and occasionally someone forgets to sanitize their data before they e-mail it or store it on unclassified media.
Let us say there are 4 vm's running on a single box, e-mail server, file server, DB server and domain controller. A user sends an e-mail that contains classified data. How do we "Clean" the classified data off the system? Is just the e-mail server contaminated or are all 4 servers contaminated?
Current policy dictates, any classified data on a hard drive, or RAID array, makes that whole medium classified.
What are the consequences in a VM environment?
I think it all depends on how secure your architecture is. In this case, I assume that e-mail server is contaminated unless the e-mail server depends on a file server that handles the repository. In any case, you should secure the message process by some means such as partitioning the data using dedicated storage with proper access controls etc. You can have two instances of e-mail server where one handles only the confidential information. Bottom line is that the underlying operating systems can not perform what we have in mind.
May have been overkill.
I have a customer who also had this situation.
Their answer was to use RDMs to RAW LUNs that included the entire RAID Group for these types of servers.
Their policy was the need to physically destroy contaminated disks, so they did this to facilitate the ability to do this.
In all actuality, if a vmdk file gets contaminated with classified information only that vmdk needs to be destroyed.
But then of course, there will always still be a footprint of that file.
So it depends on your needs.
Although current policy says if the physical medium gets contaminated the physical medium must be sanitized, that doesn't mean the policy can't change.
So what I read is the e-mail VM creates a vmdk. If the vmdk gets contaminated I would have to delete the vmdk, wipe the disk space occupied by the vmdk, then recreate the vmdk. That is over simplified but I think that is what would have to happen. What about page files? Are they stored within the vmdk?
You can't really wipe the disk space in ESX.
Instead ESX wipes the space when creating a new VMDK (default if not explicitly changed).
Therefore I'd create a LUN which fits the desired VMDK size and recreate the VMDK always on this LUN.
Yes guest page files are located within the vmdk(s) or sometimes (rare) on a seperate vmdk.
What about this. VM gets contaminated. I would wipe the VM disk (vmdk)no differnt then any other physical media. Boot the VM with a disk wipe application and scrub the disk to Dod or RCMP spec. Then delete the VM and recreate. I think this might be overkill but would satisfy any auditor.
Oh here is a great free disk wipe applicaiton!!
All good input. Thanks folks. This is an issue we have to resolve before we march down the VM path. The DoD is very sensitive about the release of classified data and we have to assure them with 99.99% certanty that if a spillage were to occure, it could be contained and mitigated.
I have to write up a white paper on this subject so any additional input would be greatly appreciated.
My 2 cents thoughts..
Coming to security, it is the architecture design that determines the depth of implementation. However, underlying operating systems and platform services should enable the platform resources. For example, when it is required to create a new VMDK, ESX should initialize the disk with NULL content. Similarly, when allocating RAM space, ESX should purge the memory content before releasing to any VM. Such measures are to be taken even in guest os space. As far as secured media is concerned, the architect should make sure that the classified VMDK should be isolated physically from other shared resources. This may have some impact on performance and costs. But, security always supersedes.
Good luck on your paper. Hope you can share your paper with us.
There are lots of agencies in the DoD who are already using ESX...maybe you should do some research to find out how THEY are dealing with this problem, rather than reinventing the wheel. I would imagine that being able to say "Agency abc has mitigated this risk by doing xyz" would have a lot more influence than saying "I've researched and the guys on the VMware forums say mno".
Without having access to the source code - and some folks who can understand the security implications of its implementation - I fear you won't be able to come up with a very compelling argument...
As the IAM for the missile subs in the pacific this is something I have to deal with on a monthy basis it seems. What we use is the standard 'Buster' package availible from https://infosec.navy.mil (only from .mil or .gov domain computers or those with CAC PKI installed at home) We're required to wipe the contaminating file and then do a freespace wipe with buster before we do a full buster scan to see if anything remains in the same way we declassify floppy disks. I've found that reverting to a snapshot and then doing a freespace wipe on the virtual drive (static size as variable would require a freespace wipe of the host drives) I still do freespace wipes of the host during nighttime hours. In any case as a Government R&D you should have access to the NSA IA department so call them and they'll point you to the people who write the policy.
A good thought but as a US Government facility handling classified data they're required to use an NSA or DISA approved program.
I do security audits on a regular basis and if I catch a program being used on a cassified system that isn't on the approved list I'll decertify them in a heartbeat.
I look at discussions such as these from the point of view of forensics. Regardless of using ESX or anything else unless the disk is heated and destroyed in some way, the data is STILL available however hard and expensive it is to access. Therefore a VMDK is still available even when overwritten. Therefore, I would have the classified VM use an RDM only with a direct set of disks either in the local host, iSCSI Server, or SAN. This way if there is spillage and you do have to pull the drives and dispose of them then you can otherwise you would have to pull drives from other VMs and it would be a huge mess.
Which tools are available for everything should not really be discussed in the forum. I would contact your Security Administrator to get the list of approved tools for your site.
Edward L. Haletky
VMware Communities User Moderator
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
Good deal. So maybe just dedicating a LUN to each VM, and this ever happened, just wipe out the LUN and clean the free space with a 3rd party utility. I'll let you know if this satisfies the question at hand. thanks
I'm in the same exact boat you are/were. I have to write a proof of concept and white papers to go along with this as well. After that writing an sop on how everything works, eventhough I don't even have the necessary equipment to bring it all together! Budgets! Sorry, had to vent. Did you ever finish your white paper? Sounds like we work for the same folks, and I too would hate to keep re-inventing the wheel. thanks a bunch