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, origine, etc.
• Métadonnées réseau: métadonnées réseau générales pour les événements de 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

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

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 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 le code temporel de l'événement.
3. 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.
4. Spécifier le résultat de sécurité (facultatif) : indiquez 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.
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 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 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 le code temporel GMT de 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 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 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 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 appareil de sécurité peut être à l'origine d'un événement, mais il ne sera pas décrit dans le champ principal. Il sera décrit dans les champs observateur ou intermédiaire. Si le logiciel de sécurité (par exemple, Carbon Black) s'exécute sur le même appareil à l'origine de l'activité (par exemple, un point de terminaison Windows où un logiciel malveillant a été détecté), cet appareil est é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), 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.

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 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) et 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 : 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 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/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 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 d'événements de sécurité qui nécessiteraient 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.