DC0078: Network Traffic Flow
Summarized network packet data that captures session-level details such as source/destination IPs, ports, protocol types, timestamps, and data volume, without storing full packet payloads. This is commonly used for traffic analysis, anomaly detection, and network performance monitoring.
Analyst context for executives and security teams
Network Traffic Flow is the summarized record of who talked to whom, when, over which ports and protocols, and how much data moved. For executives and security leaders, its value is that it often provides broad visibility without the cost and sensitivity of storing full packet contents. It is a foundational evidence source for understanding suspicious communications, validating incident scope, supporting network performance investigations, and showing whether the organization can reconstruct network activity during an event.
Executive priority
Prioritize this as a visibility and resilience question: can the organization produce reliable session-level network evidence when an incident, audit, or operational disruption occurs? Because ATT&CK provides no specific platform or tactic mapping for this data component, leaders should treat it as an enabling control for SOC operations, incident response, compliance evidence, and network risk management rather than as a detection by itself. Budget and control discussions should focus on collection coverage, retention, access, and whether flow records are usable across critical network segments and cloud or hybrid boundaries where applicable to the local environment.
Technical view
SOC and IR teams should validate that flow data includes the core fields described by MITRE: source and destination IPs, ports, protocol types, timestamps, and data volume. Since no official detection logic or relationships are supplied, detection engineering should not assume ATT&CK-defined analytics for this object. Instead, use flow records as supporting telemetry for traffic analysis, anomaly detection, scoping, and correlation with other logs. Key validation questions include whether timestamps are synchronized, whether network address translation or proxying obscures endpoints, whether internal east-west traffic is visible, and whether retention is sufficient for investigations.
Likely telemetry
- Summarized network session records such as source IP, destination IP, source and destination ports, protocol, timestamp, and data volume
- Network flow or session metadata from network infrastructure, monitoring systems, or equivalent traffic collection points
- Traffic volume and timing patterns used for anomaly detection and network performance monitoring
- Correlated records from adjacent sources, where available locally, to resolve host, user, asset, or service context
Detection direction
- Confirm that flow collection exists for the network areas that matter most to incident response and business continuity, not only at perimeter points.
- Validate data quality: complete fields, consistent timestamps, normalized protocol and port values, and usable retention.
- Tune analytics carefully because flow data is metadata only; unusual volume, timing, destination, or protocol patterns require context from assets, identity, endpoint, DNS, proxy, firewall, or application logs where available.
- Document blind spots such as encrypted payload visibility limits, missing internal segments, NAT or proxy ambiguity, short retention windows, and unmanaged or unmonitored network paths.
- Use flow records as corroborating evidence rather than standalone proof of malicious activity unless local detection logic and additional evidence support that conclusion.
Mitigation priorities
- Establish governance for where network flow data is collected, retained, protected, and accessed for SOC and incident response use.
- Prioritize coverage for critical business services, sensitive network zones, internet ingress and egress paths, and high-value operational dependencies as defined by the local environment.
- Ensure time synchronization and consistent normalization so flow data can be correlated with other investigative sources.
- Set retention based on incident response, audit, and regulatory needs, balancing storage cost and privacy considerations.
- Regularly test whether analysts can retrieve and interpret flow records during tabletop exercises or incident response readiness reviews.
Analyst notes and limits
This ATT&CK object is a data component, not an adversary technique. Its business value is evidentiary: it helps defenders understand network behavior at session level without requiring full packet payload capture. The supplied ATT&CK fields do not include tactics, platforms, relationships, or detection guidance, so this take focuses on practical visibility, validation, and operational use of the described data.
No official detection text, platform scope, tactic mapping, or relationship context was supplied. Any assessment of coverage, specific detections, affected environments, or risk severity requires local architecture, logging configuration, retention, and incident response requirements.
Network Traffic Flow
Summarized network packet data that captures session-level details such as source/destination IPs, ports, protocol types, timestamps, and data volume, without storing full packet payloads. This is commonly used for traffic analysis, anomaly detection, and network performance monitoring.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.1 | Current bundle | 5c3e0d899d40… |
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 DC0078Open 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.