12.1 Elastic Security Case Management & Triage Workflows
Key Takeaways
Elastic Security Cases provide a centralized, collaborative incident management workspace natively embedded within Kibana, unifying alerts, timelines, comments, and forensic files.
Cases support both alert-driven instantiation (from individual or bulk detection alerts) and ad-hoc creation for proactive threat hunts and intelligence-led investigations.
Case metadata taxonomies enforce operational governance through standardized Severity levels (Low, Medium, High, Critical), Status progression (Open, In Progress, Closed), Tags, and Assignees.
Attaching alerts, Timeline links, files, Lens visualizations and comments keeps the investigation record in one place, and the case activity log shows who changed what and when.
Role-based access control (RBAC) and Kibana Spaces enable granular case isolation, ensuring sensitive investigations (e.g., insider threat or executive compromise) remain restricted to authorized personnel.
The Role of Case Management in Modern Security Operations
In high-throughput enterprise Security Operations Centers (SOCs), validating and acknowledging an individual detection alert represents only the opening phase of incident response. Sophisticated cyber intrusions rarely manifest as a single, isolated anomaly. Instead, advanced persistent threats (APTs), credential stuffing campaigns, and ransomware deployments unfold across multiple endpoints, network segments, identity providers, and cloud environments over days or weeks.
Historically, SOC teams struggled with operational fragmentation. Analysts frequently tracked active investigations across disjointed tools: juggling third-party ticketing platforms, spreadsheets, disparate chat channels, and offline text files. This fragmentation caused critical investigative context to slip through the cracks, obscured chain-of-custody documentation, and severely inflated Mean Time to Remediate (MTTR).
Elastic Security Cases provides a purpose-built, collaborative incident management framework built directly into Kibana. Cases serve as the operational single pane of glass where Tier 1 triage analysts, Tier 2 incident responders, Tier 3 threat hunters, forensics specialists, and SOC managers collaborate in real time. By natively linking detection alerts, interactive Timelines, raw telemetry, forensic notes, and remediation actions within a single auditable object, Cases eliminates workflow silos and preserves an immutable chain of custody throughout the incident lifecycle.
Case Creation Paradigms: Alert-Driven vs. Ad-Hoc Investigations
Elastic Security accommodates two fundamental investigation models: reactive alert-driven triage and proactive threat hunting.
+-------------------------------------------------------------------------+
| Case Creation Paradigms |
+-------------------------------------------------------------------------+
| [ Alert-Driven Inception ] [ Ad-Hoc Inception ] |
| |
| Detection Engine Alert Triggered Proactive Threat Hunt |
| (e.g., LSASS Memory Dumping) or External Intel Report |
| | | |
| v v |
| Alert Details Flyout / Bulk Table Elastic Security Cases UI |
| Click: "Add to Case" Click: "Create Case" |
| | | |
| +---------------------+---------------------+ |
| | |
| v |
| +--------------------------+ |
| | Elastic Security Case | |
| | - Title, Description | |
| | - Severity, Tags | |
| | - Status: Open | |
| | - Assigned SOC Analyst | |
| +--------------------------+ |
+-------------------------------------------------------------------------+
1. Alert-Driven Case Creation
The vast majority of SOC investigations begin when a detection rule fires in the Elastic Security Detection Engine. Analysts can instantiate or append to cases directly from the alert triage workflow:
- From the Alert Details Flyout: When triaging an alert, clicking the Take action menu and selecting Add to case allows the analyst to either create a brand-new case or attach the finding to an active, ongoing case.
- Bulk Case Escalation: In the main Alerts table, analysts can multi-select several related alerts (e.g., ten credential access alerts across different domain controllers) and execute a bulk action to attach all of them to a unified investigation case in a single operation.
- Automated Context Ingestion: When an alert is attached to a case, Elastic Security automatically extracts and indexes the alert's primary metadata—including the detection rule name, rule type, alert severity, MITRE ATT&CK tactic and technique mappings, affected host (
host.name), affected user (user.name), and precise timestamps. This referential link remains permanent, allowing any investigator reviewing the case to drill down into the original alert document.
2. Ad-Hoc Case Creation
Security investigations do not always originate from automated detection rules. Tier 3 threat hunters, red team coordinators, and SOC leads frequently open cases independently:
- Hypothesis-Driven Threat Hunts: An analyst conducting proactive sweeps for living-off-the-land binaries (LOLBAS) or anomalous DNS tunneling may uncover suspicious behavior that has not yet triggered an alert. The analyst navigates to Cases and clicks Create case to initialize an investigation workspace.
- External Intelligence & Third-Party Advisories: When external law enforcement, national CERT advisories (e.g., CISA KEV alerts), or external third-party incident response firms report compromise indicators, analysts create an ad-hoc case to track internal compromise assessments and scoping activities.
Case Anatomy: Metadata Taxonomy & Operational Governance
Every Elastic Security Case is defined by structured metadata fields designed to enforce SOC accountability, align with Service Level Agreements (SLAs), and facilitate longitudinal metrics reporting.
+-------------------------------------------------------------------------+
| Case: [INC-2026-1044] Active C2 & Lateral Movement via WMI |
+-------------------------------------------------------------------------+
| Status: [ In Progress v ] Severity: [ Critical v ] Assignee: [rchen]|
| Tags: [ apt29, lateral-movement, pci-dss, ransomware-prep ] |
| Reporter: SOC Tier 1 (jdoe) Created: 2026-09-30 08:15:00 UTC |
+-------------------------------------------------------------------------+
| Description: Markdown Scope & Initial Triage Hypothesis |
| Host srv-db-prod01 exhibited anomalous outbound beaconing to suspected |
| bulletproof hosting provider (198.51.100.24) following WMI execution. |
+-------------------------------------------------------------------------+
| [ Attached Alerts (4) ] [ Attached Timelines (2) ] [ Files / PCAP (1) ] |
+-------------------------------------------------------------------------+
| Comments & Chronological Activity Log |
| - 08:20:00 [jdoe]: Isolated host srv-db-prod01 via Elastic Defend. |
| - 08:35:12 [rchen]: Attached Timeline 'WMI Execution Genealogy'. |
| - 08:42:00 [rchen]: Escalated to Tier 3 IR; notified CISO. |
+-------------------------------------------------------------------------+
1. Case Metadata Fields
- Title: A concise, descriptive summary of the incident. SOC best practices dictate using a standardized nomenclature, such as
[Incident Type] - [Primary Asset/User] - [Brief Threat Description](e.g.,[Ransomware] - wks-fin-04 - BlackCat Pre-Encryption Activity). - Description: A comprehensive markdown-enabled text field outlining the initial incident hypothesis, observed impact, initial indicators of compromise (IOCs), and the scope of affected systems.
- Severity: A four-tier classification governing response urgency and escalation SLAs:
- Low: Informational anomalies, single-system policy violations, or benign administrative deviations with negligible business impact.
- Medium: Suspicious activities requiring operational validation (e.g., repeated failed authentications, unauthorized script execution on non-critical workstations).
- High: Verified adversary tradecraft, persistence installation, unauthorized privilege escalation, or malware execution on production servers.
- Critical: Active ransomware execution, root/domain controller compromise, widespread lateral movement, or confirmed exfiltration of regulated data (e.g., PCI-DSS or HIPAA data).
- Status: The operational state of the investigation:
- Open: The initial state upon creation. Indicates that the case has been logged and is awaiting analyst triage, scoping, or assignment.
- In Progress: Active investigation, forensics, threat hunting, or containment actions are currently being performed by the assigned team.
- Closed: All remediation, containment, and eradication milestones have been verified, root causes identified, and post-incident documentation finalized.
- Tags: Multi-value categorization tags utilized for filtering and reporting. Common tagging taxonomies include MITRE ATT&CK tactics (
credential-access,defense-evasion), compliance flags (sox-scope,pci-environment), or threat actor designations (storm-0501,fin7). - Assignees & SOC Teams: Designates individual analysts or functional team queues (e.g.,
Tier 2 Incident Response,Forensics Unit) responsible for case resolution.
Evidence Attachment & Chain of Custody
A critical technical advantage of Elastic Security Cases is its ability to aggregate diverse forensic artifacts into an immutable record. Preserving evidentiary integrity is vital not only for operational root-cause analysis but also for legal compliance, regulatory breach notifications, and digital forensics chain of custody.
1. Attaching Alerts
Multiple detection alerts from across the enterprise can be aggregated into a single case. For example, if an attacker executes a password spray against Microsoft 365, compromises an Azure AD user, logs into an internal VPN, and executes PowerShell on an endpoint, alerts from all three layers (Cloud, Network, Endpoint) are appended to one case. Each attached alert retains its full ECS telemetry document, rule snapshot, and initial triage disposition.
2. Attaching Timelines & Pinned Events
Analysts investigating complex incidents in the Elastic Security Timeline can seamlessly export their workspace into the case:
- Pinned events, custom query strings, temporal brackets, and analyst markdown annotations are permanently associated with the case record.
- Any team member reviewing the case can click the attached Timeline link to open the exact query canvas, replicating the primary investigator's analytical view without manual query re-entry.
3. File Attachments & Artifact Storage
Investigators can upload external forensic evidence directly to the case:
- Supported artifacts include packet capture snippets (
.pcap), memory dump summaries, script samples, malware execution logs, and network architecture diagrams. - Uploaded files are stored in Elasticsearch through Kibana's files service and protected by Kibana privileges.
4. Markdown Comments & Collaborative Notes
Cases support real-time analyst collaboration through rich markdown comments. Analysts can embed tables, formatted code blocks, shell commands, and direct hyperlinks. Comments are permanently timestamped and attributed to the authenticated user, establishing a chronological operational log of every discovery, hypothesis test, and containment decision.
5. Case Settings and Metrics Every Analyst Should Know
- Sync alert status with case status: Chosen when the case is created and on by default. With sync on, changing the case status (for example closing it) updates the status of its attached alerts, and it can be turned off later.
- External incident management system: A case can be linked to a connector (ServiceNow, Jira, IBM Resilient, Swimlane or Webhook - Case Management) and pushed to that system.
- Case closure setting (Cases → Settings): Close cases manually, or close them automatically when a new incident is pushed to the external system. Closing the ticket in the external system does not close the Elastic case.
- Custom fields and templates (Cases → Settings) standardize the information every case collects.
- Visualizations: Lens charts can be added to a case as evidence.
- Case metrics under the title summarize total alerts, associated users and hosts, total connectors and the duration from creation to close.
Incident Escalation Lifecycle & Milestone Tracking
Managing an enterprise security incident requires structured progression through defined operational milestones. Elastic Security Cases provides the tracking foundation across four core phases:
- Triage & Scoping (Open -> In Progress): Tier 1 validates detection alerts, correlates related host and user entities, determines initial severity, and assigns the case to an incident responder.
- Containment & Evidence Collection (In Progress): The responder executes containment actions directly from Elastic Security (such as isolating endpoints via Elastic Defend, revoking user sessions, or blocking malicious IPs). Pinned Timeline events, Osquery live query results, and volatile memory notes are attached to the case.
- Eradication & Recovery (In Progress): Malicious persistence mechanisms (scheduled tasks, run keys, backdoor services) are removed. Systems are restored from known-good backups or patched. Analysts confirm the absence of adversary re-entry by executing continuous targeted threat hunting queries.
- Post-Incident Review & Closure (Closed): The response team compiles the final incident report, identifies root-cause failures, updates detection rules or exceptions to prevent recurrence, and transitions the case to
Closed.
Reference Matrix: Case Lifecycle, Responsibilities, and Evidence Standards
The following operational matrix details the expectations, role responsibilities, and required evidence across each phase of the Elastic Security Case lifecycle:
| Lifecycle State | Primary SOC Role | Operational Milestones & Actions | Mandatory Evidence & Documentation Requirements |
|---|---|---|---|
| Open | Tier 1 SOC Analyst | Validate initial alerts; eliminate false positives; assess initial blast radius; assign severity and primary owner. | Triggering alert documents attached; initial entity risk scores (HRS/URS) recorded; triage notes documented. |
| In Progress | Tier 2 Incident Responder | Perform deep scoping; execute host containment via Elastic Defend; isolate compromised credentials. | Chronological Timeline attached with pinned events; containment execution timestamps; endpoint network logs. |
| In Progress (Forensics) | Tier 3 Forensics / Threat Hunter | Reverse-engineer malicious payloads; reconstruct process execution genealogy; identify persistence mechanisms. | Visual event analyzer notes; Osquery triage logs; forensic file/script artifacts uploaded. |
| Closed | SOC Lead / Incident Commander | Verify eradication; oversee system restoration; conduct Post-Incident Review (PIR); tune detection rules. | Executive summary markdown; root-cause analysis; detection rule tuning tickets or exceptions linked; final sign-off. |
A Tier 1 SOC analyst identifies three related detection alerts indicating lateral movement across different database servers. The analyst needs to aggregate these findings into a unified operational record that preserves all underlying ECS telemetry, MITRE ATT&CK mappings, and analyst triage notes for Tier 2 escalation. What is the recommended Elastic Security workflow?
Export the alerts as individual PDF files and email them to the Tier 2 distribution list.
Select the three alerts from the Alerts table and use the bulk action menu to add them to a newly created Elastic Security Case.
Delete the alerts from the detection index and write a custom KQL query in Discover to manually track the hosts.
Create a new Kibana Lens visualization that plots the alert timestamps on a bar chart and save it to a personal dashboard.
An incident responder is actively investigating a High-severity credential dumping incident in Elastic Security. After isolating the infected host and revoking compromised credentials, what lifecycle transition must the responder execute once eradication is verified and post-incident documentation is finalized?
Transition the Case status directly from Open to Acknowledged.
Archive the underlying Elasticsearch cluster index and re-enroll the Elastic Defend agent.
Transition the Case status from In Progress to Closed and document root-cause findings and remediation milestones.
Reduce the Case severity from High to Low and delete all attached Timeline objects.
During a multi-host ransomware investigation, a threat hunter creates an ad-hoc Timeline, discovers critical lateral movement commands, and pins several pivotal process execution events. How does the hunter ensure these pinned events and custom query parameters are preserved and accessible to the entire incident response team within their Elastic Security Case?
Take a screenshot of the browser window and save it on a local desktop folder.
Hardcode the Elasticsearch cluster IP address into the browser's local storage cache.
Manually copy the raw JSON of each document into an external spreadsheet.
Attach the Timeline directly to the active Case using the 'Attach to Case' feature in the Timeline interface.
Sections you finish are checked off in the contents.