Penetrační testování jako součást životního cyklu vývoje SW
Penetrační testy teď nabízí kde kdo, jak ale poznat, kdo je opravdu umí provést a kdo na nich chce jen vydělat?
První, co vám mohu doporučit, prověřte si danou firmu a uvedené reference. Určitě kontaktujte osobu, která je v referencích uvedena a zeptejte se jí, jak byla s prací dané firmy spokojena, a co přesně bylo předmětem dodávky. Uvědomte si, že analýza rizik (risk analyses), prověrka konfigurace (configuration review) nebo skenování zranitelností (vulnerability scan) je něco jiného než penetrační testování nebo chcete-li ethical hacking.
Poznámka: Ethical hacker by měl být schopen dokázat přítomnost určitých zranitelností i ručně, tj. bez použití automatizovaných nástrojů. Tím nejenže prokazuje, že své práci skutečně rozumí, ale je tímto způsobem kolikrát i schopen objevit zranitelnosti, které automatizované nástroje nejsou schopny detekovat.
Mimochodem, co si dát do smlouvy s firmou, která pro vás vyvíjí nějakou webovou aplikaci, klauzuli, že v případě, že dodané dílo bude obsahovat některou ze známých zranitelností, tak daná společnost bude povinna nalezené zranitelnosti bezplatně a bezodkladně opravit a zaplatit navíc pokutu, jejíž výše bude přibližně odpovídat ceně za provedení penetračního testu dané aplikace. Tato klauzule ve smlouvě by mohla donutit firmy a jejich vývojáře, aby vyvíjeli kvalitně. Koneckonců mělo by to být v jejich zájmu, protože čím později bude chyba nalezena, tím bude její odstranění finančně náročnější.
Je samozřejmě otázka, k čemu by taková klauzule ve smlouvě v praxi vedla, zda by se třeba výše pokuty nepromítla do koncové ceny díla účtované zákazníkovi firmou vyvíjející danou webovou aplikaci. Ale nemuselo by tomu tak být, neboť jak jsme si již uvedli výše, čím dříve bude daná chyba odhalena, tím budou náklady na její odstranění nižší. A jestliže firma, která aplikaci vyvíjí, nevěří, že její kód bude prost chyb a bude obsahovat nějakou známou zranitelnost, může si nechat svou aplikaci penetračně otestovat ještě před tím, než ji předá svému zákazníkovi. Takovýto přístup by měl také něco do sebe.
Mohlo by to fungovat i tak, že firma by vám spolu s aplikací, kterou pro vás vyvinula, předala i výsledky penetračních testů, které pro ni provedla jiná společnost, a vy byste si případně mohli nechat danou aplikaci znovu otestovat, a jedno u koho. A podobnou klauzuli byste si mohli dát i do smlouvy s firmou, která pro vás bude penetrační testy provádět. Klauzule se může nést v duchu „Jestliže se prokáže, že námi testovaná verze aplikace obsahovala v dané době odhalitelnou a známou zranitelnost, vyplatíme klientovi zpět stejnou částku, kterou nám za provedení penetračního testu zaplatil.“
Důležité je samozřejmě uvést, které jsou to ty nejznámější zranitelnosti. Byť se jedná již po řadu let o ty samé, je nutné nejznámější zranitelnosti vyjmenovat, a tak se vyhnout případným sporům, které by mohli skončit i u soudu. To, že je daná zranitelnost známá, ale samo o sobě nestačí, zranitelnost musí být i odhalitelná, to znamená, že pokud by např. zranitelnost SQL injection byla obsažena ve formuláři na stránce, na kterou se nedá dostat jinak, než zadáním nějakého obskurního URL, tak tester nemá možnost tuto stránku za běžných podmínek objevit. A vězte, že občas někoho napadne si tímto způsobem testera vyzkoušet. Že se jedná o zkoušku nesmyslnou, snad ani není potřeba dodávat.
Další problematický bod může být dokazování, zda aplikace v dané době obsahovala danou zranitelnosti či nikoliv. To, kdy byl test proveden, je naprosto zásadní, protože daná zranitelnost se mohla objevit až v nové verzi aplikace nebo může souviset se změnou konfigurace nebo s upgradem systému. To by se dalo teoreticky vyřešit tak, že by se pořídila kopie dané verze aplikace, spočetl by se pro ni hash a ten by obě strany podepsaly.
Bohužel v praxi není tento postup zatím běžný, nicméně můžete se pokusit klauzuli naformulovat tak, že firma za penetrační test dostane zaplaceno jen v případě, že odhalí nějakou prakticky zneužitelnou zranitelnost. Tím by měla být firma, která bude penetrační testy provádět, dostatečně motivována k tomu, aby se opravdu snažila. Jestliže si teď říkáte, to zní dobře, ale do toho nikdo nepůjde, protože, když tam nic nenajdou, tak nedostanou zaplaceno. Ano, tato úvaha je teoreticky naprosto správná, ale realita je taková, že oni vždycky něco najdou, takže se nemusí bát, že by nemohli své lidi zaplatit. Kromě toho si mohou zvolit i ten předchozí business model.
Poznámka: Jestliže si myslíte, že výše uvedený business model nemůže fungovat, musím vás vyvést z omylu. On již funguje, přesvědčit se můžete sami, stačí, když navštívíte stránky společnosti Nethemba.
Na tomto místě bych chtěl také zdůraznit, že odhalením jedné vážné zranitelnosti penetrační testování ze strany společnosti, která se penetračním testováním zabývá a poskytuje ho jako službu, rozhodně nekončí, protože si nemůže dovolit nechat nejznámější zranitelnosti bez povšimnutí, taková společnost by totiž na trhu velice rychle skončila. To je ostatně krásný rozdíl mezi hackerem a ethical hackerem, neboť zatímco hackerovi stačí najít jakoukoliv zranitelnost a té zneužít, tak ethical hacker se musí snažit najít minimálně všechny známé zranitelnosti, které daná aplikace obsahuje a navíc v omezeném čase a často bez použití dalších technik jako je mezi hackery tolik oblíbené sociální inženýrství.
ČERMÁK, Miroslav, 2012. Penetrační testování jako součást životního cyklu vývoje SW. Online. Clever and Smart. ISSN 2694-9830. Dostupné z: https://www.cleverandsmart.cz/penetracni-testovani-jako-soucast-zivotniho-cyklu-vyvoje-sw/. [citováno 07.12.2024].
Štítky: ethical hacking
K článku “Penetrační testování jako součást životního cyklu vývoje SW” se zde nachází 1 komentář.
Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.
Pěkný článek, jako obvykle, nicméně pár připomínek.
„Tato klauzule ve smlouvě by mohla donutit firmy a jejich vývojáře, aby vyvíjeli kvalitně. Koneckonců mělo by to být v jejich zájmu, protože čím později bude chyba nalezena, tím bude její odstranění finančně náročnější.“
To je dobrý vtip, velké vývojářské firmy mají často takovou pozici, že si všechny změny řídí pomocí placených change requestů, včetně opravy bezpečnostních chyb. Prosadit do smluv klauzule o penetračním testu je složité, i když se blýská na lepší časy. Těžká je definice bezpečnostní chyby, její závažnosti a zneužitelnosti. Pokud bude tester dokázat její zneužitelnost, spotřebuje na to 3x tolik času. Navíc existuje požadavek na nalezení všech významných chyb (požadavek jít do šířky, ne do hloubky). Při stálém tlaku na cenu je složité toto vše zajistit.
A poznámka o manuálním testování je též legrační. Dobrý tester samozřejmě manálně testovat umí, ale větší aplikace prostě nemůže tímto způsobem stihnout za dobu, kterou jsou zákazníci ochotni zaplatit. Takže se motáme v kruhu.
Článek je tak hezky akademický, souhrnný a reklamní, ale realita je zatím ještě trošičku jinde.