Hodnocení rizika v LogMan.io Correlator¶

LogMan.io Correlator přiřazuje číselné hodnocení rizika každému výstupu detekce (complex události, signály, alerty). Analytici ho používají k řazení front, ladění pravidel a k entitnímu riziku na aktivech.

Skóre jsou hodnoty s plovoucí desetinnou čárkou, typicky na škále 0 až 100. Orientačně: 20 je nízké, 50 střední, 80 vysoké. Hodnoty mohou přesáhnout 100, když se sečte více bonusů.

Hodnocení rizika vs. severity¶

Severity popisuje potenciální dopad, pokud by nález byl pravdivý (low, medium, high, critical). Je to stabilní štítek scénáře.

Hodnocení rizika je číslo, které se mění v okamžiku výstupu: základ pravidla, předchozí skóre na spouštěcí události, lookupy a shody IOC se sčítají. Odpovídá na otázku „Jak silně máme na tuto detekci reagovat právě teď?“

Co se stane při spuštění detekce¶

Když korelační pravidlo spustí trigger (complex událost nebo signál), Correlator vypočítá event.risk_score ve čtyřech krokách, pokud šablona triggeru pole explicitně nenastaví:

Krok	Zdroj	Efekt
1. Základ	`define.risk_score` nebo `define.severity` pravidla a volitelně existující `event.risk_score` na spouštěcí události	Počáteční hodnota nebo eskalace existujícího skóre (viz níže)
2. Ladění pravidla	lookup `ruleid2riskscore`	Přičte se k základu
3. IOC / threat intel	Lookupy ve skupině `ioc` (a lookupy v `define.lookups`, které odpovídají dimenzím okna)	Přičte se za každou odpovídající hodnotu dimenze
4. Váha aktiva	`hostid2riskscore`, `userid2riskscore`, `serviceid2riskscore`	Přičte se, když událost nese odpovídající id principálu

Výsledek se zapíše do výstupu detekce (výchozí ECS pole event.risk_score). Tuto hodnotu vidíte v Discover, v alertech a jako skóre entity v Assets (viz Entitní hodnocení rizika na aktivech).

Pohled analytika

Vzorec v UI nekonfigurujete. Výsledek ovlivníte:

risk_score nebo severity v YAML pravidla
řádky v Lookups (ruleid2riskscore, ioc, …)
Risk score weight na aktivu v Assets (naplní userid2riskscore a sourozence)

Základní skóre z pravidla¶

Základ pravidla nastavte v define:

define:
  name: "Failed login burst"
  risk_score: 40.0

Pokud vynecháte risk_score, můžete použít kategorickou severity. Převede se na číslo, např. low → 30, medium → 50, high → 70, critical → 90.

Pokud spouštěcí událost nemá předchozí hodnocení rizika, základ je prostě hodnota pravidla.

Když spouštěcí událost už má hodnocení rizika¶

Parsované nebo upstream události někdy už nesou event.risk_score (např. předchozí detekce na complex lane). Následné pravidlo toto číslo nenahrazuje. Eskaluje ho směrem k 100 pomocí vlastního risk_score pravidla (nebo mapované severity):

new_base = existing + (100 - existing) × (rule_risk / 100)

Pravidlo funguje jako procento zbývajícího prostoru do 100. Vysoká existující skóre se hýbou méně; nízká mohou vyskočit více.

Příklad eskalace

Host už má event.risk_score: 40 z dřívější detekce. Druhé pravidlo spustí s define.risk_score: 30.

40 + (100 - 40) × (30 / 100) = 40 + 18 = 58

Druhé pravidlo skóre zvýšilo o 18 bodů, nepřičetlo 30 k 40.

Silná eskalace

Stejný start 40, ale druhé pravidlo má risk_score: 80:

40 + 60 × 0.8 = 88

Vysoký základ pravidla u řetězené detekce může výstup posunout téměř na vrchol škály v jednom kroku.

Pokud pravidlo v define nemá ani risk_score ani severity, jako základ zůstane skóre události (lookupy v krokách 2 až 4 se stále uplatní).

Ladění pravidla (`ruleid2riskscore`)¶

Úpravy pro jednotlivá pravidla přidejte do lookupu ruleid2riskscore. Klíč je id pravidla (cesta v Knihovně k YAML souboru). Sloupec score se přičte po základu.

key                                                              score
/Correlations/Windows/Failed login burst.yaml                    10.0

Ladění hlučných pravidel

Užitečné pravidlo, které často spouští, může držet define.risk_score: 50 pro férovou severity, ale ruleid2riskscore: -15 (nebo nižší kladnou hodnotu), aby analytici nebyli zahlceni prioritou top alertů, dokud IOC nebo váha aktiva nezvedne celkové skóre.

IOC a threat intelligence¶

Lookupy ve skupině ioc (a kompatibilní lookupy v define.lookups) se kontrolují proti dimenzím okna na události (např. source.ip, user.name, dns.question.name). Každá shoda přičte své risk.score (výchozí 10, pokud řádek skóre nemá).

Aby lookupy zůstaly naplněné z externích zdrojů, viz Threat intelligence feedy.

key                         risk.score
203.0.113.66                25.0
evil.example.com            20.0

IOC na dimenzi

Pravidlo neúspěšného VPN přihlášení má po eskalaci základ 45. Zdrojová IP odpovídá řádku IOC s 25. Výstup je 70 před váhou aktiva. Analytik vidí střední pravidlo jako vysokou prioritu, protože IP je známě špatná.

Váha hodnocení rizika na aktivu¶

V Assets → detail aktiva můžete nastavit Risk score weight (0 až 100) pro host, uživatele nebo službu. Hodnota je v hostid2riskscore, userid2riskscore nebo serviceid2riskscore. Když výstup detekce obsahuje id tohoto principálu, váha se přičte k finálnímu skóre.

VIP servisní účet

Základ pravidla 35, bez IOC. Uživatel svc-backup má v Assets váhu 30. Finální event.risk_score: 65. Stejné pravidlo u obecného uživatele zůstane na 35.

Eskalace plus váha aktiva

Window pravidlo má define.risk_score: 20. Dvě události v okně nesou event.risk_score: 10. Odpovídající host má v Assets váhu 10.

Do vzorce vstoupí skóre pouze spouštěcí události (dvě desítky se nesčítají):

base = 10 + (100 − 10) × (20 / 100) = 10 + 18 = 28
final = 28 + 10 = 38

Finální event.risk_score: 38. Kdyby spouštěcí událost neměla předchozí skóre, výsledek by byl 20 + 10 = 30.

Tato váha je nezávislá na Average risk score v Assets (entitní skóre v čase). Váha ovlivňuje budoucí výstupy detekcí; entitní skóre odráží minulé detekce. Viz Entitní hodnocení rizika v LogMan.io Assets.

Úplný příklad (všechny vrstvy)¶

Window pravidlo s define.risk_score: 50 spustí na uživatele jsmith.

Spouštěcí complex událost už má event.risk_score: 20 (upstream detekce).
Základ po eskalaci: 20 + 80 × 0.5 = 60
Záznam ruleid2riskscore pro toto pravidlo: +5 → 65
source.ip odpovídá IOC: +15 → 80
userid2riskscore pro jsmith: +10 → 90

Výstupní complex událost:

event.risk_score: 90.0

Pořadí je důležité v hlavě, ne v konfiguraci

Konfigurujete jen pravidlo a lookupy. Correlator vždy aplikuje: základ (s eskalací) → ladění pravidla → IOC → váha aktiva. Pořadí kroků v YAML neměníte.

Explicitní skóre v triggeru¶

Pokud blok trigger nastaví event.risk_score (nebo pole rizika ve vašem schématu) ve výstupní šabloně, použije se hodnota jak je zapsaná. Automatický výpočet se pro tento trigger přeskočí.

Používejte pro výjimečné případy. Většina pravidel by měla spoléhat na define a lookupy, aby ladění zůstalo centralizované.

Shrnutí¶

Vrstva	Kde se konfiguruje	Efekt
Základ pravidla	`define.risk_score` nebo `define.severity`	Počáteční skóre nebo eskalace existujícího `event.risk_score`
Ladění pravidla	lookup `ruleid2riskscore`	Přičtení
IOC / intel	skupina `ioc` (+ `define.lookups`)	Přičtení za odpovídající dimenzi
Váha aktiva	UI Assets → risk score weight	Přičtení, když je na události id principálu

Pro psaní pravidel viz Correlator a Jak napsat window korelační pravidlo.

Entitní hodnocení rizika na aktivech¶

event.risk_score na complex lane události je skóre té detekce. LogMan.io Assets udržuje oddělené entitní hodnocení rizika na každém aktivu (host, user, service): číslo, které v čase slábne, když pro principál nepřicházejí nové detekce.

Vrstva	Kde	Role
Correlator / complex událost	`event.risk_score`	Jedna detekce (pravidlo + lookupy)
Inventář aktiv	Risk score v UI Assets	Aktuální riziko principálu po decay

Seřaďte seznam aktiv podle risk score a upřednostněte vyšetřování. Postranní panel detailu aktiva ukazuje Average risk score (stav entity teď); graf risk score ukazuje špičky detekcí v čase.

Pro přesný decay model (akumulátory, poločas, background tick) viz Risk score decay (detailed). Pro příklady a volitelnou Risk score weight viz Entity risk score in LogMan.io Assets.