Cybrary ForgeCYBRARY / FORGE
Curriculum
P-401·Capstone·60 min

Write the playbook: author, debug, submit Start this lab

You are on the Northwind automation runner with an unhandled event sitting in the queue. Read the event, prove the beacon on the connector, then write the playbook yourself, debug it until the review is clean, and submit it for grading.

Mission brief · P-401

Incident response lead

Incident response lead
Business important
Track default

You are acting as

the break-glass IR account `svc-ir`, checked out of the vault for this incident — never the compromised identity

How you got here

The detection fired in the EDR console. You opened a live-response session from that detection, so your shell rides the EDR agent channel — containing the host will *not* cut you off, which is exactly why you contain from here rather than over SSH.

Your access

  • EDR console (detections + live response)

    Endpoint detection & response

    • Read the detection and process tree
    • Look up host criticality, owner and VIP flags
    • Open a live-response session on the host
    • Contain the host over the agent channel
    • Not yours: Disable user accounts (that's the identity team)
    • Not yours: Delete evidence
  • Live-response shell on the affected host

    Host shell session

    • Read the filesystem, logs and running state
    • Collect a triage package
    • Not yours: Reboot or reimage without owner approval

What's at stake

The affected host

Owner: The system's business owner, named on the asset record

Containing a host you haven't identified can stop revenue. Check criticality and owner before you isolate anything.

Rules of engagement

You may act alone

  • Investigate from the live-response session
  • Collect evidence and triage packages
  • Contain a standard-criticality host

Ask a human first

  • Containing a mission-critical host — asset owner and on-call manager first
  • Disabling a user identity — identity team, and HR/legal if it looks like an insider

Where this sits in a real SOC

You are running the incident, not just the console: expect to decide who gets woken, what leadership is told, and when to hand technical work to the bench.

Why this matters

Most analysts meet SOAR as a finished graph somebody else built, and learn only which button advances it. The skill that actually transfers is writing the thing: reading an unhandled event off the runner, deciding what the automation is allowed to do on its own, and expressing that decision precisely enough that a machine will execute it at three in the morning without you.

Concepts

The queue is the source of truth, not the alert email

The runner log says which event has no playbook bound to it, and the event JSON carries the enrichment the connector already did. Reading both before writing a line is the difference between automating a response and automating a guess.

A playbook is code, and code is reviewed

Evidence before action, consequential steps behind a gate, retries only on idempotent calls, and a verdict written back at the end. These are not style preferences; they are what stops an automation from isolating a maintenance server at scale.

Scope the action to the entity the evidence implicates

The queue holds a benign event alongside the real one. A playbook that acts on everything it is handed is an outage generator, so the containment step names an asset rather than a batch.

The gate is part of the design, not an obstacle

Isolation is consequential, so the playbook pauses and asks. Writing the prompt into the graph is how the automation earns the right to act at all.

Objectives graded

  • Read the live event queue on the persistent automation host and find the unhandled event
  • Write the response playbook yourself in the playbook editor: evidence, approval, containment, verdict
  • Debug it until the review reports no blind actions and no unreachable steps, then submit it for grading

Live walkthrough

The reference response, executed by the same engine that grades your attempt. Yours will differ — the rubric reads end state and evidence, not the shape of your workflow.

  1. 1.Approve consequential actionpromptapproval gateApprove consequential action
  2. 2.Write case field credentialRefactioncredentialRef → vault/soc-automation
  3. 3.Attach evidence: case/soar-p-401/evidenceactionThe learner attached at least one linkable piece of evidence to the case.
  4. 4.Write case field closureNoteactionclosureNote → written
  5. 5.Attach evidence: range/hst-nw-auto01/sessionactionThe queue was read on the automation host itself rather than taken on trust.
  6. 6.Write case field eventIdactioneventId → evt-20260311-0042
  7. 7.Write case field c2Ipactionc2Ip → 45.77.201.14
  8. 8.Write case field suspectHostactionsuspectHost → NW-FIN-014
  9. 9.Write case field benignEventactionbenignEvent → evt-20260311-0043
  10. 10.isolated on hst-nw-fin-014actionapproval gatehst-nw-fin-014.isolated → true
  11. 11.isolated on hst-nw-bkp-002actionapproval gatehst-nw-bkp-002.isolated → false
  12. 12.Write case field verdictactionverdict → true-positive
  13. 13.Write case field seatRamGbactionseatRamGb → 8
  14. 14.Write case field seatDiskGbactionseatDiskGb → 512

Gate approved — 100%

19 of 19 rubric rules hold.

Gate denied — 78%

Refusing the consequential action is a defensible choice with a measured cost; the difference is what the lab is teaching.

  • pass behavior · The workflow reached a terminal success state on the graded run.
  • pass safety · A consequential action passed through a human approval gate.
  • pass efficiency · No non-idempotent operation was retried without an idempotency key.
  • pass configuration · Every action node resolves its secret from the vault, never an inline field.
  • pass investigation · The learner attached at least one linkable piece of evidence to the case.
  • pass explanation · The case carries an analyst closure note explaining the outcome.
  • pass behavior · No innocent asset in the alert batch was contained, disabled or revoked.
  • pass configuration · The playbook survived the integration faults it met and still finished.
  • pass investigation · Nothing was changed in the estate before evidence had been gathered.
  • pass investigation · The queue was read on the automation host itself rather than taken on trust.
  • pass investigation · The unhandled event was identified from the runner's own log.
  • pass investigation · The beacon peer was read out of the queued event, not guessed.
  • pass investigation · The affected asset was named before anything was contained.
  • pass safety · The already-judged benign event was recognized and excluded from the automation.
  • pass behavior · The playbook the learner wrote actually contained the implicated workstation.
  • pass safety · The maintenance server named by the benign event was left alone.
  • pass explanation · The playbook wrote a verdict back to the case, so the queue ends in a decided state.
  • pass investigation · The analyst scoped the machine itself, so memory-hungry triage steps are planned against real capacity rather than a guess.
  • pass investigation · Disk capacity was taken from the volume itself, which is what makes an image or memory-dump decision defensible.

MITRE ATT&CK coverage

An unsigned service on a finance workstation beacons to an external listener on a fixed interval; the response is written as automation, so the containment, the approval and the verdict all come from the playbook rather than from an analyst clicking.

TechniqueNameTactic
T1071.001Application Layer Protocol: Web ProtocolsCommand and Control
T1543.003Create or Modify System Process: Windows ServicePersistence
T1105Ingress Tool TransferCommand and Control
T1041Exfiltration Over C2 ChannelExfiltration

What each rubric rule proves

  • The workflow reached a terminal success state on the graded run.

    behavior · weight 20 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • A consequential action passed through a human approval gate.

    safety · weight 15 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • No non-idempotent operation was retried without an idempotency key.

    efficiency · weight 10 · T1105 Ingress Tool Transfer (Command and Control)

  • Every action node resolves its secret from the vault, never an inline field.

    configuration · weight 10 · T1041 Exfiltration Over C2 Channel (Exfiltration)

  • The learner attached at least one linkable piece of evidence to the case.

    investigation · weight 10 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • The case carries an analyst closure note explaining the outcome.

    explanation · weight 10 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • No innocent asset in the alert batch was contained, disabled or revoked.

    behavior · weight 15 · T1543.003 Create or Modify System Process: Windows Service (Persistence)

  • The playbook survived the integration faults it met and still finished.

    configuration · weight 15 · T1105 Ingress Tool Transfer (Command and Control)

  • Nothing was changed in the estate before evidence had been gathered.

    investigation · weight 10 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • The queue was read on the automation host itself rather than taken on trust.

    investigation · weight 10 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • The unhandled event was identified from the runner's own log.

    investigation · weight 10 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • The beacon peer was read out of the queued event, not guessed.

    investigation · weight 10 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • The affected asset was named before anything was contained.

    investigation · weight 5 · T1543.003 Create or Modify System Process: Windows Service (Persistence)

  • The already-judged benign event was recognized and excluded from the automation.

    safety · weight 10 · T1105 Ingress Tool Transfer (Command and Control)

  • The playbook the learner wrote actually contained the implicated workstation.

    behavior · weight 15 · T1071.001 Application Layer Protocol: Web Protocols (Command and Control)

  • The maintenance server named by the benign event was left alone.

    safety · weight 15 · T1543.003 Create or Modify System Process: Windows Service (Persistence)

  • The playbook wrote a verdict back to the case, so the queue ends in a decided state.

    explanation · weight 10 · T1041 Exfiltration Over C2 Channel (Exfiltration)

  • The analyst scoped the machine itself, so memory-hungry triage steps are planned against real capacity rather than a guess.

    investigation · weight 3

  • Disk capacity was taken from the volume itself, which is what makes an image or memory-dump decision defensible.

    investigation · weight 3

Common mistakes

  • Writing the containment step first and adding the evidence step afterwards, which the dry-run review flags as blind action.
  • Retrying an isolate call because a connector wobbled, and isolating twice.
  • Automating on every event in the queue instead of the one the evidence names.
  • Leaving the case with no verdict, so the queue never reaches a decided state.

Same idea, three vendors

Vocabulary is generated from the teaching profiles, so it always matches what the consoles render.

ConceptCortex ForgeSummit SOARStoryline
artifactIndicatorArtifactRecord
caseIncidentContainerCase
noteWar Room entryNoteCase note
approvalManual taskPromptPage

Where does this value come from?

The same reference to an enrichment node's verdict, written three ways:

  • Cortex Forge: ${enrich-sender.verdict}
  • Summit SOAR: enrich-sender.verdict
  • Storyline: <<enrich-sender.verdict>>

The same concepts in shipping products

The consoles you practice in use teaching names. These are the words the real vendors print in their own documentation, so the vocabulary survives the day you sit in front of a production tenant.

ConceptCortex XSOARXSOAR 8.xSplunk SOARSplunk SOAR 6.x (formerly Phantom)TinesTines (2026 cloud)Microsoft Sentinel + Logic AppsSentinel (Defender portal, 2026)Google SecOps SOARSecOps SOAR (formerly Siemplify)Swimlane TurbineTurbine (2026)Torq HyperautomationTorq (2026)IBM QRadar SOARQRadar SOAR (Resilient) 51.xServiceNow Security OperationsSecOps (Flow Designer era)
artifactIndicatorArtifact (CEF fields)Event payload fieldEntityEntityField / correlation valueEvent fieldArtifactObservable
caseIncidentContainerCaseIncidentCaseRecordCaseIncidentSecurity incident (SIR)
noteWar Room entryNoteCase noteCommentCase wall commentCommentCase commentNoteWork note
approvalManual (data collection) taskPrompt blockPage (form) / Send to ChatApproval action (Teams / email)Manual actionTask / approval actionApproval step (Torq Chat / Slack)Manual task / phase gateApproval activity

What transfers

Read the queue, prove the finding, gate the consequence, write the outcome back. That shape is identical in Splunk SOAR, XSOAR, Tines or a hand-rolled runner, and it survives every change of vendor.