Wanneer dit kom by die monitering van die sekuriteit van 'n interne korporatiewe of departementele netwerk, assosieer baie dit met inligtinglekbeheer en die implementering van DLP-oplossings. En as jy probeer om die vraag te verfyn en te vra hoe jy aanvalle op die interne netwerk bespeur, dan sal die antwoord gewoonlik melding wees van intrusieopsporingstelsels (IDS). En wat 10-20 jaar gelede die enigste opsie was, word vandag 'n anachronisme. Daar is 'n meer effektiewe, en op sommige plekke die enigste moontlike opsie om die interne netwerk te monitor - om vloeiprotokolle te gebruik, wat oorspronklik ontwerp is om netwerkprobleme te soek (foutsporing), maar mettertyd omskep in 'n baie interessante sekuriteitsinstrument. Hier sal ons praat oor wat vloeiprotokolle is en watter help om netwerkaanvalle beter op te spoor, waar dit die beste is om vloeimonitering te implementeer, waarna om te kyk wanneer so 'n skema ontplooi word, en selfs hoe om dit alles op huishoudelike toerusting te "verhoog" , Ons sal binne die bestek van hierdie artikel praat.
Ek sal nie stilstaan by die vraag “Waarom moet ons die veiligheid van die interne infrastruktuur monitor nie?” Die antwoord daarop is soort van voor die hand liggend. Maar as jy nietemin weereens wil seker maak dat jy vandag nie daarsonder kan klaarkom nie, 'n kort video met 'n storie oor hoe jy op 17 maniere by 'n korporatiewe netwerk kan kom wat deur 'n firewall beskerm word. Daarom sal ons aanvaar dat ons verstaan dat interne monitering 'n noodsaaklike ding is en dit bly net om te verstaan hoe dit georganiseer kan word.
Ek sal drie sleuteldatabronne vir infrastruktuurmonitering op netwerkvlak uitsonder:
- "rou" verkeer wat ons vang en indien vir ontleding aan sommige ontledingstelsels,
- gebeure vanaf netwerktoestelle waardeur verkeer beweeg,
- verkeersinligting ontvang via een van die vloeiprotokolle.
Die vaslegging van rou verkeer is die gewildste opsie onder sekuriteitsmense, want dit het histories verskyn en was die heel eerste. Konvensionele netwerk-inbraakdetectiestelsels (die heel eerste kommersiële inbraakdetectiestelsel was NetRanger van die Wheel Group, wat in 1998 deur Cisco gekoop is) was net besig met die vaslegging van pakkies (en later sessies) waarin sekere handtekeninge deursoek is (“beslissende reëls” in die terminologie van die FSTEC), wat aanvalle aandui. Natuurlik kan jy rou verkeer nie net met IDS ontleed nie, maar ook met ander instrumente (byvoorbeeld Wireshark, tcpdum of die NBAR2-funksionaliteit in Cisco IOS), maar hulle het gewoonlik nie die kennisbasis wat 'n inligtingsekuriteitsinstrument onderskei van 'n gereelde IT-hulpmiddel.
Dus, inbraakdetectiestelsels. Die oudste en gewildste metode om netwerkaanvalle op te spoor, wat 'n goeie werk aan die omtrek doen (maak nie saak wat - korporatief, datasentrum, segment, ens.), maar misluk in moderne geskakelde en sagteware-gedefinieerde netwerke. In die geval van 'n netwerk wat op die basis van konvensionele skakelaars gebou is, word die infrastruktuur van inbraakdetectiesensors te groot - jy sal 'n sensor op elke verbinding met die gasheer moet plaas waarteen jy aanvalle wil monitor. Enige vervaardiger sal natuurlik graag honderde en duisende sensors aan jou verkoop, maar ek dink jou begroting kan nie sulke uitgawes weerstaan nie. Ek kan sê dat selfs by Cisco (en ons is die ontwikkelaars van NGIPS) ons dit nie kon doen nie, hoewel, dit wil voorkom, die kwessie van prys voor ons lê. moet staan nie - dit is ons eie besluit. Daarbenewens ontstaan die vraag, hoe om die sensor in hierdie weergawe aan te sluit? In 'n gaping? Wat as die sensor self misluk? Benodig jy 'n bypass-module in die sensor? Gebruik splitters (tik)? Dit alles verhoog die koste van die oplossing en maak dit onbekostigbaar vir 'n maatskappy van enige grootte.
Jy kan probeer om die sensor aan die SPAN/RSPAN/ERSPAN-poort te “hang” en verkeer daarheen vanaf die nodige skakelpoorte te lei. Hierdie opsie verwyder die probleem wat in die vorige paragraaf beskryf is gedeeltelik, maar stel 'n ander een - die SPAN-poort kan nie absoluut al die verkeer ontvang wat na hom gestuur sal word nie - dit sal nie genoeg bandwydte hê nie. Gewillig om iets op te offer. Of laat sommige van die nodusse sonder monitering (dan moet jy dit eers prioritiseer), of stuur nie alle verkeer vanaf die nodus nie, maar slegs 'n sekere tipe. Ons kan in elk geval 'n paar aanvalle mis. Daarbenewens kan die SPAN-poort vir ander behoeftes beset word. Gevolglik sal ons die bestaande netwerktopologie moet hersien en moontlik aanpassings daaraan moet maak om jou netwerk tot die maksimum te dek met die aantal sensors wat jy het (en dit met IT koördineer).
Wat as jou netwerk asimmetriese roetes gebruik? En as jy SDN geïmplementeer het of beplan om te implementeer? Maar wat as jy gevirtualiseerde masjiene of houers moet monitor waarvan die verkeer glad nie die fisiese skakelaar bereik nie? Dit is vrae waarvan tradisionele IDS-verskaffers nie hou nie, want hulle weet nie hoe om dit te beantwoord nie. Miskien sal hulle jou oortuig dat al hierdie modieuse tegnologieë hype is en dat jy dit nie nodig het nie. Miskien sal hulle praat oor die behoefte om klein te begin. Of miskien sal hulle sê dat jy 'n kragtige dorsmasjien in die middel van die netwerk moet plaas en alle verkeer daarheen moet lei met behulp van lasbalanseerders. Watter opsie jy ook al aangebied word, jy moet self duidelik verstaan hoe dit jou pas. En neem eers daarna 'n besluit oor die keuse van benadering tot die monitering van die inligtingsekuriteit van die netwerkinfrastruktuur. Om terug te keer na pakkievaslegging, wil ek sê dat hierdie metode steeds baie gewild en belangrik is, maar die hoofdoel daarvan is grensbeheer; die grense tussen jou organisasie en die internet, die grense tussen die datasentrum en die res van die netwerk, die grense tussen die prosesbeheerstelsel en die korporatiewe segment. Op hierdie plekke het klassieke IDS / IPS steeds die reg om te bestaan en goeie werk met hul take te doen.
Kom ons gaan na die tweede opsie. Ontleding van gebeure wat van netwerktoestelle af kom, kan ook gebruik word vir indringingsopsporingsdoeleindes, maar nie as die hoofmeganisme nie, aangesien dit slegs 'n klein klas indringings bespeur. Daarbenewens is 'n mate van reaktiwiteit inherent daaraan - 'n aanval moet eers plaasvind, dan moet dit deur 'n netwerktoestel reggestel word, wat op een of ander manier 'n probleem met inligtingsekuriteit sal aandui. Daar is verskeie sulke metodes. Dit kan syslog, RMON of SNMP wees. Die laaste twee protokolle vir netwerkmonitering in die konteks van inligtingsekuriteit word slegs gebruik as ons 'n DoS-aanval op die netwerktoerusting self moet opspoor, aangesien u met RMON en SNMP byvoorbeeld die las op die toestel se sentrale verwerker of sy koppelvlakke. Dit is een van die "goedkoopste" (almal het syslog of SNMP), maar ook die ondoeltreffendste van alle maniere om die inligtingsekuriteit van die interne infrastruktuur te monitor - baie aanvalle word eenvoudig daarvan weggesteek. Natuurlik moet hulle nie verwaarloos word nie, en dieselfde syslog-analise help jou om veranderinge in die konfigurasie van die toestel self betyds te identifiseer, wat dit in die gedrang bring, maar dit is nie baie geskik om aanvalle op die hele netwerk op te spoor nie.
Die derde opsie is om inligting te ontleed oor verkeer wat deur 'n toestel gaan wat een van verskeie vloeiprotokolle ondersteun. In hierdie geval, ongeag die protokol, bestaan die stroominfrastruktuur noodwendig uit drie komponente:
- Generasie of uitvoervloei. Hierdie rol word gewoonlik aan 'n roeteerder, skakelaar of ander netwerktoestel toegeken, wat, deur netwerkverkeer deur homself te stuur, jou toelaat om sleutelparameters daaruit te onttrek, wat dan na die versamelingsmodule oorgedra word. Byvoorbeeld, Cisco se Netflow-protokol word nie net op routers en skakelaars ondersteun nie, insluitend virtuele en industriële, maar ook op draadlose beheerders, firewalls en selfs bedieners.
- Insamelingsvloei. As in ag geneem word dat daar gewoonlik meer as een netwerktoestel in 'n moderne netwerk is, ontstaan die probleem om strome in te samel en te konsolideer, wat opgelos word met behulp van sogenaamde versamelaars wat die ontvangde strome verwerk en dan vir ontleding oordra.
- vloei analise. Die ontleder neem die hoof intellektuele taak op en maak sekere gevolgtrekkings deur verskeie algoritmes op die strome toe te pas. Byvoorbeeld, binne 'n IT-funksie kan so 'n ontleder netwerkbottelnekke identifiseer of die verkeersladingprofiel ontleed om die netwerk verder te optimaliseer. En vir inligtingsekuriteit kan so 'n ontleder datalekkasies, die verspreiding van kwaadwillige kode of DoS-aanvalle opspoor.
Moenie dink so 'n drievlak-argitektuur is te ingewikkeld nie - alle ander opsies (met die moontlike uitsondering van netwerkmoniteringstelsels wat met SNMP en RMON werk) werk ook daarvolgens. Ons het 'n datagenerator vir ontleding, wat 'n netwerktoestel of 'n alleenstaande sensor is. Ons het 'n alarm-insamelingstelsel en ons het 'n bestuurstelsel vir die hele monitering-infrastruktuur. Die laaste twee komponente kan binne 'n enkele nodus gekombineer word, maar in min of meer groot netwerke is hulle gewoonlik oor twee, op 'n minimum, toestelle versprei om skaalbaarheid en betroubaarheid te verseker.
Anders as pakkieanalise, wat gebaseer is op die studie van die kop- en dataliggaam van elke pakkie en die sessies wat daaruit bestaan, maak vloeianalise staat op die versameling van metadata oor netwerkverkeer. Wanneer, hoeveel, van waar en waar, hoe ... dit is die vrae wat netwerktelemetrie-analise beantwoord met behulp van verskeie vloeiprotokolle. Aanvanklik is dit gebruik om statistieke te ontleed en na IT-probleme in die netwerk te soek, maar toe, soos die ontwikkeling van analitiese meganismes, het dit moontlik geword om dit vir sekuriteitsdoeleindes op dieselfde telemetrie toe te pas. Dit is die moeite werd om hier te herhaal dat vloeianalise nie pakkieopvang vervang of vervang nie. Elkeen van hierdie metodes het sy eie omvang. Maar in die konteks van hierdie artikel is dit vloeianalise wat die beste geskik is vir die monitering van interne infrastruktuur. Jy het netwerktoestelle (of dit nou in 'n sagteware-gedefinieerde paradigma werk of volgens statiese reëls) wat 'n aanval nie kan omseil nie. Dit kan die klassieke IDS-sensor omseil, maar nie 'n netwerktoestel wat die vloeiprotokol ondersteun nie. Dit is die voordeel van hierdie metode.
Aan die ander kant, as jy ’n bewysbasis vir wetstoepassing of jou eie insident-ondersoekspan benodig, kan jy nie sonder pakkievaslegging klaarkom nie – netwerktelemetrie is nie ’n kopie van die verkeer wat gebruik kan word om bewyse in te samel nie; dit is nodig vir vinnige opsporing en besluitneming op die gebied van inligtingsekuriteit. Aan die ander kant, met behulp van telemetrie-analise, kan jy nie alle netwerkverkeer "skryf" nie (indien enigiets, Cisco is ook betrokke by datasentrums :-), maar slegs die een wat by die aanval betrokke is. Telemetrie-analise-instrumente in hierdie verband sal tradisionele pakkievasvangmeganismes goed aanvul, wat 'n opdrag gee vir selektiewe vaslegging en berging. Andersins sal u 'n kolossale berging-infrastruktuur moet hê.
Stel jou voor 'n netwerk wat teen 250 Mbps werk. As jy al hierdie volume wil stoor, benodig jy 31 MB berging vir een sekonde van verkeersoordrag, 1,8 GB vir een minuut, 108 GB vir een uur en 2,6 TB vir een dag. Om daaglikse data vanaf 'n netwerk met 'n bandwydte van 10 Gb/s te stoor, sal jy 108 TB berging benodig. Maar sommige reguleerders vereis dat jy sekuriteitsdata vir jare stoor ... Die op-aanvraag-opname wat vloei-analise help jou om hierdie waardes in ordes van grootte te verminder. Terloops, as ons praat oor die verhouding van die volume aangetekende data van netwerktelemetrie en volle data-vaslegging, dan is dit ongeveer 1 tot 500. Vir dieselfde waardes hierbo gegee, die berging van 'n volledige dekripsie van alle daaglikse verkeer sal onderskeidelik 5 en 216 GB wees (jy kan selfs na 'n gewone flash drive skryf).
As die metode om rou netwerkdata vir analise-instrumente vas te lê byna dieselfde is van verkoper tot verkoper, dan is die situasie anders in die geval van stroomanalise. Daar is verskeie variante van vloeiprotokolle, die verskille waarin jy moet weet in die konteks van sekuriteit. Die gewildste is die Netflow-protokol wat deur Cisco ontwikkel is. Daar is verskeie weergawes van hierdie protokol wat verskil in hul vermoëns en die hoeveelheid inligting wat oor verkeer aangeteken is. Die huidige weergawe is die negende (Netflow v9), waaruit die industriestandaard Netflow v10, ook bekend as IPFIX, ontwikkel is. Vandag ondersteun die meeste netwerkverkopers Netflow of IPFIX in hul toerusting. Maar daar is verskeie ander variante van vloeiprotokolle - sFlow, jFlow, cFlow, rFlow, NetStream, ens., waarvan sFlow die gewildste is. Dit is hy wat die meeste ondersteun word deur plaaslike vervaardigers van netwerktoerusting as gevolg van die gemak van implementering. Wat is die belangrikste verskille tussen Netflow, as 'n de facto-standaard, en dieselfde sFlow? Ek sal 'n paar sleutels uitlig. Eerstens, Netflow het gebruikerkonfigureerbare velde in teenstelling met vaste velde in sFlow. En tweedens, en dit is die belangrikste ding in ons geval, sFlow versamel die sogenaamde bemonsterde telemetrie; anders as ongemonsterde Netflow en IPFIX. Wat is die verskil tussen hulle?
Stel jou voor dat jy besluit om die boek te lees "” my kollegas Gary McIntyre, Joseph Munitz en Nadem Alfardan (jy kan 'n deel van die boek van die skakel aflaai). Jy het drie opsies om jou doel te bereik – lees die boek in sy geheel, blaai daardeur, stop by elke 10de of 20ste bladsy, of probeer om 'n hervertelling van sleutelkonsepte in 'n blog of diens soos SmartReading te vind. Dus, nie-gemonsterde telemetrie is die lees van elke "bladsy" van netwerkverkeer, dit wil sê die ontleding van metadata vir elke pakkie. Gemonsterde telemetrie is 'n selektiewe studie van verkeer in die hoop dat die geselekteerde monsters sal wees wat jy nodig het. Afhangende van die kanaalspoed, sal die gemonsterde telemetrie elke 64ste, 200ste, 500ste, 1000ste, 2000ste of selfs 10000ste pakkie vir ontleding stuur.
In die konteks van inligtingsekuriteitmonitering beteken dit dat gemonsterde telemetrie goed geskik is vir die opsporing van DDoS-aanvalle, skandering, verspreiding van kwaadwillige kode, maar dit kan atoom- of multipakkie-aanvalle mis wat nie ingesluit is in die monster wat vir ontleding gestuur word nie. Ongeveegde telemetrie het ook nie sulke tekortkominge daarmee nie. die gebruik van die reeks bespeurde aanvalle is baie wyer. Hier is 'n klein lys van gebeure wat opgespoor kan word met behulp van netwerktelemetrie-analise-instrumente.
Natuurlik sal een of ander oopbron Netflow-ontleder jou nie toelaat om dit te doen nie, aangesien sy hooftaak is om telemetrie te versamel en basiese analise daarop uit te voer vanuit 'n IT-oogpunt. Om IS-bedreigings gebaseer op vloei te identifiseer, is dit nodig om die ontleder toe te rus met verskeie enjins en algoritmes, wat kuberveiligheidsprobleme sal identifiseer op grond van standaard- of pasgemaakte Netvloei-velde, standaarddata sal verryk met eksterne data van verskeie bedreigingsintelligensie-bronne, ens.
As u dus 'n keuse het, stop dit dan op Netflow of IPFIX. Maar selfs al werk jou toerusting net met sFlow, soos huishoudelike vervaardigers, dan kan jy selfs in hierdie geval daarby baat in 'n sekuriteitskonteks.
In die somer van 2019 het ek die geleenthede ontleed wat Russiese netwerkystervervaardigers het, en almal, uitgesluit NSG, Polygon en Craftway, het ondersteuning vir sFlow aangekondig (ten minste Zelaks, Natex, Eltex, QTech, Rusteletech).
Die volgende vraag wat voor jou sal ontstaan, is waar om vloeiondersteuning vir sekuriteitsdoeleindes te implementeer? Eintlik is die vraag nie heeltemal korrek gestel nie. Op moderne toerusting word vloeiprotokolle byna altyd ondersteun. Daarom sou ek die vraag anders herformuleer - waar is die doeltreffendste manier om telemetrie uit 'n sekuriteitsoogpunt te versamel? Die antwoord sal redelik voor die hand liggend wees - op die toegangsvlak, waar jy 100% van alle verkeer sal sien, waar jy gedetailleerde inligting oor gashere sal hê (MAC, VLAN, koppelvlak-ID), waar jy selfs P2P-verkeer tussen gashere kan opspoor, wat is van kritieke belang vir skandering opsporing en verspreiding van kwaadwillige kode. Op die kernvlak kan jy dalk eenvoudig nie sommige van die verkeer sien nie, maar op die omtrekvlak sal jy goed sien as 'n kwart van jou netwerkverkeer. Maar as jy om een of ander rede vreemde toestelle op jou netwerk het wat aanvallers toelaat om die omtrek te "gaan en verlaat" wat die omtrek omseil, dan sal die ontleding van die telemetrie daaruit jou niks gee nie. Daarom, vir maksimum dekking, word dit aanbeveel om telemetrieversameling op die toegangsvlak te aktiveer. Terselfdertyd is dit opmerklik dat selfs al praat ons van virtualisering of houers, moderne virtuele skakelaars ook dikwels vloei ondersteun, wat jou toelaat om verkeer daar ook te beheer.
Maar aangesien ek die onderwerp geopper het, moet ek die vraag beantwoord, wat as die toerusting, fisies of virtueel, tog nie vloeiprotokolle ondersteun nie? Of is die insluiting daarvan verbode (byvoorbeeld in industriële segmente om betroubaarheid te verseker)? Of veroorsaak die aanskakeling van hoë SVE-gebruik (dit gebeur op ouer hardeware)? Om hierdie probleem op te los, is daar gespesialiseerde virtuele sensors (vloeisensor), wat in wese gewone splitters is wat verkeer deur hulself stuur en dit in die vorm van 'n vloei na die versamelingsmodule uitsaai. Dit is waar, in hierdie geval kry ons die hele hoop probleme waaroor ons hierbo gepraat het met betrekking tot pakketopname-instrumente. Dit wil sê, dit is nodig om nie net die voordele van vloeianalise-tegnologie te verstaan nie, maar ook die beperkings daarvan.
Nog 'n punt wat belangrik is om te onthou wanneer ons oor vloeianalise-instrumente praat. As ons die EPS (gebeurtenis per sekonde, gebeurtenisse per sekonde) metriek toepas in verhouding tot die gewone manier om sekuriteitsgebeurtenisse te genereer, dan is hierdie aanwyser nie van toepassing op telemetrie-analise nie; dit word vervang deur FPS (vloei per sekonde, vloei per sekonde). Soos in die geval van EPS, kan dit nie vooraf bereken word nie, maar dit is moontlik om die benaderde aantal drade wat 'n spesifieke toestel genereer, na gelang van sy taak te skat. Op die internet kan jy tabelle vind met benaderde waardes vir verskillende soorte ondernemingstoestelle en toestande, wat jou sal toelaat om te skat watter soort lisensies jy nodig het vir ontledingsinstrumente en wat hul argitektuur sal wees? Die feit is dat die IDS-sensor beperk word deur 'n sekere bandwydte, wat dit sal "uittrek", en die vloeikollektor het sy eie beperkings wat verstaan moet word. Daarom is daar in groot, geografies verspreide netwerke gewoonlik verskeie versamelaars. Toe ek beskryf , Ek het reeds die nommer van ons versamelaars gegee - daar is 21 van hulle. En dit is vir 'n netwerk wat oor vyf kontinente versprei is en ongeveer 'n halfmiljoen aktiewe toestelle tel).
Ons gebruik ons eie oplossing as 'n Netflow-moniteringstelsel , wat spesifiek daarop gefokus is om sekuriteitsprobleme op te los. Dit het baie ingeboude enjins vir die opsporing van abnormale, verdagte en ooglopend kwaadwillige aktiwiteit, wat jou toelaat om 'n wye verskeidenheid verskillende bedreigings op te spoor - van kripto-minering tot inligtinglekkasies, van die verspreiding van kwaadwillige kode tot bedrog. Soos die meeste vloei-ontleders, is Stealthwatch gebou op 'n drie-vlak skema (generator - versamelaar - ontleder), maar dit word aangevul met 'n aantal interessante kenmerke wat belangrik is in die konteks van die materiaal wat oorweeg word. Eerstens, dit integreer met pakketopvangoplossings (soos Cisco Security Packet Analyzer), wat jou toelaat om geselekteerde netwerksessies op te neem vir latere in-diepte ondersoek en ontleding. Tweedens, spesifiek om sekuriteitstake uit te brei, het ons 'n spesiale nvzFlow-protokol ontwikkel wat jou toelaat om toepassingsaktiwiteit op eindnodusse (bedieners, werkstasies, ens.) na telemetrie te "uitsaai" en dit na die versamelaar oor te dra vir verdere ontleding. As Stealthwatch in sy oorspronklike weergawe met enige vloeiprotokol (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) op die netwerkvlak werk, dan laat nvzFlow-ondersteuning toe dat data ook op die nodusvlak gekorreleer word. verbeter algehele stelseldoeltreffendheid en sien meer aanvalle as konvensionele netwerkvloei-ontleders.
Dit is duidelik dat wanneer daar vanuit 'n sekuriteitsoogpunt oor Netflow-analisestelsels gepraat word, die mark nie beperk is tot 'n enkele oplossing van Cisco nie. Jy kan beide kommersiële en gratis of deelware-oplossings gebruik. Dit is nogal vreemd as ek mededingers se oplossings op die Cisco-blog aanhaal, so ek sal 'n paar woorde sê oor hoe netwerktelemetrie ontleed kan word met behulp van twee gewilde, soortgelyke naam, maar steeds verskillende instrumente - SiLK en ELK.
SiLK is 'n stel gereedskap (die stelsel vir internetvlakkennis) vir verkeersanalise wat deur die Amerikaanse CERT / CC ontwikkel is en wat, in die konteks van vandag se artikel, Netflow (5de en 9de, die gewildste weergawes), IPFIX en ondersteun sFlow en die gebruik van verskeie nutsprogramme (rwfilter, rwcount, rwflowpack, ens.) om verskeie bewerkings op netwerktelemetrie uit te voer om tekens van ongemagtigde handelinge daarin op te spoor. Maar daar is 'n paar belangrike dinge om op te let. SiLK is 'n opdragreëlinstrument en voer aanlyn-analise uit, terwyl u 'n opdrag van die vorm tik (opsporing van ICMP-pakkies groter as 200 grepe):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nie baie gemaklik nie. Jy kan die iSiLK GUI gebruik, maar dit sal jou lewe nie veel makliker maak deur net die visualiseringsfunksie op te los nie, nie die ontledervervanger nie. En dit is die tweede punt. Anders as kommersiële oplossings, wat reeds 'n stewige analitiese basis het, anomalie-opsporingsalgoritmes wat ooreenstem met werkvloei, ens., in die geval van SiLK, sal jy dit alles self moet doen, wat effens ander bevoegdhede van jou sal vereis as om reeds gereed te gebruik -om te gebruik toolkit. Dit is nie goed nie en nie sleg nie - dit is 'n kenmerk van byna enige gratis hulpmiddel wat kom van die feit dat jy weet wat om te doen, en dit sal jou net hiermee help (kommersiële instrumente is minder afhanklik van die bevoegdhede van sy gebruikers, hoewel dit ook aanvaar dat ontleders ten minste basiese beginsels van die uitvoer van netwerkondersoeke en -monitering verstaan). Maar terug na SiLK. Die ontleder se werksiklus daarmee is soos volg:
- Formulering van 'n hipotese. Ons moet verstaan waarna ons in netwerktelemetrie sal soek, die unieke eienskappe ken waarmee ons sekere afwykings of bedreigings sal identifiseer.
- Model gebou. Nadat ons 'n hipotese geformuleer het, programmeer ons dit met dieselfde Python, dop of ander gereedskap wat nie by SiLK ingesluit is nie.
- Toets. Dit is tyd om die korrektheid van ons hipotese na te gaan, wat bevestig of weerlê word met behulp van die SiLK-hulpprogramme wat begin met 'rw', 'stel', 'sak'.
- Ontleding van werklike data. In kommersiële bedryf help SiLK ons om iets te identifiseer en die ontleder moet die vrae beantwoord: "Het ons gevind wat ons verwag het?", "Stem dit ooreen met ons hipotese?", "Hoe sal dit die aantal vals positiewes verminder?", "Hoe om die vlak van erkenning te verbeter? » en so aan.
- Verbetering. Op die finale stadium verbeter ons wat vroeër gedoen is - ons skep sjablone, verbeter en optimaliseer die kode, herformuleer en verfyn die hipotese, ens.
Hierdie siklus sal van toepassing wees op dieselfde Cisco Stealthwatch, net die laaste van hierdie vyf stappe outomatiseer tot die maksimum, wat die aantal ontlederfoute verminder en die doeltreffendheid van insidentopsporing verhoog. Byvoorbeeld, in SiLK kan jy netwerkstatistieke verryk met eksterne data oor kwaadwillige IP's deur jou eie skrifte te gebruik, en in Cisco Stealthwatch is dit 'n ingeboude funksie wat onmiddellik 'n alarm vir jou vertoon as interaksie met swartlys IP-adresse in die netwerk plaasvind verkeer.
As jy die piramide van "betaalde" sagteware vir die ontleding van vloei opgaan, sal die absoluut gratis SiLK gevolg word deur 'n shareware ELK, wat bestaan uit drie sleutelkomponente - Elasticsearch (indeksering, soek en ontleding van data), Logstash (data-invoer / -uitvoer) ) en Kibana (visualisering). Anders as SiLK, waar jy alles self moet skryf, het ELK reeds baie klaargemaakte biblioteke / modules (sommige word betaal, ander nie) wat die ontleding van netwerktelemetrie outomatiseer. Byvoorbeeld, die GeoIP-filter in Logstash laat jou toe om die gemonitorde IP-adresse aan hul geografiese ligging te bind (dieselfde Stealthwatch het hierdie ingeboude funksie).
ELK het ook 'n redelike groot gemeenskap wat die ontbrekende komponente by hierdie moniteringsoplossing voeg. Byvoorbeeld, om met Netflow, IPFIX en sFlow te werk, kan jy die module gebruik as jy nie tevrede is met die Logstash Netflow Module wat net Netflow ondersteun nie.
Om meer doeltreffendheid te gee om vloei te versamel en daarin te soek, het ELK tans nie 'n ryk ingeboude analise om afwykings en bedreigings in netwerktelemetrie op te spoor nie. Dit wil sê, na aanleiding van die lewensiklus wat hierbo beskryf is, sal jy onafhanklik oortredingsmodelle moet beskryf en dit dan in die gevegstelsel moet gebruik (daar is geen ingeboude modelle nie).
Natuurlik is daar meer gesofistikeerde uitbreidings vir ELK, wat reeds 'n paar modelle bevat vir die opsporing van anomalieë in netwerktelemetrie, maar sulke uitbreidings kos geld en die vraag is of die speletjie die kers werd is - skryf self 'n soortgelyke model, koop die implementering daarvan vir jou moniteringsinstrument of koop 'n sleuteloplossing van die netwerkverkeeranalise-klas.
Oor die algemeen wil ek nie in kontroversie gaan oor of dit beter is om geld te spandeer en 'n klaargemaakte oplossing te koop vir die monitering van afwykings en bedreigings in netwerktelemetrie (byvoorbeeld Cisco Stealthwatch) of dit self uit te vind en aan te pas dieselfde SiLK, ELK of nfdump of OSU Flow Tools vir elke nuwe bedreiging (ek praat van die laaste twee van hulle laaste keer)? Elkeen kies vir homself en elkeen het sy eie motiewe om een van die twee opsies te kies. Ek wou net wys dat netwerktelemetrie 'n baie belangrike hulpmiddel is om die netwerksekuriteit van jou interne infrastruktuur te verseker en jy moet dit nie verwaarloos nie, om nie 'n maatskappy by die lys te voeg wie se naam saam met die byskrifte in die media genoem word nie. "gekap", "nie-voldoen aan inligtingsekuriteitvereistes "," dink nie aan die sekuriteit van hul data en kliëntedata nie.
Opsommend wil ek graag die sleutelwenke lys wat u moet volg wanneer u inligtingsekuriteitmonitering van u interne infrastruktuur bou:
- Moenie jouself beperk tot net die omtrek nie! Gebruik (en kies) netwerkinfrastruktuur om nie net verkeer van punt A na punt B oor te dra nie, maar ook om kuberveiligheidskwessies op te los.
- Bestudeer die bestaande inligtingsekuriteitmoniteringsmeganismes in jou netwerktoerusting en gebruik dit.
- Vir interne monitering, gee voorkeur aan telemetrie-analise - dit laat jou toe om tot 80-90% van alle netwerkinligtingsekuriteitsinsidente op te spoor, terwyl jy doen wat onmoontlik is wanneer netwerkpakkies vasgelê word en stoorspasie vir alle inligtingsekuriteitsgebeurtenisse bespaar word.
- Om vloei te monitor, gebruik Netflow v9 of IPFIX - hulle gee meer inligting in die konteks van sekuriteit en laat jou toe om nie net IPv4 te monitor nie, maar ook IPv6, MPLS, ens.
- Gebruik 'n ongemonsterde vloeiprotokol - dit verskaf meer inligting om bedreigings op te spoor. Byvoorbeeld, Netflow of IPFIX.
- Gaan die vrag van jou netwerktoerusting na – dit sal dalk nie die verwerking van die vloeiprotokol ook kan hanteer nie. Oorweeg dan om virtuele sensors of 'n Netflow Generation Appliance te gebruik.
- Implementeer beheer in die eerste plek op die toegangsvlak - dit sal jou die geleentheid gee om 100% van alle verkeer te sien.
- As jy geen keuse het nie en jy gebruik Russiese netwerktoerusting, kies dan een wat vloeiprotokolle ondersteun of SPAN / RSPAN-poorte het.
- Kombineer indringing/aanval opsporing/voorkoming by die grense en vloeianalise stelsels in die interne netwerk (insluitend in die wolke).
Wat die laaste wenk betref, wil ek graag 'n illustrasie gee wat ek reeds voorheen gegee het. Jy kan sien dat as vroeër die Cisco IS-diens sy IS-moniteringstelsel byna volledig gebou het op grond van indringingopsporingstelsels en handtekeningmetodes, dit nou slegs 20% van die voorvalle uitmaak. Nog 20% word verantwoord deur vloeianalisestelsels, wat daarop dui dat hierdie oplossings nie 'n gril is nie, maar 'n ware hulpmiddel in die aktiwiteite van die inligtingsekuriteitsdienste van 'n moderne onderneming. Daarbenewens het jy die belangrikste ding vir die implementering daarvan - die netwerkinfrastruktuur, beleggings waarin addisioneel beskerm kan word deur inligtingsekuriteitmoniteringsfunksies aan die netwerk toe te ken.
Ek het doelbewus nie die onderwerp aangeraak om te reageer op afwykings of bedreigings wat in netwerkvloei bespeur word nie, maar ek dink dit is duidelik dat monitering nie net moet eindig met die opsporing van 'n bedreiging nie. Dit moet gevolg word deur 'n reaksie en verkieslik in outomatiese of outomatiese modus. Maar dit is 'n onderwerp vir 'n aparte artikel.
Bykomende inligting:
PS. As dit vir jou makliker is om na alles te luister wat hierbo geskryf is, dan kan jy die uurlange aanbieding kyk wat die basis van hierdie nota gevorm het.
Bron: will.com