Leitfaden zur Verwendung des einheitlichen Datenmodells

In diesem Dokument finden Sie eine detailliertere Beschreibung der Felder im UDM-Schema (Unified Data Model) und welche Felder je nach Ereignistyp erforderlich oder optional sind. Bei der Auswertung durch die Rules Engine beginnt das Präfix mit udm., während das Präfix für den konfigurationsbasierten Normalizer (CBN) mit event.idm.read_only_udm. beginnt.

Ereignismetadaten ausfüllen

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

Metadata.event_type

• Zweck:Gibt den Ereignistyp an. Wenn ein Ereignis mehrere mögliche Typen hat, muss mit diesem Wert der spezifischste Typ angegeben werden.
• Erforderlich:Ja
• Encoding: Muss einer der vordefinierten UDM-Ereignistypen sein.
• Mögliche Werte:In der folgenden Liste sind alle möglichen Werte für „event_type“ in der UDM aufgeführt.

Analysten-Ereignisse:

• 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

Ereignisse, die nicht angegeben sind:

• EVENTTYPE_UNSPECIFIED

Dateiereignisse, die an 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. zum 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 (gegenseitiges Ausschlussobjekt):

• 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. Details zur Netzwerkverbindung einer Firewall)
• NETWORK_DHCP
• NETWORK_DNS
• NETWORK_FLOW (z. B. aggregierte Flussstatistiken von Netflow)
• NETWORK_FTP
• NETWORK_HTTP
• NETWORK_SMTP

Alle Ereignisse im Zusammenhang mit einem Prozess, z. B. das Starten eines Prozesses, ein Prozess, der etwas Schadsoftware erzeugt, ein Prozess, der in einen anderen Prozess eingeschleust wird, eine Änderung 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

Verwenden Sie die REGISTRY-Ereignisse anstelle der SETTING-Ereignisse, wenn Sie mit Microsoft Windows-spezifischen Registrierungsereignissen arbeiten:

• REGISTRY_UNCATEGORIZED
• REGISTRY_CREATION
• REGISTRY_MODIFICATION
• REGISTRY_DELETION

Ressourcenereignisse:

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Scan-orientierte Ereignisse Umfasst On-Demand-Scans und Verhaltenserkennungen von Endpunktsicherheitsprodukten (EDR, AV, DLP). 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

Ereignisse festlegen, z. B. wenn eine Systemeinstellung auf einem Endpunkt geändert wird. Weitere Informationen zum Festlegen von Ereignisanforderungen finden Sie hier.

• SETTING_UNCATEGORIZED
• SETTING_CREATION
• SETTING_DELETION
• SETTING_MODIFICATION

Statusmeldungen von Sicherheitsprodukten, um anzuzeigen, dass Kundenservicemitarbeiter aktiv sind, und um Version, Fingerabdruck oder andere Datentypen zu senden.

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

Ereignisse im System-Audit-Log:

• SYSTEM_AUDIT_LOG_UNCATEGORIZED
• SYSTEM_AUDIT_LOG_WIPE

Ereignisse zu Nutzerauthentifizierungsaktivitäten:

• 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

• Zweck: Codiert den GMT-Zeitstempel, wenn das Ereignis von der lokalen Datenerfassungsinfrastruktur 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, entsprechend dem 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, aussagekräftiger, visuell lesbarer und produktspezifischer Ereignisname oder -typ.
• Codierung: Alphanumerischer String, Satzzeichen zulässig, maximal 64 Byte.
• Beispiele:
  • Ereignis zur Registry-Erstellung
  • 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: alphanumerischer String mit Groß-/Kleinschreibung, Zeichensetzung zulässig, maximal 256 Byte.
• Beispiel: ABcd1234-98766

Metadata.product_name

• Zweck: Gibt den Namen des Produkts an.
• Codierung: Groß- und Kleinschreibung beachten, 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, die auf eine relevante Website verlinkt, auf der Sie weitere Informationen zu dieser speziellen Veranstaltung oder zur allgemeinen Ereigniskategorie finden können.
• 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: alphanumerischer String mit Groß-/Kleinschreibung, Zeichensetzung zulässig, maximal 256 Byte
• Beispiele:
  • CrowdStrike
  • Symantec

Bevölkerung der Substantive-Metadaten

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 Protokolldaten 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 die Groß-/Kleinschreibung nicht berücksichtigt* *Anbietername wie „Carbon Black“, ProductName ein Produktname, bei dem die Groß-/Kleinschreibung nicht berücksichtigt wird, z. B. „Response“ oder „Endpunktschutz“. Die ID ist eine anbieterspezifische Kundenkennung, die in der Kundenumgebung global eindeutig ist (z. B. eine GUID oder ein eindeutiger Wert zur Identifizierung eines 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
• Siehe Füllung von Dateimetadaten.

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

• Zweck:Plattformbetriebssystem.
• Codierung: Enum
• Mögliche Werte:
  • LINUX
  • MAC
  • WINDOWS
  • UNKNOWN_PLATFORM

Noun.platform_patch_level

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

Noun.platform_version

• Zweck: Version des Plattformbetriebssystems.
• 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 zwischen 1 und 65.535.

• Beispiele:

  • 80
  • 443
  Hinweis: Wenn eine Portnummer angegeben ist, darf nur eine IP-Adresse im selben Substantiv angegeben werden.

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 Domainnamenstring mit maximal 128 Zeichen
• Beispiel: corp.altostrat.com

Noun.registry

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

Noun.url

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

Noun.user

• Zweck: Detaillierte Nutzermetadaten.
• Typ: Objekt
• Siehe Füllung 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 bestimmte Anmeldedaten.
• Encoding: Aufzählungstyp.
• Mögliche Werte:
  • UNKNOWN_AUTHENTICATION_STATUS – Standardauthentifizierungsstatus
  • AKTIV: Die Authentifizierungsmethode ist aktiv.
  • SUSPENDED: Die Authentifizierungsmethode befindet sich im Status „Gesperrt“ oder „Deaktiviert“.
  • DELETED: 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 im Cache gespeicherten Anmeldedaten
  • HARDWARE_KEY
  • LOKALES WERBENETZWERK
  • MECHANISM_OTHER: Ein anderer Mechanismus, der hier nicht definiert ist.
  • NETWORK: Netzwerkauthentifizierung
  • NETWORK_CLEAR_TEXT: Klartextauthentifizierung im Netzwerk.
  • 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

Ausfüllen von DHCP-Metadaten

Die DHCP-Metadatenfelder (Dynamic Host Control Protocol) erfassen Protokollinformationen des DHCP-Netzwerkverwaltungsprotokolls.

Dhcp.client_hostname

• Verwendung: Hostname für den Client. Weitere Informationen finden Sie unter RFC 2132, DHCP-Optionen und BOOTP-Anbietererweiterungen.
• Codierung: String.

Dhcp.client_identifier

• Zweck: Client-ID. Weitere Informationen finden Sie unter RFC 2132, DHCP-Optionen und BOOTP-Anbietererweiterungen.
• 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 Hardware-Adresse.
• Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.hops

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

Dhcp.htype

• Zweck: Hardware-Adresstyp.
• Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.lease_time_seconds

• Zweck:Vom Client angeforderte Freigabezeit für eine IP-Adresse in Sekunden. Weitere Informationen finden Sie unter RFC 2132, DHCP-Optionen und BOOTP-Anbietererweiterungen.
• Codierung: Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.opcode

• Verwendung: BOOTP-Op-Code (siehe Abschnitt 3 von RFC 951).
• Codierung:Enumerationstyp.
• Mögliche Werte:
  • UNKNOWN_OPCODE
  • BOOTREQUEST
  • SCHNELLANTWORT

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

• Zweck: Die Anzahl der Sekunden, die seit Beginn der Adresserfassung/-verlängerung durch den Kunden verstrichen sind.
• Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Dhcp.sname

• Zweck:Name des Servers, von dem der Client das Booten angefordert hat.
• Codierung: String.

Dhcp.transaction_id

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

Dhcp.type

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

Dhcp.chaddr

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

dhcp.ciaddr

• Zweck: IP-Adresse für den Client.
• 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

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

dhcp.yiaddr

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

Metadaten für DHCP-Optionen füllen

Die Metadatenfelder der DHCP-Option erfassen die Protokollinformationen der DHCP-Option.

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

• Zweck:Speichert die Daten der DHCP-Option. Weitere Informationen finden Sie in RFC 1533, DHCP Options and BOOTP Vendor Extensions (DHCP-Optionen und BOOTP-Anbietererweiterungen).
• Codierung: Byte.

DNS-Metadaten erfassen

Die DNS-Metadatenfelder enthalten 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

• Zweck: Speichert die DNS-Abfrage-ID.
• 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: Boolescher Wert.

Dns.recursion_desired

• Verwendung: Legen Sie diesen Wert auf „wahr“ fest, wenn ein rekursiver DNS-Lookup angefordert wird.
• Codierung: Boolescher Wert.

Dns.response_code

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

Dns.truncated

• Zweck: Legen Sie diesen Wert auf „true“ fest, wenn dies eine abgeschnittene DNS-Antwort ist.
• 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

• Zweck: Speichert die Antwort auf die Suchanfrage zum Domainnamen. 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 Metadatenfelder der DNS-Fragen erfassen die Informationen, die im Fragenabschnitt einer Domainprotokollnachricht enthalten sind.

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.

Ausfüllen von DNS-Ressourceneintragsmetadaten

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

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

ResourceRecord.class

• Zweck:Speichert den Code, 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 vorgesehen ist, enthält er möglicherweise einen anderen Domainnamen, wenn ein Domainname zu einem anderen Domainnamen weitergeleitet wird. Die Daten müssen genauso wie die DNS-Antwort gespeichert werden.
• Codierung: String.

ResourceRecord.name

• Zweck: Speichert den Namen des Eigentümers des Ressourceneintrags.
• Codierung: String.

ResourceRecord.ttl

• Zweck: Speichert das Zeitintervall, in dem der Ressourceneintrag im Cache gespeichert werden kann, bevor die Quelle der Informationen noch einmal abgefragt werden soll.
• Codierung: 32-Bit-Ganzzahl.

ResourceRecord.type

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

Anzahl der E-Mail-Metadaten

Die meisten Felder für E-Mail-Metadaten erfassen die E-Mail-Adressen im Nachrichtenheader und sollten dem in RFC 5322 definierten Standardformat für E-Mail-Adressen (local-mailbox@domain) entsprechen. 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

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

Email.bcc

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

Email.mail_id

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

Email.subject

• 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 aus Gründen der Nutzerfreundlichkeit und der Kompatibilität mit Dataset-übergreifenden Regeln immer noch in auth.type oder auth.mechanism generalisiert werden.
• Codierung: String.
• Beispiele: via_mfa, via_ad.

Extensions.vulns

• Zweck: Erweiterung der Sicherheitslückenmetadaten.
• Codierung: String.
• Beispiel:
  • Daten zum Scannen auf Sicherheitslücken auf dem Host.

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

• Zweck:Vollständiger Pfad zur Angabe des Speicherorts der Datei im System.
• 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

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

File.sha1

• Verwendung: SHA-1-Hashwert der 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 einfügen

Ftp.command

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

Befüllung der Gruppenmetadaten

Informationen zu einer Organisationsgruppe.

Group.creation_time

• Zweck: Erstellungszeit der Gruppe
• Codierung:RFC 3339, entsprechend dem JSON- oder Proto3-Zeitstempelformat.

Group.email_addresses

• Zweck:Gruppenkontaktdaten.
• Codierung: E-Mail.

Group.group_display_name

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

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

Auffüllen von HTTP-Metadaten

Http.method

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

Http.referral_url

• Zweck:Speichert die URL für die HTTP-Referrer-URL.
• 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

• 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

Befüllung 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

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

Location.state

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

Netzwerkmetadaten ausfüllen

Network.application_protocol

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

Network.direction

• Zweck: Gibt die Richtung des Netzwerkverkehrs an.
• Codierung:Enumerationstyp.
• Mögliche Werte:
  • UNKNOWN_DIRECTION
  • INBOUND
  • OUTBOUND (OUTBOUND)
  • ÜBERTRAGUNG

Network.email

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

Network.ip_protocol

• Zweck: Gibt das IP-Protokoll an.
• Codierung: Aufzählungstyp.
• Mögliche Werte:
  • UNKNOWN_IP_PROTOCOL
  • EIGRP – Enhanced Interior Gateway Routing Protocol
  • ESP – Encapsulating Security Payload
  • ETHERIP – Ethernet-in-IP-Kapselung
  • GRE – generische Routing-Kapselung
  • 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

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

Network.session_duration

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

Network.session_id

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

Ausfüllen von Prozessmetadaten

Process.command_line

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

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

• Zweck: Speichert den Dateinamen der vom Prozess verwendeten Datei.
• Codierung: String.
• Beispiel:report.xls

Process.parent_process

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

Process.pid

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

Ausfüllen 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

• 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

• Zweck: Speichert die mit einem Registry-Wert verknüpften Daten.
• Codierung: String.
• Beispiel: %USERPROFILE%\Local Settings\Temp

Ausfüllen von Metadaten für Sicherheitsergebnisse

Die Metadaten der Sicherheitsergebnisse enthalten Details zu Sicherheitsrisiken und Bedrohungen, die von einem Sicherheitssystem gefunden wurden, sowie die 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:Enumerationstyp.
• Mögliche Werte:Google Security Operations UDM definiert die folgenden Sicherheitsaktionen:
  • ZULASSEN
  • ALLOW_WITH_MODIFICATION: Datei oder E-Mail wurde desinfiziert oder neu geschrieben und weiterhin weitergeleitet.
  • BLOCKIEREN
  • QUARANTÄNE – Für spätere Analyse speichern (bedeutet nicht „Sperren“).
  • UNKNOWN_ACTION

SecurityResult.action_details

• Zweck:Vom Anbieter bereitgestellte Details zu den Maßnahmen, die infolge 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, auf USB-Stick kopieren.
  • 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-Angriffe, Netzwerkausnutzung, verdächtige Aktivitäten, potenzieller Reverse-Tunnel usw.
  • NETWORK_SUSPICIOUS: Nicht sicherheitsbezogen, z. B. mit Glücksspiel.
  • 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: Geben Sie eine Konfidenz in Bezug auf ein Sicherheitsereignis an, die vom Produkt geschätzt wird.
• Codierung: Enum.
• Mögliche Werte: Im UDM von Google Security Operations werden die folgenden Produktvertrauenskategorien 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: Hier wird die vom Produktanbieter geschätzte Priorität eines Sicherheitsereignisses angegeben.
• Codierung: Enum.
• 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

• Zweck: Anbieterspezifische Informationen zur Priorität der Sicherheitsergebnisse.
• 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
  • INFORMATIONEN – nicht böswillig
  • FEHLER – nicht böswillig
  • NIEDRIG – Bösartig
  • MITTEL – Bösartig
  • HOCH – Malware

SecurityResult.severity_details

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

SecurityResult.threat_name

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

SecurityResult.url_back_to_product

• Zweck:URL, über die Sie für dieses Sicherheitsereignis zur Quellproduktkonsole 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

• Zweck:Speichert den zweiten Vornamen für den Nutzer.
• Codierung: String.
• Beispiel:Anthony.

User.last_name

• Zweck:Speichert den Nachnamen des Nutzers.
• 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

• Zweck:Speichert die Telefonnummern für den Nutzer.
• 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

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

Daten zu Sicherheitslücken

Vulnerability.about

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

Vulnerability.cvss_base_score

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

Vulnerability.cvss_vector

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

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

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

• 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

• Zweck: Wenn die Sicherheitslücke während eines Asset-Scans entdeckt 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.
• Codierung:Enumerationstyp.
• Mögliche Werte:
  • UNKNOWN_SEVERITY
  • NIEDRIG
  • MITTEL
  • HOCH

Vulnerability.severity_details

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

Darstellung von Benachrichtigungsmetadaten

Achtung :Diese Felder wurden verworfen. 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 basierend auf dem Ereignistyp

In diesem Abschnitt werden die Pflichtfelder und die optionalen Felder beschrieben, die ausgefüllt werden müssen abhängig vom UDM-Ereignistyp. Eine Beschreibung dieser Felder finden Sie in der Feldliste für einheitliche Datenmodelle.

EMAIL_TRANSACTION

Pflichtfelder:

• metadata: Geben Sie die Pflichtfelder 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, die Portnummern, den Nutzernamen usw.).
• target: Wenn Daten des Ziel-E-Mail-Servers vorhanden sind, füllen Sie den Server mit Daten aus. Details im Ziel (z. B. die IP-Adresse)
• intermediary: Wenn es Mailserver- oder E-Mail-Proxy-Daten gibt, füllen Sie mit den Serverdetails.

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 ein Nomen (optional für Spam).

FILE_CREATION, FILE_DELETION, FILE_MODIFICATION, FILE_READ und FILE_OPEN

Pflichtfelder:

• metadata: Pflichtfelder sind erforderlich.
• principal:
  • Mindestens eine Maschinen-ID.
  • (Optional) Füllen Sie principal.process mit Informationen zum Prozess aus. auf die Datei zugreifen können.
• target [Ziel]:
  • Bei einer Remote-Datei (z. B. SMB-Freigabe) muss das Ziel Folgendes enthalten: mindestens eine Maschinen-ID für die Zielmaschine, andernfalls alle Maschinen-IDs müssen leer sein.
  • Fülle „target.file“ mit Informationen zur Datei aus.

Optional:

• security_result: Beschreibe die erkannte schädliche Aktivität.
• principal.user: Dieses Feld wird ausgefüllt, wenn Nutzerinformationen für den Nutzer verfügbar sind. .

FILE_COPY

Pflichtfelder:

• metadata: Füge die erforderlichen Felder wie beschrieben ein.
• Hauptkonto:
  • Mindestens eine Maschinen-ID.
  • Optional: Geben Sie in principal.process Informationen zum Prozess an, der die Dateikopiervorgänge ausführt.
• src:
  • Füllen Sie src.file mit Informationen zur Quelldatei.
  • 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üllen Sie target.file mit Informationen zur Zieldatei.
  • Bei einer Remote-Datei, z. B. bei der SMB-Freigabe, muss das Feld target muss mindestens eine Maschinen-ID für die Zielmaschine enthalten, enthält die Zieldatei.

Optionale Felder:

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

MUTEX_CREATION

Pflichtfelder:

• metadata: Pflichtfelder sind erforderlich.
• 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.
  • Füllen Sie target.resource.type mit MUTEX.
  • Geben Sie in target.resource.name den Namen des erstellten Mutex ein.

Optional:

• security_result: Beschreibe die erkannte schädliche Aktivität.
• principal.user: Dieses Feld wird ausgefüllt, wenn Nutzerinformationen für den Nutzer verfügbar sind. .

UDM-Beispiel für MUTEX_CREATION

Das folgende Beispiel zeigt, wie ein Ereignis des Typs MUTEX_CREATION formatiert für Google Security Operations UDM:

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 folgende UDM unterteilt: Kategorien:

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

NETWORK_CONNECTION

Pflichtfelder:

• metadata: event_timestamp
• Principal (Hauptkonto): Geben Sie Details zur Maschine an, die das Netzwerk initiiert hat Verbindung (z. B. 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 Ziel der Netzwerkverbindung verknüpft sind (falls verfügbar).

Hinweis: Wenn für den Haupt- oder Zielknoten ein Port angegeben ist, müssen die Felder ip und mac für alle Netzwerkereignisse 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 können Sie eine beliebige Anzahl von IP-Adressen und MACs angeben, die mit dem Parameter Gerät zum Zeitpunkt des Ereignisses verwenden (keine spezielle Bestellung erforderlich).

NETWORK_HTTP

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

Pflichtfelder:

• metadata: Pflichtfelder sind erforderlich.
• 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: Steht für den Webserver 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. Die folgenden Felder müssen ausgefüllt werden:
  • network.ip_protocol
  • network.application_protocol
  • network.http.method

Optionale Felder:

• about: Steht für andere Entitäten in der HTTP-Transaktion (für z. B. eine hochgeladene oder heruntergeladene Datei).
• intermediary: Steht für einen Proxyserver (falls abweichend vom Hauptkonto). oder Ziel).
• 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 des Typs NETWORK_HTTP wird in das UDM-Format von Google Security Operations konvertiert.

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 formatieren Sie dieselben Informationen in Proto3 mithilfe der Google Security Operations-Tools UDM-Syntax:

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

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

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

network {
  ip_protocol: TCP
 }

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

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

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

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

PROCESS_INJECTION, PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_TERMINATION, PROCESS_UNCATEGORIZED

Pflichtfelder:

• metadata: Pflichtfelder sind erforderlich.
• principal:
  • Mindestens eine Maschinen-ID.
  • Für Ereignisse zur Injektion von Prozessen und Beendigungen von Prozessen, falls verfügbar, principal.process muss Informationen zum Prozess enthalten. Initiieren der Aktion (z. B. bei einem Prozesseinführungsereignis, principal.process muss Details zum übergeordneten Prozess enthalten, wenn verfügbar).
• target [Ziel]:
  • target.process: Enthält Informationen zum aktuellen Prozess. eingefügt, geöffnet, gestartet oder beendet.
  • Wenn der Zielprozess remote ist, muss das Ziel mindestens einen Maschinen-ID der Zielmaschine (z. B. IP-Adresse, MAC-Adresse, Hostname oder Asset-ID eines Drittanbieters).

Optionale Felder:

• security_result: Beschreibt die erkannte schädliche Aktivität.
• principal.user und target.user: Geben Sie den ausführenden 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: Pflichtfelder sind erforderlich.
• principal:
  • Mindestens eine Maschinen-ID.
  • principal.process: Prozess zum Laden des Moduls.
• target [Ziel]:
  • target.process: Enthält Informationen zum Prozess.
  • target.process.file: Geladenes Modul (z. B. die DLL oder das freigegebene Objekt).

Optionale Felder:

• security_result: Beschreibe die erkannte schädliche Aktivität.
• principal.user: Dieses Feld wird ausgefüllt, wenn Nutzerinformationen für den Nutzer 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 folgende UDM unterteilt: Kategorien:

• metadata: Hintergrundinformationen zum Ereignis.
• Principal: Details zum Gerät und zum Prozess zum Laden des Moduls.
• target: Prozess- und Moduldetails.

PROCESS_PRIVILEGE_ESCALATION

Pflichtfelder:

• metadata: Pflichtfelder sind erforderlich.
• principal:
  • Mindestens eine Maschinen-ID.
  • principal.process: Prozess zum Laden des Moduls.
  • principal.user: Nutzer, der das Modul lädt.

Optionale Felder:

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

UDM-Beispiel für PROCESS_PRIVILEGE_ESCALATION

Das folgende Beispiel zeigt, wie Sie ein PROCESS_PRIVILEGE_ESCALATION mit der Google Security Operations UDM-Syntax:

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 zum Laden des -Modul.
• target: Prozess- und Moduldetails.

REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION

Pflichtfelder:

• metadata: Pflichtfelder sind erforderlich.
• principal:
  • Mindestens eine Maschinen-ID.
  • Führt ein Prozess im Nutzermodus die Registrierungsänderung durch, principal.process muss Informationen zum Prozess enthalten. Änderung der Registrierung.
  • Wenn ein Kernel-Prozess die Registrierungsänderung durchführt, principal darf 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.

Optional:

• security_result::Beschreibe die erkannte schädliche Aktivität. Beispiel: Einen fehlerhaften Registrierungsschlüssel.
• principal.user::Dieses Feld wird ausgefüllt, wenn Nutzerinformationen für das Element 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ücken mithilfe des Felds extensions.vuln.
• metadata: event_timestamp
• observer: Hiermit werden Informationen zum Scanner selbst erfasst. Wenn der Scanner extern erfolgt, müssen die Maschinendetails im Beobachterfeld 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. Beim Scannen einer Datei muss target.file erfassen, Informationen zur gescannten Datei. Wenn ein Prozess gescannt wird, muss „target.process“ Informationen zu diesem Prozess erfassen.

Optionale Felder:

• target: Nutzerdetails zum Zielobjekt, z. B. Ersteller der Datei oder Process Owner) in target.user erfasst werden.
• security_result: Beschreibt die erkannte schädliche Aktivität.

UDM-Beispiel für SCAN_HOST

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SCAN_HOST für das 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 folgende UDM unterteilt: Kategorien:

• metadata: Hintergrundinformationen zum Ereignis.
• target: Gerät, auf das die schädliche Software gelangt ist.
• Beobachter: 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: Ziel muss eine gültige Ressource und einen definierten Ressourcentyp enthalten. als „Aufgabe“.

Optionale Felder:

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

UDM-Beispiel für SCHEDULED_TASK_CREATION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SCHEDULED_TASK_CREATION für das UDM für 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 abzielt.
• 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 und nicht leer sein 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

Das folgende Beispiel zeigt, 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 zu dem Gerät, auf dem die Einstellung geändert wurde.
• target: Ressourcendetails.

SERVICE_UNSPECIFIED, SERVICE_CREATION, SERVICE_DELETION, SERVICE_START, SERVICE_STOP

Pflichtfelder:

• target: Fügen Sie die Nutzer-ID ein und geben Sie entweder den Prozess oder die Anwendung 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 Google Security Operations UDM formatiert:

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: Name der Anwendung und Ressourcentyp.

STATUS_HEARTBEAT, STATUS_STARTUP, STATUS_SHUTDOWN, STATUS_UPDATE

Pflichtfelder:

• metadata: Pflichtfelder sind erforderlich.
• Hauptkonto: Mindestens eine Maschinen-ID (IP- oder MAC-ADRESSE, Hostname, oder die Asset-ID).

UDM-Beispiel für STATUS_HEARTBEAT

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

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 folgende UDM unterteilt: Kategorien:

• metadata: Hintergrundinformationen zum Ereignis.
• Principal: Details zu Gerät und Standort.
• intermediary: IP-Adresse des Geräts.
• 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 des Typs SYSTEM_AUDIT_LOG_WIPE für die Google Security Operations-UDM formatiert:

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 Pflichtfelder 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üllen Sie „target.user“ mit den geänderten Informationen über den Nutzer.
• intermediary: Für SSO-Anmeldungen muss „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, zu einer Video- oder Sprachkonferenz in Zoom oder Google Meet oder zu 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: Geben Sie Informationen über den Computer an, an den die Anfrage an erstellen oder löschen, von dem der Nutzer stammt. Erstellen Sie lokale Nutzer oder Löschen muss das Hauptkonto mindestens eine Maschinen-ID für die Ursprungscomputer.
• target: Ort, an dem der Nutzer erstellt wird. Nutzer müssen auch angegeben werden (z. B. target.user).

Optionale Felder:

• Principal: Nutzer- und Prozessdetails für den Computer, auf dem der Nutzer Erstellungs- oder Löschanfrage wurde initiiert.
• target: Informationen zur Zielmaschine (falls abweichend vom Hauptmaschine).

USER_LOGIN, USER_LOGOUT

Pflichtfelder:

• metadata: Pflichtfelder sind erforderlich.
• 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“ mindestens eine Maschinen-ID enthalten, die den Zielcomputer identifiziert. Bei der Nutzeraktivität von Gerät zu Gerät (z. B. Remote-Anmeldung, SSO, Cloud-Dienst, VPN) muss das Ziel Informationen zum Ziel Anwendung, Zielcomputer oder Ziel-VPN-Server.
• intermediary: Für SSO-Anmeldungen muss der Vermittler mindestens einen Computer haben. ID des SSO-Servers, falls verfügbar.
• network und network.http: Wenn die Anmeldung über HTTP erfolgt, müssen Sie alle verfügbaren Details in network.ip_protocol, network.application_protocol und network.http eintragen.
• Erweiterung authentication: Muss den Typ des Authentifizierungssystems identifizieren auf die sich das Ereignis bezieht (z. B. Computer, SSO oder VPN) und verwendet wird (Nutzername und Passwort, OTP usw.).
• security_result: Fügen Sie ein Feld „security_result“ hinzu, um den Anmeldestatus anzugeben, falls die Anmeldung fehlschlägt. Gib für security_result.category den Wert AUTH_VIOLATION an, wenn die Authentifizierung fehlschlägt.

USER_RESOURCE_ACCESS

Pflichtfelder:

• principal:Füllen Sie das Feld principal.user mit Details zu auf eine Cloud-Ressource (z. B. eine Salesforce-Anfrage, Office 365-Kalender, Google Docs oder ServiceNow-Ticket).
• target:Füllen Sie das Feld target.resource mit Informationen zu die Ziel-Cloud-Ressource.

Optionale Felder:

• target.application (empfohlen): Füllen Sie das Feld target.application mit Informationen zur Ziel-Cloudanwendung.

USER_RESOURCE_CREATION, USER_RESOURCE_DELETION

Pflichtfelder:

• principal:Füllen Sie das Feld principal.user mit den zugehörigen Details aus. mit dem Nutzer, der in einer Cloud-Ressource (z. B. einem Salesforce-Konto) erstellt wurde Office 365-Kalender, Google Docs oder ServiceNow-Ticket.
• target:Füllen Sie das Feld target.resource mit Informationen zu die Ziel-Cloud-Ressource.

Optionale Felder:

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

USER_RESOURCE_UPDATE_CONTENT

Pflichtfelder:

• principal:Füllen Sie das Feld principal.user mit den zugehörigen Details aus. mit dem Nutzer, dessen Inhalte in einer Cloud-Ressource aktualisiert wurden (für z. B. Salesforce, Office 365-Kalender, Google-Dokumente oder ServiceNow Ticket).
• target:Füllen Sie das Feld target.resource mit Informationen zu die Ziel-Cloud-Ressource.

Optionale Felder:

• target.application (empfohlen): Füllen Sie das Feld target.application mit Informationen zur Ziel-Cloudanwendung.

USER_RESOURCE_UPDATE_PERMISSIONS

Pflichtfelder:

• principal:Füllen Sie das Feld principal.user mit den zugehörigen Details aus. mit dem Nutzer, dessen Berechtigungen in einer Cloud-Ressource aktualisiert wurden (für Beispiele: Salesforce-Anfragen, Office 365-Kalender, Google-Dokumente oder ServiceNow Ticket).
• target:Füllen Sie das Feld target.resource mit Informationen zu die Ziel-Cloud-Ressource.

Optionale Felder:

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

USER_UNCATEGORIZED

Pflichtfelder:

• metadata: event_timestamp
• principal: Geben Sie Informationen über den Computer an, an den die Anfrage an erstellen oder löschen, von dem der Nutzer stammt. Erstellen Sie lokale Nutzer oder Löschen muss das Hauptkonto mindestens eine Maschinen-ID für die Ursprungscomputer.
• target: Ort, an dem der Nutzer erstellt wird. Nutzer müssen auch angegeben werden (z. B. target.user).

Optionale Felder:

• Principal: Nutzer- und Prozessdetails für den Computer, auf dem der Nutzer Erstellungs- oder Löschanfrage wurde initiiert.
• target: Informationen zum Zielcomputer (falls er sich vom Hauptcomputer unterscheidet).