Datenverfügbarkeit für die Suche

Unterstützt in:

In diesem Dokument wird der Lebenszyklus der Datenaufnahme beschrieben, einschließlich des End-to-End-Datenflusses und der Latenz. Außerdem wird erläutert, wie sich diese Faktoren auf die Verfügbarkeit von kürzlich aufgenommenen Daten für Abfragen und Analysen auswirken.

Daten in Google SecOps aufnehmen und verarbeiten

In diesem Abschnitt wird beschrieben, wie Google SecOps Sicherheitsdaten aufnimmt, verarbeitet und analysiert.

Datenaufnahme

Die Datenaufnahmepipeline beginnt mit dem Erheben Ihrer Sicherheitsrohdaten aus Quellen wie:

  • Sicherheitsprotokolle aus Ihren internen Systemen
  • In Cloud Storage gespeicherte Daten
  • Ihrem Security Operations Center (SOC) und anderen internen Systemen

Google SecOps überträgt diese Daten mit einer der sicheren Aufnahmemethoden auf die Plattform.

Die wichtigsten Aufnahmemethoden sind:

  • Direkte Google Cloud Aufnahme

    Google SecOps verwendet die direkte Google Cloud Aufnahme, um automatisch Protokolle und Telemetriedaten aus Ihrer Organisation abzurufen Google Cloud, einschließlich Cloud Logging, Cloud Asset Inventory-Metadaten und Security Command Center Premium-Ergebnissen.

  • Aufnahme-APIs

    Senden Sie Daten direkt an Google SecOps über die öffentlichen REST Aufnahme-APIs. Diese Methode verwenden Sie für benutzerdefinierte Integrationen oder um Daten als unstrukturierte Protokolle oder vorformatierte Unified Data Model (UDM)-Ereignisse zu senden.

  • Bindplane-Agent

    Sie können den vielseitigen Bindplane-Agent in Ihrer Umgebung (lokal oder in anderen Clouds) bereitstellen, um Protokolle aus einer Vielzahl von Quellen zu erheben und an Google SecOps weiterzuleiten.

  • Datenfeeds

    In Google SecOps konfigurieren Sie Datenfeeds, um Protokolle aus Drittanbieterquellen abzurufen, z. B. aus bestimmten Cloud Storage-Buckets von Drittanbietern (wie Amazon S3) oder APIs von Drittanbietern (wie Okta oder Microsoft 365).

Normalisierung und Datenanreicherung

Sobald Daten in Google SecOps eingehen, werden sie auf der Plattform in den folgenden Phasen verarbeitet:

  1. Parsing und Normalisierung

    Ein Parser verarbeitet zuerst die Rohprotokolldaten, um sie zu validieren, zu extrahieren und zu transformieren die Daten aus ihrem ursprünglichen Format in das standardisierte UDM. Durch das Parsen und Normalisieren können Sie unterschiedliche Datenquellen (z. B. Firewall-Protokolle, Endpunktdaten, Cloud-Protokolle) mit einem einzigen, konsistenten Schema analysieren. Das ursprüngliche Rohprotokoll wird zusammen mit dem UDM-Ereignis gespeichert.

  2. Indexierung

    Nach der Normalisierung indexiert Google SecOps die UDM-Daten, um schnelle Abfragegeschwindigkeiten für große Datasets zu ermöglichen. So können die UDM-Ereignisse durchsucht werden.

  3. UDM-Aliasing und -Anreicherung

    • Google SecOps führt UDM-Aliasing und -Anreicherung durch, um UDM-Ereignisse mit wertvollem Kontext anzureichern. Dazu werden Kontextdaten und Indikatoren für Protokolldaten identifiziert und hinzugefügt. Beispielsweise wird der login name eines Nutzers mit seinen verschiedenen IP addresses, hostnames und MAC addresses verknüpft.
    • Geostandort: Google SecOps reichert IP-Adressen mit Geostandort daten an.

  4. ECG-Anreicherung

    • Google SecOps führt ECG-Aliasing durch, bei dem Kontext aus mehreren Quellen (z. B. IdPs, CMDBs und Threat Intelligence) zusammengeführt wird, um ein konsolidiertes Entitätsprofil im Entitätskontextdiagrammzu erstellen.

    • Threat Intelligence: Google SecOps vergleicht Ereignisdaten automatisch mit den umfangreichen Threat Intelligence-Daten von Google, einschließlich Quellen wie Google Threat Intelligence und Safe Browsing, um bekannte schädliche Bedrohungen wie domains, IP addresses, und file hashes zu identifizieren.

    • WHOIS: Google SecOps reichert Domainnamen mit ihren öffentlichen Registrierungs WHOIS informationen an.

Datenverfügbarkeit für die Analyse

Nach der Verarbeitung und Anreicherung sind UDM-Daten sofort für die Analyse verfügbar:

  • Echtzeiterkennung

    Die Detection Engine führt automatisch benutzerdefinierte und von Google entwickelte Regeln mit aktivierten Live-Regeln für eingehende Live-Daten aus, um Bedrohungen zu identifizieren und Benachrichtigungen zu generieren.

  • Suche und Untersuchung

    Ein Analyst kann die Suchmethoden verwenden, um diese normalisierten und angereicherten Daten zu durchsuchen. Beispielsweise kann er die UDM-Suche verwenden, um zwischen verknüpften Entitäten zu wechseln (z. B. von einem user zu seinem asset zu einer schädlichen domain) und Benachrichtigungen zu untersuchen.

Suchmethoden

Google SecOps bietet verschiedene Methoden zum Durchsuchen Ihrer Daten, die jeweils einem anderen Zweck dienen.

Die UDM-Suche ist die primäre und schnellste Suchmethode und wird für die meisten Untersuchungen verwendet.

  • Was wird durchsucht? Es werden die normalisierten und indexierten UDM-Ereignisse abgefragt. Da alle Daten in dieses Standardformat geparst werden, können Sie eine Abfrage schreiben, um dieselbe Aktivität (z. B. eine Anmeldung) in allen Ihren verschiedenen Produkten (z. B. Windows, Okta, Linux) zu finden.
  • Funktionsweise: Sie verwenden eine bestimmte Syntax, um Felder, Operatoren und Werte abzufragen.

  • Beispiel: principal.hostname = "win-server" AND target.ip = "10.1.2.3"

    Die Ergebnisse sind in der Regel innerhalb von 2 bis 15 Minuten nach der Aufnahme verfügbar.

Verwenden Sie die Rohlogsuche, um etwas in der ursprünglichen, nicht geparsten Protokollnachricht zu finden, das möglicherweise nicht einem UDM-Feld zugeordnet wurde. Diese Suchmethode ist für schnelle Suchen optimiert und liefert in der Regel innerhalb von 2 Sekunden Ergebnisse für bestimmte Indikatoren wie Dateihashes oder IP-Adressen.

  • Was wird durchsucht? Der ursprüngliche Rohtext der Protokolle wird durchsucht, bevor sie geparst und normalisiert wurden. Das ist nützlich, um bestimmte Strings, Befehlszeilenargumente oder andere Artefakte zu finden, die keine indexierten UDM-Felder sind.
  • Funktionsweise: Sie verwenden das Präfix raw =. Diese Methode kann langsamer als die UDM-Suche sein, da keine indexierten Felder durchsucht werden.
  • Beispiel (String): raw = "PsExec.exe"
  • Beispiel (regulärer Ausdruck): raw = /admin\$/

Verwenden Sie die Statistiksuche für langfristige Trends, bei denen Millionen von Datenzeilen zusammengefasst werden. Da die Plattform statistische Analysen und Gruppierungen durchführen muss, sind bei diesen Abfragen längere Ladezeiten zu erwarten.

Suche in natürlicher Sprache (Gemini)

Mit der Suche in natürlicher Sprache (Gemini) können Sie Fragen in normalem Deutsch stellen, die Gemini dann in eine formale UDM-Abfrage übersetzt.

  • Was wird durchsucht? Es wird eine Konversationsschnittstelle zum Abfragen von UDM-Daten bereitgestellt.
  • Funktionsweise: Sie geben eine Frage ein und Gemini generiert die zugrunde liegende UDM-Suchanfrage für Sie, die Sie dann ausführen oder verfeinern können.
  • Beispiel: „Zeige mir alle fehlgeschlagenen Anmeldungen des Nutzers ‚bob‘ in den letzten 24 Stunden.“

Die SOAR-Suche ist spezifisch für SOAR-Komponenten. Sie wird zum Verwalten von Sicherheitsvorfällen verwendet, nicht zum Suchen in Protokollen.

  • Was wird durchsucht? Es wird in der SOAR-Plattform nach Cases und Entitäten (z. B. Nutzern, Assets, IP-Adressen) gesucht.
  • Funktionsweise: Sie können Freitext- oder feldbezogene Filter verwenden, um Cases nach z. B. ID, Benachrichtigungsname, Status und zugewiesenem Nutzer zu finden.
  • Beispiel: Suchen Sie nach CaseIds:180 oder AlertName:Brute Force.

Datenaufnahmepipeline zur Suchverfügbarkeit

Die End-to-End-Datenverfügbarkeit ist die Gesamtzeit zwischen dem Auftreten eines Ereignisses und dem Zeitpunkt, an dem es in Google SecOps für die Suche oder die Regelausführung verfügbar ist. Diese Latenz ist die Summe der folgenden beiden Komponenten:

  1. Verzögerung bei der Verfügbarkeit auf der Quellseite: Die Zeit zwischen dem Auftreten eines Ereignisses und dem Zeitpunkt, an dem das Quellsystem die Protokolldaten für die Aufnahme verfügbar macht. Diese Verzögerung hängt von der Architektur, Verarbeitung, Batchverarbeitung und den API-Veröffentlichungszeitplänen des Quellsystems ab. Google SecOps kann diese Verzögerung nicht beeinflussen. Beispiele sind Verzögerungen, wenn ein System Protokolle in einen Storage-Bucket schreibt oder sie an einen API-Endpunkt veröffentlicht.

  2. Verarbeitungszeit von Google SecOps: Die Zeit, die Google SecOps benötigt, um die Daten nach dem Empfang zu verarbeiten. Diese Dauer umfasst interne Pipelinestufen wie Aufnahme, Parsing, Normalisierung, Indexierung und Anreicherung.

Sie müssen beide Komponenten berücksichtigen, wenn Sie Zeitpläne für die Datenverfügbarkeit untersuchen.

Verzögerungen, die von der Datenquelle ausgehen

Die folgenden Faktoren können die Verzögerung bei der Verfügbarkeit auf der Quellseite beeinflussen:

  • Batchverarbeitung: Einige Systeme generieren Protokolle in Batches in festgelegten Intervallen (z. B. stündlich).
  • API-Latenz: Die Quell-API kann inhärente Verzögerungen aufweisen, bis neue Ereignisse abgefragt werden können.
  • Zeitpunkt der Ereigniserstellung und ‑veröffentlichung: Ein Ereigniszeitstempel in einem Protokoll kann viel früher sein als der Zeitstempel, an dem das Protokoll fertiggestellt wird und für die Erhebung verfügbar ist.
  • Drosselung: API-Ratenbegrenzungen auf der Quellseite können den Datenabruf verlangsamen.
  • Erste Backfill-Verarbeitung: Das Bereitstellen und Aufnehmen großer Mengen historischer Daten dauert Zeit.

Diese Verzögerungen variieren je nach Datenquelle und Protokolltyp. Weitere Informationen zu Aufnahmemethoden finden Sie unter Übersicht über die Datenaufnahme. In der API-Referenz zur Feedverwaltung werden spezifische Überlegungen für Protokolltypen wie Microsoft Graph, SentinelOne, Okta und CrowdStrike beschrieben.

Verarbeitungszeit von Google SecOps

Das System verarbeitet neu aufgenommene Daten in mehreren Schritten. Die Dauer dieser Schritte bestimmt, wann neu aufgenommene Daten für Abfragen und Analysen verfügbar sind.

In der folgenden Tabelle sind die Verarbeitungsschritte für neu aufgenommene Daten nach Suchmethode aufgeschlüsselt. Neu aufgenommene Daten können durchsucht werden, nachdem diese Schritte abgeschlossen sind.

Suchmethode Durchsuchte Daten Verarbeitungsschritte, die zur Verfügbarkeitszeit beitragen
Normalisierte und angereicherte UDM-Ereignisse
  1. Aufnahme: Das Protokoll kommt am Aufnahmepunkt von Google SecOps an.
  2. Parsing: Das Rohprotokoll wird von seinem spezifischen Parser identifiziert und verarbeitet.
  3. Normalisierung: Daten werden extrahiert und dem UDM-Schema zugeordnet.
  4. Indexierung (UDM): Der normalisierte UDM-Datensatz wird für die schnelle, strukturierte Suche indexiert.
  5. Anreicherung: Kontext (Threat Intelligence, Geostandort, Nutzer- oder Assetdaten) wird hinzugefügt.
Rohlogsuche Ursprünglicher, nicht geparster Protokolltext
  1. Aufnahme: Das Protokoll kommt am Aufnahmepunkt von Google SecOps an.
Detection Engine (Regeln) Normalisierte Ereignisse
  1. Verfügbarkeit von UDM-Ereignissen: Gleiche Schritte wie für die UDM-Suche.
  2. Erkennungsauswertung: Die Rules Engine wertet Protokolle in „Mikro-Batches“ aus und löst in der Regel innerhalb von 5 bis 10 Minuten nach dem Eintreffen des Ereignisses Erkennungen aus.
SOAR-Suche Cases und Entitäten Dies ist ein anderer Lebenszyklus, da nach Benachrichtigungen und Cases und nicht nach Protokollen gesucht wird. Die Zeit basiert auf:
  1. Verfügbarkeit von UDM-Ereignissen: Es werden die gleichen Verarbeitungsschritte wie für die UDM-Suche verwendet.
  2. Erkennung: Eine Detection Engine-Regel muss mit den UDM-Ereignissen übereinstimmen.
  3. Benachrichtigungserstellung: Das System erstellt eine formale Benachrichtigung aus der Erkennung.
  4. Case-Erstellung: Die SOAR-Plattform nimmt die Benachrichtigung auf und erstellt einen Case.

Beispiel für den Datenfluss

Das folgende Beispiel zeigt, wie Google SecOps Ihre Sicherheitsdaten aufnimmt, verarbeitet, anreichert und analysiert, damit sie für Suchen und weitere Analysen verfügbar sind.

Beispiel für Datenverarbeitungsschritte

  1. Ruft Sicherheitsdaten aus Cloud-Diensten wie Amazon S3 oder aus dem Google Cloudab. Google SecOps verschlüsselt diese Daten bei der Übertragung.
  2. Trennt und speichert Ihre verschlüsselten Sicherheitsdaten in Ihrem Konto. Der Zugriff ist auf Sie und eine kleine Anzahl von Google-Mitarbeitern für Produktsupport, Entwicklung und Wartung beschränkt.
  3. Parst und validiert Sicherheitsrohdaten, um die Verarbeitung und Anzeige zu erleichtern.
  4. Normalisiert und indexiert die Daten für schnelle Suchen.
  5. Speichert die geparsten und indexierten Daten in Ihrem Konto.
  6. Reichert sie mit Kontextdaten an.
  7. Bietet Nutzern sicheren Zugriff, um ihre Sicherheitsdaten zu durchsuchen und zu überprüfen.
  8. Vergleicht Ihre Sicherheitsdaten mit der Google Threat Intelligence-Malware-Datenbank, um Übereinstimmungen zu finden. Klicken Sie in einer Google SecOps-Ereignisansicht, z. B. in der Assetansicht, auf VT-Kontext , um Informationen von Google Threat Intelligence zu sehen. Google SecOps gibt Ihre Sicherheitsdaten nicht an Google Threat Intelligence weiter.

Datenfluss und ‑verarbeitung für Google SecOps

Beispiele für die erwartete Zeit bis zur Verfügbarkeit für die Suche

Die erwartete Zeit bis zur Verfügbarkeit der neu aufgenommenen Daten für die Suche ist die Summe der Flussdauern entlang des Datenflusses.

Eine typische durchschnittliche Zeit für die Datenverfügbarkeit in der UDM-Suche beträgt beispielsweise etwa 5 Minuten und 30 Sekunden ab dem Zeitpunkt, an dem die Daten an den Google SecOps-Aufnahmedienst gesendet werden.

Datenflussschritt Beschreibung Flussdauer
Cloud Storage zu Rohprotokolle Nimmt Rohprotokolle aus Cloud Storage auf. Weniger als 30 Sekunden
Sicherheitsprotokolle zu Datenweiterleitungsdienst Überträgt Sicherheitsprotokolle aus internen Systemen an die Plattform. –
Datenweiterleitungsdienst zu Rohprotokolle Sendet Sicherheitsrohdaten aus verschiedenen Quellen an die Aufnahmepipeline. Weniger als 30 Sekunden
Rohprotokolle zu Parsen und validieren Parst und validiert Rohprotokolle im UDM-Format. Weniger als 3 Minuten
Parsen und validieren zu Index Indexiert die geparsten UDM-Daten für schnelle Suchen. –
Index zu Geparsste Kundendaten Stellt die indexierten Daten als geparste Kundendaten für die Analyse zur Verfügung. Weniger als 2 Minuten

Fehlerbehebung

In diesem Abschnitt finden Sie Tipps zur Fehlerbehebung.

Latenz und Limits

Verzögerungen bei der Verarbeitung und Visualisierung auf der Google SecOps-Plattform unterliegen den folgenden architektonischen Limits, nachdem Google SecOps die Daten erhalten hat:

  • Suchverfügbarkeit: 2 bis 15 Minuten nach der Aufnahme.
  • Regelausführung: 5 bis 10 Minuten nach dem Eintreffen des Ereignisses.
  • UI-Visualisierung: Um die Browserleistung aufrechtzuerhalten, gilt für große Mengen von Protokolldaten ein Visualisierungslimit von 10.000 Zeilen.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten