Panoramica del modello di dati unificato

Supportato in:

Questo documento fornisce una panoramica del modello di dati unificato (UDM). Per maggiori informazioni dettagli sui campi UDM, inclusa una descrizione di ognuno, consulta il campo UDM elenco predefinito. Per ulteriori informazioni sulla mappatura del parser, consulta Campi UDM importanti per la mappatura del parser.

L'UDM è una struttura dati standard di Google Security Operations che archivia informazioni sui dati ricevuti dalle fonti. È 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 è un modello 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 tramite l'API Ingestion.

Ecco alcuni dei vantaggi di 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 le regole, in quanto le regole 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. 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 costituiti da più sezioni. La prima sezione trovata in ogni evento UDM è la sezione dei metadati. Fornisce una descrizione di base dell'evento, tra cui il timestamp in cui si è verificato l'evento e il timestamp in cui si è importati 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. Con e campi di 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: l'entità da cui ha origine l'attività nell'evento. Sezioni che fanno riferimento all'origine (src) e alla destinazione (target).
  • intermediary: sistemi trasmessi dagli eventi, come un 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: ricerca di accessi riusciti a Microsoft Windows 4624

Nella ricerca seguente sono elencati gli eventi di accesso riuscito a Microsoft Windows 4624. e quando sono stati generati gli 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 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. 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: cercare i dati di 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 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 in 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 ha emesso la .
  • principal.process.file.md5: identifica l'hash MD5.
  • principal.process.command_line: riga di comando.

Esempio: cercare accessi utente riusciti associati a un reparto specifico

L'esempio seguente cerca gli accessi per utenti (metadata.event_type è USER_LOGIN) associato al reparto marketing (target.user.department) è marketing) della tua impresa. Sebbene target.user.department non sia direttamente collegato agli eventi di accesso degli utenti, è ancora presente nei dati LDAP importati 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 memorizzano i dati. Ogni 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 quali asset, utenti e risorse nel tuo ambiente. È ottenuto da una fonte di o un'origine dati attendibile. Questo è il modello di dati delle entità UDM.

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

Modello dei dati degli eventi

Figura: modello di dati sugli eventi

Modello dei dati delle entità

Figura: Modello dei dati delle entità

Struttura di un evento UDM

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

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

  • estensioni

    Modello di dati sugli eventi

    Figura: modello di dati sugli eventi

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

principal, target, src, Negozio delle sezioni observer e intermediary informazioni sugli oggetti coinvolti nell'evento. Un oggetto può essere un dispositivo, utente o processo. Nella maggior parte dei casi, solo un sottoinsieme di queste sezioni in uso. 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 in 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 estensioni è un insieme in formato libero di coppie chiave-valore.

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. La Gli attributi obbligatori e facoltativi sono determinati dal metodo metadata.event_type valore. Google Security Operations legge metadata.event_type ed esegue il campo una convalida 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.

I seguenti esempi illustrano come specificare il timestamp utilizzando RFC 3339 formato yyyy-mm-ddThh:mm:ss+hh:mm (anno, mese, giorno, ora, minuto, e la differenza 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 dell'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 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, fai riferimento all'articolo sull'utilizzo dell'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 archivio contiene informazioni sugli oggetti coinvolti l'attività, come registrato dal log non elaborato originale. Potrebbe essere il dispositivo l'utente che ha eseguito l'attività, il dispositivo o l'utente target 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ù comunemente utilizzati sono:

  • principal: oggetto che ha eseguito l'attività.
  • src: oggetto che avvia l'attività, se diverso dall'entità.
  • target: oggetto su cui è stato eseguito un'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 e che è 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, quest'ultima viene descritta nel principal. Non occorre descrivere la macchina nel 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, oppure un oggetto nella 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.

Principale rispetto al target

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 originale non elaborato sono disponibili ulteriori informazioni, ad esempio nome host, indirizzi IP aggiuntivi, indirizzi MAC e identificatori di asset proprietari, deve essere incluso anche nei campi target e entità.

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 agisce il partecipante, insieme al contesto del dispositivo o del processo per l'oggetto di origine (la macchina in cui . Ad esempio, se l'utente U copia il file A sulla macchina X nel file B sulla macchina Y, verrebbero specificati sia il file A che la macchina X nella parte src l'evento UDM.

L'attributo intermediario

Rappresenta dettagli su uno o più dispositivi intermedi di elaborazione delle attività descritti nell'evento. Potrebbero essere inclusi i dettagli relativi ai dispositivi, ad esempio tra server proxy e server di inoltro SMTP.

L'attributo osservatore

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

L'attributo informazioni

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

  • Allegati file via 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 per la sicurezza e sulle minacce individuati da un sistema di sicurezza e le azioni intraprese per mitigare tali rischi e in modo proattivo.

Ecco i tipi di informazioni che verranno memorizzati nel report 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 di sicurezza email ha rilevato due allegati infetti (security_result.category = SOFTWARE_MALICIOUS) e messi in quarantena e disinfected (security_result.action = QUARANTINE o security_result.action = ALLOW_WITH_MODIFICATION) questi allegati e poi ha inoltrato disinfettata.
  • Un sistema SSO consente l'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 file allegato cinque minuti dopo che il file era inviati (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à come le email inviate e ricevute e richieste HTTP.

Attributo estensioni

I campi in questo attributo memorizzano metadati aggiuntivi sull'evento acquisito nel log non elaborato originale. Può contenere informazioni su vulnerabilità o su 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 valore record archivia informazioni su un asset, ad esempio workstation, laptop, telefono e la macchina virtuale.

Modello di dati delle entità

Figura: modello di dati sugli eventi

I campi dei metadati

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

  • collection_timestamp: la data & volta in cui è stata raccolta la registrazione.
  • entity_type: il tipo di entità, ad esempio risorsa, utente e risorsa.

Attributo entità

I campi sotto l'attributo entità memorizzano le informazioni sull'attributo come nome host e indirizzo IP se è un asset oppure windows_sid e 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 archivia 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 archiviati nel 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 archiviate come "entità" registra 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 la relazione dell'utente con il laptop, in particolare che l'utente possiede il laptop. Il campo relazionale.entity_type consente di archiviare il valore ASSET, perché il laptop è un dispositivo.

I campi sotto l'attributo reports.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 sotto l'attributo report.entity memorizzano le informazioni sul laptop.

Il campo report.direction memorizza la direzione della relazione tra l'utente e il laptop, in particolare se la relazione bidirezionali o unidirezionali.