Report z penetračného testu často príde ako dokument s desiatkami strán. Technický tím v ňom hľadá kroky reprodukcie, vedenie chce vedieť, aká vážna je situácia. Každá skupina potrebuje z reportu niečo iné. Tento článok opisuje, ako report čítať a ako z neho vytvoriť realistický plán nápravy.
Najprv rozsah, potom zistenia
Skôr než otvoríte zoznam zraniteľností, prečítajte si časť o rozsahu a obmedzeniach. Bez nej sa výsledky nedajú správne vyložiť.
- Ktoré systémy, aplikácie, roly a prostredia sa testovali a ktoré nie.
- V akom termíne test prebehol a ktorej verzie aplikácie sa týkal.
- Aké predpoklady mal tester, napríklad prístupové údaje alebo znalosť architektúry.
- Ktoré techniky boli podľa pravidiel testu zakázané.
Krátky zoznam zistení neznamená, že je prostredie bezpečné. Môže znamenať aj úzky rozsah alebo krátky čas. Naopak dlhý zoznam nemusí znamenať vážny problém, ak ide najmä o drobnosti s malým dopadom. Test je vždy obmedzený časom a rozsahom a nedokazuje, že iné slabiny neexistujú.
Závažnosť v kontexte, nie len číslo
Pri každom zistení nájdete hodnotenie závažnosti. Často ide o skóre CVSS, teda otvorený štandard organizácie FIRST na opis technickej závažnosti zraniteľností. Je užitočné, pretože umožňuje zistenia porovnávať. Má však svoje obmedzenia.
Špecifikácia CVSS v4.0 sama odporúča doplniť základné skóre o informácie o hrozbe a o konkrétnom prostredí. Základné skóre opisuje zraniteľnosť všeobecne. Nevie, či je dotknutý server dostupný z internetu, aké údaje spracúva ani aké ďalšie opatrenia ho chránia.
Dobrý report preto vysvetľuje, prečo má zistenie danú prioritu. Pri čítaní si pri každom významnom zistení položte tri otázky:
- Kto môže slabinu zneužiť? Anonymný útočník z internetu, prihlásený používateľ, alebo iba správca?
- Čo by tým získal? Prístup k údajom zákazníkov, prevzatie účtu, alebo iba informáciu o verzii softvéru?
- Dá sa zistenie kombinovať s inými? Niekoľko stredne závažných slabín môže spolu vytvoriť vážnu cestu útoku.
Pri rozhodovaní o poradí môžu pomôcť aj verejné zdroje. Katalóg CISA Known Exploited Vulnerabilities eviduje zraniteľnosti, pri ktorých je známe aktívne zneužívanie. Model EPSS odhaduje pravdepodobnosť zneužitia zverejnenej zraniteľnosti. Oba zdroje sa týkajú známych CVE, nie chýb vo vašej vlastnej aplikácii. Kontext vášho prostredia nenahradia.
Od zistení k plánu nápravy
Report sám nič neopraví. Hodnotu získa až vtedy, keď z neho vznikne plán s konkrétnymi ľuďmi a termínmi.
Pri každom zistení určte vlastníka. Vlastník nemusí byť ten, kto chybu opraví. Je to človek, ktorý zodpovedá za rozhodnutie a za to, že sa vec dotiahne. Pri aplikácii to býva produktový vlastník alebo vedúci vývoja, pri infraštruktúre správca danej oblasti.
Termín stanovte podľa priority, nie podľa toho, kedy má tím práve voľno. Zistenia je praktické previesť do nástroja, ktorý tím bežne používa, napríklad do issue trackera. Každá úloha by mala odkazovať na konkrétne zistenie v reporte, aby sa dal neskôr dohľadať jej stav.
Potom rozdeľte zistenia do skupín podľa priority a náročnosti:
- Zistenia s vysokým dopadom a jednoduchou opravou riešte hneď.
- Zistenia s vysokým dopadom a zložitou opravou potrebujú dočasné opatrenie a plán. Dočasným opatrením môže byť obmedzenie prístupu, vypnutie funkcie alebo sprísnenie monitoringu.
- Zistenia s nízkym dopadom zaraďte do bežného vývoja alebo údržby.
- Pri zisteniach, ktoré vedome neopravíte, zapíšte dôvod, zvyškové riziko a kto ho schválil.
Posledný bod je dôležitý. Prijať riziko je legitímne rozhodnutie. Malo by však byť vedomé, zdokumentované a z času na čas znova posúdené.
Užitočné je aj hľadať príčiny. Ak report obsahuje niekoľko zistení rovnakého typu, napríklad chýbajúcu kontrolu oprávnení pri rôznych API operáciách, nestačí opraviť jednotlivé prípady. Oplatí sa upraviť spoločný komponent, knižnicu alebo postup code review.
Retest a overenie opráv
Po opravách je vhodné overiť, že zistenia naozaj zmizli a že oprava nespôsobila nový problém. Retest nie je automatickou súčasťou každého testu. Jeho rozsah, termín a podmienky sa dohodnú v ponuke.
Retest zvyčajne overuje pôvodné zistenia na konkrétnej verzii. Nejde o nový kompletný test. Ak medzitým nastali veľké zmeny v aplikácii alebo infraštruktúre, je dobré zvážiť nový test alebo rozšírenie rozsahu.
Pred retestom pripravte zoznam zistení, ktoré považujete za opravené, so stručným opisom zmeny. Tester tak vie, čo overovať, a výsledok bude presnejší.
Výsledkom retestu by mal byť aktuálny stav každého zistenia: opravené, čiastočne opravené, neopravené, alebo riziko prijaté. To je podklad pre vedenie aj pre prípadné otázky zákazníkov či audítorov.
Kontrolný zoznam po prevzatí reportu
- Prečítali ste si rozsah, predpoklady a obmedzenia testu.
- Viete, ktoré systémy test nepokryl, a máte rozhodnuté, či ich treba preveriť.
- Každé významné zistenie má vlastníka a termín.
- Pri zisteniach so zložitou opravou máte dočasné opatrenie.
- Prijaté riziká majú písomné zdôvodnenie a schválenie.
- Opakujúce sa typy zistení riešite aj na úrovni príčiny.
- Viete, či a kedy prebehne retest a čo bude pokrývať.
- Vedenie dostalo zrozumiteľné zhrnutie dopadov a plánu.
Ak si s výkladom reportu alebo s nastavením priorít nie ste istí, radi s vami zistenia prejdeme. Pomôžeme ich previesť na priority, zodpovednosti a realistický plán nápravy. Ako prvý krok si môžete dohodnúť krátku konzultáciu.
