Jó napot, korábbi cikkekben megismerkedtünk az ELK Stack munkájával. Most pedig arról lesz szó, hogy milyen lehetőségeket tud megvalósítani egy információbiztonsági szakember e rendszerek használatában. Milyen rönköket lehet és kell hozzáadni az elaszticsearch-hez. Nézzük meg, milyen statisztikák érhetők el a műszerfalak beállításával, és hogy van-e ebből nyereség. Hogyan valósíthatom meg az információbiztonsági folyamatok automatizálását az ELK verem segítségével? Készítsük el a rendszer architektúráját. Összegezve, az összes funkció megvalósítása nagyon nagy és nehéz feladat, ezért a megoldás külön nevet kapott - TS Total Sight.
Jelenleg egyre népszerűbbek azok a megoldások, amelyek az információbiztonsági incidenseket egy logikai helyen konszolidálják és elemzik, ennek eredményeként a szakember statisztikákat és cselekvési frontot kap a szervezet információbiztonsági állapotának javítására. Ilyen feladatot tűztünk ki magunk elé az ELK verem használatában, ennek eredményeként a fő funkcionalitást 4 szakaszban különítettük el:
- Statisztika és vizualizáció;
- IS események észlelése;
- Az események rangsorolása;
- Információbiztonsági folyamatok automatizálása.
Nézzük meg mindegyiket közelebbről részletesebben.
Információbiztonsági események észlelése
Az elasticsearch használatának fő feladata esetünkben csak az információbiztonsági incidensek összegyűjtése. Az információbiztonsági incidenseket bármilyen védelmi eszközből gyűjtheti, ha legalább néhány naplóátviteli módot támogat, a szabványos a syslog vagy scp fájlba mentés.
Adhat szabványos példákat a védelmi eszközökre, és nem csak arról, hogy honnan kell konfigurálnia a naplók továbbítását:
- Bármilyen NGFW alap (Check Point, Fortinet);
- Bármilyen sebezhetőségi szkenner (PT Scanner, OpenVas);
- Webalkalmazási tűzfal (PTAF);
- Netflow analizátorok (Flowmon, Cisco StealthWatch);
- AD szerver.
Miután beállította a Logstash-t naplók és konfigurációs fájlok küldésére, összevetheti és összehasonlíthatja a különféle biztonsági eszközökből származó incidenseket. Ehhez célszerű indexeket használni, amelyekben az adott eszközzel kapcsolatos összes incidenst eltároljuk. Más szavakkal, egy index egy eszköz összes incidense. Ez az elosztás kétféleképpen valósítható meg.
Az első lehetőség a Logstash konfigurációjának konfigurálása. Ehhez meg kell másolnia bizonyos mezők naplóját egy külön egységbe, eltérő típussal. Aztán később használja ezt a típust. A példa klónok a Check Point tűzfal IPS paneljéről naplózzák.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
Annak érdekében, hogy az ilyen eseményeket külön indexben tárolja a naplók mezőitől függően, például a támadási aláírás cél IP-jétől. Használhat hasonló konstrukciót:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
És ily módon az összes eseményt elmentheti az indexbe, például IP-cím vagy a gép tartományneve alapján. Ebben az esetben az indexben tároljuk "smartdefense-%{dst}", az aláírási cél IP-címe alapján.
A különböző termékek azonban eltérő naplómezőkkel rendelkeznek, ami káoszt és elvesztegetett memóriát eredményez. És itt vagy gondosan ki kell cserélni a Logstash konfigurációs beállításaiban lévő mezőket előre megtervezettekre, amelyek minden típusú incidens esetén azonosak lesznek, ami szintén nehéz feladat.
Második megvalósítási lehetőség - ez egy szkript vagy folyamat írása, amely valós időben hozzáfér a rugalmas bázishoz, kihúzza a szükséges incidenseket, és elmenti őket egy új indexbe, ez nehéz feladat, de lehetővé teszi, hogy tetszés szerint dolgozzon a naplókkal , és közvetlenül korrelálnak más biztonsági eszközökből származó incidensekkel. Ezzel az opcióval maximális rugalmassággal testreszabhatja a naplókkal végzett munkát a lehető leghasznosabb módon, de itt gondot okoz az ezt megvalósító szakember megtalálása.
És persze a legfontosabb kérdés mit lehet korrelálni és kimutatni?
Itt több lehetőség is lehet, és attól függően, hogy milyen biztonsági eszközöket használnak az infrastruktúrában, néhány példa:
- A legkézenfekvőbb és az én szempontomból a legérdekesebb lehetőség azok számára, akik rendelkeznek NGFW megoldással és sebezhetőségi szkennerrel. Ez az IPS-naplók és a sebezhetőségi vizsgálat eredményeinek összehasonlítása. Ha támadást észlelt (nem blokkolt) az IPS rendszer, és ezt a biztonsági rést a vizsgálat eredménye alapján nem zárják le a véggépen, akkor minden csövet ki kell fújni, mert nagy a valószínűsége annak, hogy a sérülékenység kihasználva.
- Sok bejelentkezési kísérlet egy gépről különböző helyekre rosszindulatú tevékenységet szimbolizálhat.
- Vírusfájlok letöltése a felhasználó által, mivel rengeteg potenciálisan veszélyes webhelyet látogat meg.
Statisztika és vizualizáció
Az ELK Stack legnyilvánvalóbb és legérthetőbb célja a rönkök tárolása és megjelenítése, megmutatták, hogyan szerezhet be naplókat különböző eszközökről a Logstash segítségével. Miután a naplók az Elasticsearch-ba kerültek, beállíthatja a műszerfalakat, amelyekről szintén szó esett , a vizualizáció révén szükséges információkkal és statisztikákkal.
Példák:
- Veszélymegelőzési események irányítópultja a legkritikusabb eseményekkel. Itt tükrözheti, hogy mely IPS-aláírásokat észlelték, és honnan származnak földrajzilag.
- Irányítópult a legkritikusabb alkalmazások használatáról, amelyekről információ szivároghat ki.
- Vizsgálja be az eredményeket bármely biztonsági szkennerről.
- A felhasználók naplózzák az Active Directoryból.
- VPN-kapcsolat irányítópultja.
Ebben az esetben, ha beállítja, hogy az irányítópultok néhány másodpercenként frissüljenek, egy meglehetősen kényelmes rendszert kaphat az események valós idejű megfigyelésére, amely azután a lehető leggyorsabban reagálhat az információbiztonsági incidensekre, ha irányítópultokat helyez el egy külön képernyő.
Az események prioritása
Nagy infrastruktúra körülményei között az incidensek száma lecsökkenhet, és a szakembereknek nem lesz idejük minden incidenst időben elemezni. Ebben az esetben mindenekelőtt csak azokat az eseményeket kell kiemelni, amelyek nagy veszélyt hordoznak magukban. Ezért a rendszernek prioritást kell adnia az incidenseknek a súlyosságuk szerint az infrastruktúrához képest. Célszerű ezekről az eseményekről levélben vagy táviratban értesítést beállítani. A prioritások meghatározása a szokásos Kibana eszközökkel, a vizualizáció beállításával valósítható meg. Értesítéssel viszont nehezebb, alapértelmezés szerint ez a funkció az Elasticsearch alapverziójában nem, csak a fizetős verzióban szerepel. Ezért vagy vásároljon fizetős verziót, vagy ismét írjon egy folyamatot, amely valós időben értesíti a szakembereket levélben vagy táviratban.
Információbiztonsági folyamatok automatizálása
Az egyik legérdekesebb rész pedig az információbiztonsági incidensekre vonatkozó műveletek automatizálása. Korábban ezt a funkciót a Splunk számára implementáltuk, ebben egy kicsit többet olvashat . Az alapötlet az, hogy az IPS házirendet soha nem tesztelik vagy optimalizálják, bár bizonyos esetekben az információbiztonsági folyamatok elengedhetetlen része. Például egy évvel az NGFW megvalósítása és az IPS optimalizálására irányuló műveletek hiánya után nagyszámú aláírás gyűlik össze a Detect művelettel, amelyek nem lesznek blokkolva, ami nagymértékben csökkenti a szervezet információbiztonsági állapotát. Íme néhány példa arra, hogy mit lehet automatizálni:
- Az IPS-aláírás átváltása Detect (Érzékelés) állapotról Megakadályozásra. Ha a Prevent nem működik a kritikus aláírásokon, akkor ez nem megfelelő, és súlyosan megsérti a védelmi rendszert. A szabályzatban szereplő műveletet az ilyen aláírásokra változtatjuk. Ez a funkció akkor valósítható meg, ha az NGFW eszköz rendelkezik a REST API funkcióval. Ez csak akkor lehetséges, ha rendelkezik programozási ismeretekkel, ki kell húznia a szükséges információkat az Elastcisearch-ból, és API kéréseket kell végrehajtania az NGFW vezérlőszerver felé.
- Ha egy IP-címről sok aláírást észleltek vagy blokkoltak a hálózati forgalomban, akkor érdemes ezt az IP-címet egy ideig letiltani a tűzfalházirendben. A megvalósítás a REST API használatából is áll.
- Indítson el gazdagép-ellenőrzést egy sebezhetőség-ellenőrzővel, ha ez a gazdagép nagyszámú aláírással rendelkezik az IPS-hez vagy más biztonsági eszközökhöz, ha OpenVas, akkor írhat egy szkriptet, amely ssh-n keresztül csatlakozik a biztonsági szkennerhez, és futtatja a vizsgálatot.
TS Total Sight
Összefoglalva, az összes funkció megvalósítása nagyon nagy és nehéz feladat. Programozási ismeretek nélkül beállíthatja a minimális funkcionalitást, ami elegendő lehet a termelékenységhez. De ha érdekli az összes funkció, akkor figyeljen a TS Total Sight-ra. További részleteket nálunk talál . Ennek eredményeként a munka és az építészet teljes sémája így fog kinézni:
Következtetés
Megnéztük, mit lehet megvalósítani az ELK Stack segítségével. A következő cikkekben külön-külön részletesebben megvizsgáljuk a TS Total Sight funkcionalitását!
Szóval maradj velünk, , , ), .
Forrás: will.com