Pokud jde o monitorování bezpečnosti interní podnikové nebo oddělení sítě, mnozí jej spojují s kontrolou úniku informací a implementací řešení DLP. A pokud se pokusíte otázku upřesnit a zeptáte se, jak odhalujete útoky na vnitřní síť, pak odpovědí obvykle bude zmínka o systémech detekce narušení (IDS). A to, co bylo před 10-20 lety jedinou možností, se dnes stává anachronismem. Existuje efektivnější, a místy i jediná možná možnost monitorování vnitřní sítě – využít flow protokoly, původně určené k vyhledávání síťových problémů (troubleshooting), ale časem přeměněné ve velmi zajímavý bezpečnostní nástroj. Zde si povíme, co jsou tokové protokoly a které pomáhají lépe detekovat síťové útoky, kde je nejlepší implementovat sledování toku, na co si dát pozor při nasazování takového schématu a dokonce jak to vše „vychovat“ na domácím zařízení. , budeme hovořit v rámci tohoto článku.
Nebudu se zabývat otázkou „Proč potřebujeme monitorovat bezpečnost vnitřní infrastruktury?“ Odpověď na to je jaksi zřejmá. Pokud se však přesto chcete ještě jednou ujistit, že se bez něj dnes neobejdete, krátké video s příběhem o tom, jak se můžete 17 způsoby dostat do firemní sítě chráněné firewallem. Budeme tedy předpokládat, že chápeme, že interní monitoring je nezbytná věc a zbývá jen pochopit, jak jej lze organizovat.
Vybral bych tři klíčové zdroje dat pro monitorování infrastruktury na úrovni sítě:
- „surový“ provoz, který zachytíme a předáme k analýze do některých analytických systémů,
- události ze síťových zařízení, kterými prochází provoz,
- dopravní informace přijaté prostřednictvím jednoho z tokových protokolů.
Zachycení surového provozu je mezi bezpečnostními lidmi nejoblíbenější možností, protože se historicky objevilo a bylo úplně první. Konvenční systémy detekce narušení sítě (úplně první komerční systém detekce narušení byl NetRanger od Wheel Group, koupený v roce 1998 společností Cisco) se právě zabývaly zachycováním paketů (a pozdějších relací), ve kterých byly prohledávány určité signatury („rozhodující pravidla“ v terminologie FSTEC), signalizace útoků. Samozřejmě můžete analyzovat nezpracovaný provoz nejen pomocí IDS, ale také pomocí dalších nástrojů (například Wireshark, tcpdum nebo funkcionalita NBAR2 v Cisco IOS), ale obvykle jim chybí znalostní báze, která odlišuje nástroj pro zabezpečení informací od běžný IT nástroj.
Takže systémy detekce narušení. Nejstarší a nejoblíbenější metoda detekce síťových útoků, která odvádí dobrou práci na perimetru (bez ohledu na to - korporátní, datové centrum, segment atd.), ale selhává v moderních přepínaných a softwarově definovaných sítích. V případě sítě postavené na bázi konvenčních přepínačů se infrastruktura senzorů detekce narušení příliš rozroste - budete muset umístit senzor na každé připojení k hostiteli, proti kterému chcete monitorovat útoky. Každý výrobce vám samozřejmě rád prodá stovky a tisíce senzorů, ale myslím, že váš rozpočet takové výdaje neunese. Mohu říci, že ani ve společnosti Cisco (a my jsme vývojáři NGIPS) jsme to nedokázali, i když, zdá se, je před námi otázka ceny. by neměly stát - je to naše vlastní rozhodnutí. Navíc vyvstává otázka, jak připojit snímač v této verzi? Do mezery? Co když selže samotný senzor? Vyžaduje se bypass modul ve snímači? Používat rozbočovače (kohoutky)? To vše zvyšuje náklady na řešení a činí jej nedostupným pro společnost jakékoli velikosti.
Můžete zkusit „zavěsit“ senzor na port SPAN/RSPAN/ERSPAN a směrovat na něj provoz z potřebných portů přepínače. Tato možnost částečně odstraňuje problém popsaný v předchozím odstavci, ale představuje další - port SPAN nemůže přijímat absolutně veškerý provoz, který na něj bude odeslán - nebude mít dostatečnou šířku pásma. Ochotný něco obětovat. Buď ponechte některé z uzlů bez monitorování (pak je nejprve musíte upřednostnit), nebo neposílejte z uzlu veškerý provoz, ale pouze určitý typ. V každém případě můžeme některé útoky minout. Port SPAN lze navíc obsadit pro jiné potřeby. V důsledku toho budeme muset přezkoumat stávající topologii sítě a případně ji upravit, abychom vaši síť pokryli na maximum počtem senzorů, které máte (a koordinovat to s IT).
Co když vaše síť používá asymetrické trasy? A pokud jste implementovali nebo plánujete implementovat SDN? Co když ale potřebujete monitorovat virtualizované stroje nebo kontejnery, jejichž provoz se k fyzickému přepínači vůbec nedostane? To jsou otázky, které tradiční prodejci IDS nemají rádi, protože nevědí, jak na ně odpovědět. Snad vás přesvědčí, že všechny tyto módní technologie jsou humbuk a vy to nepotřebujete. Možná budou mluvit o nutnosti začít v malém. Nebo možná řeknou, že musíte do středu sítě umístit výkonnou mlátičku a nasměrovat do ní veškerý provoz pomocí load balancerů. Ať je vám nabídnuta jakákoli možnost, vy sami musíte jasně pochopit, jak vám vyhovuje. A teprve poté se rozhodnout o volbě přístupu ke sledování informační bezpečnosti síťové infrastruktury. Vrátíme-li se k zachycování paketů, chci říci, že tato metoda je i nadále velmi populární a důležitá, ale jejím hlavním účelem je kontrola hranic; hranice mezi vaší organizací a internetem, hranice mezi datovým centrem a zbytkem sítě, hranice mezi systémem řízení procesů a firemním segmentem. V těchto místech mají klasické IDS / IPS stále právo existovat a dělat dobrou práci se svými úkoly.
Přejděme k druhé možnosti. Analýza událostí přicházejících ze síťových zařízení může být také použita pro účely detekce narušení, ale ne jako hlavní mechanismus, protože detekuje pouze malou třídu narušení. Navíc je tomu vlastní určitá reaktivita – nejprve musí dojít k útoku, poté jej musí opravit síťové zařízení, které tak či onak signalizuje problém s informační bezpečností. Existuje několik takových metod. Může to být syslog, RMON nebo SNMP. Poslední dva protokoly pro monitorování sítě v rámci informační bezpečnosti se používají pouze v případě, že potřebujeme detekovat DoS útok na samotné síťové zařízení, jelikož pomocí RMON a SNMP lze např. sledovat zátěž centrálního procesoru zařízení popř. jeho rozhraní. Jedná se o jeden z „nejlevnějších“ (každý má syslog nebo SNMP), ale také o nejneefektivnější ze všech způsobů sledování informační bezpečnosti vnitřní infrastruktury – mnoho útoků je před ním jednoduše skryto. Samozřejmě by se neměly zanedbávat a stejná analýza syslog vám pomůže včas identifikovat změny v konfiguraci samotného zařízení, které jej ohrozí, ale není příliš vhodná pro detekci útoků na celou síť.
Třetí možností je analyzovat informace o provozu procházejícím zařízením, které podporuje jeden z několika tokových protokolů. V tomto případě, bez ohledu na protokol, se streamovací infrastruktura nutně skládá ze tří komponent:
- Tok generování nebo exportu. Tato role je obvykle přiřazena routeru, přepínači nebo jinému síťovému zařízení, které vám po průchodu síťového provozu umožňuje extrahovat z něj klíčové parametry, které jsou pak přenášeny do sběrného modulu. Například protokol Netflow společnosti Cisco je podporován nejen na směrovačích a přepínačích, včetně virtuálních a průmyslových, ale také na bezdrátových ovladačích, firewallech a dokonce i serverech.
- Sběrný tok. Vzhledem k tomu, že v moderní síti je obvykle více než jedno síťové zařízení, vyvstává problém se sběrem a konsolidací toků, který je řešen pomocí tzv. kolektorů, které přijaté toky zpracovávají a následně předávají k analýze.
- toková analýza. Analyzátor převezme hlavní intelektuální úkol a použitím různých algoritmů na proudy vyvodí určité závěry. Například v rámci funkce IT může takový analyzátor identifikovat úzká místa sítě nebo analyzovat profil zatížení provozu za účelem další optimalizace sítě. A kvůli bezpečnosti informací dokáže takový analyzátor odhalit úniky dat, šíření škodlivého kódu nebo DoS útoky.
Nemyslete si, že taková třívrstvá architektura je příliš složitá – všechny ostatní možnosti (snad s výjimkou systémů pro monitorování sítě, které pracují s SNMP a RMON) fungují také podle ní. K analýze máme generátor dat, což je síťové zařízení nebo samostatný senzor. Máme systém sběru alarmů a máme systém řízení pro celou monitorovací infrastrukturu. Poslední dvě komponenty lze kombinovat v rámci jednoho uzlu, ale ve více či méně rozsáhlých sítích jsou obvykle rozprostřeny alespoň na dvě zařízení, aby byla zajištěna škálovatelnost a spolehlivost.
Na rozdíl od analýzy paketů, která je založena na studiu hlavičky a těla dat každého paketu a relací z nich sestávajících, se analýza toku opírá o sběr metadat o síťovém provozu. Kdy, kolik, odkud a kde, jak... to jsou otázky, na které odpovídá analýza síťové telemetrie pomocí různých tokových protokolů. Zpočátku byly používány k analýze statistik a vyhledávání problémů IT v síti, ale poté, jak se vyvinuly analytické mechanismy, bylo možné je aplikovat na stejnou telemetrii pro bezpečnostní účely. Zde stojí za to zopakovat, že analýza toku nenahrazuje ani nenahrazuje zachycení paketů. Každá z těchto metod má svůj vlastní rozsah. Ale v kontextu tohoto článku je to analýza toku, která se nejlépe hodí pro monitorování interní infrastruktury. Máte síťová zařízení (ať už fungují v softwarově definovaném paradigmatu nebo podle statických pravidel), která útok nemůže obejít. Dokáže obejít klasický IDS senzor, ale ne síťové zařízení, které podporuje flow protokol. To je výhoda této metody.
Na druhou stranu, pokud potřebujete důkazní základnu pro vymáhání práva nebo vlastní tým pro vyšetřování incidentů, neobejdete se bez zachycování paketů – síťová telemetrie není kopií provozu, kterou lze použít ke sběru důkazů; je potřebný pro rychlou detekci a rozhodování v oblasti informační bezpečnosti. Na druhou stranu pomocí telemetrické analýzy můžete „zapsat“ ne veškerý síťový provoz (pokud vůbec, Cisco je zapojeno i do datových center :-), ale pouze ten, který je zapojen do útoku. Nástroje telemetrické analýzy v tomto ohledu dobře doplní tradiční mechanismy zachycování paketů a dají příkaz pro selektivní zachycování a ukládání. V opačném případě budete muset mít kolosální infrastrukturu úložiště.
Představte si síť běžící rychlostí 250 Mbps. Pokud chcete celý tento objem ušetřit, budete potřebovat 31 MB úložiště na jednu sekundu přenosu provozu, 1,8 GB na jednu minutu, 108 GB na jednu hodinu a 2,6 TB na jeden den. Pro ukládání denních dat ze sítě s šířkou pásma 10 Gb/s budete potřebovat 108 TB úložiště. Některé regulační orgány však vyžadují, abyste bezpečnostní data uchovávali roky... Záznam na vyžádání s analýzou toku vám pomůže snížit tyto hodnoty o řády. Mimochodem, pokud mluvíme o poměru objemu zaznamenaných dat síťové telemetrie a úplného zachycení dat, pak je to přibližně 1 až 500. Pro stejné hodnoty uvedené výše je uložení úplného dešifrování veškerého denního provozu bude činit 5 a 216 GB (můžete dokonce zapisovat na běžný flash disk).
Pokud je způsob zachycování nezpracovaných síťových dat pro analytické nástroje téměř stejný u jednotlivých dodavatelů, pak v případě analýzy proudů je situace jiná. Existuje několik variant tokových protokolů, rozdíly ve kterých je potřeba znát v kontextu bezpečnosti. Nejpopulárnější je protokol Netflow vyvinutý společností Cisco. Existuje několik verzí tohoto protokolu, které se liší svými schopnostmi a množstvím zaznamenaných informací o provozu. Aktuální verze je devátá (Netflow v9), ze které byl vyvinut průmyslový standard Netflow v10, také známý jako IPFIX. Dnes většina síťových prodejců podporuje Netflow nebo IPFIX ve svých zařízeních. Existují ale různé další varianty tokových protokolů – sFlow, jFlow, cFlow, rFlow, NetStream atd., z nichž sFlow je nejoblíbenější. Právě on je nejčastěji podporován domácími výrobci síťových zařízení kvůli snadné implementaci. Jaké jsou klíčové rozdíly mezi Netflow, jako de facto standardem, a stejným sFlow? Vyzdvihl bych několik klíčových. Za prvé, Netflow má uživatelsky konfigurovatelná pole na rozdíl od pevných polí v sFlow. A za druhé, a to je v našem případě to nejdůležitější, sFlow sbírá tzv. vzorkovanou telemetrii; na rozdíl od nevzorkovaných Netflow a IPFIX. Jaký je mezi nimi rozdíl?
Představte si, že se rozhodnete číst knihu“” moji kolegové Gary McIntyre, Joseph Munitz a Nadem Alfardan (část knihy si můžete stáhnout z odkazu). Máte tři možnosti, jak dosáhnout svého cíle – přečtěte si knihu celou, prolistujte ji, zastavte se na každé 10. nebo 20. stránce nebo se pokuste najít převyprávění klíčových pojmů v blogu nebo službě, jako je SmartReading. Nevzorkovaná telemetrie je tedy čtení každé „stránky“ síťového provozu, tedy analýza metadat pro každý paket. Vzorkovaná telemetrie je selektivní studie provozu v naději, že vybrané vzorky budou to, co potřebujete. V závislosti na rychlosti kanálu odešle vzorkovaná telemetrie každý 64., 200., 500., 1000., 2000. nebo dokonce 10000. paket k analýze.
V kontextu monitorování bezpečnosti informací to znamená, že vzorková telemetrie se dobře hodí pro detekci DDoS útoků, skenování, šíření škodlivého kódu, ale může chybět atomické nebo multipaketové útoky, které nejsou zahrnuty ve vzorku odeslaném k analýze. Ani unswept telemetrie u ní takové nedostatky nemá. využití rozsahu detekovaných útoků je mnohem širší. Zde je malý seznam událostí, které lze detekovat pomocí nástrojů síťové telemetrické analýzy.
Nějaký open source Netflow analyzátor vám to samozřejmě neumožní, protože jeho hlavním úkolem je sbírat telemetrii a provádět na ní základní analýzu z pohledu IT. Pro identifikaci hrozeb IS na základě toku je nutné vybavit analyzátor různými enginy a algoritmy, které budou identifikovat problémy kybernetické bezpečnosti na základě standardních nebo vlastních polí Netflow, obohatit standardní data o externí data z různých zdrojů Threat Intelligence atd.
Proto, pokud máte na výběr, zastavte to na Netflow nebo IPFIX. Ale i když vaše zařízení funguje pouze s sFlow, jako domácí výrobci, pak i v tomto případě z něj můžete těžit v bezpečnostním kontextu.
V létě 2019 jsem analyzoval příležitosti, které mají ruští výrobci síťového železa, a všichni, kromě NSG, Polygon a Craftway, oznámili podporu pro sFlow (alespoň Zelaks, Natex, Eltex, QTech, Rusteletech).
Další otázka, která před vámi vyvstane, je, kde implementovat podporu toku pro bezpečnostní účely? Ve skutečnosti není otázka položena zcela správně. Na moderních zařízeních jsou protokoly toku téměř vždy podporovány. Proto bych otázku přeformuloval jinak – kde je z bezpečnostního hlediska nejefektivnější způsob sběru telemetrie? Odpověď bude zcela zřejmá – na úrovni přístupu, kde uvidíte 100 % veškerého provozu, kde budete mít podrobné informace o hostitelích (MAC, VLAN, ID rozhraní), kde můžete sledovat i P2P provoz mezi hostiteli, který je rozhodující pro detekci a distribuci škodlivého kódu skenováním. Na základní úrovni možná jednoduše neuvidíte část provozu, ale na úrovni perimetru uvidíte dobře čtvrtinu síťového provozu. Ale pokud z nějakého důvodu máte ve své síti cizí zařízení, která umožňují útočníkům „vstoupit a opustit“ obcházení perimetru, pak analýza telemetrie z ní vám nic nedá. Pro maximální pokrytí se proto doporučuje povolit sběr telemetrie na úrovni přístupu. Zároveň stojí za zmínku, že i když se bavíme o virtualizaci nebo kontejnerech, moderní virtuální přepínače také často podporují tok, který umožňuje řídit provoz i tam.
Ale protože jsem toto téma nastolil, pak musím odpovědět na otázku, co když přece jen zařízení, fyzické nebo virtuální, nepodporuje tokové protokoly? Nebo je jeho zařazení zakázáno (např. v průmyslových segmentech pro zajištění spolehlivosti)? Nebo jeho zapnutí způsobuje vysoké využití procesoru (to se stává na starším hardwaru)? K vyřešení tohoto problému existují specializované virtuální senzory (flow sensor), což jsou v podstatě obyčejné splittery, které si propouštějí provoz a vysílají ho ve formě toku do sběrného modulu. Pravda, v tomto případě dostaneme celou hromadu problémů, o kterých jsme mluvili výše v souvislosti s nástroji pro zachycení paketů. To znamená, že je nutné pochopit nejen výhody technologie analýzy toku, ale také její omezení.
Ještě jeden bod, který je důležité mít na paměti, když mluvíme o nástrojích analýzy toku. Pokud použijeme metriku EPS (událost za sekundu, události za sekundu) ve vztahu k obvyklým prostředkům generování bezpečnostních událostí, pak tento indikátor nelze použít pro telemetrickou analýzu; je nahrazena FPS (průtok za sekundu, průtok za sekundu). Stejně jako v případě EPS jej nelze předem vypočítat, ale lze odhadnout přibližný počet vláken, které konkrétní zařízení generuje v závislosti na své úloze. Na internetu můžete najít tabulky s přibližnými hodnotami pro různé typy podnikových zařízení a podmínek, které vám umožní odhadnout, jaké licence potřebujete pro analytické nástroje a jaká bude jejich architektura? Faktem je, že snímač IDS je omezen na určitou šířku pásma, kterou „vytáhne“ a průtokový kolektor má svá vlastní omezení, která je třeba pochopit. Ve velkých, geograficky distribuovaných sítích je proto obvykle několik kolektorů. Když jsem popisoval , počet našich sběračů jsem již uvedl - je jich 21. A to na síť roztroušenou po pěti kontinentech a čítající asi půl milionu aktivních zařízení).
Používáme vlastní řešení jako monitorovací systém Netflow , která je specificky zaměřena na řešení bezpečnostních problémů. Má mnoho vestavěných enginů pro detekci anomální, podezřelé a zjevně škodlivé činnosti, což umožňuje odhalit širokou škálu různých hrozeb – od kryptominace po úniky informací, od distribuce škodlivého kódu po podvody. Jako většina průtokových analyzátorů je i Stealthwatch postaven na tříúrovňovém schématu (generátor - kolektor - analyzátor), je však doplněn o řadu zajímavých funkcí, které jsou důležité v kontextu uvažovaného materiálu. Za prvé se integruje s řešeními pro zachytávání paketů (jako je Cisco Security Packet Analyzer), což vám umožňuje zaznamenávat vybrané síťové relace pro pozdější hloubkové zkoumání a analýzu. Za druhé, konkrétně pro rozšíření bezpečnostních úkolů, jsme vyvinuli speciální protokol nvzFlow, který umožňuje „vysílat“ aplikační aktivitu na koncových uzlech (servery, pracovní stanice atd.) do telemetrie a přenášet ji do kolektoru pro další analýzu. Pokud ve své původní verzi Stealthwatch pracuje s libovolným tokovým protokolem (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) na síťové úrovni, pak podpora nvzFlow umožňuje korelaci dat i na úrovni uzlů, tedy. zlepšení celkové efektivity systému a sledování více útoků než konvenční síťové analyzátory toku.
Je jasné, že když mluvíme o analytických systémech Netflow z bezpečnostního hlediska, trh není omezen na jediné řešení od společnosti Cisco. Můžete použít jak komerční, tak bezplatná nebo sharewarová řešení. Je poněkud zvláštní, když na blogu Cisco cituji řešení konkurence, a tak řeknu pár slov o tom, jak lze analyzovat síťovou telemetrii pomocí dvou populárních, názvem podobného, ale přesto odlišných nástrojů - SiLK a ELK.
SiLK je sada nástrojů (System for Internet-Level Knowledge) pro analýzu provozu vyvinutá americkým CERT/CC a která v kontextu dnešního článku podporuje Netflow (nejoblíbenější verze 5. a 9.), IPFIX a sFlow a pomocí různých utilit (rwfilter, rwcount, rwflowpack atd.) k provádění různých operací na síťové telemetrii za účelem odhalování známek neoprávněných akcí v ní. Ale je třeba si uvědomit několik důležitých věcí. SiLK je nástroj příkazového řádku a provádí online analýzu při psaní příkazu formuláře (detekce ICMP paketů větších než 200 bajtů):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ne moc pohodlné. Můžete použít iSiLK GUI, ale to vám život příliš neusnadní tím, že vyřeší pouze funkci vizualizace, nikoli výměnu analytika. A to je druhý bod. Na rozdíl od komerčních řešení, která již mají solidní analytickou základnu, algoritmy detekce anomálií odpovídající workflow atd., si v případě SiLK budete muset toto vše udělat sami, což od vás bude vyžadovat trochu jiné kompetence než z používání již připravených - k použití sady nástrojů. To není dobré a ne špatné – to je vlastnost téměř každého bezplatného nástroje, která vychází z toho, že víte, co máte dělat, a jen vám s tím pomůže (komerční nástroje jsou méně závislé na kompetencích svých uživatelů, i když také předpokládá, že analytici rozumí alespoň základům provádění průzkumů a monitorování sítě). Ale zpět k SiLK. Cyklus práce analytika s ním je následující:
- Formulace hypotézy. Musíme porozumět tomu, co budeme uvnitř síťové telemetrie hledat, znát jedinečné atributy, pomocí kterých budeme identifikovat určité anomálie nebo hrozby.
- Vytváření modelu. Po zformulování hypotézy ji naprogramujeme pomocí stejného Pythonu, shellu nebo jiných nástrojů, které nejsou obsaženy v SiLK.
- Testování. Je čas zkontrolovat správnost naší hypotézy, která je potvrzena nebo vyvrácena pomocí utilit SiLK počínaje 'rw', 'set', 'bag'.
- Analýza reálných dat. V komerčním provozu nám SiLK pomáhá něco identifikovat a analytik musí odpovědět na otázky „Našli jsme, co jsme očekávali?“, „Odpovídá to naší hypotéze?“, „Jak to sníží počet falešně pozitivních?“, "Jak zlepšit úroveň uznání?" a tak dále.
- Zlepšení. V konečné fázi vylepšujeme to, co bylo uděláno dříve – vytváříme šablony, vylepšujeme a optimalizujeme kód, přeformulujeme a zpřesňujeme hypotézu atd.
Tento cyklus bude použitelný pro stejné hodinky Cisco Stealthwatch, pouze posledních pět kroků se maximálně zautomatizuje, čímž se sníží počet chyb analytiků a zvýší se účinnost detekce incidentů. Například v SiLK můžete obohatit síťové statistiky o externí data o škodlivých IP pomocí vlastních skriptů a v Cisco Stealthwatch je to vestavěná funkce, která vám okamžitě zobrazí alarm, pokud v síti dojde k interakci s IP adresami na černé listině. provoz.
Pokud půjdete nahoru po pyramidě „placeného“ softwaru pro analýzu toku, pak po zcela bezplatném SiLK bude následovat sharewarový ELK, skládající se ze tří klíčových komponent – Elasticsearch (indexování, vyhledávání a analýza dat), Logstash (vstup/výstup dat) a Kibana (vizualizace). Na rozdíl od SiLK, kde si musíte vše psát sami, ELK má již mnoho hotových knihoven / modulů (některé jsou placené, některé ne), které automatizují analýzu síťové telemetrie. Například GeoIP filtr v Logstash umožňuje svázat sledované IP adresy s jejich geografickou polohou (stejné Stealthwatch mají tuto vestavěnou funkci).
ELK má také poměrně velkou komunitu, která do tohoto monitorovacího řešení přidává chybějící komponenty. Modul můžete použít například pro práci s Netflow, IPFIX a sFlow pokud nejste spokojeni s modulem Logstash Netflow, který podporuje pouze Netflow.
ELK poskytuje větší efektivitu při shromažďování toku a vyhledávání v něm a v současné době postrádá bohatou vestavěnou analytiku pro detekci anomálií a hrozeb v síťové telemetrii. To znamená, že po výše popsaném životním cyklu budete muset samostatně popsat modely porušení a poté je použít v bojovém systému (neexistují žádné vestavěné modely).
Samozřejmě existují propracovanější rozšíření pro ELK, která již obsahují nějaké modely pro detekci anomálií v síťové telemetrii, ale taková rozšíření stojí peníze a je otázka, zda vám hra stojí za svíčku – podobný model si napište sami, jeho implementaci kupte za váš monitorovací nástroj nebo si kupte řešení na klíč třídy Network Traffic Analysis.
Obecně se nechci pouštět do polemiky o tom, zda je lepší utratit peníze a koupit hotové řešení pro sledování anomálií a hrozeb v síťové telemetrii (například Cisco Stealthwatch) nebo na to přijít sami a vyladit stejné nástroje SiLK, ELK nebo nfdump nebo OSU Flow Tools pro každou novou hrozbu (mluvím o posledních dvou z nich naposledy)? Každý si vybírá sám za sebe a každý má své vlastní motivy pro volbu jedné ze dvou možností. Chtěl jsem jen ukázat, že síťová telemetrie je velmi důležitým nástrojem pro zajištění síťové bezpečnosti vaší interní infrastruktury a neměli byste ji zanedbávat, abyste na seznam nepřidali společnost, jejíž jméno je uvedeno v médiích spolu s přídomky „nabourali“, „nesplňují požadavky na bezpečnost informací“, nemysleli na bezpečnost svých dat a zákaznických dat.
Abych to shrnul, rád bych uvedl hlavní tipy, které byste měli dodržovat při budování monitorování bezpečnosti informací ve vaší interní infrastruktuře:
- Neomezujte se pouze na obvod! Využijte (a vyberte si) síťovou infrastrukturu nejen k přenosu provozu z bodu A do bodu B, ale také k řešení problémů s kybernetickou bezpečností.
- Prostudujte si stávající mechanismy monitorování bezpečnosti informací ve vašem síťovém zařízení a používejte je.
- Pro interní monitorování upřednostněte telemetrickou analýzu – umožňuje detekovat až 80–90 % všech incidentů zabezpečení informací v síti a přitom dělat to, co je nemožné při zachycování síťových paketů a úspoře úložného prostoru pro všechny události zabezpečení informací.
- Pro sledování toků použijte Netflow v9 nebo IPFIX - dávají více informací v rámci bezpečnosti a umožňují sledovat nejen IPv4, ale i IPv6, MPLS atd.
- Použijte protokol bez vzorkování – poskytuje více informací pro detekci hrozeb. Například Netflow nebo IPFIX.
- Zkontrolujte vytížení vašeho síťového zařízení – nemusí také zvládnout zpracování protokolu toku. Pak zvažte použití virtuálních senzorů nebo zařízení Netflow Generation Appliance.
- Implementujte kontrolu na prvním místě na úrovni přístupu – to vám dá možnost vidět 100 % veškerého provozu.
- Pokud nemáte na výběr a používáte ruské síťové vybavení, vyberte si takové, které podporuje tokové protokoly nebo má porty SPAN / RSPAN.
- Kombinujte detekci/prevenci narušení/útoků na hranicích a systémy analýzy toku ve vnitřní síti (včetně cloudů).
Pokud jde o poslední tip, rád bych uvedl ilustraci, kterou jsem již uvedl dříve. Můžete vidět, že pokud dříve služba Cisco IS téměř výhradně budovala svůj monitorovací systém IS založený na systémech detekce narušení a podpisových metodách, nyní představují pouze 20 % incidentů. Dalších 20 % připadá na systémy pro analýzu toků, což naznačuje, že tato řešení nejsou rozmarem, ale skutečným nástrojem v činnosti služeb informační bezpečnosti moderního podniku. Navíc máte pro jejich implementaci to nejdůležitější – síťovou infrastrukturu, do níž lze investice dodatečně chránit přiřazením funkcí monitorování bezpečnosti informací k síti.
Záměrně jsem se nedotkl tématu reakce na anomálie či hrozby identifikované v síťových tocích, ale myslím, že je jasné, že monitoring by neměl končit pouze detekcí hrozby. Měla by následovat odpověď a nejlépe v automatickém nebo automatizovaném režimu. Ale to je téma na samostatný článek.
Doplňující informace:
PS. Pokud je pro vás snazší poslouchat vše, co bylo napsáno výše, můžete se podívat na hodinovou prezentaci, která tvořila základ této poznámky.
Zdroj: www.habr.com