Informations de référence sur le schéma de normalisation DNS ASIM (Advanced Security Information Model) (version préliminaire publique)

Le modèle CIM DNS est utilisé pour décrire les événements signalés par un serveur DNS ou un système de sécurité DNS, et il est utilisé par Microsoft Sentinel pour activer l’analyse indépendante de la source.

Pour plus d’informations, consultez Normalisation et modèle ASIM (Azure Sentinel Information Model).

Vue d’ensemble du schéma

Le schéma DNS ASIM représente l’activité du protocole DNS. Les serveurs DNS et les appareils qui envoient des requêtes DNS à un serveur DNS journalisent à la fois l’activité du protocole DNS. L’activité du protocole DNS comprend les requêtes DNS, les mises à jour du serveur DNS et les transferts de données en bloc du DNS. Étant donné que le schéma représente une activité de protocole, il est régi par des RFC et des listes de paramètres officiellement attribués, qui sont référencés dans cet article, le cas échéant. Le schéma DNS ne représente pas les événements d’audit du serveur DNS.

L’activité la plus importante signalée par les serveurs DNS est une requête DNS, pour laquelle le champ EventType est défini sur Query.

Les champs les plus importants d’un événement DNS sont les suivants :

• DnsQuery, qui indique le nom de domaine pour lequel la requête a été émise.

• SrcIpAddr (avec IpAddr comme alias), qui représente l’adresse IP à partir de laquelle la requête a été générée. Les serveurs DNS fournissent généralement le champ SrcIpAddr, mais il arrive que les clients DNS ne le fournissent pas et fournissent uniquement le champ SrcHostname.

• EventResultDetails, qui indique si la requête a abouti et, dans le cas contraire, la raison de cet échec.

• Si disponible, DnsResponseName, qui contient la réponse fournie par le serveur à la requête. L’ASIM n’a pas besoin d’analyser la réponse, et son format varie selon les sources.

  Pour utiliser ce champ dans du contenu indépendant de la source, recherchez le contenu à l’aide des opérateurs has ou contains.

Les événements DNS collectés sur l’appareil du client peuvent également inclure des informations sur l’utilisateur et le processus.

Instructions pour la collecte d’événements DNS

DNS est un protocole unique en ce qu’il peut croiser un grand nombre d’ordinateurs. En outre, étant donné que DNS utilise le protocole UDP, les requêtes et les réponses sont découplées et ne sont pas directement liées les unes aux autres.

L’illustration suivante montre un flux de requête DNS simplifié, y compris quatre segments. Une requête réelle peut être plus complexe, avec plus de segments impliqués.

Étant donné que les segments de requête et de réponse ne sont pas directement connectés les uns aux autres dans le flux de requête DNS, la journalisation complète peut entraîner une duplication importante.

Le segment le plus précieux à journaliser est la réponse au client. Cette réponse fournit les requêtes de nom de domaine, le résultat de la recherche et l’adresse IP du client. Alors que de nombreux systèmes DNS consignent uniquement ce segment, il existe une valeur dans la journalisation des autres parties. Par exemple, une attaque par empoisonnement du cache DNS tire souvent parti des réponses factices d’un serveur en amont.

Si votre source de données prend en charge la journalisation DNS complète et que vous avez choisi de consigner plusieurs segments, ajustez vos requêtes pour empêcher la duplication des données dans Microsoft Sentinel.

Par exemple, vous pouvez modifier votre requête avec la normalisation suivante :

_Im_Dns | where SrcIpAddr != "127.0.0.1" and EventSubType == "response"

Analyseurs

Pour plus d’informations sur les analyseurs ASIM, consultez Vue d’ensemble des analyseurs ASIM.

Analyseurs prêts à l’emploi

Pour utiliser les analyseurs qui unifient tous les analyseurs ASIM prêts à l’emploi et faire en sorte que votre analyse s’exécute sur toutes les sources configurées, utilisez l’analyseur d’unification _Im_Dns comme nom de table dans votre requête.

Pour obtenir la liste des analyseurs DNS, Microsoft Sentinel fournit une référence prête à l’emploi à la liste des analyseurs ASIM.

Ajouter vos propres analyseurs normalisés

Lorsque vous implémentez des analyseurs personnalisés pour le modèle d’informations DNS, nommez vos fonctions KQL en utilisant le format vimDns<vendor><Product>. Reportez-vous à l’article Gestion des analyseurs ASIM pour découvrir comment ajouter vos analyseurs personnalisés aux analyseurs d’unification DNS.

Paramètres de filtrage des analyseurs

Les analyseurs DNS prennent en charge les paramètres de filtrage. Bien que ces paramètres soient facultatifs, ils peuvent améliorer les performances de vos requêtes.

Les paramètres de filtrage suivants sont disponibles :

Par exemple, pour filtrer uniquement les requêtes DNS à partir du dernier jour qui n’a pas réussi à résoudre le nom de domaine, utilisez :

_Im_Dns (responsecodename = 'NXDOMAIN', starttime = ago(1d), endtime=now())

Pour filtrer uniquement les requêtes DNS pour une liste spécifiée de noms de domaine, utilisez :

let torProxies=dynamic(["tor2web.org", "tor2web.com", "torlink.co"]);
_Im_Dns (domain_has_any = torProxies)

Certains paramètres peuvent accepter à la fois une liste de valeurs de type dynamic ou une valeur de chaîne unique. Pour transmettre une liste de littéraux aux paramètres qui attendent une valeur dynamique, utilisez explicitement un littéral dynamique. Par exemple : dynamic(['192.168.','10.'])

Contenu normalisé

Pour obtenir la liste complète des règles analytiques qui utilisent des événements DNS normalisés, consultez Contenu de sécurité des requêtes DNS.

Détails du schéma

Le modèle d’informations DNS est aligné sur le schéma d’entité DNS OSSEM.

Pour plus d’informations, consultez les informations de référence sur les paramètres DNS IANA (Internet Assigned Numbers Authority).

Champs ASIM communs

Champs communs avec des instructions spécifiques

La liste suivante mentionne uniquement les champs qui ont des instructions spécifiques pour des événements DNS :

Tous les champs communs

Les champs qui apparaissent dans le tableau ci-dessous sont communs à tous les schémas ASIM. Toute instruction spécifiée ci-dessus remplace les instructions générales pour le champ. Par exemple, un champ peut être facultatif en général, mais obligatoire pour un schéma spécifique. Pour plus d’informations sur chaque champ, consultez l’article Champs communs ASIM.

Champs Système source

Champs de l’utilisateur source

Champs de processus source

Champs du système de destination

Champs spécifiques à DNS

Champs d’inspection

Les champs suivants permettent de représenter une inspection effectuée par un appareil de sécurité DNS. Les champs associés aux menaces représentent une menace unique associée à l’adresse source, à l’adresse de destination, à l’une des adresses IP de la réponse ou au domaine de requête DNS. Si plusieurs menaces ont été identifiées, des informations concernant d’autres adresses IP peuvent être stockées dans le champ AdditionalFields.

Alias et champs dépréciés

Les champs suivants sont des alias conservés à des fins de compatibilité descendante. Ils ont été supprimés du schéma le 31 décembre 2021.

• Query (alias de DnsQuery)
• QueryType (alias de DnsQueryType)
• QueryTypeName (alias de DnsQueryTypeName)
• ResponseName (alias de DnsReasponseName)
• ResponseCodeName (alias de DnsResponseCodeName)
• ResponseCode (alias de DnsResponseCode)
• QueryClass (alias de DnsQueryClass)
• QueryClassName (alias de DnsQueryClassName)
• Flags (alias de DnsFlags)
• SrcUserDomain

Mises à jour du schéma

Les modifications apportées à la version 0.1.2 du schéma sont les suivantes :

• Ajout du champ EventSchema.
• Ajout d’un champ dédié aux indicateurs qui complète le champ combiné Indicateurs : DnsFlagsAuthoritative, DnsFlagsCheckingDisabled, DnsFlagsRecursionAvailable, DnsFlagsRecursionDesired, DnsFlagsTruncated et DnsFlagsZ.

Les modifications apportées à la version 0.1.3 du schéma sont les suivantes :

• Le schéma documente désormais explicitement les champs Src*, Dst*, Process* et User*.
• Ajout de champs Dvc* supplémentaires pour correspondre à la définition la plus récente des champs communs.
• Ajout de Src et Dst en tant qu’alias d’un identifiant principal pour les systèmes source et de destination.
• Ajout du champ facultatif DnsNetworkDuration et de Duration, son alias.
• Ajout des champs facultatifs Geo Location et Risk Level.

Voici les modifications apportées à la version 0.1.4 du schéma :

• Ajout des champs facultatifs ThreatIpAddr, ThreatField, ThreatName, ThreatConfidence, ThreatOriginalConfidence, ThreatOriginalRiskLevel, ThreatIsActive, ThreatFirstReportedTime et ThreatLastReportedTime.

Voici les modifications apportées à la version 0.1.5 du schéma :

• Ajout des champs SrcUserScope, SrcUserSessionId, SrcDvcScopeId, SrcDvcScope, DstDvcScopeId, DstDvcScope, DvcScopeId et DvcScope.

Voici les modifications apportées à la version 0.1.6 du schéma :

• Ajout des champs DnsResponseIpCountry, DnsResponseIpRegion, DnsResponseIpCity, DnsResponseIpLatitude et DnsResponseIpLongitude.

Voici les modifications apportées à la version 0.1.7 du schéma :

• Ajout des champs SrcDescription, SrcOriginalRiskLevel, DstDescription, DstOriginalRiskLevel, SrcUserScopeId, NetworkProtocolVersion, Rule, RuleName, RuleNumber et ThreatId.

Disparités propres aux sources

L’objectif de la normalisation est de veiller à ce que toutes les sources fournissent des données de télémétrie cohérentes. Une source qui ne fournit pas les données de télémétrie obligatoires, comme les champs de schéma obligatoires, ne peut pas être normalisée. En revanche, les sources qui fournissent généralement toutes les données de télémétrie obligatoires, même s’il existe des disparités, peuvent être normalisées. Les disparités peuvent affecter l’exhaustivité des résultats de requête.

Le tableau suivant liste les disparités connues :

Gestion de la réponse DNS

Dans la plupart des cas, les événements DNS consignés n’incluent pas les informations de réponse, qui peuvent être volumineuses et détaillées. Si votre enregistrement inclut plus d’informations de réponse, stockez-les dans le champ ResponseName comme elles apparaissent dans l’enregistrement.

Vous pouvez également fournir une fonction KQL supplémentaire appelée _imDNS<vendor>Response_, qui prend la réponse non analysée comme entrée et retourne une valeur dynamique avec la structure suivante :

[
    {
        "part": "answer"
        "query": "yahoo.com."
        "TTL": 1782
        "Class": "IN"
        "Type": "A"
        "Response": "74.6.231.21"
    }
    {
        "part": "authority"
        "query": "yahoo.com."
        "TTL": 113066
        "Class": "IN"
        "Type": "NS"
        "Response": "ns5.yahoo.com"
    }
    ...
]

Les champs de chaque dictionnaire dans la valeur dynamique correspondent aux champs de chaque réponse DNS. L’entrée part doit inclure answer, authority ou additional pour refléter la partie dans la réponse à laquelle le dictionnaire appartient.

Gestion des indicateurs DNS

L’analyse et la normalisation ne sont pas obligatoires pour les données d’indicateur. À la place, stockez les données d’indicateur fournies par l’appareil dans le champ Indicateurs. Si la détermination de la valeur des indicateurs individuels est directe, vous pouvez également utiliser les champs d’indicateurs dédiés.

Vous pouvez également fournir une fonction KQL supplémentaire appelée _imDNS<vendor>Flags_, qui prend la réponse non analysée, ou des champs d’indicateurs dédiés, comme entrée et retourne une liste dynamique, avec des valeurs booléennes qui représentent chaque indicateur dans l’ordre suivant :

• Authentifié (AD)
• Faisant autorité (AA)
• Vérification désactivée (CD)
• Récurrence disponible (RA)
• Récurrence souhaitée (RD)
• Tronqué (TC)
• Z

Étapes suivantes

Pour plus d'informations, consultez les pages suivantes :

• Regardez le webinaire sur ASIM ou passez en revue les diapositives
• Vue d’ensemble de l’Advanced SIEM Information Model (ASIM)
• Schémas de l’Advanced SIEM Information Model (ASIM)
• Analyseurs de l’Advanced SIEM Information Model (ASIM)
• Contenu de l’Advanced SIEM Information Model (ASIM)