A phishing-triage workflow has already run and left its mark on the case. Read the run end to end, from node attempts and resolved bindings to branch operands, and say exactly what it changed.
Mission brief · F-101
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.
Most automation incidents are not 'the tool broke' — they are 'the tool did exactly what it was told, on data nobody looked at'. Reading a run the way a mechanic reads a service log is the single skill that separates an analyst who trusts automation from one who audits it.
The diagram you author is a template. A run freezes one execution of one version of that template: which nodes attempted, what each attempt received after binding, what it returned, and when. Two runs of the same workflow can diverge entirely because their inputs differed, so never debug from the canvas alone.
Each step holds an expression written at design time and a binding resolved at run time. The overwhelming majority of 'broken playbook' tickets are an expression that resolved to empty or to the wrong array element. Compare the two side by side before you suspect the connector.
A decision did not 'choose wrong' — it evaluated operands. Cite the left operand, the comparison and the right operand and the argument about the branch is over in one sentence.
A run belongs to an immutable version id. If you cannot say which version produced a result, you cannot say the fix shipped, and your post-incident note is unverifiable.
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%
8 of 8 rubric rules hold.
Gate denied — 86%
Refusing the consequential action is a defensible choice with a measured cost; the difference is what the lab is teaching.
A spearphishing link drives a credential-harvest page; the run you read is the triage of that lure.
| Technique | Name | Tactic |
|---|---|---|
| T1566.002 | Phishing: Spearphishing Link | Initial Access |
| T1204.001 | User Execution: Malicious Link | Execution |
| T1078 | Valid Accounts | Defense Evasion |
The workflow reached a terminal success state on the graded run.
behavior · weight 20
A reversible 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
The learner cited the enrichment node output that decided the branch.
investigation · weight 20 · T1566.002 Phishing: Spearphishing Link (Initial Access)
The run was attributed to the exact immutable workflow version.
configuration · weight 15 · T1078 Valid Accounts (Defense Evasion)
Vocabulary is generated from the teaching profiles, so it always matches what the consoles render.
| Concept | Cortex Forge | Summit SOAR | Storyline |
|---|---|---|---|
| workflow-run | Playbook run | Playbook debug run | Story run |
| node | Task | Block | Action |
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) |
|---|---|---|---|---|---|---|---|---|---|
| workflow-run | Playbook run | Playbook run / debug run | Event flow | Logic App run | Playbook execution | Playbook execution | Execution | Workflow execution | Flow execution |
| node | Task | Block | Action | Action / step | Action / step | Action | Step | Function / script | Flow action |
Grades the same artifact a real post-incident review asks for: the run record, the exact version that executed, and the resolved input that decided the branch — not a screenshot of the canvas.
Cortex XSOARPalo Alto Networks
Open the incident's Work Plan, switch a task to its inputs/outputs view, and read the resolved ${...} context path against the authored expression.
Splunk SOARSplunk (Cisco)
Use the playbook debugger and the run's action results; datapaths are positional, so check the result count before trusting result 0.
TinesTines
Inspect the emitted event on each action — Tines shows the exact JSON that flowed, which is the resolved binding by another name.
Microsoft Sentinel + Logic AppsMicrosoft
Open the Logic App run history: each action shows Inputs and Outputs after expression evaluation.
IBM QRadar SOARIBM
Read the workflow execution log and the function's inputs; the BPMN diagram alone never tells you which gateway fired.
Every automation platform ships this same triplet — attempt, binding, output. Learn to find those three panes in any tool and you can debug it on day one.
CYBRARY