Detection Engineering: Writing SIEM Rules That Actually Fire on Real Attacks

A SIEM with 500 rules generating 10,000 alerts per day is not a security tool. It is a noise machine that trains analysts to treat every alert as probably nothing. Detection engineering is the discipline of developing, testing, and maintaining detection logic with the same rigour applied to production software — because production security depends on it.

The Detection Development Lifecycle

Good detections start with adversary behaviour, not log sources. Begin by identifying the technique you want to detect (use the MITRE ATT&CK framework as your library of techniques), then work backwards to identify which log sources would capture that behaviour, then write a rule that matches the behaviour while minimising false positives.

1. 01Select a technique from ATT&CK (e.g., T1053.005 - Scheduled Task/Job: Scheduled Task)
2. 02Identify relevant log sources (Windows Security Event Log 4698, Sysmon Event ID 1, EDR telemetry)
3. 03Research known implementations of the technique (malware samples, red team tool outputs)
4. 04Write a rule that matches the known-bad pattern
5. 05Test against a known clean baseline to measure false positive rate
6. 06Tune with allow-listing for legitimate administrative activity
7. 07Document the rule with: technique ID, trigger conditions, false positive notes, and a response playbook reference

Writing Effective Sigma Rules

Sigma is an open, vendor-neutral rule format for SIEM detections. Rules written in Sigma can be converted to the query language of most major SIEMs (Splunk SPL, Elastic EQL, QRadar AQL, Sentinel KQL). This portability makes it the right format for a detection rule library.

# Sigma rule: Suspicious scheduled task creation by non-administrative user
title: Suspicious Scheduled Task Creation
id: f4bc4c26-d6e1-4b42-9ef7-cde48f2b5e9a
status: experimental
description: Detects creation of a scheduled task from a user context that is not
  a known administrative account.
references:
  - https://attack.mitre.org/techniques/T1053/005/
author: ctfwithai Detection Team
date: 2025-12-01
tags:
  - attack.persistence
  - attack.t1053.005
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    EventID: 4688
    NewProcessName|endswith:
      - '\schtasks.exe'
    CommandLine|contains:
      - '/create'
  filter_admin:
    SubjectUserName|endswith:
      - '$'              # machine accounts (legitimate scheduled task setup)
    SubjectUserName:
      - 'SYSTEM'
      - 'Administrator'
  condition: selection and not filter_admin
fields:
  - SubjectUserName
  - CommandLine
  - ParentProcessName
falsepositives:
  - Software installers running in user context
  - Administrative scripts run by non-admin service accounts
level: medium

The False Positive Problem

False positives are not just an annoyance. They are a direct security risk because they train analysts to dismiss alerts. Every 100 false positives that get closed without investigation is a percentage chance that one real intrusion slips through. The goal of detection tuning is not to reach zero false positives — that would require lowering detection sensitivity to the point of uselessness — but to reach a false positive rate that the team can sustainably investigate.

Elastic EQL: Sequence Detection

Event Query Language (EQL) supports sequence detection — matching a series of events in order within a time window. This is particularly useful for detecting multi-stage attack patterns that no single event would trigger on.

// EQL: Detect credential dumping followed by lateral movement
// (LSASS access from non-standard process, followed by new network connection)
sequence by host.name with maxspan=5m
  [process where event.type == "start"
    and process.name : ("mimikatz.exe", "procdump.exe", "lsass.exe")
    and not process.parent.name : ("lsass.exe", "wininit.exe")]
  [network where event.type == "start"
    and network.direction == "outbound"
    and destination.port in (445, 139, 5985, 5986)
    and not destination.ip == "127.0.0.1"]

Coverage Measurement

Detection coverage should be measured against ATT&CK technique coverage, not rule count. A detection library of 50 well-tuned rules that covers the 20 techniques most relevant to your threat model is more valuable than 500 rules of varying quality. Use ATT&CK Navigator to visualise your current coverage and identify the highest-priority gaps based on your sector's threat actor profiles.