TheHive Case Management for SOC Teams

Why Case Management Matters

An alert is a claim that something might be wrong. An investigation is the structured work of confirming or refuting that claim, and a case is the container that holds that work. Without a case management system, investigations live in analysts' heads, scattered chat messages and ad hoc spreadsheets, which means they are not repeatable, not auditable and not handoverable.

TheHive provides the container. Every meaningful event becomes a case with a clear owner, a set of tasks, the observables under examination, a timeline of actions and a final disposition. When an auditor, a regulator or a customer asks how a particular incident was handled, the answer is a single exportable case rather than an archaeology project across five tools.

Case management is also what makes a SOC scale beyond one heroic analyst. Tasks can be assigned, templates encode institutional knowledge, and a new analyst can pick up an in-progress case and see exactly what has been done and what remains. This is the difference between a team and a collection of individuals who happen to share a tool.

The TheHive Data Model

TheHive organises work around four primary objects. An alert is an inbound, ungraded signal, usually created automatically by a SIEM, EDR or SOAR pipeline through the API. Alerts sit in a triage queue and carry a source, a severity and a set of observables, but no investigative work yet.

A case is an active investigation. It has a title, severity, TLP and PAP markings, an assignee, a description, a set of tasks and a set of observables. Cases are where analysts actually work. A case is created either from scratch or, far more commonly, by promoting one or more alerts.

A task is a unit of work inside a case: collect host logs, isolate the endpoint, check the firewall, draft customer notification. Tasks have their own assignee and status, and each task carries a task log where the analyst records what they did and what they found, building the investigation timeline.

An observable is an artefact attached to a case or alert: an IP, a domain, a hash, an email address, a filename, a URL. Observables carry a data type, a TLP marking, tags and an is-IOC flag. They are the objects that Cortex analyzers enrich and that MISP shares. A clean observable model is what makes enrichment and intelligence sharing work.

The Alert-to-Case Workflow

The day-to-day SOC loop runs through the alert queue. Detection tooling and the SOAR layer create alerts in TheHive via the API. An analyst reviews the queue, reads the alert details and attached observables, and makes a triage decision: ignore, mark as false positive, or promote to a case.

Promotion is the key transition. When an analyst promotes an alert, TheHive creates a case pre-populated with the alert's observables and metadata, optionally applying a case template so the right tasks are created automatically. Several related alerts can be merged into a single case, which is how a multi-stage attack that tripped five different detections becomes one coherent investigation rather than five disconnected ones.

Once a case exists, the investigation proceeds through its tasks. Analysts enrich observables, run Cortex analyzers, pivot on findings, add new observables they discover, and log their work. When the investigation concludes, the case is closed with a resolution status and a summary, and that closed case is the permanent, auditable record of how the event was handled.

Collaboration and Templates

TheHive is built for more than one analyst on one case. Tasks within a case can be assigned to different people, so a senior analyst handles containment while a junior collects evidence and a third drafts communications, all visible in the same case in real time. Comments and task logs keep everyone synchronised without out-of-band chatter.

Case templates are where repeatable response lives. A phishing template might pre-create tasks for header analysis, URL detonation, user notification and mailbox search, with default severity and tags. A ransomware template pre-creates isolation, scoping, backup-validation and notification tasks. When an analyst promotes an alert and picks a template, the standard playbook materialises instantly, so the team responds the same disciplined way every time regardless of who is on shift.

Metrics and custom fields let you capture the data your programme reports on: time to detection, time to containment, affected asset count, business unit, attack category. These fields turn a pile of closed cases into a dataset you can report to management and use to find where the programme is slow.

Cortex and MISP Integration

TheHive's value multiplies through two native integrations. Cortex is the analysis and response engine. From inside a case, an analyst selects an observable and runs Cortex analyzers against it: reputation, sandbox detonation, passive DNS, threat intelligence lookups. The verdicts attach straight back to the observable, so enrichment happens without leaving the case. Cortex responders then let the analyst take action from the same screen, such as blocking an IP or disabling an account.

MISP is the threat intelligence side. TheHive can pull MISP events as alerts, so an intelligence indicator that matches your environment becomes a triageable alert automatically. It can also push case observables out to MISP as a new event, contributing what you discovered back to a sharing community. The loop is detection feeds cases, cases produce intelligence, and intelligence sharpens future detection.

These integrations are what make TheHive the centre of the stack rather than just a ticketing tool. A case is not a static record; it is a workspace where detection, enrichment, response and intelligence sharing all happen against the same set of observables.

Operating TheHive in Production

Running TheHive well is mostly discipline. Decide your severity and TLP conventions up front and enforce them, because inconsistent grading makes the queue meaningless. Build a small set of case templates for your most common incident types before you go live, rather than improvising tasks during a real incident.

Connect the API early. Almost no alerts should be created by hand; the SIEM, EDR and SOAR layer should be feeding the alert queue automatically with consistent, well-structured observables. Hand-created alerts are fine for tabletop exercises but a sign of a broken pipeline if they dominate in production.

Plan for retention and access. Cases contain sensitive detail, so use organisations and role-based access to scope who sees what, and define how long closed cases are retained to satisfy your audit and regulatory obligations. Back up the underlying database, because in an open source SOC TheHive is the system of record for everything your analysts did.

Finally, review closed cases as a body of evidence rather than filing them away. A monthly read across recently closed cases reveals patterns no single case shows: a detection that keeps producing false positives, an asset that keeps appearing in investigations, a task that analysts consistently skip because it adds no value. Each pattern is a tuning opportunity, either in the detection layer, the asset hygiene, or the case templates themselves. The closed-case archive is one of the most underused sources of operational improvement in a SOC, and TheHive makes it queryable.