A busy alert queue can still leave important activity unseen. We look at the rules that fire, the logs behind them and the systems they are meant to protect. You receive a practical list of tuning and coverage work.
Security teams dealing with repeat false positives or unable to show that important systems have dependable monitoring coverage.
Independent findings from the last year, with the report each one comes from.
Independent findings from the last year, with the report each one comes from.
of intrusions were first detected by the organisation itself rather than by an outside party, up from 43% the year before. The median time an attacker went unnoticed was 14 days.
This is why the review starts from your critical systems and checks whether a detection would actually fire for each one.
of security teams encounter false positives frequently or very frequently, and the share seeing them very frequently rose from 13% to 20% in a year. False positives remain the leading operational burden.
This is why retiring and tuning rules is as much of the deliverable as proposing new ones.
was the average time to identify and contain a breach. Organisations that found the breach themselves saved around $900,000 compared with those told by the attacker.
This is why every use case is tied to a system, a log source and an owner, so the alert exists when it counts.
Agree which assets, data stores and services need the strongest monitoring coverage.
Check what each active use case detects, how often it fires and whether an analyst can act on the signal.
Confirm that the required logs arrive in the SIEM and that important fields are parsed correctly.
Test coverage against MITRE ATT&CK techniques that apply to your environment.
Review the tuning, new rules and logging work with the people who will implement them.
A large queue may look busy while useful signals are buried under repeat alerts and alerts with little value.
We go through your critical assets and your AWS or Azure environment with you, agree who should touch them and how, then write use cases that fire only when something touches them another way, such as customer data in an S3 bucket read by anything other than the one role built for it.
Old services disappear, new ones arrive and a once useful rule can become noise. Periodic review keeps the rule set relevant.
FinanceReportsRoleGetObject 
customer-dataexpectedFinanceReportsRoleGetObject customer-dataexpectedFinanceReportsRoleListBucket customer-dataexpectedAdminBreakGlassRoleGetObject customer-datanot the approved roleA detection health report that lists the tuning changes, proposed use cases and logging work in priority order, with a coverage matrix for your critical systems and each tuned query carrying the exclusions specific to your environment.
Sample report, fictional client
Our consultants have built and tuned detection programmes in regulated environments.
Offensive testing experience helps us choose relevant techniques and test whether the expected evidence appears.
The person reading the rules also presents the findings and answers the implementation questions.
