Formatta i dati di log come UDM

Supportato in:

Google SecOps SIEM

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 i seguenti:

• Entità: i dispositivi, gli utenti e i processi coinvolti in un evento.
• Metadati dell'evento: la data e l'ora in cui si è verificato l'evento, il tipo, la sua provenienza 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 di sicurezza: qualsiasi classificazione o azione eseguita da un prodotto di 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 il modello di dati unificato (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 del presente 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()"}
      ]
    }
  }
}

Sia 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 dei nomi (entità): ogni evento deve includere almeno un nome che descriva un dispositivo o un utente partecipante coinvolto nell'evento.
4. Specifica del risultato di sicurezza: (Facoltativo) specifica i risultati di sicurezza includendo dettagli su rischi e 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 obbligatorie e facoltative sull'evento utilizzando i campi dell'evento UDM.

Specifica del 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 è necessario compilare anche un insieme di altri campi e valori con le informazioni legate all'evento originale. Consulta la sezione Campi obbligatori e facoltativi per ogni tipo di evento UDM per maggiori dettagli sui campi da includere per ogni tipo di evento. L'esempio seguente mostra come specificare PROCESS_OPEN come tipo di evento utilizzando la notazione di testo Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Specifica del timestamp 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 spiega come specificare il timestamp utilizzando il formato RFC 3339. In questo esempio, aaaa-mm-ggThh:mm:ss+hh:mm—anno, mese, giorno, ora, minuto, secondo e la differenza rispetto al fuso orario 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 dei 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 nome può essere, ad esempio, il dispositivo/utente che esegue l'attività descritta in un evento o il dispositivo/utente che è il target di tale 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).

Per un evento UDM devono essere specificati uno o più dei seguenti nomi:

principal: rappresenta l'entità che agisce o il dispositivo che genera l'attività descritta nell'evento. L'entità 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 utente (ad esempio il nome utente) e, facoltativamente, includere dettagli sul processo. NON deve includere nessuno dei seguenti campi: email, file, chiavi di registro o valori.

Se tutti gli eventi si verificano sulla stessa macchina, questa deve essere descritta solo in principal. Non è necessario che la macchina sia anche descritta in target o in src.

Nota: un dispositivo di sicurezza potrebbe dare origine a un evento, ma non verrebbe descritto nel campo principal; verrà descritto nei campi observer 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 il 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" }
}

L'esempio riportato sopra descrive tutto ciò che è noto sul dispositivo e sull'utente che era l'attore principale descritto nell'evento. Questo esempio include l'indirizzo IP e il numero di porta del dispositivo, nonché il relativo nome host. Include inoltre un identificatore di risorse specifico del fornitore (di Sophos), ovvero un identificatore 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 processo di iniezione mediante il processo C nel processo D target, il processo C è descritto come principale, mentre il processo D è descritto come obiettivo.

Entità 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, come nome host, indirizzi IP aggiuntivi, indirizzi MAC, identificatori asset di proprietà e così via, queste ultime dovrebbero essere incluse anche nel campo target.

Sia principal che target (nonché altri sostantivi) possono fare riferimento ad attori sulla stessa macchina. Ad esempio, il processo A (entità) 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 su rete), che non è un intermediario diretto, ma osserva e segnala l'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 utilizzato per monitorare quanto segue:
  • Allegati di file email
  • Domini/URL/IP incorporati nel corpo di un'email
  • DLL caricate durante un evento PROCESS_LAUNCH

Le sezioni relative alle 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 prevede requisiti obbligatori per la compilazione dei campi dei nomi. 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.

Specificare il risultato sulla 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 alcuni tipi di eventi di sicurezza che richiederebbero la compilazione dei campi SecurityResult:

• Un proxy di sicurezza dell'email ha rilevato un tentativo di phishing (MAIL_PHISHING) e ha bloccato (BLOCCA) 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.