Detection tells you
something happened.
It rarely tells you what, how far it went, when it started, or whether anything left. Those are evidence questions, and evidence is the thing most security stacks do not keep.
Net-Monitor is an evidence layer, not a detection layer. It does not ship threat signatures, threat-intelligence feeds or IOC matching, and it is not a replacement for an NDR, an EDR or a SIEM. What it does is record every packet crossing the monitored links, around the clock, and keep it — so that when one of those tools raises an alert, the traffic that explains it already exists. That is the gap in most security stacks: plenty of things that say something is wrong, and nothing that can show what actually happened.
Six things detection cannot do on its own.
None of these are criticisms of detection products. They are questions that require the traffic, and detection products do not retain it.
Tell you when it really started
The alert date is when you noticed. Intrusions are routinely found weeks or months after the first foothold, and the true start date changes the scope of everything downstream — including what has to be disclosed.
Answered by searching retained traffic backwards for the first occurrence of the behaviour. If retention is shorter than the dwell time, the question has no answer.
Survive a compromised host
Logs are written by the systems under investigation. A host that has been taken is a poor witness to its own compromise, and logs can be cleared. Traffic is observed independently of the endpoint.
This is the argument that matters most in a serious incident, and it is structural rather than a feature comparison.
Show what left, and how much
The question that determines regulatory obligations is almost always about egress: what went out, where, and how much. That is a volume-and-destination question over a long window.
Answered by outbound volume per host measured against that host's own baseline, over the whole period rather than the last week.
Work through encryption
Content is opaque; the envelope is not. Who talked to whom, when, how often, in which direction, at what size, and whether the handshake succeeded are all visible without decrypting anything.
Beaconing, unusual peer relationships and abnormal egress are patterns in that metadata, not in the payload.
Close a false positive properly
Most alerts are not incidents. Without the traffic, closing one is a judgement call written up as a conclusion. With it, closure is a fact — which is also what makes it defensible later.
The time saved on alerts that turn out to be nothing is usually larger than the time saved on the ones that are real.
Show your working to someone else
Insurers, regulators, auditors and boards ask for evidence rather than conclusions. A retained record with timestamps and documented capture points is an account of what happened.
Increasingly a cyber-insurance question: can you reconstruct the incident, or only describe it.
What this is, and is not
- It is not an NDR, EDR or SIEM, and does not replace one. There are no threat signatures, no threat-intelligence feeds and no IOC matching in the product. Anyone telling you otherwise is selling something else.
- It is continuous packet recording with retention and historical search. Around the clock on the monitored links, retained, and searchable by host, interface, protocol or conversation.
- The anomaly detection is baseline-driven, not signature-driven. It learns your network's own normal and flags departures from it — which catches behaviour no signature describes, and equally will not name a known malware family for you.
- It feeds the tools you already run. A standard open API, so verdicts and evidence land in the SIEM or case-management system your SOC actually works in.
- It runs entirely on-premise. Nothing leaves your perimeter, including on segments with no route to the internet.
Short answers.
Is this an NDR product?
No. NDR products are built around detection — signatures, threat intelligence, behavioural rule libraries mapped to known techniques. Net-Monitor has none of that. It is the evidence layer that sits underneath: continuous packet recording, retention and search, so that when your detection tooling raises something, the traffic that explains it already exists.
Does it use threat intelligence feeds or signatures?
No. There is no signature engine, no IOC matching and no threat-intelligence subscription. The anomaly detection works from a baseline learned from your own traffic, which is a different mechanism with different strengths: it catches behaviour that no published signature describes, and it will not tell you the name of a known malware family.
Then what does it actually add to a SOC?
The ability to answer questions after the fact. When did this start, what did it talk to, did anything leave, is it still here, and can we prove it — all of which need the traffic from the period in question to still exist. Most stacks discover during an incident that it does not.
Can it see inside encrypted traffic?
It does not decrypt, and for most of these questions decryption is unnecessary. The handshake happens in the clear, and the metadata around every session — peers, timing, volume, direction, regularity, TLS version and certificate — carries the patterns that beaconing, lateral movement and exfiltration produce.
How long does traffic need to be retained?
Longer than for performance work. Because intrusions are frequently discovered long after they begin, a retention window shorter than the dwell time means the start of the incident is simply not available. Where the retention line falls is where the investigation stops.
Related questions.
Could you investigate something that started in July?
That is a better question than any feature comparison, and it is answerable in an afternoon. We will look at what you would have to work with.