If you're using a virtual machine
you need to make sure that it is secure,
or in other words, it needs to be hardened.
We've already discussed physical isolation,
so let's just revisit that quickly.
You can have physical isolation
in order to give you physical hardening.
You could use a dedicated secure device
as the host for the guest VM,
giving you physical isolation.
Both the host and the guest will be hardened
and a separate device used for day to day use.
The day to day use device is more likely
to be attacked and get compromised.
The secure device, used less often and for more trusted tasks,
meaning the host operating system
and the guest operating system on the secure device,
are more likely to remain safe.
Other physical measures that you can use.
Using a USB network dongle instead of the host network adapter,
as discussed already in the area on physical isolation.
You can place the VM on a separate network to the host
or for virtual isolation via a VLAN.
This is to help mitigate attacks that come from the network,
from the virtual machines.
Virtual machine leaks.
As we've discussed, virtual machines can create
on the host operating system unwanted log files,
discaching and other evidence of the activity
of your virtual machine guest,
even if it's a live operating system like Tails or there is no virtual disk.
Like in this example where you see that there is no virtual disk,
it's difficult to know all of what is created
by your hypervisor on your host operating system.
So one approach to deal with this problem,
of all the unwanted host data, would be to use
whole disk encryption on the host machine
as the mitigation against these leaks.
If you have significant adversaries and high consequences,
this would always be recommended anyway,
and we discuss more on disk encryption
and file encryption in its own section and we go into quite a lot of detail.
So defense against leaks or one of the defenses against leaks,
whole disk encryption.
Not only can we do whole disk encryption to prevent the leaking,
we could even create a whole hidden operating system
from which we have the hypervisor installed
and the guest VM running.
This makes even finding or knowing that leaks exist difficult
and it also provides plausible deniability.
But of course this only protects you when the machine is switched off,
as the encryption keys are stored in memory when the machine is on.
Another possible mitigation against unwanted storage on the host
leaks from discaching is to disable or delete the caching.
Host operating systems usually use virtual memory called swapping
or paging which copies part of the RAM to the hard disk.
There are also modes like sleeping and hibernating.
It's possible to disable this functionality
to prevent it from being stored to disk,
but you should do this at your own risk
as it’s possible that it can cause problems with your host operating system.
And we do cover more on clearing the page
and swap in the section on evidence elimination.
So if that's something that interests you, check out that section.
Moving away from leaks now
and on to protecting the data within the virtual machine.
You can enable encryption
using the hypervisor for each of the individual virtual machines,
but obviously again this only protects them
when they are switched off.
Using the hypervisor’s encryption is probably
a less tried and tested solution
than encrypting the operating system itself
using more well-known encryption technology such as LUKS,
FileVault 2, Bitlocker, and VeraCrypt
which have been subject to more public and community scrutiny
than perhaps the hyperdriver encryption has.
Enabling both encryption in the hyperdriver
and within the operating system
will slow down your virtual machine,
but does give you defense in depth.
You want to reduce the attack surface of your hypervisor
and here are some of the features that you might consider removing.
You might want to disable the audio and the microphone,
and not specific to virtual machines,
you might want to cover your webcam with tape,
disable shared folders,
disable drag and drop and clipboard,
don't enable video acceleration, 3D acceleration,
and do not enable serial ports.
If you can, do not install VirtualBox Guest Addition
or VMWare Tools or equivalent.
That gives the operating system
more access to the hypervisor
and it gives a guest access to more of the host like the microphone
and increases the attack vector.
You want to remove the floppy drive and remove any CD or DVD drives.
If it's a Live operating system,
you want to remove any virtual disks.
Do not attach USB devices if you can help it,
perhaps the network dongle,
but nothing else if you can avoid it.
Disable the USB controller which is enabled by default.
When you disable the USB controller,
this requires you setting the pointing device to be a PS/2 mouse
so that your mouse will work.
Do not enable remote display server,
do not enable I/O APIC or EFI.
Enable PAE/NX, NX is in fact a security feature.
NX helps your processor guard the PC from attacks from malware.
And remove anything that's not used.
If you are concerned about someone getting a hold of your device
and local forensics,
then use non-persistent operating systems like live CDs, live USBs
and don't add virtual storage
when setting up the virtual machine.
You can create your own custom live operating system,
so you go about installing
whatever operating system it is that you want,
configuring it in the way that you want,
and then you can convert the virtual disk to an ISO
and then boot from the ISO as a live CD.
If you look at this thing here,
this talks through converting a virtual disk image to an ISO.
You can use VMware snapshots to create non-persistence.
You can use these snapshots for security
for evidence elimination by establishing a securely
updated virtual machine that has never performed
any other activity than what you want it to have performed
and then snapshot that VM.
So for example, here would be the clean
VM with no evidence and no history.
This is your current state where you perform your activities,
then after you’ve performed your activities
you restore
back to the original clean VM.
This'll remove any malicious malware,
it'll remove history, tracking, or any evidence of activity.
This is not a perfect solution to remove evidence
due to the previously discussed possibilities
of data leakage remaining on the host,
but it is a reasonably good solution for basic non-persistence.
There's some security issues
around the power saving features of your devices.
If you pause or suspend your device
when you have an encrypted virtual machine,
the encryption keys are stored on the hard disk.
This isn't safe unless you retain
full physical control over the device.
Again, in the same light, if you hibernate your laptop
with whole disk encryption,
the encryption keys are stored on the hard disk.
This isn't a virtual machine issue,
but this isn't safe either
unless you maintain control over the device.
If you put your laptop into sleep or standby,
any whole disk encryption keys will be stored in memory.
Again, this isn't safe unless you retain
physical control over the device.
If you're using encryption, either with a hypervisor
or with a guest operating system,
or with a host operating system,
it is best for all of the operating systems,
the guest and the host,
to be logged out and shut down and switched off,
fully switched off, not paused, not suspended, not hibernated.
This way, the decryption keys are not stored on disk anywhere.