A korábbi cikkekben kicsit megismerkedtünk az ELK stack-kel és a Logstash konfigurációs fájl beállításával a naplóelemző számára, ebben a cikkben a legfontosabb dologra térünk át az elemzés szempontjából: arra, amit látni szeretnél a rendszertől, és amiért mindez létrejött — ezek a grafikonok és táblázatok, amelyek össze vannak kapcsolva a dashboardokkal. Ma közelebbről megismerkedünk a vizualizáló rendszerrel, Kibanamegnézzük, hogyan készíthetünk grafikonokat, táblázatokat, és ennek eredményeként felépítünk egy egyszerű dashboardot a Check Point tűzfal naplóiból.
A kibanával való munka első lépése egy index mintázat. Logikailag ez az indexek közötti logikai alapelv. Természetesen ez kizárólag arról szól, hogy a Kibana kényelmesebben kereshessen információkat az összes index között egyszerre. Ez úgy van beállítva, hogy egy string összehasonlítással, például “checkpoint-*” és az index nevével történik. Például a „checkpoint-2019.12.05” megfelel a mintának, míg a csak „checkpoint” már nem. Külön említést érdemel, hogy a keresés során nem lehet egyszerre különböző index mintákra keresni, később a következő cikkekben látni fogjuk, hogy az API-kérések vagy az index név alapján, vagy éppen a mintázaton keresztül történnek, a kép kattintható:
Ezután ellenőrizzük a Discover menüben, hogy minden napló indexelve van, és a helyes elemző be van állítva. Ha bármilyen eltérést találunk, például a típus megváltoztatása stringről egész számra, szerkeszteni kell a Logstash konfigurációs fájlt, ennek eredményeként az új naplók helyesen fognak rögzülni. Ahhoz, hogy a régi naplók a módosítás előtt a kívánt formátumban jelenjenek meg, csak a reindexelési folyamat segít, a következő cikkekben ezt a műveletet részletesebben fogjuk megvizsgálni. Biztosítsuk, hogy minden rendben van, a kép kattintható:
A naplók a helyükön vannak, így elkezdhetjük a dashboardok felépítését. A biztonsági termékek dashboardjaiból származó analitika alapján megérthetjük a szervezeti információbiztonság állapotát, vizuálisan láthatjuk a jelenlegi politika sebezhető pontjait, és a jövőben kidolgozhatjuk a megszüntetésük módjait. Készítünk egy kicsi dashboardot, használva néhány vizualizáló eszközt. A dashboard 5 komponensből fog állni:
- táblázat az összes napló számának összesítésére a blade-ek alapján
- táblázat a kritikus IPS aláírásokról
- kördiagram a Threat Prevention eseményeiről
- diagram a legnépszerűbb weboldalak látogatottságáról
- diagram a legveszélyesebb alkalmazások használatáról
A vizualizációs alakzatok létrehozásához lépjünk a menübe Visualize, és válasszuk ki a kívánt alakzatot, amelyet meg akarunk alkotni! Haladjunk lépésről lépésre.
Tábla a bleydekre vonatkozó logok összesítő számának kiszámításához
Ehhez válasszuk ki az alakzatot Adattábla, belépünk a grafikonok létrehozásának eszközébe, bal oldalon az alakzat beállításait adjuk meg, jobbra pedig azt, hogy jelenlegi beállításaink mellett hogyan fog kinézni. Először bemutatom, hogyan fog kinézni a kész tábla, ezt követően pedig végigmegyünk a beállításokon, a kép kattintható:
Részletesebb alakzatbeállítások, a kép kattintható:
Nézzük át a beállításokat.
Először is beállítandó metrika, ez az érték, amely szerint az összes mezőt aggregálni fogjuk. A metrikák az adott módon dokumentumokból kinyert értékek alapján számítódnak. Az értékek általában a mezők dokumentumból, de script-ekkel is generálhatók. Ebben az esetben ezt az értéket állítjuk be Aggregation: Count (a logok összes száma).
Ezt követően a táblázatot szegmensek (mezők) szerint osztjuk fel, azaz ezen beállítás segítségével történik a metrika kiszámítása. E funkciót a Buckets beállítás látja el, amely kétféleképpen konfigurálható:
- split rows — oszlopok hozzáadása, és a táblázat későbbi sorokra való felosztása
- split table — felosztás több táblázatra egy adott mező értékei szerint.
A buckets. Több felosztást is hozzáadhatunk, hogy több oszlopot vagy táblázatot készítsünk, a korlátok inkább logikai természetűek. Az aggregációnál kiválaszthatjuk, hogy milyen módon történjen a felosztás a szegmensekre: ipv4 tartomány, dátumtartomány, Terms stb. A legérdekesebb választás a Terms és Significant Terms, a felosztás az index egy adott mezőjének értékei alapján történik, a közöttük lévő különbség a visszaadott értékek számában és azok megjelenítésében rejlik. Mivel a táblázatot a bleydek neve szerint szeretnénk felosztani, kiválasztjuk a mezőt — product.keyword és megadjuk a méretet 25 visszaadott értékben.
Az Elasticsearch-ban sorok helyett 2 típusú adat létezik — szöveg és kulcsszó. Ha teljes szöveges keresést szeretne végezni, a text típust kell használnia, ami nagyon hasznos, ha saját keresőszolgáltatást ír, például szeretnék megtalálni egy szó említését egy mező (szöveg) konkrét jelentésében. Ha csak pontos egyezést szeretne, a keyword típust kell használnia. A keyword adattípust olyan mezőknél is érdemes használni, amelyek rendezést vagy aggregálást igényelnek, tehát az esetünkben.
Ennek eredményeként az Elasticsearch számolja a logok számát egy adott idő alatt, aggregálva a product mező értékét. A Custom Label mezőben adjuk meg az oszlop nevét, amely meg fog jelenni a táblázatban, beállítjuk az időtartamot, ameddig összegyűjtjük a logokat, elindítjuk a vizualizációt — a Kibana küld egy lekérdezést az elasticsearch-nek, várja a választ, majd vizualizálja az adatokat. A táblázat készen áll!
Kördiagram a Threat Prevention eseményekről
Különös érdeklődést mutat az információ, hogy hány reakció van a hozzávetőleges arányban detect és prevent a kiberbiztonsági eseményekkel kapcsolatosan a jelenlegi biztonsági politikában. Ilyen esetben jól mondható, hogy a kördiagram megfelelő. Válasszuk a Visualize opciót — Pie chart. A metrikában az aggregációt a logok számával is beállítjuk. A buckets mezőbe a Terms => action legyen beállítva.
Úgy tűnik, minden rendben van, de az eredmények minden blade-re vonatkoznak, tehát csak azon blade-eket kell kiszűrnünk, amelyek a Threat Prevention keretein belül működnek. Ezért mindenképpen beállítjuk a szűrőt hogy csak az információkat keressük azokkal a blade-ekkel kapcsolatban, amelyek a kiberbiztonsági eseményekért felelnek — product: („Anti-Bot” VAGY „New Anti-Virus” VAGY „DDoS Protector” VAGY „SmartDefense” VAGY „Threat Emulation”). A kép kattintható:
És további részletes beállítások, a kép kattintható:
Táblázat az IPS eseményekről
Ezután a kiberbiztonság szempontjából nagyon fontos az események megtekintése és ellenőrzése a blade-en Az IPS Blade hibát okozhat a szabályzat telepítésekor az NGFW-don, ha túl sok aláírást használsz. A Check Point szerint és Fenyegetés Emanáció, akik nem blokkolódnak a jelenlegi politikák szerint, hogy a jövőben vagy átválthassuk a szignatúrát prevent állapotba, vagy ha a forgalom érvényes — ne ellenőrizzük a szignatúrát. A táblázatot ugyanúgy hozzuk létre, mint az első példánál, csak azzal a különbséggel, hogy több oszlopot hozunk létre: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. Mindenképpen beállítunk egy szűrőt, hogy csak az információkat keressük azokkal a blade-ekkel kapcsolatban, amelyek a kiberbiztonsági eseményekért felelnek — product: ( „SmartDefense” VAGY „Threat Emulation”). A kép kattintható:
További részletes beállítások, a kép kattintható:
Diagramok a leglátogatottabb weboldalakról
Ehhez létrehozunk egy alakzatot — Vertikális oszlop. A metrikát szintén a count (Y tengely) segítségével használjuk, míg az X tengelyen a látogatott weboldalak neveit — "appi_name"-t fogjuk használni. Itt van egy kis trükk: ha a beállításokat az aktuális verzióval indítjuk, akkor az összes weboldal egy színnel fog jelölve lenni a grafikonon, ezért hogy színesebbé tegyük őket, egy extra beállítást használunk — a "split series"-t, amely lehetővé teszi, hogy a már elkészült oszlopot több értékre osszuk, természetesen a választott mezőtől függően! Ezt az osztást használhatjuk egy színes oszlopként az értékek szerint stacked módban, vagy normál módban, hogy több oszlopot hozzunk létre az X tengely egy adott értéke szerint. Ebben az esetben itt ugyanazt az értéket használjuk, mint az X tengelyen, ami lehetővé teszi számunkra, hogy az összes oszlopot különböző színűre fessük, a jobb felső sarokban színekkel lesznek megjelölve. A szűrőben beállítjuk — product: "URL Filtering" annak érdekében, hogy csak a látogatott weboldalakra vonatkozó információt lássuk, a kép kattintható:
Beállítások:
Diagram a legveszélyesebb alkalmazások használatáról
Ehhez létrehozunk egy alakzatot — Vertical Bar. A metrikát szintén a count (Y tengely) segítségével használjuk, míg az X tengelyen a használt alkalmazások neveit — "appi_name"-t fogjuk használni. A legfontosabb a szűrő beállítása — product: "Application Control" AND app_risk: (4 OR 5 OR 3 ) AND action: "accept". A naplókat az Application Control blade segítségével szűrjük, csak azokat a weboldalakat vesszük figyelembe, amelyeket Critical, High, Medium kockázatú weboldalként kategorizáltak, és csak abban az esetben, ha ezekhez a weboldalakhoz a hozzáférés engedélyezett. A kép kattintható:
Beállítások, kattintható:
Irányítópult
A műszerfalak megtekintése és létrehozása külön menüpontban található — Mérőműsor. Itt minden egyszerű: létrehozunk egy új műszerfalat, hozzáadjuk a vizualizációt, elhelyezzük a helyükre, és ennyi!
Létrehozunk egy műszerfalat, amely alapján megérthetjük az információbiztonság alapvető helyzetét a szervezetben, természetesen csak a Check Point szintjén, a kép kattintható:
Ezekből a grafikonokból megérthetjük, hogy mely kritikus aláírások nincsenek blokkolva a tűzfalon, hová járnak a felhasználók, és melyek a legveszélyesebb alkalmazások, amelyeket használnak.
Zárás
Megvizsgáltuk a Kibana alapvető vizualizációs lehetőségeit és létrehoztunk egy műszerfalat, de ez csak a kezdet. A tanfolyam következő részében külön foglalkozunk a térképek beállításával, az elasticsearch rendszer működésével, megismerkedünk az API lekérdezésekkel, az automatizálással és még sok mással!
Úgyhogy kövessétek az frissítéseket (, , , ), .
Forrás: habr.com
