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 completare indipendentemente dal tipo di evento. Questi campi includono:

• Entità: i dispositivi, gli utenti e i processi coinvolti in un evento.
• Metadati dell'evento: quando si è verificato l'evento, il tipo, la sua provenienza e così via.
• Metadati di rete: metadati di rete di alto livello per gli eventi orientati alla rete e dettagli del protocollo all'interno dei messaggi secondari:
  • Metadati dell'email: informazioni nei campi A, Da, Cc, Ccn e altri campi dell'email.
  • Metadati HTTP: Method, referral_url, useragent, ecc.
• Risultati relativi alla sicurezza: qualsiasi classificazione o azione eseguita da un prodotto di sicurezza.
• Metadati aggiuntivi: tutti i dati importanti sugli eventi specifici del fornitore che non possono essere adeguatamente rappresentati all'interno delle sezioni formali del modello UDM possono essere aggiunti utilizzando un campo 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 Chronicle in 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 in 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 che sia 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 del timestamp dell'evento: specifica il timestamp dell'evento.
3. Specifica dei nomi (entità): ogni evento deve includere almeno un nome che descriva il dispositivo o l'utente del partecipante coinvolto nell'evento.
4. Specifica del risultato per la sicurezza: (facoltativo) specifica i risultati relativi alla sicurezza includendo dettagli sui rischi e le minacce alla sicurezza rilevati da un sistema di sicurezza e sulle 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.

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. Questi includono valori quali PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS e così via. Per l'elenco completo, vedi Metadata.event_type. Ogni tipo di evento richiede la compilazione di un insieme di altri campi e valori con le informazioni associate all'evento originale. Per informazioni dettagliate su quali campi includere per ogni tipo di evento, consulta Campi obbligatori e facoltativi per ogni tipo di evento UDM. L'esempio seguente illustra come specificare PROCESS_OPEN come tipo di evento utilizzando la notazione del 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 bollino deve essere codificato utilizzando uno dei seguenti standard:

• Per JSON, utilizza RFC 3339
• Timestamp Proto3

Il seguente esempio 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 la differenza rispetto all'ora UTC. Lo scarto con 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 una persona giuridica in un evento UDM. Un nome potrebbe essere, ad esempio, il dispositivo/utente che esegue l'attività descritta in un evento oppure il dispositivo/utente target dell'attività descritta nell'evento. I sostantivi possono essere anche allegati o URL. Infine, i sostantivi possono essere utilizzati anche per descrivere un dispositivo di sicurezza che ha rilevato l'attività descritta nell'evento, ad esempio un proxy email o un router di rete.

In un evento UDM devono essere specificati uno o più dei seguenti sostantivi:

principal: rappresenta l'entità interessata o il dispositivo che ha origine l'attività descritta nell'evento. L'entità deve includere almeno un dettaglio della macchina (nome host, MAC, IP, porta, identificatori specifici del prodotto come il GUID della macchina CrowdStrike) o un dettaglio utente (ad esempio, nome utente) e, facoltativamente, includere i dettagli del 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 descritta anche in target o src.

Nota: un dispositivo di sicurezza potrebbe generare un evento, ma non verrebbe descritto nel campo dell'entità; lo sarebbe invece nel campo osservatore o intermediario. Se il software di sicurezza (ad esempio Carbon Black) viene eseguito sullo stesso dispositivo che ha originato l'attività (ad esempio un endpoint Windows in cui è stato rilevato un malware), quel dispositivo sarebbe anche l'entità.

L'esempio seguente illustra come compilare 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 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 nome host. Include inoltre un identificatore di asset 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 l'evento fa riferimento oppure un oggetto sul dispositivo di destinazione. Ad esempio, in una connessione firewall dal dispositivo A al dispositivo B, A viene descritto come entità e B come destinazione. Per un processo di inserimento mediante il processo C nel processo di destinazione D, il processo C è descritto come il principio e il processo D come il target.

Entità contro target in UDM

L'esempio seguente illustra come vengono compilati i campi di 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, anche questi dovrebbero essere inclusi nel target.

Sia principal che target (così come altri sostantivi) possono fare riferimento agli 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 utilizzato dal partecipante 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 sul computer X nel file B sulla macchina Y, nella parte src dell'evento UDM verranno specificati sia il file A che la macchina X.
• intermediario: rappresenta i dettagli relativi a uno o più dispositivi intermedi che elaborano l'attività descritta nell'evento. Sono inclusi i dettagli del dispositivo relativi a server proxy, server di inoltro SMTP e così via.
• osservatore:rappresenta un dispositivo osservatore (ad esempio, uno sniffer di pacchetti o uno scanner delle vulnerabilità basato su rete), che non è un intermediario diretto, ma che osserva e segnala l'evento in questione.
• about: viene utilizzato per archiviare i dettagli di tutti gli oggetti a cui fa riferimento l'evento che non sono altrimenti descritti in partecipante, src, target, intermediario o osservatore. Ad esempio, potrebbero essere utilizzati per monitorare quanto segue:
  • File allegati 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 Chronicle ha requisiti obbligatori per il completamento dei campi Nomi. Questi requisiti sono descritti in Campi obbligatori e facoltativi per ogni tipo di evento UDM. L'insieme di campi dell'entità che devono essere compilati varia in base al tipo di evento.

Specifica del risultato relativo alla 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 e sulle azioni intraprese per mitigare tali rischi e minacce. Di seguito sono riportati alcuni esempi di alcuni tipi di eventi di sicurezza che richiedono la compilazione dei campi SecurityResult:

• Un proxy di sicurezza per la posta ha rilevato un tentativo di phishing (MAIL_PHISHING) e ha bloccato (BLOCK) l'email.
• Un firewall del proxy di sicurezza per le email ha rilevato due allegati infetti (SOFTWARE_MALICIOUS) e ha messo in quarantena e disinfettati (QUARANTINE, ALLOW_WITH_MODIFICATION) questi allegati, quindi ha inoltrato l'email disinfettata.
• Un sistema SSO ha facilitato un 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 posta in arrivo.