Datenverfügbarkeit für die Suche

Unterstützt in:

In diesem Dokument wird der Lebenszyklus der Datenerfassung 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 erfassten 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 Pipeline für die Datenaufnahme beginnt mit dem Erheben Ihrer Sicherheitsrohdaten aus Quellen wie:

  • Sicherheitslogs 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 Cloud

    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-Storage-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

    Logrohdaten werden zuerst von einem Parser verarbeitet, um die Daten aus dem 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 Rohlog wird zusammen mit dem UDM-Ereignis gespeichert.

  2. Indexierung

    Nach der Normalisierung indexiert Google SecOps die UDM-Daten, um schnelle Abfragegeschwindigkeiten für umfangreiche Datasets zu ermöglichen. So können UDM-Ereignisse durchsucht werden. Außerdem werden die ursprünglichen Rohlogs für „Rohlog“-Suchanfragen indexiert.

  3. Datenanreicherung

    Google SecOps reichert Ihre Daten auf folgende Weise mit wertvollem Kontext an:

    • Entitätskontext (Aliasing): Beim Aliasing werden UDM-Logdatensätze angereichert, indem Kontextdaten und Indikatoren für Logentitäten ermittelt und hinzugefügt werden. So wird beispielsweise der Anmeldename eines Nutzers mit seinen verschiedenen IP-Adressen, Hostnamen und MAC-Adressen verknüpft, um ein konsolidiertes „Entitätsdiagramm“ zu erstellen.
    • Bedrohungsinformationen:Daten werden automatisch mit den umfangreichen Bedrohungsinformationen von Google verglichen, einschließlich Quellen wie VirusTotal und Safe Browsing, um bekannte schädliche Domains, IP-Adressen, Dateihashes und mehr zu identifizieren.
    • Standortbestimmung:IP-Adressen werden mit Standortdaten angereichert.
    • WHOIS:Domainnamen werden mit ihren öffentlichen WHOIS-Registrierungsinformationen angereichert.

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 mit Live Rule-Unterstützung 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 Durchsuchen Ihrer 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"

Mit der Rohlogsuche können Sie nach etwas in der ursprünglichen, nicht geparsten Log-Nachricht suchen, das möglicherweise keinem UDM-Feld zugeordnet wurde.

  • Wonach wird gesucht?:Es wird der ursprüngliche, unformatierte Text der Logs gescannt, bevor er geparst und normalisiert wurde. Das ist nützlich, um bestimmte Strings, Befehlszeilenargumente oder andere Artefakte zu finden, die keine indexierten UDM-Felder sind.
  • So gehts: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\$/

Suche in natürlicher Sprache (Gemini)

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

  • 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 Log-ins des Nutzers ‚bob‘ in den letzten 24 Stunden.“

Die SOAR-Suche ist spezifisch für SOAR-Komponenten. Sie verwenden es, um Sicherheitsvorfälle zu verwalten, nicht um in Logs zu suchen.

  • Was wird durchsucht?:Die SOAR-Plattform wird nach Fällen und Entitäten (z. B. Nutzer, Assets, IPs) durchsucht.
  • Funktionsweise:Sie können Freitext- oder feldbezogene Filter verwenden, um Fälle z. B. nach ID, Benachrichtigungsname, Status und zugewiesenem Nutzer zu suchen.
  • Beispiel:Suche nach CaseIds:180 oder AlertName:Brute Force

Pipeline zur Datenaufnahme für die 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 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 Rohprotokoll wird identifiziert und von seinem spezifischen Parser 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. Informationen zu Bedrohungen, Geolocation, Nutzer- oder Asset-Daten.
Rohlogsuche Originaler, nicht geparster Log-Text
  1. Aufnahme:Der Log wird am Google SecOps-Aufnahmepunkt empfangen.
  2. Indexierung (Rohdaten): Der ursprüngliche Textstring des Logs wird indexiert.
SOAR-Suche Fälle und Entitäten Das ist ein anderer Lebenszyklus, da nach Warnungen 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. Fall erstellen:Die SOAR-Plattform nimmt die Benachrichtigung auf 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 von Cloud-Diensten wie Amazon S3 oder von derGoogle 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, was die Verarbeitung und Anzeige erleichtert.
  4. Normalisiert und indexiert die Daten für schnelle Suchvorgänge.
  5. Speichert die geparsten und indexierten Daten in Ihrem Konto.
  6. Mit Kontextdaten anreichern
  7. Bietet Nutzern sicheren Zugriff, um ihre Sicherheitsdaten zu durchsuchen und zu überprüfen.
  8. Vergleicht Ihre Sicherheitsdaten mit der VirusTotal-Malware-Datenbank, um Übereinstimmungen zu finden. Klicken Sie in einer Google SecOps-Ereignisansicht, z. B. der Asset-Ansicht, auf VT-Kontext, um VirusTotal-Informationen aufzurufen. Google SecOps gibt Ihre Sicherheitsdaten nicht an VirusTotal 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 Ablaufs
Cloud Storage zu Rohlogs Rohlogs werden aus Cloud Storage aufgenommen. Weniger als 30 Sekunden
Sicherheitslogs an den Dienst zur Datenweiterleitung Überträgt Sicherheitslogs von internen Systemen an die Plattform. –
Data Forwarding Service für Rohdaten-Logs Sendet Rohdaten zur Sicherheit, die aus verschiedenen Quellen stammen, an die Aufnahmepipeline. Weniger als 30 Sekunden
Rohlogs bis Parsen und validieren Rohlogs werden geparst und in das UDM-Format validiert. Weniger als 3 Minuten
Parsen und validieren bis Index Die geparsten UDM-Daten werden für die schnelle Suche indexiert. –
Index für geparste Kundendaten Die indexierten Daten werden als geparste Kundendaten für die Analyse zur Verfügung gestellt. Weniger als 2 Minuten

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