UDM-Nutzungsleitfaden

Dieses Dokument enthält Folgendes:

• Detaillierte Beschreibungen der Schemafelder für das einheitliche Datenmodell (UDM)
• Pflicht- und optionale Felder für Entitätstypen
• Erforderliche und optionale Felder für die einzelnen Ereignistypen

Weitere Informationen zu bestimmten UDM-Feldern (z. B. Enumerationsnummern) finden Sie in der Liste der Felder für einheitliche Datenmodelle.

Formate für UDM-Feldnamen:

• Für die Auswertung der Rules Engine beginnt das Präfix mit udm.
• Für den konfigurationsbasierten Normalizer (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 den einzelnen Ereignissen gespeichert.

Metadata.event_type

• Zweck: Gibt den Typ des Ereignisses an. Wenn ein Ereignis mehrere mögliche Typen hat, muss mit diesem Wert der spezifischste Typ angegeben werden.
• Erforderlich: Ja.
• Codierung: Muss einer der vordefinierten UDM-Aufzählungstypen für „event_type“ sein.
• Mögliche Werte: In den folgenden Listen sind alle möglichen Werte für „event_type“ im UDM aufgeführt.

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

• DEVICE_CONFIG_UPDATE
• DEVICE_FIRMWARE_UPDATE
• DEVICE_PROGRAM_DOWNLOAD
• DEVICE_PROGRAM_UPLOAD

E-Mail-Ereignisse

• EMAIL_UNCATEGORIZED
• EMAIL_TRANSACTION
• EMAIL_URL_CLICK

Ereignisse ohne Angabe

• EVENTTYPE_UNSPECIFIED

Dateiaktionen, 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 Windows-Ereignisse:

• GENERIC_EVENT

Ereignisse zu Gruppenaktivitäten

• GROUP_UNCATEGORIZED
• GROUP_CREATION
• GROUP_DELETION
• GROUP_MODIFICATION

Mutex-Ereignisse

• MUTEX_UNCATEGORIZED
• MUTEX_CREATION

Netzwerktelemetrieereignisse

Netzwerk-Telemetrieereignisse, die Rohprotokoll-Nutzlasten wie DHCP und DNS sowie Protokollzusammenfassungen für Protokolle wie HTTP, SMTP und FTP und Fluss- und Verbindungsereignisse aus NetFlow und Firewalls enthalten:

• NETWORK_UNCATEGORIZED
• NETWORK_CONNECTION (z. B. Details zur Netzwerkverbindung aus einer Firewall)
• NETWORK_DHCP
• NETWORK_DNS
• NETWORK_FLOW (z. B. aggregierte Flow-Statistiken aus 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 etwas Schädlichem 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 der Festplatte:

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

Registry-Ereignisse

Verwenden Sie die folgenden REGISTRY-Ereignisse anstelle der SETTING-Ereignisse, wenn Sie es mit Microsoft Windows-spezifischen Registrierungsereignissen zu tun haben:

• REGISTRY_UNCATEGORIZED
• REGISTRY_CREATION
• REGISTRY_MODIFICATION
• REGISTRY_DELETION

Ressourcenereignisse

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Scanorientierte Ereignisse

Scanorientierte Ereignisse umfassen On-Demand-Scans und Verhaltenserkennungen, die von Endpunktsicherheitsprodukten (EDR, AV, DLP) durchgeführt werden. Sie werden nur verwendet, wenn ein SecurityResult an einen anderen Ereignistyp (z. B. PROCESS_LAUNCH) angehängt wird.

Scanorientierte Ereignisse:

• SCAN_UNCATEGORIZED
• SCAN_FILE
• SCAN_HOST
• SCAN_NETWORK
• SCAN_PROCESS
• SCAN_PROCESS_BEHAVIORS
• 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

Serviceereignisse

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

Ereignisse festlegen

Informationen zum Festlegen von Ereignisanforderungen finden Sie unter Einstellungen – Pflichtfelder.

Ereignisse zu Einstellungen, einschließlich Änderungen an Systemeinstellungen auf einem Endpunkt:

• SETTING_UNCATEGORIZED
• SETTING_CREATION
• SETTING_DELETION
• SETTING_MODIFICATION

Statusmeldungen von Sicherheitsprodukten

Statusmeldungen von Sicherheitsprodukten, um anzugeben, dass Agents aktiv sind, und um Versions-, Fingerprint- oder andere Datentypen zu 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 ein Nutzer sich physisch 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

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 für Menschen lesbare Beschreibung des Ereignisses.
• Codierung: Alphanumerischer String, Satzzeichen zulässig, maximal 1.024 Byte
• Beispiel: Die Datei „c:\bar\foo.exe“ wird daran gehindert, auf das vertrauliche Dokument „c:\documents\earnings.docx“ zuzugreifen.

Metadata.product_event_type

• Zweck: Kurzer, beschreibender, menschenlesbarer und produktspezifischer Ereignisname oder -typ.
• Codierung: Alphanumerischer String, Satzzeichen zulässig, maximal 64 Byte.
• Beispiele:
  • Ereignis zum Erstellen der Registry
  • 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: Groß-/Kleinschreibung wird berücksichtigt, alphanumerischer String, Satzzeichen sind zulässig, maximal 256 Byte.
• Beispiel: ABcd1234-98766

Metadata.product_name

• Zweck: Gibt den Namen des Produkts an.
• Codierung: Groß-/Kleinschreibung wird berücksichtigt, alphanumerischer String, Satzzeichen sind 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 sind zulässig, maximal 32 Byte
• Beispiele:
  • 1.2.3b
  • 10.3:rev1

Metadata.url_back_to_product

• Zweck: URL, die zu einer relevanten Website führt, auf der Sie weitere Informationen zu diesem bestimmten Ereignis (oder der allgemeinen Ereigniskategorie) aufrufen können.
• Codierung: Gültige RFC 3986-URL mit optionalen Parametern wie Portinformationen usw. Muss ein Protokollpräfix vor der URL haben (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: Groß-/Kleinschreibung wird berücksichtigt, alphanumerischer String, Satzzeichen zulässig, maximal 256 Byte
• Beispiele:
  • CrowdStrike
  • Symantec

Population von Noun-Metadaten

In diesem Abschnitt ist das Wort Substantiv ein Oberbegriff für die Entitäten principal, src, target, intermediary, observer und about. Diese Einheiten haben gemeinsame Attribute, stellen aber unterschiedliche Objekte in einem Ereignis dar. Weitere Informationen zu Entitäten und dazu, was die einzelnen Entitäten in einem Ereignis darstellen, finden Sie unter Logdaten als UDM 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 mit der dieses eindeutige Gerät im Laufe der Zeit verfolgt wird).
• Codierung: (VendorName oder VendorAbbreviation):ID, wobei VendorName oder VendorAbbreviation ein nicht case-sensitiver Anbietername wie Carbon Black oder CB ist und ID eine anbieterspezifische Kunden-ID ist, die in der Umgebung des Kunden 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 kann 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 Metadaten von Dateien.

Noun.hostname

• Zweck: Feld für Client-Hostname oder ‑Domainname. Nicht angeben, wenn eine URL vorhanden ist.
• Codierung: Gültiger RFC 1123-Hostname.
• Beispiele:
  • userwin10
  • www.altostrat.com

Noun.platform

• Zweck: Betriebssystem der Plattform.
• Codierung: Aufzählung
• 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: Version des Betriebssystems 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.

Noun.ip

• Zweck:
  • Einzelne IP-Adresse, die mit einer Netzwerkverbindung verknüpft ist.
  • Eine oder mehrere IP-Adressen, die zum Zeitpunkt des Ereignisses mit einem Teilnehmergerät verknüpft sind. Wenn ein EDR-Produkt beispielsweise alle IP-Adressen kennt, die mit einem Gerät verknüpft sind, kann es alle diese in IP-Feldern codieren.
• Codierung: Gültige IPv4- oder IPv6-Adresse (RFC 5942), die in ASCII codiert ist.
• Wiederholbarkeit:
  • Wenn ein Ereignis eine bestimmte Netzwerkverbindung beschreibt (z. B. srcip:srcport > dstip:dstport), muss der Anbieter nur eine einzelne IP-Adresse angeben.
  • Wenn ein Ereignis allgemeine Aktivitäten auf einem Teilnehmergerät beschreibt, aber keine bestimmte Netzwerkverbindung, kann der Anbieter 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 Zielnetzwerkportnummer, wenn in einem Ereignis eine bestimmte Netzwerkverbindung beschrieben wird.
• Codierung: Gültige TCP/IP-Portnummer zwischen 1 und 65.535.

• Beispiele:

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

Noun.mac

• Zweck: Eine oder mehrere MAC-Adressen, die einem Gerät zugeordnet sind.
• Codierung: Gültige MAC-Adresse (EUI-48) in ASCII.
• Wiederholbarkeit: Der Anbieter stellt möglicherweise alle zugehörigen MAC-Adressen für das Gerät zum Zeitpunkt des Ereignisses bereit.
• 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 Domainnamestring (maximal 128 Zeichen).
• Beispiel: corp.altostrat.com

Noun.registry

• Zweck: Detaillierte Registry-Metadaten.
• Typ: Objekt
• Weitere Informationen finden Sie unter Registry-Metadaten.

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.

Authentifizierungsmetadaten

Authentication.AuthType

• Zweck: Typ des Systems, dem ein Authentifizierungsereignis zugeordnet ist (Google Security Operations UDM).
• Codierung: Aufzählbarer Typ.
• Mögliche Werte:
  • AUTHTYPE_UNSPECIFIED
  • MACHINE: Maschinenauthentifizierung
  • PHYSISCH: Physische Authentifizierung (z. B. ein Lesegerät für Ausweise)
  • SSO, die
  • TACACS: Protokoll der TACACS-Familie zur Authentifizierung von vernetzten Systemen (z. B. TACACS oder TACACS+)
  • VPN

Authentication.Authentication_Status

• Zweck: Beschreibt den Authentifizierungsstatus eines Nutzers oder einer bestimmten Anmeldedaten.
• Codierung: Aufzählbarer Typ.
• Mögliche Werte:
  • UNKNOWN_AUTHENTICATION_STATUS: Standardauthentifizierungsstatus
  • AKTIV: Die Authentifizierungsmethode ist aktiv.
  • SUSPENDED: Die Authentifizierungsmethode ist gesperrt oder deaktiviert.
  • GELÖSCHT: Die Authentifizierungsmethode wurde gelöscht.
  • NO_ACTIVE_CREDENTIALS: Für die Authentifizierungsmethode sind keine aktiven Anmeldedaten vorhanden.

Authentication.auth_details

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

Authentication.Mechanism

• Zweck: Für die Authentifizierung verwendete Mechanismen.
• Codierung: Aufzählbarer Typ.
• Mögliche Werte:
  • MECHANISM_UNSPECIFIED: Standardauthentifizierungsmechanismus.
  • BADGE_READER
  • BATCH: Batch-Authentifizierung.
  • CACHED_INTERACTIVE: Interaktive Authentifizierung mit zwischengespeicherten Anmeldedaten.
  • HARDWARE_KEY
  • LOKAL
  • MECHANISM_OTHER: Ein anderer Mechanismus, der hier nicht definiert ist.
  • NETWORK: Netzwerkauthentifizierung.
  • NETWORK_CLEAR_TEXT: Netzwerkauthentifizierung im Klartext.
  • NEW_CREDENTIALS: Authentifizierung mit neuen Anmeldedaten.
  • OTP
  • REMOTE: Remote-Authentifizierung
  • REMOTE_INTERACTIVE: RDP, Terminaldienste, Virtual Network Computing (VNC) usw.
  • SERVICE: Dienstauthentifizierung.
  • UNLOCK: Direkte interaktive Authentifizierung zum Entsperren.
  • USERNAME_PASSWORD

DHCP-Metadaten

In den Metadatenfeldern des 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.
• Codierung: String.

Dhcp.client_identifier

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

Dhcp.file

• Zweck: Dateiname für das Boot-Image.
• Codierung: 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: Aufzählbarer 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), die in ASCII codiert ist.

Dhcp.seconds

• Zweck: Sekunden seit Beginn des Prozesses zum Abrufen oder Erneuern der Adresse durch den Client.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.sname

• Zweck: Name des Servers, von dem der Client den Start angefordert hat.
• Codierung: 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: Aufzählbarer Typ.
• Mögliche Werte:
  • UNKNOWN_MESSAGE_TYPE
  • ENTDECKEN
  • Angebot
  • ANFRAGE
  • Ablehnen
  • ACK
  • NAK
  • RELEASE
  • INFORM
  • WIN_DELECTED
  • WIN_EXPIRED

Dhcp.chaddr

• Zweck: Hardwareadresse für den Client.
• Codierung: MAC-Adresse.

Dhcp.ciaddr

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

Dhcp.giaddr

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

Dhcp.siaddr

• Zweck: IP-Adresse des nächsten Bootstrap-Servers.
• Codierung: Gültige IPv4- oder IPv6-Adresse (RFC 5942), die in ASCII codiert ist.

Dhcp.yiaddr

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

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 in RFC 1533, DHCP Options and BOOTP Vendor Extensions.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Option.data

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

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: Auf „true“ für autoritative DNS-Server festgelegt.
• Encoding: Boolesch.

Dns.id

• Zweck: Speichert die Kennung der DNS-Abfrage.
• 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 zum Angeben des Typs der DNS-Abfrage verwendet wird (Standard, Inverse, Serverstatus usw.).
• Codierung: 32-Bit-Ganzzahl.

Dns.recursion_available

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

Dns.recursion_desired

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

Dns.response_code

• Zweck: Speichert den DNS-Antwortcode gemäß RFC 1035, Domain Names – Implementation and Specification.
• Codierung: 32-Bit-Ganzzahl.

Dns.truncated

• Zweck: Auf „true“ gesetzt, wenn es sich um eine gekürzte DNS-Antwort handelt.
• Encoding: Boolesch.

Dns.questions

• Zweck: Speichert die Fragen zu Nachrichten des Domainprotokolls. Weitere Informationen finden Sie unter Metadaten für DNS-Fragen.

Dns.answers

• Zweck: Speichert die Antwort auf die Domainnamenabfrage. Weitere Informationen finden Sie unter Metadaten von DNS-Ressourceneinträgen.

Dns.authority

• Zweck: Speichert die Domain-Nameserver, die die Antwort auf die Domainnamenanfrage bestätigt haben. Weitere Informationen finden Sie unter Metadaten von DNS-Ressourceneinträgen.

Dns.additional

• Zweck: Speichert die zusätzlichen Domain-Nameserver, die zum Bestätigen der Antwort auf die Domain verwendet werden können. Weitere Informationen finden Sie unter Metadaten von DNS-Ressourceneinträgen.

Metadaten für DNS-Fragen

In den Metadatenfeldern für DNS-Anfragen werden die Informationen erfasst, die im Abschnitt „Frage“ einer Domainprotokollnachricht enthalten sind.

Question.name

• Zweck: Speichert den Domainnamen.
• Codierung: String.

Question.class

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

Question.type

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

Metadaten von DNS-Ressourceneinträgen

Die Metadatenfelder für DNS-Ressourceneinträge erfassen die Informationen, die im Ressourceneintrag einer Domainprotokollnachricht enthalten sind.

ResourceRecord.binary_data

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

• Codierung: Bytes.

  Hinweis :Dieses Feld ist nicht in RFC 1035 angegeben (im Gegensatz zu den anderen DNS-Ressourceneinträgen), sondern wurde von Google SecOps für die 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-Anfrage für alle Antworten, die im UTF-8-Format codiert sind. Das Datenfeld könnte beispielsweise die IP-Adresse des Computers zurückgeben, auf den sich der Domainname bezieht. Wenn der Ressourcendatensatz 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 so gespeichert werden, wie sie in der DNS-Antwort enthalten sind.
• Codierung: String.

ResourceRecord.name

• Zweck: Hier wird der Name des Inhabers des Ressourceneintrags gespeichert.
• Codierung: String.

ResourceRecord.ttl

• Zweck: Speichert das Zeitintervall, für das der Ressourcendatensatz im Cache gespeichert werden kann, bevor die Quelle der Informationen wieder abgefragt werden sollte.
• Codierung: 32-Bit-Ganzzahl.

ResourceRecord.type

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

Bevölkerung von E-Mail-Metadaten

In den meisten E-Mail-Metadatenfeldern werden die im Nachrichtenheader enthaltenen E-Mail-Adressen erfasst. Diese sollten dem in RFC 5322 definierten Standardformat für E-Mail-Adressen (lokales-postfach@domain) entsprechen. Zum Beispiel: [e-mail].

Email.from

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

Email.reply_to

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

Email.to

• Zweck: Speichert die An-E-Mail-Adressen.
• Codierung: String.

Email.cc

• Zweck: Speichert die CC-E-Mail-Adressen.
• Codierung: String.

Email.bcc

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

Email.mail_id

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

Email.subject

• Zweck: Speichert den Betreff der E-Mail.
• Codierung: String.
• Beispiel: „Bitte lies diese Nachricht.“

Metadaten für Erweiterungen

Ereignistypen mit integrierten Metadaten, die noch nicht von der Google SecOps UDM kategorisiert wurden.

Extensions.auth

• Zweck: Erweiterung der Authentifizierungsmetadaten.
• Codierung: 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 zur besseren Nutzbarkeit und zur Kompatibilität von Regeln für verschiedene Datasets weiterhin in auth.type oder auth.mechanism verallgemeinert werden.
• Codierung: String.
• Beispiele: via_mfa, via_ad.

Extensions.vulns

• Zweck: Erweiterung der Metadaten zur Sicherheitslücke.
• Codierung: String.
• Beispiel: Daten aus dem Host-Scan auf Sicherheitslücken.

Dateimetadaten

File.file_metadata

• Zweck: Metadaten, die mit der Datei verknüpft sind.
• Codierung: String.
• Beispiele:
  • Autor
  • Versionsnummer
  • Versionsnummer
  • Datum der letzten Speicherung

File.full_path

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

File.md5

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

File.mime_type

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

File.sha1

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

File.sha256

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

File.size

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

FTP-Metadaten

Ftp.command

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

Bevölkerung von Gruppenmetadaten

Informationen zu einer Organisationsgruppe.

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.
• Codierung: String.
• Beispiele:
  • Finanzen
  • HR
  • Marketing

Group.product_object_id

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

Group.windows_sid

• Zweck: Gruppenattributfeld für die Microsoft Windows-Sicherheits-ID (SID).
• Codierung: String.

HTTP-Metadaten

Http.method

• Zweck: Speichert die HTTP-Anfragemethode.
• Codierung: 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.
• Codierung: String.
• Beispiele:
  • Mozilla/5.0 (X11; Linux x86_64)
  • AppleWebKit/534.26 (KHTML, like Gecko)
  • Chrome/41.0.2217.0
  • Safari/527.33

Bevölkerung von Standortmetadaten

Location.city

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

Location.country_or_region

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

Location.name

• Zweck: Speichert den unternehmensspezifischen Namen, z. B. eines Gebäudes oder Campus.
• Codierung: String.
• Beispiele:
  • Campus 7B
  • Gebäude A2

Location.state

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

Netzwerkmetadaten

Network.application_protocol

• Zweck: Gibt das Netzwerk-Anwendungsprotokoll an.
• Codierung: Aufzählbarer 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: Aufzählbarer Typ.
• Mögliche Werte:
  • UNKNOWN_DIRECTION
  • INBOUND
  • OUTBOUND
  • BROADCAST

Network.email

• Zweck: Gibt die E-Mail-Adresse für den Absender/Empfänger an.
• Codierung: String.
• Beispiel: [e-mail]

Network.ip_protocol

• Zweck: Gibt das IP-Protokoll an.
• Codierung: Aufzählbarer Typ.
• Mögliche Werte:
  • UNKNOWN_IP_PROTOCOL
  • EIGRP – Enhanced Interior Gateway Routing Protocol
  • ESP – Encapsulating Security Payload
  • ETHERIP – Ethernet-in-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. Um die Dauer festzulegen, können Sie entweder „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 Netzwerk-Sitzungs-ID.
• Codierung: String.
• Beispiel: SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-01:34

Prozessmetadaten

Process.command_line

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

Process.product_specific_process_id

• Zweck: Speichert die produktspezifische Prozess-ID.
• Codierung: 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.
• Codierung: String.
• Beispiele: MySQL:78778 oder CS:90512

Process.file

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

Process.parent_process

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

Process.pid

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

Bevölkerung von Registry-Metadaten

Registry.registry_key

• Zweck: Speichert den Registrierungsschlüssel, der mit einer Anwendung oder Systemkomponente verknüpft ist.
• Codierung: 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.
• Codierung: String.
• Beispiel: TEMP

Registry.registry_value_data

• Zweck: Speichert die Daten, die einem Registrierungswert zugeordnet sind.
• Codierung: String.
• Beispiel: %USERPROFILE%\Local Settings\Temp

Sicherheitsergebnis-Metadaten

Die Metadaten des Sicherheitsergebnisses enthalten Details zu Sicherheitsrisiken und ‑bedrohungen, die von einem Sicherheitssystem gefunden wurden, sowie zu den Maßnahmen, die zur Minderung 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: Aufzählbarer Typ.
• Mögliche Werte: Im Google SecOps UDM werden die folgenden Sicherheitsaktionen definiert:
  • ZULASSEN
  • ALLOW_WITH_MODIFICATION: Die Datei oder E‑Mail wurde bereinigt oder neu geschrieben und wird trotzdem weitergeleitet.
  • BLOCKIEREN
  • QUARANTINE: Für die spätere Analyse speichern (bedeutet nicht blockieren).
  • UNKNOWN_ACTION

SecurityResult.action_details

• Zweck: Vom Anbieter bereitgestellte Details zu den Maßnahmen, die als Reaktion auf den Sicherheitsvorfall 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 vom Anbieter bereitgestellte Beschreibung der Aktion schreiben.
• Codierung: String.
• Beispiele: drop, block, decrypt, encrypt.

SecurityResult.category

• Zweck: Geben Sie eine Sicherheitskategorie an.
• Codierung: Aufzählung.
• Mögliche Werte: In Google SecOps UDM werden die folgenden Sicherheitskategorien definiert:
  • ACL_VIOLATION: Es wurde versucht, unbefugt auf Dateien, Webservices, 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 im Ruhezustand gefunden wurden.
  • DATA_DESTRUCTION: Versuch, Daten zu vernichten oder zu löschen.
  • DATA_EXFILTRATION – DLP: Übertragung von Sensordaten, Kopieren auf USB-Laufwerk.
  • EXPLOIT: Versuchte Pufferüberläufe, fehlerhafte Protokollcodierungen, ROP, SQL-Injection usw., sowohl netzwerk- als auch hostbasiert.
  • MAIL_PHISHING: Phishing-E‑Mail, Chatnachrichten usw.
  • MAIL_SPAM: Spam-E‑Mail, ‑Nachricht usw.
  • MAIL_SPOOFING: Gefälschte E-Mail-Adresse des Absenders usw.
  • NETWORK_CATEGORIZED_CONTENT
  • NETWORK_COMMAND_AND_CONTROL: Gibt an, ob der Command-and-Control-Channel bekannt ist.
  • NETWORK_DENIAL_OF_SERVICE
  • NETWORK_MALICIOUS: Command-and-Control-Server, Netzwerk-Exploit, verdächtige Aktivität, potenzieller Reverse-Tunnel usw.
  • NETWORK_SUSPICIOUS: Nicht sicherheitsbezogen, z. B. ist die URL mit Glücksspiel verknüpft.
  • NETWORK_RECON: Ein Portscan wurde von einem IDS erkannt, der von einer Webanwendung ausgeführt wurde.
  • POLICY_VIOLATION: Verstoß gegen die Sicherheitsrichtlinie, 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 wie Adware usw.
  • SOFTWARE_SUSPICIOUS
  • UNKNOWN_CATEGORY

SecurityResult.confidence

• Zweck: Gibt die Konfidenz in Bezug auf ein Sicherheitsereignis an, das vom Produkt geschätzt wird.
• Codierung: Aufzählung.
• Mögliche Werte: In Google SecOps UDM werden die folgenden Kategorien für die Produktzuverlässigkeit 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.
• Codierung: String.

SecurityResult.priority

• Zweck: Geben Sie eine Priorität in Bezug auf ein Sicherheitsereignis an, die vom Produktanbieter geschätzt wird.
• Codierung: Aufzählung.
• Mögliche Werte: Im UDM von Google SecOps werden die folgenden Produktprioritätskategorien definiert:
  • UNKNOWN_PRIORITY
  • LOW_PRIORITY
  • MEDIUM_PRIORITY
  • HIGH_PRIORITY

SecurityResult.priority_details

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

SecurityResult.rule_id

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

SecurityResult.rule_name

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

SecurityResult.severity

• Zweck: Schweregrad eines Sicherheitsereignisses, das vom Produktanbieter anhand von Werten geschätzt wird, die vom Google SecOps UDM definiert werden.
• Codierung: Aufzählung.
• Mögliche Werte: In Google SecOps UDM werden die folgenden Produkt-Schweregrade definiert:
  • UNKNOWN_SEVERITY – Nicht schädlich
  • INFORMATIONELL – Nicht schädlich
  • FEHLER – nicht schädlich
  • NIEDRIG – BÖSWILLIG
  • MITTEL – Bösartig
  • HOCH – Bösartig

SecurityResult.severity_details

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

SecurityResult.threat_name

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

SecurityResult.url_back_to_product

• Zweck: URL, die Sie zur Quellproduktkonsole für dieses Sicherheitsereignis weiterleitet.
• Codierung: String.

Nutzermetadaten

User.email_addresses

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

User.employee_id

• Zweck: Speichert die Mitarbeiter-ID für das Personalwesen für den Nutzer.
• Codierung: String.
• Beispiel: 11223344.

User.first_name

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

User.middle_name

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

User.last_name

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

User.group_identifiers

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

User.phone_numbers

• Zweck: Speichert die Telefonnummern für den Nutzer.
• Encoding: Wiederholter String.
• Beispiel: 800-555-0101

User.title

• Zweck: Speichert den Jobtitel für den Nutzer.
• Codierung: String.
• Beispiel: Customer-Relationship-Manager.

User.user_display_name

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

User.userid

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

User.windows_sid

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

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. Metadaten für Substantive
• Beispiel: executable.

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-Attribute der Sicherheitslücke. Ein CVSS-Wert setzt sich aus den folgenden Messwerten zusammen:

  • Angriffsvektor (AV)
  • Access Complexity (AC, Komplexität des Zugriffs)
  • 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.

• Codierung: 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.
• Codierung: String.
• Beispiel: 3.1

Vulnerability.description

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

Vulnerability.first_found

• Zweck: Bei Produkten, in denen der Verlauf von Sicherheitslückenscans gespeichert wird, sollte „first_found“ mit dem Zeitpunkt gefüllt werden, zu dem die Sicherheitslücke für diesen Asset zum ersten Mal erkannt wurde.
• Codierung: String.

Vulnerability.last_found

• Zweck: Bei Produkten, für die ein Verlauf von Sicherheitslückenscans geführt wird, sollte „last_found“ mit dem Zeitpunkt gefüllt werden, zu dem die Sicherheitslücke für dieses Asset zuletzt erkannt wurde.
• Codierung: String.

Vulnerability.name

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

Vulnerability.scan_end_time

• Zweck: Wenn die Sicherheitslücke bei einem Asset-Scan erkannt wurde, geben Sie in diesem Feld die Uhrzeit an, zu der der Scan beendet wurde. Lassen Sie dieses Feld leer, wenn die Endzeit nicht verfügbar oder nicht anwendbar ist.
• Codierung: String.

Vulnerability.scan_start_time

• Zweck: Wenn die Sicherheitslücke bei einem Asset-Scan erkannt wurde, geben Sie in diesem Feld die Startzeit des Scans an. Lassen Sie dieses Feld leer, wenn die Startzeit nicht verfügbar oder nicht anwendbar ist.
• Codierung: String.

Vulnerability.severity

• Zweck: Schweregrad der Sicherheitslücke.
• Codierung: Aufzählbarer Typ.
• Mögliche Werte:
  • UNKNOWN_SEVERITY
  • LOW
  • MEDIUM
  • HOCH

Vulnerability.severity_details

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

Metadaten für Benachrichtigungen werden ausgefüllt

Achtung :Diese Felder sind veraltet. Verwenden Sie Benachrichtigungen zu YARA-L-Erkennungsregeln für Benachrichtigungsmetadaten. 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 Benachrichtigung handelt.
• Encoding: Boolesch.

Erforderliche und optionale Felder für Unternehmenstypen

Entitätstyp	Unternehmensspezifische Anforderungen
IP_ADDRESS	entity.ip muss mindestens eine gültige IP-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 darstellen. Optional: Wenn entity.domain.whois_server ausgefüllt ist, darf die entity.domain-Nachricht nicht mehr als 50 Felder enthalten.
URL	entity.url muss vorhanden und nicht leer sein.
MUTEX	entity.resource muss vorhanden sein. entity.resource.resource_type muss MUTEX lauten. entity.resource.name muss vorhanden und nicht leer sein.
USER	entity.user muss vorhanden sein. Für entity.user muss mindestens eine E-Mail-Adresse angegeben sein.
RESOURCE	entity.resource muss vorhanden sein. entity.resource.resource_type muss entweder MUTEX oder STORAGE_OBJECT sein. Wenn resource_type = MUTEX: MUTEX-Anforderungen ansehen. Wenn resource_type den Wert STORAGE_OBJECT hat: entity.resource.resource_subtype muss vorhanden und nicht leer sein. Mindestens eines der folgenden Elemente muss vorhanden und 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 einen gültigen CIDR-Bereich im folgenden Format enthalten: ip_address/prefix_length.

Erforderliche und optionale Felder für die einzelnen Ereignistypen

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. Enumerationsnummern) finden Sie in der Liste der Felder für einheitliche Datenmodelle.

EMAIL_TRANSACTION, EMAIL_UNCATEGORIZED

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal: Mit Informationen zum Computer füllen, von dem die E‑Mail stammt, z. B. die IP-Adresse des Absenders.

Optionale Felder:

• about: URLs, IPs, 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 abgeleitet, der für dieses Feld normalisiert wurde.
• securityResult.about: Schlechte URLs, IP-Adressen und Dateien, die in den E‑Mail-Text eingebettet sind.
• network.email: Informationen zum Absender oder Empfänger von E‑Mails. Beachten Sie, dass „network.email“ kein Aliasfeld ist. Wenn Sie Aliasing und Anreicherung für die Suche oder Erkennung benötigen, müssen Sie mithilfe einer Parsererweiterung in den Haupt- oder Zielindex indexieren.
• principal: Wenn Clientcomputerdaten dazu vorhanden sind, wer die E‑Mail gesendet hat, füllen Sie die Serverdetails in „principal“ aus (z. B. den Clientprozess, Portnummern, den Nutzernamen usw.).
• target: Wenn Daten zum Ziel-E-Mail-Server vorhanden sind, geben Sie die Serverdetails im Ziel an (z. B. die IP-Adresse).
• intermediary: Wenn Mailserver- oder Mail-Proxy-Daten vorhanden sind, füllen Sie die Serverdetails in „intermediary“ ein.

Hinweise:

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

UDM-Beispiel für EMAIL_TRANSACTION

Das folgende Beispiel veranschaulicht, wie ein Ereignis vom Typ EMAIL_TRANSACTION für die 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 zu sehen ist, wird 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: Fügen Sie die erforderlichen Felder ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • Optional: Füllen Sie „principal.process“ mit Informationen zum Prozess aus, der auf die Datei zugreift.
• target:
  • Wenn die Datei remote ist (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: Beschreiben Sie 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 veranschaulicht, 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 zu sehen ist, wird das Ereignis in die folgenden UDM-Kategorien unterteilt:

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

FILE_COPY

Pflichtfelder:

• Metadaten: Fügen Sie die erforderlichen Felder wie beschrieben ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • Optional: Füllen Sie principal.process mit Informationen zum Prozess aus, der den Kopiervorgang für die Datei ausführt.
• src:
  • Fügen Sie in src.file Informationen zur Quelldatei ein.
  • Wenn sich die Datei auf einem Remote-Server befindet (z. B. auf einer SMB-Freigabe), muss „src“ mindestens eine Computer-ID für den Quellcomputer enthalten, auf dem die Quelldatei gespeichert ist.
• target:
  • Füllen Sie target.file mit Informationen zur Zieldatei aus.
  • Wenn die Datei sich auf einem Remote-Server befindet (z. B. SMB-Freigabe), muss das Feld target mindestens eine Maschinen-ID für den Zielcomputer enthalten, auf dem sich die Zieldatei befindet.

Optionale Felder:

• security_result: Beschreiben Sie 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: Fügen Sie src.file.full_path ein, um die Originaldatei darzustellen.
• target: Schließen Sie target.file.full_path ein, um die Zieldatei darzustellen.

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 zu sehen ist, wird 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.

MUTEX_CREATION, MUTEX_UNCATEGORIZED

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • Füllen Sie „principal.process“ mit Informationen zum Prozess aus, der das Mutex erstellt. Für die UDM-Validierung ist ein Prozessobjekt im Prinzipal erforderlich. Die UDM-Validierung kann nicht mit einem Prozess nur im Ziel bestanden werden.
• target:
  • Füllen Sie target.resource aus.
  • Füllen Sie target.resource.type mit MUTEX aus.
  • Füllen Sie target.resource.name mit dem Namen des erstellten Mutex aus.

Optionale Felder:

• security_result: Beschreiben Sie 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 des Typs 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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• Haupt-ID: Geräte- und Prozessdetails.
• target: Informationen zum Mutex.

NETWORK_CONNECTION, NETWORK_FLOW, NETWORK_FTP, NETWORK_SMTP

Pflichtfelder:

• metadata: event_timestamp
• principal: Enthält Details zum Computer, der die Netzwerkverbindung initiiert hat (z. B. die Quelle).
• target: Geben Sie Details zum Zielcomputer an, wenn er sich vom Hauptcomputer unterscheidet.
• network: Erfassen Sie Details zur Netzwerkverbindung (Ports, Protokoll usw.).

Optionale Felder:

• principal.process und target.process: Enthalten Prozessinformationen, die mit dem Prinzipal und dem Ziel der Netzwerkverbindung verknüpft sind (sofern verfügbar).
• principal.user und target.user: Nutzerinformationen, die mit dem Prinzipal 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 alle Netzwerkereignisse ein Port für das Prinzipal oder das Ziel angegeben ist, dürfen die Felder ip und mac nur jeweils einen Wert enthalten (sofern verfügbar), nämlich die IP-Adresse und die MAC-Adresse, die dem Port zugeordnet sind. Andernfalls können Sie, wenn kein Port angegeben ist, eine beliebige Anzahl von IP- und MAC-Adressen angeben, die zum Zeitpunkt des Ereignisses mit dem Gerät verknüpft sind (keine bestimmte Reihenfolge erforderlich).

NETWORK_DHCP

Pflichtfelder:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Mindestens eine Maschinen-ID (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 die Asset-Aliasierung 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 zu sehen ist, wird das Ereignis in die folgenden UDM-Kategorien unterteilt:

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

NETWORK_DNS

Pflichtfelder:

• principal: Mindestens eine Maschinen-ID (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 zu sehen ist, wird 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 Prinzipal zu einem Zielwebserver dar.

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• 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 mit dieser Netzwerkverbindung verknüpft ist, nur eine IP-Adresse an. Für das Ziel können jedoch mehrere andere Maschinenkennungen angegeben werden.
  • Geben Sie für target.url die aufgerufene URL ein.

Optionale Felder:

• principal: Stellt den Client dar, der die Webanfrage initiiert. Geben Sie mindestens eine Geräte-ID (z. B. Hostname, IP-Adresse, MAC-Adresse, eigene Asset-ID) oder eine Nutzer-ID (z. B. Nutzername) an.
  • Wenn eine bestimmte Netzwerkverbindung beschrieben wird und eine Clientportnummer 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 Geräte-IDs 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 hochgeladene oder heruntergeladene Datei.
• intermediary: Stellt einen Proxyserver dar (falls er sich vom Prinzipal oder Ziel unterscheidet).
• metadata: Füllen Sie die anderen Metadatenfelder aus.
• network: Füllen Sie die anderen 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 aus.
• 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 veranschaulicht, wie ein Sophos-Antivirusereignis vom Typ NETWORK_HTTP in das Google SecOps UDM-Format konvertiert wird.

Das ursprüngliche Sophos-Antivirus-Ereignis:

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 würden Sie dieselben Informationen in Proto3 mit der Google SecOps UDM-Syntax formatieren:

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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• principal: Sicherheitsgerät, das das Ereignis erkannt hat.
• Ziel: Gerät, auf dem die Schadsoftware empfangen wurde.
• network: Netzwerkinformationen zum schädlichen Host.
• security_result: Sicherheitsdetails zur schädlichen Software.
• Zusätzlich: Anbieterinformationen, die nicht in den Umfang des UDM fallen.

PROCESS_INJECTION, PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_TERMINATION, PROCESS_UNCATEGORIZED

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • Bei Ereignissen zur Prozesseinschleusung und zum Beenden von Prozessen muss principal.process, sofern verfügbar, Informationen zum Prozess enthalten, der die Aktion initiiert (z. B. muss principal.process bei einem Prozessstartereignis, sofern verfügbar, Details zum übergeordneten Prozess enthalten).
• target:
  • target.process: Enthält Informationen zum Prozess, in den Code eingefügt wird, der geöffnet, gestartet oder beendet wird.
  • Wenn der Zielprozess remote ist, muss das Ziel mindestens eine Maschinen-ID für den Zielcomputer enthalten (z. B. eine IP-Adresse, MAC, einen Hostnamen oder eine Drittanbieter-Asset-ID).

Optionale Felder:

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

UDM-Beispiel für PROCESS_LAUNCH

Das folgende Beispiel veranschaulicht, 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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• Hauptgrundsatz: Gerätedetails.
• Ziel: Prozessdetails.

PROCESS_MODULE_LOAD

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • principal.process: Prozess zum Laden des Moduls.
• target:
  • target.process: Enthält Informationen zum Prozess.
  • target.process.file: Geladenes Modul (z. B. die DLL oder das gemeinsam genutzte Objekt).

Optionale Felder:

• security_result: Beschreiben Sie 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 zu sehen ist, 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: Fügen Sie die erforderlichen Felder ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • principal.process: Prozess, der das Modul lädt.
  • principal.user: Der Nutzer, der das Modul lädt.

Optionale Felder:

• security_result: Beschreiben Sie die erkannte schädliche Aktivität.

UDM-Beispiel für PROCESS_PRIVILEGE_ESCALATION

Das folgende Beispiel veranschaulicht, 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 zu sehen ist, 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 Eskalierung initiiert.
• target: Details zum eskalierten Prozess.

REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION, REGISTRY_UNCATEGORIZED

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • Wenn ein Prozess im Nutzermodus die Registrierungsänderung vornimmt, muss principal.process Informationen zum Prozess enthalten, der die Registrierung ändert.
  • Wenn ein Kernelprozess die Registrierungsänderung vornimmt, darf der Principal keine Prozessinformationen enthalten.
• target:
  • target.registry: Wenn die Zielregistrierung remote ist, muss das Ziel mindestens eine Kennung für den Zielcomputer enthalten, z. B. eine IP-Adresse, MAC-Adresse, einen Hostnamen oder eine Asset-Kennung eines Drittanbieters.
  • target.registry.registry_key: Alle Registry-Ereignisse müssen den betroffenen Registry-Schlüssel enthalten.

Optionale Felder:

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

UDM-Beispiel für REGISTRY_MODIFICATION

Das folgende Beispiel zeigt, 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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• principal: Details zu Gerät, Nutzer und Prozess.
• target: Der 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: Informationen zum Scanner selbst erfassen. Wenn der Scanner sich an einem Remote-Standort befindet, müssen die Maschinendetails im Feld „Beobachter“ erfasst werden. Lassen Sie das Feld für einen lokalen Scanner leer.
• target: Erfasst Informationen zum Computer, auf dem sich das zu scannende Objekt befindet. Wenn eine Datei gescannt wird, müssen in target.file Informationen zur gescannten Datei erfasst werden. Wenn ein Prozess gescannt wird, müssen in „target.process“ Informationen zum gescannten Prozess erfasst werden.
• extensions: Definieren Sie für SCAN_VULN_HOST und SCAN_VULN_NETWORK die Sicherheitslücke mit dem Feld extensions.vuln.

Optionale Felder:

• principal: Stellt das Gerät dar, das die Verbindung initiiert, und enthält mindestens eine Maschinen-ID (z. B. Hostname, IP-Adresse, MAC-Adresse, proprietäre Asset-ID) oder eine Nutzer-ID.
• target: Nutzerdetails zum Zielobjekt (z. B. Dateiersteller oder Prozessinhaber) sollten in „target.user“ erfasst werden.
• security_result: Beschreiben Sie 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 die 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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• Ziel: Gerät, auf dem die Schadsoftware empfangen wurde.
• Beobachter: 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 die 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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• Prinzipal: Gerät, auf dem die Malware empfangen wurde.
• 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 „principal“ eine Maschinen-ID und eine Nutzer-ID enthalten.
• target: Das Ziel muss eine gültige Ressource und einen Ressourcentyp enthalten, der als „TASK“ definiert ist.

Optionale Felder:

• security_result: Beschreiben Sie 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: {
    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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• principal: Gerät, auf dem die verdächtige Aufgabe geplant wurde.
• target: Software, auf die sich der verdächtige Task bezieht.
• Zwischenhändler: Zwischenhändler, der an der verdächtigen Aufgabe beteiligt ist.
• 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 Maschinen-ID enthalten.

  Hinweis: Die Einstellung resource.type wird nicht mehr unterstützt. Verwenden Sie „resource.resource_type“.

• target: Muss vorhanden und nicht leer sein und eine Ressource enthalten, deren Typ 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": {
            "type": "SETTING",
            "name": "foo.bar"
        }
    }
}

Wie in diesem Beispiel zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Informationen zum Gerät, auf dem die Einstellungsänderung vorgenommen wurde.
• target: Details zur Einstellungsressource.

SERVICE_UNSPECIFIED, SERVICE_CREATION, SERVICE_DELETION, SERVICE_START, SERVICE_STOP

Pflichtfelder:

• target: Geben Sie die Nutzer-ID an und legen Sie entweder „process“ (Prozess) oder „application“ (Anwendung) fest.
• principal: Geben Sie mindestens eine Maschinen-ID (IP- oder MAC-ADRESSE, Hostname oder Asset-ID) an.

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: {
      type: "Service Type"
      name: "RPC"
   }
 }

Wie in diesem Beispiel zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• Hauptgrundsatz: Geräte- und Standortdetails.
• target: Hostname und Nutzer-ID.
• application: Anwendungsname und Ressourcentyp.

STATUS_HEARTBEAT, STATUS_STARTUP, STATUS_SHUTDOWN, STATUS_UPDATE

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• 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 die 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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• Hauptgrundsatz: Geräte- und Standortdetails.
• Zwischengerät: Geräte-IP-Adresse.
• security_result: Details zum Sicherheitsergebnis.

SYSTEM_AUDIT_LOG_UNCATEGORIZED, SYSTEM_AUDIT_LOG_WIPE

Pflichtfelder:

• principal: Geben Sie eine Nutzer-ID für den Nutzer an, der den Vorgang im Log ausgeführt hat, und eine Maschinen-ID für die Maschine, auf der das Log 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 die 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 zu sehen ist, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• Metadaten: Hintergrundinformationen zum Ereignis.
• Hauptidentität: Geräte- und Nutzerdetails.

USER_BADGE_IN

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• 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 veranschaulicht, 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 zu sehen ist, wird das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• target: Informationen zum Gerät oder Standort, an dem das Badge-in erfolgt ist.
• extensions: Details zum verwendeten Authentifizierungsmechanismus.

USER_CHANGE_PASSWORD, USER_CHANGE_PERMISSIONS

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal: Wenn das Nutzerkonto von einem Remote-Standort aus geändert wird, geben Sie hier Informationen zum Computer an, von dem die Änderung stammt.
• target: Füllen Sie „target.user“ mit Informationen zum geänderten Nutzer aus.
• intermediary: Bei SSO-Anmeldungen muss „intermediary“ mindestens eine Maschinen-ID für den SSO-Server enthalten, sofern verfügbar.

USER_COMMUNICATION

Pflichtfelder:

• Hauptkonto: Füllen Sie das Feld principal.user mit Details aus, die mit der vom Nutzer initiierten (Absender-)Kommunikation verknüpft sind, z. B. einer Chatnachricht in Google Chat oder Slack, einer Video- oder Sprachkonferenz 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 aus. Füllen Sie das Feld target.application mit Informationen zur Zielanwendung für die Cloud-Kommunikation aus.

USER_CREATION, USER_DELETION

Pflichtfelder:

• metadata: event_timestamp.
• principal: Geben Sie Informationen zum Computer an, von dem die Anfrage zum Erstellen oder Löschen des Nutzers stammt. Beim Erstellen oder Löschen eines lokalen Nutzers muss principal mindestens eine Maschinen-ID für die Quellmaschine enthalten.
• target: Ort, an dem der Nutzer erstellt wird. Muss auch Nutzerinformationen enthalten (z. B. target.user).

Optionale Felder:

• principal: Nutzer- und Prozessdetails für den Computer, auf dem die Anfrage zum Erstellen oder Löschen des Nutzers initiiert wurde.
• target: Informationen zum Zielcomputer (falls er sich vom Hauptcomputer unterscheidet).

USER_LOGIN, USER_LOGOUT

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal: Bei Remote-Nutzeraktivitäten (z. B. Remote-Anmeldung) geben Sie im Feld „principal“ Informationen zum Computer an, von dem die Nutzeraktivität ausgeht. Legen Sie für lokale Nutzeraktivitäten (z. B. lokale Anmeldung) keinen Prinzipal fest.
• target: Füllen Sie „target.user“ mit Informationen zum Nutzer aus, der sich angemeldet oder abgemeldet hat. Wenn „principal“ nicht festgelegt ist (z. B. bei lokaler Anmeldung), muss „target“ auch mindestens eine Maschinen-ID enthalten, die die Zielmaschine identifiziert. Bei Nutzeraktivitäten zwischen Maschinen (z. B. Remote-Anmeldung, SSO, Cloud-Dienst, VPN) muss das Ziel Informationen zur Zielanwendung, zum Zielcomputer oder zum Ziel-VPN-Server enthalten.
• intermediary: Bei SSO-Anmeldungen muss „intermediary“ mindestens eine Maschinen-ID für den SSO-Server enthalten, sofern 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 angeben.
• authentication-Erweiterung: Muss den Typ des Authentifizierungssystems angeben, auf das sich das Ereignis bezieht (z. B. Computer, SSO oder VPN) und den verwendeten Mechanismus (Nutzername und Passwort, Einmalpasswort usw.).
• security_result: Fügen Sie ein security_result-Feld hinzu, um den Anmeldestatus darzustellen, wenn die Anmeldung fehlschlägt. Geben Sie für „security_result.category“ den Wert „AUTH_VIOLATION“ an, wenn die Authentifizierung fehlschlägt.

UDM-Beispiel für USER_LOGIN

Das folgende Beispiel veranschaulicht, 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 zu sehen ist, wird 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. ein Salesforce-Vorgang, ein Office 365-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-Cloudanwendung aus.

USER_RESOURCE_CREATION, USER_RESOURCE_DELETION

Pflichtfelder:

• principal: Füllen Sie das Feld principal.user mit Details zum Nutzer aus, der in einer Cloud-Ressource erstellt wurde (z. B. ein Salesforce-Vorgang, ein Office 365-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-Cloudanwendung 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-Vorgang, ein Office 365-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-Cloudanwendung aus.

USER_RESOURCE_UPDATE_PERMISSIONS

Pflichtfelder:

• principal: Füllen Sie das Feld principal.user mit Details zum Nutzer aus, dessen Berechtigungen für eine Cloud-Ressource (z. B. ein Salesforce-Vorgang, ein Office 365-Kalender, ein Google-Dokument oder ein ServiceNow-Ticket) aktualisiert wurden.
• 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-Cloudanwendung aus.

USER_UNCATEGORIZED

Pflichtfelder:

• metadata: event_timestamp
• principal: Geben Sie Informationen zum Computer an, von dem die Anfrage zum Erstellen oder Löschen des Nutzers stammt. Beim Erstellen oder Löschen eines lokalen Nutzers muss principal mindestens eine Maschinen-ID für die Quellmaschine enthalten.
• target: Ort, an dem der Nutzer erstellt wird. Muss auch Nutzerinformationen enthalten (z. B. target.user).

Optionale Felder:

• principal: Nutzer- und Prozessdetails für den Computer, auf dem die Anfrage zum Erstellen oder Löschen des Nutzers initiiert wurde.
• target: Informationen zum Zielcomputer (falls er sich vom Hauptcomputer unterscheidet).