Når det gjelder å overvåke sikkerheten til et internt bedrifts- eller avdelingsnettverk, forbinder mange det med å kontrollere informasjonslekkasjer og implementere DLP-løsninger. Og hvis du prøver å avklare spørsmålet og spør hvordan du oppdager angrep på det interne nettverket, så vil svaret som regel være en omtale av inntrengningsdeteksjonssystemer (IDS). Og det som var det eneste alternativet for 10-20 år siden, er i ferd med å bli en anakronisme i dag. Det er et mer effektivt, og noen steder, det eneste mulige alternativet for å overvåke et internt nettverk - ved å bruke flytprotokoller, som opprinnelig ble designet for å søke etter nettverksproblemer (feilsøking), men over tid forvandlet til et veldig interessant sikkerhetsverktøy. Vi vil snakke om hvilke flytprotokoller som finnes og hvilke som er bedre til å oppdage nettverksangrep, hvor det er best å implementere flytovervåking, hva du skal se etter når du distribuerer en slik ordning, og til og med hvordan du "løfter" alt dette på husholdningsutstyr innenfor rammen av denne artikkelen.
Jeg vil ikke dvele ved spørsmålet "Hvorfor er det nødvendig med sikkerhetsovervåking av intern infrastruktur?" Svaret ser ut til å være klart. Men hvis du likevel vil forsikre deg om at du i dag ikke kan leve uten det, en kort video om hvordan du kan trenge inn i et bedriftsnettverk beskyttet av en brannmur på 17 måter. Derfor vil vi anta at vi forstår at intern overvåking er en nødvendig ting og det gjenstår bare å forstå hvordan det kan organiseres.
Jeg vil fremheve tre viktige datakilder for overvåking av infrastruktur på nettverksnivå:
- "rå" trafikk som vi fanger opp og sender inn for analyse til visse analysesystemer,
- hendelser fra nettverksenheter som trafikk går gjennom,
- trafikkinformasjon mottatt via en av flytprotokollene.
Å fange rå trafikk er det mest populære alternativet blant sikkerhetsspesialister, fordi det historisk dukket opp og var det aller første. Konvensjonelle nettverksinntrengingsdeteksjonssystemer (det aller første kommersielle inntrengningsdeteksjonssystemet var NetRanger fra Wheel Group, kjøpt i 1998 av Cisco) var nettopp engasjert i å fange pakker (og senere økter) der visse signaturer ble søkt etter ("avgjørende regler" i FSTEC-terminologi), signaliseringsangrep. Selvfølgelig kan du analysere råtrafikk ikke bare ved å bruke IDS, men også ved å bruke andre verktøy (for eksempel Wireshark, tcpdum eller NBAR2-funksjonaliteten i Cisco IOS), men de mangler vanligvis kunnskapsbasen som skiller et informasjonssikkerhetsverktøy fra et vanlig IT-verktøy.
Så angrepsdeteksjonssystemer. Den eldste og mest populære metoden for å oppdage nettverksangrep, som gjør en god jobb i perimeteren (uansett hva - bedrift, datasenter, segment, etc.), men feiler i moderne svitsjede og programvaredefinerte nettverk. Når det gjelder et nettverk bygget på basis av konvensjonelle brytere, blir infrastrukturen til angrepsdeteksjonssensorer for stor - du må installere en sensor på hver tilkobling til noden du vil overvåke angrep på. Enhver produsent vil selvfølgelig gjerne selge deg hundrevis og tusenvis av sensorer, men jeg tror budsjettet ditt ikke kan støtte slike utgifter. Jeg kan si at selv hos Cisco (og vi er utviklerne av NGIPS) kunne vi ikke gjøre dette, selv om det ser ut til at spørsmålet om pris ligger foran oss. Jeg burde ikke stå - det er vår egen avgjørelse. I tillegg oppstår spørsmålet, hvordan koble sensoren i denne versjonen? Inn i gapet? Hva om selve sensoren svikter? Trenger du en bypass-modul i sensoren? Bruke splittere (tapp)? Alt dette gjør løsningen dyrere og gjør den uoverkommelig for et selskap uansett størrelse.
Du kan prøve å "henge" sensoren på en SPAN/RSPAN/ERSPAN-port og dirigere trafikk fra de nødvendige svitsjportene til den. Dette alternativet fjerner delvis problemet beskrevet i forrige avsnitt, men utgjør et annet - SPAN-porten kan ikke akseptere absolutt all trafikken som vil bli sendt til den - den vil ikke ha nok båndbredde. Du må ofre noe. La enten noen av nodene stå uten overvåking (da må du prioritere dem først), eller send ikke all trafikk fra noden, men bare en bestemt type. Uansett kan vi gå glipp av noen angrep. I tillegg kan SPAN-porten brukes til andre behov. Som et resultat vil vi måtte gjennomgå den eksisterende nettverkstopologien og eventuelt gjøre justeringer av den for å dekke nettverket ditt maksimalt med antall sensorer du har (og koordinere dette med IT).
Hva om nettverket ditt bruker asymmetriske ruter? Hva om du har implementert eller planlegger å implementere SDN? Hva om du trenger å overvåke virtualiserte maskiner eller containere hvis trafikk ikke når den fysiske bryteren i det hele tatt? Dette er spørsmål som tradisjonelle IDS-leverandører ikke liker fordi de ikke vet hvordan de skal svare på dem. Kanskje de vil overbevise deg om at alle disse fasjonable teknologiene er hype og at du ikke trenger det. Kanskje vil de snakke om behovet for å begynne i det små. Eller kanskje de vil si at du må sette en kraftig tresker i midten av nettverket og dirigere all trafikk til den ved hjelp av balansere. Uansett hvilket alternativ som tilbys deg, må du tydelig forstå hvordan det passer deg. Og først etter det ta en beslutning om å velge en tilnærming til overvåking av informasjonssikkerheten til nettverksinfrastrukturen. For å gå tilbake til pakkefangst, vil jeg si at denne metoden fortsetter å være veldig populær og viktig, men dens hovedformål er grensekontroll; grenser mellom din organisasjon og Internett, grenser mellom datasenteret og resten av nettverket, grenser mellom prosesskontrollsystemet og bedriftssegmentet. På disse stedene har klassisk IDS/IPS fortsatt rett til å eksistere og takle sine oppgaver godt.
La oss gå videre til det andre alternativet. Analyse av hendelser som kommer fra nettverksenheter kan også brukes til angrepsdeteksjonsformål, men ikke som hovedmekanismen, siden den tillater å oppdage bare en liten klasse av inntrenging. I tillegg ligger det i en viss reaktivitet - angrepet må først skje, deretter må det registreres av en nettverksenhet, som på en eller annen måte vil signalisere et problem med informasjonssikkerheten. Det er flere slike måter. Dette kan være syslog, RMON eller SNMP. De to siste protokollene for nettverksovervåking i forbindelse med informasjonssikkerhet brukes kun hvis vi trenger å oppdage et DoS-angrep på selve nettverksutstyret, siden det ved bruk av RMON og SNMP er mulig for eksempel å overvåke belastningen på enhetens sentral. prosessor eller dens grensesnitt. Dette er en av de "billigste" (alle har syslog eller SNMP), men også den mest ineffektive av alle metoder for å overvåke informasjonssikkerheten til intern infrastruktur - mange angrep er ganske enkelt skjult for den. Selvfølgelig bør de ikke neglisjeres, og den samme syslog-analysen hjelper deg med å identifisere endringer i konfigurasjonen av selve enheten i tide, kompromisset med den, men den er ikke veldig egnet for å oppdage angrep på hele nettverket.
Det tredje alternativet er å analysere informasjon om trafikk som går gjennom en enhet som støtter en av flere flytprotokoller. I dette tilfellet, uavhengig av protokollen, består trådingsinfrastrukturen nødvendigvis av tre komponenter:
- Generering eller eksport av flyt. Denne rollen tildeles vanligvis en ruter, switch eller annen nettverksenhet, som ved å sende nettverkstrafikk gjennom seg selv lar deg trekke ut nøkkelparametere fra den, som deretter overføres til samlingsmodulen. Cisco støtter for eksempel Netflow-protokollen ikke bare på rutere og svitsjer, inkludert virtuelle og industrielle, men også på trådløse kontrollere, brannmurer og til og med servere.
- Innsamlingsflyt. Tatt i betraktning at et moderne nettverk vanligvis har mer enn én nettverksenhet, oppstår problemet med å samle og konsolidere strømmer, som løses ved hjelp av såkalte samlere, som behandler de mottatte strømmene og deretter overfører dem til analyse.
- Strømningsanalyse Analysatoren tar på seg den intellektuelle hovedoppgaven og trekker visse konklusjoner ved å bruke forskjellige algoritmer på strømmer. For eksempel, som en del av en IT-funksjon, kan en slik analysator identifisere nettverksflaskehalser eller analysere trafikkbelastningsprofilen for ytterligere nettverksoptimalisering. Og for informasjonssikkerhet kan en slik analysator oppdage datalekkasjer, spredning av ondsinnet kode eller DoS-angrep.
Ikke tro at denne trelagsarkitekturen er for komplisert - alle andre alternativer (unntatt kanskje nettverksovervåkingssystemer som jobber med SNMP og RMON) fungerer også i henhold til den. Vi har en datagenerator for analyse, som kan være en nettverksenhet eller en frittstående sensor. Vi har et alarminnsamlingssystem og et styringssystem for hele overvåkingsinfrastrukturen. De to siste komponentene kan kombineres innenfor en enkelt node, men i mer eller mindre store nettverk er de vanligvis spredt over minst to enheter for å sikre skalerbarhet og pålitelighet.
I motsetning til pakkeanalyse, som er basert på å studere overskriften og kroppsdataene til hver pakke og øktene den består av, er flytanalyse avhengig av å samle inn metadata om nettverkstrafikk. Når, hvor mye, fra hvor og hvor, hvordan... dette er spørsmålene som besvares ved analyse av nettverkstelemetri ved bruk av ulike flytprotokoller. Til å begynne med ble de brukt til å analysere statistikk og finne IT-problemer på nettverket, men etter hvert som analytiske mekanismer utviklet seg, ble det mulig å bruke dem på samme telemetri for sikkerhetsformål. Det er verdt å merke seg igjen at flytanalyse ikke erstatter eller erstatter pakkefangst. Hver av disse metodene har sitt eget bruksområde. Men i sammenheng med denne artikkelen er det flytanalyse som er best egnet for overvåking av intern infrastruktur. Du har nettverksenheter (enten de opererer i et programvaredefinert paradigme eller i henhold til statiske regler) som et angrep ikke kan omgå. Den kan omgå en klassisk IDS-sensor, men en nettverksenhet som støtter flytprotokollen kan ikke. Dette er fordelen med denne metoden.
På den annen side, hvis du trenger bevis for rettshåndhevelse eller ditt eget etterforskningsteam, kan du ikke klare deg uten pakkefangst – nettverkstelemetri er ikke en kopi av trafikk som kan brukes til å samle bevis; det er nødvendig for rask oppdagelse og beslutningstaking innen informasjonssikkerhet. På den annen side, ved hjelp av telemetrianalyse, kan du "skrive" ikke all nettverkstrafikk (hvis noe, Cisco har med datasentre :-), men bare den som er involvert i angrepet. Telemetrianalyseverktøy i denne forbindelse vil utfylle tradisjonelle pakkefangstmekanismer godt, og gi kommandoer for selektiv fangst og lagring. Ellers må du ha en kolossal lagringsinfrastruktur.
La oss forestille oss et nettverk som opererer med en hastighet på 250 Mbit/sek. Hvis du vil lagre alt dette volumet, trenger du 31 MB lagringsplass for ett sekunds trafikkoverføring, 1,8 GB i ett minutt, 108 GB i én time og 2,6 TB for én dag. For å lagre daglige data fra et nettverk med en båndbredde på 10 Gbit/s, trenger du 108 TB lagringsplass. Men noen regulatorer krever lagring av sikkerhetsdata i årevis... On-demand-opptak, som flytanalyse hjelper deg med å implementere, bidrar til å redusere disse verdiene i størrelsesordener. Forresten, hvis vi snakker om forholdet mellom volumet av registrerte nettverkstelemetridata og fullstendig datafangst, så er det omtrent 1 til 500. For de samme verdiene som er gitt ovenfor, lagrer en fullstendig transkripsjon av all daglig trafikk vil være henholdsvis 5 og 216 GB (du kan til og med ta det opp på en vanlig flash-stasjon ).
Hvis for verktøy for å analysere rå nettverksdata, er metoden for å fange dem nesten den samme fra leverandør til leverandør, så er situasjonen annerledes i tilfelle flytanalyse. Det er flere alternativer for flytprotokoller, forskjellene du trenger å vite om i forbindelse med sikkerhet. Den mest populære er Netflow-protokollen utviklet av Cisco. Det finnes flere versjoner av denne protokollen, som varierer i deres evner og mengden trafikkinformasjon registrert. Den nåværende versjonen er den niende (Netflow v9), på grunnlag av hvilken industristandarden Netflow v10, også kjent som IPFIX, ble utviklet. I dag støtter de fleste nettverksleverandører Netflow eller IPFIX i utstyret sitt. Men det er forskjellige andre alternativer for flytprotokoller - sFlow, jFlow, cFlow, rFlow, NetStream, etc., hvorav sFlow er den mest populære. Det er denne typen som oftest støttes av innenlandske produsenter av nettverksutstyr på grunn av dens enkle implementering. Hva er de viktigste forskjellene mellom Netflow, som har blitt en de facto standard, og sFlow? Jeg vil trekke frem flere viktige. For det første har Netflow brukertilpassbare felt i motsetning til de faste feltene i sFlow. Og for det andre, og dette er det viktigste i vårt tilfelle, samler sFlow inn såkalt samplet telemetri; i motsetning til den ikke-samplede for Netflow og IPFIX. Hva er forskjellen mellom dem?
Tenk deg at du bestemmer deg for å lese boken "” av mine kolleger - Gary McIntyre, Joseph Munitz og Nadem Alfardan (du kan laste ned en del av boken fra lenken). Du har tre alternativer for å nå målet ditt – les hele boken, skum gjennom den, stopp på hver 10. eller 20. side, eller prøv å finne en gjenfortelling av nøkkelbegreper på en blogg eller tjeneste som SmartReading. Så, usamplet telemetri leser hver "side" med nettverkstrafikk, det vil si å analysere metadata for hver pakke. Samplet telemetri er den selektive studien av trafikk i håp om at de utvalgte prøvene vil inneholde det du trenger. Avhengig av kanalhastigheten vil samplet telemetri bli sendt for analyse hver 64., 200., 500., 1000., 2000. eller til og med 10000.
I sammenheng med informasjonssikkerhetsovervåking betyr dette at samplet telemetri er godt egnet for å oppdage DDoS-angrep, skanne og spre ondsinnet kode, men kan gå glipp av atom- eller multipakkeangrep som ikke var inkludert i prøven sendt til analyse. Usamplet telemetri har ikke slike ulemper. Med dette er spekteret av oppdagede angrep mye bredere. Her er en kort liste over hendelser som kan oppdages ved hjelp av analyseverktøy for nettverkstelemetri.
Selvfølgelig vil en åpen kildekode Netflow-analysator ikke tillate deg å gjøre dette, siden hovedoppgaven er å samle telemetri og utføre grunnleggende analyse på den fra et IT-synspunkt. For å identifisere informasjonssikkerhetstrusler basert på flyt, er det nødvendig å utstyre analysatoren med ulike motorer og algoritmer, som vil identifisere cybersikkerhetsproblemer basert på standard eller tilpassede Netflow-felt, berike standarddata med eksterne data fra ulike Threat Intelligence-kilder, etc.
Derfor, hvis du har et valg, velg Netflow eller IPFIX. Men selv om utstyret ditt bare fungerer med sFlow, som innenlandske produsenter, så kan du også i dette tilfellet dra nytte av det i en sikkerhetssammenheng.
Sommeren 2019 analyserte jeg mulighetene som russiske nettverksmaskinvareprodusenter har, og alle, unntatt NSG, Polygon og Craftway, annonserte støtte for sFlow (minst Zelax, Natex, Eltex, QTech, Rusteleteh).
Det neste spørsmålet du vil møte er hvor du skal implementere flytstøtte for sikkerhetsformål? Spørsmålet er faktisk ikke stilt helt korrekt. Moderne utstyr støtter nesten alltid flytprotokoller. Derfor vil jeg omformulere spørsmålet annerledes – hvor er det mest effektivt å samle telemetri fra et sikkerhetssynspunkt? Svaret vil være ganske åpenbart - på tilgangsnivået, hvor du vil se 100 % av all trafikk, hvor du vil ha detaljert informasjon om verter (MAC, VLAN, grensesnitt-ID), hvor du til og med kan overvåke P2P-trafikk mellom verter, som er kritisk for skanningsdeteksjon og distribusjon av ondsinnet kode. På kjernenivå kan det hende du rett og slett ikke ser noe av trafikken, men på perimeternivå vil du se en fjerdedel av all nettverkstrafikken din. Men hvis du av en eller annen grunn har utenlandske enheter på nettverket ditt som lar angripere "gå inn og ut" uten å omgå omkretsen, vil det ikke gi deg noe å analysere telemetrien fra den. Derfor, for maksimal dekning, anbefales det å aktivere telemetriinnsamling på tilgangsnivå. Samtidig er det verdt å merke seg at selv om vi snakker om virtualisering eller containere, finnes flytstøtte også ofte i moderne virtuelle svitsjer, som lar deg kontrollere trafikken der også.
Men siden jeg tok opp emnet, må jeg svare på spørsmålet: hva om utstyret, fysisk eller virtuelt, ikke støtter flytprotokoller? Eller er det forbudt å inkludere den (for eksempel i industrielle segmenter for å sikre pålitelighet)? Eller fører det til høy CPU-belastning å slå den på (dette skjer på eldre maskinvare)? For å løse dette problemet finnes det spesialiserte virtuelle sensorer (flowsensorer), som i hovedsak er vanlige splittere som passerer trafikk gjennom seg selv og kringkaster den i form av flyt til oppsamlingsmodulen. Riktignok får vi i dette tilfellet alle problemene vi snakket om ovenfor i forhold til pakkefangstverktøy. Det vil si at du ikke bare må forstå fordelene med strømningsanalyseteknologi, men også dens begrensninger.
Et annet punkt som er viktig å huske når man snakker om flytanalyseverktøy. Hvis vi i forhold til konvensjonelle metoder for å generere sikkerhetshendelser bruker EPS-metrikken (hendelse per sekund), så er denne indikatoren ikke aktuelt for telemetrianalyse; den erstattes av FPS (flow per second). Som i tilfellet med EPS, kan det ikke beregnes på forhånd, men du kan anslå det omtrentlige antallet tråder som en bestemt enhet genererer avhengig av oppgaven. Du kan finne tabeller på Internett med omtrentlige verdier for forskjellige typer bedriftsenheter og forhold, som lar deg estimere hvilke lisenser du trenger for analyseverktøy og hva deres arkitektur vil være? Faktum er at IDS-sensoren er begrenset av en viss båndbredde som den kan "trekke", og strømningssamleren har sine egne begrensninger som må forstås. Derfor er det i store, geografisk distribuerte nettverk vanligvis flere samlere. Når jeg beskrev , Jeg har allerede oppgitt antallet samlere våre - det er 21 av dem. Og dette er for et nettverk spredt over fem kontinenter og som teller omtrent en halv million aktive enheter).
Vi bruker vår egen løsning som et Netflow overvåkingssystem , som er spesifikt fokusert på å løse sikkerhetsproblemer. Den har mange innebygde motorer for å oppdage uregelmessig, mistenkelig og tydelig ondsinnet aktivitet, som lar deg oppdage et bredt spekter av ulike trusler – fra kryptominering til informasjonslekkasjer, fra spredning av ondsinnet kode til svindel. Som de fleste flytanalysatorer er Stealthwatch bygget i henhold til et tre-nivå skjema (generator - samler - analysator), men den er supplert med en rekke interessante funksjoner som er viktige i sammenheng med materialet som vurderes. For det første integreres den med pakkefangstløsninger (som Cisco Security Packet Analyzer), som lar deg registrere utvalgte nettverksøkter for senere dybdeundersøkelse og analyse. For det andre, spesielt for å utvide sikkerhetsoppgavene, har vi utviklet en spesiell nvzFlow-protokoll, som lar deg "kringkaste" aktiviteten til applikasjoner på endenoder (servere, arbeidsstasjoner, etc.) til telemetri og overføre den til samleren for videre analyse. Hvis Stealthwatch i sin opprinnelige versjon fungerer med en hvilken som helst flytprotokoll (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) på nettverksnivå, tillater nvzFlow-støtte datakorrelasjon også på nodenivå. øke effektiviteten til hele systemet og se flere angrep enn konvensjonelle nettverksflytanalysatorer.
Det er klart at når man snakker om Netflow analysesystemer fra et sikkerhetssynspunkt, er ikke markedet begrenset til en enkelt løsning fra Cisco. Du kan bruke både kommersielle og gratis- eller shareware-løsninger. Det er ganske rart om jeg nevner konkurrenters løsninger som eksempler på Cisco-bloggen, så jeg vil si noen ord om hvordan nettverkstelemetri kan analyseres ved hjelp av to populære, like i navn, men likevel forskjellige verktøy - SiLK og ELK.
SiLK er et sett med verktøy (System for Internet-Level Knowledge) for trafikkanalyse, utviklet av amerikanske CERT/CC og som støtter, i sammenheng med dagens artikkel, Netflow (5. og 9., de mest populære versjonene), IPFIX og sFlow og bruk av ulike verktøy (rwfilter, rwcount, rwflowpack, etc.) for å utføre ulike operasjoner på nettverkstelemetri for å oppdage tegn på uautoriserte handlinger i den. Men det er et par viktige punkter å merke seg. SiLK er et kommandolinjeverktøy som utfører online-analyse ved å legge inn kommandoer som dette (deteksjon av ICMP-pakker større enn 200 byte):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ikke veldig behagelig. Du kan bruke iSiLK GUI, men det vil ikke gjøre livet ditt mye enklere, bare løse visualiseringsfunksjonen og ikke erstatte analytikeren. Og dette er det andre punktet. I motsetning til kommersielle løsninger, som allerede har en solid analytisk base, anomalideteksjonsalgoritmer, tilsvarende arbeidsflyt osv., vil du i tilfelle av SiLK måtte gjøre alt dette selv, noe som vil kreve litt annen kompetanse fra deg enn å bruke allerede klar- å bruke verktøy. Dette er verken bra eller dårlig - dette er en funksjon i nesten alle gratisverktøy som forutsetter at du vet hva du skal gjøre, og det vil bare hjelpe deg med dette (kommersielle verktøy er mindre avhengige av kompetansen til brukerne, selv om de også antar at analytikere forstår i det minste grunnleggende om nettverksundersøkelser og overvåking). Men la oss gå tilbake til SiLK. Analytikerens arbeidssyklus med det ser slik ut:
- Å formulere en hypotese. Vi må forstå hva vi vil se etter innenfor nettverkstelemetri, kjenne til de unike egenskapene som gjør at vi vil identifisere visse anomalier eller trusler.
- Bygge en modell. Etter å ha formulert en hypotese, programmerer vi den med samme Python, skall eller andre verktøy som ikke er inkludert i SiLK.
- Testing. Nå kommer turen til å sjekke riktigheten av hypotesen vår, som bekreftes eller tilbakevises ved hjelp av SiLK-verktøy som starter med 'rw', 'set', 'bag'.
- Analyse av reelle data. I industriell drift hjelper SiLK oss med å identifisere noe og analytikeren må svare på spørsmålene «Fant vi det vi forventet?», «Svarer dette til vår hypotese?», «Hvordan redusere antall falske positive?», «Hvordan for å forbedre anerkjennelsesnivået? » og så videre.
- Forbedring. I sluttfasen forbedrer vi det som ble gjort tidligere - vi lager maler, forbedrer og optimerer koden, omformulerer og avklarer hypotesen, etc.
Denne syklusen vil også gjelde for Cisco Stealthwatch, bare den siste automatiserer disse fem trinnene maksimalt, reduserer antallet analytikerfeil og øker effektiviteten av hendelsesdeteksjon. For eksempel kan du i SiLK berike nettverksstatistikk med eksterne data om ondsinnede IP-er ved hjelp av håndskrevne skript, og i Cisco Stealthwatch er det en innebygd funksjon som umiddelbart viser en alarm dersom nettverkstrafikk inneholder interaksjoner med IP-adresser fra svartelisten.
Hvis du går høyere i den "betalte" pyramiden for strømningsanalyseprogramvare, vil det etter den helt gratis SiLK være en shareware ELK, bestående av tre nøkkelkomponenter - Elasticsearch (indeksering, søk og dataanalyse), Logstash (datainngang/-utgang ) og Kibana (visualisering). I motsetning til SiLK, hvor du må skrive alt selv, har ELK allerede mange ferdige biblioteker/moduler (noen betalt, noen ikke) som automatiserer analysen av nettverkstelemetri. For eksempel lar GeoIP-filteret i Logstash deg knytte overvåkede IP-adresser til deres geografiske plassering (Stealthwatch har denne innebygde funksjonen).
ELK har også et ganske stort fellesskap som fullfører de manglende komponentene til denne overvåkingsløsningen. For å jobbe med Netflow, IPFIX og sFlow kan du for eksempel bruke modulen , hvis du ikke er fornøyd med Logstash Netflow-modulen, som kun støtter Netflow.
Mens det gir mer effektivitet i å samle flyt og søk i den, mangler ELK for tiden rik innebygd analyse for å oppdage anomalier og trusler i nettverkstelemetri. Det vil si at etter livssyklusen beskrevet ovenfor, må du uavhengig beskrive bruddmodeller og deretter bruke den i kampsystemet (det er ingen innebygde modeller der).
Det finnes selvfølgelig mer sofistikerte utvidelser for ELK, som allerede inneholder noen modeller for å oppdage anomalier i nettverkstelemetri, men slike utvidelser koster penger og her er spørsmålet om spillet er verdt lyset - skriv en lignende modell selv, kjøp dens implementering for overvåkingsverktøyet ditt, eller kjøp en ferdig løsning av klassen Network Traffic Analysis.
Generelt vil jeg ikke gå inn i debatten om at det er bedre å bruke penger og kjøpe en ferdig løsning for å overvåke anomalier og trusler i nettverkstelemetri (for eksempel Cisco Stealthwatch) eller finne ut av det selv og tilpasse det samme SiLK, ELK eller nfdump eller OSU Flow Tools for hver nye trussel (jeg snakker om de to siste av dem sist)? Alle velger selv og alle har sine egne motiver for å velge noen av de to alternativene. Jeg ville bare vise at nettverkstelemetri er et veldig viktig verktøy for å sikre nettverkssikkerheten til den interne infrastrukturen din, og du bør ikke overse det, for ikke å bli med på listen over selskaper hvis navn er nevnt i media sammen med epitetene " hacket", "ikke-kompatibel med krav til informasjonssikkerhet" ", "ikke tenker på sikkerheten til deres data og kundedata."
For å oppsummere vil jeg gjerne liste opp de viktigste tipsene du bør følge når du bygger informasjonssikkerhetsovervåking av din interne infrastruktur:
- Ikke bare begrense deg til omkretsen! Bruk (og velg) nettverksinfrastruktur ikke bare for å flytte trafikk fra punkt A til punkt B, men også for å løse problemer med cybersikkerhet.
- Studer de eksisterende overvåkingsmekanismene for informasjonssikkerhet i nettverksutstyret ditt og bruk dem.
- For intern overvåking, gi preferanse til telemetrianalyse - det lar deg oppdage opptil 80-90% av alle sikkerhetshendelser for nettverksinformasjon, mens du gjør det som er umulig når du fanger nettverkspakker og sparer plass for lagring av alle informasjonssikkerhetshendelser.
- For å overvåke flyter, bruk Netflow v9 eller IPFIX - de gir mer informasjon i en sikkerhetskontekst og lar deg overvåke ikke bare IPv4, men også IPv6, MPLS, etc.
- Bruk en ikke-samplet flytprotokoll – den gir mer informasjon for å oppdage trusler. For eksempel Netflow eller IPFIX.
- Sjekk belastningen på nettverksutstyret ditt - det kan kanskje ikke håndtere flytprotokollen også. Vurder deretter å bruke virtuelle sensorer eller Netflow Generation Appliance.
- Implementer kontroll først og fremst på tilgangsnivå – dette vil gi deg muligheten til å se 100 % av all trafikk.
- Hvis du ikke har noe valg og du bruker russisk nettverksutstyr, velg en som støtter flytprotokoller eller har SPAN/RSPAN-porter.
- Kombiner inntrengnings-/angrepsdeteksjons-/forebyggende systemer i kantene og flytanalysesystemer i det interne nettverket (inkludert i skyene).
Angående det siste tipset vil jeg gjerne gi en illustrasjon som jeg allerede har gitt tidligere. Du ser at hvis tidligere informasjonssikkerhetstjenesten Cisco nesten utelukkende bygde sitt overvåkingssystem for informasjonssikkerhet på grunnlag av inntrengningsdeteksjonssystemer og signaturmetoder, står de nå for bare 20 % av hendelsene. Ytterligere 20% faller på flytanalysesystemer, noe som antyder at disse løsningene ikke er et innfall, men et reelt verktøy i aktivitetene til informasjonssikkerhetstjenester til en moderne bedrift. Dessuten har du det viktigste for implementeringen deres - nettverksinfrastruktur, investeringer som kan beskyttes ytterligere ved å tildele informasjonssikkerhetsovervåkingsfunksjoner til nettverket.
Jeg har spesifikt ikke berørt temaet respons på anomalier eller trusler identifisert i nettverksstrømmer, men jeg tror at det allerede er klart at overvåking ikke bare skal ende med oppdagelsen av en trussel. Den bør følges av et svar og helst i en automatisk eller automatisert modus. Men dette er et tema for en egen artikkel.
Ytterligere informasjon:
PS. Hvis det er lettere for deg å høre alt som er skrevet ovenfor, kan du se den timelange presentasjonen som dannet grunnlaget for dette notatet.
Kilde: www.habr.com