Übersicht über das Unified Data Model

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 wurden. 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 das Rohlog verwendet, um einen UDM-Datensatz zu erstellen. 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.
• Beziehungen zwischen Nutzern, Hosts und IP-Adressen lassen sich leichter erkennen, da die Daten in das standardmäßige UDM-Schema normalisiert werden.
• Regeln lassen sich einfacher schreiben, da sie plattformunabhängig sein können.
• Es ist einfacher, Protokolltypen von neuen Geräten zu unterstützen.

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

Sie können zwar 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 Details des Ereignisprotokolls 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 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.

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 auch mit dem Ereignis angeben müssen.
2. Ereigniszeitstempel angeben: Geben Sie den Ereigniszeitstempel an.
3. Nomen (Entitäten) angeben: Jedes Ereignis muss mindestens ein Nomen enthalten, das ein am Ereignis beteiligtes Gerät oder einen am Ereignis beteiligten Nutzer beschreibt.
4. Sicherheitsergebnis angeben: (Optional) Geben Sie Sicherheitsergebnisse an, indem Sie Details zu Sicherheitsrisiken und ‑bedrohungen angeben, die von einem Sicherheitssystem gefunden wurden, sowie die Maßnahmen, die zur Minimierung 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 für Metadata.event_type angegeben. Dazu gehören Werte wie PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS usw. Eine 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 jeden UDM-Ereignistyp finden Sie Informationen dazu, welche Felder für die einzelnen Ereignistypen enthalten sein müssen. Das folgende Beispiel zeigt, wie Sie PROCESS_OPEN als Ereignistyp mit der Proto3-Textnotation angeben:

metadata {
    event_type: PROCESS_OPEN
}

Ereigniszeitstempel angeben

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

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

Das folgende Beispiel zeigt, 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 -8 Stunden, was PST entspricht.

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

Substantive (Entitäten) angeben

Für jedes UDM-Ereignis müssen Sie ein oder mehrere Substantive definieren. Ein Nomen steht für einen Teilnehmer oder eine Entität in einem UDM-Ereignis. Ein Nomen kann beispielsweise das Gerät oder der Nutzer sein, der die in einem Ereignis beschriebene Aktivität ausführt, oder das Gerät oder der Nutzer, das/der das Ziel einer solchen im Ereignis beschriebenen Aktivität ist. Substantive können auch Dinge wie Anhänge oder URLs sein. Schließlich kann ein Substantiv auch verwendet werden, um ein Sicherheitsgerät zu beschreiben, das die im Ereignis beschriebene Aktivität beobachtet hat (z. B. ein E-Mail-Proxy oder ein Netzwerkrouter).

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

principal: Stellt die handelnde Entität 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) und optional Prozessdetails enthalten. Es darf KEINE der folgenden Felder enthalten: E-Mail-Adresse, Dateien, Registrierungsschlüssel oder -werte.

Wenn alle Ereignisse auf demselben Computer stattfinden, muss dieser Computer nur in principal beschrieben werden. Die Maschine muss nicht auch in target oder src beschrieben werden.

Hinweis :Ein Sicherheitsgerät kann ein Ereignis auslösen, es wird jedoch nicht im Feld „principal“ beschrieben, sondern entweder im Feld observer oder intermediary. 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 dieses Gerät auch 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 die IP-Adresse, die Portnummer und den Hostnamen des Geräts sowie eine anbieterspezifische Asset-Kennung (von Sophos), die eine eindeutige ID ist, die vom Drittanbieter-Sicherheitsprodukt generiert wird.

target: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 A beispielsweise als Prinzipal und B als Ziel beschrieben. Bei einer Prozessinjektion durch Prozess C in den Zielprozess D wird Prozess C als Prinzipal und Prozess D als Ziel beschrieben.

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
}

Wenn weitere Informationen verfügbar sind, z. B. Hostname, zusätzliche IP-Adressen, MAC-Adressen, proprietäre Asset-IDs usw., sollten diese ebenfalls in target enthalten sein.

Sowohl principal als auch target (sowie andere Substantive) können sich auf Akteure auf demselben Computer beziehen. Prozess A (Principal), der auf Maschine X ausgeführt wird, wirkt sich beispielsweise auf Prozess B (Ziel) aus, der ebenfalls auf Maschine X ausgeführt wird.

• src:Stellt ein Quellobjekt dar, auf das der Teilnehmer zusammen mit dem Geräte- oder Prozesskontext für das Quellobjekt (der Computer, auf dem sich das Quellobjekt befindet) reagiert. 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.
• intermediary:Stellt Details zu einem oder mehreren Zwischengeräten dar, die die im Ereignis beschriebene Aktivität verarbeiten. Dazu gehören Gerätedetails zu einem Proxyserver, SMTP-Relay-Server usw.
• Beobachter:Stellt ein Beobachtergerät dar (z. B. ein Packet Sniffer oder ein netzwerkbasierter Scanner für Sicherheitslücken), das kein direkter Vermittler ist, sondern das betreffende Ereignis beobachtet und darüber berichtet.
• about:Wird verwendet, um Details zu allen Objekten zu speichern, auf die im Ereignis verwiesen wird und die nicht anderweitig in participant, src, target, intermediary oder observer beschrieben werden. Damit lassen sich beispielsweise folgende Aktionen erfassen:
  • E‑Mail-Dateianhänge
  • Domains/URLs/IPs, die in eine E‑Mail 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 zwingende Anforderungen. Diese Anforderungen werden unter Erforderliche und optionale Felder für jeden UDM-Ereignistyp 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 Minimierung dieser Risiken und Bedrohungen ergriffen wurden. Im Folgenden finden Sie Beispiele für einige Arten von Sicherheitsereignissen, für die die Felder von „SecurityResult“ ausgefüllt werden müssen:

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

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-Anmeldungen mit der Ereignis-ID 4624

Die folgende Suche listet die erfolgreichen Anmeldeereignisse vom Typ 4624 für Microsoft Windows auf, zusammen mit dem Zeitpunkt, zu dem die Ereignisse generiert wurden. Die Suche 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 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: 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. Obwohl target.user.department nicht direkt mit Nutzeranmeldeereignissen verknüpft ist, ist es dennoch in den LDAP-Daten vorhanden, 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 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
• 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 zeigen, 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. Jedes speichert Informationen zu Objekten, die an der Aktivität beteiligt sind, wie im ursprünglichen Rohlog 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: 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 das handelnde Rechtssubjekt 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-Adressen, 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 würde 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 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-Asset

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 Felder „Ziel“ und „Haupt-Asset“ 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

Enthält Details zu einem oder mehreren Zwischengeräten, 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“

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ö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 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 und diese Anhänge in Quarantäne verschoben und desinfiziert (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION). Anschließend wurde die desinfizierte E‑Mail 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 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 Arbeitsstation, 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 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 Entität. 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 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