Jak seřadit opravy podle rizika, ne podle skóre

Skóre je užitečné jako společný jazyk: řekne, jak vážná je chyba sama o sobě, srovnatelně napříč reporty i dodavateli. Co ale neřekne, je na jakém systému ta chyba je a kdo se k němu dostane. Deset nálezů se stejným číslem tak může být deset různých rizik. Detailně co CVSS skóre vlastně měří rozebírá slovníkové heslo, tenhle text je o tom, co se se skóre dělá dál.

Pořadí oprav proto není seřazený sloupec čísel. Je to rozhodnutí, do kterého vedle skóre vstupuje ještě několik věcí, které skóre z principu nezná. Právě ty rozhodují, proč nález se sedmičkou jde někdy do opravy dřív než nález s osmičkou.

Když v reportu srovnáváme dva nálezy, díváme se na čtyři věci, které samotné číslo nepokrývá. Každá z nich může pořadí obrátit.

• Exploitovatelnost: jestli na chybu existuje hotový veřejný exploit, nebo se dokonce už zneužívá ve volné přírodě. Chyba, na kterou stačí stáhnout nástroj, je jinak naléhavá než teoretická.
• Dosažitelnost: odkud na ten systém jde. Něco máte vystavené do internetu, něco až za VPN a přihlášením, něco jen v izolovaném segmentu, kam se běžný útočník nedostane.
• Hodnota systému: co se stane byznysu, když se to zneužije. Platební brána a interní wiki nejsou totéž, i když na nich sedí stejná chyba.
• Řetězitelnost: jestli se dá nález spojit s dalšími do jedné cesty. Řetězení znamená, že se z několika drobností složí průnik, na který by sama žádná z nich nestačila.

Skóre z těchhle čtyř zná nanejvýš kousek, a i ten nepřímo. Popisuje chybu v obecné instalaci: neví, jestli je zrovna váš systém dostupný z internetu, ani jestli na něm běží něco, o co by firma reálně přišla. Zralost exploitu a aktuální hrozby stojí v samostatných metrikách, které se do základního čísla nepočítají, takže report, který uvádí jen základní skóre, tuhle vrstvu prostě nenese.

Řetězení mění pořadí nejvíc a v čistě číselném seznamu je neviditelné. Tři nálezy, každý sám o sobě podprůměrný, můžou dohromady tvořit cestu od veřejného webu až k databázi. Kdo opravuje odshora podle čísla, tyhle tři nechá na konci, protože jednotlivě vypadají neškodně. Co ruční test na řetězení vidí, tedy co ruční test najde a skener ne, rozebírá srovnání se skenerem.

Standard s tímhle počítá: vedle základních metrik má i skupinu, kterou se výsledek upraví na konkrétní prostředí. Tam se dá zaznamenat, že daný systém je pro firmu kritický, nebo naopak že je odříznutý od internetu, a číslo se tomu přizpůsobí. My tuhle skupinu vyplňujeme podle toho, co u vás reálně platí, ne podle obecné instalace.

Prakticky to znamená, že stejný nález může u dvou klientů skončit s jiným pořadím opravy. Chyba na systému, který je u jedné firmy vystavený zákazníkům a u druhé běží v laboratoři bez připojení, dostane jinou naléhavost, i když je to bitově tentýž nález. U části nálezů navíc není z čeho opisovat: chyby v autorizaci nebo business logice žádné veřejné číslo nemají, takže skóre i jeho zdůvodnění stojí čistě na testerovi, a kdy nález nemá žádné CVE popisuje slovník.

Nejnázornější je to na příkladu. Představte si dva nálezy z jednoho testu. První je chyba s vysokým skóre v interním nástroji pro správu skladu, ke kterému se dostane pár lidí z jedné kanceláře a který není vidět z internetu. Druhý je chyba se středním skóre v přihlašovacím formuláři e-shopu, který má otevřený každý a přes který tečou platby.

Podle čísla by se opravoval první. Podle rizika jde první ten druhý: je dosažitelný odkudkoli, sedí na systému, který vydělává, a chyba v přihlášení je první krok k účtům zákazníků. Vysoké skóre na schované věci počká, střední skóre na exponované a cenné věci ne.

Druhý obrat dělá řetězení. Nález, který sám o sobě dovolí jen přečíst zdánlivě neškodný konfigurační soubor, povýší ve chvíli, kdy je v tom souboru heslo do další služby. Sám o sobě nízký, jako článek řetězu vysoký. Přesně tohle číslo na papíře nezachytí, protože hodnotí každý nález odděleně.

Žádná formule neseřadí opravy sama. Vstupuje do toho úsudek, který se nedá zapsat do vektoru. První je triáž falešných poplachů: než se nález dostane do pořadí, ověříme, že je skutečný a zneužitelný ve vaší konfiguraci, ne jen hláška nástroje. Nález, který v praxi nejde zneužít, nemá v horní části seznamu co dělat, ať má číslo jakékoli.

Druhá věc je znalost byznysu, kterou tester sám nemá a doplňuje ji zákazník. Někdy je systém s ošklivým nálezem pár týdnů před vyřazením a nemá smysl do něj investovat, jindy naopak drobnost sedí na procesu, který nesmí spadnout uprostřed sezóny. Tyhle výjimky do pořadí patří a probíráme je při předání, ne že bychom je hádali.

Proto výsledek není jen seřazený export. Je to doporučení, ke kterému dodáme důvod, a vy ho můžete podle svého kontextu přerovnat. Vzorec dá výchozí bod, úsudek dá pořadí, se kterým se dá reálně pracovat.

V reportu se tohle promítne tak, že každý nález nese tři věci: severitu, pořadí opravy a krátké zdůvodnění, proč je zrovna tam, kde je. Zdůvodnění je to podstatné, bez něj je pořadí jen další číslo, se kterým se nedá polemizovat. Co všechno report obsahuje a jak nálezy předáváme v reportu, ukazuje stránka penetračního testování.

Podle čtyř věcí, které samotné skóre nezná: jestli na chybu existuje hotový veřejný exploit, odkud je systém dosažitelný, jakou má pro byznys hodnotu a jestli se dá spojit s dalšími nálezy do jedné cesty. Skóre dá výchozí naléhavost, tyhle čtyři vstupy z ní udělají pořadí, se kterým se dá reálně pracovat.

Základní skóre ne. To popisuje vlastnosti chyby v obecné instalaci a se zralostí exploitu ani s aktuálními hrozbami nepočítá. Ty stojí v samostatných metrikách, které se do základního čísla nepromítnou. Proto report, který uvádí jen základní skóre, o dostupnosti exploitu nic neříká, a my ji do pořadí doplňujeme zvlášť.

Řetězení spojí několik nálezů, které jsou samy o sobě málo závažné, do jedné cesty útoku, na kterou by žádný z nich nestačil. Tím se jejich priorita zvedne: nález, který jen odhalí konfigurační soubor, povýší, pokud je v tom souboru heslo do další služby. V seznamu seřazeném podle čísla je řetězení neviditelné, protože každý nález se hodnotí odděleně.