Bezpečnost komunikačních sítí, systémů, aplikací, a hlavně informací, které systémy obsahují, se stala v posledních letech silně vnímanou částí IT. K tomu, abychom měli informace o slabých místech systémů a mohli vyhodnotit rizika, je vhodné si vše otestovat. Pod pojmem „otestovat“ si můžeme představit poměrně širokou škálu činností. A stejné je to také s výstupy testování. Jedna ze základních myšlenek je vždy společná všem snahám o bezpečnostní řízení. Bezpečnost není činnost jednorázová, ale soustavná. To stejné platí také v případě penetračních testů. Musejí se pravidelně opakovat.
penetrační testy IT bezpečnost bezpečnostní strategie
Motivace
Pokud se chceme bavit o krocích, které budou následovat po provedení penetračních testů, musíme se nejdříve podívat na motivaci. Tou může být cokoli od prosté potřeby záznamu, že bylo provedeno „něco a nějak“ a nazývalo se to např. bezpečnostní skenování, přes vyhovění legislativním či auditním požadavkům až po reálnou potřebu silné ochrany systémů a informací.
Vlastní průběh testu a rozdíly v jednotlivých postupech nám určí vstupní informace ze strany zadavatele testu o důvodu a rozsahu testování. Je rozdíl, zda testujeme aplikaci v laboratorním prostředí před uvedením do produkce, nebo provádíme test již instalovaného řešení s produkčními daty. Rozdílný bude nejen test, ale také nakládání s jeho výstupy.
Postup
Jestliže jsme definovali potřeby a motivace penetračního testu, je na čase vybrat testera a metodologii. Tyto skutečnosti velmi ovlivní finální výsledek. Schopnosti a zkušenosti testera jsou klíčovým aspektem celého testu. Je důležité určit, co od testera požadujeme. Bude-li provádět test plně informovaný o celém systému, zvolí jiný postup než v případě, kdy dostane jen přístup k aplikaci nebo rozsah IP adres a časový rámec.
Součástí zadání musí být také zásadní informace, zda chce-me seznam potenciálních zranitelností, které by se daly zneužít, nebo se má pokusit data kompromitovat. V případě uceleného seznamu bude práce testera hlavně v identifikaci potenciálních hrozeb, kdežto v druhém případě se zaměří na několik „nejslibnějších“ zranitelností a pokusí se zneužitím jedné či vhodnou kombinací několika zranitelností systém kompromitovat.
Zadání a zvolený postup testera nám dává výchozí informace pro rozhodování, co budeme s výsledky dělat a co bude po provedeném testu následovat. Jedno je však vždy společné pro všechny testy. Musíme mít čas na nápravu a retest. Častou chybou, kterou vídáme při provádění testů, je zařa-zení penetračního testu na konec harmonogramu. Tam jeho místo opravdu není a tento přístup s sebou nese velká rizika.
Na bezpečnost je nutné myslet od prvotní architektury. Vždy ji vrstvíme a obalujeme s ní nějaký základ, který chceme chránit. Pro zjednodušení si vše můžeme představit jako vrstvy cibule. Začneme se svrchní vrstvou, tedy s fyzickou bezpečností, poté se posuneme k infrastrukturní a dále k aplikační. V případě aplikace se zase dostáváme hlouběji v použitých frameworcích a knihovnách. Při výstavbě bezpečných aplikací je nutné postupovat od těchto základních stavebních bloků k vyšším vrstvám. Pokud penetrační test odhalí na konci vývoje kritickou zranitelnost v základním frameworku, těžko již aplikaci upravíme a její bezpečnost budeme moci řešit pouze na vyšší vrstvě, např. aplikačním firewallem. Bohužel tím přicházíme o podstatnou část bezpečnosti a musíme se o to více soustředit na architekturu infrastrukturní a fyzické vrstvy.
Konečně máme výstupy penetračního testu
Na výstupy se budeme soustředit dle vrstvy, kde byla objevena zranitelnost. Zranitelnost na nižší vrstvě lze na vrstvě vyšší zabezpečit jen částečně. Opačně však dokážeme některé nedostatky napravit lépe. Pokud nedokážeme zabezpečit budovu před vniknutím útočníka, můžeme zabezpečit jen vybrané části budovy a síťovou infrastrukturu. V jednotlivých částech budovy povýšíme zabezpečení doplněním dalších bezpečnostních řešení omezujících vstup a u síťové infrastruktury např. vhodnou implementací 802.1x. Takto bychom měli přemýšlet, i když je podle nás vyšší vrstva zabezpečena dostatečně. Vždy je vhodné problém řešit na více vrstvách.
Pominu nyní fyzickou bezpečnost a přejdeme k infrastruktuře. Výsledek penetračního testu nám může napovědět hodně o zabezpečení jako celku. Zároveň nám však správná implementace vyšší vrstvy může znemožnit identifikaci zrani-telností na vrstvě nižší. Pokud např. dáme testerovi seznam našich veřejných IP adres, finální report bude obsahovat pouze nálezy z tohoto vektoru. Budeme-li mít správně implementovány bezpečnostní technologie na perimetru a správná nastavení na infrastrukturní vrstvě. Z výstupu penetračního testu zjistíme, jak firewall chrání infrastrukturu a aplikace. O potenciálních zranitelnostech aplikace, databáze nebo o možnosti kompromitace dat nebudeme vědět nic. Tedy za předpokladu, že penetrační test tuto vrstvu zabezpečení neprolomil. Za určitých podmínek se můžeme dozvědět o aktivitě pentestra z našich dohledových systémů. Tím získáme jen část informací a spoustu slepých míst, o kterých nevíme.
Nejčastěji dáme testerovi několik vektorů k prověření a poté také několik vrstev. K jednotlivým vrstvám mu dáme přístup a případně také informace. Poskytnuté informace a přístupy se řídí potřebou testu. Je rozdíl, zda provádíme testy bez dalších informací, tzv. Black-box, nebo poskytneme testerovi širší okruh informací, tzv. White-box test. V případě Black-box testu se zvyšují nároky na praxi a zkušenost samotného testera. Výsledek nám totiž říká: „Obdobně zkušený tester se v systému zorientuje a zneužije zranitelnost za nějaký časový úsek.“ Výsledek je méně komplexní ve srovnání s White-box testem, ale na druhou stranu dává velký prostor kreativitě. Tester není svázán informacemi, které dostal, a zvětšuje se šance, že nalezne kombinaci kroků, která by jej při White-box testu nenapadla.
Dokumentace nálezů
Výstupem penetračního testu je dokumentace všech nálezů, které se ohodnotí dle závažnosti. Většinou se řeší nálezy s vysokou mírou rizika nebo přímo kritické zranitelnosti systémů. Správným výstupem penetračního testu je report konsolidující nálezy do jednoho uceleného dokumentu s unifikovanou strukturou. Do reportu se dostávají pouze negativní zjištění. Testy, které nevedly k negativním nálezům, se do reportu neuvádějí.
Pro každé zjištění jsou v reportu informace k identifikaci cíle, detaily nálezu a případný návrh nápravných opatření, která mohou být dvojí:
- okamžitá pro bezprostřední snížení kritičnosti problému
- opatření k celkové nápravě.
Report máme, s kým se na to podíváme?
Pokud již držíme v ruce report z penetračního testování, začíná další fáze. Tester nebo organizace, která testy provedla, nám pomůže porozumět nálezům. Toto porozumění je důležité hlavně pro následný výběr opatření. Není vždy možné zranitelnost eliminovat, ale je nutné dělat finální rozhodnutí při znalosti problému a s plnou informovaností. Jen tímto způsobem jsme schopni vybrat správná opatření.
Opatření, která volíme:
- zmírnit rizika
- odstranit rizika
- dočasně přijmou rizika
- smířit se s riziky.
Dobrým porozuměním reportu můžeme významně ovlivnit ča-sovou a finanční náročnost nápravných opatření. Jedním z prvních úkolů, který bude jen na nás jako na objednateli penetračního testování, je zhodnocení stavu reportu. Po zpracování reportu je důležité si odpovědět na otázku: „Víme dost?“
Pokud nemáme dostatek informací, je nutné pokusit se je získat. Ať už od testera, vlastníka testované aplikace, správce infrastruktury, nebo kohokoli, kdo je za danou problematiku odpovědný. Identifikace rolí je nutnou součástí stanovení a realizace nápravných opatření. Častou chybou bývá zaměřenína izolované problémy. Opatření poté bývají nekoordinovaná a mohou způsobovat zvýšení časové a finanční náročnosti pro realizaci dílčích změn. Dalším důsledkem je, že se výrazně prodlouží celkový čas vypořádání se s nálezy penetračního testu. V extrémních případech se můžeme dostat do stavu, že je již potřeba nového penetračního testu a my máme vypořádáno jen minimum nálezů z předchozího testu.
Pro vlastní návrh opatření a řízení změn je nutné si IT prostředí rozdělit na služby vlastní a cizí. Co řeším dodavatelsky a co jsem schopen ovlivnit vlastní silou. Následně je vhodné posoudit úroveň opatření, které jsme schopni realizovat. Pokud mám aplikaci, kde nejsem schopen upravit nic v jejím kódu ani s využitím dodavatele, je vhodné se podívat např. na infrastrukturní vrstvu a riziko zmírnit zde. S pouhým zmírněním problému na vyšší vrstvě bychom se neměli spokojit. Jak jsem již psal, tento způsob zranitelnost řeší pouze částečně, a to jen pro konkrétní vektor útoku.
Zpracování výstupů penetračního testu by mělo být řešeno jako jeden projekt, v rámci kterého stanovíme komplexní architektonický pohled. Vyhneme se tím zdvojování opatření nebo naopak pominutí některých rizik. Celá architektura našeho řešení musí dávat smysl jako celek. Poté si vše rozdělíme na jednotlivé projekty a určíme priority. V této části by mělo vše probíhat dle standardních postupů pro rozvoj a údržbu informačních systémů, které jsou v organizaci platné.
Jak postupovat
Ihned po obdržení informací o ukončení penetračního testování je vhodné prověřit nastavení logování a dohledových systémů. Víme, že se nám v síti pohyboval útočník, a měli bychom si ověřit, zda jsme něco z jeho počínání v síti zachytili v monitorovacích systémech, případně v log záznamech.
Výstupem této prvotní kontroly logů a monitorovacích systémů by měla být sada doporučení pro ladění. Často se při podobném „úklidu“ zjistí, že úroveň logování je na systémech nastavena nedostatečně. V dohledových systémech je vhodné upravit mezní hodnoty pro upozornění nebo doplnit o další sledované atributy. U mnoha společností je monitoring nastaven pro sledování provozních informací, ale bezpečnostní aspekty bývají pomíjeny.
Pokud existuje možnost provést nápravná opatření u systémů a služeb vlastní silou nebo s podporou servisní organizace, je vhodné začít těmito kroky. Vzhledem k tomu, že velká část infrastrukturních nálezů může být způsobena konfigurační chybou, mnoho problémů napravíme správnou konfigurací.
Při tvorbě architektury je vhodné se zamyslet nad více vrstvami zabezpečení. Pokud např. výsledky testu ukazují na chybu systému nebo v aplikaci, je vhodné řešit problém nejen na vrstvě, kde byla zranitelnost objevena, ale také se podívat o úroveň výše. Zranitelná aplikace může být částečně chráněna vhodnou implementací IPS nebo aplikačního firewallu. Ladění na této infrastrukturní vrstvě bude výrazně rychlejší než úpravy aplikace. Předřazením automatizované ochrany získáme čas na správnou implementaci zabezpečení v koncovém systému nebo aplikaci. Jedná se o tzv. virtuální patchování, kdy využíváme k ochraně automatizované bezpečnostní systémy rozpoznávající hrozbu na základě signatur. Příprava signatury pro novou zranitelnost trvá zavedeným výrobcům hodiny až dny. Patch pro systém nebo aplikaci může vznikat měsíce i roky.
Je vhodné si uvědomit vektor, ze kterého je zranitelnost chráněná. Mnoho sítí se soustředí na ochranu útoků z internetu. Uživatel přistupující z vnitřní sítě má výrazně širší možnosti kompromitace dat. Pokud je pro nás nějaké aktivum kritické, je vhodné stejným způsobem chránit toto aktivum také ze všech částí vlastní infrastruktury.
Architektura, která nám dovoluje bránit informace na několika úrovních, výrazně znesnadňuje práci útočníkům. Navíc získáváme komplexnější informace o systémech a aplikacích. Tím se výrazně zvyšuje šance na odhalení útočníka dříve, než napáchá významné škody.
Investice
Architektura v rámci IT bezpečnosti je vždy dlouhodobou strategií, která se upravuje na základě vývoje hrozeb a bez-pečnostních technologií. Penetrační test by měl být jedním ze vstupů, které nám pomáhají celou architekturu revidovat a upravovat priority. Určitě by však neměl být jediným ná-strojem, kolem kterého architekturu vytváříme. Celá archi-tektura by měla nejdříve bezpečně působit a měli bychom vědět, že otázku bezpečnosti v rámci naší architektury jsme vytvořili se znalostí aktiv její hodnoty.
V ideálním případě bychom měli sledovat náš architektonický plán a ladit zabezpečení jednotlivých komponent s přihlédnutím k výsledkům penetračních testů. Bohužel se vše vyvíjí velmi rychle. Je vhodné jednou za rok revidovat náš architektonický plán a zároveň minimálně jednou za rok provést penetrační test. V praxi se proto stává, že se tyto činnosti potkávají nebo spíše směřují, aby na sebe navazovaly. Občas se tak architektonický plán upravuje poněkud nekoncepčně, hlavně na základě výsledků pen-tračního testování.
Jak jsem již zmiňoval, nápravná opatření by měla být řešena projektem. Důležité je, aby byl tento projekt řízen a rozdělen na menší části se samostatným časováním a jasným začátkem, koncem, a hlavně cílem. Investice finanční i časové jsou však nezbytné nejen pro nápravná opatření, ale také pro plánovaný strategický rozvoj infrastruktury a všech oblastí bezpečnosti. Je potřeba si uvědomit, že dočasné nebo trvalé přijetí rizika je také jedním z řešení nálezů.
Bez proškolených lidí to nejde
Školení a rozvoj znalostí administrátorů nám pomáhají na dvou úrovních. Zabezpečit aktiva zvládne jen administrátor, který má dostatečné znalosti, orientuje se v problematice a umí si říci o potřebné nástroje. Pokud už k nějakému incidentu dojde, výrazně se zvyšuje možnost, že administrátor podezřelou aktivitu odhalí nebo bude schopen ochránit systémy při probíhajícím útoku. Takto lze podstatným způsobem snížit výši škod. V této oblasti se za poslední roky velká část firem výrazně posunula kupředu.
Bohužel se často zapomíná na největší skupinu osob a také největší riziko – uživatele bez privilegovaného přístupu. Ať už jste v rámci zadání penetračního testu řešili nějakou variantu sociálního inženýrství, nebo ne, je důležité se na tuto oblast soustředit. Vždy je lepší, když útok vůbec neproběhne. Doufat, že nebude zneužita zranitelnost, o které dosud nevíme nebo proti ní nejsme chráněni, není vhodnou strategií. Pravidelně cvičený uživatel nám v tomto směru může velmi pomoci, A to nejen tím, že sníží riziko průniku škodlivého kódu do našich systémů, ale také nás bude schopen upozornit na potenciální hrozbu, se kterou se setkal. Získáváme tím velmi cenný zdroj informací.
A zase testujeme
Pokud jsme upravili zabezpečení podle nálezů, provedeme retest. Velmi důležité je, že po provedení nápravných opatření následuje retest vždy. Ten může mít několik podob. Občas zadavatel požaduje, aby byl proveden retest jen na konkrétní zranitelnosti. Bohužel je to nejen problematické na provedení, takže to mnoho času neušetří, ale také bezpečnostní aspekt hovoří proti tomuto postupu.
Než se dostaneme k opětovnému testu, uběhne často několik týdnů nebo měsíců, podle složitosti nápravných opatření a celkového množství problémů. Tester po delším čase již nemusí mít zaznamenán takový detail, aby bylo možné provést jen částečný retest, který by byl cílený jen na vybrané zranitelnosti. Navíc tímto selektivním postupem nejsme schopni odhalit případné nové zranitelnosti. Nikdo nám totiž nezaručí, že odstraněním jedné zranitelnosti nevytvoříte novou. Prostou konfigurační změnou v infrastruktuře nebo úpravou aplikace je velmi snadné vytvořit problematické místo jinde.
Doporučujeme tedy provádět test stejným způsobem a ve stejném rozsahu jako test, na jehož základě vznikl původní seznam nápravných opatření.
Dohled a dokumentace
Vytvořili jsme si technologicky rozumně vypadající infrastrukturu. Zabezpečili jsme aktiva. Pravidelně testujeme a ladíme. Dříve nebo později však narazíme na kapacity našich IT pracovníků. Tím se částečně vracíme opět na začátek, protože se nám začnou objevovat chyby, které mohou mít za následek, že sebelepší technologie, kvalitní procesy a velké úsilí mnoha lidí nás neochrání. Častým jevem je zapomenuté kompromisní řešení při vývoji aplikace nebo konfiguraci systému. Spěch, lenost, nepozornost jsou slabými místy bezpečnosti. Problémem je, že penetrační test některá rizika v danou chvíli neodhalí nebo se na danou problematiku ani nezaměřuje. Pravidelný „úklid“ je důležitou částí bezpečné architektury. Změny musejí být dokumentovány a pod dohledem. Tím se podstatně zvýší bezpečnost vašich aktiv.
Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript.
