Übersicht über das einheitliche Datenmodell

Dieses Dokument bietet einen Überblick über das Unified Data Model (UDM). Weitere Informationen Details zu UDM-Feldern, einschließlich einer Beschreibung der einzelnen Felder, finden Sie im UDM-Feld Liste enthalten. Weitere Informationen zu Parserzuordnung siehe Wichtige UDM-Felder für Parser Zuordnung.

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. 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.
• Beziehungen zwischen Nutzern, Hosts und IP-Adressen einfacher 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: Das Modul für Google Security Operations-Regeln verwendet dieselben UDM-Feldnamen. Sie können dieselben Feldnamen beim Erstellen von Regeln verwenden.

Obwohl Sie mit einer Rohprotokollsuche nach Ereignissen suchen können, funktioniert eine UDM-Suche weil sie so spezifisch sind.

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. UDM kann beispielsweise Endpunktprozessereignisse so einfach verarbeiten wie Netzwerkereignisse. Kommunikationsereignisse.

UDM-Struktur

UDM-Ereignisse bestehen aus mehreren Abschnitten. Der erste Abschnitt in jeder UDM-Ereignis ist der Metadatenbereich. 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 beschrieben. der Veranstaltung. Nicht benötigte Abschnitte werden nicht berücksichtigt, wodurch Arbeitsspeicher gespart wird.

• principal: Entität, von der die Aktivität im Ereignis ausgeht. Bereiche, die auf die Quelle (src) und das Ziel verweisen (target) 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

Mit der folgenden Suche werden die Ereignisse für eine erfolgreiche Anmeldung in Microsoft Windows 4624 aufgelistet. und wann die Ereignisse generiert wurden, basierend auf nur zwei UDM-Feldern:

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

Beispiel: Nach allen erfolgreichen Anmeldungen suchen

Mit der folgenden Suche werden alle erfolgreichen Log-in-Ereignisse aufgelistet, unabhängig vom Anbieter oder 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 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 Zielbereich umfasst Unterabschnitten und Feldern, die das Ziel beschreiben. Das Ziel in dieser Fall ein Nutzer ist und mit einer Reihe von Attributen verknüpft ist. auch eine Datei, eine Registrierungseinstellung oder ein Asset sein. In diesem Beispiel wird nach "fkolzig" gesucht mit dem Feld target.user.userid.

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 Es enthält auch ein UDM-Feld aus dem Abschnitt „Network“, 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 net.exe und suchen Sie unter dem erwarteten Pfad nach dieser Datei. Die 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: Nutzer identifizieren, der die .
• 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 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. Jede UDM record an, 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: Kontextdarstellung von Elementen wie Assets, Nutzer und Ressourcen in Ihrer Umgebung. Sie wird aus einer Quelle von Truth. Dies ist das UDM-Entitätsdatenmodell.

Hier sehen Sie zwei visuelle Darstellungen des Ereignisdatenmodells Entitätsdatenmodell.

Abbildung: Ereignisdatenmodell

Hinweis: Der Begriff „Substantiv“ beschreibt die Art des Attributs. 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. Meistens ist nur ein Teil davon verwendet. Welche Felder Daten speichern, hängt vom Ereignistyp und vom Rolle spielt, die jedes Objekt bei dem Ereignis spielt.

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

• 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 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 Ereignistyp ist, sind bestimmte Attribute erforderlich, während andere optional sind. Die erforderliche und optionale Attribute werden durch „metadata.event_type“ bestimmt Wert. 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. die 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 die metadata.event_timestamp enthalten, die ist der 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 durchgeführten Aktion an und ist unabhängig vom Anbieter. Produkt oder Plattform. Beispiele für Werte sind PROCESS_OPEN, FILE_CREATION, USER_CREATION, und NETWORK_DNS. Die vollständige Liste finden Sie im UDM-Feld list enthält.

Der Wert metadata.event_type bestimmt, welcher zusätzliche erforderliche und optionale Felder müssen im UDM-Eintrag enthalten sein. Informationen zu Welche Felder für jeden Ereignistyp eingeschlossen werden sollen, siehe UDM-Nutzung .

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

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 ausgefü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 mit dem Prinzipal.
• 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 im . Dazu können Objekte wie Proxy-Server und E-Mail-Server 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.

Tritt das Ereignis auf einem einzelnen Computer ein, wird dieser in den Prinzipalattribut. Die Maschine muss nicht im "target" oder "src" verwenden.

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, von dem die Aktivität ausgeht, z. B. Endpunkt, an dem Malware gefunden 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 umfasst die IP-Adresse des Geräts, Portnummer und Hostname. Sie enthält auch eine anbieterspezifische Asset-ID, Dies ist eine eindeutige Kennung, die vom Drittanbieter-Sicherheitscenter Produkt.

Die Zielattribute

Stellt ein Zielgerät dar, auf das vom Ereignis verwiesen wird, oder ein Objekt im Zielgerät Bei einer Firewallverbindung von Gerät A zu Gerät B Gerät A wird als Hauptkonto 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: 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 Rohprotokoll weitere Informationen verfügbar sind, z. B. Hostname, zusätzliche IP-Adressen, MAC-Adressen und proprietäre Asset-IDs. sollte auch in den Feldern „target“ und „principal“ 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

Enthält Details zur Verarbeitungsaktivität eines oder mehrerer Zwischengeräte im Ereignis beschrieben. Dazu können z. B. Details zu Geräten gehören, z. B. Proxyserver und SMTP-Relay-Server.

Das Beobachter-Attribut

Ein Beobachtergerät, das kein direkter Vermittler ist, sondern das betreffende Ereignis beobachtet und darüber berichtet. Dies könnte ein Paket Sniffer oder netzwerkbasierten Schwachstellen-Scanner.

Das Attribut „about“

Hier werden Details zu einem Objekt gespeichert, auf das das Ereignis verweist, das jedoch nicht in den Feldern Principal, src, target, intermediary oder observer beschrieben. Für kann beispielsweise Folgendes erfasst werden:

• 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 die von einem Sicherheitssystem gefunden werden, und die Maßnahmen, die zur Minderung dieser Risiken Bedrohungen.

Hier sind Arten von Informationen, die im Feld „security_result“ gespeichert werden Attribut:

• 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 unter Quarantäne gestellt und desinfiziert (security_result.action = QUARANTINE oder security_result.action = ALLOW_WITH_MODIFICATION), diese Anhänge und dann die desinfizierten E-Mails.
• Ein SSO-System ermöglicht eine Anmeldung (security_result.category = AUTH_VIOLATION) der 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.

Das Netzwerkattribut

In Netzwerkattributen werden Daten zu netzwerkbezogenen Ereignissen und Details zu in untergeordneten Nachrichten. Dazu gehören Aktivitäten wie gesendete und empfangenen 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 Informationen in Bezug auf die Authentifizierung.

Struktur einer UDM-Entität

In einem UDM-Entitätseintrag werden Informationen zu jeder Entität innerhalb einer Organisation gespeichert. Ist metadata.entity_type USER, speichert der Datensatz Informationen über den user im Attribut „entity.user“ angegeben. 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: das Datum und Zeitpunkt 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 zum Entität wie 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. Beachten Sie, dass der Name des Feldes "entity" lautet, aber das Feld Feldtyp ist ein Substantiv. Ein Substantiv ist eine häufig verwendete Datenstruktur, in Entitäten und Ereignissen enthalten.

• Ist der metadata.entity_type USER, werden die Daten unter dem entity.user.
• Ist der metadata.entity_type ASSET, werden die Daten im entity.asset.

Das Attribut „relation“

In den Feldern unter dem Attribut „Beziehung“ werden Informationen zu anderen Entitäten gespeichert, die auf die sich die primäre Entität bezieht. Wenn die primäre Entität z. B. „Nutzer“ ist, und der Nutzer hat einen Laptop erhalten. Der Laptop ist ein verwandtes Element. Informationen über den Laptop werden als „Entität“ gespeichert. mit einer metadata.entity_type = ASSET. Informationen über den Nutzer werden als "entity" -Datensatz mit dem metadata.entity_type = USER.

Der User-Entität-Datensatz erfasst auch die Beziehung zwischen dem Nutzer und dem Laptop unter Verwendung der Felder unter "Relation" . Beziehung.relationship die Beziehung der Nutzenden zum Laptop, insbesondere der Nutzer Eigentümer des Laptops ist. Im Feld „relation.entity_type“ wird der Wert ASSET, weil der Laptop ein Gerät ist.

Felder unter dem Attribut „relations.entity“ enthalten Informationen zum Laptop, wie Hostnamen und MAC-Adresse. Beachten Sie, dass der Feldname "entity" und der Feldtyp ist ein Substantiv. 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 gespeichert zwischen Nutzer und Laptop, insbesondere ob die Beziehung bidirektional oder unidirektional.