hack3rs.ca network-security

/learning/threat-informed-defense-attack-technique-mapping :: module-11

student@hack3rs:~/learning$ open threat-informed-defense-attack-technique-mapping

Threat-Informed Defense Using ATT&CK-Style Technique Mapping

ATT&CK-style technique mapping connects your detections to adversary behaviors, surfaces telemetry gaps, and gives teams a shared language for coverage decisions. The goal is an honest map of what you can actually detect — not a green matrix that creates false confidence.

Isolated alerts answer narrow questions. A technique mapping approach lets defenders see whether their combined detection coverage actually addresses the attack paths that matter for their environment. It also changes conversations with leadership: instead of "we have 300 alerts," the discussion becomes "here is where we have strong coverage, here is where we are blind, and here is what changes that."

learning-objectives

$Map detections to adversary behaviors/techniques without overclaiming coverage.
$Differentiate prevention, detection, and investigative coverage.
$Identify telemetry dependencies for each detection claim.
$Prioritize coverage improvements using real environment risk and incidents.

example-dataflow-and-observation-paths

Trace each step and identify which log or capture point gives you evidence at that stage. Most triage mistakes happen when someone skips a hop and draws conclusions from an incomplete picture.

$Observed attack behavior from incident or intel -> analyst looks up the matching ATT&CK technique ID -> finds which existing detections cover that technique -> notes the telemetry source (Zeek conn.log, Windows Event 4688, etc.) -> records confidence: confirmed-tested, assumed-untested, or gap.
$Detection inventory audit: list all active rules -> map each to one or more technique IDs -> note the data source dependency -> if the data source is unavailable, the detection silently fails -> gaps with no detection and no telemetry are the highest priority.
$Incident closes with a gap confirmed -> create a backlog item: technique ID, missing telemetry or rule, owner, and test method -> when the fix is deployed, replay test traffic or a known-bad PCAP to confirm the detection fires before marking it closed.

baseline-normal-before-debugging

$Each coverage entry in the map names the specific data source (e.g., 'Zeek dns.log field: query') and the last date it was tested.
$After a detection is deployed, a PCAP replay or test event confirms the rule fires before the item is marked as covered.
$Coverage maps are updated within two weeks of any incident that exposed a gap.

Expert tip: Record what normal looks like in your actual environment before you test any edge case. A baseline you measured beats a baseline you assumed every time.

concept-breakdown-and-mastery

1. What Technique Mapping Is (and Is Not)

$ core idea: Technique mapping organizes your controls and detections against documented attacker behaviors. It helps with planning, gap analysis, and communication. It does not guarantee you will detect every implementation of a behavior — there are usually dozens of ways to achieve the same technique, and a detection written for one implementation may miss others.

$ defender angle: Avoid green matrix syndrome: marking a technique as "covered" because one generic alert exists. Real coverage depends on data quality, tuning quality, scope (which assets, which segments), and analyst ability to interpret the signal when it fires. Shallow coverage claims produce false confidence and no improvement.

$ prove understanding: Map detections to adversary behaviors/techniques without overclaiming coverage.

2. Building a Practical Coverage Map

$ core idea: For each detection, record: the behavior or technique it targets, the data sources it depends on, the scope (which assets or segments it covers), confidence level, known false-positive profile, and how the detection was tested. Coverage claims without those attributes are not auditable.

$ defender angle: Separate preventive controls, active detections, and investigative procedures. Blocking an action is not the same as detecting it — you cannot hunt with a block rule, and a blocked technique still needs investigation to understand scope and intent.

$ prove understanding: Differentiate prevention, detection, and investigative coverage.

3. Using Mapping to Drive Improvements

$ core idea: Most coverage gaps are telemetry gaps, not rule gaps. The fix is often enabling a log source, fixing a parsing error, or moving a sensor — not writing a new detection query. Identify the telemetry dependency before proposing a rule.

$ defender angle: Pair technique mapping with validation. Simulate authorized behavior in a lab, confirm that the expected telemetry appears, verify that the detection fires, and confirm that an analyst can triage the result correctly. Every mapped detection should have an associated validation approach.

$ prove understanding: Identify telemetry dependencies for each detection claim.

deep-dive-notes-expanded

Read each section, then immediately test the concept in your lab. Theory that you have not verified with a real command or log line does not stick.

1. What Technique Mapping Is (and Is Not)

Technique mapping organizes your controls and detections against documented attacker behaviors. It helps with planning, gap analysis, and communication. It does not guarantee you will detect every implementation of a behavior — there are usually dozens of ways to achieve the same technique, and a detection written for one implementation may miss others.

Avoid green matrix syndrome: marking a technique as "covered" because one generic alert exists. Real coverage depends on data quality, tuning quality, scope (which assets, which segments), and analyst ability to interpret the signal when it fires. Shallow coverage claims produce false confidence and no improvement.

Use technique mapping as a living model tied to actual evidence and test results, not a static slide updated once a year for a compliance review.

Normal Behavior

Each coverage entry in the map names the specific data source (e.g., 'Zeek dns.log field: query') and the last date it was tested.

Failure / Abuse Pattern

T1059 (Command and Scripting Interpreter) is marked as 'covered' in the map — but the detection depends on Windows 4688 logs that are not enabled on half the Windows fleet.

Evidence To Collect

Map detections to adversary behaviors/techniques without overclaiming coverage.

2. Building a Practical Coverage Map

For each detection, record: the behavior or technique it targets, the data sources it depends on, the scope (which assets or segments it covers), confidence level, known false-positive profile, and how the detection was tested. Coverage claims without those attributes are not auditable.

Separate preventive controls, active detections, and investigative procedures. Blocking an action is not the same as detecting it — you cannot hunt with a block rule, and a blocked technique still needs investigation to understand scope and intent.

Start with the techniques most relevant to your environment, your technology stack, and the incidents you have actually seen. A focused, well-evidenced coverage map for thirty relevant techniques is more useful than a shallow global matrix across hundreds.

Normal Behavior

After a detection is deployed, a PCAP replay or test event confirms the rule fires before the item is marked as covered.

Failure / Abuse Pattern

A detection rule is updated and the technique mapping is not — the coverage map claims T1071 is detected via HTTP inspection, but the updated rule only covers TLS-encrypted C2.

Evidence To Collect

Differentiate prevention, detection, and investigative coverage.

3. Using Mapping to Drive Improvements

Most coverage gaps are telemetry gaps, not rule gaps. The fix is often enabling a log source, fixing a parsing error, or moving a sensor — not writing a new detection query. Identify the telemetry dependency before proposing a rule.

Pair technique mapping with validation. Simulate authorized behavior in a lab, confirm that the expected telemetry appears, verify that the detection fires, and confirm that an analyst can triage the result correctly. Every mapped detection should have an associated validation approach.

Revisit your map after incidents and near misses. If analysts repeatedly need manual pivots to investigate a technique, that is a signal to improve enrichment, add companion detections, or fix a data quality problem upstream.

Normal Behavior

Coverage maps are updated within two weeks of any incident that exposed a gap.

Failure / Abuse Pattern

The coverage map is updated once per year during an audit — three incidents occurred in the gap, each exposing a technique that was not mapped until the annual update.

Evidence To Collect

Identify telemetry dependencies for each detection claim.

terminal-walkthroughs-with-example-output

Each walkthrough shows a command and what useful output looks like. Your lab output will differ — focus on which fields to read, not on matching the exact values shown here.

Coverage Mapping Workspace

Beginner

Command

mkdir -p coverage-map && cd coverage-map

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

$ why this matters: Run this against your lab environment and read the output field by field before moving on to the next command in this block. If you cannot explain what you see, re-read the section on coverage mapping workspace.

Detection Inventory Seed

Intermediate

Command

rg -n 'title:|name:' ../detections 2>/dev/null | head -20 || true

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

Gap Review Notes

Advanced

Command

printf 'Technique gaps:\nTelemetry gaps:\nValidation gaps:\n' > gap-review.txt

Example Output

# file created successfully

cli-labs-and-workflow

Run these in a lab VM or network segment you own or are authorized to test against. After each command, write down one thing the output told you that you did not already know.

Coverage Mapping Workspace

Beginner

mkdir -p coverage-map && cd coverage-map
printf 'technique,detection,data_source,scope,confidence,test_method\n' > coverage.csv
column -s, -t coverage.csv

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Detection Inventory Seed

Intermediate

rg -n 'title:|name:' ../detections 2>/dev/null | head -20 || true
jq '.[] | {name, data_sources}' detections.json 2>/dev/null | head

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Gap Review Notes

Advanced

printf 'Technique gaps:\nTelemetry gaps:\nValidation gaps:\n' > gap-review.txt
nano gap-review.txt

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

expert-mode-study-loop

$Explain the concept out loud as if briefing a colleague — no notes.
$Pick one CLI command and walk through exactly what the output means field by field.
$Name a specific failure mode and the log line or packet flag that reveals it.
$Write down what normal looks like for your lab before you introduce any anomaly.

Progress marker: Move on when you can brief the topic to someone else, run the commands from memory, and explain what a bad result looks like.

knowledge-check-and-answer-key

Answer each question out loud or in writing before you look at the hints. If you cannot answer it, go back to the section that covers it — do not just read the hint and move on.

1. What Technique Mapping Is (and Is Not)

Questions

?How would you explain "What Technique Mapping Is (and Is Not)" to a new defender in plain language?
?What does normal behavior look like for what technique mapping is (and is not) in your lab or environment?
?Which logs, packets, or commands would you use to validate what technique mapping is (and is not)?
?What failure mode or attacker abuse pattern matters most for what technique mapping is (and is not)?

Show answer key / hints

Answer Key / Hints

#Map detections to adversary behaviors/techniques without overclaiming coverage.
#Each coverage entry in the map names the specific data source (e.g., 'Zeek dns.log field: query') and the last date it was tested.
#mkdir -p coverage-map && cd coverage-map
#T1059 (Command and Scripting Interpreter) is marked as 'covered' in the map — but the detection depends on Windows 4688 logs that are not enabled on half the Windows fleet.

2. Building a Practical Coverage Map

Questions

?How would you explain "Building a Practical Coverage Map" to a new defender in plain language?
?What does normal behavior look like for building a practical coverage map in your lab or environment?
?Which logs, packets, or commands would you use to validate building a practical coverage map?
?What failure mode or attacker abuse pattern matters most for building a practical coverage map?

Show answer key / hints

Answer Key / Hints

#Differentiate prevention, detection, and investigative coverage.
#After a detection is deployed, a PCAP replay or test event confirms the rule fires before the item is marked as covered.
#rg -n 'title:|name:' ../detections 2>/dev/null | head -20 || true
#A detection rule is updated and the technique mapping is not — the coverage map claims T1071 is detected via HTTP inspection, but the updated rule only covers TLS-encrypted C2.

3. Using Mapping to Drive Improvements

Questions

?How would you explain "Using Mapping to Drive Improvements" to a new defender in plain language?
?What does normal behavior look like for using mapping to drive improvements in your lab or environment?
?Which logs, packets, or commands would you use to validate using mapping to drive improvements?
?What failure mode or attacker abuse pattern matters most for using mapping to drive improvements?

Show answer key / hints

Answer Key / Hints

#Identify telemetry dependencies for each detection claim.
#Coverage maps are updated within two weeks of any incident that exposed a gap.
#printf 'Technique gaps:\nTelemetry gaps:\nValidation gaps:\n' > gap-review.txt
#The coverage map is updated once per year during an audit — three incidents occurred in the gap, each exposing a technique that was not mapped until the annual update.

lab-answer-key-expected-findings

These are reference answers for a generic environment. Replace them with observations from your own lab — what you measured yourself is more useful than what is written here.

Expected Normal Findings

+Each coverage entry in the map names the specific data source (e.g., 'Zeek dns.log field: query') and the last date it was tested.
+After a detection is deployed, a PCAP replay or test event confirms the rule fires before the item is marked as covered.
+Coverage maps are updated within two weeks of any incident that exposed a gap.

Expected Failure / Anomaly Clues

!T1059 (Command and Scripting Interpreter) is marked as 'covered' in the map — but the detection depends on Windows 4688 logs that are not enabled on half the Windows fleet.
!A detection rule is updated and the technique mapping is not — the coverage map claims T1071 is detected via HTTP inspection, but the updated rule only covers TLS-encrypted C2.
!The coverage map is updated once per year during an audit — three incidents occurred in the gap, each exposing a technique that was not mapped until the annual update.

hands-on-labs

$Map five existing alerts to ATT&CK-style techniques and document their data source dependencies.
$Identify two techniques with weak coverage and propose telemetry or detection improvements.
$Create a coverage matrix that distinguishes prevention, alerting, and hunting-only visibility.

common-pitfalls

$Marking techniques as covered without testing or scope notes.
$Treating a framework as a mandate to monitor everything equally.
$Ignoring telemetry quality while focusing only on detection logic.

tools-and-references

completion-outputs

# A technique coverage map with confidence notes
# A telemetry dependency inventory for critical detections
# A prioritized coverage improvement roadmap

related-tool-guides

Each of these tools is directly relevant to the evidence collection or validation steps in this topic. Use them to close the gap between reading a concept and running it.

open /learning/tools/zeek Zeek

related-threat-pages

See where these fundamentals appear in real attack scenarios and what evidence defenders look for during triage.

open /threats/lateral-movement-after-initial-access Lateral movement after initial access open /threats/supply-chain-and-third-party-compromise Supply chain and third-party compromise

<- previous page Incident Response Playbooks Aligned to Recognized Cybersecurity Framework Functions -> next page Post-Incident Review, Hardening Backlog, and Detection Coverage Gaps

learning-path-position

Response & Improvement / Weeks 9-10 · Module 11 of 12