NDR, EDR, SIEM, XDR, MDR

NDR is security software that watches network traffic, flags behaviour that looks like an attack and gives you the evidence to respond. Firewalls and endpoint agents each see their own device; NDR sees how hosts talk to each other — command-and-control beaconing, scanning, lateral movement and unusual outbound data. NetSenX is a Network Detection and Response (NDR) platform for EU mid-market organisations that detects attacks from network behaviour, explains every alert in plain language and keeps customer data in the EU.

Network detection and response: security tools that analyse the traffic between devices to detect attacker behaviour and support the response to it. Earlier products in the same space were often called network traffic analysis (NTA).

It copies the traffic between your devices to a sensor, learns what is normal for each device, and raises an alert when one starts behaving like an attacker. The copy comes from a mirror port on a switch (SPAN), a small hardware tap on a cable, or an agent on the hosts you choose. The sensor does not need to read the content: timing, volume, destinations, ports, DNS answers and the unencrypted parts of the TLS handshake are enough to see a machine calling an outside server every few minutes, knocking on many internal hosts, logging in to servers it never used, or sending far more data out than usual. The response part is what your team does with the alert: investigate, isolate the host, reset accounts. NetSenX works this way: it never decrypts traffic, it explains every alert in plain language on every plan, and it leaves the response decision to you. It does not see devices that stay silent or segments you do not mirror.

EDR runs on each endpoint and sees the processes and files on that machine. A SIEM collects logs from many systems and correlates them. NDR watches the traffic between devices, so it also covers devices that cannot run an agent and activity that leaves no log. The three complement each other.

EDR watches each computer from the inside, NDR watches the traffic between devices, XDR puts several sources in one console, and MDR is a team that watches the alerts for you. EDR (endpoint detection and response) is software installed on laptops and servers that sees processes, files and memory on that machine. NDR (network detection and response) is a sensor that sees how devices talk to each other, including printers, cameras and machines where no software can be installed. XDR (extended detection and response) is a platform that combines endpoint, e-mail, identity, cloud and sometimes network signals. MDR (managed detection and response) is not software at all but a service: people who read the alerts around the clock and act. You will also see SIEM (security information and event management), which collects logs. NetSenX is an NDR; it works alongside the others and does not replace them.

No. NetSenX adds the network view that endpoint and log tools do not have; it does not replace endpoint protection (EDR), antivirus, log aggregation (SIEM) or a managed detection service (MDR). From the Business plan, alerts can be exported to the SIEM you already run.

Often yes, because EDR and NDR fail in different places. EDR (endpoint detection and response) only sees machines where its agent runs and is healthy. It does not see printers, cameras, phones on the Wi-Fi, building systems, machines or a contractor's laptop, and attackers often switch it off first on the machine they take over. NDR (network detection and response) watches the traffic between devices, so it still sees a compromised host calling an outside server, scanning the network or copying data out, whatever happens to its endpoint agent. If your company is a handful of laptops with everything in the cloud, EDR and good backups may be enough for now. If you have a local network with servers and devices you cannot install anything on, NDR fills the gap. NetSenX raises beaconing, scanning, lateral movement and unusual outbound volume on every plan, Free included, so you can see what it adds on your own network before paying.

Usually EDR first, because protecting each computer against malware is the more basic need. EDR (endpoint detection and response) or good modern antivirus stops much common malware on laptops and servers, and together with multi-factor authentication, prompt updates and tested offline backups it covers the attacks small companies see most. NDR (network detection and response) comes next, and it moves up the list when you have a local network with servers, printers, cameras or production machines that cannot run an agent, when a customer contract or NIS2 asks you to detect and report incidents, or when you want an independent check that the endpoint tool is not the only witness. You do not have to choose on faith: the NetSenX Free plan covers 3 devices with no time limit, so you can put one agent on a mirror port and see what the network shows before spending money.

No, not on its own, although it is a necessary start. Antivirus and endpoint protection stop known malware on the computers where they run. They do not cover a stolen password used to log in from outside, an e-mail asking the accountant to pay a fake invoice, a device where no antivirus can run, or an intruder who uses your own administration tools, which antivirus treats as legitimate. A sensible small-business baseline is multi-factor authentication on e-mail and remote access, updates applied quickly, endpoint protection on every computer, backups kept offline or immutable and tested, and a short written plan of who to call. After that, network monitoring shows what antivirus cannot: one device suddenly talking to many others, calling an outside server every few minutes, or sending a lot of data out at night. NetSenX does this on every plan; it does not replace your antivirus.

Behaviour between machines, which antivirus on a single computer cannot see. Four patterns matter most. Beaconing: a host calling the same outside server at regular intervals, which is how attackers' software receives instructions (command and control, C2). Scanning: one device knocking on many addresses or ports to map your network. Lateral movement: a workstation suddenly opening administrative sessions to servers it never used, often with legitimate tools that antivirus allows. Unusual outbound volume: much more data leaving a host than normal, for example at night. Network detection also covers devices where no antivirus can be installed, such as printers, cameras and machines. NetSenX raises these four on every plan, Free included, and explains each alert in plain language. What it does not see is what happens inside a computer without touching the network, such as a malicious file being opened: that remains the job of antivirus or EDR.

Devices without an agent, agents that have been switched off, and the traffic pattern of an attack spread over several machines. EDR (endpoint detection and response) reports from inside each computer where it runs. It cannot report from a printer, a camera recorder, a NAS, a building controller, a guest phone or an unmanaged laptop someone plugged in. It cannot report from a server where it was uninstalled or tampered with. And each agent sees one host, so a slow pattern that only makes sense across many hosts, such as one machine touching dozens of file shares or quietly calling out every five minutes, is easy to miss. The network sees all of these because every device has to talk to do harm. NetSenX watches that traffic and keeps a network map of the devices it sees. It does not see inside a host, so the two tools complement each other.

The endpoint goes quiet, and the endpoint tool cannot report its own silence, so you need a second witness. Disabling or uninstalling endpoint protection is a common early step for intruders and ransomware operators, using stolen admin rights or a vulnerable driver. From then on, the console may show the machine as offline or simply stop receiving events from it. Two things help. First, treat a silent agent as an incident: set an alert in your EDR console for agents that stop reporting, and check who has the rights to uninstall it. Second, watch the network, which the attacker cannot switch off from that one machine. NetSenX keeps seeing the host's behaviour whatever happens to its EDR: beaconing, scanning, lateral movement and unusual uploads. It does not see the EDR's own state, so it will not tell you that the agent stopped; it tells you what the machine does next.

Make silence itself an alert in your endpoint console, and keep an independent view from the network. Most EDR and antivirus consoles can report agents that have not checked in for a set time; switch that on, send it to a mailbox someone reads, and decide in advance what you do when a server goes quiet: call the owner, check whether it was a planned reinstall, and look at what the machine did on the network. Review once a month the list of machines that should have an agent against the ones that do. Restrict the right to uninstall or pause the agent to a few named accounts with multi-factor authentication. The network view is the second witness: NetSenX does not read your EDR's status, but it keeps flagging the server if it starts beaconing, scanning, moving laterally or sending unusual volumes out, so a silent agent does not mean a silent attack.

No. XDR (extended detection and response) is a platform that combines signals from several sources in one console, while NDR (network detection and response) is one of those possible sources. Most XDR products are built around an endpoint agent and add e-mail, identity and cloud logs; some add network data, some do not. The difference matters for devices that cannot run an agent, such as printers, cameras, building systems, machines and appliances: an XDR built only on endpoints does not see them unless network data is fed in. Before you buy, ask which sources the XDR really ingests in your licence, not in the brochure. NetSenX is an NDR: it watches the traffic between devices and raises beaconing, scanning, lateral movement and unusual outbound volume on every plan, Free included. It does not replace an EDR or an XDR platform, and from the Business plan its alerts can be exported to the SIEM or XDR you already run.

MDR (managed detection and response) is a service in which an outside team watches your security alerts around the clock and responds for you; you need it if nobody in your company can react to an alert at night or at weekends. It is a service, not a tool: the provider still relies on sensors such as EDR (endpoint detection and response) on your computers, and sometimes on network data. Before signing, check what the provider actually does at 03:00. Do they isolate a machine, or only send you an e-mail? Which sensors are included, and who owns the data if you leave? How fast do they respond, in writing? Many small companies combine automated detection with an on-call arrangement with their IT provider instead. NetSenX is software, not an MDR: it detects and explains alerts at any hour, and the alerts go to your team or your IT provider, who decide what to do.

EDR is software, MDR is a service run by people. EDR (endpoint detection and response) is installed on your computers and servers; it watches processes and files, raises alerts and lets an administrator isolate a machine. Someone still has to read those alerts and decide. MDR (managed detection and response) is a provider whose analysts read the alerts for you, around the clock, and respond within an agreed time. Most MDR services bring or require their own EDR, and some also take network or cloud data. So the real question is not EDR or MDR, but who reads the alerts at night. If you have staff or an IT provider on call, EDR plus network detection may be enough. If nobody can react outside office hours, a managed service fills that gap. NetSenX is detection software, not an MDR: it explains each alert so that your team or provider can act on it.

Choose on what happens at 03:00, in writing, not on the brochure. Ask each provider five things. What exactly do you do when you see an attack: call us, isolate the machine, reset accounts, or only open a ticket? What is the response time you commit to in the contract, and how is it measured? Which sensors are included: endpoint only, or also network, e-mail, identity and cloud? Where are our data and your analysts located, and which sub-processors do you use? What do we keep if we leave? Ask for a sample incident report and a reference customer of your size. Check that the price model fits you: per endpoint, per user or per site. A network sensor can sit beside an MDR service: NetSenX alerts can go by e-mail on every plan, by Slack or webhook from the Pro plan and to a SIEM from the Business plan, so a provider can receive them.

Most companies under a few hundred people outsource it or do without a full SOC, because round-the-clock coverage needs several trained people, not one. A SOC (security operations centre) is a team that watches alerts and responds, often around the clock. Building one means hiring and keeping analysts for night and weekend shifts, buying and tuning tools, and writing procedures; for a mid-sized company that is a large fixed cost. Outsourcing to an MDR or MSSP provider turns it into a contract, but you still need someone inside who knows your business and makes decisions. A middle path suits many: automated detection that runs at all hours, alerts explained well enough for a generalist, an on-call arrangement with your IT provider, and an incident-response firm on retainer. NetSenX fits that middle path as detection software; it is not a SOC and nobody at NetSenX watches your alerts for you.

No, but you do need a plan for the hours when that administrator is not there. A SOC (security operations centre) is a team watching alerts around the clock; a company with one administrator cannot staff one and usually does not need to. What it needs is narrower: detection that runs on its own, alerts short and clear enough to act on, a second person who receives them when the admin is away, and a phone number for an incident-response firm. Write down who decides to disconnect a machine or the internet line in an emergency. Keep the basics in place: multi-factor authentication, updates, endpoint protection and offline backups. NetSenX was built for this situation: one agent on a mirror port watches a whole segment, every alert is explained in plain language, and alerts go by e-mail on every plan, so they can reach a deputy or your IT provider as well.

Yes, if the tool asks for minutes a day rather than a dedicated analyst. What makes it work is fewer, clearer alerts and a routine. Decide who reads alerts each morning, who covers holidays, and what counts as urgent enough to call someone at night. Write a one-page response note: how to isolate a computer, who can reset accounts, which provider to call. Review closed alerts once a month to see what was normal and should be marked as such. Choose a tool that explains its alerts, because a bare rule name or score sends a generalist back to raw logs. NetSenX explains every alert in plain language on every plan and lets you mark false positives. It does not remove the need for a person: investigating and containing an incident still falls to your team, your IT provider or an incident-response firm.

To keep logs from many systems in one place, search them and correlate events across them. A SIEM (security information and event management) collects logs from firewalls, servers, directories, VPNs and cloud services, keeps them for a set period, and runs searches that look for suspicious combinations, such as a failed login on the VPN followed by a successful one from another country. Companies use it for three reasons: detection, investigation after the fact, and evidence for auditors and regulators who expect logs to be kept centrally. Its weakness is effort: someone has to choose the sources, write and tune the searches and read the results, or the SIEM becomes an expensive archive. A SIEM sees only what systems log; it does not see traffic that leaves no log. Network detection covers that part, and NetSenX can export its alerts to your SIEM from the Business plan.

Usually not as a first step, unless a customer, an auditor or a regulator explicitly asks for central log retention. A SIEM (security information and event management) earns its cost when someone has time to connect sources, write searches and read the results. A small business often gets more protection, sooner, from multi-factor authentication, endpoint protection, offline backups and detection that runs without log engineering. What you should keep in any case are the logs that matter most for an investigation: sign-ins to e-mail and remote access, firewall and VPN logs, and server security logs, stored somewhere an attacker cannot easily delete them and with correct time on every device. Many cloud services keep sign-in logs for you if you switch it on. NetSenX keeps an audit log on every plan and alert history per plan, and if you later add a SIEM, its alerts can be exported there from the Business plan.

Not necessarily: many small and mid-sized companies get more from NDR plus good endpoint protection than from a SIEM nobody has time to tune. A SIEM (security information and event management) collects and correlates logs from many systems: firewalls, servers, directories, cloud services. It is powerful when someone writes and maintains its searches, and heavy when nobody does. NDR (network detection and response) gives detections from network traffic without log engineering. The two answer different questions: the SIEM tells you who logged in where, NDR tells you what the devices did on the network. You may need a SIEM anyway if an auditor, a customer contract or a regulator expects central log retention, or once you have staff to use it. If you already run one, NDR alerts can feed it: NetSenX has SIEM export from the Business plan, so network detections arrive in the SIEM already explained.

Yes, most network detection tools can, and it is usually better than sending raw network logs. A SIEM (security information and event management) that receives explained network alerts gains a view it otherwise lacks, without the storage cost and noise of every connection record. Before connecting, decide which alert levels should go to the SIEM, who reads them there, and how the two tools share a host name or address so that alerts can be matched with log events. With NetSenX, SIEM export is included from the Business plan. On the Pro plan, alerts can also leave through the API, Slack or a webhook, and on every plan they are sent by e-mail and kept in the dashboard for the alert history of your plan. Exporting does not change what NetSenX sees: it remains network behaviour, never the content of encrypted sessions.

A signature-based IDS matches traffic against known attack patterns; NetSenX scores how each host behaves, so a new malware variant without a signature still leaves a trail. Every alert lists, in plain language, the network features that drove its score (SHAP values). NetSenX works alongside your IDS, EDR and SIEM — it does not replace them.

An IDS or IPS matches traffic against known attack patterns; NDR looks at how each device behaves over time. An IDS (intrusion detection system) raises an alert when traffic matches a signature, such as a known exploit or malware pattern. An IPS (intrusion prevention system) does the same and can drop the matching traffic, usually as part of a firewall. Both are good at known threats and weaker when an attacker uses legitimate tools or a new variant with no signature. NDR (network detection and response) learns what is normal for each host and flags deviations: new peers, regular call-outs, scanning, unusual volumes. Many companies run both. NetSenX is an NDR: it scores host behaviour, explains each alert in plain language, and does not drop or block traffic, so it can run beside your firewall's IPS without changing your network path.

A firewall decides which connections are allowed; NDR watches what happens inside the connections that were allowed. A firewall sits at the edge of the network, or between segments, and enforces rules: this address may reach that server on this port, everything else is refused. It is essential, but an attacker who gets in through a phishing e-mail or a stolen password uses connections the firewall permits, and most firewalls do not watch traffic between devices on the same segment at all. NDR (network detection and response) gets a copy of the traffic and looks for behaviour: a workstation that suddenly talks to many servers, a host calling an outside address every few minutes, data leaving at night. You need both. NetSenX does not filter or block anything; it alerts and explains, and you or your firewall act on the alert.

NetFlow monitoring records who talked to whom, network traffic analysis studies those records, and NDR adds detection and response on top. NetFlow and similar formats are summaries that routers and switches export for each connection: addresses, ports, start time, bytes and packets. Monitoring tools turn them into bandwidth graphs and top-talker lists, which is useful for capacity and troubleshooting but leaves the security judgement to you. Network traffic analysis (NTA) was the earlier name for tools that looked at traffic for security purposes. NDR (network detection and response) is the current name: it learns what is normal per host, raises alerts on attacker behaviour and supports the response with evidence. Flow summaries alone miss details such as DNS answers or the TLS handshake. NetSenX reads its own copy of the traffic from an agent or a mirror port rather than relying only on exported flow records.

Neither is better on its own: signatures are precise for known threats, behavioural methods catch what has no signature yet, and good tools use both. A signature matches something already known, such as a malware fingerprint or an exploit string, so it rarely raises a false alarm but misses new variants and attackers who use your own administration tools. Behavioural or machine-learning detection compares activity with what is normal and can see a new tool calling home, but it needs time to learn your network and it must explain itself, or every alert becomes a mystery. Be careful with the label: ask a vendor what the model actually looks at, how it reduces false positives on your data, and whether each alert says why it fired. NetSenX scores host behaviour and explains every alert in plain language. It does not quote a false-positive rate it cannot back with your own data.

A mirror port or tap is usually better for a whole office segment, and agents are better for specific servers or places where you cannot mirror traffic. With SPAN (a switch setting that copies traffic to one port) or a TAP (a small device that copies traffic on a cable), one sensor sees every device on the segment, including printers, cameras and machines, without installing anything on them. It needs a managed switch or a tap, and it only sees the segments you mirror. An agent on a host sees that host's own traffic wherever it is, including servers in a data centre or cloud where you cannot mirror anything. Many companies combine the two. NetSenX supports both: an agent on a SPAN or TAP port counts as one device for the whole segment, and agents run on Linux and macOS. TLS fingerprinting needs packet capture, which the basic macOS mode does not do.

Yes, within limits. Timing, volume, destinations and the TLS handshake stay visible without decryption, and they are enough to spot beaconing, scanning or unusual uploads. Without decryption, no NDR can read the content of a session. NetSenX never decrypts.

Partly: it sees your devices' connections to cloud and SaaS services, not what happens inside those services. From the office network, NDR (network detection and response) can see which hosts connect to which cloud providers, how often and how much data they send, so a server uploading a large archive to an unknown storage account at night stands out. What it cannot see is activity inside the SaaS application itself: a mailbox rule created in your e-mail service, a file shared publicly from a cloud drive, or a login from a stolen password in another country. Those live in the provider's audit and sign-in logs, which you should switch on and review. Traffic from laptops at home that never crosses your network is also out of view unless an agent runs on them. NetSenX shows cloud destinations in a review queue on the network map on every plan, and unusual outbound volume as an alert.

It depends on the product; NetSenX alerts and recommends, and does not block traffic by itself. Some NDR products sit in the traffic path or integrate with firewalls to cut connections automatically. That can stop an attack, and it can also stop your production line on a false positive, so automated blocking is usually limited to narrow, well-tested cases. A sensor on a mirror port, which is how most NDR is deployed, only receives a copy of the traffic and cannot block anything itself; the response goes through your firewall, switch, endpoint tool or a person. NetSenX explains each alert, offers manual response actions from the Starter plan and automatic response recommendations from the Pro plan, and never blocks traffic on its own. Deciding to isolate a machine, block an address or reset accounts stays with your team, which is also why every action is kept in the audit log.

Watch the network for a while and record every device that sends traffic, with the names it announces, its address and whom it talks to. Devices reveal themselves when they ask for an address (DHCP), resolve names (DNS), announce themselves on the local network, or connect to servers. A sensor on a mirror port collects this passively, without scanning anything, which matters for fragile devices such as printers, cameras and machines. Compare the result with the list you think you have: unknown devices, forgotten servers and personal equipment usually appear in the first days. Then give each device an owner and decide whether it belongs. NetSenX keeps a network map on every plan, Free included: devices seen on the LAN, their announced names, first and last seen, and who talks to whom. It only sees segments you monitor, and a device that never sends traffic does not appear.

No. A passive network map only knows devices that send something on a monitored segment, so a completely silent device stays invisible. In practice very few devices are fully silent: most request an address, resolve names, look for updates or answer the network now and then, so they appear within hours or days. The ones that do not are usually switched off, unplugged, on a segment you do not mirror, or deliberately quiet. To close that gap, compare the map with other sources: the switch's table of connected ports, the DHCP server's leases, your purchase records and a walk through the building. Active scanning finds silent devices that answer when asked, but use it carefully on printers and industrial equipment. NetSenX builds its network map passively on every plan and never probes devices, which is safe for fragile equipment and means a silent device is not on the map.

Small teams rarely have time to read firewall and DNS logs every day, and attackers who use legitimate administration tools leave few traces elsewhere. NDR watches the traffic continuously and raises what deviates. NetSenX has a Free plan, so a team can try it on its own network before paying.

Ask how it is priced, what it needs from you, what it cannot see, and how it proves an alert, and test it on your own network. Price: is it published, and what counts as a unit, a device, a sensor or a gigabit? Deployment: does it need hardware on every site, or can one sensor on a mirror port cover a segment? Visibility: which segments, encrypted traffic, cloud and remote laptops; ask the vendor to say plainly what is out of view. Alerts: does each one explain why it fired, and in words your team understands? False positives: how is the rate measured, and on whose data? Data: where is it stored, who are the sub-processors, what do you get back when you leave? Response: does it block, or only alert? Then run it for a few weeks on real traffic. NetSenX publishes its prices and has a Free plan with no time limit for that test.

Generate harmless versions of the behaviour it should catch, on a test host you own, and check what alerts appear and how quickly. Start simple and announce the test to anyone who might react. A port scan from a spare laptop against your own subnet should be flagged. A script that calls the same outside test server every few minutes for an hour imitates beaconing. Copying a large archive from a test server to an external storage account at night imitates data theft. Write down what you did, when, and what the tool raised, then review the alert text: would a colleague know what to do? Repeat after major changes to the network or the tool. Breach and attack simulation (BAS) automates such tests. NetSenX includes BAS from the Business plan; on every plan you can run manual tests like these against the detections it raises.

Breach and attack simulation (BAS) is software that safely imitates attacker behaviour on your network so you can check whether your security tools notice it. Instead of waiting for a real attack or a yearly penetration test, it runs controlled scenarios, such as a scan, a call-out to a test server or a simulated data transfer, and records which ones your tools detected. A mid-sized company benefits most when it must show auditors or customers that detection works, not only that it is installed, or after changing its network or tools. If you have no detection tool yet, buy detection first: a simulation that nobody detects proves only that. A penetration test by people still finds things BAS does not, such as weak passwords or misconfigurations. NetSenX includes breach and attack simulation from the Business plan, so you can test its own detections.

Run a small test after every significant change and a fuller one at least once a quarter, plus before an audit. Detection breaks quietly: a switch is replaced and the mirror port is not set up again, an agent stops after an update, a segment is added that nobody monitors. A short test after each change catches this. A quarterly round of the main scenarios, such as scanning, beaconing, lateral movement and a large outbound transfer, shows whether anything has drifted, and gives you dated evidence for auditors, insurers and customers. Keep a simple log: date, scenario, expected alert, actual alert, time to alert, follow-up. Tell your team and any provider before you test, so nobody isolates a machine by mistake. NetSenX includes breach and attack simulation from the Business plan; on other plans you can run the same scenarios by hand.