← Detection Engineering: From Telemetry to Tuned Detections
Foundations of Detection Engineering
What Is Detection Engineering? The Detection Engineering Lifecycle
Telemetry and Data Sources
Understanding Telemetry Sources Data Quality and Detection Blind Spots
Writing Detection Logic and Mapping Adversary Behavior
From Technique to Detection Logic MITRE ATT&CK Mapping for Detection Engineers
Testing, Tuning, and Reducing False Positives
Testing Detections with Adversary Emulation Tuning Detections and Reducing False Positives
Operating Detections in Production
Building a Sustainable Detection Program
Writing Detection Logic and Mapping Adversary Behavior

From Technique to Detection Logic

Learn a repeatable thought process for turning a threat technique into concrete detection logic, with a realistic example from technique to rule.

In this lesson, you will learn to:

  • By the end of this lesson, learners will be able to translate a threat technique into observable data requirements and design detection logic using a repeatable thought process.

From Technique to Detection Logic

This lesson teaches the core mental skill of detection engineering: translating an adversary technique into observable detection logic. Students walk through a realistic example from technique description to data fields to rule design.

The Thought Process: Technique to Observables

The core skill of detection engineering is translation: turning a description of attacker behavior into concrete, observable data requirements. This is not magic. It is a repeatable thought process.

The three-step translation process

When you encounter a new technique, follow these steps:

  1. Understand the technique. What is the attacker actually doing? What is the goal? What actions are required?
  2. Identify observables. For each action, ask what evidence it would create in logs or telemetry. Think about processes, files, network connections, identity events, and configuration changes.
  3. Select the strongest observables. Choose the evidence that is most specific and reliable. Avoid signals that are easy to trigger accidentally or easy for an attacker to change.
Why start with understanding?

If you skip understanding and jump straight to a known indicator, you create a brittle detection. Attackers change their tools, hashes, and IP addresses constantly. But the underlying technique changes much more slowly. A detection built on behavior outlasts a detection built on a specific artifact.

For example, a detection that looks for a specific malicious file hash will fail when the attacker changes one byte of the file. A detection that looks for suspicious process behavior associated with that file’s function will survive much longer.

Keep a notebook

As you read threat reports and incident summaries, keep notes on techniques and the telemetry they produce. Over time, you will build a personal library of technique-to-observable mappings. This library becomes your most valuable tool as a detection engineer.

Technique to Observable Translation FlowA light-theme flow diagram showing the three-step process from understanding a technique, to identifying observables, to selecting the strongest observables.From Technique to ObservablesA repeatable three-step translation processStep 1: Understand the TechniqueWhat is the attacker doing? What actions are required?Step 2: Identify ObservablesWhat evidence would each action leave in logs or telemetry?Step 3: Select the Strongest ObservablesChoose evidence that is observable, specific, and reliable
Technique to Observable Translation Flow — A light-theme flow diagram showing the three-step process from understanding a technique to selecting the strongest observables for detection.

A Realistic Example: Credential Dumping

Let us make the thought process concrete with a realistic example: credential dumping.

The technique

Credential dumping is an attacker technique in which the attacker extracts account passwords or password hashes from a compromised system. On Windows, tools such as Mimikatz can read credentials from memory. On Linux, attackers may read the /etc/shadow file or use tools that scrape process memory.

Step 1: Understand the actions

The attacker must first gain access to the system. Then they run a tool or command that accesses sensitive credential material. Finally, they may save the stolen credentials or send them to another system.

Step 2: Identify observables

What evidence might these actions leave?

  • Process creation events showing an unusual tool or command line.
  • Access to sensitive files such as the Windows SAM registry hive or Linux shadow file.
  • Memory access patterns from an unexpected process.
  • Network connections from the credential dumping tool to an external address.
  • Unusual parent process relationships, such as a service spawning a command shell.
Step 3: Choose the strongest observables

The strongest observables are those that are both visible in common telemetry and unusual in normal operations. For example, a command shell running with certain Mimikatz-specific command-line arguments is highly suspicious. Reading the SAM hive by a process other than the expected system service is also strong. A single generic process execution, however, is too weak on its own.

The output

After this analysis, you have a clear list of fields and values to include in a detection. You know which data sources to query and what combinations of evidence make a compelling alert. That is the translation from technique to detection logic.

From Observables to Rule Design

Once you have identified the strongest observables, the next step is designing the actual rule logic. This is where you decide how the pieces fit together.

Combining evidence

Most good detections combine multiple observables. A single suspicious command line may produce false positives. But that command line combined with an unusual parent process and an outbound network connection is much stronger.

Consider the credential dumping example. A rule might require:

  • A process creation event.
  • A command line matching known credential dumping patterns.
  • The process running under an unexpected account.

This combination narrows the detection to a meaningful subset of events while still catching variations of the technique.

Time windows

Many detections need a time window. For example, detecting a brute-force login attack is not about one failed login. It is about many failed logins from the same source within a short period. Defining the right time window is part of rule design. Too short a window misses slow attacks. Too long a window creates noisy aggregates.

Thresholds

Thresholds control how many occurrences are required before an alert fires. A threshold that is too low creates false positives. Too high creates false negatives. Choosing a threshold requires understanding normal behavior. Look at historical data to see how often the observables occur normally, then set the threshold above that baseline.

Logic structure

A useful way to think about rule structure is:

  • Filter: Narrow to the relevant event types and fields.
  • Condition: Specify the suspicious values or patterns.
  • Aggregation: Group related events by entity, such as user or host.
  • Threshold: Require a minimum count within a time window.

This structure works across most detection platforms and query languages. It turns a vague idea into a concrete, testable rule.

Rule Logic Structure: Filter, Condition, Aggregate, ThresholdA light-theme diagram showing the four-part structure of a detection rule: filter to narrow events, condition to match suspicious values, aggregation to group by entity, and threshold to require minimum count.A Simple Rule Logic StructureWorks across most detection platforms and query languagesFilterNarrow to relevant event types and fieldsConditionSpecify suspicious values or patternsAggregateGroup related events by entity, such as user or hostThresholdRequire a minimum count within a time windowThis structure turns a vague idea into a concrete, testable rule
Rule Logic Structure: Filter, Condition, Aggregate, Threshold — A light-theme diagram showing the four-part structure of detection rule logic: filter, condition, aggregation, and threshold.
← Previous: Data Quality and Detection Blind Spots Next: MITRE ATT&CK Mapping for Detection Engineers →