Lesson A19.6
A strong detection plan explains what defenders want to observe, why the signal matters, which evidence sources support the decision, how alerts should be reviewed, and how the plan will be validated and improved over time.
This lesson stays entirely defensive and synthetic. You will design detection logic conceptually from fictional Northbridge evidence. You will not probe systems, collect real logs, test credentials, bypass controls, or learn techniques for avoiding detection.
Lesson Progress
High School Advanced • A19: Cybersecurity Portfolio Projects • Lesson 6 of 10
Readiness Check
0/4 ready
Professional Hook
Risk assessment tells an organization what deserves attention. Detection planning asks a related question: what evidence would help defenders recognize that an important condition is changing? If a privileged role changes, a critical telemetry source stops reporting, or a shared service begins falling outside its expected health range, defenders need reliable evidence before they can make a sound decision.
Detection is not about collecting every possible event. It is about building useful visibility around important risks. A good plan explains the security question, the evidence sources, the context needed for triage, the expected alert behavior, the decision owner, and how the team will know whether the detection remains useful.
Learning Objectives
Explain what a defensive detection plan is, how it connects risk to observable evidence, and why detection is different from prevention, investigation, and response.
Identify useful fictional telemetry sources, detection objectives, signals, context, enrichment, ownership, and evidence limitations without teaching evasion or offensive testing.
Distinguish alert severity, confidence, priority, false positives, duplicate signals, missing telemetry, and evidence quality when reviewing a detection design.
Design safe validation and tuning activities using only synthetic records, including success criteria, rollback conditions, review metrics, and documented assumptions.
Create a portfolio-ready Detection Plan Project that communicates what defenders want to observe, why it matters, how alerts should be handled, and how the plan will be reviewed over time.
Core Teaching
A detection plan is a design document for defensive visibility. It describes a condition worth observing and the evidence that could help defenders recognize that condition. Unlike prevention, which tries to stop an unwanted action, detection helps the organization notice and interpret evidence. Unlike incident response, detection does not by itself decide the full response. It supplies information that supports later review and action.
A detection plan should start with something defenders need to know, such as whether a privileged role changed unexpectedly, whether an important service became unavailable, or whether an identity workflow departed from an approved pattern.
Logs, alerts, health records, identity events, and application records are evidence sources. One record rarely proves the full story. A strong plan states what each source can support and what it cannot prove by itself.
The same event can have different significance depending on asset importance, identity role, time, ownership, expected workflow, prior changes, recovery state, and related evidence.
An alert is useful when it helps a defender choose a safe next step: review evidence, confirm ownership, escalate, preserve records, validate recovery, or close a benign event with a documented reason.
A plan that generates many low-value alerts can hide important signals. Defenders therefore measure relevance, duplication, missing context, investigation effort, and whether the alert actually supports a decision.
Reducing noise should not mean weakening visibility blindly. Changes should be bounded, justified, reversible, validated with synthetic evidence, and reviewed after deployment.
Plan Anatomy
What defensive question should this plan help answer?
Fictional example: Can defenders identify an unexpected change to a fictional privileged role quickly enough to review it?
What system, identity, data, process, or business function makes the signal important?
Fictional example: Admin Review Console ADM-NB-2 and the integrity of protected configuration.
Which synthetic evidence sources could support the decision?
Fictional example: Identity audit events, approval records, admin-console activity, and role-review records.
What high-level condition would make the evidence worth reviewing?
Fictional example: A privileged membership change appears without the expected matching approval context.
What information helps distinguish expected from concerning activity?
Fictional example: Role owner, change ticket, approved maintenance window, identity type, and related administrative activity.
How important is the possible impact, and how strongly does the evidence support the interpretation?
Fictional example: High potential impact but Moderate confidence until approval and ownership evidence are correlated.
What safe defensive review should happen first?
Fictional example: Confirm the fictional role owner, correlate approval evidence, review related synthetic events, and document the result.
When should the alert move to a higher level of attention?
Fictional example: Escalate if the change affects a critical role and cannot be matched to approved ownership or change evidence.
How will the team know the detection behaves as intended?
Fictional example: Replay supplied synthetic examples representing approved, suspicious-looking, and ambiguous cases, then compare expected outcomes.
Who maintains the plan, and when should it be reassessed?
Fictional example: Security Monitoring Lead, with review after material system changes and at a scheduled governance checkpoint.
Evidence Reasoning
One of the most important detection skills is knowing what evidence can and cannot prove. A login record may show that an authentication event occurred. It may not prove why the person logged in, whether the action was approved, or what happened afterward. An application alert may show a pattern worth reviewing, but the surrounding identity, asset, ownership, and change context may determine whether the activity is expected.
A synthetic record directly shows an event or state, such as a role membership change or source-health status.
Another independent source supports the same interpretation, such as an approval record matching an identity event.
Ownership, asset importance, maintenance windows, expected workflows, or change records explain how the event should be interpreted.
A source, timestamp, owner, or expected record is missing. The gap changes confidence but does not automatically prove the worst case.
Signal Quality
How often the alert represents something that actually deserves defensive review in the defined fictional environment.
Review question: Does this detection help answer a meaningful security question, or does it mostly create work?
Whether the alert contains the identity, asset, ownership, timing, approval, and related evidence needed for triage.
Review question: Can a defender understand why the event matters without searching through many unrelated records?
Whether several alerts represent the same underlying activity and should be grouped or correlated.
Review question: Are repeated notifications adding new evidence, or simply repeating the same signal?
Whether the expected telemetry sources and important scenarios are represented in the plan.
Review question: Which defensive situations could be missed if a source is unavailable or a workflow changes?
Whether evidence arrives soon enough to support the intended decision.
Review question: Would a delayed signal still be useful for triage, containment planning, or recovery validation?
Whether the plan makes clear why an alert exists and what evidence caused it.
Review question: Can a reviewer trace the alert back to a risk, asset, signal, and decision?
Severity, Confidence, Priority
How serious the potential consequence could be if the alert represents a real problem.
Example: A change to a privileged administrative role may have high potential impact.
How strongly the available evidence supports the interpretation that the alert represents the condition of concern.
Example: Confidence may be Moderate until approval, ownership, and related activity are correlated.
How quickly the organization should act after considering severity, confidence, asset importance, timing, dependencies, and current workload.
Example: A high-severity, moderate-confidence alert on a critical service may still receive high review priority.
Fake Dashboard
Synthetic portfolio dashboard summarizing six fictional detection plans.
Detection plans
6
Each plan maps to a risk from the fictional A19.5 assessment
Telemetry groups
8
Identity, application, approval, workload, queue, monitoring, lifecycle, and recovery evidence
Validation cases
5
Approved, ambiguous, duplicate, maintenance, and missing-context synthetic scenarios
Open review issues
3
Ownership enrichment, source freshness, and duplicate grouping need continued tuning review
Fake SOC Alert
Source: Northbridge Identity Monitoring • Time: Synthetic review window
Fake Log Panel
[DET-301] privileged-role-change recorded for fictional role ADM-REVIEWER [CTX-301] approval reference not attached to initial alert payload [OWNER] identity governance owner exists in synthetic inventory [DET-303] source-health heartbeat delayed beyond fictional freshness target [MAINT] no matching maintenance record in supplied evidence set [DET-305] queue backlog increased while worker health remained normal [CORR] two application alerts refer to the same synthetic event window [SAFETY] records are fictional and intended only for defensive portfolio analysis
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Fictional Case
Each plan below maps back to a risk from A19.5. The portfolio value comes from showing why the signal matters, what evidence supports it, what context is required, how triage remains safe, and how the plan will be validated.
Objective: Identify fictional privileged-role changes that lack the expected approval or lifecycle context.
Sources
Identity audit record, approval record, role-owner record, admin-console activity
Signal
A privileged membership change is recorded and the synthetic evidence set does not contain the expected matching approval context.
Required Context
Role sensitivity, identity type, change owner, maintenance window, previous membership state
Rating
Severity: High · Confidence: Moderate until correlated
Triage
Confirm role ownership, correlate approval evidence, review nearby synthetic administrative events, and record the decision.
Validation
Use approved synthetic examples for authorized changes, ambiguous changes, duplicate records, and missing approval context.
Quality Metric
Percent of alerts with complete ownership and approval context at first review
Objective: Surface unusual fictional authorization decisions around protected profile resources without assuming authentication alone proves appropriate access.
Sources
API authorization events, identity context, application audit records
Signal
A protected-resource request produces an authorization outcome that differs from the expected fictional resource-access pattern.
Required Context
Identity role, resource classification, expected application workflow, recent approved changes
Rating
Severity: High · Confidence: Moderate
Triage
Review synthetic authorization evidence, confirm expected role-to-resource relationship, and escalate if ownership cannot explain the decision.
Validation
Use only supplied synthetic allowed, denied, changed-role, and ambiguous examples.
Quality Metric
Decision-support rate: alerts that contain enough context for a reviewer to classify the event without unnecessary follow-up
Objective: Identify when an expected fictional telemetry source is delayed, missing, or outside its documented freshness expectation.
Sources
Source-health heartbeat, ingestion status, synthetic timestamp comparison
Signal
An expected source does not report within its fictional freshness window or reports inconsistent health status.
Required Context
Source owner, expected cadence, maintenance status, dependent detections
Rating
Severity: Medium · Confidence: High for source-health state, lower for security meaning
Triage
Confirm the source-health condition, identify dependent detections, document reduced visibility, and notify the fictional owner.
Validation
Compare normal synthetic heartbeats with delayed and maintenance-window examples.
Quality Metric
Time to identify and document a visibility gap affecting dependent detections
Objective: Surface fictional service-identity behavior that falls outside the documented workload purpose or approved change context.
Sources
Service identity events, workload audit records, approved deployment notes
Signal
The worker identity performs an action category not represented in its approved synthetic workload profile.
Required Context
Workload owner, deployment window, service role purpose, application dependency
Rating
Severity: High · Confidence: Moderate
Triage
Correlate the event with synthetic deployment and workload records, confirm ownership, and document whether the behavior is expected.
Validation
Use synthetic normal-workload, approved-change, and unexpected-category examples without executing anything.
Quality Metric
Percent of service-identity alerts correctly enriched with workload owner and deployment context
Objective: Identify fictional queue conditions that could affect time-sensitive processing and recovery readiness.
Sources
Queue health metrics, worker health, application status, synthetic recovery records
Signal
Backlog, processing delay, or worker health departs from the documented fictional service-health range.
Required Context
Maintenance status, business period, worker availability, recovery owner
Rating
Severity: Medium · Confidence: High for health condition
Triage
Confirm service-health evidence, correlate worker status, notify the fictional operations owner, and track recovery validation.
Validation
Use synthetic normal-load, maintenance, delayed-processing, and recovery examples.
Quality Metric
Time from source-health change to owner notification and recovery-status documentation
Objective: Identify fictional federation relationships or role mappings that remain active beyond their documented business lifecycle.
Sources
Relationship inventory, role mapping record, lifecycle review record, identity governance event
Signal
A relationship status changes while associated trust or mapping records remain marked active in the synthetic evidence set.
Required Context
Relationship owner, contract lifecycle state, mapped roles, last review date
Rating
Severity: High · Confidence: Moderate
Triage
Confirm relationship ownership and lifecycle evidence, review associated mappings, and route the finding to the fictional identity-governance owner.
Validation
Use synthetic active, changed, expired, and owner-unknown relationship records.
Quality Metric
Percent of lifecycle alerts with a named owner and disposition documented
Analyze the Evidence
Tuning
Detection tuning is the process of improving how alerts support defenders. The goal is not simply fewer alerts. The goal is better relevance, context, grouping, coverage, and decision support while preserving the ability to recognize important conditions.
If an alert is noisy because it lacks context, first consider whether ownership, maintenance, identity, asset, or approval data can make the alert more useful.
Several records about one activity can often be grouped into one case while preserving the underlying evidence and timestamps.
If a clearly approved synthetic pattern should not alert, document the exact reason, scope, owner, expiration, and review condition rather than creating a broad permanent exception.
A tuning change should be reversible. Record what changed, why, who approved it, what success looks like, and what evidence would trigger rollback.
Review whether relevance, context completeness, duplicate rate, investigation effort, or coverage improved without creating unacceptable blind spots.
Detection tuning exists to improve defensive signal quality. It should never provide instructions for avoiding detection, bypassing controls, or hiding harmful activity.
Safe Validation
A detection plan should be validated before a team trusts it. In this portfolio, validation means comparing the plan against supplied fictional records and checking whether the expected decision occurs. Nothing is executed against a live environment.
Expected behavior: The plan should either remain quiet or provide low-friction context showing the approval and owner, depending on the documented design.
Synthetic evidence: Synthetic identity event plus matching approval, role owner, and maintenance record.
Expected behavior: The plan should create a reviewable signal with the role, identity, timestamp, and missing-context status visible.
Synthetic evidence: Synthetic identity event with no matching approval in the supplied evidence set.
Expected behavior: The plan should preserve the underlying evidence while avoiding unnecessary duplicate analyst work.
Synthetic evidence: Two synthetic sources describing the same approved event.
Expected behavior: Source-health logic should distinguish a known fictional maintenance window from an unexplained visibility gap.
Synthetic evidence: Synthetic maintenance record plus source-health status.
Expected behavior: The plan should maintain bounded confidence and request ownership or deployment context rather than assuming malicious intent.
Synthetic evidence: Synthetic workload event with incomplete change context.
Metrics
What percentage of reviewed alerts represented conditions that actually deserved analyst attention in the synthetic evaluation set?
How often did the alert include enough ownership, asset, identity, timing, and approval context for first-pass review?
How many alerts represented the same underlying activity and could be grouped without losing useful evidence?
How long did the fictional workflow take from alert creation to a documented triage conclusion?
Which important risks and workflows have observable evidence, and where are the known visibility gaps?
Did a tuning change improve relevance or analyst effort without creating unacceptable loss of coverage?
Common Mistakes
First define the risk, asset, and decision. Then choose evidence sources that can help answer that question.
A potentially serious event can still have limited evidence confidence. Record severity and confidence separately.
High volume can increase fatigue and hide meaningful signals. Measure usefulness, context, duplication, and decision support.
Review why the alert fires, add context, group duplicates, or create bounded exceptions before considering broader suppression.
A detection plan depends on telemetry. Missing or delayed sources should be visible because they change evidence confidence and coverage.
Student portfolio work should use synthetic events and safe fictional scenarios only.
Safe Fictional Lab
Choose three of the six Northbridge plans. Your goal is to improve the documentation and decision support using only the supplied synthetic evidence.
For each chosen plan, write the exact defensive question the alert is supposed to help answer and name the linked risk.
List the direct, corroborating, and context evidence used by the plan. Add one known evidence limitation.
Identify one ownership, asset, approval, change, or lifecycle field that would make first-pass triage easier.
Assign severity, confidence, and priority separately and explain why the three values may differ.
Write one expected, one ambiguous, and one review-worthy synthetic scenario and describe the alert behavior you expect.
Choose two metrics that would show whether the detection is helping defenders make better decisions.
Scenario Decision Lab
A fictional privileged-role alert fires often during approved maintenance because the first version lacks change-window and approval context.
Scenario Decision Lab
A synthetic application source stops meeting its freshness expectation, and three fictional detections depend on that data for context.
Advanced Challenge
Explain the objective, telemetry, context, signal quality, validation cases, metrics, and tuning boundaries.
Explain what the alert can establish, what remains uncertain, which evidence should be correlated, and when escalation is justified.
Explain how the project demonstrates risk-to-detection mapping, evidence discipline, safe validation, measurement, communication, and governance.
Defender Habits
Assessment
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a polished fictional Northbridge Detection Plan Project. Include three to six detection objectives mapped to A19.5 risks, protected assets, telemetry sources, high-level signal conditions, required context, severity and confidence, safe triage actions, escalation criteria, synthetic validation cases, quality metrics, tuning and rollback guidance, ownership, known evidence gaps, and a short publication-safety statement.
Confidence / Readiness Reflection
A19.7 moves into the Security Policy Draft Project. Before continuing, make sure you can explain how risk, detection, ownership, escalation, evidence, and review expectations can be translated into clear policy requirements without turning policy into vague slogans or overly technical procedures.
I can explain how a detection plan connects a risk to observable evidence.
I can distinguish telemetry, an alert, a finding, and a confirmed incident.
I can explain severity, confidence, and priority separately.
I can describe safe validation and tuning using synthetic evidence, metrics, and rollback.
I can explain why source health and evidence limitations belong in the final detection plan.
Portfolio Build Guide
A reviewer should be able to trace why the detection exists and which business or security concern it supports.
IDs help connect plan entries, alerts, validation cases, tuning notes, and portfolio revisions.
State which records are present before explaining what they may mean. This keeps confidence honest.
List the ownership, asset, identity, approval, timing, and change context that makes triage efficient.
Document expected outcomes for approved, ambiguous, duplicate, and review-worthy synthetic cases before claiming the plan works.
Record what changed, why, who owns it, what success looks like, and when rollback is required.
Measure relevance, context, coverage, duplicate burden, timeliness, and decision support instead of celebrating raw alert volume.
Fictional diagrams, synthetic logs, and conceptual signals can demonstrate strong detection reasoning without exposing a real environment.
Key Takeaways
Lesson Safety Boundary
Use only fictional Northbridge systems and synthetic evidence. Do not scan, probe, enumerate, fuzz, exploit, test credentials, collect real logs, bypass controls, change production configurations, or access private information. Do not create guidance for avoiding alerts, concealing activity, weakening visibility, or bypassing monitoring. Validation and tuning in this lesson are conceptual and use only supplied synthetic records.
Lesson Complete
You now have a portfolio structure that connects risk, evidence, signal quality, triage, validation, tuning, metrics, and ownership. Next, A19.7 turns security expectations into a clear and reviewable Security Policy Draft Project.