Prověrka konfigurace versus penetrační test

To lze udělat dvěma základními způsoby nebo lépe: kombinací obou.

1. Penetrační test

• je simulací útoku na ICT, jehož cílem je proniknout do systému, ovládnout ho nebo se alespoň pokusit narušit jeho činnost
• investigativní test, kde jednotlivé kroky postupu se mění podle aktuálních zjištění
• kvalita provedení penetračního testu není až tak závislá na metodice či nástrojích, ale na zkušenostech a znalostech pentestera
• výsledkem testů je nalezení slabých míst, a je-li to možné, i ověření jejich zneužitelnosti

2. Prověrka konfigurace

• je prověřování nastavení systémů vůči nějakému etalonu, jako je např. systémová bezpečnostní politika či konfigurační standard nebo doporučení výrobce
• postup je dán seznamem kontrolovaných parametrů
• prověřování konfigurace může proběhnout i offline, tzn. stačí exportované výpisy konfigurace
• kvalita provedení testů závisí především na použitém etalonu
• výsledkem je komplexní zhodnocení aktuálně nastavené bezpečnosti vůči zvolenému standardu
• na rozdíl od penetračního testu může mít prověrka konfigurace plně automatizovaný charakter v rámci procesu řízení zranitelností

V prvé řadě je nutné říci, že oba dva typy prověřování bezpečnosti mají své místo a opodstatnění a jsou-li užity správně, významně přispějí k řešení bezpečnosti daného systému.

Co testovat?

„Nedůležité“ systémy

Často se setkávám s názorem, že nedůležité systémy nepotřebují extra péči z hlediska bezpečnosti a tudíž i bezpečnostní testy jsou zbytečné s odůvodněním, že v případě úspěšného útoku se jen obnoví konfigurace a databáze a systém bude fungovat dál.

Do určité míry s tím lze souhlasit. Vždyť míru rizika určuje primárně hodnota aktiv. Ale nesmíme zapomenout, že nejde jen o samotný systém, ale i o služby, které přímo či nepřímo ovlivňuje. Přesto je nutné mít na zřeteli, že pokud umožníme útok, resp. nebudeme se starat o bezpečnost systému, stále se jedná o naši starost a odpovědnost.

V České republice neexistuje zvláštní právní předpis, který by výslovně upravoval problematiku právní odpovědnosti v souvislosti s nedostatečným zabezpečením počítačových systémů. To však vůbec neznamená, že za jeho zneužití nemůže být jeho provozovatel shledán právně odpovědným a tedy spoluzodpovědným za způsobenou škodu.

Velmi zabezpečené systémy

Na opačném konci jsou systémy, které jsou zabezpečeny na velmi vysoké úrovni. To vyžaduje vysoké zabezpečení na fyzické i personální úrovni. A přestože bychom očekávali, že takové systémy budou bezpečnostně protestovány doslova ze všech stran, je tomu zpravidla trochu jinak. Systémy bývají fyzicky velmi dobře zabezpečeny, od okolního světa velmi dobře odděleny a určeny jen úzkému okruhu uživatelů, tedy hrozba nějakého útoku z vnějšího světa není příliš pravděpodobná. Z tohoto důvodu je myšlenka na penetrační test provedený osobou mimo danou organizaci  neakceptovatelná. To, že by se systém bezpečnostně netestoval, také nepřichází v úvahu. Testy se musí přizpůsobit možnostem provozovatele systému. A tak se přebírá z různých důvěryhodných zdrojů bezpečná konfigurace, a ta se následně kontroluje pomocí prověrky.

Pokud bychom takto prověřovali pouze operační systémy a jiný základní SW, pak je to zřejmě dostatečné. Ale běží-li zde např. webový portál dělaný na zakázku nebo vyvinutý vlastními silami, hrozí např. možnost existence nějaké z kritických webových zranitelností, kde jen prověrka konfigurace stěží něco zjistí.

Existuje-li nějaká hrozba, je potřeba bezpečnostně testovat všechny systémy. Rozsah testů by měl odpovídat požadované míře bezpečnosti, a tu bychom měli znát už ve fázi designu systému. I pro bezpečnostní testování můžeme stanovit personální požadavky tak, aby test nepřinesl další rizika.

Kdy testovat?

Je zarážející, že bezpečnostní testy, pokud jsou vůbec prováděny, tak většinou jen na finální verzi systému. Přitom úzce zaměřené testy např. odolnosti proti injection útokům. si mohou vývojáři provádět sami už při vývoji aplikace. Stejně tak je potřeba řešit bezpečnost aplikace už ve fázi designu. Protože zjistíme-li bezpečnostně špatně navrženou architekturu, může to znamenat poměrně vysoké finanční prostředky na opravu. Jednoduše řečeno: na papíře se věci mění snáze a rychleji, než v reálném prostředí.

Testy by měly vždy proběhnout před nasazením aplikace do produkčního prostředí. Jde-li pouze o změnu, je třeba vždy zvážit její dopad na bezpečnost. Např. dojde-li ke změně autentizačního nebo autorizačního mechanismu, je nutné vždy testovat.

Jak testovat?

Prověrka konfigurace

Už ve fázi designu informačního systému bychom měli mít představu, z jakých bezpečnostních standardů budeme vycházet. Jako vhodné a poměrně široce pokrývající standardy, lze jmenovat „CIS - Security Configuration Benchmarks“, které umožňují nastavit bezpečnost v potřebné úrovni. U některých bezpečnostních opatření s vlivem na výkonnost systému, si pak musíme položit otázku, co má prioritu: výkonnost nebo bezpečnost systému?

Použijeme-li způsob testů „prověrka konfigurace“, měli bychom prověřovat komponenty na všech vrstvách informačního systému, tj. od síťových prvků, přes operační systémy, databáze, až po webové servery. Prověřovat pouze jednu vrstvu informačního systému může přinést falešný pocit bezpečí.

Prověrku konfigurace lze dělat manuálně nebo využít automatizovaných nástrojů. V případě komerčních produktů např. společnosti Microsoft, je k dispozici automatizovaný nástroj „Microsoft Security Compliance Manager“ aktuálně ve verzi 3.0 (viz obr.)

Penetrační test

Útočník volí většinou nejjednodušší cestu jak získat neoprávněný přístup do informačního systému a tomu by měl odpovídat rozsah penetračních testů. Tester, provádějící penetrační test, má na rozdíl od útočníka omezené časové možnosti. Proto čas musí být využit efektivně, což v praxi znamená i přerušení sady testů a přikročení k jiným testům. Test může být zaměřen infrastrukturně, zpravidla jde o interní test nebo může jít o externí test např. webové aplikace nebo služeb přístupných z Internetu. Penetrační test, jak by se mohlo zdát, není pouze o manuálním testování, naopak mnohdy je potřebné si určité nástroje pro automatizaci testů vytvořit nebo alespoň opravit. Za mnohé lze zmínit nástroje postavené na „Metasploit Framework“ nebo pro testování webových aplikací „Acunetix WVS“ s funkcí Acusensor, která odlišuje tento nástroj od jiných blackbox scannerů tím, že analyzuje zranitelnost i ve zdrojovém kódu běžící webové aplikace. U penetračního testu je nezbytné mít domluvený čas a rozsah testovaných zařízení včetně kontaktní osoby, zajišťující případnou obnovu služeb po výpadku způsobeném testem, i proto je vhodné provedení testů naplánovat mimo nejvytíženější dobu systému, zpravidla přes noc nebo o víkendu.

Robert Malý, Ness Technologies

Chcete se dozvědět více o testování a dalších IT službách? Potřebujete snížit náklady na firemní informační technologie? Využijte služeb společnosti Ness Technologies!