Cette page a été traduite par l'API Cloud Translation.

Mettre en forme les données de journal sous forme d'UDM

Compatible avec:

Google SecOps SIEM

Tous les événements UDM (Unified Data Model) disposent d'un ensemble de champs et de messages 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 de l'événement, 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 des détails sur le protocole dans les sous-messages :
- Métadonnées de l'e-mail: informations figurant dans les champs "À", "De", "Cc", "Cci" et d'autres champs de l'e-mail.
- Métadonnées HTTP: méthode, referral_url, 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: vous pouvez ajouter des données d'événement importantes spécifiques au fournisseur qui ne peuvent pas être représentées de manière adéquate dans les sections formelles du modèle UDM à l'aide d'un champ de charge utile JSON de format libre.

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

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

Pour les besoins de ce document, les champs sont représentés à l'aide d'une notation par points. 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 de le préparer à l'envoi à Google, procédez comme suit:

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.
Spécifier l'horodatage de l'événement : spécifiez l'horodatage de l'événement.
Spécifier des noms (entités) : chaque événement doit inclure au moins un nom qui décrit un appareil ou un utilisateur participant à l'événement.
Spécifier le résultat de sécurité (facultatif) : spécifiez les résultats de sécurité en incluant des informations sur les risques et menaces de sécurité détectés par un système de sécurité, ainsi que les mesures prises pour atténuer ces risques et menaces.
Renseignez le reste des 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 pour Metadata.event_type. Il peut s'agir de 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 associées à l'événement d'origine. Pour en savoir plus sur les champs à inclure pour chaque type d'événement UDM, 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 à l'aide de la notation textuelle 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 code temporel doit être encodé à l'aide de l'une des normes suivantes:

Pour le format JSON, utilisez la 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 décalage par rapport à l'heure UTC. Le décalage par rapport à l'UTC est de moins huit 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é 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/l'utilisateur qui est la cible de cette activité décrite dans l'événement. Les noms peuvent également ê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é agissante ou l'appareil à l'origine de l'activité décrite dans l'événement. Le 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 d'utilisateur (par exemple, le nom de l'utilisateur), et peut inclure des détails sur le processus. Elle ne doit PAS inclure les champs suivants: adresse e-mail, fichiers, clés de registre ou valeurs.

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

L'exemple suivant montre comment les champs principal peuvent être renseignés:

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 l'on sait sur l'appareil et l'utilisateur qui était l'acteur principal de 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), 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 entre l'appareil A et l'appareil B, l'appareil A est décrit comme le principal et l'appareil B 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 et cible dans udm

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
}

Encore une fois, si d'autres informations sont disponibles, telles que le nom d'hôte, une ou plusieurs adresses IP, une ou plusieurs adresses MAC, des identifiants d'éléments propriétaires, etc., elles doivent également être incluses dans target.

principal et target (ainsi que d'autres noms) peuvent tous deux 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 agit, ainsi que le contexte de l'appareil ou du processus pour l'objet source (la machine sur laquelle l'objet source réside). 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 tous deux spécifiés dans la partie src de l'événement UDM.
intermediary:représente les détails d'un ou de plusieurs appareils intermédiaires qui traitent l'activité décrite dans l'événement. Cela inclut les informations sur l'appareil concernant un serveur proxy, un serveur de relais SMTP, etc.
observer:représente un dispositif d'observation (par exemple, un analyseur de paquets ou un analyseur de vulnérabilités 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 informations sur tous les objets référencés par l'événement qui ne sont pas décrits dans participant, src, target, intermediary ou observer. Par exemple, vous pouvez l'utiliser pour suivre les éléments suivants :
- Pièces jointes aux e-mails
- Domaines/URL/Adresses IP intégrés au 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 des URL, des fichiers, etc.) décrits dans l'événement. L'UDM Google Security Operations comporte des exigences obligatoires pour renseigner les champs Noun. 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 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 remplissant les champs SecurityResult, y compris des informations sur les risques et menaces de sécurité détectés par le système de sécurité, ainsi que les mesures prises pour atténuer ces risques et menaces. Voici quelques exemples de types d'événements de sécurité qui nécessitent de renseigner les 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 de sécurité des e-mails a détecté deux pièces jointes infectées (SOFTWARE_MALICIOUS), puis les a placées en quarantaine et désinfectées (QUARANTINE, ALLOW_WITH_MODIFICATION). Il a ensuite 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 de logiciels malveillants a détecté un logiciel espion (SOFTWARE_MALICIOUS) dans une pièce jointe cinq minutes après que le fichier a été distribué (ALLOW) à l'utilisateur dans sa boîte de réception.