Schémas du modèle ASIM (Advanced Security Information Model)

Un schéma du modèle ASIM (Advanced Security Information Model) est un ensemble de champs qui représentent une activité. L’utilisation des champs d’un schéma normalisé dans une requête garantit que la requête fonctionnera avec toutes les sources normalisées.

Pour comprendre le fonctionnement des schémas dans l’architecture ASIM, consultez le Diagramme d’architecture ASIM.

Les références de schéma présentent les champs qui composent chaque schéma. ASIM définit actuellement les schémas suivants :

Concepts de schéma

Les concepts suivants permettent de comprendre les documents de référence de schéma et d’étendre le schéma de manière normalisée dans le cas où vos données incluent des informations que le schéma ne couvre pas.

Dénomination de champs

Les noms de champs sont au cœur de chaque schéma. Les noms de champs appartiennent aux groupes suivants :

• Champs communs à tous les schémas.
• Champs spécifiques à un schéma.
• Champs qui représentent des entités, telles que des utilisateurs, qui participent au schéma. Les champs qui représentent des entités sont similaires dans tous les schémas.

Lorsque des sources ont des champs qui ne sont pas présentés dans le schéma documenté, ils sont normalisés pour maintenir la cohérence. Si les champs supplémentaires représentent une entité, ils sont normalisés en fonction des recommandations des champs d’entité. Dans le cas contraire, les schémas s’efforcent de maintenir la cohérence entre tous les schémas.

Par exemple, alors que les journaux d’activité du serveur DNS ne fournissent pas d’informations utilisateur, les journaux d’activité DNS d’un point de terminaison peuvent inclure des informations utilisateur, qui peuvent être normalisées conformément aux instructions de l’entité utilisateur. |

Types logiques de champ

Chaque champ de schéma a un type. L’espace de travail Log Analytics possède un ensemble limité de types de données. Pour cette raison, Microsoft Sentinel utilise un type logique pour de nombreux champs de schéma, ce que Log Analytics n’impose pas, mais qui est requis pour la compatibilité des schémas. Les types de champs logiques garantissent que les valeurs et les noms de champs sont cohérents entre les sources.

Pour plus d’informations, consultez Types logiques.

Classes de champ

Les champs peuvent avoir plusieurs classes, qui définissent quand les champs doivent être implémentés par un analyseur :

• Les champs obligatoires doivent apparaître dans chaque analyseur. Si votre source ne fournit pas d’informations pour cette valeur, ou si les données ne peuvent pas être ajoutées par ailleurs, elle ne prend pas en charge la plupart des éléments de contenu qui font référence au schéma normalisé.
• Les champs recommandés doivent être normalisés si disponibles. Toutefois, ils peuvent ne pas être disponibles dans toutes les sources. Tout élément de contenu qui fait référence à ce schéma normalisé doit prendre en compte la disponibilité.
• Les champs facultatifs , le cas échéant, peuvent être normalisés ou laissés sous leur forme d’origine. En règle générale, un analyseur minimal ne les normalise pas pour des raisons de performances.
• Les champs conditionnels sont obligatoires si le champ qu’ils suivent est rempli. Les champs conditionnels sont généralement utilisés pour décrire la valeur dans un autre champ. Par exemple, le champ commun DvcIdType décrit la valeur int du champ commun DvcId ; il est donc obligatoire si ce dernier est rempli.
• L’alias est un type spécial de champ conditionnel et est obligatoire si le champ alias est rempli.

Champs communs

Certains champs sont communs à tous les schémas ASIM. Chaque schéma peut ajouter des directives pour l'utilisation de certains des champs communs dans le contexte du schéma spécifique. Par exemple, les valeurs autorisées pour le champ EventType peuvent varier selon le schéma, tout comme la valeur du champ EventSchemaVersion.

Entités

Les événements évoluent autour des entités, telles que les utilisateurs, les hôtes, les processus ou les fichiers. Chaque entité peut nécessiter plusieurs champs pour la décrire. Par exemple, un hôte peut avoir un nom et une adresse IP.

Un seul enregistrement peut inclure plusieurs entités du même type, comme un hôte source et un hôte de destination.

ASIM définit la manière de décrire les entités de manière cohérente, et les entités permettent d’étendre les schémas.

Par exemple, si le schéma de session réseau n’inclut pas d’informations sur les processus, certaines sources d’événements fournissent des informations sur les processus qui peuvent être ajoutés. Pour plus d’informations, consultez Entités.

Aliases

Les alias autorisent les noms multiples pour une valeur spécifiée. Dans certains cas, les différents utilisateurs s’attendent à ce qu’un champ ait des noms différents. Par exemple, dans la terminologie DNS, il s’agit d’un champ nommé DnsQuery, alors que plus généralement, il contient un nom de domaine. L’alias Domain est pratique, car il permet à l’utilisateur d’employer les deux noms.

Dans certains cas, un alias peut prendre la valeur d’un des différents champs, selon les valeurs disponibles dans l’événement. Par exemple, l’alias Dvc peut être associé à des champs DvcFQDN, DvcId, DvcHostname, DvcIpAddr ou Event Product. Quand un alias peut avoir plusieurs valeurs, son type doit être une chaîne pour prendre en charge toutes les valeurs avec alias possibles. Par conséquent, lorsque vous attribuez une valeur à ce genre d’alias, veillez à convertir le type en chaîne à l’aide de la fonction KQL tostring.

Les tables normalisées natives n’incluent pas d’alias, car ceux-ci nécessitent la duplication du stockage de données. À la place, les analyseurs stub ajoutent les alias. Pour implémenter des alias dans les analyseurs, créez une copie de la valeur d’origine avec l’opérateur extend. |

Types logiques

Chaque champ de schéma a un type. Certains intègrent des types de Log Analytics, tels que string, int, datetime ou dynamic. D’autres champs ont un type logique qui représente la façon dont les valeurs de champ doivent être normalisées.

Entités

Les événements évoluent autour des entités, telles que les utilisateurs, les hôtes, les processus ou les fichiers. La représentation d’entité permet à plusieurs entités du même type de faire partie d’un seul enregistrement et prend en charge plusieurs attributs pour les mêmes entités.

Pour activer la fonctionnalité d’entité, la représentation d’entité présente les indications suivantes :

Pour plus d’informations sur les types d’entités spécifiques, consultez :

• Entité utilisateur
• Entité d’appareil

Exemple de mappage d’entité

Cette section utilise l'événement Windows 4624 comme exemple pour décrire comment les données de l'événement sont normalisées pour Microsoft Sentinel.

Cet événement comporte les entités suivantes :

Sur la base de ces entités, l’événement Windows 4624 est normalisé comme suit (certains champs sont facultatifs) :

Étapes suivantes

Cet article fournit une vue d’ensemble de la normalisation dans Microsoft Sentinel et ASIM.

Pour plus d'informations, consultez les pages suivantes :

• Regardez le webinaire de formation approfondie sur la normalisation des analyseurs et le contenu normalisé Microsoft Sentinel ou passez en revue les diapositives
• Vue d’ensemble du modèle ASIM (Advanced Security Information Model)
• Analyseurs du modèle ASIM (Advanced Security Information Model)
• Contenu du modèle ASIM (Advanced Security Information Model)