EXERCISE 2 — Why monitoring without alerting is useless + 5-alert strategy with response actions =================================================================================================== WHY MONITORING WITHOUT ALERTING IS USELESS: SCENARIO: Your company has comprehensive logging. A SIEM ingests and analyzes logs in real time. BUT: there are no alerts configured. The SIEM is passively watching; nobody is looking at it, and when something anomalous happens, nobody is notified. WHAT HAPPENS: - An attacker breaches the system and starts exfiltrating data. - The SIEM detects unusual patterns (1000 downloads from a single user in one hour, 50 failed login attempts from an IP, privilege escalation). - The SIEM does... nothing. No email, no alert, no notification. - The attacker operates for weeks. The data is stolen. - Weeks later, someone casually checks the SIEM dashboard (maybe as part of a post-breach forensics investigation) and says "oh wow, there were lots of anomalies during that period." - The breach detection was DELAYED BY WEEKS. The attacker had weeks to operate and cover tracks. THE PROBLEM: Monitoring is a necessary but NOT SUFFICIENT condition for detection. You must have ALERTING so that when something important happens, a human is notified IMMEDIATELY and can RESPOND. Without alerts: - Anomalies accumulate in logs/dashboards that nobody reads. - Attackers operate undetected for days/weeks. - Breach detection happens during post-mortem forensics, not in real-time. - Damage is amplified; response is too late. ANALOGY: A CCTV camera monitoring a store is useless if the footage is recorded but nobody watches it. A thief steals for hours. Weeks later, forensics check the camera: "The thief was here the whole time!" But the damage was already done. You need someone WATCHING (or a system that detects IMMEDIATELY and alerts a human). --- 5-ALERT STRATEGY FOR AN E-COMMERCE APP (with response actions): ALERT 1: BRUTE-FORCE LOGIN ATTEMPT Threshold: ≥5 failed login attempts from the same IP in 5 minutes (or ≥10 per hour). What it detects: credential-stuffing attacks, brute-force password guessing. Example trigger: IP 203.0.113.99 fails login 7 times in 5 minutes (accounts: alice, bob, charlie, admin, support, seller1, seller2). Response action: 1. On-call security engineer receives alert immediately (email + PagerDuty). 2. Check the IP: is it known (e.g., a company office, a partner)? If yes, check if there's legitimate reason for multiple failed logins (user mistyped password). 3. If suspicious: IP-block the source for 1 hour (rate-limit at the firewall/WAF). 4. Check if any of the attempted accounts were compromised (scan for unexpected login activity post-failure). 5. Escalate to security team if the IP is from a known attack infrastructure (cross-reference against threat intel). ALERT 2: PRIVILEGE ESCALATION / UNAUTHORIZED ADMIN ACTION Threshold: A user with role=customer attempts an action that requires role=admin (e.g., creating a refund, suspending a user, accessing admin APIs). What it detects: authorization bypass, stolen admin tokens, account compromise. Example trigger: user_id=12345 (role: customer, location: Seattle) attempts to refund order ORD-99999 (order owner: different user; order from 2 years ago). Response action: 1. Alert fires immediately. 2. On-call team checks: is this the legitimate user (someone using a compromised token) or an attacker? 3. Check recent auth logs: when did user_id=12345 last log in? From where? Did they use MFA? 4. If suspicious: revoke ALL active sessions for user_id=12345 immediately (force re-authentication). 5. Force password reset for the user and check if their email/phone is compromised. 6. Audit all refunds/actions they attempted; roll back unauthorized ones. ALERT 3: DATA EXFILTRATION / BULK EXPORT Threshold: A single user downloads/exports ≥100 orders, or ≥10GB of data, in a single session. What it detects: insider threats, compromised accounts, automated scraping. Example trigger: user_id=5678 (a customer service rep) exports 500 orders + customer PII in 10 minutes. Response action: 1. On-call team checks: is this legitimate? (Maybe the customer service team does bulk exports for a batch job.) 2. If the export request came through an unexpected API (not the normal UI), that's suspicious. 3. If the user is exporting data they don't normally access (e.g., a customer service rep exporting high-value orders), flag it. 4. Check if the export was sent externally (uploaded to cloud storage, sent via email, etc.) — check DNS/HTTP logs. 5. If exfiltration is confirmed: revoke the user's access, investigate account compromise, notify the data protection officer. 6. Check what data was exported and notify affected users if PII was exposed. ALERT 4: UNUSUAL GEOGRAPHIC/TIMING ACCESS Threshold: User logs in from a new country, or at an unusual time, or immediately after a failed login attempt from a different location. What it detects: account takeover, credential theft/reuse, session hijacking. Example trigger: user_id=9999 (history: Seattle, 9am–5pm logins) suddenly logs in from Moscow at 2 AM. Response action: 1. On-call team checks the session details: same device/browser as before, or different? 2. If different device: likely account compromise. 3. If same device but VPN/proxy in use: could be legitimate (traveling user). 4. Check if the user has unusual activity in that session (accessing admin functions, exporting data). 5. If suspicious: terminate the session, force re-authentication, suggest password change, enable additional MFA. 6. Reach out to the user (email/SMS) to confirm login and alert them. ALERT 5: REPEATED INPUT VALIDATION FAILURES / SQL INJECTION PROBING Threshold: ≥5 SQL-injection patterns detected in API requests from the same IP/user in 10 minutes. What it detects: SQL injection attacks, reconnaissance, automated vulnerability scanning. Example trigger: IP 203.0.113.88 sends requests with payloads like ' OR '1'='1, UNION SELECT, etc. to the /api/search endpoint. Response action: 1. On-call team checks: is the IP known (security researcher running a scan, pentester, etc.)? 2. If unknown: likely attacker. 3. Block the IP at the WAF for 1 hour. 4. Check if any SQL-injection attempts succeeded (check for unusual database queries, error logs). 5. If successful injection is suspected: initiate incident response (forensics, database audit, user notification). 6. Review the affected endpoint's input validation; ensure it's robust. --- WHY THESE ALERTS MATTER (the response-action connection): Each alert is actionable — the on-call team doesn't just see "brute force detected"; they see the specific IP, the accounts targeted, the count, and the time. From there, they can: - BLOCK (IP-block, session revocation, account lock). - INVESTIGATE (check logs, cross-reference with threat intel, determine scope). - RESPOND (password reset, multi-factor re-enable, user notification). - ESCALATE (to incident response, to the security team, to law enforcement if needed). Without alerts, these activities happen in logs nobody reads. With alerts, response time drops from "weeks" to "minutes," and damage is minimized. --- ONE-LINE TAKEAWAY: Monitoring without alerting is like recording CCTV footage nobody watches — log anomalies are invisible until post-breach forensics; alerts + on-call response catch attacks in real time and minimize damage.