What NDR is and what it detects
NDR is the category of security solutions that continuously analyzes network traffic to detect and respond to anomalous behavior. It performs behavioral analysis on raw packets and metadata, and it monitors communication between internal systems as well as communication with the outside.
Endpoint detection and response (EDR) detects behavior inside endpoints that have an agent, and log-based security information and event management (SIEM) collects and correlates the logs of each system. NDR covers the area that neither layer observes: devices that cannot take an agent, lateral movement carried out on legitimate accounts, and communication that generates no logs.
NDR adoption has spread because rule-based detection has limits. Matching against known attack patterns does not catch attacks that abuse legitimate tools or attack flows observed for the first time, and NDR fills that gap with behavioral analysis. Behavioral analysis can identify anomalous behavior only after it has learned a baseline of normal behavior. Without a learned baseline, alerts fire even on fluctuations within the normal range, which is why false positives are so common right after deployment.
Coverage expansion and the optimization lag
False positives are a long-standing problem in detection operations, and recent survey data shows the burden has grown rather than shrunk. In a 2025 survey, 73% of respondents selected false positives as a detection challenge (multiple responses allowed), up from 64% the previous year (SANS 2025 Detection and Response Survey). More than 60% also reported experiencing false positives often or very often (same survey). The report reads this as optimization and accuracy failing to keep up with the pace at which detection coverage expanded.
The same pattern appears at NDR deployments. When operation starts with the default detection rules enabled and the initial thresholds left as they are, the grounds for judgment stop at alerts and logs. Alerts and logs show only that something occurred; they do not hold the deviation from the baseline, the content of the transfer, or the grounds for the threat verdict. Raising or lowering thresholds in that state does not resolve the root cause of the false positives. It only moves the alert count for a while.
Four causes of false positives and the action for each
False positives right after deployment fall into the four types in [Table 1]. Each type calls for a different action, so the organization must identify the main type occurring in its environment before optimization begins.
For all four types, alerts and logs cannot tell whether an alert is a false positive. Diagnosing the cause type requires data other than alerts and logs.
Industry trends: three movements in sequence
The 2025 survey cited above also shows three movements tied directly to obtaining data beyond alerts and logs. Respondents rated behavior-based analysis tools as effective (47%), very effective (20%), or not effective (13%) (SANS 2025 Detection and Response Survey). Among organizations that review detection coverage, the share using MITRE ATT&CK as the reference rose to 78% from 74% the previous year, and 53% of organizations use machine learning for threat detection (same survey). The three movements are the shift to behavioral analysis, coverage review against ATT&CK, and the growth of machine learning-based detection.
The three movements are not independent options; they follow one another. Behavioral analysis works only when a baseline exists, and coverage review identifies blind spots only when verdict records exist. Machine learning-based detection and automated alert triage become viable only after an accumulated verdict history has established their reliability. NDR detection policy optimization therefore proceeds in the order shown in [Figure 1]: establish the behavioral baseline, judge false positives against the raw data and optimize the detection rules, then automate alert triage. The output of each stage is the input to the next, so skipping a stage leaves the next one without grounds for adjustment.
Stage 1, establishing the behavioral baseline: a reference for anomaly verdicts
The baseline comes first in [Figure 1] because, until the system has learned normal behavior patterns, adjusting thresholds or adding detection rules does not reduce false positives. Without a definition of the normal state, there is no definition of anomalous behavior either.
Establishing the behavioral baseline means learning activity history by time of day and normal patterns per asset. Behavioral analysis then compares traffic against that baseline to detect anomalies such as abnormal communication on major protocols, large uploads, and session spikes. The learning period differs by environment, so this article does not prescribe a single one. Recurring patterns such as the weekly business cycle and month-end closing must fall within the learning window at least once, or the baseline will not recognize them as normal.
If this stage also puts allowlist registration and an update procedure for configuration changes in place, it resolves three of the four types in [Table 1]. Those three are baseline not yet learned, normal business traffic not registered, and environment changes not reflected. Adjusting the remaining type, detection rule sensitivity set too high, requires checking the raw transaction/session data.
Stage 2, verdicts against the raw data: the grounds for detection rule optimization
Alert counts alone cannot settle how far to raise a threshold, which is what adjusting detection rule sensitivity means. Analysts must judge whether the alerts that disappeared were real false positives, and that verdict requires the raw data of the communication at the moment the alert fired. Logs and metadata record only that a large transfer took place; only reconstructing the raw transaction/session confirms the file transferred, its path, and its destination. In a structure that stores the traffic of the collection segment as full packets, the raw data becomes the definitive evidence for the verdict. It also serves as the grounds for keeping the same false positive from recurring.
Once verdicts accumulate, detection rule optimization begins. The reference for coverage review is converging on MITRE ATT&CK, and the procedure has four steps.
- Coverage mapping: map the current detection rules to ATT&CK tactics and techniques to identify blind spots.
- Prioritization: decide which tactics to reinforce first, based on severity, business impact, and exploitability.
- Behavior-based rule reinforcement: reduce dependence on detection rules and add rules centered on behavior patterns.
- Raw-data verification and iteration: judge the alerts the new rules generate against the raw data, and readjust the rules when a false positive is confirmed.
Coverage mapping is a tool for identifying blind spots, not a metric for detection capability itself. Whether the system detects attacks that bypass the detection rules from context needs separate verification.
Attacks that abuse legitimate tools (living off the land) are where the limits of rule-based detection are clearest. Rules cannot distinguish an attack carried out with the operating system’s own administrative tools from normal administrative work. Only checking deviation from the behavioral baseline together with the content of the raw session can tell whether the tools were abused. Stage 2 is where the raw transaction/session data joins the behavioral baseline established in stage 1, and the two layers first work together.
Stage 3, automated alert triage: widening the autonomous scope step by step
Once verdict data has accumulated, the conditions for automating alert triage hold. When automation triages low-priority alerts and assigns threat scores, analysts can concentrate on high-risk alerts. The practical question is not whether to enable automated triage but how far to trust its results.
The grounds for that trust come from Explainability (XAI). Only when the record holds the features that contributed to a verdict and the path to the threat score can analysts verify the results of automated triage and identify false positives. Automated triage whose decision process analysts cannot check offsets the optimization gains of the two earlier stages: when a false positive occurs, no one can correct its cause.
Once the decision process can be checked, the scope of response automation comes under review; response automation sits one stage after alert triage. For isolation and blocking, where a single false positive can halt normal business, the right structure is semi-autonomous: the AI proposes, and an analyst approves execution. The autonomous scope widens from scenarios in which the likelihood of a false positive is extremely low and the side effects are limited. The level of autonomy for a scenario rises once operating data proves the accuracy of its verdicts.
Four metrics measure optimization results: mean time to detect (MTTD), mean time to respond (MTTR), the share of alerts that are false positives, and the share of manual analysis. Measurement itself is not yet universal. The share of organizations measuring MTTD rose to 56% from 52% the previous year. The share regularly comparing detection and response metrics against industry standards fell to 17% from 23% (SANS 2025 Detection and Response Survey). The size of the improvement depends on the input data and the operating environment, so this article does not give a single figure. The organization measures the four metrics on the same basis at every optimization stage and compares them as a trend.
The optimization order is the input order of three-layer context data
What sets the optimization order is the speed of attacks. In financially motivated attacks (eCrime), the average time from initial access to the start of lateral movement was 29 minutes in 2025 (CrowdStrike 2026 Global Threat Report). Operations in which analysts check alerts one by one cannot keep pace, and what becomes necessary is autonomous security operations that run from detection through analysis and judgment to response. Autonomous judgment needs grounds, and automated triage that relies on alerts and logs alone amounts to automating inference.
Obtaining those grounds in order is what the three stages of detection policy optimization do. The behavioral baseline from stage 1 expresses anomaly as a number relative to normal, and the raw transaction/session data from stage 2 pins down the actual content of the anomalous session. Explainability (XAI) from stage 3 verifies the decision process of automated triage. Each of the three layers, Behavioral Baseline, Raw Transaction/Session, and Explainability (XAI), supplies triage grounds in its own role. When all three are fed in together, the reliability of automated alert triage rises further.
Keeping to the optimization order completes, in order, the input data that autonomous judgment needs. The more complete that input, the more reliable the verdicts of autonomous security operations.
Optimization maturity self-assessment checklist
To diagnose its current stage, an organization judges each of the nine items in [Table 2] as met or not met. The earliest stage with an unmet item is where optimization starts.
The nine items match the outputs of the three stages, so an unmet item is exactly the input to obtain in the next round of optimization.
Frequently asked questions
Q. Which optimization comes first to reduce analyst alert fatigue?
Establishing the behavioral baseline comes before automated alert triage. Enabling automated triage without a baseline passes false positives straight through, and analysts must recheck them. Enable it only after the baseline and raw-data verdicts have accumulated, so that low-priority alerts drop out of automated triage.
Q. How is the baseline maintained in an environment where the network configuration changes often?
Include baseline updates in the configuration change procedure. When a new system goes in or an address range changes, relearn that segment and update the allowlist. Keeping a change history makes it possible to tell later whether the cause of a false positive is the baseline or a detection rule.
