Übersicht über das einheitliche Datenmodell

Dieses Dokument bietet einen Überblick über das Unified Data Model (UDM). Weitere Informationen zu UDM-Feldern, einschließlich einer Beschreibung der einzelnen Felder, finden Sie in der UDM-Feldliste. Weitere Informationen zur Parserzuordnung finden Sie unter Wichtige UDM-Felder für die Parserzuordnung.

Die UDM ist eine Standarddatenstruktur von Google Security Operations, in der Informationen zu aus Quellen empfangenen Daten gespeichert werden. Es wird auch als Schema bezeichnet. Google Security Operations speichert die Originaldaten, die es erhält, in zwei Formaten: als ursprüngliches Rohlog und als strukturierter UDM-Eintrag. Der UDM-Eintrag ist eine strukturierte Darstellung des ursprünglichen Logs.

Wenn für den angegebenen Logtyp ein Parser vorhanden ist, wird das Rohlog zum Erstellen eines UM-Eintrags verwendet. Kunden können Rohlogs auch in ein strukturiertes UDM-Format umwandeln, bevor sie die Daten über die Ingestion API an Google Security Operations senden.

Zu den Vorteilen von UDM gehören:

• Speichert denselben Datensatztyp von verschiedenen Anbietern mit derselben Semantik.
• Beziehungen zwischen Nutzern, Hosts und IP-Adressen lassen sich leichter identifizieren, da die Daten in das UDM-Standardschema normalisiert werden.
• Das Schreiben von Regeln wird vereinfacht, da die Regeln plattformunabhängig sein können.
• Einfachere Unterstützung von Protokolltypen von neuen Geräten.

Hinweis: Die Google Security Operations-Engine für Regeln verwendet dieselben UDM-Feldnamen. Sie können dieselben Feldnamen beim Erstellen von Regeln verwenden.

Obwohl Sie mit einer Rohlogsuche nach Ereignissen suchen können, funktioniert eine UDM-Suche aufgrund ihrer Spezifität schneller und präziser.

Google Security Operations verwendet das UDM-Schema für alle Ereignisse, die erfasst werden. UDM umfasst Tausende von Feldern zum Beschreiben und Kategorisieren von Ereignissen. UDM kann beispielsweise Endpunktprozessereignisse so einfach verarbeiten wie Netzwerkkommunikationsereignisse.

UDM-Struktur

UDM-Ereignisse bestehen aus mehreren Abschnitten. Der erste Abschnitt in jedem UM-Ereignis ist der Abschnitt „Metadaten“. Sie enthält eine grundlegende Beschreibung des Ereignisses, einschließlich des Zeitstempels des Ereignisses und des Zeitpunkts der Aufnahme in Google Security Operations. Außerdem sind Produktinformationen, Version und Beschreibung enthalten. Der Aufnahmeparser klassifiziert jedes Ereignis basierend auf einem vordefinierten Ereignistyp unabhängig vom spezifischen Produktlog. Allein mit den Metadatenfeldern können Sie schnell mit der Suche in den Daten beginnen.

Neben dem Metadatenbereich werden in anderen Abschnitten weitere Aspekte des Ereignisses beschrieben. Nicht benötigte Abschnitte werden nicht berücksichtigt, wodurch Arbeitsspeicher gespart wird.

• principal: Entität, von der die Aktivität im Ereignis ausgeht. Es werden auch Abschnitte einbezogen, die auf die Quelle (src) und das Ziel (target) verweisen.
• intermediary: Systeme, die Ereignisse passieren, z. B. ein Proxyserver oder ein SMTP-Relay.
• observer: Systeme wie Paket-Sniffer, die den Traffic passiv überwachen.

Beispiele für UDM-Suchanfragen

In diesem Abschnitt finden Sie Beispiele für UDM-Suchen, in denen einige grundlegende Syntax, Funktionen und Möglichkeiten der UDM-Suche veranschaulicht werden.

Beispiel: Suche nach erfolgreichen Microsoft Windows 4624-Anmeldungen

Bei der folgenden Suche werden die Ereignisse nach erfolgreicher Anmeldung in Microsoft Windows 4624 zusammen mit dem Zeitpunkt ihrer Generierung nur anhand von zwei UDM-Feldern aufgelistet:

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

Beispiel: Nach allen erfolgreichen Anmeldungen suchen

Mit der folgenden Suche werden alle erfolgreichen Anmeldeereignisse aufgelistet, unabhängig vom Anbieter oder der Anwendung:

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

Beispiel: Suche nach erfolgreichen Nutzeranmeldungen

Das folgende Beispiel zeigt, wie Sie nach userid "fkolzig" suchen und feststellen können, wann sich ein Nutzer mit dieser User-ID erfolgreich angemeldet hat. Sie können diese Suche über den Zielabschnitt durchführen. Der Abschnitt „target“ enthält Unterabschnitte und Felder, die das Ziel beschreiben. Beispielsweise ist das Ziel in diesem Fall ein Nutzer mit einer Reihe von verknüpften Attributen, das Ziel kann aber auch eine Datei, eine Registry-Einstellung oder ein Asset sein. In diesem Beispiel wird mit dem Feld target.user.userid nach "fkolzig" gesucht.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

Beispiel: Netzwerkdaten durchsuchen

Im folgenden Beispiel werden Netzwerkdaten mit einem target.port nach RDP-Ereignissen durchsucht

von 3389 und principal.ip von 35.235.240.5. Außerdem enthält es ein UDM-Feld aus dem Netzwerkabschnitt, der Richtung der Daten (network.direction).

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

Beispiel: nach einem bestimmten Prozess suchen

Wenn Sie die auf Ihren Servern erstellten Prozesse untersuchen möchten, suchen Sie nach Instanzen des Befehls net.exe und suchen Sie dann unter dem erwarteten Pfad nach dieser Datei. Das Feld, nach dem Sie suchen, ist target.process.file.full_path. Geben Sie für diese Suche den spezifischen Befehl ein, der im target.process.command_line ausgegeben wurde.

ein. Sie können auch ein Feld im Abschnitt „Info“ hinzufügen, das die Beschreibung des Microsoft Sysmon-Ereigniscodes 1 (ProcessCreate) darstellt.

Hier ist die UDM-Suche:

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

Optional können Sie die folgenden UDM-Suchfelder hinzufügen:

• principal.user.userid: Identifiziert den Nutzer, der den Befehl ausgibt.
• principal.process.file.md5: Identifizieren Sie den MD5-Hash.
• principal.process.command_line: Befehlszeile.

Beispiel: Suche nach erfolgreichen Nutzeranmeldungen für eine bestimmte Abteilung

Im folgenden Beispiel wird nach Anmeldungen von Nutzern gesucht (metadata.event_type ist USER_LOGIN), die der Marketingabteilung (target.user.department ist marketing) Ihres Unternehmens zugeordnet sind. Obwohl target.user.department nicht direkt mit Nutzeranmeldungsereignissen verbunden ist, ist er weiterhin in den LDAP-Daten vorhanden, die über Ihre Nutzer aufgenommen wurden.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

Logische Objekte: Ereignis und Entität

Das UDM-Schema beschreibt alle verfügbaren Attribute, die Daten speichern. Jeder UDM-Eintrag gibt an, ob er ein Ereignis oder eine Entität beschreibt. Die Daten werden in verschiedenen Feldern gespeichert, je nachdem, ob der Datensatz ein Ereignis oder eine Entität beschreibt und welcher Wert im Feld „metadata.event_type“ oder „metadata.entity_type“ festgelegt ist.

• UDM-Ereignis: Speichert Daten für eine Aktion, die in der Umgebung aufgetreten ist. Im ursprünglichen Ereignislog wird die Aktion in dem Zustand beschrieben, in dem sie vom Gerät aufgezeichnet wurde, z. B. durch eine Firewall und einen Web-Proxy. Dies ist das UDM-Ereignisdatenmodell.
• UDM-Entität: Kontextdarstellung von Elementen wie Assets, Nutzern und Ressourcen in Ihrer Umgebung. Sie stammt aus einer Source of Truth-Datenquelle. Dies ist das UDM-Entitätsdatenmodell.

Hier sehen Sie zwei visuelle Darstellungen des Ereignisdatenmodells und des Entitätsdatenmodells.

Abbildung: Ereignisdatenmodell

Hinweis: Der Begriff „Substantiv“ beschreibt die Art des Attributs. Die Begriffe „Hauptkonto“, „Ziel“, „src“, „Vermittler“, „Beobachter“ und „Info“ sind die Feldnamen, in denen Daten gespeichert werden.

Abbildung: Entitätsdatenmodell

Hinweis: Der Begriff „Substantiv“ beschreibt die Art des Attributs. Die Begriffe „Asset“, „Nutzer“ und „Ressource“ sind die Namen der Felder, in denen Daten gespeichert werden.

Struktur eines UDM-Ereignisses

Das UDM-Ereignis enthält mehrere Abschnitte, in denen jeweils eine Teilmenge der Daten für einen einzelnen Datensatz gespeichert ist. Die Abschnitte sind:

• Metadaten
• Hauptkonto
• Ziel
• src
• Beobachter
• Vermittler
• about
• Netzwerk
• security_result

• Erweiterungen

  

  Abbildung: Ereignisdatenmodell

Im Abschnitt metadata werden der Zeitstempel gespeichert, der event_type definiert und das Gerät beschrieben.

In den Abschnitten principal, target, src, observer und intermediary werden Informationen zu den am Ereignis beteiligten Objekten gespeichert. Ein Objekt kann ein Gerät, ein Nutzer oder ein Prozess sein. Meistens wird nur ein Teil dieser Bereiche verwendet. Die Felder, in denen Daten gespeichert werden, werden durch den Ereignistyp und die Rolle bestimmt, die jedes Objekt bei dem Ereignis spielt.

Im Abschnitt Netzwerk werden Informationen zur Netzwerkaktivität wie E-Mail- und netzwerkbezogene Kommunikation gespeichert.

• E-Mail-Daten: Informationen in den Feldern to, from, cc, bcc und anderen E-Mail-Feldern.
• HTTP-Daten: z. B. method, referral_url und useragent

Im Abschnitt security_result wird eine Aktion oder Klassifizierung gespeichert, die von einem Sicherheitsprodukt, z. B. einem Antivirenprodukt, aufgezeichnet wurde.

Die Abschnitte about und extensions enthalten zusätzliche anbieterspezifische Ereignisinformationen, die in den anderen Abschnitten nicht erfasst werden. Der Abschnitt extensions ist ein Satz von Schlüssel/Wert-Paaren im freien Format.

In jedem UDM-Ereignis werden Werte aus einem ursprünglichen Rohprotokollereignis gespeichert. Je nach Art des Ereignisses sind bestimmte Attribute erforderlich, während andere optional sind. Welche Attribute erforderlich sind, richtet sich nach dem Wert „metadata.event_type“. Google Security Operations liest „metadata.event_type“ und führt nach dem Empfang der Logs eine Feldvalidierung für diesen Ereignistyp durch.

Wenn in einem Abschnitt des UDM-Eintrags keine Daten gespeichert sind, z. B. im Abschnitt „Erweiterungen“, wird dieser Abschnitt nicht im UDM-Eintrag angezeigt.

Metadatenfelder

In diesem Abschnitt werden die Felder beschrieben, die in einem UDM-Ereignis erforderlich sind.

Das Feld „event_timestamp“

UDM-Ereignisse müssen Daten für metadata.event_timestamp enthalten, also den GMT-Zeitstempel des Ereignisses. Der Wert muss nach einem der folgenden Standards codiert werden: RFC 3339- oder Proto3-Zeitstempel.

Die folgenden Beispiele veranschaulichen, wie Sie den Zeitstempel im RFC 3339-Format yyyy-mm-ddThh:mm:ss+hh:mm (Jahr, Monat, Tag, Stunde, Minute, Sekunde und Zeitversatz zur UTC-Zeit) angeben. Die Abweichung von UTC beträgt minus 8 Stunden und entspricht somit PST.

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

Sie können den Wert auch im Epochenformat angeben.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

Das Feld „event_type“

Das wichtigste Feld im UDM-Ereignis ist metadata.event_type. Dieser Wert gibt die Art der durchgeführten Aktion an und ist unabhängig von Anbieter, Produkt oder Plattform. Beispielwerte sind PROCESS_OPEN, FILE_CREATION, USER_CREATION und NETWORK_DNS. Die vollständige Liste finden Sie im Dokument UDM-Feldliste.

Der Wert metadata.event_type bestimmt, welche zusätzlichen Pflicht- und optionalen Felder im UDM-Eintrag enthalten sein müssen. Informationen zu den Feldern, die für jeden Ereignistyp einbezogen werden sollten, finden Sie im Leitfaden zur Verwendung von UDM.

Die Attribute für Prinzipal, Ziel, Quelle, Vermittler, Beobachter und Info

Die Attribute principal, target, src, intermediary und observer beschreiben Assets, die am Ereignis beteiligt sind. In jedem werden Informationen zu Objekten gespeichert, die an der Aktivität beteiligt sind, wie vom ursprünglichen Rohlog erfasst. Dies kann das Gerät oder der Nutzer sein, der die Aktivität ausgeführt hat, oder das Gerät oder der Nutzer, der oder der Ziel der Aktivität ist. Er kann auch ein Sicherheitsgerät beschreiben, das die Aktivität beobachtet hat, z. B. ein E-Mail-Proxy oder ein Netzwerkrouter.

Die am häufigsten verwendeten Attribute sind:

• principal: Objekt, das die Aktivität ausgeführt hat.
• src: Objekt, das die Aktivität initiiert, falls es sich vom Hauptkonto unterscheidet.
• target: Objekt, auf das reagiert wird.

Für jeden Ereignistyp muss mindestens eines dieser Felder Daten enthalten.

Die Hilfsfelder sind:

• intermediary: Jedes Objekt, das als Vermittler des Ereignisses diente. Dazu können Objekte wie Proxy-Server und E-Mail-Server gehören.
• observer: Jedes Objekt, das nicht direkt mit dem betreffenden Traffic interagiert. Dies kann ein Scannen auf Sicherheitslücken oder ein Gerät zur Paket-Sniffer-Technologie sein.
• about: Alle anderen Objekte, die bei dem Ereignis eine Rolle gespielt haben und optional sind.

Hauptkontoattribute

Das handelnde Rechtssubjekt oder das Gerät, von dem die Aktivität ausging. Das Hauptkonto muss mindestens ein Maschinendetail (Hostname, MAC-Adresse, IP-Adresse, produktspezifische Kennungen wie eine CrowdStrike-Maschinen-GUID) oder ein Nutzerdetail (z. B. Nutzername) und optional Prozessdetails enthalten. Die folgenden Felder dürfen keines der folgenden Felder enthalten: E-Mail-Adresse, Dateien, Registrierungsschlüssel oder Werte.

Wenn das Ereignis auf einem einzelnen Computer stattfindet, wird dieser Rechner nur im Hauptattribut beschrieben. Die Maschine muss nicht in den Attributen „target“ oder „src“ beschrieben werden.

Hinweis: Ein Sicherheitsgerät kann ein Ereignis aufzeichnen, es wird jedoch nicht im Hauptkontoattribut beschrieben. Er wird entweder im Beobachter- oder im Intermediary-Attribut beschrieben. Wenn die Sicherheitssoftware (z. B. Carbon Black) auf demselben Gerät ausgeführt wird, von dem die Aktivität stammt (z. B. einem Windows-Endpunkt, an dem Malware gefunden wurde), ist das Windows-Gerät das Hauptkonto.

Das folgende JSON-Snippet veranschaulicht, wie das Attribut principal ausgefüllt werden könnte.

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

Dieses Attribut beschreibt alles, was über das Gerät und den Nutzer bekannt ist, die der Hauptakteur des Ereignisses waren. Dieses Beispiel enthält die IP-Adresse, die Portnummer und den Hostnamen des Geräts. Außerdem enthält sie eine anbieterspezifische Asset-ID von Sophos, eine eindeutige Kennung, die vom Sicherheitsprodukt eines Drittanbieters generiert wird.

Die Zielattribute

Stellt ein Zielgerät dar, auf das vom Ereignis verwiesen wird, oder ein Objekt auf dem Zielgerät. Bei einer Firewallverbindung von Gerät A zu Gerät B wird beispielsweise Gerät A als Hauptkonto und Gerät B als Ziel erfasst.

Bei einer Prozessinjektion durch Prozess C in Zielprozess D ist Prozess C das Hauptkonto und Prozess D das Ziel.

Abbildung: Hauptkonto und Ziel

Das folgende Beispiel zeigt, wie das Zielfeld gefüllt werden könnte.

target {
   ip: "192.0.2.31"
   port: 80
}

Wenn im ursprünglichen Rohlog weitere Informationen verfügbar sind, z. B. der Hostname, zusätzliche IP-Adressen, MAC-Adressen und proprietäre Asset-IDs, sollten diese auch in die Felder für das Ziel und das Hauptkonto aufgenommen werden.

Sowohl Prinzipal als auch Ziel können Akteure auf demselben Computer darstellen. Beispiel: Prozess A (Hauptkonto), der auf Maschine X ausgeführt wird, kann auf Prozess B (Ziel) auch auf Maschine X reagieren.

Das Attribut „src“

Stellt ein Quellobjekt dar, auf das der Teilnehmer reagiert, zusammen mit dem Geräte- oder Prozesskontext für das Quellobjekt (die Maschine, auf der sich das Quellobjekt befindet). Wenn Nutzer U beispielsweise Datei A auf Computer X in Datei B auf Computer Y kopiert, werden sowohl Datei A als auch Computer X im src-Teil des UDM-Ereignisses angegeben.

Das Zwischenattribut

Stellt Details zu einem oder mehreren Zwischengeräten zur Verarbeitung der im Ereignis beschriebenen Aktivität dar. Dazu können Gerätedetails zu Geräten wie Proxyservern und SMTP-Relay-Servern gehören.

Das Beobachter-Attribut

Stellt ein Beobachtergerät dar, das kein direkter Vermittler ist, sondern das betreffende Ereignis beobachtet und meldet. Dies kann einen Paket-Sniffer oder einen netzwerkbasierten Scannen auf Sicherheitslücken umfassen.

Das Attribut „about“

Hier werden Details zu einem Objekt gespeichert, auf das das Ereignis verweist, das nicht in den Feldern „Principal“, „src“, „Target“, „Intermediary“ oder „Observer“ beschrieben ist. Beispielsweise könnte er Folgendes erfassen:

• Dateianhänge per E-Mail senden.
• In einen E-Mail-Text eingebettete Domains, URLs oder IP-Adressen.
• DLLs, die während eines PROCESS_LAUNCH-Ereignisses geladen werden.

Das Attribut „security_result“

Dieser Abschnitt enthält Informationen zu Sicherheitsrisiken und Bedrohungen, die von einem Sicherheitssystem erkannt werden, sowie zu den Maßnahmen, die zur Minderung dieser Risiken und Bedrohungen ergriffen wurden.

Im Folgenden finden Sie Arten von Informationen, die im Attribut "security_result" gespeichert werden:

• Ein E-Mail-Sicherheitsproxy hat einen Phishing-Versuch erkannt (security_result.category = MAIL_PHISHING) und die E-Mail blockiert (security_result.action = BLOCK).
• Eine Firewall des E-Mail-Sicherheitsproxys hat zwei infizierte Anhänge erkannt (security_result.category = SOFTWARE_MALICIOUS) und diese Anhänge wurden unter Quarantäne gestellt und desinfiziert (security_result.action = QUARANTINE oder security_result.action = ALLOW_WITH_MODIFICATION) und dann die desinfizierte E-Mail weitergeleitet.
• Ein SSO-System ermöglicht eine Anmeldung (security_result.category = AUTH_VIOLATION), die blockiert wurde (security_result.action = BLOCK).
• Eine Malware-Sandbox hat Spyware (security_result.category = SOFTWARE_MALICIOUS) in einem Dateianhang fünf Minuten nach Übermittlung der Datei (security_result.action = ALLOW) an den Nutzer in seinem Posteingang erkannt.

Das Netzwerkattribut

Netzwerkattribute speichern Daten zu netzwerkbezogenen Ereignissen und Details zu Protokollen in Unternachrichten. Dazu gehören Aktivitäten wie gesendete und empfangene E-Mails sowie HTTP-Anfragen.

Das Attribut „Erweiterungen“

Die Felder unter diesem Attribut speichern zusätzliche Metadaten zu dem Ereignis, das im ursprünglichen Rohlog erfasst wurde. Sie kann Informationen zu Sicherheitslücken oder zusätzliche Informationen im Zusammenhang mit der Authentifizierung enthalten.

Struktur einer UDM-Entität

In einem UDM-Entitätseintrag werden Informationen zu jeder Entität innerhalb einer Organisation gespeichert. Wenn metadata.entity_type USER ist, speichert der Datensatz Informationen über den Nutzer im Attribut entity.user. Wenn metadata.entity_type ASSET ist, speichert der Datensatz Informationen zu einem Asset, z. B. Workstation, Laptop, Smartphone und virtuelle Maschine.

Abbildung: Ereignisdatenmodell

Metadatenfelder

Dieser Abschnitt enthält Felder, die in einer UDM-Entität erforderlich sind, z. B.:

• Collection_timestamp: Datum und Uhrzeit der Erfassung des Datensatzes
• entity_type: der Typ der Entität, z. B. Asset, Nutzer oder Ressource.

Das Entitätsattribut

In den Feldern unter dem Entitätsattribut werden Informationen zur jeweiligen Entität gespeichert, z. B. Hostname und IP-Adresse, wenn es sich um ein Asset handelt, oder Windows_sid und E-Mail-Adresse, wenn es sich um einen Nutzer handelt. Der Name des Feldes lautet "entity", der Feldtyp ist jedoch ein Substantiv. Ein Substantiv ist eine häufig verwendete Datenstruktur, die Informationen sowohl in Entitäten als auch in Ereignissen speichert.

• Wenn „metadata.entity_type“ auf USER gesetzt ist, werden die Daten unter dem Attribut „entity.user“ gespeichert.
• Wenn „metadata.entity_type“ auf ASSET gesetzt ist, werden die Daten unter dem Attribut „entity.asset“ gespeichert.

Das Attribut „relation“

Felder unter dem Attribut „Beziehung“ speichern Informationen zu anderen Entitäten, mit denen die primäre Entität verknüpft ist. Das ist beispielsweise der Fall, wenn die primäre Entität ein Nutzer ist und dem Nutzer ein Laptop zugewiesen wurde. Der Laptop ist ein verwandtes Element. Informationen über den Laptop werden als Entitätseintrag mit dem Parameter metadata.entity_type = ASSET gespeichert. Informationen zum Nutzer werden als Entitätseintrag mit dem Parameter metadata.entity_type = USER gespeichert.

Der Nutzerentitätseintrag erfasst mithilfe von Feldern unter dem Attribut "relation" außerdem die Beziehung zwischen dem Nutzer und dem Laptop. Das Feld „relation.relationship“ speichert die Beziehung zwischen dem Nutzer und dem Laptop, insbesondere dass der Nutzer Eigentümer des Laptops ist. Im Feld „relation.entity_type“ wird der Wert ASSET gespeichert, da der Laptop ein Gerät ist.

Felder unter dem Attribut „relations.entity“ speichern Informationen zum Laptop, z. B. den Hostnamen und die MAC-Adresse. Beachten Sie, dass der Feldname "entity" und der Feldtyp ein Substantiv ist. Ein Substantiv ist eine häufig verwendete Datenstruktur. Felder unter dem Attribut „relation.entity“ speichern Informationen zum Laptop.

Im Feld „relation.direction“ wird die Direktionalität der Beziehung zwischen Nutzer und Laptop gespeichert, insbesondere ob es sich um eine bidirektionale oder eine unidirektionale Beziehung handelt.