Pokiaľ ide o monitorovanie bezpečnosti internej podnikovej alebo oddelenej siete, mnohí si ho spájajú s kontrolou úniku informácií a implementáciou riešení DLP. A ak sa pokúsite objasniť otázku a opýtať sa, ako zisťujete útoky na internú sieť, odpoveďou bude spravidla zmienka o systémoch detekcie narušenia (IDS). A to, čo bolo pred 10-20 rokmi jedinou možnosťou, sa dnes stáva anachronizmom. Existuje efektívnejšia a miestami jediná možná možnosť monitorovania internej siete – pomocou tokových protokolov, ktoré boli pôvodne určené na vyhľadávanie sieťových problémov (riešenie problémov), no postupom času sa pretransformovali na veľmi zaujímavý bezpečnostný nástroj. Povieme si, aké tokové protokoly existujú a ktoré sú lepšie pri zisťovaní sieťových útokov, kde je najlepšie implementovať monitorovanie toku, čo treba hľadať pri nasadzovaní takejto schémy a dokonca aj to, ako to všetko „zdvihnúť“ na domáce zariadenia. v rozsahu tohto článku.
Nebudem sa zaoberať otázkou „Prečo je potrebné monitorovanie bezpečnosti vnútornej infraštruktúry? Zdá sa, že odpoveď je jasná. Ak by ste sa však napriek tomu chceli ešte raz uistiť, že dnes bez nej nemôžete žiť, krátke video o tom, ako môžete preniknúť do firemnej siete chránenej firewallom 17 spôsobmi. Preto budeme predpokladať, že chápeme, že interný monitoring je nevyhnutná vec a zostáva len pochopiť, ako ho možno organizovať.
Zdôraznil by som tri kľúčové zdroje údajov na monitorovanie infraštruktúry na úrovni siete:
- „surová“ návštevnosť, ktorú zachytíme a odošleme na analýzu do určitých analytických systémov,
- udalosti zo sieťových zariadení, cez ktoré prechádza prevádzka,
- dopravné informácie prijaté prostredníctvom jedného z tokových protokolov.
Zachytenie surovej prevádzky je najobľúbenejšou možnosťou medzi bezpečnostnými špecialistami, pretože sa historicky objavilo a bolo úplne prvé. Konvenčné systémy detekcie narušenia siete (úplne prvý komerčný systém detekcie narušenia bol NetRanger od Wheel Group, zakúpený v roku 1998 spoločnosťou Cisco) boli presne zapojené do zachytávania paketov (a neskorších relácií), v ktorých sa hľadali určité podpisy („rozhodujúce pravidlá“ v terminológia FSTEC), signalizácia útokov. Samozrejme, surovú návštevnosť môžete analyzovať nielen pomocou IDS, ale aj pomocou iných nástrojov (napríklad Wireshark, tcpdum alebo funkcionalita NBAR2 v Cisco IOS), ale zvyčajne im chýba báza znalostí, ktorá odlišuje nástroj informačnej bezpečnosti od bežného IT nástroj.
Takže systémy na detekciu útokov. Najstaršia a najpopulárnejšia metóda detekcie sieťových útokov, ktorá robí dobrú prácu na perimetri (bez ohľadu na to, čo - podnik, dátové centrum, segment atď.), Ale zlyháva v moderných prepínaných a softvérovo definovaných sieťach. V prípade siete vybudovanej na báze konvenčných prepínačov sa infraštruktúra senzorov na detekciu útokov stáva príliš veľkou – na každé pripojenie k uzlu, na ktorom chcete útoky monitorovať, budete musieť nainštalovať senzor. Každý výrobca vám, samozrejme, rád predá stovky a tisíce senzorov, ale myslím si, že váš rozpočet takéto výdavky nezvládne. Môžem povedať, že ani v Cisco (a my sme vývojári NGIPS) sme to nedokázali, hoci by sa zdalo, že otázka ceny je pred nami. Nemal by som stáť - je to naše vlastné rozhodnutie. Okrem toho vzniká otázka, ako pripojiť snímač v tejto verzii? Do medzery? Čo ak zlyhá samotný snímač? Vyžaduje sa obtokový modul v snímači? Používať rozdeľovače (kohútik)? To všetko riešenie predražuje a robí ho nedostupným pre spoločnosť akejkoľvek veľkosti.
Môžete skúsiť „zavesiť“ senzor na port SPAN/RSPAN/ERSPAN a nasmerovať naň prevádzku z požadovaných portov prepínača. Táto možnosť čiastočne odstraňuje problém popísaný v predchádzajúcom odseku, ale predstavuje ďalší - port SPAN nemôže akceptovať absolútne všetku komunikáciu, ktorá naň bude odoslaná - nebude mať dostatočnú šírku pásma. Budete musieť niečo obetovať. Buď ponechajte niektoré uzly bez monitorovania (potom ich musíte najskôr uprednostniť), alebo neposielajte z uzla všetku komunikáciu, ale iba určitý typ. V každom prípade nám môžu uniknúť nejaké útoky. Port SPAN je navyše možné použiť aj pre iné potreby. V dôsledku toho budeme musieť prehodnotiť existujúcu sieťovú topológiu a prípadne ju upraviť, aby sme vašu sieť pokryli na maximum počtom senzorov, ktoré máte (a skoordinovať to s IT).
Čo ak vaša sieť používa asymetrické trasy? Čo ak ste implementovali alebo plánujete implementovať SDN? Čo ak potrebujete monitorovať virtualizované stroje alebo kontajnery, ktorých prevádzka vôbec nedosahuje fyzický prepínač? To sú otázky, ktoré tradiční predajcovia IDS nemajú radi, pretože na ne nevedia odpovedať. Možno vás presvedčia, že všetky tieto módne technológie sú humbuk a vy to nepotrebujete. Možno budú hovoriť o potrebe začať v malom. Alebo možno povedia, že musíte umiestniť výkonnú mlátičku do stredu siete a nasmerovať na ňu všetku premávku pomocou balancovačov. Nech sa vám ponúkne akákoľvek možnosť, musíte jasne pochopiť, ako vám vyhovuje. A až potom sa rozhodnúť o výbere prístupu k monitorovaniu informačnej bezpečnosti sieťovej infraštruktúry. Keď sa vrátim k zachytávaniu paketov, chcem povedať, že táto metóda je naďalej veľmi populárna a dôležitá, ale jej hlavným účelom je kontrola hraníc; hranice medzi vašou organizáciou a internetom, hranice medzi dátovým centrom a zvyškom siete, hranice medzi systémom riadenia procesov a firemným segmentom. Na týchto miestach majú klasické IDS/IPS stále právo existovať a dobre sa vysporiadať so svojimi úlohami.
Prejdime k druhej možnosti. Analýza udalostí prichádzajúcich zo sieťových zariadení môže byť tiež použitá na účely detekcie útokov, ale nie ako hlavný mechanizmus, pretože umožňuje odhaliť len malú triedu prienikov. Okrem toho je mu vlastná istá reaktivita – k útoku musí najskôr dôjsť, potom ho musí zaznamenať sieťové zariadenie, ktoré tak či onak signalizuje problém s informačnou bezpečnosťou. Takýchto spôsobov je viacero. Môže to byť syslog, RMON alebo SNMP. Posledné dva protokoly na monitorovanie siete v rámci informačnej bezpečnosti sa používajú iba v prípade, ak potrebujeme detekovať DoS útok na samotné sieťové zariadenie, keďže pomocou RMON a SNMP je možné napríklad sledovať záťaž centrály zariadenia. procesor alebo jeho rozhrania. Toto je jedna z „najlacnejších“ (každý má syslog alebo SNMP), ale aj najefektívnejšia zo všetkých metód monitorovania informačnej bezpečnosti vnútornej infraštruktúry - veľa útokov je pred ňou jednoducho skrytých. Samozrejme, nemali by ste ich zanedbávať a rovnaká analýza syslog vám pomôže včas identifikovať zmeny v konfigurácii samotného zariadenia, jeho kompromitáciu, ale nie je príliš vhodná na detekciu útokov na celú sieť.
Treťou možnosťou je analyzovať informácie o premávke prechádzajúcej cez zariadenie, ktoré podporuje jeden z niekoľkých tokových protokolov. V tomto prípade, bez ohľadu na protokol, infraštruktúra vlákien nevyhnutne pozostáva z troch komponentov:
- Generovanie alebo export toku. Táto rola je zvyčajne priradená smerovaču, prepínaču alebo inému sieťovému zariadeniu, ktoré tým, že cez seba prechádza sieťovou prevádzkou, umožňuje z neho extrahovať kľúčové parametre, ktoré sa následne prenášajú do zberného modulu. Napríklad Cisco podporuje protokol Netflow nielen na smerovačoch a prepínačoch, vrátane virtuálnych a priemyselných, ale aj na bezdrôtových ovládačoch, firewalloch a dokonca aj na serveroch.
- Priebeh zberu. Vzhľadom na to, že moderná sieť má zvyčajne viac ako jedno sieťové zariadenie, vzniká problém zberu a konsolidácie tokov, ktorý sa rieši pomocou takzvaných kolektorov, ktoré prijímané toky spracúvajú a následne prenášajú na analýzu.
- Analýza toku Analyzátor preberá hlavnú intelektuálnu úlohu a aplikovaním rôznych algoritmov na prúdy vyvodzuje určité závery. Napríklad ako súčasť funkcie IT môže takýto analyzátor identifikovať úzke miesta v sieti alebo analyzovať profil prevádzkového zaťaženia pre ďalšiu optimalizáciu siete. A kvôli bezpečnosti informácií dokáže takýto analyzátor odhaliť úniky dát, šírenie škodlivého kódu či DoS útoky.
Nemyslite si, že táto trojvrstvová architektúra je príliš komplikovaná - všetky ostatné možnosti (snáď okrem systémov monitorovania siete pracujúcich s SNMP a RMON) tiež fungujú podľa nej. Na analýzu máme dátový generátor, ktorým môže byť sieťové zariadenie alebo samostatný senzor. Máme systém zberu alarmov a systém riadenia celej monitorovacej infraštruktúry. Posledné dva komponenty je možné kombinovať v rámci jedného uzla, ale vo viac či menej veľkých sieťach sú zvyčajne rozmiestnené na minimálne dvoch zariadeniach, aby bola zabezpečená škálovateľnosť a spoľahlivosť.
Na rozdiel od analýzy paketov, ktorá je založená na štúdiu údajov hlavičky a tela každého paketu a relácií, z ktorých pozostáva, sa analýza toku spolieha na zhromažďovanie metadát o sieťovej prevádzke. Kedy, koľko, odkiaľ a kde, ako... to sú otázky zodpovedané analýzou sieťovej telemetrie pomocou rôznych tokových protokolov. Spočiatku sa používali na analýzu štatistík a vyhľadávanie problémov IT v sieti, ale potom, ako sa vyvinuli analytické mechanizmy, bolo možné ich použiť na rovnakú telemetriu na bezpečnostné účely. Opäť stojí za zmienku, že analýza toku nenahrádza ani nenahrádza zachytávanie paketov. Každá z týchto metód má svoju vlastnú oblasť použitia. Ale v kontexte tohto článku je to analýza toku, ktorá je najvhodnejšia na monitorovanie vnútornej infraštruktúry. Máte sieťové zariadenia (či už fungujú v softvérovo definovanej paradigme alebo podľa statických pravidiel), ktoré útok nemôže obísť. Dokáže obísť klasický IDS senzor, no sieťové zariadenie podporujúce flow protokol nie. To je výhoda tejto metódy.
Na druhej strane, ak potrebujete dôkazy pre orgány činné v trestnom konaní alebo vlastný vyšetrovací tím incidentov, bez zachytávania paketov sa nezaobídete – sieťová telemetria nie je kópiou prevádzky, ktorú možno použiť na zhromažďovanie dôkazov; je potrebný na rýchle zisťovanie a rozhodovanie v oblasti informačnej bezpečnosti. Na druhej strane pomocou telemetrickej analýzy môžete „zapísať“ nie všetku sieťovú prevádzku (ak vôbec, Cisco sa zaoberá dátovými centrami :-), ale len tú, ktorá je zapojená do útoku. Nástroje na telemetrickú analýzu v tomto ohľade dobre doplnia tradičné mechanizmy zachytávania paketov a dávajú príkazy na selektívne zachytávanie a ukladanie. V opačnom prípade budete musieť mať kolosálnu infraštruktúru úložiska.
Predstavme si sieť pracujúcu rýchlosťou 250 Mbit/s. Ak chcete uložiť celý tento objem, budete potrebovať 31 MB úložného priestoru na jednu sekundu prenosu dát, 1,8 GB na jednu minútu, 108 GB na hodinu a 2,6 TB na jeden deň. Na ukladanie denných dát zo siete so šírkou pásma 10 Gbit/s budete potrebovať 108 TB úložiska. Niektoré regulačné orgány však vyžadujú uchovávanie bezpečnostných údajov celé roky... Nahrávanie na požiadanie, ktoré vám pomôže implementovať analýza toku, pomáha znižovať tieto hodnoty rádovo. Mimochodom, ak hovoríme o pomere objemu zaznamenaných sieťových telemetrických údajov a úplného zachytenia údajov, potom je to približne 1 ku 500. Pre rovnaké hodnotyukladanie úplného prepisu všetkej dennej prevádzky bude 5, respektíve 216 GB (môžete to dokonca nahrať na bežný flash disk).
Ak pri nástrojoch na analýzu nespracovaných sieťových údajov je spôsob ich zachytávania takmer rovnaký od dodávateľa k predajcovi, potom v prípade analýzy toku je situácia iná. Existuje niekoľko možností pre protokoly toku, o ktorých rozdieloch musíte vedieť v kontexte bezpečnosti. Najpopulárnejší je protokol Netflow vyvinutý spoločnosťou Cisco. Existuje niekoľko verzií tohto protokolu, ktoré sa líšia svojimi možnosťami a množstvom zaznamenaných dopravných informácií. Aktuálna verzia je deviata (Netflow v9), na základe ktorej bol vyvinutý priemyselný štandard Netflow v10, známy aj ako IPFIX. Dnes väčšina predajcov sietí podporuje Netflow alebo IPFIX vo svojich zariadeniach. Existujú však rôzne ďalšie možnosti pre protokoly toku - sFlow, jFlow, cFlow, rFlow, NetStream atď., z ktorých je sFlow najobľúbenejší. Práve tento typ je najčastejšie podporovaný domácimi výrobcami sieťových zariadení kvôli jednoduchosti implementácie. Aké sú kľúčové rozdiely medzi Netflow, ktorý sa stal de facto štandardom, a sFlow? Vyzdvihol by som niekoľko kľúčových. Po prvé, Netflow má užívateľsky prispôsobiteľné polia na rozdiel od pevných polí v sFlow. A po druhé, a to je v našom prípade to najdôležitejšie, sFlow zbiera takzvanú vzorkovanú telemetriu; na rozdiel od nevzorkovaného pre Netflow a IPFIX. Aký je medzi nimi rozdiel?
Predstavte si, že sa rozhodnete prečítať si knihu “” mojich kolegov - Gary McIntyre, Joseph Munitz a Nadem Alfardan (časť knihy si môžete stiahnuť z odkazu). Na dosiahnutie svojho cieľa máte tri možnosti – prečítajte si celú knihu, prelistujte si ju, zastavte sa na každej 10. alebo 20. strane alebo skúste nájsť prerozprávanie kľúčových pojmov na blogu alebo službe, ako je SmartReading. Takže telemetria bez vzorkovania číta každú „stránku“ sieťovej prevádzky, to znamená analyzuje metadáta pre každý paket. Vzorkovaná telemetria je selektívna štúdia premávky v nádeji, že vybrané vzorky budú obsahovať to, čo potrebujete. V závislosti od rýchlosti kanála sa vzorkovaná telemetria odošle na analýzu každý 64., 200., 500., 1000., 2000. alebo dokonca 10000. paket.
V kontexte monitorovania informačnej bezpečnosti to znamená, že vzorkovaná telemetria je vhodná na detekciu DDoS útokov, skenovanie a šírenie škodlivého kódu, ale môže chýbať atómové alebo multipaketové útoky, ktoré neboli zahrnuté vo vzorke odoslanej na analýzu. Bezvzorkovaná telemetria takéto nevýhody nemá. Vďaka tomu je rozsah detekovaných útokov oveľa širší. Tu je krátky zoznam udalostí, ktoré možno zistiť pomocou nástrojov analýzy sieťovej telemetrie.
Samozrejme, nejaký open source Netflow analyzátor vám to nedovolí, keďže jeho hlavnou úlohou je zbierať telemetriu a vykonávať na nej základnú analýzu z pohľadu IT. Na identifikáciu hrozieb informačnej bezpečnosti na základe toku je potrebné vybaviť analyzátor rôznymi motormi a algoritmami, ktoré budú identifikovať problémy kybernetickej bezpečnosti na základe štandardných alebo vlastných polí Netflow, obohatiť štandardné údaje o externé údaje z rôznych zdrojov Threat Intelligence atď.
Preto, ak máte na výber, zvoľte Netflow alebo IPFIX. Ale aj keď vaše zariadenie funguje len s sFlow, ako domáci výrobcovia, potom aj v tomto prípade z toho môžete profitovať v kontexte bezpečnosti.
V lete 2019 som analyzoval možnosti, ktoré majú ruskí výrobcovia sieťového hardvéru a všetci, okrem NSG, Polygon a Craftway, oznámili podporu pre sFlow (aspoň Zelax, Natex, Eltex, QTech, Rusteleteh).
Ďalšia otázka, ktorej budete čeliť, je, kde implementovať podporu toku na bezpečnostné účely? V skutočnosti otázka nie je položená úplne správne. Moderné vybavenie takmer vždy podporuje tokové protokoly. Otázku by som preto preformuloval inak – kde je z bezpečnostného hľadiska najefektívnejšie zbierať telemetriu? Odpoveď bude celkom zrejmá – na úrovni prístupu, kde uvidíte 100 % všetkej prevádzky, kde budete mať podrobné informácie o hostiteľoch (MAC, VLAN, ID rozhrania), kde môžete dokonca sledovať P2P prevádzku medzi hostiteľmi, ktoré je rozhodujúca pre detekciu a distribúciu škodlivého kódu skenovaním. Na základnej úrovni možno jednoducho neuvidíte časť návštevnosti, ale na úrovni perimetra uvidíte štvrtinu všetkej návštevnosti siete. Ak však z nejakého dôvodu máte vo svojej sieti cudzie zariadenia, ktoré umožňujú útočníkom „vstúpiť a vystúpiť“ bez obídenia perimetra, analýza telemetrie z nej vám nič nedá. Pre maximálne pokrytie sa preto odporúča povoliť telemetrický zber na úrovni prístupu. Zároveň stojí za zmienku, že aj keď hovoríme o virtualizácii alebo kontajneroch, podpora toku sa často nachádza aj v moderných virtuálnych prepínačoch, čo vám umožňuje riadiť prevádzku aj tam.
Ale keďže som nastolil tému, musím odpovedať na otázku: čo ak zariadenie, fyzické alebo virtuálne, nepodporuje tokové protokoly? Alebo je jeho zaradenie zakázané (napríklad v priemyselných segmentoch na zabezpečenie spoľahlivosti)? Alebo jeho zapnutie vedie k vysokej záťaži CPU (to sa stáva na staršom hardvéri)? Na vyriešenie tohto problému existujú špecializované virtuálne senzory (snímače prietoku), čo sú v podstate obyčajné rozdeľovače, ktoré cez seba prenášajú prevádzku a vysielajú ju vo forme prietoku do zberného modulu. Je pravda, že v tomto prípade dostaneme všetky problémy, o ktorých sme hovorili vyššie v súvislosti s nástrojmi na zachytávanie paketov. To znamená, že musíte pochopiť nielen výhody technológie analýzy toku, ale aj jej obmedzenia.
Ďalší bod, ktorý je dôležité mať na pamäti, keď hovoríme o nástrojoch analýzy toku. Ak vo vzťahu ku konvenčným prostriedkom generovania bezpečnostných udalostí používame metriku EPS (udalosť za sekundu), potom tento indikátor nie je použiteľný pre telemetrickú analýzu; je nahradený FPS (prietok za sekundu). Rovnako ako v prípade EPS sa nedá vypočítať vopred, ale môžete odhadnúť približný počet vlákien, ktoré konkrétne zariadenie generuje v závislosti od jeho úlohy. Na internete nájdete tabuľky s približnými hodnotami pre rôzne typy podnikových zariadení a podmienok, ktoré vám umožnia odhadnúť, aké licencie potrebujete na analytické nástroje a aká bude ich architektúra? Faktom je, že snímač IDS je obmedzený určitou šírkou pásma, ktorú môže „vytiahnuť“, a prietokový kolektor má svoje vlastné obmedzenia, ktoré treba pochopiť. Preto je vo veľkých, geograficky distribuovaných sieťach zvyčajne niekoľko kolektorov. Keď som opísal , už som uviedol počet našich zberateľov - je ich 21. A to na sieť roztrúsenú na piatich kontinentoch a čítajúcu okolo pol milióna aktívnych zariadení).
Používame vlastné riešenie ako monitorovací systém Netflow , ktorá je špeciálne zameraná na riešenie bezpečnostných problémov. Má mnoho vstavaných motorov na odhaľovanie anomálnej, podozrivej a jednoznačne škodlivej činnosti, čo umožňuje odhaliť široké spektrum rôznych hrozieb – od kryptominácie po úniky informácií, od šírenia škodlivého kódu až po podvody. Ako väčšina prietokových analyzátorov, aj Stealthwatch sú postavené podľa trojúrovňovej schémy (generátor - kolektor - analyzátor), ale sú doplnené o množstvo zaujímavých funkcií, ktoré sú dôležité v kontexte uvažovaného materiálu. Po prvé, integruje sa s riešeniami na zachytávanie paketov (ako je Cisco Security Packet Analyzer), čo vám umožňuje zaznamenávať vybrané sieťové relácie pre neskoršie hĺbkové skúmanie a analýzu. Po druhé, špeciálne pre rozšírenie bezpečnostných úloh sme vyvinuli špeciálny protokol nvzFlow, ktorý umožňuje „vysielať“ aktivitu aplikácií na koncových uzloch (servery, pracovné stanice atď.) do telemetrie a prenášať ju do kolektora na ďalšiu analýzu. Ak Stealthwatch vo svojej pôvodnej verzii pracuje s akýmkoľvek protokolom toku (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) na úrovni siete, potom podpora nvzFlow umožňuje dátovú koreláciu aj na úrovni uzla, teda. zvýšenie efektivity celého systému a zaznamenanie väčšieho počtu útokov ako bežné analyzátory sieťového toku.
Je jasné, že keď hovoríme o systémoch analýzy Netflow z hľadiska bezpečnosti, trh nie je obmedzený na jediné riešenie od spoločnosti Cisco. Môžete použiť komerčné aj bezplatné alebo sharewarové riešenia. Je dosť zvláštne, ak na blogu Cisco uvádzam riešenia konkurentov ako príklady, a tak poviem pár slov o tom, ako možno sieťovú telemetriu analyzovať pomocou dvoch populárnych nástrojov s podobným názvom, no predsa odlišných – SiLK a ELK.
SiLK je sada nástrojov (System for Internet-Level Knowledge) na analýzu návštevnosti vyvinutá americkým CERT/CC a ktorá v kontexte dnešného článku podporuje Netflow (najpopulárnejšia 5. a 9. verzia), IPFIX a sFlow a pomocou rôznych nástrojov (rwfilter, rwcount, rwflowpack atď.) na vykonávanie rôznych operácií na sieťovej telemetrii s cieľom odhaliť v nej znaky neoprávnených akcií. Je však potrebné poznamenať niekoľko dôležitých bodov. SiLK je nástroj príkazového riadka, ktorý vykonáva on-line analýzu zadaním príkazov, ako je tento (detekcia ICMP paketov väčších ako 200 bajtov):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nie veľmi pohodlné. Môžete použiť GUI iSiLK, ale to vám život veľmi neuľahčí, iba vyriešite funkciu vizualizácie a nenahradíte analytika. A toto je druhý bod. Na rozdiel od komerčných riešení, ktoré už majú solídny analytický základ, algoritmy detekcie anomálií, zodpovedajúci workflow atď., v prípade SiLK budete musieť toto všetko urobiť sami, čo si od vás bude vyžadovať trochu iné kompetencie ako pri používaní už pripravených- nástroje na používanie. To nie je ani dobré, ani zlé – je to vlastnosť takmer každého bezplatného nástroja, ktorý predpokladá, že viete, čo máte robiť, a iba vám s tým pomôže (komerčné nástroje sú menej závislé od kompetencií jeho používateľov, aj keď tiež predpokladajú, že aby analytici rozumeli aspoň základom vyšetrovania a monitorovania siete). Ale vráťme sa k SiLK. Pracovný cyklus analytika s ním vyzerá takto:
- Formulovanie hypotézy. Musíme pochopiť, čo budeme v rámci sieťovej telemetrie hľadať, poznať jedinečné atribúty, podľa ktorých identifikujeme určité anomálie alebo hrozby.
- Stavba modelu. Po sformulovaní hypotézy ju naprogramujeme pomocou rovnakého Pythonu, shellu alebo iných nástrojov, ktoré nie sú zahrnuté v SiLK.
- Testovanie. Teraz prichádza rad na kontrolu správnosti našej hypotézy, ktorá je potvrdená alebo vyvrátená pomocou SiLK utilit začínajúcich na 'rw', 'set', 'bag'.
- Analýza skutočných údajov. V priemyselnej prevádzke nám SiLK pomáha niečo identifikovať a analytik musí odpovedať na otázky „Našli sme, čo sme očakávali?“, „Zodpovedá to našej hypotéze?“, „Ako znížiť počet falošných poplachov?“, „Ako zlepšiť úroveň uznania? » a tak ďalej.
- Zlepšenie. V záverečnej fáze vylepšujeme to, čo bolo urobené skôr – vytvárame šablóny, zlepšujeme a optimalizujeme kód, preformulujeme a objasňujeme hypotézu atď.
Tento cyklus bude aplikovateľný aj na Cisco Stealthwatch, len ten posledný zautomatizuje týchto päť krokov na maximum, čím sa zníži počet chýb analytika a zvýši sa efektívnosť detekcie incidentov. Napríklad v SiLK môžete sieťové štatistiky obohatiť o externé údaje o škodlivých IP pomocou ručne písaných skriptov a v Cisco Stealthwatch ide o vstavanú funkciu, ktorá okamžite zobrazí alarm, ak sieťová prevádzka obsahuje interakcie s IP adresami z blacklistu.
Ak pôjdete vyššie v „platenej“ pyramíde pre softvér na analýzu toku, potom po úplne bezplatnom SiLK bude shareware ELK, pozostávajúci z troch kľúčových komponentov – Elasticsearch (indexovanie, vyhľadávanie a analýza údajov), Logstash (vstup/výstup údajov). ) a Kibana (vizualizácia). Na rozdiel od SiLK, kde si musíte všetko napísať sami, ELK už má veľa hotových knižníc/modulov (niektoré platené, iné nie), ktoré automatizujú analýzu sieťovej telemetrie. Napríklad GeoIP filter v Logstash vám umožňuje priradiť monitorované IP adresy k ich geografickej polohe (Stealthwatch má túto vstavanú funkciu).
ELK má tiež pomerne veľkú komunitu, ktorá dopĺňa chýbajúce komponenty pre toto monitorovacie riešenie. Napríklad na prácu s Netflow, IPFIX a sFlow môžete použiť modul , ak nie ste spokojní s modulom Logstash Netflow, ktorý podporuje iba Netflow.
Zatiaľ čo ELK poskytuje vyššiu efektivitu pri zhromažďovaní toku a vyhľadávaní v ňom, v súčasnosti nemá bohatú vstavanú analytiku na detekciu anomálií a hrozieb v sieťovej telemetrii. To znamená, že po životnom cykle opísanom vyššie budete musieť nezávisle opísať modely porušenia a potom ich použiť v bojovom systéme (nie sú tam žiadne vstavané modely).
Pre ELK sú samozrejme sofistikovanejšie rozšírenia, ktoré už obsahujú nejaké modely na detekciu anomálií v sieťovej telemetrii, no takéto rozšírenia stoja peniaze a je otázka, či vám hra stojí za sviečku – napíšte si podobný model sami, kúpte si jeho implementáciu pre váš monitorovací nástroj, alebo si kúpte hotové riešenie triedy Network Traffic Analysis.
Vo všeobecnosti sa nechcem púšťať do debaty o tom, že je lepšie minúť peniaze a kúpiť si hotové riešenie na sledovanie anomálií a hrozieb v sieťovej telemetrii (napríklad Cisco Stealthwatch) alebo na to prísť sám a prispôsobiť si to isté SiLK, ELK alebo nfdump alebo OSU Flow Tools pre každú novú hrozbu (hovorím o posledných dvoch z nich naposledy)? Každý si vyberá sám za seba a každý má svoje motívy na výber ktorejkoľvek z dvoch možností. Chcel som len ukázať, že sieťová telemetria je veľmi dôležitým nástrojom pri zabezpečovaní sieťovej bezpečnosti vašej internej infraštruktúry a nemali by ste ju zanedbávať, aby ste sa nezaradili do zoznamu spoločností, ktorých meno sa v médiách spomína spolu s prívlastkami “ hacknutý“, „nespĺňa požiadavky na bezpečnosť informácií“, „nemyslí na bezpečnosť svojich údajov a údajov o zákazníkoch“.
Aby som to zhrnul, rád by som uviedol kľúčové tipy, ktoré by ste mali dodržiavať pri budovaní monitorovania informačnej bezpečnosti vašej internej infraštruktúry:
- Neobmedzujte sa len na obvod! Využite (a vyberte si) sieťovú infraštruktúru nielen na presun prevádzky z bodu A do bodu B, ale aj na riešenie problémov kybernetickej bezpečnosti.
- Preštudujte si existujúce mechanizmy monitorovania informačnej bezpečnosti vo vašom sieťovom zariadení a použite ich.
- Pri internom monitorovaní uprednostňujte telemetrickú analýzu – umožňuje vám odhaliť až 80 – 90 % všetkých incidentov bezpečnosti informácií v sieti, pričom pri zachytávaní sieťových paketov robí to, čo je nemožné, a šetrí priestor na ukladanie všetkých udalostí informačnej bezpečnosti.
- Na sledovanie tokov použite Netflow v9 alebo IPFIX – poskytujú viac informácií v bezpečnostnom kontexte a umožňujú sledovať nielen IPv4, ale aj IPv6, MPLS atď.
- Použite protokol bez vzorkovania – poskytuje viac informácií na zisťovanie hrozieb. Napríklad Netflow alebo IPFIX.
- Skontrolujte zaťaženie vášho sieťového zariadenia – nemusí byť schopné zvládnuť aj protokol toku. Potom zvážte použitie virtuálnych senzorov alebo zariadenia Netflow Generation Appliance.
- Implementujte kontrolu predovšetkým na úrovni prístupu – to vám dá možnosť vidieť 100 % všetkej návštevnosti.
- Ak nemáte na výber a používate ruské sieťové vybavenie, vyberte si také, ktoré podporuje tokové protokoly alebo má porty SPAN/RSPAN.
- Kombinujte systémy detekcie/prevencie vniknutia/útokov na okrajoch a systémy analýzy toku vo vnútornej sieti (vrátane cloudov).
Pokiaľ ide o posledný tip, rád by som uviedol ilustráciu, ktorú som už uviedol. Vidíte, že ak predtým služba informačnej bezpečnosti Cisco takmer úplne vybudovala svoj monitorovací systém informačnej bezpečnosti na základe systémov detekcie narušenia a podpisových metód, teraz predstavujú len 20 % incidentov. Ďalších 20 % pripadá na systémy na analýzu tokov, čo naznačuje, že tieto riešenia nie sú rozmarom, ale skutočným nástrojom v činnosti služieb informačnej bezpečnosti moderného podniku. Navyše máte na ich implementáciu to najdôležitejšie - sieťovú infraštruktúru, investície do ktorej možno ďalej chrániť priradením funkcií monitorovania informačnej bezpečnosti sieti.
Konkrétne som sa nedotkol témy reakcie na anomálie alebo hrozby identifikované v sieťových tokoch, ale myslím si, že už teraz je jasné, že monitoring by nemal končiť len detekciou hrozby. Po ňom by mala nasledovať odpoveď, najlepšie v automatickom alebo automatizovanom režime. Ale toto je téma na samostatný článok.
Dodatočné Informácie:
PS. Ak je pre vás jednoduchšie počuť všetko, čo bolo napísané vyššie, môžete si pozrieť hodinovú prezentáciu, ktorá tvorila základ tejto poznámky.
Zdroj: hab.com