Security Monitoring & Detection

Prevention is never perfect, so you also have to notice when something is wrong: a break-in, an abuse pattern, a misuse of access. Security monitoring is the smoke alarm. It turns an attack you would otherwise find months later into an alert you can act on today.

This is different from ordinary observability (is the system healthy?) and from audit trails (the legal record of what happened). Detection asks a different question: is something malicious or unusual happening right now? That means collecting security-relevant signals, sending them somewhere they can be correlated and alerted on, and having someone (or something) watch and respond.

For an AML platform the stakes are high. An undetected account takeover or data theft is exactly the kind of incident that becomes a breach notification. The good news is that most of the value comes from alerting on a few well-chosen signals.

Collect and watch the right signals

• DoEmit security-relevant events (auth successes and failures, privilege and role changes, access to sensitive data, config and security-control changes) in a consistent, queryable form (see Observability & Logging Hygiene).
• DoCentralise these signals where they can be correlated and alerted on (a SIEM or log analytics), not scattered across services.
• DoAlert on the patterns that matter: spikes in failed logins, impossible travel or unusual locations, mass data access or export, privilege escalation, and disabled security controls.
• ConsiderUsing the platform's built-in detection (Microsoft Defender for Cloud, Entra ID risk detections) before building your own.
• AlwaysKeep security detection free of the data it watches over. Alerts and signals must not themselves log secrets or full PII.

Be able to respond

• DoMake sure alerts reach someone who can act, with enough context to triage. An alert nobody sees protects nothing.
• DoConnect detection to incident response: a credible alert becomes an incident, with the breach-notification clock in mind (see Incident Readiness).
• DoKeep security logs long enough to investigate after the fact (attacks are often found late), within retention and residency rules.
• ConsiderTuning alerts to keep the signal high. Too many false positives and real alerts get ignored (alert fatigue).
• NeverDisable or bypass security logging or alerting, or strip the audit or detection from a sensitive action, without authorisation and a record.

Self-review checklist

• AskIf an attacker were active in our systems right now, what signal would reveal it, and would anyone see it?
• AskAre auth, privilege, and sensitive-data-access events captured and correlated somewhere?
• AskDoes a real alert reach a person who can act, and turn into an incident?
• AskCould we investigate an attack discovered months later from the logs we keep?