Intrusion detection system (IDS)

Also known as: IDS

A watcher that inspects network traffic or a machine's activity and warns when it spots signs of an attack - without stopping it.

Draft - this entry has not been reviewed yet.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

Decide what the IDS must detect, based on your threat assessment and most valuable systems, and agree who in the SOC or IT operations acts on its alerts and how fast.
Choose where to place it, with network sensors at the internet edge and between key segments such as server, user and OT networks, and host-based agents on critical servers.
Feed each network sensor from a TAP or a SPAN port sized for peak traffic, and check regularly that it sees all the traffic without dropping packets.
Install a maintained rule set, such as Emerging Threats for Suricata or Snort, update it automatically every day and disable rules for protocols you do not use.
Send alerts, together with flow, DNS and TLS metadata, to the SIEM, where they are correlated with logs from endpoints and identity systems.
Tune during the first weeks by tracing the cause of each false positive, writing narrow exceptions and keeping a list of every suppressed rule with its reason.
Write a playbook for the most important alert types that says who triages, how to verify and when to isolate a machine or escalate to incident response.
Test detection at least once a year with harmless test traffic or a purple-team exercise, and review coverage whenever the network or the use of encryption changes.

Common pitfalls

Installing sensors but having nobody who reads and acts on the alerts.
Placing the only sensor at the internet edge, so an attacker moving between internal machines is never seen.
Leaving the default rules untuned until the flood of false alarms makes analysts ignore everything.
Forgetting that encryption hides the payload, so detection must rely on metadata or on decryption at a proxy.

Good guides

NIST SP 800-94 - Guide to Intrusion Detection and Prevention Systems (IDPS)(opens in a new tab) · NIST
CIS Critical Security Controls - Control 13 Network Monitoring and Defense(opens in a new tab) · Center for Internet Security
10 Steps to Cyber Security - Logging and monitoring(opens in a new tab) · NCSC UK
Suricata documentation - Rule Management with Suricata-Update(opens in a new tab) · Open Information Security Foundation

Technical deep dive

The conceptual basis for intrusion detection is Dorothy Denning's 1987 paper "An Intrusion-Detection Model" (IEEE Transactions on Software Engineering), which proposed profiling normal subject behaviour and flagging statistical deviations. NIST SP 800-94 (2007) still provides the standard taxonomy: network-based (NIDS), wireless, network behaviour analysis (flow-based) and host-based (HIDS) systems, using three detection methodologies - signature-based matching, anomaly-based detection against a baseline, and stateful protocol analysis that checks traffic against the expected behaviour of protocols such as HTTP, DNS or SMB.

A NIDS receives a copy of traffic from a switch SPAN/mirror port or a network TAP, so it is passive and cannot add latency or drop packets - but it also cannot prevent anything, and mirrored ports silently drop frames under load. The best-known open-source engines are Snort (1998), Suricata (multi-threaded, maintained by the Open Information Security Foundation) and Zeek, formerly Bro, which is less a signature matcher than a protocol analyser producing rich connection, DNS, HTTP and TLS logs. Rule sets such as Emerging Threats or Snort's Talos rules match on header fields, byte content, protocol-parsed buffers and flow state. Host-based IDS (OSSEC, Wazuh, auditd-based tools) inspect logs, file integrity and system calls on the host itself and overlap heavily with EDR.

Classic weaknesses are well documented. Ptacek and Newsham (1998) showed that differences in IP fragment and TCP segment reassembly between the sensor and the target let attackers insert or evade traffic; modern engines counter this with target-based reassembly policies. Encryption is the larger practical limit: with TLS 1.3 and encrypted SNI/ECH, a NIDS sees little beyond metadata unless traffic is decrypted at a proxy, so detection shifts to JA3/JA4-style fingerprints, certificate metadata, DNS and flow behaviour. Anomaly detection suffers from the base-rate fallacy described by Axelsson (1999): because genuine attacks are rare, even a very low false-positive rate produces far more false alarms than true ones, which is why tuning and alert triage dominate operating cost.

An IDS differs from an IPS in placement and authority - out of band and alert-only versus inline and blocking - and most modern products can run in either mode. Its output is only useful when forwarded to a SIEM or SOC that correlates and acts on it; CIS Controls v8 Control 13 (network monitoring and defense) and ISO/IEC 27002:2022 control 8.16 (monitoring activities) are the usual anchors.

What to learn first

Everything this builds on, foundations first.

Network
→Protocol
→Packet
→Intrusion detection system (IDS)

Relationships

A kind of: Security control
Requires: Network Packet
Don't confuse with: Intrusion prevention system (IPS)
Used with: SIEM Security monitoring

Sources & further reading

Standards & official texts

NIST SP 800-94 - Guide to Intrusion Detection and Prevention Systems (IDPS) · NIST

Course material

Cyber Security Fast Track - Ordliste

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queue Suggest a correction on GitHub This term as JSON

Mentioned in

Personal data

Check yourself

Loading…