What Is an Intrusion Detection System (IDS)? NIDS vs HIDS

An intrusion detection system (IDS) monitors network traffic or host activity for signs of malicious behavior or policy violations and raises an alert when it finds them. It is, at heart, a burglar alarm for your systems: it tells you something is wrong so your team can respond. What it is not — and this trips people up constantly — is a lock that stops the intruder.

Detection, not prevention

A standard IDS is passive. It observes, analyzes and alerts, but it does not block the traffic it flags. That active, blocking role belongs to an intrusion prevention system (IPS), which is essentially an IDS placed inline — directly in the path of the traffic — so it can drop packets, reset connections or block a source as well as detect them.

The difference is one of placement and consequence. An IDS watches a copy of the traffic out of band, so a mistaken alert costs you only an investigation. An IPS sits in the live path, so a false positive can break legitimate traffic and the device itself becomes a potential bottleneck or point of failure. That trade-off is exactly why many organizations run detection confidently across a broad rule set but enable active prevention only for high-confidence rules. Many modern products are a combined IDS/IPS and can do either per rule.

NIDS versus HIDS: where it watches

IDS deployments divide by where they look.

• Network-based IDS (NIDS). Inspects traffic flowing across a network segment, typically fed by a span (mirror) port or a network tap. Its strength is breadth: from one vantage point it can see activity across many hosts at once — port scans, lateral movement, command-and-control beaconing. Its limits are that it generally cannot see inside encrypted traffic, and it cannot observe anything that never crosses the network, such as a local action on a single machine.
• Host-based IDS (HIDS). Runs on an individual system and watches that host directly — its logs, file integrity, running processes, registry or configuration changes, and local activity. Its strength is depth: it sees things a network sensor cannot, including activity after traffic has been decrypted and purely local changes. Its limit is scope: it only protects the one host it runs on, so you deploy it on the systems that matter most.

The two are complementary rather than competing. NIDS gives you breadth across the network; HIDS gives you depth on critical servers and endpoints. A serious program uses both, which is itself an application of defense in depth — overlapping sensors so a gap in one vantage point is covered by another.

Signature versus anomaly: how it decides

IDS products also differ by how they decide something is suspicious.

• Signature-based detection matches observed activity against a database of known attack patterns, much like signature antivirus. It is precise and quiet for known threats, but blind to anything new or disguised — there is no signature for an attack nobody has catalogued yet.
• Anomaly-based detection builds a baseline of normal behavior and flags significant deviations. It can catch novel or previously unknown attacks that have no signature, but it generates more false positives, because "unusual" is not the same as "malicious." A new business process can look exactly like an attack to a model that has never seen it.

Neither is sufficient alone, so mature deployments combine them: signatures for the known-bad, anomaly detection as a net for the unknown.

Where an IDS sits, and why alerts go to a SIEM

A NIDS is placed at network choke points — the perimeter, between internal segments, in front of sensitive zones — so it sees the traffic that matters. A HIDS is deployed on high-value hosts. But an IDS on its own produces a stream of individual alerts with little wider context, and that stream can be overwhelming.

This is why IDS alerts are almost always forwarded to a SIEM (security information and event management system). The SIEM collects alerts alongside authentication logs, endpoint telemetry, firewall logs and threat intelligence, and correlates them. A lone suspicious packet becomes meaningful when the SIEM ties it to a failed-then-successful login and an unusual process on the same host. Triage, prioritization and investigation happen in the SIEM and the team around it; the IDS simply supplies one valuable input. Thinking through which network paths an attacker would traverse — and therefore where sensors earn their keep — is the kind of reasoning a threat model makes concrete, and an IDS is one of the detection controls that the NIST Cybersecurity Framework Detect function expects you to have.

The limits worth remembering

An IDS is a detection layer, not a standalone defense. It does not stop attacks by itself (that is the IPS), it is only as good as its tuning (a noisy, untuned IDS trains analysts to ignore it), and its alerts are only as useful as the people and process behind them. An alert nobody reads is not detection. Budget for the tuning and the response capacity, not just the sensor.

Frequently asked questions

What is an IDS? A system that monitors network traffic or host activity for malicious behavior or policy violations and raises alerts; it detects and reports but does not block.

How is an IDS different from an IPS? An IDS is passive and out of band, alerting only; an IPS is inline and can actively block, drop or reset malicious traffic, at the risk of disrupting legitimate traffic on a false positive.

What is the difference between NIDS and HIDS? NIDS watches network traffic across many hosts; HIDS runs on a single host and watches its logs, files and processes. NIDS gives breadth, HIDS gives depth.

Signature versus anomaly detection? Signatures match known attack patterns precisely but miss the new; anomaly detection flags deviations from normal and can catch novel attacks but produces more false positives.

How does an IDS work with a SIEM? The IDS produces alerts; the SIEM collects and correlates them with other logs so analysts can triage and investigate in context.