Ü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 Liste der UDM-Felder. Weitere Informationen zu Parserzuordnung: 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 derselben 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 von neuen Geräten ist einfacher.

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, durch die Ereignisse geleitet werden, z. B. ein Proxyserver oder ein SMTP-Relay.
• observer: Systeme wie Paketsniffer, die den Traffic passiv überwachen.

Beispiele für UDM-Suchanfragen

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

Beispiel: Suche nach erfolgreichen Microsoft Windows-Anmeldungen vom Typ 4624

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: 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 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, in denen Daten gespeichert werden. Jede UDM record an, ob er ein Ereignis oder eine Entität beschreibt. 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 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. Das ist das UDM-Ereignisdatenmodell.
• 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

Abbildung: Entitätsdatenmodell

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 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 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 einem der folgenden Standards codiert sein: 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, 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 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 der Nutzer sein, der die Aktivität ausgeführt hat, oder das Gerät oder der Nutzer, auf den die Aktivität ausgerichtet ist. Es kann sich auch um ein Sicherheitsgerät handeln, das die Aktivität beobachtet hat, z. B. einen E-Mail-Proxy oder einen Netzwerkrouter.

Die am häufigsten verwendeten Attribute sind:

• principal: Objekt, das die Aktivität ausgeführt hat.
• src: Das Objekt, das die Aktivität initiiert, sofern es sich von dem Hauptkonto unterscheidet.
• 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 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 eine Rolle bei dem Ereignis gespielt haben. Optional.

Die Hauptattribute

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.

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, der der Hauptakteur des Ereignisses war. Dieses Beispiel enthält 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 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 Prozessinjektion durch Prozess C in den Zielprozess D ist Prozess C der Hauptprozess 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 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 gesprochen, 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. Dazu gehören beispielsweise ein Paketsniffer oder ein netzwerkbasierter Sicherheitsscanner.

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).
• In einer Malware-Sandbox wurde fünf Minuten nach der Zustellung (security_result.action = ALLOW) eines Anhangs (security_result.category = SOFTWARE_MALICIOUS) an den Posteingang des Nutzers Spyware erkannt.

Netzwerkattribut

In Netzwerkattributen werden Daten zu netzwerkbezogenen Ereignissen und Details zu Protokollen in Unternachrichten gespeichert. 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 können 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. Wenn „metadata.entity_type“ den Wert „USER“ hat, werden im Datensatz Informationen zum Nutzer unter dem Attribut „entity.user“ gespeichert. Wenn „metadata.entity_type“ den Wert „ASSET“ hat, enthält der Eintrag Informationen zu einem Asset wie einer Workstation, einem Laptop, einem Smartphone oder einer virtuellen 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 Entitätstyp, 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.

Im User-Entität-Datensatz wird 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. 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.