Logdaten als UDM formatieren

Unterstützt in:

Google SecOps SIEM

Alle Unified Data Model-Ereignisse (UDM) verfügen über eine Reihe von allgemeinen Feldern und Meldungen, 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 andere E-Mail-Felder.
  • HTTP-Metadaten: „method“, „referral_url“, „useragent“ usw.
• Sicherheitsergebnisse: jede Klassifizierung oder Aktion, die von einem Sicherheitsprodukt vorgenommen wird.
• 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 das Unified Data Model (UDM) codiert und formatiert werden.

UDM-Codierung

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

• JSON (https://developers.google.com/protocol-buffers/docs/proto3#json)
• Proto3

In diesem Dokument werden Felder mithilfe einer Punktnotation dargestellt. Die folgende JSON-Syntax beispielsweise:

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

Sie 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: Vom ausgewählten Ereignistyp hängt ab, welche Felder in das Ereignis aufgenommen werden müssen.
2. Ereigniszeitstempel angeben: Geben Sie den Ereigniszeitstempel an.
3. Subjekte (Entitäten) angeben: Jedes Ereignis muss mindestens ein Subjekt 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 übrigen erforderlichen und optionalen Ereignisinformationen mithilfe der UDM-Ereignisfelder ein.

Angeben des Ereignistyps

Der wichtigste Wert für jedes im UDM-Format eingereichte Ereignis 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 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 nach einem der folgenden Standards codiert sein:

• Verwenden Sie für JSON RFC 3339.
• Proto3-Zeitstempel

Das folgende Beispiel zeigt, wie Sie den Zeitstempel im RFC 3339-Format angeben. Beispiel: jjjj-mm-ttThh:mm:ss+hh:mm – Jahr, Monat, Tag, Stunde, Minute, Sekunde und die UTC-Zeitverschiebung. Der Zeitversatz zu UTC beträgt minus 8 Stunden, was PST bedeutet.

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 Nomen definieren. Ein Nomen steht für einen Teilnehmer oder eine Entität in einem UDM-Ereignis. Ein Substantiv 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 Ziel dieser 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. einen E-Mail-Proxy oder einen Netzwerkrouter.

Für ein UDM-Ereignis muss eines oder mehrere 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. Das Hauptkonto muss mindestens ein Maschinendetail (Hostname, MACs, IP-Adressen, Port, produktspezifische Kennungen wie eine CrowdStrike-Maschinen-GUID) oder ein Nutzerdetail (z. B. Nutzername) und optional Prozessdetails enthalten. Die Datei darf KEINE der folgenden Felder enthalten: E-Mail-Adressen, Dateien, Registrierungsschlü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.

Hinweis: Ein Sicherheitsgerät kann ein Ereignis auslösen, wird jedoch nicht im Prinzipalfeld beschrieben. würde er entweder in den observer- oder intermediary-Feldern beschrieben. Wenn die Sicherheitssoftware (z. B. Carbon Black) auf demselben Gerät ausgeführt wird, von dem die Aktivität stammt (z. B. einem Windows-Endpunkt, auf dem Malware gefunden wurde), ist dieses Gerät auch 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" }
}

Im obigen Beispiel wird alles beschrieben, was über das Gerät und den Nutzer bekannt ist, der der im Ereignis beschriebene Hauptakteur war. Dieses Beispiel enthält die IP-Adresse und die Portnummer des Geräts sowie seinen Hostnamen. Außerdem enthält sie eine anbieterspezifische Asset-ID (von Sophos), eine eindeutige Kennung, die vom Sicherheitsprodukt des Drittanbieters generiert wird.

target:Stellt ein Zielgerät dar, auf das vom 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.

Principal und Target 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 Schulleiter als auch Ziel (sowie andere Substantive) können auf Schauspieler auf demselben Computer verweisen. Beispiel: Prozess A (Hauptkonto), der auf Maschine X ausgeführt wird, wirkt sich auf Prozess B (Ziel) auch auf Maschine X aus.

• src: Stellt ein Quellobjekt dar, auf das der Teilnehmer einwirkt, 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:Wird zum Speichern von Details zu allen Objekten verwendet, auf die das Ereignis verweist und die nicht anderweitig in participant, src, target, intermediary oder observer beschrieben sind. Sie können beispielsweise folgende Daten erfassen:
  • Dateianhänge per E-Mail senden
  • 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. Die Google Security Operations-UDM hat Pflichtfelder für das Ausfüllen von Noun-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 Sicherheitsrisiken und Bedrohungen an, die vom Sicherheitssystem gefunden wurden, sowie die Maßnahmen, die ergriffen wurden, um diese Risiken und Bedrohungen zu minimieren. Im Folgenden finden Sie Beispiele für einige der Sicherheitsereignisse, 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.