Episode 53 · Module 11 · Monitoring & Incident Response

Monitoring and Alerting Design

19 May 2026 · 8:51 · Security for Legal SaaS

8:51 8:51

You've built your legal SaaS platform with secure authentication, encrypted transport, input validation, and proper access controls. But security is not a static property — it's a continuous process. Attackers don't announce themselves. A credential stuffing attack (automated login attempts using leaked passwords, as covered in Episode 14) generates thousands of failed login events over minutes. A data exfiltration attempt looks like normal API calls until you notice the volume. Without monitoring, you won't detect the attack until a client calls asking why their documents are on the internet.

Today’s Lesson

Security for Legal SaaS — Episode 53: Monitoring and Alerting Design

If Nobody Sees the Alert, It Didn't Fire

NIST Cybersecurity Framework 2.0 organises cybersecurity into six core functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Detect function specifically requires "continuous monitoring capabilities to monitor cybersecurity events and verify the effectiveness of protective measures."¹ Everything we've covered in this series until now falls under Protect. Starting this episode, we shift to Detect, Respond, and Recover.

What to Monitor for Security

Not all system events are security events. Effective monitoring requires knowing which signals indicate malicious activity versus normal operations.

Authentication Anomalies

Signal	What It Might Indicate
Spike in failed login attempts from one IP	Credential stuffing or brute-force attack
Successful login from an unusual geography	Compromised credentials used from attacker's location
Login followed immediately by bulk data export	Account takeover in progress
Multiple MFA failures before a success	MFA fatigue attack (as covered in Episode 21)
Login outside business hours with privileged actions	Insider threat or compromised admin account

Authorisation Violations

Every time a user tries to access a resource they don't have permission for, that's a data point. One occurrence is probably a UI bug or a misclick. Ten occurrences from the same user in a minute, targeting different client records, is likely an attacker probing for IDOR vulnerabilities (Insecure Direct Object Reference — accessing other users' data by changing identifiers in requests, as covered in Episode 6).

Data Access Patterns

Monitor the volume and pattern of data access. A lawyer reviewing twenty documents in a case file is normal. The same account downloading every document across every client in the system is not. Baseline what normal looks like, and alert on deviations.

API Abuse

Rate limit violations (as covered in Episode 14), unusual API call patterns, requests to endpoints that don't exist (reconnaissance), and sudden spikes in traffic from a single source all warrant monitoring.

Alert Fatigue: The Silent Killer

The biggest threat to monitoring is not insufficient data — it's too much noise. Forrester Research reported that SOC (Security Operations Centre — the team responsible for monitoring and responding to security events) teams received an average of 11,000 alerts per day.² An ACM Computing Surveys study found that alert fatigue causes security teams to miss up to 30% of alerts — they go uninvestigated or are completely overlooked.³

For a small legal tech team without a dedicated SOC, the risk is even higher. If your monitoring system sends fifty alerts a day and forty-eight are false positives, your team will stop reading them. The two real alerts get buried.

The Target breach lesson: In the 2013 Target data breach, the security monitoring system (FireEye) detected the malware and generated alerts. The SOC team in Bangalore saw the alerts. Nobody acted on them. The breach exposed 40 million credit card numbers. The monitoring worked. The alerting process failed. Alert quality and response processes matter as much as detection capability.

Designing Alerts That Get Acted On

Fewer, higher-fidelity alerts. Modern SIEM systems (Security Information and Event Management — platforms that aggregate logs from multiple sources, correlate events, and generate alerts) aggregate observations across data sources, assign risk scores based on asset criticality and user privilege level, and only escalate when cumulative risk exceeds defined thresholds.⁴

Contextual enrichment. An alert saying "failed login from 203.0.113.45" is useless. An alert saying "12 failed logins from 203.0.113.45 (Tor exit node, never seen before) targeting admin accounts over 3 minutes" gives the responder enough context to act immediately.

Tiered severity. Not every alert needs the same response:

Severity	Example	Response
Critical	Successful admin login from unknown country	Immediate page, force session termination
High	Bulk data export exceeding 10x normal volume	Page within 15 minutes, investigate
Medium	Credential stuffing pattern detected	Review within 4 hours, consider IP block
Low	Single user accessing more files than usual	Log for review in daily security check

SIEM vs. Log Aggregation: Right-Sizing Your Stack

Not every team needs a full SIEM. The decision depends on your scale and complexity.

Log aggregation (tools like the ELK stack — Elasticsearch/Logstash/Kibana — or Grafana Loki) collects and centralises logs from your applications, databases, and infrastructure. You query them manually or write simple alert rules. For a small team with a single application, this is often sufficient.

SIEM adds correlation, behavioural analytics, and automated response. It connects events across sources: "this IP failed to log in five times, then succeeded, then accessed the admin panel, then started downloading documents" — connecting dots that individual log sources can't. Exabeam and Graylog describe how modern SIEMs integrate UEBA (User and Entity Behaviour Analytics — machine learning models that establish baselines of normal behaviour and flag anomalies) to reduce false positives.⁵⁶

For small legal SaaS teams: Start with structured logging (from Episode 52) feeding into a log aggregation platform. Write alert rules for the high-priority signals: failed login spikes, admin privilege escalation, bulk data access. Graduate to a SIEM when your user base, team size, or compliance requirements demand it. A well-configured log aggregation system with five good alert rules is better than a SIEM nobody has time to tune.

Security-Specific Dashboards

Build dashboards that answer these questions at a glance:

Authentication health: Login success/failure ratio over time. Unusual geography. MFA adoption rate.
Access patterns: Top data-accessing users. Cross-client data access (should be zero for non-admin users). Bulk operations.
API health: Requests per second by endpoint. 4xx/5xx error rates. Rate limit triggers.
Dependency health: Known vulnerabilities in current dependencies. Time since last scan.

These dashboards are not just operational tools — they're evidence. When a client or regulator asks "how do you monitor for security incidents?" you point to the dashboard and the alert history.

On-Call for Security Events

Someone must be responsible for responding to security alerts. For small teams, this doesn't mean a 24/7 security operations centre. It means:

Clear ownership: A named person or rotation who reviews security alerts daily and responds to critical alerts immediately
Escalation paths: If the on-call person can't resolve an alert, who do they escalate to? Define this before an incident, not during one
Decision authority: The on-call person needs authority to take immediate protective actions — blocking an IP, terminating a session, disabling an account — without waiting for management approval
Runbook for common scenarios: What to do when you see credential stuffing. What to do when you see bulk data export. Pre-written steps reduce response time from hours to minutes

NIST SP 800-61 Revision 3, updated in April 2025, now maps incident response activities directly to the CSF 2.0 functions, providing concrete guidance on detection and response procedures.⁷

The Monitoring Minimum

Control	Purpose
Centralised structured logging	Single source of truth for all security events
Authentication event monitoring	Detect credential attacks and account compromise
Authorisation violation tracking	Detect access control probing and IDOR attempts
Data access volume alerting	Detect exfiltration and insider threats
Tiered alert severity	Ensure critical events get immediate attention
Named on-call responder	Someone is always responsible for acting on alerts
Monthly alert tuning	Reduce false positives, update thresholds, add new rules

Monitoring without actionable alerting is just expensive logging. The goal is not to collect data — it's to detect threats fast enough to stop them before they become breaches.

Next episode: what happens when monitoring detects something real — incident response playbooks for when things go wrong.

Sources & references

NIST, Cybersecurity Framework 2.0.
Databahn, The Cybersecurity Alert Fatigue Epidemic.
ACM Computing Surveys, Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities.
Radiant Security, SIEM: Security Information and Event Management Explained — 2026 Guide.
Exabeam, SIEM Alerts: Understanding Security Information and Event Alerts.
Graylog, SIEM Automation to Improve Threat Detection and Incident Response.
NIST, SP 800-61 Revision 3: Incident Response Recommendations and Considerations.
Deepwatch, Modern Security Information and Event Management (SIEM) Strategies.
SearchInform, How SIEM Aligns with NIST, ISO, and Other Cybersecurity Frameworks.
ManageEngine, What Is SIEM? Security Information & Event Management Guide (2026).
Saltycloud / Isora GRC, NIST CSF Functions and Tiers: Complete Guide.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 53, and we're starting a new module — monitoring, alerting, and incident response. Alice, we've spent the last ten episodes on building secure infrastructure. Now we're talking about watching it. How do you know when something's going wrong?

Alice: And that shift matters. Everything up to this point has been about prevention — building walls. This module is about detection and response. Because here's the reality: prevention eventually fails. Not might fail — will fail. A credential gets stolen, a new vulnerability is disclosed in a library you depend on, an insider does something they shouldn't. The question isn't whether something bad will happen. It's whether you'll know about it in time to do something.

Dan: Right. So where do you start with monitoring?

Alice: Start with the signals that matter most. Authentication anomalies are the highest-value signals for most legal SaaS platforms. A spike in failed login attempts from one IP address — that's a credential stuffing attack, where someone is trying leaked passwords from other breaches against your system. We covered that back in Episode 14. A successful login from an unusual country, followed immediately by a bulk data export — that's an account takeover in progress. Multiple MFA failures before a success — that might be an MFA fatigue attack, which we discussed in Episode 21.

Dan: Mm. And beyond logins?

Alice: Authorisation violations. Every time a user tries to access something they don't have permission for, log it. One occurrence is a UI bug. Ten occurrences from the same user in a minute, targeting different client records — that's someone probing for IDOR vulnerabilities, trying to access other people's data by changing the ID in the request. We covered that in Episode 6. Then there's data access volume. A lawyer reviewing twenty documents in their case file is normal. The same account downloading every document across every client in the system — that's either an insider threat or a compromised account.

Dan: Yeah. So you're watching logins, access violations, and data volume. But here's what I wonder — if you monitor everything, don't you end up drowning in alerts?

Alice: <sigh> That's exactly the problem. It's called alert fatigue, and it's killed more security programmes than any attacker. Forrester Research found that security operations teams receive an average of eleven thousand alerts per day. A study in ACM Computing Surveys found that alert fatigue causes teams to miss up to thirty percent of alerts. They go completely uninvestigated.

Dan: Hmm. Thirty percent of security alerts just... ignored.

Alice: The Target breach in 2013 is the textbook example. Their security monitoring system — FireEye — detected the malware. It generated alerts. The security team in Bangalore saw the alerts. Nobody acted on them. The breach exposed forty million credit card numbers. The technology worked perfectly. The alerting process failed. And that's a company with a dedicated security team. For a small legal tech team with maybe five developers and no full-time security person, the risk of alert fatigue is even worse.

Dan: Mm-hmm. So how do you design alerts that people actually respond to?

Alice: Three principles. First — fewer, higher-quality alerts. Don't alert on every failed login. Alert on patterns: twelve failed logins from the same IP targeting admin accounts in three minutes. One alert, high confidence, actionable. Second — contextual enrichment. The alert shouldn't just say "failed login from IP address." It should say "failed login from IP address that's a known Tor exit node, never seen before, targeting admin accounts, twelve attempts in three minutes." Give the responder enough context to act immediately without having to go dig through logs.

Dan: Right. And severity levels?

Alice: Tier your alerts. Critical: successful admin login from an unknown country — page someone immediately, force-terminate the session. High: bulk data export ten times above normal volume — page within fifteen minutes, investigate. Medium: credential stuffing pattern detected — review within four hours, consider blocking the IP. Low: one user accessing more files than usual — log it for the daily security review. Not every alert is a fire. But the fires need to reach someone who can act, immediately.

Dan: Mm. Now, I keep hearing the term SIEM. What is that, and does a small team need one?

Alice: SIEM stands for Security Information and Event Management. It's a platform that collects logs from all your systems — your application, your database, your cloud infrastructure — correlates events across those sources, and generates alerts. The power of a SIEM is connection. It sees: "this IP failed to log in five times, then succeeded, then accessed the admin panel, then started downloading documents." Individual log sources can't connect those dots. A SIEM can.

Dan: Yeah. But that sounds expensive and complex for a small team.

Alice: It can be. And for a small team — say, building a case management SaaS with ten to fifty customers — you often don't need a full SIEM. Start with log aggregation. Tools like the ELK stack — that's Elasticsearch, Logstash, and Kibana — or Grafana Loki. Centralise your logs. Write simple alert rules for the high-priority signals: failed login spikes, admin privilege changes, bulk data access. Five well-tuned alert rules in a log aggregation system are more effective than a SIEM that nobody has time to configure properly. Graduate to a SIEM when your user base, team, or compliance requirements demand it.

Dan: Mm. And someone has to actually respond to these alerts, right? Who does that on a small team?

Alice: You need clear ownership. A named person — or a rotation if you have enough people — who reviews security alerts daily and responds to critical alerts immediately. They need escalation paths: if I can't handle this, who do I call? And they need decision authority. The on-call person must be able to block an IP, terminate a session, or disable an account without waiting for a manager to approve it. Because if an account takeover is in progress and the response takes two hours because someone needed permission to act, that's two hours of data exfiltration.

Dan: Right. Pre-written playbooks for common scenarios?

Alice: Exactly. A runbook — a documented set of steps — for each common scenario. "When you see credential stuffing: check the source IP, check if any accounts were compromised, block the IP if it's external, force password resets on any accounts that had successful logins during the attack window." Pre-written steps reduce response time from hours to minutes. NIST updated their incident response guidance — SP 800-61 Revision 3 — in April 2025. It now maps directly to the Cybersecurity Framework 2.0 functions, and it specifically recommends playbook-style documentation.

Dan: And the dashboards — what should they show at a glance?

Alice: Four things. Authentication health: login success and failure rates, unusual geography, MFA adoption. Access patterns: who's accessing what, any cross-client data access that shouldn't happen. API health: requests per second, error rates, rate limit triggers. And dependency health: known vulnerabilities in your current libraries. These dashboards aren't just operational. They're evidence. When a client or a regulator asks "how do you monitor for security incidents," you show the dashboard and the alert history.

Dan: Next episode — incident response playbooks. What happens when monitoring catches something real, and you need to contain a breach.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.