Mettre en forme les données des journaux au format UDM

Tous les événements UDM (Unified Data Model) comportent un ensemble de messages et de champs communs que les partenaires peuvent renseigner, quel que soit le type d'événement. Ces champs incluent les suivants :

• Entités: appareils, utilisateurs et processus impliqués dans un événement.
• Métadonnées de l'événement: date et heure de l'événement, type, origine, etc.
• Métadonnées réseau: métadonnées réseau de haut niveau pour les événements orientés réseau, ainsi que les détails du protocole dans les sous-messages :
  • Métadonnées des e-mails: informations contenues dans les champs "À", "De", "Cc", "Cci" et autres.
  • Métadonnées HTTP: Method, Refer_url, useragent, etc.
• Résultats de sécurité: toute classification ou action effectuée par un produit de sécurité.
• Métadonnées supplémentaires: toutes les données d'événement importantes propres au fournisseur qui ne peuvent pas être correctement représentées dans les sections officielles du modèle UDM peuvent être ajoutées à l'aide d'un champ de charge utile JSON de format libre.

Les sections suivantes décrivent comment encoder et formater des événements pour le modèle de données unifié (UDM).

Encodage UDM

Les événements UDM doivent être envoyés à Chronicle dans l'un des formats suivants:

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

Pour les besoins de ce document, les champs sont représentés par une notation à points. Par exemple, la syntaxe JSON suivante:

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

Elle est documentée comme suit:

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

Mettre en forme un événement UDM

Pour mettre en forme un événement UDM afin qu'il puisse être envoyé à Google, procédez comme suit:

1. Spécifier le type d'événement : le type d'événement que vous avez sélectionné détermine les champs que vous devez également inclure avec l'événement.
2. Spécifier l'horodatage de l'événement : spécifiez l'horodatage de l'événement.
3. Spécifier des noms (entités) : chaque événement doit inclure au moins un nom décrivant l'appareil ou l'utilisateur du participant concerné.
4. Spécification du résultat de sécurité : (facultatif) spécifiez les résultats de sécurité en incluant des détails sur les risques et les menaces détectés par un système de sécurité, ainsi que les mesures prises pour atténuer ces risques et ces menaces.
5. Remplissez les autres informations obligatoires et facultatives sur l'événement à l'aide des champs d'événement UDM.

Spécifier le type d'événement

La valeur la plus importante définie pour tout événement envoyé au format UDM est le type d'événement, spécifié à l'aide de l'une des valeurs possibles disponibles pour Metadata.event_type. Celles-ci incluent des valeurs telles que PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (pour obtenir la liste complète, consultez Metadata.event_type. Pour chaque type d'événement, vous devez également renseigner un ensemble d'autres champs et valeurs avec les informations liées à l'événement d'origine. Pour en savoir plus sur les champs à inclure pour chaque type d'événement, consultez la section Champs obligatoires et facultatifs pour chaque type d'événement UDM. L'exemple suivant montre comment spécifier PROCESS_OPEN comme type d'événement avec la notation de texte Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Spécifier l'horodatage de l'événement

Vous devez spécifier le code temporel GMT pour tout événement envoyé au format UDM à l'aide de Metadata.event_timestamp. Le tampon doit être encodé selon l'une des normes suivantes:

• Pour le format JSON, utilisez la norme RFC 3339.
• Code temporel Proto3

L'exemple suivant montre comment spécifier l'horodatage au format RFC 3339. Dans cet exemple, aaaa-mm-jjThh:mm:ss+hh:mm (année, mois, jour, heure, minute, seconde) et le décalage par rapport à l'heure UTC. Le décalage par rapport à l'UTC est de moins 8 heures, ce qui correspond au fuseau HNP.

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

Spécifier des noms (entités)

Pour chaque événement UDM, vous devez définir un ou plusieurs noms. Un nom représente un participant ou une entité à un événement UDM. Un nom peut être, par exemple, l'appareil/l'utilisateur qui effectue l'activité décrite dans un événement, ou l'appareil/l'utilisateur cible de cette activité décrite dans l'événement. Les noms peuvent aussi être des pièces jointes ou des URL. Enfin, un nom peut également être utilisé pour décrire un dispositif de sécurité qui a observé l'activité décrite dans l'événement (par exemple, un proxy de messagerie ou un routeur réseau).

Un événement UDM doit comporter un ou plusieurs des noms suivants:

principal: représente l'entité agissant ou l'appareil à l'origine de l'activité décrite dans l'événement. Le compte principal doit inclure au moins une information sur la machine (nom d'hôte, adresses MAC, adresses IP, port, identifiants spécifiques au produit comme un GUID de machine CrowdStrike) ou des informations sur l'utilisateur (par exemple, le nom de l'utilisateur), et éventuellement des détails sur le processus. Il ne doit inclure AUCUN des champs suivants: adresse e-mail, fichiers, clés ou valeurs de registre.

Si tous les événements se produisent sur la même machine, il suffit de la décrire dans l'attribut principal. La machine n'a pas besoin d'être également décrite dans target ou src.

Remarque :Un appareil de sécurité peut être à l'origine d'un événement, mais il ne sera pas décrit dans le champ "principal", mais dans le champ observateur ou intermédiaire. Si le logiciel de sécurité (Carbon Black, par exemple) s'exécute sur l'appareil à l'origine de l'activité (par exemple, un point de terminaison Windows sur lequel un logiciel malveillant a été détecté), cet appareil est également l'appareil principal.

L'exemple suivant montre comment remplir les champs principal:

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

L'exemple ci-dessus décrit tout ce que vous savez de l'appareil et de l'utilisateur qui était l'acteur principal décrit dans l'événement. Cet exemple inclut l'adresse IP et le numéro de port de l'appareil, ainsi que son nom d'hôte. Il inclut également un identifiant d'élément spécifique au fournisseur (provenant de Sophos), c'est-à-dire un identifiant unique généré par le produit de sécurité tiers.

target:représente un appareil cible référencé par l'événement ou un objet de l'appareil cible. Par exemple, dans une connexion de pare-feu entre l'appareil A et l'appareil B, A est décrit comme le compte principal et B est décrit comme la cible. Pour une injection de processus par le processus C dans le processus cible D, le processus C est décrit comme le processus principal et le processus D comme la cible.

Compte principal et cible dans UDM

L'exemple suivant montre comment les champs d'une cible sont renseignés:

target {
   ip: "198.51.100.31"
   port: 80
}

Là encore, si d'autres informations sont disponibles, telles que le nom d'hôte, les adresses IP supplémentaires, les adresses MAC, les identifiants des éléments propriétaires, etc., vous devez également les inclure dans target.

Les expressions principal et cible, ainsi que d'autres noms, peuvent faire référence à des acteurs sur la même machine. Par exemple, le processus A (principal) exécuté sur la machine X agit sur le processus B (cible) également sur la machine X.

• src::représente un objet source traité par le participant avec l'appareil ou le contexte de traitement de l'objet source (la machine où réside l'objet source). Par exemple, si l'utilisateur U copie le fichier A sur la machine X dans le fichier B sur la machine Y, les fichiers A et X sont spécifiés dans la partie src de l'événement UDM.
• intermédiaire:représente les détails d'une ou de plusieurs activités de traitement des appareils intermédiaires décrites dans l'événement. Cela inclut les informations sur l'appareil concernant un serveur proxy, un serveur de relais SMTP, etc.
• Observateur:représente un appareil observateur (par exemple, un renifleur de paquets ou un scanner de vulnérabilité basé sur le réseau), qui n'est pas un intermédiaire direct, mais qui observe l'événement en question et le signale.
• about::permet de stocker des informations sur tous les objets référencés par l'événement qui ne sont pas décrits dans about:, about:, about:, about: ou about:. Vous pouvez par exemple l'utiliser pour effectuer le suivi des éléments suivants :
  • Envoyer des pièces jointes par e-mail
  • Domaines/URL/adresses IP intégrés dans le corps d'un e-mail
  • DLL chargées lors d'un événement PROCESS_LAUNCH

Les sections d'entités des événements UDM incluent des informations sur les différents participants (appareils, utilisateurs, objets tels que les URL, les fichiers, etc.) décrits dans l'événement. Il est obligatoire de renseigner les champs de nom dans l'UDM de Chronicle. Ces exigences sont décrites dans la section Champs obligatoires et facultatifs pour chaque type d'événement UDM. L'ensemble des champs d'entité devant être renseignés varie en fonction du type d'événement.

Spécifier le résultat de sécurité

Si vous le souhaitez, vous pouvez spécifier les résultats de sécurité en renseignant les champs SecurityResult, y compris des détails sur les risques de sécurité et les menaces détectés par le système de sécurité, ainsi que les mesures prises pour atténuer ces risques et ces menaces. Voici des exemples de certains types d'événements liés à la sécurité qui nécessiteraient de renseigner des champs SecurityResult:

• Un proxy de sécurité des e-mails a détecté une tentative d'hameçonnage (MAIL_PHISHING) et a bloqué (BLOQUER) l'e-mail.
• Un pare-feu proxy de sécurité des e-mails a détecté deux pièces jointes infectées (Software_MALICIOUS) et les a mises en quarantaine et désinfectées (QUARANTINE, ALLOW_WITH_MODIFICATION), puis a transféré l'e-mail désinfecté.
• Un système SSO a facilité une connexion (AUTH_VIOLATION) qui a été bloquée (BLOCK).
• Un bac à sable pour logiciels malveillants a détecté des logiciels espions (Software_MALICIOUS) dans une pièce jointe cinq minutes après la distribution du fichier (AUTORISER) à l'utilisateur dans sa boîte de réception.