Detection

Detection coverage and rule health

A measured view of what the SOC can and cannot detect, and a loop that finds rules that never fire, rules that fire too often and log sources that went quiet.

The problem

Most SOCs cannot say which ATT&CK techniques they cover, whether a rule still works after a log format change, or which sources stopped sending. Coverage is assumed until an incident shows the gap.

Stack

SIEM: SplunkIBM QRadar
Framework: MITRE ATT&CK
Validation: Atomic Red TeamCaldera
Data pipeline: CriblLogstashFluentd

How it works

1
Map
Every rule in Splunk and QRadar is mapped to the ATT&CK techniques and data sources it depends on. The result is a coverage matrix by technique and by asset type.
2
Prioritize
Gaps are ranked against the threats that matter for the organization, so engineering time goes to the techniques most likely to be used against it.
3
Validate
Atomic Red Team or Caldera tests run the technique in a controlled environment. The result shows whether the rule fired, how late, and with which fields.
4
Monitor
Scheduled checks list log sources that stopped sending or changed volume, and rules that returned nothing for a long time or flood the queue.
5
Tune
Noisy rules get exclusions or threshold changes proposed from the closure reasons of past alerts. An engineer approves each change.
6
Report
A recurring coverage report shows what changed since the last cycle.

Guardrails and failure handling

Validation tests run only in an approved scope and an approved environment.
Tuning changes are reviewed, tracked and reversible.
A rule is never deleted for being quiet before someone has checked that its data source still works.