M0931: Network Intrusion Prevention
Use intrusion detection signatures to block traffic at network boundaries. In industrial control environments, network intrusion prevention should be configured so it will not disrupt protocols and communications responsible for real-time functions related to control or safety.
Analyst context for executives and security teams
Network Intrusion Prevention is an ICS mitigation focused on blocking suspicious traffic at network boundaries using intrusion detection signatures. Its business value is reducing the chance that adversary traffic, scanning, tool movement, proxying, or command-and-control over common protocols reaches sensitive control environments. In ICS, the key leadership issue is balance: prevention can reduce risk, but poorly tuned blocking can disrupt real-time control or safety communications.
Executive priority
Treat this as a resilience and control-assurance priority for industrial environments. Executives should ask whether boundary prevention is deployed where IT/OT and other trusted networks connect, whether it is tuned for ICS protocols and safety constraints, and whether evidence exists for IEC 62443 SR/CR 6.2 and NIST SP 800-53 SI-4-aligned monitoring/prevention expectations. Budget and risk decisions should account for both missed malicious traffic and the operational risk of overblocking legitimate control traffic.
Technical view
SOC, OT, and IR teams should validate that network intrusion prevention is positioned at relevant network boundaries and has signatures or policies for behaviors represented by the mitigated techniques: adversary-in-the-middle activity, port scanning, lateral tool transfer, standard application-layer protocol abuse, connection proxying, and use of commonly used ports. Because MITRE provides no detection text and no platform scope for this mitigation, local architecture, protocol baselines, and change-control evidence are required to judge whether coverage is meaningful.
Likely telemetry
- Network intrusion prevention alerts, block events, signature matches, and policy decisions
- Network boundary traffic logs, firewall logs, and flow records
- Allowed and denied communications involving common ports and standard protocols such as HTTP(S), OPC, RDP, telnet, DNP3, and Modbus where present
- OT/ICS protocol and asset communication baselines used to distinguish expected real-time traffic from anomalous traffic
- Change-control or exception records for prevention rules that could affect control or safety communications
Detection direction
- Confirm whether prevention events are centrally visible to SOC/IR teams, not only stored on the device enforcing the block.
- Tune signatures and policies against known ICS communication patterns so blocking does not interrupt real-time control or safety functions.
- Test visibility for traffic that blends into standard protocols, commonly used ports, and trusted network paths, since the related techniques explicitly use those patterns.
- Review port-scan and lateral transfer detections with false-positive context from approved engineering, maintenance, and asset-discovery activity.
- Correlate prevention events with boundary flow data so analysts can distinguish blocked attempts from allowed traffic requiring investigation.
Mitigation priorities
- Start with boundary placement: prioritize IT/OT, vendor, remote-access, and other trusted-network intersections where adversary traffic could cross into control environments.
- Use signatures and prevention policies conservatively in safety-sensitive segments, moving from monitoring to blocking only after validating operational impact.
- Baseline legitimate ICS protocols and communications before enabling disruptive controls.
- Maintain documented exceptions, rule changes, and testing evidence for compliance and incident review.
- Regularly review coverage against the related ATT&CK techniques, especially AiTM, port scanning, tool transfer, proxy use, standard protocol abuse, and common-port abuse.
Analyst notes and limits
This is a course-of-action object, not an adversary behavior. The strongest Glexia value is in validating whether prevention is safely enforceable in the specific industrial network, with evidence that blocked traffic, exceptions, and operational impact are governed.
MITRE supplies no official detection guidance, no platforms, and no tactics for this object. The object states the mitigation concept and cautions against disrupting ICS real-time control or safety communications; effectiveness must be assessed using local network design, asset inventory, protocol baselines, and prevention logs.
Network Intrusion Prevention
Use intrusion detection signatures to block traffic at network boundaries. In industrial control environments, network intrusion prevention should be configured so it will not disrupt protocols and communications responsible for real-time functions related to control or safety.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0869 | Standard Application Layer Protocol | Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. |
| ICS | T0846.001 | Port Scan Sub-technique | Use network intrusion detection/prevention systems to detect and prevent port scans. |
| ICS | T0884 | Connection Proxy | Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific C2 protocol used by a particular adversary or tool and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools. CitationGardiner, J., Cova, M., Nagaraja, S February 2014 |
| ICS | T0885 | Commonly Used Port | Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific protocol used by a particular adversary or tool and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools. CitationGardiner, J., Cova, M., Nagaraja, S February 2014 |
| ICS | T0865 | Spearphishing Attachment | Network intrusion prevention systems and systems designed to scan and remove malicious email attachments can be used to block activity. |
| ICS | T0830 | Adversary-in-the-Middle | Network intrusion detection and prevention systems that can identify traffic patterns indicative of AiTM activity can be used to mitigate activity at the network level. |
| ICS | T0863 | User Execution | If a link is being visited by a user, network intrusion prevention systems and systems designed to scan and remove malicious downloads can be used to block activity. |
| ICS | T0867 | Lateral Tool Transfer | Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware or unusual data transfer over known tools and protocols like FTP can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific obfuscation technique used by a particular adversary or tool and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools. CitationGardiner, J., Cova, M., Nagaraja, S February 2014 |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | b6422f4804d0… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M0931Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.