Data Spillage and remediation and Virtual Machines

Good Afternoon friends,

This question goes out to mainly those working in government areas that have to deal with classified networks and unclassified networks.  I want to find out if there is any information out there on data spillage remediation on virtual machines.  For example, if a data spillage occurs on a virtual PC, what if anyhting has to be done on the server that is hosting the virtual pc.  I know the standard procedure for a physical desktop, but not sure what evxtra steps may have to be taken in the case of a virtual pc.  I'm trying to write a report about this but I am unable to find any documentation about it.

If you have any questions, please ask if  you need any more information.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I have yet to see policy on that in relation to government systems.  I think it depends on how isolated the spillage incident is in relation to the host and the virtual instance.  For example, how did the spillage occur?  Is there a shared mapping between the host and virtual machine?  Network bridging?  Guest OS tools enabled, this allows access to Host files.  The convenience of a VM is you can take a snapshot in time, or even have snapshot taken every X days, so you could have a record of spillage before and after in that case.  It also gives you the option of just wiping away that entire VM in one keystoke.  However, if the data is classified, that VM is also part of the disk that is shared by the Host OS.  So, if the host OS is unclassified and the VM has classified data, in reality, the whole PC would need to be re-imaged because that disk is now hosting classified data and you can't just easily look at the disk and say there is no slack space in which classified data didn't get written to from a forensic standpoint.  Once again, I think this would depend on how "isolated" one would determined the VM to be.......NIST has a publication that recommends practices to take in relation to virtualization.  Check out 800-125 and see if that helps any.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
btanExec ConsultantCommented:
Actually for VM leakage, I see the exit points (or path) are interfaces between the key VM components eg.
a) VM <-> VM (include VM guest, an agent of the mgmt appliance installed)
b) VM <-> Hypervisor (or sometime called Virtual Machine Monitor, that also embed control of virtual switch)
c) VM <-> VM Mgmt appliance (typically there is only one such Dom0 etc with single hypervisor)
d) VM Mgmt appliance <-> Hypervisor
e) VM Mgmt centre <-> Hypervisor
f) VM Mgmt centre <-> VM Mgmt appliance

The most commonly interface to user will be the weakest link or the possible exit point. Imagine the case of USB drive used in VM and VM mgmt centre. Normally user to not directly access to hypervisor or the VM Mgmt appliance, they are transparently managed. Therefore the attention to secure those critical points in data loss prevention solution. I am not aware of any mandate in term of using such virtualisation but there are wide implementation and security technology that you can consider as input reference to your paper. For example,

i) [Govt program] High Assurance Platform® (HAP) Program - take a look at the video. I see it as a singe terminal but with application virtualised and attested in running in a trusted machine. It detect for any intrusion and tampering to ascertain assurance in highly secure user environment. They need not be physically segregated

ii) [Open effort] Qubes - the architecture proposes isolation on usage to prevent contamination. The PDF can be good design consideration. Note the segregation efforts and the self-containment in each VM images generated on demand. There are some VM that is of mgmt appliance based that have more security check like authentication with non-repudiation where possible.

iii) [Commercial] VM Security appliance - Check out VMWare partners such as Trend Micro Deep Security (there is an unified layer checks using AV for malware, firewall for deep packet inspection and etc), this pose a greater chance in detecting malware or attempt to intrude or extrude from the VMs. But this will depends on VMware exposed API (in Hypervisor) for security vendor to build their VM mgmt appliance. There may not be APIs for all VM product (e.g. Hyper-V, etc) though. Check out

iv) [Commercial] Hardening guide - Check out section under Virtual host and Mgmt Configuration, it suggest isolation and labelling in many of its practices to harden the key components such as the VM (VMware host), VM hypervisor (VMware ESX/ESXi), VM mgmt centre (Virtual Centre)

v) [Research] Attacks and defense - Rootkit in the key component pose the main culprit to extend the espionage into exfiltration attempt (in stealth mode) and some great example include SubVirt and BluePill. Yu may be interested in this project HookSafe that protect the VM guest

Quite a fair amount of material as well if you will to extent it into Cloud scenario but it can be more vulnerable (IMO) as all are residing in one "big hosted family", one "wrong" may impact all ....
btanExec ConsultantCommented:
More info on segregation which is a key aspect to minimise spillage

If you share your management network with your guest VMs, the attack vector allows a VM to access the Hyper-V management operating system and, with the right credentials, access the Hyper-V host and settings or other virtual machines. This option is turned off by default, but too many admins switch it on because of the ease of administration from many machines or limited availability of network interface cards (NICs). Enabling this setting is a security threat because you can attack the management OS from every virtual machine it hosts. Therefore, always devote a physical network adapter to a dedicated management network and never share those NICs with normal VM traffic.

You can also configure Hyper-V to recognize VLANs in order to logically separate the traffic coming from the various machines. While this is a wonderful method to mix and match various subnets onto a single machine and support clustered hosts without concern for the physical layer, you’re not really increasing security. It may appear that way on the surface since virtual machines on separate VLANs cannot see each other’s traffic without access and proper routing at the network layer. In reality, however, those bits are all on the same virtual and physical wire making VLAN hacking possible. As such, the rules one would take in the physical world also apply to the virtual world.
jpramikAuthor Commented:
Thanks for all of the wonderful comments, I was out for Friday and away this weekend, just now getting in to see these responses.  I will read them all and comment later this afternoon once I get home.  I really look forward to it!
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Project Management

From novice to tech pro — start learning today.