ASD ISM 1607 Integrity monitoring and logging for isolation mechanism
What it says
When using a software-based isolation mechanism that consumes shared physical resources, integrity monitoring and centralised event logging is performed for the isolation mechanism and underlying operating system.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure shared resources have integrity monitoring and logging for safety and transparency.
This control is about making sure that any software acting as a security barrier on shared resources is being watched and recorded. If this isn't done, someone might tamper with your software and you wouldn't even know, leading to data breaches or system failures.
Free. Save your status, tasks and notes.
Why it matters
If integrity monitoring isn't in place, systems might be tampered with to exploit weaknesses unnoticed, risking data theft or loss of trust.
How to implement
The IT team should set up monitoring software to keep an eye on systems that use virtual resources.
This involves choosing a tool that logs any changes or unusual activities and makes alerts to notify staff.
System owners should work with IT professionals to define clear roles for who responds to alerts.
They need to train staff so they know what to do when something looks suspicious.
Managers should ensure regular checks of the logs by assigning someone on their team to review them weekly.
Use a simple checklist to spot patterns suggesting the isolation mechanism has been compromised.
IT staff should develop a clear plan to regularly update and test the monitoring tools.
This ensures the tools remain effective at spotting potential threats.
Organisation leaders should make sure there is a policy to log all access attempts.
This involves writing a guideline that everyone must follow, capturing who accessed the systems and what they did.
Keep it running
Ensure monitoring and logging processes are consistently maintained to quickly identify and respond to any suspicious activities or anomalies.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the list of monitoring tools being used: Check the list includes details on what each tool does and when it was last updated.
Good evidence
includes named tools, dates of updates, and how they are configured.
- Check 2 of 5What an auditor asks for
Ask for
training logs for staff who handle alerts.
Look at
the dates and content of this training to ensure it's recent and relevant.
Good evidence
shows recent sessions covering how to handle specific threats or alerts.
- Check 3 of 5What an auditor asks for
Good evidence
shows comprehensive logs with patterns or suspicions being raised.
- Check 4 of 5What an auditor asks for
Ask for
evidence of regular log reviews.
Look at
records or reports showing reviews are happening on schedule.
Good evidence
includes review records showing issues identified and resolved.
- Check 5 of 5What an auditor asks for
Ask for
the policy document on integrity monitoring: Ensure it includes a clear outline of procedures for monitoring and responses.
Good evidence
shows a well-documented policy with executive approval and regular updates.
Mappings
Closest match in ISO/IEC 27001: A.8.16, Monitoring networks and systems for anomalous behaviour, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.16.
ISM-1607 focuses on integrity monitoring and centralised logging for server hardware shared via software isolation. Annex A 8.16 mandates broader monitoring of networks, systems, and applications for anomalies, exceeding ISM-1607's specific scope.
ASD Essential Eight: 4 mappings
This control partially overlaps E8-AH-ML2.12.
E8-AH-ML2.12 requires centralised logging of command line process creation events on hosts. ISM-1607 requires integrity monitoring and centralised event logging for the isolation mechanism and underlying operating system when using software-based isolation to share server hardware. They overlap on the centralised logging concept for the underlying OS, but ISM-1607 is context-specific to shared servers and adds integrity monitoring requirements that E8-AH-ML2.12 does not address.
This control partially overlaps E8-RA-ML2.6.
ISM-1607 mandates integrity monitoring and centralised event logging for isolation mechanisms and host OS on shared servers. E8-RA-ML2.6 requires logging privileged access events, relevant as a key part of the telemetry ISM-1607 seeks to capture. The scope of ISM-1607 includes integrity and platform logs for shared environments specifically.
This control partially overlaps E8-RA-ML2.9.
ISM-1607 requires integrity monitoring and centralised event logging for shared server hardware using software isolation. E8-RA-ML2.9 requires timely analysis of event logs from internet-facing servers to detect cybersecurity events. While ISM-1607 is specific to virtualisation layers and logging, E8-RA-ML2.9 focuses on the operational review and analysis of these logs.
This control supports E8-MF-ML2.7.
ISM-1607 requires monitoring and central logging for shared servers using software isolation. E8-MF-ML2.7 ensures logs are protected from tampering, essential for the reliability of ISM-1607's monitoring data.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.