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 — 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.
1---2name: alert-severity-normalization3description: 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.4---56# Alert Severity Normalization78## Overview910Every EDR/MDR/SIEM vendor scores urgency differently, and the scales are not11interchangeable. A Huntress "incident" carries no numeric severity at all —12urgency is implied by incident type and remediation status. A SentinelOne13threat carries an analyst/engine confidence level plus a mitigation state.14Blumira ships findings with a priority field that already resembles a15normalized scale. CIPP's alert queue mirrors whatever severity Microsoft's16own signals assigned. None of these numbers or labels mean the same thing,17and none of them are directly comparable — a Huntress "Critical" incident18report is not necessarily worse than a SentinelOne threat with high19confidence and no mitigation.2021This skill exists so that a sweep across a client's stack — or across an22entire portfolio — produces one ranked list instead of five vendor-shaped23lists that can't be stacked against each other. The normalization is a24judgment mapping, not a lookup table: read the vendor's own signal (status,25confidence, mitigation state, classification) and place it into the26normalized tier using the criteria below, not by naively copying the27vendor's label across.2829## Anti-triggers3031- **One vendor's queue on its own** — triaging, filtering, or dispositioning32 inside a single tool is that connector's surface; use33 `huntress-incidents`, `sentinelone-alerts`, `blumira-findings`,34 `cipp-alerts`, `saas-alerts-triage`, or `blackpoint-incident-response`.35 This skill only earns its tokens when two or more of them have to be36 ranked against each other.37- **Pulling non-security context around an alert** — ticket, device, and38 asset correlation is `shared-skills-incident-correlation`.3940## Step Zero: Discover What's Actually Connected4142Never assume a vendor is connected. Before running any severity sweep, call43`conduit__search_tools` to discover which security vendors are actually44wired up for the org in question. A portfolio-wide sweep will typically see45a different vendor mix per client — one tenant may only have Huntress, the46next may run SentinelOne and CIPP side by side, and a third may have no EDR47connected at all beyond CIPP's M365 alert queue. Build the vendor list from48what `conduit__search_tools` returns, not from the vendor list in this49document — this document exists to teach the mapping, not to enumerate every50tool that will ever be connected. Once a vendor's tools are confirmed51connected, use its own list/search tool (for example `huntress__list_incidents`,52`cipp__list_users` for the identity side of a finding, or `sentinelone__list_threats`)53to pull the native records; the exact tool name for any given vendor is54whatever `conduit__search_tools` reports for it — don't guess.5556## The Normalized Model5758| Tier | Definition | Response expectation |59|------|------------|----------------------|60| **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. |61| **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. |62| **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). |63| **Low** | Informational, hygiene, or low-confidence findings — noise reduction candidates, benign anomalies, or advisory-only items. | Batched for periodic review; not individually tracked. |6465Two judgment calls apply at every tier boundary:6667- **Confidence vs. impact are separate axes.** A high-confidence detection of68 a low-impact event (e.g., a confirmed but immediately blocked phishing69 click with no follow-on activity) does not automatically outrank a70 lower-confidence detection of a high-impact event (e.g., a "suspicious"71 process spawning from an unmanaged scheduled task on a domain controller).72 When they conflict, weight impact and blast radius over confidence, and73 say so explicitly in the ranking rationale.74- **Mitigation state moves the tier, not the classification.** A malicious75 threat that a vendor auto-killed and auto-quarantined is still a76 malicious threat — it should not be silently dropped to Low just because77 it was handled. It typically lands at High rather than Critical: real78 malice, contained blast radius.7980## Vendor Mapping Reference8182| Vendor | Native terminology | How to map it |83|--------|--------------------|----------------|84| **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**. |85| **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**. |86| **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. |87| **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**. |88| **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. |89| **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**. |90| **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. |9192When a vendor shows up that isn't in this table, don't block on it — apply93the same judgment axes (confidence, mitigation state, blast radius) using94whatever severity/status fields `conduit__search_tools` surfaces for it, and95note in the output that the mapping is best-effort for an unlisted vendor.9697## Worked Example9899A portfolio sweep returns: a Huntress incident (status: New, type: foothold),100a SentinelOne threat (confidence: Suspicious, mitigated: true), and a CIPP101alert queue entry (a new external forwarding rule on an executive mailbox).102Normalized: the Huntress foothold is **Critical** (unmitigated, confirmed103foothold), the CIPP forwarding rule is **High** (classic BEC precursor, not104yet confirmed as active exfiltration), and the SentinelOne threat is105**Medium** (suspicious confidence, already mitigated). The portfolio-wide106ranking leads with the Huntress incident even though it may be the107numerically "smallest" record returned by its API — normalization, not108vendor ordering, drives the ranking.109110## Related Skills111112- [Containment Playbooks](../containment-playbooks/SKILL.md) — what to do113 once an item is ranked Critical or High.114- [BEC Response](../bec-response/SKILL.md) — the specific sequence for115 business email compromise, one of the most common Critical/High findings116 this normalization surfaces.
WYRE-AI