Übersicht über das einheitliche Datenmodell

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

Das UDM ist eine Standarddatenstruktur von Google Security Operations, in der Informationen zu Daten gespeichert werden, die aus Quellen empfangen werden. Es wird auch als Schema bezeichnet. Google SecOps speichert die empfangenen Originaldaten in zwei Formaten: als ursprüngliches Rohlog und als strukturierten UDM-Datensatz. Der UDM-Datensatz ist eine strukturierte Darstellung des ursprünglichen Logs.

Wenn ein Parser für den angegebenen Logtyp vorhanden ist, wird aus dem Rohlog ein UDM-Datensatz erstellt. Kunden können Rohlogs auch in das strukturierte UDM-Format umwandeln, bevor sie die Daten mit der Ingestion API an Google SecOps senden.

Einige Vorteile von UDM:

• Speichert denselben Datensatztyp von verschiedenen Anbietern mit derselben Semantik.
• Es ist einfacher, Beziehungen zwischen Nutzern, Hosts und IP-Adressen zu erkennen, da die Daten in das standardmäßige UDM-Schema normalisiert werden.
• Regeln lassen sich einfacher schreiben, da sie plattformunabhängig sein können.
• Unterstützung von Protokolltypen von neuen Geräten ist einfacher.

Sie können zwar auch mit einer Rohlog-Suche nach Ereignissen suchen, eine UDM-Suche ist jedoch schneller und genauer, da sie spezifischer ist. In Google SecOps werden Rohprotokolldaten erfasst und die Details des Ereignisprotokolls im UDM-Schema gespeichert. UDM bietet ein umfassendes Framework mit Tausenden von Feldern zum Beschreiben und Kategorisieren verschiedener Ereignistypen, z. B. Endpunktprozessereignisse und Netzwerkkommunikationsereignisse.

UDM-Struktur

UDM-Ereignisse bestehen aus mehreren Abschnitten. Der erste Abschnitt in jedem UDM-Ereignis ist der Metadatenabschnitt. Es enthält eine grundlegende Beschreibung des Ereignisses, einschließlich des Zeitstempels, wann das Ereignis aufgetreten ist, und des Zeitstempels, wann es in Google SecOps aufgenommen wurde. Sie enthält auch die Produktinformationen, die Version und die Beschreibung. Der Ingestion-Parser klassifiziert jedes Ereignis anhand eines vordefinierten Ereignistyps, unabhängig vom jeweiligen Produktlog. Allein mit den Metadatenfeldern können Sie schnell mit der Suche in den Daten beginnen.

Neben dem Metadatenabschnitt werden in anderen Abschnitten zusätzliche Aspekte des Ereignisses beschrieben. Wenn ein Abschnitt nicht erforderlich ist, wird er nicht aufgenommen, wodurch Speicherplatz gespart wird.

• principal: Die Entität, von der die Aktivität im Ereignis ausgeht. Abschnitte, in denen auf die Quelle (src) und das Ziel (target) verwiesen wird, sind ebenfalls enthalten.
• intermediary: Systeme, durch die Ereignisse geleitet werden, z. B. ein Proxyserver oder ein SMTP-Relay.
• observer: Systeme wie Packet Sniffer, die den Traffic passiv überwachen.

Beispiele für UDM-Suchanfragen

In diesem Abschnitt finden Sie Beispiele für UDM-Suchanfragen, die einige der grundlegenden Syntaxen, Funktionen und Möglichkeiten der UDM-Suche veranschaulichen.

Beispiel: Suche nach erfolgreichen Microsoft Windows 4624-Anmeldungen

Die folgende Suche listet die erfolgreichen Anmeldeereignisse vom Typ „Microsoft Windows 4624“ auf, zusammen mit dem Zeitpunkt, zu dem die Ereignisse generiert wurden. Sie basiert auf nur zwei UDM-Feldern:

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

Beispiel: Nach allen erfolgreichen Anmeldungen suchen

Die folgende Suche listet alle erfolgreichen Anmeldeereignisse auf, unabhängig von Anbieter oder Anwendung:

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

Beispiel: Nach erfolgreichen Nutzeranmeldungen suchen

Das folgende Beispiel veranschaulicht, wie Sie nach userid "fkolzig" suchen und feststellen, wann sich der Nutzer mit dieser Nutzer-ID erfolgreich angemeldet hat. Sie können diese Suche im Zielabschnitt durchführen. Der Zielabschnitt enthält Unterabschnitte und Felder, in denen das Ziel beschrieben wird. Das Ziel ist in diesem Fall beispielsweise ein Nutzer und hat eine Reihe zugehöriger Attribute. Das Ziel kann aber auch eine Datei, eine Registrierungseinstellung 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 nach RDP-Ereignissen mit einem target.port von 3389 und einem principal.ip von 35.235.240.5 durchsucht. Es enthält auch ein UDM-Feld aus dem Netzwerkbereich, die 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

Um die auf Ihren Servern erstellten Prozesse zu untersuchen, suchen Sie nach Instanzen des Befehls net.exe und nach dieser Datei im erwarteten Pfad. Das Feld, nach dem Sie suchen, ist target.process.file.full_path. Für diese Suche geben Sie den ausgeführten Befehl im Feld target.process.command_line an. Sie können auch ein Feld im Abschnitt „Info“ hinzufügen, das die Beschreibung des Microsoft Sysmon-Ereigniscodes 1 (ProcessCreate) enthält.

Hier ist die UDM-Suchanfrage:

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: Identifizieren Sie den Nutzer, der den Befehl ausgibt.
• principal.process.file.md5: MD5-Hash identifizieren.
• principal.process.command_line: Befehlszeile.

Beispiel: Nach erfolgreichen Nutzeranmeldungen suchen, die einer bestimmten Abteilung zugeordnet sind

Im folgenden Beispiel wird nach Anmeldungen von Nutzern (metadata.event_type ist USER_LOGIN) gesucht, die der Marketingabteilung (target.user.department ist marketing) Ihres Unternehmens zugeordnet sind. target.user.department ist zwar nicht direkt mit Nutzeranmeldeereignissen verknüpft, ist aber dennoch in den LDAP-Daten enthalten, die zu Ihren Nutzern erfasst werden.

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

Logische Objekte: Ereignis und Entität

Das UDM-Schema beschreibt alle verfügbaren Attribute, in denen Daten gespeichert werden. In jedem UDM-Datensatz wird angegeben, ob er ein Ereignis oder eine Entität beschreibt. Daten werden in verschiedenen Feldern gespeichert, je nachdem, ob der Datensatz ein Ereignis oder eine Einheit 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 stattgefunden hat. Im ursprünglichen Ereignisprotokoll wird die Aktion so beschrieben, wie sie vom Gerät aufgezeichnet wurde, z. B. von der Firewall und dem Webproxy.
• UDM-Entität: Kontextbezogene Darstellung von Elementen wie Assets, Nutzern und Ressourcen in Ihrer Umgebung. Sie stammen aus einer Datenquelle, die als Single Source of Truth gilt.

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

Abbildung: Ereignisdatenmodell

Abbildung: Entitätsdatenmodell

Struktur eines UDM-Ereignisses

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

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

• Erweiterungen

  

  Abbildung: Ereignisdatenmodell

Im Bereich Metadaten wird der Zeitstempel gespeichert, 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. In den meisten Fällen wird nur ein Teil dieser Abschnitte verwendet. Die Felder, in denen Daten gespeichert werden, hängen vom Ereignistyp und der Rolle ab, die jedes Objekt im Ereignis spielt.

Im Bereich Netzwerk werden Informationen zu Netzwerkaktivitäten gespeichert, z. B. E‑Mails und netzwerkbezogene Kommunikation.

• 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 wie einem Antivirenprodukt aufgezeichnet wurde.

In den Abschnitten about und extensions werden zusätzliche anbieterspezifische Ereignisinformationen gespeichert, 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 Rohlog-Ereignis gespeichert. Je nach Art des Ereignisses sind bestimmte Attribute erforderlich, andere sind optional. Welche Attribute erforderlich und welche optional sind, hängt vom Wert von metadata.event_type ab. Google SecOps liest metadata.event_type und führt nach dem Empfang der Logs eine feldspezifische Validierung für diesen Ereignistyp durch.

Wenn in einem Abschnitt des UDM-Datensatzes keine Daten gespeichert sind, z. B. im Abschnitt „extensions“, wird dieser Abschnitt nicht im UDM-Datensatz angezeigt.

Die 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. Das ist der GMT-Zeitstempel für den Zeitpunkt, zu dem das Ereignis stattgefunden hat. Der Wert muss mit einem der folgenden Standards codiert werden: RFC 3339 oder Proto3-Zeitstempel.

Die folgenden Beispiele veranschaulichen, wie der Zeitstempel im RFC 3339-Format angegeben wird: yyyy-mm-ddThh:mm:ss+hh:mm (Jahr, Monat, Tag, Stunde, Minute, Sekunde und der Offset von der UTC-Zeit). Der Zeitversatz zu UTC beträgt -8 Stunden, was PST entspricht.

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 den Typ der ausgeführten Aktion an und ist unabhängig von Anbieter, Produkt oder Plattform. Beispielwerte sind PROCESS_OPEN, FILE_CREATION, USER_CREATION und NETWORK_DNS. Eine vollständige Liste finden Sie im Dokument UDM-Feldliste.

Der metadata.event_type-Wert bestimmt, welche zusätzlichen erforderlichen und optionalen Felder im UDM-Datensatz enthalten sein müssen. Informationen dazu, welche Felder für die einzelnen Ereignistypen enthalten sein müssen, finden Sie im UDM-Leitfaden.

Die Attribute „principal“, „target“, „src“, „intermediary“, „observer“ und „about“

Die Attribute principal, target, src, intermediary und observer beschreiben Assets, die am Ereignis beteiligt sind. Jeder speichert Informationen zu Objekten, die an der Aktivität beteiligt sind, wie im ursprünglichen Rohlog aufgezeichnet. Dies kann das Gerät oder der Nutzer sein, der die Aktivität ausgeführt hat, oder das Gerät oder der Nutzer, das bzw. der das Ziel der Aktivität ist. Möglicherweise wird auch ein Sicherheitsgerät beschrieben, 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 sich die Aktion bezieht.

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

Die Hilfsfelder sind:

• intermediary: Alle Objekte, die als Vermittler bei dem Ereignis fungierten. Dazu können Objekte wie Proxyserver und Mailserver gehören.
• observer: Ein beliebiges Objekt, das nicht direkt mit dem betreffenden Traffic interagiert. Dabei kann es sich um einen Scanner für Sicherheitslücken oder ein Gerät zum Erfassen von Paketen handeln.
• about: Alle anderen Objekte, die bei dem Ereignis eine Rolle gespielt haben und optional sind.

Die Hauptkontoattribute

Stellt die handelnde Entität oder das Gerät dar, von dem die Aktivität ausgegangen ist. Der Prinzipal muss mindestens ein Computerdetail (Hostname, MAC-Adresse, IP-Adresse, produktspezifische Kennungen wie eine CrowdStrike-Computer-GUID) oder ein Nutzerdetail (z. B. Nutzername) und optional Prozessdetails enthalten. Sie darf keine der folgenden Felder enthalten: E-Mail-Adresse, Dateien, Registrierungsschlüssel oder ‑werte.

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

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

"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 die Hauptrolle bei dem Ereignis gespielt haben. Dieses Beispiel enthält die IP-Adresse, die Portnummer und den Hostnamen des Geräts. Sie enthält auch eine anbieterspezifische Asset-Kennung von Sophos, die eine eindeutige Kennung ist, die vom Drittanbieter-Sicherheitsprodukt generiert wird.

Die Zielattribute

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

Bei einer Prozessinjektion durch Prozess C in den Zielprozess D ist Prozess C der Prinzipal und Prozess D das Ziel.

Abbildung: Haupt- und Ziel-Assets

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

target {
   ip: "192.0.2.31"
   port: 80
}

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

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

Das src-Attribut

Stellt ein Quellobjekt dar, auf das der Teilnehmer einwirkt, sowie den Geräte- oder Prozesskontext für das Quellobjekt (den Computer, auf dem 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 Vermittlerattribut

Stellt Details zu einem oder mehreren Zwischengeräten dar, die die im Ereignis beschriebene Aktivität verarbeiten. Dazu können Gerätedetails zu Geräten wie Proxyservern und SMTP-Relay-Servern gehören.

Das Attribut „Beobachter“

Ein Beobachtergerät, das kein direkter Vermittler ist, sondern das betreffende Ereignis beobachtet und darüber berichtet. Dazu kann ein Paket-Sniffer oder ein netzwerkbasierter Scanner für Sicherheitslücken gehören.

Das Attribut „about“

Hier werden Details zu einem Objekt gespeichert, auf das im Ereignis verwiesen wird und das nicht in den Feldern „principal“, „src“, „target“, „intermediary“ oder „observer“ beschrieben wird. Beispielsweise könnten folgende Informationen erfasst werden:

• E‑Mail-Dateianhänge.
• Domains, URLs oder IP-Adressen, die im E-Mail-Text eingebettet sind.
• 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 Minimierung dieser Risiken und Bedrohungen ergriffen werden.

Hier sind einige Beispiele für Informationen, die im Attribut security_result gespeichert werden:

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

Das Netzwerkattribut

In Netzwerkattributen werden Daten zu netzwerkbezogenen Ereignissen und Details zu Protokollen in untergeordneten Nachrichten gespeichert. Dazu gehören Aktivitäten wie gesendete und empfangene E‑Mails sowie HTTP-Anfragen.

Das Attribut „extensions“

In den Feldern unter diesem Attribut werden zusätzliche Metadaten zum Ereignis gespeichert, das im ursprünglichen Rohlog erfasst wurde. Sie kann Informationen zu Sicherheitslücken oder zusätzliche Informationen zur Authentifizierung enthalten.

Struktur einer UDM-Entität

In einem UDM-Entitätsdatensatz werden Informationen zu einer beliebigen Entität innerhalb einer Organisation gespeichert. Wenn metadata.entity_type USER ist, werden im Datensatz Informationen zum Nutzer im Attribut entity.user gespeichert. Wenn metadata.entity_type ASSET ist, werden im Datensatz Informationen zu einem Asset wie Workstation, Laptop, Smartphone und virtueller Maschine gespeichert.

Abbildung: Ereignisdatenmodell

Die Metadatenfelder

Dieser Abschnitt enthält Felder, die für eine UDM-Entität erforderlich sind, z. B.:

• collection_timestamp: Das Datum und die Uhrzeit, zu der der Datensatz erfasst wurde.
• entity_type: Der Entitätstyp, z. B. Asset, Nutzer und Ressource.

Das Attribut „Entität“

In den Feldern unter dem Attribut „entity“ werden Informationen zur jeweiligen Einheit gespeichert, z. B. Hostname und IP-Adresse, wenn es sich um einen Vermögenswert handelt, oder „windows_sid“ und E-Mail-Adresse, wenn es sich um einen Nutzer handelt. Der Feldname ist entity, der Feldtyp ist jedoch ein Substantiv. Ein Noun ist eine häufig verwendete Datenstruktur, in der Informationen sowohl in Entitäten als auch in Ereignissen gespeichert werden.

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

Das Attribut „relation“

In Feldern unter dem Attribut „relation“ werden Informationen zu anderen Entitäten gespeichert, auf die sich die primäre Entität bezieht. Wenn die primäre Einheit beispielsweise ein Nutzer ist und dem Nutzer ein Laptop zugewiesen wurde. Der Laptop ist eine zugehörige Einheit. Informationen zum Laptop werden als entity-Eintrag mit metadata.entity_type = ASSET gespeichert. Informationen zum Nutzer werden als entity-Datensatz mit metadata.entity_type = USER gespeichert.

Im Datensatz der Nutzerentität wird auch die Beziehung zwischen dem Nutzer und dem Laptop erfasst. Dazu werden Felder unter dem Attribut relation verwendet. Im Feld relation.relationship wird die Beziehung des Nutzers zum Laptop gespeichert, 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. Der Feldname ist entity und der Feldtyp ist ein Nomen. Ein Noun ist eine häufig verwendete Datenstruktur. In den Feldern unter dem Attribut relation.entity werden Informationen zum Laptop gespeichert.

Im Feld relation.direction wird die Richtung der Beziehung zwischen Nutzer und Laptop gespeichert, insbesondere ob die Beziehung bidirektional oder unidirektional ist.

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