Mettre en forme les données des journaux en tant que UDM

Tous les événements de modèle de données unifié (UDM) disposent d'un ensemble de champs et de messages communs que les partenaires peuvent renseigner, quel que soit leur type. 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 dans les champs "À", "De", "Cc", "Cci" et d'autres champs de l'adresse e-mail.
  • Métadonnées HTTP: méthode, reference_url, user-agent, etc.
• Résultats liés à la sécurité: toute classification ou action effectuée par un produit de sécurité.
• Métadonnées supplémentaires: vous pouvez ajouter toutes les données d'événement importantes et spécifiques aux fournisseurs qui ne peuvent pas être correctement représentées dans les sections formelles du modèle UDM à l'aide d'un champ de charge utile JSON de forme libre.

Les sections suivantes décrivent comment encoder et mettre en forme des événements pour l'UDM (Unified Data Model).

Encodage UDM

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

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

Dans 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()"}
      ]
    }
  }
}

Il 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 et l'envoyer à 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 dans l'événement.
2. Spécifier l'horodatage de l'événement : spécifiez le code temporel 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 impliqué dans l'événement.
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 de sécurité détectés par un système de sécurité, ainsi que les mesures prises pour les atténuer.
5. Renseignez 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 renseigner d'autres champs et valeurs avec les informations liées à l'événement d'origine. Consultez la section Champs obligatoires et facultatifs pour chaque type d'événement UDM pour en savoir plus sur les champs à inclure pour chaque type d'événement. L'exemple suivant montre comment spécifier PROCESS_OPEN comme type d'événement avec la notation textuelle Proto3:

metadata {
    event_type: PROCESS_OPEN
}

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

Vous devez spécifier le code temporel GMT de tout événement envoyé au format UDM à l'aide de Metadata.event_timestamp. Le tampon doit être codé 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. 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'UTC est de moins 8 heures, ce qui indique l'heure normale du Pacifique.

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 qui est la 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é 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é agissante 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, adresses MAC, adresse IP, port, identifiants spécifiques au produit, comme le GUID de la machine CrowdStrike) ou des informations sur l'utilisateur (par exemple, son nom d'utilisateur). Il doit également inclure des détails sur le processus. Il ne doit PAS inclure les champs suivants: adresse e-mail, fichiers, clés ou valeurs de registre.

Si tous les événements ont lieu sur la même machine, il suffit de décrire cette machine dans la section principal. Il n'est pas nécessaire de décrire la machine dans les champs target et src.

Remarque :Un dispositif de sécurité peut générer un événement, mais il n'est pas décrit dans le champ principal, mais dans les champs observer ou intermediary. 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 sera également le principal.

L'exemple suivant montre comment renseigner 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 toutes les informations connues sur l'appareil et 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 (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 sur l'appareil cible. Par exemple, dans une connexion de pare-feu entre l'appareil A et l'appareil B, A est décrit comme compte principal et B comme 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.

Compte principal et cible dans l'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, une ou plusieurs adresses IP supplémentaires, des adresses MAC, des identifiants d'éléments propriétaires, etc., elles doivent également être incluses dans l'attribut target.

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 sur lequel le participant intervient, ainsi que le contexte de l'appareil ou du processus pour 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 vers le fichier B sur la machine Y, les fichiers A et X seront tous deux spécifiés dans la partie src de l'événement UDM.
• intermediary (intermédiaire) : représente les détails d'un ou de plusieurs appareils intermédiaires qui traitent l'activité décrite dans l'événement. Il peut s'agir d'informations sur l'appareil concernant un serveur proxy, un serveur de relais SMTP, etc.
• observer:représente un dispositif d'observation (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 et signale l'événement en question.
• about::permet de stocker des détails 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:. Par exemple, il peut être utilisé pour :
  • Pièces jointes aux e-mails
  • 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és des événements UDM incluent des informations sur les différents participants (appareils, utilisateurs, objets tels que des URL, fichiers, etc.) décrits dans l'événement. L'UDM Google Security Operations comporte des exigences obligatoires pour renseigner les champs de nom. 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é à renseigner diffère selon le type d'événement.

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

Vous pouvez éventuellement spécifier les résultats de sécurité en remplissant 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 mesures prises pour les atténuer. Voici quelques exemples d'événements de sécurité qui nécessiteraient de renseigner les champs SecurityResult:

• Un proxy de sécurité de la messagerie a détecté une tentative d'hameçonnage (MAIL_PHISHING) et a bloqué (BLOQUER) l'e-mail.
• Un pare-feu de 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) avant de transférer l'e-mail désinfecté.
• Un système SSO a facilité une connexion (AUTH_VIOLATION), qui a été bloquée (BLOCK).
• Un bac à sable a détecté un logiciel espion (SOFTWARE_MALICIOUS) dans un fichier en pièce jointe cinq minutes après la distribution du fichier (AUTORISER) à l'utilisateur dans sa boîte de réception.