Nikdo nepřečte 5 087 bezpečnostních článků za rok

Zadání

Klientem je B2B softwarová firma, jejíž bezpečnostní tým sleduje veřejný kanál bezpečnostních zpráv. Za 12 měsíců z něj přišlo 5 087 článků: asi 420 měsíčně, 14 denně, každý den. I při jedné minutě na článek je to zhruba 85 hodin čtení, než kdokoli posoudí jediný z nich.

To nikdo nedělá. Kdo kanál jen prolétne, buď přehlédne ten jeden článek, na kterém záleží, nebo se naučí kanál ignorovat. A prolétnout není skutečná práce: abyste řekli, jestli se článek klienta týká, musíte vědět, co provozuje, jak je to vystavené a jestli chyba funguje v jeho konfiguraci.

Zadání tedy neznělo, jak číst rychleji. Znělo, jak zajistit, aby člověk četl jen těch pár článků, které si to zaslouží.

Jak přemýšlíme

Návrh se řídí několika pravidly uvažování a ta jsou důležitější než kterýkoli nástroj, který jsme zvolili.

1. Drahého čtenáře nasaďte až nakonec. Nejdřív přijdou levná, deterministická pravidla a hromadu zmenší. LLM čte jen to, co zbude. Celý kanál nikdy modelu neposíláme.
2. Posuzujte podle toho, co klient skutečně provozuje. Článek není „důležitý“ obecně. Je důležitý, když se týká produktu z vlastního inventáře klienta, a to tak, jak je ten produkt vystavený. Inventář je kotvou každého verdiktu.
3. Většina článků má skončit jako zelená. Kontrola, která v každém článku něco najde, je jen šum. Cílem je, aby naprostá většina skončila bez dopadu a skutečný odhad dopadu dostala jen malá skupina.
4. Pravidlo smí frontu pro LLM zmenšit, nikdy zvětšit. Každé nové pravidlo musí články z fronty odebrat. Když otázku zodpoví vyhledání (je tento balíček nebo plugin v lockfilech klienta?), není to práce pro LLM.
5. Rozsah je rozhodnutí, ne náhoda. Software spravovaný dodavatelem a nástroje na pracovních stanicích jsou podle pravidel mimo rozsah, protože tato kontrola se týká vlastního produktu klienta. Pravidla jsou sepsaná a dají se změnit na jednom místě.
6. Poplach musí zůstat vzácný a důvěryhodný. Červená znamená „v době zveřejnění to potřebovalo nouzovou záplatu“ a nic mírnějšího. Bezpečnostní tým, který je varován příliš často, přestane poslouchat.
7. Jeden soudce vidí všechno najednou. Oddělené dávky hodnocení přestřelují a navzájem si odporují. Jediný hodnotitel, který čte všechny vážné události pohromadě, uplatní jedno pravidlo důsledně.
8. Řekněte, co nevíme. Komponenty, o kterých se jen předpokládá, že je klient provozuje, nemohou dostat červenou, a hodnotitel zaznamená, proč událost zadržel. Text článku je nedůvěryhodná data, nikdy pokyny.
9. Končete akcí. Duplicitní zprávy o téže věci se sloučí do jednoho problému a každý problém nese konkrétní další krok, ne jen skóre.

Jak to funguje

1. Přišlo v kanálu5 087Kanál bezpečnostních zpráv, 12 měsíců
2. Zmiňuje produkt, který klient provozuje1 409Předfiltr pravidly: shoda klíčových slov a CVE s inventářem klienta27,7 % předchozího kroku
3. Bezpečnostní problém v produktu nebo infrastruktuře391Třídění pravidly: týká se bezpečnosti a podle pravidel spadá do rozsahu27,7 % předchozího kroku
4. Tady pravidla končí: LLM čte jen těchto 391Konkrétní chyba v softwaru, který klient provozuje125Rychlý průchod LLM: konkrétní chyba, ne zmínka mimochodem32,0 % předchozího kroku
5. Hodnoceno červeně nebo oranžově76Hodnocení dopadu LLM, pak jedna kontrola konzistence60,8 % předchozího kroku

4 696 článků (92,3 %) se k LLM nikdy nedostane.

Prvních 92 % zvládnou jednoduchá pravidla: 4 696 z 5 087 článků se k modelu nikdy nedostane. Zbylých 391 čtou subagenti LLM a 125 z nich ponechají k úplnému hodnocení dopadu podle textu článku a veřejných dat o zneužívání. Co zodpoví vyhledání, třeba škodlivý balíček nebo plugin ze seznamu, dostane modrou (mechanickou kontrolu) místo práce pro LLM.

Popořadě: předfiltr porovná každý článek s inventářem klienta a třídění pravidly rozdělí shody na zelené, modré a šedé pro LLM. Rychlý průchod LLM čte titulky a shrnutí a odpoví „zelená“, „závislost“ nebo „posoudit“. Články k posouzení se seskupí do událostí, doplní se o text článku a data o zneužívání (CISA KEV a EPSS) a dostanou hodnocení červená, oranžová, žlutá nebo zelená. Jedna kontrola konzistence pak přečte všechny červené a oranžové události pohromadě, sloučí duplicity do problémů a uplatní přísné pravidlo pro červenou. Výstupem je jeden řádek na článek s konečným stavem a jeden řádek na problém s datem prvního a posledního výskytu, počtem článků a konkrétní akcí.

Výsledky

93 % článků za rok nevyžadovalo žádnou akci a 76 článků (1,5 %) dostalo červenou nebo oranžovou. Těch 76 článků se slije do 31 samostatných problémů, protože o téže chybě píše víc zdrojů. Naléhavé čtení se zmenšilo z 5 087 článků na 31 problémů. Vedle zůstává práce s nižší prioritou: 43 žlutých problémů a 231 modrých článků, které potřebují mechanickou kontrolu.

Stav	Význam	Články	Podíl	Problémy
Červená	V době zveřejnění to potřebovalo nouzovou záplatu	28	0,6 %	7
Oranžová	Skutečné vystavení, ale s předpokladem (místní přístup, přihlašovací údaje, konkrétní konfigurace)	48	0,9 %	24
Žlutá	Neobvyklá konfigurace, odepření služby na interní komponentě nebo malá pravděpodobnost	44	0,9 %	43
Modrá	Potřebuje mechanické vyhledání (lockfily závislostí, seznamy pluginů)	231	4,5 %	–
Zelená	Žádný dopad na to, co klient provozuje, nebo podle pravidel mimo rozsah	4 736	93,1 %	–

Zelená není jedna věc. 3 678 článků nejmenuje nic, co klient provozuje. 489 zmiňuje produkty klienta, ale jsou informativní, zmiňují je jen mimochodem, nebo byly posouzeny jako nedotčené. 569 je podle pravidel mimo rozsah (SaaS spravovaný dodavatelem a software pracovních stanic): není prokázáno, že jsou bezpečné, jen nejsou úkolem této kontroly.

Sedm červených problémů za 12 měsíců je zhruba jeden za sedm týdnů. O tu vzácnost jde: když se červená objeví, věří se jí.

Proč se hodnocení dá věřit

Jeden krok kontroly navíc počet červených výrazně snížil. Jednotkou je tu událost, tedy články o jedné věci; duplicitní události se později slučují do jednoho problému. Při hodnocení v oddělených dávkách vyšlo červeně 21 událostí, protože každá dávka přestřelovala. Jediný hodnotitel pak přečetl všech 44 červených a oranžových událostí pohromadě a uplatnil jedno přísné pravidlo pro červenou. Výsledek byl dvojí: červených událostí ubylo z 21 na 14 a sloučení duplicitních zpráv z těch 14 udělalo 7 červených problémů (ze všech 44 událostí vzniklo 32 problémů). Červená vyžaduje všechno z tohoto:

• komponenta je v inventáři klienta, nebo jde o kompromitaci dodavatelského řetězce nástroje, který klient používá
• je dostupná z internetu
• není potřeba přihlášení
• dopadem je vzdálené spuštění kódu nebo krádež dat a tajných údajů
• funguje v běžné konfiguraci
• je zneužívaná, je v CISA KEV, nebo má skóre CVSS 9 a víc

Cokoli jiného je nejvýš oranžová. Hodnotitel zaznamená, proč událost zadržel, například „vyžaduje přihlášený účet; zákaznické účty se přidělují, nikdo si je nezaloží sám“. Cílem bylo, aby červená znamenala „v době zveřejnění to potřebovalo nouzovou záplatu“, takže bezpečnostní tým nedostává varování kvůli věcem, které ji nepotřebovaly.

Obě strany se ověřily ručně, v rozsahu, který kapacita dovolila. Každý červený a oranžový problém byl prověřen a potvrzen jako skutečný nález. Články s nižším hodnocením se kontrolovaly v menším rozsahu, náhodným vzorkem a výběrem podle závažnosti. Je to namátková kontrola, ne změřená míra přehlédnutí: ručně projít všech 5 087 článků nebylo s dostupnými lidmi nikdy možné, a právě proto celý postup existuje.

Použité pojmy

• Inventář. Vlastní seznam produktů, které klient provozuje, s tím, jak je každý vystavený (interně, nebo navenek), a s jeho typem (SaaS, server, pracovní stanice, knihovna).
• Fronta pro LLM. Články, které pravidla nerozhodla a které čekají, až je LLM přečte.
• Událost a problém. Událost je soubor článků o jedné věci. Duplicitní události se slučují do jednoho problému, a s tím pak člověk pracuje.
• CISA KEV. Veřejný katalog zranitelností, o nichž je známo, že se zneužívají při skutečných útocích; vede ho americká agentura pro kybernetickou bezpečnost CISA.
• CVSS. Skóre závažnosti zranitelnosti od 0 do 10; 9 a víc je kritická.
• EPSS. Zveřejňovaný odhad, jak pravděpodobně bude zranitelnost brzy zneužita.
• Lockfile. Soubor s přesnými verzemi balíčků, které softwarový projekt používá, takže škodlivý balíček se v něm dá dohledat mechanicky.

Omezení a otevřené otázky

• Předpokládané komponenty hodnocení omezují. 13 položek inventáře je předpokládaných, ne potvrzených, takže jejich problémy končí na oranžové. Dvě z nich hodnotitel označil jako červené pro případ, že se potvrdí jejich dostupnost z internetu.
• Rozsahem je podle pravidel produkt. 569 článků (176 o SaaS spravovaném dodavatelem, 393 o softwaru pracovních stanic) dostalo zelenou, protože tato kontrola pokrývá produkt, ne záplatování IT.
• Jeden velký zdroj se čte jen ze shrnutí. Jeho 2 322 článků se nestahuje, protože web blokuje skriptovaný přístup, takže hodnocení stojí na shrnutí z kanálu.
• Hodnocení jsou úsudky modelu. Čísla ukazují, kolik problémů se eskalovalo, ne zda byla každá červená včas záplatovaná.