Leitfaden zur Verwendung des einheitlichen Datenmodells

Dieses Dokument enthält eine detailliertere Beschreibung der Felder im Unified Data Model (UDM)-Schema und der Felder, die je nach Ereignistyp erforderlich oder optional sind. Bei der Auswertung des Regelmoduls 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 Typ des Ereignisses an. Wenn ein Ereignis mehrere mögliche Typen hat, muss mit diesem Wert der spezifischste Typ angegeben werden.
  • Erforderlich:Ja
  • Codierung:Muss einer der vordefinierten UDM-Ereignistypen mit Aufzählungszeichen sein.
  • Mögliche Werte:In der folgenden Liste sind alle möglichen Werte für „event_type“ in der UDM aufgeführt.

E-Mail-Ereignisse:

  • EMAIL_TRANSACTION
  • EMAIL_UNCATEGORIZED

Dateiereignisse, die an einem Endpunkt ausgeführt wurden:

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

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

  • GENERIC_EVENT

Mutex-Ereignisse (gegenseitiges Ausschlussobjekt):

  • MUTEX_UNCATEGORIZED
  • MUTEX_CREATION

Netzwerktelemetrie, einschließlich unformatierter Protokollnutzlasten 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_FLOW (z. B. aggregierte Flussstatistiken von Netflow)
  • NETWORK_CONNECTION (z. B. Details zur Netzwerkverbindung einer Firewall)
  • NETWORK_FTP
  • NETWORK_DHCP
  • NETWORK_DNS
  • 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, das Erstellen einer schädlichen Datei auf der Festplatte usw.

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

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

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

  • SCAN_UNCATEGORIZED
  • SCAN_FILE
  • SCAN_HOST
  • SCAN_PROCESS
  • SCAN_VULN_HOST
  • SCAN_VULN_NETWORK

Ereignisse zu geplanten Aufgaben (Windows-Taskplaner, Cron usw.):

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

Dienstereignisse:

  • SERVICE_UNSPECIFIED
  • SERVICE_CREATION
  • SERVICE_DELETION
  • SERVICE_START
  • SERVICE_STOP

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

  • SETTING_UNCATEGORIZED
  • SETTING_CREATION
  • SETTING_MODIFICATION
  • SETTING_DELETION

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

  • STATUS_UNCATEGORIZED
  • STATUS_HEARTBEAT (zeigt 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 sich ein Nutzer mit dem Badge 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

Metadata.collected_timestamp

  • Zweck: Codiert den GMT-Zeitstempel, wenn das Ereignis von der lokalen Datenerfassungsinfrastruktur des Anbieters erfasst wurde.
  • 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.event_timestamp

  • Zweck: Codiert den GMT-Zeitstempel, als 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:Für Menschen lesbare Beschreibung des Ereignisses.
  • Codierung: Alphanumerischer String, Satzzeichen zulässig, max. 1.024 Byte
  • Beispiel:Die Datei „c:\bar\foo.exe“ hat keinen Zugriff auf das vertrauliche Dokument „C:\Dokumente\earnings.docx“.

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 ID verwenden, um in der 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: alphanumerischer String mit Groß-/Kleinschreibung, Zeichensetzung zulässig, maximal 256 Byte.
  • Beispiele:
    • Falke
    • Symantec Endpoint Protection

Metadata.product_version

  • Zweck: Gibt die Version des Produkts an.
  • Codierung: Alphanumerischer String, Punkte und Bindestriche zulässig, max. 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 usw. Vor der URL muss ein Protokollpräfix stehen, z. B. https:// oder http://.
  • Beispiel:https://newco.altostrat.com:8080/event_info?event_id=12345

Metadata.vendor_name

  • Zweck: Gibt den Namen des Produktanbieters an.
  • Codierung: alphanumerischer String mit Groß-/Kleinschreibung, Zeichensetzung zulässig, maximal 256 Byte
  • Beispiele:
    • CrowdStrike
    • Symantec

Bevölkerung der Substantive-Metadaten

In diesem Abschnitt ist das Wort Noun ein übergeordneter Begriff, mit dem die Entitäten dargestellt werden: Noun, Noun, Noun, Noun, Noun und Noun. Diese Entitäten haben gemeinsame Attribute, stellen aber verschiedene 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

  • Zweck:Anbieterspezifische eindeutige Gerätekennung (z. B. eine GUID, die bei der Installation der Endpunktsicherheitssoftware auf einem neuen Gerät generiert wird, um dieses einzelne Gerät im Zeitverlauf nachzuverfolgen).
  • Codierung: VendorName.ProductName:ID, wobei die Groß-/Kleinschreibung bei VendorName.ProductName:ID nicht berücksichtigt wird* *Anbietername wie „Carbon Black“, VendorName.ProductName:ID ein Produktname, bei dem die Groß-/Kleinschreibung nicht berücksichtigt wird (z. B. „Response“ oder „Endpoint Protection“), und die ID eine anbieterspezifische Kundenkennung ist, die in der Kundenumgebung global eindeutig ist (z. B. eine GUID oder ein eindeutiger Wert für ein eindeutiges Gerät). 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:johns@test.altostrat.com

Noun.file

Noun.hostname

  • Zweck:Feld für den Hostnamen oder den Domainnamen des Clients Geben Sie nicht an, 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

Noun.ip

  • Zweck:
    • Einzelne IP-Adresse, die einer Netzwerkverbindung zugeordnet ist.
    • Eine oder mehrere IP-Adressen, die zum Zeitpunkt der Veranstaltung mit dem Gerät eines Teilnehmers verknüpft sind. Wenn ein EDR-Produkt beispielsweise alle IP-Adressen eines Geräts kennt, können diese in IP-Feldern codiert werden.
  • 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), darf der Anbieter nur eine IP-Adresse angeben.
    • Wenn in einem Ereignis eine allgemeine Aktivität auf einem Teilnehmergerät beschrieben wird, nicht aber eine bestimmte Netzwerkverbindung, kann der Anbieter zum Zeitpunkt des Ereignisses alle zugehörigen IP-Adressen für das Gerät angeben.
  • Beispiele:
    • 192.168.1.2
    • 2001:db8:1:3::1

Noun.port

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

  • Beispiele:

    • 80
    • 443

Noun.mac

  • Zweck:Eine oder mehrere MAC-Adressen, die einem Gerät zugeordnet sind.
  • Codierung: Gültige MAC-Adresse (EUI-48) in ASCII.
  • Wiederholbarkeit:Der Anbieter 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

Noun.url

  • Zweck: Standard-URL
  • Codierung: URL (RFC 3986) Muss ein gültiges Protokollpräfix enthalten, 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

Ausfüllen von Authentication-Metadaten

Authentication.AuthType

  • Zweck:Der Systemtyp, mit dem ein Authentifizierungsereignis verknüpft ist (Google Security Operations UDM).
  • Codierung:Enumerationstyp.
  • Mögliche Werte:
    • AUTHTYPE_UNSPECIFIED
    • MACHINE – Maschinenauthentifizierung
    • KÖRPERLICH – physische Authentifizierung (z. B. ein Ausweislesegerät)
    • SSO, die
    • TACACS: Protokoll der TACACS-Familie zur Authentifizierung von vernetzten Systemen, z. B. TACACS oder TACACS+
    • VPN

Authentication.Authentication_Status

  • Zweck:Beschreibt den Authentifizierungsstatus eines Nutzers oder bestimmte Anmeldedaten.
  • Codierung:Enumerationstyp.
  • 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: Die Authentifizierungsmethode hat keine aktiven Anmeldedaten.

Authentication.auth_details

  • Zweck: Anbieterdefinierte Authentifizierungsdetails.
  • Codierung: String.

Authentication.Mechanism

  • Zweck: Mechanismen zur Authentifizierung.
  • Codierung:Enumerationstyp.
  • Mögliche Werte:
    • MECHANISM_UNSPECIFIED: Standardauthentifizierungsmechanismus.
    • BADGE_READER
    • BATCH: Batch-Authentifizierung.
    • CACHED_INTERACTIVE: interaktive Authentifizierung mit im Cache gespeicherten Anmeldedaten
    • HARDWARE_KEY
    • LOCAL
    • 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 (OTP)
    • REMOTE – Remote-Authentifizierung
    • REMOTE_INTERACTIVE: RDP, Terminaldienste, Virtual Network Computing (VNC) usw.
    • SERVICE: Dienstauthentifizierung
    • ENTSPERREN: Direkte durch Menschen 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

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

  • Zweck: Anzahl der DHCP-Hops.
  • 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

  • Zweck: BOOTP-Vorgangscode (siehe Abschnitt 3 von RFC 951)
  • Codierung:Enumerationstyp.
  • Mögliche Werte:
    • UNKNOWN_OPCODE
    • BOOTANFRAGE
    • SCHNELLANTWORT

Dhcp.requested_address

  • Zweck: Client-ID. Weitere Informationen finden Sie unter RFC 2132, 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

  • Zweck: Client-Transaktions-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
    • BESTÄTIGEN
    • Nackt
    • 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

  • Zweck: 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.

Ausfüllen von DHCP-Optionsmetadaten

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

Option.code

  • Zweck: Speichert den DHCP-Optionscode. Weitere Informationen finden Sie unter RFC 1533, DHCP-Optionen und BOOTP-Anbietererweiterungen.
  • Codierung:Vorzeichenlose 32-Bit-Ganzzahl.

Option.data

  • Zweck:Speichert die Daten der DHCP-Option. Weitere Informationen finden Sie unter RFC 1533, DHCP-Optionen und BOOTP-Anbietererweiterungen.
  • Codierung: Byte.

Ausfüllen von DNS-Metadaten

Die DNS-Metadatenfelder erfassen Informationen zu DNS-Anfrage- und -Antwortpaketen. Sie haben eine Eins-zu-Eins-Übereinstimmung mit den Daten in DNS-Anfrage- und -Antwort-Datagrammen.

Dns.authoritative

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

Dns.id

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

Dns.response

  • Zweck:Legen Sie den Wert auf „true“ fest, wenn das Ereignis eine DNS-Antwort ist.
  • Codierung:Boolesch.

Dns.opcode

  • Zweck:Speichert den DNS-OpCode, mit dem der Typ der DNS-Abfrage angegeben wird (Standard, Inverse, Serverstatus usw.).
  • Codierung: 32-Bit-Ganzzahl.

Dns.recursion_available

  • Zweck:Setzen Sie diesen Wert auf „true“, wenn ein rekursiver DNS-Lookup verfügbar ist.
  • Codierung:Boolesch.

Dns.recursion_desired

  • Zweck:Setzen Sie diesen Wert auf „true“, wenn ein rekursiver DNS-Lookup angefordert wird.
  • Codierung:Boolesch.

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 gekürzte DNS-Antwort ist.
  • Codierung:Boolesch.

Dns.questions

Dns.answers

Dns.authority

Dns.additional

Anzahl der Metadaten für DNS-Fragen

Die Metadatenfelder der DNS-Fragen erfassen die Informationen, die im Fragenabschnitt einer Domainprotokollnachricht enthalten sind.

Question.name

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

Question.class

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

Question.type

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

Ausfüllen von DNS-Ressourceneintragsmetadaten

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

ResourceRecord.binary_data

  • Zweck: Speichert die Rohbyte aller Nicht-UTF8-Strings, die als Teil einer DNS-Antwort enthalten sein könnten. Dieses Feld darf nur verwendet werden, wenn die vom DNS-Server zurückgegebenen Antwortdaten Nicht-UTF8-Daten enthalten. Geben Sie andernfalls die DNS-Antwort in das Datenfeld unten ein. Diese Art von Informationen muss hier und nicht in ResourceRecord.data gespeichert werden.

  • Codierung: Byte.

ResourceRecord.class

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

ResourceRecord.data

  • Zweck: Speichert die Nutzlast oder Antwort auf die DNS-Frage für alle im UTF-8-Format codierten Antworten. Das Datenfeld könnte beispielsweise die IP-Adresse der Maschine zurückgeben, auf die 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

  • Zweck: Speichert den Code, 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: frank@email.beispiel.de.

Email.from

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

Email.reply_to

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

Email.to

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

Email.cc

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

Email.bcc

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

Email.mail_id

  • Zweck: Speichert die E-Mail- oder Nachrichten-ID.
  • Codierung: String.
  • Beispiel:192544.132632@email.beispiel.de

Email.subject

  • Zweck:Speichert die Betreffzeile der E-Mail.
  • Codierung: String.
  • Beispiel: „Bitte lesen Sie diese Nachricht.“

Ausfüllen von Erweiterungsmetadaten

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

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

Extensions.auth.auth_details

  • Zweck: Geben Sie anbieterspezifische Details zum Authentifizierungstyp oder -mechanismus an. Authentifizierungsanbieter definieren häufig Typen wie via_mfa, via_ad usw., 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.

Ausfüllen von Dateimetadaten

File.file_metadata

  • Zweck:Mit der Datei verknüpfte Metadaten.
  • Codierung: String.
  • Beispiele:
    • Autor
    • Revisionsnummer
    • Versionsnummer
    • Zuletzt gespeichert

File.full_path

  • Zweck:Vollständiger Pfad zur Angabe des Speicherorts der Datei im System.
  • Codierung: String.
  • Beispiel: \Programme\Benutzerdefinierte Dienstprogramme\Test.exe

File.md5

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

File.mime_type

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

File.sha1

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

File.sha256

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

File.size

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

Angabe von FTP-Metadaten

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

  • Zweck:Anzeigename der Gruppe.
  • Codierung: String.
  • Beispiele:
    • Finanzen
    • Std.
    • Marketing

Group.product_object_id

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

Group.windows_sid

  • Zweck:Feld für das Microsoft Windows Security Identifier (SID)-Gruppenattribut.
  • Codierung: String.

Auffüllen von HTTP-Metadaten

Http.method

  • Zweck: Speichert die HTTP-Anfragemethode.
  • 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.useragent

  • Zweck:Speichert den User-Agent-Anfrageheader, der den Anwendungstyp, das Betriebssystem, den Softwareanbieter oder die Softwareversion des User-Agents enthält, der die Software ausführt.
  • 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

  • Zweck:Speichert den Namen des Unternehmens, z. B. ein Gebäude oder einen 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

Angabe von Netzwerkmetadaten

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 Netzwerktraffics an.
  • Codierung:Enumerationstyp.
  • Mögliche Werte:
    • UNKNOWN_DIRECTION
    • EINZELN
    • OUTBOUND (OUTBOUND)
    • ÜBERTRAGUNG

Network.email

  • Zweck:Gibt die E-Mail-Adresse des Absenders/Empfängers an.
  • Codierung: String.
  • Beispiel:jcheng@company.example.com

Network.ip_protocol

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

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

Network.session_duration

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

Network.session_id

  • Zweck: Speichert die Netzwerksitzungs-ID.
  • 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

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

Process.parent_process.product_specific_process_id

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

Process.file

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

Process.parent_process

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

Process.pid

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

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

  • Zweck:Speichert den Namen des Registrierungswerts, der einer Anwendung oder Systemkomponente zugeordnet ist.
  • Codierung: String.
  • Beispiel:TEMP

Registry.registry_value_data

  • Zweck: Speichert die mit einem Registry-Wert verknüpften Daten.
  • Codierung: String.
  • Beispiel: %USERPROFILE%\Lokale Einstellungen\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:Verwerfen, blockieren, entschlüsseln, verschlüsseln

SecurityResult.category

  • Zweck: Geben Sie eine Sicherheitskategorie an.
  • Codierung: Enum.
  • Mögliche Werte:In Google Security Operations UDM werden die folgenden Sicherheitskategorien definiert:
    • ACL_VIOLATION: versuchter nicht autorisierter Zugriff, einschließlich des Versuchs, auf Dateien, Webdienste, Prozesse, Webobjekte usw. zuzugreifen.
    • AUTH_VIOLATION: Authentifizierung fehlgeschlagen, z. B. falsches Passwort oder falsche 2-Faktor-Authentifizierung.
    • DATA_AT_REST – DLP: ruhende Sensordaten bei einem Scan gefunden.
    • DATA_DESTRUCTION: Versuch, Daten zu löschen/zu löschen.
    • DATA_EXFILTRATION – DLP: Sensordatenübertragung, auf USB-Stick kopieren.
    • EXPLOIT: versuchter Überlauf, fehlerhafte Protokollcodierungen, ROP, SQL-Injection usw., sowohl netzwerk- als auch hostbasiert.
    • MAIL_PHISHING: Phishing-E-Mails, Chatnachrichten usw.
    • MAIL_SPAM: Spam-E-Mails, -Nachrichten usw.
    • MAIL_SPOOFING: gefälschte Quell-E-Mail-Adresse usw.
    • NETWORK_CATEGORIZED_CONTENT
    • NETWORK_COMMAND_AND_CONTROL: wenn der Befehls- und Kontrollgruppe bekannt ist
    • NETWORK_DENIAL_OF_SERVICE
    • NETWORK_MALICIOUS: Command-and-Control-Aktivitäten, Netzwerk-Exploit, verdächtige Aktivitäten, potenzieller Reverse-Tunnel usw.
    • NETWORK_SUSPICIOUS: Nicht sicherheitsbezogen, z. B. mit Glücksspiel.
    • NETWORK_RECON: Von einem IDS erkannter Portscan, der von einer Webanwendung geprüft wird.
    • POLICY_VIOLATION: Verstoß gegen Sicherheitsrichtlinien, einschließlich Verstößen gegen Firewall-, Proxy- und HIPS-Regeln oder NAC-Sperraktionen.
    • 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:In Google Security Operations UDM werden die folgenden Konfidenzkategorien für Produkte definiert:
    • UNKNOWN_CONFIDENCE
    • LOW_CONFIDENCE
    • MEDIUM_CONFIDENCE
    • HIGH_CONFIDENCE

SecurityResult.confidence_details

  • Zweck: Weitere Angaben zur Zuverlässigkeit eines Sicherheitsereignisses, wie vom Produktanbieter eingeschätzt.
  • Codierung: String.

SecurityResult.priority

  • Zweck: Geben Sie gemäß Einschätzung des Produktanbieters eine Priorität in Bezug auf ein Sicherheitsereignis an.
  • Codierung: Enum.
  • Mögliche Werte:In Google Security Operations UDM 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

  • Zweck:Schweregrad eines Sicherheitsereignisses, wie es vom Produktanbieter anhand der in der Google Security Operations-UDM definierten Werte geschätzt wird.
  • Codierung: Enum.
  • Mögliche Werte:Google Security Operations UDM definiert die folgenden Schweregrade für Produkte:
    • UNKNOWN_SEVERITY – nicht schädlich
    • INFORMATION – nicht böswillig
    • FEHLER – nicht böswillig
    • LOW – Schädlich
    • MITTEL – Schädlich
    • HOCH – Schädlich

SecurityResult.severity_details

  • Zweck: Der vom Produktanbieter geschätzte Schweregrad für ein Sicherheitsereignis.
  • 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.

Ausfüllen von Nutzermetadaten

User.email_addresses

  • Zweck:Speichert die E-Mail-Adressen des Nutzers.
  • Codierung: Wiederholter String.
  • Beispiel:maxmustermann@IhrUnternehmen.de

User.employee_id

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

User.first_name

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

  • Zweck:Speichert die mit einem Nutzer verknüpften Gruppen-IDs (GUID, LDAP OID oder Ähnliches).
  • Codierung: Wiederholter String.
  • Beispiel:admin-user.

User.phone_numbers

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

User.title

  • Zweck: Speichert die Berufsbezeichnung für den Nutzer.
  • Codierung: String.
  • Beispiel:Customer-Relationship-Management

User.user_display_name

  • Zweck:Speichert den Anzeigenamen für den Nutzer.
  • Codierung: String.
  • Beispiel:Max Muster.

User.userid

  • Zweck:Speichert die User-ID.
  • 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. Siehe Metadaten zur Bevölkerung von Substantiven
  • Beispiel: ausführbare Datei.

Vulnerability.cvss_base_score

  • Zweck: Basiswert für das Common Vulnerability Scoring System (CVSS).
  • Codierung: Gleitkommazahl.
  • 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)
    • Auswirkung auf die Verfügbarkeit (A)

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

  • Codierung: String.

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

Vulnerability.cvss_version

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

Vulnerability.description

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

Vulnerability.first_found

  • Zweck: Für Produkte, für die ein Verlauf von Scans auf Sicherheitslücken vorhanden ist, sollte first_found den Zeitpunkt angeben, zu dem die Sicherheitslücke bei diesem Asset zum ersten Mal erkannt wurde.
  • Codierung: String.

Vulnerability.last_found

  • Zweck: Für Produkte, für die ein Verlauf von Scans auf Sicherheitslücken vorhanden ist, sollte in „last_found“ der Zeitpunkt angegeben werden, zu dem die Sicherheitslücke bei diesem Asset zuletzt erkannt wurde.
  • Codierung: String.

Vulnerability.name

  • Zweck:Name der Sicherheitslücke.
  • Codierung: String.
  • Beispiel:Eine nicht unterstützte Betriebssystemversion wurde 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 das Ende nicht verfügbar oder nicht zutreffend ist.
  • Codierung: String.

Vulnerability.scan_start_time

  • Zweck: Wenn die Sicherheitslücke während eines Asset-Scans entdeckt wurde, geben Sie in dieses Feld den Zeitpunkt des Scanbeginns ein. Lassen Sie dieses Feld leer, wenn der Beginn nicht verfügbar oder ungültig ist.
  • Codierung: String.

Vulnerability.severity

  • Zweck:Schweregrad der Sicherheitslücke
  • Codierung:Enumerationstyp.
  • Mögliche Werte:
    • UNKNOWN_SEVERITY
    • NIEDRIG
    • MITTEL
    • HOCH

Vulnerability.severity_details

  • Zweck: Anbieterspezifischer Schweregrad.
  • Codierung: String.

Darstellung von Benachrichtigungsmetadaten

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 erforderlichen und optionalen Felder beschrieben, die je nach UDM-Ereignistyp ausgefüllt werden müssen. Eine Beschreibung dieser Felder finden Sie in der Liste der Felder für einheitliche Datenmodell.

EMAIL_TRANSACTION

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • principal: Dieses Feld enthält Informationen über den Computer, von dem die E-Mail-Nachricht stammt. Zum Beispiel die IP-Adresse des Absenders.

Optionale Felder:

  • about: URLs, IP-Adressen, Domains und alle Dateianhänge, die in den E-Mail-Text eingebettet sind.
  • securityResult.about: Ungültige URLs, IP-Adressen und in den E-Mail-Text eingebettete Dateien.
  • network.email: Informationen zum E-Mail-Absender/Empfänger.
  • principal: Wenn Clientcomputerdaten über den Absender der E-Mail vorhanden sind, geben Sie die Serverdetails im Hauptkonto an (z. B. Clientprozess, Portnummern, Nutzername usw.).
  • target: Wenn Daten zum Ziel-E-Mail-Server vorhanden sind, geben Sie die Serverdetails im Ziel ein, z. B. die IP-Adresse.
  • intermediary: Wenn E-Mail-Server-Daten oder E-Mail-Proxy-Daten vorhanden sind, tragen Sie die Serverdetails in der Intermediärdatei ein.

Hinweise:

  • Füllen Sie principal.email oder target.email niemals aus.
  • Füllen Sie das E-Mail-Feld nur in security_result.about oder network.email aus.
  • Bei Sicherheitsergebnissen der obersten Ebene wird in der Regel eine Nomen festgelegt (bei Spam optional).

FILE_CREATION, FILE_DELETION, FILE_MODIFICATION, FILE_READ und FILE_OPEN

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • Hauptkonto:
    • Mindestens eine Maschinen-ID.
    • (Optional) Füllen Sie principal.process mit Informationen zum Prozess, der auf die Datei zugreift.
  • Ziel:
    • Bei einer Remote-Datei (z. B. SMB-Freigabe) muss das Ziel mindestens eine Maschinen-ID für die Zielmaschine enthalten. Andernfalls müssen alle Maschinen-IDs leer sein.
    • Füllen Sie „target.file“ mit Informationen zur Datei.

Optional:

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

FILE_COPY

Pflichtfelder:

  • metadata: Füge die erforderlichen Felder wie beschrieben ein.
  • Hauptkonto:
    • Mindestens eine Maschinen-ID.
    • (Optional) Füllen Sie principal.process mit Informationen zu dem Prozess aus, der den Dateikopiervorgang ausführt.
  • src:
    • Füllen Sie src.file mit Informationen zur Quelldatei.
    • Wenn es sich um eine Remote-Datei handelt (z. B. SMB-Freigabe), muss src mindestens eine Maschinen-ID für die Quellmaschine enthalten, auf der die Quelldatei gespeichert ist.
  • Ziel:
    • Füllen Sie target.file mit Informationen zur Zieldatei.
    • Bei einer Remote-Datei (z. B. SMB-Freigabe) muss das Feld target mindestens eine Maschinen-ID für die Zielmaschine mit der Zieldatei enthalten.

Optionale Felder:

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

MUTEX_CREATION

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • Hauptkonto:
    • Mindestens eine Maschinen-ID.
    • Füllen Sie „principal.process“ mit Informationen zum Prozess zum Erstellen des Mutex.
  • Ziel:
    • Füllen Sie target.resource aus.
    • 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: Wird ausgefüllt, wenn Nutzerinformationen für den Prozess verfügbar sind.
UDM-Beispiel für MUTEX_CREATION

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

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

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

  • metadata: Hintergrundinformationen zum Ereignis.
  • Principal: Details zu Gerät und Prozess.
  • target: Informationen zum Mutex.

NETWORK_CONNECTION

Pflichtfelder:

  • metadata: event_timestamp
  • principal: Geben Sie Details zu dem Computer an, der die Netzwerkverbindung initiiert hat (z. B. Quelle).
  • target: Enthält Details zur Zielmaschine, falls diese sich von der Hauptmaschine unterscheidet.
  • network: Erfasst Details zur Netzwerkverbindung (Ports, Protokoll usw.).

Optionale Felder:

  • principal.process und target.process: Fügen Sie Prozessinformationen hinzu, die mit dem Hauptkonto und dem Ziel der Netzwerkverbindung verknüpft sind (falls verfügbar).
  • principal.user und target.user: Fügen Sie Nutzerinformationen hinzu, die mit dem Hauptkonto und dem Ziel der Netzwerkverbindung verknüpft sind (falls verfügbar).

NETWORK_HTTP

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

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • principal: Stellt den Client dar, der die Webanfrage initiiert. Er enthält mindestens eine Maschinen-ID (z. B. Hostname, IP-Adresse, MAC, proprietäre Asset-ID) oder eine Nutzer-ID (z. B. Nutzername). Wenn eine bestimmte Netzwerkverbindung beschrieben wird und eine Client-Portnummer verfügbar ist, muss nur eine IP-Adresse zusammen mit der Portnummer dieser Netzwerkverbindung angegeben werden. Es könnten jedoch andere Maschinenkennungen angegeben werden, um das Teilnehmergerät besser zu beschreiben. Wenn kein Quellport verfügbar ist, können alle IP- und MAC-Adressen, Asset-IDs und Hostnamenwerte, die das Hauptgerät beschreiben, angegeben werden.
  • 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 zu der Portnummer, die dieser Netzwerkverbindung zugeordnet ist, nur eine IP-Adresse an. Es können jedoch auch mehrere andere Maschinenkennungen für das Ziel angegeben werden. Geben Sie für „target.url“ die aufgerufene URL ein.
  • network und network.http: Enthält Details zur HTTP-Netzwerkverbindung. Sie müssen die folgenden Felder ausfüllen:
    • network.ip_protocol
    • network.application_protocol
    • network.http.method

Optionale Felder:

  • about: Steht für andere Entitäten, die in der HTTP-Transaktion gefunden wurden, z. B. eine hochgeladene oder heruntergeladene Datei.
  • intermediary: Stellt einen Proxyserver dar (falls abweichend vom Hauptkonto oder Ziel).
  • metadata: Füllen Sie die anderen Metadatenfelder aus.
  • network: Füllen Sie die anderen Netzwerkfelder aus.
  • network.email: Wenn die HTTP-Netzwerkverbindung von einer URL stammt, die in einer E-Mail-Nachricht enthalten ist, geben Sie die Details für network.email ein.
  • Beobachter: Steht für einen passiven Sniffer (falls vorhanden).
  • security_result: Fügen Sie dem Feld "security_result" ein oder mehrere Elemente hinzu, die die erkannte schädliche Aktivität darstellen.
UDM-Beispiel für NETWORK_HTTP

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

Folgendes ist das ursprüngliche Sophos-Antivirenereignis:

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

So formatieren Sie dieselben Informationen in Proto3 mithilfe der UDM-Syntax von Google Security Operations:

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.
  • Hauptkonto: Sicherheitsgerät, das das Ereignis erkannt hat.
  • Ziel: Gerät, auf dem die schädliche Software installiert wurde
  • network: Netzwerkinformationen über den schädlichen Host.
  • security_result: Sicherheitsdetails der schädlichen Software.
  • Zusätzlich: Informationen von Anbietern, die derzeit nicht in den Geltungsbereich der UDM fallen.

PROCESS_INJECTION, PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_TERMINATION, PROCESS_UNCATEGORIZED

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • Hauptkonto:
    • Mindestens eine Maschinen-ID.
    • Bei Ereignissen zur Prozessinjektion und Beendigung von Prozessen, sofern verfügbar, muss principal.process Informationen zu dem Prozess enthalten, der die Aktion initiiert. Bei einem Ereignis vom Typ „Prozessstart“ muss z. B. principal.process Details zum übergeordneten Prozess enthalten, sofern verfügbar.
  • Ziel:
    • target.process: Enthält Informationen zum Prozess, der eingefügt, geöffnet, gestartet oder beendet wird.
    • Wenn der Zielprozess remote ist, muss das Ziel mindestens eine Maschinen-ID für die Zielmaschine enthalten, z. B. eine IP-Adresse, einen MAC, einen Hostnamen oder eine Asset-ID eines Drittanbieters.

Optionale Felder:

  • security_result: Beschreibe die erkannte schädliche Aktivität.
  • principal.user und target.user: Füllen Sie den Initiierungsprozess (Hauptprozess) und den Zielprozess aus, sofern die Nutzerinformationen verfügbar sind.
UDM-Beispiel für PROCESS_LAUNCH

Das folgende Beispiel zeigt, wie Sie ein PROCESS_LAUNCH-Ereignis mithilfe der Google Security Operations UDM-Syntax formatieren können:

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

PROCESS_MODULE_LOAD

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • Hauptkonto:
    • Mindestens eine Maschinen-ID.
    • principal.process: Prozess zum Laden des Moduls.
  • Ziel:
    • target.process: Enthält Informationen zum Prozess.
    • target.process.file: Das Modul wurde geladen (z. B. die DLL oder das freigegebene Objekt).

Optionale Felder:

  • security_result: Beschreibe die erkannte schädliche Aktivität.
  • principal.user: Wird ausgefüllt, wenn Nutzerinformationen für den Prozess verfügbar sind.
UDM-Beispiel für PROCESS_MODULE_LOAD

Das folgende Beispiel zeigt, wie Sie ein PROCESS_MODULE_LOAD-Ereignis mithilfe der Google Security Operations UDM-Syntax formatieren können:

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

PROCESS_PRIVILEGE_ESCALATION

Pflichtfelder:

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

Optionale Felder:

  • security_result: Beschreibe die erkannte schädliche Aktivität.
UDM-Beispiel für PROCESS_PRIVILEGE_ESCALATION

Das folgende Beispiel zeigt, wie Sie ein Ereignis vom Typ PROCESS_PRIVILEGE_ESCALATION mithilfe der Google Security Operations UDM-Syntax formatieren können:

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 das Modul lädt.
  • target: Prozess- und Moduldetails.

REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • Hauptkonto:
    • Mindestens eine Maschinen-ID.
    • Wenn die Registry von einem Prozess im Nutzermodus geändert wird, muss principal.process Informationen zu dem Prozess enthalten, der die Registry ändert.
    • Wenn ein Kernel-Prozess die Registry-Änderung vornimmt, darf das Hauptkonto keine Prozessinformationen enthalten.
  • Ziel:
    • target.registry: Wenn es sich bei der Ziel-Registry um eine Remote-Registry handelt, muss das Ziel mindestens eine Kennung für die Zielmaschine enthalten, z. B. eine IP-Adresse, eine MAC-Adresse, einen Hostnamen oder eine Drittanbieter-Asset-ID.
    • target.registry.registry_key: Alle Registry-Ereignisse müssen den betroffenen Registrierungsschlüssel enthalten.

Optional:

  • security_result::Beschreibe die erkannte schädliche Aktivität. Dies kann beispielsweise ein fehlerhafter Registrierungsschlüssel sein.
  • principal.user::Wird ausgefüllt, wenn Nutzerinformationen für den Prozess verfügbar sind.
UDM-Beispiel für REGISTRY_MODIFICATION

Das folgende Beispiel zeigt, wie Sie ein REGISTRY_MODIFICATION-Ereignis in Proto3 mithilfe der Google Security Operations UDM-Syntax formatieren:

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

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

  • metadata: Hintergrundinformationen zum Ereignis.
  • Principal: Details zu Gerät, Nutzer und Prozess.
  • 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 mithilfe des Felds „extensions.vuln“.
  • metadata: event_timestamp
  • observer: Erfassen Sie Informationen zum Scanner selbst. Bei einem Remote-Scanner müssen die Maschinendetails im Beobachterfeld erfasst werden. Wenn du einen lokalen Scanner nutzen möchtest, lass das Feld leer.
  • target: Informationen über den Computer erfassen, auf dem sich das zu scannende Objekt befindet. Beim Scannen einer Datei muss target.file Informationen über die gescannte Datei erfassen. Wenn ein Prozess gescannt wird, muss target.process Informationen zum gescannten Prozess erfasst werden.

Optionale Felder:

  • target: Nutzerdetails zum Zielobjekt (z. B. Dateiersteller oder Prozessinhaber) sollten in target.user erfasst werden.
  • security_result: Beschreibe die erkannte schädliche Aktivität.
UDM-Beispiel für SCAN_HOST

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

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

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

  • metadata: Hintergrundinformationen zum Ereignis.
  • Ziel: Gerät, auf dem die schädliche Software installiert wurde
  • Beobachter: Gerät, das das betreffende Ereignis beobachtet und meldet.
  • security_result: Sicherheitsdetails der schädlichen Software.

SCHEDULED_TASK_CREATION, SCHEDULED_TASK_DELETION, SCHEDULED_TASK_DISABLE, SCHEDULED_TASK_ENABLE, SCHEDULED_TASK_MODIFICATION, SCHEDULED_TASK_UNCATEGORIZED

Pflichtfelder:

  • principal: Für alle SCHEDULED_TASK-Ereignisse muss das Hauptkonto eine Maschinen- und eine Nutzerkennung enthalten.
  • target: Das Ziel muss eine gültige Ressource und einen als „TASK“ definierten Ressourcentyp enthalten.

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 die Google Security Operations-UDM formatiert werden kann:

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: Gerät, das die verdächtige Aufgabe geplant hat.
  • target: Software, auf die die verdächtige Aufgabe verweist
  • Vermittler: Vermittler, der an der verdächtigen Aufgabe beteiligt ist
  • security_result: Sicherheitsdetails zur verdächtigen Aufgabe.

SETTING_UNCATEGORIZED, SETTING_CREATION, SETTING_MODIFICATION, SETTING_DELETION

Pflichtfelder:

  • principal: Muss vorhanden und nicht leer sein und eine Maschinen-ID enthalten.
  • target: Muss vorhanden und nicht leer sein und eine Ressource enthalten, deren Typ als SETTING angegeben ist
UDM-Beispiel für den Ereignistyp SETTING_MODIFICATION

Das folgende Beispiel zeigt, wie ein Ereignis vom Typ SETTING_MODIFICATION für 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 (Hauptkonto): 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 werden würde:

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: Details zu Gerät und Standort.
  • 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 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 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: Details zu Gerät und Standort.
  • Vermittler: 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 für das Log ausgeführt hat, und eine Maschinen-ID für die Maschine, auf der das Log gespeichert ist oder war (beim Löschen der Daten).
UDM-Beispiel für SYSTEM_AUDIT_LOG_WIPE

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

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

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

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

USER_CHANGE_PASSWORD, USER_CHANGE_PERMISSIONS

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • Principal (Hauptkonto): Wenn das Nutzerkonto von einem Remote-Standort aus geändert wurde, geben Sie für das Hauptkonto Informationen zu dem Computer ein, von dem die Nutzeränderung stammt.
  • target: Füllen Sie „target.user“ mit den geänderten Informationen über den Nutzer.
  • intermediary: Bei SSO-Anmeldungen muss der Vermittler mindestens eine Maschinen-ID für den SSO-Server angeben, falls verfügbar.

USER_COMMUNICATION

Pflichtfelder:

  • principal:Füllen Sie das Feld principal.user mit Details zur vom Nutzer initiierten Kommunikation (Sender) wie einer Chatnachricht in Google Chat oder Slack, einer Video- oder Sprachkonferenz in Zoom oder Google Meet oder einer VoIP-Verbindung.

Optionale Felder:

  • target (empfohlen): Füllen Sie das Feld target.user mit Informationen zum Zielnutzer (Empfänger) der Cloud-Kommunikationsressource. Geben Sie in das 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, von dem die Anfrage zum Erstellen oder Löschen des Nutzers stammt. Damit ein lokaler Nutzer erstellt oder gelöscht werden kann, muss das Hauptkonto mindestens eine Maschinen-ID für den Ursprungscomputer enthalten.
  • target:Der Ort, an dem der Nutzer erstellt wird. Außerdem müssen Nutzerinformationen enthalten sein (z. B. target.user).

Optionale Felder:

  • Principal: Nutzer- und Prozessdetails für den Computer, auf dem die Anfrage zum Erstellen oder Löschen des Nutzers initiiert wurde.
  • target: Informationen zur Zielmaschine (falls abweichend von der Hauptmaschine).

USER_LOGIN, USER_LOGOUT

Pflichtfelder:

  • metadata: Pflichtfelder sind erforderlich.
  • principal: Für Remote-Nutzeraktivitäten (z. B. Remote-Anmeldung) füllen Sie das Hauptkonto mit Informationen über den Computer aus, von dem die Nutzeraktivität ausgeht. Legen Sie für lokale Nutzeraktivitäten (z. B. lokale Anmeldung) kein Hauptkonto fest.
  • target: Füllen Sie "target.user" mit Informationen über den Nutzer, der sich angemeldet oder abgemeldet hat. Wenn das Hauptkonto nicht festgelegt ist (z. B. lokale Anmeldung), muss das Ziel auch mindestens eine Maschinen-ID enthalten, die den Zielcomputer identifiziert. Für Computer-zu-Computer-Nutzeraktivitäten (z. B. Remote-Anmeldung, SSO, Cloud-Dienste, VPN) muss das Ziel Informationen zur Zielanwendung, zum Zielcomputer oder zum Ziel-VPN-Server enthalten.
  • intermediary: Bei SSO-Anmeldungen muss der Vermittler mindestens eine Maschinen-ID für den SSO-Server angeben, 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 aufnehmen.
  • Erweiterung authentication: Muss den Typ des Authentifizierungssystems angeben, auf das sich das Ereignis bezieht (z. B. Maschine, SSO oder VPN) und den eingesetzten Mechanismus (Nutzername und Passwort, OTP usw.).
  • security_result: Fügen Sie ein "security_result"-Feld hinzu, das bei Fehlschlagen den Anmeldestatus darstellt. Geben Sie security_result.category mit dem Wert AUTH_VIOLATION an, wenn die Authentifizierung fehlschlägt.

USER_RESOURCE_ACCESS

Pflichtfelder:

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

Optionale Felder:

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

NUTZERRESSOURCEN_ERSTELLUNG, USER_RESOURCE_DELETION

Pflichtfelder:

  • principal:Füllen Sie das Feld principal.user mit Details zum Nutzer, der in einer Cloud-Ressource erstellt wurde, z. B. eine Salesforce-Anfrage, einen Office365-Kalender, ein Google Docs- oder ServiceNow-Ticket.
  • target: Füllen Sie das Feld target.resource mit Informationen zur Ziel-Cloudressource.

Optionale Felder:

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

USER_RESOURCE_UPDATE_CONTENT

Pflichtfelder:

  • principal:Füllen Sie das Feld principal.user mit Details zu dem Nutzer, dessen Inhalt in einer Cloud-Ressource aktualisiert wurde (z. B. eine Salesforce-Anfrage, ein Office365-Kalender, ein Google Docs- oder ein ServiceNow-Ticket).
  • target: Füllen Sie das Feld target.resource mit Informationen zur Ziel-Cloudressource.

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 Details zu dem Nutzer, dessen Berechtigungen in einer Cloud-Ressource aktualisiert wurden (z. B. eine Salesforce-Anfrage, ein Office365-Kalender, ein Google Docs- oder ein ServiceNow-Ticket).
  • target: Füllen Sie das Feld target.resource mit Informationen zur Ziel-Cloudressource.

Optionale Felder:

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

USER_UNCATEGORIZED

Pflichtfelder:

  • metadata: event_timestamp
  • principal: Geben Sie Informationen über den Computer an, von dem die Anfrage zum Erstellen oder Löschen des Nutzers stammt. Damit ein lokaler Nutzer erstellt oder gelöscht werden kann, muss das Hauptkonto mindestens eine Maschinen-ID für den Ursprungscomputer enthalten.
  • target:Der Ort, an dem der Nutzer erstellt wird. Außerdem müssen Nutzerinformationen enthalten sein (z. B. target.user).

Optionale Felder:

  • Principal: Nutzer- und Prozessdetails für den Computer, auf dem die Anfrage zum Erstellen oder Löschen des Nutzers initiiert wurde.
  • target: Informationen zur Zielmaschine (falls abweichend von der Hauptmaschine).