GO KALI FREE
AdvancedSecurity Operations

Detection Engineering: Creating Security Alerts and Rules

Learn detection engineering principles including rule development, Sigma rules, testing methodologies, false positive management, and building a detection program for security operations.

#Detection Engineering#Sigma Rules#Detection#Alerting#SOC

The Rule That Caught SolarWinds

In 2020, FireEye discovered SUNBURST — a backdoor planted in SolarWinds Orion software that had evaded every major security vendor's detection rules for months. The malware used legitimate code-signing certificates, blended into normal traffic, and mimicked standard API calls. After the breach was revealed, detection engineers built Sigma rules that could have identified the attack by modeling the adversary's behavior rather than searching for known IOCs. This shift — from signature matching to behavior-based detection — defines modern detection engineering.

Detection engineering is the discipline of designing, developing, testing, and maintaining detection logic that identifies malicious activity. It bridges the gap between threat intelligence and security operations.

Prerequisites

  • **Security Monitoring** — Understanding of detection infrastructure
  • **SIEM Fundamentals** — Familiarity with log sources and search languages
  • **Threat Hunting** — Understanding of adversary TTPs
  • **Log Analysis** — Ability to examine and interpret logs

    • The Detection Engineering Lifecycle

    Step 1: Intelligence Gathering

    Identify detection opportunities from:

  • **Threat intelligence feeds** — New CVEs, campaign reports, IOCs
  • **Incident post-mortems** — What was missed in previous breaches
  • **MITRE ATT&CK** — Uncovered techniques in the environment
  • **Penetration test results** — Techniques that evaded detection
  • **Red/purple team exercises** — Gaps identified during testing

    • Step 2: Rule Development

    Create detection logic as a query in the SIEM language or Sigma format:

    # Sigma rule for detecting WMI lateral movement
title: WMI Process Call Create
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects WMI lateral movement via process call creation
references:
    - https://attack.mitre.org/techniques/T1047/
tags:
    - attack.t1047
    - attack.lateral_movement
logsource:
    product: windows
    service: sysmon
    definition: Requires Sysmon Event ID 1
detection:
    selection:
        EventID: 1
        Image|endswith: '\wbem\WmiPrvSE.exe'
        ParentImage|endswith: '\svchost.exe'
    condition: selection
falsepositives:
    - Legitimate WMI administration scripts
level: high

    Step 3: Testing

    Before deployment, rules must be tested against:

  • **Known true positive data** — Historical incident data
  • **Synthetic attacks** — Generated using adversary emulation (Atomic Red Team, Caldera)
  • **Production baseline** — Run against recent logs to measure noise level
    • # Test detection with Atomic Red Team
Import-Module AtomicRedTeam
Invoke-AtomicTest T1047  # Test WMI execution

    Step 4: Deployment

    Deploy rules to production environment. Start with monitoring-only mode (log alerts but do not notify). This allows measurement of true and false positive rates before activation.

    Step 5: Tuning

    Based on monitoring results:

  • Adjust thresholds, exclusions, and conditions
  • Add allowlists for known legitimate activity
  • Iterate until acceptable false positive rate (typically <5%)

    • Step 6: Activation and Review

    Activate alerting after tuning. Schedule periodic reviews:

  • Review effectiveness quarterly
  • Update for new attack techniques
  • Remove or retire rules that no longer provide value

    • Sigma Rule Format

    Sigma is an open standard for writing detection rules in a generic format that can be converted to multiple SIEM languages (Splunk, KQL, Elastic, QRadar, etc.).

    # Sigma rule components
title: Human-readable rule name
id: UUID for unique identification
status: experimental/test/stable/deprecated
description: What the rule detects
references: Links to additional context
tags: MITRE ATT&CK mappings
logsource: What log source is required
detection: The detection logic
falsepositives: Known legitimate cases
level: informational/low/medium/high/critical

    Converting Sigma to SIEM Queries

    # Convert Sigma to Splunk
sigmac -t splunk rule.yml

# Convert Sigma to Elastic
sigmac -t elastic rule.yml

# Convert Sigma to QRadar
sigmac -t qradar rule.yml

    Detection Logic Patterns

    Pattern Matching

    Search for exact or pattern-matched values:

    # Detect base64-encoded PowerShell commands
index=windows EventCode=4104 ScriptBlockText="*-enc*"

    Threshold-Based

    Alert when count exceeds a threshold:

    # 10+ failed logons in 5 minutes (brute force)
index=windows EventCode=4625
| bucket span=5m _time
| stats count by _time, src_ip
| where count > 10

    Sequence-Based

    Detect events occurring in sequence:

    # Process creation followed by network connection
index=endpoint
| transaction session_id maxspan=5s
| where mvcount(EventCode) >= 2
| search EventCode=4688 AND network_connect=true

    Correlation-Based

    Combine events from different sources:

    # Failed logon followed by successful logon from different IP
index=windows (EventCode=4625 OR EventCode=4624)
| stats values(EventCode) as events, values(src_ip) as ips by UserName, _time
| where mvcount(ips) > 1 AND "4625" IN events AND "4624" IN events

    False Positive Management

    Sources of False Positives

  • **Legitimate admin activity** — Scripts, automation, monitoring tools
  • **Configuration changes** — Policies that trigger alerts during normal operations
  • **Application behavior** — Normal software operations that mimic malicious patterns
  • **Environment drift** — Rules that were correct but no longer apply

    • Tuning Process

  • Identify the false positive alert
  • Determine if it's a one-off or recurring pattern
  • For recurring patterns, add exclusion conditions to the rule
  • Document the exclusion rationale
  • Test the tuned rule against historical data
  • Deploy and monitor for new false positives

    • Detection Engineering Program

    Maturity Model

    Level 1 — Initial: Ad-hoc rules, mostly vendor-supplied, no standardized process.

    Level 2 — Defined: Standardized rule format (Sigma), defined lifecycle, basic testing.

    Level 3 — Managed: Purple team integration, coverage metrics, false positive tracking, quarterly reviews.

    Level 4 — Optimized: Automated rule generation, machine learning augmentation, predictive detection, cross-environment correlation.

    Metrics

  • **Coverage**: % of MITRE ATT&CK techniques with detection rules
  • **Time to Detect**: Mean time to detect for new attack techniques
  • **False Positive Rate**: % of alerts that are false positives
  • **Rule Age**: Average time since last rule review
  • **Detection Value**: Incidents discovered by each rule vs alerts generated

    • Real-World Example: Building a Detection Rule

    Scenario: A threat report describes a new Cobalt Strike beacon variant.

  • **Intelligence**: The report describes the beacon uses specific HTTP headers and sleeps with jitter
  • **Research**: Analyze network logs for the described patterns
  • **Development**: Create Sigma rule matching the HTTP header patterns and beacon intervals
  • **Testing**: Run against 30 days of historical proxy logs — 3 matches found, all false positives
  • **Tuning**: Add exclusion for known security scanner traffic
  • **Deployment**: Deploy in monitoring mode for 1 week — 0 additional alerts
  • **Activation**: Enable alerting; provides early warning for future use of this beacon

    • Common Mistakes

  • **Developing without testing** — Deploying untested rules that generate massive noise
  • **Ignoring false positives** — Letting analysts develop alert fatigue
  • **Writing overly specific rules** — Easy to bypass; misses variants of the technique
  • **Not using standardized format** — Rules tied to one platform are hard to migrate
  • **No lifecycle management** — Rules become stale and ineffective over time
  • **Over-relying on IOCs** — IOCs expire; TTP-based rules last longer

    • Best Practices

  • **Use Sigma format** — Generic rules work across multiple SIEM platforms
  • **Test with Atomic Red Team** — Validate detection against known adversary behavior
  • **Start with monitoring mode** — Measure noise before activating alerts
  • **Target <5% false positive rate** — Too many false positives cause alert fatigue
  • **Review rules quarterly** — Environment changes, rules must adapt
  • **Map to MITRE ATT&CK** — Track coverage and identify gaps
  • **Document rule intent** — Explain what the rule detects and why
  • **Version control rules** — Track changes and roll back if needed

    • Related Tools

  • **Sigma** — Generic detection rule format
  • **Atomic Red Team** — Adversary emulation library
  • **Caldera** — Automated adversary emulation
  • **Splunk** — SIEM for rule deployment
  • **ElastAlert** — Alerting for ELK Stack
  • **MITRE ATT&CK** — Detection coverage framework

    • Related Articles

  • Security Monitoring: Building Detection Capabilities
  • SIEM Fundamentals: Security Information and Event Management
  • Threat Hunting: Proactive Cyber Defense Strategies
  • Incident Response: Structured Approach to Security Breaches
  • Log Analysis: Extracting Intelligence from System Logs

    • Summary

    Detection engineering is the practice of creating and maintaining detection rules that identify malicious activity. The lifecycle includes intelligence gathering, rule development (preferably in Sigma format), testing, deployment, tuning, and regular review. Key concepts include pattern matching, threshold-based, sequence, and correlation detection. Managing false positives and mapping coverage to MITRE ATT&CK are essential for program maturity.

    Knowledge Check

  • What are the six steps of the detection engineering lifecycle?
  • What is Sigma and why is it useful for detection engineering?
  • What are the four types of detection logic patterns?
  • How do you manage false positives in detection rules?
  • What metrics should a detection engineering program track?

    • Frequently Asked Questions

    What is detection engineering and why is it important?

    Detection engineering is the discipline of creating and maintaining detection rules that identify malicious activity. It bridges threat intelligence and security operations by translating adversary behaviors into high-fidelity alerts, reducing dwell time and improving SOC efficiency.

    What is Sigma and why should detection engineers use it?

    Sigma is an open standard for writing detection rules in a platform-agnostic format. Rules written in Sigma can be converted to Splunk, KQL, Elastic, or QRadar queries, preventing vendor lock-in and enabling rule sharing across the security community.

    What are the six steps of the detection engineering lifecycle?

    The lifecycle includes: (1) Intelligence Gathering from threat intel and incident post-mortems, (2) Rule Development in Sigma or SIEM language, (3) Testing against known attacks, (4) Deployment in monitoring-only mode, (5) Tuning to reduce false positives, and (6) Activation with periodic review.

    What are the four types of detection logic patterns?

    The four patterns are Pattern Matching (exact value searches), Threshold-Based (count exceedances), Sequence-Based (events in specific order), and Correlation-Based (combining events from different sources). Each pattern addresses different adversary behaviors.

    How do you manage false positives in detection rules?

    Identify recurring false positive patterns, add exclusion conditions to rules, document the rationale, test against historical data, and deploy in monitoring mode before activation. Target less than 5% false positive rate to prevent analyst fatigue.

    What is Atomic Red Team and how is it used in detection testing?

    Atomic Red Team is an open-source library of adversary emulation tests mapped to MITRE ATT&CK techniques. It generates known-bad activity to validate that detection rules trigger correctly, ensuring rules work before real attacks occur.

    Why should rules start in monitoring-only mode?

    Monitoring-only mode logs alerts without notifying analysts, allowing measurement of true positive and false positive rates against production data. This prevents overwhelming the SOC with untested rules and enables data-driven tuning before activation.

    What is the detection engineering maturity model?

    The maturity model has four levels: Initial (ad-hoc vendor rules), Defined (standardized Sigma format with lifecycle), Managed (purple team integration, coverage metrics, quarterly reviews), and Optimized (automated rule generation, ML augmentation, cross-environment correlation).

    How do you test detection rules before deployment?

    Test rules against known true positive data from historical incidents, synthetic attacks using Atomic Red Team or Caldera, and production baselines to measure noise. This three-phase testing ensures rules detect real threats without excessive false positives.

    Why are TTP-based rules more effective than IOC-based rules?

    IOCs (IPs, hashes, domains) expire quickly as attackers change infrastructure. TTPs (techniques, procedures) remain stable across campaigns. TTP-based rules detect novel variants and campaign evolutions, providing longer-lasting detection coverage.