ASD ISM 1492 Enable exploit protection in operating systems
What it says
Operating system exploit protection functionality is enabled.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure operating system settings are adjusted to block potential attacks.
We need to make sure our computer systems are set up to stop hackers from taking advantage of any weaknesses in the software. This is crucial because if a system is vulnerable, it could lead to sensitive information being stolen, systems being disrupted, and potentially cost the business money and damage its reputation.
Free. Save your status, tasks and notes.
Why it matters
If exploit protection isn't enabled, attackers may exploit OS vulnerabilities, leading to data breaches and operational disruptions.
How to implement
The IT team should review current operating system settings to ensure exploit protections are enabled.
They can do this by accessing the system's settings menu and verifying that protections such as Data Execution Prevention and Address Space Layout Randomization are turned on.
The system owner should regularly update all operating systems to the latest versions.
They should set up automatic updates or schedule regular manual checks to ensure each device has the newest protection features, as updates often fix known vulnerabilities.
The IT team should create a simple guideline for employees on how to keep their system protections enabled.
This can include step-by-step instructions with screenshots, explaining how to check their settings and what to do if something seems off.
Business managers should organise awareness sessions about the importance of keeping systems secure.
These sessions can include demonstrations of potential threats and how exploit protection can prevent them, emphasising the real-life consequences of insecure systems.
System owners should work with their IT team to perform regular checks for compliance.
They should use automated tools to scan for and alert any security setting changes that might disable exploit protection, ensuring continuous enforcement.
Keep it running
Regularly verify OS exploit protection settings and updates to prevent new vulnerabilities from being exploited by attackers.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The operating system settings report for each business device.
Look at
Whether exploit protections like Data Execution Prevention are enabled.
Good evidence
Is a consistent report showing enabled protections across all devices.
- Check 2 of 5What an auditor asks for
Ask for
The process documentation on updating operating systems.
Look at
Evidence that updates are scheduled and tracked.
Good evidence
Shows clear procedures for regular updates to secure all systems.
- Check 3 of 5What an auditor asks for
Look at
The inclusion of sections about maintaining system security settings.
Good evidence
Features explicit guidance on exploit protection with visuals or step-by-step guides.
- Check 4 of 5What an auditor asks for
Ask for
Logs or records of regular security checks.
Look at
Timestamps and outcomes to confirm ongoing assessments of exploit protections settings.
Good evidence
Is regularly updated logs indicating compliance checks.
- Check 5 of 5What an auditor asks for
Look at
Alerts and actions taken in response to any exploit protection settings being turned off.
Good evidence
Is evidence of active monitoring and swift action to resolve issues.
Mappings
Closest match in ASD Essential Eight: E8-RA-ML3.4, Memory integrity functionality is enabled, which this control covers in full and more.
ASD Essential Eight: 4 mappings
This control is broader than E8-RA-ML3.4.
E8-RA-ML3.4 requires memory integrity functionality to be enabled to harden systems against memory-based exploitation and unauthorised code execution. ISM-1492 requires operating system exploit protection functionality to be enabled, which commonly includes multiple mitigations such as CFG, DEP, ASLR, and related exploit protections. Memory integrity is one specific protection under this, making E8-RA-ML3.4 a subset of the broader OS exploit protection posture required by ISM-1492.
This control partially overlaps E8-AC-ML3.3.
E8-AC-ML3.3 requires implementing Microsoft's vulnerable driver blocklist to prevent exploitation via known vulnerable kernel drivers. ISM-1492 relates by requiring operating system exploit protection to be enabled, which can mitigate exploitation techniques (including some privilege escalation paths) even if a vulnerable driver is present. The blocklist prevents specific drivers from loading, whereas exploit protection is a broader OS hardening measure and may not stop a vulnerable driver from being installed or started.
This control partially overlaps E8-RA-ML3.5.
ISM-1492 requires operating system exploit protection functionality to be enabled to block or reduce common exploitation behaviours. E8-RA-ML3.5 requires Local Security Authority (LSA) protection, which hardens a specific OS authentication component against tampering and credential dumping. The common ground is OS hardening that frustrates attacker activity, but ISM-1492 is aimed at exploit protection broadly while E8-RA-ML3.5 is a targeted control for protecting the LSA process.
This control partially overlaps E8-RA-ML3.6.
ISM-1492 requires operating system exploit protection functionality to be enabled to reduce successful exploitation paths. E8-RA-ML3.6 focuses on enabling Credential Guard, which uses OS virtualisation-based security to protect credentials from post-exploitation theft. Both are OS security hardening features that impede attacker techniques, but E8-RA-ML3.6 is credential-theft specific whereas ISM-1492 targets exploit protection more generally.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.