Lesson A18.10
Build the final Advanced Defensive Casebook and Executive Review by integrating the investigation, architecture, cloud, identity, incident-response, detection, risk, timeline, and communication skills developed across A18.
The goal is not to force nine earlier artifacts into one repetitive template. The capstone teaches how professionals preserve evidence status, reconcile uncertainty, connect genuine cross-domain dependencies, prioritize defensible improvements, and communicate a bounded conclusion. Every service, alert, log, identity, ticket, architecture record, risk, and decision is fictional and synthetic.
Lesson Progress
High School Advanced • A18: Advanced Defensive Labs • Lesson 10 of 10
Readiness Check
0/5 ready
Professional Hook
By the time a complex defensive review reaches a senior analyst, architect, incident lead, risk owner, or security leader, the hard problem is rarely finding one more isolated fact. The hard problem is deciding how evidence from different sources fits together without pretending that every source answers the same question. An identity review can show current authorization. A timeline can show sequence. An architecture review can reveal shared dependencies. A detection baseline can expose workflow noise. A risk register can express future consequence. None of those artifacts automatically proves the others.
That is why the final A18 challenge is about synthesis. Synthesis means connecting evidence where the connection is justified, keeping categories separate when they answer different questions, and explaining how the complete body of evidence changes decisions. A strong casebook lets another reviewer trace a leadership conclusion back to detailed evidence without requiring leadership to read every record first.
The capstone standard: integrate without flattening, conclude without overstating, prioritize without hiding uncertainty, and communicate without losing traceability.
Learning Objectives
Integrate the nine earlier A18 artifacts into one coherent defensive casebook while keeping evidence status, source limits, and uncertainty visible.
Distinguish facts, hypotheses, assumptions, findings, issues, risks, incidents, exceptions, recommendations, decisions, and unresolved questions when they appear in the same case.
Connect architecture, cloud, identity, incident, detection, risk, and timeline evidence only when the evidence actually supports the relationship.
Prioritize defensive improvements using evidence quality, business relevance, dependencies, ownership, control effectiveness, and validation instead of severity labels alone.
Produce an Advanced Defensive Casebook and Executive Review that is traceable, concise at the leadership level, detailed in the supporting sections, and completely fictional.
Capstone Teaching
A beginner may think integration means placing all evidence in chronological order. An intermediate reviewer may group evidence by technology domain. An advanced reviewer goes further: they ask what question each source can legitimately answer, where independent sources reinforce one another, where contradictions remain, what decisions the evidence supports, and which uncertainties are still material.
Independent sources that support the same bounded proposition can increase confidence. Approved change evidence, application audit linkage, and current identity ownership together strengthen the maintenance explanation because they answer related but not identical questions.
Different sources can contribute different pieces without directly confirming one another. Architecture evidence explains dependency risk while timeline evidence explains sequence. Together they improve understanding without becoming proof of one technical cause.
A conflict between sources should remain visible until it is explained or bounded. Do not silently choose the source that makes the story easier. Record provenance, freshness, clock behavior, ownership, and confidence before deciding what the contradiction means.
Two records are not truly independent if they both originate from the same upstream system. Counting duplicates as separate confirmations can create false confidence, especially in alerts and monitoring evidence.
Not every technically interesting detail deserves the same casebook prominence. Materiality asks whether the evidence changes scope, impact, risk, decision, ownership, confidence, or a leadership priority.
A reader should be able to move from executive statement to finding, from finding to evidence, and from evidence to its source and time context. Traceability is what makes concise leadership communication defensible.
Artifact Integration
Each prior artifact remains useful because it preserves a different professional perspective. The capstone should reference and integrate them, not erase them. Think of the final casebook as an index of defensible reasoning: leadership can start with the executive review, while a technical reviewer can follow evidence back into the relevant detailed section.
What it contributes: Evidence correlation, hypotheses, contradictions, source freshness, and bounded conclusions.
Capstone use: Provides the initial investigation record and evidence inventory.
What it contributes: Trust boundaries, dependencies, segmentation, resilience, ownership, and validation.
Capstone use: Explains which architecture dependencies affect defensive confidence.
What it contributes: Cloud identity, logging, storage, backup, recovery, governance freshness, and ownership.
Capstone use: Adds cloud-control and recovery evidence without confusing configuration with governance.
What it contributes: Purpose, least privilege, approval, review freshness, ownership, and service-identity governance.
Capstone use: Shows whether unusual identity activity is currently justified.
What it contributes: Decision chronology, changing scope, authority, reassessment triggers, communication, and recovery criteria.
Capstone use: Preserves what was known when each decision was made.
What it contributes: Alert quality, duplicates, context, routing, analyst usefulness, reopen rate, and rollback criteria.
Capstone use: Separates useful detection coverage from avoidable workflow noise.
What it contributes: Risk statements, inherent and residual risk, controls, treatment, ownership, and review triggers.
Capstone use: Turns evidence-backed weaknesses into governed priorities.
What it contributes: Normalized time, provenance, contradictions, gaps, sequence, clock uncertainty, and confidence.
Capstone use: Provides the defensible chronology without treating sequence as proof of cause.
What it contributes: Materiality, impact, confidence, recommendations, decisions, owners, and next checkpoints.
Capstone use: Provides the leadership-facing summary while preserving technical traceability.
Evidence Language
One of the easiest ways to make a casebook sound more certain than the evidence is to use professional terms loosely. A finding is not automatically a risk. A risk is not an incident. An exception is not simply an undocumented weakness. A recommendation is not a decision until the proper authority chooses it. Use the distinctions below as a quality-control language model for the entire capstone.
| State | Meaning | Professional test | Synthetic example | Common error |
|---|---|---|---|---|
| Fact | Directly supported by a synthetic source. | Can the statement be traced to a specific record without adding interpretation? | CHG-FT-41 was approved before the maintenance window. | Turning an analyst explanation into a fact. |
| Hypothesis | A testable explanation for observations. | What evidence would strengthen or weaken it? | The unusual identity activity may be maintenance related. | Treating the first plausible explanation as final. |
| Assumption | A temporary condition accepted for reasoning but not fully proven. | What changes if this assumption is wrong? | The current ownership record is assumed complete until a newer dependency map arrives. | Leaving assumptions unlabeled. |
| Finding | An evidence-backed observation that deserves review. | What condition is demonstrated, and why does it matter? | QUEUE-NB-2 has a documented telemetry gap. | Writing a vague concern without evidence. |
| Issue | A problem already occurring. | Is the unwanted condition happening now? | Late owner enrichment causes ticket reassignment today. | Calling every possible future concern an issue. |
| Risk | A possible unwanted consequence connected to a condition and plausible event. | What could happen, why, and with what consequence? | A shared monitoring failure could reduce visibility during an important event. | Calling a condition by itself a complete risk statement. |
| Incident | A security-relevant event requiring coordinated response under the fictional process. | Has the event met the defined response threshold? | The tabletop was activated for coordinated evidence review. | Equating one High alert with confirmed compromise. |
| Exception | An approved temporary deviation with boundaries and review requirements. | Who approved it, for how long, and under what conditions? | A temporary monitoring dependency exception remains approved pending validation. | Treating an undocumented gap as an approved exception. |
| Recommendation | A proposed evidence-based improvement. | Does it address the observed problem and include validation? | Move owner enrichment earlier and measure reassignment reduction. | Recommending a broad tool change with no evidence link. |
| Decision | An authorized choice made using the evidence available at that time. | Who decided, why, and what would trigger reassessment? | The lead kept the case in evidence-review status rather than declaring misuse. | Rewriting an earlier decision using later knowledge. |
| Unresolved question | A material unknown that could change confidence, scope, risk, or priority. | Would the answer change the casebook? | What caused the QUEUE-NB-2 telemetry gap? | Hiding uncertainty because one hypothesis looks strongest. |
Case Scope
The final case brings together a brief API service degradation, an unusual service-identity alert, approved maintenance, identity authorization, monitoring gaps, architecture dependencies, cloud governance freshness, detection workflow quality, risk treatment, recovery validation, and leadership communication. The evidence is intentionally mixed because professional review requires deciding which relationships are supported and which are only possible.
Primary services
APP-NB-40, API-NB-41, QUEUE-NB-2
Identity
SVC-NB-40
Detection
DET-NB-7
Approved change
CHG-FT-41
Operations ticket
OPS-1842
Environment
Northbridge fictional internal platform
Primary case question
What does the complete evidence support, and what defensive priorities remain?
Evidence boundary
Only the synthetic records supplied by A18
Safety boundary
No real acquisition, access, containment, blocking, scanning, probing, or system changes
Fake Dashboard
Cross-case evidence status for the fictional A18 capstone
Confirmed malicious activity
0
Current synthetic evidence does not confirm service-identity misuse
Material evidence gap
6m 42s
QUEUE-NB-2 telemetry remains incomplete during part of the review window
Current identity justification
Supported
Purpose, owner, and permission scope are current in the fictional packet
Detection baseline
420 alerts
Fourteen-day synthetic baseline includes duplicate and maintenance-related workload
Cross-case priorities
3
Monitoring resilience, detection quality, and recovery validation
Real systems accessed
0
All services, identities, logs, tickets, and actions are fictional
Fake SOC Alert
Source: Synthetic Detection Feed • Time: 09:05:11
Fake Log Panel
[09:00:00] CHANGE CHG-FT-41 state=APPROVED scope=API-NB-41,SVC-NB-40 [09:05:11] DETECTION DET-NB-7 severity=HIGH identity=SVC-NB-40 status=OPEN [09:06:02] SERVICE API-NB-41 state=DEGRADED [09:07:09] APP-AUDIT identity=SVC-NB-40 change_link=CHG-FT-41 result=FOUND [09:10:02] SERVICE API-NB-41 state=BASELINE_RECOVERED [09:12:58] TELEMETRY QUEUE-NB-2 state=GAP_START [09:13:20] IAM SVC-NB-40 owner=CONFIRMED scope=AUTHORIZED [09:19:40] TELEMETRY QUEUE-NB-2 state=RESUMED gap_duration=00:06:42 [09:21:12] ANALYST hypothesis=SERVICE_IDENTITY_MISUSE confidence=LOW [09:24:00] ARCH monitoring_dependency=SHARED review_status=OPEN [09:27:15] CLOUD backup_status=SUCCESS recovery_validation=STALE [09:31:00] CASE malicious_activity=NOT_CONFIRMED status=EVIDENCE_REVIEW
Training note: this is fake data for defensive analysis practice only.
Evidence Inventory
The same case can contain direct facts, findings, issues, decisions, recommendations, and unresolved questions at the same time. Read the status column before interpreting significance. The purpose is to practice disciplined language rather than make every row sound equally severe.
CHG-FT-41 approved API-NB-41 maintenance using SVC-NB-40 from 09:00 to 09:20.
Narrative significance: Provides legitimate context but does not automatically explain every event in the window.
DET-NB-7 opened at 09:05:11 as a High-priority unusual service-identity alert.
Narrative significance: The alert is important evidence, but its severity label is not a final conclusion.
API-NB-41 degraded briefly and returned to baseline by 09:10:02.
Narrative significance: Confirms operational impact during the review window without proving security causation.
Synthetic audit records link SVC-NB-40 activity to CHG-FT-41.
Narrative significance: Strengthens the approved-maintenance explanation.
Current owner, purpose, and permission scope for SVC-NB-40 are documented and approved.
Narrative significance: Supports current justification while leaving review-timeliness governance separate.
QUEUE-NB-2 telemetry is missing for six minutes and forty-two seconds.
Narrative significance: Limits reconstruction confidence and creates a monitoring-quality concern.
The original misuse hypothesis was reduced to Low confidence after later evidence arrived.
Narrative significance: Shows how confidence can change without rewriting the earlier chronology.
Several important telemetry sources depend on shared monitoring components.
Narrative significance: Creates a cross-domain resilience dependency affecting visibility and evidence collection.
DET-NB-7 baseline includes duplicates, maintenance overlap, stale routing, and delayed context.
Narrative significance: Supports workflow and enrichment improvements rather than broad suppression.
Backups complete successfully, but recovery-validation evidence is stale.
Narrative significance: Backup success and demonstrated recovery readiness are different claims.
RR-NB-18 records monitoring visibility as a priority residual risk with an accountable owner.
Narrative significance: Translates the evidence limitation into a governed future consequence.
Current evidence does not confirm malicious service-identity use.
Narrative significance: Supports a bounded executive conclusion while keeping open remediation work visible.
Improve monitoring resilience, detection context, routing, and recovery validation with measurable checkpoints.
Narrative significance: Addresses the strongest remaining defensive-quality concerns.
The exact cause of the telemetry gap is not established by the current packet.
Narrative significance: Preserves a material unknown instead of silently filling the evidence gap.
Analyze the Evidence
Cross-Case Analysis
Cross-case findings should exist only when multiple artifacts genuinely point to the same underlying defensive concern. The strongest example in Northbridge is monitoring resilience: architecture, incident response, timeline reconstruction, risk, and leadership communication all depend on trustworthy evidence availability. Other findings remain separate because they answer different questions.
Evidence convergence: Architecture, incident, risk, and timeline artifacts all depend on trustworthy monitoring evidence.
Interpretation: A shared monitoring weakness can affect detection, response confidence, reconstruction, and risk decisions at the same time.
Owner: Monitoring Engineering + Security Architecture
Validation: Use a synthetic degraded-mode exercise to confirm improved evidence continuity.
Evidence convergence: SVC-NB-40 has current purpose, ownership, scope, and authorization, but one governance review was late.
Interpretation: Authorization and review freshness answer different questions and should not be collapsed into one access judgment.
Owner: IAM Governance
Validation: Measure on-time service-identity review completion and owner follow-up.
Evidence convergence: Duplicates, maintenance overlap, stale routing, and delayed enrichment create analyst rework while high-confidence escalations remain useful.
Interpretation: The detection still has defensive value; the better response is deduplication, earlier context, and measured workflow improvement.
Owner: Detection Engineering + SOC Workflow Owner
Validation: Compare duplicate, reassignment, reopen, context-completeness, and escalation-quality metrics after changes.
Evidence convergence: Backups complete, but recovery-validation evidence is stale.
Interpretation: A working backup process does not by itself prove recovery readiness.
Owner: Platform Operations
Validation: Complete a synthetic recovery-validation exercise and document the result.
Professional Reasoning
A casebook becomes useful when it helps decision makers choose what deserves attention first. Severity labels can contribute to prioritization, but they cannot substitute for it. The same technical condition may deserve different treatment depending on service criticality, control effectiveness, scope, dependency concentration, evidence confidence, ownership, recurrence, business consequence, and whether an improvement can be validated safely.
What service, customer, obligation, evidence capability, or business outcome could realistically be affected?
Does the weakness affect several defensive capabilities at once, such as detection, response, reconstruction, and confidence?
How well supported is the finding, and could a major contradiction materially change the priority?
Are safeguards operating, partially effective, stale, unvalidated, or concentrated on one dependency?
Is the problem already happening, likely to recur soon, or bounded until a later checkpoint?
Is there an accountable team with authority and resources to act, or is unclear ownership itself part of the problem?
Can the proposed improvement be tested with evidence so success is more than a status label?
Could the proposed improvement accidentally reduce useful visibility, resilience, or operational quality?
Scenario Decision Lab
The Northbridge review contains a High identity alert, valid maintenance evidence, a monitoring gap, stale recovery validation, duplicate detection workload, and several governance-freshness findings. Leadership asks for one coherent explanation.
Decision Record
A professional casebook does not stop at 'recommend improvements.' It records what decision is supported, why, who has authority or ownership, and what future evidence should trigger reassessment. This makes the casebook durable when conditions change.
Rationale: Current evidence favors approved maintenance and does not establish unauthorized use.
Evidence: Change approval, application-audit linkage, current ownership, scoped permissions, and later reassessment.
Authority / owner: Incident Review Lead
Reassessment trigger: Reassess if new identity evidence or a stronger timeline contradiction appears.
Rationale: The gap limits reconstruction confidence but is not evidence of malicious activity by itself.
Evidence: Timeline gap, architecture dependency review, and residual monitoring risk.
Authority / owner: Monitoring Engineering Owner
Reassessment trigger: Escalate if gaps recur or affect additional critical sources.
Rationale: The rule retains defensive value while duplicates, maintenance context, routing, and enrichment create avoidable workload.
Evidence: A18.6 baseline and reopen data.
Authority / owner: Detection Engineering Lead
Reassessment trigger: Pause or roll back if visibility or escalation quality worsens.
Rationale: Control existence and successful backup execution do not replace current evidence of effectiveness.
Evidence: Cloud review, identity review, and recovery criteria.
Authority / owner: Platform Operations + Governance Owners
Reassessment trigger: Escalate if validation fails or ownership remains unclear.
Scenario Decision Lab
The identity misuse hypothesis is now Low confidence, but monitoring resilience, detection workflow quality, and stale recovery validation remain. Leadership can sponsor only a limited number of improvements in the next operating cycle.
Analyze the Evidence
Phased Improvement
A roadmap should not imply that every improvement can or should happen simultaneously. Sequencing matters. Establishing owners and baselines before changes protects the ability to measure whether those changes helped. Validation and rollback criteria protect against improvements that accidentally reduce visibility or create new operational problems.
Success evidence: Every priority has an owner, starting measure, and checkpoint.
Success evidence: Defensive improvements are implemented without reducing useful visibility.
Success evidence: The organization can demonstrate improvement with evidence rather than status labels.
Safe Fictional Lab
Use the synthetic Northbridge packet and your prior A18 artifacts. Your goal is to create a coherent professional portfolio, not reproduce every sentence from earlier lessons. Preserve detailed evidence where it supports traceability, summarize repeated material intelligently, and keep unresolved questions visible.
Write a one-paragraph case scope that names the fictional services, identity, detection, change, time window, business boundary, and safety boundary.
Create an evidence inventory that identifies source, freshness, provenance, time characteristics, owner, and whether each source is direct, derived, delayed, contradictory, or incomplete.
Summarize the A18.1 multi-source investigation with the strongest current hypotheses, contradictions, confidence, and bounded conclusion.
Add the A18.2 architecture review and identify trust boundaries, monitoring dependencies, degraded modes, resilience concerns, owners, and validation needs.
Add the A18.3 cloud review while separating configuration state, governance evidence, classification freshness, logging, backup, recovery validation, and exceptions.
Add the A18.4 identity decision pack with current justification, ownership, permission scope, review freshness, exceptions, service-identity lifecycle, and final access decisions.
Preserve the A18.5 tabletop decision chronology, including what was known at each decision point, authority, reassessment triggers, impact statements, and recovery criteria.
Add the A18.6 detection recommendation with baseline metrics, noise sources, analyst usefulness, reopen rate, safer tuning categories, monitoring window, and rollback criteria.
Add the A18.7 risk register and ensure each material risk has a complete statement, control-effectiveness analysis, residual risk, treatment, owner, due date, review trigger, and validation evidence.
Add the A18.8 normalized timeline, anchor events, contradictions, delayed records, clock uncertainty, evidence gaps, confidence labels, hypotheses, and bounded narrative.
Add the A18.9 Executive Security Summary as the leadership-facing entry point while keeping the detailed evidence available in the supporting sections.
Create a cross-case findings section that combines evidence only where multiple artifacts genuinely converge.
Create a priority-decision section that records recommendation, evidence, authority or owner, decision, rationale, and reassessment trigger.
Create a phased improvement roadmap that establishes baselines first, improves defensive controls and governance second, then measures outcomes and residual risk.
Write a leadership decision summary that clearly states what requires sponsorship now, what remains owned operational work, and what conditions would trigger escalation.
Finish with a lessons-learned section explaining how the case changed from initial alert interpretation to the final bounded conclusion without rewriting earlier evidence.
Run a final terminology check for facts, hypotheses, assumptions, findings, issues, risks, incidents, exceptions, recommendations, decisions, and unresolved questions.
Run a final safety check confirming the casebook contains no real access instructions, credentials, scanning, exploitation, bypass, evasion, containment execution, or private data.
Lab safety boundary
This capstone is analysis and documentation practice using synthetic evidence only. Do not acquire evidence from real devices, access real accounts, use credentials, inspect real cloud consoles, scan or probe systems, extract private information, bypass controls, modify endpoints, change network or cloud settings, disable detections, or execute real containment. Incident-response actions remain tabletop and conceptual.
Advanced Challenge
The final challenge is not to make the casebook sound impressive. It is to make it survive questioning. Imagine a fictional review board containing a security architect, incident lead, IAM owner, platform owner, risk manager, detection engineer, and executive sponsor. Prepare concise evidence-backed answers to the questions below.
Review question 1
What is the strongest current explanation for DET-NB-7, and why is it not stated with absolute certainty?
Review question 2
Which evidence is direct, which is interpretive, and which remains incomplete?
Review question 3
Why does the QUEUE-NB-2 gap matter even though it does not prove malicious activity?
Review question 4
What changed between the initial incident hypothesis and the final assessment?
Review question 5
Which earlier decisions were reasonable based on the evidence available at that time?
Review question 6
Why is the late identity review a governance finding instead of proof that SVC-NB-40 is unjustified?
Review question 7
Why should detection tuning focus on deduplication, enrichment, routing, and quality metrics instead of broad suppression?
Review question 8
Which architecture dependency creates the most cross-domain defensive risk?
Review question 9
Why does successful backup completion not prove recovery readiness?
Review question 10
Which risks remain after current controls, and who owns them?
Review question 11
What evidence would cause leadership to change the current priority order?
Review question 12
What can leadership decide from the executive review without reading every technical record?
Review question 13
Which statements would become misleading if the word 'confirmed' were added to them?
Review question 14
Where does the casebook intentionally preserve uncertainty, and why is that a strength?
Review question 15
How will the organization know whether the phased roadmap actually improved defensive quality?
Review question 16
What evidence supports closing the identity-misuse hypothesis as unconfirmed while keeping monitoring remediation open?
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Produce the tenth and final A18 artifact: an Advanced Defensive Casebook and Executive Review using only the fictional Northbridge evidence. Integrate the prior nine A18 artifacts into a traceable professional portfolio with an executive summary, case scope, evidence inventory, multi-source investigation, architecture review, cloud review, identity review, incident tabletop record, detection tuning recommendation, risk register, forensics timeline, cross-case findings, priority decisions, phased improvement roadmap, leadership decision summary, and final lessons learned. Preserve evidence status, uncertainty, ownership, validation, and safety boundaries throughout.
Confidence / Readiness Reflection
The module test will ask you to reason across the whole A18 curriculum rather than remember isolated vocabulary. Before continuing, you should be able to explain not only what each artifact contains, but why the artifacts sometimes support one another and sometimes must remain analytically separate.
I can correlate multiple synthetic sources without confusing correlation and causation.
I can identify trust boundaries, dependencies, resilience concerns, governance freshness, and validation needs in architecture and cloud reviews.
I can justify an identity access decision using purpose, ownership, scope, approval, review freshness, activity evidence, exceptions, and lifecycle governance.
I can preserve incident decisions in the chronology in which they were made and explain what later evidence changed.
I can evaluate detection quality using more than alert volume and can define safer tuning, monitoring, and rollback logic.
I can write a risk statement, distinguish inherent and residual risk, evaluate control effectiveness, and explain treatment ownership.
I can normalize synthetic timeline evidence while preserving provenance, clock uncertainty, contradictions, gaps, and confidence.
I can write technical, manager, and executive summaries using the same supported facts at different levels of detail.
I can integrate the entire case into cross-case findings and priority decisions without overstating what the evidence proves.
Portfolio Build Guide
The final artifact should read like one professional case portfolio while keeping enough internal structure that another reviewer can navigate quickly. The section order below is recommended because it moves from leadership meaning into evidence and analysis, then returns to priorities and lessons learned. You can use natural subsections inside each area instead of forcing identical step counts.
Section 1
Executive Summary
Section 2
Case Scope
Section 3
Evidence Inventory
Section 4
Multi-Source Investigation
Section 5
Network Defense Architecture Review
Section 6
Cloud Security Review
Section 7
Identity Access Review
Section 8
Incident Response Tabletop Record
Section 9
Detection Tuning Recommendation
Section 10
Defensive Risk Register
Section 11
Forensics Timeline and Evidence Narrative
Section 12
Cross-Case Findings
Section 13
Priority Decisions
Section 14
Phased Improvement Roadmap
Section 15
Leadership Decision Summary
Section 16
Final Review and Lessons Learned
Official A18 portfolio outcome
Advanced Defensive Casebook and Executive Review
Key Takeaways
Safety Boundary
A18.10 remains a school-appropriate defensive analysis and documentation exercise. Every account, service, alert, ticket, cloud record, architecture condition, identity, metric, timestamp, risk, and decision is fictional. The casebook teaches how to reason about evidence and governance without performing real forensic acquisition, live response, or system modification.
Allowed capstone work
Synthetic alerts and logs, fictional architecture review, trust-boundary analysis, identity governance, cloud shared responsibility, evidence correlation, conceptual incident-tabletop decisions, detection quality metrics, risk registers, forensic timeline reasoning, executive communication, remediation planning, ownership, review triggers, and validation criteria.
Not part of the capstone
Real scanning, probing, enumeration, exploitation, password guessing, credential use, token theft, privilege escalation, control bypass, evasion, persistence, malicious code, private-data recovery, real cloud or account access, endpoint modification, network modification, disabling security controls, destructive automation, or real-world containment execution.