The risk screen, and what a risk score is made of

If you came here because Risk incidents is empty while your logs are clearly arriving, or because you cannot work out why a detection you know fired did not produce an alert — both are expected, and this page is the reason for both. It is the one screen in the detection module that is deliberately not a list of everything that happened.

Find it at Detection → Risk incidents (/siem/risk). The page describes itself in one sentence at the top, and it is worth reading slowly:

Why most detections do not raise an alert

The detection library ships around ninety rules, and most of them run in shadow mode — a rule that is switched on and evaluating your events, but that raises no alert of its own. Instead of an alert, a shadow rule leaves behind a signal: a small scored note saying this rule matched, against this person or this machine, at this time, worth this many points.

Nothing is shown to you for a single signal. That is the whole design. Any one of those rules on its own produces mostly noise — a failed sign-in, a script run from a temporary folder, an unusual country — and a queue of them is not a queue anybody works. It is a queue people learn to ignore, which is worse than not having it.

So the ordering here is by score, not by time. Every other list in the product is newest-first. This one is worst-first, and if you only look at one detection screen, look at this one.

Four words you need before the rest makes sense

Entity

The thing risk accumulates against: a user, a host, or a source address. Not an event, not a rule — a who or a what. Every signal is tagged with one, and the whole mechanism is arithmetic on that tag.

Signal

One rule matching once, against one entity, worth a number of points. Signals are not shown to you individually and there is no screen listing them; you see them only inside an incident that they built.

ATT&CK tactic

A stage of an attack, from a public catalogue maintained by MITRE — for example credential access, lateral movement, exfiltration. It answers "what was the attacker trying to achieve at this point", as opposed to "what tool did they use". The screen shows them under the column headed ATT&CK.

Trigger

The reason an incident opened. There are exactly two, and the column tells you which: Score threshold or Multi-stage chain.

The two ways an incident opens

Risk is accumulated per entity over a rolling window, and an incident opens the moment either of two conditions is met. Both are checked on every new signal.

The second trigger is the interesting one, and it is why the longer window exists: real intrusions unfold over days, not hours, and the individually unremarkable steps are the point. Three mild things in three different stages of an attack, seen by two different log sources, is a stronger signal than one loud thing seen once — and the loud thing is the one an alert list would have shown you.

Where the numbers come from

Each rule contributes points based on its severity, unless the rule sets its own figure:

One critical detection therefore opens an incident on its own, since 100 is already past the threshold of 75. That is intended: a single confirmed-bad match should not have to wait for company.

Two numbers appear in the Score column, and confusing them is easy. The bold one is a normalised score capped at 100, which is what you compare between incidents. If a raw figure is shown in brackets beside it, the true accumulated score is higher than 100 — an entity sitting at a raw 400 is in a materially different situation from one at 80, and squashing both to "100" would hide that.

Severity is derived rather than set. An incident is critical if its score reaches 120, or if it spans four or more distinct tactics; otherwise it is high. There are no medium or low risk incidents — by construction, something that would have been low never crossed the bar to become an incident at all.

Reading the page

Five counters run across the top. Four of them are self-explanatory; the fifth is the one worth understanding.

The list itself defaults to Needs work, which is open, acknowledged and investigating incidents. Switch to All to include resolved, false-positive and dismissed ones. There is no free-text search and no sort control — the list is already in the order it wants you to work it.

Click an incident's title to expand it. That fetches the contributing signals on demand, and shows one row per signal: when, which detection matched, what it contributed, the ATT&CK tactics and techniques involved, and which log source it came from. Under the summary you may see a line reading Detection content by … — that is a licence condition on the detection rules we use, not a footnote we chose to add, and it has to appear wherever a match is displayed.

An incident lists at most 150 signals. Past that the count is still correct and the score is still computed from everything, but the listing is trimmed — keeping the highest-scoring signals rather than the most recent ones, because somebody opening a capped incident needs the worst things in it, not the newest. Nothing has been discarded from the arithmetic.

Entity risk, and why it matters more than it looks

Below the incidents is a second table headed Entity risk, showing the twenty highest-scoring entities with their signal count, how many distinct detections touched them, how many tactics, and when they were last seen. Its own subtitle carries the warning:

Read that table when you are asking is anything building? rather than what needs doing now?. An account sitting at 60 with four distinct detections against it has no incident and will not appear in any queue, and is exactly the thing you would want to have noticed the week before. There is nothing to click on those rows — the table is information, not work.

The three buttons, and what each one means

Row actions change depending on where the incident is. There are three, and none of them asks you to confirm or lets you type a note — a press takes effect immediately.

1. 1

   Acknowledge

   Offered only while an incident is still open. It means somebody has seen this, nothing more. The toast reads Incident acknowledged. Use it to stop a colleague picking up the same thing; it does not close anything and does not affect the score.

2. 2

   Resolve

   Means this was real and it has been dealt with. The toast reads Incident resolved. Reach for this after you have actually done something about the entity — the incident is a unit of work, and resolving it is you saying the work is finished.

3. 3

   False positive

   Means this was not real. The toast reads Marked as a false positive. Use it honestly rather than as a tidier version of Resolve, because the distinction is the only signal we get about whether the rules behind it are worth what they cost you.

Once an incident is resolved, dismissed or marked a false positive, the actions are replaced by a plain label showing its state. There is no reopen button. If you close something by mistake, the practical remedy is to wait for the next incident on that entity, which the accumulating signals will produce.

What this screen does not do yet

Worth saying plainly, because each of these is a thing a reasonable person expects to find:

• The thresholds are not editable in the console. The score threshold, the windows, the tactic and source floors, the signal cap and the critical score are all tenant settings with a working API, and there is no screen for any of them. Ask us if the defaults do not suit your environment and we will change them for you.
• Nor are per-entity weightings. The scoring supports saying "the finance director's laptop matters more than the meeting-room PC" as an addition or a multiplier on that entity. It is not exposed anywhere in the interface.
• You cannot assign an incident to a person. An assignee is carried on the record but there is no control that sets it, so Acknowledge is the only way to signal that somebody has it.
• There is no note, comment or close reason. A reason field exists on the record; nothing writes to it from this screen. Whatever you concluded lives in your head or in your ticketing system, not here.
• No response action starts from here. There is no button on a risk incident that contains a host, kills a process or opens a ticket. What a person can and cannot start is set out in Response actions, and the honest answer is: less than you would expect.
• The list is capped at 100 incidents and 20 entities, with no paging. In practice this is not a limit you should reach; if you do, something is badly misconfigured and we would like to hear about it.

What to do next

1. Work Multi-stage first, then Critical, then the rest by score. A chain across three tactics is a worse sign than a single loud detection, even when the number beside it is smaller.
2. Expand the incident and read the signal list before you touch the entity. The story is in the sequence, and no single row carries it. What to do when an alert arrives is the procedure to follow from there.
3. Deal with the entity, not the incident. The buttons on this page change a status; they do not change anything on a laptop or an account.
4. Close it — Resolve if it was real, False positive if it was not — then go and fix the rule, with Tuning a detection rule. An untuned false positive comes back.
5. Glance at Entity risk once a week. It is the only place that shows you what is accumulating below the line.