Protokolldaten als UDM formatieren

Alle UDM-Ereignisse (Unified Data Model) haben eine Reihe von allgemeinen Feldern und Nachrichten, die Partner unabhängig vom Ereignistyp ausfüllen können. Diese Felder enthalten Folgendes:

  • Entitäten: Geräte, Nutzer und Prozesse, die an einem Ereignis beteiligt sind
  • Ereignismetadaten: Zeitpunkt, zu dem das Ereignis aufgetreten ist, den Typ und das Ereignis, aus dem es stammt.
  • Netzwerkmetadaten: Allgemeine Netzwerkmetadaten für netzwerkorientierte Ereignisse sowie Protokolldetails in Unternachrichten:
    • E-Mail-Metadaten: Informationen in den Feldern toAn“, formFormular“, ccCc“, bBcc“ und andere E-Mail-Adressen
    • HTTP-Metadaten: Methode, referral_url, useragent usw.
  • Sicherheitsergebnisse: jede Klassifizierung oder Aktion eines Sicherheitsprodukts
  • Zusätzliche Metadaten: Alle wichtigen anbieterspezifischen Ereignisdaten, die in den formalen Bereichen des UDM-Modells nicht ausreichend dargestellt werden können, können mit einem 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 Chronicle gesendet werden:

In diesem Dokument werden Felder mithilfe einer Punktnotation dargestellt. Zum Beispiel die folgende JSON-Syntax:

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

Wird wie folgt dokumentiert:

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

UDM-Ereignis formatieren

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

  1. Ereignistyp angeben: Über den ausgewählten Ereignistyp wird bestimmt, welche Felder in dem Ereignis enthalten sein müssen.
  2. Ereigniszeitstempel angeben-metadata-position="body" }: Geben Sie den Ereigniszeitstempel an.
  3. Substantive (Entitäten) angeben: Jedes Ereignis muss mindestens ein Substantiv enthalten, das das Gerät oder den Nutzer eines Ereignisses beschreibt.
  4. Sicherheitsergebnis angeben: Optional können Sie Sicherheitsergebnisse angeben. Machen Sie dabei Angaben zu Sicherheitsrisiken und -bedrohungen, die von einem Sicherheitssystem gefunden wurden, sowie zu den Maßnahmen, mit denen diese Risiken und Bedrohungen minimiert werden.
  5. Füllen Sie die restlichen erforderlichen und optionalen Ereignisinformationen mithilfe der UDM-Ereignisfelder aus.

Ereignistyp angeben

Der wichtigste Wert, der für jedes im UDM-Format übermittelte Ereignis definiert wird, 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 andere Felder und Werte mit den Informationen füllen, die mit dem ursprünglichen Ereignis verknüpft sind. Weitere Informationen zu den Feldern für die einzelnen Ereignistypen finden Sie unter Erforderliche und optionale Felder für jeden UDM-Ereignistyp. Das folgende Beispiel zeigt, wie Sie PROCESS_OPEN als Ereignistyp mit der Proto3-Textschreibweise angeben:

metadata {
    event_type: PROCESS_OPEN
}

Ereigniszeitstempel angeben

Geben Sie den GMT-Zeitstempel für jedes Ereignis an, das im UDM-Format mit Metadata.event_timestamp gesendet wird. Der Stempel muss mit 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 würden. In diesem Beispiel sind das jjjj-mm-ttThh:mm:ss+hh:mm: Jahr, Monat, Tag, Stunde, Minute, Sekunde und die Abweichung zu UTC-Zeit. Die Abweichung von UTC beträgt minus 8 Stunden, was PST ergibt.

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

Substantive (Substanzen) angeben

Für jedes UDM-Ereignis müssen Sie mindestens ein Substantiv definieren. Ein Substantiv stellt einen Teilnehmer oder eine Entität in einem UDM-Ereignis dar. Es kann sich beispielsweise um ein Gerät oder einen Nutzer handeln, der die in einem Ereignis beschriebene Aktivität ausführt, oder um ein Gerät bzw. einen Nutzer, der das Ziel dieser Aktivität ist, die im Ereignis beschrieben wird. Substantive können auch Anhänge oder URLs sein. Darüber hinaus kann ein Substantiv auch verwendet werden, um ein Sicherheitsgerät zu beschreiben, das die in dem Ereignis beschriebene Aktivität überwacht, z. B. einen E-Mail-Proxy oder einen Netzwerkrouter.

In einem UDM-Ereignis muss mindestens eines der folgenden Substantive angegeben sein:

Principal: Stellt die handelnde Entität oder das Gerät dar, von dem die im Ereignis beschriebene Aktivität stammt. Das Hauptkonto muss mindestens ein Maschinendetail (Hostname, MACs, IPs, Port, produktspezifische Kennungen wie eine CrowdStrike-Maschinen-GUID) oder Nutzerdetails (z. B. Nutzernamen) und optional Prozessdetails enthalten. Folgende Felder dürfen NICHT verwendet werden: E-Mail, Dateien, Registrierungsschlüssel oder Werte.

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

.

Das folgende Beispiel zeigt, wie die Principal-Felder ausgefüllt werden können:

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

Im obigen Beispiel werden alle bisher bekannten Daten über das Gerät und den Nutzer beschrieben. In diesem Beispiel sind die IP-Adresse und Portnummer des Geräts sowie sein Hostname enthalten. Es enthält auch eine anbieterspezifische Asset-ID von Sophos, eine eindeutige ID, die vom Sicherheitsprodukt des Drittanbieters generiert wird.

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

Hauptkonto gegenüber Ziel in udm Versus-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
}

Auch wenn weitere Informationen verfügbar sind, etwa Hostname, zusätzliche IP-Adressen, MAC-Adressen, proprietäre Asset-IDs, sollten diese ebenfalls im Ziel enthalten sein.

Sowohl Principal als auch Target (sowie andere Substantive) können auf Schauspieler auf demselben Computer verweisen. Beispiel: Prozess A (Hauptkonto), der auf Maschine X ausgeführt wird, agiert auf Prozess B (Ziel) auch auf Maschine X.

  • src:Stellt ein Quellobjekt dar, auf das der Teilnehmer gemeinsam mit dem Gerät oder dem Prozesskontext für das Quellobjekt reagiert (der Computer, auf dem sich das Quellobjekt befindet). Wenn beispielsweise Nutzer U Datei A auf Maschine X in Datei B auf Computer Y kopiert, werden sowohl Datei A als auch Maschine X im Abschnitt src des UDM-Ereignisses angegeben.
  • intermediär:Stellt Details zu mindestens einem Gerät dar, das im Ereignis beschrieben wird. Dazu gehören Gerätedetails zu einem Proxyserver, SMTP-Relay-Server usw.
  • Beobachter:Stellt ein Beobachtungsgerät dar (z. B. ein Paket-Sniffer oder ein netzwerkbasierter Sicherheitslückenscanner), der kein direkter Vermittler ist, aber das entsprechende Ereignis beobachtet und über ihn berichtet.
  • zu: Werden zum Speichern von Details aller Objekte verwendet, auf die durch das Ereignis verwiesen wird, die nicht anderweitig beschrieben sind.Teilnehmer .src .Ziel .Mittler oderBeobachter aus. Sie können damit beispielsweise Folgendes erfassen:
    • Dateianhänge per E-Mail senden
    • Domains/URLs/IP-Adressen in einem E-Mail-Text
    • DLLs, die während eines PROCESS_LAUNCH-Ereignisses geladen werden

Die Entitätsabschnitte von UDM-Ereignissen enthalten Informationen zu den verschiedenen Teilnehmern des Geräts (Geräte, Nutzer, Objekte wie URLs, Dateien usw.), die im Ereignis beschrieben sind. Die Chronicle UDM hat obligatorische Anforderungen, wenn es darum geht, Nounfelder auszufüllen. Diese Anforderungen werden im Artikel Erforderliche und optionale Felder für jeden UDM-Ereignistyp beschrieben. Der Satz an Entitätsfeldern, die ausgefüllt werden müssen, ist je nach Ereignistyp unterschiedlich.

Sicherheitsergebnis angeben

Optional können Sie Sicherheitsergebnisse angeben, indem Sie die SecurityResult-Felder ausfüllen, einschließlich Details zu Sicherheitsrisiken und -bedrohungen, die vom Sicherheitssystem gefunden wurden, sowie den Maßnahmen, mit denen diese Risiken und Bedrohungen minimiert werden. Im Folgenden finden Sie Beispiele für einige Arten von Sicherheitsereignissen, die das Einfügen von SecurityResult-Feldern erfordern.

  • Ein E-Mail-Sicherheitsproxy hat einen Phishingversuch (MAIL_PHISHING) erkannt und die E-Mail blockiert (BLOCK).
  • Eine E-Mail-Sicherheitsproxy-Firewall hat zwei infizierte Anhänge (SOFTWARE_MALICIOUS) erkannt und unter Quarantäne gestellt und desinfiziert (QUARANTINE, ALLOW_WITH_MODIFICATION) diese Anhänge und leitete die desinfizierte E-Mail weiter.
  • Ein SSO-System ermöglicht eine Anmeldung (AUTH_VIOLATION), die blockiert wurde (BLOCK).
  • Eine Malware-Sandbox hat Spyware (SOFTWARE_MALICIOUS) in einem Dateianhang fünf Minuten nach der Übermittlung der Datei (ALLOW) an den Nutzer in ihrem Posteingang festgestellt.