/alert-severity-normalization

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*. Rans