UDM-Nutzungsleitfaden

In diesem Dokument finden Sie eine detaillierte Beschreibung der Felder im Schema für einheitliche Datenmodelle (Unified Data Model, UDM). Darin sind die erforderlichen und optionalen Felder für jeden Ereignistyp aufgeführt.

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.

Bevölkerung von 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.

Analysten-Events

• 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 werden

• 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

Netzwerktelemetrieereignisse, die Rohprotokollnutzlasten 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 bei Microsoft Windows-spezifischen Registrierungsereignissen die folgenden REGISTRY-Ereignisse anstelle der SETTING-Ereignisse:

• REGISTRY_UNCATEGORIZED
• REGISTRY_CREATION
• REGISTRY_MODIFICATION
• REGISTRY_DELETION

Ressourcenereignisse

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Scan-orientierte 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

Dienstereignisse

• 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, die angeben, dass Agents aktiv sind, und Versions-, Fingerprint- 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 ein Nutzer sich physisch auf einer Website 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 zur eindeutigen Identifizierung des Ereignisses (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 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 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 verweist, 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. 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ß- und Kleinschreibung beachtet wird, Satzzeichen sind zulässig, maximal 256 Byte
• Beispiele:
  • CrowdStrike
  • Symantec

Bevölkerung 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.ProductName:ID, wobei VendorName ein nicht case-sensitiver* *Anbietername wie „Carbon Black“, ProductName ein nicht case-sensitiver Produktname wie „Response“ oder „Endpoint Protection“ und ID eine anbieterspezifische Kunden-ID ist, die in der Umgebung des Kunden global eindeutig ist (z. B. eine GUID oder ein eindeutiger Wert zur Identifizierung eines eindeutigen Geräts). VendorName und ProductName sind alphanumerisch und dürfen maximal 32 Zeichen lang sein. Die ID darf maximal 128 Zeichen lang sein und alphanumerische Zeichen, Bindestriche und Punkte enthalten.
• Beispiel: CrowdStrike.Falcon: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 Dateimetadaten.

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: 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: 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 eine allgemeine Aktivität auf einem Teilnehmergerät, aber keine bestimmte Netzwerkverbindung beschreibt, 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 eine bestimmte Netzwerkverbindung in einem Ereignis 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 Nomen 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:
  • fedc:ba98:7654:3210:fedc:ba98:7654:3210
  • 1080:0:0:0:8:800:200c:417a
  • 00:a0:0:0:c9:14:c8:29

Noun.administrative_domain

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

Noun.registry

• Zweck: Detaillierte Registrierungsmetadaten.
• Typ: Objekt
• Weitere Informationen finden Sie unter Population of Registry metadata.

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.

Bevölkerung von 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 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.
• Codierung: String.

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.
• 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/Erneuern der Adresse durch den Client.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.sname

• Zweck: Name des Servers, von dem der Client gebootet werden soll.
• 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: IP-Adresse für die Clienthardware.
• Codierung: Gültige IPv4- oder IPv6-Adresse (RFC 5942), die in ASCII codiert ist.

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: Byte.

DNS-Metadaten

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

Dns.authoritative

• Zweck: Auf „true“ für autoritative DNS-Server festgelegt.
• Codierung: 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.
• Codierung: 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 eine rekursive DNS-Suche verfügbar ist.
• Codierung: Boolesch.

Dns.recursion_desired

• Zweck: Auf „true“ gesetzt, wenn eine rekursive DNS-Suche angefordert wird.
• Codierung: 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.
• Codierung: Boolesch.

Dns.questions

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

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.

DNS-Fragemetadaten

Die Metadatenfelder für DNS-Anfragen erfassen die Informationen, 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 fügen Sie die DNS-Antwort in das Datenfeld unten ein. Diese Art von Informationen muss hier und nicht in ResourceRecord.data gespeichert werden.

• Codierung: Byte.

  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: Speichert den Namen des Inhabers des Ressourceneintrags.
• Codierung: String.

ResourceRecord.ttl

• Zweck: Speichert das Zeitintervall, für das der Ressourceneintrag 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. Sie sollten dem Standardformat für E-Mail-Adressen (lokales-postfach@domain) gemäß RFC 5322 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 ID der E-Mail oder Nachricht.
• Codierung: String.
• Beispiel: [e-mail]

Email.subject

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

Metadaten für Erweiterungen

Ereignistypen mit erstklassigen Metadaten, die noch nicht von der Google SecOps-UDM kategorisiert werden.

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 oft 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 zu Sicherheitslücken.
• Codierung: String.
• Beispiel: Daten aus dem Host-Scan auf Sicherheitslücken.

Dateimetadaten

File.file_metadata

• Zweck: Metadaten, die der Datei zugeordnet 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: Gruppieren von Kontaktdaten.
• Codierung: E-Mail.

Group.group_display_name

• Zweck: Anzeigename der Gruppe.
• Codierung: String.
• Beispiele:
  • Finanzen
  • Personalwesen
  • 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: Microsoft Windows-Gruppenattributfeld für die 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
  • EINGEHEND
  • AUSGEHEND
  • 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 (Vorgang)

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 einer Anwendung oder Systemkomponente zugeordnet 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

Bevölkerung von 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: In Google SecOps UDM werden die folgenden Sicherheitsaktionen definiert:
  • ZULASSEN
  • ALLOW_WITH_MODIFICATION: Die Datei oder E‑Mail wurde desinfiziert oder neu geschrieben und wird trotzdem weitergeleitet.
  • BLOCKIEREN
  • QUARANTINE: Für die spätere Analyse speichern (bedeutet nicht, dass die Datei blockiert wird).
  • UNKNOWN_ACTION

SecurityResult.action_details

• Zweck: Vom Anbieter bereitgestellte Details zur ergriffenen Maßnahme als Reaktion auf den Sicherheitsvorfall. 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: Enum.
• Mögliche Werte: Im 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 zerstören/löschen.
  • DATA_EXFILTRATION: DLP: Übertragung von Sensordaten, Kopieren auf USB-Laufwerk.
  • EXPLOIT: Versuchte Ü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 Quell-E-Mail-Adresse 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: Enum.
• Mögliche Werte: Im UDM von Google SecOps 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: Enum.
• Mögliche Werte: In Google SecOps UDM 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: Enum.
• Mögliche Werte: Im 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, über die Sie zur Quellproduktkonsole für dieses Sicherheitsereignis weitergeleitet werden.
• Codierung: String.

Nutzermetadaten

User.email_addresses

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

User.employee_id

• Zweck: Speichert die Mitarbeiter-ID des Personalwesens 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 einem Nutzer zugeordnet sind.
• Codierung: Wiederholter String.
• Beispiel: admin-users.

User.phone_numbers

• Zweck: Speichert die Telefonnummern des Nutzers.
• Codierung: 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)
  • Zugriffskomplexität (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.

• Codierung: String.

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

Vulnerability.cvss_version

• Zweck: CVSS-Version für den Schwachstellenwert 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 angegeben 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 zutreffend ist.
• Codierung: String.

Vulnerability.scan_start_time

• Zweck: Wenn die Sicherheitslücke während eines Asset-Scans 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 zur Schwere des Problems.
• 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 Funktionen.

idm.is_significant

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

idm.is_alert

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

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

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.
• securityResult.about: Schlechte URLs, IP-Adressen und Dateien, die im E-Mail-Text eingebettet sind.
• network.email: Informationen zum E-Mail-Absender oder ‑Empfänger.
• principal: Wenn Clientcomputerdaten dazu vorhanden sind, wer die E‑Mail gesendet hat, füllen Sie die Serverdetails in „principal“ ein (z. B. den Clientprozess, Portnummern, den Nutzernamen usw.).
• target: Wenn Daten zum Ziel-E-Mail-Server vorhanden sind, füllen Sie die Serverdetails im Ziel aus (z. B. die IP-Adresse).
• intermediary: Wenn Daten zum Mailserver oder Mail-Proxy vorhanden sind, füllen Sie die Serverdetails in „intermediary“ ein.

Hinweise:

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

FILE_CREATION, FILE_DELETION, FILE_MODIFICATION, FILE_READ und FILE_OPEN

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 erkannten schädlichen Aktivitäten.
• principal.user: Wird ausgefüllt, wenn Nutzerinformationen zum Prozess verfügbar sind.

FILE_COPY

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder wie beschrieben ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • Optional: Fügen Sie in principal.process Informationen zum Prozess ein, der den Kopiervorgang für die Datei ausführt.
• src:
  • Fügen Sie Informationen zur Quelldatei in src.file ein.
  • Wenn sich die Datei auf einem Remote-Server befindet (z. B. auf einer SMB-Freigabe), muss „src“ mindestens eine Maschinen-ID für den Quellcomputer enthalten, auf dem die Quelldatei gespeichert ist.
• target:
  • Füllen Sie target.file mit Informationen zur Zieldatei aus.
  • Wenn sich die Datei 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 erkannten schädlichen Aktivitäten.
• principal.user: Wird ausgefüllt, wenn Nutzerinformationen zum Prozess verfügbar sind.

MUTEX_CREATION

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • Füllen Sie „principal.process“ mit Informationen zum Prozess, der das Mutex erstellt.
• 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 erkannten schädlichen Aktivitäten.
• 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 die 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:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptseite: Details zu Geräten und Prozessen.
• target: Informationen zum Mutex.

NETWORK_CONNECTION

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).

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_HTTP

Der Ereignistyp NETWORK_HTTP steht für eine HTTP-Netzwerkverbindung von einem Prinzipal zu einem Zielwebserver.

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal: Stellt den Client dar, der die Webanfrage initiiert, und enthält mindestens eine Maschinen-ID (z. B. Hostname, IP, MAC, proprietäre Asset-ID) oder eine Nutzer-ID (z. B. Nutzername). Wenn eine bestimmte Netzwerkverbindung beschrieben wird und eine Clientportnummer verfügbar ist, muss nur eine IP-Adresse zusammen mit der Portnummer angegeben werden, 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 alle IP- und MAC-Adressen, Asset-IDs und Hostnamenwerte angegeben werden, die das Hauptgerät beschreiben.
• target: Stellt den Webserver dar und enthält Geräteinformationen und optional eine Portnummer. 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.
• 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

Optionale Felder:

• 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 zeigt, wie ein Sophos-Antivirenereignis vom Typ NETWORK_HTTP in das Google SecOps UDM-Format konvertiert wird.

Das ist 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:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Sicherheitsgerät, das das Ereignis erkannt hat.
• Ziel: Gerät, auf dem die schädliche Software empfangen wurde.
• network: Netzwerkinformationen zum schädlichen Host.
• security_result: Sicherheitsdetails zur schädlichen Software.
• Zusätzlich: Anbieterinformationen, die nicht in den 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 Details zum übergeordneten Prozess enthalten, sofern verfügbar).
• 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 erkannten schädlichen Aktivitäten.
• 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:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptgrundsatz: Gerätedetails.
• Ziel: Details verarbeiten.

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 erkannten schädlichen Aktivitäten.
• 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: "2020-01-01T13:27:41+00:00"
  event_type: PROCESS_MODULE_LOAD
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "example.com"
  process {
    pid: "0x123"
  }
}
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:

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

PROCESS_PRIVILEGE_ESCALATION

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder ein.
• principal:
  • Mindestens eine Maschinen-ID.
  • principal.process: Prozess zum Laden des Moduls.
  • principal.user: Nutzer, der das Modul lädt.

Optionale Felder:

• security_result: Beschreiben Sie die erkannten schädlichen Aktivitäten.

UDM-Beispiel für PROCESS_PRIVILEGE_ESCALATION

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

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: PROCESS_PRIVILEGE_ESCALATION
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "example.com"
  process {
    pid: "0x123"
  }
  user {
    userid: "test"
    windows_sid: "ABCDEFGH-123456789-1111111-1000"
  }
}
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:

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

REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION

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 erkannten schädlichen Aktivitäten. Das kann beispielsweise ein fehlerhafter Registrierungsschlüssel sein.
• 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:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptkonto: Details zu Gerät, Nutzer und Prozess.
• target: Der Registrierungseintrag, der von der Änderung betroffen ist.

SCAN_FILE, SCAN_HOST, SCAN_PROCESS, SCAN_VULN_HOST, SCAN_VULN_NETWORK

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 gescannte 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 Maschinenkennung (z. B. Hostname, IP-Adresse, MAC-Adresse, proprietäre Asset-Kennung) oder eine Nutzerkennung.
• target: Nutzerdetails zum Zielobjekt (z. B. Dateiersteller oder Prozessinhaber) sollten in „target.user“ erfasst werden.
• security_result: Beschreiben Sie die erkannten schädlichen Aktivitäten.

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:

• metadata: Hintergrundinformationen zum Ereignis.
• Ziel: Gerät, auf dem die schädliche Software empfangen wurde.
• observer: Das 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:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptkonto: Gerät, auf dem die Malware empfangen wurde.
• extensions: Vulnerability details.

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 erkannten schädlichen Aktivitäten.

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:

• metadata: Hintergrundinformationen zum Ereignis.
• Hauptkonto: Gerät, das die verdächtige Aufgabe geplant hat.
• target: Software, auf die sich die verdächtige Aufgabe bezieht.
• intermediary: Vermittler, 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.
• 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: "2020-01-01T13:27:41+00:00"
  event_type: SETTING_MODIFICATION
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "test.win.com"
}
target {
  resource {
    type: "SETTING"
    name: "test-setting"
  }
}

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: Ressourcendetails.

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 Computer-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:

• metadata: 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:

• metadata: 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:

• metadata: Hintergrundinformationen zum Ereignis.
• Haupt-Identität: Geräte- und Nutzerdetails.

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:

• principal: 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 Cloud-Kommunikationsanwendung 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. Maschine, 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 security_result.category mit dem Wert AUTH_VIOLATION an, wenn die Authentifizierung fehlschlägt.

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:

• Hauptkonto: 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 in einer Cloud-Ressource (z. B. einem Salesforce-Vorgang, einem Office 365-Kalender, einem Google-Dokument oder einem 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).