How does Qevlar calculate severity?

Every alert and group Qevlar investigates gets a severity level, and every one that is not benign also gets a score from 0 to 100 (see Benign alerts). This article explains how that score is built, so you can read it, check it, and explain it to your own stakeholders.

In short: Qevlar's AI reads the investigation evidence and places the alert on a few clearly defined factors. A fixed formula then turns those factors into the score. The AI never picks the score or the level itself, so the same factors always give the same severity.

Severity levels

The score maps to one of five levels:

In a few specific situations, a guardrail moves the level outside the band of its score. See Guardrails below.

The factors

Severity looks at four factors, the same for alerts and groups. Each factor has a small number of tiers with a precise definition.

Threat: what could this threat do?

Threat is judged on what the evidence shows the threat is capable of, not on the detection name or the vendor's label. The same scale applies to endpoint, email, identity, network, DLP and cloud alerts.

When the evidence could support two tiers, Qevlar takes the higher one only if there is direct evidence for it.

A few cases that often surprise:

• Reconnaissance or discovery that only returns identifiers or metadata is Nuisance, blocked or not.
• Cracks and keygens with no bundled payload are Nuisance.
• A suspicious or impossible-travel sign-in is Access-capable while there is no evidence that an attacker controls the account. Once an attacker-controlled sign-in or token is established, it is Destructive.
• Routine operational actions, such as deleting or restarting pods, redeploying containers or restarting services, are not destructive.

Containment: how far did the threat get?

Containment describes the furthest stage the threat reached. The key rule: a threat nobody engaged with is not contained. If a phishing email sits unopened in an inbox, nothing stopped it; nobody clicked it yet.

For sign-in alerts: a sign-in stopped by a control is Blocked, a successful sign-in is Realized, and a sign-in that failed on wrong credentials with no control involved is Latent.

A few more rules:

• A control that fired after the threat succeeded counts as Blocked only if it fully reverses the access: sessions and tokens revoked, host isolated, payload removed. Otherwise the alert is Realized.
• A control on a different part of the attack chain does not contain the alerted activity.
• Traffic that a control only logged or allowed is not containment.
• When some recipients clicked a link that was blocked and others still have the email in their inbox, Qevlar takes the worst state that no control stopped: here, Latent.
• If the evidence does not say whether the threat was delivered, ran or got access, Containment is Not observed (see below), not Latent.

Reach: how many entities are affected?

Reach counts the distinct people or assets in your organization that the threat acted on or was delivered to: users, hosts and mailboxes. It does not count observables, IP addresses or alerts. A user and the device they were using count as one entity.

Blocked emails and failed sign-ins do not add to reach. Also:

• Several addresses or accounts of the same person count as one.
• For sharing, DLP, permission-change and insider alerts, reach is the acting account plus each named target.
• Infrastructure that only answered the attacker, such as domain controllers authenticating it or proxies, is not counted.
• A change scoped to the whole tenant, such as an admin consent, a tenant-wide policy or a federation change, is organization-wide.

Asset: how critical is what was hit?

Asset criticality looks at the most critical asset or user affected.

Qevlar uses explicit signals first, such as VIP tags, asset tags and privileged roles. When there are none, it infers the tier from the evidence (naming conventions such as DC or adm-, server vs workstation, group memberships, job title) and says so in the explanation.

How the score is calculated

Step 1: Threat and Reach set the base, up to 100 points. Threat carries 60% of the weight and Reach 40%.

Step 2: Containment and Asset scale the base.

Score = (Threat points + Reach points) × Containment × Asset

The result is rounded and capped at 100.

Reading the severity breakdown

Click the severity on an alert or a group to open its breakdown:

• The grid has 100 squares in five bands of 20, from Informational at the bottom to Critical at the top. The filled squares are the score.
• One row per factor shows its tier and the points it adds. The points always add up to the score.
• Click a factor to highlight its squares and read why it got that tier: one sentence citing the evidence that decided it.
• Initial severity, under the breakdown, is the level given by your tools, shown for comparison.

Guardrails

A few rules adjust the level (not the score) after scoring, so that obvious cases are never under- or over-rated. When a guardrail moves the level, the breakdown says: "A guardrail moved the level outside the band of its score."

1. Blocked threats are capped. If a control blocked the threat, the level is at most Medium, or at most High when 6 or more entities were targeted or a critical asset was involved.
2. Active attacks are at least High. If the attack is still active and the threat is at least access-capable, the level is at least High. Running adware does not trigger this.
3. Critical assets that were hit are at least High. If a critical asset is involved and the threat was realized or is still active, the level is at least High.
4. Active attacks on critical assets are Critical. If a critical asset is involved, the attack is still active and the threat is at least access-capable, the level is Critical.
5. A group is never less severe than its alerts. Its level is at least the highest level among its alerts. For an alert scored before this model existed, its previous severity level is used.

When a factor cannot be determined

Qevlar never guesses a tier. When the evidence does not establish a factor, the breakdown shows it as Not observed, and the formula uses a fixed, neutral value instead:

When two or more factors are not observed, the breakdown warns: "Some factors were not observed, so this score may be too low." Treat these alerts with extra care rather than trusting the level alone.

Benign alerts

Severity measures how serious a real threat is. When the investigation concludes an alert is benign, there is no threat to rate, so Qevlar does not score it: the alert is Informational by rule, and the breakdown shows the verdict Benign and Not scored, with no score and no factors.

The same applies to a group whose verdict is benign.

Only a benign verdict skips scoring. Malicious alerts are scored, and so are alerts whose investigation was suspicious or lacked data.

Groups of similar alerts

Groups are scored with the same factors and the same formula, looking at all their alerts together:

• Reach counts the distinct entities across all the alerts.
• Threat, Containment and Asset take the worst tier that at least one alert directly supports.
• The level is never lower than the most severe alert in it (guardrail 5).

Worked examples

Severity in the API

The Get investigation result endpoint (GET /v2/investigations/{alert_id}/result) returns the same severity as the platform, in a severity object at the root of the payload:

{
  "id": "00000000-0000-0000-0000-000000000001",
  "severity": {
    "score": 68,
    "level": "HIGH",
    "needs_data": false,
    "guardrails_applied": [],
    "parameters": {
      "threat": {
        "score": 39,
        "tier": 3,
        "explanation": "The IP is a known command-and-control server for active malware."
      },
      "containment": {
        "score": 19,
        "tier": 3,
        "explanation": "The connection succeeded and no block was recorded."
      },
      "reach": {
        "score": 10,
        "tier": 2,
        "explanation": "Three endpoints contacted the same IP."
      },
      "asset_criticality": {
        "score": 0,
        "tier": 1,
        "explanation": "Regular workstations; no server role or VIP tag found."
      }
    }
  },
  "investigation": {
    "report": {
      "qevlar_severity": "HIGH"
    }
  }
}

Tier numbers map to the tiers described above, from lowest to highest:

severity is null when the alert was not scored: a benign alert, or an alert investigated before this model existed. In both cases investigation.report.qevlar_severity still gives the level.

The same severity breakdown is also available for groups of similar alerts, through the Get alert group endpoint (GET /v2/alert-groups/{group_id}).

FAQ

Why does my alert show a level that does not match its score band?

A guardrail moved it. The breakdown tells you when this happens; see Guardrails.

Does the AI decide the severity?

The AI decides each factor's tier from the evidence, and explains each choice in one sentence. The score and the level are then pure arithmetic, so the same tiers always give the same severity.

How can I make asset criticality more accurate?

Tag your VIP users in Qevlar. Explicit signals always take precedence over what the AI infers from naming or roles.

Why is a delivered-but-unopened phishing email not rated as contained?

Because no control stopped it. It is still in the mailbox and could be opened at any time. It is rated Latent, which weighs less than Realized or Still active, but more than Blocked.