Network Security Monitoring (NSM) is the practice of continuously collecting, analyzing, and responding to network traffic data in order to detect threats, investigate incidents, and maintain situational awareness across an organization's infrastructure. The mission exists because attackers must traverse networks to accomplish their objectives, and that traversal leaves evidence. NSM converts that evidence into actionable intelligence before damage compounds. Without persistent visibility into what crosses network boundaries and moves laterally between systems, security teams operate blind, responding only after business impact has already occurred. SPH-R05 defines the structured execution of NSM capability from sensor deployment through analyst workflow, ensuring that visibility is continuous, documented, and operationally useful rather than aspirational.
---
Network Security Monitoring is the disciplined collection and analysis of network-based data for the purpose of detecting and investigating security events. It encompasses full packet capture, flow data (NetFlow, IPFIX, sFlow), protocol metadata, and alert-driven data produced by intrusion detection systems. The defining characteristic of NSM is that it produces evidence, not just alerts. An alert tells you something may have happened; NSM provides the supporting data to confirm, enrich, and investigate that something.
NSM is distinct from several adjacent disciplines that are often conflated with it. It is not the same as a firewall or network access control system, which enforce policy but do not provide investigative data. It is not identical to Security Information and Event Management (SIEM), which aggregates log data from many sources including hosts, applications, and identity systems. NSM is specifically network-centric and traffic-derived. It is also not equivalent to vulnerability scanning, which measures exposure rather than active threats.
NSM should not be confused with simple perimeter monitoring. Modern NSM programs cover internal network segments, cloud-hosted environments, east-west traffic between servers, and encrypted traffic metadata. Limiting visibility to the perimeter firewall is a recognized failure mode that allows threats moving laterally inside the network to go undetected for weeks or months.
Variants within NSM include passive NSM (capturing and analyzing traffic without injecting probe packets), active NSM (using controlled scanning or synthetic transactions to generate comparative baselines), and hybrid approaches that combine both. Cloud-native NSM extends these practices into virtual private cloud environments using traffic mirroring features offered by major providers. Industrial control system environments require specialized NSM tooling that understands operational technology protocols such as Modbus, DNP3, and EtherNet/IP.
---
NSM operates through four integrated functions: collection, detection, analysis, and response. Each function depends on the previous one, and gaps in any layer degrade the overall program.
Collection is the foundation. Sensors are deployed at strategic network chokepoints: internet gateways, internal segment boundaries, connections to cloud workloads, and critical server subnets. These sensors capture raw traffic (when legally and technically feasible), extract session metadata and protocol logs, and forward data to centralized storage. The most effective architectures capture full packet data at high-value chokepoints while using flow data for broader coverage across segments where full capture is cost-prohibitive. Retention periods must be defined in policy, with a minimum of 30 days of session data being a practical baseline for meaningful incident investigation. Collection infrastructure must be sized for peak traffic loads because dropped packets represent lost evidence.
Detection converts collected data into prioritized signals. This happens through multiple mechanisms operating simultaneously. Signature-based detection (as implemented in tools such as Suricata and Snort) matches traffic against known-bad patterns including malware command-and-control indicators, exploit attempts, and protocol violations. Anomaly detection establishes behavioral baselines for hosts, subnets, and applications, and alerts on statistically significant deviations. Threat intelligence integration enriches detection by comparing observed indicators (IP addresses, domains, file hashes transmitted over unencrypted channels) against curated threat feeds. Protocol analysis detects misuse of legitimate protocols, such as DNS tunneling used for data exfiltration or HTTP carrying command-and-control traffic on non-standard ports.
Analysis is the human and automated process of evaluating detections, correlating them with other data sources, and determining whether a genuine incident has occurred. An analyst receiving a detection event for unusual outbound DNS volume from a workstation would pull the associated PCAP, examine the query patterns, cross-reference the destination domains against threat intelligence, and review the host's recent authentication and process execution logs. The analysis workflow must be documented and repeatable. Triage criteria should be defined in advance so that low-fidelity alerts are handled efficiently without consuming analyst capacity that should be reserved for high-confidence detections.
A concrete scenario illustrates the full cycle: an NSM sensor at an organization's data center perimeter detects a spike in outbound DNS query volume from a Windows server that normally generates minimal DNS traffic. The detection triggers an alert based on a threshold anomaly rule. An analyst pulls session logs showing hundreds of queries per minute to a domain registered within the past 48 hours. Full packet data shows that query names are long, randomly structured subdomains, consistent with DNS tunneling for data exfiltration. The analyst pivots to endpoint telemetry and identifies a process executing a known exfiltration tool. Incident response is initiated. Without NSM, this exfiltration could have continued for days, limited only by how much data the attacker decided to take.
Response integration is the final function. NSM does not operate in isolation. Detections feed into incident response workflows, and response actions (blocking an IP, isolating a host, resetting credentials) must be documented with the corresponding NSM evidence that justified the action. This creates an audit trail that serves both operational and compliance purposes.
Configuration considerations are significant. Sensor placement must account for network topology changes as the environment grows. Encrypted traffic (TLS 1.3, for example) cannot be deep-inspected without decryption infrastructure, so programs must compensate by focusing on certificate metadata, connection patterns, and JA3/JA3S fingerprints for encrypted session analysis. Alert tuning is an ongoing operational task, not a one-time configuration. A fresh deployment of Suricata with default rulesets will produce thousands of alerts, many of them low-value. Systematic tuning against the organization's specific environment is required before the program delivers reliable signal.
---
Organizations without functional NSM programs discover breaches late, investigate them poorly, and remediate them incompletely. The security and business consequences are concrete and well-documented.
The primary security impact is detection latency. The Mandiant M-Trends report has consistently shown that organizations without strong network visibility have dwell times measured in months rather than days. An attacker who has been inside a network for 90 days has had time to map the environment, establish multiple persistence mechanisms, exfiltrate sensitive data, and potentially destroy backup systems. Early detection, which NSM enables, compresses the attacker's operational window before significant damage occurs.
The business impact extends beyond the immediate incident. Regulatory frameworks including the Payment Card Industry Data Security Standard, the Health Insurance Portability and Accountability Act, and the General Data Protection Regulation require organizations to demonstrate that they have controls in place to detect unauthorized access to covered data. An organization that suffers a breach and cannot produce network logs showing detection efforts will face regulatory penalties that go beyond what the breach itself would have triggered. Demonstrating NSM capability to auditors is evidence of reasonable security practice.
A well-documented real-world consequence of inadequate NSM is the 2013 Target Corporation breach, in which attackers used a third-party HVAC vendor's credentials to enter the network, moved laterally to point-of-sale systems, and exfiltrated payment card data for approximately 40 million customers over several weeks. Network monitoring alerts were generated by the deployed security tools, but the organizational workflow to act on them was inadequate. The sensors existed; the monitoring program did not. This distinction, between having tools and operating a monitoring program, is a common and costly misconception.
The misconception that firewalls and endpoint protection tools make NSM redundant is operationally dangerous. Firewalls control what is permitted, but permitted traffic can carry threats. Endpoint tools miss network-layer attack techniques and provide no visibility into network infrastructure devices such as routers, switches, and load balancers that cannot run endpoint agents. NSM covers the gaps that all other security layers leave open.
---
CDA approaches SPH-R05 through the Security Posture Health (SPH) domain of the Planetary Defense Model (PDM), under the Autonomous Posture Command (APC) methodology, expressed by the principle: "Your posture adapts. Your hygiene never sleeps."
In practice, this means CDA treats NSM not as a project to complete but as a continuous operational function that requires active management. The APC methodology distinguishes between NSM programs that are technically deployed and those that are operationally effective. CDA's assessment process for SPH-R05 evaluates both dimensions: sensor coverage completeness (what percentage of network segments have monitoring), detection quality (whether the alert pipeline produces actionable signals rather than noise), and analyst workflow maturity (whether detections move through triage and response within defined time objectives).
CDA maps SPH-R05 directly to MITRE ATT&CK tactic coverage. An NSM program that cannot detect Command and Control (TA0011) or Exfiltration (TA0010) traffic patterns is considered incomplete regardless of how many sensors are deployed. CDA uses ATT&CK-aligned detection coverage assessments to identify specific blind spots in a client's NSM deployment and prioritizes remediation based on threat actor TTPs most relevant to the client's industry and geography.
The APC methodology drives continuous improvement through feedback loops. Alert tuning results are reviewed monthly. Sensor coverage is validated after every significant network change. Detection rules are updated when new threat intelligence indicates emerging TTP patterns. This operational rhythm prevents the common failure mode where NSM capability degrades over time as the network evolves but the monitoring infrastructure does not.
CDA also emphasizes that NSM generates evidence that must be preserved correctly. Chain of custody practices for PCAP data, log integrity controls, and defined retention schedules are treated as first-class requirements, not administrative afterthoughts. When an incident requires legal or regulatory response, the integrity of NSM evidence determines whether it can be used effectively.
---
---
---