performing-alert-triage-with-elastic-siem
Perform systematic alert triage in Elastic Security SIEM—classifying, prioritizing, and investigating alerts using Kibana, ES|QL queries, and ECS-normalized data—to drive SOC analyst workflows. Use when triaging incoming Elastic Security detections, prioritizing an analyst's alert queue, or investigating alerts during SOC operations.
- License 许可
- Apache-2.0
- 最近更新
- 2026-08-31
- Stars
- ★ 3.6w
- Forks
- 4.4k
01 前言 Front Matter
- name
- performing-alert-triage-with-elastic-siem
- tags
- [ "elastic", "siem", "alert-triage", "soc", "elastic-security", "detection", "esql", "kibana" ]
- author
- mahipal
- domain
- cybersecurity
- license
- Apache-2.0
- version
- 1.0
- nist_csf
- [ "DE.CM-01", "DE.AE-02", "RS.MA-01", "DE.AE-06" ]
- subdomain
- soc-operations
- description
- Perform systematic alert triage in Elastic Security SIEM—classifying, prioritizing, and investigating alerts using Kibana, ES|QL queries, and ECS-normalized data—to drive SOC analyst workflows. Use when triaging incoming Elastic Security detections, prioritizing an analyst's alert queue, or investigating alerts during SOC operations.
- mitre_attack
- [ "T1078", "T1685.002", "T1685.005", "T1566" ]
- d3fend_techniques
- [ "Token Binding", "Restore Access", "Application Protocol Command Analysis", "Password Authentication", "Reissue Credential" ]
02 资源文件 7
- 资产文件assets/template.md1.2 KB
- 许可证LICENSE11.0 KB
- 参考文档references/api-reference.md2.8 KB
- 参考文档references/standards.md1.7 KB
- 参考文档references/workflows.md1.6 KB
- 脚本scripts/agent.py6.6 KB
- 脚本scripts/process.py11.2 KB
03 SKILL.md 正文
Performing Alert Triage with Elastic SIEM
Overview
Alert triage in Elastic Security is the systematic process of reviewing, classifying, and prioritizing security alerts to determine which represent genuine threats. Elastic's AI-driven Attack Discovery feature can triage hundreds of alerts down to discrete attack chains, but skilled analyst triage remains essential. A structured triage workflow typically takes 5-10 minutes per alert cluster using Elastic's built-in tools.
When to Use
- When conducting security assessments that involve performing alert triage with elastic siem
- When following incident response procedures for related security events
- When performing scheduled security testing or auditing activities
- When validating security controls through hands-on testing
Prerequisites
- Elastic Security deployed (version 8.x or later)
- Elastic Agent or Beats configured for endpoint and network data collection
- Detection rules enabled and generating alerts
- Elastic Common Schema (ECS) compliance across data sources
- Analyst access to Kibana Security app with appropriate privileges
Alert Triage Workflow
Step 1: Initial Alert Assessment (2 minutes)
When viewing an alert in Elastic Security, review the alert details panel:
Alert Details Panel:
- Rule Name and Description
- Severity and Risk Score
- MITRE ATT&CK Mapping
- Host and User Context
- Process Tree (for endpoint alerts)
- Timeline of related events
Key Fields to Examine First
| Field | Purpose | ECS Field |
|---|---|---|
| Rule severity | Initial priority assessment | kibana.alert.severity |
| Risk score | Quantified threat level | kibana.alert.risk_score |
| Host name | Affected system | host.name |
| User name | Affected identity | user.name |
| Process name | Executing process | process.name |
| Source IP | Origin of activity | source.ip |
| Destination IP | Target of activity | destination.ip |
| MITRE tactic | Attack stage | threat.tactic.name |
Step 2: Context Gathering (3 minutes)
Query Related Events with ES|QL
FROM logs-endpoint.events.*
| WHERE host.name == "affected-host" AND @timestamp > NOW() - 1 HOUR
| STATS count = COUNT(*) BY event.category, event.action
| SORT count DESC
Find All Activity from Suspicious User
FROM logs-*
| WHERE user.name == "suspicious-user" AND @timestamp > NOW() - 24 HOURS
| STATS count = COUNT(*), unique_hosts = COUNT_DISTINCT(host.name) BY event.category
| SORT count DESC
Check for Related Alerts from Same Source
FROM .alerts-security.alerts-default
| WHERE source.ip == "10.0.0.50" AND @timestamp > NOW() - 24 HOURS
| STATS alert_count = COUNT(*) BY kibana.alert.rule.name, kibana.alert.severity
| SORT alert_count DESC
Investigate Lateral Movement from Same IP
FROM logs-system.auth-*
| WHERE source.ip == "10.0.0.50" AND event.outcome == "success"
| STATS login_count = COUNT(*), hosts = COUNT_DISTINCT(host.name) BY user.name
| WHERE hosts > 3
Step 3: Threat Intelligence Enrichment (2 minutes)
Check indicators against threat intelligence:
FROM logs-ti_*
| WHERE threat.indicator.ip == "203.0.113.50"
| KEEP threat.indicator.type, threat.indicator.provider, threat.indicator.confidence, threat.feed.name
Check File Hash Against Known Threats
FROM logs-endpoint.events.file-*
| WHERE file.hash.sha256 == "abc123..."
| STATS occurrences = COUNT(*) BY host.name, file.path, user.name
Step 4: Classification Decision (2 minutes)
| Classification | Criteria | Action |
|---|---|---|
| True Positive | Confirmed malicious activity | Escalate to incident, begin containment |
| Benign True Positive | Expected behavior matching rule | Document in alert notes, acknowledge |
| False Positive | Rule triggered on benign activity | Mark as false positive, create tuning task |
| Needs Investigation | Insufficient data for determination | Assign for deeper investigation |
Step 5: Documentation and Escalation (1 minute)
For each triaged alert, document:
- Classification decision with rationale
- Evidence artifacts examined
- Related alerts or investigations
- Recommended next steps
Detection Rules for Triage
Pre-Built Detection Rules
Elastic Security includes 1000+ pre-built detection rules organized by:
- MITRE ATT&CK Tactic: Initial Access, Execution, Persistence, etc.
- Platform: Windows, Linux, macOS, Cloud
- Data Source: Endpoint, Network, Cloud, Identity
Custom Alert Correlation Rule
{
"name": "Multiple Failed Logins Followed by Success",
"type": "threshold",
"query": "event.category:authentication AND event.outcome:failure",
"threshold": {
"field": ["source.ip", "user.name"],
"value": 5,
"cardinality": [
{
"field": "user.name",
"value": 3
}
]
},
"severity": "high",
"risk_score": 73,
"threat": [
{
"framework": "MITRE ATT&CK",
"tactic": {
"id": "TA0006",
"name": "Credential Access"
},
"technique": [
{
"id": "T1110",
"name": "Brute Force"
}
]
}
]
}
AI-Assisted Triage
Elastic AI Assistant Integration
- Open alert in Elastic Security
- Click AI Assistant panel
- Use quick prompts:
- "Summarize this alert" - Get initial assessment
- "Generate ES|QL query to find related activity" - Expand investigation
- "What are the recommended response actions?" - Get playbook guidance
- "Is this likely a false positive?" - Get AI confidence assessment
Attack Discovery
Elastic's Attack Discovery automatically:
- Groups related alerts into attack chains
- Maps alerts to MITRE ATT&CK kill chain stages
- Filters false positives using ML models
- Prioritizes based on business impact
- Provides narrative summary of the attack
Triage Prioritization Matrix
| Risk Score | Severity | Asset Criticality | Response SLA |
|---|---|---|---|
| 90-100 | Critical | High | 15 minutes |
| 70-89 | High | High | 30 minutes |
| 70-89 | High | Medium | 1 hour |
| 50-69 | Medium | Any | 4 hours |
| 21-49 | Low | Any | 8 hours |
| 1-20 | Informational | Any | 24 hours |
Triage Metrics and KPIs
| Metric | Target | Measurement |
|---|---|---|
| Mean Time to Triage (MTTT) | < 10 minutes | Time from alert creation to classification |
| False Positive Rate | < 30% | False positives / total alerts |
| Escalation Rate | 10-20% | Escalated alerts / total alerts |
| Alert Coverage | > 80% | Triaged alerts / generated alerts per shift |
| Reclassification Rate | < 5% | Changed classifications / total classified |
References
04 同仓库更多 Skills
verifying-build-provenance-with-slsa-sigstore
Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI/CD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.
validating-tpm-measured-boot-attestation
Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote/tpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware/kernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.
validating-backup-integrity-for-recovery
Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable/air-gapped backups for silent corruption or tampering.
triaging-windows-with-kape
Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment/triage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.
triaging-vulnerabilities-with-ssvc-framework
Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track/Track*/Attend/Act decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.
triaging-security-incident
Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM/EDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.