The enrichment stage is too big to maintain and the containment step is too dangerous to run unattended. Split enrichment into a child playbook, then contain a mailbox rule behind an approval gate a second analyst must clear.
Mission brief · X-210
you, signed in to the automation platform as `eng.you` (build role, not the on-call responder)
You are not on the console watching the queue. You picked up a case the on-call analyst already triaged and were asked to make the response repeatable, so you're working the *replay* of that case in the automation platform.
Automation platform (author + test)
Automation platform
Ticketing (read + work notes)
Ticketing / ITSM
The playbook itself
Owner: SOC manager (approves anything that touches production)
A playbook that contains hosts without an approval gate will do it at 3am, at machine speed, to every host in the batch.
You may act alone
Ask a human first
In a real SOC the analyst works the alert and hands the *pattern* to you. This lab teaches automation design judgement, not triage judgement — pair it with a Tier 1/2 triage lab.
Sub-workflows are how a playbook library stays maintainable — and how a subtle failure becomes invisible. Knowing what crosses the boundary is the difference.
In Cortex Forge this is called Sub-playbook.
A sub-playbook takes inputs and returns outputs. Anything it touches outside that contract — mutating shared context, closing the parent's tasks — is a side effect that will bite someone at 3am.
In Cortex Forge this is called Context path.
Map inputs explicitly and read outputs explicitly. Relying on inherited context makes the child unusable anywhere else, which defeats the point of writing it.
Decide deliberately whether a child failure fails the parent, or is caught and downgraded. Undeclared, it becomes whatever the platform's default is — and the default is rarely what an incident commander wants.
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.
Gate approved — 100%
11 of 11 rubric rules hold.
Gate denied — 90%
Refusing the consequential action is a defensible choice with a measured cost; the difference is what the lab is teaching.
Post-compromise mailbox persistence: an inbox forwarding rule plus hiding rules that keep the victim unaware.
| Technique | Name | Tactic |
|---|---|---|
| T1078 | Valid Accounts | Defense Evasion |
| T1114.003 | Email Collection: Email Forwarding Rule | Collection |
| T1564.008 | Email Hiding Rules | Defense Evasion |
The workflow reached a terminal success state on the graded run.
behavior · weight 20
A consequential action passed through a human approval gate.
safety · weight 15
No non-idempotent operation was retried without an idempotency key.
efficiency · weight 10
Every action node resolves its secret from the vault, never an inline field.
configuration · weight 10
The learner attached at least one linkable piece of evidence to the case.
investigation · weight 10
The case carries an analyst closure note explaining the outcome.
explanation · weight 10
No innocent asset in the alert batch was contained, disabled or revoked.
behavior · weight 15
The playbook survived the integration faults it met and still finished.
configuration · weight 15
Nothing was changed in the estate before evidence had been gathered.
investigation · weight 10
A child run executed and returned into the parent context.
behavior · weight 20 · T1078 Valid Accounts (Defense Evasion)
The attacker mailbox forwarding rule is gone at end state.
behavior · weight 20 · T1114.003 Email Collection: Email Forwarding Rule (Collection)
Vocabulary is generated from the teaching profiles, so it always matches what the consoles render.
| Concept | Cortex Forge | Summit SOAR | Storyline |
|---|---|---|---|
| child-workflow | Sub-playbook | Child playbook | Sub-story |
| context-path | Context path | Datapath | Event path |
The same reference to an enrichment node's verdict, written three ways:
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.
| Concept | Cortex XSOARXSOAR 8.x | Splunk 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.x | ServiceNow Security OperationsSecOps (Flow Designer era) |
|---|---|---|---|---|---|---|---|---|---|
| child-workflow | Sub-playbook | Child playbook | Send to Story | Nested Logic App | Block | Sub-playbook | Nested workflow | Called workflow | Subflow |
| context-path | Context path (${...}) | Datapath | Formula (<<path.to.value>>) | Expression (@{body('step')}) | Placeholder ([Entity.Identifier]) | Reference ($record.field) | Expression ({{ .event.field }}) | Rule/script object (incident.properties) | Data pill |
Grades the composition contract: declared inputs and outputs, and a deliberate answer to 'what happens to the parent when the child fails'.
Cortex XSOARPalo Alto Networks
Sub-playbooks declare inputs/outputs; a sub-playbook that writes to parent context is the usual source of 3am surprises.
Splunk SOARSplunk (Cisco)
Child playbooks are called synchronously or asynchronously — that choice, not a setting you inherit, decides propagation.
TinesTines
Send to Story passes an explicit payload; anything else the child needs is a design smell.
Microsoft Sentinel + Logic AppsMicrosoft
Nested Logic Apps propagate failure only if you configure run-after behavior; the default silently continues.
This is ordinary function design: explicit parameters, explicit returns, declared error behavior.
CYBRARY