Jó napot, az előző cikkekben megismerkedtünk az ELK Stack működésével. Most beszéljünk azokról a lehetőségekről, amelyeket az IT-biztonsági szakember ki tud használni ezeknek a rendszereknek a révén. Milyen naplókat érdemes és szükséges létrehozni az Elasticsearch-ban. Megfontoljuk, milyen statisztikákat kaphatunk a műszerfalak beállításával, és van-e ebben haszon. Milyen módon lehet az IT-biztonsági folyamatokat automatizálni az ELK Stack használatával. Összeállítjuk a rendszer működésének architektúráját. Összességében a teljes funkcionalitás megvalósítása nagyon nagy és nehéz feladat, ezért a megoldást egy külön név alatt - TS Total Sight - emeltük ki.
Jelenleg egyre népszerűbbek azok a megoldások, amelyek egy logikai helyen konszolidálják és elemzik az IT-biztonsági eseményeket, így a szakember statisztikát és cselekvési keretet kap a szervezet IT-biztonsági helyzetének javítására. Ezt a feladatot tűztük ki az ELK Stack használatára, ennek eredményeként négy fő funkcióra osztottuk:
- Statisztika és vizualizáció;
- IT-biztonsági incidensek észlelése;
- Incidensprioritás;
- IT-biztonsági folyamatok automatizálása.
Most részletesebben nézzük meg ezeket külön-külön.
IT-biztonsági incidensek észlelése
Az Elasticsearch használatának fő célja ebben az esetben kizárólag az IT-biztonsági incidensek gyűjtése. Az IT-biztonsági eseményeket bármilyen védelmi eszközből lehet gyűjteni, amennyiben támogatják a naplók átküldésének bármilyen módját, a hagyományos megoldás a syslog vagy a scp által fájlba történő mentés.
Szokásos példákat lehet említeni a védelmi eszközökre, amelyekből be kell állítani a naplók átküldését:
- Bármilyen NGFW eszköz (Check Point, Fortinet);
- Bármilyen sebezhetőségi szkenner (PT Scanner, OpenVas);
- Webalkalmazás tűzfal (PT AF);
- Netflow elemzők (Flowmon, Cisco StealthWatch);
- AD szerver.
Miután beállítottuk a naplók és a konfigurációs fájlok küldését a Logstash-ba, összekorrelálhatjuk és összehasonlíthatjuk az incidenseket, amelyek különböző biztonsági eszközöktől érkeznek. Ehhez kényelmesen használhatjuk az indexeket, amelyekben tárolni fogjuk az adott eszközhöz kapcsolódó összes incidenst. Más szóval, egy index minden incidens egy eszközhöz. Ezt az elosztást két módon lehet megvalósítani.
Első lehetőség: Ez a Logstash konfigurálása. Ehhez szükséges a napló bizonyos mezői alapján külön egységként, más típussal való másolása. Majd a későbbiekben ezt a típust használni. A példában az IPS tűzfal Check Point naplóit másolják.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
Ahhoz, hogy az ilyen eseményeket külön indexbe menthessük, a naplómezők, például az attack signature Destination IP alapján. Használhatunk hasonló szerkezetet:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
Így elérhetjük, hogy az összes incidens, például IP cím vagy gép domain neve alapján kerüljön mentésre az indexbe. Ebben az esetben az indexbe mentjük „smartdefense-%{dst}“, az attack signature alapján lévő IP cím szerint.
Azonban különböző termékek eltérő mezőket fognak használni a naplókhoz, ami káoszhoz és felesleges memóriafogyasztáshoz vezet. Itt vagy gondosan kell a Logstash konfigurációs beállításokban kicserélni a mezőket előre megtervezettekre, amelyek minden incident típus számára azonosak, ami szintén egy nehéz feladat.
A megvalósítás második lehetősége — egy szkript vagy folyamat írása, amely valós időben lép kapcsolatba az Elastic adatbázissal, és kiemeli a szükséges incidenseket, majd új indexbe menti őket, ez nehéz feladatnak számít, de lehetővé teszi a naplókkal való szabad munkát és a közvetlen korrelációt más biztonsági eszközökkel. Ez a lehetőség a naplókkal való munkát a lehető legjobban a specifikus esethez igazítja a maximális rugalmassággal, de felmerül a probléma, hogy milyen szakember képes ezt megvalósítani.
És természetesen a legfontosabb kérdés, hogy mit lehet egyáltalán korrelálni és felfedezni?
Itt több lehetőség is van, és attól függ, hogy milyen biztonsági eszközöket használnak az infrastruktúrában, pár példa:
- A legnyilvánvalóbb és véleményem szerint a legérdekesebb lehetőség azok számára, akik rendelkeznek NGFW megoldással és sebezhetőségi szkennerrel. Ez a naplók összehasonlítása az IPS és a sebezhetőségi vizsgálatok eredményei között. Ha az IPS rendszer érzékelte a támadást (nem blokkolta), és ez a sebezhetőség nem záródott le a végső gépen a szkennelés eredményei alapján — akkor nagy valószínűséggel ki kell kiáltani, mivel van egy jelentős lehetőség arra, hogy a sebezhetőséget kihasználták.
- Sok bejelentkezési kísérlet egy gépről különböző helyekre zavaró aktivitást szimbolizálhat.
- Fertőzött fájlok letöltése a felhasználó által, rengeteg potenciálisan veszélyes weboldal látogatása miatt.
Statisztika és vizualizáció
A legnyilvánvalóbb és legegyszerűbb ok, amiért az ELK Stack szükséges — a naplók tárolása és vizualizálása. megmutatták, hogyan lehet naplókat gyűjteni különböző eszközöktől, Logstash használatával. Miután a naplók az Elasticsearch-ba kerülnek, beállíthatók a műszerfalak, amelyekről szintén szó esett , a szükséges információkkal és statisztikákkal a vizualizáció révén.
Példák:
- Műszerfal a Threat Prevention eseményekkel a legkritikusabb eseményekkel. Itt tükrözni lehet, hogy mely IPS aláírásokat észlelték és honnan érkeztek földrajzilag.
- Műszerfal a legkritikusabb alkalmazások használatáról, amelyek információk kiszivárgását okozhatják.
- Bármilyen biztonsági szkenner által generált szkennelési eredmények.
- Active Directory naplók felhasználók szerint.
- Műszerfal a VPN kapcsolatokhoz.
Ebben az esetben, ha a műszerfalakat néhány másodpercenként frissítjük, egy kényelmes rendszert kaphatunk az események valós idejű nyomon követésére, amit később a kibervédelmi incidensek gyors reagálására használhatunk, ha a műszerfalakat külön képernyőn állítjuk be.
Az incidensek priorizálása
Nagy infrastruktúrák esetén az incidensek száma megugorhat, és a szakemberek nem biztos, hogy időben fel tudják dolgozni az összes incidenst. Ebben az esetben elsődlegesen csak azokat az incidenseket kell kiemelni, amelyek jelentős veszélyt jelentenek. Ezért a rendszernek priorizálnia kell az incidenseket a veszélyességük alapján az infrastruktúrájára nézve. Ajánlott értesítést beállítani e-mailbe vagy Telegramra az ilyen eseményekről. A priorizálást a Kibana beépített eszközeivel lehet megvalósítani, vizualizáció beállításával. Az értesítések beállítása azonban nehezebb, ugyanis alapértelmezés szerint ez a funkció nincs bekapcsolva az Elasticsearch ingyenes verziójában, csak a fizetősben. Tehát vagy meg kell vásárolni a fizetős verziót, vagy saját magunknak kell írni egy folyamatot, amely valós időben értesíti a szakembereket e-mailben vagy Telegramon.
Az IT-biztonsági folyamatok automatizálása
Az egyik legérdekesebb rész a IT-biztonsági incidensek automatikus kezelése. Korábban ezt a funkciót a Splunk számára valósítottuk meg, részleteket olvashat erről itt . Az alapvető ötlet az, hogy az IPS politika soha nincs ellenőrizve és optimalizálva, pedig bizonyos esetekben ez a folyamatok kulcsfontosságú része a kibervédelemben. Például egy évvel az NGFW bevezetése után, és az IPS optimalizálásának hiányában, rengeteg Detect akcióval rendelkező jel érkezik, amelyeket nem blokkolnak, ami jelentősen csökkenti a vállalat IT-biztonsági állapotát. Íme néhány példa arra, amit automatizálni lehet:
- Az IPS jel átkonfigurálása Detect-ről Prevent-re. Ha a kritikus jelzéseknél nem működik a Prevent, az nem megfelelő, és komoly hiányosságot jelent a védelmi rendszerben. Az ilyen jelzések politikai akcióját meg kell változtatni. Ezt a funkciót csak akkor lehet megvalósítani, ha az NGFW eszköz REST API funkcióval rendelkezik. Ez programozási készségeket igényel; szükséges visszanyerni a szükséges adatokat az Elasticsearchból és API-kéréseket végrehajtani az NGFW vezérlőszerverén.
- Ha egy IP címen a hálózati forgalomban sok jelzés került felfedezésre vagy blokkolásra, akkor van értelme egy időre blokkolni ezt az IP címet a tűzfal politikában. A megvalósítás szintén REST API használatával történik.
- Futtasson biztonsági sebezhetőségi vizsgálatot a hoston, ha a hostra nagy mennyiségű IPS vagy más biztonsági eszköz által generált aláírás vonatkozik. Ha ez OpenVas, írhatsz egy scriptet, amely SSH-n keresztül csatlakozik a biztonsági szkennerhez és elindítja a szkennelést.
TS Total Sight
Összességében az összes funkcionalitás megvalósítása nagyon nagy és nehéz feladat. Programozási ismeretek nélkül beállítható egy minimális funkcionalitás, amely elegendő lehet a termeléshez. De ha az összes funkcionalitás érdekel, érdemes megfontolnod a TS Total Sight-ot. Részletesebben megismerkedhetsz a . Az eredmény az lesz, hogy az egész rendszer és architektúra így fog kinézni:
Zárás
Megvizsgáltuk, hogy mit lehet megvalósítani az ELK Stack segítségével. A következő cikkekben részletesebben áttekintjük a TS Total Sight funkcionalitását!
Úgyhogy kövessétek az frissítéseket (, , , ), .
Forrás: habr.com
