14.3 Workbooks; Ticket vs Alert vs Detection Rule

Workbooks exist so 03:00 does not invent a new process

TryHackMe's SAL1 training content (24 March 2025) groups Alert Triage and Ticketing around the purpose of SOC workbooks, the difference between a ticket, an alert, and a detection rule, then the triage workflow and classification fields in the next section. This independent section is the object model and the human procedure. Section 14.4 is how you walk the workflow and apply verdicts.

A workbook (often called a runbook in operations teams) is a written, step-by-step guide for investigating a class of detection: "possible brute force," "macro spawned a script interpreter," "impossible travel," "scanner-like outbound sweep." Purpose:

• Consistency. Two L1s on two continents should check the same facts, not whichever dashboard they like.
• Completeness. Stress makes people skip asset lookup or related-alert search. The workbook lists the steps.
• Speed. You are not designing science at 03:00; you are executing a known path, then branching when evidence says so.
• Handoff. Follow-the-sun only works if the next analyst can see which workbook steps already ran.
• Safety. Workbooks say when L1 may isolate, when L1 must stop and call IR, and when L1 must not run attacker tools.

A workbook is human procedure. A Security Orchestration, Automation, and Response (SOAR) playbook (chapter 12) may automate enrichment or ticket creation for the same detection. They cooperate: SOAR can attach VirusTotal output and open the ticket; the workbook still tells L1 what to decide. Do not assume the exam simulator will click the workbook for you. Read company documentation the same way: it is the local workbook for that fictional firm.

Workbooks are not sacred forever. After a tabletop or a messy incident, detection engineering and the SOC manager update the steps. L1's job is to follow the current version and to note when a step is impossible ("asset list has no BR-WKS-22") rather than skip silently.

Three objects: rule, alert, ticket

Candidates fail items by using these words as synonyms. They are not.

Detection rule (correlation search, EDR behavioral rule, email policy). This is logic. It lives in a SIEM, EDR, or email gateway whether or not anything is firing right now. It has a name, a version, a severity assignment, maybe a MITRE technique tag, and an owner—usually detection engineering. You can disable, tune, or split a rule. You cannot "close" a rule the way you close a case; you change its code or its exceptions.

Alert (notable, detection, firing). This is one instance of the rule matching telemetry at a time. It carries a timestamp, affected asset, raw or highlighted events, severity, and often a status (New, in progress). Alerts are ephemeral operational objects. Ten alerts can come from one rule in one night. Closing an alert does not delete the rule.

Ticket (incident, case, ServiceNow/Jira record, simulator case). This is the human work record. It has an assignee, comments, SLA clocks, and a place for verdict and evidence. One ticket may group five alerts that are the same incident. One alert may spawn a ticket. A vulnerability-scan finding may become a ticket with no SOC alert at all. Tickets outlive the blinking badge in the SIEM.

Traps:

• Treating the alert title as a verdict. Titles are hypotheses ("possible C2"). Investigation can refute them.
• "Closing the rule" when you mean closing the ticket. The next night the rule will fire again—correctly, if it is a good rule.
• Opening a ticket with no link back to the alert identifiers, so nobody can replay the evidence.
• Assuming SOAR creating a ticket means the case is already triaged. Automation opened a folder; L1 still thinks.

How a rule becomes an alert that becomes a ticket

1. Telemetry exists. Endpoint, identity, email, proxy, or firewall events reach the SIEM or EDR (chapter 12 pipeline).
2. The detection rule evaluates. Threshold, join, signature, or analytics model matches.
3. An alert object is created. Severity is usually copied from the rule or from a scoring function. Status starts at New.
4. Ticketing. A SOAR playbook may open a ticket automatically and attach enrichment. Or L1 opens the ticket manually from the alert. Some SOC platforms are the ticket (the notable is the case). Mentally you still have three layers: logic, firing, human record.
5. Workbook. L1 executes the steps for that rule's class.
6. Outcome. Verdict and status on the alert; comments and next action on the ticket; possibly a separate FP-remediation ticket for the rule.

If step 2 never happens, you can still have a ticket from a phone call ("user reports a ransom note"). If step 4 never happens, the alert can rot in New until an SLA breaks (chapter 15). If you change step 1's parsing, the same rule may stop firing even though attackers did not leave—that is a pipeline bug, not a quiet night.

Worked lifecycle: Cedar Bank "rare 60-second HTTPS beacon"

Rule (logic, always there). Detection engineering maintains CEDAR-C2-BEACON-60, version 1.4: EDR plus proxy correlation for a process making HTTPS connections to a rare domain at an interval near 60 seconds for 10 minutes, excluding the documented availability-probe list. Severity assignment: High. Workbook ID: WB-C2-01.

Tuesday 13:05 UTC — alert (a firing). Host BR-WKS-22, user a.nguyen, process wscript.exe, destination updates-cdn-mail.example (48-hour-old domain), interval 58–62 seconds. Alert ID ALT-88412. Status New. Severity High. This object did not exist at 13:04. The rule did.

Ticket. SOAR opens INC-22019, copies the alert ID, runs a threat-intel lookup (domain unknown in the TIP), and assigns the Dublin L1 queue. The ticket is now the place Priya writes. She does not edit the rule's SPL to "fix" this one host.

Workbook WB-C2-01 (human steps, abbreviated). (1) Record time, host, user, process, destination. (2) Check change calendar and scanner list—BR-WKS-22 is not SCAN-VULN-01. (3) Parent process: winword.exe opening an email attachment—not the signed helpdesk installer. (4) Related alerts: email gateway "newly observed sender" two minutes earlier to a branch mailbox. (5) Enrich domain and hash. (6) Verdict and escalation path.

Outcome on the objects. Alert ALT-88412 gets verdict true positive and status escalated. Ticket INC-22019 gets the evidence and IR assignment. Rule CEDAR-C2-BEACON-60 stays enabled—it did its job. If this had been the helpdesk installer misfiring a different rule, Priya would still close that alert and ticket, and open a second ticket aimed at detection engineering about the rule.

A second firing at 13:41 UTC (same host, cmd.exe discovery) is a new alert, often the same ticket. Do not open a disconnected incident for every badge. Do not pretend the second firing is a new rule.

What L1 writes so the objects stay honest

On the ticket, write enough that a Singapore analyst can continue: alert IDs, rule name and version if shown, workbook ID and steps completed, facts versus guesses, and whether the rule needs a quality follow-up. On the alert, set status to match reality (in progress, escalated, closed). Do not set the rule to disabled because one TP scared you.

Independent study of these SAL1 ticketing topics is mechanical on purpose. Simulator classification scoring sits on top of this model: you are disposing alerts using workbook-like investigation, and your case notes are the ticket. If you rewrite the wrong object, you either leave the attacker in place or you smash a useful detection.