UDM-Nutzungsleitfaden

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

Formate für UDM-Feldnamen

• Bei der Auswertung durch die Regelengine beginnt das Präfix mit udm.
• Bei einem konfigurationsbasierten Normalizer (CBN) beginnt das Präfix mit event.idm.read_only_udm.

Erfassen von Ereignis-Metadaten

Im Bereich „Ereignismetadaten“ für UDM-Ereignisse werden allgemeine Informationen zu jedem Ereignis gespeichert.

Metadata.event_type

• Zweck:Gibt den Typ des Ereignisses an. Wenn ein Ereignis mehrere mögliche Typen hat, muss dieser Wert den spezifischeren Typ angeben.
• Erforderlich:Ja
• Encoding:Muss einer der vordefinierten UDM-Ereignistypen sein.
• Mögliche Werte:Im Folgenden sind alle möglichen Werte für „event_type“ im UDM aufgeführt.

Analystenereignisse:

• ANALYST_ADD_COMMENT
• ANALYST_UPDATE_PRIORITY
• ANALYST_UPDATE_REASON
• ANALYST_UPDATE_REPUTATION
• ANALYST_UPDAATE_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

Nicht angegebene Ereignisse:

• EVENTTYPE_UNSPECIFIED

Dateiereignisse, die auf einem Endpunkt ausgeführt wurden:

• FILE_UNCATEGORIZED
• FILE_COPY (z. B. Kopieren einer Datei auf einen USB-Speicher)
• FILE_CREATION
• FILE_DELETION
• FILE_MODIFICATION
• FILE_MOVE
• FILE_OPEN (z. B. kann das Öffnen einer Datei auf einen Sicherheitsverstoß hinweisen)
• FILE_READ (z. B. Lesen einer Passwortdatei)
• FILE_SYNC

Ereignisse, die in keine andere Kategorie fallen, einschließlich nicht kategorisierter Windows-Ereignisse.

• GENERIC_EVENT

Ereignisse für Gruppenaktivitäten:

• GROUP_UNCATEGORIZED
• GROUP_CREATION
• GROUP_DELETION
• GROUP_MODIFICATION

Mutex-Ereignisse (Mutual Exclusion Object):

• MUTEX_UNCATEGORIZED
• MUTEX_CREATION

Netzwerktelemetrie, einschließlich Rohprotokollnutzlasten wie DHCP und DNS sowie Protokollzusammenfassungen für Protokolle wie HTTP, SMTP und FTP sowie Fluss- und Verbindungsereignisse von Netflow und Firewalls.

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

Alle Ereignisse, die sich auf einen Prozess beziehen, z. B. das Starten eines Prozesses, das Erstellen eines schädlichen Prozesses, das Einschleusen eines Prozesses in einen anderen Prozess, die Änderung eines Registrierungsschlüssels oder das Erstellen einer schädlichen Datei auf dem Laufwerk.

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

Verwenden Sie bei Microsoft Windows-spezifischen Registrierungsereignissen die 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

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

• SCAN_UNCATEGORIZED
• SCAN_FILE
• SCAN_HOST
• SCAN_NETWORK
• SCAN_PROCESS
• SCAN_PROCESS_BEHAVIORS
• SCAN_VULN_HOST
• SCAN_VULN_NETWORK

Ereignisse für geplante Aufgaben (Windows-Taskplaner, 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

Ereigniseinstellungen, z. B. wenn eine Systemeinstellung auf einem Endpunkt geändert wird. Informationen zum Festlegen von Ereignisanforderungen finden Sie unter Einstellungen – Pflichtfelder.

• SETTING_UNCATEGORIZED
• SETTING_CREATION
• SETTING_DELETION
• SETTING_MODIFICATION

Statusmeldungen von Sicherheitsprodukten, die angeben, dass die Agenten aktiv sind, und Version, Fingerabdruck oder andere Daten senden.

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

System-Audit-Log-Ereignisse:

• SYSTEM_AUDIT_LOG_UNCATEGORIZED
• SYSTEM_AUDIT_LOG_WIPE

Ereignisse zur Nutzerauthentifizierung:

• USER_UNCATEGORIZED
• USER_BADGE_IN (z. B. wenn ein Nutzer sich physisch mit einem Ausweis 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

• Verwendung:Enthält 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

• Verwendung:Der 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:Datei c:\bar\foo.exe darf nicht auf das vertrauliche Dokument c:\documents\earnings.docx zugreifen.

Metadata.product_event_type

• Zweck:Kurzer, beschreibender, visuell wahrnehmbarer und produktspezifischer Ereignisname oder ‑typ.
• Codierung:Alphanumerischer String, Satzzeichen zulässig, maximal 64 Byte.
• Beispiele:
  • Ereignis „Registry Creation“
  • ProcessRollUp
  • Rechteausweitung erkannt
  • Malware blockiert

Metadata.product_log_id

• Verwendung:Eine Anbieterspezifische Ereignis-ID wird codiert, um das Ereignis eindeutig zu identifizieren (GUID). Nutzer können diese Kennung verwenden, um in der proprietären Konsole des Anbieters nach dem betreffenden Ereignis zu suchen.
• Codierung:Groß- und Kleinschreibung beachtender alphanumerischer String, Satzzeichen zulässig, maximal 256 Byte.
• Beispiel:ABcd1234-98766

Metadata.product_name

• Zweck:Gibt den Namen des Produkts an.
• Codierung:Groß- und Kleinschreibung beachtender alphanumerischer String, Satzzeichen zulässig, maximal 256 Byte.
• Beispiele:
  • Falcon
  • Symantec Endpoint Protection

Metadata.product_version

• Verwendung:Gibt die Version des Produkts an.
• Codierung:Alphanumerischer String, erlaubt sind Punkte und Bindestriche, maximal 32 Byte
• Beispiele:
  • 1.2.3b
  • 10.3:rev1

Metadata.url_back_to_product

• Zweck:URL zu einer relevanten Website, auf der Sie weitere Informationen zu diesem bestimmten Ereignis (oder der allgemeinen Ereigniskategorie) finden.
• Codierung:Gültige RFC 3986-URL mit optionalen Parametern wie Portinformationen. Muss vor der URL ein Protokollpräfix 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ß- und Kleinschreibung beachten, alphanumerischer String, Satzzeichen zulässig, maximal 256 Byte
• Beispiele:
  • CrowdStrike
  • Symantec

Metadaten für Nomen bevölkern

In diesem Abschnitt ist das Wort Noun (Substantiv) ein übergeordneter Begriff, der die Entitäten principal, src, target, intermediary, observer und about darstellt. Diese Entitäten haben gemeinsame Attribute, stellen aber unterschiedliche Objekte in einem Ereignis dar. Weitere Informationen zu Entitäten und ihrer Bedeutung in einem Ereignis finden Sie unter Logdaten als UDM formatieren.

Noun.asset_id

• Verwendung:Anbieterspezifische eindeutige Geräte-ID (z. B. eine GUID, die beim Installieren von Endpunktsicherheitssoftware auf einem neuen Gerät generiert wird und zum Überwachen dieses eindeutigen Geräts verwendet wird).
• Codierung:VendorName.ProductName:ID, wobei VendorName ein Anbietername ohne Berücksichtigung der Groß- und Kleinschreibung* *wie „Carbon Black“ ist, ProductName ein Produktname ohne Berücksichtigung der Groß- und Kleinschreibung wie „Response“ oder „Endpoint Protection“ und ID eine anbieterspezifische Kunden-ID ist, die innerhalb der Umgebung des Kunden weltweit eindeutig ist (z. B. eine GUID oder ein eindeutiger Wert, der ein eindeutiges Gerät identifiziert). 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

• Verwendung:Detaillierte Dateimetadaten.
• Typ:Objekt
• Weitere Informationen finden Sie unter Dateimetadaten einfügen.

Substantiv.hostname

• Verwendung:Feld für den Hostnamen oder Domainnamen des Clients. Nicht angeben, wenn eine URL vorhanden ist.
• Codierung:Gültiger RFC 1123-Hostname.
• Beispiele:
  • userwin10
  • www.altostrat.com

Noun.platform

• Verwendung:Betriebssystem der Plattform.
• Encoding:Aufzählung
• Mögliche Werte:
  • LINUX
  • MAC
  • WINDOWS
  • UNKNOWN_PLATFORM

Noun.platform_patch_level

• Verwendung:Patchebene des Plattformbetriebssystems.
• Codierung:Alphanumerischer String mit Satzzeichen, maximal 64 Zeichen.
• Beispiel:Build 17134.48

Noun.platform_version

• Verwendung: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 Metadaten für Prozesse füllen.

Noun.ip

• Zweck:
  • Eine 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), codiert in ASCII.
• Wiederholbarkeit:
  • Wenn ein Ereignis eine bestimmte Netzwerkverbindung beschreibt (z. B. srcip:srcport > dstip:dstport), muss der Anbieter nur eine einzige IP-Adresse angeben.
  • Wenn ein Ereignis allgemeine Aktivitäten auf einem Teilnehmergerät beschreibt, aber keine bestimmte Netzwerkverbindung, stellt der Anbieter möglicherweise alle zugehörigen IP-Adressen für das Gerät zum Zeitpunkt des Ereignisses bereit.
• Beispiele:
  • 192.168.1.2
  • 2001:db8:1:3::1

Noun.port

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

• Beispiele:

  • 80
  • 443
  Hinweis: Wenn eine Portnummer angegeben ist, muss im selben Nomen eine und nur eine IP-Adresse angegeben sein.

Noun.mac

• Verwendung:Eine oder mehrere MAC-Adressen, die mit einem Gerät verknüpft sind.
• Codierung:Gültige MAC-Adresse (EUI-48) in ASCII.
• Wiederholbarkeit:Der Anbieter kann zum Zeitpunkt des Ereignisses alle zugehörigen MAC-Adressen für das Gerät angeben.
• 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 Domainnamen-String (maximal 128 Zeichen).
• Beispiel:corp.altostrat.com

Noun.registry

• Verwendung:Detaillierte Registrierdatenmetadaten.
• Typ:Objekt
• Siehe Metadaten in der Registry füllen

Noun.url

• Verwendung: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 Erstellen von Nutzermetadaten.

Authentifizierungsmetadaten erfassen

Authentication.AuthType

• Zweck:Der Typ des Systems, dem ein Authentifizierungsereignis zugeordnet ist (UDM von Google Security Operations).
• Encoding:Aufzählungstyp.
• Mögliche Werte:
  • AUTHTYPE_UNSPECIFIED
  • MACHINE – Maschinenauthentifizierung
  • PHYSICAL: Physische Authentifizierung (z. B. über einen Ausweislesegerät)
  • SSO, die
  • TACACS: TACACS-Familienprotokoll für die Authentifizierung von vernetzten Systemen (z. B. TACACS oder TACACS+)
  • VPN

Authentication.Authentication_Status

• Zweck:Beschreibt den Authentifizierungsstatus eines Nutzers oder bestimmter Anmeldedaten.
• Codierung:Aufzählungstyp.
• Mögliche Werte:
  • UNKNOWN_AUTHENTICATION_STATUS – Standardauthentifizierungsstatus
  • AKTIV: Die Authentifizierungsmethode ist aktiv.
  • AUSGESTELLT: Die Authentifizierungsmethode ist gesperrt oder deaktiviert.
  • GELOSCHEN – Authentifizierungsmethode wurde gelöscht
  • NO_ACTIVE_CREDENTIALS: Für die Authentifizierungsmethode sind keine aktiven Anmeldedaten vorhanden.

Authentication.auth_details

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

Authentication.Mechanism

• Zweck:Mechanismen, die für die Authentifizierung verwendet werden.
• Encoding:Aufzählungstyp.
• Mögliche Werte:
  • MECHANISM_UNSPECIFIED: Standardauthentifizierungsmechanismus.
  • BADGE_READER
  • BATCH: Batch-Authentifizierung.
  • CACHED_INTERACTIVE: Interaktive Authentifizierung mit zwischengespeicherten Anmeldedaten.
  • HARDWARE_KEY
  • LOKALES WERBENETZWERK
  • 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 für die Entsperrung.
  • USERNAME_PASSWORD

Ausfüllen von DHCP-Metadaten

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

Dhcp.client_hostname

• Verwendung:Hostname für den Client. Weitere Informationen finden Sie in RFC 2132, DHCP Options and BOOTP Vendor Extensions (DHCP-Optionen und BOOTP-Anbietererweiterungen).
• Codierung:String.

Dhcp.client_identifier

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

Dhcp.file

• Verwendung:Dateiname für das Boot-Image.
• Codierung:String.

Dhcp.flags

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

dhcp.hlen

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

dhcp.hops

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

Dhcp.htype

• Verwendung:Hardwareadressentyp.
• Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.lease_time_seconds

• Verwendung:Vom Client angeforderte Lease-Dauer für eine IP-Adresse in Sekunden. Weitere Informationen finden Sie in RFC 2132, DHCP Options and BOOTP Vendor Extensions (DHCP-Optionen und BOOTP-Anbietererweiterungen).
• Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.opcode

• Verwendung:BOOTP-Op-Code (siehe Abschnitt 3 von RFC 951).
• Codierung:Aufzählungstyp.
• 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 (DHCP-Optionen und BOOTP-Anbietererweiterungen).
• Codierung:Gültige IPv4- oder IPv6-Adresse (RFC 5942), codiert in ASCII.

Dhcp.seconds

• Verwendung:Anzahl der Sekunden, die seit Beginn des Adresserwerbs-/Verlängerungsvorgangs vergangen sind.
• Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.sname

• Zweck:Name des Servers, von dem aus der Client gestartet werden soll.
• Codierung:String.

Dhcp.transaction_id

• Zweck:Clienttransaktions-ID.
• Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.type

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

Dhcp.chaddr

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

dhcp.ciaddr

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

Dhcp.giaddr

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

Dhcp.siaddr

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

dhcp.yiaddr

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

Metadaten für DHCP-Optionen füllen

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

Option.code

• Verwendung:Speichert den DHCP-Optionscode. Weitere Informationen finden Sie in RFC 1533, DHCP Options and BOOTP Vendor Extensions (DHCP-Optionen und BOOTP-Anbietererweiterungen).
• Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Option.data

• Verwendung:Hier werden die DHCP-Optionsdaten gespeichert. Weitere Informationen finden Sie in RFC 1533, DHCP Options and BOOTP Vendor Extensions (DHCP-Optionen und BOOTP-Anbietererweiterungen).
• Codierung:Bytes.

DNS-Metadaten füllen

Die DNS-Metadatenfelder erfassen Informationen zu DNS-Anfrage- und Antwortpaketen. Sie stehen in einem Eins-zu-Eins-Verhältnis zu den Daten in DNS-Anfrage- und Antwortdatagrammen.

Dns.authoritative

• Verwendung:Legen Sie für autoritative DNS-Server „wahr“ fest.
• Codierung:Boolesch.

Dns.id

• Verwendung:Hier wird die ID der DNS-Abfrage gespeichert.
• Codierung:32-Bit-Ganzzahl.

Dns.response

• Verwendung:Legen Sie „true“ fest, wenn es sich bei dem Ereignis um eine DNS-Antwort handelt.
• Codierung:Boolesch.

Dns.opcode

• Verwendung:Hier wird der DNS-OpCode gespeichert, mit dem der Typ der DNS-Abfrage angegeben wird (z. B. Standard, invers, Serverstatus).
• Codierung:32-Bit-Ganzzahl.

Dns.recursion_available

• Verwendung:Legen Sie „true“ fest, wenn ein rekursiver DNS-Lookup verfügbar ist.
• Codierung:Boolesch.

Dns.recursion_desired

• Verwendung:Legen Sie „true“ fest, wenn ein rekursiver DNS-Lookup angefordert wird.
• Codierung:Boolesch.

Dns.response_code

• Verwendung:Speichert den DNS-Antwortcode gemäß RFC 1035, Domainnamen – Implementierung und Spezifikation.
• Codierung:32-Bit-Ganzzahl.

Dns.truncated

• Verwendung:Legen Sie „true“ fest, wenn es sich um eine gekürzte DNS-Antwort handelt.
• Codierung:Boolesch.

Dns.questions

• Verwendung:Hier werden die Fragen zum Domainprotokoll gespeichert. Weitere Informationen finden Sie unter Metadaten für DNS-Fragen füllen.

Dns.answers

• Verwendung:Hier wird die Antwort auf die Abfrage des Domainnamens gespeichert. Weitere Informationen finden Sie unter Metadaten für DNS-Ressourceneinträge erfassen.

Dns.authority

• Verwendung:Hier werden die Domain-Nameserver gespeichert, die die Antwort auf die Domainnamenabfrage bestätigt haben. Weitere Informationen finden Sie unter Metadaten für DNS-Ressourceneinträge erfassen.

Dns.additional

• Verwendung:Hier werden die zusätzlichen Domainnamenserver gespeichert, mit denen die Antwort auf die Domain überprüft werden kann. Weitere Informationen finden Sie unter Metadaten für DNS-Ressourceneinträge erfassen.

Metadaten für DNS-Fragen füllen

Die DNS-Fragemetadatenfelder erfassen die Informationen im Frageabschnitt einer Domainprotokollnachricht.

Question.name

• Verwendung:Hier wird der Domainname gespeichert.
• Codierung:String.

Question.class

• Verwendung:Hier wird der Code gespeichert, der die Klasse der Abfrage angibt.
• Codierung:32-Bit-Ganzzahl.

Question.type

• Verwendung:Hier wird der Code gespeichert, der den Abfragetyp angibt.
• Codierung:32-Bit-Ganzzahl.

Metadaten für DNS-Ressourceneinträge füllen

Die Metadatenfelder des DNS-Ressourceneintrags erfassen die Informationen im Ressourceneintrag einer Domainprotokollnachricht.

ResourceRecord.binary_data

• Verwendung:Hier werden die Rohbytes aller nicht UTF-8-Strings gespeichert, die Teil einer DNS-Antwort sein können. Dieses Feld darf nur verwendet werden, wenn die vom DNS-Server zurückgegebenen Antwortdaten keine UTF-8-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:Bytes.

  Hinweis: Dieses Feld ist im Gegensatz zu den anderen DNS-Ressourceneintragsfeldern nicht in RFC 1035 spezifiziert, sondern wurde von Google Security Operations für die UDM definiert.

ResourceRecord.class

• Verwendung:Hier wird der Code gespeichert, der die Klasse des Ressourceneintrags angibt.
• Codierung:32-Bit-Ganzzahl.

ResourceRecord.data

• Verwendung:Speichert die Nutzlast oder Antwort auf die DNS-Frage 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 Ressourceneintrag für einen anderen Typ oder eine andere Klasse ist, kann er einen anderen Domainnamen enthalten (wenn ein Domainname auf einen anderen Domainnamen weitergeleitet wird). Die Daten müssen genau so gespeichert werden, wie sie in der DNS-Antwort enthalten sind.
• Codierung:String.

ResourceRecord.name

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

ResourceRecord.ttl

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

ResourceRecord.type

• Verwendung:Hier wird der Code gespeichert, der den Typ des Ressourceneintrags angibt.
• Codierung:32-Bit-Ganzzahl.

E-Mail-Metadaten füllen

Die meisten Felder für E-Mail-Metadaten enthalten die E-Mail-Adressen im Nachrichtenheader und müssen dem Standardformat für E-Mail-Adressen (lokale-mailbox@domain) entsprechen, wie in RFC 5322 definiert. Beispiel: [e-mail].

Email.from

• Verwendung:Hier wird die Absender-E-Mail-Adresse gespeichert.
• Codierung:String.

Email.reply_to

• Verwendung:Hier wird die E-Mail-Adresse reply_to gespeichert.
• Codierung:String.

Email.to

• Verwendung:Hier werden die E-Mail-Adressen für An gespeichert.
• Codierung:String.

Email.cc

• Verwendung:Hier werden die E-Mail-Adressen für die Cc gespeichert.
• Codierung:String.

Email.bcc

• Verwendung:Hier werden die Bcc-E-Mail-Adressen gespeichert.
• Codierung:String.

Email.mail_id

• Verwendung:Hier wird die E-Mail-ID (oder Nachrichten-ID) gespeichert.
• Codierung:String.
• Beispiel:[e-mail]

Email.subject

• Verwendung:Hier wird die Betreffzeile der E-Mail gespeichert.
• Codierung:String.
• Beispiel: „Bitte lesen Sie diese Nachricht.“

Metadaten zur Auslieferung von Erweiterungen

Ereignistypen mit erstklassigen Metadaten, die noch nicht vom UDM von Google Security Operations kategorisiert wurden. Extensions.auth

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

• Verwendung:Hier geben Sie die anbieterspezifischen Details für den Authentifizierungstyp oder ‑mechanismus an. Authentifizierungsanbieter definieren häufig Typen wie „via_mfa“ oder „via_ad“, die nützliche Informationen zum Authentifizierungstyp liefern. Diese Typen können weiterhin in auth.type oder auth.mechanism generalisiert werden, um die Nutzerfreundlichkeit zu verbessern und die Kompatibilität von Regeln für Datensätze zu erhöhen.
• Codierung:String.
• Beispiele:via_mfa, via_ad.

Extensions.vulns

• Zweck:Erweiterung der Metadaten zur Sicherheitslücke.
• Codierung:String.
• Beispiel:
  • Daten zum Scannen von Sicherheitslücken auf Hosts

Dateimetadaten füllen

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

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

Datei.md5

• Verwendung:MD5-Hashwert der Datei.
• Codierung:String, Hexadezimal in Kleinbuchstaben.
• Beispiel:35bf623e7db9bf0d68d0dda764fd9e8c

File.mime_type

• Verwendung:MIME-Typ (Multipurpose Internet Mail Extensions) der Datei.
• Codierung:String.
• Beispiele:
  • PE
  • PDF
  • PowerShell-Script

Datei.sha1

• Verwendung:SHA-1-Hashwert der Datei.
• Codierung:String, Hexadezimal in Kleinbuchstaben.
• Beispiel:eb3520d53b45815912f2391b713011453ed8abcf

File.sha256

• Verwendung:SHA-256-Hashwert der Datei.
• Codierung:String, Hexadezimal in Kleinbuchstaben.
• Beispiel:
  • d7173c568b8985e61b4050f81b3fd8e75bc922d2a0843d7079c81ca4b6e36417

File.size

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

FTP-Metadaten einfügen

Ftp.command

• Verwendung:Hier wird der FTP-Befehl gespeichert.
• Codierung:String.
• Beispiele:
  • binary
  • Löschen
  • get
  • put

Metadaten für Gruppenpopulation

Informationen zu einer Organisationsgruppe.

Group.creation_time

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

Group.email_addresses

• Zweck:Kontaktdaten von Gruppen.
• Codierung:E-Mail.

Group.group_display_name

• Verwendung:Anzeigename der Gruppe.
• Codierung:String.
• Beispiele:
  • Finanzen
  • Personalwesen
  • Marketing

Group.product_object_id

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

Group.windows_sid

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

HTTP-Metadaten füllen

Http.method

• Verwendung:Hier wird die HTTP-Anfragemethode gespeichert.
• Codierung:String.
• Beispiele:
  • GET
  • HEAD
  • POST

Http.referral_url

• Verwendung:Hier wird die URL des HTTP-Referers gespeichert.
• Codierung:Gültige RFC 3986-URL.
• Beispiel:https://www.altostrat.com

Http.response_code

• Verwendung:Hier wird der HTTP-Antwortstatuscode gespeichert, der angibt, ob eine bestimmte HTTP-Anfrage erfolgreich abgeschlossen wurde.
• Codierung:32-Bit-Ganzzahl.
• Beispiele:
  • 400
  • 404

Http.user_agent

• Verwendung:Hier wird der User-Agent-Anfrageheader gespeichert, 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, wie Gecko)
  • Chrome/41.0.2217.0
  • Safari/527.33

Standortmetadaten bevölkern

Location.city

• Verwendung:Hier wird der Name der Stadt gespeichert.
• Codierung:String.
• Beispiele:
  • Sunnyvale
  • Chicago
  • Málaga

Location.country_or_region

• Verwendung:Hier wird der Name des Landes oder der Region gespeichert.
• Codierung:String.
• Beispiele:
  • USA
  • Vereinigtes Königreich
  • Spanien

Location.name

• Verwendung:Hier wird der unternehmensspezifische Name gespeichert, z. B. eines Gebäudes oder Campus.
• Codierung:String.
• Beispiele:
  • Campus 7B
  • Gebäude A2

Location.state

• Verwendung:Hier wird der Name des Bundesstaats, der Provinz oder des Territoriums gespeichert.
• Codierung:String.
• Beispiele:
  • Kalifornien
  • Illinois
  • Ontario

Netzwerkmetadaten ausfüllen

Network.application_protocol

• Zweck:Gibt das Netzwerkanwendungsprotokoll an.
• Codierung:Aufzählungstyp.
• Mögliche Werte:
  • UNKNOWN_APPLICATION_PROTOCOL
  • QUIC
  • HTTP
  • HTTPS
  • DNS
  • DHCP

Network.direction

• Zweck:Gibt die Richtung des Netzwerkverkehrs an.
• Encoding:Aufzählungstyp.
• Mögliche Werte:
  • UNKNOWN_DIRECTION
  • INBOUND
  • AUSGANGSRICHTUNG
  • ÜBERTRAGUNG

Network.email

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

Network.ip_protocol

• Zweck:Gibt das IP-Protokoll an.
• Encoding:Aufzählungstyp.
• 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

• Verwendung:Gibt die Anzahl der empfangenen Bytes an.
• Codierung:Vorzeichenlose 64-Bit-Ganzzahl.
• Beispiel:12.453.654.768

Network.sent_bytes

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

Network.session_duration

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

Network.session_id

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

Metadaten für Prozesse füllen

Process.command_line

• Verwendung:Hier wird der Befehlszeilenstring für den Prozess gespeichert.
• Codierung:String.
• Beispiel:c:\windows\system32\net.exe group

Process.product_specific_process_id

• Verwendung:Hier wird die produktspezifische Prozess-ID gespeichert.
• Codierung:String.
• Beispiele:MySQL:78778 oder CS:90512

Process.parent_process.product_specific_process_id

• Verwendung:Hier wird die produktspezifische Prozess-ID für den übergeordneten Prozess gespeichert.
• Codierung:String.
• Beispiele:MySQL:78778 oder CS:90512

Process.file

• Verwendung:Hier wird der Dateiname der vom Prozess verwendeten Datei gespeichert.
• Codierung:String.
• Beispiel:Bericht.xls

Process.parent_process

• Verwendung:Hier werden die Details des übergeordneten Prozesses gespeichert.
• Codierung: Substantiv (Prozess)

Process.pid

• Verwendung:Hier wird die Prozess-ID gespeichert.
• Codierung:String.
• Beispiele:
  • 308
  • 2002

Metadaten der Registry füllen

Registry.registry_key

• Verwendung:Hier wird der Registrierungsschlüssel gespeichert, der mit einer Anwendung oder Systemkomponente verknüpft ist.
• Codierung:String.
• Beispiel:HKEY_LOCAL_MACHINE/SYSTEM/DriverDatabase

Registry.registry_value_name

• Verwendung:Hier wird der Name des Registrierungswerts gespeichert, der mit einer Anwendung oder Systemkomponente verknüpft ist.
• Codierung:String.
• Beispiel:TEMP

Registry.registry_value_data

• Verwendung:Hier werden die Daten gespeichert, die mit einem Registrierungswert verknüpft sind.
• Codierung:String.
• Beispiel: %USERPROFILE%\Local Settings\Temp

Metadaten für Sicherheitsergebnisse füllen

Die Metadaten für Sicherheitsergebnisse 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.
• Encoding:Aufzählungstyp.
• Mögliche Werte:Im UDM von Google Security Operations sind die folgenden Sicherheitsaktionen definiert:
  • ZULASSEN
  • ALLOW_WITH_MODIFICATION: Die Datei oder E-Mail wurde desinfiziert oder umgeschrieben und trotzdem weitergeleitet.
  • BLOCKIEREN
  • QUARANTINE: Daten werden zur späteren Analyse gespeichert (nicht blockiert).
  • UNKNOWN_ACTION

SecurityResult.action_details

• Verwendung:Vom Anbieter bereitgestellte Details zu den Maßnahmen, die aufgrund des Sicherheitsvorfalls ergriffen wurden. Sicherheitsaktionen lassen sich am besten in das allgemeinere UDM-Feld Security_Result.action übertragen. Möglicherweise müssen Sie jedoch Regeln für die genaue vom Anbieter bereitgestellte Beschreibung der Aktion schreiben.
• Codierung:String.
• Beispiele:Drop, blockieren, entschlüsseln, verschlüsseln.

SecurityResult.category

• Zweck:Geben Sie eine Sicherheitskategorie an.
• Codierung:Aufzählung.
• Mögliche Werte:Im UDM von Google Security Operations werden die folgenden Sicherheitskategorien definiert:
  • ACL_VIOLATION: Versuchter unbefugter Zugriff, einschließlich versuchter Zugriffe auf Dateien, Webdienste, Prozesse, Webobjekte usw.
  • AUTH_VIOLATION: Die Authentifizierung ist fehlgeschlagen, z. B. aufgrund eines ungültigen Passworts oder einer ungültigen 2-Faktor-Authentifizierung.
  • DATA_AT_REST – DLP: Inaktive Sensordaten, die bei einem Scan gefunden wurden.
  • DATA_DESTRUCTION: Versuch, Daten zu zerstören/zu löschen.
  • DATA_EXFILTRATION – DLP: Sensordatenübertragung, Kopieren auf USB-Speicher
  • EXPLOIT: Versuche von Überläufen, fehlerhafte Protokollcodierungen, ROP, SQL-Injection usw., sowohl netzwerk- als auch hostbasiert.
  • MAIL_PHISHING: Phishing-E-Mails, Chatnachrichten usw.
  • MAIL_SPAM: Spam-E-Mail, -Nachricht usw.
  • MAIL_SPOOFING – gefälschte E-Mail-Adresse der Quelle usw.
  • NETWORK_CATEGORIZED_CONTENT
  • NETWORK_COMMAND_AND_CONTROL: Gibt an, ob der Befehls- und Kontrollkanal bekannt ist.
  • NETWORK_DENIAL_OF_SERVICE
  • NETWORK_MALICIOUS: Command-and-Control-Angriff, Netzwerk-Exploit, verdächtige Aktivität, potenzieller Reverse-Tunnel usw.
  • NETWORK_SUSPICIOUS: Nicht sicherheitsbezogen, z. B. wenn die URL mit Glücksspielen in Verbindung steht.
  • NETWORK_RECON: Portscan, der von einem IDS erkannt wurde, und Proben von einer Webanwendung.
  • 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, z. B. Adware
  • SOFTWARE_SUSPICIOUS
  • UNKNOWN_CATEGORY

SecurityResult.confidence

• Zweck:Gibt die vom Produkt geschätzte Wahrscheinlichkeit für ein Sicherheitsereignis an.
• Codierung:Aufzählung.
• Mögliche Werte:Im UDM von Google Security Operations werden die folgenden Kategorien für die Produktzuverlässigkeit definiert:
  • UNKNOWN_CONFIDENCE
  • LOW_CONFIDENCE
  • MEDIUM_CONFIDENCE
  • HIGH_CONFIDENCE

SecurityResult.confidence_details

• Verwendung:Zusätzliche Informationen zur Wahrscheinlichkeit eines Sicherheitsereignisses, wie vom Produktanbieter geschätzt.
• Codierung:String.

SecurityResult.priority

• Verwendung:Hiermit wird die vom Produktanbieter geschätzte Priorität eines Sicherheitsereignisses angegeben.
• Codierung:Aufzählung.
• Mögliche Werte:In der UDM von Google Security Operations werden die folgenden Produktprioritätskategorien definiert:
  • UNKNOWN_PRIORITY
  • LOW_PRIORITY
  • MEDIUM_PRIORITY
  • HIGH_PRIORITY

SecurityResult.priority_details

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

• Verwendung:Die vom Produktanbieter anhand der vom Google Security Operations-UDM definierten Werte geschätzte Schwere eines Sicherheitsereignisses.
• Codierung:Aufzählung.
• Mögliche Werte:Im UDM von Google Security Operations werden die folgenden Produktschweregrade definiert:
  • UNKNOWN_SEVERITY – Nicht schädlich
  • INFORMATIONSÜBERMITTLUNG – Nicht böswillig
  • ERROR – Nicht schädlich
  • NIEDRIG – Bösartig
  • MITTEL – Schadhaft
  • HOCH – Schadhaft

SecurityResult.severity_details

• Verwendung:Die vom Produktanbieter geschätzte Schwere eines Sicherheitsereignisses.
• Codierung:String.

SecurityResult.threat_name

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

SecurityResult.url_back_to_product

• Verwendung:URL, über die Sie zur Konsole des Quellprodukts für dieses Sicherheitsereignis weitergeleitet werden.
• Codierung:String.

Nutzermetadaten erfassen

User.email_addresses

• Verwendung:Hier werden die E-Mail-Adressen des Nutzers gespeichert.
• Codierung:Wiederholter String.
• Beispiel:[e-mail]

User.employee_id

• Verwendung:Hier wird die Mitarbeiter-ID des Nutzers gespeichert.
• Codierung:String.
• Beispiel:11223344.

User.first_name

• Verwendung:Hier wird der Vorname des Nutzers gespeichert.
• Codierung:String.
• Beispiel:Max.

User.middle_name

• Verwendung:Hier wird der zweite Vorname des Nutzers gespeichert.
• Codierung:String.
• Beispiel:Anton

User.last_name

• Verwendung:Hier wird der Nachname des Nutzers gespeichert.
• Codierung:String.
• Beispiel:Locke.

User.group_identifiers

• Verwendung:Hier werden die Gruppen-IDs (GUID, LDAP-OID oder ähnliches) gespeichert, die mit einem Nutzer verknüpft sind.
• Codierung:Wiederholter String.
• Beispiel:admin-users.

User.phone_numbers

• Verwendung:Hier werden die Telefonnummern des Nutzers gespeichert.
• Codierung:Wiederholter String.
• Beispiel:800-555-0101

User.title

• Verwendung:Hier wird der Jobtitel des Nutzers gespeichert.
• Codierung:String.
• Beispiel:Customer Relationship Manager.

User.user_display_name

• Verwendung:Hier wird der Anzeigename des Nutzers gespeichert.
• Codierung:String.
• Beispiel:John Locke.

User.userid

• Verwendung:Hier wird die Nutzer-ID gespeichert.
• Codierung:String.
• Beispiel:jlocke.

User.windows_sid

• Verwendung:Hier wird die Microsoft Windows-Sicherheits-ID (SID) gespeichert, die mit einem Nutzer verknüpft ist.
• Codierung:String.
• Beispiel:S-1-5-21-1180649209-123456789-3582944384-1064

Metadaten zur Population von Sicherheitslücken

Vulnerability.about

• Zweck:Wenn sich die Sicherheitslücke auf ein bestimmtes Nomen bezieht (z. B. ausführbar), fügen Sie es hier hinzu.
• Codierung: Substantiv. Weitere Informationen finden Sie unter Erstellen von Nomenmetadaten.
• Beispiel:ausführbar.

Vulnerability.cvss_base_score

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

Vulnerability.cvss_vector

• Verwendung:Vektor für die CVSS-Eigenschaften der Sicherheitslücke. Ein CVSS-Wert besteht aus den folgenden Messwerten:

  • Angriffsvektor (AV)
  • Zugangskomplexität (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

• Verwendung:CVSS-Version für die Bewertung oder den Vektor der Sicherheitslücke.
• Codierung:String.
• Beispiel:3.1

Vulnerability.description

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

Vulnerability.first_found

• Verwendung:Bei Produkten, für die ein Verlauf von Sicherheitslückenscans geführt wird, sollte „first_found“ mit dem Zeitpunkt ausgefüllt werden, zu dem die Sicherheitslücke für dieses Asset zum ersten Mal erkannt wurde.
• Codierung:String.

Vulnerability.last_found

• Verwendung:Bei Produkten, für die ein Verlauf von Sicherheitslückenscans geführt wird, sollte „last_found“ mit dem Zeitpunkt ausgefü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

• Verwendung:Wenn die Sicherheitslücke bei einem Asset-Scan gefunden wurde, geben Sie in dieses Feld die Uhrzeit ein, 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

• Verwendung:Wenn die Sicherheitslücke bei einem Asset-Scan erkannt wurde, geben Sie in dieses Feld die Uhrzeit ein, zu der der Scan gestartet wurde. Lassen Sie dieses Feld leer, wenn der Beginn nicht verfügbar oder nicht zutreffend ist.
• Codierung:String.

Vulnerability.severity

• Zweck:Schweregrad der Sicherheitslücke.
• Encoding:Aufzählungstyp.
• Mögliche Werte:
  • UNKNOWN_SEVERITY
  • NIEDRIG
  • MITTEL
  • HOCH

Vulnerability.severity_details

• Verwendung:Anbieterspezifische Details zur Schwere.
• Codierung:String.

Metadaten für Benachrichtigungen erstellen

Achtung: Diese Felder werden nicht mehr unterstützt. 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.
• Codierung:Boolescher Wert

idm.is_alert

• Verwendung:Gibt an, ob es sich bei dem Ereignis um eine Benachrichtigung handelt.
• Codierung:Boolescher Wert

Erforderliche und optionale Felder für jeden Ereignistyp

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

Weitere Informationen zu bestimmten UDM-Feldern finden Sie in der Liste der Felder für einheitliche Datenmodelle.

EMAIL_TRANSACTION

Pflichtfelder:

• metadata: Geben Sie die erforderlichen Felder an.
• principal: Geben Sie Informationen zum Computer an, von dem die E-Mail stammt. Beispielsweise die IP-Adresse des Absenders.

Optionale Felder:

• about: URLs, IP-Adressen, Domains und alle Dateianhänge, die im E-Mail-Text eingebettet sind.
• securityResult.about: Falsche URLs, IP-Adressen und Dateien, die im E-Mail-Text eingebettet sind.
• network.email: Informationen zum E-Mail-Absender/-Empfänger.
• principal: Wenn es Daten auf dem Clientcomputer dazu gibt, wer die E-Mail gesendet hat, füllen Sie die Serverdetails in „principal“ aus (z. B. den Clientprozess, Portnummern, Nutzername usw.).
• target: Wenn Daten zum Ziel-E-Mail-Server vorhanden sind, füllen Sie die Serverdetails in „target“ aus (z. B. die IP-Adresse).
• intermediary: Wenn es Mailserver- oder Mailproxy-Daten gibt, füllen Sie die Serverdetails unter „intermediary“ aus.

Hinweise:

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

FILE_CREATION, FILE_DELETION, FILE_MODIFICATION, FILE_READ und FILE_OPEN

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder an.
• principal:
  • Mindestens eine Maschinen-ID.
  • Optional: Geben Sie in „principal.process“ Informationen zum Prozess an, der auf die Datei zugreift.
• target:
  • Wenn die Datei remote ist (z. B. SMB-Freigabe), muss das Ziel mindestens eine Maschinen-ID für den Zielcomputer enthalten. Andernfalls müssen alle Maschinen-IDs leer sein.
  • Fülle „target.file“ mit Informationen zur Datei aus.

Optionale Felder:

• security_result: Hier wird die erkannte schädliche Aktivität beschrieben.
• principal.user: Geben Sie diesen Wert an, wenn Nutzerinformationen zum Vorgang verfügbar sind.

FILE_COPY

Pflichtfelder:

• metadata: Fügen Sie die erforderlichen Felder wie beschrieben hinzu.
• principal:
  • Mindestens eine Maschinen-ID.
  • Optional: Geben Sie in principal.process Informationen zum Prozess an, der die Dateikopiervorgänge ausführt.
• src:
  • Fügen Sie src.file Informationen zur Quelldatei hinzu.
  • Wenn die Datei remote ist (z. B. SMB-Freigabe), muss „src“ mindestens eine Maschinen-ID für den Quellcomputer enthalten, auf dem die Quelldatei gespeichert ist.
• target:
  • Fügen Sie target.file Informationen zur Zieldatei hinzu.
  • Wenn sich die Datei auf einem Remote-Gerät befindet (z. B. SMB-Freigabe), muss das Feld target mindestens eine Maschinen-ID für das Zielgerät enthalten, auf dem sich die Zieldatei befindet.

Optionale Felder:

• security_result: Hier wird die erkannte schädliche Aktivität beschrieben.
• principal.user: Geben Sie diesen Wert an, wenn Nutzerinformationen zum Vorgang verfügbar sind.

MUTEX_CREATION

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder an.
• principal:
  • Mindestens eine Maschinen-ID.
  • Geben Sie in „principal.process“ Informationen zum Prozess an, der den Mutex erstellt.
• target:
  • Geben Sie einen Wert für target.resource an.
  • Geben Sie für target.resource.type den Wert „MUTEX“ ein.
  • Geben Sie in target.resource.name den Namen des erstellten Mutex ein.

Optionale Felder:

• security_result: Hier wird die erkannte schädliche Aktivität beschrieben.
• principal.user: Geben Sie diesen Wert an, wenn Nutzerinformationen zum Vorgang verfügbar sind.

UDM-Beispiel für MUTEX_CREATION

Im folgenden Beispiel wird veranschaulicht, wie ein Ereignis vom Typ MUTEX_CREATION für das UDM von Google Security Operations formatiert wird:

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

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

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

NETWORK_CONNECTION

Pflichtfelder:

• metadata: event_timestamp
• principal: Gib Details zum Computer an, der die Netzwerkverbindung initiiert hat (z. B. die Quelle).
• target: Geben Sie Details zum Zielcomputer an, falls er sich vom Hauptcomputer unterscheidet.
• network: Hier können Sie Details zur Netzwerkverbindung erfassen (z. B. Ports und Protokolle).

Optionale Felder:

• principal.process und target.process: Prozessinformationen, die mit dem Haupt- und Ziel der Netzwerkverbindung verknüpft sind (falls verfügbar).
• principal.user und target.user: Geben Sie Nutzerinformationen an, die mit dem Haupt- und dem Ziel der Netzwerkverbindung verknüpft sind (falls verfügbar).

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

NETWORK_HTTP

Der Ereignistyp „NETWORK_HTTP“ steht für eine HTTP-Netzwerkverbindung von einem Prinzipal zu einem Ziel-Webserver.

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder an.
• 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 und eine Clientportnummer verfügbar ist, müssen nur eine IP-Adresse und die mit dieser Netzwerkverbindung verknüpfte Portnummer angegeben werden. Es können jedoch auch andere Maschinen-IDs 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. Es können jedoch mehrere andere Maschinen-IDs für das Ziel angegeben werden. Geben Sie unter „target.url“ die URL ein, auf die zugegriffen wurde.
• 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 (sofern er sich vom Principal oder Target unterscheidet).
• metadata: Fülle die anderen Metadatenfelder aus.
• network: Hier können Sie andere Netzwerkfelder ausfüllen.
• network.email: Wenn die HTTP-Netzwerkverbindung von einer URL stammt, die in einer E-Mail-Nachricht enthalten war, füllen Sie die Details in network.email 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 UDM-Format von Google Security Operations konvertiert wird.

Im Folgenden sehen Sie das ursprüngliche Sophos-Antivirenereignis:

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

So würden Sie dieselben Informationen in Proto3 mit der UDM-Syntax von Google Security Operations 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 gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Sicherheitsgerät, das das Ereignis erkannt hat.
• target: Gerät, auf das die schädliche Software gelangt ist.
• network: Netzwerkinformationen zum schädlichen Host.
• security_result: Sicherheitsdetails zur Malware.
• additional: Anbieterinformationen, die derzeit nicht in den UDM-Umfang fallen.

PROCESS_INJECTION, PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_TERMINATION, PROCESS_UNCATEGORIZED

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder an.
• principal:
  • Mindestens eine Maschinen-ID.
  • Bei Ereignissen vom Typ „Prozesseinschleusung“ und „Prozessbeendigung“ muss principal.process, sofern verfügbar, Informationen zum Prozess enthalten, der die Aktion initiiert. Bei einem Ereignis vom Typ „Prozessstart“ muss principal.process beispielsweise Details zum übergeordneten Prozess enthalten, sofern verfügbar.
• target:
  • target.process: Enthält Informationen zum Prozess, der eingefügt, geöffnet, gestartet oder beendet wird.
  • Wenn der Zielprozess remote ist, muss „target“ mindestens eine Maschinen-ID für den Zielcomputer enthalten, z. B. eine IP-Adresse, MAC, Hostname oder Asset-ID eines Drittanbieters.

Optionale Felder:

• security_result: Hier wird die erkannte schädliche Aktivität beschrieben.
• principal.user und target.user: Geben Sie den auslösenden Prozess (principal) und den Zielprozess an, sofern die Nutzerinformationen verfügbar sind.

UDM-Beispiel für PROCESS_LAUNCH

Im folgenden Beispiel wird gezeigt, wie Sie ein PROCESS_LAUNCH-Ereignis mit der UDM-Syntax von Google Security Operations formatieren:

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

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

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Gerätedetails.
• target: Verarbeitungsdetails.

PROCESS_MODULE_LOAD

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder an.
• principal:
  • Mindestens eine Maschinen-ID.
  • principal.process: Prozess, der das Modul lädt.
• target:
  • target.process: Enthält Informationen zum Prozess.
  • target.process.file: Geladenes Modul (z. B. die DLL oder das freigegebene Objekt).

Optionale Felder:

• security_result: Hier wird die erkannte schädliche Aktivität beschrieben.
• principal.user: Geben Sie diesen Wert an, wenn Nutzerinformationen zum Vorgang verfügbar sind.

UDM-Beispiel für PROCESS_MODULE_LOAD

Im folgenden Beispiel wird gezeigt, wie Sie ein PROCESS_MODULE_LOAD-Ereignis mit der UDM-Syntax von Google Security Operations 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 gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Details zum Gerät und zum Prozess, mit dem das Modul geladen wird.
• target: Prozess- und Moduldetails.

PROCESS_PRIVILEGE_ESCALATION

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder an.
• principal:
  • Mindestens eine Maschinen-ID.
  • principal.process: Prozess, der das Modul lädt.
  • principal.user: Nutzer, der das Modul lädt.

Optionale Felder:

• security_result: Hier wird die erkannte schädliche Aktivität beschrieben.

UDM-Beispiel für PROCESS_PRIVILEGE_ESCALATION

Im folgenden Beispiel wird gezeigt, wie Sie ein PROCESS_PRIVILEGE_ESCALATION-Ereignis mit der UDM-Syntax von Google Security Operations 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 gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

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

REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder an.
• principal:
  • Mindestens eine Maschinen-ID.
  • Wenn die Registrierungsänderung von einem Prozess im Nutzermodus ausgeführt wird, muss principal.process Informationen zum Prozess enthalten, der die Registrierung ändert.
  • Wenn die Registrierungsänderung von einem Kernelprozess ausgeführt wird, darf der Principal keine Prozessinformationen enthalten.
• target:
  • target.registry: Wenn die Zielregistrierung remote ist, muss „target“ mindestens eine Kennung für den Zielcomputer enthalten, z. B. eine IP-Adresse, MAC, Hostname oder Asset-ID 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. Beispielsweise ein fehlerhafter Registrierungsschlüssel.
• principal.user:Geben Sie einen Wert an, wenn Nutzerinformationen zum Vorgang verfügbar sind.

UDM-Beispiel für REGISTRY_MODIFICATION

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

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

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

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

SCAN_FILE, SCAN_HOST, SCAN_PROCESS, SCAN_VULN_HOST, SCAN_VULN_NETWORK

Pflichtfelder:

• extensions: Definieren Sie für SCAN_VULN_HOST und SCAN_VULN_NETWORK die Sicherheitslücke mit dem Feld „extensions.vuln“.
• metadata: event_timestamp
• observer: Hiermit werden Informationen zum Scanner selbst erfasst. Wenn sich der Scanner nicht lokal befindet, müssen die Gerätedetails im Feld „Observer“ erfasst werden. Bei einem lokalen Scanner lassen Sie das Feld leer.
• target: Hiermit werden Informationen zum Computer erfasst, auf dem sich das gescannte Objekt befindet. Wenn eine Datei gescannt wird, muss „target.file“ Informationen zur gescannten Datei erfassen. Wenn ein Prozess gescannt wird, muss „target.process“ Informationen zu diesem Prozess erfassen.

Optionale Felder:

• target: Nutzerdetails zum Zielobjekt (z. B. Dateiersteller oder Prozessinhaber) sollten in „target.user“ erfasst werden.
• security_result: Hier wird die erkannte schädliche Aktivität beschrieben.

UDM-Beispiel für SCAN_HOST

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

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

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

• metadata: Hintergrundinformationen zum Ereignis.
• target: Gerät, auf das die schädliche Software gelangt ist.
• observer: Gerät, das das betreffende Ereignis beobachtet und meldet.
• security_result: Sicherheitsdetails zur Malware.

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- und eine Nutzer-ID enthalten.
• target: Das Ziel muss eine gültige Ressource und einen als „TASK“ definierten Ressourcentyp enthalten.

Optionale Felder:

• security_result: Hier wird die erkannte schädliche Aktivität beschrieben.

UDM-Beispiel für SCHEDULED_TASK_CREATION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SCHEDULED_TASK_CREATION für das UDM von Google Security Operations 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 gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Das Gerät, auf dem die verdächtige Aufgabe geplant wurde.
• target: Software, auf die die verdächtige Aufgabe ausgerichtet ist.
• intermediary: Mittler, 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, nicht leer und eine Maschinen-ID enthalten.
• target: Muss vorhanden und nicht leer sein und eine Ressource mit dem Typ SETTING enthalten.

UDM-Beispiel für den Ereignistyp SETTING_MODIFICATION

Im folgenden Beispiel wird gezeigt, wie ein Ereignis vom Typ SETTING_MODIFICATION für die 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 gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

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

SERVICE_UNSPECIFIED, SERVICE_CREATION, SERVICE_DELETION, SERVICE_START, SERVICE_STOP

Pflichtfelder:

• target: Geben Sie die Nutzer-ID an und geben Sie entweder „process“ oder „application“ an.
• 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 die UDM von Google Security Operations 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 gezeigt, wurde das Ereignis in die folgenden UDM-Kategorien unterteilt:

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

STATUS_HEARTBEAT, STATUS_STARTUP, STATUS_SHUTDOWN, STATUS_UPDATE

Pflichtfelder:

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

UDM-Beispiel für STATUS_HEARTBEAT

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

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

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

• metadata: Hintergrundinformationen zum Ereignis.
• principal: Geräte- und Standortdetails.
• intermediary: 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 am Protokoll ausgeführt hat, und eine Maschinen-ID für den Computer, auf dem das Protokoll gespeichert ist oder war (beim Löschen).

UDM-Beispiel für SYSTEM_AUDIT_LOG_WIPE

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SYSTEM_AUDIT_LOG_WIPE für die UDM von Google Security Operations formatiert wird:

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

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

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

USER_CHANGE_PASSWORD, USER_CHANGE_PERMISSIONS

Pflichtfelder:

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

USER_COMMUNICATION

Pflichtfelder:

• principal:Geben Sie im Feld principal.user Details zu nutzerinitiierter (Absender) Kommunikation ein, z. B. zu einer Chatnachricht in Google Chat oder Slack, einer Video- oder Sprachkonferenz in Zoom oder Google Meet oder einer VoIP-Verbindung.

Optionale Felder:

• target: (Empfohlen) Geben Sie im Feld target.user Informationen zum Zielnutzer (Empfänger) der Cloud-Kommunikationsressource ein. Geben Sie im Feld target.application Informationen zur Ziel-Cloud-Kommunikationsanwendung ein.

USER_CREATION, USER_DELETION

Pflichtfelder:

• metadata:event_timestamp
• principal:Gibt Informationen zum Computer an, von dem aus 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 den Ursprungscomputer 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 gestartet wurde.
• target:Informationen zum Zielcomputer (falls er sich vom Hauptcomputer unterscheidet).

USER_LOGIN, USER_LOGOUT

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder an.
• principal: Geben Sie für Remote-Nutzeraktivitäten (z. B. Remote-Anmeldung) Informationen zum Computer an, von dem die Nutzeraktivität ausgeht. Legen Sie für lokale Nutzeraktivitäten (z. B. lokale Anmeldung) keinen Hauptbenutzer fest.
• target: Geben Sie in „target.user“ Informationen zum Nutzer ein, der sich angemeldet oder abgemeldet hat. Wenn „principal“ nicht festgelegt ist (z. B. lokale Anmeldung), muss „target“ auch mindestens eine Maschinen-ID enthalten, die den Zielcomputer 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 der 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 eintragen.
• Erweiterung authentication: Muss den Typ des Authentifizierungssystems angeben, mit dem das Ereignis zusammenhängt (z. B. Maschine, SSO oder VPN) und den verwendeten Mechanismus (Nutzername und Passwort, OTP usw.).
• security_result: Fügen Sie ein Feld „security_result“ hinzu, um den Anmeldestatus anzugeben, falls 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:Geben Sie im Feld principal.user Details zu Zugriffsversuchen auf eine Cloud-Ressource ein (z. B. einen Salesforce-Fall, einen Office 365-Kalender, ein Google-Dokument oder ein ServiceNow-Ticket).
• target:Geben Sie im Feld target.resource Informationen zur Ziel-Cloud-Ressource ein.

Optionale Felder:

• target.application: (Empfohlen) Geben Sie im Feld target.application Informationen zur Ziel-Cloud-Anwendung ein.

USER_RESOURCE_CREATION, USER_RESOURCE_DELETION

Pflichtfelder:

• principal:Geben Sie im Feld principal.user Details zum Nutzer ein, der in einer Cloud-Ressource erstellt wurde (z. B. ein Salesforce-Fall, ein Office 365-Kalender, ein Google-Dokument oder ein ServiceNow-Ticket).
• target:Geben Sie im Feld target.resource Informationen zur Ziel-Cloud-Ressource ein.

Optionale Felder:

• target.application: (Empfohlen) Geben Sie im Feld target.application Informationen zur Ziel-Cloud-Anwendung ein.

USER_RESOURCE_UPDATE_CONTENT

Pflichtfelder:

• principal:Geben Sie im Feld principal.user Details zum Nutzer ein, dessen Inhalte in einer Cloud-Ressource aktualisiert wurden (z. B. ein Salesforce-Fall, ein Office 365-Kalender, ein Google-Dokument oder ein ServiceNow-Ticket).
• target:Geben Sie im Feld target.resource Informationen zur Ziel-Cloud-Ressource ein.

Optionale Felder:

• target.application: (Empfohlen) Geben Sie im Feld target.application Informationen zur Ziel-Cloud-Anwendung ein.

USER_RESOURCE_UPDATE_PERMISSIONS

Pflichtfelder:

• principal:Geben Sie im Feld principal.user Details zum Nutzer ein, dessen Berechtigungen in einer Cloud-Ressource aktualisiert wurden, z. B. ein Salesforce-Fall, ein Office 365-Kalender, ein Google-Dokument oder ein ServiceNow-Ticket.
• target:Geben Sie im Feld target.resource Informationen zur Ziel-Cloud-Ressource ein.

Optionale Felder:

• target.application: (Empfohlen) Geben Sie im Feld target.application Informationen zur Ziel-Cloud-Anwendung ein.

USER_UNCATEGORIZED

Pflichtfelder:

• metadata:event_timestamp
• principal:Gibt Informationen zum Computer an, von dem aus 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 den Ursprungscomputer 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 gestartet wurde.
• target:Informationen zum Zielcomputer (falls er sich vom Hauptcomputer unterscheidet).