Start your lesson
Study the required lesson for each block, then take its short check. Guided exercises are optional. Required case practice within the blocks counts toward the readiness checklist, not lesson completion.
Your notesPrivate to you
Block 1 of 6Order of volatility · Chain of custody · Evidence integrity hash · Evidence provenance
Practice savedNext · 15 min
Order of volatility · Chain of custody · Evidence integrity hash · Evidence provenance
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Order of volatility
Prioritizes evidence likely to disappear or change, while allowing safety, authorization, and containment needs to override ideal collection order.
Chain of custody
Records who collected, possessed, transferred, stored, and accessed evidence so handling remains reviewable over time.
Evidence integrity hash
Detects whether the hashed acquisition changed after calculation but does not prove source truth or collection completeness.
Evidence provenance
Records the source system, acquisition method, tool version, time, and destination of a collected artifact so the acquisition can be reviewed and repeated.
Required block check · Block 1
Required for course progress · Pass with 3 of 4 correct
Block 2 of 6Event time versus ingestion time · Timeline normalization · Root-cause analysis · Alternate hypothesis
Practice saved15 min
Event time versus ingestion time · Timeline normalization · Root-cause analysis · Alternate hypothesis
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Event time versus ingestion time
Distinguishes when source activity occurred from when a monitoring platform received the record, preventing delayed logs from misordering timelines.
Timeline normalization
Preserves original timestamps while applying documented time zones and supported clock offsets for cross-source sequence analysis.
Root-cause analysis
Tests explanations against evidence to identify the underlying failure that enabled occurrence or recurrence, rather than stopping at the first visible symptom.
Alternate hypothesis
Provides a plausible competing explanation and identifies evidence that would distinguish it from the leading incident theory.
Required block check · Block 2
Required for course progress · Pass with 3 of 4 correct
Block 3 of 6Collect volatile evidence with provenance
Practice saved8 min
Collect volatile evidence with provenance
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Collect volatile evidence with provenance
By the end, you can
- Analyze supplied evidence for evidence-volatility order.
- Analyze supplied evidence for evidence-integrity interpretation.
Collection order follows the investigative question and the risk that evidence will change. Live memory, processes, connections, and logged-in sessions can disappear at shutdown; disk and centralized logs often persist longer. Safety and containment can override ideal collection order, so record why a volatile source was skipped or altered.
Provenance makes evidence reviewable. Record collector, time, source, method, tool version, destination, and integrity value where applicable. A hash can show that a collected file has not changed since hashing, but it does not prove the source was trustworthy or that the acquisition captured every relevant byte.
Worked example
An isolated workstation remains powered on with an encrypted volume mounted and a suspicious process connected to a remote address.
- Live state: PID 5521 connected to 198.51.100.31:8443
- Storage: full-disk encryption active; recovery key availability unconfirmed
- Collection worksheet: memory tool approved; evidence drive ready; current UTC 18:22
Power loss could remove memory, process, socket, and mounted-volume access. Approved live collection should precede shutdown if it does not create unacceptable risk.
Record the live state and provenance, acquire volatile evidence with the approved tool, calculate and record integrity values, then follow the authorized disk-collection procedure.
Reasoning self-check
An isolated workstation remains powered on with an encrypted volume mounted and a suspicious process connected to a remote address.
- Live state: PID 5521 connected to 198.51.100.31:8443
- Storage: full-disk encryption active; recovery key availability unconfirmed
- Collection worksheet: memory tool approved; evidence drive ready; current UTC 18:22
- Record a timestamped fact table from the supplied evidence.
- Test the two most plausible explanations against every observation.
- Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
- Record the live state and provenance, acquire volatile evidence with the approved tool, calculate and record integrity values, then follow the authorized disk-collection procedure.
- The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
- If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
- If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 3
Required for course progress · Pass with 2 of 2 correct
Block 4 of 6Build and test an incident timeline
Practice saved18 min
Build and test an incident timeline
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Build and test an incident timeline
By the end, you can
- Analyze supplied evidence for event-time reconstruction.
- Analyze supplied evidence for evidence-linked root cause.
A timeline normalizes timestamps while preserving original values, time zones, clock offsets, and source identifiers. Separate event time from ingestion time: a delayed upload can arrive after later activity. Sequence by corrected event time only when the correction is supported, and mark uncertain ordering when clock evidence is missing.
Root-cause analysis tests explanations against the full sequence. The earliest observed malicious event is not automatically the initial cause; collection may begin late. Look for the control failure that enabled recurrence, validate alternate paths, and connect corrective actions to evidence rather than choosing the first visible symptom.
Worked example
A cloud audit event arrives at the SIEM after an endpoint alert, but its original event time and token ID connect it to an earlier token creation.
- Cloud event_time 08:41Z, ingest_time 09:12Z, CreateToken for svc-build, token ID tok-58c1
- Endpoint 08:47Z: svc-build starts a remote shell authenticated with token ID tok-58c1
- Identity policy: build service could create non-expiring tokens; approved design requires one-hour tokens
Event time and the shared token ID place token creation before remote-shell use despite later ingestion. The overbroad token policy is a causal control weakness, not merely a timeline artifact.
Preserve both time fields, revoke the token, constrain token lifetime and creation authority, and verify a test service cannot create a non-expiring token.
Reasoning self-check
A cloud audit event arrives at the SIEM after an endpoint alert, but its original event time and token ID connect it to an earlier token creation.
- Cloud event_time 08:41Z, ingest_time 09:12Z, CreateToken for svc-build, token ID tok-58c1
- Endpoint 08:47Z: svc-build starts a remote shell authenticated with token ID tok-58c1
- Identity policy: build service could create non-expiring tokens; approved design requires one-hour tokens
- Record a timestamped fact table from the supplied evidence.
- Test the two most plausible explanations against every observation.
- Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
- Preserve both time fields, revoke the token, constrain token lifetime and creation authority, and verify a test service cannot create a non-expiring token.
- The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
- If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
- If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Work through the scenario
Use the case evidence to complete the tasks, then check objectives.
Guided: Preserve volatile ransomware evidence
One server shows active encryption and a reachable management console permits isolation.
- Responderactor
- Endpoint response consolecontrol
- File serverresource
- analystinterpretsevidence
- evidencedescribesasset
Objectives
- Interpret the supplied evidence without overclaimingpending
- Choose the bounded evidence-supported actionpending
- Select evidence that verifies security and operational outcomepending
Evidence 1
EDR: encryptor process active; hundreds of rename events per minute.
Evidence 2
Memory capture capability is available remotely.
Evidence 3
Backups are offline and last restore test passed yesterday.
Fictional, disposable SOC evidence. No production system or external service is contacted.
Report an issue with this exercise
Required case practice
Required for the readiness checklist · Pass at 100%
Handle a lost cloud audit trail
A cloud workload is suspected of credential theft and its short-retention logs will expire soon.
- Cloud responderactor
- Cloud forensic controlscontrol
- Workload identityresource
- analystinterpretsevidence
- evidencedescribesasset
Objectives
- Interpret the supplied evidence without overclaimingpending
- Choose the bounded evidence-supported actionpending
- Select evidence that verifies security and operational outcomepending
Evidence 1
Audit retention remaining: 47 minutes.
Evidence 2
Snapshot and log export are available without stopping the workload.
Evidence 3
A network deny policy can isolate the workload identity after export begins.
Fictional, disposable SOC evidence. No production system or external service is contacted.
Report an issue with this exercise
Required block check · Block 4
Required for course progress · Pass with 2 of 2 correct
Block 5 of 6Prepare people, plans, and telemetry for incidents
Practice saved10 min
Prepare people, plans, and telemetry for incidents
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Prepare people, plans, and telemetry for incidents
By the end, you can
- Explain and apply plan, playbook, role, and communication.
- Explain and apply exercise evidence.
- Explain and apply incident telemetry pipeline.
- Explain and apply triage and priority.
An incident plan governs the program; communication plans define recipients and channels; playbooks guide scenario decisions; runbooks can hold commands. Named roles prevent duplicate or conflicting action. Tabletop discussion tests decisions and dependencies, while a simulation executes bounded behavior and telemetry to test operational capability.
Collection is not complete until sources arrive with usable time and identity, correlation retains the original evidence, enrichment has provenance, and alerts reach an accountable role. Triage validates the signal, builds a supported timeline, estimates severity/impact, and sets priority without presenting missing scope as fact.
Worked example
A ransomware tabletop succeeds verbally, but a later simulation alert never reaches the overnight responder and database clocks differ by seven minutes.
- Call tree lists only daytime staff
- SIEM notification integration reports HTTP 401
- Database NTP record documents +7 minute offset
The exercise exposed preparedness and notification failures; the known clock offset can normalize the timeline without overwriting originals.
Assign an overnight escalation path, repair and test notification delivery, normalize with documented offsets, and rerun the scenario.
Reasoning self-check
A tabletop approves an overnight response path, but a simulation reveals failed paging and conflicting timestamps.
- Plan names only daytime incident commander
- Notification webhook returns 401
- Database clock offset documented; enrichment source is stale
- Build a short evidence table that separates observations, supported conclusions, and remaining unknowns.
- Choose the authorized action that tests the leading conclusion with the least operational impact.
- Compare your decision and reopen condition with the expected results before continuing.
Compare your reasoning
Expected answers
- Update roles, communication plan and playbook; treat the simulation as control evidence; retain raw/normalized times and enrichment provenance; prioritize the notification gap by impact.
- Reopen training closure until an overnight retest delivers the alert, reaches an accountable role, and reconstructs the same timeline.
If you got stuck
- If the answer depends on a product name alone, return to the actual evidence it produced.
- If no option can be falsified, name the missing record before choosing.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 5
Required for course progress · Pass with 3 of 4 correct
Block 6 of 6Preserve evidence and prove containment through restoration
Practice saved9 min
Preserve evidence and prove containment through restoration
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Preserve evidence and prove containment through restoration
By the end, you can
- Explain and apply evidence preservation.
- Explain and apply containment-to-release proof.
- Explain and apply root cause and corrective action.
Custody records who handled evidence, when, why, where, and under what identifier. Integrity hashes detect later change after calculation; they do not prove the source was complete or genuine. Preservation and legal hold suspend ordinary deletion for scoped material and require coordination with authorized legal and privacy roles.
Isolation limits harm but can affect safety and service. Escalate conflicts, record the decision, remove persistence and vulnerable paths, verify the fix, restore controls and telemetry, and test required service before release. Root cause explains supported enabling failure; corrective action names an owner, due date, observable result, and retest.
Worked example
A production host is isolated and rebuilt, but counsel issues a hold and the replacement lacks monitoring before reconnection.
- Source image hash matches acquisition record
- Automatic log deletion remains enabled
- Replacement service works; EDR and hardening baseline absent
The image integrity is supported, but hold preservation and trustworthy recovery are incomplete.
Suspend scoped deletion, preserve custody records, restore EDR/hardening, verify service and telemetry, then authorize release.
Reasoning self-check
A held forensic image is preserved while a rebuilt host awaits release from isolation.
- Custody transfer recorded and image hash reverified
- Legal hold active; original auto-deletion disabled
- Replacement service healthy but shared deployment secret and missing EDR remain
- Build a short evidence table that separates observations, supported conclusions, and remaining unknowns.
- Choose the authorized action that tests the leading conclusion with the least operational impact.
- Compare your decision and reopen condition with the expected results before continuing.
Compare your reasoning
Expected answers
- Preserve custody/hold evidence, rotate and redesign the root-cause secret, restore controls, verify remediation and service, then authorize release.
- Reopen if custody breaks, deletion resumes, the shared secret still authenticates, telemetry is absent, or the original exploit path succeeds.
If you got stuck
- If the answer depends on a product name alone, return to the actual evidence it produced.
- If no option can be falsified, name the missing record before choosing.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 6
Required for course progress · Pass with 3 of 3 correct
Review this lesson
Use only this lesson's worked example and key concepts for a quick self-check.
- Restate the worked example in your own words.
- Name the lesson concepts that explain the result.
- Explain why the closest alternative does not fit.
Check the whole objective
This unlocks objective 3.3 for recall. The latest checkpoint needs 70% or higher; a lower result puts the lesson back near the front of your timeline.