Detection Engineering Program - Part 5 - Example Writing Detections
Writing a Detection: Overview
The core of a detection is its analytic logic: the conditions used to evaluate organizational telemetry and identify activity that may be malicious, suspicious, or inconsistent with expected behavior.
Detection logic may use one or more analytic methods, including:
Matching a specific string, command, file path, event ID, or field value
Combining multiple strings, fields, events, or log sources
Correlating related activity across identities, endpoints, networks, applications, or cloud services
Applying thresholds, such as a specified number of events within a defined period
Comparing activity with an established behavioral or statistical baseline
Enriching events with organizational context, such as asset criticality, user role, or vulnerability status
Comparing observed values with allowlists, denylists, or threat-intelligence indicators
Identifying unusual sequences, relationships, or changes in behavior
The query is important, but it is only one part of a complete detection. A production detection also requires documented intent, data requirements, execution settings, severity, validation criteria, known false positives, response guidance, ownership, and maintenance procedures which will continue to discuss in future sections of this course.
The Relationship Between Threat Hunting and Detection Engineering
Threat hunting and detection engineering work closely together because both disciplines develop analytic logic to find evidence of suspicious activity.
A threat hunter commonly searches historical telemetry to answer:
Has this threat or behavior occurred in our environment?
If the hunt produces reliable logic, that logic can potentially be operationalized as a continuous detection that asks:
Is this threat or behavior occurring now?
This creates a natural progression:
Threat hypothesis → Historical hunt → Validated findings → Refined logic → Production detection
Important Caveat: Hunt Queries Are Not Automatically Production Detections
Threat-hunting queries are often intentionally broad. A hunter can manually review the results, eliminate benign matches, add context, and decide whether further investigation is warranted.
A production detection operates repeatedly and may send every qualifying result to the SOC. If the original hunt query returns large numbers of benign matches, converting it directly into an alert can create excessive noise and analyst workload.
Before operationalizing a hunt query, determine whether:
Benign activity can be excluded safely
Additional context can distinguish malicious from legitimate behavior
Multiple signals should be correlated
The alert volume is operationally sustainable
The result provides enough information to support action
The logic is better suited to scheduled hunting than continuous alerting
Some useful hunt logic should remain a hunt. Not every analytic query should become an alert.
Detection Query Execution
Once developed and validated, query-based detection logic is normally configured to run at a defined interval, such as:
Every minute
Every 5 or 15 minutes
Every hour
Every 24 hours
Factors in querying scheduling:
The urgency of the threat be detected
Expected event volume being analyzed
Data-ingestion latency
Query complexity and computing cost
Required response time
The query frequency and lookback period are separate settings. For example, a query may run every five minutes while reviewing the previous ten minutes of data. This overlap can help account for delayed log ingestion, although the detection must prevent the same event from creating duplicate alerts.
Distinguishing the Detection, Query, and Analysis Method
The terms detection and query are often used interchangeably, but they are not identical:
Detection — The complete security capability, including its objective, data, analytic logic, execution method, alerting behavior, validation, severity, and response guidance.
Query — The technical expression used to search or analyze data.
Analysis method — The way and location in which the logic executes, such as within a sensor, against stored data, or in a streaming pipeline.
A single detection may use more than one query, and some detections operate without a traditional SIEM query.
Three Common Detection Models
1. Sensor-Based Detection
A security sensor, such as an EDR, firewall, IDS/IPS, NDR, or email-security product, analyzes activity within or near the system it monitors.
The sensor may:
Block the activity immediately
Generate an alert in its own platform
Send an alert record to a SIEM
Send raw telemetry for additional analysis
If a SIEM rule later identifies the sensor-generated alert, the original detection occurred at the sensor. The SIEM is consuming, correlating, enriching, or routing the result rather than independently detecting the original behavior.
Example:
Endpoint activity → EDR Vendor X detection → Vendor X alert → Alert log ingested into SIEM → SIEM detection query looking for Vendor X alerts → Alert in SIEM
2. Scheduled Query Detection
Sensors, applications, systems, and cloud services may send raw events that do not represent detections by themselves. A SIEM query periodically analyzes those stored events for suspicious patterns.
Example:
Process event → Log ingestion → SIEM storage → SIEM detection query looking for suspiocus patteern in process logs → Alert in SIEM
In this model, the SIEM detection occurs after the original activity and after the necessary telemetry has been ingested and made searchable.
3. Streaming or Ingestion-Pipeline Detection
Some architectures evaluate events while they pass through a streaming platform, message broker, or analytics pipeline. This can identify patterns before data is fully stored and later queried in the SIEM.
Streaming analysis can be especially useful for:
High-volume event processing
Sliding-window thresholds
Rapid sequences of related activity
Time-sensitive detections
Stateful event correlation
However, “streaming” does not necessarily mean instantaneous. The event must still be generated, transmitted, received, parsed, enriched, evaluated, and converted into an alert.
Event Time Is Not Alert Time
Every detection has some degree of latency. A useful model distinguishes four timestamps:
Event time — When the activity occurred
Ingestion time — When the telemetry reached the analytics platform
Processing time — When the detection logic evaluated the telemetry
Alert time — When the result became available to analysts or automation
Delays may result from:
Endpoint or application log-generation delays
Network transmission and collection delays
Parsing, normalization, and enrichment
Scheduled query intervals
Large lookback periods
Detection complexity
Correlation across multiple data sources
Vendor-side processing
Alert routing and automation
Even major security platforms may issue certain alerts minutes or hours after the underlying activity because they require additional telemetry, correlation, enrichment, or cloud-based analysis.
Understanding “Near Real Time”
Security teams frequently describe detections as operating in near real time, but that phrase does not have one universal meaning. Depending on the organization and use case, it could mean:
Less than one minute
Less than five minutes
Less than fifteen minutes
Within an established operational service level
Organizations should define near real time using a measurable target rather than treating it as synonymous with immediate detection.
Scheduled Windows Versus Sliding Windows
The difference between scheduled and streaming analysis is especially important for threshold-based detections.
Scheduled Query Window
A query runs every five minutes and examines a defined lookback period.
Example:
Alert if five failed sign-ins occurred during the period evaluated by the query.
Poorly designed fixed windows can divide related events across query boundaries. Overlapping lookback periods can reduce this risk, but they require deduplication.
Sliding Window
A streaming analytic continually evaluates the most recent five-minute period.
Example:
At any point, alert when the fifth failed sign-in occurs within the preceding five minutes.
Sliding windows can identify threshold crossings more quickly and avoid some fixed-boundary problems, but they require state management, appropriate event-time handling, and controls for late or duplicate events.
Defining Detection Query Formats
As a detection engineering program matures, the way it stores, documents, and tracks detections typically evolves. At the most basic level, the detection may exist only as a platform-specific query.
Common query languages include:
Splunk: Search Processing Language (SPL)
Elastic Stack: Elasticsearch Query DSL, Event Query Language (EQL), ES|QL, and Kibana Query Language
Microsoft Sentinel and Defender XDR: Kusto Query Language (KQL)
Terminology note: Elastic’s Kibana Query Language and Microsoft’s Kusto Query Language are both abbreviated as KQL, but they are different languages.
Comparing Common Query Syntaxes
The following examples perform the same basic operation: calculate the total number of bytes associated with each host.
Splunk SPL
index=sample_data_index
| stats sum(bytes) AS total_bytes BY hostElastic ES|QL
FROM sample_data_index
| STATS total_bytes = SUM(bytes) BY hostMicrosoft KQL
sample_data_index
| summarize total_bytes = sum(bytes) by hostImportant: These are visualization and aggregation examples—not security detections. They are intended only to demonstrate how similar analytic logic is expressed in different query languages.
The Rise of Vendor-Neutral Detection Formats
Security teams traditionally wrote separate versions of the same detection for every SIEM and analytics platform they operated. This created duplicated effort and made detection content difficult to share, migrate, and maintain.
The Sigma project was developed to address this challenge. Sigma is an open, vendor-neutral, structured format for describing log-based detection logic in YAML. A Sigma rule can be converted into platform-specific queries for supported systems such as Splunk, Elasticsearch, Microsoft Sentinel, and others.
Example Sigma Rule
The following simplified rule detects selected Windows Defender events associated with protection being disabled or unavailable:
title: Windows Defender Threat Protection Disabled
id: 11111111-2222-3333-4444-555555555555
status: test
description: Detects Windows Defender events associated with disabled or unavailable protection.
logsource:
product: windows
service: windefend
detection:
selection:
EventID:
- 5001
- 5010
- 5012
- 5101
condition: selection
falsepositives:
- Authorized administrative or troubleshooting activity
level: high
tags:
- attack.defense-evasion
- attack.t1562.001A Sigma rule commonly contains:
Title and description — Explain what the rule detects
Log source — Identifies the required product, service, or event category
Detection logic — Defines selections, filters, and matching conditions
False positives — Documents legitimate activity that may trigger the rule
Level — Assigns a general severity
Tags — Supports classifications such as MITRE ATT&CK mappings
References, author, dates, and status — Provide ownership and lifecycle context
Sigma’s required core is comparatively small, but its metadata makes rules easier to understand, review, share, and manage.
Sigma conversion uses platform-specific backends to generate the target query language. Optional processing pipelines map generic Sigma log sources and field names to the actual indexes, tables, fields, and schemas used by the destination environment.
Illustrative Conversion Results
The Defender tampering possible event selection above might be represented as follows after the appropriate environmental mappings are applied.
Splunk SPL
source="WinEventLog:Microsoft-Windows-Windows Defender/Operational"
EventCode IN (5001, 5010, 5012, 5101)Elastic ES|QL
FROM logs-windows.*
| WHERE winlog.channel == "Microsoft-Windows-Windows Defender/Operational"
AND event.code IN ("5001", "5010", "5012", "5101")Microsoft KQL
WindowsEvent
| where EventLog == "Microsoft-Windows-Windows Defender/Operational"
| where EventID in (5001, 5010, 5012, 5101)These examples are illustrative because the final query depends on the organization’s data connectors, schema, table or index names, field mappings, and selected Sigma processing pipeline.
Converting Sigma Rules
Browser-Based Conversion
Detection Studio provides a browser-based environment for working with and converting Sigma rules.
A typical workflow is:
Paste or open a Sigma YAML rule.
Select the destination platform or query language.
Apply an appropriate backend or pipeline when available.
Review the generated query.
Adapt it to the organization’s schema and data sources.
Test it against historical and simulated activity before deployment.
Sigma Command-Line Conversion
SigmaHQ also provides sigma-cli, which uses pySigma backends and pipelines to perform conversions.
Example Splunk conversion:
sigma plugin install splunk
sigma convert \
--target splunk \
--pipeline splunk_windows \
./rules/windows_defender_threat_detection_disabled.ymlSigma’s Important Limitation
Sigma improves portability, but it is not a universal one-click conversion mechanism. A syntactically valid converted query may still fail operationally because:
Field names differ between environments.
Required logs may not be collected.
Vendor schemas represent the same activity differently.
Table, index, and source names require local mapping.
Some target platforms do not support every Sigma feature.
Threshold, correlation, enrichment, and stateful logic may require additional implementation.
The converted query may produce different performance or alert volumes across platforms.
Therefore, every converted rule must be reviewed, mapped, tested, tuned, and validated within the target environment.
Add examples later:
Comments