Panoramica del modello di dati unificato

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 dei parser, consulta Campi UDM importanti per la mappatura dei 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:

• Memorizza 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.
• Supporto più semplice dei tipi di log dei nuovi dispositivi.

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 aspetti aggiuntivi 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 cui passano gli eventi, come un server proxy o un inoltro SMTP.
• observer: sistemi come i packet sniffer che monitorano passivamente il traffico.

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 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, in questo caso il target è un utente e ha una serie di attributi associati, ma il target 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 cerca nei dati di rete 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 che contiene la descrizione del codice evento 1 (ProcessCreate) di Microsoft Sysmon.

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

Il seguente esempio 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à.

Figura: modello dei dati sugli eventi

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 metadati memorizza il timestamp, definisce il 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 estensioni è 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 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: 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 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 aggiuntivi obbligatori e facoltativi 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 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à, 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 avuto 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.

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, come il nome host, indirizzi IP aggiuntivi, indirizzi MAC e identificatori di asset proprietari, queste devono essere incluse anche nei campi target e principal.

Sia il principal che la destinazione 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. Ciò potrebbe includere uno sniffer di pacchetti o 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 su rischi e minacce per la 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 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 del file (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 le email inviate e ricevute e le 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, 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 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 sotto l'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.