Report z penetračního testu často přijde jako dokument o desítkách stran. Technický tým v něm hledá kroky reprodukce, vedení chce vědět, jak vážná je situace. Každá skupina potřebuje z reportu něco jiného. Tento článek popisuje, jak report číst a jak z něj vytvořit realistický plán nápravy.
Nejdřív rozsah, potom nálezy
Než otevřete seznam zranitelností, přečtěte si část o rozsahu a omezeních. Bez ní nelze výsledky správně vyložit.
- Které systémy, aplikace, role a prostředí byly testovány a které ne.
- V jakém termínu test proběhl a které verze aplikace se týkal.
- Jaké předpoklady tester měl, například přístupové údaje nebo znalost architektury.
- Které techniky byly podle pravidel testu zakázané.
Krátký seznam nálezů neznamená, že je prostředí bezpečné. Může také znamenat úzký rozsah nebo krátký čas. Naopak dlouhý seznam nemusí znamenat vážný problém, pokud jde hlavně o drobnosti s malým dopadem. Test je vždy omezený časem a rozsahem a nedokazuje, že jiné slabiny neexistují.
Závažnost v kontextu, ne jen číslo
U každého nálezu najdete hodnocení závažnosti. Často jde o skóre CVSS, tedy otevřený standard organizace FIRST pro popis technické závažnosti zranitelností. Je užitečné, protože umožňuje nálezy srovnávat. Má ale svá omezení.
Specifikace CVSS v4.0 sama doporučuje doplnit základní skóre o informace o hrozbě a o konkrétním prostředí. Základní skóre popisuje zranitelnost obecně. Neví, jestli je dotčený server dostupný z internetu, jaká data zpracovává ani jaká další opatření ho chrání.
Dobrý report proto vysvětluje, proč má nález danou prioritu. Při čtení si u každého významného nálezu položte tři otázky:
- Kdo může slabinu zneužít? Anonymní útočník z internetu, přihlášený uživatel, nebo jen správce?
- Co by tím získal? Přístup k datům zákazníků, převzetí účtu, nebo jen informaci o verzi software?
- Dá se nález kombinovat s jinými? Několik středně závažných slabin může dohromady vytvořit vážnou cestu útoku.
Při rozhodování o pořadí mohou pomoci i veřejné zdroje. Katalog CISA Known Exploited Vulnerabilities eviduje zranitelnosti, u kterých je známé aktivní zneužívání. Model EPSS odhaduje pravděpodobnost zneužití publikované zranitelnosti. Oba zdroje se týkají známých CVE, ne chyb ve vaší vlastní aplikaci. Kontext vašeho prostředí nenahradí.
Od nálezů k plánu nápravy
Report sám nic neopraví. Hodnotu získá až ve chvíli, kdy z něj vznikne plán s konkrétními lidmi a termíny.
U každého nálezu určete vlastníka. Vlastník nemusí být ten, kdo chybu opraví. Je to člověk, který odpovídá za rozhodnutí a za to, že se věc dotáhne. U aplikace to bývá produktový vlastník nebo vedoucí vývoje, u infrastruktury správce dané oblasti.
Termín stanovte podle priority, ne podle toho, kdy má tým zrovna volno. Nálezy je praktické převést do nástroje, který tým běžně používá, například do issue trackeru. Každý úkol by měl odkazovat na konkrétní nález v reportu, aby se dal později dohledat jeho stav.
Pak rozdělte nálezy do skupin podle priority a náročnosti:
- Nálezy s vysokým dopadem a jednoduchou opravou řešte hned.
- Nálezy s vysokým dopadem a složitou opravou potřebují dočasné opatření a plán. Dočasným opatřením může být omezení přístupu, vypnutí funkce nebo zpřísnění monitoringu.
- Nálezy s nízkým dopadem zařaďte do běžného vývoje nebo údržby.
- U nálezů, které vědomě neopravíte, zapište důvod, zbytkové riziko a kdo ho schválil.
Poslední bod je důležitý. Přijmout riziko je legitimní rozhodnutí. Mělo by ale být vědomé, zdokumentované a čas od času znovu posouzené.
Užitečné je také hledat příčiny. Pokud report obsahuje několik nálezů stejného typu, například chybějící kontrolu oprávnění u různých API operací, nestačí opravit jednotlivé případy. Vyplatí se upravit společnou komponentu, knihovnu nebo postup code review.
Retest a ověření oprav
Po opravách je vhodné ověřit, že nálezy skutečně zmizely a že oprava nezpůsobila nový problém. Retest není automatickou součástí každého testu. Jeho rozsah, termín a podmínky se dohodnou v nabídce.
Retest obvykle ověřuje původní nálezy na konkrétní verzi. Nejde o nový kompletní test. Pokud mezitím vznikly velké změny v aplikaci nebo infrastruktuře, je dobré zvážit nový test nebo rozšíření rozsahu.
Před retestem připravte seznam nálezů, které považujete za opravené, se stručným popisem změny. Tester tak ví, co ověřovat, a výsledek bude přesnější.
Výsledkem retestu by měl být aktuální stav každého nálezu: opraveno, částečně opraveno, neopraveno, nebo riziko přijato. To je podklad pro vedení i pro případné dotazy zákazníků či auditorů.
Kontrolní seznam po převzetí reportu
- Přečetli jste rozsah, předpoklady a omezení testu.
- Víte, které systémy test nepokryl, a máte rozhodnuto, zda je potřeba je prověřit.
- Každý významný nález má vlastníka a termín.
- U nálezů se složitou opravou máte dočasné opatření.
- Přijatá rizika mají písemné zdůvodnění a schválení.
- Opakující se typy nálezů řešíte i na úrovni příčiny.
- Víte, zda a kdy proběhne retest a co bude pokrývat.
- Vedení dostalo srozumitelné shrnutí dopadů a plánu.
Pokud si s výkladem reportu nebo s nastavením priorit nejste jistí, rádi s vámi nálezy projdeme. Pomůžeme je převést na priority, odpovědnosti a realistický plán nápravy. Prvním krokem může být krátká konzultace.
