Příprava na penetrační test: co si připravit a co dodat testerovi

Ještě než napíšete poptávku a vyberete dodavatele testu, vyplatí se rozhodnout tři věci: co je v rozsahu a co ne, co chcete testem ověřit, a kolik toho tester dostane dopředu vědět. Tohle trojí určuje cenu i délku a mění se hůř, když už zakázka běží; samotný pojem, tedy definici a průběh testu bez nabídky, drží slovník.

Rozsah je seznam toho, co se testuje, a stejně důležitý je jeho opak: co je mimo. Vyjmenujte domény, IP rozsahy a aplikace, které do testu patří, a zvlášť ty, na které se sahat nesmí, typicky systémy třetí strany nebo produkce, kterou nesnese výpadek. Cíl testu je druhá věc: jestli chcete prověřit jednu aplikaci před nasazením, nebo zjistit, kam se útočník dostane z běžné stanice.

Třetí rozhodnutí je, kolik toho tester ví předem: od nuly přes účty a dokumentaci až po přístup ke zdrojovému kódu. Rozdíl mění, kolik času padne na průzkum a kolik na hledání chyb, a rozebírá ho heslo o tom, kolik znalostí testerovi dát (black, grey, white box). Co samotný test pak obnáší, drží stránka o penetračním testování.

Tady vzniká zdržení nejsnáz. Přístupy připravte před zahájením, ne až první den, protože dokud tester nemá účet nebo konektivitu, nemůže testovat a jen čeká. Konkrétně jde o pět věcí.

• Testovací účet pro každou uživatelskou roli, kterou aplikace zná. Největší nálezy vznikají mezi rolemi, takže samotný účet běžného uživatele nestačí.
• Konektivita do prostředí: VPN nebo dedikovaný přístup do interní sítě u interního testu, u externího jen potvrzení, které adresy jsou vaše.
• Allowlisting zdrojových IP testera tam, kde by ho jinak zablokoval firewall nebo rate limiting a test by měřil jen obcházení ochrany.
• Domluvené výjimky ve WAF nebo EDR podle scénáře, ať se čas neutratí na obcházení filtru místo na hledání chyb v aplikaci.
• Kontakt na člověka, který umí účet nebo přístup rychle opravit, když během testu přestane fungovat.

Jestli se výjimky ve WAF a EDR dělají, závisí na tom, co chcete měřit. To rozvádí sekce níž a odpovídá na to zvlášť.

Dva dokumenty jsou tvrdá podmínka: písemné pověření k testu od někoho, kdo ho může dát, a NDA. Bez pověření se nezačíná, protože bez něj by šlo o neoprávněný přístup, ne o test. Zbytek jsou pravidla zapojení, která se dohodnou předem, aby se během testu nemuselo improvizovat.

• Kontaktní osoby na obou stranách, dostupné po celou dobu testu, ne jen v pracovní době.
• Časové okno: kdy se testovat smí a kdy ne, zvlášť u systémů, které nesnesou zátěž během provozu.
• Eskalační postup: komu a jak rychle voláme, když najdeme aktivně zneužitelnou cestu dovnitř nebo když se něco rozbije.
• Pravidla pro rizikové techniky: co je zakázané úplně, u čeho se před provedením volá, a jestli se smí testovat i sociální inženýrství.

U webové aplikace nebo API rozhoduje příprava účtů a dat. Připravte účet pro každou roli, testovací data, která se blíží produkci, a krátký popis business logiky, tedy k čemu aplikace slouží a co v ní nemá jít udělat. Podrobněji to shrnuje příprava pro test webové aplikace.

U interní infrastruktury a Active Directory jde hlavně o přístup a rozsah. Tester potřebuje cestu do sítě, běžný doménový účet jako výchozí bod a seznam IP rozsahů, které jsou v hře. Co se u takového testu prověřuje, popisuje příprava pro test interní sítě.

U cloudu, konkrétně u AWS, připravte read-only přístup k účtu, seznam služeb, které se mají prověřit, a souhlas s pravidly poskytovatele pro testování. AWS má vlastní seznam toho, co se smí testovat bez schválení, a co testování v AWS obnáší, popisujeme přímo u služby.

U Wi-Fi rozhoduje přístup na místo a rozsah bezdrátu. Tester musí být v dosahu signálu, ať na místě, nebo připojený z okolí, takže připravte přístup na lokalitu, seznam SSID v rozsahu, kontakt na někoho, kdo síť zná, a okno, ve kterém smíme krátce rušit provoz deautentizací. Víc k tomu, co si nachystat před testem bezdrátové sítě, je na stránce testu Wi-Fi.

U mobilní aplikace rozhoduje build a testovací účty. Připravte instalační balíček, tedy APK u Androidu a IPA u iOS, nebo přístup k testovací verzi, k tomu účet pro každou roli a krátký popis funkcí. Když má aplikace vlastní backend, řekněte, na které servery se smí sahat. Celý seznam, tedy co mít připravené pro test mobilní aplikace, je součástí popisu služby.

U OT a ICS rozhoduje kooperace provozu a bezpečné okno. Připravte schéma sítě s rozdělením do zón, seznam hlavních zařízení a protokolů, kontakt na technika odpovědného za provoz, dostupného po celou dobu testu, a domluvené servisní okno pro aktivní kroky. Podrobnosti, včetně toho, co nachystat před testem OT prostředí, drží stránka testu OT a ICS.

Nejvíc hodnoty sebere zamlčený systém mimo rozsah, změna prostředí uprostřed testu, chybějící retest v zadání a testování na produkci bez zálohy. Každá z těch čtyř věcí buď zdrží start, nebo způsobí, že výsledek neplatí.

Zamlčený systém je zrádný tím, že ho útočník najde a test ne. Když v rozsahu chybí subdoména nebo aplikace, o které nikdo nevěděl, zůstane neotestovaná, i když je zvenčí dostupná. Změna prostředí během testu, tedy nasazení nové verze uprostřed práce, znehodnotí to, co už proběhlo. A bez domluveného retestu, tedy opakovaného ověření, že jsou nálezy opravdu opravené, doložíte jen to, co bylo rozbité, ne to, co je spravené.

Testování na produkci není zakázané, ale patří k němu záloha a okno mimo špičku. Otázku produkce versus testovací prostředí, tedy jestli testovat naostro, nebo ve stagingu a co ta volba mění, rozebírá stránka testu webových aplikací. Kde se rozhoduje, jak velká zakázka bude, najdete v ceníku.

Před zahájením potřebuje tester pět věcí: písemné pověření k testu, vymezený rozsah s tím, co je in scope a co ne, přístupy do prostředí, testovací účet pro každou roli a kontakt na člověka, který umí přístup rychle opravit. S tímhle se test rozjede první den, bez toho se čeká.

Záleží na typu testu a na počtu rolí a systémů v rozsahu. U jedné aplikace se dvěma rolemi je to otázka přípravy pár účtů a přístupu, u interní sítě přibývá zřízení konektivity a účtu v doméně. Nejvíc přípravu protáhne to, když se rozsah upřesňuje až po zahájení. Čím dřív je jasné, co je in scope, tím kratší je start.

Podle toho, co chcete měřit. Když má test prověřit i účinnost obrany, WAF a EDR zůstávají zapnuté, protože jsou součástí toho, co se hodnotí. Když chcete prověřit hlavně samotnou aplikaci, dá se zdrojová IP testera na WAF allowlistovat, aby se čas neutratil na obcházení filtru místo na hledání chyb. Rozhodnutí patří do pravidel zapojení a dělá se předem, ne až když test narazí na blok.

Jen u interního testu. Externí test perimetru pracuje s tím, co máte vystavené do internetu, takže mu stačí seznam domén a IP adres a přístup do sítě nepotřebuje. Interní test naopak začíná zevnitř, z pozice někoho, kdo už je v síti, takže mu připravíte konektivitu přes VPN nebo dedikovaný přístup a běžný účet jako výchozí bod.