Skóre rizika entity¶
LogMan.io používá dva související koncepty hodnocení rizik:
| Koncept | Kde to vidíš | Význam |
|---|---|---|
| Skóre rizika detekce | Složitá události, upozornění, Objevovat | Skóre jednoho zjištění po pravidlech korelace a vyhledávání |
| Skóre rizika entity | Seznam aktiv a detail aktiva | Jak rizikový je tento uživatel, hostitel nebo služba právě teď, na základě nedávných detekcí |
Hodnocení detekce je popsáno v Hodnocení rizik v Korelátoru. Tato stránka vysvětluje skóre rizika entity u aktiv.
Kde hledat v uživatelském rozhraní¶
| Místo | Co vidíte | Co vám to říká |
|---|---|---|
| Tabulka aktiv | Sloupec skóre rizika | Porovnejte hlavní částky na první pohled; seřaďte podle rizika |
| Podrobnosti o majetku postranní panel | Průměrné skóre rizika | Aktuální skóre entity po úbytku |
| Podrobnosti o majetku graf | Řádek skóre rizika | Skóre detekce vrcholů v průběhu času (není to stejné číslo jako na postranním panelu) |
!!! tip „SOC třídění v pondělí ráno“
Otevřete Aktiva a seřaďte podle skóre rizika sestupně. Pracovní stanice s hodnotou 72 po několika neúspěšných přihlášeních během víkendu zůstává na vrcholu, i když byla poslední výstraha před několika hodinami. Server, který měl včera jednu výstrahu 85, ale od té doby nic, může již ukazovat 40, protože skóre slábne, když aktivita ustane.
Jedno hlasité upozornění vs mnoho tichých
Uživatel jsmith spustí jedno pravidlo s rizikem detekce 80. Jejich skóre entity se posune směrem k 80. Následující den přijdou tři menší detekce po 20: skóre entity se nestane 140. Směruje spíše k novým hodnotám (přibližně 40, pokud dorazily blízko sebe). Starý šum se nesčítá neomezeně.
!!! tip „Postranní panel vs graf“
Postranní panel Průměrné skóre rizika odpovídá: „Měl bych se o tohoto ředitele nyní obávat?“
Graf skóre rizika odpovídá na otázku: „Kdy došlo k nárůstu detekcí?“
Po klidném týdnu může boční panel zobrazovat 0 nebo být prázdný, zatímco graf stále ukazuje nárůst z minulého úterý.
Jak se vytváří skóre entity¶
LogMan.io Assets zpracovává detekce korelací pro každého nájemce. Když detekce obsahuje event.risk_score a identifikuje hostitele, uživatele nebo službu, tato hodnota aktualizuje skóre entity pro daný subjekt pokud aktivum již existuje (vytvořeno ze streamu aktivit nebo HTTP). Komplexní detekce nevytvářejí řádky inventáře.
Skóre je vážený průměr s časovým útlumem nedávných hodnot detekce (styl UEBA), ne průběžný součet. Pro přesný model viz Útlum rizikového skóre (podrobně).
Na vysoké úrovni:
- Nová zjištění zvyšují skóre (nebo snižují, pokud je nová hodnota nižší).
- Doba bez zjištění snižuje skóre (výchozí poločas 24 hodin).
- Mnoho slabých upozornění se nesčítá nekonečně stejným způsobem, jako by se sčítal jejich prostý součet.
Příklad (zjednodušeně): Skóre entity bylo 80 z jednoho upozornění. Okamžitě přijde nové zjištění s rizikem 20: smíšené skóre se stane přibližně 50, ne 100. Po 24 hodinách bez dalších zjištění se skóre znovu zmenší přibližně na 25, pak nová aktivita může skóre opět posunout.
!!! tip „Proč průměr, a ne součet?“
Deset upozornění s nízkou prioritou rozložených v průběhu týdne by uživatele nemělo posunout na stejnou úroveň jako deset kritických incidentů. Skóre entity odráží nedávnou relevanci, podobně jako u produktů UEBA, kde zastaralé riziko slábne místo toho, aby žilo navždy v běžícím součtu.
Pokles skóre rizika (podrobně)¶
Tato sekce popisuje přesný model rizika entit používaný lmio-assets při slučování složitých detekcí jízdních pruhů.
Vstup¶
Důležité jsou pouze události komplexního pruhu. Pro každé zjištění služba čte:
| Vstup | Zdroj |
|---|---|
| Ředitel | ID hostitele, uživatele nebo služby ze schématu nájemce (stejná pole jako u aktiv aktivit) |
Příspěvek c |
event.risk_score on the detection (must be > 0 to change state) |
Čas události t |
Hlavní datum a čas u složité události (obvykle @timestamp), jako Unix milisekundy |
Detekce s c ≤ 0 jsou pro hodnocení ignorovány.
Vnitřní stav v MongoDB¶
Celé číslo risk_score zobrazené v uživatelském rozhraní je odvozeno ze tří interních polí na dokumentu aktiva:
| Pole | Role |
|---|---|
risk_score_sum (S) |
Vážený součet minulých hodnot detekce |
risk_score_weight (W) |
Součet vah (každé zjištění přidá 1 po rozkladu) |
risk_score_at |
Unix ms, kdy byly akumulátory naposledy posunuty na čas události |
Skóre entity v kterýkoli okamžik:
score = S / W (rounded to integer for API / list sort)
Odpovědi API a exporty nezobrazují risk_score_sum, risk_score_weight nebo risk_score_at; pouze vypočtené risk_score.
Rozpad mezi detekcemi¶
Když čas postupuje od předchozí aktualizace (risk_score_at) k novému času události t bez začlenění nového zjištění, oba akumulátory jsou vynásobeny stejným faktorem:
decay(Δt) = 0.5 ^ (Δt_hours / half_life_hours)
S ← S × decay(Δt)
W ← W × decay(Δt)
Výchozí half_life_hours = 24 ([assets] risk_score_decay_half_life, výchozí 24h).
Po jedné celé polovině života bez nových detekcí se S i W zmenší na polovinu, takže score = S/W zůstává stejné až do doby, než bude sloučena nová detekce.
Intuice: poločas nesnižuje zobrazené skóre, zatímco se nic nového neděje (S a W se zmenšují stejně, takže S/W zůstává konstantní). Řídí, jak moc starší detekce započítávají, když je další detekce sloučena — po 24 hodinách nečinnosti přispívá předchozí historie poloviční vahou, než je nová hodnota smíchána.
!!! poznámka „Nečinná vs. nová zjištění“
Žádné nové složité události: postranní panel a seznam risk_score zůstávají na poslední hodnotě (např. 80 zůstává 80).
Nová detekce po nečinnosti: historie je nejprve snížena, poté zprůměrována s novým event.risk_score — tehdy se číslo posune dolů (nebo nahoru).
Tipy analytiků, které popisují, že skóre „vybledne“ během klidného víkendu, předpokládají další nižší záznamy nebo kombinaci minulých vzorků, nikoli jen samovolné slábnutí ze starého upozornění.
Sloučení nového zjištění¶
Když detekce s hodnotou c > 0 dorazí v čase t:
- Pokud
t ≥ risk_score_at: aplikujte pokles odrisk_score_atdot, potom nastavterisk_score_at = t. - Pokud
t < risk_score_at(pozdní událost): přidejtecdo S a +1 do W, ale neposouvejterisk_score_atzpět. - Aktualizujte akumulátory:
S ← S × decay(Δt) + c (Δt = 0 when late event)
W ← W × decay(Δt) + 1
score = round(S / W)
Bufferované detekce z Kafky jsou před zápisem sloučeny v pořadí podle času události pro každý prostředek.
Odstraňování nízkých skóre¶
Pokud po snížení nebo sloučení score < risk_score_decay_clear_below (výchozí 0,5), jsou všechna pole rizika odstraněna z Mongo (risk_score, risk_score_sum, risk_score_weight). Aktivum pak v uživatelském rozhraní nezobrazuje žádné riziko entity až do další kvalifikující detekce.
Když je aplikováno rozklad¶
| Okamžik | Chování |
|---|---|
| Komplexní proplach jízdního pruhu | Detekce sloučeny do Mongo; akumulátory posunuty na nejnovější čas události v dávce |
| HTTP GET (seznam, detail, export) | risk_score recomputed at now from stored S, W, and risk_score_at (passive decay) |
| Pozadí cvaknutí | Každých 10 minut (Application.tick/600!) se uložené S, W a risk_score zachovají po pasivním úbytku, takže třídění podle risk score v seznamu aktiv zůstává zarovnané, aniž by bylo třeba číst každý řádek při každém požadavku |
Mezi značkami se seznam/podrobnosti stále zobrazují správnou zmenšenou hodnotu při čtení, i když Mongo stále uchovává mírně zastaralé celé čísla.
Bezpečnost více instancí¶
Několik instancí lmio-assets může spotřebovávat stejné složité téma. Sloučení používá porovnej-a-nastav na risk_score_at: aktualizace se aplikuje pouze tehdy, pokud risk_score_at v Mongo stále odpovídá přečtené hodnotě. Konfliktní zápisy se opakují (výchozí 8 pokusů, [assets] risk_score_cas_retries). Pasivní úloha degradace používá stejnou ochranu, takže současné sloučení detekce není přepsáno.
Číselný příklad¶
Konfigurace: poločas 24 h, clear_below = 0,5.
- T0: První detekce
c = 80→ S = 80, W = 1, skóre = 80. - T0 + 1 h: Druhá detekce
c = 20→ decay(1 h) ≈ 0,971, S ≈ 80×0,971 + 20 ≈ 97,7, W ≈ 1,971, skóre ≈ 50. - T0 + 25 h (žádné další detekce): pokud stále neaktivní, skóre zůstává ≈ 50 (S a W se rozpadají stejně).
- T0 + 25 h s novou detekcí
c = 10: historie s poloviční váhou se mísí směrem k 10 — zobrazené skóre klesá, protože přišel nový vzorek, ne jen vzhledem k době nečinnosti.
Postranní panel vs graf skóre rizika¶
Tyto pohledy odpovídají na různé otázky a využívají různá data:
| Zobrazit | Data | Otázka |
|---|---|---|
| Průměrné skóre rizika (postranní panel, sloupec seznamu) | Model rozložené entity nahoře | Jak rizikový je tento princip právě teď? |
| Graf skóre rizika (podrobnosti o majetku) | max(event.risk_score) per time bucket on complex lane events only |
Kdy jednotlivá zjištění vrcholila v každém období? |
Graf může ukázat nárůst z minulého úterý, zatímco postranní panel je už 0 po klidném týdnu.
Volitelná váha rizikového skóre¶
Na stránce s podrobnostmi o aktivu můžete nastavit váhu skóre rizika (0 až 100). Použijte to, když vaše nasazení upravuje, jak silně by měly budoucí detekce zahrnující daného uživatele skórovat (například řadič domény nebo známý servisní účet).
Toto přepsání je oddělené od Průměrného skóre rizika v postranním panelu, které stále vychází z reálných detekcí na tomto majetku.
Pro úpravu vyhledávání potřebujete oprávnění. Použijte Vymazat váhu k odstranění přepsání.
Skóre v průběhu času¶
- Detekce používají čas události na komplexní události (obvykle
@timestamp). - Otevření seznamu nebo detailu aktiva zobrazuje skóre tak, jak je nyní, včetně pasivního rozpadu od poslední detekce (viz Rozpad skóre rizika (podrobně)).
- Služba také na pozadí každých 10 minut aktualizuje uložená skóre, aby řazení v seznamu aktiv zůstalo v souladu s modelem.
- Velmi nízká skóre (pod 0,5 ve výchozím nastavení) se z UI ztrácejí.
Pokud detekce dorazí pozdě (čas události starší než poslední aktualizace), její hodnota stále přispívá do průměru, ale rozpady se nevrací zpět v čase.
Konfigurace (správci)¶
[assets] key |
Výchozí | Popis |
|---|---|---|
risk_score_decay_half_life |
24h |
Polovina života při snižování váhy minulých detekcí před sloučením nové |
risk_score_decay_clear_below |
0.5 |
Skrýt a vymazat skóre pod touto hodnotou |
risk_score_cas_retries |
8 |
Optimistické opakování při slučování zjištění napříč instancemi |
complex_mongo_batch_max |
100 |
Vyrovnaná detekce před uložením |
complex_mongo_batch_max_age |
60 |
Maximální počet sekund před částečným vyprázdněním vyrovnávací paměti |
Viz Konfigurace pro nastavení služby a závislosti.
Související dokumentace¶
- Hodnocení rizik v Correlator: podle detekce
event.risk_score - Přehled aktiv LogMan.io