Filter Network Traffic (M1037)

Defensive objective

Filter Network Traffic is the defensive objective identified by MITRE ATT&CK® as M1037. In practical terms, the objective is to permit only necessary network communication and inspect, block, or constrain traffic that violates approved flows and trust boundaries.

The mitigation should be treated as a control objective rather than a product label. An organization still has to identify the systems, identities, data, workflows, and adversary behaviors that are in scope, then choose technical and procedural safeguards appropriate to its architecture.

A useful implementation makes the boundary of Filter Network Traffic explicit: where it applies, who owns it, what evidence demonstrates operation, what exceptions remain, and which detection, response, and recovery layers address residual risk.

Scope and design decisions

Network mitigations control reachability and visibility across trust boundaries, including user, server, cloud, management, remote-access, and incident-communications paths.

For Filter Network Traffic, begin with the decision points that make the relevant adversary behavior possible. Map the required access, privilege, trust, exposure, configuration, and dependencies before choosing enforcement. This prevents a broad control statement from hiding uncovered platforms or alternate paths.

• Map required flows, identities, protocols, ports, destinations, and administrative paths.
• Default to the least access that supports the approved service.
• Separate management and recovery paths from ordinary production traffic.
• Centralize flow, firewall, proxy, DNS, inspection, and remote-access evidence.
• Test failure, bypass, fail-open, fail-closed, and emergency-access behavior.

Implementation priorities

The implementation priorities below turn M1037 into an operating capability. They are intentionally technology-neutral so they can be applied to on-premises, cloud, hybrid, endpoint, application, identity, and service-provider environments.

Sequence the work so visibility and rollback exist before disruptive enforcement. High-consequence controls should be introduced through representative testing, documented change authority, and a time-bounded exception process.

• Map required flows
• enforce least-access rules
• centralize rule change and traffic evidence
• remove stale allowances.
• Assign an accountable control owner and named operational team.
• Document scope, prerequisites, dependencies, and known exclusions.
• Pair prevention or restriction with protected telemetry and response procedures.
• Review the control after incidents, major architecture changes, and material threat shifts.

Validation and evidence

Validation should show that Filter Network Traffic is deployed where intended, resists unauthorized change, produces usable evidence, and affects the targeted path. A policy document or enabled feature is not enough by itself.

Use at least one controlled positive test, one controlled negative test, and one legitimate business workflow. Confirm timestamps, identity attribution, field meaning, retention, alert delivery, escalation, and recovery. Evidence should support both operational troubleshooting and an independent assurance review.

• Current network and data-flow diagrams with owners and trust boundaries
• Firewall, proxy, segmentation, DNS, inspection, and remote-access rule exports
• Flow, session, rejection, inspection, and policy-change telemetry
• Rule review, recertification, exception, and expiration records
• Controlled connection tests from approved and unapproved sources

Common failure modes

Filter Network Traffic can appear complete while leaving meaningful bypasses. The following conditions should be treated as test hypotheses, not merely checklist cautions.

Where a failure mode cannot be removed immediately, record the residual risk, compensating visibility, response expectation, accountable owner, and date by which the decision must be reconsidered.

• A diagram shows intended segmentation but routing, identity, or cloud policy permits a bypass.
• Temporary rules become permanent because ownership and expiration are missing.
• Encrypted, tunneled, alternate-protocol, or management traffic avoids the expected control.
• Inspection exists at one choke point while direct service paths remain open.
• A security device fails in a mode that restores broad connectivity without alerting.

Ownership, exceptions, and review

The business or risk owner decides how much residual risk is acceptable; the control owner designs and maintains Filter Network Traffic; operators respond to control health and security events; and assurance functions independently evaluate evidence. Those roles may be performed by different teams, but they should not be left implicit.

Every exception should state the affected asset or population, business reason, approving owner, compensating controls, monitoring requirement, expiration date, and reassessment trigger. A change in exposure, privilege, data sensitivity, threat activity, platform support, or recovery capability should force review before the ordinary cadence.

• Name the risk owner, control owner, operator, and independent reviewer.
• Set measurable coverage, health, effectiveness, and response indicators.
• Require expiration dates for exceptions and temporary workarounds.
• Retain evidence of approval, testing, incidents, remediation, and closure.
• Reassess after material threat, architecture, identity, data, or supplier changes.

Using this mitigation with ATT&CK

ATT&CK associates mitigation objects such as M1037 with adversary techniques and sub-techniques for which the defensive objective may be relevant. A relationship is a research and engineering lead—not a guarantee that one implementation prevents every procedure represented by a technique.

Start with the observed or prioritized adversary behavior, inspect the official relationship and its supporting context, then determine whether this mitigation changes a required precondition, blocks an action, limits consequence, improves recovery, or creates evidence. Preserve the distinction between preventive coverage, detective visibility, response readiness, and resilience.

Bare Metal Cyber will add a separately validated relationship layer in a later release. This foundation release does not fabricate or overstate technique coverage where the official relationship edge has not yet been imported and reviewed.

Attribution, version, and scope

© 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. Bare Metal Cyber is not affiliated with or endorsed by MITRE.

This is an original Bare Metal Cyber educational profile reviewed against Enterprise ATT&CK catalog v19.2. The official M1037 page controls the current object name, status, version, relationships, source citations, and changes. MITRE identifier, name, version, creation date, modification date, and official URL are preserved as source metadata; the explanatory and implementation guidance is original.

Certification relevance

This subject appears in or supports the following certification bodies of knowledge:

Authoritative sources

• MITRE ATT&CK® M1037 — Filter Network Traffic
• MITRE ATT&CK® Enterprise Mitigations
• MITRE ATT&CK® Data & Tools
• MITRE ATT&CK® Legal and Branding Guidance