Loading...
New
See what manual alert triage really costs your security team.
New
See what manual alert triage really costs your security team.
See what manual alert triage really costs your security team.
See what manual alert triage really costs your security team.
Loading...
Detection engineering is the practice of turning attacker behavior into alert rules, usually mapped to MITRE ATT&CK, and keeping them working through seven stages: hypothesis, telemetry, logic, test, deploy, tune, and retire. The hard part comes after a rule ships. A 2026 preprint on SigmaHQ history found false-positive exclusions were added 5.4 times as often as they were withdrawn.
A detection rule starts aging the day it ships. Fields get renamed, log sources go quiet, and every false positive someone tunes away narrows what the rule can see. None of that raises an error, so your coverage dashboard keeps showing the picture from launch day.
Detection engineering is the discipline of turning attacker behavior into alert logic, then testing, deploying, and maintaining that logic inside your SIEM, EDR, or data lake. It owns a question nobody else in the SOC owns. If this technique runs again, will anything fire?
| Function | Question it answers | Time horizon |
|---|---|---|
| Alert triage | Is this one alert malicious? | This shift |
| Threat hunting | Did something happen that no rule caught? | This week |
| Detection engineering | Will we catch it next time? | Next quarter |
| Threat intelligence | What are attackers doing now? | Ongoing |
If nobody on your team can say whether you'd catch a technique you care about next time, you're assuming untested coverage.
A detection engineer turns a backlog of attacker behaviors into working rules, then keeps those rules alive while the environment changes. The backlog fills from incidents, hunts, threat intelligence, and red-team findings. Writing new rules is only part of the week. The rest goes to testing, tuning, and retiring the ones already running.
That maintenance slips first. In the 2026 SANS and Anvilogic State of Detection Engineering survey, 80% of 307 practitioners said they're barely keeping pace or behind. The job looks more like software engineering every year, yet only 13% reported high proficiency in it.
The detection engineering lifecycle has seven stages: hypothesis, telemetry, logic, test, deploy, tune, and retire. Follow one real rule through them: Florian Roth's Suspicious Encoded PowerShell Command Line from SigmaHQ, which flags PowerShell launched with a base64-encoded command and maps to T1059.001.
Attackers encode PowerShell commands so the payload never appears in plain text. Palantir's Alerting and Detection Strategy framework has you write that hypothesis down, with the rule's blind spots, before shipping.
The rule reads process-creation events from Sysmon event 1 or Windows Security event 4688. Event 4688 needs process-creation auditing turned on, and Microsoft's documentation says its command-line field stays empty until a separate Group Policy setting enables it. On hosts without that setting the rule can't match, so check command-line coverage host by host.
The detection block and level, verbatim from SigmaHQ:
detection:
selection_img:
- Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
- OriginalFileName:
- 'PowerShell.EXE'
- 'pwsh.dll'
selection_cli_enc:
CommandLine|contains: ' -e' # covers -en and -enc
selection_cli_content:
CommandLine|contains:
- ' JAB'
- ' SUVYI'
- ' SQBFAFgA'
- ' aQBlAHgA'
- ' aWV4I'
- ' IAA'
- ' IAB'
- ' UwB'
- ' cwB'
selection_standalone:
CommandLine|contains:
- '.exe -ENCOD '
- ' BA^J e-' # Reversed
filter_optional_remote_signed:
CommandLine|contains: ' -ExecutionPolicy remotesigned '
condition: selection_img and (all of selection_cli_* or selection_standalone) and not 1 of filter_optional_*
level: high
It makes three bets. The process is PowerShell, by path or original file name. The command line carries an encoded-command switch. And the payload starts with a fragment like JAB, the base64 of a leading $ in PowerShell's UTF-16LE text. Since ' -e' also matches -ExecutionPolicy, the payload check does the real work.
Test every rule twice, on the behavior it targets and on a baseline window of normal activity. This rule fails the first one. Atomic Red Team's T1059.001 "PowerShell Command Execution" test runs powershell.exe -e JgAg…, which decodes to & (gcm ('ie{0}' -f 'x'))…, an obfuscated iex. The opening & encodes as JgAg, a fragment missing from the list, so this rule on its own stays silent.
A companion rule on PowerShell script block logging (event 4104), which records the decoded command, covers part of that gap. The baseline run then measures noise: some deployment tools pass encoded commands legitimately.
Translating Sigma into your SIEM's language lets silent bugs in. Field names change, and so do operators. CommandLine becomes ProcessCommandLine in Microsoft Defender. Rewrite Sigma's contains as KQL's has_any and the query misses payloads that start JAB, because has_any matches whole terms only. Detection as code adds review around this step, though fewer than half the teams in the SANS survey run rules through a CI/CD pipeline.
Every false positive invites an exclusion, and this rule ships with one. Its filter_optional_remote_signed branch, applied unless someone edits it out, drops any command line containing -ExecutionPolicy remotesigned. The match is case-insensitive and can sit anywhere in the line, so an attacker who adds -ExecutionPolicy RemoteSigned to an encoded launch never trips this Sigma rule.
A 2026 preprint, The Exclusion Ratchet, counted 1,642 exclusions added to SigmaHQ rules and 304 withdrawn, and estimated 86.7% were still in force three years later. It also found 64.1% of path-based exclusions could be satisfied by an unprivileged process choosing a filename. Give every exclusion an owner and an expiry date, or it becomes a blind spot nobody remembers approving.
Retire a rule when its telemetry is gone for good or a better rule replaces it. If the log pipeline broke, fix that instead. Rebuild when tradecraft moves past the rule's assumptions, as that & payload does. Left switched on, a dead rule still pads your ATT&CK coverage number.
Detection rules stop firing because the data, environment, adversary tradecraft, and team knowledge they were written against keep moving, almost always without an error. That movement is detection drift. By Simbian's 2026 estimate, about 20% of SOC detection rules stop firing within six months.
CardinalOps, now part of Cribl, found that about one production rule in ten was broken at a single point in time, in its 2025 State of SIEM Detection Risk report. No independent study has published a cross-organization decay rate, so measure your own.
| Drift | What happens to the PowerShell rule |
|---|---|
| Data drift | A parser change silently drops command lines |
| Environment drift | A new deployment tool floods the rule until someone mutes it |
| Adversary drift | A payload opens with a fragment the list doesn't anticipate |
| Knowledge drift | The author leaves, and nobody knows the remote-signed filter is a bypass |
Adversary drift is the one teams underestimate. At USENIX Security 2024, Uetz and colleagues evaded 129 of 292 widely used SIEM rules with five straightforward techniques.
A broken rule and an idle one look identical on a dashboard, so check detection rule health on a schedule and after every SIEM or log-source change.
| Check | How it works | What it catches here |
|---|---|---|
| Zero-fire review | Test every rule that's been silent for 90 days | A blind rule passing as a quiet one |
| Field-presence canary | Check daily, per host group, that each field a rule reads arrives | Hosts missing the command-line policy |
| Scheduled true-positive test | Re-run test cases, including known misses | The & payload |
| Exclusion audit | Review by expiry date and challenge any that an attacker could satisfy | The remote-signed filter |
AI is changing detection engineering fastest at translation work, such as drafting Sigma from a hypothesis or converting it to KQL and SPL. Stages that depend on your environment still need human judgment. In the 2026 SANS survey, 83% of practitioners said they use AI tools, yet only 42% trust them with core work like tuning detections.
| Stage | Where AI helps | What a human still owns |
|---|---|---|
| Telemetry | Mapping fields from schemas | Proof the data arrives |
| Logic and deploy | Drafting Sigma, translating it to KQL and SPL | Intent and blind spots |
| Test | Generating cases, clustering false positives | The acceptable noise level |
| Tune | Proposing exclusions from false-positive history | Approving each one, with an expiry |
Faster drafting also makes it cheap to ship a rule against a field your SIEM doesn't collect, syntactically perfect and dead on arrival.
Simbian's AI Detection Engineering Agent works the logic, test, deploy, and tune stages. It drafts candidate rules from what your SOC investigations and threat hunts turn up, and proposes tuning changes from the false positives your SOC closes. Your team approves each one before anything ships to your SIEM.
It's one node of a four-node loop mapped to MITRE ATT&CK. The AI Pentest Agent asks what could happen, the AI Threat Hunt Agent asks whether it already happened, the AI SOC Agent asks whether you detected it, and this Agent asks whether you'll catch it next time.
Onboarding telemetry is still your team's job. Each candidate is replay-tested against your own data, so one written against a missing field fails there, before anyone reviews it. Approved rules deploy automatically, with rollback and an audit trail.
Nothing reaches production without a human: self-improving, not self-driving.
Q: What is detection in cyber security? In cyber security, detection means spotting malicious activity in endpoint, network, cloud, and identity telemetry and raising an alert someone can act on. It sits between prevention and response, and detection engineering builds and maintains the rules that do the spotting.
Q: How do you become a detection engineer? Most detection engineers come over from SOC analysis, incident response, or threat hunting, because those roles teach how attacks look in real logs. Learn one SIEM query language deeply, write Sigma rules mapped to MITRE ATT&CK, and work in Git. Rules merged into SigmaHQ are the most direct proof of skill.
Q: Are vendor-provided detection rules enough? No. Vendor rules are a baseline written for a generic environment. In the 2026 SANS survey, 66% of respondents named vendor rules as a source of high false-positive rates. Start from vendor rules, then write custom rules for what matters most to you.
Q: What is a detection engineering framework? A detection engineering framework is a written standard for how every rule gets documented and tested. The best-known is Palantir's Alerting and Detection Strategy framework (2017), where each rule records its goal, ATT&CK mapping, blind spots, expected false positives, and a validation plan.
Pull your rule list this week and sort it by the date each rule last fired, newest first.
The silent ones at the bottom need a zero-fire review. The busy ones at the top can hide the other failure, like the PowerShell rule: still firing every week and blind in a way nobody wrote down. To see the AI Detection Engineering Agent draft rules from your own investigations, Book a Demo.
