So funktioniert die Analyse des Netzwerkverkehrs in NDR

Die Netzwerkverkehrsanalyse beschreibt, wie eine NDR-Plattform den Datenverkehr in einem hybriden Unternehmensnetzwerk erfasst, verarbeitet und untersucht, um das Verhalten von Angreifern in Echtzeit zu erkennen. Eine effektive Netzwerkverkehrsanalyse umfasst, wie der Datenverkehr aus lokalen, cloud und Remote-Umgebungen erfasst wird, wie er zu sicherheitsrelevanten Metadaten verarbeitet wird, wie verschlüsselte Sitzungen ohne Entschlüsselung untersucht werden, wie Identitäten aus Netzwerkprotokollen abgeleitet werden und wie Analysekomponenten bereitgestellt und skaliert werden. Auf dieser Seite werden die einzelnen Ebenen für Sicherheitsteams erläutert, die NDR evaluieren oder bereitstellen.

So funktioniert die Analyse des Netzwerkverkehrs in einer NDR-Architektur

Die Analyse des Netzwerkverkehrs in NDR basiert auf drei miteinander verknüpften Ebenen: Erfassung des Datenverkehrs, Verhaltensanalyse und Integration von Reaktionsmaßnahmen. In den Netzwerksegmenten eingesetzte Sensoren erfassen den Rohdatenverkehr und leiten Metadaten an eine Verarbeitungskomponente weiter – gemeinhin als „Brain-Appliance“ bezeichnet –, die diese Metadaten mithilfe von KI-Modellen zur Verhaltensanalyse auswertet. Die Erkennungsergebnisse werden in einer Verwaltungsschnittstelle angezeigt und an nachgelagerte Systeme wie SIEM und SOAR weitergeleitet.

Im Gegensatz zu endpoint Tools arbeitet NDR auf Netzwerkebene, d. h., es erfasst alle Geräte, die innerhalb der Umgebung kommunizieren – ob verwaltet, nicht verwaltet, cloud oder IoT-/OT-Geräte –, unabhängig davon, ob ein Sicherheitsagent installiert ist. Dadurch erhalten Sicherheitsteams Einblick in laterale Bewegungen, Ost-West-Datenverkehr und identitätsbasierte Aktivitäten, die endpoint nicht erfassen können.

Die Architektur ist so konzipiert, dass am Erfassungsort keine Agenten erforderlich sind. Die Sensoren empfangen eine Kopie des Netzwerkverkehrs über SPAN-Ports, TAPs oder cloud Spiegelung und erfordern weder eine Inline-Platzierung noch eine Verkehrsabfangung. Dies minimiert die Komplexität der Bereitstellung und verhindert, dass Latenzen in den Produktionsdatenverkehr entstehen.

Überwachung des Ost-West- gegenüber dem Nord-Süd-Verkehr

Die Überwachung des Netzwerkverkehrs umfasst zwei Hauptverkehrsrichtungen, die jeweils eine bestimmte Art von Angreiferverhalten offenbaren. Der Nord-Süd-Verkehr verläuft zwischen internen Systemen und externen Zielen; hier werden Command-and-Control-Kommunikation, Datenexfiltration und Botnetz-Aktivitäten sichtbar. Der Ost-West-Verkehr verläuft lateral zwischen internen Systemen; hier finden Aufklärung, Privilegieneskalation und laterale Bewegung statt, nachdem sich ein Angreifer bereits einen Zugang verschafft hat.

Die meisten Tools für die Perimetersicherheit konzentrieren sich auf den Nord-Süd-Datenverkehr am Netzwerkrand. Dadurch bleibt die Transparenz im Ost-West-Datenverkehr weitgehend unberücksichtigt. Wenn ein Angreifer gültige Anmeldedaten nutzt, um sich zwischen Servern, Workloads oder Identitätssystemen zu bewegen, verläuft diese Aktivität im Ost-West-Richtungsfluss und löst keine Warnmeldungen in Tools aus, die lediglich den ein- und ausgehenden Datenverkehr überprüfen.

Der NDR schließt diese Lücke, indem er den Datenverkehr nicht nur am Netzwerkrand, sondern auch in internen Netzwerksegmenten, innerhalb von Rechenzentren, über cloud hinweg und zwischen Campus-Standorten erfasst. Dadurch können Verhaltensmodelle laterale Bewegungen in Echtzeit beobachten, noch bevor ein Angriff sein Ziel erreicht. Für einen tieferen Einblick darin, wie Angreifer Lücken in der Abdeckung jenseits der endpoint ausnutzen, bietet die Analyse auf Netzwerkebene den größten Mehrwert gerade bei den Angriffspfaden, die in diesen toten Winkeln entstehen.

Die nachstehende Tabelle ordnet jede Verkehrsrichtung den damit verbundenen Angriffsmustern zu. Sicherheitsteams sollten sicherstellen, dass die Sensoren so platziert sind, dass sie den Datenverkehr in allen Netzwerksegmenten abdecken, in denen sensible Systeme betrieben werden.

Welchen Datenverkehr sollte die Netzwerkanalyse erfassen (und welchen ausschließen)?

Eine effektive Analyse des Netzwerkverkehrs erfasst die Protokolle, die Verhaltensmuster, Authentifizierungsvorgänge, die Kommunikation zwischen Diensten und Aktivitäten auf Sitzungsebene offenlegen, während datenintensiver Datenverkehr, der nur Störsignale ohne Sicherheitswert liefert, ausgeblendet wird. Die Auswahl der Protokolle wirkt sich direkt auf die Erkennungsgenauigkeit und die Leistung der Appliance aus.

Die folgenden Tabellen enthalten operative Leitlinien, die direkt aus den Einsatzspezifikationen von Vectra NDR abgeleitet wurden. Betrachten Sie sie im Zusammenhang: Was erfasst wird, bestimmt den Erfassungsumfang; was ausgeschlossen wird, bestimmt die Modellgenauigkeit und die Effizienz der Appliance; und was die HostID verbessert, bestimmt, wie zuverlässig die Plattform Aktivitäten bestimmten benannten Hosts und Identitäten zuordnet.

Protokolle, die erfasst werden sollen, vs. Datenverkehr, der ausgeschlossen werden soll

In der linken Spalte sind Protokolle aufgeführt, die Verhaltenssignale enthalten – Authentifizierung, Dienstaufrufe, Sitzungsdaten. In der rechten Spalte sind Verkehrskategorien aufgeführt, die Kapazität beanspruchen, ohne die Erkennungsleistung zu verbessern. Die Erfassung ausgeschlossener Verkehrstypen erhöht die Auslastung des Geräts und führt zu Störsignalen, die die Genauigkeit des KI-Modells beeinträchtigen.

Was trägt zur Verbesserung der HostID von Vectra bei?

Die Genauigkeit der Host-Identifizierung hängt davon ab, inwieweit die Plattform die Protokolle befolgt, die Signale zur Benennung von Geräten und Identitäten übertragen. Die folgenden Eingaben – sowohl protokollbasierte als auch integrationsbasierte – verbessern die Zuverlässigkeit, mit der die Plattform Netzwerkaktivitäten bestimmten benannten Hosts und Identitäten zuordnet, selbst wenn sich die IP-Adressen ändern.

Unterstützte Kapselungsformate

Vectra NDR-Sensoren unterstützen die folgenden Netzwerk-Kapselungsformate und gewährleisten so Kompatibilität mit modernen Rechenzentrums-, Campus- und cloud .

Typische Quellen für die Erfassung von Datenverkehr

Der Netzwerkverkehr gelangt über die folgenden Erfassungsmechanismen zu Vectra Sensors. Die geeignete Quelle hängt von der Netzwerkarchitektur, der Art der Umgebung und davon ab, ob die Bereitstellung eine lokale, cloud oder eine Hybridinfrastruktur umfasst.

‍

Hinweise zur Platzierung: Sensoren sollten auf der Südseite eines Proxy- oder NAT-Geräts eingesetzt werden, um den Ursprungshost genau zu identifizieren. Wenn der Datenverkehr von mehreren Hosts hinter einem Proxy auf eine einzige IP-Adresse gebündelt wird, sollte die NDR-Plattform so konfiguriert werden, dass sie diesen Proxy erkennt, um die Erkennungsgenauigkeit zu gewährleisten. Kleine Remote-Niederlassungen benötigen in der Regel keinen dedizierten Sensor – der Datenverkehr von diesen Standorten ist in der Regel an zentralen Standorten sichtbar, an denen bereits Sensoren eingesetzt werden. Hinweise zur Dimensionierung physischer und virtueller Appliances nach Durchsatzstufen finden Sie in den Spezifikationen der Appliances und Sensoren.

So funktioniert die Analyse verschlüsselter Datenverkehr in NDR

Bei der überwiegenden Mehrheit der NDR-Erkennungen ist keine Entschlüsselung des Datenverkehrs erforderlich. KI-Modelle, die auf Verhaltensanalysen basieren, werten Metadaten aus, die aus verschlüsselten Sitzungen, Paket-Timing, Sitzungsgröße, Verbindungsmustern, Zertifikatsattributen und Protokollverhalten abgeleitet werden, um böswillige Aktivitäten zu identifizieren, ohne den Inhalt der Nutzdaten zu überprüfen. Dadurch erweist sich die Analyse des Netzwerkverkehrs als wirksames Mittel gegen die Tarnung von Command-and-Control-Kommunikation im verschlüsselten Datenverkehr – eines der am häufigsten übersehenen Angriffsmuster in Unternehmensumgebungen.

Dies ist ein entscheidender architektonischer Unterschied. Die Inline-Entschlüsselung bringt Latenzzeiten, Datenschutzbedenken, regulatorische Komplexität und erhebliche Infrastrukturkosten mit sich. NDR umgeht diese Kompromisse, indem es auf Metadaten statt auf Klartext-Nutzdaten basiert – eine Sichtweise, die dadurch untermauert wird, dass moderne Architekturen keine Inline-Entschlüsselung mehr benötigen, um eine aussagekräftige Abdeckung bei der Verhaltenserkennung zu erreichen.

Es gibt nur wenige Fälle, in denen der Zugriff auf entschlüsselte Metadaten des Datenverkehrs einen zusätzlichen Nutzen bietet:

• Teams, die erweiterte Ermittlungs- oder Wiederherstellungsfunktionen nutzen, für die entschlüsselte Sitzungsinhalte zur forensischen Analyse erforderlich sind
• Bereitstellungen unter Verwendung von Regeln zur Mustererkennung, bei denen bestimmte Signaturen nur dann ausgelöst werden, wenn der Inhalt der Nutzdaten überprüft werden kann

Wann eine Entschlüsselung erforderlich ist: der parallele Pipeline-Ansatz

Wenn sowohl der verschlüsselte als auch der entschlüsselte Datenverkehr analysiert werden muss, sollte dies über parallele Verarbeitungs-Pipelines erfolgen – und nicht, indem beide Datenverkehrstypen an denselben Sensor gesendet werden. Werden beide Datenströme an einen einzigen Sensor gesendet, führt dies dazu, dass die Deduplizierungslogik einen der beiden Datenströme verwirft (in der Regel die entschlüsselte Version, da die Entschlüsselung einen zusätzlichen Verarbeitungsaufwand verursacht, wodurch sie später eintrifft). Der richtige Ansatz besteht darin, für den entschlüsselten Datenstrom einen dedizierten Sensor einzusetzen, der mit einer separaten Brain-Appliance gekoppelt ist. Virtuelle Sensoren und Brain-Appliances werden für diesen Zweck ohne zusätzliche Lizenzkosten unterstützt.

So funktioniert die Erkennung von Netzwerkidentitäten anhand von Datenverkehr-Metadaten

Die Identitätserkennung im Netzwerk leitet den Identitätskontext direkt aus Netzwerkprotokollen ab, anstatt sich allein auf von Agenten gemeldete Telemetriedaten oder die Erfassung von Protokollen zu stützen. Durch die Analyse des Authentifizierungsdatenverkehrs im Netzwerk, von Kerberos-Tickets, LDAP-Abfragen, NTLM-Austauschvorgängen und DCE/RPC-Aufrufen erstellt die Plattform ein kontinuierliches Bild davon, welche Identitäten aktiv sind, auf welche Ressourcen sie zugreifen und wie ihr Verhalten im Vergleich zu festgelegten Basiswerten ausfällt. Dies macht den Ansatz besonders effektiv bei der Erkennung von privilegienbasierten Identitätsangriffen, bei denen kompromittierte Konten zwar innerhalb der erwarteten Zugriffsgrenzen operieren, sich jedoch hinsichtlich der Authentifizierungsmuster anomal verhalten.

Zudem erzeugen Dienstkonten, die sich zwischen Systemen authentifizieren, Workloads, die API-Aufrufe tätigen, und KI-Agenten, die die Infrastruktur durchlaufen, identitätsbezogenen Netzwerkverkehr, selbst wenn auf diesen Systemen kein endpoint vorhanden ist.

Die folgende Tabelle ordnet jedes identitätsrelevante Protokoll dem damit verbundenen Angriffsverhalten zu und erläutert, warum dies aus operativer Sicht von Bedeutung ist.

‍

Die Erkennung von Netzwerkidentitäten trägt zudem zur Genauigkeit der Host-Identifizierung bei. DNS, Reverse-DNS, Multicast-DNS, Kerberos, DHCP und NetBIOS sind die wichtigsten Signale, die verwendet werden, um Netzwerkaktivitäten bestimmten benannten Hosts und Identitäten zuzuordnen – was eine konsistente Zuordnung auch bei wechselnden IP-Adressen ermöglicht.

„Brain“- und Sensor-Architektur in NDR-Implementierungen

Die Kernarchitektur von NDR besteht aus zwei Hauptgerätetypen: dem „Brain“ und dem „Sensor“. Jeder erfüllt eine eigene Funktion, und durch ihr Zusammenspiel wird die Analyse des Rohdaten-Netzwerkverkehrs in priorisierte Sicherheitswarnungen umgewandelt.

Sensor-Appliances erfassen den Rohdatenverkehr an festgelegten Erfassungspunkten, in Rechenzentren, Campus-Umgebungen, cloud und an entfernten Standorten. Die Sensoren deduplizieren den Datenverkehr, bevor sie Metadaten an das Brain weiterleiten. Sie unterhalten einen rollierenden Erfassungspuffer, der bei Bedarf eine Abfrage auf Paketebene (PCAP) für Untersuchungszwecke ermöglicht. Der vSensor ist die virtuelle Variante, die auf Hypervisoren oder in cloud bereitgestellt werden kann.

Brain-Appliances empfangen Metadaten von einem oder mehreren gekoppelten Sensoren und verarbeiten diese lokal mithilfe von verhaltensbasierten KI-Modellen, um Erkennungen zu generieren. Das Verständnis dafür, wie metadatengesteuerte Erkennung die Transparenz von Bedrohungen verbessert, ist entscheidend, um zu beurteilen, warum diese Architektur logbasierte Ansätze bei der Überwachung des Ost-West-Datenverkehrs und bei identitätsbasierten Angriffsszenarien übertrifft. Bei cloud Bereitstellungen (Respond UX) sendet das Brain Erkennungsdaten und Metadaten an die cloud in der Verwaltungsoberfläche dargestellt werden. Bei lokalen Bereitstellungen (Quadrant UX) hostet das Brain die Verwaltungs-UI lokal.

Mixed-Mode-Geräte vereinen Brain- und Sensor-Funktionen in einem einzigen Gerät und eignen sich für kleinere Bereitstellungen oder Umgebungen, in denen eine Architektur mit zwei Geräten nicht sinnvoll ist.

‍

Kommunikation und Kopplung:

• Die Sensoren kommunizieren über TCP/22 (SSH) und TCP/443 (HTTPS) mit ihrem gekoppelten Brain
• Sensoren kommunizieren in der Regel nur mit dem Brain und dem DNS – nicht direkt mit externen Systemen
• Brain-Geräte initiieren alle ausgehenden Verbindungen zur Vectra cloud
• Aktualisierungen werden von der cloud das Brain gesendet und automatisch an die gekoppelten Sensoren weitergeleitet
• Air-Gapped-Bereitstellungen werden unterstützt (nur Quadrant UX), wobei die Erkennungen lokal auf dem Brain generiert werden
• Physische Sensoren können cloud ersten Start über TCP/443 die Brain-IP aus der cloud abrufen, wodurch eine automatische Kopplung über DHCP ermöglicht wird

Empfehlung zur Bereitstellung: Brain- und Sensor-Appliances sollten an Netzwerkstandorten platziert werden, die vom öffentlichen Internet aus nicht direkt einsehbar sind. Eine private Verbindung oder ein VPN-Tunnel, der außerhalb der Vectra-Appliances endet, ist der bevorzugte Ansatz. NDR-Erkennungen konzentrieren sich auf die Kommunikation von innen nach innen und von innen nach außen – die Erfassung von Datenverkehr außerhalb der Edge-Firewalls in der DMZ wird nicht empfohlen.

‍

Überlegungen zu Bereitstellung, Skalierung und Global View

NDR-Implementierungen reichen von Umgebungen mit einem einzigen Standort bis hin zu großen, global verteilten Unternehmen. Für Teams, die Implementierungen im Unternehmensmaßstab planen, ist es unerlässlich, die Kapazität der Appliance und die Architektur mit mehreren Instanzen zu verstehen.

Dimensionierung von Geräten

Die folgende Tabelle gibt einen Überblick über die aktuellen Leistungsstufen der Appliances. Die tatsächliche Leistung hängt von der Zusammensetzung des Datenverkehrs ab – arbeiten Sie mit Ihrem Account-Team zusammen, um die richtige Mischung aus physischen und virtuellen Appliances für Ihre Umgebung zu ermitteln.

‍

Hinweis: Vectra veröffentlicht regelmäßig neue Appliance-Konfigurationen, um aktualisierten Durchsatzanforderungen, Hypervisoren und cloud gerecht zu werden. Beachten Sie vor der Dimensionierung einer Bereitstellung stets die aktuellen Angaben in den Spezifikationen der Appliance und der Sensoren.

Gesamtüberblick für verteilte Unternehmen

Unternehmen mit mehreren Standorten oder Geschäftsbereichen können „Global View“ für verteilte SOC-Umgebungen einsetzen, um über separate NDR-Instanzen hinweg ein einheitliches Erkennungsbild zu gewährleisten. „Global View“ fasst priorisierte Entitätsdaten aus untergeordneten Respond UX-Instanzen in einer Ankerinstanz zusammen und bietet so eine zentrale Verwaltungsansicht, ohne die gespeicherten Daten zu zentralisieren.

‍

Netzwerkverkehrsanalyse in der Praxis: Ergebnisse der Einführung, 2023–2025

Die Analyse des Netzwerkverkehrs liefert bei korrekter Implementierung messbare Ergebnisse, doch diese Ergebnisse hängen unmittelbar von architektonischen Entscheidungen ab: wo Sensoren platziert werden, welcher Datenverkehr erfasst wird, wie Identitäten aus Protokollen abgeleitet werden und wie Erkennungen in der gesamten Umgebung priorisiert werden. Die folgenden Beispiele veranschaulichen, welche Auswirkungen die Architektur in Produktionsumgebungen in verschiedenen Netzwerkumgebungen hat.

Goodwood Estate — Ost-West-Transparenz von 20 % auf 95 % (2024) Vor der Einführung von NDR deckte die Ost-West-Verkehrsüberwachung bei Goodwood Estate etwa 20 % der verteilten Infrastruktur ab. Durch blinde Flecken auf dem Campus sowie in IoT- und OT-Umgebungen blieben wichtige laterale Bewegungswege unüberwacht. Nach der Bereitstellung von Sensoren in internen Netzwerksegmenten – nicht nur am Perimeter – erreichte die Ost-West-Transparenz 95 %, wodurch die Abdeckungslücken geschlossen wurden, die herkömmliche Perimeter-Tools aufgrund ihrer Konzeption nicht schließen können.

Schaefer Kalk — Abwehr eines ransomware , der EDR umging (2023) endpoint von Schaefer Kalk konnten eine aktive ransomware , die sich lateral über das Netzwerk ausbreitete, nicht erkennen. Eine Analyse des Netzwerkverkehrs, bei der Ost-West-Datenströme untersucht wurden, die EDR nicht beobachten kann, deckte die laterale Ausbreitung auf und stoppte den Angriff, bevor er die Produktionssysteme erreichte.

Globe Telecom – 99 % weniger Fehlalarme und 75 % schnellere Reaktion (2024) Globe Telecom verkürzte die Reaktionszeit bei Vorfällen von 16 Stunden auf 3,5 Stunden. Das Alarmrauschen sank um 99 % und die Eskalationen gingen um 96 % zurück, sodass sich die Analysten auf sechs echte Vorfälle konzentrieren konnten, anstatt auf Hunderttausende von Alarmen mit geringem Wert. Der entscheidende Faktor: eine risikobasierte Priorisierung, die auf verhaltensbasierter KI basiert, die über Netzwerk-, Identitäts- und cloud hinweg arbeitet, anstatt einzelne Alarme anhand von Signaturen abzugleichen.

Eine globale Gesundheitsorganisation – Aufdeckung von Missbrauch von Anmeldedaten, den das SIEM-System übersehen hatte (2024) Bereits wenige Tage nach der Implementierung wurden durch die Analyse des Netzwerkverkehrs gestohlene Anmeldedaten, cloud , Versuche der Privilegienerweiterung sowie Aktivitäten zur Aufrechterhaltung der Präsenz in AWS entdeckt, die das SIEM-System der Organisation nicht erkannt hatte. Die Identitätserkennung anhand von Netzwerkprotokollen – Kerberos, LDAP, DCE/RPC – lieferte das Signal, das logbasierte Systeme nicht rekonstruieren konnten. Das SOC griff ein, bevor Daten oder Betriebsabläufe beeinträchtigt wurden.

Das Wichtigste auf einen Blick: Die Ergebnisse hängen von der Platzierung der Sensoren entlang der Ost-West-Segmente, der Erfassung des Protokollverkehrs einschließlich des Authentifizierungsverkehrs sowie von Verhaltensmodellen ab, die die Bewegung von Identitäten im gesamten Netzwerk analysieren, anstatt isolierte Warnmeldungen an einzelnen Endpunkten zu betrachten.

Wie Vectra AI die Analyse des Netzwerkverkehrs Vectra AI

Die Netzwerkverkehrsanalyse Vectra AI basiert auf vier technischen Schichten, die zusammenwirken, um Rohdaten aus Netzwerk- und Identitäts-Telemetrie in priorisierte, umsetzbare Erkennungsergebnisse umzuwandeln. Dabei handelt es sich nicht um allgemeine NDR-Funktionen – vielmehr beschreiben sie die spezifischen architektonischen Entscheidungen, die bestimmen, wie sich die Plattform in der Produktion in hybriden,cloud und identitätsgesteuerten Umgebungen verhält.

Ebene 1: Modellierung des Verhaltens von Angreifern

Jede Erkennung basiert auf Sicherheitsforschung und nicht auf statistischen Anomalien. Die Modelle sind direkt MITRE ATT&CK und Techniken MITRE ATT&CK in den Bereichen Netzwerk, Identitätsmanagement, cloud und SaaS zugeordnet.

Erkennungsingenieure und Datenwissenschaftler definieren für jede Angriffstechnik drei Aspekte:

• Was muss erkannt werden?
• Welche Telemetriedaten sind erforderlich, um dies zu erkennen?
• Welches KI-/ML-Modell eignet sich für dieses spezielle Problem?

Die Modelle werden je nach Problemstellung – Missbrauch von Anmeldedaten, laterale Bewegung, Command-and-Control, Persistenz – ausgewählt und nicht pauschal angewendet. Dadurch wird sichergestellt, dass die Erkennungen nachvollziehbar, wiederholbar und vertretbar sind und ein klarer Zusammenhang zwischen der Angreifertechnik und dem Verteidigungsergebnis besteht. Vectra AI dazu beigetragen und Einfluss darauf genommen, wie netzwerk- und identitätsbasierte ATT&CK-Techniken von der breiteren Sicherheitsgemeinschaft verstanden und abgebildet werden.

Ebene 2: Jetstream – Echtzeit-Streaming-Engine

Jetstream verarbeitet Netzwerk- und Identitätsdaten in Echtzeit – nicht erst im Nachhinein.

Im Gegensatz zu batchbasierten, protokollorientierten Systemen, die Datenverkehr speichern und später analysieren, erfasst, ergänzt und korreliert Jetstream Telemetriedaten kontinuierlich, sobald Ereignisse im gesamten hybriden Unternehmen auftreten. Dadurch lassen sich Verhaltensmuster bereits während eines Angriffs erkennen und nicht erst Minuten oder Stunden später.

Gerade bei der Überwachung des Ost-West-Verkehrs kommt es auf das Streaming an. Seitliche Bewegungen, die sich über mehrere Minuten hinweg vollziehen, können von Systemen, die auf Batch-Verarbeitungszyklen basieren, nicht zuverlässig erkannt werden.

Schicht 3: Metadaten-Signalstruktur

Anstatt auf die vollständige Erfassung von Paketen oder die direkte Einlesung von Rohprotokollen zurückzugreifen, Vectra AI , normalisiert und ergänzt Vectra AI sicherheitsrelevante Metadaten aus dem gesamten hybriden Netzwerk.

Zu den Quellen gehören:

• Netzwerkflüsse
• Identitätsereignisse
• Cloud
• SaaS-Interaktionen
• Infrastruktur-Telemetrie

Jeder Metadatensatz wird kontinuierlich um Kontextinformationen erweitert – Identität, Rolle des Assets, Verhaltensverlauf, Angriffsphase und Risikolage –, wodurch eine gemeinsame Informationsebene für die Arbeitsabläufe in den Bereichen Erkennung, Untersuchung und Reaktion entsteht. Analysten erhalten umfassende Einblicke, ohne den Speicher- und Leistungsaufwand, der mit der Verwaltung umfangreicher Paketaufzeichnungen in großem Maßstab verbunden ist.

Ebene 4: Mehrschichtige Zuordnung

In Umgebungen, in denen Angreifer Identitäten missbrauchen, sich als Dienste ausgeben und sich lateral bewegen, muss die Zuordnung über IP-Adressen und die Korrelation einzelner Ereignisse hinausgehen.

Die mehrschichtige Attributionsfunktion Vectra AI verknüpft Aktivitäten über Benutzer, Dienstkonten, Workloads, Hosts und die Infrastruktur hinweg kontinuierlich miteinander, indem sie Netzwerkverhalten, Identitätskontext und Informationen zu Zugriffsrechten kombiniert. Drei Funktionen arbeiten dabei zusammen, um dies zu ermöglichen:

‍

Zusammen ermöglichen diese Ebenen der Plattform, zuverlässig zu ermitteln, wer was tut, wo und mit welchen Berechtigungen – selbst wenn Angreifer gültige Anmeldedaten verwenden und sich in den normalen Datenverkehr einfügen.

Schlussfolgerung

Bei der Netzwerkerkennung und -reaktion geht es nicht um die Entscheidung für ein einzelnes Produkt, sondern um eine Reihe miteinander verknüpfter technischer Entscheidungen, die darüber entscheiden, ob Ihr Sicherheitsteam laterale Bewegungen in Echtzeit erkennen, aus Netzwerkprotokollen Identitätskontext ableiten, verschlüsselten Datenverkehr ohne Entschlüsselung analysieren und die Erkennung auf verteilte Umgebungen ausweiten kann, ohne gespeicherte Daten zu zentralisieren.

Die auf dieser Seite behandelten Grundlagen wirken sich unmittelbar auf die betrieblichen Ergebnisse aus: Die Ausrichtung der Sensoren in Ost-West-Richtung entscheidet darüber, ob seitliche Bewegungen beobachtet oder nur abgeleitet werden; Entscheidungen zur Protokollerfassung bestimmen, ob identitätsbasierte Angriffe sichtbar oder unsichtbar sind; die Gestaltung paralleler Pipelines entscheidet darüber, ob die Analyse verschlüsselten Datenverkehrs die Erkennungsgenauigkeit beeinträchtigt; und die Global-View-Architektur bestimmt, ob verteilte Bereitstellungen eine einheitliche Transparenz oder eine fragmentierte Abdeckung gewährleisten.

Erfahren Sie, wie die Plattform Vectra AI eine Netzwerkverkehrsanalyse bietet, die laterale Bewegungen, Identitätsmissbrauch und verschlüsselte Command-and-Control-Kommunikation aufspürt und dabei genau das erkennt, was Perimeter-Tools und endpoint übersehen.