Detection content built for your environment: prioritised against your risk, validated against your actual log sources, tuned before it is enabled, documented so it survives, and measured so the library improves instead of accumulating.

Review your detections How content is built

Why estates under-detect

A source was never connected

A rule was never tuned and got muted

Nobody owns the detection library

Coverage was assumed, never measured

The estate changed, the content did not

Mapped to MITRE ATT&CK so coverage is a measured figure rather than an assumption, and delivered in a form your own analysts can extend after we leave.

Lifecycle

Six steps per detection, and skipping the fourth is why SOCs drown

Writing the logic is the quick part. Everything around it is what makes a detection worth having in the queue.

Step 01

Prioritise

Which detections to build first, chosen from your risk register, your crown-jewel systems and the techniques actually used against your sector. Not the vendor library in alphabetical order.

Step 02

Confirm the data

Every use case depends on a source and specific fields within it. Before writing anything we verify the log exists, arrives reliably, and contains what the logic needs.

Step 03

Write the logic

Correlation across sources and across time, not single-event matching. Thresholds, sequences, baselines and exclusions defined against your environment.

Step 04

Tune before enabling

Run in silent mode against historical data first. If it would have fired 400 times last month, it is not a detection, it is a report.

Step 05

Document it

Each use case gets a purpose, the technique it covers, the sources it needs, the expected alert volume, the triage steps and the owner. An undocumented rule is deleted the first time it is noisy.

Step 06

Measure and retire

True positive rate tracked per use case. Rules that never fire are examined, rules that fire uselessly are fixed or removed. The library gets smaller as often as it gets bigger.

Detection types

Five kinds of logic, used deliberately

Most libraries are almost entirely single-event rules, which is why they miss multi-stage intrusions and generate volume instead of findings.

Single-event

A known-bad condition in one log line: a disabled audit policy, a cleared log, a credential-dumping tool signature.

Cheap, precise, and limited to what one source can see.

Threshold

The same event occurring more than N times in a window: failed authentications, denied connections, file access volume.

Catches brute force and bulk activity, needs careful baselining.

Sequence

Ordered events across sources: brute force, then success, then privilege change, then remote execution.

This is where correlation earns its name and where most real detections live.

Behavioural

Deviation from a learned norm for that user, host or account: unusual hours, unusual peers, unusual data volume.

Finds the activity no static rule anticipated, at the cost of tuning effort.

Contextual

Any of the above, weighted by asset criticality, exposure, vulnerability state or identity privilege.

Turns a true alert into an urgent one, or an urgent one into noise.

Every use case ships with

A rule nobody can explain gets muted within a month

The documentation is not paperwork. It is what lets a new analyst triage the alert correctly at three in the morning, and what lets you decide whether the rule still earns its place.

Purpose

What behaviour this detects and why it matters here.

Technique mapping

The ATT&CK technique or techniques it covers.

Required sources

The logs and specific fields the logic depends on.

Expected volume

What normal looks like, so a spike is itself a signal.

Triage steps

What an analyst checks, in order, and what confirms a true positive.

Response action

Containment or escalation expected when confirmed.

Exclusions

Known good behaviour and the reason each exception was accepted.

Owner and review date

Who maintains it and when it is next examined.

What goes wrong

Six failure modes we find in existing libraries

A detection review usually finds three of these. None of them are platform problems.

Vendor library enabled wholesale

Hundreds of rules switched on at go-live, none tuned. The queue is unusable by week two and the platform gets blamed.

Detections with no owner

Nobody knows why a rule exists or what to do when it fires, so it gets suppressed rather than fixed.

No exclusion strategy

Legitimate behaviour re-triggering the same alert every day, re-investigated every time because the exception was never recorded.

Coverage assumed, not measured

No mapping of which techniques are actually detected, so the gaps are unknown until an incident finds them.

Written once, never revisited

Detections built for an estate that has since changed, silently failing because a log source stopped or a field was renamed.

Alert count as the metric

Volume reported as productivity. The right measure is how many alerts led to a real finding.

Engagement model

Build the library

A defined engagement: coverage assessed against ATT&CK, gaps prioritised, detections written and tuned on your platform, documented and handed over with your analysts trained to extend them.

Talk to an engineer →

Engagement model

Maintain it with us

Content kept current as adversary behaviour and your estate change, source health monitored, false positive rates reviewed monthly, and new techniques covered as they emerge.

Managed SOC →

Related

Start with what you already have.

We review your current detection library against ATT&CK and your own risk register, and tell you which rules are earning their place.

Review your detections Talk to an engineer

A platform does not detect anything. The content you write inside it does.