SIEM: Auditing a monitoring

Je SIEM něco, čím bychom se měli vážně zabývat nebo je to jen další buzzword?

V počátcích informatiky nepředstavoval auditing a monitoring informačního systému téměř žádný problém, neboť každá organizace měla zpravidla jen jeden informační systém, ke kterému se uživatelé připojovali prostřednictvím terminálů a vytvářel se tak pouze jeden log. Správce takového systému pak nastavil, které události se mají do logu zaznamenávat, a log pak pravidelně vyhodnocoval. Nyní je však nutné vzhledem k existenci enterprise architektury sbírat, korelovat a analyzovat události ze všech vrstev mnoha různých systémů. Takové vyhodnocování už nelze provádět ručně, a pokud má být tato činnost dostatečně efektivní, je nutné za tímto účelem nasadit specializované řešení, které se nazývá SIEM (Security Information and Event Management).

Poznámka: Auditingem se v tomto příspěvku myslí auditní protokolování neboli zaznamenávání vybraných událostí do logu, rozuměj do souboru. Monitoringem pak vyhodnocování těchto událostí a reakce na ně. Jedná se tedy o dvě naprosto rozdílné aktivity.

Auditing

Prvním krokem je identifikace systémů a zařízení, které budou zapojeny do centrálního monitorovacího systému. To můžete provést například na základě analýzy rizik, kdy určíte, které servery a zařízení obsahují, zpracovávají a přenášejí kritická a citlivá data nebo poskytují důležité služby. Poté musíte vybrat události, které se mají logovat. Jsou systémy, kde se provádí detailní logování všech aktivit, včetně příkazů zadaných uživatelem z příkazového řádku, což znamená disponovat velkou diskovou kapacitou. V neposlední řadě musíte určit dobu, po kterou se budou jednotlivé události uchovávat a způsob jejich archivace. Logování je možné provádět na úrovni:

• operačního systému,
• aplikace,
• databáze,
• sítě a síťových prvků.

V okamžiku, kdy se vám budou vytvářet auditní logy na jednotlivých serverech a zařízeních, musíte zajistit, že jednotlivé události budou přeneseny do centrálního úložiště nebo proběhne jejich záloha dříve, než dojde k jejich přepsání novými událostmi. Nezapomínejte, že informace uvedené v logu jsou nezbytné pro zpětnou rekonstrukci činností uživatele v systému a odhalování bezpečnostních incidentů a jejich šetření. Aby mohly být tyto záznamy uznány jako důkazní materiál, je nutné je chránit před nežádoucí modifikací. Obvykle se to řeší tak, že se logy buď kopírují v původní nezměněné podobě do geograficky vzdálené lokality, nebo se přímo tam vytvářejí. Tento požadavek jsou samozřejmě schopny zajistit i některá specializovaná SIEM řešení. Dodavatel by vám měl být proto schopen odpovědět na otázku, jak se provádí deployment a jak je zajištěna komunikace mezi centrálním serverem a dohlíženými zařízeními. Existují zde určitá rizika, jako podvrhnutí zařízení, modifikace přenášených dat, zahlcení centrálního serveru falešnými událostmi apod. Dle způsobu přenosu logů resp. jednotlivých událostí rozlišujeme řešení:

• s agentem (agent) – aktivní řešení, kdy na každém stroji, který má být dohlížen, je nainstalován agent. Agent může být komerční aplikace nebo může mít podobu skriptu. Agent zasílá všechny nebo vybrané události, které se zapisují do auditního logu na centrální server. Jedná se o metodu push, kdy agent „tlačí“ data na centrální server.
• bez agenta (agent less) – pasivní řešení, kdy se žádný agent neinstaluje, centrální server se připojuje ke konkrétním serverům a zařízením a sám si události z auditního logu načítá. Jedná se metodu pull, kdy agent „tahá“ data z auditních logů.

V obou případech pak na centrálním serveru, ke kterému je připojen velkokapacitní disk nebo diskové pole, dochází ke zpracování jednotlivých událostí v těchto několika krocích:

• agregace (gathering, centralization, collecting) – události z různých systémů resp. z jejich logů jsou stahovány na jedno místo.
• normalizace (normalization) – vzhledem k tomu, že události jsou v logách uloženy v různém formátu a tvaru, musí být nejprve převedeny do stejného formátu a poté mohou být uloženy do příslušných polí v dané DB tabulce.
• korelace (correlation) – nad událostmi, které jsou uloženy v DB v normalizovaném tvaru, je možné provádět nejrůznější SQL dotazy a tím odhalovat bezpečnostní neshody.
• reportování (reporting) – patří sem zasílání alertů na vybrané adresy, generování reportů apod.

Pokud hovoříme o centrálním serveru, nemusí se nutně jednat o jeden server, nýbrž o několik spolupracujících serverů, kdy např. několik serverů provádí agregaci a parsování a ukládá data do DB a další server zase provádí analýzu těchto událostí.

Agregace

Abyste byli schopni stanovit odpovídající požadavky na HW konfiguraci a diskový prostor, musíte alespoň přibližně spočítat:

• jaký bude počet událostí za konkrétní časové období,
• průměrnou velikost události,
• úspěšnost komprese, neboť naprostá většina událostí se opakuje a liší se jen minimálně.

V okamžiku, kdy se budete návrhem architektury a výběrem vhodného řešení zabývat, měli byste vzít v úvahu, že požadavky na logování budou růst, protože budou přibývat uživatelé a systémy. Měli byste se proto ptát, jaká je škálovatelnost daného řešení, zda budete moci použít vlastní DB nebo jen DB dodávanou s daným produktem. Kolik systémů budete moci dohlížet a jaká je cena za licenci? Dost často se platí za počet dohlížených zařízení, tak abyste pak nebyli nemile překvapeni.

Normalizace

Příchozí události se musí normalizovat, protože pokud mají být uloženy ve společné databázi, musí být zajištěno, že se do příslušných databázových polí budou ukládat odpovídající položky. Doporučujeme následující strukturu, tzv. W7 formát, kdy jsou v DB následující pole:

• Who – Kdo je původcem dané události? Účet.
• What – Co se stalo, resp. o jakou událost se jedná?
• When – Kdy se událost vyskytla?
• onWhat – Jakého objektu se daná událost týkala?
• Where – Na jakém stroji k události došlo?
• WhereFrom (Whence) – Odkud událost přišla? Stroj.
• WhereTo – Jaký systém byl cílem události?

Dále byste měli zajistit, aby byl na všech systémech synchronizovaný čas, a bylo možné jednoznačně určit identitu uživatele, neboť na různých systémech může vystupovat pod různými jmény. To ovšem předpokládá nějaké propojení s identity managementem (IAM).

Korelace

V okamžiku, kdy vám začne do DB chodit obrovské množství událostí, měli byste sledovat a vyhodnocovat i souvislosti mezi nimi. Ty nemusí být na první pohled vůbec zřejmé a bez použití SIEM nástroje je prakticky nemožné je odhalit. Pro vyhodnocování souvislostí se používá pojem korelace. Pro sledování souvislostí mezi událostmi si však musíte vytvořit vlastní korelační pravidla. Pokud již SIEM nástroj nějaká korelační pravidla obsahuje, pak zpravidla jen pro síťové prvky, ale už ne pro UNIX, LINUX nebo Windows. Vždy byste se měli ptát, jak snadné je nastavit pravidla pro vyhodnocování souvislostí a zda lze jednotlivé alerty kategorizovat, tj. stanovit jim určitou prioritu. Některá SIEM řešení v rámci korelace provádějí i vyhodnocování souvislostí s jinými událostmi, z jiných organizací, a jsou tak schopni odhalit incident ve vašem systému dřív, než nastane.

Reporting

Způsob, jakým SIEM řešení hlásí podezření na bezpečnostní incidenty je neméně důležitý. Obvykle bývá u každého SIEM řešení k dispozici konzole, na které se zobrazují alerty. Pokud konzole neprovádí deduplikaci, stává se v určitých případech nepoužitelnou. Deduplikace funguje tak, že pokud se objeví stejný alert, tak nepřibude další řádek na konzoli, ale jen se aktualizuje počet udávající četnost výskytu a datum a čas posledního výskytu daného alertu. Další důležitou vlastností je vytváření a automatické generování přehledných reportů a jejich zasílání odpovědným osobám.

Monitoring

Dost často se v praxi rozlišují dva druhy monitoringu. Tzv. provozní, který si IT většinou dělá samo, nebo který outsourcuje a dále bezpečnostní monitoring, který bývá provozován odděleně a u kterého dost často není jasné, kdo by ho měl vlastně provádět. V případě, že je provozní a bezpečnostní monitoring realizován odděleně, mohou nastat situace, kdy se šance na včasné odhalení incidentu výrazně snižují. V praxi narazíte na problém, že nevíte, zda to, že žádný incident nebyl detekován, není proto, že by daná událost vůbec nenastala, ale proto, že server někdo kompromitoval, agenta deaktivoval nebo změnil rozsah auditování.

V případě některých společností může být auditing a monitoring vyžadován přímo legislativou, jedná se např. o požadavky definované v BASEL II, SOX, HIPPA, FISMA nebo PCI DSS.

Provozní monitoring

Provozní monitoring spočívá ve vyhodnocování aktuálního stavu systému, tzn., že se sleduje zatížení CPU, množství dostupné paměti, volného místa na disku, počet I/O operací, zatížení sítě. Tyto parametry se sledují především proto, že překročení některé z hodnot často vede k nedostupnosti služby a porušení SLA. A nedostupnost na rozdíl od narušení důvěrnosti a integrity uživatel zjistí obvykle hned. Samozřejmě se mohou vyskytovat i krátkodobé peaky, na které není třeba bezprostředně reagovat, ale je o nich dobré vědět, protože tyto informace mohou být velice cenné v rámci kapacitního plánování (capacity planning).

Bezpečnostní monitoring

Cílem bezpečnostního monitoringu je odhalit pokusy o překonání bezpečnostních opatření. Spoléhá se tedy na nastavení auditingu a události, které se objeví v auditním žurnálu a které jsou následně uloženy v centrální databázi, nad kterou probíhají vlastní dotazy a vyhodnocování souvislostí. Na tomto místě bych rád zdůraznil, že žádné SIEM řešení nemůže splnit svůj účel, pokud není správně nastaven auditing. Nezapomínejte, že SIEM pouze pracuje s událostmi, které se objeví v auditním logu.

Alert

V případech, kdy je detekován nestandardní stav nebo podezřelá událost, je vygenerován alert. Tím se zpravidla rozumí hlášení na obrazovce, ale může se jednat i o zaslání mailu nebo SMS na vybranou adresu nebo telefonní číslo. Alert může být generován již po prvním výskytu události nebo při splnění určitých podmínek. Např. v okamžiku, kdy počet událostí nebo nějaká hodnota překročí tzv. threshold. Reakce na alert může automatická ze strany systému nebo vyžaduje nějakou interakci ze strany lidské obsluhy. Z těchto důvodů je vhodné, aby bylo možné jednotlivým alertům přidělit nějakou závažnost (severitu), která určuje prioritu řešení. Jinými slovy stanovuje, jakému alertu by se měl operátor věnovat nejdříve.

Závěr: V praxi se ukazuje, že ani nástroje, které jsou označovány jako SIEM nepokrývají všechny potřeby organizace a spoustu věci je nutné doprogramovat, což představuje dodatečné náklady. Mnohé organizace také v minulosti nakoupily nějaký SIEM nástroj, ale nedokázaly ho již plně využít, protože nebyly schopny vydefinovat, jaké události a odkud se mají sbírat a jak se mají vyhodnocovat. A pokud se jim to podařilo, tak zase neurčily osobu nebo útvar, který by se o SIEM staral a dál ho rozvíjel. Je třeba si uvědomit, že SIEM, pokud má splnit svůj účel, je nutné průběžně upravovat, aby dokázal reagovat na měnící se podmínky. Ideální by bylo takové SIEM řešení, které by dokázalo spolupracovat s DLP, IAM, EZS a docházkovým systémem. S takovým řešením však dosud žádný dodavatel nepřišel. Výzvou do budoucna pro SIEM nástroje je tedy vyšší míra integrace a porozumění informacím hlášených z různých typů zdrojů tak, aby systém byl schopen reagovat proaktivně na potencionální hrozby.

Štítky: informační bezpečnost, SIEM

K článku “SIEM: Auditing a monitoring” 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řihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce:

Δ

 Chci zasílat upozornění na nové komentáře e-mailem.