Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Protokolldaten als UDM formatieren

Alle Ereignisse des Unified Data Model (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, seine Herkunft usw.
  • Netzwerkmetadaten: Allgemeine Netzwerkmetadaten für netzwerkorientierte Ereignisse sowie Protokolldetails in Unternachrichten:
    • E-Mail-Metadaten: Informationen in den Feldern „An“, „Cc“, „Bcc“ und anderen E-Mail-Feldern.
    • HTTP-Metadaten: Methode, referral_url, User-Agent usw.
  • Sicherheitsergebnisse: Klassifizierungen oder Aktionen von Sicherheitsprodukten.
  • Zusätzliche Metadaten: Alle wichtigen anbieterspezifischen Ereignisdaten, die in den formalen Abschnitten des UDM-Modells nicht angemessen dargestellt werden können, können mit einem freien JSON-Nutzlastfeld 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 bei Chronicle eingereicht werden:

Im Rahmen dieses Dokuments werden Felder mit einem Punkt als Punkt dargestellt. Hier ein Beispiel für die JSON-Syntax:

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

Ist folgendermaßen 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 legen Sie fest, welche Felder im Ereignis enthalten sein müssen.
  2. Angeben des Ereigniszeitstempels-metadata-position="body" }: Geben Sie den Ereigniszeitstempel an.
  3. Nomen (Entitäten) angeben: Jedes Ereignis muss mindestens ein Substantiv enthalten, das ein Gerät oder einen Nutzer beschreibt, der am Ereignis beteiligt ist.
  4. Sicherheitsergebnis angeben (optional): Sie können Sicherheitsergebnisse angeben, indem Sie Details zu Sicherheitsrisiken und -bedrohungen angeben, die von einem Sicherheitssystem gefunden wurden, sowie die Maßnahmen ergreifen, um diese Risiken und Bedrohungen zu minimieren.
  5. Geben Sie die restlichen und optionalen Ereignisinformationen in die entsprechenden Felder ein.

Ereignistyp angeben

Der wichtigste Wert, der für jedes Ereignis im UDM-Format definiert wird, ist der Ereignistyp. Er wird mit einem der möglichen Werte festgelegt, 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 außerdem eine Reihe anderer Felder und Werte mit den Informationen aus dem ursprünglichen Ereignis füllen. Unter Erforderliche und optionale Felder für jeden UDM-Ereignistyp erfahren Sie, welche Felder für den jeweiligen Ereignistyp enthalten sein müssen. Das folgende Beispiel zeigt, wie Sie PROCESS_OPEN als Ereignistyp in Proto3-Text angeben würden:

metadata {
    event_type: PROCESS_OPEN
}

Ereigniszeitstempel 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

Das folgende Beispiel zeigt, wie Sie den Zeitstempel im Format RFC 3339 angeben. In diesem Beispiel: jjjj-mm-ttThh:mm:ss+hh:mm: Jahr, Monat, Tag, Stunde, Minute, Sekunde und die Abweichung zur UTC-Zeit. Die Abweichung von UTC beträgt minus 8 Stunden (PST).

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 Substantiv kann beispielsweise das Gerät/der Nutzer sein, der die in einem Ereignis beschriebene Aktivität ausführt, oder das Gerät/der Nutzer, der das Ziel dieser im Ereignis beschriebenen Aktivität ist. Substantive können auch aus Anhängen oder URLs bestehen. Mit einem Substantiv lässt sich außerdem ein Sicherheitsgerät beschreiben, das die im Ereignis beschriebene Aktivität beobachtet, z. B. einen E-Mail-Proxy oder einen Netzwerkrouter.

Für ein UDM-Ereignis müssen eines oder mehrere der folgenden Substantive angegeben werden:

Hauptkonto: Steht für die handelnde Entität oder das Gerät, von dem die im Ereignis beschriebene Aktivität stammt. Das Hauptkonto muss mindestens ein Computerdetail (Hostname, MACs, IP-Adressen, Port, produktspezifische Kennungen wie eine CrowdStrike-Maschinen-GUID) oder Nutzerdetails (z. B. den Nutzernamen) enthalten und optional Prozessdetails enthalten. Das Feld darf keines der folgenden Felder enthalten: E-Mail-Adresse, Datei, Registrierungsschlüssel oder Wert.

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

Im folgenden Beispiel sehen Sie, wie die main-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 bekannten Informationen über das Gerät und den Nutzer, der das Hauptereignis des Ereignisses war, beschrieben. In diesem Beispiel werden die IP-Adresse und die Portnummer des Geräts sowie sein Hostname aufgeführt. Außerdem ist eine anbieterspezifische Asset-ID (von Sophos) enthalten, die vom Drittanbieter-Sicherheitsprodukt generiert wurde.

target: Gibt ein Zielgerät an, auf das durch das Ereignis verwiesen wird, oder ein Objekt auf dem Zielgerät. Bei 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 Zielprozess D wird Prozess C als Hauptkonto und Prozess D als Ziel beschrieben.

Hauptkonto im Vergleich zum Ziel in UDM

Hauptgegner im Vergleich zu 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, etwa der Hostname, zusätzliche IP-Adressen, MAC-Adressen, proprietäre Asset-IDs, sollten sie ebenfalls in target enthalten sein.

Sowohl Hauptkonto als auch Ziel (und andere Substantive) können auf Darsteller auf demselben Computer verweisen. Beispiel: Prozess A (Hauptkonto), der auf Computer X ausgeführt wird, gilt auch für Prozess B (Ziel) auf Computer X.

  • src: Gibt ein Quellobjekt an, auf das der Teilnehmer reagiert, zusammen mit dem Geräte- oder Prozesskontext für das Quellobjekt (der Computer, auf dem sich das Quellobjekt befindet). Wenn beispielsweise Nutzer U die Datei A auf der Maschine X in die Datei B auf der Maschine Y kopiert, werden sowohl die Datei A als auch die Maschine X im src-Teil des UDM-Ereignisses angegeben.
  • Mittler:Stellt Details zu einer oder mehreren Zwischenaktivitäten dar, die im Ereignis beschrieben werden. Dazu gehören Gerätedetails zu einem Proxyserver, SMTP-Relay-Server usw.
  • observer: Gibt ein Beobachtergerät wie einen Paket-Sniffer oder einen netzwerkbasierten Sicherheitslücken-Scanner an, der keinen direkten Vermittler darstellt, aber das fragliche Ereignis beobachtet und meldet.
  • about:Wird zum Speichern von Details in allen Objekten, auf die im Ereignis verwiesen wird, angegeben, die nicht unter Teilnehmer, src, Ziel, Vermittler oder Observer beschrieben sind. Damit können Sie beispielsweise Folgendes erfassen:
    • E-Mail-Dateianhänge
    • In einen E-Mail-Text eingebettete Domains/URLs/IP-Adressen
    • DLLs, die während eines PROCESS_LAUNCH-Ereignisses geladen werden

Die Bereiche der Entitäten von UDM-Ereignissen umfassen Informationen zu den verschiedenen Teilnehmern (Geräte, Nutzer, Objekte wie URLs, Dateien usw.), die im Ereignis beschrieben werden. Für Chronicle UDM gelten bestimmte Anforderungen, wenn es um das Ausfüllen von Substantivfeldern geht. Diese Anforderungen werden unter Pflichtfelder und optionale Felder für jeden UDM-Ereignistyp beschrieben. Die Entitätsfelder, die ausgefüllt werden müssen, unterscheiden sich je nach Ereignistyp.

Sicherheitsergebnis angeben

Optional können Sie Sicherheitsergebnisse festlegen, indem Sie die Felder „SecurityResult“ ausfüllen, einschließlich Details zu Sicherheitsrisiken und -bedrohungen, die vom Sicherheitssystem gefunden wurden, sowie die Maßnahmen, um diese Risiken und Bedrohungen zu minimieren. Im Folgenden finden Sie einige Beispiele für einige Arten von Sicherheitshinweisen, die das Ausfüllen von SecurityResult-Feldern erfordern:

  • Ein E-Mail-Sicherheits-Proxy 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 diese Anhänge anschließend desinfiziert.
  • Ein SSO-System ermöglichte eine Anmeldung (AUTH_VIOLATION), die blockiert wurde (BLOCK).
  • Eine Malware-Sandbox hat fünf Minuten nach der Zustellung der Datei (ALLOW) an den Posteingang des Nutzers Spyware (SOFTWARE_MALICIOUS) in einem Dateianhang erkannt.