Šablona poptávky penetračního testu, na kterou dostanete porovnatelné nabídky
Typické zadání zní takhle: „Hledáme dodavatele pro penetrační testy naší webové aplikace. Cílem je otestovat zabezpečení, identifikovat zranitelnosti a získat výstup pro interní audit a vedení.“
Je to správný záměr. Problém je, že na takové zadání dostanete tři nabídky, které se liší o polovinu a nedají se porovnat – protože si každý dodavatel domyslel jiný rozsah. Jeden nacení dvoudenní automatizovaný sken, druhý dvoutýdenní manuální test s retestem. Obě nabídky formálně odpovídají na to, co jste napsali.
Níže je šablona, kterou si můžete okopírovat a doplnit. Není v ní nic, co byste museli řešit s právníkem – je to osm bodů, které z nabídek udělají čísla, jež jdou položit vedle sebe.
Proč obecné zadání nefunguje
Cena penetračního testu se počítá v člověkodnech. Kolik jich bude, určuje rozsah a hloubka – ne velikost vaší firmy a ne to, jak naléhavě test potřebujete. Dokud v zadání nestojí, co se testuje a jak hluboko, dodavatel musí odhadovat, a každý odhaduje jinak.
Tři nejčastější místa, kde se nabídky rozejdou:
- Počet uživatelských rolí. Aplikace se třemi rolemi znamená tři průchody testem autorizace, ne jeden. Bývá to největší jednotlivá položka rozdílu.
- Podíl manuální práce. Automatizovaný sken najde známé zranitelnosti. Chyby v business logice – obejití platby, přístup k cizí objednávce, eskalace oprávnění – najde jen člověk. Když to v zadání nestojí, levnější nabídka bude skenem.
- Co je výstup. „Report“ může být export ze skeneru i dokument s manažerským shrnutím, reprodukovatelnými postupy a hodnocením rizik. Vy potřebujete to druhé, protože to jde předložit auditorovi.
Šablona poptávky: osm bodů
1. Kdo poptává
Název společnosti, IČO, kontaktní osoba pro technickou část a kontaktní osoba pro obchodní část, telefon. Zní to samozřejmě, ale technický scoping hovor se nedá vést s nákupem a cenu neschválí vývojář.
2. Co se má testovat
- Adresa produkční aplikace a adresa testovacího prostředí
- Typ: klasická webová aplikace, SPA, veřejné API, mobilní backend, nebo kombinace
- Počet uživatelských rolí a jestli dodáte testovací účty pro každou z nich
- Klíčové funkce a integrace, na kterých vám záleží nejvíc (platby, export dat, správa uživatelů)
- Přibližný počet obrazovek nebo endpointů
3. Prostředí a omezení
- Testuje se na produkci, nebo na kopii? Pokud na produkci, v jakém časovém okně
- Bude po dobu testu WAF a rate limiting obejit whitelistem? Bez toho testujete WAF, ne aplikaci
- Existují data nebo funkce, kterých se test nesmí dotknout (odesílání e-mailů zákazníkům, platební brána v ostrém režimu)
4. Hloubka a metodika
- Black box, grey box, nebo white box – a proč. Nejčastější volba je grey box, tedy tester dostane účty a základní popis
- Požadovaná metodika: OWASP WSTG, OWASP ASVS a v jaké úrovni, případně NIST SP 800-115
- Požadovaný podíl manuálního testování. Napište to výslovně
5. Výstup
Tady se rozhoduje, jestli z testu budete mít užitek i za rok:
- Manažerské shrnutí pro vedení a samostatná technická část pro vývoj
- Jazyk zprávy
- Hodnocení rizik podle CVSS
- U každého nálezu reprodukovatelný postup a důkaz (Proof-of-Concept)
- Prezentace výsledků vývojovému týmu
- Potvrzení o provedení testu použitelné pro interní audit
6. Retest
Je retest v ceně, nebo se doúčtovává? Do kdy ho lze uplatnit? Bez retestu máte zdokumentovaný problém místo zdokumentovaného řešení – a auditorovi ukážete nález, ne jeho odstranění.
7. Formality
- NDA
- Pojištění odpovědnosti dodavatele
- Certifikace konkrétních testerů, kteří test provedou (OSCP, OSWE, CISSP)
- Kde a jak dlouho budou uložena data z testu a kdy budou smazána
- Požadovaný termín zahájení a dodání zprávy
8. Kritéria hodnocení
Napište je do poptávky. Dodavatel pak ví, na čem záleží, a vy máte podle čeho rozhodnout:
- Cena v člověkodnech, ne paušálem za „test aplikace“
- Podíl manuální práce
- Retest v ceně
- Ukázka anonymizované zprávy dodaná před rozhodnutím
- Jmenovitě uvedení testeři a jejich certifikace
Jak porovnat tři nabídky
Až nabídky dorazí, převeďte je na jedno číslo: cena za člověkoden. Pak se podívejte, kolik člověkodnů kdo nabízí. Pokud jeden dodavatel nabízí polovinu, zeptejte se, co v jeho rozsahu není – obvykle je to podíl manuálního testování nebo počet otestovaných rolí.
Nabídka bez uvedeného počtu člověkodnů se s ničím porovnat nedá. Je to legitimní důvod poslat ji zpět s dotazem.
A poslední věc: pokud vám dodavatel nabídne, že vám nálezy rovnou i opraví, zvažte to. Testování a náprava u stejného dodavatele odstraňuje nezávislost výstupu, což je přesně ta vlastnost, kvůli které auditor zprávu uzná.
Chcete zadání zkontrolovat, než ho rozešlete?
Pošlete nám ho na kontaktní formulář nebo na info@haxoris.com. Do dvou pracovních dnů vám zdarma napíšeme, co v zadání chybí a kde by si dodavatelé domysleli něco jiného, než myslíte. Nabídku od nás dostanete jen tehdy, když si o ni řeknete.
