Anreichern
Bei der Anreicherung werden die folgenden Methoden verwendet, um einem UDM-Indikator oder ‑Ereignis Kontext hinzuzufügen:
- Gibt Alias-Entitäten an, die einen Indikator beschreiben, in der Regel ein UDM-Feld.
- Fügt der UDM-Nachricht zusätzliche Details aus den identifizierten Aliasen oder Entitäten hinzu.
- Fügt UDM-Ereignissen globale Anreicherungsdaten wie GeoIP und VirusTotal hinzu.
Logikmuster für die Anreicherung verstehen
Google SecOps wendet je nach Anreicherungstyp unterschiedliche logische Muster auf Daten an. Anhand der folgenden Tabelle können Sie diese Muster zur Fehlerbehebung nachvollziehen und erklären, warum bestimmte Felder ausgefüllt, zusammengeführt oder überschrieben werden.
| Logikmuster | Beschreibung | Anwendbare Anreicherung |
|---|---|---|
| Erstes Spiel | Es wird eine strenge Prioritätenliste eingehalten. Die Pipeline fragt nur den ersten verfügbaren Wert ab, der in der Sequenz gefunden wird. | Artefakt (Datei-Hashes) |
| Zusammengeführt | Erfasst und kombiniert Daten aus mehreren Feldern gleichzeitig, um einen einzelnen „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. Aliased-Daten 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 nur 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 „Entity“-Ansicht 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_idnicht verfügbar ist.
- Hostname, MAC und
Für jedes Asset-Ereignis werden 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 den Inhalt aufzulösen. |
ip |
IP-Adresse | Fallback: Wird nur in die Anreicherungsabfrage aufgenommen, wenn asset_id nicht verfügbar ist. |
Nutzeranreicherung
Bei der Nutzeranreicherung werden Identitätsdaten durch die Suche nach bestimmten Kennungen aufgelöst. Wie bei der Artefaktanreicherung wird in dieser Pipeline eine Reihenfolge verwendet, um zu bestimmen, welche Kennzeichnung 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 |
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:Die letzte Möglichkeit, eine Nutzeridentität aufzulösen. |
Für jeden Indikator führt die Pipeline die folgenden Aktionen aus:
- Ruft eine Liste von Nutzerentitäten ab. Beispiel: Die Entitäten von
principal.email_addressundprincipal.useridkönnen identisch oder unterschiedlich sein. - Wählt die Aliase des Indikatortyps mit der höchsten Priorität aus. Die Prioritätsreihenfolge ist:
WINDOWS_SID,EMAIL,USERNAME,EMPLOYEE_IDundPRODUCT_OBJECT_ID. noun.userwird mit der Entität 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-Ereignis-Batchtyp.
| UDM-Entität | Feldquelle | Logik oder Priorität |
|---|---|---|
| Primäre Entitäten |
principal, src, target
|
Extraktion:In der Pipeline wird die PSPI aus diesen Entitäten der obersten 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 die Prozessaliasierung, 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 (z. B. Befehlszeilen, Dateihashes und Details zum übergeordneten Prozess). Die auf dem Computer ausgeführte EDR-Software weist eine anbieterspezifische Prozess-UUID zu.
In der folgenden Tabelle sind die Felder aufgeführt, die bei einem Prozessstart-Ereignis 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 werden in Google SecOps Informationen zum übergeordneten Prozess erfasst und indexiert.
Artefaktanreicherung
Bei der Artefaktanreicherung werden Metadaten für Dateihashes von VirusTotal und Geolocation-Daten für IP-Adressen hinzugefügt. Bei Dateihashes 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:
|
| 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 Ereigniszeit 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 Einheiten principal, src und target basierend auf dem Ursprung der Daten zur Standortbestimmung überschrieben:
artifact.ipartifact.locationartifact.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 nachdem, woher der Indikator stammt. In der Pipeline werden alle vorhandenen Werte beibehalten, die sich nicht mit den neuen Daten überschneiden.
Anreicherung mit IP-Standortdaten
Durch geografisches Aliasing werden Daten zur geografischen Position 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-Unterprotokollpuffer mit den zugehörigen Standort- und ASN-Informationen erstellt.
Beim geografischen Aliasing werden weder Lookback noch Caching verwendet. Aufgrund der großen Anzahl von Ereignissen wird in Google SecOps ein Index im Arbeitsspeicher verwaltet.
Ereignisse mit VirusTotal-Dateimetadaten anreichern
In Google SecOps werden Dateihashes in UDM-Ereignisse eingefügt und zusätzlicher Kontext für die Untersuchung bereitgestellt. Durch Hash-Aliasing werden UDM-Ereignisse angereichert, indem alle Arten von Datei-Hashes kombiniert und Informationen zu einem Datei-Hash während 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 verstehen und bei der Suche nach Bedrohungen. 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 für einheitliche Datenmodelle (Unified Data Model, UDM).
| 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 bei einem UDM-Ereignis erwartete Anreicherungsdaten fehlen, können Sie das Problem mit den folgenden Vorschlägen 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%) kann es vorkommen, dass die Anreicherung beim ersten Durchlauf übersprungen wird. 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 Logquelle 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. VirusTotal wird nicht nach dem MD5 gefragt, wenn ein SHA256 vorhanden ist.
Wenn Sie die Standortbestimmung für principal.ip, aber nicht für target.ip sehen, wird jede IP-Adresse in der parallelen Logik 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 (Zusammenführungs- und Fallback-Logik)
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 diesen und ignoriert die IP-Adresse für die entsprechende Anfrage, um redundante oder widersprüchliche Daten zu vermeiden.
Nutzeranreicherung (Reihenfolge der Präferenzen)
Wenn im Feld Department "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 Wert "Security" aus Ihrer Identitätsquelle (z. B. Okta oder AD) überschrieben.
Prozessanreicherung (Zuordnung 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 die PSPI-Suche einen genaueren Prozessnamen aus dem EDR-Kontext zurückgibt, wird der ursprüngliche geparste Wert vollständig ersetzt.
Nächste Schritte
Informationen zur Verwendung angereicherter Daten mit anderen Google SecOps-Funktionen finden Sie unter:
- Kontextbezogene Daten in UDM Search verwenden:
- Kontextbezogene Daten in Regeln verwenden
- Kontextbezogene Daten in Berichten verwenden
Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten