UDM-Übersicht

Unterstützt in:

Google SecOps SIEM

Dieses Dokument bietet eine Übersicht über das Unified Data Model (UDM). Weitere Informationen zu UDM-Feldern, einschließlich einer Beschreibung der einzelnen Felder, finden Sie in der UDM-Feldliste. Weitere Informationen zur Parser-Zuordnung finden Sie unter Wichtige UDM-Felder für die Parser-Zuordnung.

Das UDM ist eine Standarddatenstruktur von Google Security Operations, in der Informationen zu Daten gespeichert werden, die von Quellen empfangen wurden. Sie wird auch als Schema bezeichnet. Google SecOps speichert die empfangenen Originaldaten in zwei Formaten: als ursprüngliches Rohlog und als strukturierter UDM-Eintrag. Der UDM-Eintrag 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-Eintrag zu erstellen. Kunden können Logrohdaten auch in das strukturierte UDM-Format umwandeln, bevor sie die Daten über die Ingestion API an Google SecOps senden.

Zu den Vorteilen von UDM gehören:

• Speichert denselben Datensatztyp von verschiedenen Anbietern mit derselben Semantik.
• Beziehungen zwischen Nutzern, Hosts und IP-Adressen lassen sich leichter identifizieren, da die Daten im Standard-UDM-Schema normalisiert sind.
• Regeln lassen sich einfacher schreiben, da sie plattformunabhängig sein können.
• Protokolltypen von neuen Geräten können einfacher unterstützt werden.

Hinweis: Die Google SecOps-Regel-Engine verwendet dieselben UDM-Feldnamen. Sie können diese Feldnamen auch beim Erstellen von Regeln verwenden.

Sie können zwar mit einer Rohlogsuche nach Ereignissen suchen, eine UDM-Suche ist jedoch aufgrund ihrer Spezifität schneller und präziser. Google SecOps erfasst Rohprotokolldaten und speichert die Details des Ereignisprotokolls im UDM-Schema. Das UDM bietet ein umfassendes Framework mit Tausenden von Feldern, um verschiedene Ereignistypen zu beschreiben und zu kategorisieren, z. B. Endpunktprozessereignisse und Netzwerkkommunikationsereignisse.

UDM-Struktur

UDM-Ereignisse bestehen aus mehreren Abschnitten. Der erste Abschnitt, der in jedem UDM-Ereignis zu finden ist, ist der Metadatenabschnitt. Es enthält eine grundlegende Beschreibung des Ereignisses, einschließlich des Zeitstempels, zu dem das Ereignis aufgetreten ist, und des Zeitstempels, zu dem es in Google SecOps aufgenommen wurde. Außerdem enthält sie Produktinformationen, Version und Beschreibung. Der Aufnahme-Parser klassifiziert jedes Ereignis anhand eines vordefinierten Ereignistyps, unabhängig vom spezifischen Produktprotokoll. Allein mit den Metadatenfeldern können Sie schnell mit der Suche in den Daten beginnen.

Zusätzlich zum Metadatenbereich werden in anderen Bereichen weitere Aspekte des Ereignisses beschrieben. Wenn ein Abschnitt nicht benötigt wird, wird er nicht einbezogen, was Speicherplatz spart.

• principal: Entität, von der die Aktivität im Ereignis ausgeht. Abschnitte, die auf die Quelle (src) und das Ziel (target) verweisen, sind ebenfalls enthalten.
• intermediary: Systeme, die Ereignisse durchlaufen, z. B. ein Proxyserver oder ein SMTP-Relay.
• observer: Systeme wie Paket-Sniffer, die den Traffic passiv überwachen.

UDM-Ereignis formatieren

So formatieren Sie ein UDM-Ereignis, damit es an Google gesendet werden kann:

1. Ereignistyp angeben: Der ausgewählte Ereignistyp bestimmt, welche Felder Sie auch in das Ereignis aufnehmen müssen.
2. Geben Sie den Zeitstempel des Ereignisses an.
3. Nomen (Entitäten) angeben: Jedes Ereignis muss mindestens ein Nomen enthalten, das ein Gerät oder einen Nutzer beschreibt, das bzw. der am Ereignis beteiligt ist.
4. Optional: Sicherheitsergebnis angeben: Geben Sie Sicherheitsergebnisse an, indem Sie Details zu den Risiken und Bedrohungen angeben, die ein Sicherheitssystem findet. Geben Sie die spezifischen Maßnahmen an, die zur Minimierung dieser Risiken und Bedrohungen ergriffen wurden.
5. Geben Sie die restlichen erforderlichen und optionalen Ereignisinformationen in die UDM-Ereignisfelder ein.

Ereignistyp angeben

Sie müssen für jedes im UDM-Format gesendete Ereignis immer den Ereignistyp angeben. Geben Sie diesen Wert mit einem der möglichen Werte für metadata.event_type an. Dazu gehören Werte wie PROCESS_OPEN, FILE_CREATION, USER_CREATION und NETWORK_DNS. Eine vollständige Liste finden Sie unter Metadata.event_type. Für jeden Ereignistyp müssen Sie außerdem eine Reihe anderer Felder und Werte mit den Informationen füllen, die mit dem ursprünglichen Ereignis verknüpft sind. Weitere Informationen dazu, welche Felder für die einzelnen Ereignistypen erforderlich sind, finden Sie unter Erforderliche und optionale Felder für jeden Ereignistyp.

Im folgenden Beispiel wird gezeigt, wie Sie PROCESS_OPEN als Ereignistyp mithilfe der Proto3-Textnotation angeben:

metadata {
    event_type: PROCESS_OPEN
}

Zeitstempel des Ereignisses angeben

Sie müssen den GMT-Zeitstempel für jedes im UDM-Format gesendete Ereignis mit „Metadata.event_timestamp“ angeben. Der Stempel muss mit einem der folgenden Standards codiert sein:

• Verwenden Sie für JSON RFC 3339.
• 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"
}

Nomen (Entitäten) angeben

Definieren Sie für jedes UDM-Ereignis ein oder mehrere Substantive. Nomen 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 Router). Substantive stehen auch für Objekte wie URLs oder Anhänge.

Achtung: Für UDM-Ereignisse gilt für die Hostnamenfelder eine Zeichenbeschränkung von 256 Zeichen (z. B. principal.hostname oder target.hostname). Das Zuordnen von Rohlogs (aus einer Quelle wie ArcSight), die diese Beschränkung überschreiten, führt zu Validierungsfehlern und verworfenen Logs. Dies gilt nicht für einzelne Parser.

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. Das Hauptkonto muss mindestens ein Gerätedetail (Hostname, MACs, IPs, Port, produktspezifische Kennungen wie eine CrowdStrike-Geräte-GUID) oder Nutzerdetail (z. B. Nutzername) und optional Prozessdetails enthalten. Sie darf KEINES der folgenden Felder enthalten: E-Mail, Dateien, Registrierungsschlüssel oder Werte.

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

Hinweis: Beschreiben Sie im Feld principal keine Sicherheitsgeräte, 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 das Hauptkonto.

Das folgende Beispiel zeigt, wie die principal-Felder 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 der Hauptakteur des Ereignisses war. Außerdem enthält es eine anbieterspezifische Asset-ID (von Sophos), die eine eindeutige ID ist, die vom Sicherheitsprodukt des Drittanbieters 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 Hauptkonto und B das Ziel. Bei einer Prozessinjektion, bei der Prozess C in Prozess D injiziert wird, ist C das Subjekt und D das Ziel.

Hauptkonto im Vergleich zum Ziel im UDM

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

target {
   ip: "198.51.100.31"
   port: 80
}

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

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

• src: Steht für das Quellobjekt, auf das reagiert wird, und seinen Kontext, z. B. den Computer, auf dem es sich befindet. Wenn Nutzer U beispielsweise Datei A auf Maschine X in Datei B auf Maschine Y kopiert, geben Sie sowohl Datei A als auch Maschine X im Block src an.

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

• observer: Ein Gerät, das kein direkter Vermittler ist, aber Aktivitäten überwacht und meldet. Dazu gehören Geräte wie Paket-Sniffer oder netzwerkbasierte Vulnerability Scanner.

• about: Speichert Details zu allen Objekten, auf die das Ereignis verweist und die nicht in participant, src, target, intermediary oder observer passen. Damit können Sie Folgendes im Blick behalten:

  • E‑Mail-Dateianhänge
  • Domains/URLs/IPs, die in einen 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 obligatorische Anforderungen für das Ausfüllen von Nomenfeldern. Diese Anforderungen werden unter Erforderliche und optionale Felder für jeden UDM-Ereignistyp beschrieben. Die Gruppe der Entitätsfelder, die ausgefüllt werden müssen, unterscheidet sich je nach Ereignistyp.

Sicherheitsergebnis angeben

Sie können optional Sicherheitsergebnisse angeben, indem Sie die SecurityResult-Felder ausfüllen. Dazu gehören Details zu Sicherheitsrisiken und Bedrohungen, die vom Sicherheitssystem gefunden 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 SecurityResult-Felder ausgefüllt werden müssen:

• Eine E-Mail-Sicherheits-Proxy-Firewall hat zwei infizierte Anhänge (SOFTWARE_MALICIOUS) erkannt. Sie wurden unter Quarantäne gestellt und desinfiziert (QUARANTINE, ALLOW_WITH_MODIFICATION). Anschließend wurde die desinfizierte E‑Mail weitergeleitet.

• Ein SSO-System hat einen Anmeldeversuch ermöglicht, der zu einem AUTH_VIOLATION geführt hat 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

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

Beispiel: Nach erfolgreichen Microsoft Windows 4624-Anmeldungen suchen

In der folgenden Suche werden die erfolgreichen Microsoft Windows 4624-Anmeldeereignisse zusammen mit dem Zeitpunkt der Erstellung der Ereignisse aufgeführt. Dabei werden nur zwei UDM-Felder verwendet:

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

Beispiel: Nach allen erfolgreichen Anmeldungen suchen

In 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 gezeigt, 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 Abschnitt „Ziel“ durchführen. Der Abschnitt „target“ enthält Unterabschnitte und Felder, die das Ziel beschreiben. In diesem Fall ist das Ziel beispielsweise ein Nutzer mit einer Reihe von zugehörigen Attributen. Das Ziel könnte aber auch eine Datei, eine Registry-Einstellung oder ein Asset sein. In diesem Beispiel wird im 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. Außerdem enthält sie ein UDM-Feld aus dem Netzwerkabschnitt, 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

Wenn Sie die auf Ihren Servern erstellten Prozesse untersuchen möchten, suchen Sie nach Instanzen des Befehls net.exe und nach dieser bestimmten Datei im erwarteten Pfad. Das Feld, nach dem Sie suchen, ist target.process.file.full_path. Für diese Suche fügen Sie den spezifischen Befehl ein, der im Feld target.process.command_line ausgegeben wurde. 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-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: Identifiziert den Nutzer, der den Befehl ausgibt.
• principal.process.file.md5: Identifizieren Sie den MD5-Hash.
• principal.process.command_line: Befehlszeile.

Beispiel: Nach erfolgreichen Nutzeranmeldungen suchen, die mit einer bestimmten Abteilung verknüpft 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 verbunden, aber dennoch in den LDAP-Daten enthalten, die zu Ihren Nutzern aufgenommen 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-Eintrag wird angegeben, ob es sich um ein Ereignis oder eine Entität handelt. Die Daten werden in verschiedenen Feldern gespeichert, je nachdem, ob der Eintrag 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 Umgebung aufgetreten ist. Das ursprüngliche Ereignisprotokoll beschreibt die Aktion so, 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 wird aus einer Source of Truth-Datenquelle abgerufen.

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

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

Abbildung: Ereignisdatenmodell

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

Abbildung: Entitätsdatenmodell

Struktur eines UDM-Ereignisses

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

• Metadaten
• Prinzipal
• Ziel
• src
• Beobachter
• intermediary
• über
• Netzwerk
• security_result

• Erweiterungen

  

  Abbildung: Ereignisdatenmodell

Im Abschnitt metadata wird der Zeitstempel gespeichert, die 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. Meistens wird nur ein Teil dieser Abschnitte verwendet. Die Felder, in denen Daten gespeichert werden, werden durch den Ereignistyp und die Rolle bestimmt, die jedes Objekt im Ereignis spielt.

Im Abschnitt 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 nicht in den anderen Abschnitten erfasst werden. Der Abschnitt extensions ist ein flexibel formulierter Satz von Schlüssel/Wert-Paaren.

In jedem UDM-Ereignis werden Werte aus einem ursprünglichen Roheintragsereignis gespeichert. Je nach Ereignistyp sind bestimmte Attribute erforderlich, während andere optional sind. Die erforderlichen und optionalen Attribute werden durch den Wert metadata.event_type bestimmt. Google SecOps liest metadata.event_type und führt nach dem Empfang der Logs eine Feldbestätigung für diesen Ereignistyp durch.

Wenn in einem Abschnitt des UDM-Eintrags keine Daten gespeichert sind, z. B. im Abschnitt „Erweiterungen“, wird dieser Abschnitt nicht im UDM-Eintrag 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. Dies ist der GMT-Zeitstempel, der angibt, wann das Ereignis aufgetreten ist. Der Wert muss mit einem der folgenden Standards codiert werden: RFC 3339 oder Proto3-Zeitstempel.

In den folgenden Beispielen wird gezeigt, wie Sie den Zeitstempel im RFC 3339-Format yyyy-mm-ddThh:mm:ss+hh:mm (Jahr, Monat, Tag, Stunde, Minute, Sekunde und Abweichung von der UTC-Zeit) angeben. 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 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 Wert metadata.event_type bestimmt, welche zusätzlichen erforderlichen und optionalen Felder im UDM-Eintrag enthalten sein müssen. Informationen dazu, welche Felder für die einzelnen Ereignistypen enthalten sein müssen, finden Sie im UDM-Nutzungsleitfaden.

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 Feld enthält Informationen zu Objekten, 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, der das Ziel der Aktivität ist. Es kann auch ein Sicherheitsgerät beschreiben, 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: Objekt, das die Aktivität initiiert, falls es sich nicht um das Hauptkonto handelt.
• target: Objekt, auf das sich die Aktion bezieht.

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

Die Hilfsfelder sind:

• intermediary: Jedes Objekt, das als Vermittler im Ereignis fungiert hat. Dazu können Objekte wie Proxyserver und Mailserver gehören.
• observer: Jedes Objekt, das nicht direkt mit dem betreffenden Traffic interagiert. Das kann ein Vulnerability Scanner oder ein Packet Sniffer sein.
• about: Alle anderen Objekte, die beim Ereignis eine Rolle gespielt haben und optional sind.

Die Hauptkontoattribute

Stellt die handelnde Entität oder das Gerät dar, von dem die Aktivität ausgeht. Das Hauptkonto muss mindestens ein Gerätedetail (Hostname, MAC-Adresse, IP-Adresse, produktspezifische Kennungen wie eine CrowdStrike-Geräte-GUID) oder Nutzerdetail (z. B. Nutzername) und optional Prozessdetails enthalten. Sie darf keines der folgenden Felder enthalten: E-Mail, Dateien, Registrierungsschlüssel oder Werte.

Wenn das Ereignis auf einer einzelnen Maschine stattfindet, wird diese Maschine 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, aber es wird nicht im Hauptattribut beschrieben. Sie wird entweder im Attribut „observer“ oder „intermediary“ 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 das Hauptkonto.

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

Die Zielattribute

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

Bei einer Prozess-Injection durch Prozess C in Zielprozess D ist Prozess C das Subjekt und Prozess D das Ziel.

Abbildung: Hauptkonto im Vergleich zum Ziel

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 den Feldern „target“ und „principal“ enthalten sein.

Sowohl das Hauptkonto als auch das Ziel können Akteure auf demselben Computer darstellen. Beispielsweise könnte Prozess A (Hauptkonto), der auf Maschine X ausgeführt wird, auf Prozess B (Ziel) einwirken, der ebenfalls auf Maschine X ausgeführt wird.

Das src-Attribut

Stellt ein Quellobjekt dar, auf das der Teilnehmer einwirkt, zusammen mit dem Geräte- oder Prozesskontext für das Quellobjekt (die Maschine, auf der sich das Quellobjekt befindet). Wenn beispielsweise Nutzer U die Datei A auf Maschine X in die Datei B auf Maschine Y kopiert, werden sowohl Datei A als auch Maschine X im src-Teil des UDM-Ereignisses angegeben.

Das Attribut „Intermediary“

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 Proxyservern und SMTP-Relay-Servern gehören.

Das Beobachterattribut

Stellt ein Beobachtergerät dar, das kein direkter Vermittler ist, aber das betreffende Ereignis beobachtet und meldet. Dazu gehören beispielsweise ein Paket-Sniffer oder ein netzwerkbasierter Vulnerability Scanner.

Das Attribut „about“

Hier werden Details zu einem Objekt gespeichert, auf das im Ereignis verwiesen wird und das nicht in den Feldern „principal“, „src“, „target“, „intermediary“ oder „observer“ beschrieben ist. 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 Minimierung dieser Risiken und Bedrohungen ergriffen wurden.

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

• Ein E‑Mail-Sicherheitsproxy hat einen Phishing-Versuch (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 dann die desinfizierte E-Mail weitergeleitet.
• Ein SSO-System lässt eine Anmeldung (security_result.category = AUTH_VIOLATION) zu, die blockiert wurde (security_result.action = BLOCK).
• Eine Malware-Sandbox hat fünf Minuten nach der Zustellung der Datei (security_result.action = ALLOW) an den Nutzer in seinem Posteingang Spyware (security_result.category = SOFTWARE_MALICIOUS) in einem Dateianhang erkannt.

Das Netzwerkattribut

Netzwerkattribute speichern Daten zu netzwerkbezogenen Ereignissen und Details zu Protokollen in Unternachrichten. Dazu gehören Aktivitäten wie gesendete und empfangene E‑Mails und HTTP-Anfragen.

Das Attribut „Erweiterungen“

Felder unter diesem Attribut speichern zusätzliche Metadaten zum Ereignis, das im ursprünglichen Rohprotokoll erfasst wurde. Sie kann Informationen zu Sicherheitslücken oder zusätzliche Informationen zur Authentifizierung enthalten.

Struktur einer UDM-Entität

In einem UDM-Entitätseintrag werden Informationen zu einer Entität innerhalb einer Organisation gespeichert. Wenn der metadata.entity_type USER ist, werden im Datensatz Informationen zum Nutzer unter dem Attribut entity.user gespeichert. Wenn der metadata.entity_type ASSET ist, speichert der Eintrag Informationen zu einem Asset, z. B. Workstation, Laptop, Smartphone und virtuelle Maschine.

Abbildung: Ereignisdatenmodell

Die Metadatenfelder

Dieser Abschnitt enthält Felder, die in einer UDM-Entität erforderlich sind, z. B.:

• collection_timestamp: Datum und Uhrzeit der Erfassung des Datensatzes.
• entity_type: der Entitätstyp, z. B. Asset, Nutzer und Ressource.

Das Entitätsattribut

Die Felder unter dem Entitätsattribut enthalten Informationen zur jeweiligen Entität, z. B. 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. 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 der metadata.entity_type USER ist, werden die Daten unter dem Attribut entity.user gespeichert.
• Wenn der metadata.entity_type ASSET ist, werden die Daten unter dem Attribut entity.asset gespeichert.

Das Beziehungsattribut

In den Feldern unter dem Beziehungsattribut werden Informationen zu anderen Entitäten gespeichert, mit denen die primäre Entität in Beziehung steht. Beispiel: Die primäre Entität ist ein Nutzer und dem Nutzer wurde ein Laptop zugewiesen. Der Laptop ist eine verwandte Entität. Informationen zum Laptop werden als entity-Eintrag mit metadata.entity_type = ASSET gespeichert. Informationen zum Nutzer werden als entity-Eintrag 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, genauer gesagt, dass der Nutzer der Eigentümer des Laptops ist. Im Feld relation.entity_type wird der Wert ASSET gespeichert, da der Laptop ein Gerät ist.

In den Feldern unter dem Attribut relations.entity werden Informationen zum Laptop gespeichert, z. B. der Hostname und die MAC-Adresse. Der Feldname ist wieder entity und der Feldtyp ist ein Noun. 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