Alert fatigue
It is the most common problem security teams have: a detection system generating hundreds or thousands of alerts a day. Almost all of them are false or irrelevant. After a few weeks, the team learns to ignore them. And the alert that genuinely mattered arrives mixed in with the rest and goes unnoticed.
More alerts is not more security. It is less.
Fewer rules, better thought out
Each detection rule is written as a record sheet, just like a control:
- Which risk it covers: 'use of an administration credential from a country where we do not operate'.
- Which condition triggers it, in concrete terms.
- Who receives it, by name or role.
- What has to be done when it fires: the first step of the response playbook.
A rule with no planned action is not an alert, it is noise.
Tuning as continuous work
Each alert, when closed, is marked as useful or false. With that marking:
- Rules that only produce false positives are tuned (more context, known exceptions) or retired.
- Incidents that triggered nothing become new rules (the logic of every failure leaves a rule).
- The indicator that matters is not how many alerts there are, but what percentage of them is useful and how long the important ones take to be handled.
Where to start
The first rules worth having cover what almost always shows up in real incidents: anomalous sign-ins to privileged accounts, permission changes outside the normal processes, logging or controls being switched off, bulk access to confidential data, and unsigned artefacts attempting to deploy.
Detecting in time is only any use if you then know what to do. That is not improvised during the incident.
How we apply it: Cybersecurity.