ASD ISM 1667 Prevent child processes in Microsoft Office
What it says
Microsoft Office is blocked from creating child processes.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishMicrosoft Office is configured to prevent it from starting other programs or processes.
This control ensures that Microsoft Office programs, like Word or Excel, can't start other programs on your computer. By stopping this, you reduce the risk of getting a virus or malware that sneaks in via Office and does harmful things on your computer.
Free. Save your status, tasks and notes.
Why it matters
Allowing Office to start child processes can lead to malware execution, data breaches, or system compromises through malicious documents.
How to implement
Office Manager should coordinate with the IT team to check that Microsoft Office apps are configured correctly.
This means ensuring settings prevent these apps from launching other programs. IT can do this by updating group policies or using configuration management tools.
The IT team should review Group Policy or similar tools used in your organisation to ensure restrictions on child processes are applied.
This involves checking that the settings block Word, Excel, and other Office apps from running other software.
System Owner should work with the IT department to deploy any necessary security updates.
Make sure Office apps are set to update automatically as these updates often fix security vulnerabilities that could allow child processes to run.
IT team should conduct regular checks to confirm the settings are active.
This includes testing whether the software restrictions on child processes are actually being enforced by trying to run a script or program from within an Office app and ensuring it's blocked.
Management should communicate the importance of these measures to all staff, ensuring they understand not to change settings that enable child processes.
Provide training that highlights the security risks involved if these settings are altered.
Keep it running
Regularly confirm the ASR rule 'Block Office from creating child processes' is enabled and enforced; review blocked events to tune exceptions.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A report from the IT team showing the configuration settings applied to Microsoft Office.
Look at
The settings to confirm they specifically prevent Office from running other programs.
Good evidence
Will show settings like Group Policy Object (GPO) configurations that restrict these actions.
- Check 2 of 5What an auditor asks for
Look at
The logs to verify they show blocks when such attempts occur.
Good evidence
Is logs showing blocked attempts with date and time stamps.
- Check 3 of 5What an auditor asks for
Ask for
A demonstration where an IT member attempts to run a program from within Word or Excel. Look closely to ensure the attempt is blocked and recorded.
Good evidence
Will show the attempt fails and is logged.
- Check 4 of 5What an auditor asks for
Look at
Records that these updates include any changes to child process settings.
Good evidence
Would be a log or report listing updates and their impact on security configurations.
- Check 5 of 5What an auditor asks for
Ask for
Training records or communications sent to staff about security settings in Office.
Look at
The content for clarity on prohibitions against altering these settings.
Good evidence
Is a complete record of educational efforts detailing why the control is important.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML2.2, Block Microsoft Office from creating child processes, which asks for the same thing.
ASD Essential Eight: 5 mappings
This control is equivalent to E8-AH-ML2.2.
ISM-1667 requires Microsoft Office to be blocked from creating child processes. E8-AH-ML2.2 specifies the same control outcome for Microsoft Office child process creation. The scope and intent align closely (hardening Office to prevent process-spawning tradecraft).
This control partially overlaps E8-AH-ML2.3.
ISM-1667 requires Microsoft Office to be blocked from creating child processes. E8-AH-ML2.3 addresses a related capability by blocking Office from creating executable content, which often precedes launching them as child processes. They overlap in mitigating Office-based execution chains, but ISM-1667 is about process spawning whereas E8-AH-ML2.3 is about creating executable artefacts.
This control partially overlaps E8-AH-ML2.4.
E8-AH-ML2.4 requires blocking Microsoft Office from injecting code into other processes. ISM-1667 instead requires blocking Microsoft Office from creating child processes, which mitigates a related but different Office abuse path (process spawning rather than process injection). Both reduce Office's ability to launch or control other programs, but E8-AH-ML2.4 targets injection specifically while ISM-1667 targets process creation.
This control partially overlaps E8-AH-ML2.5.
E8-AH-ML2.5 requires Microsoft Office to be configured to prevent activation of OLE packages to reduce embedded-object execution risk. ISM-1667 requires Microsoft Office to be blocked from creating child processes, which mitigates common post-exploitation behaviours used by malicious Office content. They overlap in reducing Office-borne malware execution pathways, but E8-AH-ML2.5 is specifically about OLE package activation whereas ISM-1667 targets process creation regardless of whether OLE is involved.
This control partially overlaps E8-RM-ML2.1.
E8-RM-ML2.1 focuses on preventing Win32 API calls from Office macros to limit interaction with the system. ISM-1667 prohibits Office from creating child processes, a technique used by macros for payload execution. Though the methods differ, both aim to restrict macro-execution pathways.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.