Building a Detection Engineering Program

The alert-fatigue trap

Most detection stacks we inherit have the same problem: a dashboard lit up like a slot machine, thousands of alerts a day, and an analyst who long ago learned to ignore all of them. When everything is an alert, nothing is. The default posture of many tools — turn on every rule, forward every log — produces a wall of noise that hides the one event that mattered. Real intrusions sail through because the signal was buried under a hundred benign "possible" hits nobody had time to triage.

A detection engineering program flips that logic. Instead of collecting everything and hoping a rule catches something, we start from the threats we actually face and build a small set of high-fidelity detections that earn their place. Every alert should be worth waking someone up for.

Start from threats, not tools

The temptation is to buy a platform and switch on its rule packs. That gets the vendor's idea of a threat, not yours. We start the other way around: what does an intrusion against this organization plausibly look like? Which techniques would an attacker use against your identity provider, your edge, your endpoints, your build pipeline?

We map that to MITRE ATT&CK — not as a checkbox exercise, but as a way to prioritize. Techniques you are genuinely exposed to get a detection; techniques that don't apply to your environment don't waste an analyst's attention. The output is a coverage map: for each technique that matters, either a detection exists, a detection is planned, or we've made a conscious decision to accept the gap.

The log pipeline that feeds it

A detection is only as good as the data underneath it. Before writing a single rule, we make sure the right sources land in the SIEM, normalized into a shape rules can query. The sources that consistently earn their keep:

• Authentication and identity — sign-ins, MFA events, privilege changes. Most intrusions touch identity somewhere.
• Endpoint telemetry — process creation, command lines, parent-child relationships, script-block logging.
• Edge and network — VPN, firewall, and proxy logs that show what crossed the perimeter.
• Cloud and control-plane audit trails — API calls and configuration changes to the systems that run everything else.

We build this on tooling you can run and own — Wazuh or the Elastic stack — with normalization done at ingest so a field means the same thing regardless of which source produced it. A rule that has to special-case five log formats is a rule that will break.

Detection as code

Detections are software, and we treat them that way. Every rule lives in version control, gets peer-reviewed before it ships, and carries a test that proves it fires on the behaviour it's meant to catch. No more editing rules directly in a web console where the last change is a mystery and a typo takes production down silently.

A rule in this model is a small, readable artifact — here an illustrative Sigma-style detection for a suspicious credential-dumping pattern:

title: LSASS Access From Non-System Process
status: experimental
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1010'
            - '0x1410'
    filter_known:
        SourceImage|endswith:
            - '\wininit.exe'
            - '\csrss.exe'
    condition: selection and not filter_known
falsepositives:
    - EDR and backup agents that legitimately read process memory
level: high

Because it's text in a repository, we can diff it, review it, roll it back, and run it against recorded data before it ever touches the live pipeline.

Tuning: every rule earns its keep

A raw rule is a starting point, not a finished detection. The work is in the tuning — driving false positives toward zero without blinding the rule to the real thing. We tie each rule to an expected behaviour: what legitimate activity looks like the attack, and how we tell them apart. The backup agent that reads process memory, the admin tool that spawns PowerShell — those get filtered explicitly, in the rule, with a comment saying why.

The discipline is simple: a rule that fires on benign activity more often than malicious activity is a broken rule, and it gets fixed or retired. An alert an analyst can't act on is worse than no alert at all.

Validate: does it actually fire?

The most dangerous detection is the one everyone assumes works. Before we call a rule done, we prove it. Atomic tests replay the exact technique in a controlled way; a red-team replay walks the full behaviour end to end. If the rule doesn't light up, we find out why — wrong log source, a field that isn't collected, a condition that's too tight — and fix it. Detections that were never tested are just optimism written in YAML.

DFIR automation on top

A firing alert is the beginning of the work, not the end. We wire enrichment into the pipeline so that when a rule triggers, the analyst gets context automatically — the user, the host, recent activity, threat-intel matches — instead of pivoting through five consoles by hand. For well-understood scenarios, response playbooks handle the routine first moves: isolate a host, disable an account, pull a memory image. The goal is to compress the time between detection and containment, which is the number that actually decides how bad an incident gets.

Build and own it

When we build a detection program, it's yours. The rules, the pipeline configuration, the coverage map, the playbooks — documented and handed over so your team can run and extend them without us. It runs on tooling you control, not a subscription that stops working the day you stop paying. Detection engineering done right is an asset you keep, not a service you rent.