IT Operations & Cybersecurity Encyclopedia
TheHive and Cortex incident response guide
TheHive and Cortex can give a security team a structured incident response workspace, but the value depends on disciplined alert intake, case templates, observable handling, analyzer and responder governance, evidence retention, permissions, metrics, and reporting. This guide explains how to operate the platform as an auditable incident response process instead of a loose ticket queue.
Why it matters
Turn incident activity into controlled response work
TheHive is commonly used to organize alerts, cases, observables, tasks, timelines, comments, reports, and analyst workflow. Cortex extends the process by running analyzers and responders against observables or cases so analysts can enrich indicators and execute approved response actions.
A professional TheHive and Cortex deployment should be reviewed like any other security operations platform. Teams need clear intake paths, severity rules, case templates, evidence standards, access controls, analyzer approvals, responder guardrails, backup procedures, and management reporting.
This guide helps IT and security teams improve TheHive and Cortex operations. It does not replace incident response planning, forensic investigation, legal review, threat hunting, regulatory notification analysis, or a professional cybersecurity audit.
Practical rule: Treat TheHive and Cortex as the response system of record: control alert intake, normalize case templates, protect evidence, approve analyzers/responders, restrict access, and measure response performance.
Review scope
TheHive and Cortex operating domains
Alert intake
Control how alerts enter the platform, how duplicates are handled, and how severity and ownership are assigned.
Case templates
Use standard tasks, fields, tags, reports, and closure requirements for each incident type.
Observable enrichment
Run approved Cortex analyzers against IPs, domains, hashes, URLs, emails, files, and other observables.
Responder governance
Restrict actions that can block, isolate, notify, ticket, or change systems to approved roles and workflows.
Evidence and timeline
Keep attachments, comments, task decisions, observable results, and response actions organized for review.
Access and audit
Review organizations, profiles, external sharing, audit logs, service accounts, API keys, and retention.
Review matrix
TheHive and Cortex review matrix
| Area | What to verify | Questions to answer | Evidence |
|---|---|---|---|
| Alert intake | SIEM, EDR, email, MISP, webhooks, manual alerts, API feeders, severity mapping, duplicate handling, and routing. | Do alerts arrive with enough context to triage quickly? | Connector inventory, routing map, sample alerts, severity rules, and rejected-alert records. |
| Case workflow | Case templates, incident categories, task lists, required fields, custom tags, closure criteria, and reports. | Can analysts follow a consistent response process? | Template export, case examples, task SLA report, closure checklist, and report template. |
| Observables | Observable types, tags, analyzer results, responder results, similarity checks, relationships, and exports. | Are indicators enriched and controlled consistently? | Observable examples, analyzer job history, export records, and enrichment reports. |
| Cortex automation | Analyzers, responders, API keys, service accounts, secrets, proxy settings, execution limits, and job failures. | Are enrichment and response actions approved and traceable? | Analyzer inventory, responder approval list, job logs, API key review, and service account records. |
| Access and sharing | Organizations, profiles, internal sharing, external sharing, attachments, comments, and restricted cases. | Can sensitive incident data be accessed only by approved users? | Role export, organization map, external sharing records, access review, and audit log samples. |
| Metrics and evidence | Backlog, severity aging, triage time, task completion, case timelines, closure quality, retention, and reporting. | Can leadership see response performance and risk? | Dashboard screenshots, KPI exports, case reports, timelines, and monthly review notes. |
Step-by-step review
TheHive and Cortex incident response runbook
Map alert sources
List every source that creates alerts or cases, including SIEM, EDR, email, MISP, webhooks, manual intake, and API feeders.
Standardize case templates
Define templates for phishing, malware, account compromise, data exposure, vulnerability exploitation, insider risk, and service outage events.
Validate observables
Check observable types, required tags, TLP/PAP handling, similarity checks, analyzer reports, and export restrictions.
Govern Cortex jobs
Review analyzers, responders, API keys, secrets, service accounts, job failures, execution permissions, and change approval for new actions.
Review permissions
Audit organizations, profiles, administrators, external sharing, restricted cases, attachment access, and disabled or stale users.
Test response workflow
Walk one representative alert through triage, case creation, enrichment, task assignment, response approval, evidence capture, and closure.
Package audit evidence
Save case reports, timelines, dashboards, job histories, access reviews, connector lists, backup notes, and improvement actions.
Common risks
Common TheHive and Cortex risks
Uncontrolled alert noise
Poor routing and deduplication can bury high-risk incidents inside repeated low-quality alerts.
Unsafe responders
Responder actions can affect production systems if they are available to the wrong roles or lack approval workflow.
Weak evidence discipline
Missing timelines, unclear comments, unmanaged attachments, and inconsistent reports weaken incident review.
Analyzer drift
Broken analyzers, expired API keys, or unmanaged third-party integrations can silently reduce enrichment quality.
Overbroad sharing
Incident cases may contain sensitive data and must be protected through organizations, profiles, and sharing rules.
No management metrics
Without backlog, triage, aging, and closure-quality metrics, leadership cannot see response capacity or recurring risk.
Related support
Where IT Perfection can help
IT Perfection can help operate incident response platforms, improve ticketing workflow, connect monitoring sources, support endpoint and network teams, and keep response evidence organized.
OC Security Audit can help assess incident response maturity, security operations evidence, cyber insurance readiness, and security control gaps.
Created by Ali Hassani, CISO
Professional incident response workflow support
Ali Hassani brings 25+ years of hands-on experience across IT operations, cybersecurity, Microsoft infrastructure, network security, compliance readiness, cloud services, healthcare IT, MSP services, and business technology leadership.
This guide is for initial education and planning. It does not replace a professional cybersecurity audit, compliance assessment, penetration test, legal review, vendor engineering review, or Microsoft professional services engagement.
Response tools need process discipline
TheHive and Cortex work best when alert intake, case templates, observables, analyzer governance, responder approvals, access control, evidence handling, and reporting are managed as one response process.
FAQ
TheHive and Cortex incident response FAQ
What should be reviewed first in TheHive?
Start with alert sources, case templates, required fields, task lists, user roles, sharing rules, and recent case closure quality.
What should be reviewed first in Cortex?
Review analyzers, responders, API keys, service accounts, secrets handling, job failures, and who can execute response actions.
Why are observables important?
Observables such as IPs, domains, URLs, hashes, email addresses, and files are the investigation objects that analysts enrich, relate, export, and use for response decisions.
What evidence should be retained?
Keep case reports, timelines, task records, comments, attachments, analyzer results, responder approvals, access reviews, connector lists, and management dashboards.