Learn how professional defenders convert mission risks and defender questions into evidence-aware, behavior-focused, tested, tuned, documented, maintainable, and measurable detection capabilities using only invented data and safe conceptual logic.
Module Snapshot
Module
A5 Detection Engineering
Lessons
10 complete Advanced lessons
Assessment
25-question module test
Portfolio
Complete fictional detection package
Primary focus
Design, testing, tuning, and documentation
Evidence
Identity, endpoint, network, DNS, app, cloud, supplier
Professional skill
Translate risk into defender questions and logic
Safety model
Invented events and non-operational concepts only
Begin with the fictional mission risk and defender decision instead of copying an alert idea.
Document source health, field meaning, coverage, alternatives, confidence, and what the detection cannot prove.
Test, tune, document, approve, monitor, review, improve, and retire detections instead of optimizing only for fewer alerts.
Main Question
Detection engineering is not simply writing a condition that produces an alert. A professional detection must answer a useful defender question, rely on understood evidence, represent a clear behavior hypothesis, handle expected variation, survive missing or degraded data, support triage, protect privacy, and remain testable, explainable, maintainable, and owned.
Connect each fictional detection to a mission, asset, identity, service, trust boundary, policy, supplier, or recovery concern.
State which fictional question the alert helps answer and which evidence or analyst action must come next.
Measure fictional quality, review missed conditions, tune carefully, retest, document changes, and preserve residual risk.
Safety Boundary
This module includes
This module does not authorize
Professional Workflow
State which fictional asset, identity, service, workflow, trust boundary, policy, supplier, administrative function, or recovery outcome requires detection support.
Required output
Detection purpose and mission-risk statement
Describe exactly what a fictional defender needs to know, which decision the answer supports, and what the detection cannot prove by itself.
Required output
Defender-question and decision record
Identify fictional identity, endpoint, network, DNS, application, cloud, supplier, administrative, support, and source-health evidence with provenance, coverage, privacy, and limitations.
Required output
Data-source and evidence coverage map
Describe fictional expected behavior, meaningful deviation, sequence, relationship, identity, destination, time, frequency, privilege, and alternative explanations.
Required output
Behavior hypothesis and assumptions sheet
Define fictional conditions, required fields, time windows, sequences, counts, relationships, context, exclusions, missing-data behavior, severity, and confidence.
Required output
Detection-logic design specification
Build invented positive, negative, boundary, maintenance, change, degraded-source, privacy, edge, and regression cases with expected outcomes.
Required output
Synthetic test-data and expected-results package
Review fictional true alerts, expected alerts, false positives, false negatives, unknown outcomes, source-health failures, coverage gaps, and analyst usefulness.
Required output
Detection-quality and defect register
Add fictional identity, asset, service, peer, time, device, maintenance, change, source-health, and authorization context while avoiding broad suppression.
Required output
Tuning, enrichment, exception, and rollback plan
Record fictional ownership, purpose, evidence, logic, limits, privacy, severity, testing, response guidance, dependencies, lifecycle, and change history.
Required output
Detection specification and approval packet
Define fictional validation gates, observation periods, source-health monitoring, metrics, reviews, change triggers, reopened findings, retirement, and lessons learned.
Required output
Detection lifecycle and maintenance plan
Module Objectives
Objective 1
Explain detection engineering as a mission-driven process for converting risks and defender questions into tested, documented, maintainable, and reviewable detection capabilities.
Objective 2
Design a safe fictional detection scope covering assets, identities, users, devices, services, suppliers, trust boundaries, evidence sources, privacy, exclusions, and operational ownership.
Objective 3
Evaluate fictional data sources using provenance, field meaning, freshness, completeness, timing, coverage, transformation, duplication, source health, privacy, and failure behavior.
Objective 4
Translate fictional behavior hypotheses into conceptual detection logic using conditions, sequences, relationships, time windows, counts, context, exclusions, confidence, and missing-data handling.
Objective 5
Analyze fictional false positives, false negatives, expected alerts, unknown outcomes, blind spots, source-health failures, and labeling limitations without hiding uncertainty.
Objective 6
Tune fictional detections using identity, asset, service, device, peer, time, change, maintenance, authorization, source health, and mission context while preserving meaningful coverage.
Objective 7
Create safe fictional test plans with invented positive, negative, boundary, degraded-source, edge, privacy, change, maintenance, and regression cases.
Objective 8
Produce a portfolio-ready fictional detection-engineering package containing defender questions, source maps, logic, tests, tuning, documentation, metrics, residual risks, ownership, and leadership communication.
A5 Lesson Path
Each lesson uses fictional detection context, professional defensive reasoning, fake evidence, hidden-answer checks, safe testing, and one connected portfolio artifact.
A5.1
Lesson 1 of 10
Define detection engineering as a professional defensive discipline that turns mission risks, defender questions, data sources, behavior hypotheses, logic, testing, tuning, documentation, ownership, and lifecycle review into maintainable detection capabilities.
Core skills
Portfolio outcome
Create a fictional detection-engineering charter with mission questions, stakeholders, scope, evidence boundaries, and lifecycle responsibilities.
A5.2
Lesson 2 of 10
Examine fictional identity, endpoint, network, DNS, email, application, cloud, supplier, administrative, physical-context, and source-health data as evidence inputs with different strengths, gaps, privacy limits, ownership, and failure modes.
Core skills
Portfolio outcome
Build a fictional detection data-source catalog, provenance map, health matrix, privacy plan, and coverage-gap register.
A5.3
Lesson 3 of 10
Study how fictional detection logic combines conditions, sequences, counts, time windows, relationships, allow context, exclusions, confidence, severity, source health, and evidence requirements without turning conceptual training into operational attack guidance.
Core skills
Portfolio outcome
Produce a fictional detection-logic design sheet with hypotheses, conditions, windows, exclusions, source requirements, and validation criteria.
A5.4
Lesson 4 of 10
Learn to reason about fictional behavior patterns across identity, device, service, destination, time, sequence, frequency, privilege, change, peer context, baselines, and mission impact rather than relying only on static indicators.
Core skills
Portfolio outcome
Create a fictional behavior-detection hypothesis library and expected-versus-unusual behavior matrix.
A5.5
Lesson 5 of 10
Evaluate how fictional detections can alert on acceptable activity, miss meaningful conditions, overfit training data, rely on unhealthy sources, or create hidden coverage gaps—and how defenders review these outcomes responsibly.
Core skills
Portfolio outcome
Build a fictional detection-quality register with false-positive reviews, missed-condition reviews, root-cause hypotheses, and improvement actions.
A5.6
Lesson 6 of 10
Design fictional tuning around mission importance, identity, assets, service roles, time, peer groups, maintenance, change, geography concepts, device posture, source health, and expected workflows without suppressing risk blindly.
Core skills
Portfolio outcome
Create a fictional detection-tuning plan, contextual enrichment matrix, exception register, validation record, and rollback criteria.
A5.7
Lesson 7 of 10
Turn fictional alerts into structured defender questions about identity, device, service, destination, sequence, authorization, source health, scope, impact, ownership, alternatives, and next evidence instead of treating alert text as a conclusion.
Core skills
Portfolio outcome
Build a fictional alert-to-question matrix, evidence-request plan, triage handoff, and closure checklist.
A5.8
Lesson 8 of 10
Test fictional detection ideas using invented events, controlled expected outcomes, source-health variations, edge cases, negative cases, change scenarios, privacy checks, and regression records without touching real environments.
Core skills
Portfolio outcome
Produce a fictional detection test plan, synthetic event set, expected-results matrix, defect log, and regression record.
A5.9
Lesson 9 of 10
Create professional fictional documentation covering purpose, risk, defender question, data sources, fields, logic, assumptions, exclusions, severity, testing, tuning, ownership, privacy, dependencies, response guidance, lifecycle, and change history.
Core skills
Portfolio outcome
Create a fictional detection specification, analyst guide, owner record, change log, review checklist, and executive summary.
A5.10
Lesson 10 of 10
Integrate the complete A5 workflow in a safe fictional lab covering defender questions, risk, data sources, logic, behavior, false positives, false negatives, tuning, testing, documentation, ownership, validation, and executive communication.
Core skills
Portfolio outcome
Produce a complete fictional detection-engineering package and leadership-ready improvement plan.
Fictional Evidence Preview
Observation
A student-support platform depends on employee identities, service identities, remote support, supplier results, notifications, DNS, wireless service devices, administrative changes, monitoring, and recovery workflows.
Supports
Detection questions should cover identity, service, supplier, administrative, naming, wireless, evidence, and recovery behavior rather than one generic alert stream.
Does not prove
The brief does not prove which data sources exist, which behaviors are detectable, or which events indicate harmful activity.
Detection-design use
Use it to define detection priorities, stakeholders, defender questions, ownership, and evidence needs.
Observation
Identity, network, DNS, application, wireless, remote-access, supplier, and source-health evidence exists, but field quality and retention differ.
Supports
Detection design must document which source can answer which question and how source health affects confidence.
Does not prove
The inventory does not prove complete coverage, correct normalization, current events, or reliable correlation.
Detection-design use
Create provenance, field, freshness, coverage, privacy, and blind-period requirements.
Observation
One administrative detection creates many alerts during approved maintenance, while a separate missed case involved a stale emergency role after an exercise.
Supports
Tuning must consider maintenance context without suppressing lifecycle and revocation risk.
Does not prove
The review does not prove the noisy alerts are useless or that one missed case represents the entire detection's coverage.
Detection-design use
Design positive, negative, maintenance, expiration, source-degraded, and regression tests.
Observation
A network event stream remained connected while freshness exceeded the approved range and application correlation was delayed.
Supports
Detection logic and alert confidence need explicit source-health and missing-context behavior.
Does not prove
Delayed evidence does not prove event loss, manipulation, normal behavior, or harmful behavior.
Detection-design use
Define Degraded states, alternate evidence, confidence changes, and analyst guidance.
Observation
A workflow service reached a new destination after a deployment, one supplier session occurred outside its usual window, and one wireless service device changed network class.
Supports
Behavior detections need change, identity, destination, time, class, ownership, authorization, and alternative-explanation context.
Does not prove
The differences do not prove compromise, misuse, or unacceptable activity.
Detection-design use
Write defender questions and conceptual logic that preserves uncertainty.
Observation
The initial logic detected all supplied positive cases but also alerted on approved recovery activity and failed when one required field was missing.
Supports
Coverage, precision, degraded-source behavior, recovery context, and missing-data handling require improvement.
Does not prove
A small synthetic test set does not prove performance across all future cases.
Detection-design use
Expand negative, boundary, recovery, missing-field, and regression tests before approval.
Detection Quality Preview
Which fictional mission risk and defender question does the detection address?
Which fictional sources and fields support the logic, and how healthy are they?
Which fictional sequence, relationship, state, or deviation is being evaluated?
Which fictional true, expected, false-positive, false-negative, or unknown outcomes occurred?
Which fictional identity, asset, service, peer, time, change, maintenance, or authorization details matter?
Which fictional analyst question, evidence request, triage step, or escalation follows?
Who owns fictional testing, tuning, documentation, review, change, and retirement?
What can the fictional detection not prove, and which residual risks remain?
Portfolio Outcome
By the end of A5, you will have one connected fictional package showing how a professional defender moves from mission risk and evidence to behavior hypotheses, logic, testing, tuning, documentation, quality review, ownership, and leadership communication.
Artifact 1
Fictional detection-engineering purpose, mission risk, stakeholders, scope, exclusions, authorization, and safety boundary
Artifact 2
Asset, identity, service, supplier, administrative, wireless, DNS, evidence, and recovery detection-priority map
Artifact 3
Defender-question catalog with decision use, non-proof statement, evidence needs, owner, priority, and review trigger
Artifact 4
Data-source inventory with provenance, fields, freshness, completeness, timing, schema, transformation, duplication, coverage, privacy, and source health
Artifact 5
Behavior-hypothesis library with expected state, meaningful deviation, identity, destination, sequence, time, peer context, alternatives, and confidence
Artifact 6
Conceptual detection-logic specifications with conditions, windows, counts, sequences, relationships, exclusions, missing-data behavior, severity, and limits
Artifact 7
False-positive, false-negative, expected-alert, unknown-outcome, source-degraded, and coverage-gap review register
Artifact 8
Detection-tuning and contextual-enrichment plan with owners, evidence, exceptions, expiration, validation, metrics, and rollback
Artifact 9
Alert-to-defender-question matrix with evidence requests, triage context, escalation criteria, unresolved states, and closure requirements
Artifact 10
Synthetic detection-test package with invented positive, negative, boundary, maintenance, change, degraded-source, privacy, edge, and regression cases
Artifact 11
Detection documentation packet with purpose, sources, logic, assumptions, severity, testing, tuning, response guidance, privacy, ownership, dependencies, and lifecycle
Artifact 12
Detection-quality metrics plan covering coverage, precision, noise, missed conditions, source health, analyst usefulness, review time, and residual risk
Artifact 13
Multidisciplinary detection-review findings, disagreement log, owner actions, completion criteria, validation results, and reopened issues
Artifact 14
Leadership summary, technical appendix, analyst guide, portfolio reflection, and complete fictionalization statement
Detection Risk Preview
Why it is risky
Starting with a fictional alert title or product feature before defining the mission risk and defender question.
Professional correction
Trace every detection from mission and asset to behavior hypothesis, evidence source, logic, test, alert, decision, and owner.
Why it is risky
Assuming a fictional log source is useful because it exists, even when fields, freshness, timing, coverage, provenance, or source health are weak.
Professional correction
Document required fields, meaning, health, blind periods, transformations, privacy, and confidence effects.
Why it is risky
Treating fictional unusual timing, destinations, identities, devices, or sequences as malicious without change, maintenance, assignment, recovery, or peer context.
Professional correction
Use behavior hypotheses, alternative explanations, authorization evidence, confidence, scope, and mission impact.
Why it is risky
Suppressing fictional alerts broadly until volume falls, without measuring missed conditions, coverage loss, stale exceptions, or lifecycle gaps.
Professional correction
Tune narrowly with context, owners, expiration, tests, rollback, and false-negative review.
Why it is risky
Assuming a fictional detection is complete because it passes a small set of invented positive examples.
Professional correction
Use positive, negative, edge, maintenance, change, missing-field, degraded-source, privacy, and regression cases with documented limits.
Why it is risky
Treating a fictional High alert as more important than a lower-severity condition involving privileged identity, critical assets, confirmed impact, or weak recoverability.
Professional correction
Prioritize using mission, identity, asset value, evidence, scope, impact, source health, and recoverability.
Why it is risky
Creating fictional detections without current purpose, fields, logic, assumptions, testing, tuning, ownership, response guidance, or retirement criteria.
Professional correction
Make documentation and approval part of the design and lifecycle, not an optional final task.
Why it is risky
Using real logs, identities, domains, addresses, alerts, supplier activity, internal behavior, or incident records in a public learning artifact.
Professional correction
Invent every organization, source, identity, event, field, rule, alert, test, owner, date, decision, and outcome from scratch.
Module Test
Complete a 25-question hidden-answer assessment covering detection data sources, provenance, behavior hypotheses, conceptual logic, false positives, false negatives, tuning, context, defender questions, safe testing, documentation, source health, privacy, ownership, metrics, and lifecycle decisions.
Every answer remains hidden until the student chooses to reveal it.
The assessment covers the complete A5 Detection Engineering pathway.
Questions measure evidence-aware defensive judgment rather than memorized alert terms.
Module Navigation
Start with A5.1 to learn why detection engineering begins with mission risks and defender questions—not alert volume, product features, or copied rules.