What Is Intrusion Detection System?

An intrusion detection system monitors traffic or host activity for signs of attack and raises alerts. It detects and does not block, which is the whole distinction from an intrusion prevention system — frequently the same product with one setting changed.

Detection-only deployment is often the right first posture: it carries no risk of dropping legitimate traffic, which means it can be deployed quickly and tuned with real data before anything is enforced.

Network and host placement

Network sensors observe traffic from a tap or mirror port and see whatever crosses that point. The placement decision determines the value: a sensor at the internet edge sees inbound and outbound traffic and nothing internal, which means it will not observe lateral movement.

Host-based sensors watch activity on a single system — file integrity, configuration change, log content — and cover what network visibility cannot, including anything inside an encrypted session.

Signatures and anomalies

Signature matching finds known patterns reliably and misses anything novel. Anomaly detection flags deviation from a learned baseline and can find unknown activity, at the cost of false positives whenever the environment changes legitimately.

Both are useful and neither is sufficient. In practice signature content carries the detection load while anomaly output needs considerably more analyst time per alert.

Encryption has narrowed what it sees

Most traffic is now encrypted, which limits content inspection to whatever can be derived from metadata unless the sensor is placed after decryption. That has shifted value toward traffic analysis approaches that work on connection patterns rather than payloads.

It is why endpoint telemetry has become the richer source: on the host, the traffic is plaintext before it is encrypted.

Alert volume is the operational problem

An untuned sensor on a busy link produces more alerts than anyone can read, and the response is either to ignore the console or to disable noisy rules wholesale. Both leave the deployment nominally in place and functionally absent.

Tuning against your own baseline traffic, before expecting anyone to watch the output, is what makes the difference — and it is the step most often compressed to fit a deployment schedule.

It only works if somebody reads it

Detection without response is the recurring failure. A sensor generating excellent alerts into a console nobody watches outside business hours produces the same outcome as no sensor. The response path deserves at least as much attention as the signature configuration.

The compliance driver, and satisfying it honestly

Several frameworks and regulations explicitly require intrusion detection, which means these systems are frequently deployed to satisfy an assessor rather than to detect anything. The result passes the audit and does not detect intrusions.

Where the requirement exists, it is worth treating the deployment as a genuine detection investment rather than evidence production: correct placement, real tuning, and an owner for the alerts. Assessors increasingly ask who reviews the output and what was done about the last alert, which is a harder question than whether the appliance exists.

Where to start

Confirm where your sensors sit and whether any of them observe internal east-west traffic. If they all sit at the perimeter, lateral movement is invisible to them by design.

See intrusion prevention. GuardsArm delivers managed security.