Use Dedicated Environments for Malicious Code Analysis
Malicious software is studied in separate, secure systems to prevent it from harming other networks or devices.
Plain language
This control is about making sure any nasty software, like viruses or malware, is analysed in a secure and separate environment when we're responding to a security incident or conducting research. It's important because if we study this malware on regular systems, it might spread and cause harm to other computers or networks in the organisation.
Framework
ASD Information Security Manual (ISM)
Control effect
Responsive
Classifications
NC, OS, P, S, TS
ISM last updated
Nov 2024
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for cyber security incidentsOfficial control statement
Malicious code processed for cyber security incident response or research purposes is done so in a dedicated analysis environment that is segregated from other systems.
Why it matters
Analysing malware outside a segregated environment risks its spread, leading to potential network breaches and operational disruptions.
Operational notes
Use a dedicated malware analysis lab segregated from production (VLAN/air-gap), with controlled ingress/egress, snapshots/rebuilds, and strict tooling access.
Implementation tips
- The IT team should set up a dedicated computer or network to analyse malicious software. This means using equipment that is separate from everyday business computers, preventing the malware from accidentally affecting the rest of the organisation's systems.
- IT managers need to ensure this environment has no outside connections. This can be done by disconnecting it from the internet and any internal networks, limiting the risk of malware spreading.
- Cyber security staff should install necessary tools on the secure system. These tools should help in safely analysing the malicious software without enabling it to communicate or spread.
- Management should train staff on using the dedicated environment properly. This involves providing guidance and instructions to those who will handle suspicious software, ensuring they understand how to use the environment safely and effectively.
- The security team must update and regularly check the malicious code analysis setup. This includes software updates and routine checks to ensure the secure environment remains effective and nothing unexpected has been connected.
Audit / evidence tips
- AskRecords of the dedicated analysis environment setup GoodIncludes specific documentation showing the system's separation from others and evidence of regular updates
- GoodList demonstrates limited access to trained personnel with signed acknowledgement of their responsibilities
- AskReports from past malicious code analysis activities. Assess whether they demonstrate proper use of the dedicated environment and understanding of security protocols GoodReport clearly indicates safe handling practices and conclusions drawn from the analysis
Cross-framework mappings
How ISM-1970 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| Annex A 8.22 | ISM-1970 specifies analysis of malicious code in a segregated environment to safeguard other systems | |
| Annex A 8.31 | ISM-1970 mandates the use of a dedicated environment for analysing malicious code to prevent interference with other systems | |
| handshake Supports (2) expand_less | ||
| Annex A 8.16 | Annex A 8.16 requires monitoring networks, systems and applications for anomalous behaviour and then evaluating potential incidents | |
| Annex A 8.20 | ISM-1970 necessitates segregated environments for malware analysis, supporting the concept in ISO/IEC 27001:2022 Annex A 8.20, which ensu... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.