Übersicht über das einheitliche Datenmodell

Unterstützt in:

Google SecOps SIEM

Dieses Dokument bietet eine Übersicht über das 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.

Die UDM ist eine Google Security Operations-Standarddatenstruktur, in der Informationen über die aus den Quellen empfangenen Daten. Es wird auch als Schema bezeichnet. Google Security Operations speichert die Originaldaten in zwei Formaten: ursprünglichen Rohprotokolls und als strukturierter UDM-Eintrag. Der UDM-Eintrag ist ein strukturierter Darstellung des ursprünglichen Protokolls.

Wenn für den angegebenen Logtyp ein Parser vorhanden ist, wird anhand des Rohlogs ein UDM-Eintrag erstellt. Kunden können Rohlogs auch in das strukturierte UDM-Format umwandeln bevor die Daten mithilfe der Ingestion API an Google Security Operations gesendet werden.

Zu den Vorteilen von UDM gehören:

• Speichert denselben Datensatztyp von verschiedenen Anbietern mit demselben Semantik.
• Es ist einfacher, Beziehungen zwischen Nutzern, Hosts und IP-Adressen zu identifizieren, da die Daten in das standardmäßige UDM-Schema normalisiert werden.
• Das Schreiben von Regeln wird vereinfacht, da die Regeln plattformunabhängig sein können.
• Die Unterstützung von Protokolltypen neuer Geräte ist einfacher.

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

Sie können zwar auch mit einer Suche in Rohlogs nach Ereignissen suchen, aber eine UDM-Suche ist aufgrund ihrer Spezifität schneller und genauer.

Google Security Operations verwendet das UDM-Schema für alle Ereignisse, die erfasst werden. UDM enthält Tausende von Feldern, mit denen Ereignisse beschrieben und kategorisiert werden. So kann UDM beispielsweise Endpunktprozess-Ereignisse genauso einfach verarbeiten wie Netzwerkkommunikationsereignisse.

UDM-Struktur

UDM-Ereignisse bestehen aus mehreren Abschnitten. Der erste Abschnitt in jedem UDM-Ereignis ist der Metadatenabschnitt. Sie enthält eine grundlegende Beschreibung des Ereignisses, einschließlich des Zeitstempels für das Ereignis in Google Security Operations integriert. Sie enthält auch die Produktinformationen, Version und Beschreibung. Der Aufnahmeparser klassifiziert jedes Ereignis anhand eines vordefinierter Ereignistyp, unabhängig vom spezifischen Produktprotokoll. Mit der Metadatenfelder allein können Sie schnell mit der Suche in den Daten beginnen.

Neben dem Metadatenabschnitt 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. Abschnitte, die auf die Quelle (src) und das Ziel (target) verweisen, sind ebenfalls enthalten.
• intermediary: Systeme, die Ereignisse passieren, z. B. ein Proxy oder ein SMTP-Relay.
• observer: Systeme wie Paket-Sniffer, die passiv reagieren Traffic zu überwachen.

Beispiele für UDM-Suchanfragen

Dieser Abschnitt enthält Beispiele für UDM-Suchanfragen, die einige der grundlegende Syntax, Funktionen und Möglichkeiten der UDM-Suche.

Beispiel: Suche nach erfolgreichen Microsoft Windows 4624-Anmeldungen

In der folgenden Suche werden die erfolgreichen Anmelde-Ereignisse von Microsoft Windows 4624 und das Datum und die Uhrzeit ihrer Generierung basierend auf nur zwei UDM-Feldern aufgeführt:

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

Beispiel: Nach allen erfolgreichen Anmeldungen suchen

Die folgende Suche listet alle erfolgreichen Anmeldevorgänge 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 zeigt, wie nach userid "fkolzig" gesucht wird und ermitteln, wann sich ein Nutzer mit dieser User-ID erfolgreich angemeldet hat. Sie können und schließen Sie diese Suche im Zielbereich ab. Der Bereich „Ziel“ enthält Unterabschnitte und Felder, in denen das Ziel beschrieben wird. In diesem Fall ist das Ziel beispielsweise ein Nutzer mit einer Reihe von zugehörigen Attributen. Das Ziel kann aber auch eine Datei, eine Registrierungseinstellung oder ein Asset sein. In diesem Beispiel wird mithilfe des Felds target.user.userid nach "fkolzig" gesucht.

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

Beispiel: In Netzwerkdaten suchen

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

von 3389 und einer principal.ip von 35.235.240.5. Außerdem enthält es ein UDM-Feld aus dem Netzwerkabschnitt, die Datenübertragungsrichtung (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 nach dieser bestimmten Datei im erwarteten Pfad. Das Feld, nach dem Sie suchen, ist target.process.file.full_path. Für fügen Sie den spezifischen Befehl ein, der im target.process.command_line

ein. Sie können im Abschnitt „Info“ auch ein Feld hinzufügen, Microsoft Sysmon-Ereigniscode 1 (ProcessCreate).

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: Identifizieren Sie 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, die mit einer bestimmten Abteilung verknüpft sind

Im folgenden Beispiel wird nach Anmeldungen nach Nutzern gesucht (metadata.event_type). ist USER_LOGIN) der Marketingabteilung (target.user.department) zugeordnet ist marketing) Ihres Unternehmens. Obwohl target.user.department nicht direkt mit Nutzeranmeldungsereignissen verbunden ist, ist er noch in den aufgenommenen LDAP-Daten vorhanden. zu Ihren Nutzenden.

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. In jedem UDM-Eintrag wird angegeben, ob er ein Ereignis oder eine Entität beschreibt. Daten werden gespeichert in verschiedene Felder, je nachdem, ob der Datensatz ein Ereignis beschreibt Entity und welchen Wert in den metadata.event_type oder metadata.entity_type zurückgegeben.

• UDM-Ereignis: Speichert Daten für eine Aktion, die in der zu verbessern. Im ursprünglichen Ereignisprotokoll wird die Aktion so beschrieben, wie sie aufgezeichnet wurde. durch das Gerät verursacht, z. B. durch eine Firewall oder einen Web-Proxy. Dies sind die UDM-Ereignisdaten modellieren.
• UDM-Entität: Kontextbezogene Darstellung von Elementen wie Assets, Nutzern und Ressourcen in Ihrer Umgebung. Sie wird aus einer Quelle von Truth. Dies ist das UDM-Entitätsdatenmodell.

Hier sind zwei visuelle Darstellungen des Ereignisdatenmodells und des Entitätsdatenmodells.

Abbildung: Ereignisdatenmodell

Hinweis: Der Begriff „Noun“ (Substantiv) beschreibt den Attributtyp. Die Begriffe Prinzipal, „target“, „src“, „intermediary“, „observer“ und „about“ sind die Feldnamen, gespeichert.

Abbildung: Entitätsdatenmodell

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

Struktur eines UDM-Ereignisses

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

• Metadaten
• Hauptkonto
• target
• src
• Beobachter
• Vermittler
• über
• network
• security_result

• extensions

  

  Abbildung: Ereignisdatenmodell

Im Abschnitt metadata wird der Zeitstempel gespeichert, definiert den event_type und beschreibt das Gerät.

principal, target, src, Bereichs-Store für observer und intermediary Informationen zu den am Ereignis beteiligten Objekten enthalten. Ein Objekt könnte ein Gerät, Nutzer oder Prozess. In den meisten Fällen wird nur ein Teil dieser Abschnitte verwendet. Die Felder, in denen Daten gespeichert werden, richten sich nach dem Ereignistyp und der Rolle, die jedes Objekt im Ereignis spielt.

Im Bereich Netzwerk werden Informationen zu Netzwerkaktivitäten gespeichert, z. B. E-Mails und Netzwerkkommunikation.

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

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

In den Abschnitten about und extensions werden zusätzliche anbieterspezifische Ereignisse gespeichert. Informationen, die in den anderen Abschnitten nicht erfasst werden. Der Abschnitt Erweiterungen enthält eine Reihe von Schlüssel/Wert-Paaren im freien Format.

In jedem UDM-Ereignis werden Werte aus einem ursprünglichen Rohprotokollereignis gespeichert. Je nach Ereignistyp sind bestimmte Attribute erforderlich, andere sind optional. Ob ein Attribut erforderlich oder optional ist, wird durch den Wert von „metadata.event_type“ bestimmt. Google Security Operations liest „metadata.event_type“ und führt das Feld aus eine Validierung speziell für diesen Ereignistyp, nachdem die Logs empfangen wurden.

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 das metadata.event_timestamp enthalten, also den GMT-Zeitstempel des Ereignisses. Der Wert muss mit einer der folgenden Standards: RFC 3339- oder Proto3-Zeitstempel.

Die folgenden Beispiele veranschaulichen, wie Sie den Zeitstempel mithilfe von RFC 3339 angeben. Format, yyyy-mm-ddThh:mm:ss+hh:mm (Jahr, Monat, Tag, Stunde, Minute, und die Abweichung von der UTC-Zeit). Die Abweichung von der UTC beträgt minus 8 Stunden, für PST angegeben.

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

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

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

principal, target, src, Die Attribute „intermediary“ und „observer“ beschreiben Assets die an der Veranstaltung beteiligt sind. Jeder speichert Informationen über Objekte, die an die Aktivität, wie sie im ursprünglichen Rohprotokoll aufgezeichnet wurde. Das kann das Gerät oder Nutzer, der die Aktivität durchgeführt hat, das Gerät oder den Nutzer, der das Ziel des Aktivitäten. Es kann auch eine Beschreibung eines Sicherheitsgeräts sein, das die Aktivität beobachtet hat, wie ein E-Mail-Proxy oder 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 von der für das Prinzipal.
• target: Objekt, auf das eine Aktion angewendet wird.

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

Die Hilfsfelder sind:

• intermediary: Jedes Objekt, das beim Ereignis als Vermittler fungierte. Dazu können Objekte wie Proxy- und Mailserver gehören.
• observer: Jedes Objekt, das nicht direkt mit dem den betreffenden Traffic. Dies könnte ein Scannen auf Sicherheitslücken oder ein Paket sein Schnüffler-Gerät.
• about: Alle anderen Objekte, die bei dem Ereignis eine Rolle gespielt haben und optional.

Hauptkontoattribute

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

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

Hinweis: Ein Sicherheitsgerät kann ein Ereignis aufzeichnen, es wird jedoch nicht im Hauptkontoattribut. Sie wird entweder im Beobachter- oder ein. Wenn die Sicherheitssoftware (z. B. Carbon Black) auf demselben Gerät ausgeführt wird, auf dem die Aktivität ihren Ursprung hat (z. B. ein Windows-Endpunkt, auf dem Malware erkannt wurde), ist das Windows-Gerät das Hauptkonto.

Das folgende JSON-Snippet veranschaulicht, wie das Attribut principal dargestellt wird.

"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, Hauptakteur des Ereignisses ist. Dieses Beispiel enthält die IP-Adresse des Geräts, Portnummer und Hostname. Außerdem enthält sie eine anbieterspezifische Asset-ID von Sophos, eine eindeutige Kennung, die vom Sicherheitsprodukt des Drittanbieters generiert wird.

Die Zielattribute

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

Bei einer Injektion von Prozess C in Zielprozess D ist Prozess C der und Prozess D ist das Ziel.

Abbildung: Haupt- und Zielelement

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

target {
   ip: "192.0.2.31"
   port: 80
}

Wenn im ursprünglichen Rohprotokoll weitere Informationen verfügbar sind, z. B. Hostname, zusätzliche IP-Adressen, MAC-Adressen und proprietäre Asset-IDs, sollten diese auch in den Ziel- und Hauptfeldern enthalten sein.

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

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 die Quelle -Objekt enthält). Beispiel: Wenn Nutzer U Datei A auf Computer X in Datei B auf Maschine Y würden sowohl Datei A als auch Maschine X im src-Teil von das UDM-Ereignis.

Das Zwischenattribut

Stellt Details zu einem oder mehreren Zwischengeräten dar, die die im Ereignis beschriebene Aktivität verarbeiten. Dazu gehören möglicherweise Gerätedetails wie Proxy-Server und SMTP-Relay-Server.

Das Attribut „observer“

Stellt ein Beobachtergerät dar, das kein direkter Vermittler ist, aber das betreffende Ereignis beobachtet und meldet. Dazu gehören beispielsweise ein Paketsniffer oder ein netzwerkbasierter Sicherheitsscanner.

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 ist. Für kann beispielsweise Folgendes erfasst werden:

• E-Mail-Anhä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 Minderung dieser Risiken und Bedrohungen ergriffen werden.

Hier sind einige 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 blockiert (security_result.action = BLOCK) Sie die E-Mail.
• Eine E-Mail-Sicherheits-Proxy-Firewall hat zwei infizierte Anhänge erkannt (security_result.category = SOFTWARE_MALICIOUS) und diese in 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 erlaubt eine Anmeldung (security_result.category = AUTH_VIOLATION), die blockiert wurde (security_result.action = BLOCK).
• Eine Malware-Sandbox hat Spyware entdeckt (security_result.category = SOFTWARE_MALICIOUS) in einem Dateianhang fünf Minuten, nachdem die Datei (security_result.action = ALLOW) per E-Mail an den Nutzer zugestellt.

Netzwerkattribut

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

Das Attribut „Erweiterungen“

In den Feldern unter diesem Attribut werden zusätzliche Metadaten zum erfassten Ereignis gespeichert im ursprünglichen Rohprotokoll. Sie kann Informationen zu Sicherheitslücken oder zusätzliche authentifizierungsbezogene Informationen 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“ den Wert „USER“ hat, werden im Datensatz Informationen zum Nutzer unter dem Attribut „entity.user“ gespeichert. Ist „metadata.entity_type“ ASSET, enthält Informationen über ein 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, an dem bzw. der der Datensatz erfasst wurde.
• 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 bei einem Asset oder windows_sid und E-Mail-Adresse bei einem Nutzer. Der Feldname ist „entity“, der Feldtyp ist jedoch ein Nomen. Ein Substantiv ist eine häufig verwendete Datenstruktur, in Entitäten und Ereignissen enthalten.

• Wenn „metadata.entity_type“ den Wert „USER“ hat, werden die Daten unter dem Attribut „entity.user“ gespeichert.
• Wenn „metadata.entity_type“ den Wert „ASSET“ hat, werden die Daten unter dem Attribut „entity.asset“ gespeichert.

Das Beziehungsattribut

In den Feldern unter dem Beziehungsattribut werden Informationen zu anderen Entitäten gespeichert, mit denen die Hauptentität in Beziehung steht. Beispiel: Die primäre Entität ist ein Nutzer und ihm wurde ein Laptop zugewiesen. Der Laptop ist eine zugehörige Entität. Informationen über den Laptop werden als „Entität“ gespeichert. mit einer metadata.entity_type = ASSET. Informationen zum Nutzer werden als Datensatz vom Typ „Entität“ mit dem Metadatentyp „metadata.entity_type = USER“ gespeichert.

Im User-Entität-Datensatz wird auch die Beziehung zwischen dem Nutzer und dem Laptop unter Verwendung der Felder unter "Relation" . Im Feld „relation.relationship“ wird die Beziehung des Nutzers zum Laptop gespeichert, insbesondere, dass der Nutzer Inhaber des Laptops ist. Im Feld „relation.entity_type“ ist der Wert „ASSET“ gespeichert, da der Laptop ein Gerät ist.

Felder unter dem Attribut „relations.entity“ enthalten Informationen zum Laptop, wie Hostnamen und MAC-Adresse. Beachten Sie noch einmal, dass der Feldname „entity“ und der Feldtyp „Noun“ ist. Ein Nomen ist eine häufig verwendete Datenstruktur. Felder unter dem Attribut „relation.entity“ speichern Informationen zum Laptop.

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