Panoramica di UDM

Supportata in:

Google SecOps SIEM

Questo documento fornisce una panoramica di Unified Data Model (UDM). Per maggiori dettagli sui campi UDM, inclusa una descrizione di ciascuno, consulta l'elenco dei campi UDM. Per ulteriori informazioni sulla mappatura del parser, consulta Campi UDM importanti per la mappatura del parser.

UDM è una struttura di dati standard di Google Security Operations che archivia le informazioni sui dati ricevuti dalle origini. Viene anche chiamato schema. Google SecOps archivia i dati originali che riceve in due formati: come log non elaborato originale e come record UDM strutturato. Il record UDM è una rappresentazione strutturata del log originale.

Se esiste un parser per il tipo di log specificato, il log non elaborato viene utilizzato per creare un record UDM. I clienti possono anche trasformare i log non elaborati nel formato UDM strutturato prima di inviare i dati a Google SecOps utilizzando l'API Ingestion.

Alcuni dei vantaggi dell'utilizzo di UDM includono:

• Archivia lo stesso tipo di record di fornitori diversi utilizzando la stessa semantica.
• È più facile identificare le relazioni tra utenti, host e indirizzi IP perché i dati vengono normalizzati nello schema UDM standard.
• È più facile scrivere regole, poiché possono essere indipendenti dalla piattaforma.
• È più facile supportare i tipi di log dei nuovi dispositivi.

Nota: il motore delle regole di Google SecOps utilizza gli stessi nomi dei campi UDM. Puoi utilizzare questi stessi nomi di campo durante la creazione delle regole.

Sebbene sia possibile cercare eventi con una ricerca nei log non elaborati, una ricerca UDM funziona più velocemente e con maggiore precisione grazie alla sua specificità. Google SecOps raccoglie i dati dei log non elaborati e archivia i dettagli del log eventi nello schema UDM. UDM fornisce un framework completo di migliaia di campi per descrivere e classificare diversi tipi di eventi, ad esempio eventi di processo degli endpoint ed eventi di comunicazione di rete.

Struttura UDM

Gli eventi UDM sono costituiti da più sezioni. La prima sezione presente in ogni evento UDM è quella dei metadati. Fornisce una descrizione di base dell'evento, incluso il timestamp di quando si è verificato e il timestamp di quando è stato importato in Google SecOps. Include anche le informazioni sul prodotto, la versione e la descrizione. Il parser di importazione classifica ogni evento in base a un tipo di evento predefinito, indipendentemente dal log del prodotto specifico. Solo con i campi dei metadati, puoi iniziare rapidamente a cercare i dati.

Oltre alla sezione dei metadati, altre sezioni descrivono aspetti aggiuntivi dell'evento. Se una sezione non è necessaria, non viene inclusa, risparmiando memoria.

• principal: l'entità che genera l'attività nell'evento. Sono incluse anche le sezioni che fanno riferimento all'origine (src) e alla destinazione (target).
• intermediary: sistemi attraverso i quali passano gli eventi, come un server proxy o un inoltro SMTP.
• observer: sistemi come gli sniffer di pacchetti che monitorano passivamente il traffico.

Formatta un evento UDM

Per formattare un evento UDM in modo che sia pronto per l'invio a Google, devi completare i seguenti passaggi:

1. Specifica il tipo di evento: il tipo di evento selezionato determina i campi che devi includere nell'evento.
2. Specifica il timestamp dell'evento.
3. Specifica i sostantivi (entità): ogni evento deve includere almeno un sostantivo che descriva un dispositivo o un utente partecipante coinvolto nell'evento.
4. (Facoltativo) Specifica il risultato di sicurezza: specifica i risultati di sicurezza includendo dettagli sui rischi e sulle minacce rilevati da un sistema di sicurezza. Includi le azioni specifiche intraprese per mitigare questi rischi e minacce.
5. Compila il resto delle informazioni obbligatorie e facoltative sull'evento utilizzando i campi evento UDM.

Specifica il tipo di evento

Devi sempre specificare il tipo di evento per ogni evento inviato in formato UDM. Specifica questo valore utilizzando uno dei possibili valori disponibili per metadata.event_type. Questi includono valori come PROCESS_OPEN, FILE_CREATION, USER_CREATION e NETWORK_DNS (per l'elenco completo, consulta Metadata.event_type). Ogni tipo di evento richiede anche la compilazione di un insieme di altri campi e valori con le informazioni associate all'evento originale. Per informazioni dettagliate sui campi da includere per ogni tipo di evento, consulta Campi obbligatori e facoltativi per ogni tipo di evento.

L'esempio seguente illustra come specificare PROCESS_OPEN come tipo di evento utilizzando la notazione di testo Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Specifica il timestamp dell'evento

Devi specificare il timestamp GMT per qualsiasi evento inviato in formato UDM utilizzando Metadata.event_timestamp. Il timestamp deve essere codificato utilizzando uno dei seguenti standard:

• Per JSON, utilizza RFC 3339
• Timestamp Proto3

L'esempio seguente illustra come specificare il timestamp utilizzando il formato RFC 3339. Per questo esempio, aaaa-mm-ggThh:mm:ss+hh:mm: anno, mese, giorno, ora, minuto, secondo e scostamento dall'ora UTC. L'offset rispetto all'UTC è di meno 8 ore, che indica il fuso orario PST.

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

Specifica i sostantivi (entità)

Definisci uno o più sostantivi per ogni evento UDM. I sostantivi rappresentano i partecipanti o le entità, come l'utente che esegue l'attività, il target dell'azione o il dispositivo di sicurezza che osserva l'evento (ad esempio, un proxy email o un router). I sostantivi rappresentano anche oggetti come URL o allegati.

Attenzione: per gli eventi UDM, i campi del nome host hanno un limite di 256 caratteri (ad esempio principal.hostname o target.hostname). La mappatura dei log non elaborati (da una fonte come ArcSight) che superano questo limite comporta errori di convalida e l'eliminazione dei log. Questo non è specifico per i singoli parser.

Un evento UDM deve avere uno o più dei seguenti sostantivi specificati:

principal: rappresenta l'entità o il dispositivo che origina l'attività descritta nell'evento. L'entità deve includere almeno un dettaglio della macchina (nome host, MAC, IP, porta, identificatori specifici del prodotto come un GUID della macchina CrowdStrike) o un dettaglio dell'utente (ad esempio, il nome utente) e, facoltativamente, i dettagli del processo. NON deve includere nessuno dei seguenti campi: email, file, chiavi del registry o valori.

Se tutte le attività si verificano su un'unica macchina, descrivi solo quella macchina nel blocco principal. Non duplicare i dettagli della macchina in target o src.

Nota: non descrivere i dispositivi di sicurezza nel campo principal, anche se sono loro a generare l'evento. Utilizza invece i campi observer o intermediary. Se il software di sicurezza viene eseguito sullo stesso dispositivo che ha generato l'attività (ad esempio un agente EDR su un endpoint Windows), il dispositivo è comunque il principal.

L'esempio seguente illustra come potrebbero essere compilati i campi principal:

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

Questo esempio fornisce dettagli sul dispositivo e sull'utente che è stato l'attore principale dell'evento. Include anche un identificatore di asset specifico del fornitore (da Sophos), che è un ID univoco generato dal prodotto di sicurezza di terze parti.

target: rappresenta il dispositivo o l'oggetto a cui fa riferimento l'evento. In una connessione firewall dal dispositivo A al dispositivo B, A è l'entità e B è la destinazione. Per un'iniezione in un processo in cui il processo C inserisce codice nel processo D, C è l'entità e D è il target.

Principal e target in UDM

L'esempio seguente illustra come vengono compilati i campi di un target:

target {
   ip: "198.51.100.31"
   port: 80
}

Includi qualsiasi altra informazione disponibile nel blocco target, ad esempio il nome host, indirizzi IP o indirizzi MAC aggiuntivi e identificatori di asset proprietari.

Sia principal che target (e altri sostantivi) possono fare riferimento ad attori sulla stessa macchina. Ad esempio, se il processo A (principal) in esecuzione sulla macchina X agisce sul processo B (target) anch'esso sulla macchina X, descrivi entrambi nei rispettivi blocchi.

• src: rappresenta l'oggetto di origine su cui viene eseguita l'azione e il suo contesto, ad esempio la macchina in cui si trova. Ad esempio, se l'utente U copia il file A sulla macchina X nel file B sulla macchina Y, specifica sia il file A sia la macchina X nel blocco src.

• intermediary: contiene i dettagli di uno o più dispositivi che hanno elaborato l'attività descritta nell'evento. Sono incluse le informazioni per dispositivi come server proxy e inoltri SMTP.

• observer: rappresenta un dispositivo che non è un intermediario diretto, ma monitora e segnala l'attività. Sono inclusi dispositivi come packet sniffer o scanner di vulnerabilità basati sulla rete.

• about: memorizza i dettagli di tutti gli oggetti a cui fa riferimento l'evento che non rientrano in participant, src, target, intermediary o observer. Utilizzalo per monitorare elementi come:

  • Allegati email
  • Domini/URL/IP incorporati nel corpo dell'email
  • DLL caricate durante un evento PROCESS_LAUNCH

Le sezioni delle entità degli eventi UDM includono informazioni sui vari partecipanti (dispositivi, utenti, oggetti come URL, file e così via) descritti nell'evento. L'UDM di Google Security Operations prevede requisiti obbligatori per la compilazione dei campi dei sostantivi. Questi requisiti sono descritti in Campi obbligatori e facoltativi per ogni tipo di evento UDM. L'insieme di campi dell'entità da compilare varia in base al tipo di evento.

Specifica il risultato di sicurezza

Se vuoi, puoi specificare i risultati di sicurezza compilando i campi SecurityResult, inclusi i dettagli sui rischi e sulle minacce alla sicurezza rilevati dal sistema di sicurezza, nonché le azioni intraprese per mitigare questi rischi e minacce. Di seguito sono riportati alcuni esempi di tipi di eventi di sicurezza che richiedono la compilazione dei campi SecurityResult:

• Un firewall proxy di sicurezza delle email ha rilevato due allegati infetti (SOFTWARE_MALICIOUS). Ha messo in quarantena e disinfettato i file (QUARANTINE, ALLOW_WITH_MODIFICATION), quindi ha inoltrato l'email disinfettata.

• Un sistema SSO ha facilitato un tentativo di accesso che ha generato un AUTH_VIOLATION ed è stato bloccato (BLOCK).

• Una sandbox per malware ha rilevato uno spyware (SOFTWARE_MALICIOUS) in un file allegato cinque minuti dopo che il sistema ha recapitato (ALLOW) l'email nella Posta in arrivo dell'utente.

Esempi di ricerche UDM

Questa sezione fornisce esempi di ricerche UDM che mostrano alcune delle sintassi, delle funzionalità e delle capacità di base della ricerca UDM.

Esempio: cerca gli accessi riusciti a Microsoft Windows 4624

La seguente ricerca elenca gli eventi di accesso riusciti di Microsoft Windows 4624, insieme alla data e ora di generazione degli eventi, in base a soli due campi UDM:

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

Esempio: cerca tutti gli accessi riusciti

La seguente ricerca elenca tutti gli eventi di accesso riusciti, indipendentemente dal fornitore o dall'applicazione:

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

Esempio: cerca gli accessi utente riusciti

L'esempio seguente illustra come cercare userid "fkolzig" e determinare quando l'utente con questo ID utente ha eseguito l'accesso. Puoi completare questa ricerca utilizzando la sezione Target. La sezione Target include sottosezioni e campi che descrivono il target. Ad esempio, il target in questo caso è un utente e ha una serie di attributi associati, ma potrebbe anche essere un file, un'impostazione del registro o un asset. Questo esempio cerca "fkolzig" utilizzando il campo target.user.userid.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

Esempio: cerca i dati della tua rete

L'esempio seguente cerca nei dati di rete gli eventi RDP con un target.port di 3389 e un principal.ip di 35.235.240.5. Include anche un campo UDM della sezione di rete, la direzione dei dati (network.direction).

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

Esempio: cerca un processo specifico

Per esaminare i processi creati sui tuoi server, cerca le istanze del comando net.exe e cerca questo file specifico nel percorso previsto. Il campo che stai cercando è target.process.file.full_path. Per questa ricerca, includi il comando specifico eseguito nel campo target.process.command_line. Puoi anche aggiungere un campo nella sezione Informazioni, che è la descrizione del codice evento 1 di Microsoft Sysmon (ProcessCreate).

Ecco la ricerca UDM:

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

Facoltativamente, puoi aggiungere i seguenti campi di ricerca UDM:

• principal.user.userid: identifica l'utente che esegue il comando.
• principal.process.file.md5: identifica l'hash MD5.
• principal.process.command_line: riga di comando.

Esempio: cerca gli accessi utente riusciti associati a un reparto specifico

L'esempio seguente cerca gli accessi degli utenti (metadata.event_type è USER_LOGIN) associati al reparto marketing (target.user.department è marketing) della tua azienda. Sebbene target.user.department non sia direttamente collegato agli eventi di accesso degli utenti, è comunque presente nei dati LDAP acquisiti relativi ai tuoi utenti.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

Oggetti logici: Evento ed Entità

Lo schema UDM descrive tutti gli attributi disponibili che archiviano i dati. Ogni record UDM identifica se descrive un evento o un'entità. I dati vengono archiviati in campi diversi a seconda che il record descriva un evento o un'entità e anche del valore impostato nel campo metadata.event_type o metadata.entity_type.

• Evento UDM: memorizza i dati di un'azione che si è verificata nell'ambiente. Il log eventi originale descrive l'azione così come è stata registrata dal dispositivo, ad esempio firewall e proxy web.
• Entità UDM: rappresentazione contestuale di elementi come asset, utenti e risorse nel tuo ambiente. Viene ottenuta da un'origine dati fonte di verità.

Di seguito sono riportate due rappresentazioni visive di alto livello del modello dei dati sugli eventi e del modello dei dati delle entità.

Nota: il termine Sostantivo descrive il tipo di attributo. I termini principal, target, src, intermediary, observer e about sono i nomi dei campi in cui vengono archiviati i dati.

Figura: modello dei dati sugli eventi

Nota: il termine Sostantivo descrive il tipo di attributo. I termini asset, utente e risorsa sono i nomi dei campi in cui vengono archiviati i dati.

Figura: modello dei dati delle entità

Struttura di un evento UDM

L'evento UDM contiene più sezioni, ognuna delle quali memorizza un sottoinsieme dei dati per un singolo record. Le sezioni sono:

• metadati
• entità
• destinazione
• src
• observer
• intermediario
• about
• rete
• security_result

• estensioni

  

  Figura: modello dei dati sugli eventi

La sezione metadata memorizza il timestamp, definisce event_type e descrive il dispositivo.

Le sezioni principal, target, src, observer e intermediary memorizzano informazioni sugli oggetti coinvolti nell'evento. Un oggetto potrebbe essere un dispositivo, un utente o un processo. La maggior parte delle volte viene utilizzato solo un sottoinsieme di queste sezioni. I campi che memorizzano i dati sono determinati dal tipo di evento e dal ruolo che ogni oggetto svolge nell'evento.

La sezione network memorizza le informazioni relative all'attività di rete, ad esempio le comunicazioni relative alle email e alla rete.

• Dati delle email: informazioni nei campi to, from, cc, bcc e altri campi delle email.
• Dati HTTP: ad esempio method, referral_url e useragent.

La sezione security_result memorizza un'azione o una classificazione registrata da un prodotto di sicurezza, ad esempio un prodotto antivirus.

Le sezioni about ed extensions memorizzano informazioni aggiuntive sugli eventi specifiche del fornitore non acquisite dalle altre sezioni. La sezione extensions è un insieme di coppie chiave-valore in formato libero.

Ogni evento UDM memorizza i valori di un evento di log non elaborato originale. A seconda del tipo di evento, alcuni attributi sono obbligatori, mentre altri sono facoltativi. Gli attributi obbligatori e facoltativi sono determinati dal valore metadata.event_type. Google SecOps legge metadata.event_type ed esegue la convalida dei campi specifica per quel tipo di evento dopo la ricezione dei log.

Se in una sezione del record UDM non sono archiviati dati, ad esempio la sezione delle estensioni, questa sezione non viene visualizzata nel record UDM.

I campi dei metadati

Questa sezione descrive i campi obbligatori in un evento UDM.

Il campo event_timestamp

Gli eventi UDM devono includere i dati per metadata.event_timestamp, ovvero il timestamp GMT di quando si è verificato l'evento. Il valore deve essere codificato utilizzando uno dei seguenti standard: RFC 3339 o timestamp Proto3.

I seguenti esempi illustrano come specificare il timestamp utilizzando il formato RFC 3339, yyyy-mm-ddThh:mm:ss+hh:mm (anno, mese, giorno, ora, minuto, secondo e l'offset dall'ora UTC). L'offset rispetto all'UTC è di meno 8 ore, che indica il fuso orario PST.

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

Puoi anche specificare il valore utilizzando il formato epoch.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

Il campo event_type

Il campo più importante nell'evento UDM è metadata.event_type. Questo valore identifica il tipo di azione eseguita ed è indipendente dal fornitore, dal prodotto o dalla piattaforma. I valori di esempio includono PROCESS_OPEN, FILE_CREATION, USER_CREATION e NETWORK_DNS. Per l'elenco completo, consulta il documento Elenco dei campi UDM.

Il valore metadata.event_type determina quali campi aggiuntivi obbligatori e facoltativi devono essere inclusi nel record UDM. Per informazioni su quali campi includere per ogni tipo di evento, consulta la guida all'utilizzo di UDM.

Gli attributi principal, target, src, intermediary, observer e about

Gli attributi principal, target, src, intermediary e observer descrivono gli asset coinvolti nell'evento. Ognuno memorizza informazioni sugli oggetti coinvolti nell'attività, come registrato dal log non elaborato originale. Potrebbe trattarsi del dispositivo o dell'utente che ha eseguito l'attività, oppure del dispositivo o dell'utente che è il target dell'attività. Potrebbe anche descrivere un dispositivo di sicurezza che ha osservato l'attività, ad esempio un proxy email o un router di rete.

Gli attributi di uso comune sono:

• principal: l'oggetto che ha eseguito l'attività.
• src: l'oggetto che avvia l'attività, se diverso dall'entità.
• target: l'oggetto su cui viene eseguita l'azione.

Ogni tipo di evento richiede che almeno uno di questi campi contenga dati.

I campi ausiliari sono:

• intermediary: qualsiasi oggetto che ha agito come intermediario nell'evento. Potrebbero essere inclusi oggetti come server proxy e server di posta.
• observer: qualsiasi oggetto che non interagisce direttamente con il traffico in questione. Potrebbe trattarsi di uno scanner di vulnerabilità o di un dispositivo di packet sniffing.
• about: qualsiasi altro oggetto che ha avuto un ruolo nell'evento ed è facoltativo.

Gli attributi principali

Rappresenta l'entità o il dispositivo che ha originato l'attività. L'entità deve includere almeno un dettaglio della macchina (nome host, indirizzo MAC, indirizzo IP, identificatori specifici del prodotto come un GUID della macchina CrowdStrike) o un dettaglio dell'utente (ad esempio, il nome utente) e, facoltativamente, i dettagli del processo. Non deve includere nessuno dei seguenti campi: email, file, chiavi o valori del registry.

Se l'evento si verifica su una singola macchina, questa viene descritta solo nell'attributo principal. La macchina non deve essere descritta negli attributi target o src.

Nota: un dispositivo di sicurezza potrebbe registrare un evento, ma questo non verrebbe descritto nell'attributo principal. Verrà descritto nell'attributo observer o intermediary. Se il software di sicurezza (ad esempio Carbon Black) viene eseguito sullo stesso dispositivo che ha generato l'attività (ad esempio un endpoint Windows in cui è stato rilevato un malware), il dispositivo Windows sarà l'entità principale.

Il seguente snippet JSON illustra come potrebbe essere compilato l'attributo principal.

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

Questo attributo descrive tutto ciò che è noto sul dispositivo e sull'utente che è stato l'attore principale dell'evento. Questo esempio include l'indirizzo IP, il numero di porta e il nome host del dispositivo. Include anche un identificatore di asset specifico del fornitore, da Sophos, che è un identificatore univoco generato dal prodotto di sicurezza di terze parti.

Gli attributi target

Rappresenta un dispositivo di destinazione a cui fa riferimento l'evento o un oggetto sul dispositivo di destinazione. Ad esempio, in una connessione firewall dal dispositivo A al dispositivo B, il dispositivo A viene acquisito come entità e il dispositivo B come target.

Per un'iniezione in un processo da parte del processo C nel processo di destinazione D, il processo C è l'entità e il processo D è la destinazione.

Figura: entità rispetto alla destinazione

L'esempio seguente illustra come potrebbe essere compilato il campo di destinazione.

target {
   ip: "192.0.2.31"
   port: 80
}

Se nel log non elaborato originale sono disponibili ulteriori informazioni, come nome host, indirizzi IP aggiuntivi, indirizzi MAC e identificatori di asset proprietari, queste devono essere incluse anche nei campi target e principal.

Sia l'entità che la destinazione possono rappresentare attori sulla stessa macchina. Ad esempio, il processo A (principal) in esecuzione sulla macchina X potrebbe agire sul processo B (target) sempre sulla macchina X.

L'attributo src

Rappresenta un oggetto di origine su cui il partecipante agisce, insieme al contesto del dispositivo o del processo per l'oggetto di origine (la macchina in cui si trova l'oggetto di origine). Ad esempio, se l'utente U copia il file A sulla macchina X nel file B sulla macchina Y, sia il file A che la macchina X verranno specificati nella parte src dell'evento UDM.

L'attributo Intermediary

Rappresenta i dettagli di uno o più dispositivi intermedi che elaborano l'attività descritta nell'evento. Potrebbero essere inclusi dettagli su dispositivi come server proxy e server di inoltro SMTP.

L'attributo observer

Rappresenta un dispositivo osservatore che non è un intermediario diretto, ma che osserva e segnala l'evento in questione. Potrebbe trattarsi di uno sniffer di pacchetti o di uno scanner di vulnerabilità basato sulla rete.

L'attributo about

Questo campo memorizza i dettagli di un oggetto a cui fa riferimento l'evento, che non è descritto nei campi principal, src, target, intermediary o observer. Ad esempio, potrebbe acquisire quanto segue:

• File allegati alle email.
• Domini, URL o indirizzi IP incorporati nel corpo dell'email.
• DLL caricate durante un evento PROCESS_LAUNCH.

L'attributo security_result

Questa sezione contiene informazioni sui rischi e sulle minacce alla sicurezza rilevati da un sistema di sicurezza e sulle azioni intraprese per mitigarli.

Ecco i tipi di informazioni che verrebbero memorizzati nell'attributo security_result:

• Un proxy di sicurezza delle email ha rilevato un tentativo di phishing (security_result.category = MAIL_PHISHING) e ha bloccato (security_result.action = BLOCK) l'email.
• Un firewall proxy di sicurezza delle email ha rilevato due allegati infetti (security_result.category = SOFTWARE_MALICIOUS), li ha messi in quarantena e li ha disinfettati (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION), quindi ha inoltrato l'email disinfettata.
• Un sistema SSO consente un accesso (security_result.category = AUTH_VIOLATION) che era stato bloccato (security_result.action = BLOCK).
• Una sandbox per malware ha rilevato uno spyware (security_result.category = SOFTWARE_MALICIOUS) in un file allegato cinque minuti dopo che il file è stato consegnato (security_result.action = ALLOW) all'utente nella sua posta in arrivo.

L'attributo network

Gli attributi di rete memorizzano i dati sugli eventi relativi alla rete e i dettagli sui protocolli all'interno dei sottomessaggi. Sono incluse attività come le email inviate e ricevute e le richieste HTTP.

L'attributo extensions

I campi di questo archivio attributi memorizzano metadati aggiuntivi sull'evento acquisito nel log non elaborato originale. Può contenere informazioni sulle vulnerabilità o informazioni aggiuntive relative all'autenticazione.

Struttura di un'entità UDM

Un record di entità UDM memorizza le informazioni su qualsiasi entità all'interno di un'organizzazione. Se metadata.entity_type è USER, il record memorizza le informazioni sull'utente nell'attributo entity.user. Se metadata.entity_type è ASSET, il record memorizza informazioni su un asset, ad esempio workstation, laptop, smartphone e macchina virtuale.

Figura: modello dei dati sugli eventi

I campi dei metadati

Questa sezione contiene i campi obbligatori in un'entità UDM, ad esempio:

• collection_timestamp: la data e l'ora in cui è stato raccolto il record.
• entity_type: il tipo di entità, ad esempio asset, utente e risorsa.

L'attributo dell'entità

I campi dell'attributo entity memorizzano informazioni sull'entità specifica, come il nome host e l'indirizzo IP se si tratta di un asset o windows_sid e l'indirizzo email se si tratta di un utente. Tieni presente che il nome del campo è entity, ma il tipo di campo è un sostantivo. Un sostantivo è una struttura di dati di uso comune che memorizza informazioni sia nelle entità che negli eventi.

• Se metadata.entity_type è USER, i dati vengono archiviati nell'attributo entity.user.
• Se metadata.entity_type è ASSET, i dati vengono archiviati nell'attributo entity.asset.

L'attributo relation

I campi dell'attributo di relazione memorizzano informazioni su altre entità a cui è correlata l'entità principale. Ad esempio, se l'entità principale è un utente e all'utente è stato assegnato un laptop. Il laptop è un'entità correlata. Le informazioni sul laptop vengono archiviate come record entity con metadata.entity_type = ASSET. Le informazioni sull'utente vengono archiviate come record entity con metadata.entity_type = USER.

Il record dell'entità utente acquisisce anche la relazione tra l'utente e il laptop, utilizzando i campi dell'attributo relation. Il campo relation.relationship memorizza la relazione che l'utente ha con il laptop, in particolare che l'utente possiede il laptop. Il campo relation.entity_type memorizza il valore ASSET, perché il laptop è un dispositivo.

I campi dell'archivio attributi relations.entity memorizzano informazioni sul laptop, come il nome host e l'indirizzo MAC. Ancora una volta, il nome del campo è entity e il tipo di campo è un sostantivo. Un sostantivo è una struttura di dati di uso comune. I campi dell'attributo relation.entity memorizzano le informazioni sul laptop.

Il campo relation.direction memorizza la direzionalità della relazione tra l'utente e il laptop, in particolare se la relazione è bidirezionale o unidirezionale.

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.