Übersicht über UDM

Unterstützt in:

Google SecOps SIEM

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 strukturierter 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.

Hinweis: Die Google SecOps-Regel-Engine verwendet dieselben UDM-Feldnamen. Sie können dieselben Feldnamen verwenden, wenn Sie Regeln erstellen.

Sie können zwar auch mit einer Rohlog-Suche nach Ereignissen suchen, eine UDM-Suche ist jedoch schneller und genauer, da sie spezifischer ist. Google SecOps erfasst Rohprotokolldaten und speichert die Ereignisprotokolldetails im UDM-Schema. 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 Metadatenbereich 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.

UDM-Ereignis formatieren

Damit ein UDM-Ereignis für den Versand an Google formatiert werden kann, müssen Sie die folgenden Schritte ausführen:

1. Ereignistyp angeben: Der ausgewählte Ereignistyp bestimmt, welche Felder Sie ebenfalls in das Ereignis aufnehmen müssen.
2. Zeitstempel des Ereignisses angeben
3. Substantive (Entitäten) angeben: Jedes Ereignis muss mindestens ein Substantiv enthalten, das ein am Ereignis beteiligtes Teilnehmergerät oder einen am Ereignis beteiligten Nutzer beschreibt.
4. Optional: Sicherheitsergebnis angeben: Geben Sie Sicherheitsergebnisse an, indem Sie Details zu den Risiken und Bedrohungen angeben, die ein Sicherheitssystem findet. Geben Sie die konkreten Maßnahmen an, die zur Minderung dieser Risiken und Bedrohungen ergriffen wurden.
5. Füllen Sie die restlichen erforderlichen und optionalen Ereignisinformationen mit den UDM-Ereignisfeldern aus.

Ereignistyp angeben

Der wichtigste Wert, der für ein im UDM-Format eingereichtes Ereignis definiert wird, ist der Ereignistyp. Er wird mit einem der möglichen Werte angegeben, die für Metadata.event_type verfügbar sind. Dazu gehören Werte wie PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS usw. (die vollständige Liste finden Sie unter „Metadata.event_type“). Für jeden Ereignistyp müssen Sie auch eine Reihe anderer Felder und Werte mit den Informationen zum ursprünglichen Ereignis ausfüllen. Unter Erforderliche und optionale Felder für die einzelnen UDM-Ereignistypen finden Sie weitere Informationen dazu, welche Felder für die einzelnen Ereignistypen enthalten sein müssen. Im folgenden Beispiel wird gezeigt, wie Sie PROCESS_OPEN als Ereignistyp mit der Proto3-Textnotation angeben:

metadata {
    event_type: PROCESS_OPEN
}

Zeitstempel des Ereignisses angeben

Für jedes Ereignis, das im UDM-Format übermittelt wird, müssen Sie den GMT-Zeitstempel mit Metadata.event_timestamp angeben. Der Stempel muss mit einem der folgenden Standards codiert sein:

• Für JSON RFC 3339 verwenden
• Proto3-Zeitstempel

Im folgenden Beispiel wird gezeigt, wie Sie den Zeitstempel im RFC 3339-Format angeben. In diesem Beispiel: jjjj-mm-ttThh:mm:ss+hh:mm – Jahr, Monat, Tag, Stunde, Minute, Sekunde und der Zeitversatz zur UTC. Der Zeitversatz zu UTC beträgt minus 8 Stunden, was PST entspricht.

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

Substantive (Entitäten) angeben

Definieren Sie für jedes UDM-Ereignis mindestens ein Substantiv. Substantive stehen für Teilnehmer oder Entitäten, z. B. den Nutzer, der die Aktivität ausführt, das Ziel der Aktion oder das Sicherheitsgerät, das das Ereignis beobachtet (z. B. ein E‑Mail-Proxy oder ein Router). Substantive stehen auch für Objekte wie URLs oder Anhänge.

Achtung :Bei UDM-Ereignissen gilt für die Hostname-Felder eine Beschränkung von 256 Zeichen (z. B. principal.hostname oder target.hostname). Wenn Sie Rohlogs (aus einer Quelle wie ArcSight) zuordnen, die dieses Limit überschreiten, führt dies zu Validierungsfehlern und verworfenen Logs. Das ist nicht auf einzelne Parser beschränkt.

Für ein UDM-Ereignis muss mindestens eines der folgenden Substantive angegeben werden:

principal: Stellt das handelnde Rechtssubjekt oder das Gerät dar, von dem die im Ereignis beschriebene Aktivität ausgeht. Der Prinzipal muss mindestens ein Maschinendetail (Hostname, MAC-Adressen, IP-Adressen, Port, produktspezifische Kennungen wie eine CrowdStrike-Maschinen-GUID) oder ein Nutzerdetail (z. B. Nutzername) enthalten und kann optional Prozessdetails enthalten. Sie darf KEINE der folgenden Felder enthalten: E‑Mail-Adresse, Dateien, Registrierungsschlüssel oder ‑werte.

Wenn alle Aktivitäten auf einem einzelnen Computer stattfinden, beschreiben Sie diesen Computer nur im principal-Block. Geben Sie die Maschinendetails nicht doppelt in target oder src an.

Hinweis :Beschreiben Sie Sicherheitsgeräte nicht im Feld principal, auch wenn sie das Ereignis ausgelöst haben. Verwenden Sie stattdessen die Felder observer oder intermediary. Wenn Sicherheitssoftware auf demselben Gerät ausgeführt wird, von dem die Aktivität stammt (z. B. ein EDR-Agent auf einem Windows-Endpunkt), ist dieses Gerät weiterhin der Prinzipal.

Das folgende Beispiel zeigt, wie die Felder principal ausgefüllt werden könnten:

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

Dieses Beispiel enthält Details zum Gerät und zum Nutzer, der die Hauptrolle bei dem Ereignis gespielt hat. Sie enthält auch eine anbieterspezifische Asset-Kennung (von Sophos), eine eindeutige ID, die vom Drittanbieter-Sicherheitsprodukt generiert wird.

target: Stellt das Gerät oder Objekt dar, auf das sich das Ereignis bezieht. Bei einer Firewallverbindung von Gerät A zu Gerät B ist A das Prinzipal und B das Ziel. Bei einer Prozessinjektion, bei der Prozess C in Prozess D injiziert wird, ist C der Prinzipal und D das Ziel.

Hauptkonto im Vergleich zum Ziel in UDM

Das folgende Beispiel zeigt, wie die Felder für ein Zielvorhaben ausgefüllt werden:

target {
   ip: "198.51.100.31"
   port: 80
}

Fügen Sie dem target-Block alle anderen verfügbaren Informationen hinzu, z. B. den Hostnamen, zusätzliche IP- oder MAC-Adressen und proprietäre Asset-IDs.

Sowohl principal als auch target (und andere Nomen) können sich auf Akteure auf demselben Computer beziehen. Wenn beispielsweise Prozess A (Hauptkonto), der auf Computer X ausgeführt wird, auf Prozess B (Ziel) einwirkt, der ebenfalls auf Computer X ausgeführt wird, beschreiben Sie beide in ihren jeweiligen Blöcken.

• src:Stellt das Quellobjekt dar, auf das sich die Aktion bezieht, sowie dessen Kontext, z. B. den Computer, auf dem es sich befindet. Wenn Nutzer U beispielsweise Datei A auf Computer X in Datei B auf Computer Y kopiert, geben Sie sowohl Datei A als auch Computer X im src-Block an.

• intermediary:Enthält Details zu einem oder mehreren Geräten, auf denen die im Ereignis beschriebene Aktivität verarbeitet wurde. Dazu gehören Informationen für Geräte wie Proxyserver und SMTP-Relays.

• Beobachter:Stellt ein Gerät dar, das kein direkter Vermittler ist, aber Aktivitäten überwacht und meldet. Dazu gehören Geräte wie Packet Sniffers oder netzwerkbasierte Vulnerability Scanner.

• about:Speichert Details für alle Objekte, auf die sich das Ereignis bezieht, die nicht in participant, src, target, intermediary oder observer passen. Damit können Sie unter anderem Folgendes erfassen:

  • E‑Mail-Dateianhänge
  • Domains/URLs/IPs, die in den E‑Mail-Text eingebettet sind
  • DLLs, die während eines PROCESS_LAUNCH-Ereignisses geladen werden

Die Entitätsabschnitte von UDM-Ereignissen enthalten Informationen zu den verschiedenen Teilnehmern (Geräte, Nutzer, Objekte wie URLs, Dateien usw.), die im Ereignis beschrieben werden. Für das Google Security Operations-UDM gelten beim Ausfüllen von Noun-Feldern bestimmte Anforderungen. Diese Anforderungen werden unter Erforderliche und optionale Felder für die einzelnen UDM-Ereignistypen beschrieben. Die Menge der Entitätsfelder, die ausgefüllt werden müssen, hängt vom Ereignistyp ab.

Sicherheitsergebnis angeben

Optional können Sie Sicherheitsergebnisse angeben, indem Sie die SecurityResult-Felder ausfüllen. Dazu gehören Details zu Sicherheitsrisiken und ‑bedrohungen, die vom Sicherheitssystem erkannt wurden, sowie die Maßnahmen, die zur Eindämmung dieser Risiken und Bedrohungen ergriffen wurden. Im Folgenden finden Sie einige Beispiele für Arten von Sicherheitsereignissen, für die SecurityResult-Felder ausgefüllt werden müssen:

• Eine E‑Mail-Sicherheits-Proxy-Firewall hat zwei infizierte Anhänge (SOFTWARE_MALICIOUS) erkannt. Sie wurden in Quarantäne verschoben und desinfiziert (QUARANTINE, ALLOW_WITH_MODIFICATION) und dann weitergeleitet.

• Ein SSO-System hat einen Anmeldeversuch ermöglicht, der zu einem AUTH_VIOLATION geführt und blockiert wurde (BLOCK).

• Eine Malware-Sandbox hat fünf Minuten nach der Zustellung (ALLOW) der E‑Mail an den Posteingang des Nutzers Spyware (SOFTWARE_MALICIOUS) in einem Dateianhang erkannt.

Beispiele für UDM-Suchanfragen

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

Beispiel: Suche nach erfolgreichen Microsoft Windows-Anmeldungen mit der Ereignis-ID 4624

Die folgende Suche listet die erfolgreichen Anmeldeereignisse von 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

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

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

Beispiel: Nach erfolgreichen Nutzeranmeldungen suchen

Im folgenden Beispiel wird veranschaulicht, wie Sie nach userid "fkolzig" suchen und ermitteln, wann sich der Nutzer mit dieser Nutzer-ID erfolgreich angemeldet hat. Sie können diese Suche im Zielabschnitt durchführen. Der Abschnitt „Ziel“ 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 bestimmten Datei im erwarteten Pfad. Das Feld, nach dem Sie suchen, ist target.process.file.full_path. Für diese Suche geben Sie den spezifischen 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: Suche nach erfolgreichen Nutzeranmeldungen, 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: Event und Entity

Im UDM-Schema werden alle verfügbaren Attribute beschrieben, in denen Daten gespeichert werden. In jedem UDM-Datensatz wird angegeben, 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 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 (z. B. Firewall und Webproxy) aufgezeichnet wurde.
• UDM-Entität: Kontextbezogene Darstellung von Elementen wie Assets, Nutzern und Ressourcen in Ihrer Umgebung. Sie stammen aus einer Datenquelle mit dem Status „Source of Truth“.

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

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

Abbildung: Ereignisdatenmodell

Hinweis :Der Begriff „Noun“ (Substantiv) beschreibt den Attributtyp. Die Begriffe „Asset“, „Nutzer“ und „Ressource“ sind die Feldnamen, in denen Daten gespeichert werden.

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
• Prinzipal
• Ziel
• src
• Beobachter
• Vermittler
• über
• Netzwerk
• security_result

• Erweiterungen

  

  Abbildung: Ereignisdatenmodell

Im Abschnitt Metadaten werden der Zeitstempel und die event_type gespeichert und das Gerät wird 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 eine Teilmenge 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‑Mail- 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 Bereich extensions ist eine Sammlung von Schlüssel/Wert-Paaren in freiem Format.

In jedem UDM-Ereignis werden Werte aus einem ursprünglichen Rohlog-Ereignis gespeichert. Je nach Ereignistyp sind bestimmte Attribute erforderlich, andere sind optional. Die erforderlichen und optionalen Attribute werden durch den metadata.event_type-Wert bestimmt. 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 im UDM-Datensatz nicht 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, 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 minus 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 Epoch-Format 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. Beispielwerte sind PROCESS_OPEN, FILE_CREATION, USER_CREATION und NETWORK_DNS. Eine vollständige Liste finden Sie im Dokument UDM-Feldliste.

Der Wert metadata.event_type 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 an dem Ereignis beteiligt sind. Darin werden Informationen zu Objekten gespeichert, die an der Aktivität beteiligt sind, wie im ursprünglichen Rohprotokoll aufgezeichnet. Das 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: Das 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 fungiert haben. 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 das handelnde Rechtssubjekt oder das Gerät dar, von dem die Aktivität ausgegangen ist. Der Prinzipal muss mindestens ein Gerätedetail (Hostname, MAC-Adresse, IP-Adresse, produktspezifische Kennungen wie eine CrowdStrike-Geräte-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.

Hinweis :Ein Sicherheitsgerät kann ein Ereignis aufzeichnen, das nicht im Hauptattribut beschrieben wird. Es wird entweder im Attribut „Beobachter“ oder „Vermittler“ beschrieben. Wenn die Sicherheitssoftware (z. B. Carbon Black) auf demselben Gerät ausgeführt wird, von dem die Aktivität stammt (z. B. ein Windows-Endpunkt, auf dem Malware erkannt wurde), ist das Windows-Gerät der Hauptakteur.

Das folgende JSON-Snippet zeigt, 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: Hauptkonto im Vergleich zum Zielkonto

Das folgende Beispiel veranschaulicht, 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 Felder „Ziel“ und „Prinzipal“ 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 Proxyserver und SMTP-Relayserver gehören.

Das Attribut „Beobachter“

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

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önnte Folgendes erfasst werden:

• E‑Mail-Dateianhänge.
• Domains, URLs oder IP-Adressen, die in den 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 wurden, sowie zu den Maßnahmen, die zur Risikominderung ergriffen wurden.

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

• Ein E‑Mail-Sicherheitsproxy hat einen Phishingversuch (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 Nutzer in seinem Posteingang 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 „Erweiterungen“

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 der Entität

In den Feldern unter dem Attribut „entity“ werden Informationen zur jeweiligen Entität gespeichert, z. B. Hostname und IP-Adresse, wenn es sich um einen Asset handelt, oder „windows_sid“ und E-Mail-Adresse, wenn es sich um einen Nutzer handelt. Der Feldname ist entity, der Feldtyp ist jedoch ein Nomen. 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 im Attribut entity.user gespeichert.
• Wenn metadata.entity_type ASSET ist, werden die Daten im 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 Nutzerentitätsdatensatz 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 den Laptop besitzt. Im Feld relation.entity_type wird der Wert ASSET gespeichert, da es sich bei dem Laptop um ein Gerät handelt.

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 dem Nutzer und dem Laptop gespeichert, insbesondere ob die Beziehung bidirektional oder unidirektional ist.

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