TheHive & Case Management

Why Case Management Matters

In Lesson 13.1, you learned the IR lifecycle — Preparation through Post-Incident Activity. But a lifecycle on paper does not track itself. When three analysts are working the same P2 incident across a 12-hour shift rotation, someone needs to answer fundamental questions: What has been done? What still needs to happen? Who is responsible for each task? What evidence has been collected? When did we notify stakeholders?

Email threads do not scale. Slack channels lose context. Spreadsheets create version conflicts. Sticky notes on monitors are not an audit trail.

Case management is the operational backbone that turns an IR framework into a trackable, repeatable, auditable process. A case management platform gives your IR team:

TheHive Platform Overview

TheHive is an open-source, scalable Security Incident Response Platform (SIRP) designed specifically for SOC teams. It is not a general-purpose ticketing system like Jira or ServiceNow — it is purpose-built for security incidents with native support for observables, threat intelligence integration, automated analysis, and multi-analyst collaboration.

TheHive's architecture consists of three tightly integrated components:

• TheHive (core platform): Case management, task tracking, observable management, case templates, dashboards, and API
• Cortex (analysis engine): Automated analysis of observables using "analyzers" — plugins that query VirusTotal, AbuseIPDB, MISP, Shodan, PassiveTotal, and dozens of other services. When you add an IP address to a case, Cortex can automatically check it against 30+ threat intelligence sources.
• MISP (threat intelligence): Bidirectional integration — TheHive can query MISP for matching IOCs, and findings from TheHive cases can be exported back to MISP as events to share with the community.

Click to enlarge

How TheHive Fits in the CyberBlueSOC Stack

In the full CyberBlueSOC environment, TheHive sits at the center of the response workflow:

1. Wazuh/Suricata/EveBox detect suspicious activity and generate alerts
2. Shuffle (SOAR) automatically forwards qualifying alerts to TheHive as new alerts
3. An analyst reviews the TheHive alert and promotes it to a case (or merges it with an existing case)
4. The analyst adds observables (IPs, hashes, domains) to the case
5. Cortex automatically analyzes each observable against configured analyzers
6. MISP provides additional context — is this IP in a known campaign? Is this hash in a threat feed?
7. The analyst documents findings, assigns tasks, and tracks the case through resolution

In Lab 13.2, you will work with TheHive directly — creating cases, adding observables, running Cortex analyzers, and managing the case lifecycle.

Creating and Managing Cases

A case in TheHive represents a single security incident or investigation. Every case has structured metadata that drives visibility, prioritization, and handling.

Case Fields

Creating a Case from an Alert

TheHive distinguishes between alerts and cases. Alerts are incoming notifications from integrated tools (Wazuh, Suricata via Shuffle). Cases are confirmed incidents that require investigation.

The workflow:

1. Alert arrives in TheHive (automatically via Shuffle, or manually imported)
2. Analyst reviews the alert — checks source, severity, observables, context
3. Decision point:
   • Promote to new case: This is a new incident requiring investigation
   • Merge into existing case: This alert is related to an incident already being tracked
   • Mark as false positive: Dismiss the alert with a documented reason
   • Ignore: No action needed (use sparingly — document why)

Creating a Case Manually

Not every case starts from an automated alert. Manual case creation covers:

• Incidents reported by users ("I clicked a suspicious link")
• Findings from threat hunts (Module 6 skills)
• External notifications ("Law enforcement called — your data is on a forum")
• Proactive investigations triggered by threat intelligence

In TheHive's UI: New Case → fill in title, severity, TLP, PAP, tags, description → Create. The case receives a unique identifier (e.g., #42) and appears on the dashboard.

Observables: The Evidence Trail

Observables are the technical indicators linked to a case — the artifacts you discover during investigation and the IOCs you correlate against threat intelligence. If you completed Module 5 (Threat Intelligence), you already understand IOC types. In TheHive, these become observables attached to a case.

Observable Data Types

Adding Observables to a Case

When you add an observable, TheHive lets you specify:

• Data type: Select from the list above
• Value: The actual indicator
• TLP: Can differ from the case TLP (e.g., a case might be TLP:AMBER but a specific hash from a public threat report is TLP:GREEN)
• Is IOC: Boolean flag — mark true when this observable is a confirmed indicator of compromise, false when it is still under investigation
• Tags: Additional categorization (c2, phishing, lateral-movement)
• Description: Context about where and how you found this observable

Tasks: Structured Work Assignment

Tasks break a case into discrete, assignable work items. Instead of "investigate the incident," tasks create accountability:

Each task has a task log — a running journal where the assigned analyst documents their work. Task logs are timestamped and become part of the permanent case record. When the next shift analyst picks up the case, they read the task logs to understand exactly what has been done and what remains.

Case Templates

Case templates eliminate the "blank page" problem when creating cases for common incident types. Instead of building task lists from scratch during a crisis, you pre-configure templates during the Preparation phase.

A ransomware case template might include:

Pre-configured fields:

• Severity: 4 (Critical)
• TLP: TLP:AMBER
• PAP: PAP:AMBER
• Tags: ransomware, malware, encryption

Pre-configured tasks:

1. Identify patient zero and initial infection vector
2. Determine scope — how many systems are encrypted?
3. Isolate affected systems from the network
4. Collect forensic images before remediation
5. Identify ransomware variant (check ransom note, encrypted file extensions)
6. Check for decryption tools (NoMoreRansom.org)
7. Assess backup availability and integrity
8. Notify Legal and Cyber Insurance carrier
9. Determine if data exfiltration occurred (double extortion)
10. Begin recovery from verified backups
11. Implement additional monitoring for re-infection
12. Conduct lessons learned meeting

TheHive + Cortex Integration

Cortex is TheHive's analysis engine. When you add an observable to a case, Cortex can automatically run it through dozens of analyzers — saving hours of manual lookups across different threat intelligence platforms.

Click to enlarge

How Cortex Analyzers Work

1. You add an observable to a case (e.g., IP address 198.51.100.47)
2. Click Run Analyzers (or configure auto-run for specific data types)
3. Cortex sends the observable to configured analyzers in parallel:
   • AbuseIPDB: Is this IP reported for abuse?
   • VirusTotal: Has this IP been seen hosting malware?
   • Shodan: What services is this IP running?
   • MISP: Does this IP appear in any MISP events?
   • MaxMind GeoIP: Where is this IP located?
   • Passive DNS: What domains have resolved to this IP?
4. Each analyzer returns a report with a severity taxonomy: info, safe, suspicious, or malicious
5. Reports are attached to the observable within the case — visible to all analysts working the case

Common Cortex Analyzers by Observable Type

Case Lifecycle

Every case in TheHive follows a defined lifecycle that maps to the NIST framework from Lesson 13.1:

Resolution Status Codes

When resolving a case, TheHive requires a resolution status:

Case Metrics and SLAs

TheHive tracks timing metrics automatically:

These metrics serve two purposes: operational (are we meeting our SLAs?) and strategic (are we getting faster over time? do we need more staff? which incident types take longest?).

What's Next

You now understand the tools and workflows for structured case management. In Lesson 13.3: Containment, Eradication & Recovery, you will dive deep into the most operationally intense phase of the IR lifecycle — the decisions and actions that stop an attacker, remove their presence, and restore normal operations. You will learn containment strategies (network isolation, account disabling, IP blocking), eradication techniques (malware removal, credential resets, backdoor elimination), and recovery procedures (backup restoration, system rebuilding, re-infection monitoring). Then in Lab 13.2, you will put case management into practice by creating cases, adding observables, running Cortex analyzers, and managing the full case lifecycle in TheHive.