Formattare i dati di log come UDM

Supportato in:

Google SecOps SIEM

Campi comuni degli eventi UDM

Tutti gli eventi Unified Data Model (UDM) hanno un insieme di campi e messaggi comuni che i partner possono compilare indipendentemente dal tipo di evento. Questi campi includono:

• Entità: dispositivi, utenti e processi coinvolti in un evento.
• Metadati evento: quando si è verificato l'evento, il tipo di evento, la relativa origine e così via.
• Metadati di rete: metadati di rete di alto livello per eventi orientati alla rete, nonché dettagli del protocollo all'interno dei messaggi secondari:
  • Metadati email: informazioni nei campi A, Da, Cc, Ccn e altri campi email.
  • Metadati HTTP: Method, referral_url, useragent e così via.
• Risultati relativi alla sicurezza: qualsiasi classificazione o azione eseguita da un prodotto per la sicurezza.
• Metadati aggiuntivi: qualsiasi dato evento importante specifico del fornitore che non può essere rappresentato adeguatamente nelle sezioni formali del modello UDM può essere aggiunto utilizzando un campo del payload JSON in formato libero.

Le sezioni seguenti descrivono come codificare e formattare gli eventi per l'UDM.

Codifica UDM

Gli eventi UDM devono essere inviati a Google Security Operations utilizzando uno dei seguenti formati:

• JSON (https://developers.google.com/protocol-buffers/docs/proto3#json)
• Proto3

Ai fini di questo documento, i campi sono rappresentati utilizzando una notazione a punti. Ad esempio, la seguente sintassi JSON:

{"menu":
  {
    "id": "file",
    "value": "File",
    "popup": {
      "menuitem": [
        {"value": "New", "onclick": "CreateNewDoc()"}
      ]
    }
  }
}

È documentato come segue:

menu.id = "file"
menu.value = "File"
menu.popup.menuitem.value = "New"
menu.popup.menuitem.onclick = "CreateNewDoc()"

Formattazione di un evento UDM

Per formattare un evento UDM in modo da renderlo pronto per l'invio a Google, devi completare i seguenti passaggi:

1. Specifica il tipo di evento: il tipo di evento selezionato determina i campi da includere nell'evento.
2. Specifica il timestamp dell'evento: specifica il timestamp dell'evento.
3. Specifica i nomi (entità): ogni evento deve includere almeno un nome che descriva un dispositivo o un utente partecipante coinvolto nell'evento.
4. Specifica il risultato di sicurezza: (Facoltativo) specifica i risultati di sicurezza includendo dettagli sui rischi e sulle minacce alla sicurezza rilevati da un sistema di sicurezza, nonché le azioni intraprese per mitigare questi rischi e minacce.
5. Compila il resto delle informazioni sugli eventi obbligatori e facoltativi utilizzando i campi evento UDM.

Specifica il tipo di evento

Il valore più importante definito per qualsiasi evento inviato in formato UDM è il tipo di evento, specificato utilizzando uno dei possibili valori disponibili per Metadata.event_type. Sono inclusi valori come PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS e così via (per l'elenco completo, consulta Metadata.event_type. Per ogni tipo di evento devi compilare anche un insieme di altri campi e valori con le informazioni correlate all'evento originale. Per informazioni dettagliate sui campi da includere per ogni tipo di evento UDM, consulta la sezione Campi obbligatori e facoltativi per ogni tipo di evento UDM. L'esempio seguente mostra come specificare PROCESS_OPEN come tipo di evento utilizzando la notazione di testo Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Specifica il timestamp dell'evento

Devi specificare il timestamp GMT per qualsiasi evento inviato in formato UDM utilizzando Metadata.event_timestamp. Il timbro deve essere codificato utilizzando uno dei seguenti standard:

• Per JSON, utilizza RFC 3339
• Timestamp Proto3

L'esempio seguente illustra come specificare il timestamp utilizzando il formato RFC 3339. Per questo esempio, aaaa-mm-ggThh:mm:ss+hh:mm: anno, mese, giorno, ora, minuto, secondo e lo scarto rispetto all'ora UTC. Lo scarto da UTC è di meno 8 ore, il che indica il fuso orario PST.

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

Specifica i nomi (entità)

Per ogni evento UDM, devi definire uno o più sostantivi. Un sostantivo rappresenta un partecipante o una persona giuridica in un evento UDM. Un sostantivo potrebbe essere, ad esempio, il dispositivo/utente che esegue l'attività descritta in un evento o il dispositivo/utente che è il target di questa attività descritta nell'evento. I nomi possono essere anche allegati o URL. Infine, un nome può essere utilizzato anche per descrivere un dispositivo di sicurezza che ha osservato l'attività descritta nell'evento (ad esempio, un proxy email o un router di rete).

Un evento UDM deve avere uno o più dei seguenti sostantivi specificati:

principal: rappresenta l'entità che agisce o il dispositivo che genera l'attività descritta nell'evento. Il principale deve includere almeno un dettaglio della macchina (nome host, MAC, IP, porta, identificatori specifici del prodotto come un GUID della 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 di sistema.

Se tutti gli eventi si verificano sulla stessa macchina, questa deve essere descritta solo in principal. La macchina non deve essere descritta anche in target o in src.

Nota: un dispositivo di sicurezza potrebbe generare un evento, ma non verrebbe descritto nel campo principale, bensì nei campi osservatore o intermediario. Se il software di sicurezza (ad esempio Carbon Black) viene eseguito sullo stesso dispositivo che ha generato l'attività (ad esempio un endpoint Windows in cui è stato rilevato un malware), anche questo dispositivo sarà il principale.

L'esempio seguente illustra come possono essere compilati i campi principal:

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

Questo esempio fornisce dettagli sul dispositivo e sull'utente che è stato l'attore principale dell'evento. Sono inclusi l'indirizzo IP, il numero di porta e il nome host del dispositivo, oltre a un identificatore della risorsa specifico del fornitore (di Sophos), ovvero un ID univoco generato dal prodotto di sicurezza di terze parti.

target: rappresenta un dispositivo di destinazione a cui fa riferimento l'evento o un oggetto sul dispositivo di destinazione. Ad esempio, in una connessione del firewall dal dispositivo A al dispositivo B, A è descritto come principale e B come target. Per un'iniezione di processo da parte del processo C nel processo target D, il processo C è descritto come principale e il processo D come target.

Principale e target in UDM

L'esempio seguente illustra come vengono compilati i campi per un target:

target {
   ip: "198.51.100.31"
   port: 80
}

Anche in questo caso, se sono disponibili ulteriori informazioni, ad esempio nome host, indirizzi IP aggiuntivi, indirizzi MAC, identificatori di asset proprietari e così via, devono essere inclusi anche in target.

Sia principal che target (nonché altri sostantivi) possono fare riferimento ad attori sulla stessa macchina. Ad esempio, il processo A (principale) in esecuzione sulla macchina X agisce sul processo B (target) anche sulla macchina X.

• 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 sia la macchina X verranno specificati nella parte src dell'evento UDM.
• intermediary: rappresenta i dettagli su uno o più dispositivi intermedi che elaborano l'attività descritta nell'evento. Sono inclusi i dettagli del dispositivo relativi a un server proxy, un server di inoltro SMTP e così via.
• observer:rappresenta un dispositivo di osservazione (ad esempio uno sniffer di pacchetti o uno scanner di vulnerabilità basato sulla rete), che non è un intermediario diretto, ma che osserva e genera report sull'evento in questione.
• about: utilizzato per memorizzare i dettagli di tutti gli oggetti a cui fa riferimento l'evento che non sono descritti in altro modo in participant, src, target, intermediary o observer. Ad esempio, potrebbe essere utilizzata per monitorare quanto segue:
  • Allegati file email
  • Domini/URL/IP incorporati nel corpo di un'email
  • DLL caricate durante un evento PROCESS_LAUNCH

Le sezioni delle entità degli eventi UDM includono informazioni sui vari partecipanti (dispositivi, utenti, oggetti come URL, file e così via) descritti nell'evento. L'UDM di Google Security Operations ha requisiti obbligatori per quanto riguarda la compilazione dei campi Noun. Questi requisiti sono descritti in Campi obbligatori e facoltativi per ogni tipo di evento UDM. L'insieme di campi delle entità da compilare varia in base al tipo di evento.

Specifica il risultato di sicurezza

Se vuoi, puoi specificare i risultati di sicurezza compilando i campi SecurityResult, inclusi i dettagli sui rischi e sulle minacce alla sicurezza rilevati dal sistema di sicurezza, nonché le azioni intraprese per mitigare questi rischi e minacce. Di seguito sono riportati alcuni esempi di tipi di eventi di sicurezza che richiedono la compilazione dei campi SecurityResult:

• Un proxy per la sicurezza delle email ha rilevato un tentativo di phishing (MAIL_PHISHING) e ha bloccato (BLOCK) l'email.
• Un firewall proxy per la sicurezza delle email ha rilevato due allegati infetti (SOFTWARE_MALICIOUS) e li ha messi in quarantena e disinfettati (QUARANTINE, ALLOW_WITH_MODIFICATION), quindi ha inoltrato l'email disinfettata.
• Un sistema SSO ha facilitato un accesso (AUTH_VIOLATION) che è stato bloccato (BLOCK).
• Una sandbox per il malware ha rilevato spyware (SOFTWARE_MALICIOUS) in un allegato cinque minuti dopo che il file è stato recapitato (ALLOW) all'utente nella Posta in arrivo.

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.