Panoramica del modello di dati unificato

Questo documento fornisce una panoramica del modello di dati unificato (UDM). Per ulteriori 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.

L'UDM è una struttura di dati standard di Google Security Operations che memorizza informazioni sui dati ricevuti dalle origini. È chiamato anche schema. Google Security Operations archivia i dati originali ricevuti 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 Security Operations utilizzando l'API di importazione.

Ecco alcuni vantaggi dell'UDM:

• 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 perché possono essere indipendenti dalla piattaforma.
• È più facile supportare i tipi di log dei nuovi dispositivi.

Sebbene sia possibile cercare eventi con una ricerca dei log non elaborati, una ricerca UDM funziona più velocemente e con maggiore precisione grazie alla sua specificità.

Google Security Operations utilizza lo schema UDM per tutti gli eventi raccolti. L'UDM include migliaia di campi utilizzati per descrivere e classificare gli eventi. Ad esempio, UDM può gestire gli eventi di processo dell'endpoint con la stessa facilità degli eventi di comunicazione di rete.

Struttura UDM

Gli eventi UDM sono composti da più sezioni. La prima sezione trovata in ogni evento UDM è la sezione dei metadati. Fornisce una descrizione di base dell'evento, incluso il timestamp dell'evento e il timestamp dell'importazione in Google Security Operations. Include inoltre le informazioni, la versione e la descrizione del prodotto. L'analizzatore 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 e si risparmia memoria.

• principal: 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, ad esempio un server proxy o un inoltro SMTP.
• observer: sistemi come gli sniffer di pacchetti che monitorano passivamente il traffico.

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 di Microsoft Windows 4624

La seguente ricerca elenca gli eventi di accesso riusciti 4624 di Microsoft Windows, insieme al momento in cui sono stati generati, 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 completarla utilizzando la sezione Destinazione. La sezione del target include sezioni secondarie e campi che descrivono il target. Ad esempio, in questo caso il target è un utente e ha una serie di attributi associati, ma potrebbe anche essere un file, un'impostazione di registro o una risorsa. 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: cercare nei dati di rete

L'esempio seguente cerca eventi RDP nei dati di rete con un valore target.port 3389 e un valore principal.ip di 35.235.240.5. Include anche un campo UDM della sezione della 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 corrisponda alla 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"

Se vuoi, puoi aggiungere i seguenti campi di ricerca UDM:

• principal.user.userid: identifica l'utente che emette 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. Anche se target.user.department non è direttamente collegato agli eventi di accesso degli utenti, è comunque presente nei dati LDAP importati 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 memorizzano i dati. Ogni record UDM identifica se descrive un evento o un'entità. I dati vengono memorizzati in campi diversi a seconda che il record descriva un evento o un'entità e anche in base al valore impostato nel campo metadata.event_type o metadata.entity_type.

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

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

Figura: modello di dati sugli eventi

Figura: Modello dei dati delle entità

Struttura di un evento UDM

L'evento UDM contiene più sezioni che memorizzano ciascuna un sottoinsieme di dati per un singolo record. Le sezioni sono:

• metadati
• entità
• target
• src
• osservatore
• intermediario
• about
• e viceversa
• security_result

• estensioni

  

  Figura: modello di dati sugli eventi

La sezione metadata 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. Nella maggior parte dei casi, viene utilizzato solo un sottoinsieme di queste sezioni. I campi che memorizzano i dati sono determinati dal tipo di evento e dal ruolo svolto da ciascun oggetto nell'evento.

La sezione Rete memorizza le informazioni relative all'attività di rete, ad esempio email e comunicazioni relative alla 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 about ed extensions memorizzano informazioni aggiuntive sugli eventi specifici 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 rispetto a quelli facoltativi sono determinati dal valore metadata.event_type. Google Security Operations legge metadata.event_type ed esegue la convalida del campo 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, che è 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 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 rispetto all'ora UTC). Lo scarto da UTC è di meno 8 ore, indicando 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. Alcuni esempi di valori sono 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 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. Ogni elemento memorizza le 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.

Attributi principali

Rappresenta la persona giuridica che agisce o il dispositivo da cui ha avuto origine l'attività. Il principale deve includere almeno un dettaglio della macchina (nome host, indirizzo MAC, indirizzo IP, identificativi specifici del prodotto come un GUID della macchina CrowdStrike) o un dettaglio dell'utente (ad esempio il nome utente) e, facoltativamente, i dettagli della procedura. Non deve includere nessuno dei seguenti campi: email, file, chiavi o valori del Registro di sistema.

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

Lo snippet JSON seguente 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 della risorsa 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 target.

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

Figura: valore principale rispetto al target

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

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

L'attributo src

Rappresenta un oggetto di origine su cui il partecipante esegue un'azione, insieme al contesto del dispositivo o del processo per l'oggetto di origine (la macchina in cui risiede 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 relativi all'attività di elaborazione di uno o più dispositivi intermedi descritta nell'evento. Potrebbero essere inclusi dettagli su dispositivi come server proxy e server di inoltro SMTP.

L'attributo observer

Rappresenta un dispositivo di osservazione che non è un intermediario diretto, ma che osserva e genera report sull'evento in questione. Potrebbe includere uno sniffer di pacchetti o uno scanner di vulnerabilità basato sulla rete.

L'attributo about

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 di 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 alla sicurezza rilevati da un sistema di sicurezza e sulle azioni intraprese per attenuarli.

Di seguito sono riportati i tipi di informazioni che verranno memorizzati nell'attributo security_result:

• Un proxy di sicurezza per le email ha rilevato un tentativo di phishing (security_result.category = MAIL_PHISHING) e ha bloccato (security_result.action = BLOCK) l'email.
• Un firewall proxy per la sicurezza delle email ha rilevato due allegati infetti (security_result.category = SOFTWARE_MALICIOUS) e li ha messi in quarantena e disinfettati (security_result.action = QUARANTINE o security_result.action = ALLOW_WITH_MODIFICATION) e poi ha inoltrato 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 spyware (security_result.category = SOFTWARE_MALICIOUS) in un allegato cinque minuti dopo che il file è stato inviato (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 messaggi secondari. Sono incluse le attività, ad esempio le email inviate e ricevute e le richieste HTTP.

Attributo estensioni

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

Struttura di un'entità UDM

Un record dell'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 una risorsa, ad esempio workstation, laptop, telefono e macchina virtuale.

Figura: modello di 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 risorsa, utente e asset.

L'attributo entità

I campi dell'attributo entity memorizzano informazioni sull'entità specifica, ad esempio il nome host e l'indirizzo IP se si tratta di una risorsa oppure 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 nome è 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 memorizzati nell'attributo entity.asset.

L'attributo 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 a questo utente è stato assegnato un laptop. Il laptop è un'entità correlata. Le informazioni sul laptop vengono memorizzate come record "entità" con un valore 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 dell'utente 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'attributo relations.entity memorizzano le informazioni sul laptop, come il nome host e l'indirizzo MAC. Tieni presente che il nome del campo è 'entity' e il tipo di campo è un sostantivo. Un nome è una struttura di dati di uso comune. I campi dell'attributo relation.entity memorizzano le informazioni sul laptop.

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