Modifier le contenu pour utiliser l’Advanced SIEM Information Model (ASIM) (préversion publique)

Article
06/01/2023

Le contenu de sécurité normalisé dans Microsoft Sentinel comprend des règles analytiques, des requêtes de chasse et des classeurs qui fonctionnent avec des analyseurs de normalisation d’unification.

Vous pouvez trouver du contenu normalisé prêt à l’emploi dans les galeries et les solutions Microsoft Sentinel, créer votre propre contenu normalisé ou modifier le contenu personnalisé existant pour utiliser des données normalisées.

Cet article explique comment convertir des règles analytiques Microsoft Sentinel existantes pour utiliser des données normalisées avec l’ASIM.

Pour comprendre le fonctionnement du contenu normalisé dans l’architecture ASIM, consultez le Diagramme de l’architecture ASIM.

Conseil

Regardez également le webinaire de formation approfondie sur la normalisation des analyseurs et le contenu normalisé Microsoft Sentinel ou passez en revue les diapositives. Pour plus d’informations, consultez Étapes suivantes.

Important

ASIM n’est actuellement disponible qu’en PRÉVERSION. Les Conditions d’utilisation supplémentaires des préversions Microsoft Azure incluent des conditions légales supplémentaires qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou pas encore disponibles dans la version en disponibilité générale.

Modifier le contenu personnalisé pour utiliser la normalisation

Pour permettre à votre contenu Microsoft Sentinel personnalisé d’utiliser la normalisation :

Modifiez vos requêtes pour utiliser des analyseurs d’unification correspondant à la requête.
Modifiez les noms de champ dans votre requête pour utiliser les noms de champs du schéma normalisé.
Le cas échéant, modifiez les conditions pour utiliser les valeurs normalisées des champs de votre requête.

Exemple de normalisation des règles analytiques

Par exemple, considérons la règle d’analyse DNS Client rare observé avec un nombre de recherches DNS inversée élevé, qui fonctionne sur les événements DNS envoyés par les serveurs DNS Infoblox :

let threshold = 200;
InfobloxNIOS
| where ProcessName =~ "named" and Log_Type =~ "client"
| where isnotempty(ResponseCode)
| where ResponseCode =~ "NXDOMAIN"
| summarize count() by Client_IP, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (InfobloxNIOS
    | where ProcessName =~ "named" and Log_Type =~ "client"
    | where isnotempty(ResponseCode)
    | where ResponseCode =~ "NXDOMAIN"
    ) on Client_IP
| extend timestamp = TimeGenerated, IPCustomEntity = Client_IP

Le code suivant est la version indépendante de la source, qui utilise la normalisation pour fournir la même détection pour toutes les sources fournissant des événements de requête DNS. L’exemple suivant utilise des analyseurs ASIM intégrés :

_Im_Dns(responsecodename='NXDOMAIN')
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns(responsecodename='NXDOMAIN')) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Pour utiliser des analyseurs ASIM déployés par l’espace de travail, remplacez la première ligne par le code suivant :

imDns(responsecodename='NXDOMAIN')

Différences entre les analyseurs intégrés et les analyseurs déployés par l’espace de travail

Les deux options de l’exemple ci-dessus sont fonctionnellement identiques. La version normalisée, indépendante de la source, présente les différences suivantes :

Les analyseurs normalisés _Im_Dns et imDns sont utilisés à la place de l’analyseur Infoblox.
Les analyseurs normalisés récupèrent uniquement les événements de requête DNS. Vous n’avez donc pas besoin de vérifier le type d’événement, comme le fait where ProcessName =~ "named" and Log_Type =~ "client" dans la version Infoblox.
Le SrcIpAddr champ est utilisé à la place de Client_IP .
Le filtrage des paramètres de l’analyseur est utilisé pour ResponseCodeName et évite d’utiliser des clauses where explicites.

Notes

Outre la prise en charge d’une source DNS normalisée, la version normalisée est plus concise et plus facile à comprendre.

Si le schéma ou les analyseurs ne prennent pas en charge les paramètres de filtrage, les changements sont similaires, sauf que les conditions de filtrage de la requête d’origine sont conservées. Par exemple :

let threshold = 200;
imDns
| where isnotempty(ResponseCodeName)
| where ResponseCodeName =~ "NXDOMAIN"
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns
    | where isnotempty(ResponseCodeName)
    | where ResponseCodeName =~ "NXDOMAIN"
    ) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Étapes suivantes

Cet article présente le contenu d’ASIM (Advanced Security Information Model).

Pour plus d'informations, consultez les pages suivantes :

Partage via