Mettre en forme les données du journal au format UDM

Tous les événements de modèle de données unifiés (UDM) offrent un ensemble de champs et de messages communs que les partenaires peuvent remplir, quel que soit le type d'événement. Ces champs sont les suivants:

  • Entités: appareils, utilisateurs et processus impliqués dans un événement.
  • Métadonnées d'événement: date et heure de l'événement, type d'origine, etc.
  • Métadonnées réseau: métadonnées réseau générales pour les événements réseau, ainsi que détails du protocole dans les sous-messages :
    • Métadonnées d'e-mail: informations dans les champs "À", "Formulaire", "Cc", "Cci" et "Autres destinataires"
    • Métadonnées HTTP: méthode, URL de provenance, user-agent, etc.
  • Résultats de sécurité: toute classification ou action effectuée par un produit de sécurité.
  • Métadonnées supplémentaires: toute donnée d'événement spécifique à un fournisseur qui ne peut pas être correctement représentée dans les sections formelles du modèle UDM peut être ajoutée à l'aide d'un champ de charge utile JSON de forme libre.

Les sections suivantes décrivent comment encoder et mettre en forme les événements pour le modèle de données unifié (UDM).

Encodage UDM

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

Dans le cadre de ce document, les champs sont représentés par un point. Par exemple, la syntaxe JSON suivante:

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

Cet article est décrit 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 soit envoyé à Google, procédez comme suit:

  1. Spécifier le type d'événement : le type d'événement sélectionné détermine les champs que vous devez également inclure avec l'événement.
  2. Spécifier l'horodatage de l'événement – metadata-position="body" } : spécifiez l'horodatage de l'événement.
  3. Noms (entités) : chaque événement doit inclure au moins un nom décrivant l'appareil ou l'utilisateur participant à l'événement.
  4. Spécifier les résultats de sécurité : (facultatif) spécifiez les résultats de sécurité en fournissant des détails sur les risques et les menaces de sécurité détectés par un système de sécurité, ainsi que sur les mesures prises pour atténuer ces risques et menaces.
  5. Renseignez les autres informations sur les événements obligatoires et facultatifs à 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. Il est spécifié à l'aide de l'une des valeurs possibles pour Metadata.event_type. Il s'agit des valeurs telles que PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (pour obtenir la liste complète, consultez la page Metadata.event_type). Chaque type d'événement nécessite que vous fournissiez un ensemble de valeurs et de champs supplémentaires avec les informations liées à l'événement initial. Pour en savoir plus sur les champs à inclure pour chaque type d'événement, reportez-vous à 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 à l'aide de la notation de texte Proto3:

metadata {
    event_type: PROCESS_OPEN
}

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

Vous devez spécifier l'horodatage GMT pour tous les événements envoyés au format UDM à l'aide de Metadata.event_timestamp. L'horodatage doit être encodé selon l'une des normes suivantes:

  • Pour le format JSON, utilisez le document RFC 3339.
  • Horodatage Proto3

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

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é dans un événement UDM. Il peut s'agir, par exemple, de l'appareil ou de l'utilisateur qui effectue l'activité décrite dans un événement, ou de l'appareil ou de l'utilisateur qui est la cible de l'activité décrite dans l'événement. Les noms peuvent également correspondre à des pièces jointes ou à des URL. Enfin, un nom peut également être utilisé pour décrire un appareil 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 ou plusieurs des noms suivants doivent être spécifiés pour un événement UDM:

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

Si tous les événements se déroulent sur la même machine, celle-ci doit simplement être décrite dans la section principal. La machine n'a pas besoin d'être également décrite dans target ou src.

L'exemple suivant montre comment renseigner les champs principals:

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 nous savons sur l'appareil et l'utilisateur qui a été 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 propre au fournisseur (provenant de Sophos), qui est 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 sur l'appareil cible. Par exemple, dans une connexion de pare-feu de l'appareil A vers l'appareil B, A est décrit comme principal et B est la cible. Pour l'injection de processus par le processus C dans le processus cible D, le processus C est décrit comme le principal et le processus D est décrit comme cible.

principal et cible dans udm Principal objectif par rapport à la fonctionnalité 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, la ou les adresses IP supplémentaires, la ou les adresses MAC, les identifiants d'éléments propriétaires, etc., elles doivent également être incluses dans target.

Les termes principal et target (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, ainsi que le contexte de l'appareil ou du processus pour 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 vers le fichier B sur la machine Y, le fichier A et la machine X sont spécifiés dans la partie src de l'événement UDM.
  • intermédiaire:correspond aux détails d'un ou de plusieurs appareils de traitement intermédiaires, décrits dans l'événement. Cela inclut les détails de l'appareil sur un serveur proxy, un serveur de relais SMTP, etc.
  • Observateur:représente un appareil d'observation (par exemple, un outil de détection de failles ou d'analyse de failles basé sur les réseaux), qui n'est pas un intermédiaire direct, mais qui observe et génère des rapports sur l'événement en question.
  • à propos de: Permet de stocker les détails de tous les objets référencés par l'événement qui ne sont pas autrement décrits dansparticipant, src, cible, intermédiaire ou le ciblage parobservateur ... Par exemple, il peut servir à suivre les éléments suivants :
    • E-mails en pièces jointes
    • Domaines/URL/adresses IP intégrés à un corps d'e-mail
    • DLL chargées pendant un événement PROCESS_LAUNCH

Les sections d'entité 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. Chronicle UDM impose des exigences obligatoires pour remplir les champs Nom. Ces exigences sont décrites dans Champs obligatoires et facultatifs pour chaque type d'événement UDM. L'ensemble des champs d'entité à remplir varie en fonction du type d'événement.

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

Vous pouvez éventuellement spécifier des résultats de sécurité en renseignant les champs SecurityResult, y compris des détails sur les risques et les menaces de sécurité détectés par le système de sécurité, ainsi que les actions effectuées pour limiter ces risques et menaces. Voici quelques exemples de types d'événements de sécurité qui nécessitent l'insertion de champs SecurityResult:

  • Un proxy de sécurité des e-mails a détecté une tentative d'hameçonnage (MAIL_PHISHING) et a bloqué (BLOCK) l'e-mail.
  • Un pare-feu proxy pour la 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é les e-mails désinfectés.
  • Un système SSO a facilité la connexion (AUTH_VIOLATION) qui a été bloquée (BLOCK).
  • Un bac à sable contenant des logiciels malveillants a détecté des logiciels espions (SOFTWARE_MALICIOUS) dans une pièce jointe cinq minutes après la distribution du fichier (ALLOW) à l'utilisateur dans sa boîte de réception.