Thinking in Detection Pipelines

It is easy to talk about detection as if it were a list of rules. A rule fires, an analyst looks, something is decided. But a rule is only the visible end of a longer chain, and most of what makes a detection good or bad happens before and after it.

This is a mental model I use to keep the whole chain in view. It is deliberately vendor-neutral and high level.

1. 01TELEMETRYwhat is observed
2. 02NORMALIZATIONone consistent shape
3. 03CONTEXTwhat the event means here
4. 04DETECTIONlogic that selects what matters
5. 05INVESTIGATIONreconstructing what happened
6. 06RESPONSEacting on the conclusion
7. 07IMPROVEMENTfeeding everything back

Telemetry

Everything starts with what you can observe: endpoints, network, cloud, identity. A detection cannot be better than the data underneath it. Gaps in telemetry are silent, which makes them dangerous. Nothing alerts you that something was never recorded.

Normalization

Raw events arrive in different shapes. Normalization gives them one consistent structure, with the same field for the same idea. It sounds like plumbing, but it decides whether logic written once can apply everywhere. Inconsistent fields are a common reason a good idea behaves differently across data sources.

Context

An event on its own is rarely meaningful. The same action can be routine for one account or machine and unusual for another. Context is what separates them: who or what was involved, what is normal for it, what it relates to. Adding it early keeps detection logic simple and investigations short.

Detection

Only here does something resemble a rule. Good detection logic is specific about what it is looking for and honest about what it cannot see. It also has a cost: every detection adds noise or maintenance, so each one should earn its place.

A detection is a hypothesis about behaviour, plus an agreement about what to do when it is true.

Investigation

When a detection fires, an analyst reconstructs a timeline from evidence. The quality of that work depends on what the earlier stages preserved: complete records, consistent fields, enough context to read the events without guessing. A pipeline that makes investigation slow has a design problem, not a staffing problem.

Response

Response is the point where understanding turns into action: triage, escalation, remediation. It is also where the cost of a bad detection becomes visible, as time spent on alerts that did not matter.

Improvement

The last stage is the one that makes the others better. Every investigation is evidence about the pipeline itself. Which fields were missing? Which alerts were noise? Which steps were repeated by hand again and again?

Why this is an engineering problem

Seen as a chain, most detection problems stop looking like rule-writing problems. Noisy alerts often come from weak normalization or missing context. Slow investigations often come from poor evidence handling. Stale detections come from a missing feedback loop.

That is why I find the space between analyst and builder interesting. The analyst feels the friction of the system. The builder can change the system. The pipeline is where those two perspectives meet.