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

    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 Log-Entitä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. Identitätsanbietern, CMDBs und Threat Intelligence) zusammengeführt wird, um ein konsolidiertes Entitätsprofil im Entitätskontextdiagramm zu erstellen.

    • Bedrohungsanalyse:Google SecOps vergleicht Ereignisdaten automatisch mit der umfangreichen Bedrohungsanalyse von Google, einschließlich Quellen wie VirusTotal 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 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 Rohlog-Suche 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.
  • 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 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, IP-Adressen) 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 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. Informationen zu Bedrohungen, Geolocation, Nutzer- oder Asset-Daten.
Rohlogsuche Originaler, nicht geparster Log-Text
  1. Aufnahme:Der Log wird am Google SecOps-Aufnahmepunkt empfangen.
SOAR-Suche Fälle und Rechtssubjekte Das ist ein anderer Lebenszyklus, da hier 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. 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 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. 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 Flows
Cloud Storage in 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