Published on

Few alerts, good ones

A thousand alerts a day protect nobody: they get ignored. Useful detection means few rules, each tied to a specific risk, with an owner and a planned action, tuned until almost every alert means something.

Service line Cybersecurity

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

Few alerts, good onesWeekly alerts from 1,240 to 38 while the useful percentage rises from 4% to 71%, plus a rule’s record sheet.SECURITY · DETECTIONFew alerts, good ones1240w14%w26%w39%w414%330w522%w635%w748%w858%w966%38w1071%Alerts per week (logarithmic scale) and the useful percentageusefulA RULE'S RECORD SHEETRiskadministration credential used from a country where we do not operateConditionadministrative sign-in + country off the listGoes tosecurity on callActiondisable the session and open the response playbookA rule with no planned action is not an alert: it is noise.Illustrative data; they do not correspond to any real caseN100F · n100f.com

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.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk