🔄 Topic

The incident-detection material introduced intrusion detection systems (IDS) and intrusion prevention systems (IPS). Both monitor activity for possible intrusions, but they have different consequences when they decide that something looks dangerous.

🎯 Goal

Understand the operational difference between generating an alert and taking an automated blocking action, and connect that distinction to the way I design security controls.

🛠 What I Studied

An IDS monitors system or network activity, analyses it for patterns or anomalies, and produces an alert for the appropriate people or systems. An IPS includes those detection capabilities but can also take action intended to stop or limit the activity.

The course introduced tools such as Snort, Zeek, Kismet, Sagan, and Suricata as examples in the detection and prevention ecosystem. The important lesson was not that one tool solves every problem. It was that security teams combine monitoring, analysis, investigation, and response.

I compared the two controls using a simple question:

  • If the control is wrong, does the organisation receive an extra investigation?
  • Or does the control interrupt a legitimate user, service, or business process?

An IDS false positive may create noise and consume analyst time. An IPS false positive may block a legitimate connection and create an availability incident. That means an IPS needs especially careful rule tuning, scope, logging, rollback, and exception handling.

🧠 What I Learned

“Automated” does not mean “more secure” in every situation. Prevention can reduce the time between detection and containment, but it also increases the blast radius of a bad decision. Detection gives a human or downstream system a chance to assess context; prevention acts before that assessment is complete.

The right design depends on the asset, the confidence of the signal, the cost of interruption, and the recovery path. A high-confidence rule for a disposable test endpoint is different from an aggressive rule applied to a production payment service.

This also connects to my broader work on fail-closed and least-privilege controls. The control should have only the authority it needs, record what it did, and make it possible to understand and reverse a mistaken action.

⚠️ Limitations

I studied the concepts and tool categories; I did not deploy Snort, Suricata, or another IPS on a production network. The examples here describe the learning model, not a claim that I operated an enterprise intrusion-prevention system.

✅ Takeaway

An alert is a request for investigation. A block is an intervention. Treating those as the same thing hides the risk introduced by automation. Good detection engineering makes the signal useful; good prevention engineering adds scope, evidence, observability, and a safe recovery path.