CY6: Logging, monitoring and detection
Writing detection rules
🎯You'll be able to
Write rules with thresholds and time windows for guessing, account takeover, injection attempts and admin changes.
🏠The everyday picture
A bank doesn't phone you for every card payment. It calls when five payments happen in ten minutes in two different cities. The rule is a count, a time window and a pattern.
📘What it really is
-
Threshold and window: "10 or more failed logins from one address within 5 minutes". Use a sliding window that drops events older than 5 minutes as new ones arrive.
-
Quiet period: after alerting on an address, don't alert again for it for an hour, or one attack makes a hundred alerts.
-
Sequence rules: "a successful login for an account after 5 or more failures for it in the previous 30 minutes" suggests a password was guessed.
-
Pattern rules: a search query containing a quote followed by
OR,UNION,--or;looks like an attempt to break the database query. Group by address and alert at 3 or more. Raise the severity if any got a server error, which can mean a query broke. -
Change rules: every grant of the admin role is worth an alert. Make it high outside office hours (08:00 to 20:00 IST) or when someone grants it to themselves.
-
Each alert says the rule, severity, time, subject, count and evidence in plain words.
📝A worked example
Input: the kit's login log, which contains 40 failed logins from 203.0.113.45 within a few minutes on 29 October.
Steps:
- For each failed login, add its time to that address's window and drop entries older than 5 minutes.
- When the window holds 10 or more and the address hasn't alerted in the last hour, raise
BRUTE_FORCE. - Continue: the remaining failures fall inside the quiet hour, so no more alerts for that address.
Expected output: one BRUTE_FORCE alert for 203.0.113.45, not 31.
🌍Where it's used
- SOCs run hundreds of rules like these in their SIEM.
- Fraud systems use the same windows for payments.
- Cloud providers alert on new admin grants by default in many services.
📝Case scenario
A college's IT team alerted on every failed login and received 4,000 emails a day. When a real guessing attack happened, the alert was lost among them. A threshold, a window and a quiet period cut alerts to a handful a day, and the next attack was noticed in minutes.
🖱️Try it
Write in plain words a rule for "too many password reset requests for one account". Success: it names a threshold, a window and a quiet period.
⚠️Common mistakes
- Alerting on every event. Sign: thousands of alerts. Fix: thresholds and windows.
- Counting all-time totals. Sign: last month's failures still count. Fix: a sliding window.
- No quiet period. Sign: one attack, dozens of alerts. Fix: suppress repeats for a while.
🛠️For your project
Tests 2, 3, 5 and 6 check the guessing, takeover, admin-change and injection rules against the kit's logs.
✅Quick check
What three parts does a threshold rule usually have?
Show the answer
A count, a time window and what is being counted (grouped by, for example, address).
Why raise severity when injection-like searches got server errors?
Show the answer
An error can mean the input actually broke the query.