An intrusion detection system watches network traffic or host activity for signs of attack and raises alerts, while an intrusion prevention system sits inline and can block what it recognises.
Our take. An intrusion detection system nobody reads is an expensive log. The value is entirely in the tuning and the person on the other end, and an organisation that buys the sensor before it has someone to receive the alerts has bought the second half of a control.
Two questions decide the shape of any such system. Where does it look, and how does it recognise an attack? Network-based sensors read traffic at a chokepoint and see everything that crosses it, including devices nobody installed software on; host-based agents read what happens on one machine and see things encrypted traffic hides from the network. Signature-based detection matches traffic against known patterns and is precise about what it knows and blind to what it does not; anomaly-based detection learns what normal looks like and flags departures, catching novel activity at the cost of flagging every unusual but legitimate event. Mature deployments run both kinds in both places, and the hard part is never the sensor.
Aspect
Detection (IDS)
Prevention (IPS)
Position
Off a mirror port or a tap; sees a copy
Inline; traffic passes through it
On a match
Alerts
Blocks, and alerts
Cost of a false positive
An analyst's time
A legitimate connection dropped
Cost of a false negative
The attack proceeds unseen
The same
Failure mode
Nobody reads the alerts
A rule blocks the business
The hard part is the volume. A sensor with default rules on a busy network produces more alerts in a day than a team can read in a month, and the response is either to tune, which means suppressing rules that fire on legitimate traffic and prioritising the ones that matter, or to stop reading, which is what most organisations do without admitting it. Tuning is continuous, because the network changes; it is skilled, because a suppressed rule is a blind spot; and it is the whole job, because an untuned sensor is indistinguishable from no sensor. The analyst certifications examine exactly that judgement, and the vendor-neutral analyst exam gives detection and its tuning the largest share of its weight.
In practice
Week one: eleven thousand alerts, most from the company's own scanner and a backup job.
Week two: the team stops opening tickets.
Week six, after tuning: a few dozen alerts a day, and the first real finding seen within an hour.
A mid-sized company installs a network sensor with a vendor's default rule set and connects it to a ticketing system. In the first week the sensor raises eleven thousand alerts, most of them a scanning rule firing on the company's own vulnerability scanner and a protocol rule firing on a backup job. The team stops opening the tickets by day three. The redesign starts by whitelisting the scanner and the backup hosts, disables rules for protocols the company does not run, routes the remaining alerts into a system that groups them by source, and gives one analyst two hours a day to work the queue. The alert count falls to a few dozen, and the first real finding, a workstation talking to a known command-and-control address, arrives in week six and is seen within an hour.
A firewall decides whether traffic may pass, by rule, before it does. Intrusion detection watches traffic that was allowed for signs it is malicious anyway. The firewall is the gate; the sensor is the camera behind it.
A SIEM collects and correlates events from many sources, including intrusion sensors. The sensor produces alerts about traffic; the SIEM is where those alerts meet the logs that give them context.
The intrusion detection system is a tool; the security operations centre is the team and process that reads it. One without the other is either an unread log or analysts with nothing to read.
Key takeaways
→Network sensors see everything at a chokepoint; host agents see inside the encryption. Run both.
→Signatures are precise and blind to the new; anomalies catch the new and flag the merely unusual.
→Tuning is continuous, skilled, and the whole job; an untuned sensor is no sensor.
Certifications that test this
Vendor exams whose syllabus covers this concept — facts, cost and a preparation path on each page.
A rotating selection from the course directory, drawn from the subcategories where this concept is taught rather than picked for it. Details, price and the provider link are on the course page.
Get certified with Salesforce Data Cloud Consultant certification by practicing actual exam type questions. This Course…
Udemy
FAQ
Should I deploy detection or prevention?
Detection first, until the rules are tuned, because an inline system blocking on an untuned rule set stops legitimate traffic and gets switched off. Move well-understood, high-confidence rules to blocking once you trust them, and leave the rest alerting.
Does encryption blind a network sensor?
Largely, for the content of connections, which is most of them now. It still sees who talks to whom, how often and how much, which is enough for a great deal of detection. Host-based agents see the content after decryption, which is why the two are paired.
How much of this does a small organisation need?
Less than the vendors suggest. Endpoint detection on every device, logs from the identity provider and the firewall into something searchable, and a person who looks at them covers most of the value. A dedicated network sensor comes after those, not before.
Sources
The primary text this definition rests on. Read it before you trust ours.