Detection Engineering

The problem

Most detection estates grow by accident. Rules are switched on because a data table exists, not because an attack needs catching. New rules flood the queue on day one. Existing rules drift as data changes, and the fixes are lost the next time a vendor updates its template. The result is coverage that looks healthy on paper, an alert queue nobody trusts, and analyst hours spent clearing noise.

What we do

• Develop detections against 13 attack scenarios, from a phishing attack that steals a login through to human-operated ransomware, each mapped to MITRE ATT&CK, so you can see which attacks you are covered for and which you are not.
• Deploy every rule flood-checked and tuned against your live data first, so switching it on never creates an alert storm.
• Tune your existing rules, proving the root cause of the noise past the rule's own filter and over a 90-day window, then cutting the volume without cutting the coverage.
• Measure every change before and after. One rule, in a recent engagement, went from around 96 alerts a day to about one, with the detection kept intact.

The safeguards

• Read-only until you approve each change.
• Every reduction carries a named compensating control, so nothing is given up silently.
• Tuning is decoupled, so a vendor template update can never overwrite it.