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 6Detection tuning · False positive · False negative · Behavioral baseline
Practice savedNext · 15 min
Detection tuning · False positive · False negative · Behavioral baseline
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Detection tuning
Changes a rule threshold or condition using labeled outcomes to reduce avoidable noise while retaining known malicious examples.
False positive
Occurs when a detection labels benign activity as malicious or policy-violating even though the underlying unwanted condition is absent.
False negative
Occurs when malicious or policy-violating activity is present but a detection fails to identify it.
Behavioral baseline
Describes expected activity across representative business cycles so analysts can evaluate deviations without treating every rare event as malicious.
Required block check · Block 1
Required for course progress · Pass with 3 of 4 correct
Block 2 of 6Response playbook · Escalation path · Time to contain · Automation guardrail
Practice saved15 min
Response playbook · Escalation path · Time to contain · Automation guardrail
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Response playbook
Defines triggers, owners, evidence, decisions, actions, verification, communication, and exit criteria for a repeatable security workflow.
Escalation path
Names the condition, responsible role, contact method, and authority needed when an event exceeds an analyst's scope or decision rights.
Time to contain
Measures elapsed time from a defined detection or declaration point until verified action limits the incident's harmful activity.
Automation guardrail
Constrains automated action with scope, approvals, audit records, stop conditions, and rollback or release paths.
Required block check · Block 2
Required for course progress · Pass with 3 of 4 correct
Block 3 of 6Tune detections with labeled outcomes
Practice saved8 min
Tune detections with labeled outcomes
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Tune detections with labeled outcomes
By the end, you can
- Analyze supplied evidence for scoped detection exception.
- Analyze supplied evidence for detection replay validation.
Detection tuning should begin with labeled examples: true positive, benign true condition, duplicate, expected test, or data-quality error. Lowering sensitivity until alerts stop can hide attacks. Change one threshold or condition at a time and compare precision, missed known cases, and analyst load over a defined period.
Baselines must include business cycles and known changes. A Monday backup peak or monthly payroll run may be rare in a short window but normal over a full cycle. Store the old rule, test the candidate against historical cases, and define rollback criteria before production activation.
Worked example
A large-upload rule creates 80 weekly alerts; 62 are approved Friday backups, 14 are user transfers, and four are confirmed unauthorized tools.
- Rule: outbound >5 GB in 30 min
- Backup jobs: signed process backup.exe, destination backup.example, Friday 23:00
- Confirmed cases: unsigned tools to three unrelated destinations
Suppressing all Friday traffic would hide a confirmed case if it occurred then. Constrain the exception to the approved process, destination, and schedule.
Replay the refined rule against all 80 labeled events; expect 62 approved backups excluded and all four confirmed cases retained.
Reasoning self-check
A large-upload rule creates 80 weekly alerts; 62 are approved Friday backups, 14 are user transfers, and four are confirmed unauthorized tools.
- Rule: outbound >5 GB in 30 min
- Backup jobs: signed process backup.exe, destination backup.example, Friday 23:00
- Confirmed cases: unsigned tools to three unrelated destinations
- 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
- Replay the refined rule against all 80 labeled events; expect 62 approved backups excluded and all four confirmed cases retained.
- 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 6Improve playbooks using measurable handoffs
Practice saved18 min
Improve playbooks using measurable handoffs
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Improve playbooks using measurable handoffs
By the end, you can
- Analyze supplied evidence for structured playbook handoff.
- Analyze supplied evidence for outcome-linked process metric.
A playbook makes decisions repeatable by naming trigger, owner, evidence, approvals, actions, verification, communication, and exit criteria. Automation should stop at a human decision when context or business impact cannot be encoded safely. Every automated change needs an audit trail and a rollback or release path.
Useful measures connect process to outcomes: time to acknowledge, time to contain, rework caused by missing evidence, false-positive rate, and percentage of actions verified. A faster closure time can be harmful if analysts close alerts without containment proof. Review cases for bottlenecks and update the step that caused delay or error.
Worked example
Phishing cases stall for about 45 minutes between the SOC and the mailbox team, which must locate and remove each reported message.
- Median acknowledgment 8 min
- Median containment 71 min
- 18 of 25 cases were returned because the handoff contained only a screenshot of the message
The dominant delay is an incomplete evidence handoff, not acknowledgment. A screenshot cannot be searched or purged; the mailbox team needs the message ID, the recipients, and the delivery time to find every copy.
Make the message ID, recipients, and delivery time required before handoff; expect rework count and containment time to fall without lowering evidence quality.
Reasoning self-check
Phishing cases stall for about 45 minutes between the SOC and the mailbox team, which must locate and remove each reported message.
- Median acknowledgment 8 min
- Median containment 71 min
- 18 of 25 cases were returned because the handoff contained only a screenshot of the message
- 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
- Make the message ID, recipients, and delivery time required before handoff; expect rework count and containment time to fall without lowering evidence quality.
- 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: Bound an enrichment workflow
A repetitive alert needs enrichment automation without allowing unreviewed containment.
- Automation engineeractor
- SOAR enrichment workflowcontrol
- Alert queueresource
- 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
Current step: analysts manually fetch asset owner, vulnerability state, and identity risk.
Evidence 2
APIs are read-only for those three sources.
Evidence 3
Containment changes production access and requires analyst approval.
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%
Stop a looping ticket playbook
A playbook creates duplicate tickets when the case API times out after accepting a request.
- Automation engineeractor
- Case-creation playbookcontrol
- Incident queueresource
- 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
Case API: request accepted with client token T-884, response times out.
Evidence 2
Retry log: a new token is generated on every retry.
Evidence 3
Queue: four cases contain the same alert fingerprint.
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 6Standardize and automate without losing control
Practice saved8 min
Standardize and automate without losing control
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Standardize and automate without losing control
By the end, you can
- Explain and apply coordinated standard process.
- Explain and apply governed automation.
A playbook coordinates people and decisions; a runbook records repeatable operational steps. Both need explicit inputs, owners, approvals, failure paths, evidence, and exit criteria. Standardization reduces omissions but should preserve an escalation route when safety or business constraints conflict with the ordinary path.
SOAR can enrich, route, or act on cases. IaC declares infrastructure state and can change many resources consistently. Automation magnifies both correctness and error, so use least privilege, dry runs where possible, version review, concurrency control, audit records, rollback, and service plus security verification.
Worked example
A SOAR case invokes an IaC change to quarantine a cloud subnet, but the plan has no owner for shared database dependencies.
- Playbook trigger: one high-confidence endpoint alert
- IaC plan: replaces subnet route table for 46 resources
- Service map: database dependency owner blank
The trigger may justify escalation, but the unowned shared dependency makes automatic broad quarantine unsafe.
Pause the change, identify decision authority and dependencies, test a narrower containment path, and retain the reviewed plan and result.
Reasoning self-check
A SOAR playbook proposes an IaC route change that would isolate a shared authentication service.
- Playbook: alert threshold met
- IaC plan: changes 72 routes
- Runbook: no dependency owner, rollback test, or abort signal
- 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
- Pause execution, assign decision and dependency owners, distinguish playbook decisions from runbook steps, and require reviewed IaC scope, rollback, and verification.
- Reopen automation after a dry run shows only intended routes change and both authentication and containment tests pass.
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 2 of 2 correct
Block 6 of 6Enrich detections and integrate tools safely
Practice saved8 min
Enrich detections and integrate tools safely
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Enrich detections and integrate tools safely
By the end, you can
- Explain and apply traceable enrichment and tuning.
- Explain and apply authenticated integration.
Enrichment adds context; it must not overwrite the source event or collapse disagreements into one severe label. Rule tuning needs labeled true and false outcomes plus replay of known malicious examples. Dashboards communicate a defined population and time window; counts without denominators or collection health can mislead.
An API is a callable contract, a webhook pushes an event to a receiver, and a plug-in extends a host product. Validate payload schemas, authenticate both ends, protect secrets, reject replays, rate-limit, log outcomes, and design retry/dead-letter behavior so an outage does not silently drop or duplicate response work.
Worked example
A webhook retries the same alert 18 times, creating duplicate cases whose enrichment feeds disagree on the destination IP.
- Webhook has no event ID or signature
- Feed A: malicious 14 months ago
- Feed B: shared cloud service today
The integration lacks authenticity and idempotency; the feeds should remain separate time-scoped observations.
Require signed events with stable IDs, deduplicate retries, preserve feed provenance, and show both case count and unique-event count.
Reasoning self-check
A case plug-in receives unsigned webhook retries and enriches them with two disagreeing feeds.
- Webhook: same event delivered 14 times without stable ID
- Feed A: address malicious last year
- Feed B: address is shared hosting today
- 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
- Authenticate and deduplicate the integration, preserve both feed provenance records, tune on labeled outcomes, and chart unique events with delivery health and a time-bounded denominator.
- Reopen tuning if replayed known-positive events stop alerting or if signed retries still create more than one case.
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 2 of 2 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 1.5 for recall. The latest checkpoint needs 70% or higher; a lower result puts the lesson back near the front of your timeline.