Skip to content

Entity risk score

LogMan.io uses two related risk score concepts:

Concept Where you see it Meaning
Detection risk score Complex events, alerts, Discover Score of one detection after correlation rules and lookups
Entity risk score Assets list and asset detail How risky this user, host, or service is right now, based on recent detections

Detection scoring is described in Risk scoring in Correlator. This page explains the entity risk score on assets.

Where to look in the UI

Place What you see What it tells you
Assets table Risk score column Compare principals at a glance; sort by risk
Asset detail sidebar Average risk score Current entity score after decay
Asset detail chart Risk score line Peak detection scores over time (not the same number as the sidebar)

SOC triage on Monday morning

Open Assets and sort by risk score descending. A workstation at 72 after several failed logins over the weekend stays near the top even if the last alert was hours ago. A server that had one 85 alert yesterday but nothing since may already show 40, because the score fades when activity stops.

One loud alert vs many quiet ones

User jsmith triggers one rule with detection risk 80. Their entity score moves toward 80. The next day, three minor detections at 20 each arrive: the entity score does not become 140. It blends toward the new values (roughly 40 if they arrived close together). Old noise does not stack without limit.

Sidebar vs chart

The sidebar Average risk score answers: "Should I worry about this principal now?"

The risk score chart answers: "When did detections spike?"

After a quiet week the sidebar may read 0 or be empty, while the chart still shows a spike from last Tuesday.

How the entity score is built

LogMan.io Assets processes correlation detections for each tenant. When a detection carries event.risk_score and identifies a host, user, or service, that value updates the entity score for that principal.

The score is a time decayed average of recent detection values:

  • New detections pull the score up (or down if the new value is lower).
  • Time without detections pulls the score down (default half life 24 hours).
  • Many weak alerts do not add up forever the way a raw sum would.

Example (simplified): The entity score was 80 from one alert. A new detection with risk 20 arrives immediately: the blended score becomes about 50, not 100. After 24 hours with no further detections, the score halves again toward 25, then new activity can move it again.

Why an average, not a sum?

Ten low priority alerts spread across a week should not push a user to the same level as ten critical incidents. The entity score reflects recent relevance, similar to UEBA products where stale risk fades instead of living forever in a running total.

Optional risk score weight

On the asset detail page you can set Risk score weight (0 to 100). Use this when your deployment tunes how strongly future detections involving that principal should score (for example a domain controller or a known service account).

This override is separate from Average risk score in the sidebar, which still comes from real detections on that asset.

You need permission to edit lookups. Use Clear weight to remove the override.

Score over time

  • Detections use the event time on the complex event (typically @timestamp).
  • Opening the asset list or detail shows the score as it is now, including decay since the last detection.
  • The service also refreshes stored scores periodically in the background so sorting in the asset list stays aligned with the model.
  • Very low scores (below 0.5 by default) disappear from the UI.

If a detection arrives late (event time older than the last update), its value still contributes to the average, but decay does not move backward in time.

Configuration (administrators)

[assets] key Default Description
risk_score_decay_half_life 24h How fast the score fades without new detections
risk_score_decay_clear_below 0.5 Hide and clear scores below this value
complex_mongo_batch_max 100 Buffered detections before persist
complex_mongo_batch_max_age 60 Max seconds before partial buffer flush

See Configuration for service setup and dependencies.