Napjainkban elengedhetetlen rendszereink naplózása. Miért is vált fontossá ez ennyire? Naplóink értelmezése és elemzése a gyakorlatban minden olyan területen hasznunkra válhat, ami csak előfordulhat egy IT rendszerben. Mind biztonsági, mind üzemeltetési szempontokból rengeteg előnyünk származhat egy jól működő naplózó rendszerből. Mégis miért hanyagolják el ezt a területet olyan sokan?
A válasz talán a probléma komplexitásában rejlik, hisz még egy jól konfigurált naplózás esetén is cégmérettől függően a napi több ezer bejegyzéstől a több millióig terjedhet a rögzített események száma. Hibakeresés és egyéb felderítés céljából bár minden illetékes rendszergazda elemzi az általa felügyelt rendszereket, de így könnyen előfordulhat, hogy az összefüggő információk együttes többletértéke nem kerül előtérbe az elemzések elkülönüléséből fakadóan. Magyarán ha az egymással nem kommunikáló windowsos, hálózatos és tűzfalas rendszergazdák a saját rendszerükben észlelt egyidejű üzemzavarról nem értekeznek, akkor lehet, hogy soha ki sem derül, hogy egy rosszindulatú támadó keze van a dologban. Márpedig az éles hibák elhárítása során esetlegesen kialakult „pánikhelyzetben” ritkán jellemző, hogy egymástól viszonylag független területek konzultáljanak egymással, amíg arra a következtetésre nem jutnak, hogy a hiba megszüntetéséhez segítségül kell hívni a társterületet. Ez általában már csak a munka utáni sörözéskor bukik ki, hogy a területek rendszergazdái meglátják az összefüggést, miután mindenki elmesélte a többieknek, milyen nehéz napja is volt. Mit lehet tenni, hogy elkerüljük az események magasabb szinten való elemzésének hiányában keletkező információveszteséget? A probléma megoldása egyértelműen a központosított loggyűjtés irányába mutat, de ha ránézünk a számokra, méretekre, könnyen beláthatjuk, hogy ekkora eseménymennyiséget manuálisan képtelenség feldolgozni.
A piacnak a problémára több ingyenes és fizetős megoldása is van. Ezek nem mások, mint a központi logelemző / logmenedzselő rendszerek, azaz a SIMS–ek (security information management system). Ezek a megoldások képesek a beáramló naplókat fogadni és különböző korrelációs szabályrendszerrel feldolgozni. Így egy jól kidolgozott szabályhierarchiával képesek lehetünk közel realtime észlelni problémáink forrását (fenti példánkban egy támadási diagram generálásával) és magát a kiváltó okot megszüntetni.
Hogyan is néz ki egy tipikus SIMS? Jellemzően rendelkeznek loggyűjtő és normalizáló , valamint korrelátor modullal, az események strukturált tárolására pedig valamilyen adatbázis megoldást használnak. A loggyűjtő hivatott fogadni a naplókat, melyet a normalizátor alakít a korrelátor számára megfelelő formára, megőrizve az eseménybejegyzések integritását. A korrelátor modul a szabályrendszer alapján incidenseket generál, melyeket a szerepkör alapú hozzáférésekkel rendelkező személyzet kezel a vállalat hatályos incidenskezelési szabályzata vagy eljárásrendje alapján.
Az architektúra kialakításának nehézsége abban rejlik, hogy manapság egy vállalati infrastruktúra meglehetősen sokféle komponensből állhat, melyeknek naplózási mechanizmusai eltérőek lehetnek. Tipikusan történhet a naplózás fájlba, adatbázisba vagy syslog szerű megoldásokkal. SIMS –ünket úgy kell megválasztanunk, hogy az a lehető legjobban illeszkedjen az általunk felügyelt környezetbe, és az üzleti és IT stratégiákat figyelembe véve a legjobban illeszkedjen a tervezett fejlesztésekhez is, legyen az infrastrukturális vagy szoftver.
Új gyári rendszerek bevezetésénél (pl. operációs rendszerek) általában a naplózási funkció adott, így ezen a vonalon sok teendő nincsen, mindössze a kompatibilis / nem kompatibilis feltételt kell megvizsgálnunk SIMS-ünk esetében, ami esetlegesen befolyásolhatja eszközválasztásainkat. Egyedi, saját fejlesztéseink esetén azonban már más a helyzet. Ezen esetekben célszerű tudatosan abba az irányba terelni a dolgok menetét, ami biztonságunk és SIMS –ünk számára kedvezőbb. Annak hogy egy napló mennyire legyen bőbeszédű, egyedi fejlesztések esetén gyakorlatilag csak a képzeletünk – meg az erre allokált büdzsé –határozza meg. Azonban célszerű a naplózási kritériumokat úgy specifikálni, hogy lehetőleg a fejlesztendő rendszer ne a SIMS –ünk áteresztőképességét legyen hivatott tesztelni, hanem csak a számunkra releváns és fontos információkat naplózza le.
Azt gondolom, hogy nagy vonalakban sikerült megvilágítanom, hogy miért is fontos figyelmet szentelnünk a naplózásra és az események feldolgozására, valamint bepillantottunk egy tipikus naplóelemző rendszer felépítésébe is, ahol meghatároztunk pár szempontot a bevezetéshez és követéshez. Azonban ahhoz, hogy egy ilyen architektúra megfelelően működjön, a forrásoldalaknak is jól konfiguráltnak kell lenniük. A következő cikk ebbe a témában íródik majd.
