Panoramica del modello di dati unificato

Supportato in:

Google SecOps SIEM

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

L'UDM è una struttura di dati standard di Google Security Operations che memorizza le informazioni sui dati ricevuti dalle origini. È chiamato anche 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 in formato UDM strutturato prima di inviare i dati a Google SecOps utilizzando l'API Ingestion.

Alcuni dei vantaggi 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, in quanto 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 gli stessi nomi dei campi quando crei le regole.

Anche se puoi 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 dei 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 dell'endpoint ed eventi di comunicazione di rete.

Struttura UDM

Gli eventi UDM sono composti da più sezioni. La prima sezione presente in ogni evento UDM è la sezione dei metadati. Fornisce una descrizione di base dell'evento, inclusi il timestamp in cui si è verificato l'evento e il timestamp in cui è stato inserito 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. Con i soli campi dei metadati, puoi iniziare rapidamente a cercare i dati.

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

• principal: l'entità che ha generato 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 i packet sniffer che monitorano passivamente il traffico.

Formattazione di un evento UDM

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

1. Specifica il tipo di evento: il tipo di evento selezionato determina i campi da includere anche nell'evento.
2. Specifica il timestamp dell'evento: specifica il timestamp dell'evento.
3. Specifica i nomi (entità): ogni evento deve includere almeno un nome che descriva un dispositivo o un utente partecipante coinvolto nell'evento.
4. Specifica il risultato di sicurezza: (facoltativo) specifica i risultati di sicurezza includendo i dettagli sui rischi e sulle minacce per la sicurezza rilevati da un sistema di sicurezza, nonché le azioni intraprese per mitigare questi rischi e minacce.
5. Compila le informazioni sugli eventi obbligatorie e facoltative rimanenti utilizzando i campi evento UDM.

Specifica il tipo di evento

Il valore più importante definito per qualsiasi evento inviato in formato UDM è il tipo di evento, specificato utilizzando uno dei valori possibili disponibili per Metadata.event_type. Questi includono valori come PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS e così via (per l'elenco completo, vedi Metadata.event_type). Ogni tipo di evento richiede anche di compilare un insieme di altri campi e valori con le informazioni associate all'evento originale. Consulta Campi obbligatori e facoltativi per ogni tipo di evento UDM per informazioni dettagliate sui campi da includere per ogni tipo di evento. Il seguente esempio mostra 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 timbro deve essere codificato utilizzando uno dei seguenti standard:

• Per JSON, utilizza RFC 3339
• Timestamp Proto3

L'esempio seguente mostra 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 lo scarto con fuso orario UTC. Lo scarto da UTC è di -8 ore, il che indica il fuso orario PST.

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

Specifica i nomi (entità)

Per ogni evento UDM, devi definire uno o più nomi. Un sostantivo rappresenta un partecipante o un'entità in un evento UDM. Un sostantivo potrebbe essere, ad esempio, il dispositivo/utente che esegue l'attività descritta in un evento o il dispositivo/utente che è il target di tale attività descritta nell'evento. I sostantivi possono anche essere allegati o URL. Infine, un sostantivo può essere utilizzato anche per descrivere un dispositivo di sicurezza che ha osservato l'attività descritta nell'evento (ad esempio, un proxy email o un router di rete).

Un evento UDM deve avere specificato uno o più dei seguenti nomi:

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

Se tutti gli eventi si svolgono sulla stessa macchina, questa deve essere descritta solo in principal. La macchina non deve essere descritta anche in target o in src.

Nota :un dispositivo di sicurezza potrebbe generare un evento, ma non sarebbe descritto nel campo principale; sarebbe descritto nei campi osservatore o intermediario. 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), anche questo dispositivo sarà il principale.

Il seguente esempio 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 l'indirizzo IP, il numero di porta e il nome host del dispositivo, nonché un identificatore di asset specifico del fornitore (di Sophos), ovvero un ID univoco generato dal prodotto di sicurezza di terze parti.

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, A è descritto come principale e B come destinazione. Per un'iniezione in un processo da parte del processo C nel processo di destinazione D, il processo C viene descritto come principale e il processo D come destinazione.

Entità e target in UDM

Il seguente esempio mostra come vengono compilati i campi per una destinazione:

target {
   ip: "198.51.100.31"
   port: 80
}

Anche in questo caso, se sono disponibili ulteriori informazioni, come nome host, indirizzi IP aggiuntivi, indirizzi MAC, identificatori di asset proprietari e così via, devono essere incluse anche in target.

Sia l'entità sia il target (e altri sostantivi) possono fare riferimento agli attori sulla stessa macchina. Ad esempio, il processo A (entità di servizio) in esecuzione sulla macchina X agisce sul processo B (target) anch'esso sulla macchina X.

• src:rappresenta un oggetto di origine su cui agisce il partecipante 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 sia la macchina X verranno specificati nella parte src dell'evento UDM.
• intermediario:rappresenta i dettagli di uno o più dispositivi intermedi che elaborano l'attività descritta nell'evento. Sono inclusi i dettagli del dispositivo relativi a un server proxy, a un server di inoltro SMTP e così via.
• observer:rappresenta un dispositivo osservatore (ad esempio, un packet sniffer o uno scanner di vulnerabilità basato sulla rete), che non è un intermediario diretto, ma che osserva e segnala l'evento in questione.
• about: utilizzato per memorizzare i dettagli di tutti gli oggetti a cui fa riferimento l'evento e che non sono descritti in participant, src, target, intermediary o observer. Ad esempio, potrebbe essere utilizzata per monitorare quanto segue:
  • Allegati file email
  • Domini/URL/IP incorporati nel corpo di un'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 ha requisiti obbligatori per quanto riguarda il riempimento dei campi Noun. Questi requisiti sono descritti in Campi obbligatori e facoltativi per ogni tipo di evento UDM. Il set di campi dell'entità da compilare varia in base al tipo di evento.

Specificare il risultato di sicurezza

Se vuoi, puoi specificare i risultati di sicurezza compilando i campi SecurityResult, inclusi i dettagli sui rischi e sulle minacce per la 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 proxy di sicurezza email ha rilevato un tentativo di phishing (MAIL_PHISHING) e ha bloccato (BLOCK) l'email.
• Un firewall proxy di sicurezza email ha rilevato due allegati infetti (SOFTWARE_MALICIOUS), li ha messi in quarantena e disinfettati (QUARANTINE, ALLOW_WITH_MODIFICATION) e poi ha inoltrato l'email disinfettata.
• Un sistema SSO ha facilitato un accesso (AUTH_VIOLATION) che è stato bloccato (BLOCK).
• Una sandbox per il malware ha rilevato spyware (SOFTWARE_MALICIOUS) in un allegato di file cinque minuti dopo che il file è stato recapitato (ALLOW) all'utente nella sua Posta in arrivo.

Esempi di ricerche UDM

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

Esempio: cerca gli accessi riusciti a Microsoft Windows 4624

La seguente ricerca elenca gli eventi di accesso riuscito di Microsoft Windows 4624, insieme alla data 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

Il seguente esempio mostra 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, la destinazione in questo caso è un utente e ha una serie di attributi associati, ma la destinazione 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 nei dati di rete

Il seguente esempio esegue la ricerca nei dati di rete di eventi RDP con un target.port di 3389 e un principal.ip di 35.235.240.5. Include anche un campo UDM della sezione 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 una procedura specifica

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 emesso nel campo target.process.command_line. Puoi anche aggiungere un campo nella sezione Informazioni, ovvero 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"

(Facoltativo) 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 inseriti sui 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 a seconda del valore impostato nel campo metadata.event_type o metadata.entity_type.

• Evento UDM: memorizza i dati relativi a un'azione eseguita 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 ottenuto da un'origine dati source of truth.

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 Noun descrive il tipo di attributo. I termini principal, target, src, intermediary, observer e about sono i nomi dei campi in cui sono archiviati i dati.

Figura: modello dei dati sugli eventi

Nota :il termine Noun 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à
• target
• src
• osservatore
• 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 può essere un dispositivo, un utente o un processo. La maggior parte delle volte viene utilizzato solo un sottoinsieme di queste sezioni. I campi che archiviano i dati sono determinati dal tipo di evento e dal ruolo che ogni oggetto svolge nell'evento.

La sezione Rete memorizza le informazioni relative all'attività di rete, ad esempio le comunicazioni via email e di rete.

• Dati email: informazioni nei campi to, from, cc, bcc e altri campi 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 Informazioni ed Estensioni 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 di metadata.event_type. Google SecOps legge metadata.event_type ed esegue la convalida dei campi specifici per quel tipo di evento dopo aver ricevuto i log.

Se in una sezione del record UDM, ad esempio la sezione delle estensioni, non sono memorizzati dati, 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 dati per metadata.event_timestamp, ovvero il timestamp GMT in cui si è verificato l'evento. Il valore deve essere codificato utilizzando uno dei seguenti standard: timestamp RFC 3339 o Proto3.

Gli esempi seguenti mostrano come specificare il timestamp utilizzando il formato RFC 3339, yyyy-mm-ddThh:mm:ss+hh:mm (anno, mese, giorno, ora, minuto, secondo e offset rispetto al fuso orario UTC). Lo scarto da UTC è di -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 obbligatori e facoltativi aggiuntivi devono essere inclusi nel record UDM. Per informazioni sui campi da includere per ciascun 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. Ogni negozio contiene 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à, del dispositivo o dell'utente che è il target dell'attività. Potrebbe anche descrivere un dispositivo di sicurezza che ha osservato l'attività, come un proxy email o un router di rete.

Gli attributi più utilizzati sono:

• principal: oggetto che ha eseguito l'attività.
• src: oggetto che avvia l'attività, se diverso dall'entità.
• target: 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 da 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 sniffer di pacchetti.
• about: qualsiasi altro oggetto che ha svolto un ruolo nell'evento ed è facoltativo.

Gli attributi principali

Rappresenta la persona giuridica o il dispositivo che ha generato l'attività. Il soggetto deve includere almeno un dettaglio della macchina (nome host, indirizzo MAC, indirizzo IP, identificatori specifici del prodotto come un GUID 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 registro.

Se l'evento si svolge 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 non sarebbe descritto nell'attributo principale. Verrà descritto nell'attributo osservatore o intermediario. 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 malware), il dispositivo Windows sarà il principale.

Il seguente snippet JSON mostra 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 del dispositivo, il numero di porta e il nome host. Include anche un identificatore di asset specifico del fornitore, di 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 principale e il dispositivo B come destinazione.

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

Figura: principale rispetto al target

Il seguente esempio 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, ad esempio nome host, indirizzi IP aggiuntivi, indirizzi MAC e identificatori di asset proprietari, queste devono essere incluse anche nei campi target e principale.

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

L'attributo src

Rappresenta un oggetto di origine su cui agisce il partecipante 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 intermediario

Rappresenta i dettagli di uno o più dispositivi intermedi che elaborano l'attività descritta nell'evento. Questi potrebbero includere 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 un packet sniffer o di uno scanner di vulnerabilità basato sulla rete.

L'attributo Informazioni

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

• Allegati ai file email.
• Domini, URL o indirizzi IP incorporati nel corpo di un'email.
• DLL caricate durante un evento PROCESS_LAUNCH.

Attributo security_result

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

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

• Un proxy di sicurezza 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 email ha rilevato due allegati infetti (security_result.category = SOFTWARE_MALICIOUS) e li ha messi in quarantena e disinfettati (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION), per poi inoltrare l'email disinfettata.
• Un sistema SSO consente un accesso (security_result.category = AUTH_VIOLATION) che è stato bloccato (security_result.action = BLOCK).
• Una sandbox per il malware ha rilevato uno spyware (security_result.category = SOFTWARE_MALICIOUS) in un allegato di file cinque minuti dopo la consegna (security_result.action = ALLOW) all'utente nella sua Posta in arrivo.

L'attributo di rete

Gli attributi di rete archiviano i dati relativi agli eventi correlati alla rete e i dettagli sui protocolli all'interno dei messaggi secondari. Sono incluse attività come email inviate e ricevute e richieste HTTP.

L'attributo Estensioni

I campi di questo attributo 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 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, come 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: data e 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 dell'entità memorizzano informazioni sull'entità specifica, ad esempio nome host e indirizzo IP se si tratta di un asset oppure windows_sid e 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 di relazione

I campi dell'attributo 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 memorizzate come record entity con un 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 il rapporto dell'utente con il laptop, in particolare che l'utente è proprietario del laptop. Il campo relation.entity_type memorizza il valore ASSET, perché il laptop è un dispositivo.

I campi in relations.entity memorizzano informazioni sul laptop, come il nome host e l'indirizzo MAC. Nota ancora una volta che 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.