M0937: Filter Network Traffic
Use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic. Perform inline allow/denylisting of network messages based on the application layer (OSI Layer 7) protocol, especially for automation protocols. Application allowlists are beneficial when there are well-defined communication sequences, types, rates, or patterns needed during expected system operations. Application denylists may be needed if all acceptable communication sequences cannot be defined, but instead a set of known malicious uses can be denied (e.g., excessive communication attempts, shutdown messages, invalid commands). Devices performing these functions are often referred to as deep-packet inspection (DPI) firewalls, context-aware firewalls, or firewalls blocking specific automation/SCADA protocol aware firewalls. [1]
Analyst context for executives and security teams
Filter Network Traffic is an ICS mitigation focused on making control-system communications explicit and enforceable, not merely connected. Its business value is reducing the chance that unauthorized commands, program changes, firmware-related actions, remote-service access, or abnormal message patterns can reach controllers and other operational assets. For executives, this is a resilience and safety-control question: do critical automation networks only permit the messages required for expected operations, and can the organization prove that through configuration and logs?
Executive priority
Prioritize this where interruption or manipulation of industrial processes would create operational, safety, or compliance consequences. The ATT&CK relationships show this control is relevant across high-consequence ICS behaviors including program download/upload, firmware modification, device restart/shutdown, rogue master activity, remote services, valid-account abuse, and unauthorized command or reporting messages. Leaders should ask whether network filtering is protocol-aware for automation traffic, whether allowlists are based on known-good communication sequences and rates, and whether evidence aligns to the mapped control expectations: IEC 62443 SR/CR 5.1 and NIST SP 800-53 AC-3 and SC-7.
Technical view
For SOC, OT security, and IR teams, validate that filtering is enforced at both network appliances and endpoint software where applicable. The object specifically calls out ingress/egress filtering, protocol-based filtering, and Layer 7 application allow/denylisting for automation protocols. Testing should focus on whether controls can distinguish expected engineering, supervisory, and device communications from abnormal actions such as excessive communication attempts, shutdown messages, invalid commands, unauthorized command/reporting messages, program transfer activity, firmware-update mode activity, and remote-service traffic between segments. Because ATT&CK provides no official detection text and no platforms for this mitigation, local asset inventory, ICS protocol knowledge, and firewall/DPI capability determine practical coverage.
Likely telemetry
- Network firewall and segmentation policy logs for allowed and denied ingress/egress traffic
- Deep-packet inspection or protocol-aware firewall events for automation/SCADA protocols
- Layer 7 allowlist/denylist decisions, including command type, message type, source, destination, and rate where available
- Endpoint host firewall or local filtering logs on engineering workstations, servers, and other managed endpoints where deployed
- Remote service session records for protocols such as RDP, SMB, SSH, or similar mechanisms referenced in the related Remote Services technique
Detection direction
- Do not treat this mitigation as detection coverage by itself; ATT&CK provides no official detection guidance for M0937.
- Validate whether filtering devices actually parse the ICS application-layer protocols in use, rather than only permitting ports or IP pairs.
- Tune allowlists around known-good source, destination, message type, sequence, rate, and operating pattern where communications are well defined.
- Where complete allowlisting is not feasible, maintain deny rules for known unwanted message types or conditions such as excessive attempts, shutdown messages, and invalid commands, as described by ATT&CK.
- Correlate network filtering decisions with asset roles: engineering workstations, jump boxes, control servers, masters/outstations, PLCs/controllers, and devices capable of firmware or program changes.
Mitigation priorities
- Start with an inventory of required ICS communications: assets, zones, sources, destinations, protocols, message types, expected rates, and maintenance paths.
- Implement ingress and egress filtering at network boundaries between operational segments and at relevant endpoints where software filtering is available.
- Prefer application-layer allowlisting for automation protocols when normal communication sequences and patterns are well understood.
- Add denylisting for clearly unacceptable or high-risk activity, including excessive communication attempts, shutdown messages, invalid commands, and unauthorized command/reporting message patterns where the filtering technology supports it.
- Restrict engineering and maintenance paths used for program upload/download, online edit, program append, firmware updates, and remote services to approved systems and times where operationally feasible.
Analyst notes and limits
This is a mitigation object, not a technique. Its strongest decision value comes from the breadth of related ICS techniques it mitigates: unauthorized messages, PLC program transfer activity, firmware modification, device restart/shutdown, brute-force I/O, rogue master behavior, remote services, connection proxy use, valid-account misuse, and process reconnaissance such as point/tag or operating-mode identification. The object supports a defensible control strategy: protocol-aware filtering should be designed around expected industrial communication behavior, not generic enterprise perimeter rules alone.
The supplied ATT&CK object does not specify platforms, tactics, or official detection analytics. It also does not provide vendor-specific protocol details, deployment architectures, or proof of effectiveness. Local engineering knowledge is required to define safe allowlists, maintenance exceptions, and acceptable message patterns without disrupting operations. Any assessment of coverage must be based on the organization’s actual network design, filtering technology, asset inventory, and available logs.
Filter Network Traffic
Use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic. Perform inline allow/denylisting of network messages based on the application layer (OSI Layer 7) protocol, especially for automation protocols. Application allowlists are beneficial when there are well-defined communication sequences, types, rates, or patterns needed during expected system operations. Application denylists may be needed if all acceptable communication sequences cannot be defined, but instead a set of known malicious uses can be denied (e.g., excessive communication attempts, shutdown messages, invalid commands). Devices performing these functions are often referred to as deep-packet inspection (DPI) firewalls, context-aware firewalls, or firewalls blocking specific automation/SCADA protocol aware firewalls. [1]
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 | T1693.002 | Module Firmware Sub-technique | Filter for protocols and payloads associated with firmware activation or updating activity. |
| ICS | T0843.003 | Program Append Sub-technique | Filter for protocols and payloads associated with program download activity to prevent unauthorized device configurations. |
| ICS | T1692.001 | Command Message Sub-technique | Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid messages. |
| ICS | T0843 | Program Download | Filter for protocols and payloads associated with program download activity to prevent unauthorized device configurations. |
| ICS | T0848 | Rogue Master | Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid reporting messages. |
| ICS | T0859 | Valid Accounts | Consider using IP allowlisting along with user account management to ensure that data access is restricted not only to valid users but only from expected IP ranges to mitigate the use of stolen credentials to access data. |
| ICS | T0843.001 | Download All Sub-technique | Filter for protocols and payloads associated with program download activity to prevent unauthorized device configurations. |
| ICS | T0868 | Detect Operating Mode | Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid messages. |
| ICS | T0861 | Point & Tag Identification | Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid messages. |
| ICS | T1692.002 | Reporting Message Sub-technique | Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid reporting messages. |
| ICS | T0884 | Connection Proxy | Traffic to known anonymity networks and C2 infrastructure can be blocked through the use of network allow and block lists. It should be noted that this kind of blocking may be circumvented by other techniques likeDomain Fronting. |
| ICS | T1693.001 | System Firmware Sub-technique | Filter for protocols and payloads associated with firmware activation or updating activity. |
| ICS | T0806 | Brute Force I/O | Allow/denylists can be used to block access when excessive I/O connections are detected from a system or device during a specified time period. |
| ICS | T0845 | Program Upload | Filter for protocols and payloads associated with program upload activity to prevent unauthorized access to device configurations. |
| ICS | T0843.002 | Online Edit Sub-technique | Filter for protocols and payloads associated with program download activity to prevent unauthorized device configurations. |
| ICS | T0816 | Device Restart/Shutdown | Application denylists can be used to block automation protocol functions used to initiate device shutdowns or restarts, such as DNP3's 0x0D function code, or vulnerabilities that can be used to trigger device shutdowns (e.g., CVE-2014-9195, CVE-2015-5374). |
| ICS | T1692 | Unauthorized Message | Perform inline allowlisting of automation protocol commands to prevent devices from sending unauthorized command or reporting messages. Allow/denylist techniques need to be designed with sufficient accuracy to prevent the unintended blocking of valid messages. |
| ICS | T0800 | Activate Firmware Update Mode | Filter for protocols and payloads associated with firmware activation or updating activity. |
| ICS | T0886 | Remote Services | Filter application-layer protocol messages for remote services to block any unauthorized activity. |
| ICS | T1693 | Modify Firmware | Filter for protocols and payloads associated with firmware activation or updating activity. |
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 | 02ff6d188879… |
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]
Centre for the Protection of National Infrastructure February 2005
Centre for the Protection of National Infrastructure 2005, February FIREWALL DEPLOYMENT FOR SCADA AND PROCESS CONTROL NETWORKS Retrieved. 2020/09/17
Open source URL -
[2]
mitre-attack M0937Open 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.