Intrusion Detection & Network Detection and Response

A firewall only sees traffic crossing the perimeter. Once an attacker is inside — moving between servers, scanning for targets, quietly exfiltrating data — that traffic is internal, "east-west" movement a perimeter device was never positioned to watch. The tools built for this sit on the internal network itself, watching raw traffic for the behavior patterns attackers use once they're in.

Some deploy passively, purely to alert; others sit inline and can drop malicious traffic outright. Either way the goal is the same: catch what a firewall structurally cannot, using known attack signatures and behavioral baselines that flag activity no specific rule anticipated.

The problem it solves

Modern attacks rarely stay confined to the first compromised system. After an initial foothold, an attacker typically scans the internal network for reachable hosts, tries stolen credentials against them, and moves toward whatever they're actually after — often over connections that never cross the perimeter firewall at all. Without something watching internal traffic, the entire middle stage of an intrusion goes unobserved.

Compounding this, plenty of attacker traffic matches no known signature — a legitimate admin tool used maliciously, or a technique nobody has catalogued yet. Detection that only matches known patterns misses exactly the intrusions that matter most.

How it works

Sensors positioned at key points in the network — tapped links, mirrored switch ports, or virtual equivalents in cloud environments — capture traffic in full or as detailed connection metadata. That stream is checked against libraries of known attack and exploit signatures, while a behavioral layer baselines what's normal for the environment and flags meaningful deviations, catching threats no signature yet describes.

Detections are enriched with threat intelligence feeds of known-malicious IPs, domains, and file hashes, and stored packet data or metadata lets an analyst reconstruct exactly what happened rather than guessing after the fact. Deployed inline, the system can drop malicious traffic in real time; deployed passively, it only observes and reports, with zero risk of disrupting legitimate traffic if something misfires. Increasingly, these tools also flag suspicious patterns inside encrypted flows without decrypting them at all.

IDS vs IPS

An intrusion detection system (IDS) watches a copy of the traffic and raises an alert — it can't stop anything itself, but also can't accidentally break a legitimate connection. An intrusion prevention system (IPS) sits directly in the traffic path and can drop or block malicious traffic the instant it's recognized, at the cost of becoming a potential point of failure — or disruption — if it blocks something legitimate by mistake.

Most modern products can run in either mode, and the choice often comes down to how much confidence the team has in tuning: an aggressively tuned IPS blocking real traffic causes its own outage, while a purely passive IDS generating alerts nobody acts on protects nothing at all.

If my firewall has IPS, do I need this?

Fair question — most next-generation firewalls now ship a full inline IPS, so the signature-based blocking described here often already runs at your perimeter. But a perimeter IPS and internal detection solve different problems. The firewall only inspects traffic that crosses it, which means it watches the north-south boundary and never sees the east-west movement between internal hosts — exactly the lateral movement, scanning, and credential reuse that define the middle of an intrusion. A dedicated IDS or NDR sits on the internal network to catch that.

There's a deployment difference too. A firewall's IPS runs inline, in the critical path, so it stays fast and conservative by necessity. NDR usually runs out of band on a copy of the traffic, free to do heavier behavioral and encrypted-traffic analysis and to retain packet history for forensics without ever risking a bottleneck. Think of the firewall's IPS as blocking known-bad at the door, and this category as watching how everything behaves once it's inside.

Choosing one

Start with what you actually need visibility into: full east-west coverage across internal segments matters most, since that's precisely the traffic a firewall never sees. Confirm the product can reach the taps or mirrored traffic it needs before evaluating anything else.

Then weigh inline blocking against passive monitoring by team capacity: automatic blocking is valuable when nobody's watching alerts in real time, but demands confidence that legitimate traffic won't get caught in the crossfire. And since most traffic is now encrypted, check how much detection still works without decrypting it — a tool that goes blind on encrypted traffic covers a shrinking fraction of what it's watching.