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 Security Operations 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 entweder als unstrukturierte Protokolle oder als vorformatierte UDM-Ereignisse (Unified Data Model) 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 Drittanbieter-APIs (wie Okta oder Microsoft 365).

Normalisierung und Datenanreicherung

Sobald Daten in Google SecOps eingehen, werden sie 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 Protokollentitäten 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. EKG-Anreicherung

    • Google SecOps führt EKG-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.

    • Bedrohungsinformationen: Google SecOps vergleicht Ereignisdaten automatisch mit den umfangreichen Bedrohungsinformationen 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 Echtzeitdaten aus, um Bedrohungen zu identifizieren und Benachrichtigungen zu generieren.

  • Suche und Untersuchung

    Ein Analyst kann die Suchmethoden verwenden, um alle 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 einen anderen Zweck erfüllen.

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 dem ursprünglichen, nicht geparsten Logeintrag 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 =. Sie 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 Fällen und Entitäten (z. B. Nutzern, Assets, IP-Adressen) gesucht.
  • Funktionsweise: Sie können Freitext- oder feldbezogene Filter verwenden, um Fälle z. B. nach ID, Benachrichtigungsname, Status und zugewiesenem Nutzer zu finden.
  • Beispiel: Suchen Sie nach CaseIds:180 oder AlertName:Brute Force.

Datenaufnahmepipeline zur Suchverfügbarkeit

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, Standortbestimmung, 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 „Micro-Batches“ aus und löst in der Regel innerhalb von 5 bis 10 Minuten nach dem Eintreffen des Ereignisses Erkennungen aus.
SOAR-Suche Fälle und Entitäten Dies ist ein anderer Lebenszyklus, da nach Benachrichtigungen und Fällen und nicht nach Protokollen gesucht wird. Die Zeit basiert auf:
  1. Verfügbarkeit von UDM-Ereignissen: Es werden dieselben 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 aus der Erkennung eine formale Benachrichtigung.
  4. Fall erstellen: Die SOAR-Plattform nimmt die Benachrichtigung auf und erstellt einen Fall.

Beispiel für den Datenfluss

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

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 Rohsicherheitsdaten, 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 der Suche

Die erwartete Zeit, bis die neu aufgenommenen Daten für die Suche verfügbar sind, ist die Summe der Flussdauern entlang des Datenflusses.

Die 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 aus verschiedenen Quellen empfangene Rohsicherheitsdaten 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 die schnelle Suche. –
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 in Google SecOps unterliegen den folgenden architektonischen Limits:

  • Sichtbarkeit der Suche: 2 bis 15 Minuten nach der Aufnahme.
  • Regelausführung: 5 bis 10 Minuten nach dem Eintreffen des Ereignisses.
  • UI-Visualisierung: Für Protokolldaten mit hohem Volumen gilt ein Visualisierungslimit von 10.000 Zeilen,um die Browserleistung aufrechtzuerhalten.

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