The Essential Eight is the Australian Signals Directorate’s short list of mitigation strategies that do the most to stop common attacks. It has become a common benchmark well beyond government. It is also, by ASD’s own description, designed primarily for Microsoft Windows-based, internet-connected networks. That leaves an obvious question for any organisation that owns its infrastructure: what about the hypervisors, storage, switches and management plane that everything else runs on?
A quick refresher
The eight strategies are application control, patching applications, restricting Microsoft Office macros, user application hardening, restricting administrative privileges, patching operating systems, multi-factor authentication and regular backups.
The strategies are assessed against a maturity model, with each step up designed to resist a more capable adversary. The model is revised from time to time, so this article deals in principles rather than level-by-level requirements. For those, work from ASD’s current published version, not a checklist downloaded years ago.
Where the model stops and your infrastructure starts
A hypervisor host, a storage node and a switch do not run Office macros, and a baseboard management controller does not browse the web. It would be easy to conclude that the Essential Eight does not reach them. That would be a mistake, because the infrastructure layer sits underneath every control applied to the guests.
Anyone who controls the virtualisation management plane can power off servers, copy their disks, open their consoles and delete them, without touching any of the protections inside the guest operating systems. Several ransomware families have versions built specifically to encrypt virtual machine files directly on the hypervisor, bypassing the guests entirely. The principles behind the Essential Eight apply to this layer with more force, not less, even where the letter of the model does not.
Restrict administrative privileges, starting with the management plane
On owned infrastructure this is the strategy that matters most, and the one most often done by halves.
- Use separate accounts for administration and for everyday work. The model expects privileged accounts to be prevented from using email and browsing the web, and that expectation is even more sensible for accounts that can delete a storage pool.
- Think carefully before tying the hypervisor management plane to the same directory as everything else. If compromising the domain means compromising the hypervisors, the blast radius is the whole estate.
- Put every management interface on a dedicated management network, reachable from administrative workstations or jump hosts, not from the general office network or the VPN pool.
- Treat out-of-band controllers, the iDRAC, iLO or IPMI interfaces on each server, as the keys to the building they are. They provide remote console and power control below the operating system. Keep them off the general network and never expose them to the internet, change the default credentials, and keep their firmware current.
- Use roles. An operator who restarts virtual machines does not need rights to delete storage or change the cluster network.
- Review who holds privileged access on a schedule, and remove what is no longer needed.
- Log privileged actions centrally, somewhere the account being logged cannot edit.
Multi-factor authentication wherever an administrator logs in
Multi-factor authentication belongs on the hypervisor management interface, the storage management interface, the backup console, the network equipment and the remote access path into all of them. Some infrastructure components support it poorly or not at all, particularly older out-of-band controllers and switches. Where a device cannot do it, put it behind a jump host that can, and make the network the enforcement point.
Phishing-resistant methods, such as hardware security keys, are stronger than codes that a convincing fake login page can collect. Administrative access to infrastructure is a sensible place to start with them, even before the rest of the organisation is ready.
Patching the layers underneath
Patching is about speed and coverage: the most exposed systems and the most serious vulnerabilities first, with regular vulnerability scanning to find what has been missed. Check the current maturity model for the specific timeframes and scope at your target level. In practice, hypervisors, storage firmware, out-of-band controllers and network equipment all need to be inside the patching program, and software that its vendor no longer supports is a risk in its own right.
On owned infrastructure, the practical problem is that patches get skipped when applying them means an outage. The answer is to design for rolling maintenance from the start:
- enough spare capacity that any single host can be emptied by live migration and patched
- on a hyperconverged cluster, patching one node at a time and waiting for the storage to return to full health before touching the next
- a calendar that includes firmware for servers, disks, network cards, switches and out-of-band controllers, not only the operating systems
- a register of every component’s support end date, so an out-of-support switch or hypervisor version is a planned replacement rather than a surprise
A platform that cannot be patched without downtime is a platform that will not be patched on time.
Application control and hardening on servers
Application control is usually discussed for workstations, but the same idea suits servers, and fixed-role servers are often easier candidates than desktops. A database server or a file server runs a small, stable set of software, which is exactly what an allowlist suits. Hypervisor hosts and appliances deserve the same minimalism: install only what the role needs, and nothing else.
Macro settings and user application hardening also belong on infrastructure you own if you host remote desktop or virtual desktop session hosts. Those are workstations in everything but form factor, and they should be configured like workstations.
Backups out of the attacker’s reach
The backup strategy is where owned infrastructure has the most to gain. Good backup practice means tested restores and tight control over who can access, change and delete backups. In practice that means backup administration separated from infrastructure administration, at least one copy that cannot be modified before its retention period ends, and restores that are rehearsed rather than assumed. Storage snapshots on the same cluster do not count. We covered the detail in backups that survive ransomware.
Evidence, not intentions
Maturity is assessed on evidence: configuration exports, scan results, access reviews, logs and restore test records. Owning the infrastructure means that evidence is directly available, with no waiting on a provider’s attestation. It also means someone has to collect and keep it. Build the evidence trail into normal operations and the assessment becomes a matter of gathering records rather than reconstructing them.
A practical starting point
- Draw every path by which a person can gain administrative control of a hypervisor, storage system, switch, out-of-band controller or backup system.
- Put multi-factor authentication and a management network in front of all of them, starting with the out-of-band controllers.
- List the versions and support end dates of every infrastructure component.
- Confirm that backup administration uses separate credentials from infrastructure administration.
None of this is an assessment. A formal assessment against the current maturity model is its own exercise, ideally carried out by someone independent of the people who built the environment.
Where Bizix fits
Bizix builds private cloud with management, storage cluster, storage client and tenant traffic separated onto their own VLANs from the start, and hardening is a defined phase of every deployment runbook. The Bizix Operator UI has role-aware permissions, and the environments we operate are backed by 24/7 incident response from the team that designed them.