| 1 | --- |
| 2 | title: Case templates |
| 3 | description: Reusable investigation playbooks with predefined tasks and timeline auditing for cases. |
| 4 | --- |
| 5 | |
| 6 | # Case templates |
| 7 | |
| 8 | **Menu:** Incident Management → Case Templates |
| 9 | |
| 10 | **Best for:** Admin / Analyst (template ownership is restricted to these roles) |
| 11 | |
| 12 | Case templates are reusable **investigation playbooks** you attach to cases. Each template defines a set of tasks (with optional guidelines) that get snapshot-copied onto a new case when the template matches. Customers see the resulting tasks read-only on their portal so they know what's being worked on. |
| 13 | |
| 14 | Templates address three real problems: |
| 15 | |
| 16 | - **Investigation consistency** — every case for a given alert source follows the same checklist |
| 17 | - **Auditability** — task status changes, comments, and case mutations all land in a per-case timeline |
| 18 | - **Onboarding** — new analysts don't have to memorize the playbook; the case carries it |
| 19 | |
| 20 | --- |
| 21 | |
| 22 | ## Where templates apply |
| 23 | |
| 24 | A template has three optional scoping fields: |
| 25 | |
| 26 | | Field | Effect | Example | |
| 27 | |---|---|---| |
| 28 | | `customer_code` | Restricts the template to one customer. Empty = global. | `ACME` | |
| 29 | | `source` | Restricts the template to one alert source. Empty = any source. | `wazuh` | |
| 30 | | `is_default` | This is the fallback template within its (customer_code, source) scope. | true / false | |
| 31 | |
| 32 | When a case is created **from an alert**, the backend picks the most specific matching template using this priority: |
| 33 | |
| 34 | 1. `customer_code` + `source` exact match |
| 35 | 2. `customer_code` only (source IS NULL) |
| 36 | 3. `source` only (customer_code IS NULL) |
| 37 | 4. Global default (`is_default=true` with both NULL) |
| 38 | |
| 39 | Each step short-circuits the next on first match. Within a step, ties are broken by `is_default` first, then by most-recently-created. |
| 40 | |
| 41 | > **First-alert-wins.** When a case is created from an alert, the template is picked from that alert's `(customer_code, source)`. If you later link more alerts to the case, additional templates are **not** auto-applied — analysts can manually apply more via the case's Tasks tab if needed. |
| 42 | |
| 43 | --- |
| 44 | |
| 45 | ## Authoring a template |
| 46 | |
| 47 | **Menu:** Incident Management → Case Templates → **New template** |
| 48 | |
| 49 | | Field | Required | Notes | |
| 50 | |---|---|---| |
| 51 | | Name | yes | Short, recognizable. Shown in the picker on case creation. | |
| 52 | | Description | no | Free-form context for analysts. | |
| 53 | | Customer code | no | Empty = global. | |
| 54 | | Alert source | no | Empty = any source. | |
| 55 | | Default for scope | no | Marks this as the fallback within its (customer, source) pair. Only one default per scope; activating one auto-demotes any other. | |
| 56 | | Tasks | yes | At least one task. Each task has title, description, guidelines, mandatory toggle, and order. | |
| 57 | |
| 58 | ### Task fields |
| 59 | |
| 60 | | Field | Effect | |
| 61 | |---|---| |
| 62 | | Title | Short statement of what to do (e.g., "Identify affected assets") | |
| 63 | | Description | Longer explanation — what success looks like | |
| 64 | | Guidelines | Step-by-step or links to runbooks. Rendered collapsibly under each task on the case Tasks tab. | |
| 65 | | Mandatory | If true, **NOT_NECESSARY** is rejected and closing the case with this task incomplete fires a soft warning. | |
| 66 | | Order | Drag arrows in the editor reorder tasks; lower order_index renders first. | |
| 67 | |
| 68 | > Edits to a template **do not** mutate task snapshots already attached to real cases. Each `CaseTask` row is a copy made at template-application time. This way historical investigations stay locked to the template version that was in effect when they were opened. |
| 69 | |
| 70 | --- |
| 71 | |
| 72 | ## Tasks on a real case |
| 73 | |
| 74 | **Menu:** any case → **Tasks** tab |
| 75 | |
| 76 | Analysts see: |
| 77 | |
| 78 | - The full task list (status, evidence notes, completion attribution) |
| 79 | - A status dropdown per task: **TODO**, **DONE**, **NOT_NECESSARY** (last is greyed out for mandatory tasks) |
| 80 | - An evidence textarea where you can paste logs, command output, screenshots-as-text, or links |
| 81 | - "Add task" — for one-off custom tasks added during the investigation |
| 82 | - "Apply template" — to layer another template's tasks onto the case (e.g., add an EDR-specific checklist after a Wazuh template was already applied) |
| 83 | |
| 84 | Customers see the same list **read-only** on the customer portal. They cannot change status, edit evidence, or add tasks. |
| 85 | |
| 86 | --- |
| 87 | |
| 88 | ## Soft warning on close |
| 89 | |
| 90 | When you try to close a case where one or more **mandatory** tasks are not marked DONE, a confirmation modal appears listing the incomplete tasks. You can: |
| 91 | |
| 92 | - **Cancel** — closes the modal, leaves the case in its current status |
| 93 | - **Close anyway** — closes the case and records `forced=true` in the timeline so the override is auditable |
| 94 | |
| 95 | The intent is to remind, not block. Mandatory + soft warning gives consistency without forcing analysts to lie ("I marked it done so I could close it") — the override is captured honestly in the audit trail. |
| 96 | |
| 97 | --- |
| 98 | |
| 99 | ## Timeline tab |
| 100 | |
| 101 | **Menu:** any case → **Timeline** tab |
| 102 | |
| 103 | Append-only audit log of meaningful case mutations. One row per: |
| 104 | |
| 105 | - Case created (manual or from alert) |
| 106 | - Status change (with the `forced=true` flag when the soft warning was bypassed) |
| 107 | - Assignment, escalation |
| 108 | - Alert link / unlink (single or bulk) |
| 109 | - Comment added (with a short snippet preview) |
| 110 | - Template applied |
| 111 | - Task added (template-derived or custom) |
| 112 | - Task status change |
| 113 | - Task evidence comment |
| 114 | |
| 115 | Customer portal shows the same timeline read-only. |
| 116 | |
| 117 | --- |
| 118 | |
| 119 | ## Examples |
| 120 | |
| 121 | ### Wazuh global default |
| 122 | |
| 123 | ``` |
| 124 | Name: Wazuh — Default |
| 125 | Source: wazuh |
| 126 | Customer: (empty — global) |
| 127 | Default: yes |
| 128 | Tasks: |
| 129 | 1. Triage alert (mandatory) |
| 130 | 2. Identify affected assets (mandatory, with guidelines) |
| 131 | 3. Check Wazuh agent for related events (mandatory) |
| 132 | 4. Document findings (optional) |
| 133 | 5. Notify customer (optional, NOT_NECESSARY allowed) |
| 134 | ``` |
| 135 | |
| 136 | Result: any case created from a Wazuh alert (regardless of customer) gets these five tasks pre-populated. Closing the case requires steps 1–3 to be DONE or the soft warning fires. |
| 137 | |
| 138 | ### Customer-specific override |
| 139 | |
| 140 | ``` |
| 141 | Name: ACME — Wazuh |
| 142 | Source: wazuh |
| 143 | Customer: ACME |
| 144 | Default: yes |
| 145 | Tasks: |
| 146 | 1. Triage alert (mandatory) |
| 147 | 2. Identify affected assets (mandatory) |
| 148 | 3. Check ACME-specific runbook in wiki (mandatory, guidelines link) |
| 149 | 4. Page on-call if business-hours (mandatory) |
| 150 | ``` |
| 151 | |
| 152 | Because `(customer=ACME, source=wazuh)` is more specific than `(customer=any, source=wazuh)`, ACME's Wazuh cases get this template instead of the global one. |
| 153 | |
| 154 | ### EDR-specific addon |
| 155 | |
| 156 | ``` |
| 157 | Name: CrowdStrike — Investigation |
| 158 | Source: crowdstrike |
| 159 | Customer: (empty) |
| 160 | Default: no |
| 161 | Tasks: |
| 162 | 1. Pull process tree from EDR |
| 163 | 2. Identify network connections |
| 164 | 3. Collect memory dump if hash unknown (guidelines: link to runbook) |
| 165 | ``` |
| 166 | |
| 167 | Marked non-default. Auto-applies on create-from-CrowdStrike-alert. Analysts can also manually apply this template to a Wazuh case mid-investigation if EDR work becomes relevant. |
| 168 | |
| 169 | --- |
| 170 | |
| 171 | ## Permissions summary |
| 172 | |
| 173 | | Capability | Admin | Analyst | Customer User | |
| 174 | |---|---|---|---| |
| 175 | | Manage templates (create / edit / delete) | ✅ | ✅ | — | |
| 176 | | Apply template to case | ✅ | ✅ | — | |
| 177 | | Add custom case task | ✅ | ✅ | — | |
| 178 | | Update case task status / evidence | ✅ | ✅ | — | |
| 179 | | Delete case task | ✅ | ✅ | — | |
| 180 | | View case tasks | ✅ | ✅ | ✅ (read-only) | |
| 181 | | View case timeline | ✅ | ✅ | ✅ (read-only) | |
| 182 | | Close case with incomplete mandatory tasks | ✅ | ✅ | — | |
| 183 | |
| 184 | --- |
| 185 | |
| 186 | ## How to use templates well |
| 187 | |
| 188 | The mechanics above describe what templates *can* do. This section is about *how to actually use them* so they accelerate investigations instead of cluttering them. |
| 189 | |
| 190 | ### Start with one global default per source, then layer |
| 191 | |
| 192 | Resist the urge to author per-customer templates on day one. The path that scales: |
| 193 | |
| 194 | 1. **Pick your top 2–3 alert sources** (Wazuh, CrowdStrike, Velociraptor — whatever drives the most cases). Author one **global default** per source. Each should have 3–6 mandatory tasks that capture the universal triage flow, plus 2–4 optional tasks for common follow-ups. |
| 195 | 2. **Run for two weeks.** Watch which tasks consistently get marked NOT_NECESSARY. Watch what custom tasks analysts add (the Tasks tab "Add task" button — those are unmet template needs). Track close-with-force events in the timeline. |
| 196 | 3. **Tune the global default** based on what you saw. Demote noisy mandatory tasks to optional, promote frequently-added custom tasks into the template. |
| 197 | 4. **Only then** start adding customer-specific overrides for the customers that actually have a different runbook (PCI environments, regulated industries, customer-specific evidence requirements, etc.). |
| 198 | |
| 199 | You can always create more templates. Removing them later is harder once analysts have memorized the workflow. |
| 200 | |
| 201 | ### Mandatory discipline — what *should* block close |
| 202 | |
| 203 | The soft warning fires on close when a mandatory task isn't DONE. The override is recorded as `forced=true` in the timeline. |
| 204 | |
| 205 | A task should be **mandatory** only if: |
| 206 | |
| 207 | - Skipping it would leave you unable to answer "what did you actually find?" later |
| 208 | - Skipping it would fail a compliance/audit review |
| 209 | - Skipping it would leave the customer with an unsupported claim ("the alert was benign") |
| 210 | |
| 211 | A task should be **optional** if: |
| 212 | |
| 213 | - It only applies in some scenarios (e.g., "Pull memory dump" — only matters if hash is unknown) |
| 214 | - It's nice-to-have but the case can close honestly without it |
| 215 | - It's expensive (analyst time, customer time) and not always justified |
| 216 | |
| 217 | > **Anti-pattern:** marking everything mandatory. Analysts will start force-closing routinely, the timeline fills with `forced=true`, and the soft warning becomes background noise instead of a real safety net. |
| 218 | |
| 219 | ### Use guidelines as the runbook quick-reference |
| 220 | |
| 221 | The `guidelines` field renders as a collapsible panel under each task. Treat it as the **5-second runbook** — what the analyst needs without leaving the case page. |
| 222 | |
| 223 | Good guidelines content: |
| 224 | |
| 225 | - 1–3 sentences of "what success looks like for this task" |
| 226 | - A direct link to the deeper runbook in your wiki/SharePoint/Confluence |
| 227 | - 2–3 bullet hints if there's a common gotcha |
| 228 | - Actual command snippets if the task involves running something |
| 229 | |
| 230 | ``` |
| 231 | Bad: "Investigate the alert." |
| 232 | Good: "Confirm the alert isn't a known false positive (check our exception list |
| 233 | at <wiki link>). If new, pull the matching events from the last 24h via |
| 234 | Graylog query: source.ip:X.X.X.X AND event.action:authentication_failure" |
| 235 | ``` |
| 236 | |
| 237 | ### Evidence comments are the compliance trail |
| 238 | |
| 239 | Every task has an evidence comment textarea. The customer-portal user sees this read-only. |
| 240 | |
| 241 | What to put there: |
| 242 | |
| 243 | - **Logs / command output** — paste the actual snippet, don't just describe it |
| 244 | - **Reference IDs** — Jira ticket, ServiceNow change number, Velociraptor hunt ID, Graylog query URL |
| 245 | - **Decisions and reasoning** — "marked NOT_NECESSARY because the affected host is decommissioned, see asset CMDB" |
| 246 | - **Customer communication** — "notified customer at 14:32 EST via portal comment" |
| 247 | |
| 248 | What *not* to put there: |
| 249 | |
| 250 | - Sensitive data the customer shouldn't see (the customer-portal will surface it) |
| 251 | - Internal-team chatter (use case Comments tab for that — also visible to customer but framed as conversation) |
| 252 | |
| 253 | ### Reorder for natural investigation flow |
| 254 | |
| 255 | The order_index dictates display order on the case Tasks tab. Sequence tasks the way an analyst actually works the case: |
| 256 | |
| 257 | 1. Triage / scope (is this real? how big?) |
| 258 | 2. Identify (who/what/where) |
| 259 | 3. Investigate (logs, processes, network) |
| 260 | 4. Decide (true positive / false positive / inconclusive) |
| 261 | 5. Act (contain / notify / document) |
| 262 | 6. Close (notify customer, retro) |
| 263 | |
| 264 | Tasks higher in the list should be cheaper and faster — get to a triage decision early so the analyst doesn't burn 30 minutes investigating before realizing it's a known false positive. |
| 265 | |
| 266 | ### The two-template pattern: source + capability |
| 267 | |
| 268 | Many investigations are "Wazuh detection that needs EDR follow-up". Rather than authoring one giant Wazuh-with-EDR template, use two: |
| 269 | |
| 270 | - `Wazuh — Default` (auto-applies via source match) |
| 271 | - `CrowdStrike — Investigation` (manually layered when EDR work is needed) |
| 272 | |
| 273 | Analyst flow: |
| 274 | 1. Case auto-opens from Wazuh alert with the Wazuh template |
| 275 | 2. Initial triage reveals lateral movement → analyst clicks "Apply template" and picks the CrowdStrike one |
| 276 | 3. Both templates' tasks are now on the case, separately tracked |
| 277 | |
| 278 | This keeps each template focused (and reusable for non-co-occurring scenarios) and lets you grow the library without exploding the matrix. |
| 279 | |
| 280 | ### Custom-task adds as a feedback loop |
| 281 | |
| 282 | The "Add task" button on the case Tasks tab is for one-off needs that don't fit any template. But it's also a *signal*. If you find: |
| 283 | |
| 284 | - The same custom task being added across many cases → promote to a template task |
| 285 | - A custom task being added on cases for one specific customer → maybe that customer needs an override template |
| 286 | - Custom tasks consistently appearing *before* the template's first task → reorder so the template starts where investigations actually start |
| 287 | |
| 288 | Schedule a 30-minute monthly template review and look at recent custom tasks. The data is in the timeline (`task_added` events with `source: "custom"`). |
| 289 | |
| 290 | ### Timeline as compliance + handoff tool |
| 291 | |
| 292 | The timeline is more than an audit log — it's the case's **narrative**. When you hand a case to another analyst (shift change, escalation), they should be able to read the timeline top-to-bottom and understand: |
| 293 | |
| 294 | - What's been done |
| 295 | - What's left |
| 296 | - What the analyst was thinking (via task evidence comments and case Comments) |
| 297 | |
| 298 | For compliance reviews, the timeline answers: "Was the procedure followed? When? By whom? If it wasn't, was the deviation documented?" The `forced=true` flag on close, the evidence comments on each task, and the actor/timestamp on each event give you that story without manually reconstructing it. |
| 299 | |
| 300 | ### Customer-portal as transparency tool |
| 301 | |
| 302 | Customers see Tasks + Timeline read-only. Use this deliberately: |
| 303 | |
| 304 | - **Mandatory tasks signal effort.** A customer seeing 5 mandatory tasks completed with evidence understands their alert was investigated, not just dismissed. |
| 305 | - **Status changes signal velocity.** OPEN → IN_PROGRESS → CLOSED with reasonable timestamps in the timeline shows responsiveness. |
| 306 | - **Evidence comments signal substance.** A task marked DONE with no evidence looks like a checkbox tick. A task with `"Pulled process tree from EDR, no suspicious children. See Velociraptor hunt vh-1234"` shows real work. |
| 307 | |
| 308 | If you don't want the customer to see a particular detail, put it in the case Comments tab (still visible) framed as analyst-to-analyst conversation, or in your internal wiki and reference the link from the evidence comment. |
| 309 | |
| 310 | ### Quarterly template review checklist |
| 311 | |
| 312 | Set a recurring 30-minute meeting with your analyst leads: |
| 313 | |
| 314 | - [ ] What's the close-with-force rate per template? (Anything > 20% suggests a mandatory task is wrong.) |
| 315 | - [ ] What custom tasks were added this quarter? Any patterns? |
| 316 | - [ ] Are there customers consistently force-closing with the global template? Time for an override. |
| 317 | - [ ] Are there templates with > 80% NOT_NECESSARY on a specific task? Demote it. |
| 318 | - [ ] Have any new alert sources been onboarded that need their own template? |
| 319 | - [ ] Any guideline links that 404? (Wiki rot is real.) |
| 320 | |
| 321 | --- |
| 322 | |
| 323 | ## Common gotchas |
| 324 | |
| 325 | ### "I edited the template but the existing case didn't change" |
| 326 | Expected — task rows on a case are snapshots, not live references. New cases will pick up the edits; old ones won't. |
| 327 | |
| 328 | ### "I deleted a template and the case Tasks tab is empty" |
| 329 | Not expected. Template deletion preserves CaseTask snapshots and only nulls the soft `template_task_id` link. If tasks vanished, file an issue. |
| 330 | |
| 331 | ### "The wrong template auto-applied to my case" |
| 332 | Check the priority order. A more specific match (customer + source) always wins over a less specific one. If you have multiple defaults at the same scope, the most-recently-created wins — promote the one you want to default and the others get auto-demoted. |
| 333 | |
| 334 | ### "The customer portal shows a task they shouldn't see" |
| 335 | Customer portal scoping uses the case's `customer_code`. If a case is mis-scoped, the tasks follow it. Fix the case's customer_code; the tasks come along for the ride. |