Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Mettre en forme les données des journaux en UDM

Tous les événements UDM (Unified Data Model) comportent un ensemble de champs et de messages communs que les partenaires peuvent renseigner, 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 de l'événement, provenance, etc.
  • Métadonnées réseau: métadonnées de réseau générales pour les événements axés sur le réseau, ainsi que les détails du protocole dans les sous-messages :
    • Métadonnées des e-mails : informations contenues dans les champs "À", "Formulaire", "Cc", "Cci" et autres.
    • Métadonnées HTTP: méthode, URL du site référent, 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: toutes les données d'événements importantes propres à un fournisseur qui ne peuvent pas être représentées de manière adéquate dans les sections formelles du modèle UDM peuvent être ajoutées à l'aide d'un champ de charge utile JSON à forme libre.

Les sections suivantes expliquent 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 dans l'un des formats suivants:

Pour les besoins 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()"}
      ]
    }
  }
}

est documenté 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 prêt à être 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 à l'événement.
  2. Spécifier l'horodatage de l'événement-metadata-position\">
  3. Spécifier des 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 le 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 de sécurité détectés par un système de sécurité, ainsi que les mesures prises pour limiter ces risques et menaces.
  5. Remplissez les autres informations obligatoires et facultatives à l'aide des champs d'événement UDM.

Spécifier le type d'événement

La valeur la plus importante définie pour un é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. Il s'agit de valeurs telles que PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (Pour obtenir la liste complète, consultez la section 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 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 l'horodatage GMT pour tout événement envoyé au format UDM à l'aide de Metadata.event_timestamp. Le cache doit être encodé selon l'une des normes suivantes:

  • Pour JSON, utilisez la RFC 3339.
  • Horodatage Proto3

L'exemple suivant montre comment spécifier l'horodatage au format RFC 3339. Dans cet exemple, il s'agit de 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 moins huit heures, ce qui correspond à l'heure normale du Pacifique (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. Un nom peut être, par exemple, l'appareil/l'utilisateur qui effectue l'activité décrite dans un événement, ou l'appareil/utilisateur qui est la cible de l'activité décrite dans l'événement. Les noms peuvent également être utilisés comme pièces jointes ou URL. Enfin, un nom peut également être utilisé pour décrire un dispositif de sécurité ayant 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é qui agit ou l'appareil à l'origine de l'activité décrite dans l'événement. Le compte principal doit inclure au moins un détail de machine (nom d'hôte, adresses MAC, adresses IP, port, identifiants spécifiques au produit comme un GUID de machine CrowdStrike) ou des détails de l'utilisateur (par exemple, le nom d'utilisateur), et éventuellement des détails de processus. Il ne doit inclure AUCUN des champs suivants : "email", "files", "registre" ou "values".

Si tous les événements ont lieu sur la même machine, il ne doit être décrit que dans l'élément principal. La machine n'a pas besoin d'être décrite dans target ou dans src.

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 qui est connu 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 comprend également un identifiant d'élément spécifique 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 à l'appareil B, A est décrit comme le 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 principal et le processus D comme la cible.

principal vs cible dans udm

Différence entre le principal et la 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 des informations supplémentaires sont disponibles, telles que le nom d'hôte, la ou les adresses IP supplémentaires, les adresses MAC, les identifiants d'éléments propriétaires, etc., elles doivent également être incluses dans target.

Les champs 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 (target) également sur la machine X.

  • src:représente un objet source faisant l'objet d'une action de la part du participant, ainsi que le contexte de l'appareil ou du processus de l'objet source (la machine sur laquelle se trouve 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, le fichier A et la machine X seront tous deux spécifiés dans la partie src de l'événement UDM.
  • Intermédiaire:correspond aux 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 concernant l'appareil concernant le serveur proxy, le serveur de relais SMTP, etc.
  • Observateur:représente un appareil observateur (par exemple un outil de détection de paquets ou un outil d'analyse des failles basé sur le réseau), qui n'est pas un intermédiaire direct, mais qui observe l'événement en question et génère des rapports sur cet événement.
  • about : sert à stocker des informations sur tous les objets référencés par l'événement qui ne sont pas autrement décrits dans participant, src, target, intermédiaire ou observateur. Par exemple, il peut servir à effectuer le suivi des éléments suivants :
    • Pièces jointes
    • Domaines/URL/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é 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. L'UDM Chronicle a des exigences obligatoires pour remplir les champs Noun. Ces exigences sont décrites dans Champs obligatoires et facultatifs pour chaque type d'événement UDM. L'ensemble des champs d'entité à remplir diffère selon le 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 les détails des risques de sécurité détectés par le système de sécurité et les mesures prises pour limiter ces risques et menaces. Vous trouverez ci-dessous quelques exemples d'événements de 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é (BLOCK).
  • 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). Il a ensuite transféré l'e-mail infecté.
  • Un système SSO a facilité la connexion (AUTH_VIOLATION) qui a été bloquée (BLOCK).
  • Un bac à sable de détection de logiciels malveillants (SOFTWARE_MALICIOUS) a été détecté dans une pièce jointe de cinq minutes après que le fichier a été distribué (ALLOW) à l'utilisateur dans sa boîte de réception.