Existuje situace, který se v organizacích znovu a znovu opakuje, bez ohledu na jejich velikost nebo obor. Něco se stane, nemusí to být ani nic dramatického. Uživatel si přes noc zablokuje přístup, aplikace začne bez zjevného důvodu zpomalovat nebo si někdo všimne aktivity, která zkrátka vypadá podezřele. Není to ještě kritický incident, ale je to dost na to, aby si administrátor, bezpečnostní expert nebo jiný specialita položil otázku: co se vlastně děje?

Tým tak udělá to, co udělat má.

Otevře logy.

A právě v ten moment se celý proces začne zpomalovat.

Proč se vyšetřování incidentů v reálném světě zasekává

V praxi se většina řešení incidentů nezpomaluje proto, že by chyběla data. Těch je obvykle dost až příliš. Problém je v tom, že jsou rozesetá v různých systémech a každý z nich „mluví jiným jazykem“.

Active Directory loguje jedním způsobem, VPN druhým, firewally třetím a aplikace často jen sypou textové záznamy bez větší struktury. Názvy polí se liší, časová razítka nesedí, události se zaznamenávají v různé podobě jako syslog, JSON, CEF, LEEF a dalších (viz článek o různých typech logů). To, co by má být jednoduché dohledání informace, připomíná překladatelské cvičení.

Typickým příkladem je obyčejný account lockout.

Administrátor začne prozkoumávat Active Directory a najde sérii neúspěšných přihlášení. Jenže časové údaje jsou nekonzistentní, něco v lokálním čase, něco v UTC. Přesune se tedy do VPN logů, kde se tentýž uživatel objevuje pod jiným názvem pole. Snaží se pospojovat souvislosti, ale už v této chvíli spíš odhaduje než analyzuje.

Je to ta samá událost? Patří k ní tahle IP adresa? Navazuje to na to, co viděl před chvílí?

Tak pokračuje dál, do firewall logů, možná do aplikačních záznamů. Každý další krok přidává více dat, ale zároveň více nejistoty. A než se všechno sladí natolik, aby bylo možné vůbec začít odpovídat na původní otázku, trvá to půl hodiny nebo i víc.

A to mluvíme o ideálním případě, kdy jsou logy stále po ruce.

V mnoha prostředích (firmách) totiž starší data dostupná nejsou, protože se po několika dnech odlévají na cold storage, aby se ušetřilo. Což je rozumné, dokud vyšetřování nesáhne za tuto hranici. Najednou data nejsou fulltextově prohledatelná, musí se obnovovat, stahovat, někdy i převádět do použitelného formátu.

A vyšetřování incidentu drhne.

Ne proto, že by tým nevěděl, co dělat, ale proto, že systém není postavený na okamžitou práci s daty.

A přitom samotné otázky většinou nejsou nijak složité:

  • Kdo se přihlásil?
  • Odkud?
  • Kdy to začalo?
  • Co se změnilo?

Složitost neleží v tom, na co se ptát, ale v tom, dostat data do podoby, ve které z nich lze rychle vyčíst odpovědi.

Velký příslib versus každodenní realita SIEMu

Po dostatečném počtu podobných zkušeností se debata v organizaci obvykle posune. Někdo navrhne, že už nestačí jen „někam ukládat logy“ a že je čas jít dál.

A téměř nevyhnutelně přijde na přetřes SIEM.

Na papíře to dává smysl. SIEM slibuje přesně to, co chybí: centralizaci, korelaci, alerting, širší viditelnost napříč systémy. Působí jako logický další krok. Řešení, které konečně vnese řád do chaosu.

A svým způsobem to splní. Logy se načítají, vzniknou dashboardy, nastaví alerty. Systém funguje.

Jenže to, co následuje, často není ta očekávaná transformační změna. Protože SIEM nepřináší jen nové schopnosti, ale vyžaduje i určitou připravenost/vyspělost organizace.

Předpokládá, že logy jsou už strukturované. Že názvy polí jsou konzistentní. Že uživatelé rozumí tomu, co je v jejich prostředí normální chování. A že umí definovat, ladit a udržovat korelační logiku.

V praxi ale mnoho organizací na této úrovni vyspělosti teprve pracuje. A tak namísto očekávané přehlednosti a zjednodušení přichází komplexita v jiné podobě.

Alerty chodí, ale je jich moc nebo jsou obtížně interpretovatelné. Korelační pravidla vyžadují víc práce, než se čekalo. Data se chovají nekonzistentně, protože nekonzistentní jsou už vstupní logy.

Postupně se z SIEMu stává méně „řešení“ a více „projekt“. Tedy něco, co vyžaduje neustálé ladění, vysvětlování a úpravy. Ne, že by nefungoval. Jen od organizace požaduje víc, než je v danou chvíli schopná dát.

A dříve nebo později někdo ten pocit shrne velmi jednoduše: “SIEM je sice užitečný, ale na to, co teď opravdu potřebujeme, zbytečně složitý.”

Praktický kompromis mezi běžným logováním a SIEMem

Většina týmů nežije na jednom z extrémů sbírání logů / SIEM. Nejsou ve fázi, kdy by jim stačilo jen logy někam ukládat. Ale zároveň nejsou plně připravené na nároky plnohodnotného SIEMu.

Fungují někde mezi tím. Řeší reálné otázky, které potřebují reálné odpovědi, bez luxusu perfektně připravených dat a armády specializovaných analytiků.

A právě tento prostor bývá dlouhodobě přehlížený.

Není definovaný ambicí „detekovat všechno automaticky“. Je definovaný praktičností.

Cílem není mít nejkomplexnější bezpečnostní platformu na trhu. Cílem je rozumět tomu, co se děje, bez zbytečných komplikací.

Tedy mít možnost sledovat jednu událost napříč systémy. Korelovat aktivity tak, aby to dávalo smysl. Přesunout se od pozorování k akci, aniž většinu času zabere samotná příprava dat.

Když se lidé pak setkají s „mezivrstvou“ v podobě pokročilého log managementu, která přesně do tohoto prostoru zapadá, reakce bývá často okamžitá.

Ne proto, že by přinesla něco úplně revolučního. Ale protože odstraní něco velmi dobře známého, komplikovanost.

A to mění víc než jen uživatelskou přívětivost. Mění to i zapojení lidí. Jakmile může se systémem pracovat více členů týmu, přestává být analýza logů specializovanou disciplínou několika expertů a stává se součástí běžného provozu.

Když jsou logy skutečně použitelné

Rozdíl je nejviditelnější právě v situacích, které dříve způsobovaly zdržení.

Vraťme se k příkladu account lockoutu.

Místo přepínání mezi několika systémy jsou logy už centralizované v řešení, které má jak log management funkce, tak i to nejdůležitější ze SIEM. Místo hádání názvů polí jsou data normalizovaná, „username“ znamená všude totéž. Události na sebe časově navazují. Neúspěšná přihlášení z různých zdrojů se zobrazují pohromadě jako jeden srozumitelný příběh, ne jako izolované fragmenty.

Vyšetřování se může okamžitě posunout dál.

Je vidět zdrojová IP adresa. Ta je obohacená o kontext, patří do konkrétního segmentu, možná i ke známému zařízení nebo vlastníkovi. Místo otázky „kam se podívat teď?“ je už cesta jasně daná.

Čas, který je potřeba investigaci věnovat se přesune tam, kde má být. Výsledkem je méně času stráveného skládáním dat a více času na skutečné porozumění incidentu.

Stejné je to u výkonnostních problémů. Náhlý nárůst aplikačních requestů už nevede k manuálnímu skládání logů z několika míst. Události jsou mnohem jednodušeji čitelné, odkud požadavky přicházejí, jak se chovají, zda mají něco společného (pattern).

Namísto rekonstrukce incidentu z útržků ho tým prostě čte tak, jak se odehrává.

Jeden účastník odborné diskuse to shrnul velmi trefně: „Vyšetřujete podle symptomů, ne podle produktů.“

Začínáte tím, co vidíte. Ne tím, kde si myslíte, že by to mohlo být schované.

Máte-li takový nástroj, začne se projevovat i jeden méně viditelný důsledek. Jakmile jsou logy strukturované, snadno dostupné a na jednom místě, analýza přestává být závislá na několika málo lidech, kteří se vyznají v celé té komplexitě. Stává se z ní něco, co může sdílet celý tým, společně o tom diskutovat a dál na tom stavět.

A občas se stane i něco nečekaného. Po chvíli práce na scénářích, které by dřív působily zdlouhavě a únavně, si někdo uvědomí, že ten proces už vlastně není frustrující. Že je docela dobře zvládnutelný.

Připravené logy dávají SIEMu ekonomický smysl

S rostoucím rozsahem prostředí se objevuje ještě jedna důležitá rovina.

V mnoha SIEM implementacích je výchozí strategie jednoduchá: posílat do systému všechno. Každý log. Každou událost. Každý datový záznam.

Na první pohled to působí jako optimální přístup, maximální viditelnost, nic neunikne.

Jenže v praxi to vytváří vlastní problémy:

  • příliš mnoho dat,
  • příliš mnoho šumu,
  • a náklady, které rostou rychleji než reálná hodnota.

Analytici tráví čas filtrováním nerelevantních signálů, laděním false positives a hledáním smyslu v zahlcujícím objemu vstupů.

Problém přitom často není samotný SIEM. Problém je to, co se do něj posílá.

Pokud se logy před SIEMem předzpracují, tedy odfiltrují, normalizují a obohatí v log management řešení, mění se celá dynamika. Irelevantní data mizí, užitečný kontext přibývá a to, co zůstane, lze efektivně analyzovat.

Organizace tak neplatí za ukládání všeho, ale investují do toho, co má smysl.

Právě řešení mezi čistým logováním a SIEM, toto umí doručit. Nenahrazuje SIEM ani s ním nesoutěží. Připravuje půdu tak, aby ve chvíli, kdy se SIEM nasadí, fungoval tak, jak má. Data jsou čistší, vzorce přehlednější a systém se stává něčím, na co se může tým spolehnout. Ne něčím, co je potřeba neustále ladit.

Připravenost na SIEM tedy není o rozpočtu ani o záměru. Je o tom, jestli máte správné základy. Tedy data, která dávají smysl, procesy, které fungují, a nástroje, které lidem pomáhají analyzovat dění v IT prostředí.

Rozhoduje praktičnost

Týmy obvykle nechtějí další systém, který bude vyžadovat neustálou péči. Další místo, kde se data zaseknou, další nástroj, který vyřeší jeden problém a vytvoří tři nové.

Otázka je proto nasnadě: “Dokáže log management věci skutečně zjednodušit?”

Ten nejsilnější argument leží v problematice dostupnosti dat. Jak už jsme uvedli, je běžné, že se starší logy přesouvají do tzv. cold storage. Ta je sice finančně méně náročná, ale data nejsou okamžitě dostupná a prohledatelná. Řešení typu Logmanager tyto problémy odstraňují, data jsou připravená a fulltextově dohledatelná týdny i měsíce zpětně. Vyšetřování incidentu se tedy výrazně zjednodušuje, protože specialisté už nemusí řešit, jestli budou data dostupná, zda nebude potřeba je upravovat, nebo jak dlouho potrvá se k nim dostat.

Pokročily log management navíc výrazně zvyšují flexibilitu zpracování dat. Místo spoléhání na předem definované pipeline nebo nutnosti psát vlastní skripty mohou týmy pracovat s daty pomocí vizuálního rozhraní. Parsing, normalizace, obohacení, všechny kroky, které z raw logů dělají smysluplná data, lze navrhovat a upravovat vizuálně, bez potřeby psát kód.

To má zásadní dopad. Nejde jen o to, že se systém lépe používá, ale i o to, že se snáze přizpůsobuje. Když se objeví nový zdroj logů nebo se změní formát toho stávajícího, není potřeba rozjíždět vývojový cyklus. Úpravu zvládnou přímo lidé, kteří datům rozumí.

Synergie dvou světů

Sbírat logy dnes umí téměř každý. Skutečná výzva je ale v tom, jestli je možné s daty efektivně pracovat ve chvíli, kdy je opravdu potřebujete. A to se v praxi ne vždy daří vzhledem k jejich neideální podobě a zároveň tlaku na rychlou reakci, když se něco stane.

Mezivrstva mezi prostým logováním a SIEM, kterou představuje řešení Logmanager, tento problém smazává. Umí proměnit roztříštěné logy z různých systémů v strukturovaná a obohacená data, která jsou rychle dohledatelná a zároveň připravená pro odeslání do dalších systémů nebo prokázání souladu s předpisy (compliance).

Lze je tak využívat přímo v rámci Logmanageru pro vyšetřování, analýzu i každodenní přehled o dění. Pro mnoho týmů je to plně dostačující, získají odpovědi, které potřebují, bez nutnosti zavádět další vrstvy.

Pokud ale organizace používá SIEM nebo jeho nasazení plánuje, stejná data lze poslat dál. Ne v původní, surové podobě, ale už jako připravený vstup, filtrovaný, normalizovaný, obohacený. Výsledkem je vyšší kvalita dat, nižší objem a smysluplnější signály.

To mění nejen způsob práce, ale i ekonomiku celého řešení. Místo toho, aby organizace platily za ingest všech dat, posílají jen to, co skutečně potřebují. A místo ladění pravidel nad hlučnými vstupy pracují s daty, která dávají smysl.

Logmanager tak nejen propojuje dva světy, ale umožňuje jejich synergii.