Wenn es um die Überwachung der Sicherheit eines internen Unternehmens- oder Abteilungsnetzwerks geht, stehen viele im Zusammenhang mit der Kontrolle von Informationslecks und der Implementierung von DLP-Lösungen. Wenn Sie versuchen, die Frage zu klären und zu fragen, wie Sie Angriffe auf das interne Netzwerk erkennen, lautet die Antwort in der Regel die Erwähnung von Intrusion Detection-Systemen (IDS). Und was vor 10 bis 20 Jahren die einzige Option war, wird heute zum Anachronismus. Es gibt eine effektivere und an einigen Stellen einzig mögliche Option zur Überwachung des internen Netzwerks - die Verwendung von Flussprotokollen, die ursprünglich zur Suche nach Netzwerkproblemen entwickelt wurden (Fehlerbehebung), aber schließlich in ein sehr interessantes Sicherheitstool umgewandelt wurden. Wir werden darüber sprechen, was Flussprotokolle sind und welche besser dazu beitragen, Netzwerkangriffe zu erkennen, wo die Flussüberwachung am besten implementiert werden kann, worauf bei der Bereitstellung eines solchen Schemas zu achten ist und sogar wie es auf Haushaltsgeräten „aufgegriffen“ werden kann als Teil dieses Artikels.
Ich werde nicht auf die Frage eingehen: "Warum müssen wir die Sicherheit der internen Infrastruktur überwachen?" Die Antwort scheint klar zu sein. Wenn Sie dennoch noch einmal sicherstellen möchten, dass es nirgendwo ohne sie gibt,
sehen Sie sich ein kurzes Video mit einer Geschichte an, wie Sie auf 17 Arten in das durch eine Firewall geschützte Unternehmensnetzwerk gelangen können. Wir gehen daher davon aus, dass wir verstehen, dass interne Überwachung eine notwendige Sache ist, und es bleibt nur zu verstehen, wie sie organisiert werden kann.
Ich würde drei wichtige Datenquellen für die Überwachung der Infrastruktur auf Netzwerkebene herausgreifen:
- "Roher" Verkehr, den wir erfassen und zur Analyse an bestimmte Analysesysteme senden,
- Ereignisse von Netzwerkgeräten, über die der Datenverkehr geleitet wird,
- Verkehrsinformationen, die unter Verwendung eines der Flussprotokolle empfangen wurden.
Das Erfassen von unformatiertem Datenverkehr ist die beliebteste Option unter Sicherheitspersonal, da es historisch gesehen die allererste war. Herkömmliche netzwerkbasierte Angriffserkennungssysteme (das allererste kommerzielle Angriffserkennungssystem war WheelRs NetRanger, das 1998 von Cisco gekauft wurde) befassten sich ausschließlich mit der Erfassung von Paketen (und späteren Sitzungen), die nach bestimmten Signaturen suchten („entscheidende Regeln“). in der FSTEC-Terminologie), signalisiert Angriffe. Natürlich können Sie den Rohdatenverkehr nicht nur mit IDS analysieren, sondern auch mit anderen Tools (z. B. Wireshark-, tcpdum- oder NBAR2-Funktionen in Cisco IOS). In der Regel fehlt ihnen jedoch eine Wissensdatenbank, die ein Informationssicherheitstool von einem normalen IT-Tool unterscheidet.
Also Angriffserkennungssysteme. Die älteste und beliebteste Methode zur Erkennung von Netzwerkangriffen, die ihre Aufgabe am Perimeter (egal was - Unternehmen, Rechenzentrum, Segment usw.) gut bewältigt, aber in modernen Switched- und Software-definierten Netzwerken eingesetzt wird. Bei einem Netzwerk, das auf herkömmlichen Switches basiert, wird die Infrastruktur der Angriffserkennungssensoren zu groß. Sie müssen bei jeder Verbindung mit dem Host, dessen Angriffe Sie überwachen möchten, einen Sensor installieren. Natürlich wird jeder Hersteller Ihnen gerne Hunderte und Tausende von Sensoren verkaufen, aber ich denke, Ihr Budget kann solchen Kosten nicht standhalten. Ich kann sagen, dass wir dies selbst bei Cisco (und wir sind die Entwickler von NGIPS) nicht konnten, obwohl es den Anschein hat, dass das Preisproblem vor uns liegt. sollte nicht stehen - das ist unsere eigene Entscheidung. Außerdem stellt sich die Frage, wie der Sensor in dieser Ausführungsform angeschlossen werden soll. Zur Lücke? Und wenn der Sensor selbst deaktiviert ist? Benötigen Sie ein Bypass-Modul im Sensor? Tap Splitter verwenden? All dies verteuert die Lösung und macht sie für ein Unternehmen jeder Größenordnung unerträglich.
Sie können versuchen, den Sensor am SPAN / RSPAN / ERSPAN-Port aufzuhängen und den Datenverkehr von den erforderlichen Ports am Switch zu ihm zu leiten. Diese Option behebt das im vorherigen Absatz beschriebene Problem teilweise, stellt jedoch ein anderes Problem dar. Der SPAN-Port kann nicht den gesamten an ihn gesendeten Datenverkehr akzeptieren. Er verfügt nicht über genügend Bandbreite. Kuschel dich an etwas, um es zu opfern. Lassen Sie entweder einen Teil der Knoten ohne Überwachung (dann müssen Sie sie zuerst priorisieren) oder leiten Sie nicht den gesamten Datenverkehr vom Knoten, sondern nur einen bestimmten Typ. In jedem Fall können wir einige Angriffe überspringen. Darüber hinaus kann der SPAN-Port für andere Anforderungen belegt werden. Infolgedessen müssen wir die vorhandene Netzwerktopologie überarbeiten und möglicherweise Anpassungen vornehmen, um Ihr Netzwerk mit der Anzahl der vorhandenen Sensoren maximal abzudecken (und dies mit der IT zu koordinieren).
Und wenn Ihr Netzwerk asymmetrische Routen verwendet? Und wenn Sie SDN implementiert haben oder einführen möchten? Und wenn Sie virtualisierte Maschinen oder Container überwachen müssen, deren Datenverkehr den physischen Switch überhaupt nicht erreicht? Hersteller traditioneller IDS mögen diese Fragen nicht, weil sie nicht wissen, wie sie zu beantworten sind. Vielleicht neigen sie Sie dazu, dass all diese modischen Technologien ein Hype sind und Sie sie nicht brauchen. Vielleicht werden sie über die Notwendigkeit sprechen, klein anzufangen. Oder vielleicht sagen sie, dass Sie eine leistungsstarke Dreschmaschine in die Mitte des Netzwerks stellen und den gesamten Datenverkehr mithilfe von Balancern dorthin leiten müssen. Unabhängig davon, welche Option Ihnen angeboten wird, müssen Sie selbst klar verstehen, wie gut sie zu Ihnen passt. Und erst danach entscheiden Sie sich für einen Ansatz zur Überwachung der Informationssicherheit der Netzwerkinfrastruktur. Zurück zur Paketerfassung, ich möchte sagen, dass diese Methode weiterhin sehr beliebt und wichtig ist, aber ihr Hauptzweck ist die Grenzkontrolle. die Grenzen zwischen Ihrer Organisation und dem Internet, die Grenzen zwischen dem Rechenzentrum und dem Rest des Netzwerks, die Grenzen zwischen dem ICS und dem Unternehmenssegment. An diesen Orten haben klassische IDS / IPS immer noch das Recht zu existieren und ihre Aufgaben gut zu erledigen.
Fahren wir mit der zweiten Option fort. Eine Analyse von Ereignissen von Netzwerkgeräten kann auch zum Erkennen von Angriffen verwendet werden, jedoch nicht als Hauptmechanismus, da Sie nur eine kleine Klasse von Eingriffen erkennen können. Darüber hinaus ist eine gewisse Reaktivität damit verbunden - ein Angriff muss zuerst erfolgen, dann muss er von einem Netzwerkgerät behoben werden, was auf die eine oder andere Weise auf ein Problem mit der Informationssicherheit hinweist. Es gibt verschiedene Möglichkeiten. Dies kann Syslog, RMON oder SNMP sein. Die letzten beiden Protokolle zur Netzwerküberwachung im Kontext der Informationssicherheit werden nur verwendet, wenn ein DoS-Angriff auf das Netzwerkgerät selbst erkannt werden muss, da wir beispielsweise mit RMON und SNMP die Last des Zentralprozessors des Geräts oder seiner Schnittstellen überwachen können. Dies ist eine der „billigsten“ (jeder hat Syslog oder SNMP), aber auch die ineffektivste aller Möglichkeiten, die Informationssicherheit der internen Infrastruktur zu überwachen - viele Angriffe sind einfach davor verborgen. Natürlich sollten sie nicht vernachlässigt werden, und dieselbe Syslog-Analyse hilft Ihnen dabei, Änderungen in der Konfiguration des Geräts rechtzeitig zu erkennen. Dies ist ein Kompromiss, aber nicht sehr gut geeignet, um Angriffe auf das gesamte Netzwerk zu erkennen.
Die dritte Option besteht darin, Informationen über den Datenverkehr zu analysieren, der durch ein Gerät geleitet wird, das eines von mehreren Ablaufprotokollen unterstützt. In diesem Fall besteht die Flussinfrastruktur unabhängig vom Protokoll notwendigerweise aus drei Komponenten:
- Flow generieren oder exportieren. Diese Rolle wird normalerweise einem Router, Switch oder einem anderen Netzwerkgerät zugewiesen, mit dem Sie durch Weiterleiten des Netzwerkverkehrs wichtige Parameter daraus extrahieren können, die dann an das Erfassungsmodul übertragen werden. Beispielsweise wird das Cisco Netflow-Protokoll nicht nur auf Routern und Switches unterstützt, einschließlich virtueller und industrieller, sondern auch auf drahtlosen Controllern, Firewalls und sogar Servern.
- Sammlungsfluss. Angesichts der Tatsache, dass in einem modernen Netzwerk normalerweise mehr als ein Netzwerkgerät vorhanden ist, besteht das Problem des Sammelns und Konsolidierens von Flüssen, das mithilfe der sogenannten Kollektoren gelöst wird, die die empfangenen Flüsse verarbeiten und dann zur Analyse übertragen.
- Durchflussanalyse. Der Analysator übernimmt die intellektuelle Hauptaufgabe und zieht unter Anwendung verschiedener Algorithmen auf die Flüsse bestimmte Schlussfolgerungen. Beispielsweise kann ein solcher Analysator als Teil der IT-Funktion Netzwerktengpässe identifizieren oder das Verkehrslastprofil analysieren, um das Netzwerk weiter zu optimieren. Aus Gründen der Informationssicherheit kann ein solcher Analysator Datenlecks, die Verbreitung von Schadcode oder DoS-Angriffe erkennen.
Sie sollten nicht denken, dass eine solche dreistufige Architektur zu kompliziert ist - alle anderen Optionen (außer vielleicht Netzwerküberwachungssystemen, die mit SNMP und RMON arbeiten) funktionieren ebenfalls entsprechend. Wir haben einen Datengenerator zur Analyse, bei dem es sich um ein Netzwerkgerät oder einen freistehenden Sensor handelt. Wir haben ein Alarmsammelsystem und ein Managementsystem für die gesamte Überwachungsinfrastruktur. Die letzten beiden Komponenten können innerhalb eines einzelnen Knotens kombiniert werden. In mehr oder weniger großen Netzwerken werden sie jedoch normalerweise durch mindestens zwei Geräte getrennt, um Skalierbarkeit und Zuverlässigkeit sicherzustellen.
Im Gegensatz zur Paketanalyse basiert die Flussanalyse auf der Erfassung von Metadaten zum Netzwerkverkehr, basierend auf der Untersuchung des Headers und des Datenkörpers jedes Pakets und der daraus bestehenden Sitzungen. Wann, wie viel, wo und wo, wie ... das sind die Fragen, die durch die Analyse der Netzwerktelemetrie unter Verwendung verschiedener Flussprotokolle beantwortet werden. Ursprünglich wurden sie zur Analyse von Statistiken und zur Suche nach IT-Problemen im Netzwerk verwendet. Mit der Entwicklung von Analysemechanismen wurde es jedoch möglich, sie auf dieselbe Telemetrie und aus Sicherheitsgründen anzuwenden. Es ist hier noch einmal erwähnenswert, dass die Stream-Analyse die Paketerfassung nicht ersetzt oder abbricht. Jede dieser Methoden hat ihren eigenen Anwendungsbereich. Im Kontext dieses Artikels eignet sich jedoch die Flussanalyse am besten zur Überwachung der internen Infrastruktur. Sie haben Netzwerkgeräte (und es spielt keine Rolle, ob sie in einem softwaredefinierten Paradigma oder nach statischen Regeln funktionieren), die der Angriff nicht passieren kann. Es kann den klassischen IDS-Sensor umgehen, es gibt jedoch kein Netzwerkgerät, das das Flussprotokoll unterstützt. Dies ist der Vorteil dieser Methode.
Wenn Sie jedoch Beweise für die Strafverfolgung oder Ihr eigenes Untersuchungsteam für Vorfälle benötigen, können Sie nicht auf die Paketerfassung verzichten. Die Netzwerktelemetrie ist keine Kopie des Datenverkehrs, mit dem Beweise gesammelt werden können. Es wird für die betriebliche Erkennung und Entscheidungsfindung im Bereich der Informationssicherheit benötigt. Andererseits können Sie mithilfe der Telemetrieanalyse nicht den gesamten Netzwerkverkehr „schreiben“ (wenn überhaupt, dann ist Cisco an Rechenzentren beteiligt :-), sondern nur an dem, der an dem Angriff beteiligt ist. Telemetrieanalysewerkzeuge in dieser Hinsicht werden die traditionellen Paketerfassungsmechanismen gut ergänzen und den Befehl zur selektiven Erfassung und Speicherung geben. Andernfalls müssen Sie über eine kolossale Speicherinfrastruktur verfügen.
Stellen Sie sich ein Netzwerk vor, das mit einer Geschwindigkeit von 250 Mbit / s arbeitet. Wenn Sie dieses gesamte Volume speichern möchten, benötigen Sie 31 MB Speicher für eine Sekunde der Datenübertragung, 1,8 GB für eine Minute, 108 GB für eine Stunde und 2,6 TB für einen Tag. Um tägliche Daten aus einem Netzwerk mit einer Bandbreite von 10 Gbit / s zu speichern, benötigen Sie 108 TB Speicher. Bei einigen Regulierungsbehörden müssen Sie jedoch jahrelang Sicherheitsdaten speichern. Durch die Aufzeichnung von „on demand“, mit deren Hilfe Sie die Durchflussanalyse implementieren können, können diese Werte um Größenordnungen reduziert werden. Übrigens, wenn wir über das Verhältnis der aufgezeichneten Daten der Netzwerktelemetrie zur gesamten Datenerfassung sprechen, dann sind es ungefähr 1 bis 500. Bei den gleichen Werten oben beträgt der Speicher für die vollständige Entschlüsselung des gesamten täglichen Datenverkehrs 5 bzw. 216 GB (Sie können sogar auf ein normales USB-Flash-Laufwerk schreiben )
Wenn die Tools zur Analyse von Rohnetzdaten über eine Methode zur Erfassung verfügen, die fast mit der des Anbieters für den Anbieter identisch ist, ist die Situation bei der Analyse von Flows anders. Es gibt verschiedene Optionen für Ablaufprotokolle, die Unterschiede, die Sie im Sicherheitskontext kennen müssen. Am beliebtesten ist das von Cisco entwickelte Netflow-Protokoll. Es gibt verschiedene Versionen dieses Protokolls, die sich in ihren Funktionen und der Menge der über den Datenverkehr aufgezeichneten Informationen unterscheiden. Die aktuelle Version ist die neunte (Netflow v9), auf deren Grundlage der Industriestandard Netflow v10, auch als IPFIX bekannt, entwickelt wurde. Heutzutage unterstützen die meisten Netzwerkanbieter genau Netflow oder IPFIX in ihren Geräten. Es gibt jedoch verschiedene andere Optionen für Flussprotokolle - sFlow, jFlow, cFlow, rFlow, NetStream usw., von denen sFlow beliebter ist. Er wird aufgrund der einfachen Implementierung am häufigsten von einheimischen Herstellern von Netzwerkgeräten unterstützt. Was sind die Hauptunterschiede zwischen Netflow als De-facto-Standard und sFlow? Ich würde ein paar Schlüssel herausgreifen. Erstens verfügt Netflow über benutzerdefinierte Felder im Gegensatz zu festen Feldern in sFlow. Und zweitens, und dies ist in unserem Fall das Wichtigste, sammelt sFlow die sogenannte abgetastete Telemetrie. im Gegensatz zu nicht abgetasteten in Netflow und IPFIX. Was ist der Unterschied zwischen ihnen?
Stellen Sie sich vor, Sie haben beschlossen, das Buch „
Security Operations Center: Aufbau, Betrieb und Wartung Ihres SOC “ von meinen Kollegen Gary MacIntyre, Joseph Muniz und Nadef Alfardan zu lesen (Sie können einen Teil des Buches über den Link herunterladen). Sie haben drei Möglichkeiten, um Ihr Ziel zu erreichen: Lesen Sie das gesamte Buch, lesen Sie es durch die Augen, halten Sie bei jeder 10. oder 20. Seite an oder versuchen Sie, wichtige Konzepte in einem Blog oder Dienst wie SmartReading nacherzählen zu können. Die nicht abgetastete Telemetrie liest also jede „Seite“ des Netzwerkverkehrs, dh analysiert Metadaten für jedes Paket. Die Sampling-Telemetrie ist eine selektive Untersuchung des Verkehrs in der Hoffnung, dass die ausgewählten Samples das haben, was Sie benötigen. Abhängig von der Geschwindigkeit des Kanals sendet die abgetastete Telemetrie jedes 64., 200., 500., 1000., 2000. oder sogar 10000. Paket zur Analyse.
Im Zusammenhang mit der Überwachung der Informationssicherheit bedeutet dies, dass die abgetastete Telemetrie gut zum Erkennen von DDoS-Angriffen, zum Scannen und zum Verbreiten von Schadcode geeignet ist. Sie kann jedoch Atom- oder Mehrpaketangriffe überspringen, die nicht in die zur Analyse gesendete Stichprobe fallen. Die nicht abgetastete Telemetrie weist solche Mängel nicht auf. Die Reichweite der erkennbaren Angriffe ist viel größer. Hier ist eine kurze Liste von Ereignissen, die mithilfe von Analysetools für die Netzwerktelemetrie erkannt werden können.
Natürlich können Sie dies bei einigen Open-Source-Netflow-Analysegeräten nicht tun, da die Hauptaufgabe darin besteht, Telemetrie zu sammeln und aus IT-Sicht grundlegende Analysen durchzuführen. Um Bedrohungen der Informationssicherheit basierend auf dem Datenfluss zu identifizieren, muss der Analysator mit verschiedenen Engines und Algorithmen ausgestattet werden, die Cybersicherheitsprobleme auf der Grundlage von Standard- oder benutzerdefinierten Netflow-Feldern identifizieren, Standarddaten mit externen Daten aus verschiedenen Quellen von Threat Intelligence anreichern usw.
Wenn Sie eine Auswahl haben, beenden Sie sie daher unter Netflow oder IPFIX. Aber selbst wenn Ihre Geräte wie inländische Hersteller nur mit sFlow funktionieren, können Sie auch in diesem Fall im Sicherheitskontext davon profitieren.
Im Sommer 2019 analysierte ich die Möglichkeiten, die russische Hersteller von vernetzter Hardware haben, und alle, mit Ausnahme von NSG, Polygon und Craftway, erklärten ihre Unterstützung für sFlow (zumindest Zelax, Natex, Eltex, QTech, Rusteletech).
Die nächste Frage, der Sie sich stellen müssen, ist, wo Sie die Flow-Unterstützung aus Sicherheitsgründen implementieren können. In der Tat ist die Frage nicht ganz richtig. Bei modernen Geräten ist die Unterstützung von Flussprotokollen fast immer vorhanden. Daher würde ich die Frage anders formulieren - wo ist der sicherste Weg, Telemetrie unter Sicherheitsgesichtspunkten zu sammeln? Die Antwort liegt auf der Hand - auf der Zugriffsebene, wo Sie 100% des gesamten Datenverkehrs sehen, wo Sie detaillierte Informationen zu Hosts (MAC, VLAN, Schnittstellen-ID) haben, wo Sie sogar den P2P-Datenverkehr zwischen Hosts verfolgen können, was für die Erkennung von Scans von entscheidender Bedeutung ist und und die Verbreitung von Schadcode. Auf der Kernel-Ebene sehen Sie möglicherweise keinen Teil des Datenverkehrs, aber auf der Perimeter-Ebene sehen Sie gut, ob ein Viertel des gesamten Netzwerkverkehrs vorhanden ist. Wenn jedoch aus irgendeinem Grund fremde Geräte in Ihrem Netzwerk aufgelöst werden, die es Angreifern ermöglichen, unter Umgehung des Perimeters ein- und auszusteigen, führt die Analyse der Telemetrie nichts dazu. Für eine maximale Abdeckung wird daher empfohlen, die Telemetriesammlung auf der Zugriffsebene einzuschließen. Gleichzeitig ist anzumerken, dass in modernen virtuellen Switches häufig auch Flussunterstützung vorhanden ist, mit der Sie den Datenverkehr dort steuern können, selbst wenn es sich um Virtualisierung oder Container handelt.
Aber seit ich das Thema angesprochen habe, muss ich die Frage beantworten, aber was ist, wenn physische oder virtuelle Geräte keine Flow-Protokolle unterstützen? Oder ist seine Aufnahme verboten (zum Beispiel in Industriesegmenten, um Zuverlässigkeit zu gewährleisten)? Oder führt seine Einbeziehung zu einer hohen CPU-Auslastung (dies geschieht bei veralteten Geräten)? Um dieses Problem zu lösen, gibt es spezielle virtuelle Sensoren (Durchflusssensor), bei denen es sich im Wesentlichen um gewöhnliche Splitter handelt, die den Verkehr durch sich selbst leiten und ihn in Form eines Durchflusses an das Sammelmodul übertragen. In diesem Fall treten zwar eine ganze Reihe von Problemen auf, über die wir oben in Bezug auf Paketerfassungstools gesprochen haben. Das heißt, Sie müssen nicht nur die Vorteile der Durchflussanalysetechnologie verstehen, sondern auch deren Grenzen.
Ein weiterer wichtiger Punkt, an den Sie denken sollten, wenn Sie über Tools zur Durchflussanalyse sprechen. Wenn wir die EPS-Metrik (Ereignis pro Sekunde, Ereignisse pro Sekunde) auf herkömmliche Mittel zur Erzeugung von Sicherheitsereignissen anwenden, gilt dieser Indikator nicht für die Telemetrieanalyse. Es wird durch FPS (Durchfluss pro Sekunde) ersetzt. Wie im Fall von EPS kann es nicht im Voraus berechnet werden, aber Sie können die ungefähre Anzahl von Flüssen schätzen, die ein bestimmtes Gerät abhängig von seiner Aufgabe generiert. Im Internet finden Sie Tabellen mit ungefähren Werten für verschiedene Arten von Unternehmensgeräten und -bedingungen, anhand derer Sie herausfinden können, welche Lizenzen Sie für Analysetools benötigen und wie ihre Architektur aussehen wird. Tatsache ist, dass der IDS-Sensor durch eine bestimmte Bandbreite begrenzt ist, die er "zieht", und der Flusskollektor seine eigenen Einschränkungen hat, die verstanden werden müssen. Daher gibt es in großen, geografisch verteilten Netzen normalerweise mehrere Stauseen. Als ich beschrieb,
wie das Netzwerk in Cisco überwacht wird , habe ich bereits die Anzahl unserer Kollektoren angegeben - es gibt 21. Und dies ist ein Netzwerk, das über fünf Kontinente verteilt ist und etwa eine halbe Million aktive Geräte zählt.
Als Netflow-Überwachungssystem verwenden wir unsere eigene
Cisco Stealthwatch-Lösung , die speziell auf die Lösung von Sicherheitsproblemen ausgerichtet ist. Es verfügt über viele integrierte Engines zum Erkennen abnormaler, verdächtiger und offensichtlich böswilliger Aktivitäten, mit denen eine Vielzahl verschiedener Bedrohungen erkannt werden können - vom Crypto Mining bis hin zu Informationslecks, von der Verbreitung von Schadcode bis hin zu Betrug. Wie die meisten Durchflussanalysatoren ist Stealthwatch nach einem dreistufigen Schema (Generator - Kollektor - Analysator) aufgebaut, wird jedoch durch eine Reihe interessanter Merkmale ergänzt, die im Zusammenhang mit dem betrachteten Material wichtig sind. Erstens lässt es sich in Paketerfassungslösungen (wie Cisco Security Packet Analyzer) integrieren, mit denen Sie ausgewählte Netzwerksitzungen für weitere eingehende Untersuchungen und Analysen aufzeichnen können. Zweitens haben wir speziell für die Erweiterung von Sicherheitsaufgaben ein spezielles Protokoll nvzFlow entwickelt, mit dem Sie die Aktivität von Anwendungen auf Endknoten (Servern, Workstations usw.) in Telemetrie "übersetzen" und zur weiteren Analyse an den Kollektor übertragen können. Wenn Stealthwatch in seiner Originalversion mit jedem Flow-Protokoll (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) auf Netzwerkebene funktioniert, können Daten auf nvzFlow-Unterstützung auch auf Host-Ebene korreliert werden. Steigerung der Effizienz des gesamten Systems und mehr Angriffe als bei herkömmlichen Netzwerkflussanalysatoren.
Es ist klar, dass der Markt für Netflow-Systeme zur Sicherheitsanalyse nicht auf eine einzige Lösung von Cisco beschränkt ist. Sie können sowohl kommerzielle als auch Freeware- oder Shareware-Lösungen verwenden. Wenn ich den Cisco-Blog als Beispiel für die Lösungen von Wettbewerbern verwende, sage ich seltsamerweise ein paar Worte darüber, wie die Netzwerktelemetrie mit zwei gängigen, namenähnlichen, aber immer noch unterschiedlichen Tools analysiert werden kann - SiLK und ELK.
SiLK ist eine Reihe von Tools (das System für Wissen auf Internetebene) für die Verkehrsanalyse, die vom amerikanischen CERT / CC entwickelt wurden und im Kontext des heutigen Artikels Netflow (5. und 9., die beliebtesten Versionen), IPFIX und sFlow unterstützen und Verwenden verschiedener Dienstprogramme (rwfilter, rwcount, rwflowpack usw.), um verschiedene Operationen an der Netzwerktelemetrie durchzuführen, um Anzeichen von nicht autorisierten Aktionen darin zu erkennen. Es gibt jedoch einige wichtige Punkte zu beachten. SiLK ist ein Befehlszeilentool und führt bei jeder Eingabe eines Befehls des Formulars (Erkennung von ICMP-Paketen mit mehr als 200 Byte) eine Betriebsanalyse durch:
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15nicht sehr bequem. Sie können die iSiLK-GUI verwenden, aber es wird Ihr Leben nicht viel einfacher machen, wenn Sie nur die Visualisierungsfunktion lösen, nicht den Ersatz des Analytikers. Und das ist der zweite Punkt. Im Gegensatz zu kommerziellen Lösungen, die bereits über eine solide analytische Basis, Anomalieerkennungsalgorithmen, Workflow-bezogene Algorithmen usw. verfügen, müssen Sie bei SiLK all dies selbst tun, was erfordert, dass Sie etwas andere Kompetenzen verwenden als bereits gebrauchsfertige Werkzeuge. Dies ist schlecht und nicht schlecht - dies ist eine Funktion fast aller kostenlosen Tools, die sich aus der Tatsache ergibt, dass Sie wissen, was zu tun ist, und es hilft Ihnen nur dabei (kommerzielle Tools sind weniger abhängig von den Kompetenzen ihrer Benutzer, obwohl davon ausgegangen wird, dass Analysten zumindest verstehen Grundlagen der Netzwerkuntersuchung und -überwachung). Aber zurück zu SiLK. Der Arbeitszyklus des Analytikers mit ihm ist wie folgt:
- Formulierung einer Hypothese. Wir müssen verstehen, wonach wir in der Netzwerktelemetrie suchen, um die eindeutigen Attribute zu kennen, anhand derer wir bestimmte Anomalien oder Bedrohungen identifizieren können.
- Ein Modell bauen. Nachdem wir eine Hypothese formuliert haben, programmieren wir sie mit demselben Python, derselben Shell oder anderen Tools, die nicht in SiLK enthalten sind.
- Testen. Es ist an der Zeit, die Gültigkeit unserer Hypothese zu testen, die mit den SiLK-Dienstprogrammen bestätigt oder widerlegt wird, beginnend mit 'rw', 'set', 'bag'.
- Analyse realer Daten. Im industriellen Betrieb hilft uns SiLK, etwas zu identifizieren, und der Analyst muss die Fragen „Haben wir gefunden, was wir erwartet haben?“, „Entspricht dies unserer Hypothese?“, „Wie kann die Anzahl der falsch positiven Ergebnisse verringert werden?“, „Wie kann das Erkennungsniveau verbessert werden? "" usw.
- Verbesserung. In der letzten Phase verbessern wir das, was zuvor getan wurde - erstellen Sie Vorlagen, verbessern und optimieren Sie den Code, formulieren Sie die Hypothese neu und verfeinern Sie sie usw.
Dieser Zyklus gilt für dieselbe Cisco Stealthwatch. Nur die letzten fünf Schritte werden maximal automatisiert, wodurch die Anzahl der Analystenfehler verringert und die Geschwindigkeit der Vorfallerkennung erhöht wird. In SiLK können Sie beispielsweise Netzwerkstatistiken mithilfe Ihrer eigenen Skripts mit externen Daten zu schädlichen IP-Adressen anreichern. In Cisco Stealthwatch ist dies eine integrierte Funktion, die sofort einen Alarm anzeigt, wenn im Netzwerkverkehr mit IP-Adressen auf der schwarzen Liste interagiert wird.
Wenn wir in der „bezahlten“ Pyramide für Flussanalysesoftware höher gehen, folgt auf absolut kostenloses SiLK die Shareware ELK, die aus drei Schlüsselkomponenten besteht: Elasticsearch (Indizierung, Suche und Datenanalyse), Logstash (Dateneingabe / -ausgabe) und Kibana ( Visualisierung). Im Gegensatz zu SiLK, wo Sie alles selbst schreiben müssen, verfügt ELK bereits über viele vorgefertigte Bibliotheken / Module (einige werden bezahlt, andere nicht), die die Analyse der Netzwerktelemetrie automatisieren. Mit dem GeoIP-Filter in Logstash können Sie beispielsweise die beobachteten IP-Adressen an ihren geografischen Standort binden (für Stealthwatch ist dies eine integrierte Funktion).
ELK hat auch eine ziemlich große Community, die die fehlenden Komponenten für diese Überwachungslösung vervollständigt. Um beispielsweise mit Netflow, IPFIX und sFlow zu arbeiten, können Sie das
Elastiflow- Modul verwenden, wenn Sie mit dem Logstash Netflow-Modul, das nur Netflow unterstützt, nicht vertraut sind.
ELK bietet derzeit keine umfassende integrierte Analyse zur Erkennung von Anomalien und Bedrohungen in der Netzwerktelemetrie, um den Datenfluss effizienter zu erfassen und darin zu suchen. Das heißt, nach dem oben beschriebenen Lebenszyklus müssen Sie das Modell der Verstöße unabhängig beschreiben und es dann im Kampfsystem verwenden (es gibt dort keine eingebauten Modelle).
Natürlich gibt es anspruchsvollere Erweiterungen für ELK, die bereits einige Modelle zur Erkennung von Anomalien in der Netzwerktelemetrie enthalten. Solche Erweiterungen kosten jedoch Geld und die Frage ist, ob das Spiel die Kerze wert ist - schreiben Sie dasselbe Modell selbst, kaufen Sie die Implementierung für Ihr Überwachungstool oder kaufen Sie schlüsselfertige Lösung für die Klasse "Network Traffic Analysis".
Im Allgemeinen möchte ich nicht auf die Debatte eingehen, dass es besser ist, Geld auszugeben und eine schlüsselfertige Lösung zur Überwachung von Anomalien und Bedrohungen in der Netzwerktelemetrie zu kaufen (z. B. Cisco Stealthwatch) oder sie selbst herauszufinden und dieselben SiLK-, ELK- oder nfdump- oder OSU-Flow-Tools (für jede neue Bedrohung) zu verwenden ( Ich habe letztes Mal über die letzten beiden gesprochen . Jeder wählt für sich selbst und jeder hat seine eigenen Motive, eine von zwei Optionen zu wählen. Ich wollte nur zeigen, dass die Netzwerktelemetrie ein sehr wichtiges Instrument zur Gewährleistung der Netzwerksicherheit Ihrer internen Infrastruktur ist, und Sie sollten sie nicht vernachlässigen, um die Liste des Unternehmens, dessen Name in den Medien zusammen mit den Beinamen „gehackt“ erwähnt wird, die nicht den Anforderungen an die Informationssicherheit entsprachen, nicht zu ergänzen "," Nicht an die Sicherheit seiner Daten und Kundendaten denken. "
Zusammenfassend möchte ich die wichtigsten Tipps auflisten, die Sie beim Aufbau der Überwachung der Informationssicherheit Ihrer internen Infrastruktur befolgen sollten:- Beschränken Sie sich nicht nur auf den Umfang! Verwenden Sie die Netzwerkinfrastruktur (und wählen Sie sie aus), um nicht nur Datenverkehr von Punkt A nach Punkt B zu übertragen, sondern auch um Cybersicherheitsprobleme zu lösen.
- Informieren Sie sich über vorhandene Sicherheitsüberwachungsmechanismen in Ihren Netzwerkgeräten und stellen Sie diese bereit.
- Bevorzugen Sie bei der internen Überwachung die Telemetrieanalyse. Sie ermöglicht es Ihnen, bis zu 80-90% aller Informationssicherheitsvorfälle zu erkennen, während Sie das Unmögliche tun, wenn Sie Netzwerkpakete erfassen und Platz für die Speicherung aller Informationssicherheitsereignisse sparen.
- Verwenden Sie zur Überwachung von Flows Netflow v9 oder IPFIX. Sie bieten weitere Informationen im Sicherheitskontext und ermöglichen Ihnen die Überwachung nicht nur von IPv4, sondern auch von IPv6, MPLS usw.
- flow- – . , Netflow IPFIX.
- – flow-. Netflow Generation Appliance.
- – 100% .
- , , flow- SPAN/RSPAN-.
- / / ( ).
Zum letzten Tipp möchte ich eine Illustration geben, die ich bereits zuvor zitiert habe. Sie sehen, wenn der Cisco IS-Dienst früher sein IS-Überwachungssystem fast vollständig auf Intrusion Detection-Systemen und Signaturmethoden aufgebaut hat, machen sie jetzt nur noch 20% der Vorfälle aus. Weitere 20% entfallen auf Flussanalysesysteme, was darauf hindeutet, dass diese Lösungen keine Laune sind, sondern ein echtes Werkzeug für die Aktivitäten von Informationssicherheitsdiensten eines modernen Unternehmens. Darüber hinaus haben Sie das Wichtigste für ihre Implementierung - die Netzwerkinfrastruktur, deren Investitionen zusätzlich geschützt werden können, indem dem Netzwerk auch IS-Überwachungsfunktionen zugewiesen werden.
Ich habe das Thema der Reaktion auf in Netzwerkströmen festgestellte Anomalien oder Bedrohungen bewusst nicht angesprochen, aber ich denke, es ist klar, dass die Überwachung nicht nur durch Erkennen einer Bedrohung abgeschlossen werden sollte. Es sollte eine Antwort folgen und vorzugsweise in einem automatischen oder automatisierten Modus. Dies ist jedoch das Thema eines separaten Materials.Weitere Informationen:Bedrohung. Wenn es für Sie einfacher ist, alles zu hören, was oben geschrieben wurde, können Sie sich die einstündige Präsentation ansehen, die die Grundlage dieser Notiz bildete.