--- name: "Alert Severity Normalization" description: > A common Critical/High/Medium/Low normalized severity model for security alerts, incidents, and findings, with the judgment axes (confidence, mitigation state, blast radius) that place a record in a tier and the mapping from each vendor's native terminology — Huntress incident status, SentinelOne threat confidence, Blumira finding priority, CIPP alert queue severity, Blackpoint Cyber SOC severity, SaaS Alerts risk level — plus how to discover which security vendors are actually connected. when_to_use: >- When normalizing, comparing, or ranking security alerts, incidents, or findings across more than one connected security vendor. Use when: alert severity, normalize severity, severity mapping, which alert is worse, portfolio severity ranking, cross-vendor severity, triage priority, severity scale, compare incidents across tools, rank alerts by urgency. --- # Alert Severity Normalization ## Overview Every EDR/MDR/SIEM vendor scores urgency differently, and the scales are not interchangeable. A Huntress "incident" carries no numeric severity at all — urgency is implied by incident type and remediation status. A SentinelOne threat carries an analyst/engine confidence level plus a mitigation state. Blumira ships findings with a priority field that already resembles a normalized scale. CIPP's alert queue mirrors whatever severity Microsoft's own signals assigned. None of these numbers or labels mean the same thing, and none of them are directly comparable — a Huntress "Critical" incident report is not necessarily worse than a SentinelOne threat with high confidence and no mitigation. This skill exists so that a sweep across a client's stack — or across an entire portfolio — produces one ranked list instead of five vendor-shaped lists that can't be stacked against each other. The normalization is a judgment mapping, not a lookup table: read the vendor's own signal (status, confidence, mitigation state, classification) and place it into the normalized tier using the criteria below, not by naively copying the vendor's label across. ## Anti-triggers - **One vendor's queue on its own** — triaging, filtering, or dispositioning inside a single tool is that connector's surface; use `huntress-incidents`, `sentinelone-alerts`, `blumira-findings`, `cipp-alerts`, `saas-alerts-triage`, or `blackpoint-incident-response`. This skill only earns its tokens when two or more of them have to be ranked against each other. - **Pulling non-security context around an alert** — ticket, device, and asset correlation is `shared-skills-incident-correlation`. ## Step Zero: Discover What's Actually Connected Never assume a vendor is connected. Before running any severity sweep, call `conduit__search_tools` to discover which security vendors are actually wired up for the org in question. A portfolio-wide sweep will typically see a different vendor mix per client — one tenant may only have Huntress, the next may run SentinelOne and CIPP side by side, and a third may have no EDR connected at all beyond CIPP's M365 alert queue. Build the vendor list from what `conduit__search_tools` returns, not from the vendor list in this document — this document exists to teach the mapping, not to enumerate every tool that will ever be connected. Once a vendor's tools are confirmed connected, use its own list/search tool (for example `huntress__list_incidents`, `cipp__list_users` for the identity side of a finding, or `sentinelone__list_threats`) to pull the native records; the exact tool name for any given vendor is whatever `conduit__search_tools` reports for it — don't guess. ## The Normalized Model | Tier | Definition | Response expectation | |------|------------|----------------------| | **Critical** | Active, unmitigated compromise: confirmed malicious execution, ransomware behavior, confirmed account takeover with session activity, or data exfiltration in progress. Nothing is automatically contained. | Immediate action, regardless of business hours. Page/escalate now. | | **High** | Confirmed malicious or highly suspicious activity that is contained or auto-mitigated, OR unmitigated activity with lower confirmed blast radius (single low-privilege endpoint, single mailbox rule). Not actively spreading, but not resolved. | Same-business-day human validation and closure. | | **Medium** | Suspicious activity, a policy violation, or a finding that raises risk with no evidence of exploitation (e.g., a risky sign-in that was blocked, a suspicious-but-quarantined attachment, a config drift finding). | Review within normal SLA (commonly next business day). | | **Low** | Informational, hygiene, or low-confidence findings — noise reduction candidates, benign anomalies, or advisory-only items. | Batched for periodic review; not individually tracked. | Two judgment calls apply at every tier boundary: - **Confidence vs. impact are separate axes.** A high-confidence detection of a low-impact event (e.g., a confirmed but immediately blocked phishing click with no follow-on activity) does not automatically outrank a lower-confidence detection of a high-impact event (e.g., a "suspicious" process spawning from an unmanaged scheduled task on a domain controller). When they conflict, weight impact and blast radius over confidence, and say so explicitly in the ranking rationale. - **Mitigation state moves the tier, not the classification.** A malicious threat that a vendor auto-killed and auto-quarantined is still a malicious threat — it should not be silently dropped to Low just because it was handled. It typically lands at High rather than Critical: real malice, contained blast radius. ## Vendor Mapping Reference | Vendor | Native terminology | How to map it | |--------|--------------------|----------------| | **Huntress** | No numeric severity — incidents carry a *status* (New / In Progress / Closed) and an incident *type*. Ransomware Canary trips and confirmed footholds are inherently severe regardless of status. | Confirmed foothold / ransomware canary / active incident, status New or In Progress → **Critical**. Confirmed foothold already remediated by Huntress or the SOC → **High**. Suspicious-but-unconfirmed detections still open → **Medium**. Closed/resolved with no confirmed compromise → **Low**. | | **SentinelOne** | Threat *confidence* (Malicious / Suspicious / N/A) plus a *mitigation status* (mitigated / not mitigated) and analyst verdict. | Malicious + not mitigated → **Critical**. Malicious + mitigated, or Suspicious + not mitigated on a sensitive asset → **High**. Suspicious + mitigated → **Medium**. Benign/resolved or false-positive verdict → **Low**. | | **Blumira** | Finding *priority* (already Critical/High/Medium/Low-shaped, sometimes with an "Informational" tier). | Near 1:1 — pass the native priority through. Collapse "Informational" into **Low**. Re-check Critical/High findings for whether they were auto-suppressed by a detection rule tune; a suppressed finding that fired anyway deserves a second look before trusting the native label. | | **CIPP alert queue** | Mirrors Microsoft's own signal severity for the tenant (risky sign-ins, mailbox rule changes, admin role changes, standards drift, BEC indicators). | Confirmed risky sign-in with subsequent mailbox/inbox rule change, or a BEC indicator from `cipp__bec_check`-style checks → **Critical**. Risky sign-in blocked/challenged by Conditional Access, or a new inbox forwarding rule to an external domain → **High**. Standards/config drift with no activity evidence → **Medium**. Informational audit-log entries → **Low**. | | **Blackpoint Cyber** | SOC-assigned incident severity, typically already tiered by their analysts (their own P1–P4 or Critical/High/Medium/Low convention varies by portfolio configuration). | Treat a Blackpoint SOC escalation as **Critical** or **High** by default — their model already filters for analyst-reviewed, actionable events; do not downgrade an escalated incident without evidence. Anything still labeled advisory/informational by their console → **Low**/**Medium** per their own label. | | **SaaS Alerts** | Per-event *risk level* tied to the specific SaaS activity (impossible travel, mass file download, new admin, forwarding rule, third-party app grant). | Impossible travel + mass download/exfil-shaped activity, or a high-risk OAuth grant → **Critical**. New admin role grant or a forwarding rule to an external domain → **High**. Single anomalous sign-in with no follow-on activity → **Medium**. Routine policy-hygiene notices → **Low**. | | **RocketCyber / other SOC-managed feeds** | SOC-reviewed event clusters, generally pre-filtered for actionability. | Default to **High** for anything the SOC surfaced as an incident (it already passed a human filter); reserve **Critical** for confirmed active compromise language in the SOC's own writeup. | When a vendor shows up that isn't in this table, don't block on it — apply the same judgment axes (confidence, mitigation state, blast radius) using whatever severity/status fields `conduit__search_tools` surfaces for it, and note in the output that the mapping is best-effort for an unlisted vendor. ## Worked Example A portfolio sweep returns: a Huntress incident (status: New, type: foothold), a SentinelOne threat (confidence: Suspicious, mitigated: true), and a CIPP alert queue entry (a new external forwarding rule on an executive mailbox). Normalized: the Huntress foothold is **Critical** (unmitigated, confirmed foothold), the CIPP forwarding rule is **High** (classic BEC precursor, not yet confirmed as active exfiltration), and the SentinelOne threat is **Medium** (suspicious confidence, already mitigated). The portfolio-wide ranking leads with the Huntress incident even though it may be the numerically "smallest" record returned by its API — normalization, not vendor ordering, drives the ranking. ## Related Skills - [Containment Playbooks](../containment-playbooks/SKILL.md) — what to do once an item is ranked Critical or High. - [BEC Response](../bec-response/SKILL.md) — the specific sequence for business email compromise, one of the most common Critical/High findings this normalization surfaces.