11.1 Alert Triage Workflow & the Alert Details Flyout
Key Takeaways
Detection alerts have three statuses, Open, Acknowledged and Closed; closed alerts can be reopened, and dispositions such as False Positive are recorded with alert tags (kibana.alert.workflow_tags), assignees and case notes.
Alert severity is set by the rule, whereas entity risk scores (0–100) combine the risk scores of a host's or user's open and acknowledged alerts from the last 30 days, adjusted by asset criticality.
The alert details flyout has Overview, Table and JSON tabs, with About, Investigation, Visualizations, Insights (entities, threat intelligence, correlations, prevalence) and Response sections.
The flyout's Take action menu adds alerts to cases, changes status, adds exceptions, opens Timeline, runs Osquery, and isolates hosts with Elastic Defend (Platinum or higher) while they keep sending data to the Elastic Stack.
Tier 1 triage workflows enforce structured escalation paths: tuning noisy rules via rule exceptions and alert suppression, while escalating verified true positives to Tier 2 incident response.
Modern SOC Alert Triage in Elastic Security
In high-throughput Security Operations Centers (SOCs), detection rules continuously evaluate streaming telemetry against thousands of indicators of compromise (IOCs), behavioral anomalies, and correlation logic. This generates hundreds or thousands of security alerts daily into the dedicated alert index (.alerts-security.alerts-*). Without a disciplined, repeatable operational triage framework, security teams rapidly succumb to alert fatigue, increasing the risk that sophisticated adversary intrusions remain unnoticed amidst operational noise.
Elastic Security provides a structured alert triage ecosystem designed to accelerate Tier 1 validation, streamline Tier 2 escalation, and maintain an immutable audit trail of analyst decisions. Mastering alert lifecycle management, understanding the distinction between static rule severity and dynamic entity risk scoring, navigating the Alert Details Flyout, and executing tactical containment actions are core competencies for SIEM analysts.
Alert Statuses & Disposition Tracking
Every detection alert has one of three workflow statuses. Tracking them keeps the SOC accountable and supports metrics such as Mean Time to Respond (MTTR).
+-------------------------------------------------------------------------+
| Alert Workflow Statuses |
| |
| [ New Alert Generated ] |
| | |
| v |
| +-------+ Analyst takes ownership +--------------+ |
| | Open | ------------------------------> | Acknowledged | |
| +-------+ +--------------+ |
| | | |
| +--------------------+----------------------+ |
| v |
| +----------+ |
| | Closed | -- can be set back to Open |
| +----------+ if new evidence appears |
| |
| Disposition is recorded with alert tags (e.g. "False Positive", |
| "Duplicate"), assignees, notes and cases -- not a closing reason. |
+-------------------------------------------------------------------------+
1. Alert Workflow Statuses
- Open: The default status of every new detection alert. The Alerts page shows open alerts by default, and unassigned open alerts are the SOC's working backlog.
- Acknowledged: The alert is under active investigation. Marking it acknowledged tells the rest of the shift that someone is handling it.
- Closed: The investigation is finished. Closed alerts stay searchable, can be reopened by setting them back to Open, and are excluded from entity risk scoring.
You change status from the row's More actions (…) menu, in bulk with Selected x alerts, for a whole group through Take actions, or from the flyout's Take action menu. In Elastic Security 8.15, closing an alert does not prompt for a resolution reason.
2. Recording the Disposition: Tags, Assignees and Notes
- Alert tags (
kibana.alert.workflow_tags) label alerts for filtering and reporting. The default tag options are Duplicate, False Positive and Further investigation required, managed through thesecuritySolution:alertTagsadvanced setting. Apply them with Apply alert tags, then search, for example,kibana.alert.workflow_tags : "False Positive". - Assignees (
kibana.alert.workflow_assignee_ids) show who owns an alert. Assigning users does not notify them, and the Assignees filter shows each analyst's queue. - Notes and cases capture the reasoning, for example that an alert was authorized penetration testing or a confirmed intrusion that has been remediated.
A useful vocabulary for dispositions, even though Elastic does not enforce it:
- True positive: The rule detected real malicious activity. Escalate it, attach it to a case, and close it after remediation.
- False positive: The rule fired on activity that does not match its intent, such as an IT tool that looks like an attack. Tag it False Positive and fix the cause with a rule exception or query change.
- Benign true positive: The rule correctly detected the behavior, but it was authorized, such as a scheduled penetration test. Document the authorization and close the alert.
3. Organizing the Alerts Page
The Alerts page defaults to the last 24 hours and to open alerts. Up to four drop-down filter controls narrow the list (Status, Severity, User and Host by default; the Status control cannot be removed). Group alerts by nests alerts under up to three fields, such as rule name, host name or source IP. The visualization section offers Summary, Trend, Counts and Treemap views. Building block alerts are hidden unless you include them under Additional filters. The table can switch between the grid view and an event rendered view.
Severity Levels vs. Dynamic Entity Risk Scoring
A common point of confusion in SIEM operations is the operational distinction between Alert Severity and Entity Risk Score. Both provide numerical and categorical threat ratings, but they evaluate security posture from entirely different dimensions.
1. Alert Severity
Alert severity is defined at the detection rule level. It reflects the potential technical impact and confidence of an isolated detection condition:
- Low (risk score guideline 0–21): Informational events, minor policy non-compliance, or high-volume baseline anomalies that present negligible immediate compromise risk (e.g., first-time user login from an uncommon workstation).
- Medium (22–47): Suspicious events that warrant operational review during normal shift cycles (e.g., suspicious PowerShell execution flags, multiple failed SSH login attempts).
- High (48–73): High-confidence indicators of malicious adversary activity (e.g., LSASS memory dumping, credential dumping utilities, suspicious scheduled task creation).
- Critical (74–100): Immediate active threats posing severe organizational risk (e.g., endpoint ransomware execution, unauthorized domain controller replication, known active C2 beaconing).
2. Entity Risk Scoring (Host and User Risk Scores)
While severity describes one alert, entity risk scoring summarizes the recent alert history of a host or user. In 8.15 it is a beta feature that needs a Platinum or higher subscription and must be turned on (for example from the Host risk or User risk tab or the Entity Analytics settings). It works like this:
- The risk scoring engine runs hourly and collects Open and Acknowledged alerts from the last 30 days, up to 10,000 alerts per entity.
- It groups them by
host.nameoruser.nameand combines their individual alert risk scores (kibana.alert.risk_score) so that higher-scoring alerts contribute more. This is the Alerts category of the risk summary. - If the entity has an asset criticality level (enabled with the
securitySolution:enableAssetCriticalityadvanced setting), the score is adjusted by its weight: Low impact 0.5, Medium impact 1, High impact 1.5, Extreme impact 2. - The result is normalized to 0–100 and mapped to a risk level:
| Risk level | Risk score |
|---|---|
| Unknown | < 20 |
| Low | 20–40 |
| Moderate | 40–70 |
| High | 70–90 |
| Critical | > 90 |
Entities with no alerts, or with only Closed alerts, get no risk score. Scores are stored in the risk-score.risk-score-<space-id> data stream and appear in the Entity Analytics dashboard, the Hosts and Users pages, and the host and user flyouts. View risk contributions shows the top 10 contributing alerts.
Triage Prioritization Impact
Entity risk scores transform triage workflows. An isolated Medium severity alert occurring on a laptop with an HRS of 12 can be triaged through standard queues. However, that exact same Medium severity alert occurring on a server with an HRS of 88 (indicating multiple prior detections across credential access and lateral movement) requires immediate priority escalation to Tier 2 incident response.
Anatomy of the Alert Details Flyout
Clicking View details (the expand icon) on an alert opens the alert details flyout. It is the main triage workspace, with a right panel for the summary and a left panel that opens for expanded views.
+--------------------------------------------------------------------------+
| Alert: Suspicious PowerShell Download [Chat] [Share alert] |
| Severity: High | Risk score: 73 | Status: Open | Assignees: rchen |
+--------------------------------------------------------------------------+
| Tabs: [ Overview ] [ Table ] [ JSON ] |
| Overview sections: |
| About - rule description, alert reason, MITRE ATT&CK |
| Investigation - investigation guide, highlighted fields |
| Visualizations - Session View preview, Analyzer preview |
| Insights - Entities, Threat intelligence, Correlations, |
| Prevalence |
| Response - response actions defined on the rule |
+--------------------------------------------------------------------------+
| [ Take action v ] status, case, exception, isolate, Timeline, Osquery |
+--------------------------------------------------------------------------+
1. Header and Tabs
The header shows severity, risk score, status and assignees. It also has a Chat button that opens AI Assistant with the alert as context, and a Share alert button for a stable alert URL. The Overview tab summarizes the alert, the Table tab lists every field as a field-value pair, and the JSON tab shows the raw alert document. Hovering over a field shows inline actions: Filter In, Filter Out, Add to timeline, Show top N and Copy to clipboard.
2. About and Investigation
About explains what the rule looks for, why this alert fired (the reason statement) and the rule's MITRE ATT&CK tactic, technique and sub-technique mapping. Investigation shows the rule's investigation guide, if it has one, which can include buttons that launch Timeline queries or Osquery. It also shows the highlighted fields, including custom highlighted fields defined on the rule.
3. Visualizations
The Analyzer preview shows up to three levels of ancestors and descendants of the alerted process, and the Session View preview summarizes Linux session activity. Each opens the full tool in Timeline.
4. Insights
- Entities: The host and user involved, with risk scores and levels (Platinum or higher) and recent activity.
- Threat intelligence: Matched indicators, plus fields enriched with threat intelligence, which checks the alert against threat indices over the past 30 days.
- Correlations: Suppressed alerts, alerts from the same source event, cases that contain the alert, alerts from the same session, and alerts related by process ancestry (Platinum or higher).
- Prevalence: How often the alert's highlighted field values appear in other alerts and events over the last 30 days, with host and user prevalence percentages on Platinum or higher. Rare values are strong leads.
5. Response
Lists the response actions (such as Osquery or endpoint actions) configured on the rule.
Direct Containment and Response Actions
The Alert Details Flyout is not merely a passive display; it is an active response launchpad. Directly from the flyout footer and action menus, analysts can execute critical operational workflows:
1. Add to Case
Clicking Add to Case attaches the alert, its metadata, and its entity context to an existing investigation case or initializes a brand-new case. All associated ECS fields and analyst notes are formally indexed into the case record, maintaining chain-of-custody documentation.
2. Investigate in Timeline
Clicking Investigate in Timeline opens the Elastic Security Timeline canvas. Timeline opens with the alert loaded, or with up to 2,000 selected alerts sent from the table. For a threshold alert, all matching events are listed, including ones that did not reach the threshold. If the rule has a Timeline template, its template filters are filled in with the alert's values (for example host.name: "{host.name}" becomes the alert's host).
3. Endpoint Host Isolation (Elastic Defend)
For high-confidence endpoint compromises, analysts can click the Take Action menu and select Isolate Host:
- Requirements: Host isolation needs a Platinum or Enterprise subscription, the Host Isolation privilege, and hosts running Elastic Defend on Windows, macOS or supported Linux distributions. You can isolate from the alert flyout (Take action → Isolate host), from the Endpoints page, or from the response console (Enterprise). An optional comment explains why.
- Effect: The host is blocked from communicating with other hosts on the network, which stops lateral movement and C2 traffic.
- Preserved Visibility: Isolated hosts can still send data to Elasticsearch and Kibana, so analysts keep receiving telemetry, can run response actions, and can later choose Release host. Host isolation exceptions let specific IP addresses, such as a VPN or DNS server, remain reachable.
- Audit Trail: Every isolation and release is recorded in the host's response actions history, and an Isolated status appears next to the agent status.
Alert Statuses, Transitions, and SOC Escalation Paths
The following operational matrix details the transition conditions, required actions, and escalation pathways across alert lifecycle states:
| Alert Status | Entry Condition | Analyst Action | Next Statuses | Typical Record of Disposition |
|---|---|---|---|---|
| Open | Created by a detection rule, or reopened | Review in the queue; verify entity context and rule logic | Acknowledged, Closed | Assign an owner; tag Further investigation required if needed |
| Acknowledged | Analyst has taken ownership | Deep triage in the flyout; pivot to Timeline; check entity risk | Closed, Open | Notes, case link, escalation to Tier 2 if malicious |
| Closed | Investigation finished | Document outcome; create exceptions for confirmed false positives | Open (reopen) | False Positive or Duplicate tag, case notes for true positives |
A Tier 1 SOC analyst triages a High-severity alert triggered by a rule named 'Suspicious PowerShell Download'. Upon inspecting the process command line and parent process in the Alert Details Flyout, the analyst determines that the script was executed by the enterprise IT monitoring software (C:\Program Files\Monitoring\agent.exe) during a scheduled inventory collection script. Which disposition and follow-up action should the analyst take?
Close the alert, apply the False Positive alert tag, and add a rule exception matching the monitoring agent's parent process path to prevent repeat alerts.
Close the alert and delete the alert document from the underlying Elasticsearch index to clear queue metrics.
Leave the alert in the Open state, but reduce the rule's risk score from 75 to 0 across the entire Elastic Security deployment.
Mark the alert as Acknowledged, create an Elastic Security Case, and immediately isolate the IT monitoring server.
An operational SOC shift receives two alerts simultaneously during a peak shift period: Alert X is a High-severity alert on a workstation with a Host Risk Score of 15. Alert Y is a Medium-severity alert on an application server with a Host Risk Score of 88. How should the triage queue prioritize these alerts according to Elastic Security entity analytics best practices?
Alert X must be triaged first because detection rule severity is the only metric governed by SOC Service Level Agreements (SLAs).
Alert Y should be prioritized for immediate investigation because an elevated Host Risk Score indicates cumulative multi-alert malicious behavior and high aggregate risk on that entity.
Both alerts should be automatically closed by the ingestion pipeline until an alert with a Critical severity rating arrives.
Alert X should be prioritized because workstations are always more susceptible to internet phishing attacks than back-end application servers.
During the triage of an active ransomware alert, an incident responder selects 'Isolate Host' from the Alert Details Flyout action menu. How does the Elastic Defend agent enforce this network containment on the target endpoint?
It powers down the physical network interface controller (NIC) via the host BIOS management bus.
It drops all inbound network traffic while allowing unrestricted outbound internet connections to maintain telemetry reporting.
It blocks the host's network communication with other hosts, while the host can still send data to Elasticsearch and Kibana and reach any IP addresses listed as host isolation exceptions.
It uninstalls all networking drivers and forces an immediate operating system reboot into Safe Mode.
Sections you finish are checked off in the contents.