ASD ISM 1604 Harden software isolation mechanisms sharing physical computing resources
What it says
When using a software-based isolation mechanism that consumes shared physical computing resources, the configuration of the isolation mechanism is hardened by removing unneeded functionality and restricting access to the administrative interface used to manage the isolation mechanism.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishA software-based isolation mechanism is software (such as a hypervisor or container engine) that lets multiple workloads share the same physical computing resources (the same processor, memory and storage) while keeping them separated from each other. Because everything runs on shared hardware, a weakness in this software could let one workload reach another's data or take over the underlying system. This control requires you to harden the isolation mechanism's configuration in two specific ways. First, remove any functionality that is not needed, so there are fewer features an attacker could exploit. Second, restrict access to the administrative interface (the management console or controls used to configure and run the isolation mechanism) so that only authorised people can change how it works.
When you run several systems on the same physical machine, special software keeps them apart so they cannot interfere with each other. This software has to be locked down. There are two things to do. The first is to turn off any features the software offers that your business does not actually use, because every switched-on feature is something an attacker could try to misuse. The second is to make sure that only trusted, authorised staff can reach the management controls that configure the software. If you leave unused features running, or let too many people into the management controls, an attacker could break out of one system, reach data that belongs to another, or take over the whole shared machine.
Free. Save your status, tasks and notes.
Why it matters
If unused features stay enabled or too many people reach the management controls, an attacker could break out of one workload, read another's data, or take over the shared machine.
How to implement
System administrators should produce a baseline configuration for the isolation mechanism (for example the hypervisor or container engine) that lists every feature, service and capability it offers, then disable everything not required for business use.
The platform team should turn off optional functions that are commonly unused on shared-resource isolation software, such as unnecessary device pass-through, clipboard or file sharing between guests, legacy network services, and unused management plugins or APIs.
Identity administrators should restrict the administrative interface so only named, authorised individuals can reach it, using role-based access so each person has only the management rights their job needs.
Network engineers should place the administrative interface on a separate, controlled management network and block it from general user networks and the internet, so the controls cannot be reached from where workloads run.
The configuration owner should record each hardening change with the reason it was made, and re-check the live configuration against the hardened baseline on a set schedule so removed features are not quietly re-enabled.
Keep it running
Re-check the live configuration against the hardened baseline on a set schedule, since updates or new workloads can re-enable removed features or widen admin access.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the team to name the software-based isolation mechanisms that share physical computing resources and to show the hardened configuration baseline for each.
Look at
a documented list of features with unneeded ones marked disabled and a reason recorded.
Good evidence
pairs each removed feature with its business justification and a date.
- Check 2 of 5What an auditor asks for
Ask for
how they decided which functionality was unneeded.
Look at
a feature-by-feature review against business requirements rather than default vendor settings left in place.
Good evidence
references a vendor hardening guide or benchmark and shows defaults that were deliberately turned off.
- Check 3 of 5What an auditor asks for
Ask for
who can reach the administrative interface and how access is granted.
Look at
a short list of named, authorised administrators with role-based permissions.
Good evidence
shows access is limited by role and that general users and unused accounts cannot reach the management controls.
- Check 4 of 5What an auditor asks for
Ask for
how the administrative interface is protected from being reached by ordinary workloads or external networks.
Look at
network separation, firewall rules or an isolated management network.
Good evidence
demonstrates the interface is unreachable from user and guest networks.
- Check 5 of 5What an auditor asks for
Ask for
how they confirm the hardening stays in place over time.
Look at
periodic checks comparing the live configuration against the hardened baseline.
Good evidence
shows dated review records and evidence that any drift (re-enabled features or added admin access) was corrected.
Mappings
Closest match in ISO/IEC 27001: A.8.3, Restrict access to information and assets, which this control covers in full and more.
ISO/IEC 27001: 4 mappings
This control is broader than A.8.3.
ISM-1604 requires hardening of the virtual isolation mechanism and restricting access to its administrative interface. Annex A 8.3 broadly requires restricting access to information and associated assets in line with access control policy, which includes restricting access to hypervisors, management consoles and configuration stores. ISM-1604 is a specific, technology-focused instance of this general access restriction requirement for virtualisation management and isolation controls.
This control partially meets A.5.15.
ISM-1604 requires hardening of the virtual server isolation mechanism and restricting access to the administrative interface used to manage it. Annex A 5.15 sets the overarching requirement to establish and implement access control rules and procedures for logical access to assets, which includes hypervisor management interfaces. ISM-1604 is a specific technical application of access control policy to virtualisation administration rather than a full access control policy framework.
This control partially meets A.8.9.
ISM-1604 requires a hardened configuration for the software-based isolation mechanism, including removing unneeded functionality and restricting administrative interface access. Annex A 8.9 requires configurations (including security configurations) across hardware, software, services and networks to be established, documented, monitored and reviewed, which encompasses hypervisor configuration baselines and reviews. ISM-1604 is a specific configuration hardening requirement for virtualisation isolation, whereas Annex A 8.9 covers configuration management lifecycle controls broadly.
This control partially overlaps A.8.2.
ISM-1604 requires restricting access to the administrative interface used to manage the isolation mechanism, reducing who can administer the hypervisor/virtualisation layer. Annex A 8.2 supports this by requiring privileged access rights to be restricted and managed, which is the governance mechanism that should determine and enforce who may administer the isolation mechanism. ISM-1604 is more prescriptive about hardening the isolation mechanism itself, while Annex A 8.2 focuses on privileged access allocation and control.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.