Logdaten als UDM formatieren

Unterstützt in:

Gängige 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 stattgefunden hat, sein Typ, seine Herkunft usw.
  • Netzwerkmetadaten: Hochrangige Netzwerkmetadaten für netzwerkorientierte Ereignisse sowie Protokolldetails in Unternachrichten:
    • E-Mail-Metadaten: Informationen in den Feldern „An“, „Von“, „Cc“, „Bcc“ und anderen E-Mail-Feldern.
    • HTTP-Metadaten: „method“, „referral_url“, „useragent“ usw.
  • Sicherheitsergebnisse: Klassifizierungen oder Aktionen, die von einem Sicherheitsprodukt ausgeführt werden.
  • Zusätzliche Metadaten: Alle wichtigen anbieterspezifischen Ereignisdaten, die in den formellen Abschnitten des UDM-Modells nicht angemessen dargestellt werden können, können über ein JSON-Nutzlastfeld im freien Format hinzugefügt werden.

In den folgenden Abschnitten wird beschrieben, wie Ereignisse für die UDM codiert und formatiert werden.

UDM-Codierung

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

In diesem Dokument werden Felder mithilfe einer Punktnotation dargestellt. Beispiel:

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

wird so dokumentiert:

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

UDM-Ereignisse 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 im 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 teilnehmendes Gerät oder einen Nutzer beschreibt, der am Ereignis beteiligt ist.
  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 ergriffen wurden, um diese Risiken und Bedrohungen zu mindern.
  5. Geben Sie die restlichen erforderlichen und optionalen Ereignisinformationen in den UDM-Ereignisfeldern ein.

Ereignistyp angeben

Der wichtigste Wert, der für jedes im UDM-Format eingereichte Ereignis definiert ist, 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 und NETWORK_DNS. 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 ausfüllen, die mit dem ursprünglichen Ereignis verknüpft sind. Weitere Informationen dazu, welche Felder für jeden Ereignistyp erforderlich oder optional sind, finden Sie unter Erforderliche und optionale Felder für jeden UDM-Ereignistyp. Im folgenden Beispiel wird veranschaulicht, 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 gesendet wird, und zwar mit Metadata.event_timestamp. 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: yyyy-mm-ddThh: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 bedeutet.

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

Nomen (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 bzw. der das Ziel einer solchen Aktivität ist. Nomen können auch Anhänge oder URLs sein. Schließlich kann ein Nomen auch ein Sicherheitsgerät 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 Nomen angegeben sein:

principal: Stellt die handelnde Entität oder das Gerät dar, von dem die im Ereignis beschriebene Aktivität ausgeht. Der Hauptbenutzer muss mindestens ein Maschinendetail (Hostname, MACs, IPs, Port, produktspezifische Kennungen wie eine CrowdStrike-Maschinen-GUID) oder Nutzerdetail (z. B. Nutzername) und optional Prozessdetails enthalten. Die Datei darf KEINE der folgenden Felder enthalten: E-Mail-Adressen, Dateien, Registry-Schlüssel oder ‑Werte.

Wenn alle Ereignisse auf demselben Computer stattfinden, muss dieser Computer nur in principal beschrieben werden. Der Computer 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" }
}

In diesem Beispiel finden Sie Details zum Gerät und zum Nutzer, der der Hauptakteur bei dem Ereignis war. Sie enthält die IP-Adresse, die Portnummer und den Hostnamen des Geräts sowie eine anbieterspezifische Asset-ID (von Sophos), eine eindeutige ID, die vom Sicherheitsprodukt des Drittanbieters generiert wird.

target:Stellt ein Zielgerät dar, auf das im Ereignis verwiesen wird, oder ein Objekt auf dem Zielgerät. In einer Firewallverbindung von Gerät A zu Gerät B wird beispielsweise A als Hauptkonto und B als Ziel beschrieben. Bei einer Prozessinjektion durch Prozess C in den Zielprozess D wird Prozess C als Hauptprozess und Prozess D als Ziel beschrieben.

Haupt- und Zielkonto in Universal Analytics-Messwerten

Principal und Ziel in UDM

Das folgende Beispiel zeigt, wie die Felder für ein Ziel 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 aufgenommen werden.

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

  • src:Stellt ein Quellobjekt dar, auf das der Teilnehmer eine Aktion ausführt, zusammen mit dem Geräte- oder Prozesskontext für das Quellobjekt (der 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 Bereich src des UDM-Ereignisses angegeben.
  • intermediary:Enthält Details zu einem oder mehreren Zwischengeräten, auf denen die im Ereignis beschriebene Aktivität verarbeitet wird. Dazu gehören Gerätedetails zu einem Proxyserver, SMTP-Relay-Server usw.
  • observer:Stellt ein Beobachtergerät dar (z. B. einen Paketsniffer oder einen netzwerkbasierten Sicherheitsscanner), das kein direkter Vermittler ist, aber das betreffende Ereignis beobachtet und meldet.
  • about:Hier werden Details zu allen Objekten gespeichert, auf die im Ereignis verwiesen wird und die nicht anderweitig in participant, src, target, intermediary oder observer beschrieben sind. Sie können damit beispielsweise Folgendes erfassen:
    • E-Mail-Anhänge
    • Domains/URLs/IPs, die im 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. Das Google Security Operations-UDM hat obligatorische Anforderungen für das Ausfüllen von Nomen-Feldern. Diese Anforderungen werden unter Erforderliche und optionale Felder für jeden UDM-Ereignistyp beschrieben. Welche Entitätsfelder ausgefüllt werden müssen, hängt vom Ereignistyp ab.

Sicherheitsergebnis angeben

Sie können optional Sicherheitsergebnisse angeben, indem Sie die Felder „SecurityResult“ ausfüllen. Geben Sie dabei Details zu den vom Sicherheitssystem erkannten Sicherheitsrisiken und Bedrohungen sowie zu den Maßnahmen an, die zur Behebung dieser Risiken und Bedrohungen ergriffen wurden. Im Folgenden finden Sie Beispiele für einige der Arten von Sicherheitsereignissen, bei denen die Felder „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 und diese unter Quarantäne gestellt und desinfiziert (QUARANTINE, ALLOW_WITH_MODIFICATION) und dann die desinfizierte E-Mail weitergeleitet.
  • Ein SSO-System hat eine Anmeldung (AUTH_VIOLATION) ermöglicht, die blockiert wurde (BLOCK).
  • In einer Malware-Sandbox wurde fünf Minuten nach der Zustellung (ALLOW) der Datei in 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