NSM (Network Security Monitoring)

Network Security Monitoring (NSM) is the discipline of collecting, storing, and analyzing network traffic data to detect and respond to intrusions. NSM assumes that prevention eventually fails, so it focuses on visibility and detection: gathering telemetry (full packet content, session data, transaction data, and alerts) that lets an analyst reconstruct what happened during an incident and assess its scope. The term was popularized by Richard Bejtlich in “The Tao of Network Security Monitoring” and “The Practice of Network Security Monitoring,” which frame NSM as a threat-centric approach rather than reliance on the firewall alone.

What is Network Security Monitoring?

NSM is not a single device or product but an operational process built on three pillars: collection of network data, detection of suspicious events, and analysis performed by people and tools. Its core premise is that since no defense blocks every attack, you must maintain enough visibility to quickly determine that a compromise occurred, establish what the adversary did, and contain the impact.

NSM works on passive data — a sensor attached to a SPAN/port mirror or a network TAP sees a copy of the traffic without interfering with its flow. Capture is therefore invisible to the attacker and introduces no latency. This distinguishes NSM from inline controls such as firewalls and IPS, which actively block packets.

What are the NSM data types?

The value of NSM comes from layering several kinds of telemetry that differ in granularity and storage cost. The classic taxonomy (Bejtlich) includes:

• Full content — raw packets stored as PCAP (e.g., via tcpdump). The richest and most expensive data: it lets you reconstruct payloads, headers, and transferred files byte by byte.
• Session / flow data — a summary of a “conversation” between two hosts: source and destination IP, ports, protocol, timestamps, duration, and byte and packet counts. Produced by NetFlow/IPFIX, Argus, or Zeek (conn.log). Compact, and ideal for retrospection and anomaly detection.
• Transaction data — application-specific event logs extracted from traffic: HTTP requests and responses, DNS queries, TLS handshakes, SMTP commands. This is Zeek’s domain, decomposing traffic into readable protocol logs.
• Statistical data — profiles and aggregates of traffic (protocol distribution, top talkers, volume over time) used to baseline normal behavior and spot deviations.
• Alert data — verdicts from IDS engines (e.g., Suricata, Snort) matching traffic against signatures or rules. The smallest in volume, but flags the points that warrant analyst attention.
• Extracted content — files carved out of traffic (documents, executables) routed to analysis or a sandbox.

In practice a SOC combines these layers: an IDS alert flags an event, session and transaction data provide context, and full-content PCAP confirms exactly what occurred.

How does NSM work step by step?

1. Traffic acquisition — a sensor captures a copy of packets via a TAP or SPAN; in encrypted environments this may add TLS termination/decryption or analysis of metadata instead of payload.
2. Telemetry generation — engines such as Zeek produce transaction logs, Suricata generates alerts, and a separate process writes full content to PCAP.
3. Indexing and storage — data lands in a store (e.g., Elasticsearch) under a retention policy; full content usually has a shorter window than lightweight flow logs.
4. Detection — signature rules, behavioral detections, and threat hunting surface suspicious events.
5. Analysis and response — an analyst correlates the data layers, decides whether an alert is an incident, and triggers incident response.

Which tools implement NSM?

NSM traditionally relies on open-source, vendor-neutral tooling:

• Zeek (formerly Bro) — a passive traffic analyzer generating rich transaction logs and metadata; the core of the transaction-data layer.
• Suricata and Snort — signature-based IDS/IPS engines providing alert data; Suricata can also run inline as an IPS.
• tcpdump and Wireshark — capture and analysis of full-content PCAP.
• Argus, NetFlow/IPFIX — session/flow data.
• Security Onion — a ready-made distribution combining Zeek, Suricata, Strelka (file analysis), the Elastic stack, and an investigation interface; effectively the reference NSM platform for a SOC.

How does NSM differ from IDS/IPS and a firewall?

A firewall and IPS operate inline and aim to block traffic based on rules — this is prevention. NSM operates passively and aims at visibility and detection: it retains data even about traffic that already passed the firewall, enabling later analysis and the discovery of attacks that bypassed preventive controls. An IDS (part of NSM) merely alerts without blocking. In practice the layers complement each other: prevention reduces noise, while NSM supplies context and evidence when prevention fails.

How does NSM differ from NDR and SIEM?

NDR (Network Detection and Response) is a newer, commercial evolution of the NSM idea — it combines packet inspection with behavioral detection and machine learning plus automated response. NDR can be seen as a product category that sits within the broader NSM discipline, focused on traffic-based detection.

SIEM aggregates and correlates logs from many sources (hosts, applications, devices), whereas NSM focuses on data taken directly “off the wire.” In a mature SOC, NSM and SIEM work together: network telemetry from NSM feeds SIEM correlation, and SIEM alerts are often verified against NSM PCAP data.

Why does NSM matter for security?

Many adversary techniques show up on the network even when a host stays “quiet” or an EDR (endpoint protection) agent has been disabled — for example lateral movement, covert command-and-control (C2) channels, and data exfiltration. NSM gives you a layer of visibility that does not depend on the endpoint, plus a durable record that is hard for an attacker to erase. It answers the questions that matter in incident response: who talked to whom, for how long, how much data moved, and whether anything left the organization. That is what makes NSM a foundation for threat hunting and forensic analysis.

Learn more

• Data Loss Prevention (DLP) — DLP monitors data flows to detect and prevent sensitive data exfiltration.
• Cloud Security Posture Management (CSPM) — CSPM helps track cloud misconfigurations that NSM may reveal through traffic patterns.
• SaaS Security Posture Management (SSPM) — SSPM secures SaaS settings, while NSM can spot suspicious SaaS traffic and usage.
• Deep Packet Inspection — Deep packet inspection gives NSM detailed visibility into packet contents and protocols.
• North-South vs East-West Traffic — NSM must monitor both north-south and east-west traffic to detect threats across the network.
• Cloud Access Security Broker (CASB) — CASB complements NSM by enforcing cloud access controls and monitoring user activity.
• Asset Discovery — Asset discovery helps NSM identify devices and services that generate network traffic.
• Incident Response Lifecycle — NSM supports incident response by providing detection, investigation, and evidence.