ASD ISM 1605 Harden the operating system beneath software isolation mechanisms
What it says
When using a software-based isolation mechanism that consumes shared physical computing resources, the underlying operating system is hardened.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWhen you run a software-based isolation mechanism (software that separates different workloads, such as a hypervisor or container engine) on top of an operating system that shares the same physical computing resources, that underlying operating system must be hardened. Hardening means configuring the operating system securely so the isolation between workloads cannot be broken by an attacker who exploits a weakness in the shared layer beneath them.
Some software keeps different workloads apart so they cannot interfere with each other. Examples are a hypervisor (software that runs multiple virtual machines on one physical server) or a container engine (software such as Docker that runs many small isolated applications). When this separating software shares the same physical parts (the same processor, memory and storage) underneath, all of those workloads sit on one common operating system. That shared operating system becomes a single point of failure: if an attacker breaks into it, they can reach across every workload it is holding apart. This control says that whenever you use that kind of software-based separation on shared hardware, you must harden the operating system underneath it. Hardening simply means setting it up securely: removing anything not needed, locking down its configuration, and keeping it patched so there are no easy weaknesses to exploit.
Free. Save your status, tasks and notes.
Why it matters
A hardened operating system under shared isolation software stops an attacker exploiting the common host to break separation between workloads and reach data across all of them.
How to implement
The platform or infrastructure team identifies every host where a software-based isolation mechanism (such as a hypervisor or container engine) runs on a shared operating system, and records which operating system version sits underneath each one.
System administrators apply a recognised hardening baseline to that underlying operating system, for example a vendor hardening guide or an industry benchmark, and document the settings that were changed so the configuration can be repeated and checked.
Administrators reduce the attack surface of the shared operating system by removing or disabling any software, services, drivers and accounts that the isolation host does not need to function, leaving only what is essential to run the workloads.
The patching team keeps the underlying operating system fully up to date, prioritising security fixes for the host because a single unpatched weakness there can affect every isolated workload sharing the same physical resources.
The team locks the hardened configuration in place using a configuration baseline or automated build, so that every new isolation host is created already hardened and any drift away from the approved settings is detected and corrected.
Keep it running
Re-check the underlying operating system against its hardening baseline after patches and upgrades, since updates to the isolation host can reset secure settings and weaken separation between shared workloads.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Where do you run software-based isolation mechanisms (hypervisors or container engines) on a shared operating system, and how is the operating system underneath each one hardened?
Look at
an inventory of isolation hosts mapped to their underlying operating system and the hardening applied. GOOD-ANSWER: every shared host is listed and each has a documented hardening baseline.
- Check 2 of 5What an auditor asks for
Ask for
Which hardening standard or baseline did you apply to the underlying operating system?
Look at
the named vendor guide or benchmark and a record of the settings changed. GOOD-ANSWER: a recognised baseline is used and the applied configuration is documented, not just claimed.
- Check 3 of 5What an auditor asks for
Ask for
What unnecessary services, software and accounts were removed from the shared operating system?
Look at
before-and-after configuration showing the reduced attack surface. GOOD-ANSWER: only components essential to running the isolated workloads remain enabled.
- Check 4 of 5What an auditor asks for
Ask for
How quickly are security patches applied to these underlying operating systems?
Look at
patch records and dates for the isolation hosts. GOOD-ANSWER: hosts are patched promptly and host patching is prioritised because it underpins every workload.
- Check 5 of 5What an auditor asks for
Ask for
How do you stop a hardened isolation host from drifting back to an insecure configuration over time?
Look at
a configuration baseline, automated build or compliance scan results. GOOD-ANSWER: new hosts are built hardened automatically and drift from the baseline is detected and fixed.
Mappings
Closest match in ISO/IEC 27001: A.8.9, Configuration management for secure IT systems, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.9.
ISM-1605 requires that the underlying operating system for software-based isolation on shared servers is hardened, which relies on establishing and maintaining secure baseline configurations. Annex A 8.9 supports this by requiring security configurations to be established, documented, implemented, monitored, and reviewed, which is the governance and lifecycle mechanism needed to keep host OS hardening effective over time. Annex A 8.9 is broader configuration management across IT systems, while ISM-1605 is specifically the requirement to harden the host OS for virtual environments.
ASD Essential Eight: 1 mapping
This control supports E8-PO-ML3.9.
ISM-1605 requires that the underlying host operating system is hardened when using software-based isolation to share physical server hardware in virtual environments. E8-PO-ML3.9 supports this by ensuring the OS is a current (latest or previous) release, which is a foundational prerequisite for applying and sustaining effective hardening guidance and security baselines. However, E8-PO-ML3.9 is about platform currency, while ISM-1605 is about hardening configuration specifically for secure virtualisation.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.