Datenverfügbarkeit für die Suche

Unterstützt in:

Google SecOps

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 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 Erheben 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 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-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 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. 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:

• Echtzeiterkennung

  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 einer user zu ihrer 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.

UDM-Suche

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.
• So funktioniert es: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 innerhalb von 2 bis 15 Minuten nach der Aufnahme verfügbar.

Rohlogsuche

Mit der Rohlog-Suche können Sie in der ursprünglichen, nicht geparsten Log-Nachricht nach etwas suchen, das möglicherweise keinem UDM-Feld zugeordnet wurde. Diese Suchmethode ist für schnelle Untersuchungen optimiert und liefert in der Regel innerhalb von zwei Sekunden Ergebnisse für bestimmte Indikatoren wie Dateihashes oder IP-Adressen.

• 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.
• 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\$/

Statistiksuche

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, ist mit längeren Ladezeiten für diese Abfragen zu rechnen.

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

SOAR-Suche

Die SOAR-Suche ist spezifisch für SOAR-Komponenten. Sie verwenden es zum Verwalten von Sicherheitsvorfällen, nicht zum Suchen in Logs.

• 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 z. B. nach ID, Benachrichtigungsname, Status und zugewiesenem Nutzer zu suchen.
• Beispiel:Suche nach CaseIds:180 oder AlertName:Brute Force

Pipeline für die Datenaufnahme zur 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 Ausführung von Regeln 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.

Bei der Fehlerbehebung in Bezug auf die Zeitachse für die Datensichtbarkeit müssen Sie beide Komponenten berücksichtigen.

Verzögerungen aufgrund der Datenquelle

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

• Batchverarbeitung:Einige Systeme generieren Logs 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: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:Das Bereitstellen und Erfassen großer Mengen von Verlaufsdaten dauert seine Zeit.

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

Bearbeitungszeit 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 sind erst durchsuchbar, wenn diese Schritte abgeschlossen sind.

Suchmethode	Daten, die durchsucht werden	Verarbeitungsschritte, die zur Verfügbarkeitszeit beitragen
UDM-Suche Suche in natürlicher Sprache (Gemini)	Normalisierte und angereicherte UDM-Ereignisse	Aufnahme:Der Log wird am Google SecOps-Aufnahmepunkt empfangen. Parsing:Das Rohlog wird identifiziert und von seinem spezifischen Parser verarbeitet. Normalisierung:Daten werden extrahiert und dem UDM-Schema zugeordnet. Indexierung (UDM): Der normalisierte UDM-Datensatz wird für die schnelle, strukturierte Suche indexiert. Anreicherung:Es wird Kontext hinzugefügt, z. B. Informationen zu Bedrohungen, Geolocation, Nutzer- oder Asset-Daten.
Rohlogsuche	Originaler, nicht geparster Log-Text	Aufnahme:Der Log wird am Google SecOps-Aufnahmepunkt empfangen.
Detection Engine (Regeln)	Normalisierte Ereignisse	Verfügbarkeit von UDM-Ereignissen:Die Schritte sind dieselben wie für die UDM-Suche. 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 Entitäten	Das ist ein anderer Lebenszyklus, da hier nach Warnungen und Fällen und nicht nach Logs gesucht wird. Die Zeit basiert auf: Verfügbarkeit von UDM-Ereignissen:Hier werden dieselben Verarbeitungsschritte wie für die „UDM-Suche“ verwendet. Erkennung:Eine Detection Engine-Regel muss mit den UDM-Ereignissen übereinstimmen. Benachrichtigung erstellen:Das System erstellt aus der Erkennung eine formelle Benachrichtigung. Fall erstellen: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. Rohdaten zur Sicherheit 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 Malware-Datenbank von Google Threat Intelligence, 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. Ihre Sicherheitsdaten werden in Google SecOps nicht an Google Threat Intelligence weitergegeben.

Beispiele für die erwartete Zeit bis zur Verfügbarkeit in 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, zu dem die Daten an den Google SecOps-Aufnahmedienst gesendet werden.

Datenflussschritt	Beschreibung	Dauer des Flows
Cloud Storage – 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

Fehlerbehebung

In diesem Abschnitt finden Sie Anleitungen 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.
• UI-Visualisierung:Um die Browserleistung aufrechtzuerhalten, unterliegen Logdaten mit hohem Volumen einem Visualisierungslimit von 10.000 Zeilen.

Hinweis :Diese Zeiten beginnen, nachdem Google SecOps die Daten empfangen hat. Die End-to-End-Datenverfügbarkeit hängt auch von Verzögerungen ab, die durch die Datenquelle verursacht werden, bevor die Daten in die Google SecOps-Pipeline gelangen.

Achtung :Wenn eine Änderung nicht sofort in der Benutzeroberfläche angezeigt wird, bedeutet das nicht unbedingt, dass die Synchronisierung fehlgeschlagen ist. Wenn das Ereignis bei der Suche vor weniger als 15 Minuten oder bei Regeln vor weniger als 10 Minuten aufgetreten ist, werden die Daten wahrscheinlich noch in der Standardverarbeitungspipeline verarbeitet. Die Verzögerung ist kein Hinweis auf einen Systemausfall.

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