Jak často provádět penetrační test podle rizika, ne jen podle zákona

Roční test stačí tam, kde se prostředí skoro nemění. Jakmile firma nasazuje často, přidává integrace nebo roste, jednou za rok je málo, protože mezi testy vznikne spousta nového kódu a nových vstupů, které nikdo neprověřil.

Rozdíl je v tempu změn, ne ve velikosti firmy. Malý e-shop, který každý týden vydává novou funkci, má víc neprověřených změn než velká firma s jedním stabilním systémem. Kalendář tohle nezachytí, proto se kadence odvíjí od toho, kolik se toho od minulého testu změnilo.

Vedle pravidelného cyklu má test smysl pokaždé, když se podstatně změní to, co je v ohrožení. Konkrétně jde o šest situací, a žádná z nich se neřídí kalendářem.

• Nová verze nebo funkce aplikace, která mění business logiku nebo přidává vstupní body.
• Migrace systému nebo dat, například přechod do cloudu nebo na jinou platformu.
• Nová integrace nebo API, kterým se ven otevírá další cesta dovnitř.
• Nový perimetr: nová doména, nová veřejná služba, nově vystavené rozhraní.
• Fúze nebo akvizice, kdy do vaší sítě přibude prostředí, které jste netestovali.
• Bezpečnostní incident, po kterém je potřeba ověřit, jestli je cesta útočníka zavřená a jestli nezůstala další.

Tyhle spouštěče nejsou o čase, ale o změně. Když nastanou dva měsíce po ročním testu, nečeká se na další rok. Test se navazuje na tu změnu, ne na datum v kalendáři.

Kadenci si odvodíte z pěti faktorů, ne z jednoho čísla. Čím víc jich u vás platí silně, tím kratší interval mezi testy dává smysl.

• Velikost attack surface, tedy souhrnu všeho, čím se dá do firmy dostat zvenčí i zevnitř. Víc aplikací, domén a rozhraní znamená víc míst, kde vznikne chyba.
• Tempo změn: čím častěji nasazujete, tím dřív je předchozí test zastaralý.
• Citlivost dat: u plateb, zdravotních a osobních údajů je cena jediné chyby vyšší.
• Míra expozice do internetu: co je veřejně dostupné, zkoušejí útočníci nepřetržitě.
• Obor: regulovaná odvětví a časté terče útoků potřebují kratší cyklus.

Žádný z faktorů sám o sobě přesný interval neurčí, ale společně vám řeknou, jestli patříte spíš k ročnímu základu, nebo k častějšímu testování. Když si nejste jistí, kam ve škále spadáte, je to přesně věc na jeden hovor.

Frekvence testů je jedna věc, retest druhá. Retest, tedy opakované ověření, že jsou nalezené chyby opravdu opravené, nepatří do kadence, ale ke každému jednotlivému testu. Bez něj máte doloženo jen to, co bylo rozbité, ne to, co je spravené. Jak retest zapadá do celku, ukazuje jak probíhá jednotlivý penetrační test.

Ve vyšším režimu platí pro regulované firmy zákonné minimum, jak často testovat. To tady nerozvádíme, je to samostatné téma: zákonné minimum pro testování ve vyšším režimu i lhůty, které nZKB ukládá regulovaným firmám mají vlastní články.

Jestli se vás regulace vůbec týká, je otázka režimu, kterou zjistíte podle toho, jestli vaše firma vůbec spadá pod regulaci. Pro rozhodnutí o kadenci ale platí jen tolik: zákonné minimum je spodní hranice, ne cílová frekvence. Kdo se řídí jen jím, testuje málo.

Ročně jako výchozí základ, k tomu po každé významné změně systému a podle míry rizika. Firma, která často nasazuje nebo drží citlivá data, potřebuje kratší interval než stabilní prostředí, které se nemění. Rozhoduje tempo změn a citlivost dat, ne samotný kalendář.

Ne po každé, jen po významné. Oprava překlepu ani drobná úprava vzhledu nový test nevyžadují. Smysl má tam, kde se změní business logika, přibude vstupní bod, nová integrace nebo API, nebo se rozšíří rozsah systému. Rozhoduje, jestli změna otevřela novou cestu dovnitř, ne jak je velká v řádcích kódu.

Zákonné minimum platí jen pro regulované firmy ve vyšším režimu a stanoví ho vyhláška, ne obecné pravidlo. Konkrétní lhůtu i to, co přesně vyhláška o testování žádá, rozebírá samostatný článek. Kdo pod regulaci nespadá, žádnou zákonnou frekvenci testu nemá a řídí se rizikem, jak popisuje zbytek tohoto textu.