Severity and Confidence

Every alert MetaDefender NDR produces carries two numbers: a severity label drawn from a unified four-level scale, and a confidence score expressed as a floating-point value between 0.40 and 0.99. Together, the two define how urgent the alert is (severity) and how much trust the detection places in its own finding (confidence). Analysts use severity to pick what to look at next and confidence to order work within a severity band; every detection family in the platform — Suricata signatures, command-and-control (C2) intelligence, OPSWAT InSights threat intelligence, MetaDefender Core file scanning, behavioral analytics, and machine-learning (ML) anomaly detection — converges on the same vocabulary so operators never translate between schemes when pivoting across detection types.

This chapter defines the scales, documents the single rule that can override them (indicator-of-compromise (IOC) auto-escalation), explains how severity influences the user interface (UI), and states the platform's stance on service-level agreements (SLAs). Acronyms expanded in this chapter: IOC (Indicator of Compromise), SLA (service-level agreement), C2 (command-and-control), UI (user interface), ML (machine learning), RCF (Random Cut Forest), AV (antivirus), TIDB (Threat Intelligence Database), REPDB (Reputation Database), IDS (intrusion detection system).

The Unified Severity Scale

MetaDefender NDR classifies every alert into one of four severity levels. The level is set by the alert engine at the moment the rule fires, on the basis of the detection's native trigger conditions.

The scale is absolute, not relative to the deployment. A Critical alert at a small single-sensor installation means the same thing as a Critical alert at a large multi-sensor fleet — the thresholds that produce each label are fixed in the detection pipeline and identical across every site.

Severity has no built-in decay. A Critical alert remains Critical until it is closed; the platform does not automatically demote it as time passes. Analysts manage state through the Hunt page and runbook workflows documented in Daily Operations.

The Confidence Score Range

Alongside severity, every alert carries a confidence score. Confidence is a floating-point number on the closed interval 0.40 to 0.99. It quantifies the detection engine's trust in its own finding — how likely it is that the alert represents real malicious or anomalous activity rather than noise.

No alert is emitted below 0.40 — the platform filters out signals that would not clear the minimum-confidence floor. The top of the band is 0.99, not 1.00, so that "perfect confidence" stays reserved for the IOC auto-escalation pathway described below.

Analysts use confidence to order work within a severity band. Among ten Medium alerts in the queue, the one at 0.78 confidence is triaged before the one at 0.42. Analysts never use confidence across severity bands — a Medium at 0.94 is still less urgent than a High at 0.40.

Suricata Native Severity

Suricata, the intrusion detection system (IDS) engine running inside every MetaDefender NDR sensor, assigns rules their own severity on a 1 to 4 scale set by the rule author. The convention is inverted relative to many other security tools: a lower number means a more severe rule.

The alert engine applies this mapping one-to-one whenever a Suricata signature fires. Analysts reading the raw alert.severity value on a Suricata alert row in the Hunt page sidebar (the Suricata Alert + Payload section) therefore see the native number, and the separate Severity column on the row shows the mapped unified label. The two should always agree for signature alerts; a mismatch points at a bad rule-severity mapping and should be reported.

The inversion trap is the most common source of confusion for analysts coming from other platforms where "severity 5" means critical. A Suricata rule set to severity 1 is not low — it is Critical. Anyone authoring or importing custom Suricata rules should mirror the Proofpoint Emerging Threats convention: reserve 1 for confirmed attack signatures, 2 for likely malicious activity, 3 for potentially unwanted activity, and 4 for informational or policy-only rules.

IOC Auto-Escalation Rule

A single, non-negotiable rule overrides the native severity and confidence whenever an IOC match is present on an event:

When any entity on an event matches the C2 feed or the InSights TIDB or REPDB feeds, the alert is raised to Critical severity and 0.99 confidence — regardless of the detection family's normal thresholds, and regardless of what the native evidence alone would have produced.

This rule applies to every detection family that can carry an IOC reference: behavioral detections whose destination is on the C2 feed, Suricata signature alerts whose source or destination matches InSights, MetaDefender Core alerts whose file was transferred to an IOC-listed endpoint, and ML anomaly alerts whose entity is on a watchlist. The implementation is internal to the alert engine, anchored on the enriched-event field insights.malicious_count > 0, and is not tunable by operators or administrators.

The rule exists because the evidence crosses into a different category once a known-bad indicator is involved: a beaconing pattern might be polling, but polling to a known command-and-control server is no longer ambiguous. The signal is too strong to demote.

Two practical consequences:

• Threshold-Critical vs IOC-Critical. Analysts reading a Critical alert need to know whether the Critical label came from the native threshold (for example, 50 or more beaconing connections) or from the IOC override (any count, but to an IOC-listed destination). The Hunt page sidebar makes the distinction visible: an IOC-Critical alert renders a C2 Enrichment or InSights Enrichment section that names the matched entity and the source feed. A threshold-Critical alert carries only the family-native metadata. Treat IOC-Critical alerts as the stronger of the two — native evidence plus a confirmed indicator is always worse than native evidence alone.
• A Low behavioral alert can become Critical. A Long Duration Flow of 3,700 seconds to a REPDB-listed domain would normally land as Medium (the pure-duration threshold tier), but the REPDB hit pushes it to Critical at 0.99 confidence. Similarly, 15 beaconing connections (the lowest tier) become Critical if the destination is on the C2 feed. Analysts should not dismiss IOC-escalated alerts on the grounds that the underlying behavioral evidence looks modest — the escalation is the signal.

How Severity Influences the UI

Severity is a first-class visual channel on every operator surface.

• Dashboard — Recent Severities donut. The donut chart segments recent alerts by Critical, High, Medium, Low, and Unknown. Operators use the donut as the fastest way to see the shape of the current alert stream: a sudden Critical spike is visually obvious.
• Dashboard — Recent Alerts widget. Each alert row shows its severity as a colored label. The color cue lets operators scan the widget for Criticals without reading the column explicitly.
• Hunt page — severity column. Every alert sub-tab exposes severity as a sortable, filterable first-class column. Analysts routinely sort the All Alerts tab by severity descending to work the highest-urgency items first.
• Hunt page — row urgency cues. Row-level visual treatment (color coding, icon weight) reflects severity so that a Critical row draws the eye even when the severity column is scrolled out of view or when the operator is scanning the table peripherally.
• Hunt page — detail sidebar. When an alert row is selected, the sidebar header carries the severity label and the confidence score together. Enrichment sections that triggered an IOC auto-escalation — C2 Enrichment, InSights Enrichment — render prominently in the sidebar so the reason for the Critical label is one scroll away.

MetaDefender NDR does not use severity as a dashboard-wide filter on MVP; the current Dashboard interval filter is historical interval only. Severity-based cross-widget filtering is on the Dashboard roadmap. Operators who need to narrow the global view by severity today do so on the Hunt page, which exposes the full filter grammar.

No SLA Mapping in This Guide

MetaDefender NDR deliberately does not publish response-time SLAs keyed to severity. The platform provides the triage signal — the label that says this alert is more urgent than that one — but the time-to-acknowledge, time-to-contain, and time-to-resolve targets remain the responsibility of the operating organization's incident-response policy.

The rationale is straightforward. The right SLA for a Critical alert depends on factors the platform cannot know: shift coverage model, analyst headcount, asset criticality at the alerting entity, regulatory exposure at the organization, downstream automation coupling, and whether the deployment is a Managed Security Service Provider (MSSP) multi-tenant environment or a direct enterprise Security Operations Center (SOC). A 15-minute time-to-acknowledge target that is reasonable for a direct-enterprise SOC on its crown-jewel subnet is unreasonable for an MSSP serving 200 customers with a tier-one team, and vice versa.

Operators who need to express SLAs inside their own documentation should layer them over the platform's severity scale — for example, Critical: 15-minute acknowledge / 1-hour contain / 4-hour resolve; High: 1-hour / 4-hour / next business day; Medium and Low: best-effort — and treat the severity label as the input to their SLA computation rather than expecting the platform to enforce deadlines. The alert engine does not escalate, reassign, or page on its own; all lifecycle management of an alert is analyst-driven on the Hunt Page and documented in Daily Operations.

For the end-to-end investigative workflow that starts from a Critical alert, see Critical Alert Triage. For the full catalog of detections and the severity range each produces before IOC auto-escalation.