Panoramica del modello di dati unificato

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

UDM è una struttura di dati standard di Chronicle che archivia le informazioni sui dati ricevuti dalle origini. È anche chiamato schema. Chronicle archivia i dati originali che riceve in due formati: il log non elaborato originale e un record UDM strutturato. Il record UDM è una rappresentazione strutturata del log originale.

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

Alcuni dei vantaggi dell'UDM includono:

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

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

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

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

Struttura UDM

Gli eventi UDM sono composti da più sezioni. La prima sezione che si trova in ogni evento UDM è la sezione dei metadati. Fornisce una descrizione di base dell'evento, inclusi il timestamp in cui si è verificato e il timestamp in cui è stato importato in Chronicle. oltre a informazioni sul prodotto, versione e descrizione. Il parser di importazione classifica ogni evento in base a un tipo di evento predefinito, indipendentemente dal log del prodotto specifico. Utilizzando solo i campi di metadati, puoi iniziare rapidamente a cercare i dati.

Oltre alla sezione dei metadati, in altre sezioni vengono descritti altri aspetti dell'evento. Se una sezione non è necessaria, non viene inclusa, risparmiando memoria.

• principal: entità che ha dato origine all'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 server proxy o 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 dimostrano alcune delle funzionalità, sintassi e funzionalità di base della ricerca UDM.

Esempio: ricerca di accessi a Microsoft Windows 4624 riusciti

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

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

Esempio: ricerca di 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: ricerca di 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 di destinazione. La sezione della destinazione include sezioni e campi che descrivono la destinazione. Ad esempio, in questo caso la destinazione è un utente a cui sono associati vari attributi, ma la destinazione potrebbe anche essere un file, un'impostazione del registro o un asset. In questo esempio viene eseguita la ricerca di "fkolzig" utilizzando il campo target.user.userid.

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

Esempio: ricerca nei dati di rete

L'esempio seguente cerca nei dati di rete eventi RDP con target.port

di 3389 e un principal.ip di 35.235.240.5. Include anche un campo UDM della sezione Network, 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: cercare un processo specifico

Per esaminare i processi creati sui tuoi server, cerca 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 inviato nel comando target.process.command_line

. Puoi anche aggiungere un campo nella sezione delle 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 ha emesso il comando.
• principal.process.file.md5: identifica l'hash MD5.
• principal.process.command_line: riga di comando.

Esempio: cercare gli accessi riusciti degli utenti associati a un reparto specifico

L'esempio seguente cerca gli accessi in base agli 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 utente, è ancora presente nei dati LDAP importati relativi agli 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 diversi campi a seconda che il record descriva un evento o un'entità e anche il valore impostato nel campo metadata.event_type o metadata.entity_type.

• Evento UDM: archivia i dati per 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. Questo è il modello di dati Eventi UDM.
• Entità UDM: rappresentazione contestuale di elementi come asset, utenti e risorse nel tuo ambiente. È ottenuto da una fonte attendibile. 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 dell'entità.

Figura: modello dei dati sugli eventi

Nota :il termine Nome descrive il tipo di attributo. I termini principal, target, src, intermediario, osservatore e about sono i nomi dei campi in cui sono archiviati i dati.

Figura: modello dei dati delle entità

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

Struttura di un evento UDM

L'evento UDM contiene più sezioni in cui ogni record memorizza un sottoinsieme dei dati per un singolo record. Le sezioni sono:

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

• estensioni

  

  Figura: modello dei 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 archiviano le 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 in cui sono archiviati 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 le comunicazioni correlate a email e rete.

• Dati dell'email: informazioni nei campi to, from, cc, bcc e in altri campi dell'email.
• Dati HTTP: come method, referral_url e useragent.

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

Le sezioni about ed extensions contengono 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 archivia 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. Chronicle 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, quella sezione non viene visualizzata nel record UDM.

I campi dei metadati

In questa sezione vengono descritti i campi obbligatori in un evento UDM.

Il campo event_timestamp

Gli eventi UDM devono includere dati relativi a metadata.event_timestamp, ovvero il timestamp GMT al momento dell'evento. Il valore deve essere codificato utilizzando uno dei seguenti standard: timestamp RFC 3339 o Proto3.

I seguenti esempi 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 dall'ora UTC). Lo scarto rispetto al fuso orario UTC è meno 8 ore, a indicare 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 dell'evento UDM è metadata.event_type. Questo valore identifica il tipo di azione eseguita ed è indipendente da fornitore, prodotto o piattaforma. I valori di esempio sono PROCESS_OPEN, FILE_CREATION, USER_CREATION e NETWORK_DNS. Per l'elenco completo, consulta il documento sull'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, intermediario, osservatore e informazioni

Gli attributi principal, target, src, intermediary e observer descrivono gli asset coinvolti nell'evento. Ogni archivio memorizza le informazioni sugli oggetti coinvolti nell'attività, come registrato dal log non elaborato originale. Potrebbe essere il dispositivo o l'utente che ha eseguito l'attività, il dispositivo o l'utente 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 più comunemente utilizzati sono:

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

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

I campi ausiliari sono:

• intermediary: qualsiasi oggetto che ha operato 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 l'entità agente o il dispositivo che ha generato l'attività. L'entità deve includere almeno un dettaglio della macchina (nome host, indirizzo MAC, indirizzo IP, identificatori specifici del prodotto come il GUID della macchina di CrowdStrike) o un dettaglio utente (ad esempio il nome utente). Inoltre, facoltativamente, deve includere i dettagli del processo. Non deve includere nessuno dei seguenti campi: email, file, chiavi di registro o valori.

Se l'evento si verifica su una singola macchina, questa viene descritta solo nell'attributo principale. Non è necessario che la macchina sia descritta negli attributi target o src.

Nota: un dispositivo di sicurezza potrebbe registrare un evento, ma non verrebbe descritto nell'attributo principale. È descritto nell'attributo osservatore o intermediario. Se il software di sicurezza (ad esempio Carbon Black) viene eseguito sullo stesso dispositivo che ha originato l'attività (ad esempio un endpoint Windows in cui è stato rilevato un malware), il dispositivo Windows sarebbe il 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 tutte le informazioni note 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 inoltre un identificatore di asset specifico del fornitore, di Sophos, un identificatore univoco generato dal prodotto di sicurezza di terze parti.

Il target attribuisce

Rappresenta un dispositivo di destinazione a cui l'evento fa riferimento oppure 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 destinazione.

Per un'iniezione in un processo mediante il processo C nel processo di destinazione D, il processo C è l'entità, mentre il processo D è il target.

Figura: entità e target

L'esempio seguente illustra come completare 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, è necessario includerli anche nei campi Entità e Destinazione.

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

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 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 sull'attività di elaborazione di uno o più dispositivi intermedi descritti nell'evento. Potrebbero essere inclusi i dettagli dei dispositivi come server proxy e server di inoltro SMTP.

L'attributo osservatore

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

L'attributo informazioni

Questo archivio include i dettagli di un oggetto a cui fa riferimento l'evento che non è descritto nei campi entità, src, target, intermediari o osservatore. 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 per la sicurezza rilevati da un sistema di sicurezza e sulle azioni intraprese per mitigare tali rischi e minacce.

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

• Un proxy di sicurezza per l'email ha rilevato un tentativo di phishing (security_result.category = MAIL_PHISHING) e ha bloccato (security_result.action = BLOCK) l'email.
• Un firewall del proxy di sicurezza per le email ha rilevato due allegati infetti (security_result.category = SOFTWARE_MALICIOUS) e ha messo in quarantena e disinfettati (security_result.action = QUARANTINE o security_result.action = ALLOW_WITH_MODIFICATION) questi allegati e quindi 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 malware ha rilevato spyware (security_result.category = SOFTWARE_MALICIOUS) in un file allegato cinque minuti dopo la consegna del file (security_result.action = ALLOW) all'utente nella posta in arrivo.

L'attributo di rete

Gli attributi di rete memorizzano i dati sugli eventi relativi alla rete e i dettagli sui protocolli all'interno dei messaggi secondari. Sono incluse attività, ad esempio email inviate e ricevute e richieste HTTP.

L'attributo delle estensioni

I campi in 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 archivia 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 archivia le informazioni su una risorsa, ad esempio workstation, laptop, telefono 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 il record è stato raccolto.
• entity_type: il tipo di entità, ad esempio asset, utente e risorsa.

L'attributo dell'entità

I campi sotto l'attributo dell'entità memorizzano le informazioni sull'entità specifica, ad esempio il nome host e l'indirizzo IP se si tratta di un asset oppure windows_sid e indirizzo email se è un utente. Nota che il nome del campo è "entity", ma il tipo di campo è un Sostantivo. Un nome è una struttura di dati di uso comune che memorizza le informazioni sia in 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 di relazione

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

Il record delle entità utente acquisisce anche la relazione tra l'utente e il laptop, utilizzando i campi dell'attributo "relation". Il campo report.Relationship memorizza la relazione che l'utente ha con il laptop, nello specifico quando l'utente possiede il laptop. Il campo connection.entity_type memorizza il valore ASSET, perché il laptop è un dispositivo.

I campi all'interno dell'attributo Relas.entity archiviano le 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 all'interno dell'attributo connection.entity archiviano le informazioni sul laptop.

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