Alert Severity Normalization

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

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

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 — what to do once an item is ranked Critical or High.
• BEC Response — the specific sequence for business email compromise, one of the most common Critical/High findings this normalization surfaces.