Als het gaat om het monitoren van de veiligheid van een intern bedrijfs- of afdelingsnetwerk, associëren velen dit met het beheersen van informatielekken en het implementeren van DLP-oplossingen. En als je de vraag probeert te verhelderen en vraagt hoe je aanvallen op het interne netwerk detecteert, dan zal het antwoord in de regel een vermelding zijn van inbraakdetectiesystemen (IDS). En wat tien tot twintig jaar geleden de enige optie was, wordt vandaag de dag een anachronisme. Er is een effectievere en op sommige plaatsen de enige mogelijke optie voor het monitoren van een intern netwerk: het gebruik van stroomprotocollen, die oorspronkelijk waren ontworpen om netwerkproblemen op te sporen (probleemoplossing), maar in de loop van de tijd zijn omgevormd tot een zeer interessant beveiligingshulpmiddel. We zullen praten over welke stroomprotocollen er zijn en welke beter zijn in het detecteren van netwerkaanvallen, waar het het beste is om stroommonitoring te implementeren, waar je op moet letten bij het inzetten van een dergelijk schema, en zelfs hoe je dit allemaal op huishoudelijke apparatuur kunt 'liften'. binnen de reikwijdte van dit artikel.
Ik zal niet stilstaan bij de vraag: “Waarom is monitoring van de interne infrastructuurbeveiliging nodig?” Het antwoord lijkt duidelijk. Maar als je er toch nog eens zeker van wilt zijn dat je vandaag de dag niet meer zonder kunt, een korte video over hoe u op 17 manieren een door een firewall beschermd bedrijfsnetwerk kunt binnendringen. Daarom gaan we ervan uit dat we begrijpen dat interne monitoring een noodzakelijke zaak is en dat het enige dat overblijft is begrijpen hoe dit kan worden georganiseerd.
Ik zou drie belangrijke gegevensbronnen voor het monitoren van de infrastructuur op netwerkniveau willen benadrukken:
- ‘ruw’ verkeer dat we vastleggen en voor analyse indienen bij bepaalde analysesystemen,
- gebeurtenissen van netwerkapparaten waar verkeer doorheen gaat,
- verkeersinformatie ontvangen via een van de stroomprotocollen.
Het vastleggen van onbewerkt verkeer is de meest populaire optie onder beveiligingsspecialisten, omdat het historisch verscheen en de allereerste was. Conventionele netwerkinbraakdetectiesystemen (het allereerste commerciële inbraakdetectiesysteem was NetRanger van de Wheel Group, in 1998 gekocht door Cisco) hielden zich precies bezig met het vastleggen van pakketten (en latere sessies) waarin naar bepaalde handtekeningen werd gezocht (“beslissende regels” in FSTEC-terminologie), signalering van aanvallen. Natuurlijk kun je het ruwe verkeer niet alleen analyseren met IDS, maar ook met andere tools (bijvoorbeeld Wireshark, tcpdum of de NBAR2-functionaliteit in Cisco IOS), maar deze missen meestal de kennisbasis die een informatiebeveiligingstool onderscheidt van een reguliere tool. IT-tool.
Aanvaldetectiesystemen dus. De oudste en meest populaire methode voor het detecteren van netwerkaanvallen, die het goed doet aan de perimeter (wat er ook gebeurt - bedrijf, datacenter, segment, enz.), maar faalt in moderne geschakelde en softwaregedefinieerde netwerken. In het geval van een netwerk dat is gebouwd op basis van conventionele switches wordt de infrastructuur van aanvalsdetectiesensoren te groot: je zult een sensor moeten installeren op elke verbinding met het knooppunt waarop je aanvallen wilt monitoren. Elke fabrikant zal u natuurlijk graag honderden en duizenden sensoren verkopen, maar ik denk dat uw budget dergelijke uitgaven niet kan dragen. Ik kan zeggen dat we dit zelfs bij Cisco (en wij zijn de ontwikkelaars van NGIPS) niet zouden kunnen doen, ook al lijkt het erop dat de kwestie van de prijs voor ons ligt. Ik zou niet moeten blijven staan; het is onze eigen beslissing. Bovendien rijst de vraag: hoe sluit je de sensor in deze versie aan? In de kloof? Wat als de sensor zelf defect raakt? Een bypassmodule in de sensor nodig? Splitsers gebruiken (tap)? Dit alles maakt de oplossing duurder en onbetaalbaar voor een bedrijf van welke omvang dan ook.
U kunt proberen de sensor aan een SPAN/RSPAN/ERSPAN-poort te ‘hangen’ en verkeer vanaf de vereiste switchpoorten ernaartoe te leiden. Deze optie verwijdert gedeeltelijk het probleem dat in de vorige paragraaf is beschreven, maar brengt een ander probleem met zich mee: de SPAN-poort kan niet absoluut al het verkeer accepteren dat ernaar wordt verzonden; hij zal niet genoeg bandbreedte hebben. Je zult iets moeten opofferen. Laat een aantal knooppunten achter zonder monitoring (dan moet u ze eerst prioriteren), of stuur niet al het verkeer vanaf het knooppunt, maar alleen een bepaald type. In ieder geval kunnen we enkele aanvallen missen. Bovendien kan de SPAN-poort voor andere behoeften worden gebruikt. Hierdoor zullen wij de bestaande netwerktopologie moeten herzien en eventueel aanpassen om uw netwerk maximaal te dekken met het aantal sensoren dat u heeft (en dit afstemmen met IT).
Wat als uw netwerk asymmetrische routes gebruikt? Wat als u SDN heeft geïmplementeerd of van plan bent dit te implementeren? Wat als u gevirtualiseerde machines of containers moet monitoren waarvan het verkeer de fysieke switch helemaal niet bereikt? Dit zijn vragen waar traditionele IDS-leveranciers niet van houden, omdat ze niet weten hoe ze ze moeten beantwoorden. Misschien zullen ze je ervan overtuigen dat al deze modieuze technologieën een hype zijn en dat je ze niet nodig hebt. Misschien zullen ze praten over de noodzaak om klein te beginnen. Of misschien zullen ze zeggen dat je een krachtige dorsmachine in het midden van het netwerk moet plaatsen en al het verkeer daar naartoe moet leiden met behulp van balancers. Welke optie u ook wordt aangeboden, u moet duidelijk begrijpen hoe deze bij u past. En pas daarna een beslissing nemen over het kiezen van een aanpak voor het monitoren van de informatiebeveiliging van de netwerkinfrastructuur. Terugkomend op het vastleggen van pakketten, wil ik zeggen dat deze methode nog steeds erg populair en belangrijk is, maar dat het hoofddoel ervan grenscontrole is; grenzen tussen uw organisatie en internet, grenzen tussen het datacenter en de rest van het netwerk, grenzen tussen het procescontrolesysteem en het corporate segment. Op deze plekken hebben de klassieke IDS/IPS nog steeds bestaansrecht en kunnen ze hun taken goed uitvoeren.
Laten we verder gaan met de tweede optie. Analyse van gebeurtenissen afkomstig van netwerkapparaten kan ook worden gebruikt voor aanvalsdetectie, maar niet als hoofdmechanisme, omdat hiermee slechts een kleine groep inbraken kan worden gedetecteerd. Bovendien is het inherent aan enige reactiviteit: de aanval moet eerst plaatsvinden en vervolgens worden geregistreerd door een netwerkapparaat, dat op de een of andere manier een probleem met de informatiebeveiliging zal signaleren. Er zijn verschillende van dergelijke manieren. Dit kan syslog, RMON of SNMP zijn. De laatste twee protocollen voor netwerkmonitoring in de context van informatiebeveiliging worden alleen gebruikt als we een DoS-aanval op de netwerkapparatuur zelf moeten detecteren, omdat het met behulp van RMON en SNMP bijvoorbeeld mogelijk is om de belasting van de centrale van het apparaat te monitoren processor of zijn interfaces. Dit is een van de “goedkoopste” (iedereen heeft syslog of SNMP), maar ook de meest ineffectieve van alle methoden om de informatiebeveiliging van de interne infrastructuur te bewaken - veel aanvallen zijn er eenvoudigweg voor verborgen. Natuurlijk mogen ze niet worden verwaarloosd, en dezelfde syslog-analyse helpt je om tijdig veranderingen in de configuratie van het apparaat zelf te identificeren, het compromis ervan, maar het is niet erg geschikt voor het detecteren van aanvallen op het hele netwerk.
De derde optie is het analyseren van informatie over verkeer dat door een apparaat gaat dat een van de verschillende stroomprotocollen ondersteunt. In dit geval bestaat de threading-infrastructuur, ongeacht het protocol, noodzakelijkerwijs uit drie componenten:
- Generatie of export van stroom. Deze rol wordt meestal toegewezen aan een router, switch of ander netwerkapparaat, waarmee u, door netwerkverkeer door zichzelf te laten gaan, er belangrijke parameters uit kunt extraheren, die vervolgens naar de verzamelmodule worden verzonden. Cisco ondersteunt het Netflow-protocol bijvoorbeeld niet alleen op routers en switches, inclusief virtuele en industriële, maar ook op draadloze controllers, firewalls en zelfs servers.
- Verzamelstroom. Gezien het feit dat een modern netwerk meestal meer dan één netwerkapparaat heeft, ontstaat het probleem van het verzamelen en consolideren van stromen, dat wordt opgelost met behulp van zogenaamde collectors, die de ontvangen stromen verwerken en deze vervolgens verzenden voor analyse.
- Stroomanalyse De analysator neemt de belangrijkste intellectuele taak op zich en trekt, door verschillende algoritmen op streams toe te passen, bepaalde conclusies. Als onderdeel van een IT-functie kan een dergelijke analysator bijvoorbeeld netwerkknelpunten identificeren of het verkeersbelastingsprofiel analyseren voor verdere netwerkoptimalisatie. En voor de informatiebeveiliging kan zo’n analyser datalekken, de verspreiding van kwaadaardige code of DoS-aanvallen detecteren.
Denk niet dat deze drielaagse architectuur te ingewikkeld is: alle andere opties (behalve misschien netwerkmonitoringsystemen die met SNMP en RMON werken) werken er ook volgens. We hebben een datagenerator voor analyse, die een netwerkapparaat of een stand-alone sensor kan zijn. Wij beschikken over een alarmopvangsysteem en een beheersysteem voor de gehele monitoringinfrastructuur. De laatste twee componenten kunnen binnen één knooppunt worden gecombineerd, maar worden in min of meer grote netwerken meestal over minimaal twee apparaten verspreid om schaalbaarheid en betrouwbaarheid te garanderen.
In tegenstelling tot pakketanalyse, die gebaseerd is op het bestuderen van de header- en bodygegevens van elk pakket en de sessies waaruit het bestaat, is stroomanalyse gebaseerd op het verzamelen van metagegevens over netwerkverkeer. Wanneer, hoeveel, waar en waar, hoe... dit zijn de vragen die worden beantwoord door de analyse van netwerktelemetrie met behulp van verschillende stroomprotocollen. Aanvankelijk werden ze gebruikt om statistieken te analyseren en IT-problemen op het netwerk op te sporen, maar naarmate de analytische mechanismen zich ontwikkelden, werd het mogelijk om ze voor beveiligingsdoeleinden op dezelfde telemetrie toe te passen. Het is de moeite waard om nogmaals op te merken dat stroomanalyse het vastleggen van pakketten niet vervangt of vervangt. Elk van deze methoden heeft zijn eigen toepassingsgebied. Maar in de context van dit artikel is stroomanalyse het meest geschikt voor het monitoren van de interne infrastructuur. Je hebt netwerkapparaten (of ze nu werken in een door software gedefinieerd paradigma of volgens statische regels) die een aanval niet kan omzeilen. Het kan een klassieke IDS-sensor omzeilen, maar een netwerkapparaat dat het flowprotocol ondersteunt, kan dat niet. Dit is het voordeel van deze methode.
Aan de andere kant, als u bewijs nodig heeft voor wetshandhavingsinstanties of uw eigen incidentonderzoeksteam, kunt u niet zonder pakketregistratie; netwerktelemetrie is geen kopie van verkeer dat kan worden gebruikt om bewijsmateriaal te verzamelen; het is nodig voor snelle detectie en besluitvorming op het gebied van informatiebeveiliging. Aan de andere kant kun je met behulp van telemetrieanalyse niet al het netwerkverkeer 'schrijven' (Cisco heeft in ieder geval te maken met datacenters :-), maar alleen datgene dat bij de aanval betrokken is. Telemetrie-analysetools zullen in dit opzicht de traditionele mechanismen voor het vastleggen van pakketten goed aanvullen en opdrachten geven voor selectieve opvang en opslag. Anders zul je over een kolossale opslaginfrastructuur moeten beschikken.
Laten we ons een netwerk voorstellen dat werkt met een snelheid van 250 Mbit/sec. Als je al dit volume wilt opslaan, heb je 31 MB opslagruimte nodig voor één seconde verkeersoverdracht, 1,8 GB voor één minuut, 108 GB voor één uur en 2,6 TB voor één dag. Om dagelijkse data op te slaan vanaf een netwerk met een bandbreedte van 10 Gbit/s heb je 108 TB opslagruimte nodig. Maar sommige toezichthouders eisen dat beveiligingsgegevens jarenlang worden opgeslagen... On-demand opname, waarvan de stroomanalyse u helpt bij de implementatie, helpt deze waarden met ordes van grootte te verminderen. Trouwens, als we het hebben over de verhouding tussen het volume van de opgenomen netwerktelemetriegegevens en de volledige gegevensverzameling, dan is dit ongeveer 1 op 500. Voor dezelfde waarden die hierboven zijn gegeven, wordt een volledig transcript van al het dagelijkse verkeer opgeslagen zal respectievelijk 5 en 216 GB zijn (je kunt het zelfs opnemen op een gewone flashdrive).
Als voor tools voor het analyseren van onbewerkte netwerkgegevens de methode voor het vastleggen ervan vrijwel hetzelfde is van leverancier tot leverancier, dan is de situatie in het geval van stroomanalyse anders. Er zijn verschillende opties voor stroomprotocollen, waarvan u de verschillen moet kennen in de context van beveiliging. Het populairst is het Netflow-protocol, ontwikkeld door Cisco. Er zijn verschillende versies van dit protocol, die verschillen in hun mogelijkheden en de hoeveelheid geregistreerde verkeersinformatie. De huidige versie is de negende (Netflow v9), op basis waarvan de industriestandaard Netflow v10, ook wel IPFIX genoemd, is ontwikkeld. Tegenwoordig ondersteunen de meeste netwerkleveranciers Netflow of IPFIX in hun apparatuur. Maar er zijn verschillende andere opties voor flowprotocollen - sFlow, jFlow, cFlow, rFlow, NetStream, enz., waarvan sFlow de meest populaire is. Het is dit type dat het vaakst wordt ondersteund door binnenlandse fabrikanten van netwerkapparatuur vanwege het gemak van implementatie. Wat zijn de belangrijkste verschillen tussen Netflow, dat de facto een standaard is geworden, en sFlow? Ik wil een aantal belangrijke punten benadrukken. Ten eerste heeft Netflow door de gebruiker aanpasbare velden, in tegenstelling tot de vaste velden in sFlow. En ten tweede, en dit is in ons geval het belangrijkste: sFlow verzamelt zogenaamde bemonsterde telemetrie; in tegenstelling tot de onbemonsterde versie voor Netflow en IPFIX. Wat is het verschil tussen hen?
Stel je voor dat je besluit het boek te lezen “” van mijn collega's - Gary McIntyre, Joseph Munitz en Nadem Alfardan (je kunt een deel van het boek downloaden via de link). Je hebt drie opties om je doel te bereiken: lees het hele boek, blader er doorheen, stop bij elke 10e of 20e pagina, of probeer een hervertelling van de belangrijkste concepten te vinden op een blog of dienst als SmartReading. Onbemonsterde telemetrie leest dus elke “pagina” van het netwerkverkeer, dat wil zeggen, het analyseren van metagegevens voor elk pakket. Sampled-telemetrie is de selectieve studie van verkeer in de hoop dat de geselecteerde samples bevatten wat u nodig heeft. Afhankelijk van de kanaalsnelheid wordt de bemonsterde telemetrie elk 64e, 200e, 500e, 1000e, 2000e of zelfs 10000e pakket ter analyse verzonden.
In de context van informatiebeveiligingsmonitoring betekent dit dat bemonsterde telemetrie zeer geschikt is voor het detecteren van DDoS-aanvallen, het scannen en verspreiden van kwaadaardige code, maar mogelijk atomaire of multi-pakketaanvallen mist die niet waren opgenomen in het monster dat voor analyse werd verzonden. Onbemonsterde telemetrie heeft dergelijke nadelen niet. Hiermee is het bereik van gedetecteerde aanvallen veel groter. Hier is een korte lijst met gebeurtenissen die kunnen worden gedetecteerd met behulp van analysetools voor netwerktelemetrie.
Natuurlijk staat een open source Netflow-analysator je dit niet toe, omdat de hoofdtaak het verzamelen van telemetrie is en er basisanalyses op uitvoert vanuit IT-oogpunt. Om informatiebeveiligingsbedreigingen op basis van flow te identificeren, is het noodzakelijk om de analyser uit te rusten met verschillende motoren en algoritmen, die cyberbeveiligingsproblemen zullen identificeren op basis van standaard of aangepaste Netflow-velden, standaardgegevens zullen verrijken met externe gegevens uit verschillende Threat Intelligence-bronnen, enz.
Als u de keuze heeft, kies dan voor Netflow of IPFIX. Maar zelfs als uw apparatuur alleen met sFlow werkt, zoals binnenlandse fabrikanten, kunt u er zelfs in dit geval van profiteren in een veiligheidscontext.
In de zomer van 2019 analyseerde ik de mogelijkheden die Russische fabrikanten van netwerkhardware hebben en ze hebben allemaal, met uitzondering van NSG, Polygon en Craftway, ondersteuning aangekondigd voor sFlow (tenminste Zelax, Natex, Eltex, QTech, Rusteleteh).
De volgende vraag waarmee u te maken krijgt, is waar u flow-ondersteuning voor beveiligingsdoeleinden kunt implementeren? Eigenlijk is de vraag niet helemaal correct gesteld. Moderne apparatuur ondersteunt vrijwel altijd stroomprotocollen. Daarom zou ik de vraag anders formuleren: waar is het vanuit veiligheidsoogpunt het meest effectief om telemetrie te verzamelen? Het antwoord zal heel duidelijk zijn: op toegangsniveau, waar u 100% van al het verkeer zult zien, waar u gedetailleerde informatie over hosts (MAC, VLAN, interface-ID) zult hebben, waar u zelfs P2P-verkeer tussen hosts kunt monitoren, wat is van cruciaal belang voor het scannen, detecteren en verspreiden van kwaadaardige code. Op het kernniveau ziet u misschien een deel van het verkeer niet, maar op het perimeterniveau ziet u een kwart van al uw netwerkverkeer. Maar als u om de een of andere reden buitenlandse apparaten in uw netwerk heeft waarmee aanvallers kunnen "binnenkomen en vertrekken" zonder de perimeter te omzeilen, dan levert het analyseren van de telemetrie daarvan u niets op. Voor maximale dekking wordt daarom aanbevolen om telemetrieverzameling op toegangsniveau in te schakelen. Tegelijkertijd is het vermeldenswaard dat zelfs als we het over virtualisatie of containers hebben, flow-ondersteuning ook vaak wordt aangetroffen in moderne virtuele switches, waardoor je ook daar het verkeer kunt controleren.
Maar nu ik het onderwerp ter sprake heb gebracht, moet ik de vraag beantwoorden: wat als de apparatuur, fysiek of virtueel, geen stroomprotocollen ondersteunt? Of is de opname ervan verboden (bijvoorbeeld in industriële segmenten om de betrouwbaarheid te garanderen)? Of leidt het inschakelen ervan tot een hoge CPU-belasting (dit gebeurt op oudere hardware)? Om dit probleem op te lossen zijn er gespecialiseerde virtuele sensoren (stroomsensoren), die in wezen gewone splitters zijn die verkeer door zichzelf doorgeven en dit in de vorm van stroom naar de verzamelmodule uitzenden. Het is waar dat we in dit geval alle problemen krijgen waar we het hierboven over hadden met betrekking tot tools voor het vastleggen van pakketten. Dat wil zeggen dat u niet alleen de voordelen van de stromingsanalysetechnologie moet begrijpen, maar ook de beperkingen ervan.
Nog een punt dat belangrijk is om te onthouden als we het hebben over stroomanalysetools. Als we met betrekking tot conventionele manieren om beveiligingsgebeurtenissen te genereren de EPS-metriek (gebeurtenis per seconde) gebruiken, dan is deze indicator niet van toepassing op telemetrieanalyse; het wordt vervangen door FPS (flow per seconde). Net als bij EPS kan dit niet vooraf worden berekend, maar kunt u het geschatte aantal threads schatten dat een bepaald apparaat genereert, afhankelijk van zijn taak. U kunt op internet tabellen vinden met geschatte waarden voor verschillende soorten zakelijke apparaten en voorwaarden, waarmee u kunt inschatten welke licenties u nodig heeft voor analysetools en wat hun architectuur zal zijn? Het feit is dat de IDS-sensor wordt beperkt door een bepaalde bandbreedte die hij kan “trekken”, en de stroomcollector heeft zijn eigen beperkingen die moeten worden begrepen. Daarom zijn er in grote, geografisch verspreide netwerken meestal meerdere verzamelaars. Toen ik beschreef (Ik heb het aantal van onze verzamelaars al gegeven - er zijn er 21. En dit is voor een netwerk verspreid over vijf continenten en met ongeveer een half miljoen actieve apparaten).
Wij gebruiken onze eigen oplossing als Netflow monitoringsysteem , dat specifiek gericht is op het oplossen van veiligheidsproblemen. Het heeft veel ingebouwde motoren voor het detecteren van afwijkende, verdachte en duidelijk kwaadaardige activiteiten, waardoor u een breed scala aan verschillende bedreigingen kunt detecteren - van cryptomining tot informatielekken, van de verspreiding van kwaadaardige code tot fraude. Zoals de meeste flowanalyzers is Stealthwatch gebouwd volgens een schema met drie niveaus (generator - collector - analysator), maar wordt het aangevuld met een aantal interessante features die belangrijk zijn in de context van het beschouwde materiaal. Ten eerste kan het worden geïntegreerd met oplossingen voor het vastleggen van pakketten (zoals Cisco Security Packet Analyzer), waarmee u geselecteerde netwerksessies kunt opnemen voor later diepgaand onderzoek en analyse. Ten tweede hebben we, specifiek om de beveiligingstaken uit te breiden, een speciaal nvzFlow-protocol ontwikkeld, waarmee u de activiteit van applicaties op eindknooppunten (servers, werkstations, enz.) kunt "uitzenden" naar telemetrie en deze naar de verzamelaar kunt verzenden voor verdere analyse. Als Stealthwatch in de originele versie werkt met elk stroomprotocol (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) op netwerkniveau, dan maakt nvzFlow-ondersteuning datacorrelatie ook op knooppuntniveau mogelijk. het verhogen van de efficiëntie van het hele systeem en het zien van meer aanvallen dan conventionele netwerkstroomanalysatoren.
Het is duidelijk dat wanneer we het hebben over Netflow-analysesystemen vanuit beveiligingsoogpunt, de markt zich niet beperkt tot één enkele oplossing van Cisco. U kunt zowel commerciële als gratis of shareware-oplossingen gebruiken. Het is nogal vreemd als ik oplossingen van concurrenten als voorbeeld noem op het Cisco-blog, dus ik zal een paar woorden zeggen over hoe netwerktelemetrie kan worden geanalyseerd met behulp van twee populaire, qua naam vergelijkbare, maar nog steeds verschillende tools: SiLK en ELK.
SiLK is een set tools (het System for Internet-Level Knowledge) voor verkeersanalyse, ontwikkeld door het Amerikaanse CERT/CC en die, in de context van het artikel van vandaag, Netflow (5e en 9e, de meest populaire versies), IPFIX ondersteunt en sFlow en het gebruik van verschillende hulpprogramma's (rwfilter, rwcount, rwflowpack, enz.) om verschillende bewerkingen op netwerktelemetrie uit te voeren om tekenen van ongeautoriseerde acties daarin te detecteren. Maar er zijn een paar belangrijke punten om op te merken. SiLK is een opdrachtregelprogramma dat online analyses uitvoert door opdrachten als deze in te voeren (detectie van ICMP-pakketten groter dan 200 bytes):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
niet erg comfortabel. U kunt de iSiLK GUI gebruiken, maar het zal uw leven niet veel eenvoudiger maken, omdat u alleen de visualisatiefunctie oplost en de analist niet vervangt. En dit is het tweede punt. In tegenstelling tot commerciële oplossingen, die al over een solide analytische basis, algoritmen voor het detecteren van afwijkingen, een bijbehorende workflow enz. beschikken, zult u dit in het geval van SiLK allemaal zelf moeten doen, wat iets andere competenties van u zal vereisen dan bij het gebruik van reeds kant-en-klare oplossingen. hulpmiddelen te gebruiken. Dit is niet goed of slecht - dit is een kenmerk van bijna elke gratis tool die ervan uitgaat dat je weet wat je moet doen, en het zal je alleen hierbij helpen (commerciële tools zijn minder afhankelijk van de competenties van de gebruikers, hoewel ze er ook van uitgaan dat analisten op zijn minst de basisprincipes van netwerkonderzoek en -monitoring begrijpen). Maar laten we terugkeren naar SiLK. De werkcyclus van de analist ziet er als volgt uit:
- Het formuleren van een hypothese. We moeten begrijpen waar we naar op zoek zullen zijn binnen netwerktelemetrie, en de unieke kenmerken kennen waarmee we bepaalde afwijkingen of bedreigingen kunnen identificeren.
- Een model bouwen. Nadat we een hypothese hebben geformuleerd, programmeren we deze met dezelfde Python, shell of andere tools die niet in SiLK zijn opgenomen.
- Testen. Nu komt de beurt om de juistheid van onze hypothese te controleren, die wordt bevestigd of weerlegd met behulp van SiLK-hulpprogramma's die beginnen met 'rw', 'set', 'bag'.
- Analyse van echte gegevens. Bij industrieel gebruik helpt SiLK ons iets te identificeren en de analist moet de vragen beantwoorden: “Hebben we gevonden wat we verwachtten?”, “Komt dit overeen met onze hypothese?”, “Hoe kunnen we het aantal valse positieven verminderen?”, “Hoe om het herkenningsniveau te verbeteren? » enzovoort.
- Verbetering. In de laatste fase verbeteren we wat eerder is gedaan: we maken sjablonen, verbeteren en optimaliseren de code, herformuleren en verduidelijken de hypothese, enz.
Deze cyclus zal ook van toepassing zijn op Cisco Stealthwatch, alleen de laatste automatiseert deze vijf stappen maximaal, waardoor het aantal analistenfouten afneemt en de efficiëntie van incidentdetectie toeneemt. Zo kun je in SiLK met handgeschreven scripts netwerkstatistieken verrijken met externe data over kwaadaardige IP’s, en in Cisco Stealthwatch is het een ingebouwde functie die direct alarm geeft als netwerkverkeer interacties bevat met IP-adressen uit de zwarte lijst.
Als je hoger gaat in de “betaalde” piramide voor software voor stroomanalyse, dan zal er na de absoluut gratis SiLK een shareware ELK zijn, bestaande uit drie belangrijke componenten: Elasticsearch (indexeren, zoeken en data-analyse), Logstash (gegevensinvoer/uitvoer ) en Kibana (visualisatie). In tegenstelling tot SiLK, waar je alles zelf moet schrijven, beschikt ELK al over veel kant-en-klare bibliotheken/modules (sommige betaald, andere niet) die de analyse van netwerktelemetrie automatiseren. Met het GeoIP-filter in Logstash kunt u bijvoorbeeld bewaakte IP-adressen koppelen aan hun geografische locatie (Stealthwatch heeft deze ingebouwde functie).
ELK heeft ook een vrij grote community die de ontbrekende componenten voor deze monitoringoplossing aanvult. Om bijvoorbeeld met Netflow, IPFIX en sFlow te werken kun je de module gebruiken , als u niet tevreden bent met de Logstash Netflow-module, die alleen Netflow ondersteunt.
Hoewel ELK meer efficiëntie biedt bij het verzamelen van stroom en het zoeken daarin, ontbeert het momenteel uitgebreide ingebouwde analyses voor het detecteren van afwijkingen en bedreigingen in netwerktelemetrie. Dat wil zeggen dat je, volgens de hierboven beschreven levenscyclus, zelfstandig overtredingsmodellen moet beschrijven en deze vervolgens in het gevechtssysteem moet gebruiken (er zijn daar geen ingebouwde modellen).
Er zijn natuurlijk meer geavanceerde uitbreidingen voor ELK, die al enkele modellen bevatten voor het detecteren van afwijkingen in netwerktelemetrie, maar dergelijke uitbreidingen kosten geld en hier is de vraag of het spel de kaars waard is - schrijf zelf een soortgelijk model, koop het implementatie voor uw monitoringtool, of koop een kant-en-klare oplossing uit de klasse Network Traffic Analysis.
Over het algemeen wil ik niet in de discussie stappen dat het beter is om geld uit te geven en een kant-en-klare oplossing te kopen voor het monitoren van afwijkingen en bedreigingen in netwerktelemetrie (bijvoorbeeld Cisco Stealthwatch) of om het zelf uit te zoeken en hetzelfde aan te passen SiLK, ELK of nfdump of OSU Flow Tools voor elke nieuwe bedreiging (ik heb het over de laatste twee laatste keer)? Iedereen kiest voor zichzelf en iedereen heeft zijn eigen motieven om voor een van de twee opties te kiezen. Ik wilde alleen maar laten zien dat netwerktelemetrie een zeer belangrijk hulpmiddel is bij het waarborgen van de netwerkbeveiliging van uw interne infrastructuur en dat u dit niet mag verwaarlozen, om niet op de lijst te komen van bedrijven waarvan de naam samen met de scheldwoorden in de media wordt genoemd. gehackt”, “niet in overeenstemming met informatiebeveiligingseisen” “, “niet nadenken over de veiligheid van hun gegevens en klantgegevens.”
Samenvattend zou ik de belangrijkste tips willen opsommen die u moet volgen bij het opzetten van informatiebeveiligingsmonitoring van uw interne infrastructuur:
- Beperk jezelf niet alleen tot de perimeter! Gebruik (en kies) de netwerkinfrastructuur niet alleen om verkeer van punt A naar punt B te verplaatsen, maar ook om cyberbeveiligingsproblemen aan te pakken.
- Bestudeer de bestaande mechanismen voor het monitoren van informatiebeveiliging in uw netwerkapparatuur en gebruik deze.
- Geef voor interne monitoring de voorkeur aan telemetrieanalyse. Hiermee kunt u tot 80-90% van alle netwerkinformatiebeveiligingsincidenten detecteren, terwijl u doet wat onmogelijk is bij het vastleggen van netwerkpakketten en ruimte bespaart voor het opslaan van alle informatiebeveiligingsgebeurtenissen.
- Om stromen te monitoren, gebruikt u Netflow v9 of IPFIX - deze bieden meer informatie in een beveiligingscontext en stellen u in staat niet alleen IPv4 te monitoren, maar ook IPv6, MPLS, enz.
- Gebruik een onbemonsterd stroomprotocol: dit biedt meer informatie voor het detecteren van bedreigingen. Bijvoorbeeld Netflow of IPFIX.
- Controleer de belasting van uw netwerkapparatuur; deze kan mogelijk ook niet overweg met het flowprotocol. Overweeg dan de inzet van virtuele sensoren of Netflow Generation Appliance.
- Implementeer de controle allereerst op toegangsniveau - dit geeft u de mogelijkheid om 100% van al het verkeer te zien.
- Als u geen keus heeft en Russische netwerkapparatuur gebruikt, kies er dan een die flowprotocollen ondersteunt of over SPAN/RSPAN-poorten beschikt.
- Combineer inbraak-/aanvalsdetectie-/preventiesystemen aan de randen en stroomanalysesystemen in het interne netwerk (ook in de clouds).
Wat betreft de laatste tip wil ik een illustratie geven die ik al eerder heb gegeven. Je ziet dat waar de informatiebeveiligingsdienst van Cisco voorheen zijn monitoringsysteem voor informatiebeveiliging vrijwel geheel op basis van inbraakdetectiesystemen en handtekeningmethoden bouwde, deze nu slechts 20% van de incidenten voor hun rekening nemen. Nog eens 20% valt onder stroomanalysesystemen, wat suggereert dat deze oplossingen geen bevlieging zijn, maar een echt hulpmiddel in de activiteiten van informatiebeveiligingsdiensten van een moderne onderneming. Bovendien beschikt u over het allerbelangrijkste voor de implementatie ervan: de netwerkinfrastructuur, waarvan de investeringen verder kunnen worden beschermd door functies voor het monitoren van informatiebeveiliging aan het netwerk toe te wijzen.
Ik heb specifiek niet ingegaan op het onderwerp van het reageren op afwijkingen of bedreigingen die in netwerkstromen zijn geïdentificeerd, maar ik denk dat het al duidelijk is dat monitoring niet alleen mag eindigen bij de detectie van een bedreiging. Het moet worden gevolgd door een reactie en bij voorkeur in een automatische of geautomatiseerde modus. Maar dit is een onderwerp voor een apart artikel.
Extra Informatie:
PS. Als u alles wat hierboven is geschreven gemakkelijker kunt horen, kunt u de presentatie van een uur bekijken die de basis vormde van deze notitie.
Bron: www.habr.com