M0930: Network Segmentation
Architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network. Restrict network access to only required systems and services. In addition, prevent systems from other networks or business functions (e.g., enterprise) from accessing critical process control systems. For example, in IEC 62443, systems within the same secure level should be grouped into a zone, and access to that zone is restricted by a conduit, or mechanism to restrict data flows between zones by segmenting the network. CitationIEC February 2019 CitationIEC August 2013
Security context for executives and security teams
Network Segmentation matters in ICS because many high-consequence actions depend first on reaching sensitive control assets, engineering functions, remote services, or OT protocols. The business value is not just “better network design”; it is reducing the chance that exposure from internet-facing services, enterprise networks, remote access paths, or transient assets can become direct access to process control systems.
Executive priority
Treat this as a resilience and governance control. Leaders should ask whether critical process control systems are grouped into defensible zones, whether access between zones is limited to required conduits, and whether internet-facing services are contained in a DMZ rather than exposed to internal control networks. The supplied ATT&CK labels also make this useful for compliance evidence against IEC 62443 SR/CR 5.1 and NIST SP 800-53 AC-3.
Technical view
For SOC, IR, and OT engineering teams, the validation point is whether segmentation actually restricts traffic needed for the related ICS techniques: external remote services, public-facing application exposure, discovery, network sniffing, OPC-style collection, program upload/download, operating mode changes, device restart/shutdown, rogue master activity, and use of standard protocols such as HTTP(S), OPC, RDP, telnet, DNP3, and Modbus. ATT&CK provides no detection text for this mitigation, so teams should evaluate control enforcement and monitoring at zone boundaries rather than assume detection coverage.
Likely telemetry
- Network zone and conduit diagrams or asset inventory showing critical systems, engineering workstations, DMZ services, enterprise networks, and process control networks
- Firewall, router, ACL, and segmentation policy configurations
- Firewall and boundary device allow/deny logs between enterprise, DMZ, remote access, and ICS zones
- Remote access gateway or VPN connection logs where external remote services are used
- Network flow records or packet metadata for OT and standard application protocols crossing zone boundaries
Detection direction
- Validate that monitoring exists at segmentation boundaries, not only on enterprise endpoints.
- Baseline approved traffic between zones and tune alerts for new conduits, unexpected protocols, or unexpected source/destination pairs involving critical process control systems.
- Review whether broadcast, multicast, port scan, and protocol enumeration activity can be observed within and across ICS zones.
- Correlate remote service access with any subsequent connections into engineering or control zones.
- Expect false positives during authorized maintenance, firmware work, engineering changes, and vendor support; require change context rather than suppressing all such activity.
Mitigation priorities
- Identify critical systems, functions, and resources, then group systems with similar security requirements into zones.
- Restrict traffic between zones through defined conduits and allow only required systems and services.
- Place internet-facing services in a DMZ rather than exposing internal control networks.
- Prevent enterprise networks or unrelated business functions from directly accessing critical process control systems unless explicitly required and controlled.
- Prioritize segmentation around remote access, engineering workstations, PLC/controller access paths, and protocols used for control, discovery, and management.
Additional notes and limits
The relationship set shows this mitigation is broadly relevant across ICS behaviors involving initial access, discovery, collection, remote services, control protocol use, and engineering changes. Its practical value depends on whether segmentation is enforced and monitored, not merely documented.
Platforms and tactics are not specified, and ATT&CK provides no official detection guidance for M0930. Local architecture, asset inventory, protocol use, and maintenance workflows are required to determine exact control gaps and telemetry needs.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Network Segmentation
Architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network. Restrict network access to only required systems and services. In addition, prevent systems from other networks or business functions (e.g., enterprise) from accessing critical process control systems. For example, in IEC 62443, systems within the same secure level should be grouped into a zone, and access to that zone is restricted by a conduit, or mechanism to restrict data flows between zones by segmenting the network. CitationIEC February 2019 CitationIEC August 2013
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.
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.
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.