UDM-Nutzungsleitfaden

Dieses Dokument enthält Folgendes:

• Detaillierte Beschreibungen der Schemafelder des einheitlichen Datenmodells (UDM)
• Pflicht- und optionale Felder für Entitätstypen
• Pflichtfelder und optionale Felder für jeden Ereignistyp

Weitere Informationen zu bestimmten UDM-Feldern (z. B. Enum-Nummern) finden Sie in der Feldliste für das Unified Data Model.

Formate für UDM-Feldnamen:

• Für die Auswertung der Regel-Engine beginnt das Präfix mit udm.
• Bei konfigurationsbasierten Normalisierern (CBN) beginnt das Präfix mit event.idm.read_only_udm.

Ereignis-Metadaten

Im Abschnitt mit den Ereignismetadaten für UDM-Ereignisse werden allgemeine Informationen zu jedem Ereignis gespeichert.

Metadata.event_type

• Zweck: Gibt den Typ des Ereignisses an. Wenn ein Ereignis mehrere mögliche Typen hat, muss dieser Wert den spezifischsten Typ angeben.
• Erforderlich: Ja.
• Codierung: Muss einer der vordefinierten UDM-event_type-Aufzählungstypen sein.
• Mögliche Werte: In den folgenden Abschnitten sind alle möglichen Werte für metadata.event_type im UDM aufgeführt. Die erforderlichen und optionalen Felder für die einzelnen Kategorien finden Sie unter Erforderliche und optionale Felder für die einzelnen Ereignistypen.

Analystenveranstaltungen

• ANALYST_ADD_COMMENT
• ANALYST_UPDATE_PRIORITY
• ANALYST_UPDATE_REASON
• ANALYST_UPDATE_REPUTATION
• ANALYST_UPDATE_RISK_SCORE
• ANALYST_UPDATE_ROOT_CAUSE
• ANALYST_UPDATE_SEVERITY_SCORE
• ANALYST_UPDATE_STATUS
• ANALYST_UPDATE_VERDICT

Geräteereignisse

Ereignisse im Zusammenhang mit Firmware-, Konfigurations- oder Programmaktualisierungen auf einem Gerät (z. B. einem industriellen Steuerungssystem oder einer OT-Anlage):

• DEVICE_CONFIG_UPDATE
• DEVICE_FIRMWARE_UPDATE
• DEVICE_PROGRAM_DOWNLOAD
• DEVICE_PROGRAM_UPLOAD

E‑Mail-Ereignisse

Ereignisse im Zusammenhang mit E-Mail-Transaktionen und E-Mail-Sicherheitsprüfungen:

• EMAIL_UNCATEGORIZED
• EMAIL_TRANSACTION
• EMAIL_URL_CLICK (eingestellt)

Ereignisse ohne Angabe

Platzhalterwert für einen nicht initialisierten Ereignistyp (Ereignisse, die auf EVENTTYPE_UNSPECIFIED gesetzt sind, bestehen die UDM-Validierung nicht):

• EVENTTYPE_UNSPECIFIED

Dateiereignisse, die auf einem Endpunkt ausgeführt wurden

• FILE_UNCATEGORIZED
• FILE_COPY (z. B. Kopieren einer Datei auf einen USB-Stick)
• FILE_CREATION
• FILE_DELETION
• FILE_MODIFICATION
• FILE_MOVE
• FILE_OPEN (Das Öffnen einer Datei kann beispielsweise auf eine Sicherheitsverletzung hinweisen.)
• FILE_READ (z. B. Lesen einer Passwortdatei)
• FILE_SYNC

Ereignisse, die in keine andere Kategorie fallen

Ereignisse, die in keine andere Kategorie fallen, einschließlich nicht kategorisierter Betriebssystemereignisse:

• GENERIC_EVENT

Ereignisse zu Gruppenaktivitäten

Ereignisse im Zusammenhang mit dem Erstellen, Ändern oder Löschen von Nutzer- oder Systemgruppen:

• GROUP_UNCATEGORIZED
• GROUP_CREATION
• GROUP_DELETION
• GROUP_MODIFICATION

Mutex-Ereignisse

Ereignisse im Zusammenhang mit dem Erstellen oder Verwalten eines Mutex-Objekts (Mutual Exclusion) auf einem Endpunkt:

• MUTEX_UNCATEGORIZED
• MUTEX_CREATION

Netzwerktelemetrie-Ereignisse

Netzwerktelemetrie-Ereignisse, einschließlich Rohprotokoll-Nutzlasten wie DHCP und DNS, sowie Protokollzusammenfassungen für Protokolle wie HTTP, SMTP und FTP und Fluss- und Verbindungsereignisse von NetFlow und Firewalls:

• NETWORK_UNCATEGORIZED
• NETWORK_CONNECTION (z. B. Netzwerkverbindungsdetails von einer Firewall)
• NETWORK_DHCP
• NETWORK_DNS
• NETWORK_FLOW (z. B. aggregierte Flussstatistiken von Netflow)
• NETWORK_FTP
• NETWORK_HTTP
• NETWORK_SMTP

Ereignisse verarbeiten

Alle Ereignisse, die sich auf einen Prozess beziehen, z. B. das Starten eines Prozesses, das Erstellen von schädlichen Inhalten durch einen Prozess, das Einfügen eines Prozesses in einen anderen Prozess, das Ändern eines Registrierungsschlüssels oder das Erstellen einer schädlichen Datei auf dem Laufwerk:

• PROCESS_UNCATEGORIZED
• PROCESS_INJECTION
• PROCESS_LAUNCH
• PROCESS_MODULE_LOAD
• PROCESS_OPEN
• PROCESS_PRIVILEGE_ESCALATION
• PROCESS_TERMINATION

Registry-Ereignisse

Verwenden Sie für Microsoft Windows-spezifische Registrierungsereignisse die folgenden REGISTRY-Ereignisse anstelle der SETTING-Ereignisse:

• REGISTRY_UNCATEGORIZED
• REGISTRY_CREATION
• REGISTRY_MODIFICATION
• REGISTRY_DELETION

Ressourcenereignisse

Ereignisse im Zusammenhang mit dem Erstellen, Lesen, Schreiben, Löschen oder Ändern von Berechtigungen für eine Ressource:

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Scanorientierte Ereignisse

Zu den scanorientierten Ereignissen gehören On-Demand-Scans und Verhaltenserkennungen, die von Endpunkt- oder Netzwerksicherheitsprodukten (z. B. EDR, Antivirenprogramme, Vulnerability Scanner oder DLP) durchgeführt werden:

• SCAN_UNCATEGORIZED
• SCAN_FILE
• SCAN_HOST
• SCAN_NETWORK
• SCAN_PROCESS
• SCAN_PROCESS_BEHAVIORS (eingestellt)
• SCAN_VULN_HOST
• SCAN_VULN_NETWORK

Ereignisse geplanter Aufgaben (Windows-Aufgabenplanung, Cron usw.)

• SCHEDULED_TASK_UNCATEGORIZED
• SCHEDULED_TASK_CREATION
• SCHEDULED_TASK_DELETION
• SCHEDULED_TASK_DISABLE
• SCHEDULED_TASK_ENABLE
• SCHEDULED_TASK_MODIFICATION

Dienstereignisse

Ereignisse im Zusammenhang mit dem Erstellen, Löschen, Ändern, Starten oder Beenden eines Betriebssystems oder Anwendungsdienstes:

• SERVICE_UNSPECIFIED
• SERVICE_CREATION
• SERVICE_DELETION
• SERVICE_MODIFICATION
• SERVICE_START
• SERVICE_STOP

Ereignisse festlegen

Informationen zum Festlegen von Anforderungen an Veranstaltungen finden Sie unter SETTING_UNCATEGORIZED, SETTING_CREATION, SETTING_MODIFICATION, SETTING_DELETION.

Einstellungsereignisse, einschließlich der Änderung einer Systemeinstellung auf einem Endpunkt:

• SETTING_UNCATEGORIZED
• SETTING_CREATION
• SETTING_DELETION
• SETTING_MODIFICATION

Statusmeldungen von Sicherheitsprodukten

Statusnachrichten von Sicherheitsprodukten, die angeben, dass Agents aktiv sind, und die Versions-, Fingerabdruck- oder andere Datentypen senden:

• STATUS_UNCATEGORIZED
• STATUS_HEARTBEAT (gibt an, dass das Produkt aktiv ist)
• STATUS_STARTUP
• STATUS_SHUTDOWN
• STATUS_UPDATE (Software- oder Fingerabdruck-Update)

System-Audit-Log-Ereignisse

• SYSTEM_AUDIT_LOG_UNCATEGORIZED
• SYSTEM_AUDIT_LOG_WIPE

Aktivitätsereignisse zur Nutzerauthentifizierung

• USER_UNCATEGORIZED
• USER_BADGE_IN (z. B. wenn sich ein Nutzer physisch mit einem Ausweis an einem Standort anmeldet)
• USER_CHANGE_PASSWORD
• USER_CHANGE_PERMISSIONS
• USER_COMMUNICATION
• USER_CREATION
• USER_DELETION
• USER_LOGIN
• USER_LOGOUT
• USER_RESOURCE_ACCESS
• USER_RESOURCE_CREATION
• USER_RESOURCE_DELETION
• USER_RESOURCE_UPDATE_CONTENT
• USER_RESOURCE_UPDATE_PERMISSIONS
• USER_STATS (eingestellt)

Metadata.collected_timestamp

• Zweck: Codiert den GMT-Zeitstempel, zu dem das Ereignis von der lokalen Erfassungsinfrastruktur des Anbieters erfasst wurde.
• Codierung: RFC 3339, je nach JSON- oder Proto3-Zeitstempelformat.
• Beispiel:
  • RFC 3339: '2019-09-10T20:32:31-08:00'
  • Proto3-Format: „2012-04-23T18:25:43.511Z“

Metadata.event_timestamp

• Zweck: Codiert den GMT-Zeitstempel, zu dem das Ereignis generiert wurde.
• Erforderlich: Ja
• Codierung: RFC 3339, je nach JSON- oder Proto3-Zeitstempelformat.
• Beispiel:
  • RFC 3339: 2019-09-10T20:32:31-08:00
  • Proto3-Format: 2012-04-23T18:25:43.511Z

Metadata.description

• Zweck: Eine menschenlesbare Beschreibung des Ereignisses.
• Codierung: Alphanumerischer String, Satzzeichen zulässig, maximal 1.024 Byte
• Beispiel: Der Zugriff der Datei „c:\bar\foo.exe“ auf das vertrauliche Dokument „c:\documents\earnings.docx“ wurde blockiert.

Metadata.product_event_type

• Zweck: Kurzer, beschreibender, menschenlesbarer und produktspezifischer Ereignisname oder ‑typ.
• Codierung: Alphanumerischer String, Satzzeichen zulässig, maximal 64 Byte.
• Beispiele:
  • Ereignis: Registry-Erstellung
  • ProcessRollUp
  • Rechteausweitung erkannt
  • Malware blockiert

Metadata.product_log_id

• Zweck: Codiert eine anbieterspezifische Ereignis-ID, um das Ereignis eindeutig zu identifizieren (eine GUID). Nutzer können diese Kennung verwenden, um in der proprietären Konsole des Anbieters nach dem betreffenden Ereignis zu suchen.
• Codierung: Alphanumerischer String, bei dem zwischen Groß- und Kleinschreibung unterschieden wird, Satzzeichen zulässig, maximal 256 Byte.
• Beispiel: ABcd1234-98766

Metadata.product_name

• Zweck: Gibt den Namen des Produkts an.
• Codierung: Alphanumerischer String, bei dem zwischen Groß- und Kleinschreibung unterschieden wird, Satzzeichen zulässig, maximal 256 Byte.
• Beispiele:
  • Falcon
  • Symantec Endpoint Protection

Metadata.product_version

• Zweck: Gibt die Version des Produkts an.
• Codierung: Alphanumerischer String, Punkte und Bindestriche zulässig, maximal 32 Byte
• Beispiele:
  • 1.2.3b
  • 10.3:rev1

Metadata.url_back_to_product

• Zweck: URL, die auf eine relevante Website verweist, auf der Sie weitere Informationen zu diesem bestimmten Ereignis (oder der allgemeinen Ereigniskategorie) finden.
• Codierung: Gültige RFC-3986-URL mit optionalen Parametern wie Portinformationen usw. Vor der URL muss ein Protokollpräfix stehen (z. B. https:// oder http://).
• Beispiel: https://newco.altostrat.com:8080/event_info?event_id=12345

Metadata.vendor_name

• Zweck: Gibt den Namen des Produktanbieters an.
• Codierung: Alphanumerischer String, bei dem die Groß-/Kleinschreibung beachtet wird, Satzzeichen sind zulässig, maximal 256 Byte
• Beispiele:
  • CrowdStrike
  • Symantec

Population von Noun-Metadaten

In diesem Abschnitt ist das Wort Noun ein übergeordneter Begriff, der für die folgenden Entitäten verwendet wird: principal, src, target, intermediary, observer und about. Diese Entitäten haben gemeinsame Attribute, stellen aber unterschiedliche Objekte in einem Ereignis dar. Weitere Informationen zu Entitäten und ihrer Bedeutung in einem Ereignis finden Sie unter UDM-Ereignis formatieren.

Noun.asset_id

• Zweck: Anbieterspezifische eindeutige Geräte-ID (z. B. eine GUID, die bei der Installation von Endpunktsicherheitssoftware auf einem neuen Gerät generiert wird und zur Nachverfolgung dieses eindeutigen Geräts im Laufe der Zeit verwendet wird).
• Codierung: (VendorName oder VendorAbbreviation):ID, wobei VendorName oder VendorAbbreviation ein Anbietername ohne Berücksichtigung der Groß-/Kleinschreibung ist, z. B. Carbon Black oder CB, und ID eine anbieterspezifische Kundenkennung ist, die innerhalb der Kundenumgebung global eindeutig ist (z. B. eine GUID oder ein eindeutiger Wert, der ein eindeutiges Gerät identifiziert). VendorName ist alphanumerisch und darf maximal 32 Zeichen lang sein. Die ID darf maximal 128 Zeichen lang sein und alphanumerische Zeichen, Bindestriche und Punkte enthalten.
• Beispiel: CrowdStrike:0bce4259-4ada-48f3-a904-9a526b01311f
• Beispiel: CS:0bce4259-4ada-48f3-a904-9a526b01311f

Noun.email

• Zweck: E‑Mail-Adresse
• Codierung: Standardformat für E-Mail-Adressen.
• Beispiel: [e-mail]

Noun.file

• Zweck: Detaillierte Dateimetadaten.
• Typ: Objekt
• Weitere Informationen finden Sie unter Ausfüllen von Dateimetadaten.

Noun.hostname

• Zweck: Feld für den Hostnamen oder Domainnamen des Clients. Nicht angeben, wenn eine URL vorhanden ist.
• Codierung: Gültiger RFC 1123-Hostname.
• Validierungseinschränkung: Hostnamen-Strings dürfen nicht länger als 255 Byte sein, um den Limits für die Suchindexierung zu entsprechen.
• Beispiele:
  • userwin10
  • www.altostrat.com

Noun.platform

• Zweck: Betriebssystem der Plattform.
• Codierung: Enum
• Mögliche Werte:
  • LINUX
  • MAC
  • WINDOWS
  • UNKNOWN_PLATFORM

Noun.platform_patch_level

• Zweck: Patch-Level des Betriebssystems der Plattform.
• Codierung: Alphanumerischer String mit Satzzeichen, maximal 64 Zeichen.
• Beispiel: Build 17134.48

Noun.platform_version

• Zweck: Betriebssystemversion der Plattform.
• Codierung: Alphanumerischer String mit Satzzeichen, maximal 64 Zeichen.
• Beispiel: Microsoft Windows 10 Version 1803

Noun.process

• Zweck: Detaillierte Prozessmetadaten.
• Typ: Objekt
• Weitere Informationen finden Sie unter Prozessmetadaten füllen.

Noun.ip

• Zweck:
  • Einzelne IP-Adresse, die einer Netzwerkverbindung zugeordnet ist.
  • Eine oder mehrere IP-Adressen, die zum Zeitpunkt des Ereignisses mit einem Teilnehmergerät verknüpft waren (wenn ein EDR-Produkt beispielsweise alle mit einem Gerät verknüpften IP-Adressen kennt, kann es alle diese Adressen in IP-Feldern codieren).
• Codierung: Gültiger IPv4- (4 Byte) oder IPv6-Adressstring (16 Byte) (RFC 5942), codiert in ASCII.
• Wiederholbarkeit:
  • Wenn ein Ereignis eine bestimmte Netzwerkverbindung beschreibt (z. B. srcip:srcport > dstip:dstport), müssen Sie nur eine einzige IP-Adresse angeben.
  • Wenn ein Ereignis allgemeine Aktivitäten auf einem Teilnehmergerät beschreibt, aber keine bestimmte Netzwerkverbindung, können Sie alle zugehörigen IP-Adressen für das Gerät zum Zeitpunkt des Ereignisses angeben.
• Beispiele:
  • 192.168.1.2
  • 2001:db8:1:3::1

Noun.port

• Zweck: Quell- oder Zielnetzwerk-Portnummer, wenn eine bestimmte Netzwerkverbindung in einem Ereignis beschrieben wird.
• Codierung: Gültige TCP/IP-Portnummer von 1 bis 65.535.

• Beispiele:

  • 80
  • 443
  Hinweis: Wenn eine Portnummer angegeben ist, muss im selben Noun genau eine IP-Adresse angegeben sein.

Noun.mac

• Zweck: Eine oder mehrere MAC-Adressen, die mit einem Gerät verknüpft sind.
• Codierung: Gültige 6-Byte-MAC-Adresse im 48-Bit-EUI-48-Format (Extended Unique Identifier), codiert in ASCII.
• Wiederholbarkeit: Sie können alle zugehörigen MAC-Adressen für das Gerät zum Zeitpunkt des Ereignisses angeben.
• Beispiele:
  • 00:24:98:7B:19:02
  • 00:00:5e:00:53:2a

Noun.administrative_domain

• Zweck: Domain, zu der das Gerät gehört (z. B. die Windows-Domain).
• Codierung: Gültiger Domainname (maximal 128 Zeichen).
• Beispiel: corp.altostrat.com

Noun.registry

• Zweck: Detaillierte Registry-Metadaten.
• Typ: Objekt
• Siehe Registry-Metadaten füllen.

Noun.url

• Zweck: Standard-URL
• Codierung: URL (RFC 3986). Muss ein gültiges Protokollpräfix haben (z. B. https:// oder ftp://). Muss die vollständige Domain und den vollständigen Pfad enthalten. Kann die Parameter der URL enthalten.
• Beispiel: https://foo.altostrat.com/bletch?a=b;c=d

Noun.user

• Zweck: Detaillierte Nutzermetadaten.
• Typ: Objekt
• Weitere Informationen finden Sie unter Nutzer-Metadaten füllen.

Ausfüllen von Authentifizierungsmetadaten

Authentication.AuthType

• Zweck: Typ des Systems, mit dem ein Authentifizierungsereignis verknüpft ist (Google Security Operations UDM).
• Codierung: Enumerated-Typ.
• Mögliche Werte:
  • AUTHTYPE_UNSPECIFIED
  • MACHINE: Maschinenauthentifizierung
  • PHYSICAL: Physische Authentifizierung (z. B. ein Ausweisleser)
  • SSO, die
  • TACACS: TACACS-Protokollfamilie zur Authentifizierung von Netzwerksystemen (z. B. TACACS oder TACACS+)
  • VPN

Authentication.Authentication_Status

• Zweck: Beschreibt den Authentifizierungsstatus eines Nutzers oder bestimmter Anmeldedaten.
• Codierung: Enumerated-Typ.
• Mögliche Werte:
  • UNKNOWN_AUTHENTICATION_STATUS: Standardauthentifizierungsstatus
  • ACTIVE: Die Authentifizierungsmethode ist aktiv.
  • SUSPENDED: Die Authentifizierungsmethode ist gesperrt oder deaktiviert.
  • DELETED: Die Authentifizierungsmethode wurde gelöscht.
  • NO_ACTIVE_CREDENTIALS: Die Authentifizierungsmethode hat keine aktiven Anmeldedaten.

Authentication.auth_details

• Zweck: Vom Anbieter definierte Authentifizierungsdetails.
• Encoding: String.

Authentication.Mechanism

• Zweck: Mechanismen, die für die Authentifizierung verwendet werden.
• Codierung: Enumerated-Typ.
• Mögliche Werte:
  • MECHANISM_UNSPECIFIED: Standardauthentifizierungsmechanismus.
  • BADGE_READER
  • BATCH: Batch-Authentifizierung.
  • CACHED_INTERACTIVE: Interaktive Authentifizierung mit im Cache gespeicherten Anmeldedaten.
  • HARDWARE_KEY
  • LOKAL
  • MECHANISM_OTHER: Ein anderer Mechanismus, der hier nicht definiert ist.
  • NETWORK: Netzwerkauthentifizierung.
  • NETWORK_CLEAR_TEXT: Netzwerk-Klartextauthentifizierung.
  • NEW_CREDENTIALS: Authentifizierung mit neuen Anmeldedaten.
  • OTP
  • REMOTE: Remote-Authentifizierung
  • REMOTE_INTERACTIVE: RDP, Terminaldienste, Virtual Network Computing (VNC) usw.
  • SERVICE: Dienstauthentifizierung.
  • UNLOCK – Direkte Authentifizierung durch menschliche Interaktion zum Entsperren.
  • USERNAME_PASSWORD

Ausfüllen von DHCP-Metadaten

In den Metadatenfeldern für das Dynamic Host Control Protocol (DHCP) werden Protokollinformationen zum DHCP-Netzwerkverwaltungsprotokoll erfasst.

Dhcp.client_hostname

• Zweck: Hostname für den Client. Weitere Informationen finden Sie in RFC 2132, DHCP Options and BOOTP Vendor Extensions.
• Encoding: String.
• Validierungseinschränkung: Hostnamen-Optionsstrings dürfen nicht länger als 255 Byte sein, um den Suchindexierungslimits zu entsprechen.

Dhcp.client_identifier

• Zweck: Client-ID. Weitere Informationen finden Sie in RFC 2132, DHCP Options and BOOTP Vendor Extensions.
• Codierung: Byte.

Dhcp.file

• Zweck: Dateiname für das Boot-Image.
• Encoding: String.

Dhcp.flags

• Zweck: Wert für das Feld „DHCP-Flags“.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.hlen

• Zweck: Länge der Hardwareadresse.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.hops

• Zweck: DHCP-Hop-Anzahl.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.htype

• Zweck: Typ der Hardwareadresse.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.lease_time_seconds

• Zweck: Vom Client angeforderte Lease-Zeit für eine IP-Adresse in Sekunden. Weitere Informationen finden Sie in RFC 2132, DHCP Options and BOOTP Vendor Extensions.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.opcode

• Zweck: BOOTP-Opcode (siehe Abschnitt 3 von RFC 951).
• Codierung: Enumerated-Typ.
• Mögliche Werte:
  • UNKNOWN_OPCODE
  • BOOTREQUEST
  • BOOTREPLY

Dhcp.requested_address

• Zweck: Client-ID. Weitere Informationen finden Sie in RFC 2132, DHCP Options and BOOTP Vendor Extensions.
• Codierung: Gültige IPv4- oder IPv6-Adresse (RFC 5942), codiert in ASCII.

Dhcp.seconds

• Zweck: Sekunden, die vergangen sind, seit der Client mit dem Abrufen oder Erneuern der Adresse begonnen hat.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.sname

• Zweck: Name des Servers, von dem der Client booten soll.
• Encoding: String.

Dhcp.transaction_id

• Zweck: Client-Transaktions-ID.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.type

• Zweck: DHCP-Nachrichtentyp. Weitere Informationen finden Sie in RFC 1533.
• Codierung: Enumerated-Typ.
• Mögliche Werte:
  • UNKNOWN_MESSAGE_TYPE
  • ENTDECKEN
  • Angebot
  • ANFRAGE
  • Ablehnen
  • ACK
  • NAK
  • RELEASE
  • INFORM
  • WIN_DELECTED
  • WIN_EXPIRED

Dhcp.chaddr

• Zweck: Hardwareadresse des Clients.
• Codierung: MAC-Adresse

Dhcp.ciaddr

• Zweck: IP-Adresse des Clients.
• Codierung: Gültige IPv4- oder IPv6-Adresse (RFC 5942), codiert in ASCII.

Dhcp.giaddr

• Zweck: IP-Adresse für den Relay-Agenten.
• Codierung: Gültige IPv4- oder IPv6-Adresse (RFC 5942), codiert in ASCII.

Dhcp.siaddr

• Zweck: IP-Adresse für den nächsten Bootstrap-Server.
• Codierung: Gültige IPv4- oder IPv6-Adresse (RFC 5942), codiert in ASCII.

Dhcp.yiaddr

• Zweck: Ihre IP-Adresse.
• Codierung: Gültige IPv4- oder IPv6-Adresse (RFC 5942), codiert in ASCII.

Hinweis: Wenn Dhcp.type den Wert ACK, OFFER oder DECLINE angibt, müssen Sie sowohl eine gültige 4-Byte-IPv4-Adresse in Dhcp.yiaddr oder Dhcp.requested_address ALS AUCH eine entsprechende MAC-Adresse angeben. Für die Nachrichten-Opcodes REQUEST, RELEASE, WIN_DELETED oder WIN_EXPIRED müssen Sie eine gültige 4-Byte-IPv4-Adresse in Dhcp.ciaddr oder Dhcp.yiaddr angeben.

Ausfüllen von DHCP-Optionsmetadaten

In den Metadatenfeldern für DHCP-Optionen werden die Protokollinformationen für DHCP-Optionen erfasst.

Option.code

• Zweck: Speichert den DHCP-Optionscode. Weitere Informationen finden Sie unter RFC 1533, DHCP Options and BOOTP Vendor Extensions.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Option.data

• Zweck: Speichert die DHCP-Optionsdaten. Weitere Informationen finden Sie unter RFC 1533, DHCP Options and BOOTP Vendor Extensions.
• Codierung: Byte.

Ausfüllen von DNS-Metadaten

Die DNS-Metadatenfelder enthalten Informationen zu DNS-Anfrage- und -Antwortpaketen. Sie entsprechen eins zu eins den Daten in DNS-Anfrage- und Antwortdatagrammen.

Dns.authoritative

• Zweck: Für autoritative DNS-Server auf „true“ setzen.
• Encoding: Boolesch.

Dns.id

• Zweck: Speichert die DNS-Abfrage-ID.
• Codierung: 32-Bit-Ganzzahl.

Dns.response

• Zweck: Auf „true“ setzen, wenn das Ereignis eine DNS-Antwort ist.
• Encoding: Boolesch.

Dns.opcode

• Zweck: Speichert den DNS-OpCode, der verwendet wird, um den Typ der DNS-Abfrage anzugeben (Standard, invers, Serverstatus usw.).
• Codierung: 32-Bit-Ganzzahl.

Dns.recursion_available

• Zweck: Wird auf „true“ gesetzt, wenn ein rekursiver DNS-Lookup verfügbar ist.
• Encoding: Boolesch.

Dns.recursion_desired

• Zweck: Auf „true“ setzen, wenn ein rekursiver DNS-Lookup angefordert wird.
• Encoding: Boolesch.

Dns.response_code

• Zweck: Speichert den DNS-Antwortcode, wie in RFC 1035, Domain Names – Implementation and Specification, definiert.
• Codierung: 32-Bit-Ganzzahl.

Dns.truncated

• Zweck: Wird auf „true“ gesetzt, wenn es sich um eine abgeschnittene DNS-Antwort handelt.
• Encoding: Boolesch.

Dns.questions

• Zweck: Speichert die Fragen zu Domainprotokoll-Mitteilungen. Siehe Population of DNS Question metadata.

Dns.answers

• Zweck: Speichert die Antwort auf die Domainnamenabfrage. Weitere Informationen finden Sie unter Ausfüllen von Metadaten für DNS-Ressourceneinträge.

Dns.authority

• Zweck: Speichert die Domain-Nameserver, die die Antwort auf die Domainnamenabfrage bestätigt haben. Weitere Informationen finden Sie unter Ausfüllen von Metadaten für DNS-Ressourceneinträge.

Dns.additional

• Zweck: Speichert die zusätzlichen Domain-Nameserver, die zur Bestätigung der Antwort auf die Domain verwendet werden können. Weitere Informationen finden Sie unter Ausfüllen von Metadaten für DNS-Ressourceneinträge.

Population von DNS-Fragenmetadaten

Die Metadatenfelder für DNS-Fragen erfassen die Informationen, die im Frageabschnitt einer Domainprotokollnachricht enthalten sind.

Question.name

• Zweck: Speichert den Domainnamen.
• Encoding: String.
• Validierungseinschränkung: Domain-Abfragestrings dürfen nicht leer sein und müssen gemäß den RFC 1035-Bestimmungen und den Limits für die Suchindexierung maximal 255 Oktette (Byte) lang sein.

Question.class

• Zweck: Speichert den Code, der die Klasse der Abfrage angibt.
• Codierung: 32-Bit-Ganzzahl.

Question.type

• Zweck: Speichert den Code, der den Typ der Abfrage angibt.
• Codierung: 32-Bit-Ganzzahl.

Auffüllen von DNS-Ressourceneintragsmetadaten

In den Metadatenfeldern für DNS-Ressourceneinträge werden die Informationen erfasst, die im Ressourceneintrag einer Domainprotokollnachricht enthalten sind.

ResourceRecord.binary_data

• Zweck: Speichert die Rohbytes aller Nicht-UTF8-Strings, die möglicherweise in einer DNS-Antwort enthalten sind. Dieses Feld darf nur verwendet werden, wenn die vom DNS-Server zurückgegebenen Antwortdaten keine UTF8-Daten enthalten. Andernfalls fügen Sie die DNS-Antwort in das Feld „data“ ein. Diese Art von Informationen muss hier und nicht in ResourceRecord.data gespeichert werden.

• Codierung: Byte.

  Hinweis: Dieses Feld ist im Gegensatz zu den anderen DNS-Ressourceneintragsfeldern nicht in RFC 1035 angegeben, wurde aber von Google SecOps für das UDM definiert.

ResourceRecord.class

• Zweck: Speichert den Code, der die Klasse des Ressourceneintrags angibt.
• Codierung: 32-Bit-Ganzzahl.

ResourceRecord.data

• Zweck: Speichert die Nutzlast oder Antwort auf die DNS-Frage für alle im UTF-8-Format codierten Antworten. Das Datenfeld könnte beispielsweise die IP-Adresse des Computers zurückgeben, auf den sich der Domainname bezieht. Wenn der Ressourceneintrag für einen anderen Typ oder eine andere Klasse bestimmt ist, kann er einen anderen Domainnamen enthalten (wenn ein Domainname zu einem anderen Domainnamen weitergeleitet wird). Die Daten müssen genau so gespeichert werden, wie sie in der DNS-Antwort enthalten sind.
• Encoding: String.

ResourceRecord.name

• Zweck: Speichert den Namen des Inhabers des Ressourceneintrags.
• Encoding: String.

ResourceRecord.ttl

• Zweck: Speichert das Zeitintervall, für das der Ressourceneintrag im Cache gespeichert werden kann, bevor die Informationsquelle noch einmal abgefragt werden muss.
• Codierung: 32-Bit-Ganzzahl.

ResourceRecord.type

• Zweck: Speichert den Code, der den Typ des Ressourceneintrags angibt.
• Codierung: 32-Bit-Ganzzahl.

Ausfüllen von E-Mail-Metadaten

Die meisten Felder für E-Mail-Metadaten erfassen die E-Mail-Adressen im Nachrichtenheader und sollten dem Standardformat für E-Mail-Adressen (lokales-postfach@domain) entsprechen, wie in RFC 5322 definiert. Beispiel: [e-mail].

Email.from

• Zweck: Speichert die Von-E-Mail-Adresse.
• Encoding: String.

Email.reply_to

• Zweck: Speichert die E-Mail-Adresse reply_to.
• Encoding: String.

Email.to

• Zweck: Speichert die E-Mail-Adressen im Feld An.
• Encoding: String.

Email.cc

• Zweck: Speichert die cc-E-Mail-Adressen.
• Encoding: String.

Email.bcc

• Zweck: Speichert die Bcc-E‑Mail-Adressen.
• Encoding: String.

Email.mail_id

• Zweck: Speichert die E‑Mail- oder Nachrichten-ID.
• Encoding: String.
• Beispiel: [e-mail]

Email.subject

• Zweck: Speichert die Betreffzeile der E‑Mail.
• Encoding: String.
• Beispiel: „Bitte lies diese Nachricht.“

Ausfüllen von Metadaten für Erweiterungen

Ereignistypen mit integrierten Metadaten, die noch nicht vom Google SecOps-UDM kategorisiert wurden.

Extensions.auth

• Zweck: Erweiterung der Authentifizierungsmetadaten.
• Encoding: String.
• Beispiele:
  • Sandbox-Metadaten (alle Verhaltensweisen einer Datei, z. B. FireEye)
  • Daten zur Netzwerkzugriffssteuerung (Network Access Control, NAC)
  • LDAP-Details zu einem Nutzer (z. B. Rolle, Organisation usw.)

Extensions.auth.auth_details

• Zweck: Geben Sie die anbieterspezifischen Details für den Authentifizierungstyp oder -mechanismus an. Authentifizierungsanbieter definieren häufig Typen wie „via_mfa“ oder „via_ad“, die nützliche Informationen zum Authentifizierungstyp liefern. Diese Typen können weiterhin in auth.type oder auth.mechanism verallgemeinert werden, um die Nutzerfreundlichkeit und die Kompatibilität von Regeln über Datasets hinweg zu verbessern.
• Encoding: String.
• Beispiele: via_mfa, via_ad.

Extensions.vulns

• Zweck: Erweiterung der Metadaten zu Sicherheitslücken.
• Encoding: String.
• Beispiel: Daten zum Scannen auf Sicherheitslücken auf dem Host.

Ausfüllen von Dateimetadaten

File.file_metadata

• Zweck: Mit der Datei verknüpfte Metadaten.
• Encoding: String.
• Beispiele:
  • Autor
  • Versionsnummer
  • Versionsnummer
  • Datum der letzten Speicherung

File.full_path

• Zweck: Vollständiger Pfad, der den Speicherort der Datei im System angibt.
• Encoding: String.
• Beispiel: \Programme\Benutzerdefinierte Dienstprogramme\Test.exe

File.md5

• Zweck: MD5-Hashwert für die Datei.
• Codierung: String, Hexadezimalzahl in Kleinbuchstaben.
• Beispiel: 35bf623e7db9bf0d68d0dda764fd9e8c

File.mime_type

• Zweck: MIME-Typ (Multipurpose Internet Mail Extensions) für die Datei.
• Encoding: String.
• Beispiele:
  • PE
  • PDF
  • PowerShell-Skript

File.sha1

• Zweck: SHA-1-Hashwert für die Datei.
• Codierung: String, Hexadezimalzahl in Kleinbuchstaben.
• Beispiel: eb3520d53b45815912f2391b713011453ed8abcf

File.sha256

• Zweck: SHA-256-Hashwert für die Datei.
• Codierung: String, Hexadezimalzahl in Kleinbuchstaben.
• Beispiel: d7173c568b8985e61b4050f81b3fd8e75bc922d2a0843d7079c81ca4b6e36417

File.size

• Zweck: Größe der Datei.
• Codierung: Vorzeichenlose 64-Bit-Ganzzahl.
• Beispiel: 342135

Ausfüllen von FTP-Metadaten

Ftp.command

• Zweck: Speichert den FTP-Befehl.
• Encoding: String.
• Beispiele:
  • binary
  • Löschen
  • get
  • put

Gruppenmetadaten

Informationen zu einer Organisationsgruppe. Damit eine gültige Identität einer Organisationsgruppe während der Normalisierung dargestellt werden kann, müssen Sie mindestens ein Gruppenattribut parametrisieren. Geben Sie dazu entweder eine E-Mail-Adresse in Group.email_addresses oder eine Windows-Sicherheits-ID in Group.windows_sid an.

Group.creation_time

• Zweck: Zeitpunkt der Gruppenerstellung.
• Codierung: RFC 3339, je nach JSON- oder Proto3-Zeitstempelformat.

Group.email_addresses

• Zweck: Kontaktdaten gruppieren.
• Codierung: E-Mail.

Group.group_display_name

• Zweck: Anzeigename der Gruppe.
• Encoding: String.
• Beispiele:
  • Finanzen
  • HR
  • Marketing

Group.product_object_id

• Zweck: Global eindeutige Nutzerobjekt-ID für das Produkt, z. B. eine LDAP-Objekt-ID.
• Encoding: String.

Group.windows_sid

• Zweck: Feld für das Gruppenattribut „Microsoft Windows Security Identifier (SID)“.
• Encoding: String.

Ausfüllen von HTTP-Metadaten

Http.method

• Zweck: Speichert die HTTP-Anfragemethode. Wenn Traffic über HTTP- oder HTTPS-Transportprotokolle erfolgt, müssen Sie eine aktive Anfragemethode angeben. Sie können die Methode nicht auf METHOD_UNSPECIFIED belassen.
• Encoding: String.
• Beispiele:
  • GET
  • HEAD
  • POST

Http.referral_url

• Zweck: Speichert die URL für den HTTP-Referrer.
• Codierung: Gültige RFC-3986-URL.
• Beispiel: https://www.altostrat.com

Http.response_code

• Zweck: Speichert den HTTP-Antwortstatuscode, der angibt, ob eine bestimmte HTTP-Anfrage erfolgreich abgeschlossen wurde.
• Codierung: 32-Bit-Ganzzahl.
• Beispiele:
  • 400
  • 404

Http.user_agent

• Zweck: Speichert den User-Agent-Anfrageheader, der den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des anfragenden Software-User-Agents enthält. User-Agent-Header-Strings dürfen nur aus gültigen UTF-8-codierten Zeichenarrays bestehen.
• Encoding: String.
• Beispiele:
  • Mozilla/5.0 (X11; Linux x86_64)
  • AppleWebKit/534.26 (KHTML, like Gecko)
  • Chrome/41.0.2217.0
  • Safari/527.33

Ausfüllen von Standortmetadaten

Location.city

• Zweck: Speichert den Namen der Stadt.
• Encoding: String.
• Beispiele:
  • Sunnyvale
  • Chicago
  • Málaga

Location.country_or_region

• Zweck: Speichert den Namen des Landes oder der Region der Welt.
• Encoding: String.
• Beispiele:
  • USA
  • Vereinigtes Königreich
  • Spanien

Location.name

• Zweck: Speichert den Namen, der für das Unternehmen spezifisch ist, z. B. ein Gebäude oder Campus.
• Encoding: String.
• Beispiele:
  • Campus 7B
  • Gebäude A2

Location.state

• Zweck: Speichert den Namen des Bundesstaats, der Provinz oder des Gebiets.
• Encoding: String.
• Beispiele:
  • Kalifornien
  • Illinois
  • Ontario

Ausfüllen von Netzwerkmetadaten

Network.application_protocol

• Zweck: Gibt das Netzwerk-Anwendungsprotokoll an.
• Codierung: Enumerated-Typ.

• Mögliche Werte:

  • UNKNOWN_APPLICATION_PROTOCOL
  • AFP
  • APPC
  • AMQP
  • ATOM
  • BEEP
  • BITCOIN
  • BIT_TORRENT
  • CFDP
  • CIP
  • COAP
  • COTP
  • DCERPC
  • DDS
  • DEVICE_NET
  • DHCP
  • DICOM
  • DNP3
  • DNS
  • E_DONKEY
  • ENRP
  • FAST_TRACK
  • FINGER
  • FREENET
  • FTAM
  • GOOSE
  • GOPHER
  • GRPC
  • HL7
  • H323
  • HTTP
  • HTTPS
  • IEC104
  • IRCP
  • KADEMLIA
  • KRB5
  • LDAP
  • LPD
  • MIME
  • MMS
  • MODBUS
  • MQTT
  • NETCONF
  • NFS
  • NIS
  • NNTP
  • NTCIP
  • NTP
  • OSCAR
  • PNRP
  • PTP
  • QUIC
  • RDP
  • RELP
  • RIP
  • RLOGIN
  • RPC
  • RTMP
  • RTP
  • RTPS
  • RTSP
  • SAP
  • SDP
  • SIP
  • SLP
  • KMU
  • SMTP
  • SNMP
  • SNTP
  • SSH
  • SSMS
  • STYX
  • SV
  • TCAP
  • TDS
  • TOR
  • Technischer Vertriebsprozess
  • VTP
  • WHOIS
  • WEB_DAV
  • X400
  • X500
  • XMPP

Network.direction

• Zweck: Gibt die Richtung des Netzwerkverkehrs an.
• Codierung: Enumerated-Typ.
• Mögliche Werte:
  • UNKNOWN_DIRECTION
  • INBOUND
  • OUTBOUND
  • BROADCAST

Network.email

• Zweck: Gibt die E-Mail-Adresse des Absenders/Empfängers an.
• Encoding: String.
• Beispiel: [e-mail]

Network.ip_protocol

• Zweck: Gibt das IP-Protokoll an.
• Codierung: Enumerated-Typ.
• Mögliche Werte:
  • UNKNOWN_IP_PROTOCOL
  • EIGRP – Enhanced Interior Gateway Routing Protocol
  • ESP – Encapsulating Security Payload
  • ETHERIP – Ethernet-within-IP-Kapselung
  • GRE – Generic Routing Encapsulation
  • ICMP – Internet Control Message Protocol
  • IGMP – Internet Group Management Protocol
  • IP6IN4 – IPv6-Kapselung
  • PIM – Protocol Independent Multicast
  • TCP – Transmission Control Protocol
  • UDP (User Datagram Protocol)
  • VRRP – Virtual Router Redundancy Protocol

Network.received_bytes

• Zweck: Gibt die Anzahl der empfangenen Byte an.
• Codierung: Vorzeichenlose 64-Bit-Ganzzahl.
• Beispiel: 12,453,654,768

Network.sent_bytes

• Zweck: Gibt die Anzahl der gesendeten Byte an.
• Codierung: Vorzeichenlose 64-Bit-Ganzzahl.
• Beispiel: 7.654.876

Network.session_duration

• Zweck: Speichert die Dauer der Netzwerksitzung, die normalerweise in einem Drop-Ereignis für die Sitzung zurückgegeben wird. Sie können die Dauer entweder mit „network.session_duration.seconds = 1“ (Typ int64) oder „network.session_duration.nanos = 1“ (Typ int32) festlegen.
• Codierung:
  • 32-Bit-Ganzzahl – für Sekunden (network.session_duration.seconds).
  • 64-Bit-Ganzzahl – für Nanosekunden (network.session_duration.nanos).

Network.session_id

• Zweck: Speichert die Netzwerksitzungs-ID.
• Encoding: String.
• Beispiel: SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-01:34

Auffüllen von Prozessmetadaten

Process.command_line

• Zweck: Speichert den Befehlszeilenstring für den Prozess.
• Encoding: String.
• Beispiel: c:\windows\system32\net.exe-Gruppe.

Process.product_specific_process_id

• Zweck: Speichert die produktspezifische Prozess-ID.
• Encoding: String.
• Beispiele: MySQL:78778 oder CS:90512

Process.parent_process.product_specific_process_id

• Zweck: Speichert die produktspezifische Prozess-ID für den übergeordneten Prozess.
• Encoding: String.
• Beispiele: MySQL:78778 oder CS:90512

Process.file

• Zweck: Speichert den Dateinamen der Datei, die vom Prozess verwendet wird.
• Encoding: String.
• Beispiel: report.xls

Process.parent_process

• Zweck: Speichert die Details des übergeordneten Prozesses.
• Codierung: Substantiv (Prozess)

Process.pid

• Zweck: Speichert die Prozess-ID.
• Encoding: String.
• Beispiele:
  • 308
  • 2002

Ausfüllen von Registry-Metadaten

Registry.registry_key

• Zweck: Speichert den Registrierungsschlüssel, der mit einer Anwendung oder Systemkomponente verknüpft ist.
• Encoding: String.
• Beispiel: HKEY_LOCAL_MACHINE/SYSTEM/DriverDatabase

Registry.registry_value_name

• Zweck: Speichert den Namen des Registrierungswerts, der mit einer Anwendung oder Systemkomponente verknüpft ist.
• Encoding: String.
• Beispiel: TEMP

Registry.registry_value_data

• Zweck: Speichert die mit einem Registrierungswert verknüpften Daten.
• Encoding: String.
• Beispiel: %USERPROFILE%\Local Settings\Temp

Auffüllen von Metadaten für Sicherheitsergebnisse

Die Metadaten des Sicherheitsergebnisses enthalten Details zu Sicherheitsrisiken und ‑bedrohungen, die von einem Sicherheitssystem gefunden wurden, sowie zu den Maßnahmen, die zur Minimierung dieser Risiken und Bedrohungen ergriffen wurden.

SecurityResult.about

• Zweck: Geben Sie eine Beschreibung des Sicherheitsergebnisses an.
• Codierung: Substantiv.

SecurityResult.action

• Zweck: Geben Sie eine Sicherheitsaktion an.
• Codierung: Enumerated-Typ.
• Mögliche Werte: Im Google SecOps-UDM sind die folgenden Sicherheitsaktionen definiert:
  • ZULASSEN
  • ALLOW_WITH_MODIFICATION: Die Datei oder E‑Mail wurde desinfiziert oder umgeschrieben und trotzdem weitergeleitet.
  • BLOCKIEREN
  • QUARANTINE: Für eine spätere Analyse speichern (bedeutet nicht blockieren).
  • UNKNOWN_ACTION

SecurityResult.action_details

• Zweck: Vom Anbieter bereitgestellte Details zu den Maßnahmen, die aufgrund des Sicherheitsvorfalls ergriffen wurden. Sicherheitsaktionen lassen sich oft am besten in das allgemeinere UDM-Feld Security_Result.action übersetzen. Möglicherweise müssen Sie jedoch Regeln für die genaue Beschreibung der Aktion durch den Anbieter schreiben.
• Encoding: String.
• Beispiele: „drop“, „block“, „decrypt“, „encrypt“.

SecurityResult.category

• Zweck: Geben Sie eine Sicherheitskategorie an.
• Encoding: Enum.
• Mögliche Werte: Google SecOps UDM definiert die folgenden Sicherheitskategorien:
  • ACL_VIOLATION: Es wurde versucht, unbefugt auf Dateien, Webdienste, Prozesse, Webobjekte usw. zuzugreifen.
  • AUTH_VIOLATION: Die Authentifizierung ist fehlgeschlagen, z. B. aufgrund eines falschen Passworts oder einer falschen 2-Faktor-Authentifizierung.
  • DATA_AT_REST—DLP: Sensordaten, die bei einem Scan in inaktiven Daten gefunden wurden.
  • DATA_DESTRUCTION: Versuch, Daten zu zerstören oder zu löschen.
  • DATA_EXFILTRATION—DLP: Übertragung von Sensordaten, Kopieren auf USB-Stick.
  • EXPLOIT: Versuchte Überläufe, fehlerhafte Protokollcodierungen, ROP, SQL-Injection usw., sowohl netzwerk- als auch hostbasiert.
  • MAIL_PHISHING: Phishing-E-Mails, Chatnachrichten usw.
  • MAIL_SPAM: Spam-E‑Mail, ‑Nachricht usw.
  • MAIL_SPOOFING: Gefälschte Quell-E-Mail-Adresse usw.
  • NETWORK_CATEGORIZED_CONTENT
  • NETWORK_COMMAND_AND_CONTROL: Wenn der Command and Control-Kanal bekannt ist.
  • NETWORK_DENIAL_OF_SERVICE
  • NETWORK_MALICIOUS: Command and Control, Netzwerk-Exploit, verdächtige Aktivität, potenzieller Reverse-Tunnel usw.
  • NETWORK_SUSPICIOUS: Nicht sicherheitsrelevant, z. B. wenn die URL mit Glücksspielen verknüpft ist.
  • NETWORK_RECON: Portscan, der von einem IDS erkannt wurde, oder Prüfung durch eine Webanwendung.
  • POLICY_VIOLATION: Verstoß gegen Sicherheitsrichtlinien, einschließlich Verstößen gegen Firewall-, Proxy- und HIPS-Regeln oder NAC-Blockierungsaktionen.
  • SOFTWARE_MALICIOUS: Malware, Spyware, Rootkits usw.
  • SOFTWARE_PUA: Potenziell unerwünschte App, z. B. Adware usw.
  • SOFTWARE_SUSPICIOUS
  • UNKNOWN_CATEGORY

SecurityResult.confidence

• Zweck: Geben Sie die Konfidenz in Bezug auf ein Sicherheitsereignis an, wie vom Produkt geschätzt.
• Encoding: Enum.
• Mögliche Werte: Im Google SecOps-UDM sind die folgenden Kategorien für die Produktkonfidenz definiert:
  • UNKNOWN_CONFIDENCE
  • LOW_CONFIDENCE
  • MEDIUM_CONFIDENCE
  • HIGH_CONFIDENCE

SecurityResult.confidence_details

• Zweck: Zusätzliche Details zur Konfidenz eines Sicherheitsereignisses, wie vom Produktanbieter geschätzt.
• Encoding: String.

SecurityResult.priority

• Zweck: Geben Sie eine Priorität für ein Sicherheitsereignis an, wie vom Produktanbieter geschätzt.
• Encoding: Enum.
• Mögliche Werte: Im Google SecOps-UDM sind die folgenden Produktprioritätskategorien definiert:
  • UNKNOWN_PRIORITY
  • LOW_PRIORITY
  • MEDIUM_PRIORITY
  • HIGH_PRIORITY

SecurityResult.priority_details

• Zweck: Anbieterspezifische Informationen zur Priorität des Sicherheitsergebnisses.
• Encoding: String.

SecurityResult.rule_id

• Zweck: Kennung für die Sicherheitsregel.
• Encoding: String.
• Beispiele:
  • 08123
  • 5d2b44d0-5ef6-40f5-a704-47d61d3babbe

SecurityResult.rule_name

• Zweck: Name der Sicherheitsregel.
• Encoding: String.
• Beispiel: BlockInboundToOracle.

SecurityResult.severity

• Zweck: Schweregrad eines Sicherheitsereignisses, wie vom Produktanbieter anhand der im Google SecOps-UDM definierten Werte geschätzt.
• Encoding: Enum.
• Mögliche Werte: Google SecOps UDM definiert die folgenden Produktschweregrade:
  • UNKNOWN_SEVERITY – Nicht bösartig
  • INFORMATIONAL—Non-malicious
  • FEHLER – Nicht bösartig
  • NIEDRIG – Schädlich
  • MITTEL – Bösartig
  • HOCH – Schädlich

SecurityResult.severity_details

• Zweck: Schweregrad eines Sicherheitsereignisses, wie vom Produktanbieter geschätzt.
• Encoding: String.

SecurityResult.threat_name

• Zweck: Name der Sicherheitsbedrohung.
• Encoding: String.
• Beispiele:
  • W32/File-A
  • Slammer

SecurityResult.url_back_to_product

• Zweck: URL, über die Sie zur Quellproduktkonsole für dieses Sicherheitsereignis weitergeleitet werden.
• Encoding: String.

Auffüllen von Nutzermetadaten

Hinweis: Alle wichtigen Nutzerkontoparameter, insbesondere User.userid, User.windows_sid, User.employee_id und jede einzelne E-Mail-Adresse in User.email_addresses, haben eine obligatorische strukturelle Längenbegrenzung von 256 Zeichen. Wenn Sie einen Kontoidentitätsstring mit mehr als 256 Zeichen angeben, wird die Nutzlast bei der Indexierungsprüfung abgelehnt. Außerdem müssen Sie mindestens eine dieser vier Haupt-Properties angeben, um die Identitätsprüfungen für Hauptnutzer während der Normalisierung zu bestehen.

User.email_addresses

• Zweck: Speichert die E‑Mail-Adressen des Nutzers.
• Encoding: Wiederholter String.
• Beispiel: [e-mail]

User.employee_id

• Zweck: Speichert die Personal-ID des Nutzers.
• Encoding: String.
• Beispiel: 11223344.

User.first_name

• Zweck: Speichert den Vornamen des Nutzers.
• Encoding: String.
• Beispiel: Max.

User.middle_name

• Zweck: Speichert den zweiten Vornamen des Nutzers.
• Encoding: String.
• Beispiel: Anthony.

User.last_name

• Zweck: Speichert den Nachnamen des Nutzers.
• Encoding: String.
• Beispiel: Locke.

User.group_identifiers

• Zweck: Speichert die Gruppen-ID(s) (eine GUID, LDAP-OID oder ähnliches), die einem Nutzer zugeordnet sind.
• Encoding: Wiederholter String.
• Beispiel: admin-users.

User.phone_numbers

• Zweck: Speichert die Telefonnummern des Nutzers.
• Encoding: Wiederholter String.
• Beispiel: 18005550101

User.title

• Zweck: Speichert die Berufsbezeichnung des Nutzers.
• Encoding: String.
• Beispiel: Customer-Relationship-Manager.

User.user_display_name

• Zweck: Speichert den Anzeigenamen des Nutzers.
• Encoding: String.
• Beispiel: John Locke.

User.userid

• Zweck: Speichert die Nutzer-ID.
• Encoding: String.
• Beispiel: jlocke.

User.windows_sid

• Zweck: Speichert die Microsoft Windows-Sicherheitskennung (SID), die einem Nutzer zugeordnet ist.
• Encoding: String.
• Beispiel: S-1-5-21-1180649209-123456789-3582944384-1064

Ausfüllen von Metadaten zu Sicherheitslücken

Vulnerability.about

• Zweck: Wenn sich die Sicherheitslücke auf ein bestimmtes Substantiv bezieht (z. B. ausführbare Datei), fügen Sie es hier hinzu.
• Codierung: Substantiv. Siehe Population of Noun metadata.
• Beispiel: ausführbar.

Vulnerability.cvss_base_score

• Zweck: Basiswert für das Common Vulnerability Scoring System (CVSS).
• Codierung: Gleitkomma.
• Bereich: 0,0 bis 10,0
• Beispiel: 8,5

Vulnerability.cvss_vector

• Zweck: Vektor für die CVSS-Eigenschaften der Sicherheitslücke. Ein CVSS-Wert setzt sich aus den folgenden Messwerten zusammen:

  • Angriffsvektor (AV)
  • Access Complexity (AC)
  • Authentifizierung (Au)
  • Auswirkungen auf die Vertraulichkeit (C)
  • Auswirkungen auf die Integrität (I)
  • Auswirkungen auf die Verfügbarkeit (A)

  Weitere Informationen finden Sie unter https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator.

• Encoding: String.

• Beispiel: AV:L/AC:H/Au:N/C:N/I:P/A:C

Vulnerability.cvss_version

• Zweck: CVSS-Version für den Sicherheitslückenwert oder ‑vektor.
• Encoding: String.
• Beispiel: 3.1

Vulnerability.description

• Zweck: Beschreibung der Sicherheitslücke.
• Encoding: String.

Vulnerability.first_found

• Zweck: Produkte, die einen Verlauf von Scans auf Sicherheitslücken speichern, sollten „first_found“ mit dem Zeitpunkt füllen, zu dem die Sicherheitslücke für dieses Asset zum ersten Mal erkannt wurde.
• Encoding: String.

Vulnerability.last_found

• Zweck: Produkte, die einen Verlauf von Scans auf Sicherheitslücken speichern, sollten „last_found“ mit dem Zeitpunkt füllen, zu dem die Sicherheitslücke für dieses Asset zuletzt erkannt wurde.
• Encoding: String.

Vulnerability.name

• Zweck: Name der Sicherheitslücke.
• Encoding: String.
• Beispiel: Nicht unterstützte Betriebssystemversion erkannt.

Vulnerability.scan_end_time

• Zweck: Wenn die Sicherheitslücke während eines Asset-Scans entdeckt wurde, geben Sie in diesem Feld den Zeitpunkt an, zu dem der Scan beendet wurde. Lassen Sie dieses Feld leer, wenn die Endzeit nicht verfügbar oder nicht zutreffend ist.
• Encoding: String.

Vulnerability.scan_start_time

• Zweck: Wenn die Sicherheitslücke während eines Asset-Scans entdeckt wurde, geben Sie in diesem Feld die Startzeit des Scans an. Lassen Sie dieses Feld leer, wenn die Startzeit nicht verfügbar oder nicht zutreffend ist.
• Encoding: String.

Vulnerability.severity

• Zweck: Schweregrad der Sicherheitslücke.
• Codierung: Enumerated-Typ.
• Mögliche Werte:
  • UNKNOWN_SEVERITY
  • LOW
  • MEDIUM
  • HOCH

Vulnerability.severity_details

• Zweck: Anbieterspezifische Details zum Schweregrad.
• Encoding: String.

Ausfüllen von Benachrichtigungsmetadaten

Achtung: Diese Felder werden nicht mehr unterstützt. Verwenden Sie YARA-L-Erkennungsregelwarnungen für Warnungsmetadaten. Weitere Informationen finden Sie unter Verworfene Features.

idm.is_significant

• Zweck: Gibt an, ob die Benachrichtigung in Enterprise Insights angezeigt werden soll.
• Encoding: Boolesch.

idm.is_alert

• Zweck: Gibt an, ob es sich bei dem Ereignis um eine Meldung handelt.
• Encoding: Boolesch.

Erforderliche und optionale Felder für Entitätstypen

Entitätstyp	Rechtssubjektspezifische Anforderungen
IP_ADDRESS	entity.ip muss mindestens eine gültige IPv4- oder IPv6-Adresse enthalten.
FILE	entity.file muss vorhanden sein und mindestens ein Feld enthalten.
DOMAIN_NAME	entity.hostname muss vorhanden sein und einen gültigen Hostnamen mit einer Länge von bis zu 255 Byte darstellen. Optional: Wenn entity.domain.whois_server ausgefüllt ist, darf die entity.domain-Nachricht nicht mehr als 50 abgeleitete Felder enthalten.
URL	entity.url muss vorhanden und darf nicht leer sein.
MUTEX	entity.resource muss vorhanden sein. entity.resource.resource_type muss auf MUTEX festgelegt sein. entity.resource.name muss vorhanden und darf nicht leer sein.
USER	entity.user muss vorhanden sein. Bei Kontextentitäten muss entity.user mindestens ein Kernidentitätsfeld angeben: user.userid, user.windows_sid, user.employee_id oder eine E-Mail-Adresse in user.email_addresses. Die einzelnen Kernkennungen dürfen maximal 256 Zeichen lang sein. Außerdem müssen Sie entweder product_object_id in entity.user oder product_entity_id in metadata angeben. Für Kompromittierungsindikator-Entitäten (IOC) muss entity.user mindestens eine E-Mail-Adresse in user.email_addresses enthalten.
RESOURCE	entity.resource muss vorhanden sein. Für Kontextentitäten muss entity.resource.resource_type angegeben und darf nicht leer sein. Außerdem müssen Sie entweder product_object_id in entity.resource oder product_entity_id in metadata angeben. Für Kompromittierungsindikator-Entitäten (Indicator of Compromise, IOC) muss entity.resource.resource_type entweder auf MUTEX oder STORAGE_OBJECT festgelegt werden. Wenn resource_type MUTEX ist: Folgen Sie den Anforderungen für MUTEX. Wenn resource_type den Wert STORAGE_OBJECT hat: entity.resource.resource_subtype muss vorhanden und darf nicht leer sein. Mindestens eines der folgenden Felder in entity.registry muss vorhanden und darf nicht leer sein: entity.registry.registry_key entity.registry.registry_value_data entity.registry.registry_value_name
CIDR_BLOCK	entity.network.ip_subnet_range muss vorhanden sein und eine gültige CIDR-Notation (Classless Inter-Domain Routing) im folgenden Format enthalten: ip_address/prefix_length.
ASSET	entity.asset muss vorhanden sein. entity.asset muss mindestens ein Kernidentitätsfeld enthalten: asset.hostname, asset.asset_id, eine IP-Adresse in asset.ip oder eine MAC-Adresse in asset.mac. Alle angegebenen IP-Adressen müssen gültige IPv4- oder IPv6-Formate sein. Sie müssen entweder product_object_id in entity.asset oder product_entity_id in metadata angeben.
GROUP	entity.group muss vorhanden sein. entity.group muss mindestens ein Feld für die Kernidentität angeben: eine E-Mail-Adresse in group.email_addresses oder eine Windows-Sicherheits-ID in group.windows_sid. Sie müssen entweder product_object_id in entity.group oder product_entity_id in metadata angeben.
AI	entity.ai muss vorhanden sein.

Pflichtfelder und optionale Felder für jeden Ereignistyp

In diesem Abschnitt werden die erforderlichen und optionalen Felder beschrieben, die für jeden UDM-Ereignistyp ausgefüllt werden sollten.

Weitere Informationen zu bestimmten UDM-Feldern (z. B. Enum-Nummern) finden Sie in der Feldliste für das Unified Data Model.

DEVICE_CONFIG_UPDATE, DEVICE_FIRMWARE_UPDATE, DEVICE_PROGRAM_DOWNLOAD, DEVICE_PROGRAM_UPLOAD

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder (event_timestamp und event_type) an.
• principal: Geben Sie mindestens eine Maschinenkennung an (principal.hostname, principal.ip, principal.mac oder principal.asset_id).

Optionale Felder:

• principal.user: Wird ausgefüllt, wenn Nutzerinformationen für das Konto verfügbar sind, das die Geräteaktualisierung initiiert hat.
• target: Geben Sie Details zum Zielgerät, zur Firmware, zur Konfigurationsressource oder zur Programmdatei ein, wenn diese sich von principal unterscheiden.
• security_result: Beschreibt alle erkannten schädlichen oder anomalen Aktivitäten.

UDM-Beispiel für DEVICE_FIRMWARE_UPDATE

Das folgende Beispiel zeigt, wie ein DEVICE_FIRMWARE_UPDATE-Ereignis für das Google SecOps-UDM formatiert wird:

{
  "metadata": {
    "event_timestamp": "2025-03-10T14:22:05.000000Z",
    "event_type": "DEVICE_FIRMWARE_UPDATE"
  },
  "principal": {
    "hostname": "plc-controller-01",
    "ip": [
      "10.20.30.40"
    ]
  }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Gerät, auf dem das Firmware-Update durchgeführt wurde.

EMAIL_TRANSACTION, EMAIL_UNCATEGORIZED

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• principal: Geben Sie Informationen zu dem Computer ein, von dem die E‑Mail-Nachricht stammt (z. B. die IP-Adresse des Absenders).

Optionale Felder:

• about: URLs, IP-Adressen, Domains und alle Dateianhänge, die im E‑Mail-Text eingebettet sind. Beachten Sie, dass „about.file.hash“ kein indexiertes Feld für Datei-Hashes ist. Hash-Ansichten werden nicht aus einem Anhang-Hash ausgefüllt, der auf dieses Feld normalisiert ist.
• securityResult.about: Schädliche URLs, IP-Adressen und Dateien, die im E‑Mail-Text eingebettet sind.
• network.email: Informationen zum Absender oder Empfänger der E‑Mail. Beachten Sie, dass „network.email“ kein Aliasing-Feld ist. Wenn Sie Aliasing und Anreicherung für die Suche oder Erkennung benötigen, müssen Sie mithilfe einer Parsererweiterung in das Hauptkonto oder Ziel indexieren.
• principal: Wenn Clientcomputerdaten darüber vorhanden sind, wer die E-Mail gesendet hat, füllen Sie die Serverdetails in „principal“ aus (z. B. Clientprozess, Portnummern, Nutzername usw.).
• target: Wenn Daten zum Ziel-E-Mail-Server vorhanden sind, geben Sie die Serverdetails in „target“ ein (z. B. die IP-Adresse).
• intermediary: Wenn Mailserver- oder Mailproxy-Daten vorhanden sind, geben Sie die Serverdetails in „intermediary“ ein.

Hinweise:

• Geben Sie niemals principal.email oder target.email ein.
• Füllen Sie nur das E-Mail-Feld in security_result.about oder network.email aus.
• Sicherheitsergebnisse auf oberster Ebene haben in der Regel ein Substantiv (optional für Spam).
• EMAIL_URL_CLICK ist als veraltet markiert.

UDM-Beispiel für EMAIL_TRANSACTION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ EMAIL_TRANSACTION für das Google SecOps-UDM formatiert wird:

metadata {
  event_timestamp: "2023-07-06T06:26:10.448584Z"
  event_type: EMAIL_TRANSACTION
}
principal {
  ip: "1.2.3.4"
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Gerät, von dem die E‑Mail stammt.

FILE_CREATION, FILE_DELETION, FILE_MODIFICATION, FILE_READ, FILE_OPEN und FILE_UNCATEGORIZED

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• Hauptkonto:
  • Mindestens eine Maschinenkennung.
  • (Optional) Füllen Sie „principal.process“ mit Informationen zum Prozess, der auf die Datei zugreift.
• target:
  • Wenn sich die Datei auf einem Remote-System befindet (z. B. SMB-Freigabe), muss das Ziel mindestens eine Maschinen-ID für die Zielmaschine enthalten. Andernfalls müssen alle Maschinen-IDs leer sein.
  • Füllen Sie „target.file“ mit Informationen zur Datei.

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität.
• principal.user: Wird ausgefüllt, wenn Nutzerinformationen zum Prozess verfügbar sind.

UDM-Beispiel für FILE_MODIFICATION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ FILE_MODIFICATION für das Google SecOps-UDM formatiert wird:

metadata {
  event_timestamp: "2023-07-03T12:14:38.164507Z"
  event_type: FILE_MODIFICATION
}
principal {
  hostname: "pinguino-01"
}
target {
  file {
    full_path: "foo.bar"
  }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Gerät, auf dem die Datei geändert wurde.
• target: Informationen zur geänderten Datei.

FILE_COPY

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder wie beschrieben an.
• Hauptkonto:
  • Mindestens eine Maschinenkennung.
  • (Optional) Füllen Sie principal.process mit Informationen zum Prozess, der den Dateikopiervorgang ausführt.
• src:
  • Geben Sie in src.file Informationen zur Quelldatei ein.
  • Wenn sich die Datei auf einem Remote-System befindet (z. B. SMB-Freigabe), muss „src“ mindestens eine Maschinen-ID für die Quellmaschine enthalten, auf der die Quelldatei gespeichert ist.
• target:
  • Geben Sie in target.file Informationen zur Zieldatei ein.
  • Wenn sich die Datei auf einem Remote-System befindet (z. B. SMB-Freigabe), muss das Feld target mindestens eine Maschinenkennung für die Zielmaschine enthalten, auf der sich die Zieldatei befindet.

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität.
• principal.user: Wird ausgefüllt, wenn Nutzerinformationen zum Prozess verfügbar sind.

FILE_MOVE, FILE_SYNC

Pflichtfelder:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Mindestens eine Maschinen-ID (z. B. principal.hostname).
• src: Geben Sie src.file (z. B. src.file.full_path) an, um die Originaldatei darzustellen. Dieses Feld ist für FILE_MOVE und FILE_COPY erforderlich. Für FILE_SYNC müssen Sie mindestens src.file oder target.file angeben (und target darf nicht leer sein).
• target: Geben Sie target.file (z. B. target.file.full_path) für die Zieldatei an. Dieses Feld ist für FILE_MOVE und FILE_COPY erforderlich. Für FILE_SYNC müssen Sie mindestens src.file oder target.file angeben.

UDM-Beispiel für FILE_MOVE

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ FILE_MOVE für das Google SecOps-UDM formatiert wird:

{
    "metadata": {
        "event_timestamp": "2023-07-03T12:45:02.557878Z",
        "event_type": "FILE_MOVE"
    },
    "src": {
        "file": {
            "full_path": "foo.bar"
        }
    },
    "principal": {
        "hostname": "pinguino-01"
    },
    "target": {
        "file": {
            "full_path": "foo.bar"
        }
    }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Gerät, auf dem die Datei verschoben wurde.
• src: Informationen zur Quelldatei.
• target: Informationen zur Zieldatei.

GENERIC_EVENT

Verwenden Sie GENERIC_EVENT nur, wenn ein Ereignis in keine andere UDM-Ereignistypkategorie passt.

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder (event_timestamp und event_type) an.

Optionale Felder:

• metadata.product_event_type und metadata.description: Geben Sie den anbieterspezifischen Ereignisnamen und eine menschenlesbare Beschreibung an.
• principal, target, src, intermediary, observer und about: Geben Sie alle am Ereignis beteiligten Entitäten an. GENERIC_EVENT erzwingt keine entitätsspezifischen Feldanforderungen, die über die Standardvalidierung für skalare Typen hinausgehen (z. B. gültige IP-Adressen und Hostnamen bis zu 255 Byte).
• security_result: Beschreibt alle erkannten schädlichen oder anomalen Aktivitäten.

UDM-Beispiel für GENERIC_EVENT

Das folgende Beispiel zeigt, wie ein GENERIC_EVENT-Ereignis für das Google SecOps-UDM formatiert wird:

{
  "metadata": {
    "event_timestamp": "2025-03-10T15:00:00.000000Z",
    "event_type": "GENERIC_EVENT",
    "product_event_type": "CustomAuditEvent",
    "description": "Custom audit event recorded on host"
  },
  "principal": {
    "hostname": "workstation-01"
  }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen und anbieterspezifische Beschreibung des Ereignisses.
• principal: Informationen zum Gerät, das mit dem Ereignis verknüpft ist.

GROUP_CREATION, GROUP_DELETION, GROUP_MODIFICATION, GROUP_UNCATEGORIZED

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder (event_timestamp und event_type) an.
• Hauptkonto: Geben Sie mindestens eine Nutzer-ID in principal.user an (userid, windows_sid, email_addresses oder employee_id).
• target: Geben Sie in target.group Details zur Gruppe ein, die erstellt, gelöscht oder geändert wird (und in target.user, wenn ein Nutzer der Gruppe hinzugefügt oder daraus entfernt wird). Das Feld „target“ darf nicht leer sein.

Optionale Felder:

• principal: Enthält Maschinenkennungen für das Gerät, von dem der Gruppenvorgang stammt.
• target.group: Schließen Sie Gruppenkennungen wie group_display_name, product_object_id, windows_sid oder email_addresses ein.
• security_result: Beschreibt alle erkannten schädlichen Aktivitäten.

UDM-Beispiel für GROUP_MODIFICATION

Das folgende Beispiel zeigt, wie ein GROUP_MODIFICATION-Ereignis für das Google SecOps-UDM formatiert wird:

{
  "metadata": {
    "event_timestamp": "2025-03-10T16:10:00.000000Z",
    "event_type": "GROUP_MODIFICATION"
  },
  "principal": {
    "user": {
      "userid": "admin_user"
    }
  },
  "target": {
    "group": {
      "group_display_name": "Domain Admins",
      "windows_sid": "S-1-5-21-3623811015-3361044348-30300820-512"
    },
    "user": {
      "userid": "jdoe"
    }
  }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Nutzer, der die Gruppe geändert hat.
• target: Informationen zur geänderten Gruppe und zum betroffenen Nutzer.

MUTEX_CREATION, MUTEX_UNCATEGORIZED

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• Hauptkonto:
  • Mindestens eine Maschinenkennung.
  • Füllen Sie „principal.process“ mit Informationen zum Prozess, der den Mutex erstellt. Für die UDM-Validierung ist ein Prozessobjekt im Hauptkonto erforderlich. Sie können die UDM-Validierung nicht mit einem Prozess bestehen, der nur im Ziel vorhanden ist.
• target:
  • Füllen Sie target.resource aus.
  • Geben Sie für target.resource.type den Wert MUTEX ein.
  • Geben Sie für target.resource.name den Namen des erstellten Mutex ein.

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität.
• principal.user: Wird ausgefüllt, wenn Nutzerinformationen zum Prozess verfügbar sind.

UDM-Beispiel für MUTEX_CREATION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ MUTEX_CREATION für das Google SecOps-UDM formatiert wird:

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: MUTEX_CREATION
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "test.altostrat.com"
  process {
    pid: "0xc45"
    file {
      full_path: "C:\\Windows\\regedit.exe"
    }
  }
}
target {
  resource {
    type: "MUTEX"
    name: "test-mutex"
  }
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptkonto: Geräte- und Prozessdetails.
• target: Informationen zum Mutex.

NETWORK_CONNECTION, NETWORK_FLOW, NETWORK_FTP, NETWORK_SMTP

Pflichtfelder:

• metadata: event_timestamp
• Hauptkonto: Geben Sie Details zum Computer an, der die Netzwerkverbindung initiiert hat (z. B. Quelle).
• target: Geben Sie Details zur Zielmaschine an, wenn sie sich von der Hauptmaschine unterscheidet.
• network: Erfasst Details zur Netzwerkverbindung (Ports, Protokoll usw.).

Optionale Felder:

• principal.process und target.process: Enthalten Prozessinformationen, die mit dem Hauptkonto und dem Ziel der Netzwerkverbindung verknüpft sind (falls verfügbar).
• principal.user und target.user: Enthalten Nutzerinformationen, die mit dem Hauptkonto und dem Ziel der Netzwerkverbindung verknüpft sind (falls verfügbar).
• network: Erfasst Details zur Netzwerkverbindung, einschließlich Ports und Protokoll.

Hinweis: Wenn für das Hauptkonto oder das Ziel ein Port angegeben ist, dürfen die Felder ip und mac für alle Netzwerkereignisse jeweils nur einen Wert enthalten (falls verfügbar), d. h. die IP-Adresse und die MAC-Adresse, die mit dem Port verknüpft sind. Wenn kein Port angegeben ist, können Sie eine beliebige Anzahl von IP- und MAC-Adressen angeben, die dem Gerät zum Zeitpunkt des Ereignisses zugeordnet waren (keine bestimmte Reihenfolge erforderlich).

NETWORK_DHCP

Pflichtfelder:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Mindestens eine Maschinenkennung (z. B. principal.ip).
• network: network.application_protocol muss als DHCP angegeben werden. Außerdem muss „network.dhcp.opcode“ ausgefüllt sein (z. B. BOOTREQUEST oder BOOTREPLY).

Hinweis: Google SecOps wertet nur BOOTREQUEST oder BOOTREPLY für Asset-Aliasing aus.

UDM-Beispiel für NETWORK_DHCP

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ NETWORK_DHCP für das Google SecOps-UDM formatiert wird:

{
    "metadata": {
        "event_timestamp": "2023-07-04T18:52:22.142364Z",
        "event_type": "NETWORK_DHCP"
    },
    "principal": {
        "ip": [
            "1.2.3.4"
        ]
    },
    "network": {
        "application_protocol": "DHCP",
        "dhcp": {
            "opcode": "BOOTREPLY"
        }
    }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Gerät, das die DHCP-Lease anfordert oder empfängt.
• network: Details zur DHCP-Netzwerkverbindung und zum Vorgangscode.

NETWORK_DNS

Pflichtfelder:

• principal: Mindestens eine Maschinenkennung (z. B. principal.ip).
• network: network.application_protocol muss als DNS angegeben werden. Erfordert auch network.dns.questions.name.
• metadata: Hintergrundinformationen zum Ereignis.

UDM-Beispiel für NETWORK_DNS

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ NETWORK_DNS für das Google SecOps-UDM formatiert wird:

{
    "metadata": {
        "event_timestamp": "2023-07-04T18:54:15.943301Z",
        "event_type": "NETWORK_DNS"
    },
    "principal": {
        "ip": [
            "1.2.3.4"
        ]
    },
    "network": {
        "application_protocol": "DNS",
        "dns": {
            "questions": {
                "name": "www.acme.com"
            }
        }
    }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Gerät, das die DNS-Anfrage stellt.
• network: Details zur DNS-Netzwerkverbindung und zum abgefragten Domainnamen.

NETWORK_HTTP

Der Ereignistyp NETWORK_HTTP stellt eine HTTP-Netzwerkverbindung von einem Hauptkonto zu einem Zielwebserver dar.

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• target: Stellt den Webserver dar. Geben Sie Geräteinformationen und eine optionale Portnummer an.
  • Wenn eine Zielportnummer verfügbar ist, geben Sie zusätzlich zur Portnummer, die dieser Netzwerkverbindung zugeordnet ist, nur eine IP-Adresse an (obwohl für das Ziel mehrere andere Maschinenkennungen angegeben werden könnten).
  • Geben Sie für target.url die aufgerufene URL ein.

Optionale Felder:

• Hauptkonto: Stellt den Client dar, der die Webanfrage initiiert. Geben Sie mindestens eine Maschinenkennung (z. B. Hostname, IP, MAC, proprietäre Asset-ID) oder eine Nutzer-ID (z. B. Nutzername) an.
  • Wenn eine bestimmte Netzwerkverbindung beschrieben wird und eine Client-Portnummer verfügbar ist, geben Sie nur eine IP-Adresse zusammen mit der Portnummer an, die dieser Netzwerkverbindung zugeordnet ist. Es können jedoch auch andere Maschinenkennungen angegeben werden, um das Teilnehmergerät besser zu beschreiben.
  • Wenn kein Quellport verfügbar ist, können Sie alle IP- und MAC-Adressen, Asset-IDs und Hostnamenwerte angeben, die das Hauptgerät beschreiben.
• network und network.http: Enthält Details zur HTTP-Netzwerkverbindung. Sie müssen die folgenden Felder ausfüllen:
  • network.ip_protocol
  • network.application_protocol
  • network.http.method
• about: Stellt andere Entitäten dar, die in der HTTP-Transaktion gefunden wurden (z. B. eine hoch- oder heruntergeladene Datei).
• intermediary: Stellt einen Proxyserver dar (falls dieser sich vom Hauptkonto oder Ziel unterscheidet).
• metadata: Füllen Sie die anderen Metadatenfelder aus.
• network: Füllen Sie andere Netzwerkfelder aus.
• network.email: Wenn die HTTP-Netzwerkverbindung von einer URL stammt, die in einer E‑Mail-Nachricht enthalten war, füllen Sie „network.email“ mit den entsprechenden Details.
• observer: Stellt einen passiven Sniffer dar (falls vorhanden).
• security_result: Fügen Sie dem Feld „security_result“ ein oder mehrere Elemente hinzu, um die erkannte schädliche Aktivität darzustellen.

UDM-Beispiel für NETWORK_HTTP

Das folgende Beispiel zeigt, wie ein Sophos-Antivirenereignis vom Typ NETWORK_HTTP in das Google SecOps-UDM-Format konvertiert wird.

Das folgende Ereignis ist das ursprüngliche Sophos-Antivirenereignis:

date=2013-08-07 time=13:27:41 timezone="GMT" device_name="CC500ia" device_id= C070123456-ABCDE log_id=030906208001 log_type="Anti-Virus" log_component="HTTP" log_subtype="Virus" status="" priority=Critical fw_rule_id=0 user_name="john.smith" iap=7 av_policy_name="" virus="TR/ElderadoB.A.78" url="altostrat.fr/img/logo.gif" domainname="altostrat.fr" src_ip=10.10.2.10 src_port=60671 src_country_code= dst_ip=203.0.113.31 dst_port=80 dst_country_code=FRA

So formatieren Sie dieselben Informationen in Proto3 mit der Google SecOps-UDM-Syntax:

metadata {
  event_timestamp: "2013-08-07T13:27:41+00:00"
  event_type: NETWORK_HTTP
  product_name: "Sophos Antivirus"
  product_log_id: "030906208001"
}

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

target {
  hostname: "altostrat.fr"
  ip: "203.0.113.31"
  port: 80
  url: "altostrat.fr/img/logo.gif"
}

network {
  ip_protocol: TCP
 }

security_result {
  about {
    url: "altostrat.fr/img/logo.gif"
    category: SOFTWARE_MALICIOUS
    category_details: "Virus"
    threat_name: "TR/ElderadoB.A.78"
    severity: HIGH                   # Google Security Operations-normalized severity
    severity_details: "Critical"    # Vendor-specific severity string
  }
}

additional { "dst_country_code" : "FRA", "iap" : "7" "fw_rule_id" : "0" }

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Sicherheitsgerät, das das Ereignis erkannt hat.
• Ziel: Gerät, das die Schadsoftware erhalten hat.
• Netzwerk: Netzwerkinformationen zum schädlichen Host.
• security_result: Sicherheitsdetails zur schädlichen Software.
• additional: Anbieterinformationen außerhalb des UDM-Bereichs.

PROCESS_INJECTION, PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_TERMINATION, PROCESS_UNCATEGORIZED

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• Hauptkonto:
  • Mindestens eine Maschinenkennung.
  • Bei Ereignissen zur Prozessinjektion und Prozessbeendigung muss principal.process, sofern verfügbar, Informationen zum Prozess enthalten, der die Aktion initiiert hat. Bei einem Ereignis zum Prozessstart muss principal.process beispielsweise Details zum übergeordneten Prozess enthalten, sofern verfügbar.
• target:
  • target.process: Enthält Informationen zum Prozess, der eingefügt, geöffnet, gestartet oder beendet wird.
  • Wenn der Zielprozess remote ist, muss das Ziel mindestens eine Maschinenkennung für die Zielmaschine enthalten (z. B. eine IP-Adresse, eine MAC-Adresse, einen Hostnamen oder eine Drittanbieter-Asset-ID).

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität.
• principal.user und target.user: Füllen Sie den initiierenden Prozess (Hauptkonto) und den Zielprozess aus, wenn die Nutzerinformationen verfügbar sind.

UDM-Beispiel für PROCESS_LAUNCH

Das folgende Beispiel zeigt, wie Sie ein PROCESS_LAUNCH-Ereignis mit der Google SecOps-UDM-Syntax formatieren:

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: PROCESS_LAUNCH
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "altostrat.com"
}
target {
  process {
    pid: "0xc45"
    file {
      full_path: "C:\\Windows\\regedit.exe"
    }
  }
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptkonto: Gerätedetails.
• target: Prozessdetails.

PROCESS_MODULE_LOAD

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• Hauptkonto:
  • Geben Sie mindestens eine Maschinen-ID an (entweder in principal oder target).
  • principal.process: Geben Sie Informationen zum Prozess ein, der das Modul lädt.
• target:
  • target.process: Geben Sie Informationen zum geladenen Modulprozess an, einschließlich mindestens eines der folgenden Elemente: target.process.file (z. B. die DLL oder das freigegebene Objekt) oder target.process.product_specific_process_id.

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität.
• principal.user: Wird ausgefüllt, wenn Nutzerinformationen zum Prozess verfügbar sind.

UDM-Beispiel für PROCESS_MODULE_LOAD

Im folgenden Beispiel wird gezeigt, wie Sie ein PROCESS_MODULE_LOAD-Ereignis mit der Google SecOps-UDM-Syntax formatieren:

{
    "metadata": {
        "event_timestamp": "2023-07-03T20:40:29.854097Z",
        "event_type": "PROCESS_MODULE_LOAD"
    },
    "principal": {
        "hostname": "pinguino-01",
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    },
    "target": {
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    }
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Details zum Gerät und zum Prozess, der das Modul lädt.
• target: Prozess- und Moduldetails.

PROCESS_PRIVILEGE_ESCALATION

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• Hauptkonto:
  • Geben Sie mindestens eine Maschinen-ID an (entweder in principal oder target).
  • principal.process: Geben Sie Informationen zum Prozess an, der die Rechteausweitung initiiert.
  • principal.user: Geben Sie Informationen zum Nutzer an, der die Rechteausweitung initiiert, einschließlich mindestens einer Nutzer-ID.
• target: Geben Sie Informationen zum Ziel der Rechteausweitung ein (z. B. target.process für den Prozess mit ausgeweiteten Rechten). Das Feld „target“ darf nicht leer sein.

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität.

UDM-Beispiel für PROCESS_PRIVILEGE_ESCALATION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ PROCESS_PRIVILEGE_ESCALATION für das Google SecOps-UDM formatiert wird:

{
    "metadata": {
        "event_timestamp": "2023-07-04T19:04:12.573338Z",
        "event_type": "PROCESS_PRIVILEGE_ESCALATION"
    },
    "principal": {
        "user": {
            "userid": "pinguino"
        },
        "hostname": "pinguino-01",
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    },
    "target": {
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    }
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Details zum Gerät, zum Nutzer und zum Prozess, der die Eskalation initiiert.
• target: Details zum eskalierten Prozess.

REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION, REGISTRY_UNCATEGORIZED

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• Hauptkonto:
  • Mindestens eine Maschinenkennung.
  • Wenn ein Prozess im Nutzermodus die Registrierung ändert, muss principal.process Informationen über den Prozess enthalten, der die Registrierung ändert.
  • Wenn ein Kernel-Prozess die Registry-Änderung vornimmt, darf das Hauptkonto keine Prozessinformationen enthalten.
• target:
  • target.registry: Wenn sich die Ziel-Registry auf einem Remote-System befindet, muss das Ziel mindestens eine Kennung für den Zielcomputer enthalten (z. B. eine IP-Adresse, MAC-Adresse, einen Hostnamen oder eine Drittanbieter-Asset-Kennung).
  • target.registry.registry_key: Alle Registry-Ereignisse müssen den betroffenen Registry-Schlüssel enthalten.

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität. Zum Beispiel ein fehlerhafter Registrierungsschlüssel.
• principal.user: Wird ausgefüllt, wenn Nutzerinformationen zum Prozess verfügbar sind.

UDM-Beispiel für REGISTRY_MODIFICATION

Im folgenden Beispiel wird gezeigt, wie Sie ein REGISTRY_MODIFICATION-Ereignis in Proto3 mit der Google SecOps-UDM-Syntax formatieren:

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: REGISTRY_MODIFICATION
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "test-win"
  user {
    userid: "test"
    windows_sid: "ABCDEFGH-123456789-1111111-1000"
  }
  process {
    pid: "0xc45"
    file {
      full_path: "C:\\Windows\\regedit.exe"
    }
  }
}
target {
  registry {
    registry_key: "\\REGISTRY\\USER\\TEST_USER\\Control Panel\\PowerCfg\\PowerPolicy"
    registry_value_name: "Description"
    registry_value_data: "For extending battery life."
  }
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Geräte-, Nutzer- und Prozessdetails.
• target: Registrierungseintrag, der von der Änderung betroffen ist.

INFOMATERIAL

Ereignistypen:

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Minimales UDM-Ereignis:

{
   "metadata": {
       "event_timestamp": "2023-07-04T20:19:53.394745Z",
       "event_type": "RESOURCE_CREATION"
   },
   "principal": {
       "user": {
           "userid": "pinguino"
       }
   },
   "target": {
       "resource": {
           "name": "foo.bar"
       }
   }
}

SCAN_FILE, SCAN_HOST, SCAN_PROCESS, SCAN_VULN_HOST, SCAN_VULN_NETWORK

Für SCAN_FILE:

{
  "metadata": {
    "event_timestamp": "2023-07-06T06:57:08.443142Z",
    "event_type": "SCAN_FILE"
  },
  "principal": {
    "hostname": "pinguino-01"
  },
  "target": {
    "file": {
      "full_path": "foo.bar"
    }
  }
}

Für SCAN_PROCESS:

{
  "metadata": {
    "event_timestamp": "2023-07-06T06:59:17.690425Z",
    "event_type": "SCAN_PROCESS"
  },
  "principal": {
    "hostname": "pinguino-01"
  },
  "target": {
    "process": {
      "file": {
        "full_path": "foo.bar"
      }
    }
  }
}

Pflichtfelder:

• metadata: event_timestamp und Hintergrundinformationen zum Ereignis.
• observer: Erfasst Informationen zum Scanner selbst. Wenn der Scanner remote ist, müssen die Maschinendetails im Feld „Beobachter“ erfasst werden. Lassen Sie das Feld für einen lokalen Scanner leer.
• target: Erfassen Sie Informationen über die Maschine, die das zu scannende Objekt enthält. Wenn eine Datei gescannt wird, muss target.file Informationen zur gescannten Datei erfassen. Wenn ein Prozess gescannt wird, muss target.process Informationen zum gescannten Prozess erfassen.
• extensions: Definieren Sie für SCAN_VULN_HOST und SCAN_VULN_NETWORK die Sicherheitslücke mit dem Feld „extensions.vuln“.

Optionale Felder:

• principal: Steht für das Gerät, das die Verbindung initiiert, und enthält mindestens eine Maschinenkennung (z. B. Hostname, IP-Adresse, MAC-Adresse, proprietäre Asset-ID) oder eine Nutzer-ID.
• target: Nutzerdetails zum Zielobjekt (z. B. Ersteller der Datei oder Prozessinhaber) sollten in target.user erfasst werden.
• security_result: Beschreibt die erkannte schädliche Aktivität.

UDM-Beispiel für SCAN_HOST

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SCAN_HOST für das Google SecOps-UDM formatiert wird:

metadata: {
  event_timestamp: {
    seconds: 1571386978
  }
  event_type: SCAN_HOST
  vendor_name: "vendor"
  product_name: "product"
  product_version: "1.0"
}
target: {
  hostname: "testHost"
  asset_id: "asset"
  ip: "192.168.200.200"
}
observer: {
  hostname: "testObserver"
  ip: "192.168.100.100"
}
security_result: {
  severity: LOW
  confidence: HIGH_CONFIDENCE
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• target: Gerät, das die schädliche Software erhalten hat.
• observer: Gerät, das das betreffende Ereignis beobachtet und meldet.
• security_result: Sicherheitsdetails zur schädlichen Software.

UDM-Beispiel für SCAN_VULN_HOST

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SCAN_VULN_HOST für das Google SecOps-UDM formatiert wird:

metadata: {
  event_timestamp: "2025-05-09T12:59:52.45298Z",
  event_type: 18005,
  product_name: "TestProduct",
  vendor_name: "TestVendor"
  },
principal {
  asset_id: "TEST:Mwl8ABcd",
  ip: "127.0.0.3",
  hostname: "TEST-Localhost",
  mac: ["02:00:00:00:00:01"]
  },
extensions: {
  vulns: {
    vulnerabilities: [
      {
      cve_id: "CVE-6l9VxQmz",
      vendor_vulnerability_id: "TEST:7gmCmFWX",
      name: "CVE pA7DzwPU",
      severity: 2,
      vendor: "TestVendor",
      last_found: "2025-05-09T14:59:52.45300Z",
      first_found: "2025-05-09T13:59:52.45300Z"
       }
      ]
    }
  }

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptkonto: Gerät, das die Malware erhalten hat.
• extensions: Details zur Sicherheitslücke.

SCHEDULED_TASK_CREATION, SCHEDULED_TASK_DELETION, SCHEDULED_TASK_DISABLE, SCHEDULED_TASK_ENABLE, SCHEDULED_TASK_MODIFICATION, SCHEDULED_TASK_UNCATEGORIZED

Pflichtfelder:

• principal: Für alle SCHEDULED_TASK-Ereignisse muss das Hauptkonto eine Maschinen-ID und eine Nutzer-ID enthalten.
• target: Geben Sie ein gültiges target.resource an, wobei target.resource.resource_type auf TASK festgelegt ist.

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität.

UDM-Beispiel für SCHEDULED_TASK_CREATION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SCHEDULED_TASK_CREATION für das Google SecOps-UDM formatiert werden könnte:

metadata: {
  event_timestamp: {
    seconds: 1577577998
  }
  event_type: SCHEDULED_TASK_CREATION
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal: {
  hostname: "fake-host.altostrat.com"
  user: {
    userid: "TestUser"
    windows_sid: "AB123CDE"
  }
  process {
    pid: "1234"
  }
}
target: {
  resource: {
    resource_type: TASK
    name: "\\Adobe Acrobat Update Task"
  }
}
intermediary: {
  hostname: "fake-intermediary.altostrat.com"
}
security_result: {
  rule_name: "EventID: 6789"
  summary: "A scheduled task was created."
  severity: INFORMATIONAL
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Gerät, das die verdächtige Aufgabe geplant hat.
• target: Software, auf die der verdächtige Task abzielt.
• intermediary: Intermediary involved with the suspicious task.
• security_result: Sicherheitsdetails zur verdächtigen Aufgabe.

SETTING_UNCATEGORIZED, SETTING_CREATION, SETTING_MODIFICATION, SETTING_DELETION

Pflichtfelder:

• principal: Muss vorhanden und nicht leer sein und eine Maschinenkennung enthalten.

  Hinweis: Die Einstellung resource.type wurde verworfen. Verwenden Sie resource.resource_type.

• target: Muss vorhanden und nicht leer sein und eine Ressource enthalten, bei der target.resource.resource_type als SETTING angegeben ist.

UDM-Beispiel für den Ereignistyp SETTING_MODIFICATION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SETTING_MODIFICATION für das Google SecOps-UDM formatiert wird:

{
    "metadata": {
        "event_timestamp": "2023-07-05T14:15:27.070909Z",
        "event_type": "SETTING_MODIFICATION"
    },
    "principal": {
        "hostname": "foo.bar"
    },
    "target": {
        "resource": {
            "resource_type": "SETTING",
            "name": "foo.bar"
        }
    }
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Gerät, auf dem die Einstellung geändert wurde.
• target: Details zur Einstellungsressource.

SERVICE_UNSPECIFIED, SERVICE_CREATION, SERVICE_DELETION, SERVICE_MODIFICATION, SERVICE_START, SERVICE_STOP

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder (event_timestamp und event_type) an.
• principal: Geben Sie mindestens eine Maschinenkennung an (principal.hostname, principal.ip, principal.mac oder principal.asset_id).
• target: Geben Sie mindestens target.process oder target.application an.

Optionale Felder:

• target.user: Geben Sie hier Informationen ein, wenn Nutzerinformationen für das Dienstkonto oder den Zielnutzer verfügbar sind.
• target.resource: Geben Sie Details zur Dienstressource ein (z. B. resource_type: SERVICE).

UDM-Beispiel für SERVICE_UNSPECIFIED

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SERVICE_UNSPECIFIED für das Google SecOps-UDM formatiert wird:

metadata: {
 event_timestamp: {
   seconds: 1595656745
   nanos: 832000000
    }
 event_type: SERVICE_UNSPECIFIED
   vendor_name: "Preempt"
   product_name: "PREEMPT_AUTH"
   product_event_type: "SERVICE_ACCESS"
   description: "Remote Procedures (RPC)"
   }
 principal: {
   hostname: "XXX-YYY-ZZZ"
   ip: "10.10.10.10"
   }
 target: {
   hostname: "TestHost"
   user: {
      userid: "ORG\\User"
      user_display_name: "user name"
   }
 application: "application.name"
   resource: {
      resource_type: SERVICE
      name: "RPC"
   }
 }

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptkonto: Geräte- und Standortdetails.
• target: Hostname und Nutzer-ID.
• application: Name der Anwendung und Ressourcentyp.

STATUS_HEARTBEAT, STATUS_STARTUP, STATUS_SHUTDOWN, STATUS_UNCATEGORIZED, STATUS_UPDATE

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• principal: Mindestens eine Maschinen-ID (IP- oder MAC-Adresse, Hostname oder Asset-ID).

UDM-Beispiel für STATUS_HEARTBEAT

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ STATUS_HEARTBEAT für das Google SecOps-UDM formatiert wird:

metadata: {
  event_timestamp: {
    seconds: 1588180305
  }
  event_type: STATUS_HEARTBEAT
  vendor_name: "DMP"
  product_name: "ENTRE"
}
principal: {
  hostname: "testHost"
  location: {
    name: "Building 1"
  }
}
intermediary: {
  ip: "8.8.8.8"
}
security_result: {
  summary: "Event - Locked"
  description: "description"
  severity: LOW
  severity_details: "INFO"
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Geräte- und Standortdetails.
• intermediary: IP-Adresse des Geräts.
• security_result: Details zum Sicherheitsergebnis.

SYSTEM_AUDIT_LOG_UNCATEGORIZED, SYSTEM_AUDIT_LOG_WIPE

Pflichtfelder:

• Hauptkonto: Geben Sie eine Nutzer-ID für den Nutzer an, der den Vorgang für das Protokoll ausgeführt hat, und eine Maschinen-ID für die Maschine, auf der das Protokoll gespeichert ist oder war (im Fall des Löschens).

UDM-Beispiel für SYSTEM_AUDIT_LOG_WIPE

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SYSTEM_AUDIT_LOG_WIPE für das Google SecOps-UDM formatiert wird:

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: SYSTEM_AUDIT_LOG_WIPE
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "altostrat.com"
  user {
    userid: "test"
    windows_sid: "ABCDEFGH-123456789-1111111-1000"
  }
}

Wie in diesem Beispiel gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptkonto: Geräte- und Nutzerdetails.

USER_BADGE_IN

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• target: Muss mindestens eine Maschinen-ID enthalten (z. B. target.hostname).
• extensions: Der Authentifizierungsmechanismus muss in extensions.auth.type angegeben werden.

UDM-Beispiel für USER_BADGE_IN

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ USER_BADGE_IN für das Google SecOps-UDM formatiert wird:

{
    "metadata": {
        "event_timestamp": "2023-07-05T20:31:18.303584Z",
        "event_type": "USER_BADGE_IN"
    },
    "target": {
        "hostname": "jamon-01"
    },
    "extensions": {
        "auth": {
            "type": "MACHINE"
        }
    }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• target: Informationen zum Gerät oder Standort, an dem der Badge-In stattgefunden hat.
• extensions: Details zum verwendeten Authentifizierungsmechanismus.

USER_CHANGE_PASSWORD, USER_CHANGE_PERMISSIONS

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• target: Darf nicht leer sein. Geben Sie in target Informationen zum geänderten Nutzerkonto (target.user) oder zum Zielcomputer, zur Anwendung oder zur Ressource ein, auf dem bzw. der die Änderung vorgenommen wurde.
• target.user oder principal.user: Geben Sie für mindestens eines der Felder target.user (das geänderte Nutzerkonto) oder principal.user (der Nutzer, der die Änderung initiiert hat) eine Nutzer-ID (userid, windows_sid, email_addresses oder employee_id) an.

Optionale Felder:

• principal: Wenn Sie die Nutzer-ID in target.user angeben, ist principal.user optional. Wenn das Nutzerkonto von einem Remote-Standort aus geändert wird, füllen Sie principal mit Informationen über den Computer, von dem die Änderung stammt.
• intermediary: Bei SSO-Anmeldungen muss intermediary mindestens eine Maschinenkennung für den SSO-Server enthalten, falls verfügbar.

USER_COMMUNICATION

Pflichtfelder:

• principal: Füllen Sie das Feld principal.user mit Details zu einer vom Nutzer (Absender) initiierten Kommunikation aus, z. B. einer Chatnachricht in Google Chat oder Slack, einer Video- oder Audiokonferenz in Zoom oder Google Meet oder einer VoIP-Verbindung.

Optionale Felder:

• target: (Empfohlen) Füllen Sie das Feld target.user mit Informationen zum Zielnutzer (Empfänger) der Cloud-Kommunikationsressource. Füllen Sie das Feld target.application mit Informationen zur Ziel-Cloud-Kommunikationsanwendung aus.

USER_CREATION, USER_DELETION

Pflichtfelder:

• metadata: Schließen Sie event_timestamp und event_type ein.
• principal: Geben Sie mindestens eine gültige Nutzer-ID in principal.user (userid, windows_sid, email_addresses oder employee_id, bis zu 256 Zeichen) für das Konto an, das die Erstellung oder Löschung initiiert hat. Wenn target.application nicht festgelegt ist, muss principal auch mindestens eine Maschinenkennung (hostname, ip, mac oder asset_id) enthalten.
• target: Geben Sie in target.user mindestens eine gültige Nutzer-ID (bis zu 256 Zeichen) für das Nutzerkonto an, das erstellt oder gelöscht wird. Wenn principal keine Maschinenkennung enthält, füllen Sie target.application aus.

Optionale Felder:

• principal.process: Prozessdetails für den Computer, auf dem die Anfrage zum Erstellen oder Löschen des Nutzers initiiert wurde.
• target: Informationen zur Zielmaschine (falls sie sich von der Hauptmaschine unterscheidet).

USER_LOGIN, USER_LOGOUT

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• principal: Geben Sie für Remote-Nutzeraktivitäten (z. B. Remote-Anmeldung) Informationen zum Computer an, von dem die Nutzeraktivität stammt. Legen Sie für lokale Nutzeraktivitäten (z. B. lokale Anmeldung) kein Hauptkonto fest.
• target: Füllen Sie target.user mit Informationen über den Nutzer, der sich an- oder abgemeldet hat. Wenn „principal“ nicht festgelegt ist (z. B. lokale Anmeldung), muss „target“ auch mindestens eine Maschinenkennung enthalten, die die Zielmaschine identifiziert. Bei Nutzeraktivitäten zwischen Maschinen (z. B. Remote-Anmeldung, SSO, Cloud-Dienst, VPN) muss das Ziel Informationen zur Zielanwendung, zur Zielmaschine oder zum Ziel-VPN-Server enthalten.
• intermediary: Bei SSO-Anmeldungen muss „intermediary“ mindestens eine Maschinen-ID für den SSO-Server enthalten, falls verfügbar.
• network und network.http: Wenn die Anmeldung über HTTP erfolgt, müssen Sie alle verfügbaren Details in network.ip_protocol, network.application_protocol und network.http platzieren.
• authentication-Erweiterung: Muss den Typ des Authentifizierungssystems, auf das sich das Ereignis bezieht (z. B. Computer, SSO oder VPN), und den verwendeten Mechanismus (Nutzername und Passwort, OTP usw.) angeben.
• security_result: Fügen Sie ein Feld „security_result“ hinzu, um den Anmeldestatus darzustellen, wenn die Anmeldung fehlschlägt. Geben Sie „security_result.category“ mit dem Wert AUTH_VIOLATION an, wenn die Authentifizierung fehlschlägt.

UDM-Beispiel für USER_LOGIN

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ USER_LOGIN für das Google SecOps-UDM formatiert wird:

{
    "metadata": {
        "event_timestamp": "2023-07-05T20:48:50.657334Z",
        "event_type": "USER_LOGIN"
    },
    "target": {
        "user": {
            "userid": "jamon"
        }
    },
    "extensions": {
        "auth": {
            "type": "MACHINE"
        }
    }
}

Wie in diesem Beispiel gezeigt, ist das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• target: Informationen zum Nutzer, der sich anmeldet.
• extensions: Details zum verwendeten Authentifizierungsmechanismus.

USER_RESOURCE_ACCESS

Pflichtfelder:

• principal: Füllen Sie das Feld principal.user mit Details zu Versuchen, auf eine Cloud-Ressource zuzugreifen (z. B. einen Salesforce-Fall, einen Office365-Kalender, ein Google-Dokument oder ein ServiceNow-Ticket).
• target: Füllen Sie das Feld target.resource mit Informationen zur Ziel-Cloud-Ressource aus.

Optionale Felder:

• target.application: (Empfohlen) Füllen Sie das Feld target.application mit Informationen zur Ziel-Cloud-Anwendung aus.

USER_RESOURCE_CREATION, USER_RESOURCE_DELETION

Pflichtfelder:

• principal: Füllen Sie das Feld principal.user mit Details aus, die mit dem Nutzer verknüpft sind, der in einer Cloud-Ressource erstellt wurde (z. B. Salesforce-Fall, Office 365-Kalender, Google-Dokument oder ServiceNow-Ticket).
• target: Füllen Sie das Feld target.resource mit Informationen zur Ziel-Cloud-Ressource aus.

Optionale Felder:

• target.application: (Empfohlen) Füllen Sie das Feld target.application mit Informationen zur Ziel-Cloud-Anwendung aus.

USER_RESOURCE_UPDATE_CONTENT

Pflichtfelder:

• principal: Füllen Sie das Feld principal.user mit Details zum Nutzer aus, dessen Inhalte in einer Cloud-Ressource aktualisiert wurden (z. B. ein Salesforce-Fall, ein Office365-Kalender, ein Google-Dokument oder ein ServiceNow-Ticket).
• target: Füllen Sie das Feld target.resource mit Informationen zur Ziel-Cloud-Ressource aus.

Optionale Felder:

• target.application: (Empfohlen) Füllen Sie das Feld target.application mit Informationen zur Ziel-Cloud-Anwendung aus.

USER_RESOURCE_UPDATE_PERMISSIONS

Pflichtfelder:

• principal: Füllen Sie das Feld principal.user mit Details zum Nutzer aus, dessen Berechtigungen in einer Cloud-Ressource aktualisiert wurden (z. B. Salesforce-Anfrage, Office 365-Kalender, Google-Dokument oder ServiceNow-Ticket).
• target: Füllen Sie das Feld target.resource mit Informationen zur Ziel-Cloud-Ressource aus.

Optionale Felder:

• target.application: (Empfohlen) Füllen Sie das Feld target.application mit Informationen zur Ziel-Cloud-Anwendung aus.

USER_UNCATEGORIZED

Pflichtfelder:

• metadata: Schließen Sie event_timestamp und event_type ein.
• principal oder target:
  • Wenn target nicht ausgefüllt ist, muss principal mindestens eine gültige Nutzer-ID in principal.user (userid, windows_sid, email_addresses oder employee_id, bis zu 256 Zeichen) oder mindestens eine Maschinen-ID (hostname, ip, mac oder asset_id) enthalten.
  • Wenn target ausgefüllt ist, müssen Sie mindestens eine der folgenden Angaben machen: eine Nutzer-ID in target.user, eine Maschinen-ID in target oder eine gültige Nutzer-ID in principal.user.

Optionale Felder:

• principal.process: Prozessdetails, die mit der Nutzeraktivität verknüpft sind.
• security_result: Beschreibt alle erkannten schädlichen oder anomalen Aktivitäten.

Hinweis: USER_STATS wurde eingestellt.