A screening model rejected eligible applicants for a day. Classify the incident against the threshold text using the record's own numbers, work the reporting clock from detection, and find the inventory artifact the system has never had.
Mission brief · A-320
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.
The first serious AI incident in an organization is usually mis-reported: late, vague, or overstated. Classification against a written threshold and a clock that runs from detection turns an argument into arithmetic, and lets you report honestly while the facts are still incomplete.
The threshold table states its tests. Apply them to the incident record's own figures — people affected, reversibility — and the class falls out. Do not let the owning team's adjectives do the classification.
Reporting windows start when you knew, not when you understood. Work out the deadline first so the report is scoped to the time you actually have.
An initial report with explicit unknowns is credible and correctable. One that overstates certainty becomes a second finding when it turns out to be wrong.
An inventory record with no model card will be found by the regulator anyway. Naming it yourself, with a date to fix it, is the difference between a gap and a cover-up.
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%
15 of 15 rubric rules hold.
Gate denied — 92%
Refusing the consequential action is a defensible choice with a measured cost; the difference is what the lab is teaching.
A standing deployment identity keeping an unfit system promotable while an incident is still being reported.
| Technique | Name | Tactic |
|---|---|---|
| T1078 | Valid Accounts | Defense Evasion |
| T1199 | Trusted Relationship | Initial Access |
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
The classification came from the record and the threshold text on the host.
investigation · weight 15 · T1078 Valid Accounts (Defense Evasion)
The population was quoted from the record rather than described as 'a number of users'.
investigation · weight 10 · T1199 Trusted Relationship (Initial Access)
The class was derived by applying the threshold text to the record's own numbers.
investigation · weight 10 · T1199 Trusted Relationship (Initial Access)
The reporting deadline was read off the class rather than negotiated.
explanation · weight 10 · T1199 Trusted Relationship (Initial Access)
The documentation gap was found, so the report can state it rather than be caught out by it.
configuration · weight 10 · T1199 Trusted Relationship (Initial Access)
The deployment identity was held under approval so the unfit model cannot be re-promoted mid-report.
safety · weight 20 · 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 |
|---|---|---|---|
| artifact | Indicator | Artifact | Record |
| approval | Manual task | Prompt | Page |
| note | War Room entry | Note | Case note |
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) |
|---|---|---|---|---|---|---|---|---|---|
| artifact | Indicator | Artifact (CEF fields) | Event payload field | Entity | Entity | Field / correlation value | Event field | Artifact | Observable |
| approval | Manual (data collection) task | Prompt block | Page (form) / Send to Chat | Approval action (Teams / email) | Manual action | Task / approval action | Approval step (Torq Chat / Slack) | Manual task / phase gate | Approval activity |
| note | War Room entry | Note | Case note | Comment | Case wall comment | Comment | Case comment | Note | Work note |
Threshold, clock, evidenced statement, named gaps is the structure of every regulated incident report, AI or otherwise.
CYBRARY