Logdaten als UDM formatieren

Unterstützt in:

Häufig verwendete UDM-Ereignisfelder

Alle Ereignisse des einheitlichen Datenmodells (UDM) haben eine Reihe gemeinsamer Felder und Nachrichten, die Partner unabhängig vom Ereignistyp ausfüllen können. Zu diesen Feldern gehören:

  • Entitäten: Geräte, Nutzer und Prozesse, die an einem Ereignis beteiligt sind.
  • Ereignismetadaten: Wann das Ereignis aufgetreten ist, der Typ des Ereignisses, woher es stammt usw.
  • Netzwerkmetadaten: Netzwerkmetadaten auf hoher Ebene für netzwerkorientierte Ereignisse sowie Protokolldetails in untergeordneten Nachrichten:
    • E-Mail-Metadaten: Informationen in den Feldern „An“, „Von“, „Cc“, „Bcc“ und anderen E-Mail-Feldern.
    • HTTP-Metadaten: Methode, referral_url, useragent usw.
  • Sicherheitsergebnisse: Alle Klassifizierungen oder Aktionen, die von einem Sicherheitsprodukt vorgenommen werden.
  • Zusätzliche Metadaten: Wichtige anbieterspezifische Ereignisdaten, die in den formalen Abschnitten des UDM-Modells nicht angemessen dargestellt werden können, lassen sich über ein Feld für eine frei formatierbare JSON-Nutzlast hinzufügen.

In den folgenden Abschnitten wird beschrieben, wie Sie Ereignisse für das UDM codieren und formatieren.

UDM-Codierung

UDM-Ereignisse müssen in einem der folgenden Formate an Google Security Operations gesendet werden:

In diesem Dokument werden Felder mit einer Punktnotation dargestellt. Beispiel für die JSON-Syntax:

{"menu":
  {
    "id": "file",
    "value": "File",
    "popup": {
      "menuitem": [
        {"value": "New", "onclick": "CreateNewDoc()"}
      ]
    }
  }
}

So wird sie dokumentiert:

menu.id = "file"
menu.value = "File"
menu.popup.menuitem.value = "New"
menu.popup.menuitem.onclick = "CreateNewDoc()"

UDM-Ereignis formatieren

Damit ein UDM-Ereignis an Google gesendet werden kann, müssen Sie es so formatieren, dass es den Anforderungen entspricht. Führen Sie dazu die folgenden Schritte aus:

  1. Ereignistyp angeben: Der ausgewählte Ereignistyp bestimmt, welche Felder Sie ebenfalls mit dem Ereignis einfügen müssen.
  2. Ereigniszeitstempel angeben: Geben Sie den Ereigniszeitstempel an.
  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. 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 Details dazu, welche Felder für jeden Ereignistyp 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

Im folgenden Beispiel wird veranschaulicht, 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 Substantiv stellt einen Teilnehmer oder eine Entität in einem UDM-Ereignis dar. 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.

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

Haupt- im Vergleich zu Ziel-UDM

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 Nomen) können auf Akteure auf demselben Computer verweisen. Prozess A (Prinzipal), 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) einwirkt. 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 sich das Ereignis bezieht und die nicht anderweitig in participant, src, target, intermediary oder observer beschrieben werden. Damit lassen sich beispielsweise folgende Daten 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 obligatorische Anforderungen für das Ausfüllen von Noun-Feldern. 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 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.

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