🥇A Flow-protokollok mint a belső hálózat biztonsági monitoringjának eszközei

Amikor a belső vállalati vagy hatósági hálózat biztonsági monitorozásáról van szó, sokakban az információszivárgás ellenőrzése és a DLP-megoldások bevezetése merül fel. Mit szólnál, ha pontosítanánk a kérdést, és megkérdeznénk, hogyan fedezed fel a támadásokat a belső hálózaton? A válasz általában a behatolásérzékelő rendszerek (IDS) említése. Ami 10-20 éve még az egyetlen lehetőség volt, ma már anachronizmusnak számít. Létezik egy hatékonyabb, sőt, egyes esetekben az egyetlen lehetséges módszer a belső hálózat monitorozására — a flow-protokollokat használni, amelyek eredetileg a hálózati problémák keresésére (troubleshooting) készültek, de idővel nagyon érdekes biztonsági eszközzé alakultak. Ebben a cikkben arról fogunk beszélni, hogy milyen flow-protokollok léteznek, és melyek segítenek a legjobban a hálózati támadások észlelésében, hol érdemes a flow monitorozását bevezetni, mire érdemes figyelni a rendszer kiépítésekor, és akár arról is, hogyan lehet mindezt hazai eszközökön működtetni.

Nem fogok megállni a kérdésnél, hogy "Miért szükséges a belső infrastruktúra biztonsági monitorozása?" A válasz nyilvánvaló. De ha mégis szeretnél megbizonyosodni róla, hogy ma már ez elengedhetetlen, nézd meg ez a rövid videó, amely bemutatja, hogy 17 módon lehet behatolni egy tűzfallal védett vállalati hálózatba. Tehát tekintsük úgy, hogy értjük, hogy a belső monitorozás szükséges, és csak annyit kell megértenünk, hogyan szervezhetjük meg.

Három kulcsfontosságú adatforrást emelnék ki a hálózati szintű infrastruktúra monitorozásához:

"nyers" forgalom, amelyet rögzítünk és elemzésre küldünk különböző elemző rendszereknek,
hálózati eszközökből származó események, amelyeken keresztül a forgalom áthalad,
a forgalomrel kapcsolatos információ, amelyet az egyik flow-protokoll alapján kapunk.

A nyers forgalom elfogása a legnépszerűbb választás a biztonsági szakemberek számára, mivel történelmileg ez volt az első lehetőség. A hagyományos behatolás-érzékelő rendszerek (az első kereskedelmi behatolás-érzékelő rendszer a NetRanger volt, amelyet a Wheel Group készített, és 1998-ban vásárolt meg a Cisco) éppen a csomagok (később a szekciók) elfogásával foglalkoztak, amelyekben bizonyos aláírásokat kerestek (“döntési szabályok” a FSTÉK terminológiájában), amelyek támadásokat jeleznek. Nyilvánvaló, hogy a nyers forgalmat nemcsak IDS segítségével lehet elemezni, hanem más eszközökkel is (például Wireshark, tcpdump vagy a Cisco IOS NBAR2 funkciója), de ezek általában nem rendelkeznek azokkal az ismeretekkel, amelyek megkülönböztetik a biztonsági eszközt a szokásos IT-eszközöktől.

Tehát, behatolás-érzékelő rendszerek. A legrégebbi és legnépszerűbb hálózati támadások érzékelési módszer, amely jól teljesít a peremen (függetlenül attól, hogy vállalati, adatközponti, szegmens stb.), de a modern váltó- és szoftveresen definiált hálózatokban nem tud lépést tartani. Ha a hálózatot hagyományos kapcsolókra építik, a támadások érzékelésére szolgáló érzékelő infrastruktúra túl nagy lesz – egy érzékelőt kell telepíteni minden egyes csatlakozásra, amelyhez a támadásokat figyelni szeretné. Minden gyártó természetesen örülne, ha eladna Önnek több száz és ezer érzékelőt, de gondolom, a költségvetése nem bírja el az ilyen kiadásokat. Azt kell mondanom, hogy még a Cisco-nál (mi vagyunk az NGIPS fejlesztői) sem tudtuk ezt megoldani, jóllehet, látszólag az ár kérdése nem állhatott fenn – ez mégis a saját megoldásunk. Ezenkívül kérdés merül fel, hogy hogyan csatlakoztathatjuk az érzékelőt ilyen formában? Kihúzásban? Mi van, ha magának az érzékelőnek hibásodik el? Követelni kell a bypass modul meglétét az érzékelőben? Használjunk elosztókat (tap)? Mindez növeli a megoldás költségeit, és megfizethetetlenné teszi azt bármilyen méretű cég számára.

Megpróbálhatja „ráakasztani” az érzékelőt a SPAN/RSPAN/ERSPAN portokra, és irányítani a forgalmat a szükséges switchek portjairól. Ez a megoldás részben enyhíti a korábban említett problémát, de egy másikat felvet — a SPAN port nem tudja fogadni az összes forgalmat, amelyet irányítani fognak rá — nem lesz elegendő sávszélessége. Kénytelen lesz valamiről lemondani. Vagy a csomópontok egy részét meg kell hagyni figyelés nélkül (ehhez előzetesen priorizálni kell őket), vagy nem az összes csomópont forgalmát irányítani, hanem csak egy bizonyos típusút. Bármilyen esetben előfordulhat, hogy kihagyunk néhány támadást. Ezenkívül a SPAN portot más célokra is felhasználhatják. Ennek eredményeként át kell gondolnunk a meglévő hálózati topológiát, és esetleg módosításokat kell végeznünk, hogy maximálisan lefedjük a hálózatát a rendelkezésre álló érzékelők számával (és ezt össze kell hangolnunk az IT-val).

Mi van, ha a hálózata aszimmetrikus útvonalakat használ? Mi van, ha SDN-t integráltak, vagy tervezik az integrálását? Mi van, ha virtuális gépeket vagy konténereket kell monitorozni, amelyek forgalma egyáltalán nem jut el a fizikai switchhez? Ezekre a kérdésekre a hagyományos IDS gyártói nem szeretik a válaszokat, mert nem tudják, hogyan reagáljanak rájuk. Lehetséges, hogy arra próbálnak rábeszélni, hogy ezek a divatos technológiák csak üres szavak, és Önnek nincs szüksége rájuk. Talán azt mondják, hogy kis lépésekkel kell kezdenie. Vagy lehet, hogy azt tanácsolják, hogy állítson fel egy erőteljes központi megoldást a hálózat közepén, és irányítson minden forgalmat oda a terheléselosztókon keresztül. Bármi legyen is az ajánlott megoldás, Önnek magának kell pontosan megértenie, hogy mennyire felel meg Önnek. Csak ezt követően kell döntenie a hálózati infrastruktúra biztonsági monitorozásának megközelítéséről. Visszatérve a csomagcapturálásra, meg kell említenem, hogy ez a módszer továbbra is rendkívül népszerű és fontos, de alapvető feladata a határok ellenőrzése: a határok között az Ön szervezete és az Internet között, a határok között az adatközpont és a többi hálózat között, a határok között az automatizált vezérlőrendszer és a vállalati szegmens között. Ezekben a helyekben a klasszikus IDS/IPS megoldások továbbra is indokoltak és jól teljesítenek a kitűzött feladatokkal.

Térjünk át a második lehetőségre. Az események elemzése, amelyek a hálózati eszközökről érkeznek, szintén használható a támadások észlelésére, de nem mint fő mechanizmus, mivel csak egy szűk betörésosztályt képes észlelni. Ráadásul van egy bizonyos reakcióképessége — a támadásnak először meg kell történnie, majd rögzíteni kell azt a hálózati eszköznek, amely valamilyen módon jelezni fog a kibertér biztonságával kapcsolatos problémát. Számos módszer létezik erre. Ezek lehetnek syslog, RMON vagy SNMP. Az utolsó két protokoll a hálózati megfigyeléshez a kibertér biztonságának kontextusában csak akkor alkalmazható, ha DoS-támadást szeretnénk észlelni magán a hálózati berendezésen, mivel RMON és SNMP segítségével például nyomon követhetjük a berendezés központi processzorának vagy interfészeinek terhelését. Ez egyike a leg

A harmadik lehetőség a forgalom információinak elemzése, amely egy olyan eszközön halad át, amely támogatja az egyik flow-protokollt. Ebben az esetben függetlenül a protokolltól, a folyamokkal való munka infrastruktúrájának három összetevőből kell állnia:

Flow generálás vagy exportálás. Ezt a szerepet általában egy router, egy switch vagy más hálózati eszköz tölti be, amely a hálózati forgalmat átengedve kiemeli belőle a kulcsfontosságú paramétereket, amelyeket ezután a gyűjtő modulnak továbbítanak. Például a Cisco esetében a Netflow protokoll nemcsak routereken és switcheken, beleértve a virtuális és ipari berendezéseket is, hanem vezeték nélküli vezérlőkön, tűzfalakon és még szervereken is támogatott.
Flow gyűjtés. Figyelembe véve, hogy a modern hálózatokban általában több mint egy hálózati eszköz található, felmerül a folyamok gyűjtésének és egyesítésének feladata, amelyet úgynevezett gyűjtők segítségével oldanak meg, amelyek feldolgozzák a kapott folyamokat, majd azokat elemzés céljából továbbítják.
Folyam-elemzés. Az elemző magára vállalja az alapvető intellektuális feladatot, és különböző algoritmusokat alkalmazva a folyamokra, különböző következtetéseket von le. Például az IT funkción belül egy ilyen elemző képes azonosítani a hálózati szűk keresztmetszeteket vagy elemezni a forgalom terhelési profilját a hálózat további optimalizálása érdekében. Az információbiztonság terén pedig az elemző képes azonosítani az adatlopásokat, rosszindulatú kódok terjedését vagy DoS támadásokat.

Nem érdemes azt gondolni, hogy egy ilyen háromszintes architektúra túlságosan bonyolult — minden más lehetőség (kivéve talán az SNMP és RMON alapján működő hálózati megfigyelő rendszereket) is ezen alapelvek szerint működik. Van egy adatgenerátor az elemzéshez, amely lehet egy hálózati eszköz vagy egy önálló érzékelő. Van egy riasztási jelzések gyűjtésére szolgáló rendszer, és van egy a teljes megfigyelési infrastruktúra irányítására szolgáló rendszer. Az utolsó két összetevő egy csomópont keretein belül egyesíthető, de a nagyobb hálózatokban általában legalább két külön eszközre oszlik, a skálázhatóság és megbízhatóság érdekében.

A csomagok elemzésével ellentétben, amely a csomagok fejlécének és adatainak minden részének tanulmányozásán alapul, a folyamok elemzése a hálózati forgalom metadatainak gyűjtésére támaszkodik. Mikor, mennyi, honnan és hová, hogyan… ezek a kérdések azok, amelyekre a hálózati telemetria folyamata elemzése válaszol különböző flow protokollok segítségével. Eredetileg a statisztikák elemzésére és az IT problémák felderítésére használták a hálózatban, de ahogy az elemző mechanizmusok fejlődtek, lehetővé vált a telemetria hasonló célokra való alkalmazása is. Érdemes még egyszer hangsúlyozni, hogy a folyamok elemzése nem helyettesíti és nem törli el a csomagok rögzítését. Mindegyiknek megvan a saját alkalmazási területe. De a cikk kontextusában a folyamok elemzése a legjobban a belső infrastruktúra megfigyelésére alkalmas. Vannak hálózati eszközei (bár lényegtelen, hogy programozottan definiált paradigmában működnek vagy statikus szabályok szerint), amelyeken a támadás nem tud átjutni. A klasszikus IDS érzékelőjén át tud menni, de a flow protokollt támogató hálózati eszközön nem. Ez a módszer előnye.

Másrészt, ha bizonyítékokkal kell szolgálnia a bű enforcement számára vagy a saját incidensvizsgáló csapata számára, akkor a csomagok rögzítése elengedhetetlen — a hálózati telemetria nem a forgalom másolata, amelyet bizonyítékok összegyűjtésére lehet használni; ez az IT biztonság területén a gyors észleléshez és döntésekhez szükséges. Másrészről, a telemetria elemzésével nem kell az összes hálózati forgalmat „írnia” (ha van valaki, akivel foglalkozik, az a Cisco és az adatközpontok :-), hanem csak azt, amely a támadásban részt vesz. A telemetriai elemző eszközök jól kiegészítik a hagyományos csomagrögzítő mechanizmusokat azzal, hogy lehetővé teszik a szelekciós rögzítést és tárolást. Ellenkező esetben hatalmas tárolási infrastruktúrával kell rendelkeznie.

Képzeljünk el egy 250 Mbit/s sebességgel működő hálózatot. Ha szeretné megőrizni az összes ezen mennyiséget, akkor 31 MB tárolóra van szüksége egy másodpercnyi forgalom átviteléhez, 1,8 GB-ra egy perchez, 108 GB-ra egy órához és 2,6 TB-ra egy naphoz. A napi adatok tárolásához egy 10 Gbit/s sávszélességű hálózatról 108 TB tárolóra van szüksége. Ráadásul egyes szabályozók éveken át megkövetelik az adatok tárolását… A „kérésre történő rögzítés”, amihez a forgalom elemzés segít, rendkívül csökkenti ezeket az értékeket. Egyébként, ha a hálózati telemetria által rögzített adatok mennyiségét és a teljes adatgyűjtést nézzük, ez körülbelül 1 az 500hoz arányban áll. Az előző értékekhez képest a teljes napi forgalom teljes dekódolása 5 és 216 GB lenne (még egy szokásos USB flash meghajtóra is rögzíthető).

Ha a nyers hálózati adatok elemzésének módszerei gyakorlatilag nem különböznek a gyártók esetében, akkor a folyamatok elemzése más helyzet. Számos változat létezik flow-protokollokból, melyek eltéréseiről tudni kell a biztonság szempontjából. A legnépszerűbb a Cisco által kifejlesztett Netflow protokoll. Több verziója létezik ennek a protokollnak, amelyek eltérnek a lehetőségeik és a forgalomról rögzített információk mennyiségében. A jelenlegi verzió a kilencedik (Netflow v9), amelyen alapul a Netflow v10 ipari szabvány, más néven IPFIX. Ma a legtöbb hálózati gyártó támogatja a Netflow-t vagy az IPFIX-et az eszközeiben. De vannak különböző egyéb flow-protokollok is — sFlow, jFlow, cFlow, rFlow, NetStream stb., amelyek közül a sFlow a legnépszerűbb. Ezt támogatják leggyakrabban a hazai hálózati berendezések gyártói, mivel könnyen megvalósítható. Mik a kulcsfontosságú különbségek a de facto sztenderdként kezelt Netflow és az sFlow között? Néhány lényeges különbséget kiemelnék. Először is, a Netflow konfigurálható mezőkkel rendelkezik, míg az sFlow-ban rögzített mezők találhatók. Másodszor, ami a legfontosabb a mi esetünkben, az sFlow úgynevezett mintázott telemetriát gyűjt; szemben a nem mintázott telemetriával, amely a Netflow és az IPFIX sajátja. Mi a különbség közöttük?

Képzelje el, hogy szeretne megismerkedni a „Security Operations Center: Building, Operating, and Maintaining your SOC“ című könyvvel, amelyet kollégáim, Gary McIntyre, Joseph Muniz és Nadem Alfarhan írtak (a hivatkozás segítségével letöltheti a könyv egy részét). Három lehetősége van a kitűzött cél elérésére — elolvasni a könyvet teljes terjedelmében, átfutni azt, megállva minden 10. vagy 20. oldalon, vagy megpróbálni találni egy összefoglalót a főbb koncepciókról egy blogban vagy olyan szolgáltatásban, mint a SmartReading. Nos, a nem mintázott telemetria olyan, mint a hálózati forgalom minden „oldalának” elolvasása, azaz az egyes csomagok metaadatainak elemzése. A mintázott telemetria pedig a forgalom szelektív vizsgálata, abban a reményben, hogy a kiválasztott minták között olyan információt talál, amire szüksége van. A csatorna sebességétől függően a mintázott telemetria elemzés céljából a 64., 200., 500., 1000., 2000. vagy akár a 10000. csomagot képes továbbítani.

A biztonsági monitoring kontextusában ez azt jelenti, hogy a mintavételezett telemetria jól alkalmazható DDoS-támadások, szkennelések és rosszindulatú kódok terjesztésének felfedezésére, de kihagyhat atomikus vagy többcsomagos támadásokat, amelyek nem kerültek bele a mintába, amelyet elemzésre küldtek. A nem mintavételezett telemetriának nincsenek ilyen hátrányai, így sokkal szélesebb a felfedezettségi spektruma. Íme egy rövid lista azokról az eseményekről, amelyeket a hálózati telemetria elemzésére szolgáló eszközökkel észlelni lehet.

Természetesen egy open source Netflow-analizátor erre nem képes, mivel alapvető feladata a telemetria gyűjtése és annak alapvető IT szempontú elemzése. A flow alapú informatikai fenyegetések felfedezéséhez az elemzőt különböző motorokkal és algoritmusokkal kell felszerelni, amelyek a standard vagy egyedi Netflow mezők alapján felfedezik a kiberbiztonsági problémákat, gazdagítják a standard adatokat különböző Threat Intelligence forrásokkal stb.

Ezért, ha van választási lehetősége, álljon meg a Netflow vagy IPFIX mellett. De még ha az Ön eszköze kizárólag sFlow-t támogat, mint a helyi gyártók esetében, akkor is hasznot húzhat belőle a biztonság szempontjából.

2019 nyarán elemeztem a lehetőségeket, amelyeket a orosz hálózati hardver gyártók kínálnak, és mindannyian, kivéve az NSG-t, a Poligon-t és a Kraftveit, azt állították, hogy támogatják az sFlow-t (legalábbis a Zelax, a Natex, az Eltex, a QTech és a Rusteletech esetében).

A következő kérdés, amely felmerül, hogy hol érdemes bevezetni a flow támogatását a biztonsági célok érdekében? Valójában a kérdés nem teljesen korrektül van megfogalmazva. A modern berendezéseken a flow protokollok támogatása szinte mindig adott. Ezért a kérdést másként fogalmaznám át — hol a leghatékonyabb gyűjteni a telemetriát a biztonság szempontjából? A válasz elég nyilvánvaló — a hozzáférési szinten, ahol a forgalom 100%-át láthatja, ahol részletes információt kap a hosztokról (MAC, VLAN, interfész ID), ahol még a hosztok közötti P2P forgalmat is nyomon tudja követni, ami kritikus a szkennelés és a kártékony kód terjedésének észleléséhez. Az alap szinten a forgalom egy részét egyszerűen nem láthatja, a perem szinten pedig, ha szerencséje van, csak a hálózati forgalma egynegyedét fogja látni. De ha valamilyen okból az Ön hálózatában olyan idegen eszközök jelentek meg, amelyek lehetővé teszik a támadók számára a „bemenetel” és „kimenetel” megkerülését, akkor a telemetria elemzése ebből nem fog hasznot hozni. Ezért a maximális lefedettség érdekében ajánlott a telemetria gyűjtését kifejezetten a hozzáférési szinten elindítani. Érdemes megjegyezni, hogy még ha virtualizációról vagy konténerekről van szó, akkor a modern virtuális switchekben is gyakran előfordul a flow támogatás, amely lehetővé teszi a forgalom ellenőrzését ott is.

De mivel már felhoztam a témát, válaszolni kell arra a kérdésre is, mi van akkor, ha a berendezés, akár fizikai, akár virtuális, nem támogatja a flow protokollokat? Vagy annak bekapcsolása tilos (például ipari szegmensekben a megbízhatóság biztosítása érdekében)? Vagy hogy az aktiválása a központi processzor nagy terheléséhez vezet (ez előfordulhat elavult berendezéseken)? E problémák megoldására léteznek speciális virtuális érzékelők (flow sensor), amelyek lényegében egyszerű elosztók, amelyek átengedik a forgalmat, és azt flow formájában továbbítják az összegyűjtő modul felé. Az igazság az, hogy ebben az esetben számos problémával szembesülünk, amelyeket korábban említettünk a csomagok rögzítésével kapcsolatban. Tehát fontos megérteni nemcsak a flow analizáló technológia előnyeit, hanem annak korlátait is.

Még egy fontos szempont, amit érdemes figyelembe venni a folyamelemző eszközök kapcsán. Ha a hagyományos biztonsági eseménygenerálók esetében az EPS (events per second, események másodpercenként) mutatót alkalmazzuk, akkor a telemetria elemzésénél ez a mutató nem alkalmazható; helyette az FPS (flows per second, folyamatok másodpercenként) kerül előtérbe. Az EPS-hez hasonlóan ezt sem lehet előre kiszámítani, de meg lehet becsülni a különböző eszközök által generált folyamatok hozzávetőleges számát a feladatuk függvényében. Az interneten találhatóak táblázatok, amelyek az ipari eszközök különböző típusaihoz tartozó példaszerű értékeket tartalmaznak, amelyek segítenek megbecsülni, hogy milyen licenszekre van szüksége a folyamelemző eszközöknek és milyen architektúrára van szükségük. Az a helyzet, hogy az IDS érzékelőknek korlátozott sávszélességük van, amelyet monitorálják a Cisco belső hálózatát,, már említettem a gyűjtőink számát — ez 21. És ez egy olyan hálózat számára, amely öt kontinensre terjed ki, és körülbelül félmillió aktív eszközt számlál.

A Netflow megfigyelő rendszerként a saját megoldásunkat használjuk, a Cisco Stealthwatchot., amely kifejezetten a biztonsági feladatok megoldására összpontosít. Számos beépített motorral rendelkezik, amelyek képesek észlelni a rendellenes, gyanús és nyíltan rosszindulatú tevékenységeket, lehetővé téve a különféle fenyegetések széles spektrumának detektálását — a kriptovaluta bányászattól az információszivárgáson át a rosszindulatú kód terjesztéséig és a csalásokig. Mint a legtöbb Stealthwatch folyamatelemző, háromszintű architektúrára épül (generátor — gyűjtő — elemző), de számos érdekes funkcióval kiegészítették, amelyek fontosak a vizsgált anyag szempontjából. Először is, integrálódik a csomagfogó megoldásokkal (például Cisco Security Packet Analyzer), ami lehetővé teszi a kiválasztott hálózati ülések rögzítését a későbbi mélyreható vizsgálat és elemzés céljából. Másodszor, a biztonsági feladatok kibővítése érdekében egy speciális nvzFlow protokollt fejlesztettünk ki, amely lehetővé teszi az alkalmazások aktivitásának „közvetítését” a végponti eszközökön (szervereken, munkaállomásokon stb.) telemetriává, és annak gyűjtőbe történő továbbítását további elemzés céljából. Míg az eredeti Stealthwatch bármilyen flow-protokollal (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) működik a hálózati szinten, az nvzFlow támogatás lehetővé teszi az adatok korrelálását csomóponti szinten is, ezáltal növelve az egész rendszer hatékonyságát, és több támadást észlelve, mint a hagyományos hálózati folyamatelemzők.

Nyilvánvaló, hogy a Netflow elemző rendszerek biztonsági szempontjából nem csupán a Cisco megoldásaira korlátozódnak. Használhatók kereskedelmi, ingyenes vagy feltételesen ingyenes megoldások is. Kicsit furcsa lenne, ha a Cisco blogjában versenytársak megoldásait említeném, ezért mondok néhány szót arról, hogy a hálózati telemetria hogyan elemezhető két népszerű, nevükben hasonló, de mégis különböző eszközzel — SiLK és ELK.

A SiLK egy eszközökből álló készlet (a System for Internet-Level Knowledge), amely a forgalom elemzésére szolgál, és az amerikai CERT/CC fejlesztette ki. A cikk szempontjából a Netflow (5. és 9. legnépszerűbb verzió), IPFIX és sFlow támogatott, különböző eszközök (rwfilter, rwcount, rwflowpack stb.) segítségével különböző műveleteket végezhet a hálózati telemetriával, hogy észlelje a jogosulatlan tevékenységek jeleit. azonban érdemes megjegyezni néhány fontos dolgot. A SiLK egy parancssori eszköz, és a működési elemzéseket mindig olyan parancsok beírásával végezzük, mint az (ICMP-csomagok észlelése, amelyek mérete meghaladja a 200 bájtot):

rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15

ez nem túl kényelmes. Használhat grafikus felületet is, mint az iSiLK, de ez nem fog sokat segíteni az életén, mivel csak a vizualizálás funkcióját látja el, és nem helyettesíti az elemző munkáját. Ez a második fontos megjegyzés. A kereskedelmi megoldásokkal ellentétben, amelyekre már egy szilárd analitikai alap épült, anomáliaészlelési algoritmusok, a munkafolyamatok stb. vonatkozóan, a SiLK esetében mindezt önállóan kell elvégeznie, ami olyan készségeket igényel, amelyek eltérnek a már kész eszközök használatától. Ez nem jó vagy rossz — ez a szinte bármely ingyenes eszköz sajátossága, amely abból indul ki, hogy tudnia kell, mit kell tennie, és az csak segít ebben (a kereskedelmi eszközök kevésbé függenek a felhasználók kompetenciáitól, bár azt is feltételezik, hogy az elemzők legalább az alapvető hálózati nyomozási és megfigyelési ismeretekkel rendelkeznek). De térjünk vissza a SiLK-hez. Az elemző munkafolyamata ennek megfelelően a következőképpen alakul:

Hipotézis megfogalmazása. Meg kell értenünk, mit akarunk keresni a hálózati telemetriában, és ismerni kell azokat az egyedi attribútumokat, amelyek alapján az adott anomáliákat vagy fenyegetéseket azonosítjuk.
Modell kialakítása. Miután megfogalmaztuk a hipotézist, programozzuk azt a Python, shell vagy más, a SiLK-on kívüli eszközök segítségével.
Tesztelés. Elérkezett az idő, hogy ellenőrizzük hipotézisünk helyességét, amelyet a SiLK `rw`, `set`, `bag` előtt álló eszközeivel megerősítünk vagy megcáfolunk.
Valós adatok elemzése. A SiLK ipari használatában segít felfedezni valamit, és az elemzőnek válaszolnia kell a kérdésekre: „Rátaláltunk arra, amit vártunk?”, „Ez megfelel a hipotezisünknek?”, „Hogyan csökkenthető a hamis riasztások száma?”, „Hogyan javítható a felismerés szintje?” stb.
Fejlesztés. A végső szakaszban javítjuk a korábban elkészült anyagot — sablonokat hozunk létre, optimalizáljuk a kódot, újrafogalmazzuk és pontosítjuk a hipotezist, stb.

Ez a ciklus alkalmazható a Cisco Stealthwatchra is, csak az utóbbi maximálisan automatizálja ezeket az öt lépést, csökkentve az elemző hibáinak számát és növelve az események észlelésének gyorsaságát. Például a SiLK-nél a hálózati statisztikákat kiegészítheted külső adatokkal a rosszindulatú IP-kről saját magad által írt szkriptekkel, míg a Cisco Stealthwatchban ez egy beépített funkció, amely azonnal riaszt, ha a hálózati forgalomban olyan IP-címekkel találkozunk, amelyek a feketelistán szerepelnek.

Ha felmegyünk a flow-elemző szoftverek "fizetős" piramisának csúcsára, akkor a teljesen ingyenes SiLK után következik a feltételesen ingyenes ELK, amely három kulcsfontosságú összetevőből áll — Elasticsearch (indexelés, keresés és adatanalízis), Logstash (adatbe/ki), és Kibana (vizualizáció). A SiLK-től eltérően, ahol mindent saját magadnak kell megírnod, az ELK-nek már sok kész könyvtára/module van (részben fizetős, részben ingyenes), amelyek automatizálják a hálózati telemetria elemzését. Például a Logstash GeoIP szűrője lehetővé teszi az észlelt IP-címek földrajzi helyének hozzárendelését (a Stealthwatch esetében ez is beépített funkció).

Az ELK-nek szintén elég nagy közössége van, amely kiegészíti az ezt a monitorozási megoldást megvalósító hiányzó összetevőket. Például, hogy a Netflow, IPFIX és sFlow-ra tudjál dolgozni, használhatod a modult elastiflow, ha a Logstash Netflow modullal nem vagy megelégedve, amely csak a Netflow-t támogatja.

Az ELK, miközben gyorsabbá teszi a flow összegyűjtését és keresését, jelenleg nem rendelkezik gazdag beépített analitikával az anomáliák és fenyegetések észlelésére a hálózati telemetriában. Tehát a fentebb leírt életciklus követésekor neked magadnak kell leírnod a zavarási modelleket, majd azokat a harci rendszerben használnod (beépített modellek ott nincsenek).

Természetesen léteznek ennél bonyolultabb ELK kiterjesztések is, amelyek már tartalmaznak bizonyos anomáliák észlelési modelleket a hálózati telemetriában, de ezek a kiterjesztések pénzbe kerülnek, és itt már kérdés, hogy megéri-e — saját modellt írni, megvásárolni a megvalósítását a saját monitoring eszköze számára, vagy inkább kész megoldást venni a Network Traffic Analysis kategóriában.

Igazából nem szeretnék belemenni a vitába, hogy érdemesebb-e pénzt költeni és kész megoldást vásárolni anomáliák és fenyegetések monitorozására a hálózati telemetriában (például Cisco Stealthwatch), vagy inkább magunknak felfejleszteni és bármely új fenyegetéshez hozzáigazítani a SiLK, ELK vagy nfdump, vagy az OSU Flow Tools (az utolsó kettőre gondolok) használatát, mint ahogy a legutóbb tettem. beszéltem Mindenki saját magának választ, és mindenkinek megvannak a maga indokai, hogy melyik opciót válassza. Én csak azt akartam bemutatni, hogy a hálózati telemetria egy nagyon fontos eszköz a belső infrastruktúra hálózati biztonságának biztosításában, és nem szabad figyelmen kívül hagyni, hogy ne bővüljön annak a cégek listája, akiknek a neve a médiában olyan jelzőkkel szerepel, mint "feltört", "a kiberbiztonsági követelményeknek nem megfelelő", "nem törődő az adatai és az ügyfelei adatai biztonságával".

Összegzésképpen szeretném megemlíteni azokat a kulcsfontosságú tanácsokat, amelyeket érdemes követni a belső infrastruktúra kiberbiztonsági monitorozásának felépítésekor:

Ne korlátozódjon csupán a peremre! Használja (és válassza) a hálózati infrastruktúrát nemcsak arra, hogy a forgalmat A pontból B pontba irányítsa, hanem a kiberbiztonság kérdéseinek megoldására is.
Tanulmányozza a meglévő kiberbiztonsági monitoring mechanizmusokat az Ön hálózati berendezéseiben, és használja ki azokat.
Belső monitorozáshoz előnyben részesítse a telemetria elemzését — ez lehetővé teszi a kiberbiztonsági események 80-90%-ának észlelését, ezzel olyasmit végezve, amit a hálózati csomagok elfogásával nem lehet megtenni, miközben megtakarítja a kiberbiztonsági események tárolásához szükséges helyet.
A forgalom monitorozásához használjon Netflow v9-et vagy IPFIX-t – ezek több információt kínálnak a biztonság kontextusában, és lehetővé teszik nemcsak az IPv4, hanem az IPv6, MPLS stb. monitorozását is.
Használjon nem mintavételezett flow-protokollt – ez több információt nyújt a fenyegetések észleléséhez. Például Netflow vagy IPFIX.
Ellenőrizze a hálózati berendezései terhelését – lehet, hogy nem képesek kezelni a flow-protokollokat is. Gondolkodjon virtuális érzékelők vagy Netflow Generation Appliance alkalmazásán.
Valósítson meg ellenőrzést elsősorban a hozzáférés szintjén – ez lehetővé teszi, hogy lássa a forgalom 100%-át.
Ha nincs más választása, és orosz hálózati berendezéseket használ, válassza azt, amely támogatja a flow-protokollokat vagy rendelkezik SPAN/RSPAN portokkal.
Kombinálja a behatolás/ támadásmegelőző rendszereket a határokon és a belső hálózati forgalomelemző rendszereket (beleértve a felhőket is).

A legutolsó tanács kapcsán szeretnék bemutatni egy illusztrációt, amit korábban már említettem. Látja, hogy ha korábban a Cisco információbiztonsági szolgáltatás szinte teljes mértékben IDS-alapú monitoring rendszereken és aláírás-alapú módszereken alapult, most a tárgykörükbe tartozó incidensek csupán 20%-át képviselik. Egy másik 20% a forgalomelemző rendszerekre vonatkozik, ami azt mutatja, hogy ezek a megoldások nem szeszélyek, hanem valós eszközök a modern vállalatok információbiztonsági szolgálatainak működésében. Ráadásul a megvalósításhoz megvan a legfontosabb – a hálózati infrastruktúra, amelynek befektetéseit még jobban meg lehet védeni, ha a hálózatra még információbiztonsági monitoring funkciókat is ráruház.

Különösen nem akartam a hálózati forgalomban felfedezett anomáliákra vagy fenyegetésekre való reagálás témájával foglalkozni, de gondolom, így is világos, hogy a monitoring nem ér véget csak a fenyegetés felfedezésével. Ezt reagálásnak kell követnie, és lehetőleg automatikus vagy automatizált módon. De ez már egy külön anyag témája.