Guida all'utilizzo di UDM

Questo documento fornisce:

• Descrizioni dettagliate dei campi dello schema Unified Data Model (UDM)
• Campi obbligatori e facoltativi per i tipi di entità
• Campi obbligatori e facoltativi per ogni tipo di evento

Per informazioni dettagliate su campi UDM specifici (ad esempio i numeri enum), consulta l'elenco dei campi Unified Data Model.

Formati dei nomi dei campi UDM:

• Per la valutazione del motore delle regole, il prefisso inizia con udm.
• Per il normalizzatore basato sulla configurazione (CBN), il prefisso inizia con event.idm.read_only_udm.

Popolamento dei metadati degli eventi

La sezione dei metadati degli eventi UDM memorizza informazioni generali su ogni evento.

Metadata.event_type

• Purpose: specifica il tipo di evento. Se un evento ha più tipi possibili, questo valore deve specificare il tipo più specifico.
• Obbligatorio: sì.
• Codifica: deve essere uno dei tipi enumerati UDM event_type predefiniti.
• Valori possibili: le sezioni seguenti elencano tutti i valori possibili per metadata.event_type all'interno dell'UDM. Per i campi obbligatori e facoltativi per ogni categoria, consulta Campi obbligatori e facoltativi per ogni tipo di evento.

Eventi per analisti

• ANALYST_ADD_COMMENT
• ANALYST_UPDATE_PRIORITY
• ANALYST_UPDATE_REASON
• ANALYST_UPDATE_REPUTATION
• ANALYST_UPDATE_RISK_SCORE
• ANALYST_UPDATE_ROOT_CAUSE
• ANALYST_UPDATE_SEVERITY_SCORE
• ANALYST_UPDATE_STATUS
• ANALYST_UPDATE_VERDICT

Eventi dispositivo

Eventi relativi ad aggiornamenti di firmware, configurazione o programmi su un dispositivo (ad esempio un sistema di controllo industriale o un asset di tecnologia operativa):

• DEVICE_CONFIG_UPDATE
• DEVICE_FIRMWARE_UPDATE
• DEVICE_PROGRAM_DOWNLOAD
• DEVICE_PROGRAM_UPLOAD

Eventi email

Eventi relativi alle transazioni email e alle ispezioni di sicurezza delle email:

• EMAIL_UNCATEGORIZED
• EMAIL_TRANSACTION
• EMAIL_URL_CLICK (ritirato)

Eventi non specificati

Valore segnaposto per un tipo di evento non inizializzato (gli eventi impostati su EVENTTYPE_UNSPECIFIED non superano la convalida UDM):

• EVENTTYPE_UNSPECIFIED

Eventi relativi ai file eseguiti su un endpoint

• FILE_UNCATEGORIZED
• FILE_COPY (ad esempio, la copia di un file su un'unità flash)
• FILE_CREATION
• FILE_DELETION
• FILE_MODIFICATION
• FILE_MOVE
• FILE_OPEN (ad esempio, l'apertura di un file potrebbe indicare una violazione della sicurezza)
• FILE_READ (ad esempio, la lettura di un file di password)
• FILE_SYNC

Eventi che non rientrano in nessun'altra categoria

Eventi che non rientrano in nessun'altra categoria, inclusi gli eventi del sistema operativo non classificati:

• GENERIC_EVENT

Eventi di attività di gruppo

Eventi relativi alla creazione, alla modifica o all'eliminazione di gruppi di utenti o di sistema:

• GROUP_UNCATEGORIZED
• GROUP_CREATION
• GROUP_DELETION
• GROUP_MODIFICATION

Eventi mutex

Eventi relativi alla creazione o alla gestione di un oggetto di mutua esclusione (mutex) su un endpoint:

• MUTEX_UNCATEGORIZED
• MUTEX_CREATION

Eventi di telemetria di rete

Eventi di telemetria di rete, che includono payload di protocolli non elaborati, come DHCP e DNS, nonché riepiloghi di protocolli come HTTP, SMTP e FTP ed eventi di flusso e connessione da NetFlow e firewall:

• NETWORK_UNCATEGORIZED
• NETWORK_CONNECTION (ad esempio, i dettagli della connessione di rete da un firewall)
• NETWORK_DHCP
• NETWORK_DNS
• NETWORK_FLOW (ad esempio, statistiche di flusso aggregate da Netflow)
• NETWORK_FTP
• NETWORK_HTTP
• NETWORK_SMTP

Eventi di processo

Qualsiasi evento relativo a un processo, come l'avvio di un processo, un processo che crea qualcosa di dannoso, un processo che si inserisce in un altro processo, la modifica di una chiave del Registro di sistema o la creazione di un file dannoso sul disco:

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

Eventi del registry

Utilizza i seguenti eventi REGISTRY anziché gli eventi SETTING quando gestisci eventi del registry specifici di Microsoft Windows:

• REGISTRY_UNCATEGORIZED
• REGISTRY_CREATION
• REGISTRY_MODIFICATION
• REGISTRY_DELETION

Eventi risorsa

Eventi relativi alla creazione, alla lettura, alla scrittura, all'eliminazione o alla modifica delle autorizzazioni per una risorsa:

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Eventi orientati alla scansione

Gli eventi orientati alla scansione includono scansioni on demand e rilevamenti comportamentali eseguiti da prodotti di sicurezza degli endpoint o della rete (come EDR, antivirus, scanner di vulnerabilità o DLP):

• SCAN_UNCATEGORIZED
• SCAN_FILE
• SCAN_HOST
• SCAN_NETWORK
• SCAN_PROCESS
• SCAN_PROCESS_BEHAVIORS (deprecato)
• SCAN_VULN_HOST
• SCAN_VULN_NETWORK

Eventi delle attività pianificate (Windows Task Scheduler, cron ecc.)

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

Eventi di servizio

Eventi relativi alla creazione, all'eliminazione, alla modifica, all'avvio o all'arresto di un sistema operativo o di un servizio di applicazione:

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

Impostazione degli eventi

Per i requisiti per gli eventi, consulta SETTING_UNCATEGORIZED, SETTING_CREATION, SETTING_MODIFICATION, SETTING_DELETION.

Impostazione degli eventi, tra cui la modifica di un'impostazione di sistema su un endpoint:

• SETTING_UNCATEGORIZED
• SETTING_CREATION
• SETTING_DELETION
• SETTING_MODIFICATION

Messaggi di stato dai prodotti di sicurezza

Messaggi di stato dei prodotti di sicurezza per indicare che gli agenti sono attivi e per inviare dati relativi a versione, fingerprint o altri tipi di dati:

• STATUS_UNCATEGORIZED
• STATUS_HEARTBEAT (indica che il prodotto è attivo)
• STATUS_STARTUP
• STATUS_SHUTDOWN
• STATUS_UPDATE (aggiornamento del software o dell'impronta)

Eventi degli audit log di sistema

• SYSTEM_AUDIT_LOG_UNCATEGORIZED
• SYSTEM_AUDIT_LOG_WIPE

Eventi di attività di autenticazione utente

• USER_UNCATEGORIZED
• USER_BADGE_IN (ad esempio, quando un utente accede fisicamente a un sito)
• 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 (deprecato)

Metadata.collected_timestamp

• Scopo: codifica il timestamp GMT quando l'evento è stato raccolto dall'infrastruttura di raccolta locale del fornitore.
• Codifica: RFC 3339, in base al formato del timestamp JSON o Proto3.
• Esempio:
  • RFC 3339: "2019-09-10T20:32:31-08:00"
  • Formato Proto3: "2012-04-23T18:25:43.511Z"

Metadata.event_timestamp

• Scopo: codifica il timestamp GMT di quando è stato generato l'evento.
• Obbligatorio: sì
• Codifica: RFC 3339, in base al formato del timestamp JSON o Proto3.
• Esempio:
  • RFC 3339: 2019-09-10T20:32:31-08:00
  • Formato Proto3: 2012-04-23T18:25:43.511Z

Metadata.description

• Purpose: descrizione leggibile dell'evento.
• Codifica: stringa alfanumerica, punteggiatura consentita, massimo 1024 byte
• Esempio: l'accesso al documento sensibile c:\documents\earnings.docx è stato bloccato per il file c:\bar\foo.exe.

Metadata.product_event_type

• Scopo: nome o tipo di evento breve, descrittivo, leggibile e specifico del prodotto.
• Codifica: stringa alfanumerica, punteggiatura consentita, massimo 64 byte.
• Esempi:
  • Evento di creazione del registry
  • ProcessRollUp
  • Escalation dei privilegi rilevata
  • Malware bloccato

Metadata.product_log_id

• Scopo: codifica un identificatore di evento specifico del fornitore per identificare in modo univoco l'evento (un GUID). Gli utenti potrebbero utilizzare questo identificatore per cercare l'evento in questione nella console proprietaria del fornitore.
• Codifica: stringa alfanumerica sensibile alle maiuscole, punteggiatura consentita, massimo 256 byte.
• Esempio: ABcd1234-98766

Metadata.product_name

• Scopo: specifica il nome del prodotto.
• Codifica: stringa alfanumerica sensibile alle maiuscole, punteggiatura consentita, massimo 256 byte.
• Esempi:
  • Falcon
  • Symantec Endpoint Protection

Metadata.product_version

• Scopo: specifica la versione del prodotto.
• Codifica: stringa alfanumerica, sono consentiti punti e trattini, massimo 32 byte
• Esempi:
  • 1.2.3b
  • 10.3:rev1

Metadata.url_back_to_product

• Scopo: URL che rimanda a un sito web pertinente in cui puoi visualizzare ulteriori informazioni su questo evento specifico (o sulla categoria generale dell'evento).
• Codifica: URL RFC 3986 valido con parametri facoltativi, ad esempio informazioni sulla porta e così via. Deve avere un prefisso del protocollo prima dell'URL (ad esempio https:// o http://).
• Esempio: https://newco.altostrat.com:8080/event_info?event_id=12345

Metadata.vendor_name

• Scopo: specifica il nome del fornitore del prodotto.
• Codifica: stringa alfanumerica sensibile alle maiuscole, punteggiatura consentita, massimo 256 byte
• Esempi:
  • CrowdStrike
  • Symantec

Popolazione dei metadati di Noun

In questa sezione, la parola Sostantivo è un termine generico utilizzato per rappresentare le seguenti entità: principal, src, target, intermediary, observer e about. Queste entità hanno attributi comuni, ma rappresentano oggetti diversi in un evento. Per saperne di più sulle entità e su ciò che ciascuna rappresenta in un evento, consulta Formattare un evento UDM.

Noun.asset_id

• Scopo: identificatore univoco del dispositivo specifico del fornitore (ad esempio, un GUID generato durante l'installazione del software di sicurezza degli endpoint su un nuovo dispositivo utilizzato per monitorare quel dispositivo univoco nel tempo).
• Codifica: (VendorName o VendorAbbreviation):ID dove VendorName o VendorAbbreviation è un nome del fornitore senza distinzione tra maiuscole e minuscole, come Carbon Black o CB, e ID è un identificatore del cliente specifico del fornitore che è univoco a livello globale nell'ambiente del cliente (ad esempio, un GUID o un valore univoco che identifica un dispositivo univoco). VendorName è alfanumerico e non supera i 32 caratteri. L'ID può contenere un massimo di 128 caratteri e può includere caratteri alfanumerici, trattini e punti.
• Esempio: CrowdStrike:0bce4259-4ada-48f3-a904-9a526b01311f
• Esempio: CS:0bce4259-4ada-48f3-a904-9a526b01311f

Noun.email

• Purpose: Email address
• Codifica: formato standard dell'indirizzo email.
• Esempio: [e-mail]

Noun.file

• Scopo: metadati dettagliati dei file.
• Tipo: Oggetto
• Consulta Popolamento dei metadati dei file.

Noun.hostname

• Finalità: campo del nome host o del nome di dominio del client. Non includere se è presente un URL.
• Codifica: nome host RFC 1123 valido.
• Limitazione di convalida: le stringhe del nome host non devono superare i 255 byte di lunghezza per rispettare i limiti di indicizzazione della Ricerca.
• Esempi:
  • userwin10
  • www.altostrat.com

Noun.platform

• Finalità: sistema operativo della piattaforma.
• Codifica: Enum
• Valori possibili:
  • LINUX
  • MAC
  • WINDOWS
  • UNKNOWN_PLATFORM

Noun.platform_patch_level

• Scopo: livello patch del sistema operativo della piattaforma.
• Codifica: stringa alfanumerica con punteggiatura, massimo 64 caratteri.
• Esempio: Build 17134.48

Noun.platform_version

• Scopo: versione del sistema operativo della piattaforma.
• Codifica: stringa alfanumerica con punteggiatura, massimo 64 caratteri.
• Esempio: Microsoft Windows 10 versione 1803

Noun.process

• Purpose: Detailed process metadata.
• Tipo: Oggetto
• Consulta Popolamento dei metadati di Process.

Noun.ip

• Scopo:
  • Singolo indirizzo IP associato a una connessione di rete.
  • Uno o più indirizzi IP associati a un dispositivo partecipante al momento dell'evento (ad esempio, se un prodotto EDR conosce tutti gli indirizzi IP associati a un dispositivo, può codificarli tutti all'interno dei campi IP).
• Codifica: stringa di indirizzo IPv4 (4 byte) o IPv6 (16 byte) valida (RFC 5942) codificata in ASCII.
• Ripetibilità:
  • Se un evento descrive una connessione di rete specifica (ad esempio srcip:srcport > dstip:dstport), devi fornire un solo indirizzo IP.
  • Se un evento descrive un'attività generale che si verifica su un dispositivo partecipante, ma non una connessione di rete specifica, puoi fornire tutti gli indirizzi IP associati al dispositivo al momento dell'evento.
• Esempi:
  • 192.168.1.2
  • 2001:db8:1:3::1

Noun.port

• Scopo: numero di porta di rete di origine o di destinazione quando una connessione di rete specifica viene descritta all'interno di un evento.

• Esempi:

  • 80
  • 443
  Nota: se viene specificato un numero di porta, deve essere specificato un solo indirizzo IP nello stesso sostantivo.

Noun.mac

• Scopo: uno o più indirizzi MAC associati a un dispositivo.
• Codifica: indirizzo MAC valido di 6 byte conforme al formato Identificatore Univoco Esteso a 48 bit (EUI-48) codificato in ASCII.
• Ripetibilità: puoi fornire tutti gli indirizzi MAC associati al dispositivo al momento dell'evento.
• Esempi:
  • 00:24:98:7B:19:02
  • 00:00:5e:00:53:2a

Noun.administrative_domain

• Scopo: dominio a cui appartiene il dispositivo (ad esempio, il dominio Windows).
• Codifica: stringa del nome di dominio valida (massimo 128 caratteri).
• Esempio: corp.altostrat.com

Noun.registry

• Scopo: metadati dettagliati del registry.
• Tipo: Oggetto
• Consulta Popolamento dei metadati del registry

Noun.url

• Scopo: URL standard
• Codifica: URL (RFC 3986). Deve avere un prefisso di protocollo valido (ad esempio https:// o ftp://). Deve includere il dominio e il percorso completi. Potrebbe includere i parametri dell'URL.
• Esempio: https://foo.altostrat.com/bletch?a=b;c=d

Noun.user

• Scopo: metadati utente dettagliati.
• Tipo: Oggetto
• Consulta Popolamento dei metadati utente.

Popolamento dei metadati di autenticazione

Authentication.AuthType

• Scopo: tipo di sistema a cui è associato un evento di autenticazione (UDM di Google Security Operations).
• Encoding: tipo enumerato.
• Valori possibili:
  • AUTHTYPE_UNSPECIFIED
  • MACHINE: autenticazione della macchina
  • PHYSICAL: autenticazione fisica (ad esempio, un lettore di badge)
  • SSO
  • TACACS: protocollo della famiglia TACACS per l'autenticazione dei sistemi di rete (ad esempio TACACS o TACACS+)
  • VPN

Authentication.Authentication_Status

• Scopo: descrive lo stato di autenticazione di un utente o di una credenziale specifica.
• Encoding: tipo enumerato.
• Valori possibili:
  • UNKNOWN_AUTHENTICATION_STATUS: stato di autenticazione predefinito
  • ACTIVE: il metodo di autenticazione è in stato attivo
  • SUSPENDED: il metodo di autenticazione è in stato sospeso o disattivato
  • DELETED: il metodo di autenticazione è stato eliminato
  • NO_ACTIVE_CREDENTIALS: il metodo di autenticazione non dispone di credenziali attive.

Authentication.auth_details

• Scopo: dettagli di autenticazione definiti dal fornitore.
• Codifica: stringa.

Authentication.Mechanism

• Scopo: meccanismi utilizzati per l'autenticazione.
• Encoding: tipo enumerato.
• Valori possibili:
  • MECHANISM_UNSPECIFIED: meccanismo di autenticazione predefinito.
  • BADGE_READER
  • BATCH: autenticazione batch.
  • CACHED_INTERACTIVE: autenticazione interattiva che utilizza le credenziali memorizzate nella cache.
  • HARDWARE_KEY
  • LOCALE
  • MECHANISM_OTHER: un altro meccanismo non definito qui.
  • NETWORK: autenticazione di rete.
  • NETWORK_CLEAR_TEXT: autenticazione di rete in testo non crittografato.
  • NEW_CREDENTIALS: autenticazione con nuove credenziali.
  • OTP
  • REMOTE: autenticazione remota
  • REMOTE_INTERACTIVE: RDP, servizi terminal, Virtual Network Computing (VNC) e così via.
  • SERVICE: autenticazione del servizio.
  • UNLOCK: autenticazione di sblocco diretta con interazione umana.
  • USERNAME_PASSWORD

Popolamento dei metadati DHCP

I campi dei metadati del protocollo DHCP (Dynamic Host Control Protocol) acquisiscono le informazioni di log del protocollo di gestione della rete DHCP.

Dhcp.client_hostname

• Purpose: Hostname for the client. Per saperne di più, consulta RFC 2132, DHCP Options and BOOTP Vendor Extensions.
• Codifica: stringa.
• Limitazione di convalida: le stringhe delle opzioni del nome host non devono superare i 255 byte di lunghezza per rispettare i limiti dell'indice della Ricerca.

Dhcp.client_identifier

• Finalità: identificatore del client. Per saperne di più, consulta RFC 2132, DHCP Options and BOOTP Vendor Extensions.
• Codifica: byte.

Dhcp.file

• Scopo: nome file per l'immagine di avvio.
• Codifica: stringa.

Dhcp.flags

• Scopo: valore per il campo dei flag DHCP.
• Codifica: numero intero non firmato a 32 bit.

Dhcp.hlen

• Purpose: Hardware address length.
• Codifica: numero intero non firmato a 32 bit.

Dhcp.hops

• Scopo: conteggio degli hop DHCP.
• Codifica: numero intero non firmato a 32 bit.

Dhcp.htype

• Scopo: tipo di indirizzo hardware.
• Codifica: numero intero non firmato a 32 bit.

Dhcp.lease_time_seconds

• Scopo: durata del lease richiesta dal client per un indirizzo IP in secondi. Per saperne di più, consulta RFC 2132, DHCP Options and BOOTP Vendor Extensions.
• Codifica: numero intero non firmato a 32 bit.

Dhcp.opcode

• Scopo: codice operativo BOOTP (consulta la sezione 3 di RFC 951).
• Encoding: tipo enumerato.
• Valori possibili:
  • UNKNOWN_OPCODE
  • BOOTREQUEST
  • BOOTREPLY

Dhcp.requested_address

• Finalità: identificatore del client. Per saperne di più, consulta RFC 2132, DHCP Options and BOOTP Vendor Extensions.
• Codifica: indirizzo IPv4 o IPv6 valido (RFC 5942) codificato in ASCII.

Dhcp.seconds

• Scopo: secondi trascorsi da quando il client ha avviato il processo di acquisizione o rinnovo dell'indirizzo.
• Codifica: numero intero non firmato a 32 bit.

Dhcp.sname

• Scopo: nome del server da cui il client ha richiesto l'avvio.
• Codifica: stringa.

Dhcp.transaction_id

• Scopo: ID transazione client.
• Codifica: numero intero non firmato a 32 bit.

Dhcp.type

• Scopo: tipo di messaggio DHCP. Per saperne di più, consulta RFC 1533.
• Encoding: tipo enumerato.
• Valori possibili:
  • UNKNOWN_MESSAGE_TYPE
  • DISCOVER
  • OFFERTA
  • RICHIEDI
  • RIFIUTO
  • ACK
  • NAK
  • RELEASE
  • INFORMA
  • WIN_DELECTED
  • WIN_EXPIRED

Dhcp.chaddr

• Scopo: indirizzo hardware del client.
• Codifica: indirizzo MAC.

Dhcp.ciaddr

• Scopo: indirizzo IP del client.
• Codifica: indirizzo IPv4 o IPv6 valido (RFC 5942) codificato in ASCII.

Dhcp.giaddr

• Scopo: indirizzo IP per l'agente di inoltro.
• Codifica: indirizzo IPv4 o IPv6 valido (RFC 5942) codificato in ASCII.

Dhcp.siaddr

• Scopo: indirizzo IP del server bootstrap successivo.
• Codifica: indirizzo IPv4 o IPv6 valido (RFC 5942) codificato in ASCII.

Dhcp.yiaddr

• Scopo: il tuo indirizzo IP.
• Codifica: indirizzo IPv4 o IPv6 valido (RFC 5942) codificato in ASCII.

Nota: quando Dhcp.type specifica ACK, OFFER o DECLINE, devi fornire un indirizzo IPv4 valido di 4 byte in Dhcp.yiaddr o Dhcp.requested_address E un indirizzo MAC corrispondente. Per gli opcode dei messaggi REQUEST, RELEASE, WIN_DELETED o WIN_EXPIRED, devi fornire un indirizzo IPv4 valido di 4 byte in Dhcp.ciaddr o Dhcp.yiaddr.

Compilazione dei metadati dell'opzione DHCP

I campi dei metadati dell'opzione DHCP acquisiscono le informazioni di log dell'opzione DHCP.

Option.code

• Scopo: memorizza il codice dell'opzione DHCP. Per saperne di più, consulta RFC 1533, DHCP Options and BOOTP Vendor Extensions.
• Codifica: numero intero a 32 bit senza segno.

Option.data

• Scopo: memorizza i dati delle opzioni DHCP. Per saperne di più, consulta RFC 1533, DHCP Options and BOOTP Vendor Extensions.
• Codifica: byte.

Popolamento dei metadati DNS

I campi dei metadati DNS acquisiscono informazioni relative ai pacchetti di richieste e risposte DNS. Hanno una corrispondenza uno a uno con i dati trovati nei datagrammi di richiesta e risposta DNS.

Dns.authoritative

• Scopo: impostato su true per i server DNS autoritativi.
• Codifica: booleano.

Dns.id

• Scopo: memorizza l'identificatore della query DNS.
• Codifica: numero intero a 32 bit.

Dns.response

• Scopo: impostato su true se l'evento è una risposta DNS.
• Codifica: booleano.

Dns.opcode

• Scopo: memorizza l'opcode DNS utilizzato per specificare il tipo di query DNS (standard, inversa, stato del server e così via).
• Codifica: numero intero a 32 bit.

Dns.recursion_available

• Scopo: impostato su true se è disponibile una ricerca DNS ricorsiva.
• Codifica: booleano.

Dns.recursion_desired

• Scopo: impostato su true se viene richiesta una ricerca DNS ricorsiva.
• Codifica: booleano.

Dns.response_code

• Scopo: memorizza il codice di risposta DNS come definito da RFC 1035, Nomi di dominio - Implementazione e specifica.
• Codifica: numero intero a 32 bit.

Dns.truncated

• Scopo: impostato su true se si tratta di una risposta DNS troncata.
• Codifica: booleano.

Dns.questions

• Scopo: memorizza le domande dei messaggi del protocollo di dominio. Consulta Popolamento dei metadati delle domande DNS.

Dns.answers

• Scopo: memorizza la risposta alla query sul nome di dominio. Consulta la sezione Popolamento dei metadati dei record di risorse DNS.

Dns.authority

• Scopo: memorizza i server dei nomi di dominio che hanno verificato la risposta alla query sul nome di dominio. Consulta la sezione Popolamento dei metadati dei record di risorse DNS.

Dns.additional

• Scopo: memorizza i server dei nomi di dominio aggiuntivi che possono essere utilizzati per verificare la risposta al dominio. Consulta la sezione Popolamento dei metadati dei record di risorse DNS.

Popolamento dei metadati delle domande DNS

I campi dei metadati della domanda DNS acquisiscono le informazioni contenute nella sezione della domanda di un messaggio del protocollo di dominio.

Question.name

• Scopo: memorizza il nome di dominio.
• Codifica: stringa.
• Limitazione di convalida: le stringhe di query del dominio non possono rimanere vuote e devono contenere al massimo 255 ottetti (byte) ai sensi delle normative RFC 1035 e dei limiti di indicizzazione dell'indice della Ricerca.

Question.class

• Scopo: memorizza il codice che specifica la classe della query.
• Codifica: numero intero a 32 bit.

Question.type

• Scopo: memorizza il codice che specifica il tipo di query.
• Codifica: numero intero a 32 bit.

Popolamento dei metadati dei record di risorse DNS

I campi dei metadati del record di risorse DNS acquisiscono le informazioni contenute nel record di risorse di un messaggio del protocollo di dominio.

ResourceRecord.binary_data

• Scopo: memorizza i byte non elaborati di eventuali stringhe non UTF8 che potrebbero essere incluse in una risposta DNS. Questo campo deve essere utilizzato solo se i dati di risposta restituiti dal server DNS contengono dati non UTF8. In caso contrario, inserisci la risposta DNS nel campo "data". Questo tipo di informazioni deve essere archiviato qui anziché in ResourceRecord.data.

• Codifica: byte.

  Nota: questo campo non è specificato in RFC 1035 (a differenza degli altri campi dei record di risorse DNS), ma è stato definito da Google SecOps per l'UDM.

ResourceRecord.class

• Scopo: memorizza il codice che specifica la classe del record di risorse.
• Codifica: numero intero a 32 bit.

ResourceRecord.data

• Scopo: memorizza il payload o la risposta alla domanda DNS per tutte le risposte codificate in formato UTF-8. Ad esempio, il campo di dati potrebbe restituire l'indirizzo IP della macchina a cui si riferisce il nome di dominio. Se il record di risorse è di un tipo o di una classe diversi, potrebbe contenere un altro nome di dominio (quando un nome di dominio viene reindirizzato a un altro nome di dominio). I dati devono essere archiviati esattamente come nella risposta DNS.
• Codifica: stringa.

ResourceRecord.name

• Scopo: memorizza il nome del proprietario del record di risorse.
• Codifica: stringa.

ResourceRecord.ttl

• Scopo: memorizza l'intervallo di tempo per il quale il record di risorse può essere memorizzato nella cache prima che l'origine delle informazioni venga nuovamente interrogata.
• Codifica: numero intero a 32 bit.

ResourceRecord.type

• Scopo: memorizza il codice che specifica il tipo di record di risorse.
• Codifica: numero intero a 32 bit.

Popolamento dei metadati delle email

La maggior parte dei campi dei metadati email acquisisce gli indirizzi email inclusi nell'intestazione del messaggio e deve essere conforme al formato standard degli indirizzi email (local-mailbox@domain) definito in RFC 5322. Ad esempio, [e-mail].

Email.from

• Scopo: memorizza l'indirizzo email del mittente.
• Codifica: stringa.

Email.reply_to

• Scopo: memorizza l'indirizzo email reply_to.
• Codifica: stringa.

Email.to

• Scopo: memorizza gli indirizzi email A.
• Codifica: stringa.

Email.cc

• Scopo: memorizza gli indirizzi email in Cc.
• Codifica: stringa.

Email.bcc

• Scopo: memorizza gli indirizzi email in Ccn.
• Codifica: stringa.

Email.mail_id

• Scopo: memorizza l'ID della posta (o del messaggio).
• Codifica: stringa.
• Esempio: [e-mail]

Email.subject

• Scopo: memorizza la riga dell'oggetto dell'email.
• Codifica: stringa.
• Esempio: "Leggi questo messaggio."

Popolamento dei metadati delle estensioni

Tipi di eventi con metadati integrati che non sono già classificati dal formato UDM di Google SecOps.

Extensions.auth

• Scopo: estensione dei metadati di autenticazione.
• Codifica: stringa.
• Esempi:
  • Metadati della sandbox (tutti i comportamenti mostrati da un file, ad esempio FireEye).
  • Dati di Network Access Control (NAC).
  • Dettagli LDAP su un utente (ad esempio ruolo, organizzazione e così via).

Extensions.auth.auth_details

• Scopo: specifica i dettagli specifici del fornitore per il tipo o il meccanismo di autenticazione. I provider di autenticazione spesso definiscono tipi come via_mfa o via_ad che forniscono informazioni utili sul tipo di autenticazione. Questi tipi possono comunque essere generalizzati in auth.type o auth.mechanism per l'usabilità e la compatibilità delle regole tra set di dati.
• Codifica: stringa.
• Esempi: via_mfa, via_ad.

Extensions.vulns

• Scopo: estensione ai metadati della vulnerabilità.
• Codifica: stringa.
• Esempio: dati di scansione delle vulnerabilità dell'host.

Popolamento dei metadati dei file

File.file_metadata

• Scopo: metadati associati al file.
• Codifica: stringa.
• Esempi:
  • Autore
  • Numero di revisione
  • Numero di versione
  • Data dell'ultimo salvataggio

File.full_path

• Scopo: percorso completo che identifica la posizione del file nel sistema.
• Codifica: stringa.
• Esempio: \Program Files\Custom Utilities\Test.exe

File.md5

• Scopo: valore hash MD5 del file.
• Codifica: stringa, esadecimale in minuscolo.
• Esempio: 35bf623e7db9bf0d68d0dda764fd9e8c

File.mime_type

• Scopo: tipo MIME (Multipurpose Internet Mail Extensions) del file.
• Codifica: stringa.
• Esempi:
  • PE
  • PDF
  • script di PowerShell

File.sha1

• Scopo: valore hash SHA-1 per il file.
• Codifica: stringa, esadecimale in minuscolo.
• Esempio: eb3520d53b45815912f2391b713011453ed8abcf

File.sha256

• Scopo: valore hash SHA-256 per il file.
• Codifica: stringa, esadecimale in minuscolo.
• Esempio: d7173c568b8985e61b4050f81b3fd8e75bc922d2a0843d7079c81ca4b6e36417

File.size

• Scopo: dimensioni del file.
• Codifica: numero intero non firmato a 64 bit.
• Esempio: 342135

Popolamento dei metadati FTP

Ftp.command

• Scopo: memorizza il comando FTP.
• Codifica: stringa.
• Esempi:
  • binario
  • elimina
  • get
  • put

Popolamento dei metadati del gruppo

Informazioni su un gruppo organizzativo. Per rappresentare un'identità di gruppo organizzativo valida durante la normalizzazione, devi parametrizzare almeno un attributo del gruppo principale specificando un indirizzo email in Group.email_addresses o un identificatore di sicurezza di Windows in Group.windows_sid.

Group.creation_time

• Scopo: ora di creazione del gruppo.
• Codifica: RFC 3339, in base al formato del timestamp JSON o Proto3.

Group.email_addresses

• Scopo: raggruppare i dati di contatto.
• Codifica: Email.

Group.group_display_name

• Scopo: nome visualizzato del gruppo.
• Codifica: stringa.
• Esempi:
  • Finanza
  • HR
  • Marketing

Group.product_object_id

• Scopo: identificatore univoco globale dell'oggetto utente per il prodotto, ad esempio un identificatore di oggetto LDAP.
• Codifica: stringa.

Group.windows_sid

• Scopo: campo dell'attributo di gruppo Identificatore di sicurezza (SID) di Microsoft Windows.
• Codifica: stringa.

Popolamento dei metadati HTTP

Http.method

• Scopo: memorizza il metodo di richiesta HTTP. Quando il traffico avviene tramite protocolli di trasporto HTTP o HTTPS, devi specificare un metodo di richiesta attivo; non puoi lasciare il metodo impostato su METHOD_UNSPECIFIED.
• Codifica: stringa.
• Esempi:
  • GET
  • HEAD
  • POST

Http.referral_url

• Scopo: memorizza l'URL del referrer HTTP.
• Codifica: URL RFC 3986 valido.
• Esempio: https://www.altostrat.com

Http.response_code

• Scopo: memorizza il codice di stato della risposta HTTP, che indica se una richiesta HTTP specifica è stata completata correttamente.
• Codifica: numero intero a 32 bit.
• Esempi:
  • 400
  • 404

Http.user_agent

• Scopo: memorizza l'intestazione della richiesta dello user agent che include il tipo di applicazione, il sistema operativo, il fornitore del software o la versione software dello user agent del software richiedente. Le stringhe di intestazione User-Agent devono essere costituite interamente da array di caratteri con codifica UTF-8 valida.
• Codifica: stringa.
• Esempi:
  • Mozilla/5.0 (X11; Linux x86_64)
  • AppleWebKit/534.26 (KHTML, like Gecko)
  • Chrome/41.0.2217.0
  • Safari/527.33

Popolamento dei metadati sulla posizione

Location.city

• Scopo: memorizza il nome della città.
• Codifica: stringa.
• Esempi:
  • Sunnyvale
  • Chicago
  • Malaga

Location.country_or_region

• Scopo: memorizza il nome del paese o della regione del mondo.
• Codifica: stringa.
• Esempi:
  • Stati Uniti
  • Regno Unito
  • Spagna

Location.name

• Scopo: memorizza il nome specifico dell'azienda, ad esempio un edificio o un campus.
• Codifica: stringa.
• Esempi:
  • Campus 7B
  • Edificio A2

Location.state

• Scopo: memorizza il nome dello stato, della provincia o del territorio.
• Codifica: stringa.
• Esempi:
  • California
  • Illinois
  • Ontario

Compilazione dei metadati di rete

Network.application_protocol

• Scopo: indica il protocollo dell'applicazione di rete.
• Encoding: tipo enumerato.

• Valori possibili:

  • UNKNOWN_APPLICATION_PROTOCOL
  • AFP
  • APPC
  • AMQP
  • ATOM
  • BEEP
  • BITCOIN
  • BIT_TORRENT
  • CFDP
  • CIP
  • COAP
  • COTP
  • DCERPC
  • DDS
  • DEVICE_NET
  • DHCP
  • DICOM
  • DNP3
  • DNS
  • E_DONKEY
  • ENRP
  • FAST_TRACK
  • FINGER
  • FREENET
  • FTAM
  • GOOSE
  • GOPHER
  • GRPC
  • HL7
  • H323
  • HTTP
  • HTTPS
  • IEC104
  • IRCP
  • KADEMLIA
  • KRB5
  • LDAP
  • LPD
  • MIME
  • MMS
  • MODBUS
  • MQTT
  • NETCONF
  • NFS
  • NIS
  • NNTP
  • NTCIP
  • NTP
  • OSCAR
  • PNRP
  • PTP
  • QUIC
  • RDP
  • RELP
  • RIP
  • RLOGIN
  • RPC
  • RTMP
  • RTP
  • RTPS
  • RTSP
  • SAP
  • SDP
  • SIP
  • SLP
  • SMB
  • SMTP
  • SNMP
  • SNTP
  • SSH
  • SSMS
  • STYX
  • SV
  • TCAP
  • TDS
  • TOR
  • TSP
  • VTP
  • WHOIS
  • WEB_DAV
  • X400
  • X500
  • XMPP

Network.direction

• Scopo: indica la direzione del traffico di rete.
• Encoding: tipo enumerato.
• Valori possibili:
  • UNKNOWN_DIRECTION
  • INBOUND
  • OUTBOUND
  • BROADCAST

Network.email

• Scopo: specifica l'indirizzo email del mittente/destinatario.
• Codifica: stringa.
• Esempio: [e-mail]

Network.ip_protocol

• Purpose: indica il protocollo IP.
• Encoding: tipo enumerato.
• Valori possibili:
  • UNKNOWN_IP_PROTOCOL
  • EIGRP: Enhanced Interior Gateway Routing Protocol
  • ESP: Encapsulating Security Payload
  • ETHERIP: incapsulamento Ethernet-within-IP
  • GRE (Generic Routing Encapsulation)
  • ICMP: Internet Control Message Protocol
  • IGMP: Internet Group Management Protocol
  • IP6IN4: incapsulamento IPv6
  • PIM (Protocol Independent Multicast)
  • TCP: Transmission Control Protocol
  • UDP: User Datagram Protocol
  • VRRP: Virtual Router Redundancy Protocol

Network.received_bytes

• Scopo: specifica il numero di byte ricevuti.
• Codifica: numero intero non firmato a 64 bit.
• Esempio: 12.453.654.768

Network.sent_bytes

• Scopo: specifica il numero di byte inviati.
• Codifica: numero intero non firmato a 64 bit.
• Esempio: 7.654.876

Network.session_duration

• Scopo: memorizza la durata della sessione di rete, in genere restituita in un evento di interruzione della sessione. Per impostare la durata, puoi impostare network.session_duration.seconds = 1 (tipo int64) o network.session_duration.nanos = 1 (tipo int32).
• Codifica:
  • Numero intero a 32 bit: per i secondi (network.session_duration.seconds).
  • Numero intero a 64 bit: per i nanosecondi (network.session_duration.nanos).

Network.session_id

• Scopo: memorizza l'identificatore della sessione di rete.
• Codifica: stringa.
• Esempio: SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-01:34

Popolazione dei metadati di processo

Process.command_line

• Scopo: memorizza la stringa della riga di comando per il processo.
• Codifica: stringa.
• Esempio: gruppo c:\windows\system32\net.exe.

Process.product_specific_process_id

• Scopo: memorizza l'ID di processo specifico del prodotto.
• Codifica: stringa.
• Esempi: MySQL:78778 o CS:90512

Process.parent_process.product_specific_process_id

• Scopo: memorizza l'ID di processo specifico del prodotto per il processo padre.
• Codifica: stringa.
• Esempi: MySQL:78778 o CS:90512

Process.file

• Scopo: memorizza il nome del file in uso dal processo.
• Codifica: stringa.
• Esempio: report.xls

Process.parent_process

• Scopo: memorizza i dettagli del processo principale.
• Encoding: sostantivo (processo)

Process.pid

• Scopo: memorizza l'ID di processo.
• Codifica: stringa.
• Esempi:
  • 308
  • 2002

Popolamento dei metadati del registry

Registry.registry_key

• Scopo: memorizza la chiave del registry associata a un'applicazione o a un componente di sistema.
• Codifica: stringa.
• Esempio: HKEY_LOCAL_MACHINE/SYSTEM/DriverDatabase

Registry.registry_value_name

• Scopo: memorizza il nome del valore del registry associato a un'applicazione o a un componente di sistema.
• Codifica: stringa.
• Esempio: TEMP

Registry.registry_value_data

• Scopo: memorizza i dati associati a un valore del registry.
• Codifica: stringa.
• Esempio: %USERPROFILE%\Local Settings\Temp

Popolamento dei metadati dei risultati di sicurezza

I metadati dei risultati di sicurezza includono dettagli sui rischi e sulle minacce alla sicurezza rilevati da un sistema di sicurezza, nonché sulle azioni intraprese per mitigarli.

SecurityResult.about

• Scopo: fornire una descrizione del risultato di sicurezza.
• Codifica: sostantivo.

SecurityResult.action

• Scopo: specifica un'azione di sicurezza.
• Encoding: tipo enumerato.
• Valori possibili: l'UDM di Google SecOps definisce le seguenti azioni di sicurezza:
  • CONSENTI
  • ALLOW_WITH_MODIFICATION: il file o l'email è stato disinfettato o riscritto e comunque inoltrato.
  • BLOCCA
  • QUARANTINE: archivia per un'analisi successiva (non significa bloccare).
  • UNKNOWN_ACTION

SecurityResult.action_details

• Scopo: dettagli forniti dal fornitore sull'azione intrapresa a seguito dell'incidente di sicurezza. Le azioni di sicurezza spesso si traducono meglio nel campo UDM più generale Security_Result.action. Tuttavia, potresti dover scrivere regole per la descrizione esatta dell'azione fornita dal fornitore.
• Codifica: stringa.
• Esempi: drop, block, decrypt, encrypt.

SecurityResult.category

• Scopo: specifica una categoria di sicurezza.
• Codifica: Enum.
• Valori possibili: Google SecOps UDM definisce le seguenti categorie di sicurezza:
  • ACL_VIOLATION: tentativo di accesso non autorizzato, incluso il tentativo di accesso a file, servizi web, processi, oggetti web e così via.
  • AUTH_VIOLATION: autenticazione non riuscita, ad esempio password errata o autenticazione a due fattori errata.
  • DATA_AT_REST—DLP: dati dei sensori trovati at-rest in una scansione.
  • DATA_DESTRUCTION: tentativo di distruggere o eliminare i dati.
  • DATA_EXFILTRATION: DLP: trasmissione dei dati dei sensori, copia su unità flash.
  • EXPLOIT: overflow tentati, codifiche di protocollo errate, ROP, SQL injection e così via, sia basati su rete che su host.
  • MAIL_PHISHING: email di phishing, messaggi chat e così via.
  • MAIL_SPAM: email, messaggio e così via di spam.
  • MAIL_SPOOFING: indirizzo email di origine falsificato e così via.
  • NETWORK_CATEGORIZED_CONTENT
  • NETWORK_COMMAND_AND_CONTROL: se il canale di comando e controllo è noto.
  • NETWORK_DENIAL_OF_SERVICE
  • NETWORK_MALICIOUS: comando e controllo, exploit di rete, attività sospetta, potenziale tunnel inverso e così via.
  • NETWORK_SUSPICIOUS: non correlato alla sicurezza, ad esempio l'URL è collegato a giochi e scommesse e così via.
  • NETWORK_RECON: scansione delle porte rilevata da un IDS, probing da parte di un'applicazione web.
  • POLICY_VIOLATION: violazione delle policy di sicurezza, incluse violazioni delle regole di firewall, proxy e HIPS o azioni di blocco NAC.
  • SOFTWARE_MALICIOUS: malware, spyware, rootkit e così via.
  • SOFTWARE_PUA: app potenzialmente indesiderata, ad esempio adware e così via.
  • SOFTWARE_SUSPICIOUS
  • UNKNOWN_CATEGORY

SecurityResult.confidence

• Scopo: specifica un livello di confidenza relativo a un evento di sicurezza stimato dal prodotto.
• Codifica: Enum.
• Valori possibili: l'UDM di Google SecOps definisce le seguenti categorie di affidabilità del prodotto:
  • UNKNOWN_CONFIDENCE
  • LOW_CONFIDENCE
  • MEDIUM_CONFIDENCE
  • HIGH_CONFIDENCE

SecurityResult.confidence_details

• Scopo: dettagli aggiuntivi relativi alla confidenza di un evento di sicurezza, come stimato dal fornitore del prodotto.
• Codifica: stringa.

SecurityResult.priority

• Scopo: specifica una priorità relativa a un evento di sicurezza, come stimato dal fornitore del prodotto.
• Codifica: Enum.
• Valori possibili: Google SecOps UDM definisce le seguenti categorie di priorità dei prodotti:
  • UNKNOWN_PRIORITY
  • LOW_PRIORITY
  • MEDIUM_PRIORITY
  • HIGH_PRIORITY

SecurityResult.priority_details

• Scopo: informazioni specifiche del fornitore sulla priorità del risultato di sicurezza.
• Codifica: stringa.

SecurityResult.rule_id

• Scopo: identificatore della regola di sicurezza.
• Codifica: stringa.
• Esempi:
  • 08123
  • 5d2b44d0-5ef6-40f5-a704-47d61d3babbe

SecurityResult.rule_name

• Scopo: nome della regola di sicurezza.
• Codifica: stringa.
• Esempio: BlockInboundToOracle.

SecurityResult.severity

• Scopo: gravità di un evento di sicurezza stimata dal fornitore del prodotto utilizzando i valori definiti dall'UDM di Google SecOps.
• Codifica: Enum.
• Valori possibili: Google SecOps UDM definisce le seguenti gravità del prodotto:
  • UNKNOWN_SEVERITY: non dannoso
  • INFORMATIVA: non dannoso
  • ERRORE: non dannoso
  • BASSO - Dannoso
  • MEDIA - Maligni
  • ALTO - Dannoso

SecurityResult.severity_details

• Scopo: gravità di un evento di sicurezza stimata dal fornitore del prodotto.
• Codifica: stringa.

SecurityResult.threat_name

• Scopo: nome della minaccia alla sicurezza.
• Codifica: stringa.
• Esempi:
  • W32/File-A
  • Slammer

SecurityResult.url_back_to_product

• Scopo: URL che ti indirizza alla console del prodotto di origine per questo evento di sicurezza.
• Codifica: stringa.

Popolamento dei metadati utente

Nota: tutti i parametri principali dell'account utente, in particolare User.userid, User.windows_sid, User.employee_id e ogni singolo indirizzo email all'interno di User.email_addresses, hanno un limite di lunghezza strutturale obbligatorio di 256 caratteri. Se fornisci una stringa di identità dell'account più lunga di 256 caratteri, la verifica dell'indicizzazione rifiuta il payload. Inoltre, per superare i controlli di base dell'identità utente durante la normalizzazione, devi compilare almeno una di queste quattro proprietà di base.

User.email_addresses

• Scopo: memorizza gli indirizzi email dell'utente.
• Codifica: stringa ripetuta.
• Esempio: [e-mail]

User.employee_id

• Scopo: memorizza l'ID dipendente delle risorse umane per l'utente.
• Codifica: stringa.
• Esempio: 11223344.

User.first_name

• Purpose: Stores the first name for the user.
• Codifica: stringa.
• Esempio: Mario.

User.middle_name

• Scopo: memorizza il secondo nome dell'utente.
• Codifica: stringa.
• Esempio: Antonio.

User.last_name

• Scopo: memorizza il cognome dell'utente.
• Codifica: stringa.
• Esempio: Locke.

User.group_identifiers

• Scopo: memorizza gli ID gruppo (un GUID, un OID LDAP o simili) associati a un utente.
• Codifica: stringa ripetuta.
• Esempio: admin-users.

User.phone_numbers

• Scopo: memorizza i numeri di telefono dell'utente.
• Codifica: stringa ripetuta.
• Esempio: 18005550101

User.title

• Scopo: memorizza la qualifica dell'utente.
• Codifica: stringa.
• Esempio: Customer Relationship Manager.

User.user_display_name

• Scopo: memorizza il nome visualizzato dell'utente.
• Codifica: stringa.
• Esempio: John Locke.

User.userid

• Scopo: memorizza l'ID utente.
• Codifica: stringa.
• Esempio: jlocke.

User.windows_sid

• Scopo: memorizza l'identificatore di sicurezza (SID) di Microsoft Windows associato a un utente.
• Codifica: stringa.
• Esempio: S-1-5-21-1180649209-123456789-3582944384-1064

Popolamento dei metadati delle vulnerabilità

Vulnerability.about

• Scopo: se la vulnerabilità riguarda un sostantivo specifico (ad esempio, eseguibile), aggiungilo qui.
• Codifica: sostantivo. Consulta Popolazione dei metadati di Noun
• Esempio: eseguibile.

Vulnerability.cvss_base_score

• Scopo: punteggio di base per il sistema di valutazione delle vulnerabilità comuni (CVSS).
• Codifica: rappresentazione in virgola mobile.
• Intervallo: da 0,0 a 10,0
• Esempio: 8.5

Vulnerability.cvss_vector

• Scopo: vettore per le proprietà CVSS della vulnerabilità. Un punteggio CVSS è composto dalle seguenti metriche:

  • Vettore d'attacco (AV)
  • Access Complexity (AC)
  • Autenticazione (Au)
  • Impatto sulla riservatezza (C)
  • Impatto sull'integrità (I)
  • Impatto sulla disponibilità (A)

  Per saperne di più, visita la pagina https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator.

• Codifica: stringa.

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

Vulnerability.cvss_version

• Scopo: versione CVSS per il punteggio o il vettore della vulnerabilità.
• Codifica: stringa.
• Esempio: 3.1

Vulnerability.description

• Scopo: descrizione della vulnerabilità.
• Codifica: stringa.

Vulnerability.first_found

• Scopo: i prodotti che mantengono una cronologia delle analisi delle vulnerabilità devono compilare first_found con l'ora in cui è stata rilevata per la prima volta la vulnerabilità per questo asset.
• Codifica: stringa.

Vulnerability.last_found

• Scopo: i prodotti che mantengono una cronologia delle analisi delle vulnerabilità devono compilare last_found con l'ora in cui è stata rilevata più di recente la vulnerabilità per questo asset.
• Codifica: stringa.

Vulnerability.name

• Scopo: nome della vulnerabilità.
• Codifica: stringa.
• Esempio: è stata rilevata una versione del sistema operativo non supportata.

Vulnerability.scan_end_time

• Scopo: se la vulnerabilità è stata rilevata durante una scansione degli asset, compila questo campo con l'ora di fine della scansione. Lascia questo campo vuoto se l'ora di fine non è disponibile o non è applicabile.
• Codifica: stringa.

Vulnerability.scan_start_time

• Scopo: se la vulnerabilità è stata rilevata durante una scansione degli asset, compila questo campo con l'ora di inizio della scansione. Lascia questo campo vuoto se l'ora di inizio non è disponibile o non è applicabile.
• Codifica: stringa.

Vulnerability.severity

• Finalità: gravità della vulnerabilità.
• Encoding: tipo enumerato.
• Valori possibili:
  • UNKNOWN_SEVERITY
  • BASSO
  • MEDIO
  • ALTO

Vulnerability.severity_details

• Scopo: dettagli sulla gravità specifici del fornitore.
• Codifica: stringa.

Popolamento dei metadati degli avvisi

Attenzione: questi campi sono deprecati. Utilizza gli avvisi delle regole di rilevamento YARA-L per i metadati degli avvisi. Per saperne di più, consulta Ritiro delle funzionalità.

idm.is_significant

• Scopo: specifica se visualizzare l'avviso in Enterprise Insights.
• Codifica: booleano.

idm.is_alert

• Scopo: identifica se l'evento è un avviso.
• Codifica: booleano.

Campi obbligatori e facoltativi per i tipi di entità

Tipo di entità	Requisiti specifici per persona giuridica
IP_ADDRESS	entity.ip deve contenere almeno un indirizzo IPv4 o IPv6 valido.
FILE	entity.file deve essere presente e contenere almeno un campo.
DOMAIN_NAME	entity.hostname deve essere presente e rappresentare un nome host valido di lunghezza massima di 255 byte. Optional: se entity.domain.whois_server è compilato, il messaggio entity.domain non deve contenere più di 50 campi dedotti.
URL	entity.url deve essere presente e non vuoto.
MUTEX	entity.resource deve essere presente. entity.resource.resource_type deve essere impostato su MUTEX. entity.resource.name deve essere presente e non vuoto.
USER	entity.user deve essere presente. Per le entità di contesto, entity.user deve specificare almeno un campo di identità principale: user.userid, user.windows_sid, user.employee_id o un indirizzo email in user.email_addresses. Ogni identificatore principale non deve superare i 256 caratteri. Inoltre, devi fornire product_object_id in entity.user o product_entity_id in metadata. Per le entità indicatore di compromissione (IOC), entity.user deve avere almeno un indirizzo email specificato in user.email_addresses.
RESOURCE	entity.resource deve essere presente. Per le entità di contesto, entity.resource.resource_type deve essere specificato e non vuoto e devi fornire product_object_id in entity.resource o product_entity_id in metadata. Per le entità indicatore di compromissione (IOC), entity.resource.resource_type deve essere impostato su MUTEX o STORAGE_OBJECT. Se resource_type è MUTEX: segui i requisiti di MUTEX. Se resource_type è STORAGE_OBJECT: entity.resource.resource_subtype deve essere presente e non vuoto. Almeno uno dei seguenti campi in entity.registry deve essere presente e non vuoto: entity.registry.registry_key entity.registry.registry_value_data entity.registry.registry_value_name
CIDR_BLOCK	entity.network.ip_subnet_range deve essere presente e includere una notazione CIDR (Classless Inter-Domain Routing) valida nel seguente formato: ip_address/prefix_length.
ASSET	entity.asset deve essere presente. entity.asset deve contenere almeno un campo di identità principale: asset.hostname, asset.asset_id, un indirizzo IP in asset.ip o un indirizzo MAC in asset.mac. Tutti gli indirizzi IP forniti devono essere in formato IPv4 o IPv6 valido. Devi fornire product_object_id in entity.asset o product_entity_id in metadata.
GROUP	entity.group deve essere presente. entity.group deve specificare almeno un campo di identità principale: un indirizzo email in group.email_addresses o un identificatore di sicurezza di Windows in group.windows_sid. Devi fornire product_object_id in entity.group o product_entity_id in metadata.
AI	entity.ai deve essere presente.

Campi obbligatori e facoltativi per ogni tipo di evento

Questa sezione descrive i campi obbligatori e facoltativi che devono essere compilati per ogni tipo di evento UDM.

Per informazioni dettagliate su campi UDM specifici (ad esempio, numeri enum), consulta l'elenco dei campi Unified Data Model.

DEVICE_CONFIG_UPDATE, DEVICE_FIRMWARE_UPDATE, DEVICE_PROGRAM_DOWNLOAD, DEVICE_PROGRAM_UPLOAD

Campi obbligatori:

• metadata: includi i campi obbligatori (event_timestamp e event_type).
• principal: includi almeno un identificatore della macchina (principal.hostname, principal.ip, principal.mac o principal.asset_id).

Campi facoltativi:

• principal.user: compila se sono disponibili informazioni sull'utente per l'account che ha avviato l'aggiornamento del dispositivo.
• target: compila con i dettagli relativi al dispositivo di destinazione, al firmware, alla risorsa di configurazione o al file di programma, se diversi da principal.
• security_result: descrive qualsiasi attività dannosa o anomala rilevata.

Esempio di UDM per DEVICE_FIRMWARE_UPDATE

L'esempio seguente mostra come formattare un evento DEVICE_FIRMWARE_UPDATE per l'UDM di Google SecOps:

{
  "metadata": {
    "event_timestamp": "2025-03-10T14:22:05.000000Z",
    "event_type": "DEVICE_FIRMWARE_UPDATE"
  },
  "principal": {
    "hostname": "plc-controller-01",
    "ip": [
      "10.20.30.40"
    ]
  }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: informazioni sul dispositivo su cui è stato eseguito l'aggiornamento firmware.

EMAIL_TRANSACTION, EMAIL_UNCATEGORIZED

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal: compila con le informazioni sulla macchina da cui ha avuto origine l'email (ad esempio, l'indirizzo IP del mittente).

Campi facoltativi:

• Informazioni: URL, IP, domini ed eventuali file allegati incorporati nel corpo dell'email. Tieni presente che about.file.hash non è un campo indicizzato per gli hash dei file. Le visualizzazioni degli hash non verranno compilate da un hash dell'allegato normalizzato in questo campo.
• securityResult.about: URL, IP e file dannosi incorporati nel corpo dell'email.
• network.email: informazioni sul mittente o sul destinatario dell'email. Tieni presente che network.email non è un campo di aliasing. Se hai bisogno di aliasing e arricchimento per la ricerca o il rilevamento, dovrai indicizzare in principal o target utilizzando un'estensione del parser.
• principal: se sono presenti dati della macchina client su chi ha inviato l'email, compila i dettagli del server in principal (ad esempio, il processo client, i numeri di porta, il nome utente e così via).
• target: se sono presenti dati del server email di destinazione, compila i dettagli del server nel target (ad esempio l'indirizzo IP).
• intermediary: se sono presenti dati del server di posta o del proxy di posta, compila i dettagli del server in intermediary.

Note:

• Non compilare mai principal.email o target.email.
• Compila solo il campo email in security_result.about o network.email.
• I risultati di sicurezza di primo livello generalmente hanno un insieme di sostantivi (facoltativo per lo spam).
• EMAIL_URL_CLICK è contrassegnato come deprecato.

Esempio di UDM per EMAIL_TRANSACTION

L'esempio seguente illustra come un evento di tipo EMAIL_TRANSACTION verrebbe formattato per Google SecOps UDM:

metadata {
  event_timestamp: "2023-07-06T06:26:10.448584Z"
  event_type: EMAIL_TRANSACTION
}
principal {
  ip: "1.2.3.4"
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: informazioni sul dispositivo da cui è stata inviata l'email.

FILE_CREATION, FILE_DELETION, FILE_MODIFICATION, FILE_READ, FILE_OPEN e FILE_UNCATEGORIZED

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal:
  • Almeno un identificatore della macchina.
  • (Facoltativo) Compila principal.process con le informazioni sul processo che accede al file.
• target:
  • Se il file è remoto (ad esempio una condivisione SMB), la destinazione deve includere almeno un identificatore della macchina di destinazione, altrimenti tutti gli identificatori della macchina devono essere vuoti.
  • Compila target.file con le informazioni sul file.

Campi facoltativi:

• security_result: descrive l'attività dannosa rilevata.
• principal.user: compila se sono disponibili informazioni sull'utente relative al processo.

Esempio di UDM per FILE_MODIFICATION

L'esempio seguente illustra come un evento di tipo FILE_MODIFICATION verrebbe formattato per l'UDM di Google SecOps:

metadata {
  event_timestamp: "2023-07-03T12:14:38.164507Z"
  event_type: FILE_MODIFICATION
}
principal {
  hostname: "pinguino-01"
}
target {
  file {
    full_path: "foo.bar"
  }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: informazioni sul dispositivo su cui è stata eseguita la modifica del file.
• target: informazioni sul file modificato.

FILE_COPY

Campi obbligatori:

• metadata: includi i campi obbligatori come descritto.
• principal:
  • Almeno un identificatore della macchina.
  • (Facoltativo) Compila principal.process con le informazioni sul processo che esegue l'operazione di copia del file.
• src:
  • Compila src.file con le informazioni sul file di origine.
  • Se il file è remoto (ad esempio una condivisione SMB), src deve includere almeno un identificatore della macchina di origine in cui è archiviato il file di origine.
• target:
  • Compila target.file con le informazioni sul file di destinazione.
  • Se il file è remoto (ad esempio una condivisione SMB), il campo target deve includere almeno un identificatore della macchina di destinazione che contiene il file di destinazione.

Campi facoltativi:

• security_result: descrive l'attività dannosa rilevata.
• principal.user: compila se sono disponibili informazioni sull'utente relative al processo.

FILE_MOVE, FILE_SYNC

Campi obbligatori:

• metadata: informazioni di base sull'evento.
• principal: almeno un identificatore della macchina (ad esempio, principal.hostname).
• src: compila src.file (ad esempio, src.file.full_path) per rappresentare il file originale. Questo campo è obbligatorio per FILE_MOVE e FILE_COPY. Per FILE_SYNC, devi compilare almeno uno tra src.file e target.file (e target non deve essere vuoto).
• target: compila target.file (ad esempio target.file.full_path) per rappresentare il file di destinazione. Questo campo è obbligatorio per FILE_MOVE e FILE_COPY. Per FILE_SYNC, devi compilare almeno uno tra src.file e target.file.

Esempio UDM per FILE_MOVE

L'esempio seguente illustra come un evento di tipo FILE_MOVE verrebbe formattato per l'UDM di Google SecOps:

{
    "metadata": {
        "event_timestamp": "2023-07-03T12:45:02.557878Z",
        "event_type": "FILE_MOVE"
    },
    "src": {
        "file": {
            "full_path": "foo.bar"
        }
    },
    "principal": {
        "hostname": "pinguino-01"
    },
    "target": {
        "file": {
            "full_path": "foo.bar"
        }
    }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: informazioni sul dispositivo su cui è avvenuto lo spostamento del file.
• src: informazioni sul file di origine.
• target: informazioni sul file di destinazione.

GENERIC_EVENT

Utilizza GENERIC_EVENT solo quando un evento non rientra in nessun'altra categoria di tipo di evento UDM.

Campi obbligatori:

• metadata: includi i campi obbligatori (event_timestamp e event_type).

Campi facoltativi:

• metadata.product_event_type e metadata.description: includi il nome dell'evento specifico del fornitore e la descrizione leggibile.
• principal, target, src, intermediary, observer e about: compila tutte le entità coinvolte nell'evento. GENERIC_EVENT non applica requisiti di campo specifici per le entità oltre alla convalida standard del tipo scalare (ad esempio indirizzi IP e nomi host validi fino a 255 byte).
• security_result: descrive qualsiasi attività dannosa o anomala rilevata.

Esempio di UDM per GENERIC_EVENT

L'esempio seguente mostra come formattare un evento GENERIC_EVENT per l'UDM di Google SecOps:

{
  "metadata": {
    "event_timestamp": "2025-03-10T15:00:00.000000Z",
    "event_type": "GENERIC_EVENT",
    "product_event_type": "CustomAuditEvent",
    "description": "Custom audit event recorded on host"
  },
  "principal": {
    "hostname": "workstation-01"
  }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base e descrizione dell'evento specifica del fornitore.
• principal: informazioni sul dispositivo associato all'evento.

GROUP_CREATION, GROUP_DELETION, GROUP_MODIFICATION, GROUP_UNCATEGORIZED

Campi obbligatori:

• metadata: includi i campi obbligatori (event_timestamp e event_type).
• principal: includi almeno un identificatore dell'utente in principal.user (userid, windows_sid, email_addresses o employee_id).
• target: compila target.group con i dettagli relativi al gruppo che viene creato, eliminato o modificato (e target.user se un utente viene aggiunto o rimosso dal gruppo). Il campo target non deve essere vuoto.

Campi facoltativi:

• principal: include gli identificatori della macchina per il dispositivo da cui ha avuto origine l'operazione di gruppo.
• target.group: includi identificatori di gruppo come group_display_name, product_object_id, windows_sid o email_addresses.
• security_result: descrive qualsiasi attività dannosa rilevata.

Esempio di UDM per GROUP_MODIFICATION

L'esempio seguente mostra come formattare un evento GROUP_MODIFICATION per l'UDM di Google SecOps:

{
  "metadata": {
    "event_timestamp": "2025-03-10T16:10:00.000000Z",
    "event_type": "GROUP_MODIFICATION"
  },
  "principal": {
    "user": {
      "userid": "admin_user"
    }
  },
  "target": {
    "group": {
      "group_display_name": "Domain Admins",
      "windows_sid": "S-1-5-21-3623811015-3361044348-30300820-512"
    },
    "user": {
      "userid": "jdoe"
    }
  }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: informazioni sull'utente che ha modificato il gruppo.
• target: informazioni sul gruppo modificato e sull'utente interessato.

MUTEX_CREATION, MUTEX_UNCATEGORIZED

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal:
  • Almeno un identificatore della macchina.
  • Compila principal.process con le informazioni sul processo che crea il mutex. La convalida UDM richiede un oggetto di processo in principal. Non puoi superare la convalida UDM con un processo solo nel target.
• target:
  • Compila target.resource.
  • Compila target.resource.type con MUTEX.
  • Compila target.resource.name con il nome del mutex creato.

Campi facoltativi:

• security_result: descrive l'attività dannosa rilevata.
• principal.user: compila se sono disponibili informazioni sull'utente relative al processo.

Esempio di UDM per MUTEX_CREATION

L'esempio seguente illustra come un evento di tipo MUTEX_CREATION verrebbe formattato per Google SecOps 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"
  }
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dettagli del dispositivo e del processo.
• target: informazioni sul mutex.

NETWORK_CONNECTION, NETWORK_FLOW, NETWORK_FTP, NETWORK_SMTP

Campi obbligatori:

• metadata: event_timestamp
• principal: includi i dettagli sulla macchina che ha avviato la connessione di rete (ad esempio, l'origine).
• target: includi i dettagli della macchina di destinazione se è diversa dalla macchina principale.
• network: acquisisce i dettagli sulla connessione di rete (porte, protocollo ecc.).

Campi facoltativi:

• principal.process e target.process: includono le informazioni sul processo associate al principal e alla destinazione della connessione di rete (se disponibili).
• principal.user e target.user: includono le informazioni sull'utente associate all'entità e alla destinazione della connessione di rete (se disponibili).
• network: acquisisce i dettagli sulla connessione di rete, inclusi porte e protocollo.

Nota: per tutti gli eventi di rete, se l'entità o la destinazione ha una porta specificata, i campi ip e mac devono includere un solo valore ciascuno (se disponibile), ovvero l'indirizzo IP e il MAC associati alla porta. In caso contrario, se non viene specificata alcuna porta, puoi specificare un numero qualsiasi di indirizzi IP e indirizzi MAC associati al dispositivo al momento dell'evento (non è richiesto un ordine particolare).

NETWORK_DHCP

Campi obbligatori:

• metadata: informazioni di base sull'evento.
• principal: almeno un identificatore della macchina (ad esempio, principal.ip).
• network: deve specificare network.application_protocol come DHCP. Richiede inoltre la compilazione di network.dhcp.opcode (ad esempio, BOOTREQUEST o BOOTREPLY).

Nota: Google SecOps valuta solo BOOTREQUEST o BOOTREPLY per l'aliasing degli asset.

Esempio di UDM per NETWORK_DHCP

L'esempio seguente illustra come un evento di tipo NETWORK_DHCP verrebbe formattato per l'UDM di Google SecOps:

{
    "metadata": {
        "event_timestamp": "2023-07-04T18:52:22.142364Z",
        "event_type": "NETWORK_DHCP"
    },
    "principal": {
        "ip": [
            "1.2.3.4"
        ]
    },
    "network": {
        "application_protocol": "DHCP",
        "dhcp": {
            "opcode": "BOOTREPLY"
        }
    }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: informazioni sul dispositivo che richiede o riceve il lease DHCP.
• network: dettagli sulla connessione di rete DHCP e sul codice operativo.

NETWORK_DNS

Campi obbligatori:

• principal: almeno un identificatore della macchina (ad esempio, principal.ip).
• network: deve specificare network.application_protocol come DNS. Richiede anche network.dns.questions.name.
• metadata: informazioni di base sull'evento.

Esempio di UDM per NETWORK_DNS

L'esempio seguente illustra come viene formattato un evento di tipo NETWORK_DNS per l'UDM di Google SecOps:

{
    "metadata": {
        "event_timestamp": "2023-07-04T18:54:15.943301Z",
        "event_type": "NETWORK_DNS"
    },
    "principal": {
        "ip": [
            "1.2.3.4"
        ]
    },
    "network": {
        "application_protocol": "DNS",
        "dns": {
            "questions": {
                "name": "www.acme.com"
            }
        }
    }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: informazioni sul dispositivo che effettua la richiesta DNS.
• network: dettagli sulla connessione di rete DNS e sul nome di dominio interrogato.

NETWORK_HTTP

Il tipo di evento NETWORK_HTTP rappresenta una connessione di rete HTTP da un'entità a un server web di destinazione.

Campi obbligatori:

• metadata: includi i campi obbligatori.
• target: rappresenta il server web. Includi le informazioni sul dispositivo e un numero di porta facoltativo.
  • Se è disponibile un numero di porta di destinazione, specifica un solo indirizzo IP oltre al numero di porta associato alla connessione di rete (anche se è possibile fornire più identificatori di macchina per la destinazione).
  • Per target.url, inserisci l'URL a cui è stato eseguito l'accesso.

Campi facoltativi:

• principal: rappresenta il client che avvia la richiesta web. Includi almeno un identificatore della macchina (ad esempio nome host, IP, MAC, identificatore dell'asset proprietario) o un identificatore dell'utente (ad esempio nome utente).
  • Se viene descritta una connessione di rete specifica ed è disponibile un numero di porta client, specifica un solo indirizzo IP insieme al numero di porta associato alla connessione di rete (anche se potrebbero essere forniti altri identificatori della macchina per descrivere meglio il dispositivo partecipante).
  • Se non è disponibile alcuna porta di origine, puoi specificare tutti gli indirizzi IP e MAC, gli identificatori degli asset e i valori dei nomi host che descrivono il dispositivo principale.
• network e network.http: includono i dettagli sulla connessione di rete HTTP. Devi compilare i seguenti campi:
  • network.ip_protocol
  • network.application_protocol
  • network.http.method
• about: rappresenta altre entità trovate nella transazione HTTP (ad esempio un file caricato o scaricato).
• intermediary: rappresenta un server proxy (se diverso dal principal o dal target).
• metadata: compila gli altri campi dei metadati.
• network: compila altri campi della rete.
• network.email: se la connessione di rete HTTP ha avuto origine da un URL visualizzato in un messaggio email, compila network.email con i dettagli.
• observer: rappresenta uno sniffer passivo (se presente).
• security_result: aggiungi uno o più elementi al campo security_result per rappresentare l'attività dannosa rilevata.

Esempio di UDM per NETWORK_HTTP

L'esempio seguente illustra come un evento antivirus Sophos di tipo NETWORK_HTTP viene convertito nel formato UDM di Google SecOps.

Di seguito è riportato l'evento antivirus Sophos originale:

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

Ecco come formattare le stesse informazioni in Proto3 utilizzando la sintassi UDM di Google SecOps:

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" }

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dispositivo di sicurezza che ha rilevato l'evento.
• dispositivo di destinazione: dispositivo che ha ricevuto il software dannoso.
• network: informazioni di rete sull'host dannoso.
• security_result: dettagli sulla sicurezza relativi al software dannoso.
• additional: informazioni sul fornitore al di fuori dell'ambito dell'UDM.

PROCESS_INJECTION, PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_TERMINATION, PROCESS_UNCATEGORIZED

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal:
  • Almeno un identificatore della macchina.
  • Per gli eventi di process injection e process termination, se disponibili, principal.process deve includere informazioni sul processo che avvia l'azione (ad esempio, per un evento di process launch, principal.process deve includere i dettagli sul processo principale, se disponibili).
• target:
  • target.process: include informazioni sul processo che viene inserito, aperto, avviato o terminato.
  • Se il processo di destinazione è remoto, la destinazione deve includere almeno un identificatore della macchina di destinazione (ad esempio un indirizzo IP, un MAC, un nome host o un identificatore di asset di terze parti).

Campi facoltativi:

• security_result: descrive l'attività dannosa rilevata.
• principal.user e target.user: compila il processo di avvio (principal) e il processo di destinazione se le informazioni dell'utente sono disponibili.

Esempio di UDM per PROCESS_LAUNCH

L'esempio seguente illustra come formattare un evento PROCESS_LAUNCH utilizzando la sintassi UDM di Google SecOps:

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"
    }
  }
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dettagli del dispositivo.
• target: dettagli del processo.

PROCESS_MODULE_LOAD

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal:
  • Includi almeno un identificatore della macchina (in principal o target).
  • principal.process: compila con le informazioni sul processo che carica il modulo.
• target:
  • target.process: compila con le informazioni sul processo del modulo caricato, incluso almeno uno tra target.process.file (ad esempio la DLL o l'oggetto condiviso) o target.process.product_specific_process_id.

Campi facoltativi:

• security_result: descrive l'attività dannosa rilevata.
• principal.user: compila se sono disponibili informazioni sull'utente relative al processo.

Esempio di UDM per PROCESS_MODULE_LOAD

L'esempio seguente illustra come formattare un evento PROCESS_MODULE_LOAD utilizzando la sintassi UDM di Google SecOps:

{
    "metadata": {
        "event_timestamp": "2023-07-03T20:40:29.854097Z",
        "event_type": "PROCESS_MODULE_LOAD"
    },
    "principal": {
        "hostname": "pinguino-01",
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    },
    "target": {
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    }
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dettagli sul dispositivo e sul processo che carica il modulo.
• target: dettagli del processo e del modulo.

PROCESS_PRIVILEGE_ESCALATION

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal:
  • Includi almeno un identificatore della macchina (in principal o target).
  • principal.process: compila con le informazioni sul processo che avvia l'escalation dei privilegi.
  • principal.user: compila con le informazioni sull'utente che avvia l'escalation dei privilegi, incluso almeno un identificatore dell'utente.
• target: compila con le informazioni sul target dell'escalation dei privilegi (ad esempio, target.process per il processo con privilegi elevati). Il campo target non deve essere vuoto.

Campi facoltativi:

• security_result: descrive l'attività dannosa rilevata.

Esempio di UDM per PROCESS_PRIVILEGE_ESCALATION

L'esempio seguente illustra come viene formattato un evento di tipo PROCESS_PRIVILEGE_ESCALATION per l'UDM di Google SecOps:

{
    "metadata": {
        "event_timestamp": "2023-07-04T19:04:12.573338Z",
        "event_type": "PROCESS_PRIVILEGE_ESCALATION"
    },
    "principal": {
        "user": {
            "userid": "pinguino"
        },
        "hostname": "pinguino-01",
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    },
    "target": {
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    }
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dettagli sul dispositivo, sull'utente e sul processo che avvia l'escalation.
• target: dettagli sul processo per cui viene eseguita l'escalation.

REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION, REGISTRY_UNCATEGORIZED

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal:
  • Almeno un identificatore della macchina.
  • Se un processo in modalità utente esegue la modifica del registry, principal.process deve includere informazioni sul processo che modifica il registry.
  • Se la modifica del registry viene eseguita da un processo del kernel, l'entità non deve includere informazioni sul processo.
• target:
  • target.registry: se il registro di destinazione è remoto, la destinazione deve includere almeno un identificatore per la macchina di destinazione (ad esempio un indirizzo IP, un MAC, un nome host o un identificatore di asset di terze parti).
  • target.registry.registry_key: tutti gli eventi del registry devono includere la chiave del registry interessata.

Campi facoltativi:

• security_result: descrive l'attività dannosa rilevata. Ad esempio, una chiave del Registro di sistema errata.
• principal.user: compila se sono disponibili informazioni sull'utente relative al processo.

Esempio di UDM per REGISTRY_MODIFICATION

L'esempio seguente illustra come formattare un evento REGISTRY_MODIFICATION in Proto3 utilizzando la sintassi UDM di Google SecOps:

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."
  }
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dettagli del dispositivo, dell'utente e del processo.
• target: voce del registry interessata dalla modifica.

RISORSA

Tipi di eventi:

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Evento UDM minimo:

{
   "metadata": {
       "event_timestamp": "2023-07-04T20:19:53.394745Z",
       "event_type": "RESOURCE_CREATION"
   },
   "principal": {
       "user": {
           "userid": "pinguino"
       }
   },
   "target": {
       "resource": {
           "name": "foo.bar"
       }
   }
}

SCAN_FILE, SCAN_HOST, SCAN_PROCESS, SCAN_VULN_HOST, SCAN_VULN_NETWORK

Per SCAN_FILE:

{
  "metadata": {
    "event_timestamp": "2023-07-06T06:57:08.443142Z",
    "event_type": "SCAN_FILE"
  },
  "principal": {
    "hostname": "pinguino-01"
  },
  "target": {
    "file": {
      "full_path": "foo.bar"
    }
  }
}

Per SCAN_PROCESS:

{
  "metadata": {
    "event_timestamp": "2023-07-06T06:59:17.690425Z",
    "event_type": "SCAN_PROCESS"
  },
  "principal": {
    "hostname": "pinguino-01"
  },
  "target": {
    "process": {
      "file": {
        "full_path": "foo.bar"
      }
    }
  }
}

Campi obbligatori:

• metadata: event_timestamp e informazioni di base sull'evento.
• observer: acquisisce informazioni sullo scanner stesso. Se lo scanner è remoto, i dettagli della macchina devono essere acquisiti dal campo dell'osservatore. Per uno scanner locale, lascia vuoto.
• target: acquisisce informazioni sulla macchina che contiene l'oggetto scansionato. Se un file viene scansionato, target.file deve acquisire informazioni sul file scansionato. Se è in corso la scansione di un processo, target.process deve acquisire informazioni sul processo scansionato.
• extensions: per SCAN_VULN_HOST e SCAN_VULN_NETWORK, definisci la vulnerabilità utilizzando il campo extensions.vuln.

Campi facoltativi:

• principal: rappresenta il dispositivo che avvia la connessione e include almeno un identificatore della macchina (ad esempio nome host, indirizzo IP, indirizzo MAC, identificatore proprietario dell'asset) o un identificatore dell'utente.
• target: i dettagli dell'utente relativi all'oggetto target (ad esempio, il creatore del file o il proprietario del processo) devono essere acquisiti in target.user.
• security_result: descrive l'attività dannosa rilevata.

Esempio di UDM per SCAN_HOST

L'esempio seguente illustra come viene formattato un evento di tipo SCAN_HOST per Google SecOps UDM:

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
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• target: il dispositivo che ha ricevuto il software dannoso.
• observer: il dispositivo che osserva e segnala l'evento in questione.
• security_result: dettagli sulla sicurezza relativi al software dannoso.

Esempio di UDM per SCAN_VULN_HOST

L'esempio seguente illustra come un evento di tipo SCAN_VULN_HOST verrebbe formattato per l'UDM di Google SecOps:

metadata: {
  event_timestamp: "2025-05-09T12:59:52.45298Z",
  event_type: 18005,
  product_name: "TestProduct",
  vendor_name: "TestVendor"
  },
principal {
  asset_id: "TEST:Mwl8ABcd",
  ip: "127.0.0.3",
  hostname: "TEST-Localhost",
  mac: ["02:00:00:00:00:01"]
  },
extensions: {
  vulns: {
    vulnerabilities: [
      {
      cve_id: "CVE-6l9VxQmz",
      vendor_vulnerability_id: "TEST:7gmCmFWX",
      name: "CVE pA7DzwPU",
      severity: 2,
      vendor: "TestVendor",
      last_found: "2025-05-09T14:59:52.45300Z",
      first_found: "2025-05-09T13:59:52.45300Z"
       }
      ]
    }
  }

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: il dispositivo che ha ricevuto il software dannoso.
• extensions: dettagli della vulnerabilità.

SCHEDULED_TASK_CREATION, SCHEDULED_TASK_DELETION, SCHEDULED_TASK_DISABLE, SCHEDULED_TASK_ENABLE, SCHEDULED_TASK_MODIFICATION, SCHEDULED_TASK_UNCATEGORIZED

Campi obbligatori:

• principal: per tutti gli eventi SCHEDULED_TASK, l'entità deve includere un identificatore della macchina e un identificatore dell'utente.
• target: includi un target.resource valido con target.resource.resource_type impostato su TASK.

Campi facoltativi:

• security_result: descrive l'attività dannosa rilevata.

Esempio di UDM per SCHEDULED_TASK_CREATION

L'esempio seguente illustra come un evento di tipo SCHEDULED_TASK_CREATION potrebbe essere formattato per Google SecOps UDM:

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: {
    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
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: il dispositivo che ha pianificato l'attività sospetta.
• target: il software preso di mira dall'attività sospetta.
• intermediary: intermediario coinvolto nell'attività sospetta.
• security_result: dettagli sulla sicurezza relativi all'attività sospetta.

SETTING_UNCATEGORIZED, SETTING_CREATION, SETTING_MODIFICATION, SETTING_DELETION

Campi obbligatori:

• principal: deve essere presente, non vuoto e includere un identificatore della macchina.

  Nota: l'impostazione resource.type è deprecata. Utilizza resource.resource_type.

• target: deve essere presente, non vuoto e includere una risorsa con target.resource.resource_type specificato come SETTING.

Esempio di UDM per il tipo di evento SETTING_MODIFICATION

L'esempio seguente illustra come viene formattato un evento di tipo SETTING_MODIFICATION per Google SecOps UDM:

{
    "metadata": {
        "event_timestamp": "2023-07-05T14:15:27.070909Z",
        "event_type": "SETTING_MODIFICATION"
    },
    "principal": {
        "hostname": "foo.bar"
    },
    "target": {
        "resource": {
            "resource_type": "SETTING",
            "name": "foo.bar"
        }
    }
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: informazioni sul dispositivo su cui è stata eseguita la modifica dell'impostazione.
• target: dettagli sulla risorsa di impostazione.

SERVICE_UNSPECIFIED, SERVICE_CREATION, SERVICE_DELETION, SERVICE_MODIFICATION, SERVICE_START, SERVICE_STOP

Campi obbligatori:

• metadata: includi i campi obbligatori (event_timestamp e event_type).
• principal: includi almeno un identificatore della macchina (principal.hostname, principal.ip, principal.mac o principal.asset_id).
• target: specifica almeno uno tra target.process e target.application.

Campi facoltativi:

• target.user: compila se sono disponibili informazioni sull'utente per il account di servizio o l'utente di destinazione.
• target.resource: compila con i dettagli della risorsa del servizio (ad esempio resource_type: SERVICE).

Esempio di UDM per SERVICE_UNSPECIFIED

L'esempio seguente illustra come viene formattato un evento di tipo SERVICE_UNSPECIFIED per Google SecOps UDM:

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: {
      resource_type: SERVICE
      name: "RPC"
   }
 }

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dettagli del dispositivo e della posizione.
• target: nome host e identificatore dell'utente.
• application: nome dell'applicazione e tipo di risorsa.

STATUS_HEARTBEAT, STATUS_STARTUP, STATUS_SHUTDOWN, STATUS_UNCATEGORIZED, STATUS_UPDATE

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal: almeno un identificatore della macchina (indirizzo IP o indirizzo MAC, nome host o identificatore dell'asset).

Esempio di UDM per STATUS_HEARTBEAT

L'esempio seguente illustra come un evento di tipo STATUS_HEARTBEAT verrebbe formattato per l'UDM di Google SecOps:

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"
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dettagli del dispositivo e della posizione.
• intermediario: indirizzo IP del dispositivo.
• security_result: dettagli del risultato della sicurezza.

SYSTEM_AUDIT_LOG_UNCATEGORIZED, SYSTEM_AUDIT_LOG_WIPE

Campi obbligatori:

• principal: includi un identificatore dell'utente che ha eseguito l'operazione sul log e un identificatore della macchina in cui è o era archiviato il log (in caso di cancellazione).

Esempio di UDM per SYSTEM_AUDIT_LOG_WIPE

L'esempio seguente illustra come viene formattato un evento di tipo SYSTEM_AUDIT_LOG_WIPE per l'UDM di Google SecOps:

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"
  }
}

Come mostrato in questo esempio, l'evento è stato suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• principal: dettagli del dispositivo e dell'utente.

USER_BADGE_IN

Campi obbligatori:

• metadata: includi i campi obbligatori.
• target: deve includere almeno un identificatore della macchina (ad esempio, target.hostname).
• extensions: il meccanismo di autenticazione deve essere fornito in extensions.auth.type.

Esempio di UDM per USER_BADGE_IN

L'esempio seguente illustra come viene formattato un evento di tipo USER_BADGE_IN per Google SecOps UDM:

{
    "metadata": {
        "event_timestamp": "2023-07-05T20:31:18.303584Z",
        "event_type": "USER_BADGE_IN"
    },
    "target": {
        "hostname": "jamon-01"
    },
    "extensions": {
        "auth": {
            "type": "MACHINE"
        }
    }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• target: informazioni sul dispositivo o sulla posizione in cui è avvenuto l'accesso con badge.
• extensions: dettagli relativi al meccanismo di autenticazione utilizzato.

USER_CHANGE_PASSWORD, USER_CHANGE_PERMISSIONS

Campi obbligatori:

• metadata: includi i campi obbligatori.
• target: non deve essere vuoto. Compila target con le informazioni sull'account utente modificato (target.user) o sulla macchina, sull'applicazione o sulla risorsa di destinazione in cui è stata apportata la modifica.
• target.user o principal.user: compila almeno uno dei campi target.user (l'account utente che è stato modificato) o principal.user (l'utente che ha avviato la modifica) con un identificatore dell'utente (userid, windows_sid, email_addresses o employee_id).

Campi facoltativi:

• principal: se fornisci l'identificatore dell'utente in target.user, principal.user è facoltativo. Se l'account utente viene modificato da una posizione remota, compila principal con le informazioni sulla macchina da cui ha avuto origine la modifica.
• intermediary: per gli accessi SSO, intermediary deve includere almeno un identificatore della macchina per il server SSO, se disponibile.

USER_COMMUNICATION

Campi obbligatori:

• principal: compila il campo principal.user con i dettagli associati alla comunicazione avviata dall'utente (mittente), ad esempio un messaggio chat in Google Chat o Slack, una videoconferenza o una conferenza vocale in Zoom o Google Meet o una connessione VoIP.

Campi facoltativi:

• target: (consigliato) compila il campo target.user con informazioni sull'utente di destinazione (destinatario) della risorsa di comunicazione cloud. Compila il campo target.application con le informazioni sull'applicazione di comunicazione cloud di destinazione.

USER_CREATION, USER_DELETION

Campi obbligatori:

• metadata: includi event_timestamp e event_type.
• principal: includi almeno un identificatore utente valido in principal.user (userid, windows_sid, email_addresses o employee_id, fino a 256 caratteri) per l'account che ha avviato la creazione o l'eliminazione. Se target.application non è impostato, principal deve includere anche almeno un identificatore della macchina (hostname, ip, mac o asset_id).
• target: includi almeno un identificatore dell'utente valido in target.user (fino a 256 caratteri) per l'account utente che viene creato o eliminato. Se principal non include un identificatore della macchina, compila target.application.

Campi facoltativi:

• principal.process: dettagli del processo per la macchina in cui è stata avviata la richiesta di creazione o eliminazione dell'utente.
• target: informazioni sulla macchina di destinazione (se diversa dalla macchina principale).

USER_LOGIN, USER_LOGOUT

Campi obbligatori:

• metadata: includi i campi obbligatori.
• principal: per l'attività utente remota (ad esempio, l'accesso remoto), compila principal con le informazioni sulla macchina che ha generato l'attività utente. Per l'attività utente locale (ad esempio, l'accesso locale), non impostare principal.
• target: compila target.user con le informazioni sull'utente che ha eseguito l'accesso o la disconnessione. Se principal non è impostato (ad esempio, accesso locale), target deve includere anche almeno un identificatore della macchina che identifica la macchina di destinazione. Per l'attività utente da macchina a macchina (ad esempio, accesso remoto, SSO, servizio cloud, VPN), la destinazione deve includere informazioni sull'applicazione di destinazione, sulla macchina di destinazione o sul server VPN di destinazione.
• intermediary: per gli accessi SSO, l'intermediario deve includere almeno un identificatore della macchina per il server SSO, se disponibile.
• network e network.http: se l'accesso avviene tramite HTTP, devi inserire tutti i dettagli disponibili in network.ip_protocol, network.application_protocol e network.http.
• Estensione authentication: deve identificare il tipo di sistema di autenticazione a cui è correlato l'evento (ad esempio, macchina, SSO o VPN) e il meccanismo utilizzato (nome utente e password, OTP e così via).
• security_result: aggiungi un campo security_result per rappresentare lo stato di accesso se non va a buon fine. Specifica security_result.category con il valore AUTH_VIOLATION se l'autenticazione non va a buon fine.

Esempio di UDM per USER_LOGIN

L'esempio seguente illustra come un evento di tipo USER_LOGIN verrebbe formattato per l'UDM di Google SecOps:

{
    "metadata": {
        "event_timestamp": "2023-07-05T20:48:50.657334Z",
        "event_type": "USER_LOGIN"
    },
    "target": {
        "user": {
            "userid": "jamon"
        }
    },
    "extensions": {
        "auth": {
            "type": "MACHINE"
        }
    }
}

Come mostrato in questo esempio, l'evento è suddiviso nelle seguenti categorie UDM:

• metadata: informazioni di base sull'evento.
• target: informazioni sull'utente connesso.
• extensions: dettagli relativi al meccanismo di autenticazione utilizzato.

USER_RESOURCE_ACCESS

Campi obbligatori:

• principal: compila il campo principal.user con i dettagli sui tentativi di accesso a una risorsa cloud (ad esempio un caso Salesforce, un calendario Office365, un documento Google o un ticket ServiceNow).
• target: compila il campo target.resource con le informazioni sulla risorsa cloud di destinazione.

Campi facoltativi:

• target.application: (consigliato) compila il campo target.application con informazioni sull'applicazione cloud di destinazione.

USER_RESOURCE_CREATION, USER_RESOURCE_DELETION

Campi obbligatori:

• principal: compila il campo principal.user con i dettagli associati all'utente creato all'interno di una risorsa cloud (ad esempio una richiesta di assistenza Salesforce, un calendario di Office 365, un documento Google o un ticket ServiceNow).
• target: compila il campo target.resource con le informazioni sulla risorsa cloud di destinazione.

Campi facoltativi:

• target.application: (consigliato) compila il campo target.application con informazioni sull'applicazione cloud di destinazione.

USER_RESOURCE_UPDATE_CONTENT

Campi obbligatori:

• principal: compila il campo principal.user con i dettagli associati all'utente i cui contenuti sono stati aggiornati all'interno di una risorsa cloud (ad esempio un caso Salesforce, un calendario Office365, un documento Google o un ticket ServiceNow).
• target: compila il campo target.resource con le informazioni sulla risorsa cloud di destinazione.

Campi facoltativi:

• target.application: (consigliato) compila il campo target.application con informazioni sull'applicazione cloud di destinazione.

USER_RESOURCE_UPDATE_PERMISSIONS

Campi obbligatori:

• principal: compila il campo principal.user con i dettagli associati all'utente le cui autorizzazioni sono state aggiornate all'interno di una risorsa cloud (ad esempio, una richiesta di assistenza Salesforce, un calendario di Office 365, un documento Google o un ticket ServiceNow).
• target: compila il campo target.resource con le informazioni sulla risorsa cloud di destinazione.

Campi facoltativi:

• target.application: (consigliato) compila il campo target.application con informazioni sull'applicazione cloud di destinazione.

USER_UNCATEGORIZED

Campi obbligatori:

• metadata: includi event_timestamp e event_type.
• principal o target:
  • Se target non è compilato, principal deve includere almeno un identificatore dell'utente valido in principal.user (userid, windows_sid, email_addresses o employee_id, fino a 256 caratteri) o almeno un identificatore macchina (hostname, ip, mac o asset_id).
  • Se target è compilato, devi compilare almeno uno dei seguenti campi: un identificatore dell'utente in target.user, un identificatore della macchina in target o un identificatore dell'utente valido in principal.user.

Campi facoltativi:

• principal.process: dettagli del processo associati all'attività utente.
• security_result: descrive qualsiasi attività dannosa o anomala rilevata.

Nota: USER_STATS è deprecato.