Efektivní využití IDS

Rozhodně nestačí systém IDS pouze vlastnit. Je naprosto nezbytné ho také správně nastavit a používat. V předminu...


Rozhodně nestačí systém IDS pouze vlastnit. Je naprosto nezbytné ho také
správně nastavit a používat.

V předminulém vydání Computerworldu (CW 5/2005) jsme se věnovali základnímu
popisu systémů IDS (Intrusion Detection Systém) včetně toho, jak lze řešení od
jednotlivých výrobců porovnat. Dnes budeme předpokládat, že takovýto systém již
vlastníte a že stojíte před skoro nerudovskou otázkou: Co s ním?
Bohužel se v případě informační bezpečnosti lze více než často setkat s
přístupem, kdy veškerá starost o určitou aplikaci/službu končí jejím
nainstalováním. To je ale kardinální selhání bezpečnost totiž nelze řešit
systémem "nainstaluj a zapomeň". O bezpečnost sítě je zapotřebí se starat,
monitorovat ji a především ji stále dolaďovat, a to na základě nových poznatků
nebo aktuálních incidentů. Nejslabším prvkem bezpečnosti tak bývá pohříchu její
závěrečné zavedení do každodenní praxe.
Z časového hlediska můžeme úkony související právě s implementací IDS rozdělit
do tří fází: příprava, identifikace incidentu plus vypořádání se s ním a
vyhodnocení.

Cíle IDS
Cílem instalace systémů IDS je identifikace útoků a ruku v ruce s tím i
eliminace FP (False Positive; to je situace, kdy je korektní aktivita z
nějakého důvodu reportována jako bezpečnostní incident). Nejde ale samozřejmě o
pouhé sledování funkčnosti a činnosti systému, pročítání výpisů, vytváření
statistik útoků pro management, eventuelně bědování nad úspěšnými útoky. V
praxi jde i o další činnosti:
Vlastní monitorování IDS a úpravy systémů v závislosti na četnosti útoků, FP
nebo FN (False Negative; situace, kdy je bezpečnostní incident považován za
korektní aktivitu).
Ošetření incidentů. Samozřejmě je zapotřebí na vzniklé problémy reagovat, a to
umožňuje jen průběžné vyhodnocování dat získávaných z IDS (mimochodem, právě
shromažďování dat ač často podceňováno nebo přehlíženo patří k hlavním úkolům
IDS).
Analýza a ukládání dat, která jsou získána v průběhu činnosti IDS.
Reportování pokud má mít celý systém smysl, pak je zapotřebí, abychom ze
získaných dat vytvářeli informace, a ty pravidelně a správně interpretovali.
IDS není podobně jako ostatní bezpečnostní prvky systémem, který by zajistil,
že k útokům nebude docházet. Jeho úkolem je útoky identifikovat, a tak je
zapotřebí mít vypracovánu politiku nakládání s incidenty. Ostatně, kdyby tato
politika nebyla vypracována, tak by ani nemělo smysl snažit se útoky detekovat.

Kategorie útoků
Ne každý incident má stejnou míru nebezpečnosti, takže kromě vytyčení jasných
pravidel pro jednotlivé situace (co dělat v některém z daných případů) je
žádoucí rozdělit si incidenty do několika kategorií. Pokusem o skenování portů
nemá totiž smysl zabývat se stejně podrobně jako cíleným útokem na kritická
data.
V první kategorii by mohly být běžné pokusy o útok skenování portů, pokusy o
neautorizovaný přístup, mapování apod. Spíše než o nějaký útok jde o
potenciálně nebezpečné aktivity, protože každá jen trochu zabezpečená síť by
vůči nim měla být stoprocentně imunní. Nicméně je dobré zaznamenat IP adresu či
doménu útočníka a uchovat ji pro budoucí použití (třeba ji vést na seznamu
rizikových nebo rovnou zakázaných).
Ve druhé kategorii bezpečnostních incidentů jsou snahy o získání informací
neautorizovanými osobami (snaha získat soubory s hesly, snaha o přístup do
nepovolených oblastí apod.) nebo incidenty z předchozí kategorie, ale
realizované opakovaně. Vzhledem k tomu, že se jedná o závažnější incidenty, je
zapotřebí provést podrobnější šetření. Kromě pouhého zjištění IP adresy nebo
domény útočníka je zapotřebí ještě provést jejich validaci zdali jsou opravdu
platné, zdali pouze neslouží coby zástěrka pro změnu identity skutečného
agresora. Zároveň je zapotřebí vyhodnotit, jaká možná rizika z prováděných
aktivit vyplývají.
Ve třetí kategorii jsou závažné bezpečnostní incidenty (DoS útoky, opakované
pokusy z druhé kategorie apod.). V takovém případě je už zapotřebí provést
podrobnější šetření. A především zajistit zdokumentování celého incidentu.

Dokumentace
Dokumentace slouží jako zdroj informací v případě dalších podobných incidentů.
Je nutné archivovat všechny relevantní logy, výpisy síťového provozu, soubory,
výsledky zjištěné nástroji IDS, výsledky následných analýz, výpisy aktivit na
administrátorské konzoli aj. Stejně tak je nutné co nejpodrobněji archivovat
podobu kompromitovaného systému před incidentem a po incidentu.
Dokumentování má ještě jeden závažný důvod přibývá totiž incidentů, které mají
vážný charakter a které spadají do oblasti porušování zákonů. Takovým se pak
čím dále častěji věnují orgány činné v trestním řízení. A právě pro tento
případ je nutné provádět dokumentaci, protože jednou zničený důkaz v
kybernetickém prostoru je nenávratně ztracený. Pro případ zajišťování stop
trestné činnosti je pak zapotřebí mít vypracované přesné postupy jejich
získávání a archivování, aby je pak bylo možné použít coby důkazní materiál, a
aby bylo možné jednoznačně prokázat způsob jeho získání.
A podobné dokumentování má ještě jednu nezanedbatelnou výhodu. Podrobnou
analýzou dat lze totiž ve sporných případech určit zodpovědnou osobu což nemusí
vždy být administrátor, nicméně právě na něj je zpravidla většina zodpovědnosti
přesouvána. Pokud administrátor dělá svoji práci kvalitně, pak mu dokumentace
umožní udržet si i po bezpečnostním incidentu čistý štít.

Politika
Politika nakládání s incidenty se musí stát základem pro úspěšné využívání IDS.
Skládat by se měla z následujících oblastí:
Určení, jakým způsobem k incidentu došlo. Úspěšný útok se totiž rovná neúspěšné
obraně. Kde se stala chyba? Co jsme udělali nebo naopak neudělali? Jak jsme
útočníkovi usnadnili jeho úkol?
Provedení úkonů vedoucích k zabránění dalších zneužití zjištěné slabiny.
Bezpečnostní nedostatek, o kterém víme, že existuje, je rozhodně lepší, než
nedostatek neznámý. Víme, že něco není v pořádku, víme co to je a to je základ
pro realizaci protiopatření.
Zabránění zhoršení situace a následným potížím. Darmo plakat nad rozlitým
mlékem stejně tak nad bezpečnostním incidentem. Ale v případě zaznamenaného
incidentu můžeme poměrně snadno určit cíl a stejně tak dobře můžeme zamezit
další eskalaci problému.
Stanovení rozsahu a typu poškození, které incident způsobil. Je zapotřebí
zjistit přesný rozsah škod a kvantifikovat zasažená data i oblasti.
Obnovení stavu do původního tedy do podoby před incidentem (je-li to možné a
žádoucí). Každý bezpečnostní incident přináší problémy, které jsou o to větší,
dochází-li k zasažení kritických oblastí. Ty je zapotřebí nákladně a časově i
lidsky náročně vracet do původní podoby, přičemž mnohdy je to nemožné. (Někdy
dokonce i nežádoucí, a to zvláště v případě, pokud stav před incidentem umožnil
jeho vznik.)
Je-li to potřeba, pak je třeba aktualizovat procesy a postupy. Jinými slovy:
poučit se z incidentu.
Je-li to možné a žádoucí, je třeba stanovit, kdo je zodpovědný. Tím samozřejmě
nechceme říci, že v případě bezpečnostních incidentů jsou si všichni rovni, ale
někteří rovnější. Ale jsou typy incidentů (zvláště z kategorií lehčích), kdy by
ani podobná analýza dat nedokázala jednoznačně stanovit osobu zodpovědnou nebo
kdy by její odhalení znamenalo neúnosné vynaložení prostředků.
Systémy IDS jsou výbornými nástroji bezpečnostní architektury, ale jejich pouhé
nainstalování nestačí. Je zapotřebí je průběžně monitorovat, získané informace
vyhodnocovat a následně je obratem využívat v praxi. Jinak se IDS stane jen
dalším článkem formální bezpečnosti stejně zbytečným jako drahým.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.