ASD ISM 1669 Prevent Microsoft Office from injecting code
What it says
Microsoft Office is blocked from injecting code into other processes.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishMicrosoft Office is configured to not insert code into other programs for security reasons.
This control is about stopping Microsoft Office from inserting its code into other software on your computer. It matters because if Office could easily inject code elsewhere, it might open the door for hackers to exploit that capability, leading to data theft or malicious software spreading without you knowing.
Free. Save your status, tasks and notes.
Why it matters
If Microsoft Office can inject code into other processes, attackers can use Office to run malicious code in trusted apps, enabling malware spread and data compromise.
How to implement
The IT team should adjust settings within Microsoft Office to prevent it from injecting code into other applications.
They can do this by accessing the Office application settings and modifying the security settings related to code execution and integration with other software.
Managers should work with their staff to ensure they understand how to spot any suspicious activity related to unexpected Microsoft Office behaviour.
Conduct a short training session to explain what unusual behaviour looks like, such as Office applications trying to access other programs without warning.
System administrators should regularly update Microsoft Office software.
They can schedule automatic updates or routinely check for new updates through Microsoft's update service to ensure any known vulnerabilities are patched.
Procurement officers should ensure that all purchased software including Office is bought from legitimate sources.
Verify licences and purchase records to avoid using pirated versions, which are more likely to have security risks enabling code injection.
Security officers should monitor the use of Office applications with network security tools.
Set up alerts for activities that seem odd, such as Office files that are interacting with other parts of the system without a clear reason.
Keep it running
Enable and audit the Defender ASR rule 'Block Office applications from injecting code into other processes', monitor alerts, and restrict any exceptions to approved cases.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of Microsoft Office security settings: Request a document or screenshot showing how Office is configured on systems to prevent code injection.
Look at
Settings related to macro use and application integration.
Good evidence
Will show these features are set to 'disabled' or 'restricted.'.
- Check 2 of 5What an auditor asks for
Ask for
The results of any recent IT security audits involving Microsoft Office: Request copies of the reports.
Look at
Sections that address application hardening.
Good evidence
Is an audit that specifically confirms code injection protections are active.
- Check 3 of 5What an auditor asks for
Ask for
Training materials given to staff about Microsoft Office use and security: Check the content for clear advice about preventing unauthorised actions by Office applications.
Good evidence
Includes mentions of recognising unusual Office behaviour.
- Check 4 of 5What an auditor asks for
Ask for
Documentation on the software update process: This should outline how often Office is updated and who is responsible.
Look at
Precise mechanisms and timelines ensuring updates are applied promptly.
Good evidence
Includes a log of past updates applied.
- Check 5 of 5What an auditor asks for
Ask for
Procurement records for Microsoft Office licences: Review them to ensure all software in use has legitimate licences.
Good evidence
Should rely on clear documentation from official vendors or Microsoft itself.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML2.4, Block Microsoft Office from injecting code into other processes, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.9.
ISM-1669 requires Microsoft Office to be blocked from injecting code into other processes. ISO/IEC 27001:2022 Annex A 8.9 is broader, requiring organisations to establish, document, implement, monitor and review security configurations across systems. ISM-1669 is a specific configuration requirement that would sit within an Annex A 8.9 configuration management program.
ASD Essential Eight: 5 mappings
This control is equivalent to E8-AH-ML2.4.
E8-AH-ML2.4 requires Microsoft Office to be blocked from injecting code into other processes to reduce macro-driven and exploit-driven post-compromise behaviour. ISM-1669 states the same requirement, targeting the same Office-to-process injection technique (commonly implemented via Microsoft Defender Attack Surface Reduction rules or equivalent controls). The scope and implementation intent align closely, so satisfying ISM-1669 would largely satisfy E8-AH-ML2.4.
This control partially meets E8-AH-ML2.7.
ISM-1669 requires Microsoft Office to be blocked from injecting code into other processes. E8-AH-ML2.7 is broader, requiring Office productivity suite security settings to be immutable by users, which would typically include hardening settings such as those that prevent risky behaviours. ISM-1669 is one specific hardening outcome, while the candidate covers protection of the overall Office security configuration baseline.
This control partially overlaps E8-AH-ML2.2.
ISM-1669 requires Microsoft Office to be blocked from injecting code into other processes. E8-AH-ML2.2 instead requires blocking Microsoft Office from creating child processes, which addresses a different but related Office-to-process interaction used for malware execution. Both reduce Office-driven post-exploitation behaviours, but process injection and child process creation are distinct mitigations with different enforcement points.
This control partially overlaps E8-AH-ML2.3.
ISM-1669 requires Microsoft Office to be blocked from injecting code into other processes. E8-AH-ML2.3 blocks Microsoft Office from creating executable content, limiting another common pathway where Office drops or builds malware for later execution. Both constrain Office as an enabler of code execution, but one targets process injection while the other targets creation of executable artefacts on disk.
This control partially overlaps E8-RM-ML2.1.
ISM-1669 requires Microsoft Office to be blocked from injecting code into other processes. E8-RM-ML2.1 blocks Office macros from making Win32 API calls, which can otherwise be used to perform or facilitate process injection techniques. They overlap in reducing macro-enabled malicious capability, but ISM-1669 is a direct mitigation for process injection whereas the candidate broadly restricts macro-to-OS API access.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.