Most small businesses that still run servers do not run many. They run one or two physical hosts with eight or ten virtual machines on top, which is a sensible way to build. It is cheaper, it is easier to move, and restoring a whole server has gone from a weekend to an afternoon.
It also concentrates the risk. Before virtualisation, compromising a file server got you a file server. Now there is a single machine, and a single console, that can copy, pause, export or delete every server you own. Physical security habits do not cover that, because the thing worth protecting is no longer in the rack, it is in the management interface.
Here is what actually changes, and the four fixes worth doing before anything else.
The management console is the whole estate
If someone reaches your hypervisor management interface with administrative rights, they do not need to attack your servers individually. They can create an account, grant it rights, and take copies of the virtual disks holding your accounting system, your email archive and your client files, without ever logging into those servers.
The Australian Signals Directorate describes privileged credentials as the “keys to the kingdom”, because they allow the bearers to have access and control over many different assets within a network, and notes that privileged access is often the attacker’s goal precisely because it allows malware to be spread widely, new privileged accounts to be created, and controls for applications, databases and file servers to be bypassed.
On a virtual estate the hypervisor console is the highest-value version of that. It deserves to be treated as a separate class of system, not as another web page an administrator can reach from their normal laptop.
The convenience features between host and guest
Virtualisation platforms include a set of features that exist to make administrators’ lives easier: shared folders between host and guest, copy and paste from the management console into a running machine, mounting a disk image to grab a file, running a hypervisor inside a virtual machine for testing.
Every one of those is also a path across a boundary that is supposed to hold. Microsoft’s Hyper-V security guidance puts two of these in plain terms: “Don’t mount unknown VHDs. This can expose the host to file system level attacks”, and “Don’t enable nesting in your production environment unless it’s required.”
The pattern is the same on any platform. If a convenience feature lets data or code move between the host and a guest, leave it off in production and turn it on deliberately when you need it.
Ransomware goes for the host, and often the backups
Attackers worked out some time ago that encrypting ten virtual machines one at a time is slow, and encrypting the files those machines live in is fast. The host is now a target in its own right.
That matters most for backups. If your backup system runs as another virtual machine on the same host, writes to storage the host can see, and authenticates with an account that has rights on the host, then everything you would use to recover is inside the thing you are recovering from.
ASD’s Maturity Level One backup requirements in the Essential Eight maturity model address exactly this. Backups must be “retained in a secure and resilient manner”, restoration to a common point in time must be “tested as part of disaster recovery exercises”, unprivileged accounts must not be able to access backups belonging to other accounts, and unprivileged accounts must be “prevented from modifying and deleting backups”.
Read those as questions about your own setup and the gaps usually appear within a minute.
Fix one: separate the management plane
Microsoft’s guidance for a Hyper-V host is a good template whatever you run. Use the minimum installation option. Don’t use the host as a workstation or install unnecessary software on it. Manage the host remotely, and if you must manage it locally, use Credential Guard. Use a separate network with a dedicated network adapter for the host, and a private or secure network to reach virtual machine configurations and virtual hard disk files.
On permissions, the same page is specific: add the people who need to manage the host to the Hyper-V administrators group, and “don’t grant virtual machine administrators permissions on the Hyper-V host operating system”. Someone who looks after an application server has no business holding rights over the machine that server lives on.
There is a related requirement in the Essential Eight worth knowing. At Maturity Level Two, ASD requires that “privileged operating environments are not virtualised within unprivileged operating environments”. In other words, the admin environment must not be a virtual machine running on a day-to-day desktop.
Fix two: patch the host on the same clock as everything else
Hypervisors get forgotten because nobody logs into them and nothing visibly breaks. That is also why they run versions nobody has updated in two years.
The Essential Eight sets the timeframes at Maturity Level One. Patches for operating systems on internet-facing servers and network devices go on within 48 hours when a vendor rates the flaw critical or a working exploit exists, and within two weeks otherwise. Operating systems on workstations and non-internet-facing servers get one month. Operating systems no longer supported by vendors are replaced, not tolerated.
Microsoft’s host guidance adds the part people skip: keep “the Hyper-V host operating system, firmware, and device drivers up to date with the latest security updates”, and check the hardware vendor’s recommendations for firmware and drivers. Server firmware is the single most commonly neglected item we find during onboarding.
Fix three: harden the guests, not only the host
A locked-down host full of unpatched virtual machines is not a secure environment.
Microsoft recommends creating generation 2 virtual machines for supported guest operating systems and enabling Secure Boot, installing the latest security updates before a machine is switched on in production, keeping integration services current, and hardening each guest according to the role it performs using published security baselines. For higher-security environments it points at shielded virtual machines on a guarded fabric, which needs hardware with a TPM 2.0 chip.
Also worth doing: confirm each virtual network adapter is attached to the switch you think it is. Segmentation on paper that does not match the configuration is the most common finding in a virtual network review.
Fix four: know what you have
Virtual machines are easy to create and nobody ever deletes anything. Two years later there are machines running that no one can account for, still patched or, more often, not.
Keep an inventory of every virtual machine with what it does, who owns it, and whether it is still needed. Review it quarterly and shut down what nobody claims, after a snapshot. Log the administrative actions taken on the host so that account creation and configuration changes leave a trail. Keep virtual hard disks and snapshot files somewhere restricted, and encrypt the underlying drives.
None of this is exotic. It is the same discipline you would apply to a physical server room, applied to a console instead of a door.
One thing to do this week
Log into your hypervisor’s management interface and look at the account list. Work out who can reach it, from which machines, and whether any of those accounts is also somebody’s everyday login. That one answer usually reorders the rest of the list.
If you would like someone to go through your virtual environment and tell you where it actually stands, get in touch.