Anreicherung konfigurieren

Unterstützt in:

Bei der Anreicherung werden die folgenden Methoden verwendet, um einem UDM-Indikator oder ‑Ereignis Kontext hinzuzufügen:

  • Kennzeichnet Alias-Entitäten, die einen Indikator beschreiben, in der Regel ein UDM-Feld.
  • Die UDM-Nachricht wird mit zusätzlichen Details aus den identifizierten Aliasen oder Entitäten gefüllt.
  • Fügt UDM-Ereignissen globale Anreicherungsdaten wie GeoIP und VirusTotal hinzu.

Termine ansehen

Sehen Sie sich die Ereignisse auf dem Tab Ereignisfelder der Ereignisanzeige an. Auf diesem Tab werden UDM-Ereignisfelder in einer hierarchischen Baumstruktur mit dem Label Ausgewählt angezeigt. Jedes UDM-Feld ist mit einem Symbol gekennzeichnet, das angibt, ob das Feld angereicherte oder nicht angereicherte Daten enthält. Die Symbolbeschriftungen sind:

  • U: Für nicht angereicherte Felder werden Werte während der Normalisierung direkt aus dem ursprünglichen Rohlog abgerufen.
  • E: Angereicherte Felder enthalten Werte, die von Google SecOps generiert werden, um zusätzlichen Kontext zu Artefakten in Ihrer Umgebung bereitzustellen.

In angereicherten Feldern werden alle zugehörigen Quellen angezeigt, um Sie bei der Validierung, Fehlerbehebung, Prüfung und Compliance zu unterstützen. Sie können Felder auch nach der Anreicherungsquelle filtern, um die Ansicht einzugrenzen.

Logikmuster für die Anreicherung verstehen

Google SecOps wendet je nach Anreicherungstyp unterschiedliche logische Muster auf Daten an. In der folgenden Tabelle finden Sie Informationen zu diesen Mustern, die Ihnen bei der Fehlerbehebung helfen und erklären, warum bestimmte Felder ausgefüllt, zusammengeführt oder überschrieben werden.

Logikmuster Beschreibung Anwendbare Anreicherung
Erstes Spiel Es wird eine strikte Prioritätenliste eingehalten. In der Pipeline wird nur der erste verfügbare Wert abgefragt, der in der Sequenz gefunden wird. Artefakt (Datei-Hashes)
Zusammengeführt Erfasst und kombiniert Daten aus mehreren Feldern gleichzeitig, um einen einzigen „goldenen“ Datensatz zu erstellen. Asset, Nutzer
Bedingter Fallback Ein bestimmtes Feld wird nur zur Anreicherung verwendet, wenn eine Kennung mit höherer Priorität fehlt. Asset (ip-Adresse)
Zuordnen und überschreiben Verwendet eine eindeutige ID (PSPI), um Entitäten aufzulösen. Aliasdaten aus der Anreicherungsquelle ersetzen vorhandene geparste Daten. Prozess

Asset-Anreicherung

Bei der Asset-Anreicherung werden eindeutige Assets durch Auswertung mehrerer UDM-Felder identifiziert. Im Gegensatz zur Artefaktanreicherung, bei der eine ID ausgewählt wird, werden bei der Asset-Anreicherung Kontextinformationen aus mehreren IDs zusammengeführt, um ein vollständiges Asset-Profil zu erstellen.

Google SecOps reichert Asset-Ereignisse an, die mit demselben Namespace klassifiziert sind.

Bei Assets ist die Logik kumulativ und nicht exklusiv, mit Ausnahme bestimmter Fallbackszenarien. Verwenden Sie diese Details für die Erklärung:

  • Logiktyp: „Zusammengeführt“ oder „Fallback“. Die Pipeline erfasst Daten aus allen verfügbaren Feldern, um eine einzelne Ansicht „Entität“ zu erstellen, sofern keine Fallback-Bedingung (z. B. die asset_id-Prüfung) erfüllt ist.
  • Feldzuordnungen:
    • Hostname, MAC und asset_id: Werden als primäre IDs behandelt. Die Aliasing-Ergebnisse aus all diesen Feldern werden zusammengeführt, um das endgültige angereicherte Asset-Profil zu erstellen.
    • IP-Adresse: Wird nur in die Anreicherungsanfrage aufgenommen, wenn asset_id nicht verfügbar ist.

Für jedes Asset-Ereignis werden mit der Pipeline die folgenden UDM-Felder aus den Entitäten principal, src und target extrahiert:

UDM-Feld Indikatortyp Logik / Vorrang
hostname HOSTNAME Zusammengeführt: Die Alias-Ergebnisse aus diesen Feldern werden kombiniert, um den endgültigen angereicherten Asset-Datensatz zu erstellen.
asset_id PRODUCT_SPECIFIC_ID Zusammengeführt: Primäre Kennung, die zum Zusammenführen des Asset-Kontexts verwendet wird.
mac MAC Zusammengeführt: Wird in Verbindung mit anderen Kennungen verwendet, um das Asset aufzulösen.
ip IP-Adresse Fallback: Wird nur in die Anreicherungsanfrage aufgenommen, wenn asset_id nicht verfügbar ist.

Nutzeranreicherung

Bei der Nutzeranreicherung werden Identitätsdaten durch die Suche nach bestimmten Kennungen aufgelöst. Wie beim Anreichern von Artefakten wird in dieser Pipeline eine Reihenfolge verwendet, um zu bestimmen, welche Kennung als Primärschlüssel für die Suche verwendet wird.

Für jedes Nutzerereignis werden die folgenden UDM-Felder aus principal, src und target extrahiert:

UDM-Feld Indikatortyp Logik oder Vorrang
user.email_addresses E-MAIL Höchste Priorität:Die Pipeline versucht zuerst, die Daten anhand der primären oder sekundären E-Mail-Adressen des Nutzers anzureichern.
user.windows_sid WINDOWS_SID Zweite Priorität:Wenn keine E‑Mail-Adresse verfügbar ist, wird die Windows-Sicherheits-ID (SID) verwendet.
user.userid USER_ID Dritte Priorität:Wird nur verwendet, wenn E‑Mail-Adresse und SID fehlen. Wird in der Regel lokalen oder anwendungsspezifischen IDs zugeordnet.
user.employee_id EMPLOYEE_ID Niedrigste Priorität:Der letzte Fallback für die Auflösung einer Nutzeridentität.

Für jeden Indikator führt die Pipeline die folgenden Aktionen aus:

  • Ruft eine Liste von Nutzerentitäten ab. Die Entitäten von principal.email_address und principal.userid können beispielsweise identisch oder unterschiedlich sein.
  • Wählt die Aliase des Indikatortyps mit der höchsten Priorität aus. Die Priorität ist in dieser Reihenfolge festgelegt: WINDOWS_SID, EMAIL, USERNAME, EMPLOYEE_ID und PRODUCT_OBJECT_ID.
  • noun.user wird mit der Organisationseinheit gefüllt, deren Gültigkeitszeitraum sich mit der Ereigniszeit überschneidet.

Prozessanreicherung

Bei der Prozessanreicherung geht es darum, Einblick in Ausführungsereignisse zu geben. In der Pipeline werden Prozessdetails extrahiert und durch Abgleich mit Dateireputationen und übergeordneten/untergeordneten Beziehungen angereichert.

Verwenden Sie die Prozessanreicherung, um eine produktspezifische Prozess-ID (product_specific_process_id) oder PSPI dem tatsächlichen Prozess zuzuordnen und Details zum übergeordneten Prozess abzurufen. Dieser Prozess basiert auf dem EDR-Ereignisbatchtyp.

UDM-Entität Feldquelle Logik oder Priorität
Primäre Entitäten principal, src, target Extraktion:In der Pipeline wird die PSPI aus diesen Einheiten auf oberster Ebene extrahiert, um die Suche zu starten.
Übergeordnete Prozesse principal.process.parent_process,
src.process.parent_process,
target.process.parent_process 		Zuordnung:Der PSPI ruft mit der Prozessaliasierung Details zum übergeordneten Prozess ab.
Daten zusammenführen noun.process (z. B. principal.process) Überschreibungsregel:Aliasfelder haben absolute Priorität. Wenn sowohl geparste als auch aliasierte Daten für dasselbe Feld vorhanden sind, werden die geparsten Daten in der Pipeline durch die aliasierten Daten ersetzt.

Die Pipeline verwendet Prozess-Aliasing, um den tatsächlichen Prozess aus dem PSPI zu identifizieren und Informationen zum übergeordneten Prozess abzurufen. Anschließend werden diese Daten in das entsprechende Feld noun.process in der angereicherten Nachricht eingefügt.

EDR-indexierte Felder für Prozess-Aliasing

Wenn ein Prozess gestartet wird, erfasst das System Metadaten wie Befehlszeilen, Dateihashes und Details zum übergeordneten Prozess. Die EDR-Software, die auf dem Computer ausgeführt wird, weist eine anbieterspezifische Prozess-UUID zu.

In der folgenden Tabelle sind die Felder aufgeführt, die bei einem Prozessstartereignis indexiert werden:

UDM-Feld Indikatortyp
target.product_specific_process_id PROCESS_ID
target.process Gesamter Prozess, nicht nur der Indikator

Zusätzlich zum Feld target.process aus dem normalisierten Ereignis erfasst und indexiert Google SecOps Informationen zum übergeordneten Prozess.

Artefakt-Anreicherung

Bei der Artefaktanreicherung werden Metadaten für Dateihashes von VirusTotal und Standortbestimmungsdaten für IP-Adressen hinzugefügt. Bei Datei-Hashes wird die Pipeline beim ersten Wert beendet, der in einer priorisierten Liste gefunden wird. Bei IP-Adressen werden jedoch alle Einträge parallel verarbeitet. Für jedes UDM-Ereignis werden Kontextdaten für die folgenden Artefaktindikatoren aus den Entitäten principal, src und target extrahiert und abgefragt. Das Anreicherungsverhalten hängt dabei vom Indikatortyp ab:

Indikatortyp Extraktionslogik Vorrang / Reihenfolge von Operationen
Datei-Hashes Erstes Spiel Die Pipeline sucht in der folgenden Reihenfolge nach Hashes und wählt nur den ersten verfügbaren aus, um VirusTotal abzufragen:
  1. file.sha256
  2. file.sha1
  3. file.md5
  4. process.file.sha256
  5. process.file.sha1
  6. process.file.md5
IP-Adresse Parallel (wiederholt) Jede öffentliche oder routingfähige IP-Adresse wird als unabhängiger Eintrag behandelt. Es gibt keine Reihenfolge der Präferenz. Jede IP-Adresse erhält eigene Anreicherungsdaten.

In der Pipeline werden UNIX-Epoche und Ereignisstunde verwendet, um den Zeitraum für die Abfragen von Datei-Artefakten zu definieren. Wenn Daten zur Standortbestimmung verfügbar sind, werden die folgenden UDM-Felder für die Entitäten principal, src und target basierend auf dem Ursprung der Daten zur Standortbestimmung überschrieben:

  • artifact.ip
  • artifact.location
  • artifact.network (nur, wenn die Daten den IP-Netzwerkkontext enthalten)
  • location (nur, wenn die Originaldaten dieses Feld nicht enthalten)

Wenn in der Pipeline Metadaten zum Dateihash gefunden werden, werden diese Metadaten den Feldern „Datei“ oder process.file hinzugefügt, je nach Herkunft des Indikators. In der Pipeline werden alle vorhandenen Werte beibehalten, die sich nicht mit den neuen Daten überschneiden.

Anreicherung mit IP-Standortdaten

Durch geografisches Aliasing werden Standortdaten für externe IP-Adressen bereitgestellt. Für jede nicht aliasierte IP-Adresse im Feld principal, target oder src für ein UDM-Ereignis wird ein ip_geo_artifact-Subprotokollpuffer mit den zugehörigen Standort- und ASN-Informationen erstellt.

Beim geografischen Aliasing werden keine Lookback- oder Caching-Methoden verwendet. Aufgrund der großen Anzahl von Ereignissen führt Google SecOps einen Index im Arbeitsspeicher.

Inkonsistenzen bei der IP-Standortbestimmung

Die proprietäre IP-Geolokalisierungstechnologie von Google verwendet eine Kombination aus Netzwerkdaten und anderen Eingaben und Methoden, um den Standort von IP-Adressen und die Netzwerkauflösung für Nutzer zu ermitteln. Andere Organisationen verwenden möglicherweise andere Signale oder Methoden, was gelegentlich zu unterschiedlichen Ergebnissen führen kann.

Wenn Sie eine Unstimmigkeit bei den von Google bereitgestellten IP-Geolokalisierungsergebnissen feststellen, erstellen Sie ein Kundensupport-Ticket, damit Google die Angelegenheit untersuchen und die Datensätze gegebenenfalls korrigieren kann.

Ereignisse mit VirusTotal-Dateimetadaten anreichern

Google SecOps reichert Dateihashes in UDM-Ereignissen an und bietet zusätzlichen Kontext bei der Untersuchung. Durch Hash-Aliasing werden UDM-Ereignisse angereichert, indem alle Arten von Datei-Hashes kombiniert und Informationen zu einem Datei-Hash bei einer Suche bereitgestellt werden.

Google SecOps integriert VirusTotal-Dateimetadaten und die Anreicherung von Beziehungen, um Muster schädlicher Aktivitäten zu erkennen und Malware-Bewegungen in einem Netzwerk nachzuverfolgen.

Ein Rohlog enthält nur begrenzte Informationen zur Datei. VirusTotal reichert das Ereignis mit Dateimetadaten an, einschließlich Details zu schädlichen Hashes und Dateien. Die Metadaten enthalten beispielsweise Informationen wie Dateinamen, Typen, importierte Funktionen und Tags. Sie können diese Informationen in der UDM-Such- und ‑Erkennungs-Engine mit YARA-L verwenden, um schädliche Dateiereignisse zu analysieren und Bedrohungen zu erkennen. So können Sie beispielsweise Änderungen an der Originaldatei erkennen, bei denen die Dateimetadaten zur Bedrohungserkennung verwendet werden.

Die folgenden Informationen werden mit dem Datensatz gespeichert. Eine Liste aller UDM-Felder finden Sie unter Liste der Felder des Unified Data Model.

Datentyp UDM-Feld
sha-256 ( principal | target | src | observer ).file.sha256
md5 ( principal | target | src | observer ).file.md5
sha-1 ( principal | target | src | observer ).file.sha1
Größe ( principal | target | src | observer ).file.size
ssdeep ( principal | target | src | observer ).file.ssdeep
vhash ( principal | target | src | observer ).file.vhash
authentihash ( principal | target | src | observer ).file.authentihash
Imphash für PE-Dateimetadaten ( principal | target | src | observer ).file.pe_file.imphash
security_result.threat_verdict ( principal | target | src | observer ).(process | file).security_result.threat_verdict
security_result.severity ( principal | target | src | observer ).(process | file).security_result.severity
last_modification_time ( principal | target | src | observer ).file.last_modification_time
first_seen_time ( principal | target | src | observer ).file.first_seen_time
last_seen_time ( principal | target | src | observer ).file.last_seen_time
last_analysis_time ( principal | target | src | observer ).file.last_analysis_time
exif_info.original_file ( principal | target | src | observer ).file.exif_info.original_file
exif_info.product ( principal | target | src | observer ).file.exif_info.product
exif_info.company ( principal | target | src | observer ).file.exif_info.company
exif_info.file_description ( principal | target | src | observer ).file.exif_info.file_description
signature_info.codesign.id ( principal | target | src | observer ).file.signature_info.codesign.id
signature_info.sigcheck.verfied ( principal | target | src | observer ).file.signature_info.sigcheck.verified
signature_info.sigcheck.verification_message ( principal | target | src | observer ).file.signature_info.sigcheck.verification_message
signature_info.sigcheck.signers.name ( principal | target | src | observer ).file.signature_info.sigcheck.signers.name
signature_info.sigcheck.status ( principal | target | src | observer ).file.signature_info.sigcheck.signers.status
signature_info.sigcheck.valid_usage ( principal | target | src | observer ).file.signature_info.sigcheck.signers.valid_usage
signature_info.sigcheck.cert_issuer ( principal | target | src | observer ).file.signature_info.sigcheck.signers.cert_issuer
file_type ( principal | target | src | observer ).file.file_type

Fehlerbehebung bei der Anreicherung

Wenn Sie feststellen, dass in einem UDM-Ereignis erwartete Anreicherungsdaten fehlen, können Sie das Problem mithilfe der folgenden Vorschläge beheben.

Allgemeine Anreicherung

Wenn einige Ihrer Ereignisse überhaupt nicht angereichert werden, liegt das wahrscheinlich daran, dass Google SecOps die Liefergeschwindigkeit priorisiert. Bei einem kleinen Prozentsatz der Ereignisse (<1%) wird die Anreicherung beim ersten Durchlauf möglicherweise übersprungen. Versuchen Sie es in einigen Minuten noch einmal. Das System verarbeitet diese Ereignisse automatisch noch einmal. Wenn die Anreicherung nach einer Stunde immer noch fehlt, prüfen Sie, ob die Protokollquelle korrekt in UDM geparst wird.

Artefaktanreicherung (First-Match-Logik)

Wenn Ihr Ereignis einen MD5- und einen SHA256-Hash hat, Sie aber nur VirusTotal-Metadaten für den SHA256-Hash sehen, liegt das an der First-Match-Logik. Die Pipeline wird beendet, sobald der Hash mit der höchsten Priorität (sha256) gefunden wird. Wenn ein SHA256-Hash vorhanden ist, wird VirusTotal nicht nach dem MD5-Hash gefragt.

Wenn Sie die Standortbestimmung für principal.ip, aber nicht für target.ip sehen, wird bei der parallelen Logik jede IP-Adresse unabhängig behandelt. Wenn eine IP-Adresse intern oder privat (nicht routingfähig) und die andere öffentlich ist, wird nur die öffentliche IP-Adresse mit Geolocation-Informationen angereichert.

Asset-Anreicherung (Logik für Zusammenführung und Fallback)

Wenn im Feld „IP-Adresse“ keine Anreicherungsdaten für Ihr Asset angezeigt werden, handelt es sich um eine bedingte Fallback-Logik. Die IP-Adresse wird nur für eine Anreicherungsanfrage verwendet, wenn die asset_id (PSID) fehlt. Wenn ein asset_id vorhanden ist, verwendet das System dieses und ignoriert die IP-Adresse für die entsprechende Anfrage, um redundante oder widersprüchliche Daten zu vermeiden.

Nutzeranreicherung (Reihenfolge)

Wenn im Feld Department der Wert "IT" angezeigt wird, in meinen lokalen Logs aber "Security" steht, bedeutet das, dass bei der Nutzeranreicherung analysierte Felder gegenüber Aliasfeldern bevorzugt werden. Wenn Ihr Rohlog mit "IT" geparst wurde, wird er in der Anreicherungspipeline nicht mit dem "Security"-Wert aus Ihrer Identitätsquelle (z. B. Okta oder AD) überschrieben.

Anreicherung verarbeiten (zuordnen und überschreiben)

Wenn Sie in Ihrem Rohlog einen Prozessnamen sehen, der in der UDM-Suche durch einen anderen Namen ersetzt wird, bedeutet das, dass eine Überschreibungslogik vorliegt. Bei der Prozessanreicherung werden Aliasfelder priorisiert. Wenn bei der PSPI-Suche ein genauerer Prozessname aus dem EDR-Kontext zurückgegeben wird, wird der ursprünglich geparste Wert vollständig ersetzt.

Nächste Schritte

Informationen zur Verwendung angereicherter Daten mit anderen Google SecOps-Funktionen finden Sie unter:

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