Security Alert Triage
Classify Elastic security alerts as benign, unknown, or malicious using evidence-first criteria so solo operators do not drown in false positives.
Overview
security-alert-triage is an agent skill most often used in Operate (also Ship, Grow) that classifies security alerts using Elastic’s evidence-first benign, unknown, and malicious criteria.
Install
npx skills add https://github.com/elastic/agent-skills --skill security-alert-triageWhat is this skill?
- Evidence-first principle: most alerts are false positives; default to unknown when evidence is thin
- Pre-classification checklist spanning related alerts, rule frequency, process tree, network, persistence, and signing
- Explicit Benign (score 0–19), Unknown, and Malicious tracks with behavioral weight guidance
- Common false positive sources and sandbox or test environment context called out
- Classify as unknown rather than wrong malicious or benign labels that waste IR or miss threats
- Benign classification score band 0–19 documented in guide
- Pre-classification checklist with 9 evidence areas before any classification
Adoption & trust: 1k installs on skills.sh; 502 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Elastic stack floods you with detections and you lack a repeatable way to separate false positives from real incidents without mislabeling threats.
Who is it for?
Solo operators or micro-teams running Elastic detections who need structured alert triage inside their agent-assisted workflow.
Skip if: Builders with no Elastic telemetry, no endpoint or SIEM data, or who only need generic OWASP app scanning without alert queues.
When should I use this skill?
When Elastic or endpoint security alerts need structured classification and you must gather process, network, and environmental evidence first.
What do I get? / Deliverables
You produce a defensible benign, unknown, or malicious classification backed by checklist evidence and behavioral weighting instead of guesswork.
- Alert classification as benign, unknown, or malicious with cited evidence
- Triage notes aligned to checklist gaps when classified unknown
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Operate monitoring is the canonical home for alert triage you run against live detections, though the same discipline applies when hardening before launch. Monitoring subphase reflects continuous alert classification, correlation, and escalation—not one-off code generation.
Where it fits
A new PowerShell rule fires overnight and you walk the agent through the checklist before paging anyone.
Repeated benign-classified alerts suggest a mis-tuned rule; you document unknown vs benign rationale for suppression tuning.
Before enabling a custom detection in production, you dry-run sample events through the classification guide.
User growth expands endpoints and alert volume; you standardize unknown-default triage for contractors assisting part-time.
How it compares
A procedural triage methodology for SIEM alerts, not a vulnerability scanner or generic code review skill.
Common Questions / FAQ
Who is security-alert-triage for?
Indie SaaS operators and small security-minded teams using Elastic alerts who want the agent to follow formal classification steps instead of improvised threat narratives.
When should I use security-alert-triage?
Use it in Operate when alerts fire in monitoring, in Ship when validating new detection rules before go-live, and in Grow when scaling infrastructure increases alert volume.
Is security-alert-triage safe to install?
Use the Security Audits panel on this Prism page and restrict agent access to production Elastic credentials; triage assumes querying sensitive security data.
SKILL.md
READMESKILL.md - Security Alert Triage
# Alert Classification Guide Detailed criteria for classifying alerts as benign, unknown, or malicious. ## Contents - Fundamental principle - Pre-classification checklist - Classification: Benign - Classification: Unknown - Classification: Malicious - Behavioral weight table - Common false positive sources - Sandbox and testing environments ## Fundamental principle Most alerts are false positives. Your job is to find EVIDENCE, not to confirm suspicions. When in doubt, classify as "unknown" -- this is better than a wrong malicious classification that wastes IR resources, or a wrong benign classification that misses a threat. ## Pre-classification checklist Before making ANY classification, confirm you have: - [ ] Searched for related alerts on the same agent/user - [ ] Checked rule frequency across the environment - [ ] Investigated process tree and parent-child relationships - [ ] Reviewed network activity (DNS, connections, lateral movement) - [ ] Checked for persistence mechanisms (registry, scheduled tasks, services) - [ ] Looked for defense evasion behaviors - [ ] Verified code signing status of executables involved - [ ] Identified environment context (production vs sandbox/test) - [ ] Considered if this matches a known false positive pattern If you cannot check most of the above, either gather more context or classify as "unknown." ## Classification: Benign (score 0-19) Confirmed false positive or legitimate activity. **Use when you have positive evidence of legitimacy:** - Recognized enterprise software performing expected functions - Known IT management/deployment activity (SCCM, Group Policy, Intune) - Security testing with clear test environment indicators - User-initiated installation of legitimate software - Rule known to have high FP rate for this specific scenario - No malicious behaviors observed (no persistence, no C2, no credential theft) **Examples:** - SCCM pushing software update via PowerShell - User installing Discord (large Electron app) from official source - Atomic Red Team test in designated testing environment - IT admin using PSExec for legitimate remote management ## Classification: Unknown (score 20-60) Insufficient information to determine. Needs further investigation. **Use when:** - Suspicious indicators BUT lack corroborating evidence of malicious INTENT - Activity COULD be malicious OR legitimate, and you can't tell which - Need more context that isn't available in the current data - First time seeing this pattern with no baseline **Examples:** - Unsigned installer running from Temp folder, but no C2/persistence observed - PowerShell script with obfuscation, but no malicious payload identified - Process injection APIs used, but target is a child process it spawned itself - Large binary with WriteProcessMemory, but appears to be Electron/Node.js app ## Classification: Malicious (score 61-100) Confirmed or highly suspected malicious activity. **Requires at least ONE high-confidence indicator:** - Confirmed C2 communication (beaconing to known bad IP/domain) - Persistence mechanisms established (registry Run keys, scheduled tasks, services) - Credential theft (LSASS access, credential file access, keylogging) - Lateral movement (RDP/SMB/WinRM to other internal hosts) - Active defense evasion (disabling AV, clearing logs, timestomping) - Known malware hash match - Data exfiltration observed **NOT sufficient alone (these require corroboration):** - Unsigned binary (many legitimate apps are unsigned) - Large file size (Electron apps are routinely 100MB+) - Running from Temp folder (installers commonly do this) - WriteProcessMemory API (used by legitimate apps for child process creation) - VirtualAlloc RWX (used by JIT compilers in .NET, Java, Node.js) - Alert severity is "critical" (severity is rule author's opinion, not evidence) - Rule name contains "Malicious" (rule names are often sensationalized) ## Behavioral weight table ### Strong indicators (can support MALICIO