Panoramica del modello di dati unificato

Questo documento fornisce una panoramica dell'Unified Data Model (UDM). Per maggiori informazioni dettagli sui campi UDM, inclusa una descrizione di ognuno, consulta la sezione Campo UDM elenco predefinito. Per ulteriori informazioni mappatura del parser, consulta Campi UDM importanti per l'analizzatore sintattico il mapping.

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 che riceve in due formati, log originale non elaborato e come record UDM strutturato. Il record UDM è un modello strutturato 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 vantaggi della tecnologia UDM:

• Archivia lo stesso tipo di record di diversi fornitori usando lo stesso la semantica.
• Consente di identificare più facilmente 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.
• Supporto più facile dei tipi di log dai nuovi dispositivi.

Nota: il motore delle regole di Google Security Operations utilizza gli stessi nomi dei campi UDM. Puoi usa gli stessi nomi dei campi durante la creazione delle regole.

Anche se puoi cercare eventi con una ricerca nei log non elaborata, una ricerca UDM funziona più rapidamente 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 degli endpoint con la stessa facilità con cui eventi di comunicazione.

Struttura UDM

Gli eventi UDM sono costituiti da più sezioni. La prima sezione che si trova in ogni L'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. Sono incluse anche informazioni sul prodotto, la versione e la descrizione. Il parser di importazione classifica ogni evento in base a una predefinito, indipendentemente dal log dei prodotti specifico. Con e campi di metadati, puoi iniziare rapidamente a cercare i dati.

Oltre alla sezione relativa ai metadati, altre sezioni descrivono altri aspetti dell'evento. Se una sezione non è necessaria, non viene inclusa, risparmiando 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 lo sniffer dei pacchetti che passano in modo passivo monitorare il traffico.

Esempi di ricerche UDM

Questa sezione fornisce esempi di ricerche UDM che dimostrano alcuni dei sintassi, funzionalità e 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

Nella ricerca seguente sono elencati tutti gli eventi di accesso riusciti, indipendentemente dal fornitore o 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 target. La sezione target include e campi che descrivono il target. Ad esempio, il target in questo case è un utente e ha una serie di attributi associati, ma il target potrebbe 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: cercare i dati di rete

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

di 3389 e un principal.ip di 35.235.240.5. Include inoltre un campo UDM della sezione della rete, la direzione del 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 un processo specifico

Per esaminare i processi creati sui tuoi server, cerca le istanze del net.exe e cerca il file specifico nel percorso previsto. La 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 è la descrizione 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"

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 in cui sono archiviati i dati. Ogni 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 meno Entità e anche il valore impostato in metadata.event_type o nel campo metadata.entity_type.

• Evento UDM: memorizza i dati relativi a un'azione che si è verificata nella completamente gestito di Google Cloud. Il log eventi originale descrive l'azione così come è stata registrata dal dispositivo, come firewall e proxy web. Questi sono i dati sugli eventi UDM un modello di machine learning.
• 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 dei dati dell'entità UDM.

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

Figura: modello di dati sugli eventi

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

Figura: modello dei dati delle entità

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

Struttura di un evento UDM

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

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

• estensioni

  

  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 in cui vengono memorizzati i dati sono determinati dal tipo di evento e che ogni oggetto svolge nell'evento.

La sezione Rete memorizza informazioni relative all'attività di rete, come comunicazioni correlate all'email e 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 archivia un'azione o una classificazione registrata da un prodotto per la sicurezza, ad esempio un prodotto antivirus.

Le sezioni Informazioni ed estensioni memorizzano altri eventi specifici del fornitore. informazioni non acquisite dalle altre sezioni. La sezione estensioni è un insieme in formato libero di coppie chiave-valore.

Ogni evento UDM archivia i valori di un evento di log non elaborato originale. In base tipo di evento, alcuni attributi sono obbligatori, altri 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 le 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 relativi a 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). La differenza rispetto al fuso orario UTC è meno di 8 ore. che indica 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, prodotto o piattaforma. I valori di esempio sono PROCESS_OPEN, FILE_CREATION, USER_CREATION e NETWORK_DNS. Per l'elenco completo, vedi il campo UDM elenco.

Il valore metadata.event_type determina quale e campi facoltativi 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 entità, target, src, intermediario, osservatore e informazioni

principal, target, src, Gli attributi intermediary e observer descrivono le risorse coinvolte 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 rilevato 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 da l'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 nel . Potrebbero essere inclusi oggetti come server proxy e server di posta.
• observer: qualsiasi oggetto che non interagisce direttamente con traffico in questione. Potrebbe trattarsi di uno scanner di vulnerabilità o sniffer device.
• about: qualsiasi altro oggetto che ha avuto un ruolo nell'evento e che è facoltativo.

Gli attributi dell'entità

Rappresenta l'entità che agisce o il dispositivo che ha dato origine all'attività. La L'entità deve includere almeno un dettaglio della macchina (nome host, indirizzo MAC, IP specifici del prodotto, come il GUID di una macchina CrowdStrike) o l'utente (ad es. nome utente) e, facoltativamente, includere dettagli sul processo. Deve non includere nessuno dei seguenti campi: email, file, chiavi del Registro di sistema o valori.

Se l'evento si verifica su una singola macchina, quest'ultima viene descritta nel principal. Non occorre descrivere la macchina nel target o src.

Nota: un dispositivo di sicurezza potrebbe registrare un evento, ma non sarebbe descritto nella l'attributo principal. Potrebbe essere descritto nell'osservatore intermediario. Se il software di sicurezza (ad esempio Carbon Black) viene eseguito sullo stesso dispositivo che ha originato l'attività (ad esempio, un in cui è stato rilevato malware), il dispositivo Windows rappresenta il principale.

Il seguente snippet JSON illustra come l'attributo principal potrebbe essere compilato.

"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 era l'attore principale dell'evento. Questo esempio include l'indirizzo IP del dispositivo, numero di porta e nome host. Include anche un identificatore di risorse specifico del fornitore, da Sophos, un identificatore univoco generato dal team di sicurezza prodotto.

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 tra il dispositivo A e il dispositivo B, il dispositivo A viene acquisito come entità e il dispositivo B viene acquisito come destinazione.

Per un processo di iniezione tramite il processo C nel processo D target, il processo C è la l'entità e il processo D sono il target.

Figura: entità e 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 risorse proprietari, deve essere incluso anche nei campi target e entità.

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

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.

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 osservatore che non è un intermediario diretto, ma che osserva e segnala l'evento in questione. Potrebbe includere un pacchetto sniffer o scanner di vulnerabilità basato su rete.

L'attributo informazioni

Questo datastore mostra i dettagli di un oggetto a cui fa riferimento l'evento che non è descritti nei campi principal, src, target, intermediario o osservatore. Per potrebbe acquisire quanto segue:

• Allegati file via email.
• Domini, URL o IP con indirizzo 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 dell'email ha rilevato un tentativo di phishing (security_result.category = MAIL_PHISHING) e bloccata (security_result.action = BLOCCA) 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 relativi agli eventi di rete e ai dettagli i protocolli all'interno dei messaggi secondari. Sono incluse attività come le email inviate e ricevute e richieste HTTP.

Attributo delle estensioni

I campi in questo attributo memorizzano metadati aggiuntivi sull'evento acquisito nel log non elaborato originale. Può contenere informazioni sulle vulnerabilità altre informazioni 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 sul parametro l'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.

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 asset, 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. Come puoi notare, il nome del campo è "entity", ma è un nome. 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 nel attributo entity.user [entità.utente].
• Se metadata.entity_type è ASSET, i dati vengono archiviati nel attributo entity.asset.

L'attributo di relazione

I campi sotto l'attributo di relazione memorizzano le informazioni su altre entità che a cui è correlata l'entità principale. Ad esempio, se l'entità principale è un utente e all'utente è stato fornito 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 'entity' con il valore metadata.entity_type = USER.

Il record dell'entità utente acquisisce anche la relazione tra l'utente e Laptop, utilizzando i campi nella colonna "relazione" . Relazione memorizza la relazione che l'utente ha con il laptop, in particolare 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. Nota ancora una volta 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.