CY6: Logging, monitoring and detection
Tuning: false alarms and missed attacks
🎯You'll be able to
Adjust rules using a baseline of normal activity, so ordinary work stays quiet and unusual activity stands out.
🏠The everyday picture
A smoke alarm placed above the kitchen stove goes off every time someone cooks, until the family takes its battery out. Moving it to the corridor keeps it useful.
📘What it really is
- False positives: alerts on normal activity. Too many, and people stop reading alerts (alert fatigue).
- False negatives: attacks the rules miss. Rules that are too loose or too strict both cause harm.
-
Baselines: learn what normal looks like. Many staff behind one office address make several typos a day; a doctor views perhaps 30 to 60 records in a busy morning. These figures are illustrative.
-
Shared addresses: a clinic's staff may share one public address (NAT). Per-address rules must allow for that, or every Monday morning looks like an attack.
-
Bulk access: one account viewing more than 200 different patient records in 10 minutes isn't normal for anyone at the clinic. Count distinct records, not page views.
-
Test rules against known data: the kit's logs contain both attacks and ordinary activity, and the tests check both sides.
- Keep notes on why each threshold was chosen.
📝A worked example
Input: the clinic's office address 198.51.100.10 makes 27 failed logins across the week, all typos followed by success.
Steps:
- Check the guessing rule: 10 in 5 minutes. The clinic's typos are spread over days, so they never reach 10 in a window.
- Check the takeover rule: none of the clinic's successes follows 5 failures for the same account within 30 minutes.
- Check the bulk rule against the busiest doctor's morning: well under 200 distinct records in any 10 minutes.
Expected output: no alerts for the clinic's ordinary work, while the real incidents still raise alerts.
🌍Where it's used
- SOC teams review their noisiest rules every week.
- Fraud teams measure false positives because each one inconveniences a customer.
- Detection engineers keep tests for each rule, like code.
📝Case scenario
A hospital's rule alerted whenever anyone opened more than 20 records an hour. Emergency doctors triggered it every shift, and the alerts were ignored. When a clerk later copied 3,000 records, the alert looked like all the others. Changing to distinct records in a short window, with a much higher limit, made the real case stand out.
🖱️Try it
Look at tests/test_detection.py in the kit and find the test that checks ordinary activity raises nothing. Success: you can name
which address it uses and why.
⚠️Common mistakes
- Tuning by turning rules off. Sign: noisy rules disabled. Fix: adjust thresholds, windows or grouping.
- Counting page views instead of distinct records. Sign: refreshing a page looks like bulk access. Fix: count distinct records.
- No record of why. Sign: thresholds nobody can explain. Fix: write a line per threshold.
🛠️For your project
Tests 4 and 7 check that the clinic's typos raise nothing and that a busy doctor isn't flagged, while the bulk viewing in the kit's incident is.
✅Quick check
What is alert fatigue?
Show the answer
Ignoring alerts because too many of them are false.
Why count distinct records for bulk access?
Show the answer
So refreshing or revisiting the same record doesn't look like bulk viewing.