NDR vs EDR and SIEM: differences explained by risk and money

Where the confusion starts: “we need NDR”

The phrase “we need NDR” usually appears not because the company has clearly chosen a class of solution. More often something hurts, and the conversation immediately drifts into product names and trendy acronyms. People end up arguing about whether NDR is better than EDR or SIEM, but they don’t answer the main question: which risk are we reducing and how much does it cost.

Behind that request there are almost always grounded business fears: downtime of a critical service, fines after an incident, leakage of customer or internal data, project delays from infrastructure outage. The CFO often asks it like this: “How much will one day of downtime cost us and how quickly will we notice it?” That’s already a conversation about risk and time, not tools.

Explaining cybersecurity in terms of risk means tying technical events to consequences: incident probability, scale of damage, time to detect, time to recover, and who makes decisions in the moment. When these are clear, the choice between solution classes becomes simpler.

It’s useful to pin down in advance what you want to measure and improve:

• time to detect suspicious activity on the network and on hosts
• share of incidents that actually impact the business (downtime, leaks)
• load on the team: how many signals are triaged vs ignored
• cost of ownership: licenses, data storage, people, deployment services
• coverage: which network segments and traffic types are visible at all

Once those goals are defined, you can demand concrete metrics in the pilot and ask questions in advance so the pilot doesn’t end up as “we installed a sensor, got noise, learned nothing.”

Short and practical: what EDR, SIEM and NDR do

Put simply, these are three different vantage points for the same attack. They complement one another but are rarely interchangeable.

What each class actually does

EDR looks at endpoints: laptops, servers, VMs. It sees processes and files, attempts to run malicious code and can react quickly on the host.

SIEM collects events from many sources: AD, mail, VPN, firewalls, applications, EDR. It helps correlate events, conduct investigations and prepare reports for control and audit.

NDR observes the network: who talks to whom, which protocols and behaviors appear in traffic. It’s useful where “the host is quiet” but suspicious movement is already visible on the network.

If you need a cheat sheet:

• EDR — what happens inside the device and rapid response on it
• SIEM — unified picture from logs, correlation and investigations
• NDR — anomalies and behavior in network traffic, especially east-west

Boundaries and blind spots

EDR is weaker where you can’t install an agent: parts of IoT, printers, network gear, some medical devices. SIEM depends on log quality: if a source doesn’t produce the right events or they get filtered out, investigations hit gaps. NDR, meanwhile, struggles with what is fully hidden by encryption without extra methods, and it doesn’t replace control over what happens inside a host process.

Example: an attacker gains access to a server and quietly scans neighboring subnets. EDR may not raise an alarm if there’s no overt malicious process on the host. SIEM will only notice if the right network logs exist and rules are set. NDR is more likely to spot atypical internal scans and strange inter-segment connections even when devices are configured differently.

Which risks are covered by the network, endpoints and logs

Instead of arguing about names, it’s more useful to map tools to risks: what can stop business interruption, lead to a leak or a fine.

EDR is strongest where individual devices matter: an accountant’s laptop, a 1C server, an engineer’s workstation. If a ransomware payload lands on an endpoint, EDR can detect suspicious processes, block execution and isolate the host. This directly reduces downtime risk when each hour of service outage costs money.

NDR sees the network as the roads between systems. It’s particularly useful for lateral movement, remote contractor access, odd connections to internal services or quiet data exfiltration. This reduces the risk of leaks (customer data, trade secrets) and supply-chain issues when the problem originates at a partner.

SIEM is more about evidence and governance: it collects logs, helps analyze incidents, shows auditors that controls exist and speeds regulatory responses. But SIEM depends on the sources: if an event isn’t present, you can’t invent it.

In practice, mapped to risk layers it often looks like this:

• downtime — EDR plus basic network measures, NDR helps catch spread across the network
• data leak — NDR plus SIEM (for correlation), EDR catches some host actions
• sanctions and audits — SIEM as the reporting center, supported by EDR/NDR evidence
• supply chain — NDR for remote sessions control and unusual network paths

Example: a contractor connects remotely and their account is stolen. EDR may see nothing if the attacker operates quietly with legitimate tools. SIEM will spot the login if the log arrived and a rule exists. NDR will show that after login unusual file-shares were accessed and data was sent out, giving reason to act before a full leak.

Turning differences into money: what makes up the budget

People argue about features, but the budget cares about something else: what you pay once and what you pay monthly, and how many people it takes for the system to deliver value.

Split costs into CapEx and OpEx. CapEx appears if you need sensors, dedicated traffic analysis servers or extra storage. OpEx usually includes licenses (by traffic volume, node count or events), support and update subscriptions.

Typically the budget has five clear parts: licenses and support; infrastructure (sensors/mirroring, compute, storage); deployment (design, tuning, integrations, testing); operations (updates, detector quality control, training); and analyst time for triage and investigations.

The most underestimated part is ownership cost via working time. If NDR adds 30 alerts a day and initial triage takes 10 minutes each, that’s 5 hours per day just for first-look checks. With an analyst hourly cost of, say, 12,000 KZT, that’s about 60,000 KZT per day and roughly 1.2 million KZT per month (20 workdays). So when comparing solutions ask not only about “accuracy” but how fast a signal becomes an actionable item.

Also count the price of false positives. Every extra alert consumes SOC time, distracts network admins, causes coordination delays and can stall projects. A sensible financial question before purchase: how many false alerts are you willing to pay for daily and who owns that time.

If the pilot is in a large network, infrastructure costs can be noticeable. For on-prem compute and storage clarify if you have spare capacity or need to buy and maintain it. In Kazakhstan this often ties to local hosting and support requirements — fix such details in the estimate before the pilot, not after the first weeks of operation.

Where NDR is usually stronger: scenarios hidden from EDR and SIEM

NDR sees the network as the road that all devices and services travel on. It tends to win where the attack lives in traffic, not on a single laptop or in neatly collected logs.

NDR’s primary strength is east-west traffic inside the perimeter. Once an attacker is inside they look for access, move between segments and try credentials. EDR might not be on every server, SIEM may not receive the right logs in time, but the network still “remembers” who talked to whom.

Typical scenarios where NDR provides earlier, clearer signals:

• lateral movement: unusual inter-subnet connections, SMB spikes, attempts to access shares and admin resources
• EDR blind spots: unmanaged devices, IoT, printers, medical gear, branch terminals
• SIEM blind spots: incomplete logs, delivery delays, events drowned in noise
• early network anomalies: odd DNS queries, calls to rare domains, new external connections from a normally dormant server
• segmentation breaches: a service suddenly talks to a segment it shouldn’t

Simple example: in a hospital an infection starts from a workstation, then looks for weak devices on the network. EDR catches some activity on PCs, SIEM sees isolated events, but NDR is the first to show the chain: who initiated scanning, which nodes were targeted, where SMB attempts began and which DNS names were used. For the business that translates directly to money: less time investigating and a smaller chance the incident will spread.

Step by step: preparing for an NDR pilot in a corporate network

Pilots fail more often because goals are fuzzy than because the technology is weak. Define 3–5 scenarios you want to see in the network: internal movement between servers, unexpected external connections, port scanning, attempts to exfiltrate data, suspicious DNS queries.

Then choose where to look. One well-chosen segment is better than five random ones. Common choices are the data center (critical services), one office area (user traffic) and, if needed, one branch with weaker controls and more grey channels.

Agree in advance which data you’ll feed in and which constraints are acceptable. Otherwise the comparison will be unfair: one solution sees the needed flow and another doesn’t.

Minimum preparation plan

• Fix the pilot goal and success criteria: which alerts are useful and how fast they should lead to action.
• Define segments and attachment points: is north-south (internet) or east-west (between servers) more important for you?
• Choose sources: SPAN/TAP or mirror, NetFlow/sFlow, DNS/Proxy logs if available.
• Decide how to handle encrypted traffic: without decryption you’ll see metadata, not content.
• Assign owners: InfoSec, network engineers, SOC, system owners and the final decision maker.

A practical check is simple: if your goal is to catch a “quiet” leak from an accounting server, the pilot must include that subnet and internet egress. Otherwise you’re testing luck, not NDR.

If you involve an integrator, clarify who provides SPAN/TAP access, who changes switch configs and who will triage alerts with your team. At GSE.kz, as a systems integrator, these roles are usually fixed in the pilot plan to avoid losing the first week to approvals.

Questions before the pilot: coverage, data and constraints

Pilots often fail not because the product is weak but because you’re looking in the wrong place or missing the right traffic. In terms of risk and money the task is simple: identify which segments would cause the highest damage if compromised, and which data you can realistically collect without breaking privacy or operations.

Start with coverage: which assets must be visible during the pilot. If you attach only an office VLAN and leave critical servers in the dark, you’ll get pretty graphs and little value.

Minimal coverage questions

Phrase them so you end up with a map of “what we see / what we don’t” and why:

• Which segments are mandatory: data center, application servers, user workstations, Wi‑Fi, remote users, contractors, OT/IoT (if present)?
• Which zones and flows are critical: AD, DNS, mail, VPN, RDP/SSH admin, backups, integrations with external APIs?
• Where are visibility chokepoints: NAT, firewalls, proxies, SD‑WAN, SPAN/TAP, cloud egress points?
• What is the expected traffic volume and peaks so the pilot doesn’t hit performance limits?
• What counts as a unit of coverage: percentage of subnets, number of key servers, share of critical flows?

Data, encryption and constraints

Encryption is almost always the main limiter. Clarify whether you expect decryption (TLS inspection) or metadata only (SNI, certificates, directions, frequencies). Sometimes metadata is enough to catch C2 or lateral movement, but not always.

Also record storage and privacy rules: which fields are personal, who can access raw data and reports, retention period and who pays for storage. In a clinic or a bank access to network data may be restricted — that’s normal, but pilot criteria must be adjusted accordingly.

The outcome of these questions is simple: you’ll know in advance where NDR will have quick effect and where expectations are unrealistic due to encryption, lack of mirroring or access rules.

Questions before the pilot: processes, integration and responsibility

If the pilot is “install a sensor and wait for magic”, it will disappoint. Value appears when it’s clear where alerts go, who decides and what the team does in the first 15–60 minutes.

Start with integrations. This is not about “which product is better” but how NDR, EDR and SIEM complement each other in one process. Clarify whether NDR will send alerts to your SIEM, ticketing system and team channels, and in what form: raw events or enriched incidents.

Next — responsibility. Who tunes detectors, handles exclusions and triages false positives: vendor, integrator or your SOC? And what happens when EDR is silent but NDR sees suspicious traffic?

To test operability in the pilot, prepare a minimal response playbook:

• who can isolate a host via EDR and how many minutes it realistically takes
• who and where blocks at the perimeter (FW, proxy, NAC) based on NDR findings
• how forensics is triggered: which artifacts do we collect and who stores them
• how a ticket is opened and who confirms incident closure

Agree in advance how you’ll measure benefit. Record “before” metrics (mean time to detect, share of incidents without an owner, number of manual checks) and “after” (how much detection time decreased, how many incidents reached confirmation). The pilot should end with a short report for leadership: 3–5 findings, impact on risks and what’s required for production (people, integrations, response rules).

If you use an external team, document boundaries: who configures integrations, who supports after the pilot and what level of support is available off hours.

Common mistakes and pitfalls in an NDR pilot

The main trap is deploying NDR “blind.” If your goal is “let’s see what comes up,” you almost certainly get debate about value: many signals, little obvious effect. A working goal can be simple: detect lateral movement in the office network, monitor egress from critical subnets or find unaccounted services.

Second mistake — connecting all segments at once. The pilot becomes noise: tens of thousands of events and the team can’t triage even the top layer. Start with 1–2 zones where damage is highest: the server segment with business systems and one user VLAN where infections often start.

Third trap — data quality. With poor mirroring (bad SPAN/TAP) or misconfigured NetFlow/IPFIX, NDR sees partial sessions, mixes up client/server roles, misses DNS or TLS handshakes. The result is false conclusions like “suspicious volume” or “unknown protocol” when in fact traffic was simply not fully captured.

Fourth — no agreement on response. If alerts arrive and it’s unclear who checks, who closes them and in what timeframe, the pilot won’t prove value.

Before starting, put on one page:

• 2–3 measurable success criteria (e.g., find X unmanaged hosts or reduce initial triage time to Y minutes)
• list of pilot segments and what’s critical in each
• requirements for traffic sources and verification of completeness
• RACI: who does first triage, who investigates, who blocks
• maintenance window and escalation rules to avoid stopping business operations

Example from practice: NDR reports suspicious connections between two internal subnets at night. If there’s no defined owner to react, the signal “lives” until morning and the real problem may spread further across the network.

Quick checklist: what to check in 1–2 weeks

The pilot’s goal is not to “defeat all attacks.” It’s simpler: see whether NDR provides visibility where EDR and SIEM are usually quiet, and how much this will cost in human effort.

In a short window run a few scenarios (preferably in a test segment or agreed maintenance window):

• lateral movement: SMB/RDP/WinRM, unusual "who talks to whom" patterns
• C2: periodic callbacks to external addresses, new domains, odd SNI/JA3
• suspicious DNS: NXDOMAIN spikes, DGA-like domains, abrupt changes for one host
• exfiltration: long outbound sessions, unusual volumes, transfers at odd hours
• scanning: many short connections across ports, subnet sweeps, rising failures

To avoid turning the pilot into a like/dislike debate, fix three metrics:

• time to detect: from event to alert and to reaction
• share of useful signals: how many alerts lead to checks and findings
• asset coverage: which portion of segments and critical systems you actually see

Also check data quality. Packet loss, overloaded SPAN/TAP, clock drift on sensors and NAT hiding sources produce noise or blind spots.

One more operational test — who gets the alert (SOC, InfoSec, duty admin), how it escalates, how long initial triage takes and what is recorded as the result (ticket, false/confirmed, which artifacts are saved). Without this, even a good NDR will look “too noisy.”

A realistic scenario: one incident seen by NDR, EDR and SIEM

An office, a normal workday. An employee opens an attachment and within minutes ransomware appears on the network. Most company PCs have EDR, but an old accounting PC was temporarily swapped and has no agent. The infection started from that machine.

EDR triggers on machines with agents: it sees a suspicious process and a launch attempt from a user folder. But on the uninstrumented PC EDR sees nothing — there’s nothing to collect.

NDR looks at the network and sees what’s visible even without an agent. Almost immediately abnormal SMB activity appears: one host begins mass-opening files on a file server, rapidly enumerating directories and performing many similar operations. For the business this shows up simply as “the document server is slow and people can’t work.”

SIEM ties the evidence together. Logs show:

• atypical authentication under an employee account
• permissions on several folders changed in a short time
• access errors and a spike of events on the file server
• timestamps match the network anomalies NDR raised

The investigation moves faster: NDR shows where it started and where traffic went, EDR provides details for affected endpoints, SIEM corroborates actions by accounts and configuration changes.

Money is easy to calculate. If four to eight hours of downtime in a department halt sales, procurement or payments, losses often exceed the cost of the pilot many times. The pilot pays off if you spot mass encryption early and can disable the infected host and account before the whole network is affected.

Next steps after the pilot: decision and rollout plan

After the pilot, convert “lots of alerts and impressions” into a clear decision quickly. The winner is the option that reduces specific risks for a clear price, not the one with “more features.”

Prepare a one-page summary for InfoSec and the business. It should contain: 2–3 key risks the pilot found or confirmed; an estimate of impact if those risks materialize; deployment cost; quality metrics (number of detected incidents, false positive rate, mean time to detect, real coverage of segments and hosts, what was integrated into SIEM and response).

Then lock down the target architecture. Typically NDR is mandatory where lateral movement and internal traffic matter: data center, server segments, financial systems, healthcare, ICS and other expensive-failure zones. Where endpoint control and host-level investigation are primary, EDR plus disciplined logging to SIEM is often enough.

Rollout plan without stretching for a year

• 0–30 days: confirm sensor placement, access, traffic sources, retention rules and roles.
• 30–60 days: enable integrations (SIEM, EDR, asset inventory), configure basic scenarios and thresholds.
• 60–90 days: exercise 3–5 response playbooks, measure SOC load, finalize KPIs.
• Afterwards: expand coverage by segments and add scenarios matching your threat profile.

At the same time calculate TCO: licenses, sensors and mirroring, storage, analyst time, training and 24/7 support if needed.

If the pilot showed value but you’re limited by network or team resources, consider procuring on-prem infrastructure and local integration. For example, GSE.kz (gse.kz) as a technology vendor and systems integrator in Kazakhstan can help assemble and support the baseline security and DC infrastructure and build integrations into your architecture without locking you to a single vendor.