Penetrační testování

 Je to již delší dobu, naposledy v roce 2014, kdy se v DSM objevil článek na téma penetračních testů, přinášíme proto po letech rekapitulaci. Je dobře známo, že zabezpečení informací je nutností, a proto je na místě otázka: „Dokážeme odstranit zranitelnosti systému, aniž bychom o nich vůbec věděli?“ Odpovědí na tuto otázku je provedení penetračního testu.

Část I.

 penetrační testy        IT bezpečnost      black-box testy           red-team          zranitelnosti         etický hacking

 Penetrační test

Jedná se o techniku ověřování zabezpečení, která se snaží o nalezení a demonstraci praktického zneužití bezpečnostních nedostatků v systému s cílem zlepšit nebo prokázat kvalitu zabezpečení. To obvykle zahrnuje nasazení „etických hackerů“, kteří používají postupy reálných útočníků k nalezení a následné dokumentaci těchto zranitelností. Penetrační testy lze provádět na různých systémech a platformách od webových a mobilních aplikací přes infrastrukturu a specializovaná zařízení po API. 

Motivace

Napříč odvětvími, ve kterých jsou penetrační testy pravidelně prováděny, existuje mnoho sdílených motivací. Nejzjevnější motivací, která představuje základní kámen penetračních testů, je zvýšení bezpečnosti. Provedení penetračního testu umožňuje odhalení zranitelností, demonstraci jejich zneužití a následné zdokumentování. Dokumentace zranitelností pak poskytuje podklad pro provedení změn v systému vedoucích k odstranění zranitelností. Mnoho společností vyvíjejících softwarové produkty navíc díky aktivní komunikaci o provádění penetračních testů zvyšuje důvěru zákazníků v jejich zabezpečení. Ověření bezpečnosti tímto způsobem zaručuje transparentnost a zvyšuje pocit jistoty, který je obtížné získat. Nejčastější motivací pro penetrační test je zajištění souladu s vnitřními či vnějšími směrnicemi, vyhnutí se pokutám a dodržování zákonů i regulací.

Přístupy k penetračnímu testování

Přístup může mít několik různých forem. U větších společností vznikají interní týmy zabývající se penetračním testováním. To umožňuje průběžné ověřování bezpečnosti s hlubokou znalostí testovaných systémů a jejich funkcí. Bohužel tento přístup často postrádá invenci v postupech testování, což může vést k opomenutí některých zranitelností. Alternativou je nezávislý test externím subjektem. Tento přístup je často používán, umožňuje „čerstvý“ přístup k testovaným systémům a poskytuje vyšší míru jistoty zavedením vnější, nezávislé kontroly. Výběr dodavatele penetračního testování Proces hledání a výběru nezávislé třetí strany pro provedení testu je stejně důležitý jako samotný test. Typická pro odvětví založená na znalostech je jistá závislost výsledků na osobnosti testera i specifikách společnosti. Z tohoto důvodu je důležité pečlivě zvážit a vybrat tu správnou společnost. Při jejím výběru je vždy dobré požádat o reference od jiných organizací, pro které testy realizovala.

Kromě referencí mohou prokázat schopnosti penetračního testování také osvědčení. Certifikace osvědčující pokročilé znalosti penetračního testování zahrnují např. Offensive Security Certified Professional (OSCP), Offensive Security Certified Expert (OSCE), Certified Expert Penetration Tester (CEPT) a Licensed Penetration Tester (LPT). Je důležité nezapomenout, že ne všechna osvědčení jsou zcela rovnocenná a jenom u několika pokročilejších je úroveň kvalifikace a schopností prokazována i praktickou zkouškou. Dalším užitečným faktorem pro výběr firmy pro penetrační testy jsou informace uvedené v její nabídce. Důkladné přečtení každé předložené nabídky, seznámení se s procesem, kterým budou testy prováděny, použité standardy i prozkoumání vzorové zprávy můžou nastavit očekávání o hloubce informací a výsledku, který lze očekávat na konci testu.

Metodiky penetračního testování

V závislosti na systému lze pro testování použít různé standardy. Poskytují odborově přijatelný checklist, proti kterému lze testovat. Existují obecné standardy pro penetrační testování, jako je „Open Source Security Testing Methodology Manual“ (OSSTMM), „Penetration Testing Execution Standard“ (PTES), i systémově specifické standardy, jako je „OWASP Application Security Verification Standard Version 4“ (ASVS v4) pro webové aplikace a „OWASP Mobile Security testing guide“ pro mobilní aplikace. Některé jsou populárnější než jiné, ale existují i společnosti, které využívají vlastní standardy a/nebo procesy. Stanovení správného standardu do značné míry závisí na testovaném systému, požadované hloubce testování a preferencích zadavatele testu. V průběhu času jsou vydávány nové verze standardů zahrnující nová technologická rizika a zranitelnosti.

Webové aplikace

Otevřené konsorcium OWASP, zabývající se definicí standardů pro penetrační testování mobilních a webových aplikací, nabízí různé pohledy na testování. Např. OWASP Testing Guide Version 4 (OTG v4) zkoumá obecnou úroveň bezpečnostních rizik aplikace, a to buď hledáním nejběžnějších „top 10“ zranitelností, či testováním úplného seznamu známých bezpečnostních zranitelností pro důkladnější kontrolu. OWASP Application Security Verification Standard Version 4 (ASVS v4) se více zaměřuje na hodnotu chráněných aktiv, a proto nabízí tři úrovně testování tak, aby odpovídaly úrovni hrozeb.

Mobilní aplikace

OWASP podobně poskytuje několik variací standardů pro testování mobilních aplikací. „Mobile Security Testing Guide“, „Top 10 Mobile Controls“ a „Mobile Application Verification Security Standard“ se mohou lišit v hloubce a v konkrétních testech, ale obecně jsou metodiky podobné. Rozhodnutí o ideálním standardu, který lze použít pro testování, vyžaduje důkladné pochopení aplikace a potenciálních dopadů bezpečnostních rizik na uživatele i systém jako celek. Z tohoto důvodu se během testu obvykle klade důraz na pochopení funkce aplikace, její kontext a roli v systému. Vybraný OWASP standard pak poskytne odpovídající požadavky na ověření aplikace na mobilním zařízení a také zabezpečení na straně serveru.

Infrastruktura

Při penetračním testu infrastruktury je obvykle kladen důraz na oprávnění, přístupová práva a segmentaci sítě. Tyto faktory mohou často vést k nezamýšleným zranitelnostem a snadnému získání přístupu útočníka k síti. Tyto testy lze provést na veřejně dostupné infrastruktuře, vnitřní infrastruktuře a cloudové infrastruktuře. Tester se řídí obecným cyklem penetračního testování zahrnujícím shromažďování informací, návrh a provedení vektorů útoků, eskalací oprávnění a laterálním pohybem v síti.

Sociální inženýrství

Je třeba zmínit, že jedním z nejčastějších způsobů, jak může útočník získat přístup do systému, je sociální inženýrství. Firmy můžou provést testy sociálního inženýrství za účelem otestování i tréninku pracovníků, kteří mají přístup k citlivým datům. Tyto testy se běžně provádějí jako phishingové kampaně, které se pokoušejí zaměstnance přelstít za použití smyšleného scénáře, aby je nalákali k instalaci malwaru, ransomwaru, vyzrazení přihlašovacích údajů či jiných informací. V rámci společnosti může phishingová kampaň sloužit jako trénink a zvýšit povědomí o těchto typech útoků.

Hloubka testování

O hloubce testování a prostředcích investovaných do testů by se mělo rozhodnout realistickým pohledem na citlivost aktiv, hodnotu informací a potenciální dopady narušení bezpečnosti. Obvykle jsou tyto aspekty úměrné motivaci potenciálních útočníků k napadení systému. Tyto motivace určují množství úsilí, zdrojů a investic, které bude útočník ochoten vynaložit. V ideálním případě by úsilí na ochranu aktiv mělo být v rovnováze s mírou rizik spojených s daným aktivem. Při určování úrovně motivace útočníka je potřebné zvážit kromě finančních zisků i druh informací, politickou motivaci, tzv. hacktivizmus a rozsah dopadů útoku. Např. státní složky cílící na informace nejvyššího stupně utajení mají jinou motivaci než útočník na online platformu elektronického obchodu usilující o finanční zisk či reputaci. I když je motivace pro kybernetický útok dostatečná v obou případech, úroveň ochrany před těmito útoky se bude lišit. Znalost této motivace a míry rizika může pomoci určit hloubku a úsilí, které by mělo být vynaloženo na penetrační testování. Organizace by měly vždy nechat své systémy otestovat ve stejné hloubce, ne-li ve větší, jakou by použil útočník při útoku.

Black-box a White-box testy

Dalším faktorem, který je potřeba vzít v úvahu při provádění penetračního testu, je úroveň informací, které bude mít tester při zahájení. Přístupem nejvíce odpovídajícím realitě je tzv. Black-box test. V tomto případě má tester pouze základní informace o rozsahu testu. Tester se spoléhá pouze na informace, které získá sám. To může představovat určitou nevýhodu v tom, že některé oblasti systému nemusejí být otestovány, pokud tester nezíská dostatek informací k jejich uchopení.

Tzv. White-box test může naopak poskytnout komplexnější pohled na zabezpečení systému. Tento typ testu poskytne testerovi konkrétnější cíle a systémové informace, jako je např. zdrojový kód nebo privilegovaný přístup k testovanému systému. Tester tak předem zná a může pokrýt celý rozsah systému a nevychází pouze z informací, které získá během samotného testování.

Proces penetračního testování

Bez ohledu na rozsah poskytnutých informací probíhá penetrační test jako sled kroků popsaných níže. Zpočátku se tester pokusí získat co nejvíce informací o testovaném systému. Tato část testu může být podpořena automatizovanými nástroji a skeny, ale neobejde se bez tvůrčího vhledu testera. Ten používá několik běžných nástrojů s různými funkcemi od přelomení hesel přes scanování portů až po vyhledávání běžných zranitelností. Každý z nich poskytuje testerovi částkové informace, které mu pomáhají porozumět danému systému. Tester získává v průběhu testu více informací a dozvídá se o možných rizicích, která by se potenciálně mohla proměnit v zranitelnosti – samostatně nebo v kombinaci s jinými riziky. Aby tester potvrdil, zda existuje nějaká zranitelnost systému, v dalším kroku na základě získaných informací navrhne vektor útoku a pokusí se jej provést. Potvrdí-li se existence zranitelnosti, pokusí se ji tester využít k získání dalších informací či eskalaci privilegii a celý proces dále pokračuje v rozšířeném rozsahu. S každou novou informací či dodatečnými oprávněními bude tester navrhovat další vektory útoku, odhalovat nové zranitelnosti a postupovat hlouběji systémem, bude-li to možné. Každá zranitelnost a její dopad budou v průběhu procesu zaznamenány tak, aby je bylo možno replikovat a ověřit.

Hodnocení závažnosti zranitelností

Zranitelnosti jsou ohodnoceny na základě oborových standardů, např. Common Vulnerability Scoring System (CVSS), který každé zranitelnosti přidělí číselné skóre. To je určeno na základě zneužitelnosti a dopadu zranitelnosti. Bere v úvahu mnohé faktory: pozice útočníka vůči napadenému systému (např. spojení přes internet nebo nevyhnutelnost fyzického přístupu), kolik faktorů je mimo kontrolu útočníků (do jaké míry je útok deterministický), úroveň oprávnění potřebných k útoku, zda je vyžadována interakce uživatele, dopad zranitelnosti na jiné systémy, dopad na důvěrnost informací, vliv na integritu a přístupnost informací. Tester v rámci penetračního testu přiřadí zranitelnosti CVSS skóre z tzv. Base Metric Group (BMG), organizace sama jej může pomocí Temporal Metric Group (TMG) a Environmental Metric Group (EMG) dále rozšířit a přesněji posoudit dopad zranitelnosti na specifické prostředí s ohledem na další systémové podmínky a procesy, které tester obvykle nezná.

Kombinací všech tří skupin lze získat nejkomplexnější ohodnocení míry rizik, byť posouzení TMG a EMG není obvyklé. Např. útok, který lze provést vzdáleně, s nejnižší úrovní oprávnění a který může výrazně ovlivnit integritu, důvěrnost nebo dostupnost dat, by byl vyhodnocen jako závažnější než útok vyžadující lokální provedení s vysokou úrovní oprávnění a umožnil by přístup k informacím pouze „pro čtení“. Existují i jiné standardy pro ohodnocení zranitelností a některé společnosti se dokonce rozhodnou vytvořit a užívat svůj vlastní standard. Většina zpráv o penetračních testech bude obsahovat seznam zranitelností a technické informace o nich. Výstupy mohou navíc zahrnovat i návrhy, jak zranitelnost odstranit/zmírnit, není to ale pravidlem.

Penetrační testy a scan zranitelností

Rozdíl mezi penetračním testem a skenem zranitelností (Vulnerability Scan) není vždy úplně jasný. Skener zranitelností je automatizovaný nástroj, který lze použít k nalezení známých zranitelností balíkového softwaru. Je schopen najít zjevná rizika zabezpečení typicky plynoucí z chybějících záplat daného softwaru či konfigurace. Na rozdíl od penetračního testu sken zranitelností nenalezne jedinečné nebo veřejně neznámé zranitelnosti, nedokáže kombinovat informace a rizika s cílem najít méně zjevné zranitelnosti nebo komplexně otestovat na míru vytvořené aplikace či hledat logické chyby.

Lidská tvořivost, která je součástí penetračního testu, se pohybuje daleko za hranicí skenu zranitelností. Zdánlivě nedůležitá či zanedbatelná zranitelnost se díky kreativitě zkušeného etického hackera může přetavit v zásadní zranitelnost systému. Sken zranitelností jednoduše nedokáže poskytnout takovou úroveň testování zabezpečení, jakou zajistí dobře provedený penetrační test. Pro penetrační testery může být vyhledávání zranitelností použito jako výchozí bod k nalezení zjevných vstupních míst. Avšak vždy to bude pouze začátek testování systému. Skenování zranitelností je skvělým způsobem monitorování systémů a poskytuje základní ochranu před známými zranitelnostmi v období mezi jednotlivými penetračními testy.

Red-teaming

Další mylnou představou je, že penetrační test je shodný s tzv. red team cvičením. Je pravdou, že některé metody penetračního testování můžou být použity i v „red team“ cvičení, avšak hlavním rozdílem je spolupráce s „blue team“ (obvykle odpovídá SOC) a „purple team“ (specifická koordinační role). Toto cvičení se primárně používá k testování a školení detekce a reakce na útok ve smyslu jeho aktivního zastavení, zatímco penetrační testy se zaměřují na preventivní odhalování systémových zranitelností. Scénáře útoků jsou navrženy a prováděny „red teamem“, „blue team“ by měl na útoky reagovat jako na realistický scénář. Tato interakce je řízena „purple teamem“, který slouží jako spojka mezi stranami a určuje, zda byla přijata náležitá opatření a zda by se scénáře měly pro další výcvik opakovat. Tato cvičení jistě odhalí i zranitelnosti systému – primárně se zaměřují na detekci, reakci a zastavení útoku. Mnoho zranitelných míst nebude v průběhu cvičení objeveno a „red team“ cvičení by nemělo nahradit pravidelný penetrační test.

Frekvence provádění penetračních testů

Penetrační testování by mělo být provedeno pokaždé, když dojde k uvolnění nové verze systému nebo jeho významné změně, případně v časové periodě nejvíce jednoho roku, nenastanou-li předchozí spouštěče. Díky pokroku v technologiích a neustálému vývoji nových taktik útoků nelze tvrdit, že systém, který byl jednou otestován a považován za bezpečný, bude bezpečný napořád.

S postupnou digitalizací našich životů bude penetrační testování čím dál důležitější a v ideálním případě se stane standardem pro každý IT produkt. Vyvážený přístup k zabezpečení a životnímu cyklu softwaru bude působit jako jedna ze zbraní, kterými je možné zabezpečit systém a chránit se před útočníky i v budoucnosti. Další informace o tomto tématu najdete v budoucích článcích tohoto seriálu. Další části se zaměří na podrobnosti o penetračním testování, metodách a výsledcích v reálném životě.