När det gäller att övervaka säkerheten i ett internt företags- eller avdelningsnätverk förknippar många det med att kontrollera informationsläckor och implementera DLP-lösningar. Och om man försöker förtydliga frågan och frågar hur man upptäcker attacker på det interna nätverket, så blir svaret i regel ett omnämnande av intrångsdetekteringssystem (IDS). Och det som var det enda alternativet för 10-20 år sedan håller på att bli en anakronism idag. Det finns ett mer effektivt, och på vissa ställen, det enda möjliga alternativet för att övervaka ett internt nätverk - med hjälp av flödesprotokoll, som ursprungligen var designade för att söka efter nätverksproblem (felsökning), men med tiden förvandlades till ett mycket intressant säkerhetsverktyg. Vi kommer att prata om vilka flödesprotokoll som finns och vilka som är bättre på att upptäcka nätverksattacker, var det är bäst att implementera flödesövervakning, vad man ska leta efter när man distribuerar ett sådant schema och till och med hur man "lyfter" allt detta på hushållsutrustning inom ramen för denna artikel.
Jag kommer inte att uppehålla mig vid frågan "Varför behövs säkerhetsövervakning av intern infrastruktur?" Svaret verkar vara tydligt. Men om du ändå vill försäkra dig om att du idag inte kan leva utan den, en kort video om hur du kan penetrera ett företagsnätverk skyddat av en brandvägg på 17 sätt. Därför kommer vi att anta att vi förstår att intern övervakning är en nödvändig sak och allt som återstår är att förstå hur den kan organiseras.
Jag skulle lyfta fram tre viktiga datakällor för övervakning av infrastruktur på nätverksnivå:
- "rå" trafik som vi fångar in och skickar för analys till vissa analyssystem,
- händelser från nätverksenheter som trafik passerar,
- trafikinformation som tas emot via ett av flödesprotokollen.
Att fånga råtrafik är det mest populära alternativet bland säkerhetsspecialister, eftersom det historiskt sett dök upp och var det allra första. Konventionella nätverksintrångsdetekteringssystem (det allra första kommersiella systemet för intrångsdetektering var NetRanger från Wheel Group, köpt 1998 av Cisco) var exakt engagerade i att fånga paket (och senare sessioner) där vissa signaturer letades efter ("avgörande regler" i FSTEC-terminologi), signaleringsattacker. Naturligtvis kan du analysera råtrafik inte bara med IDS, utan även med andra verktyg (till exempel Wireshark, tcpdum eller NBAR2-funktionaliteten i Cisco IOS), men de saknar vanligtvis kunskapsbasen som skiljer ett informationssäkerhetsverktyg från ett vanligt IT-verktyg.
Så, attackdetekteringssystem. Den äldsta och mest populära metoden för att upptäcka nätverksattacker, som gör ett bra jobb vid omkretsen (oavsett vad - företag, datacenter, segment, etc.), men misslyckas i moderna switchade och mjukvarudefinierade nätverk. När det gäller ett nätverk byggt på basis av konventionella switchar blir infrastrukturen för attackdetekteringssensorer för stor - du måste installera en sensor på varje anslutning till den nod som du vill övervaka attacker på. Vilken tillverkare som helst kommer naturligtvis gärna att sälja hundratals och tusentals sensorer till dig, men jag tror att din budget inte kan stödja sådana utgifter. Jag kan säga att även på Cisco (och vi är utvecklare av NGIPS) kunde vi inte göra detta, även om det verkar som att frågan om pris ligger framför oss. Jag borde inte stå - det är vårt eget beslut. Dessutom uppstår frågan, hur man ansluter sensorn i denna version? In i gapet? Vad händer om själva sensorn misslyckas? Behöver du en bypass-modul i sensorn? Använd splitter (kran)? Allt detta gör lösningen dyrare och gör den oöverkomlig för ett företag av alla storlekar.
Du kan försöka "hänga" sensorn på en SPAN/RSPAN/ERSPAN-port och dirigera trafik från de nödvändiga switchportarna till den. Det här alternativet tar delvis bort problemet som beskrivs i föregående stycke, men utgör ett annat - SPAN-porten kan inte acceptera absolut all trafik som kommer att skickas till den - den kommer inte att ha tillräckligt med bandbredd. Du kommer att behöva offra något. Antingen lämna några av noderna utan övervakning (då måste du prioritera dem först), eller skicka inte all trafik från noden, utan bara en viss typ. I alla fall kan vi missa några attacker. Dessutom kan SPAN-porten användas för andra behov. Som ett resultat kommer vi att behöva se över den befintliga nätverkstopologin och eventuellt göra justeringar av den för att täcka ditt nätverk maximalt med antalet sensorer du har (och samordna detta med IT).
Vad händer om ditt nätverk använder asymmetriska rutter? Vad händer om du har implementerat eller planerar att implementera SDN? Vad händer om du behöver övervaka virtualiserade maskiner eller behållare vars trafik inte når den fysiska switchen alls? Det här är frågor som traditionella IDS-leverantörer inte gillar eftersom de inte vet hur de ska svara på dem. Kanske kommer de att övertyga dig om att alla dessa fashionabla tekniker är hype och att du inte behöver det. Kanske kommer de att prata om behovet av att börja smått. Eller kanske kommer de att säga att du måste sätta en kraftfull tröska i mitten av nätverket och dirigera all trafik till den med hjälp av balanserare. Oavsett vilket alternativ som erbjuds dig måste du tydligt förstå hur det passar dig. Och först efter det fatta ett beslut om att välja en metod för att övervaka informationssäkerheten i nätverksinfrastrukturen. För att återgå till paketfångning vill jag säga att denna metod fortsätter att vara mycket populär och viktig, men dess huvudsakliga syfte är gränskontroll; gränser mellan din organisation och Internet, gränser mellan datacentret och resten av nätverket, gränser mellan processtyrningssystemet och företagssegmentet. På dessa platser har klassiska IDS/IPS fortfarande rätt att existera och klara sina uppgifter väl.
Låt oss gå vidare till det andra alternativet. Analys av händelser som kommer från nätverksenheter kan också användas för att detektera attacker, men inte som huvudmekanism, eftersom den endast tillåter detektering av en liten klass av intrång. Dessutom är det inneboende i viss reaktivitet - attacken måste först inträffa, sedan måste den registreras av en nätverksenhet, som på ett eller annat sätt kommer att signalera ett problem med informationssäkerheten. Det finns flera sådana sätt. Detta kan vara syslog, RMON eller SNMP. De två sista protokollen för nätverksövervakning i samband med informationssäkerhet används endast om vi behöver upptäcka en DoS-attack på själva nätverksutrustningen, eftersom det med RMON och SNMP är möjligt att till exempel övervaka belastningen på enhetens centrala processor eller dess gränssnitt. Detta är en av de "billigaste" (alla har syslog eller SNMP), men också den mest ineffektiva av alla metoder för att övervaka informationssäkerheten för intern infrastruktur - många attacker är helt enkelt dolda från den. Naturligtvis bör de inte försummas, och samma syslog-analys hjälper dig att snabbt identifiera förändringar i konfigurationen av själva enheten, kompromissen med den, men den är inte särskilt lämplig för att upptäcka attacker på hela nätverket.
Det tredje alternativet är att analysera information om trafik som passerar genom en enhet som stöder ett av flera flödesprotokoll. I det här fallet, oavsett protokoll, består trådningsinfrastrukturen nödvändigtvis av tre komponenter:
- Generering eller export av flöde. Denna roll tilldelas vanligtvis en router, switch eller annan nätverksenhet, som, genom att skicka nätverkstrafik genom sig själv, låter dig extrahera nyckelparametrar från den, som sedan överförs till insamlingsmodulen. Till exempel stöder Cisco Netflow-protokollet inte bara på routrar och switchar, inklusive virtuella och industriella, utan även på trådlösa kontroller, brandväggar och till och med servrar.
- Insamlingsflöde. Med tanke på att ett modernt nätverk vanligtvis har mer än en nätverksenhet uppstår problemet med att samla och konsolidera flöden, vilket löses med hjälp av så kallade samlare, som bearbetar de mottagna flödena och sedan överför dem för analys.
- Flödesanalys Analysatorn tar på sig den huvudsakliga intellektuella uppgiften och, genom att tillämpa olika algoritmer på strömmar, drar vissa slutsatser. Till exempel, som en del av en IT-funktion, kan en sådan analysator identifiera nätverksflaskhalsar eller analysera trafikbelastningsprofilen för ytterligare nätverksoptimering. Och för informationssäkerhet kan en sådan analysator upptäcka dataläckor, spridning av skadlig kod eller DoS-attacker.
Tro inte att denna treskiktsarkitektur är för komplicerad - alla andra alternativ (förutom kanske nätverksövervakningssystem som arbetar med SNMP och RMON) fungerar också enligt den. Vi har en datagenerator för analys, som kan vara en nätverksenhet eller en fristående sensor. Vi har ett larminsamlingssystem och ett ledningssystem för hela övervakningsinfrastrukturen. De två sista komponenterna kan kombineras inom en enda nod, men i mer eller mindre stora nätverk är de vanligtvis spridda över minst två enheter för att säkerställa skalbarhet och tillförlitlighet.
Till skillnad från paketanalys, som bygger på att studera huvud- och kroppsdata för varje paket och de sessioner det består av, bygger flödesanalys på att samla in metadata om nätverkstrafik. När, hur mycket, varifrån och var, hur... dessa är frågorna som besvaras av analys av nätverkstelemetri med olika flödesprotokoll. Till en början användes de för att analysera statistik och hitta IT-problem i nätverket, men sedan, i takt med att analytiska mekanismer utvecklades, blev det möjligt att tillämpa dem på samma telemetri av säkerhetsskäl. Det är värt att notera igen att flödesanalys inte ersätter eller ersätter paketfångning. Var och en av dessa metoder har sitt eget användningsområde. Men i denna artikels sammanhang är det flödesanalys som lämpar sig bäst för att övervaka intern infrastruktur. Du har nätverksenheter (oavsett om de fungerar i ett programvarudefinierat paradigm eller enligt statiska regler) som en attack inte kan kringgå. Den kan kringgå en klassisk IDS-sensor, men en nätverksenhet som stöder flödesprotokollet kan inte. Detta är fördelen med denna metod.
Å andra sidan, om du behöver bevis för brottsbekämpning eller ditt eget incidentutredningsteam, kan du inte klara dig utan paketfångning - nätverkstelemetri är inte en kopia av trafik som kan användas för att samla bevis; det behövs för snabb upptäckt och beslutsfattande inom informationssäkerhetsområdet. Å andra sidan, med hjälp av telemetrianalys kan du inte "skriva" all nätverkstrafik (om något, Cisco hanterar datacenter :-), utan bara den som är inblandad i attacken. Telemetrianalysverktyg i detta avseende kommer att komplettera traditionella paketinfångningsmekanismer väl, vilket ger kommandon för selektiv infångning och lagring. Annars måste du ha en kolossal lagringsinfrastruktur.
Låt oss föreställa oss ett nätverk som arbetar med en hastighet av 250 Mbit/sek. Om du vill lagra all denna volym behöver du 31 MB lagringsutrymme för en sekunds trafiköverföring, 1,8 GB för en minut, 108 GB för en timme och 2,6 TB för en dag. För att lagra daglig data från ett nätverk med en bandbredd på 10 Gbit/s behöver du 108 TB lagringsutrymme. Men vissa regulatorer kräver att säkerhetsdata lagras i flera år... On-demand-inspelning, som flödesanalys hjälper dig att implementera, hjälper till att minska dessa värden i storleksordningar. Förresten, om vi talar om förhållandet mellan volymen av inspelad nätverkstelemetridata och fullständig datafångst, så är det cirka 1 till 500. För samma värden som anges ovan, lagra en fullständig transkription av all daglig trafik kommer att vara 5 respektive 216 GB (du kan till och med spela in det på en vanlig flashenhet ).
Om för verktyg för att analysera rå nätverksdata är metoden för att fånga den nästan densamma från leverantör till leverantör, då är situationen annorlunda när det gäller flödesanalys. Det finns flera alternativ för flödesprotokoll, de skillnader som du behöver veta om i säkerhetssammanhang. Det populäraste är Netflow-protokollet utvecklat av Cisco. Det finns flera versioner av detta protokoll, som skiljer sig åt i deras kapacitet och mängden registrerad trafikinformation. Den nuvarande versionen är den nionde (Netflow v9), på grundval av vilken industristandarden Netflow v10, även känd som IPFIX, utvecklades. Idag stöder de flesta nätverksleverantörer Netflow eller IPFIX i sin utrustning. Men det finns flera andra alternativ för flödesprotokoll - sFlow, jFlow, cFlow, rFlow, NetStream, etc., av vilka sFlow är den mest populära. Det är denna typ som oftast stöds av inhemska tillverkare av nätverksutrustning på grund av dess enkla implementering. Vilka är de viktigaste skillnaderna mellan Netflow, som har blivit en de facto-standard, och sFlow? Jag skulle lyfta fram flera viktiga. För det första har Netflow användaranpassningsbara fält i motsats till de fasta fälten i sFlow. Och för det andra, och detta är det viktigaste i vårt fall, samlar sFlow in så kallad samplade telemetri; i motsats till den osamplade för Netflow och IPFIX. Vad är skillnaden mellan dem?
Föreställ dig att du bestämmer dig för att läsa boken "” av mina kollegor - Gary McIntyre, Joseph Munitz och Nadem Alfardan (du kan ladda ner en del av boken från länken). Du har tre alternativ för att uppnå ditt mål – läs hela boken, skumma igenom den, stanna vid var tionde eller 10:e sida, eller försök hitta en återberättelse av nyckelbegrepp på en blogg eller tjänst som SmartReading. Så osamplad telemetri läser varje "sida" i nätverkstrafik, det vill säga analyserar metadata för varje paket. Samplad telemetri är den selektiva studien av trafik i hopp om att de utvalda proverna ska innehålla det du behöver. Beroende på kanalhastigheten kommer samplade telemetri att skickas för analys vart 20:e, 64:e, 200:e, 500:e, 1000:e eller till och med 2000:e paket.
I samband med informationssäkerhetsövervakning betyder detta att samplade telemetri är väl lämpad för att upptäcka DDoS-attacker, skanna och sprida skadlig kod, men kan missa atom- eller multipaketattacker som inte ingick i provet som skickades för analys. Osamplad telemetri har inte sådana nackdelar. Med detta är utbudet av upptäckta attacker mycket bredare. Här är en kort lista över händelser som kan upptäckas med hjälp av analysverktyg för nätverkstelemetri.
Naturligtvis kommer en Netflow-analysator med öppen källkod inte att tillåta dig att göra detta, eftersom dess huvuduppgift är att samla in telemetri och utföra grundläggande analys på den ur IT-synpunkt. För att identifiera informationssäkerhetshot baserat på flöde är det nödvändigt att utrusta analysatorn med olika motorer och algoritmer, som kommer att identifiera cybersäkerhetsproblem baserat på standard- eller anpassade Netflow-fält, berika standarddata med extern data från olika Threat Intelligence-källor, etc.
Därför, om du har ett val, välj sedan Netflow eller IPFIX. Men även om din utrustning bara fungerar med sFlow, som inhemska tillverkare, så kan du även i det här fallet dra nytta av det i säkerhetssammanhang.
Sommaren 2019 analyserade jag de möjligheter som ryska nätverkshårdvarutillverkare har och alla, exklusive NSG, Polygon och Craftway, tillkännagav stöd för sFlow (åtminstone Zelax, Natex, Eltex, QTech, Rusteleteh).
Nästa fråga du kommer att möta är var man ska implementera flödesstöd i säkerhetssyfte? Faktum är att frågan inte är helt korrekt ställd. Modern utrustning stöder nästan alltid flödesprotokoll. Därför skulle jag formulera om frågan annorlunda – var är det mest effektivt att samla in telemetri ur säkerhetssynpunkt? Svaret kommer att vara ganska uppenbart - på åtkomstnivån, där du kommer att se 100% av all trafik, där du kommer att ha detaljerad information om värdar (MAC, VLAN, gränssnitts-ID), där du till och med kan övervaka P2P-trafik mellan värdar, vilket är avgörande för skanning av upptäckt och distribution av skadlig kod. På kärnnivån kanske du helt enkelt inte ser en del av trafiken, men på perimeternivå ser du en fjärdedel av all din nätverkstrafik. Men om du av någon anledning har främmande enheter i ditt nätverk som tillåter angripare att "gå in och ut" utan att kringgå omkretsen, då kommer du inte att analysera telemetrin från den. Därför, för maximal täckning, rekommenderas det att aktivera telemetriinsamling på åtkomstnivån. Samtidigt är det värt att notera att även om vi pratar om virtualisering eller containrar så finns flödesstöd ofta även i moderna virtuella switchar, vilket gör att du kan styra trafiken även där.
Men eftersom jag tog upp ämnet måste jag svara på frågan: vad händer om utrustningen, fysisk eller virtuell, inte stöder flödesprotokoll? Eller är det förbjudet att inkludera det (till exempel i industrisegment för att säkerställa tillförlitlighet)? Eller leder det till hög CPU-belastning att slå på den (detta händer på äldre hårdvara)? För att lösa detta problem finns det specialiserade virtuella sensorer (flödessensorer), som i huvudsak är vanliga splitters som passerar trafik genom sig själva och sänder den i form av flöde till insamlingsmodulen. Det är sant att vi i det här fallet får alla problem som vi pratade om ovan i samband med paketfångningsverktyg. Det vill säga, du måste förstå inte bara fördelarna med flödesanalysteknik, utan också dess begränsningar.
En annan punkt som är viktig att komma ihåg när man pratar om verktyg för flödesanalys. Om vi i förhållande till konventionella sätt att generera säkerhetshändelser använder EPS-måttet (händelse per sekund), så är denna indikator inte tillämplig på telemetrianalys; den ersätts av FPS (flöde per sekund). Som i fallet med EPS kan det inte beräknas i förväg, men du kan uppskatta det ungefärliga antalet trådar som en viss enhet genererar beroende på dess uppgift. Du kan hitta tabeller på Internet med ungefärliga värden för olika typer av företagsenheter och villkor, vilket gör att du kan uppskatta vilka licenser du behöver för analysverktyg och vad deras arkitektur kommer att vara? Faktum är att IDS-sensorn är begränsad av en viss bandbredd som den kan "dra", och flödesuppsamlaren har sina egna begränsningar som måste förstås. Därför finns det oftast flera samlare i stora, geografiskt spridda nätverk. När jag beskrev , Jag har redan angett numret på våra samlare - det finns 21 av dem. Och det här är för ett nätverk utspridda över fem kontinenter och som har cirka en halv miljon aktiva enheter).
Vi använder vår egen lösning som ett Netflow övervakningssystem , som är specifikt inriktat på att lösa säkerhetsproblem. Den har många inbyggda motorer för att upptäcka onormal, misstänksam och tydligt skadlig aktivitet, vilket gör att den kan upptäcka ett brett utbud av olika hot – från kryptominering till informationsläckor, från spridning av skadlig kod till bedrägeri. Liksom de flesta flödesanalysatorer är Stealthwatch byggd enligt ett trenivåschema (generator - samlare - analysator), men den är kompletterad med ett antal intressanta funktioner som är viktiga i sammanhanget med det aktuella materialet. För det första integreras den med paketfångningslösningar (som Cisco Security Packet Analyzer), så att du kan spela in utvalda nätverkssessioner för senare djupgående undersökningar och analyser. För det andra, specifikt för att utöka säkerhetsuppgifterna, har vi utvecklat ett speciellt nvzFlow-protokoll, som gör att du kan "sända" aktiviteten hos applikationer på ändnoder (servrar, arbetsstationer, etc.) till telemetri och överföra den till insamlaren för vidare analys. Om Stealthwatch i sin ursprungliga version fungerar med vilket flödesprotokoll som helst (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) på nätverksnivå, så tillåter nvzFlow-stöd datakorrelation även på nodnivå. öka effektiviteten i hela systemet och se fler attacker än konventionella nätverksflödesanalysatorer.
Det är tydligt att när man talar om Netflow-analyssystem ur säkerhetssynpunkt är marknaden inte begränsad till en enda lösning från Cisco. Du kan använda både kommersiella och gratis- eller shareware-lösningar. Det är ganska konstigt om jag nämner konkurrenters lösningar som exempel på Cisco-bloggen, så jag ska säga några ord om hur nätverkstelemetri kan analyseras med två populära, liknande till namnet men ändå olika verktyg - SiLK och ELK.
SiLK är en uppsättning verktyg (System for Internet-Level Knowledge) för trafikanalys, utvecklad av amerikanska CERT/CC och som stöder, i samband med dagens artikel, Netflow (5:e och 9:e, de mest populära versionerna), IPFIX och sFlow och använda olika verktyg (rwfilter, rwcount, rwflowpack, etc.) för att utföra olika operationer på nätverkstelemetri för att upptäcka tecken på obehöriga åtgärder i den. Men det finns ett par viktiga punkter att notera. SiLK är ett kommandoradsverktyg som utför onlineanalys genom att ange kommandon som detta (detektering av ICMP-paket större än 200 byte):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
inte särskilt bekväm. Du kan använda iSiLK GUI, men det kommer inte att göra ditt liv mycket enklare, bara att lösa visualiseringsfunktionen och inte ersätta analytikern. Och detta är den andra punkten. Till skillnad från kommersiella lösningar, som redan har en solid analytisk bas, anomalidetekteringsalgoritmer, motsvarande arbetsflöde, etc., måste du i fallet med SiLK göra allt detta själv, vilket kommer att kräva lite andra kompetenser av dig än från att använda redan färdiga- att använda verktyg. Detta är varken bra eller dåligt - det här är en funktion i nästan alla gratisverktyg som förutsätter att du vet vad du ska göra, och det kommer bara att hjälpa dig med detta (kommersiella verktyg är mindre beroende av dess användares kompetens, även om de också antar att analytiker åtminstone förstår grunderna för nätverksundersökningar och övervakning). Men låt oss återgå till SiLK. Analytikerns arbetscykel med den ser ut så här:
- Att formulera en hypotes. Vi måste förstå vad vi kommer att leta efter inom nätverkstelemetri, känna till de unika attributen med vilka vi kommer att identifiera vissa anomalier eller hot.
- Att bygga en modell. Efter att ha formulerat en hypotes programmerar vi den med samma Python, skal eller andra verktyg som inte ingår i SiLK.
- Testning. Nu kommer turen att kontrollera riktigheten av vår hypotes, som bekräftas eller vederläggs med hjälp av SiLK-verktyg som börjar med 'rw', 'set', 'bag'.
- Analys av verkliga data. Inom industriell drift hjälper SiLK oss att identifiera något och analytikern måste svara på frågorna ”Hittade vi vad vi förväntade oss?”, ”Stämmer detta överens med vår hypotes?”, ”Hur minskar man antalet falska positiva?”, ”Hur för att förbättra nivån på erkännande? » och så vidare.
- Förbättring. I slutskedet förbättrar vi det som gjorts tidigare - vi skapar mallar, förbättrar och optimerar koden, omformulerar och förtydligar hypotesen m.m.
Den här cykeln kommer också att vara tillämplig på Cisco Stealthwatch, bara den sista automatiserar dessa fem steg maximalt, vilket minskar antalet analytikerfel och ökar effektiviteten för incidentdetektering. I SiLK kan man till exempel berika nätverksstatistiken med extern data om skadliga IP-adresser med hjälp av handskrivna skript, och i Cisco Stealthwatch är det en inbyggd funktion som omedelbart visar larm om nätverkstrafiken innehåller interaktioner med IP-adresser från den svarta listan.
Om du går högre upp i den "betalda" pyramiden för mjukvara för flödesanalys, kommer det efter den helt gratis SiLK att finnas en shareware ELK, bestående av tre nyckelkomponenter - Elasticsearch (indexering, sökning och dataanalys), Logstash (datainmatning/utdata ) och Kibana (visualisering). Till skillnad från SiLK, där du måste skriva allt själv, har ELK redan många färdiga bibliotek/moduler (en del betalda, andra inte) som automatiserar analysen av nätverkstelemetri. Till exempel låter GeoIP-filtret i Logstash dig associera övervakade IP-adresser med deras geografiska plats (Stealthwatch har denna inbyggda funktion).
ELK har också en ganska stor community som håller på att färdigställa de saknade komponenterna för denna övervakningslösning. Till exempel, för att arbeta med Netflow, IPFIX och sFlow kan du använda modulen , om du inte är nöjd med Logstash Netflow-modulen, som bara stöder Netflow.
Samtidigt som ELK ger mer effektivitet i att samla in flöde och söka i det, saknar ELK för närvarande rik inbyggd analys för att upptäcka anomalier och hot i nätverkstelemetri. Det vill säga, efter livscykeln som beskrivs ovan måste du självständigt beskriva överträdelsemodeller och sedan använda den i stridssystemet (det finns inga inbyggda modeller där).
Det finns förstås mer sofistikerade tillägg för ELK, som redan innehåller några modeller för att upptäcka anomalier i nätverkstelemetri, men sådana tillägg kostar pengar och här är frågan om spelet är värt ljuset - skriv en liknande modell själv, köp dess implementering för ditt övervakningsverktyg, eller köp en färdig lösning av klassen Network Traffic Analysis.
Generellt sett vill jag inte gå in i debatten om att det är bättre att spendera pengar och köpa en färdig lösning för att övervaka anomalier och hot inom nätverkstelemetri (till exempel Cisco Stealthwatch) eller ta reda på det själv och anpassa detsamma. SiLK, ELK eller nfdump eller OSU Flow Tools för varje nytt hot (jag pratar om de två sista av dem förra gången)? Alla väljer själva och alla har sina egna motiv för att välja något av de två alternativen. Jag ville bara visa att nätverkstelemetri är ett mycket viktigt verktyg för att säkerställa nätverkssäkerheten för din interna infrastruktur och du bör inte försumma det, för att inte gå med i listan över företag vars namn nämns i media tillsammans med epitet " hackad", "inte överensstämmer med informationssäkerhetskraven" ", "inte tänker på säkerheten för deras data och kunddata."
För att sammanfatta skulle jag vilja lista de viktigaste tipsen som du bör följa när du bygger informationssäkerhetsövervakning av din interna infrastruktur:
- Begränsa dig inte bara till omkretsen! Använd (och välj) nätverksinfrastruktur inte bara för att flytta trafik från punkt A till punkt B, utan också för att ta itu med cybersäkerhetsfrågor.
- Studera de befintliga informationssäkerhetsövervakningsmekanismerna i din nätverksutrustning och använd dem.
- För intern övervakning, ge företräde åt telemetrianalys - det låter dig upptäcka upp till 80-90% av alla nätverksinformationssäkerhetsincidenter, samtidigt som du gör det som är omöjligt när du fångar nätverkspaket och sparar utrymme för att lagra alla informationssäkerhetshändelser.
- För att övervaka flöden, använd Netflow v9 eller IPFIX - de ger mer information i säkerhetssammanhang och låter dig övervaka inte bara IPv4, utan även IPv6, MPLS, etc.
- Använd ett flödesprotokoll utan prov – det ger mer information för att upptäcka hot. Till exempel Netflow eller IPFIX.
- Kontrollera belastningen på din nätverksutrustning - den kanske inte kan hantera flödesprotokollet lika bra. Överväg sedan att använda virtuella sensorer eller Netflow Generation Appliance.
- Implementera kontroll först och främst på åtkomstnivån - detta ger dig möjlighet att se 100 % av all trafik.
- Om du inte har något val och du använder rysk nätverksutrustning, välj en som stöder flödesprotokoll eller har SPAN/RSPAN-portar.
- Kombinera intrångs-/attackdetektering/förebyggande system vid kanterna och flödesanalyssystem i det interna nätverket (inklusive i molnen).
Angående det sista tipset så skulle jag vilja ge en illustration som jag redan har gett tidigare. Du ser att om Ciscos informationssäkerhetstjänst tidigare nästan helt byggde sitt övervakningssystem för informationssäkerhet på basis av intrångsdetekteringssystem och signaturmetoder, står de nu för endast 20 % av incidenterna. Ytterligare 20% faller på flödesanalyssystem, vilket tyder på att dessa lösningar inte är ett infall, utan ett verkligt verktyg i verksamheten för informationssäkerhetstjänster i ett modernt företag. Dessutom har du det viktigaste för deras implementering - nätverksinfrastruktur, investeringar i som kan skyddas ytterligare genom att tilldela informationssäkerhetsövervakningsfunktioner till nätverket.
Jag berörde specifikt inte frågan om att bemöta anomalier eller hot som identifierats i nätverksflöden, men jag tror att det redan är klart att övervakningen inte bara bör sluta med upptäckten av ett hot. Den ska följas av ett svar och helst i ett automatiskt eller automatiserat läge. Men detta är ett ämne för en separat artikel.
Ytterligare information:
PS. Om det är lättare för dig att höra allt som skrevs ovan kan du titta på den timslånga presentationen som låg till grund för denna anteckning.
Källa: will.com