Keď sa hovorí o monitorovaní bezpečnosti vnútornej firemnej alebo štátnej siete, mnohým sa hneď vynorí predstava kontroly únikov informácií a zavádzania DLP riešení. Ak sa ale pokúsime objasniť otázku a opýtať sa, ako zistíte útoky vo vnútornej sieti, odpoveďou býva zvyčajne zmienka o systémoch detekcie útokov (intrusion detection systems, IDS). A to, čo bolo jedinou možnosťou pred 10-20 rokmi, sa dnes stáva anachronizmom. Existuje efektívnejšia, miestami aj jediná možná varianta monitorovania vnútornej siete — využívať flow protokoly, pôvodne určené na hľadanie sieťových problémov (troubleshooting), ale časom sa transformovali na veľmi zaujímavý nástroj bezpečnosti. O tom, aké flow protokoly existujú a ktoré z nich najlepšie pomáhajú odhaľovať sieťové útoky, kde je najlepšie zaviesť monitorovanie flow, na čo si dať pozor pri nasadení takejto schémy, a dokonca ako to všetko „rozbehnúť“ na domácom zariadení, budeme hovoriť v rámci tohto článku.
Nebudem sa zastavovať na otázke „Prečo je potrebné monitorovanie bezpečnosti vnútornej infraštruktúry?“ Odpoveď na ňu je už viac-menej jasná. Ale ak by ste sa predsa len chceli ešte raz presvedčiť, že dnes bez toho sa nikam nepohneme, krátke video s rozprávaním o tom, ako možno 17 spôsobmi preniknúť do firemnej siete, chránené firewallom. Preto budeme považovať, že chápeme, že vnútorné monitorovanie je potrebné a zostáva len pochopiť, ako ho môžeme zorganizovať.
Vyzdvihol by som tri kľúčové zdroje údajov na monitorovanie infraštruktúry na sieťovej úrovni:
- „surový“ trafik, ktorý zachytávame a podávame na analýzu niektorým analyzačným systémom,
- udalosti zo sieťových zariadení, cez ktoré prechádza trafik,
- informácie o traffiku získané prostredníctvom jedného z flow protokolov.
Zachytenie surového trafficu je najpopulárnejšou voľbou medzi bezpečnostnými odborníkmi, pretože historicky vzniklo ako prvé. Bežné sieťové systémy na detekciu útokov (prvým komerčným systémom na detekciu útokov bol NetRanger od spoločnosti Wheel Group, ktorý v roku 1998 zakúpila spoločnosť Cisco) sa primárne zaoberali zachytávaním paketov (a neskôr aj relácií), v ktorých sa hľadali určité podpisy („rozhodujúce pravidlá“ v terminológii FSTEK), signalizujúce útoky. Samozrejme, surový traffic je možné analyzovať nielen pomocou IDS, ale aj inými nástrojmi (napríklad Wireshark, tcpdump alebo funkciou NBAR2 v Cisco IOS), avšak obvykle im chýba databáza poznatkov, ktorá odlišuje bezpečnostný nástroj od bežného IT nástroja.
Takže, systémy na detekciu útokov. Najstaršia a najpopulárnejšia metóda detekcie sieťových útokov, ktorá celkom dobre plní svoju úlohu na perimetri (nezáleží na tom, či je to podnikový, dátové centrum, segment atď.), ale zlyháva v súčasných prepínaných a softvérovo definovaných sieťach. V prípade siete postavenej na bežných prepínačoch sa infraštruktúra senzorov detekcie útokov stáva príliš veľkou - budete musieť umiestniť senzor na každé pripojenie k uzlu, ktorý chcete monitorovať. Každý výrobca vám rád predá stovky a tisíce senzorov, ale myslím si, že váš rozpočet nevydrží také náklady. Môžem povedať, že ani v spoločnosti Cisco (kde sme vývojári NGIPS) sme to nedokázali, aj keď sa zdalo, že cena by nemala byť pre nás problémom - je to predsa naše vlastné riešenie. Okrem toho sa objavuje otázka, ako pripojiť senzor v takom prípade? V prepojení? A ak sa samotný senzor pokazí? Požadovať prítomnosť bypass modulu v senzore? Použiť rozdvojovače (tap)? To všetko zvyšuje náklady a robí riešenie nevhodným pre akúkoľvek firmu.
Môžete sa pokúsiť "pripevniť" senzor na porty SPAN/RSPAN/ERSPAN a nasmerovať na ne prevádzku z požadovaných portov prepínača. Táto možnosť čiastočne vyrieši problém popísaný v predchádzajúcom odseku, ale vytvorí iný — SPAN port nemôže prijať absolútne všetku prevádzku, ktorá do neho bude smerovaná — nebude mať dostatočnú kapacitu. Budete musieť niečo obetovať. Buď ponecháte niektoré uzly bez monitorovania (potom ich musíte najprv prioritizovať), alebo budete smerovať nie celú prevádzku z uzla, ale iba určitý typ. V každom prípade môžeme vynechať niektoré útoky. Okrem toho môže byť SPAN port obsadený na iné účely. Nakoniec budeme musieť prehodnotiť existujúcu topológiu siete a možno do nej vplyvniť zmeny, aby sme maximalizovali pokrytie vašej siete dostupným počtom senzorov (a dohodnúť sa s IT).
A čo keď vaša sieť používa asymetrické trasy? A čo ak máte implementovanú alebo plánujete implementáciu SDN? A čo ak potrebujete monitorovať virtualizované stroje alebo kontajnery, ktorých prevádzka sa vôbec nedostane k fyzickému prepínaču? Tieto otázky nemajú radi výrobcovia tradičných IDS, pretože nevedia, ako na ne odpovedať. Možno vás budú presviedčať, že všetky tieto moderné technológie sú len hype a že ich nepotrebujete. Možno vám povedia, že je potrebné začať s malým. Alebo možno povedia, že potrebujete nainštalovať výkonný stroj do centra siete a nasmerovať naň všetku prevádzku pomocou vyrovnávačov záťaže. Akúkoľvek možnosť vám ponúknu, musíte si sami jasne uvedomiť, ako veľmi vám vyhovuje. A až potom urobte rozhodnutie o prístupe k monitorovaniu bezpečnosti v sieti. Keď sa vrátim k zachytávaniu paketov, chcem povedať, že táto metóda naďalej zostáva veľmi populárna a dôležitá, ale jej hlavné určenie — kontrola hraníc; hraníc medzi vašou organizáciou a internetom, hraníc medzi dátovým centrom a ostatnými sieťami, hraníc medzi automatizovanými riadiacimi systémami a firemným segmentom. Na týchto miestach majú klasické IDS/IPS stále právo na existenciu a dobre sa dajú s úlohami.
Prejdeme k druhej možnosti. Analýza udalostí prijímaných zo sieťových zariadení môže byť využitá na detekciu útokov, nie však ako hlavný mechanizmus, pretože umožňuje detegovať len malý rozsah narušení. Navyše má určitú reakčnosť — útok musí najprv nastať, potom musí byť zaznamenaný sieťovým zariadením, ktoré nejakým spôsobom signalizuje problém s informačnou bezpečnosťou. Existuje niekoľko takých spôsobov. Môže to byť syslog, RMON alebo SNMP. Posledné dva protokoly na sieťové monitorovanie sa v kontexte informačnej bezpečnosti aplikujú len v prípade, ak potrebujeme odhaliť DoS útok na samotné sieťové zariadenie, pretože pomocou RMON a SNMP môžeme sledovať napríklad zaťaženie procesora zariadenia alebo jeho rozhraní. To je jeden z najlacnejších spôsobov (syslog alebo SNMP má každý), ale aj najneefektívnejší zo všetkých spôsobov monitorovania informačnej bezpečnosti v rámci vnútornej infraštruktúry — mnohé útoky sú jednoducho pred ním skryté. Samozrejme, netreba ich podceňovať a analýza syslog vám pomáha včas identifikovať zmeny v konfigurácii samotného zariadenia, jeho kompromitáciu, ale detekcia útokov na celú sieť sa veľmi nehodí.
Tretia možnosť — je analýza informácií o prevádzke prechádzajúcej cez zariadenie, ktoré podporuje jeden z niekoľkých flow protokolov. V tomto prípade, nezávisle od protokolu, infraštruktúra práce s prúdmi sa nevyhnutne skladá z troch komponentov:
- Generácia alebo export flow. Táto úloha sa zvyčajne priraďuje smerovaču, prepínaču alebo inému sieťovému zariadeniu, ktoré, prechádzajúce sieťovou prevádzkou, umožňuje vyťažiť kľúčové parametre, ktoré sa následne odosielajú na zberný modul. Napríklad u Cisco protokol Netflow podporujú nielen smerovače a prepínače, vrátane virtuálnych a priemyselných, ale aj bezdrôtové kontroléry, firewall-och a dokonca aj servery.
- Zber flow. Vzhľadom na to, že v modernej sieti býva zvyčajne viac ako jedno sieťové zariadenie, vzniká úloha zhromaždenia a konsolidácie prúdov, ktorú riešia takzvané kolektory, ktoré spracovávajú prijaté prúdy a následne ich odosielajú na analýzu.
- Analýza flow. Analizátor preberá hlavnú intelektuálnu úlohu a, aplikovaním rôznych algoritmov na toky, robí isté závery. Napríklad, v rámci IT funkcie môže takýto analizátor odhalovať úzke miesta v sieti alebo analyzovať profil zaťaženia prevádzky na ďalšiu optimalizáciu siete. A pre IB môže analizátor odhaľovať úniky dát, šírenie malvéru alebo DoS útoky.
Netreba si myslieť, že takáto trojvrstvová architektúra je príliš zložitá — všetky ostatné varianty (okrem možno systémov sieťového monitorovania fungujúcich so SNMP a RMON) pracujú podľa nej. Máme generátor dát na analýzu, ktorým je sieťové zariadenie alebo samostatný senzor. Máme systém na zber signálov poplachu a systém na správu celej monitorovacej infraštruktúry. Posledné dva komponenty môžu byť zjednotené v rámci jedného uzla, ale v relatívne veľkých sieťach sú zvyčajne rozdelené na dve, minimálne, zariadenia za účelom zabezpečenia škálovania a spoľahlivosti.
Na rozdiel od analýzy paketov, ktorá sa zakladá na skúmaní hlavičky a obsahu každého paketu a pozostáva z nich relácií, analýza tokov sa opiera o zber metadát o sieťovej prevádzke. Kedy, koľko, odkiaľ a kam, ako… to sú otázky, na ktoré odpovedá analýza sieťovej telemetrie pomocou rôznych protokolov flow. Pôvodne sa používali na analýzu štatistiky a hľadanie IT problémov v sieti, ale neskôr, s rozvojom analytických mechanizmov, ich bolo možné aplikovať aj na tú istú telemetriu a na účely bezpečnosti. Je potrebné ešte raz zdôrazniť, že analýza tokov nenahrádza a neodstráňuje zber paketov. Každá z týchto metód má svoju oblasť aplikácie. Ale v kontexte tohto článku je práve analýza tokov najvhodnejšia na monitorovanie vnútornej infraštruktúry. Máte sieťové zariadenia (a nezáleží na tom, či pracujú v softvérovo definovanej paradigme alebo podľa statických pravidiel), ktoré útok nemôže obísť. Senzor klasickej IDS môže útok obísť, ale sieťové zariadenie podporujúce flow protokol nie. V tom spočíva výhoda tejto metódy.
Na druhej strane, ak potrebujete dôkazy pre orgány činné v trestnom konaní alebo vlastnú skupinu na vyšetrovanie incidentov, bez zachytávania paketov sa nezaobídete — sieťová telemetria nie je kópiou prevádzky, ktorú môžete použiť pri zhromažďovaní dôkazov; je potrebná na rýchle zistenie a rozhodovanie v oblasti bezpečnosti informácií. Na druhej strane, pomocou analýzy telemetrie môžete "zapisovať" nie všetku sieťovú prevádzku (inak sa o to starajú Cisco a dátové centrá :-), ale len tú, ktorá sa podieľa na útoku. Nástroje na analýzu telemetrie v tomto ohľade dobre doplnia tradičné mechanizmy zachytávania paketov, pričom dajú príkaz na selektívne zachytávanie a uchovávanie. Inak budete musieť mať obrovskú infraštruktúru na uchovávanie.
Predstavme si sieť, ktorá pracuje rýchlosťou 250 Mbit/s. Ak by ste chceli uchovávať celý tento objem, potrebovali by ste úložisko na 31 MB pre jednu sekundu prenosu prevádzky, 1,8 GB — pre jednu minútu, 108 GB — pre jednu hodinu a 2,6 TB — pre jeden deň. Na uchovávanie denných údajov zo siete s priepustnosťou 10 Gbit/s by ste potrebovali úložisko na 108 TB. A niektorí regulátori požadujú uchovávanie údajov o bezpečnosti po celé roky... Záznam „na požiadanie“, ktorý vám pomáha realizovať analýza prúdov, pomáha znížiť tieto hodnoty o poriadky. Mimochodom, ak hovoríme o pomere objemu zapisovaných údajov sieťovej telemetrie a úplného zachytenia údajov, ten činí približne 1 ku 500. Pre rovnaké uvedené hodnoty bude uchovávanie úplnej dešifrovanej prevádzky počas celého dňa predstavovať 5 a 216 GB resp. (môžete to dokonca zapísať na obyčajnú USB kľúč).
Ak sa metódy na analýzu surových sieťových dát u jednotlivých dodávateľov takmer nelíšia, v prípade analýzy tokov je situácia iná. Existuje niekoľko variantov flow protokolov, o ktorých rozdieloch je potrebné vedieť práve v kontexte bezpečnosti. Najpopulárnejším je protokol Netflow vyvinutý spoločnosťou Cisco. Existuje niekoľko verzií tohto protokolu, ktoré sa líšia svojimi schopnosťami a objemom zapisovaných informácií o prevádzke. Aktuálna verzia — deviata (Netflow v9), na základe ktorej bol vyvinutý priemyselný štandard Netflow v10, známy aj ako IPFIX. Dnes väčšina sieťových dodávateľov podporuje práve Netflow alebo IPFIX vo svojich zariadeniach. Existujú však aj rôzne iné varianty flow protokolov — sFlow, jFlow, cFlow, rFlow, NetStream a podobne, z ktorých je sFlow najpopulárnejší. Tento protokol je najčastejšie podporovaný domácimi výrobcami sieťových zariadení kvôli jednoduchej implementácii. Aké sú kľúčové rozdiely medzi Netflow, ktorého sa stal de-facto štandardom, a sFlow? Rozdielov by som vyzdvihol niekoľko. Po prvé, Netflow má nastaviteľné polia používateľom v porovnaní s fixnými poliami v sFlow. Po druhé, a to je v našom prípade najdôležitejšie, sFlow zbiera takzvanú vzorkovanú telemetriu; na rozdiel od nevzorkovanej u Netflow a IPFIX. Aký je teda medzi nimi rozdiel?
Predstavte si, že ste sa rozhodli oboznámiť sa s knihou “” mojich kolegov — Garyho MakinTaira, Josepha Munica a Nadema Al-Fardana (na odkaze si môžete stiahnuť časť knihy). Máte tri možnosti, ako dosiahnuť stanovený cieľ — prečítať knihu celú, prebehnuť ju očami s tým, že sa zastavíte na každej 10., alebo 20. strane, alebo sa pokúsiť nájsť zhrnutie kľúčových konceptov v nejakom blogu alebo službe typu SmartReading. Takže nevzorkovaná telemetria je čítanie každej 'strany' sieťovej prevádzky, to znamená analýzu metadát pre každý paket. Vzorkovaná telemetria je výberové študovanie prevádzky s nádejou, že v vybraných vzorkách bude to, čo potrebujete. V závislosti od rýchlosti kanála vzorkovaná telemetria poskytne na analýzu každý 64., 200., 500., 1000., 2000., alebo dokonca 10000. paket.
V kontexte monitorovania IT bezpečnosti to znamená, že vzorkovaná telemetria je dobre prispôsobená na detekciu DDoS útokov, skenovania, šírenia malvéru, ale môže vynechať atomárne alebo viacpaketové útoky, ktoré sa nedostali do vzorky poslanej na analýzu. Nesmplovaná telemetria má takéto nevýhody minimálne a s jej pomocou je spektrum detekovaných útokov oveľa širšie. Tu je malý zoznam udalostí, ktoré je možné detekovať pomocou prostriedkov analýzy sieťovej telemetrie.
Samozrejme, žiadny open source analyzátor Netflow vám to nedovolí, keďže jeho hlavnou úlohou je zbierať telemetriu a vykonávať nad ňou základnú analýzu z pohľadu IT. Na identifikáciu hrozieb IT bezpečnosti na základe flow je potrebné vybaviť analyzátor rôznymi motorčekmi a algoritmami, ktoré budú vyhodnocovať problémy kybernetickej bezpečnosti na základe štandardných alebo používateľských polí Netflow, obohacovať štandardné dáta o externé údaje z rôznych zdrojov Threat Intelligence a pod.
Preto, ak máte na výber, zastavte sa na Netflow alebo IPFIX. Ale aj keď vaše zariadenia pracujú iba s sFlow, ako u domácich výrobcov, aj v tomto prípade môžete získať z neho benefity v kontexte bezpečnosti.
V lete 2019 som vykonal analýzu možností, ktoré majú ruskí výrobcovia sieťového hardvéru a všetci, okrem NSG, Poligon a Kraftway, uvádzali podporu sFlow (minimálne Zelaks, Natex, Eltex, QTech, Rusteletech).
Nasledujúca otázka, ktorá pred vami vyvstane, je, kde implementovať podporu flow pre bezpečnostné účely? V skutočnosti nie je otázka úplne presne formulovaná. Na moderných zariadeniach je podpora flow protokolov takmer vždy. Preto by som otázku preformuloval inak – kde je najefektívnejšie zbierať telemetriu z pohľadu bezpečnosti? Odpoveď bude dosť 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 budete môcť sledovať aj P2P prevádzku medzi hostiteľmi, čo je kritické na odhalenie skenovania a šírenia malvéru. Na úrovni jadra niektoré prevádzky jednoducho neuvidíte, a na úrovni perimetra uvidíte dobre, ak štvrtinu všetkého vášho sieťového toku. Ale ak z nejakého dôvodu vo vašej sieti existujú nežiaduce zariadenia, ktoré umožňujú útočníkom „vstupovať a vystupovať“ obchádzajúce perimetr, analýza telemetrie z neho vám nič nedá. Preto sa odporúča zahrnúť zber telemetrie práve na úrovni prístupu. Pri tom je potrebné poznamenať, že aj keď hovoríme o virtualizácii alebo kontajneroch, v moderných virtuálnych prepínačoch sa často vyskytuje podpora flow, čo umožňuje kontrolovať prevádzku aj tam.
Ale keďže som otvoril túto tému, musím odpovedať na otázku, čo ak predsa len zariadenie, fyzické alebo virtuálne, nepodporuje flow protokoly? Alebo jeho zapnutie je zakázané (napríklad v priemyselných segmentoch pre zabezpečenie spoľahlivosti)? Alebo jeho zapnutie vedie k vysokej záťaži procesora (to sa stáva na zastaraných zariadeniach)? Na riešenie tohto problému existujú špecializované virtuálne senzory (flow sensor), ktoré v podstate fungujú ako bežné rozbočovače, ktoré prepúšťajú cez seba prevádzku a prenášajú ju vo forme flow na zberný modul. Pravda, v tomto prípade dostávame celý balík problémov, o ktorých sme hovorili vyššie v súvislosti s prostriedkami na zachytávanie paketov. To znamená, že musíme chápať nielen výhody technológie analýzy prúdenia, ale aj jej obmedzenia.
Ďalší aspekt, ktorý je dôležité mať na pamäti pri diskusii o nástrojoch na analýzu tokov. Pokiaľ pri bežných nástrojoch na generovanie bezpečnostných udalostí používame metriku EPS (event per second, udalosti za sekundu), pri analýze telemetrie sa táto metrika nahrádza FPS (flow per second, toky za sekundu). Rovnako ako pri EPS, jej hodnotu nie je možné vypočítať vopred, ale je možné odhadnúť približný počet tokov, ktoré generuje konkrétne zariadenie v závislosti od jeho úlohy. Na internete nájdete tabuľky s približnými hodnotami pre rôzne typy podnikov, čo vám pomôže určiť, aké licencie potrebujete pre nástroje na analýzu a aká bude ich architektúra. Ide o to, že IDS senzor má obmedzenú priepustnosť, ktorú dokáže „vytiahnuť“, a kolektor tokov má svoje obmedzenia, ktoré je potrebné chápať. Preto v veľkých, teritoriálne rozložených sieťach je bežne viacero kolektorov. Keď som opisoval, , už som uviedol počet našich kolektorov — je ich 21. A to na sieť rozprestierajúcu sa na piatich kontinentoch a obsahujúcu približne pol milióna aktívnych zariadení).
Ako systém monitorovania Netflow používame naše vlastné riešenie , ktoré je špeciálne zamerané na riešenie bezpečnostných úloh. Má množstvo vnorených motorov na detekciu anomálnej, podozrivej a jednoznačne škodlivej aktivity, čo umožňuje detekciu širokého spektra rôznych hrozieb — od kryptominingu po úniky informácií, od šírenia škodlivého kódu po podvody. Rovnako ako väčšina analyzátorov tokov je Stealthwatch postavený na trojstupňovej schéme (generátor — zberač — analytik), avšak je doplnený o množstvo zaujímavých funkcií, ktoré sú dôležité v kontexte preberaného materiálu. Po prvé, integruje sa s riešeniami na zachytávanie paketov (napríklad Cisco Security Packet Analyzer), čo umožňuje zaznamenávať vybrané sieťové relácie na neskoršie hlboké vyšetrovanie a analýzu. Po druhé, špeciálne na rozšírenie bezpečnostných úloh sme vyvinuli špeciálny protokol nvzFlow, ktorý umožňuje „transmitovať“ aktivitu aplikácií na koncových uzloch (serveroch, pracovných staniciach a pod.) do telemetrie a prenášať ju na zberač na ďalšiu analýzu. Ak v svojom pôvodnom variante Stealthwatch pracuje s akýmkoľvek flow-protokolom (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) na úrovni siete, podpora nvzFlow umožňuje vykonávať koreláciu údajov aj na úrovni uzla, čím zvyšuje efektivitu celého systému a vidí viac útokov ako bežné sieťové analyzátory tokov.
Je zrejmé, že keď hovoríme o systémoch analýzy Netflow z hľadiska bezpečnosti, trh nie je obmedzený len na jedno riešenie od Cisco. Môžete používať ako komerčné, tak aj bezplatné alebo podmienečne bezplatné riešenia. Je dosť zvláštne, ak by som na blogu Cisco uvádzal ako príklad riešenia konkurentov, preto poviem pár slov o tom, ako môže byť sieťová telemetria analyzovaná pomocou dvoch populárnych, podobne pomenovaných, ale predsa len rôznych nástrojov — SiLK a ELK.
SiLK — je súbor nástrojov (the System for Internet-Level Knowledge) na analýzu prevádzky, vyvinutý americkým CERT/CC, ktorý podporuje, v kontexte dnešného článku, Netflow (5. a 9. najpopulárnejšie verzie), IPFIX a sFlow, a pomocou rôznych utilít (rwfilter, rwcount, rwflowpack a ďalšie) vykonáva rôzne operácie na sieťovej telemetrii s cieľom identifikovať v nej znaky neoprávnených činností. Je však potrebné zdôrazniť niekoľko dôležitých bodov. SiLK je nástroj príkazového riadku a pre vykonávanie operatívnej analýzy je potrebné neustále zadávať príkazy typu (identifikácia 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 je to veľmi pohodlné. Môžete použiť grafické rozhranie iSiLK, ale to výrazne nezjednoduší váš život, pretože plní iba funkciu vizualizácie, a nie nahrádzania analytika. A toto je druhý bod. Na rozdiel od komerčných riešení, ktoré už obsahujú solídnu analytickú základňu, algoritmy na detekciu anomálií, workflow a podobne, v prípade SiLK budete musieť všetko toto vykonať sami, čo si vyžaduje iné kompetencie, než používanie už hotového nástroja. Nie je to dobré ani zlé — to je vlastnosť takmer každého bezplatného nástroja, ktorý predpokladá, že presne viete, čo robiť, a on vám iba pomôže v tomto (komerčné nástroje sú menej závislé od kompetencií svojich používateľov, aj keď tiež predpokladajú, že analytici rozumejú aspoň základom sieťových vyšetrovaní a monitorovania). Ale vráťme sa k SiLK. Pracovný cyklus analytika s ním vypadá nasledovne:
- Formulovanie hypotézy. Musíme chápať, čo budeme hľadať v sieťovej telemetrii, poznať unikátne atribúty, podľa ktorých identifikujeme tie alebo iné anomálie alebo hrozby.
- Vybudovanie modelu. Formulovaním hypotézy ju programujeme pomocou Pythonu, shellu alebo iných nástrojov, ktoré nie sú súčasťou SiLK.
- Testovanie. Nastáva čas overiť správnosť našej hypotézy, ktorá sa potvrdzuje alebo vyvracia pomocou utilít SiLK, začínajúcich na 'rw', 'set', 'bag'.
- Analýza reálnych dát. V priemyselných aplikáciách nám SiLK pomáha identifikovať niečo a analytik musí odpovedať na otázky ako „Našli sme to, čo sme predpokladali?“, „Zodpovedá to našej hypotéze?“, „Ako znížiť počet falošných poplachov?“, „Ako zlepšiť úroveň rozpoznania?“ a podobne.
- Zlepšenie. V konečnej fáze vylepšujeme to, čo sme už vytvorili – vytvárame šablóny, zlepšujeme a optimalizujeme kód, preformulovávame a spresňujeme hypotézu a iné.
Tento cyklus bude aplikovateľný aj na Cisco Stealthwatch, len posledný tieto päť krokov maximalizuje automatizáciu, čím znižuje počet chýb analytika a zvyšuje operatívnosť pri odhaľovaní incidentov. Napríklad v SiLK môžete sieťovú štatistiku obohatiť o externé dáta o škodlivých IP pomocou vlastnoručne napísaných skriptov, zatiaľ čo v Cisco Stealthwatch je to vstavaná funkcia, ktorá okamžite zobrazuje alarm, ak sa v sieťovej prevádzke vyskytuje interakcia s IP adresami zo zoznamu zakázaných.
Ak sa posunieme vyššie po pyramíde „plateného“ softvéru na analýzu flow, potom grátis SiLK nasleduje podmienečne zadarmo ELK, ktorý sa skladá z troch kľúčových komponentov – Elasticsearch (indexácia, vyhľadávanie a analýza dát), Logstash (vstup/výstup dát) a Kibana (vizualizácia). Na rozdiel od SiLK, kde všetko musíte napísať sami, má ELK už mnoho pripravených knižníc/module (časť platených, časť nie), ktoré automatizujú analýzu sieťovej telemetrie. Napríklad filter GeoIP v Logstash umožňuje priradiť pozorované IP adresy k ich geografickej polohe (u Stealthwatch je to vstavaná funkcia).
ELK má tiež dosť veľké komunity, ktorá dopisuje chýbajúce komponenty pre toto riešenie na monitorovanie. Napríklad na prácu s Netflow, IPFIX a sFlow môžete využiť modul , ak vás neuspokojuje Logstash Netflow Module, ktorý podporuje iba Netflow.
Zatiaľ čo ELK poskytuje väčšiu operatívnosť pri zbere flow a jeho vyhľadávaní, momentálne postráda bohatú vstavanú analytiku na odhaľovanie anomálií a hrozieb v sieťovej telemetrii. To znamená, že podľa vyššie popísaného životného cyklu budete musieť samostatne popísať modely porušovania a potom už nimi môcť disponovať v reálnom systéme (vstavané modely tam nie sú).
Samozrejme, existujú aj sofistikovanejšie rozšírenia pre ELK, ktoré už obsahujú niektoré modely na odhaľovanie anomálií v sieťovej telemetrii, ale takéto rozšírenia stoja peniaze a tu už je otázka, či to stojí za to — vyvinúť si podobný model sám, zakúpiť jeho implementáciu pre svoje monitorovacie prostriedky alebo kúpiť hotové riešenie triedy Analýza sieťového prevádzky.
Vôbec sa nechcem zaoberať polemikou, či lepšie je utratiť peniaze a kúpiť hotové riešenie pre monitorovanie anomálií a hrozieb v sieťovej telemetrii (napríklad Cisco Stealthwatch) alebo sa s tým vysporiadať samostatne a prispôsobiť si k každej novej hrozbe rovnaké SiLK, ELK alebo nfdump či OSU Flow Tools (myslím tie posledné dva z nich z minulej doby)? Každý si vyberá pre seba a každý má svoje pohnútky, prečo si zvoliť ktorúkoľvek z dvoch variant. Ja som chcel len ukázať, že sieťová telemetria je veľmi dôležitý nástroj pri zabezpečení sieťovej bezpečnosti vlastnej infraštruktúry, a nemali by sme ňou pohŕdať, aby sme sa neocitli na zozname spoločností, ktorých meno sa spomína v médiách spolu s epitetami „hacknutá“, „nedodržiavajúca požiadavky v oblasti informačnej bezpečnosti“, „nepremýšľajúca o bezpečnosti svojich dát a údajov klientov“.
Na záver by som chcel uviesť kľúčové rady, ktorými by sa malo riadiť pri budovaní monitorovania informačnej bezpečnosti vlastnej infraštruktúry:
- Nerobte si len obvodové bezpečnostné opatrenia! Používajte (a vyberajte) sieťovú infraštruktúru nielen na prenos prevádzky z bodu A do bodu B, ale aj na riešenie otázok kybernetickej bezpečnosti.
- Preskúmajte existujúce mechanizmy monitorovania informačnej bezpečnosti vo vašom sieťovom zariadení a využívajte ich.
- Pre vnútorné monitorovanie dávajte prednosť analýze telemetrie — umožňuje odhaliť až 80-90% všetkých sieťových incidentov informačnej bezpečnosti, zatiaľ čo poskytuje to, čo je nemožné pri zachytávaní sieťových paketov a šetrí miesto na ukladanie všetkých udalostí informačnej bezpečnosti.
- Na monitorovanie tokov používajte Netflow v9 alebo IPFIX – poskytujú viac informácií v kontexte bezpečnosti a umožňujú monitorovať nielen IPv4, ale aj IPv6, MPLS atď.
- Používajte nesampľovaný flow-protokol – poskytuje viac informácií pre odhaľovanie hrozieb. Napríklad, Netflow alebo IPFIX.
- Skontrolujte zaťaženie vašich sieťových zariadení – možno nezvládnu spracovávať aj flow protokol. Potom zvážte využitie virtuálnych senzorov alebo Netflow Generation Appliance.
- Implementujte kontrolu najprv na úrovni prístupu – to vám umožní vidieť 100% celého trafficu.
- Ak nemáte na výber a používate ruské sieťové zariadenia, vyberte si tie, ktoré podporujú flow protokoly alebo majú SPAN/RSPAN porty.
- Kombinujte systémy detekcie/preventívne systémy útokov na hraniciach a systémy analýzy tokov vo vnútornej sieti (vrátane a v cloude).
Čo sa týka poslednej rady, rád by som uviedol ilustráciu, ktorú som už spomínal skôr. Vidíte, že ak predtým služba IT bezpečnosti Cisco téměř úplne budovala svoj monitoring informačnej bezpečnosti na základe systémov detekcie vniknutia a signatúrnych metód, teraz na ich podiel pripadá iba 20% incidentov. Ďalších 20% pripadá na systémy analýzy tokov, čo naznačuje, že tieto riešenia sú reálnym nástrojom v činnosti služieb informačnej bezpečnosti moderného podniku. O to viac, že máte na ich implementáciu to najdôležitejšie – sieťovú infraštruktúru, do ktorej môžete dodatočne investovať, a na sieť môžete zveriť aj funkcie monitorovania bezpečnosti.
Špeciálne som sa nechcel zaoberať témou reakcie na zistené anomálie alebo hrozby vo sieťových tokoch, ale myslím, že je jasné, že monitoring by nemal končiť iba detekciou hrozby. Následne by mala nasledovať reakcia, a to ideálne automaticky alebo v automatizovanom režime. Ale to je už téma samostatného materiálu.
Ďalšie informácie:
P.S. Ak máte jednoduchšie vnímať všetko, čo bolo napísané vyššie, môžete si pozrieť hodinovú prezentáciu, ktorá sa stala základom tejto poznámky.
Zdroj: habr.com
