Formatta i dati di log come UDM

Tutti gli eventi UDM (Unified Data Model) 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 e dettagli di protocollo all'interno dei messaggi secondari:
  • Metadati email: informazioni nei campi A, Da, Cc, Ccn e altri campi email.
  • Metadati HTTP: metodo, referral_url, useragent e così via.
• Risultati per la sicurezza: qualsiasi classificazione o azione eseguita da un prodotto di sicurezza.
• Metadati aggiuntivi: tutti i dati sugli eventi importanti specifici del fornitore che non possono essere rappresentati in modo adeguato all'interno delle sezioni formali del modello UDM possono essere aggiunti utilizzando un campo di payload json in formato libero.

Le seguenti sezioni 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 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()"}
      ]
    }
  }
}

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 e renderlo pronto per l'invio a Google, devi completare i seguenti passaggi:

1. Specificare il tipo di evento: il tipo di evento selezionato determina quali campi devi includere anche 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 di un partecipante coinvolto nell'evento.
4. Specifica del risultato per la sicurezza: (facoltativo) specifica i risultati relativi alla sicurezza includendo dettagli sui rischi e sulle minacce per la sicurezza rilevati da un sistema di sicurezza, nonché le azioni intraprese per mitigare tali rischi e minacce.
5. Compila il resto delle informazioni obbligatorie e facoltative sull'evento utilizzando i campi dell'evento UDM.

Specificare 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. Includono valori come PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS e così via (per l'elenco completo, vedi 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 spiega come specificare PROCESS_OPEN come tipo di evento utilizzando la notazione di testo Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Specificare 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 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. La differenza rispetto al fuso orario UTC è meno 8 ore, che indica PST.

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

Specificare i nomi (entità)

Per ogni evento UDM, devi definire uno o più sostantivi. Un nome rappresenta un partecipante o un'entità 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 anche essere 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 ha dato origine all'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, è necessario descrivere questa macchina solo in entità. Non è necessario che la macchina sia anche descritta in target o in src.

Nota :un dispositivo di sicurezza potrebbe generare un evento, ma non verrebbe descritto nel campo principal, ma nel campo 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 potrebbero essere compilati i campi dell'entità:

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

L'esempio precedente descrive tutto ciò che è noto sul dispositivo e sull'utente che è stato 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 target a cui fa riferimento l'evento oppure un oggetto sul dispositivo di destinazione. Ad esempio, in una connessione firewall dal dispositivo A al dispositivo B, A è descritto come entità 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 di una destinazione:

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 (così come altri nomi) 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 agisce, 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, verranno specificati entrambi i file nella parte src dell'evento UDM.
• intermediario: rappresenta i dettagli su uno o più dispositivi intermedi attività di elaborazione descritte nell'evento. Sono inclusi i dettagli dei dispositivi 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 archiviare i dettagli di tutti gli oggetti a cui fa riferimento l'evento che non sono altrimenti descritti in participant, src, target, intermediary o observer. Ad esempio, potrebbe essere utilizzato 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 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 entità che devono essere compilati varia in base al tipo di evento.

Specificare il risultato sulla sicurezza

Facoltativamente, puoi specificare i risultati relativi alla sicurezza compilando i campi SecurityResult, inclusi i dettagli sui rischi e le minacce per la sicurezza rilevati dal sistema di sicurezza, nonché le azioni intraprese per mitigare tali 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 di sicurezza e-mail ha rilevato due allegati infetti (SOFTWARE_MALICIOUS) e ha messo in quarantena e disinfettato (QUARANTINE, ALLOW_WITH_MODIFICATION) questi allegati e quindi ha inoltrato l’e-mail disinfettata.
• Un sistema SSO ha facilitato l'accesso (AUTH_VIOLATION) che è stato bloccato (BLOCK).
• Una sandbox malware ha rilevato spyware (SOFTWARE_MALICIOUS) in un file allegato cinque minuti dopo la consegna del file (ALLOW) all’utente nella sua posta in arrivo.