07 Detection Engineering

Welcome to:

Module 07 — Detection Engineering

In the previous modules, you learned how to:

Monitor
      ↓
Detect
      ↓
Hunt
      ↓
Respond
      ↓
Investigate
      ↓
Reconstruct

attacker activity. You now understand how adversaries may appear across:

Identity

Endpoint

Network

Cloud

Email

Applications

The next challenge is:

How Do We
Turn That Knowledge

Into Reliable
Security Detections?

This is the role of:

Detection Engineering

Detection engineering is the structured practice of converting:

Threat Behavior
      ↓
Observable Activity
      ↓
Security Telemetry
      ↓
Detection Logic
      ↓
Alert

into repeatable defensive capability.

The objective is not simply to create:

More Alerts

The objective is to create:

Useful

Reliable

Actionable

Testable

Maintainable

detections.

Module Objectives

By the end of this module, you will understand how to:

• explain detection engineering.

• understand the detection engineering lifecycle.

• identify detection requirements.

• create detection use cases.

• translate attacker behaviors into observables.

• identify required telemetry.

• design detection logic.

• understand query-based detection.

• understand rule-based detection.

• understand threshold detections.

• understand correlation detections.

• understand sequence detections.

• understand behavioral detections.

• understand risk-based detection.

• understand Sigma.

• understand portable detection logic.

• create Sigma-style detection rules.

• map detections to MITRE ATT&CK.

• understand detection coverage.

• build ATT&CK coverage matrices.

• identify detection gaps.

• identify telemetry gaps.

• test detections.

• perform positive and negative tests.

• understand false positives.

• understand false negatives.

• tune detection rules.

• manage exclusions.

• understand alert severity and confidence.

• create investigation guidance.

• measure detection quality.

• version detections.

• manage detection lifecycle.

• convert incidents into new detections.

• convert threat hunts into new detections.

• use threat intelligence to improve detections.

• understand detection-as-code concepts.

• document detections professionally.

1 — What Is Detection Engineering?

Detection engineering is the disciplined process of designing, building, testing and maintaining security detections.

A detection engineer asks:

What Threat
Do We Care About?

      ↓

What Behavior
Would It Produce?

      ↓

Which Telemetry
Would Capture It?

      ↓

What Logic
Could Detect It?

      ↓

How Do We
Validate It?

      ↓

How Do We
Maintain It?

2 — Detection Engineering vs SOC Monitoring

SOC monitoring focuses on:

Receiving

Triaging

Investigating

alerts.

Detection engineering focuses on:

Designing

Building

Testing

Improving

the logic that generates those alerts.

3 — Detection Engineering vs Threat Hunting

Threat hunting asks:

What Threat
Might Exist
That We
Did Not Detect?

Detection engineering asks:

How Can We
Reliably Detect
That Behavior
Next Time?

This creates:

Threat Hunt
      ↓
Behavior Identified
      ↓
Detection Engineering
      ↓
Automated Detection

4 — Detection Engineering Lifecycle

Use:

Threat Need
      ↓
Use Case
      ↓
Telemetry
      ↓
Detection Logic
      ↓
Build
      ↓
Test
      ↓
Deploy
      ↓
Monitor
      ↓
Tune
      ↓
Review
      ↓
Retire

5 — Start With the Threat

Do not begin with:

What Query
Can I Write?

Begin with:

What Threat
Do We Need
to Detect?

Example:

Threat:

Credential
Dumping

Then ask:

What Behavior
Would Indicate
Credential Dumping?

6 — Detection Use Case

A detection use case defines the defensive requirement.

Example:

DET-IAM-001

Detect Potential
Privileged Account
Compromise

A professional use case may include:

Use Case ID

Threat Scenario

Business Risk

ATT&CK Mapping

Required Telemetry

Detection Logic

Severity

Confidence

Known Benign Activity

Investigation Steps

Test Method

7 — Detection Requirement

A detection requirement should explain:

What Must
Be Detected

not exactly:

Which SIEM Syntax
to Use

Example:

Detect repeated
authentication failures
against multiple accounts
from the same source
within a short period.

This requirement can later be translated into different platforms.

8 — Threat to Observable

Detection engineering begins by translating attacker behavior into:

Observable
Activity

Example:

Threat:

Password Spray

Observable:

Same Source IP

Multiple Usernames

Authentication Failures

Short Time Window

9 — Observable to Telemetry

Then ask:

Which Data Source
Can Show
Those Observables?

For password spray:

Identity Logs

Fields might include:

Source IP

Username

Result

Timestamp

Application

10 — Detection Dependency Chain

A detection depends on:

Threat Behavior
      ↓
Telemetry Source
      ↓
Log Collection
      ↓
Parsing
      ↓
Fields
      ↓
Detection Logic

If any layer fails:

Detection
May Fail

11 — Telemetry First

Before building a rule, confirm:

Does Required
Telemetry Exist?

Is It Collected?

Is It Parsed?

Is It Timely?

Is It Complete?

12 — Detection Cannot Fix Missing Telemetry

If the requirement is:

Detect
PowerShell Execution

but process and PowerShell telemetry are not collected:

No Query
Can Reliably
Solve the Problem

This is:

Telemetry Gap

not simply a detection gap.

13 — Detection Logic

Detection logic describes:

Which Events

Which Conditions

Which Relationships

Which Thresholds

Which Time Window

should produce an alert.

14 — Simple Detection

Example:

IF

event_type =
admin_role_assignment

THEN

Alert

This is simple but may be noisy.

15 — Contextual Detection

Improved version:

IF

event_type =
admin_role_assignment

AND

target_environment =
production

AND

actor NOT IN
approved_admin_automation

THEN

Alert

16 — Query-Based Detection

Many SIEM detections are built as queries.

Conceptually:

Search Events

      ↓

Apply Conditions

      ↓

Group

      ↓

Calculate

      ↓

Alert

The exact query language depends on the platform.

17 — Detection Fields

Common identity fields:

User

Source IP

Destination

Device

Result

MFA Status

Role

Timestamp

Endpoint fields:

Process

Parent Process

Command Line

File

Hash

User

Host

Destination IP

18 — Field Quality Matters

Suppose your detection expects:

source_ip

but the parser incorrectly stores it as:

destination_ip

Your rule may:

Fail

or

Generate Wrong Alerts

Detection engineering therefore depends on good data engineering.

19 — Selection Logic

A detection may identify:

Events of Interest

using one or more conditions.

Example:

process_name = powershell.exe

20 — Filter Logic

Filters remove:

Known Expected
Activity

Example:

Exclude
Approved Deployment
Automation

21 — Avoid Broad Filters

Dangerous:

Exclude
All Administrator
Accounts

This may hide real attacks.

Filters should be:

Specific

Documented

Reviewed

22 — Threshold Detection

Example:

More Than
20 Failed Logins

By Same User

Within
5 Minutes

Useful for:

Brute Force

23 — Password Spray Threshold

Different logic may be required:

Same Source IP

      ↓

Failures Against
20 Different Users

      ↓

Within
10 Minutes

This shows why:

Grouping

is critical.

24 — Correlation Detection

Correlation combines events.

Example:

Failed Logins
      +
Successful Login
      +
Admin Role Assignment

within:

15 Minutes

25 — Sequence Detection

Sequence matters when order is important.

Example:

Phishing Delivery
      ↓
Suspicious Login
      ↓
Mailbox Rule

This may produce stronger evidence than individual events.

26 — Behavioral Detection

Behavior-based detections focus on attacker actions.

Example:

Office Process
      ↓
Scripting Interpreter
      ↓
External Connection

rather than:

Known Malware Hash

27 — Behavioral Detection Benefits

Attackers can change:

Hash

Domain

File Name

IP

but may still need to perform:

Execution

Persistence

Credential Access

Lateral Movement

Collection

28 — Risk-Based Detection

Risk-based models combine signals.

Example:

New Country
+20

Repeated MFA Denial
+30

New Admin Role
+50

Total:

100

may trigger:

High-Risk
Identity Alert

29 — Severity

Severity asks:

How Significant
Could the
Activity Be?

Example:

Credential Dumping
on Domain Controller

may have high severity.

30 — Confidence

Confidence asks:

How Strongly
Does the Detection
Suggest Malicious
Activity?

These should remain separate.

31 — Example

Detection:

Rare PowerShell
Command

may have:

Severity:
High

Confidence:
Low

depending on environment.

32 — MITRE ATT&CK Mapping

Map detections to relevant ATT&CK techniques.

Example:

Detection:
Suspicious PowerShell

      ↓

ATT&CK:
Execution

      ↓

Command and
Scripting Interpreter

33 — Why Map Detections to ATT&CK?

ATT&CK mapping helps with:

Coverage Analysis

Threat Modeling

Purple Team Testing

Detection Prioritization

Reporting

34 — Avoid ATT&CK Over-Mapping

Do not map a detection to every technique that sounds related.

Ask:

What Behavior
Can This Rule
Actually Observe?

35 — Detection Coverage

Detection coverage asks:

Which Relevant
Attacker Behaviors
Can We Detect?

36 — Coverage Matrix

Create:

Technique	Telemetry	Detection	Tested	Coverage
PowerShell	Endpoint	DET-END-001	Yes	Covered
Credential Dumping	Endpoint	DET-END-002	Yes	Covered
Scheduled Task	Endpoint	None	No	Gap
New Cloud Access Key	Cloud	DET-CLD-001	Partial	Partial

37 — Coverage Does Not Equal Effectiveness

Remember:

Detection Exists
      ≠
Detection Works

A rule may be:

Disabled

Broken

Too Noisy

Missing Data

Poorly Tuned

38 — Coverage Status

Use statuses such as:

Covered

Partially Covered

Detection Gap

Telemetry Gap

Not Applicable

Needs Validation

39 — Detection Gap

A detection gap exists when:

Threat Behavior
      ↓
Telemetry Exists
      ↓
No Detection Logic

40 — Telemetry Gap

A telemetry gap exists when:

Threat Behavior
      ↓
Required Telemetry
Unavailable

41 — Detection Validation

Validation answers:

Does the
Detection Actually
Work?

42 — End-to-End Validation

Simulated Behavior
      ↓
Telemetry Generated
      ↓
Collected
      ↓
Parsed
      ↓
Rule Matches
      ↓
Alert Generated
      ↓
Analyst Receives It

43 — Positive Test

A positive test asks:

Does Expected
Threat-Like Behavior
Generate an Alert?

44 — Negative Test

A negative test asks:

Does Similar
Benign Activity
Avoid Unnecessary
Alerting?

Both are important.

45 — Test Case

Create:

Detection_Test_Case.csv

with:

Test ID	Detection	Behavior	Expected Telemetry	Expected Result	Actual Result

46 — Example Positive Test

Detection:

New Privileged
Cloud Role

Test:

Create Approved
Test Role Assignment

Expected:

Cloud Audit Event
      ↓
Detection Match
      ↓
Alert

47 — Example Negative Test

Same detection.

Expected benign scenario:

Approved Automation
Creates Expected Role

The detection should behave according to the designed exception logic.

48 — Test Safely

Detection testing must occur in:

Authorized

Controlled

Approved

environments.

Do not perform unsafe attack activity against systems without authorization.

49 — Detection Test Failure

Possible causes:

No Telemetry

Parsing Error

Wrong Field

Incorrect Query

Threshold Problem

Rule Disabled

Alert Routing Failure

50 — False Positive

A false positive occurs when:

Detection
Incorrectly Identifies
Benign Activity
as Suspicious

51 — Benign True Positive

The rule correctly identifies the targeted behavior, but the behavior is:

Authorized

Example:

Approved
Penetration Test

52 — False Negative

A false negative occurs when:

Malicious Activity
Occurs

but

Detection
Does Not Trigger

53 — Why False Negatives Matter

False negatives may remain:

Invisible

unless discovered through:

Incident Response

Threat Hunting

Forensics

Purple Team Testing

54 — Causes of False Negatives

Examples:

Missing Telemetry

Threshold Too High

Rule Logic Wrong

Filter Too Broad

Attack Variation

Parsing Failure

55 — Detection Tuning

Tuning improves:

Signal
to
Noise

Possible tuning actions:

Adjust Threshold

Add Context

Improve Conditions

Use Asset Criticality

Use Identity Context

Narrow Exclusion

Add Sequence

56 — Bad Tuning

Bad approach:

Too Many Alerts
      ↓
Exclude Everything

This creates blind spots.

57 — Good Tuning

Example:

Instead of excluding all PowerShell:

Focus on:

Encoded Commands

Unusual Parents

Network Downloads

High-Risk Hosts

58 — Detection Exclusion Register

Create:

Detection_Exclusions.csv

with:

Detection	Exclusion	Reason	Owner	Expiration	Review

59 — Exclusions Need Governance

Every exclusion should answer:

Why Does It Exist?

Who Approved It?

When Should
It Be Reviewed?

Could It
Hide an Attack?

60 — Detection Quality

A good detection should be:

Relevant

Accurate

Actionable

Explainable

Testable

Maintainable

61 — Actionable Detection

An alert should tell the analyst:

What Happened?

Who?

Where?

When?

Why Alerted?

What Should
Be Checked Next?

62 — Alert Context

Useful alert fields:

User

Host

IP

Process

Resource

Timestamp

ATT&CK Technique

Detection Reason

Severity

Confidence

63 — Investigation Guidance

Each detection should ideally contain:

Investigation
Steps

Example:

Detection:

Privileged MFA
Fatigue

Investigation:

Review MFA Events

Check Source IP

Confirm User Activity

Review Authentication

Review Privilege Changes

Review Subsequent Actions

64 — Detection Runbook

A detection can connect to a runbook:

Alert
      ↓
Runbook
      ↓
Investigation

65 — Detection Documentation

Create:

Detection_Use_Case.md

with:

# Detection ID

# Detection Name

# Purpose

# Threat Scenario

# ATT&CK Mapping

# Required Telemetry

# Detection Logic

# Severity

# Confidence

# Known Benign Activity

# Exclusions

# Investigation Steps

# Validation Test

# Owner

# Version

# Status

66 — Detection Naming

Good:

Privileged Account
Added to
Administrative Group

Better than:

Rule 17

Names should explain:

What Behavior
Is Being Detected

67 — Detection IDs

Use consistent IDs.

Example:

DET-IAM-001

DET-END-001

DET-NET-001

DET-CLD-001

DET-EMAIL-001

68 — Detection Domains

Possible taxonomy:

IAM
Identity

END
Endpoint

NET
Network

CLD
Cloud

EMAIL
Email

APP
Application

69 — Detection Versioning

Track:

Detection ID

Version

Change

Reason

Date

Reviewer

70 — Detection Change Example

Version 1:

20 Failures
in 5 Minutes

Version 2:

10 Failures
in 5 Minutes
for Privileged Accounts

Document why.

71 — Detection Lifecycle Status

Possible:

Draft

Testing

Production

Tuning

Deprecated

Retired

72 — Detection Review

Review detections periodically for:

Alert Volume

False Positives

False Negatives

Last Triggered

Telemetry Health

ATT&CK Mapping

Threat Relevance

73 — Detection Debt

A SOC may accumulate:

Unused Rules

Broken Rules

Duplicate Rules

Unowned Rules

High-Noise Rules

This is:

Detection Debt

74 — Duplicate Detection

Two teams may create:

Suspicious PowerShell

and

Malicious PowerShell

with nearly identical logic.

Review for:

Duplicate

Overlap

Different Scope

75 — Detection Rationalization

Workflow:

Existing Rules
      ↓
Compare Objective
      ↓
Compare Logic
      ↓
Compare Telemetry
      ↓
Compare Alert Outcome
      ↓
Consolidate
Where Appropriate

76 — Detection-as-Code

Detection-as-code treats detection logic like software.

Principles may include:

Version Control

Peer Review

Testing

Automation

Change History

77 — Benefits

Detection-as-code can improve:

Consistency

Traceability

Review

Testing

Deployment

78 — Detection Repository

A simple repository might look like:

detections/
│
├── identity/
├── endpoint/
├── network/
├── cloud/
├── email/
└── tests/

79 — Rule Metadata

Each detection should include metadata such as:

Title

ID

Description

Author

Date

Status

ATT&CK

Data Source

80 — What Is Sigma?

Sigma is a generic, structured format for describing log-based detection rules.

It aims to make detection logic:

Portable

Readable

Shareable

across different security platforms.

81 — Sigma Concept

Instead of writing a detection only for one SIEM:

Threat Behavior
      ↓
Sigma Rule
      ↓
Platform-Specific
Query

82 — Basic Sigma Structure

Conceptually:

title: Suspicious PowerShell Execution
id: example-id
status: experimental

logsource:
  category: process_creation
  product: windows

detection:
  selection:
    Image|endswith:
      - '\powershell.exe'

  condition: selection

This is intentionally simple.

83 — Sigma Detection Section

The:

detection

section usually contains:

Selections

Filters

Condition

84 — Selection

Example:

selection:
  Image|endswith:
    - '\powershell.exe'

This identifies relevant events.

85 — Additional Behavior

Improve:

selection:
  Image|endswith:
    - '\powershell.exe'
  CommandLine|contains:
    - '-EncodedCommand'

Now the detection is more behavior-specific.

86 — Parent Process Logic

You could also consider:

ParentImage|endswith:
  - '\winword.exe'
  - '\excel.exe'

when detecting suspicious Office-to-PowerShell chains.

87 — Filters

Example conceptual filter:

filter_approved:
  User:
    - 'approved_automation_account'

Then:

condition: selection and not filter_approved

88 — Sigma Is Not Magic

A Sigma rule still depends on:

Correct Logs

Correct Fields

Platform Mapping

Testing

Tuning

89 — Portable Does Not Mean Identical

Different SIEM platforms may represent:

Process

Command Line

User

Event Type

differently.

Conversion requires validation.

90 — Sigma Rule Quality

A good Sigma-style rule should include:

Clear Title

Description

Log Source

Detection Logic

False Positives

ATT&CK Tags

Status

91 — Example Detection: Suspicious PowerShell

Threat scenario:

Attacker Uses
PowerShell
to Execute
Encoded Command

Telemetry:

Process Creation

Observable:

powershell.exe

EncodedCommand

92 — Sigma-Style Example

title: PowerShell With Encoded Command
status: experimental

logsource:
  category: process_creation
  product: windows

detection:
  selection:
    Image|endswith:
      - '\powershell.exe'
    CommandLine|contains:
      - '-EncodedCommand'
      - '-enc'

  condition: selection

falsepositives:
  - Administrative scripts
  - Approved automation

level: medium

93 — Detection Improvement

Add context such as:

Unusual Parent

Network Connection

Privileged User

Critical Asset

to improve prioritization.

94 — Detection: Password Spray

Requirement:

Detect repeated
authentication failures
against multiple accounts
from one source.

Logic:

Group by:
Source IP

Count:
Distinct Users

Condition:
High User Count

Window:
Short Period

95 — Detection: Brute Force

Logic differs:

Group by:
User

Count:
Failures

Within:
Short Period

96 — Detection: MFA Fatigue

Sequence:

Multiple MFA
Denials

      ↓

MFA Approval

Potential context:

New IP

New Device

Privileged User

97 — Detection: New Administrator

Telemetry:

Identity

Directory

Cloud IAM

Alert when:

Privileged Role
Assigned

Investigate:

Actor

Target

Approval

Source

Subsequent Activity

98 — Detection: Credential Dumping

Potential observable:

Unexpected Process

      ↓

Accesses
Credential Process

Context may include:

Process Path

Signer

User

Host

Command

99 — Detection: Scheduled Task Persistence

Detect:

New Scheduled Task

and prioritize when:

Suspicious Command

Rare User

Critical Host

Unusual Path

100 — Detection: Service Creation

Monitor:

New Service

Binary Path

Creator

Target Host

101 — Detection: C2 Beaconing

Potential analytics:

Same Host

Same Destination

Regular Intervals

Repeated Connections

102 — Detection: DNS Tunneling

Potential features:

Long Queries

High Entropy

High Frequency

Large Subdomains

Rare Domain

103 — Detection: Data Exfiltration

Consider:

Data Volume

Destination

User

Time

Asset

Historical Baseline

104 — Detection: Cloud Logging Disabled

High-value rule:

Audit Logging
Disabled
or
Modified

Investigate:

Actor

Resource

Source IP

Approval

Related IAM Changes

105 — Detection: Public Cloud Storage

Detect:

Storage Policy
Changed
      ↓
Public Access
Enabled

106 — Detection: Cloud Access Key Creation

Prioritize when:

Privileged Identity

Unexpected Source

New Key

Production Account

107 — Detection: Inbox Forwarding

Monitor:

New External
Mailbox Forwarding

especially after:

Suspicious Login

108 — Detection Correlation Across Domains

A powerful detection might combine:

Identity
Suspicious Login

      +

Endpoint
PowerShell

      +

Network
Rare Domain

This may produce higher confidence than any one signal.

109 — Multi-Stage Detection

You may identify:

Initial Access
      ↓
Execution
      ↓
Persistence

across several alerts.

This is sometimes called:

Attack Chain
Correlation

110 — Alert Prioritization

Prioritize using:

Detection Severity

Confidence

Asset Criticality

User Privilege

Threat Intelligence

Related Alerts

111 — Entity Risk

An entity may accumulate risk.

Example:

User A

Suspicious Login
+20

MFA Denial
+20

Privilege Change
+50

Total:

90

This can improve prioritization.

112 — Detection Analytics vs Static Rules

Static rule:

Hash =
Known Malware

Analytic detection:

Rare Process
      +
Unusual Parent
      +
External Connection

Both have value.

113 — Threat Intelligence-Driven Detection

Threat intelligence might identify:

Domain

Hash

Technique

Malware Family

Campaign

Translate this into:

IOC Rules

Behavior Rules

Hunts

Coverage Review

114 — Avoid Threat Feed Overload

Do not create:

Millions
of IOC Rules

without considering:

Freshness

Confidence

Relevance

Performance

115 — Incident-Driven Detection

After an incident:

Build Timeline

Identify Behaviors

Identify Missed Signals

Create Detection

116 — Example Incident Improvement

Incident reveals:

Mailbox Rule
Created
After Suspicious Login

New detection:

Suspicious Login
      ↓
Mailbox Rule
Within 30 Minutes

117 — Forensics-to-Detection

Forensics finds:

Scheduled Task

PowerShell

Rare Domain

Use these behaviors to build:

Detection Logic

118 — Hunt-to-Detection

Threat hunt identifies:

Low-and-Slow
Password Spray

Existing rule missed it.

Build detection using:

Distinct Users
by Source IP

119 — Purple Team Validation

Purple Team can safely simulate relevant techniques.

Workflow:

Technique
      ↓
Simulation
      ↓
Telemetry
      ↓
Detection
      ↓
SOC Investigation
      ↓
Gap Analysis

120 — Detection Metrics

Possible metrics:

Alert Volume

True Positive Rate

False Positive Rate

Detection Coverage

Time to Alert

Rules Tested

Rules Failing

Detection Gaps

121 — Metric Caution

A detection with:

Zero
False Positives

may simply:

Never Trigger

Metrics require context.

122 — Precision

Conceptually:

Of Alerts
Generated

How Many
Were Relevant?

123 — Recall

Conceptually:

Of Relevant
Threat Activity

How Much
Did We Detect?

Recall is harder to measure because:

Unknown Threats
May Never
Be Observed

124 — Detection Latency

Measure:

Activity Time
      ↓
Alert Time

A detection arriving hours later may not support timely response.

125 — Telemetry Latency

Sometimes the rule is fast but:

Logs Arrive
Late

This is a telemetry pipeline issue.

126 — Detection Health

Monitor:

Rule Enabled?

Rule Executing?

Data Source Healthy?

Alert Routing Working?

Last Triggered?

127 — Detection Health Dashboard

Create:

Detection_Health_Dashboard.md

with:

Production Rules

Rules Tested

Rules Failing

High-Noise Rules

Data Source Failures

Unowned Rules

Review Overdue

128 — Detection Review Questions

For every rule ask:

Does Threat
Still Matter?

Does Telemetry
Still Exist?

Does Logic
Still Work?

Is It Noisy?

Does SOC
Know How
to Investigate It?

129 — Detection Retirement

Retire when:

Technology Removed

Threat No Longer Relevant

Rule Replaced

Telemetry Removed

Document the reason.

130 — Detection Governance

A mature program defines:

Naming

IDs

Owners

Review

Testing

Change Approval

Versioning

Retirement

131 — Detection Change Review

Before changing logic, evaluate:

Why?

Expected Benefit?

False Positive Impact?

False Negative Risk?

Testing Required?

132 — Peer Review

Detection rules should ideally receive:

Technical Review

Threat Review

Data Review

Testing Review

before production deployment.

133 — Detection Testing Record

Create:

Detection_Test_Register.csv

with:

Detection	Version	Positive Test	Negative Test	Result	Reviewer

134 — Detection Gap Register

Create:

Detection_Gap_Register.csv

with:

Gap ID	Threat Behavior	ATT&CK	Telemetry	Detection	Gap Type	Priority

135 — Detection Inventory

Create:

Detection_Inventory.csv

with:

Detection ID	Name	Domain	ATT&CK	Telemetry	Owner	Status	Version

136 — ATT&CK Coverage Register

Create:

ATTACK_Detection_Coverage.csv

with:

Tactic	Technique	Relevant?	Telemetry	Detection	Tested	Coverage

137 — Detection Engineering Backlog

Maintain:

Threat

Requested Detection

Priority

Reason

Telemetry Readiness

Owner

Status

138 — Prioritize Detection Work

Use:

Threat Relevance

Business Impact

Asset Criticality

Current Coverage

Incident History

Threat Intelligence

not simply:

ATT&CK Technique Count

139 — High-Value Areas

Common high-value detection areas include:

Privileged Identity

Credential Access

Persistence

Lateral Movement

Cloud IAM

Security Disablement

Data Exfiltration

140 — Detection Engineering and AI

AI can assist with:

Query Drafting

Sigma Drafting

Rule Documentation

ATT&CK Mapping

Test Cases

False Positive Analysis

Detection Summaries

But:

AI-Generated Rule
      ≠
Production-Ready
Detection

141 — Validate AI Queries

AI may:

Use Wrong Field

Invent Event ID

Use Invalid Syntax

Misunderstand Platform

Always validate against:

Actual Schema

Real Telemetry

Test Dataset

142 — Validate AI ATT&CK Mapping

AI may over-map a rule.

Check:

What Behavior
Does the Rule
Actually Detect?

143 — AI and False Positives

AI can help brainstorm:

Possible
Benign Causes

But these must be validated against the actual environment.

144 — AI and Detection Documentation

AI is especially useful for drafting:

Description

Investigation Guidance

Test Plan

Change Summary

from validated technical information.

145 — Professional Detection Engineering Principle

The best detection is not the one with:

Most Complex Query

It is the one that:

Detects Relevant Threat

Uses Reliable Data

Produces Useful Alert

Can Be Tested

Can Be Investigated

Can Be Maintained

Practical Exercise 1 — Create a Detection Use Case

Build:

DET-IAM-001
Potential Password Spray

Document:

Threat

Observable Behavior

Telemetry

Fields

Logic

Time Window

Severity

Confidence

False Positives

Investigation Steps

Practical Exercise 2 — Build a Brute-Force Detection

Design a detection using:

User

Failed Login

Count

Time Window

Then explain why the same logic may not detect password spraying.

Practical Exercise 3 — Build a Sigma Rule

Create a Sigma-style rule for:

PowerShell
with
Encoded Command

Include:

Title

Log Source

Selection

Condition

False Positives

ATT&CK

Severity

Practical Exercise 4 — Improve the Sigma Rule

Add:

Parent Process

Critical Asset

Network Activity

as contextual enrichment.

Practical Exercise 5 — Build an Identity Correlation

Detect:

Multiple MFA Denials
      ↓
Successful MFA
      ↓
New Admin Role

within:

30 Minutes

Practical Exercise 6 — Build a Cloud Detection

Create:

DET-CLD-001
Cloud Logging Disabled

Document:

Telemetry

Event

Fields

Severity

ATT&CK

Investigation Steps

Practical Exercise 7 — Build a Detection Test

For your cloud rule define:

Positive Test

Negative Test

Expected Telemetry

Expected Alert

Pass Criteria

Practical Exercise 8 — Detection Gap Analysis

Create coverage for:

Credential Dumping

Scheduled Task

Remote Services

Cloud Role Assignment

Data Exfiltration

classifying:

Covered

Partial

Detection Gap

Telemetry Gap

Practical Exercise 9 — Detection Tuning

Given:

500 Daily
PowerShell Alerts

design a tuning plan using:

Parent Process

Command Line

User

Asset Criticality

Known Automation

Do not simply disable the rule.

Practical Exercise 10 — Build Detection Inventory

Create at least:

15 Detections

across:

Identity

Endpoint

Network

Cloud

Email

with IDs, owners, ATT&CK mapping and lifecycle status.

Knowledge Check

1. What is detection engineering?

2. How is detection engineering different from SOC monitoring?

3. How is detection engineering different from threat hunting?

4. What is the detection engineering lifecycle?

5. Why should detection design begin with a threat?

6. What is a detection use case?

7. What is a detection requirement?

8. What is an observable?

9. Why must telemetry be validated before building a detection?

10. What is a telemetry gap?

11. What is a detection gap?

12. What is threshold detection?

13. Why does event grouping matter?

14. How does password-spray detection differ from brute-force detection?

15. What is correlation detection?

16. What is sequence detection?

17. What is behavior-based detection?

18. What is risk-based detection?

19. What is detection severity?

20. What is detection confidence?

21. Why should severity and confidence remain separate?

22. Why map detections to MITRE ATT&CK?

23. Why should ATT&CK over-mapping be avoided?

24. What is detection coverage?

25. Why does coverage not prove effectiveness?

26. What is detection validation?

27. What is a positive test?

28. What is a negative test?

29. Why should both be performed?

30. What is a false positive?

31. What is a benign true positive?

32. What is a false negative?

33. What can cause false negatives?

34. What is detection tuning?

35. Why can broad exclusions be dangerous?

36. Why should exclusions be governed?

37. What makes an alert actionable?

38. What should investigation guidance contain?

39. What is detection debt?

40. What is detection rationalization?

41. What is detection-as-code?

42. Why is version control useful for detections?

43. What is Sigma?

44. Why is Sigma useful?

45. Does Sigma eliminate the need for testing?

46. What information should a Sigma rule contain?

47. What is detection latency?

48. What is telemetry latency?

49. What is detection health?

50. How can incidents improve detections?

51. How can threat hunts improve detections?

52. How can forensic findings improve detections?

53. How can Purple Team exercises validate detections?

54. How can AI support detection engineering?

55. Why must AI-generated detection rules be validated?

Key Takeaways

Detection engineering follows:

Threat
      ↓
Behavior
      ↓
Observable
      ↓
Telemetry
      ↓
Detection Logic
      ↓
Alert
      ↓
Investigation

The engineering lifecycle is:

Design
      ↓
Build
      ↓
Test
      ↓
Deploy
      ↓
Monitor
      ↓
Tune
      ↓
Review

Remember:

Rule Exists
      ≠
Rule Works

Telemetry Exists
      ≠
Detection Exists

Detection Exists
      ≠
Coverage Proven

Coverage Exists
      ≠
Detection Effective

Sigma Rule
      ≠
Production-Ready Rule

and:

AI-Generated Query
      ≠
Validated Detection

A mature detection engineering program creates the feedback loop:

Threat Intelligence
      ↓
Threat Hunting
      ↓
Detection
      ↓
Incident
      ↓
Forensics
      ↓
Detection Improvement

Career Connection

Detection engineering skills are valuable for:

Detection Engineers

SOC Analysts

Senior SOC Analysts

Threat Hunters

Blue Team Analysts

SIEM Engineers

Incident Responders

Security Engineers

During interviews, you should be able to explain:

How You Identify
a Detection Requirement

How You Select
Telemetry

How You Write
Detection Logic

How You Use
Sigma

How You Map
to ATT&CK

How You Test
a Rule

How You Tune
False Positives

How You Identify
Detection Gaps

How You Manage
the Detection Lifecycle

The key professional skill is not simply:

Writing
SIEM Queries

It is building a defensible chain:

Threat
      ↓
Telemetry
      ↓
Detection
      ↓
Testing
      ↓
Investigation
      ↓
Continuous Improvement

What’s Next?

➡️ Next: 08 — Purple Team Operations

You now know how to design, build and validate detections.

But the strongest question is:

Can Our
Detections Identify
Realistic Attacker
Behavior?

In the next module, you will connect offensive and defensive teams through:

Purple Team
Operations

You will learn how to:

Select Attack Techniques

Design Safe Simulations

Map ATT&CK Techniques

Define Expected Telemetry

Validate Logging

Validate Detection

Test SOC Investigation

Measure Detection Gaps

Improve Detection Logic

Retest Controls

The workflow becomes:

Attack Technique
      ↓
Controlled Simulation
      ↓
Telemetry
      ↓
Detection
      ↓
SOC Investigation
      ↓
Gap Analysis
      ↓
Detection Improvement
      ↓
Retest

You will move from:

We Built
a Detection

to:

We Tested
the Detection

We Know
What Works

We Know
What Fails

and

We Know
How to Improve It

➡️ Next: 08 — Purple Team Operations