2.3Uses of monitoring data types

More detailed monitoring data is not simply better. Detailed data explodes in retention cost, while coarse data limits investigation depth. A good SOC combines data types in layers—watching broadly day to day with alerts and lightweight metadata, and drilling into deep data only when needed. This section organizes what each of the six data types answers and how much it costs, so you can choose "which type this investigation needs."

2.3.1Deep (heavy) data types

• Full packet capture is the most detailed data, recording the entire content (headers + payload). It fully reconstructs the commands and files actually sent in an attack and has high evidentiary value. But its data volume is orders of magnitude larger, making long retention or always-on company-wide capture impractical. Use it after narrowing the deep-investigation target.
• Transaction data records individual exchanges (request and response) at the application layer—e.g., an HTTP GET /login plus response code, a DNS query and answer, an SMTP send/receive. It reveals part of the content (URLs, status, query names) without being as heavy as full payloads, letting you trace "which URL was accessed how often and what came back."

2.3.2Light (broadly retainable) data types

• Session data is the summary of one conversation (flow): the 5-tuple (source/destination IP, ports, protocol) plus start/end times and bytes/packets transferred. It has no content but lightweightly retains "who talked to whom, when, and how much" long-term; NetFlow is the representative example, leaning session/transaction. It is the backbone of correlation.
• Statistical data is many communications aggregated/baselined (average traffic by time of day, protocol ratios, top talkers). It shows overall trends rather than individual events and is used to detect "different from usual" deviations. Metadata is descriptive information attached to each communication (file names, hashes, certificate details, user agents)—not the content itself but a powerful clue.
• Alert data are notifications of "events worth attention" generated by IDS/IPS, antivirus, SIEM, etc. based on rules/signatures/behavior. It is itself a starting point—"something may have happened"—whose truth (true/false positive) is corroborated with other types (session, transaction, full packet).

Your SIEM raises an alert for "suspected malware infection." Immediately quarantining the endpoint and closing the case—or conversely treating "an alert fired = confirmed" and sounding the sirens—are both immature responses. An alert is only the starting point for corroborating truth. First, use the lightweight, long-retained session data (NetFlow) to see where externally the endpoint communicated around the alert time. Next, use transaction data to view the specific URLs it GET-ed over HTTP or the DNS names queried, checking for C2 domains or suspicious download sources. Then, as metadata, take the hash of any downloaded file and check it against threat intelligence for known malware. Once true-positive confidence is high, finally narrow to that endpoint and time window and review full packet capture to confirm the actual payloads sent/received (stolen data or C2 commands) and preserve them as evidence. This order matters—form a hypothesis with broad, light data (session, statistical, metadata) and confirm with narrow, deep data (full packet). And if you routinely baseline with statistical data, you could have noticed this endpoint's "unlike usual" traffic volume or protocol-ratio deviation—an unknown sign before any signature existed. Data types are not competitors but a division of roles, and layering them with an understanding of the cost/depth trade-off is the essence of SOC design.

2.3.3Section summary

• Full packet is entire content and heaviest, transaction is per request/response, and session (NetFlow) is the light, long-term 5-tuple conversation summary
• Statistical data detects deviation from a baseline, metadata provides attached clues like hashes/certificates, and an alert is the starting point for corroboration
• Cost and depth trade off; the crux of SOC design is a layered combination—form a hypothesis with broad light data and confirm with narrow deep data