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 Pipeline für die Datenaufnahme beginnt mit dem Erfassen Ihrer Sicherheitsrohdaten aus Quellen wie:

  • Sicherheitsprotokolle aus Ihren internen Systemen
  • In Cloud Storage gespeicherte Daten
  • Ihr Security Operations Center (SOC) und andere interne Systeme

Google SecOps überträgt diese Daten über eine der sicheren Aufnahmemethoden auf die Plattform.

Die primären Methoden für die Aufnahme sind:

  • Google Cloud Direkte Aufnahme

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

  • Ingestion APIs

    Senden Sie Daten direkt an Google SecOps über die öffentlichen REST-Ingestion APIs. Sie verwenden diese Methode für benutzerdefinierte Integrationen oder um Daten als unstrukturierte Logs oder 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 Logs aus einer Vielzahl von Quellen zu erfassen und an Google SecOps weiterzuleiten.

  • Datenfeeds

    In Google SecOps konfigurieren Sie Datenfeeds, um Logs aus Drittanbieterquellen abzurufen, z. B. aus bestimmten Drittanbieter-Cloud-Speicher-Buckets (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 Logrohdaten, um die Daten aus ihrem ursprünglichen Format in das standardisierte UDM zu validieren, zu extrahieren und zu transformieren. Mit Parsing und Normalisierung können Sie unterschiedliche Datenquellen (z. B. Firewall-Logs, Endpunktdaten, Cloud-Logs) 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 riesige Datasets zu ermöglichen. So können UDM-Ereignisse durchsucht werden.

  3. UDM-Aliasing und ‑Anreicherung

    • In Google SecOps werden UDM-Aliasing und ‑Anreicherung durchgeführt, um UDM-Ereignisse mit wertvollem Kontext anzureichern. Dazu werden Kontextdaten und Indikatoren für Protokollentitäten ermittelt und hinzugefügt. So wird beispielsweise das login name eines Nutzers mit seinen verschiedenen IP addresses, hostnames und MAC addresses verknüpft.
    • Geolokalisierung:In Google SecOps werden IP-Adressen mit Geolokalisierungsdaten angereichert.

  4. EKG-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ätskontextdiagramm zu 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 erkennen.

    • 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:

  • Erkennung in Echtzeit

    Die Detection Engine führt automatisch benutzerdefinierte und von Google entwickelte Regeln, für die Live Rule aktiviert ist, für eingehende Live-Daten aus, um Bedrohungen zu erkennen und Benachrichtigungen zu generieren.

  • Suche und Untersuchung

    Ein Analyst kann die Suchmethoden verwenden, um alle diese normalisierten und angereicherten Daten zu durchsuchen. Sie können beispielsweise die UDM-Suche verwenden, um zwischen verknüpften Einheiten zu wechseln (z. B. von einem user zu seinem asset zu einem schädlichen domain) und Benachrichtigungen zu untersuchen.

Suchmethoden

Google SecOps bietet verschiedene Methoden zum Suchen in Ihren Daten, die jeweils einem anderen Zweck dienen.

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

  • Was wird durchsucht?:Es werden die normalisierten und indexierten UDM-Ereignisse abgefragt. Da alle Daten in dieses Standardformat geparst werden, können Sie eine einzige 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"

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

Verwenden Sie die Rohlogsuche, um etwas im ursprünglichen, nicht geparsten Logeintrag zu finden, das möglicherweise keinem UDM-Feld zugeordnet wurde. Diese Suchmethode ist für schnelle Untersuchungen 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, unformatierte Text der Logs wird vor dem Parsen und Normalisieren gescannt. 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 =. Die Suche kann langsamer sein als die UDM-Suche, 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 auf der Plattform statistische Analysen und Gruppierungen durchgeführt werden müssen, kann es bei diesen Abfragen zu längeren Ladezeiten kommen.

Suche in natürlicher Sprache (Gemini)

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

  • Wonach wird gesucht?: Es wird eine Konversationsschnittstelle zum Abfragen von UDM-Daten bereitgestellt.
  • So funktioniert es: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. Es wird zum Verwalten von Sicherheitsvorfällen verwendet, nicht zum Suchen in Protokollen.

  • Wonach wird gesucht? Es wird in der SOAR-Plattform nach Fällen und Entitäten (z. B. Nutzer, Assets, IP-Adressen) gesucht.
  • Funktionsweise:Sie können Freitext- oder feldbezogene Filter verwenden, um Fälle anhand von beispielsweise ID, Warnungsname, Status und zugewiesenem Nutzer zu finden.
  • Beispiel:Suche nach CaseIds:180 oder AlertName:Brute Force

Pipeline zur Datenaufnahme für die Suchverfügbarkeit

Die End-to-End-Datenverfügbarkeit ist die Gesamtzeit zwischen dem Eintreten eines Ereignisses und dem Zeitpunkt, zu 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 Eintreten eines Ereignisses und dem Zeitpunkt, zu dem das Quellsystem die Protokolldaten für die Aufnahme zur Verfügung stellt. Diese Verzögerung hängt von der Architektur, Verarbeitung, Batching und den API-Veröffentlichungszeitplänen des Quellsystems ab. Google SecOps kann diese Verzögerung nicht beeinflussen. Beispiele sind Verzögerungen, wenn ein System Logs in einen Speicher-Bucket schreibt oder an einen API-Endpunkt sendet.

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

Sie müssen beide Komponenten berücksichtigen, wenn Sie Probleme mit der Datenansicht beheben.

Verzögerungen aufgrund der Datenquelle

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

  • Batchverarbeitung:Einige Systeme generieren Logs in Batches in festgelegten Intervallen (z. B. stündlich).
  • API-Latenz: Bei der Quell-API kann es zu Verzögerungen kommen, bis neue Ereignisse abgefragt werden können.
  • Zeitpunkt der Ereigniserstellung und -veröffentlichung:Der Zeitstempel eines Ereignisses in einem Log kann viel früher sein als der Zeitstempel, zu dem das Log fertiggestellt und für die Erfassung verfügbar wird.
  • Drosselung:API-Ratenbegrenzungen auf der Quellseite können den Datenabruf verlangsamen.
  • Erster Backfill:Die Bereitstellung und Aufnahme großer Mengen von Verlaufsdaten dauert.

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

Bearbeitungszeit von Google SecOps

Neu aufgenommene Daten werden in mehreren Schritten verarbeitet. 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 sind erst durchsuchbar, wenn diese Schritte abgeschlossen sind.

Suchmethode Daten, die durchsucht werden Verarbeitungsschritte, die zur Verfügbarkeitszeit beitragen
Normalisierte und angereicherte UDM-Ereignisse
  1. Aufnahme:Der Log wird am Google SecOps-Aufnahmepunkt empfangen.
  2. Parsing:Das Rohlog wird durch den entsprechenden 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:Es wird Kontext hinzugefügt, z. B. Threat Intelligence, Standortbestimmung, Nutzer- oder Asset-Daten.
Rohlogsuche Originaler, nicht geparster Logtext
  1. Aufnahme:Der Log wird am Google SecOps-Aufnahmepunkt empfangen.
Detection Engine (Regeln) Normalisierte Ereignisse
  1. Verfügbarkeit von UDM-Ereignissen:Die Schritte sind dieselben wie für die UDM-Suche.
  2. Erkennungsauswertung:Die Rules Engine wertet Logs in „Mikro-Batches“ aus und löst Erkennungen in der Regel innerhalb von 5 bis 10 Minuten nach Eintreffen des Ereignisses aus.
SOAR-Suche Fälle und Rechtssubjekte Das ist ein anderer Lebenszyklus, da nach Benachrichtigungen und Fällen und nicht nach Logs gesucht wird. Die Zeit basiert auf:
  1. Verfügbarkeit von UDM-Ereignissen:Hier werden dieselben Verarbeitungsschritte wie für die UDM-Suche verwendet.
  2. Erkennung:Eine Detection Engine-Regel muss mit den UDM-Ereignissen übereinstimmen.
  3. Benachrichtigung erstellen:Das System erstellt aus der Erkennung eine formelle Benachrichtigung.
  4. Fallerstellung:Die SOAR-Plattform erfasst die Benachrichtigung und erstellt einen Fall.

Beispiel für Datenfluss

Das folgende Beispiel zeigt, wie Google SecOps Ihre Sicherheitsdaten aufnimmt, verarbeitet, anreichert und analysiert und sie für Suchvorgänge und weitere Analysen zur Verfügung stellt.

Beispiel für Datenverarbeitungsschritte

  1. Ruft Sicherheitsdaten aus Cloud-Diensten wie Amazon S3 oder aus demGoogle Cloudab. Google SecOps verschlüsselt diese Daten bei der Übertragung.
  2. Ihre verschlüsselten Sicherheitsdaten werden in Ihrem Konto getrennt gespeichert. Der Zugriff ist auf Sie und eine kleine Anzahl von Google-Mitarbeitern für Produktsupport, Entwicklung und Wartung beschränkt.
  3. Rohe Sicherheitsdaten werden geparst und validiert, sodass sie leichter zu verarbeiten und anzusehen sind.
  4. Normalisiert und indexiert die Daten für schnelle Suchvorgänge.
  5. Die geparsten und indexierten Daten werden in Ihrem Konto gespeichert.
  6. Mit Kontextdaten anreichern.
  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. der Asset-Ansicht, auf VT Context (VT-Kontext), um Informationen zu Google Threat Intelligence aufzurufen. 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 durchschnittliche Zeit, bis Daten in der UDM-Suche verfügbar sind, 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 Dauer des Flows
Cloud Storage in Rohlogs Rohe Logs werden aus Cloud Storage aufgenommen. Weniger als 30 Sekunden
Sicherheitsprotokolle an den Dienst zur Datenweiterleitung Überträgt Sicherheitslogs von internen Systemen an die Plattform. –
Dienst zur Datenweiterleitung zu Rohlogs Sendet Rohdaten zur Sicherheit, die aus verschiedenen Quellen stammen, an die Aufnahmepipeline. Weniger als 30 Sekunden
Rohprotokolle bis Parsen und validieren Rohlogs werden geparst und in das UDM-Format validiert. Weniger als 3 Minuten
Parsen und validieren bis Index Indexiert die geparsten UDM-Daten für die schnelle Suche. –
Index für geparste 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 Hinweise zur Fehlerbehebung.

Latenz und Limits

Verarbeitungs- und Visualisierungsverzögerungen innerhalb der Google SecOps-Plattform unterliegen nach dem Empfang der Daten durch Google SecOps den folgenden architektonischen Einschränkungen:

  • Sichtbarkeit in der Suche:2 bis 15 Minuten nach der Aufnahme.
  • Regelausführung:5 bis 10 Minuten nach Eintreffen des Ereignisses.

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