# Network Detection and Response Architecture
Network Detection and Response (NDR) architecture is the structured design framework that governs how an organization deploys, connects, and operates network-layer detection and response capabilities across its environment. It exists because perimeter-based security models consistently fail to detect lateral movement, command-and-control communication, and data exfiltration once an attacker establishes a foothold inside the network. NDR architecture solves the visibility gap between endpoint telemetry and log-based detection by treating the network itself as a continuous, high-fidelity source of behavioral evidence.
The architecture encompasses sensor placement strategies, data collection protocols, analytics engines, storage tiers, orchestration layers, and automated response mechanisms. It is not merely a product deployment but a design discipline that defines where traffic is observed, how signals are enriched, which response actions are automated, and how the system integrates with SIEM, SOAR, and endpoint detection platforms.
NDR architecture differs fundamentally from traditional network security monitoring, which focuses on packet capture and retrospective analysis. It also differs from intrusion detection systems, which apply signature-based rules without the behavioral baselining and machine-learning components that characterize modern threat detection. The architecture treats network traffic as a real-time data source for security operations, not just a forensic artifact.
Three architectural variants address different operational requirements. Inline NDR deploys sensors in the traffic path, enabling active blocking and traffic shaping alongside detection. Out-of-band NDR uses passive taps or SPAN ports to observe traffic without affecting network performance, prioritizing comprehensive visibility over enforcement capability. Hybrid NDR combines both approaches, using passive sensors for broad coverage and selective inline deployment at critical network segments such as data center east-west traffic, industrial control system boundaries, or cloud egress points.
NDR architecture operates through five interconnected stages: collection, processing, detection, investigation, and response. Each stage has specific technical requirements and design decisions that determine whether the overall system performs effectively under real operational conditions.
Collection Architecture
The foundation begins with strategic sensor placement. Physical appliances, virtual machines, or software agents capture raw packets or flow records from network chokepoints. Optimal placement targets core switching fabric, data center interconnects, internet egress points, remote access gateways, and cloud transit connections. A typical enterprise deployment requires sensors at fifteen to forty locations to achieve comprehensive coverage without blind spots.
Sensors forward data to centralized analysis platforms using bandwidth-conscious protocols. Packet-based sensors either store full captures locally while forwarding metadata centrally, or forward only parsed protocol fields and extracted features to reduce bandwidth consumption. Flow-based collection using NetFlow, IPFIX, or sFlow trades packet-level fidelity for scalability, making it suitable for high-bandwidth core links where full packet capture would be cost-prohibitive.
Data transport from sensors to the analysis platform requires careful network design. Dedicated management networks prevent sensor traffic from competing with production workloads. Compression and sampling reduce bandwidth requirements while preserving detection fidelity. Regional collection points aggregate sensor data before forwarding to central analysis, reducing WAN utilization for geographically distributed organizations.
Processing and Enrichment
Collected data passes through processing layers that perform protocol decoding, session reconstruction, metadata extraction, and contextual enrichment. The system correlates individual packets into sessions, identifies application protocols through deep packet inspection or behavioral fingerprinting, and extracts observable features such as DNS query names, TLS certificate subjects, HTTP headers, and file transfer metadata.
Enrichment engines add context from external sources: threat intelligence feeds, internal asset inventories, user identity directories, and vulnerability scanners. This transforms raw network observations into structured security telemetry with business context. A DNS query to a suspicious domain becomes an alert that includes the requesting host's owner, software inventory, patch status, and previous security incidents.
Session reconstruction handles complex protocols that span multiple connections or use dynamic ports. The system tracks FTP control and data channels, correlates HTTP requests with responses across keep-alive connections, and reconstructs file transfers that span multiple TCP sessions. This capability is essential for detecting attacks that fragment malicious activity across multiple network flows.
Detection Methods
The detection layer applies multiple analytic approaches simultaneously. Signature-based detection matches known indicators from threat intelligence: command-and-control IP addresses, malicious domain names, file hashes in HTTP downloads, or protocol-specific attack patterns. These rules provide high-confidence detection of known threats with minimal false positives.
Behavioral analytics establish baselines of normal activity per host, subnet, protocol, and time period, then flag statistical deviations. Examples include workstations initiating SSH connections to external networks, servers scanning internal hosts on administrative ports, or encrypted tunnels with unusual data volumes. The system learns organizational communication patterns over weeks or months, then identifies anomalies that would be invisible to signature-based rules.
Machine learning models detect subtle patterns that rule-based systems miss. Beaconing detection identifies command-and-control traffic with irregular timing designed to evade threshold-based rules. Protocol anomaly detection flags malformed packets or unusual protocol usage that may indicate exploitation attempts. Clustering algorithms group similar behaviors to identify coordinated attacks across multiple hosts.
Investigation Capabilities
Alerts trigger investigation workflows supported by historical telemetry storage. Analysts query stored network data to determine incident scope: which hosts communicated with suspicious destinations, whether lateral movement followed initial compromise, and whether data left the environment. Effective architectures retain 30 to 90 days of detailed network metadata and 7 to 14 days of full packet captures for critical network segments.
Investigation tools provide pivoting capabilities that follow attack chains across the network. An analyst investigating a suspicious DNS query can immediately view all traffic from the requesting host, identify other hosts that queried the same domain, and examine file transfers or encrypted sessions that followed the initial query. This capability reduces mean time to understand from hours to minutes.
Integration with SIEM platforms enriches network findings with correlated log data from endpoints, identity providers, and cloud services. The investigation interface presents a unified timeline that shows network events alongside authentication logs, process execution events, and file system changes.
Response and Orchestration
The response layer executes containment and remediation actions based on detection confidence and organizational risk tolerance. Automated responses handle high-confidence, low-ambiguity scenarios: blocking known-malicious IP addresses at perimeter firewalls, quarantining hosts that exhibit clear signs of compromise, or triggering SOAR playbooks that collect forensic artifacts and notify incident response teams.
Response actions integrate with existing security infrastructure through APIs and standard protocols. The system can instruct firewalls to block specific connections, direct NAC systems to isolate compromised hosts, trigger EDR platforms to collect detailed host forensics, or update DNS sinkholes to redirect malicious domains. Response timing is critical; automated blocking actions execute within seconds of detection, while human-in-the-loop approvals are reserved for high-impact containment decisions.
Encrypted Traffic Analysis
Modern NDR architectures must address the reality that approximately 90 percent of enterprise network traffic is encrypted. Detection approaches for encrypted traffic include TLS certificate analysis, JA3/JA3S handshake fingerprinting, encrypted session metadata analysis, and correlation with DNS queries. Some organizations deploy TLS inspection proxies to decrypt traffic for analysis, but this approach requires careful certificate management, performance optimization, and privacy controls.
DNS remains largely unencrypted in most environments and provides valuable context for encrypted sessions. The system correlates DNS queries with subsequent TLS connections to the resolved IP addresses, enabling detection of connections to malicious domains even when the actual data transfer is encrypted. Behavioral analysis of encrypted session timing, size, and frequency patterns can identify command-and-control traffic or data exfiltration without requiring payload inspection.
Network-based detection addresses attack techniques that consistently evade other security controls. Advanced persistent threat groups, ransomware operators, and insider threats all depend on network communication at critical points in their attack chains. Credential theft requires authentication traffic. Lateral movement requires internal network communication. Command-and-control operations require external connectivity. Data exfiltration requires moving large data volumes out of the environment. An architecture that monitors network behavior consistently catches attacks that endpoint agents miss.
The 2020 SolarWinds supply chain compromise demonstrates the value of network detection. Attackers used legitimate software update infrastructure to distribute the SUNBURST backdoor, then established command-and-control communication using DNS and HTTPS traffic designed to blend with normal SolarWinds telemetry. Organizations that detected the compromise early were those with NDR capabilities that identified unusual DNS query patterns, unexpected external communication from Orion servers, and behavioral anomalies in encrypted session timing. Organizations without network visibility discovered the compromise weeks or months later, often only after external notification.
Without effective NDR architecture, organizations face predictable failure modes. Mean time to detect network-based threats increases from days to months. Lateral movement proceeds unobserved, allowing attackers to establish persistence across multiple systems before generating any alerts. Data exfiltration events are discovered through external notification rather than internal detection. The 2021 Ransomware Task Force report found that organizations with comprehensive network monitoring detected ransomware deployment 76 percent faster than those relying primarily on endpoint detection.
Common misconceptions limit NDR adoption and effectiveness. Many organizations assume that cloud migration eliminates the need for network detection, but cloud environments introduce new traffic patterns, protocols, and attack techniques that require adapted monitoring approaches. Others believe that NDR requires dedicated security operations centers with expert analysts, but modern platforms produce prioritized, contextualized alerts that smaller security teams can handle effectively, especially when combined with automated response capabilities.
The business impact of network visibility gaps extends beyond security metrics. Regulatory frameworks increasingly expect organizations to demonstrate comprehensive monitoring capabilities. The European Union's NIS2 Directive explicitly requires critical infrastructure operators to maintain continuous network monitoring. Cyber insurance policies now include network detection capability requirements, and coverage exclusions often apply to attacks that exploited unmonitored network segments.
CDA approaches NDR architecture through two domains of the Planetary Defense Model: Security Posture and Hygiene (SPH) and Threat Intelligence and Detection (TID). The SPH domain treats network visibility as a measurable hygiene requirement with specific coverage targets, sensor health metrics, and baseline maintenance procedures. The TID domain ensures that detection rules align with organization-specific threat intelligence and validated attack scenarios.
Within the SPH framework, CDA operationalizes the Autonomous Posture Command principle: "Your posture adapts. Your hygiene never sleeps." Network visibility baseline establishment precedes all detection tuning. CDA requires clients to complete a comprehensive coverage audit before activating any detection rules. This audit maps every traffic chokepoint, documents coverage gaps, and establishes quantitative targets (typically 95 percent of east-west traffic and 100 percent of north-south traffic).
The coverage audit process differs from conventional NDR deployments that focus immediately on alert tuning. CDA mandates four weeks of baseline data collection to understand normal traffic patterns before enabling behavioral detection. Generic detection thresholds applied to unbased environments produce alert fatigue that erodes analyst confidence. Baseline-driven detection reduces false positives by 60 to 80 percent compared to out-of-box configurations.
CDA's TID domain integration maps detection rules to MITRE ATT&CK techniques relevant to each organization's specific threat profile. A financial services client faces different adversary tactics than a manufacturing company; the NDR detection logic must reflect that specificity through targeted rule sets, not generic threat feeds. Quarterly red team exercises validate detection effectiveness against realistic attack scenarios, with results feeding back into architecture improvements.
Two operational requirements distinguish CDA's approach from standard NDR implementations. First, documented response playbooks must exist for every active detection rule before production deployment. Alerts without tested response procedures create analyst burden without security value. Second, response timing requirements drive architecture design decisions. Automated containment actions must execute within 30 seconds of high-confidence detection; this requirement influences sensor placement, network paths, and integration protocols.
CDA measures NDR architecture effectiveness through adversary simulation rather than alert volume metrics. Monthly tabletop exercises and quarterly hands-on-keyboard assessments test whether the architecture detects realistic attack scenarios within acceptable timeframes. Architecture modifications follow directly from exercise results, treating each assessment as a quality control event rather than a separate validation activity.