During the last Virtualization Security Podcast, our guest had to postpone so we discussed to several interesting topics all related to Digital Forensics and how encryption would best work within the virtual environment. Our very own Michael Berman, in a previous life, was a forensic investigator and had some great insights into the problem of digital forensic within the virtual environment.
We discussed forensic from the perspective of evidence necessary for the court of law. In other words, forensically sound data acquisition prepared for forensic analysis. This is the an interesting aspect of virtualization. Some of which I have discussed before.
Out of this discussion came some fairly straight forward advice that many may find difficult to perform due entirely to the additional cost and requirements:
- Have a Written Incident Response Policy and Procedure
- Have a Written Data Retention Policy
- Have a Separate ESX Cluster for purely Forensics
The costs associated with theses are very important to understand, but that should NEVER stop you from implementing at least the first two options. It is extremely important to have a written Incident Response Policy, even is this policy states to call a third party. If this policy states that you use your own forensics lab, be sure to contact local and federal law enforcement for guides and proven procedures, that can be used within your lab. Forensic analysis its self is often costly but necessary component of any incident response policy.
In many cases, your forensics investigator may need to review older bits of data stored within backups therefore you need a written Data Retention Policy. When it comes to backing up the virtual environment, the need is for block by block duplicates of virtual disks and nearly every backup tool will do just this. For some organizations, data may need to keep for extended periods of time in a protected location, which increases costs.
The last item is current guidance for data acquisition, that is having an hypervisor host that you can move the VM under investigation so that there can be a clean acquisition of data without movement of the data from host to host or from storage device to storage device. A capture environment that is only used for acquisition. There is the expense for licensing, management of said host following proven and written procedures, as well as the cost of keeping such a host running and devoid of other VMs until it is needed.
However, that led to the question about whether or not data is needed from each location the VM has lived in the past? Why is this important?
- Provides an External time source for performing forensic analysis
- Provides a historical record of the VMs data content.
These both can also be achieved by having available, to the forensic scientist, full block by block backups of any virtual disk under investigation. These backups can also provide an external time source necessary for forensic investigation. Most of a forensics scientists time is spent correlating the times they find within a virtual disk with some external source. In many cases, the times within a system are corrupted to protect the suspect. External time correlation becomes necessary to understanding the time-line of events.
The conversation continued with what other data would be useful to the forensic scientist:
- Fault Tolerance/CPU Data
- VMotion or Memory Data
- Virtual Disk Data (already required)
With CPU and Memory data it is now possible to decrypt any encryption that originates or terminates within the VM. This is very important to the forensic scientist and points out a major failing with current encryption mechanisms within the virtual environment and cloud. Until hardware keys can be used to perform encryption within the VM this weakness will continue to exist and thereby make life much easier for forensic scientists. At the same time, and because of this fact, virtualization specific networks (Management, FT, vMotion, and LiveMigration) will continue to require isolation and superior protections.
Share this Article:
Latest posts by Edward Haletky (see all)
- Common Product Security Questions - November 23, 2016
- Sorry Support: Not Getting My Data - November 18, 2016
- Moving to the Future: Strategies for Handling Data Scale - November 14, 2016