Penetrační test začíná dávno před prvním odeslaným požadavkem. Kvalita výsledku závisí na tom, jak jasně je vymezený cíl, rozsah a pravidla. Když tyto otázky zůstanou otevřené, test se zdrží, část času padne na vyjasňování a výsledky se hůř porovnávají s očekáváním.
Následující přehled vychází z naší praxe a z veřejných rámců. Například publikace NIST SP 800-115 věnuje plánování testu samostatnou kapitolu a obsahuje i vzor pravidel testu. Neberte přehled jako úplný seznam. Každé prostředí má svá specifika.
Začněte cílem a rozsahem
Nejdřív si ujasněte, proč test děláte. Jiný přístup vyžaduje kontrola nové aplikace před spuštěním, jiný ověření externí infrastruktury a jiný požadavek zákazníka nebo auditora. Cíl určuje, co testovat, jak do hloubky a jakou formu má mít výstup.
Při vymezení rozsahu pomohou odpovědi na tyto otázky:
- Které systémy, aplikace, API nebo rozsahy adres jsou předmětem testu?
- Co do rozsahu výslovně nepatří, například systémy třetích stran nebo sdílený hosting?
- Testujeme produkci, nebo testovací prostředí, které jí věrně odpovídá?
- Jaké uživatelské role aplikace má a které z nich chcete ověřit?
- Jde o pohled zvenku, zevnitř sítě, nebo o obojí?
Pozor na služby, které nevlastníte. Cloudové platformy, SaaS aplikace nebo hosting mají vlastní pravidla pro bezpečnostní testování. Před testem ověřte, co poskytovatel dovoluje, a případně si vyžádejte jeho souhlas.
Autorizace a pravidla testu
Bez písemné autorizace se penetrační test nemá zahájit. Podepsat ji má ten, kdo má k testovaným systémům skutečné oprávnění. U systémů provozovaných dodavatelem to často znamená zapojit i jeho.
Na autorizaci navazují pravidla testu, anglicky Rules of Engagement. Popisují, jak bude test probíhat a co je povolené. Obvykle obsahují:
- časová okna testu a případná omezení, třeba mimo účetní uzávěrku,
- povolené a zakázané techniky, například zátěžové testy nebo sociální inženýrství,
- zdrojové IP adresy testerů, aby je váš tým poznal v záznamech,
- postup při nálezu kritické zranitelnosti a jak rychle ho hlásit,
- podmínky, za kterých se test okamžitě zastaví,
- zacházení s daty, ke kterým se tester během testu dostane.
Rozhodněte také, zda o testu bude vědět váš provozní nebo bezpečnostní tým. Ohlášený test omezí falešné poplachy. Neohlášený zase ukáže, jak tým reaguje. Obě varianty mají smysl, jen je potřeba je dohodnout předem.
Testovací účty, data a kontakty
U aplikací a API bývá častým zdržením chybějící přístup. Připravte testovací účty pro každou roli, kterou chcete ověřit. Pro testy autorizace jsou potřeba alespoň dva účty se stejnou rolí, ideálně v různých organizacích nebo tenantech. Jen tak lze ověřit, že uživatel nevidí cizí data.
Do testovacího prostředí patří realistická, ale ne skutečná data. Pokud testujete produkci, domluvte, se kterými záznamy se smí pracovat. Přihlašovací údaje předávejte bezpečnou cestou, nikdy ne v běžném e-mailu spolu s adresou systému.
Zkontrolujte také technické detaily:
- Ověřte, že testovací prostředí funguje a obsahuje aktuální verzi.
- Domluvte, zda mají být adresy testerů povolené ve WAF nebo jiných ochranách. Záleží na cíli testu.
- U mobilních aplikací připravte instalační balíček a přístup k testovacímu backendu.
- U API dodejte dokumentaci, například specifikaci OpenAPI, nebo sadu ukázkových požadavků.
- Zálohujte data, pokud test probíhá v prostředí s důležitým obsahem.
Kontakty a komunikace během testu
Na obou stranách určete kontaktní osoby. Na vaší straně potřebujete někoho, kdo rozumí testovaným systémům a může rychle rozhodnout. Pro případ potíží se hodí i náhradní kontakt a dohodnutý komunikační kanál.
Předem si řekněte, jak se budete informovat o průběhu. U kratších testů stačí úvodní a závěrečná schůzka. U delších se hodí průběžné krátké zprávy. Kritický nález nemusí čekat na závěrečný report, pokud se tak dohodnete.
Co od testu nečekat
Penetrační test je omezený časem a rozsahem. Snižuje nejistotu, ale nemůže dokázat, že v prostředí nejsou žádné další zranitelnosti. Nenahrazuje pravidelné aktualizace, monitoring ani bezpečný vývoj. Výsledkem není certifikát, ale doložený popis toho, co tester v dohodnutých podmínkách ověřil a co našel.
Test sám také neřeší nápravu. Report popíše nálezy, jejich dopad a doporučení. Opravy pak provádí váš tým nebo dodavatel. Retest, tedy ověření oprav, bývá samostatnou částí nabídky.
Kontrolní seznam před testem
- Cíl testu a očekávaná forma výstupu jsou zapsané.
- Rozsah obsahuje seznam cílů i výslovné výjimky.
- Autorizaci podepsal oprávněný vlastník systémů, případně i poskytovatel služby.
- Pravidla testu obsahují časová okna, zakázané techniky a postup zastavení.
- Testovací účty existují pro všechny role, včetně dvou účtů se stejnou rolí.
- Testovací prostředí funguje a data jsou připravená.
- Kontakty, náhradní kontakty a komunikační kanál jsou domluvené.
- Je jasné, zda o testu ví provozní tým.
Pokud test plánujete a nejste si jisti rozsahem nebo pravidly, můžeme je projít společně. Více o průběhu najdete na stránce Penetrační testy. Domluvte si konzultaci a probereme, co má smysl pro vaše prostředí.
