Développer des analyseurs ASIM (Advanced Security Information Model)

Les utilisateurs du modèle ASIM (Advanced Security Information Model) utilisent des analyseurs d’unification au lieu de noms de tables dans leurs requêtes, pour afficher les données dans un format normalisé et inclure toutes les données pertinentes pour le schéma dans la requête. Les analyseurs d’unification utilisent à leur tour des analyseurs spécifiques à la source pour gérer les détails spécifiques de chaque source.

Microsoft Sentinel fournit des analyseurs intégrés et spécifiques à la source pour de nombreuses sources de données. Vous pouvez modifier ou développer ces analyseurs spécifiques à la source dans les situations suivantes :

  • Lorsque votre appareil fournit des événements qui correspondent à un schéma ASIM, mais qu’un analyseur spécifique à la source pour votre appareil et le schéma approprié n’est pas disponible dans Microsoft Sentinel.

  • Lorsque des analyseurs spécifiques à la source ASIM sont disponibles pour votre appareil, mais que celui-ci envoie des événements dans une méthode ou un format différent de celui attendu par les analyseurs ASIM. Par exemple :

    • Votre appareil source peut être configuré pour envoyer des événements d’une manière non standard.

    • Votre appareil peut avoir une version différente de celle prise en charge par l’analyseur ASIM.

    • Les événements peuvent être collectés, modifiés et transférés par un système intermédiaire.

Pour comprendre comment les analyseurs s’intègrent dans l’architecture ASIM, reportez-vous au diagramme de l’architecture ASIM.

Processus de développement de l’analyseur ASIM personnalisé

Le flux de travail suivant décrit les étapes générales du développement d’un analyseur ASIM personnalisé spécifique à la source :

  1. Collectez des exemples de journaux.

  2. Identifiez les schémas ou schémas que les événements envoyés à partir de la source représentent. Pour plus d’informations, consultez Vue d’ensemble du schéma.

  3. Mappez les champs d’événement source au ou aux schémas identifiés.

  4. Développez un ou plusieurs analyseurs ASIM pour votre source. Vous devez développer un analyseur de filtrage et un analyseur sans paramètre pour chaque schéma pertinent pour la source.

  5. Testez votre analyseur.

  6. Déployez les analyseurs dans vos espaces de travail Microsoft Sentinel.

  7. Mettez à jour l’analyseur d’unification ASIM approprié pour référencer le nouvel analyseur personnalisé. Pour plus d’informations, consultez Gestion des analyseurs ASIM.

  8. Vous pouvez également contribuer à vos analyseurs à la distribution ASIM principale. Les analyseurs fournis peuvent également être mis à disposition dans tous les espaces de travail en tant qu’analyseurs intégrés.

Cet article vous guide tout au long des étapes de développement, de test et de déploiement du processus.

Conseil

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

Collecter des exemples de journaux

Pour créer des analyseurs ASIM efficaces, vous avez besoin d’un ensemble représentatif de journaux, ce qui, dans la plupart des cas, nécessite la configuration du système source et sa connexion à Microsoft Sentinel. Si vous n’avez pas l’appareil source disponible, les services cloud de paiement à l’utilisation vous permettent de déployer de nombreux appareils à des fins de développement et de test.

En outre, la recherche de la documentation du fournisseur et des exemples pour les journaux peut aider à accélérer le développement et à réduire les erreurs en garantissant une couverture large du format de journal.

Un ensemble représentatif de journaux doit inclure :

  • Événements avec des résultats d’événement différents.
  • Événements avec différentes actions de réponse.
  • Différents formats pour le nom d’utilisateur, le nom d’hôte et les ID, ainsi que d’autres champs qui nécessitent une normalisation des valeurs.

Conseil

Démarrez un nouvel analyseur personnalisé à l’aide d’un analyseur existant pour le même schéma. L’utilisation d’un analyseur existant est particulièrement importante pour filtrer les analyseurs afin de s’assurer qu’ils acceptent tous les paramètres requis par le schéma.

Planification du mappage

Avant de développer un analyseur, mappez les informations disponibles dans le ou les événements sources au schéma que vous avez identifié :

  • Mapper tous les champs obligatoires et, de préférence, les champs recommandés.
  • Essayez de mapper toutes les informations disponibles de la source aux champs normalisés. S’il n’est pas disponible dans le cadre du schéma sélectionné, envisagez de mapper aux champs disponibles dans d’autres schémas.
  • Mapper les valeurs des champs à la source aux valeurs normalisées autorisées par ASIM. La valeur d’origine est stockée dans un champ distinct, tel que EventOriginalResultDetails.

Développement d’analyseurs

Développez à la fois un filtre et un analyseur sans paramètre pour chaque schéma pertinent.

Un analyseur personnalisé est une requête KQL développée dans la page journaux Microsoft Sentinel. La requête de l’analyseur comprend trois parties :

Filtre>Parse>Préparer les champs

Filtrage

Filtrage des enregistrements pertinents

Dans de nombreux cas, une table dans Microsoft Sentinel inclut plusieurs types d’événements. Par exemple :

  • La table Syslog contient des données provenant de plusieurs sources.
  • Les tables personnalisées peuvent inclure des informations provenant d’une seule source qui fournit plusieurs types d’événements et peut s’adapter à différents schémas.

Par conséquent, un analyseur doit d’abord filtrer uniquement les enregistrements pertinents pour le schéma cible.

Le filtrage dans KQL est effectué à l’aide de l’opérateur where . Par exemple, l’événement Sysmon 1 signale la création du processus et est donc normalisé au schéma ProcessEvent . L’événement Sysmon event 1 fait partie de la Event table. Vous devez donc utiliser le filtre suivant :

Event | where Source == "Microsoft-Windows-Sysmon" and EventID == 1

Importante

Un analyseur ne doit pas filtrer par heure. La requête qui utilise l’analyseur applique un intervalle de temps.

Filtrage par type de source à l’aide d’une watchlist

Dans certains cas, l’événement lui-même ne contient pas d’informations permettant de filtrer des types sources spécifiques.

Par exemple, les événements DNS Infoblox sont envoyés en tant que messages Syslog et sont difficiles à distinguer des messages Syslog envoyés à partir d’autres sources. Dans ce cas, l’analyseur s’appuie sur une liste de sources qui définit les événements pertinents. Cette liste est conservée dans la watchlist Sources_by_SourceType .

Pour utiliser la watchlist ASimSourceType dans vos analyseurs, utilisez la _ASIM_GetSourceBySourceType fonction dans la section filtrage de l’analyseur. Par exemple, l’analyseur DNS Infoblox inclut les éléments suivants dans la section filtrage :

  | where Computer in (_ASIM_GetSourceBySourceType('InfobloxNIOS'))

Pour utiliser cet exemple dans votre analyseur :

  • Remplacez par Computer le nom du champ qui inclut les informations de source de votre source. Vous pouvez conserver cela comme Computer pour tous les analyseurs basés sur Syslog.

  • Remplacez le InfobloxNIOS jeton par une valeur de votre choix pour votre analyseur. Informez les utilisateurs de l’analyseur qu’ils doivent mettre à jour la watchlist à l’aide ASimSourceType de la valeur sélectionnée, ainsi que la liste des sources qui envoient des événements de ce type.

Filtrage basé sur les paramètres de l’analyseur

Lorsque vous développez des analyseurs de filtrage, assurez-vous que votre analyseur accepte les paramètres de filtrage pour le schéma approprié, comme indiqué dans l’article de référence pour ce schéma. L’utilisation d’un analyseur existant comme point de départ garantit que votre analyseur inclut la signature de fonction correcte. Dans la plupart des cas, le code de filtrage réel est également similaire pour les analyseurs de filtrage pour le même schéma.

Lors du filtrage, assurez-vous que vous :

  • Filtrez avant l’analyse à l’aide de champs physiques. Si les résultats filtrés ne sont pas suffisamment précis, répétez le test après l’analyse pour affiner vos résultats. Pour plus d’informations, consultez Optimisation du filtrage.
  • Ne filtrez pas si le paramètre n’est pas défini et a toujours la valeur par défaut.

Les exemples suivants montrent comment implémenter le filtrage pour un paramètre de chaîne, où la valeur par défaut est généralement « * », et pour un paramètre de liste, où la valeur par défaut est généralement une liste vide.

srcipaddr=='*' or ClientIP==srcipaddr
array_length(domain_has_any) == 0 or Name has_any (domain_has_any)

Pour plus d’informations sur les éléments suivants, consultez la documentation kusto :

Optimisation du filtrage

Pour garantir les performances de l’analyseur, notez les recommandations de filtrage suivantes :

  • Filtrez toujours sur les champs intégrés plutôt que sur les champs analysés. Bien qu’il soit parfois plus facile de filtrer à l’aide de champs analysés, cela a un impact considérable sur les performances.
  • Utilisez des opérateurs qui fournissent des performances optimisées. En particulier, ==, haset startswith. L’utilisation d’opérateurs tels que contains ou matches regex a également un impact considérable sur les performances.

Les recommandations de filtrage pour les performances peuvent ne pas toujours être faciles à suivre. Par exemple, l’utilisation de has est moins précise que contains. Dans d’autres cas, la correspondance avec le champ intégré, par SyslogMessageexemple , est moins précise que la comparaison d’un champ extrait, tel que DvcAction. Dans ce cas, nous vous recommandons de toujours préfiltrer à l’aide d’un opérateur d’optimisation des performances sur un champ intégré et de répéter le filtre en utilisant des conditions plus précises après l’analyse.

Pour obtenir un exemple, consultez l’extrait de code de l’analyseur DNS Infoblox suivant. L’analyseur vérifie d’abord que le champ has SyslogMessage contient le mot client. Toutefois, le terme peut être utilisé à un autre endroit dans le message. Par conséquent, après avoir analysé le Log_Type champ, l’analyseur vérifie à nouveau que le mot client était bien la valeur du champ.

Syslog | where ProcessName == "named" and SyslogMessage has "client"
…
      | extend Log_Type = tostring(Parser[1]),
      | where Log_Type == "client"

Remarque

Les analyseurs ne doivent pas filtrer par heure, car la requête utilisant l’analyseur filtre déjà le temps.

Analyse

Une fois que la requête sélectionne les enregistrements appropriés, il peut être nécessaire de les analyser. En règle générale, l’analyse est nécessaire si plusieurs champs d’événement sont transmis dans un seul champ de texte.

Les opérateurs KQL qui effectuent l’analyse sont répertoriés ci-dessous, classés en fonction de leur optimisation des performances. La première offre les performances les plus optimisées, tandis que la dernière fournit les performances les moins optimisées.

Operator/function() Description
fonction split() Analysez une chaîne de valeurs délimitées.
fonction parse_csv() Analysez une chaîne de valeurs au format CSV (valeurs séparées par des virgules).
opérateur parse-kv Extrait des informations structurées d’une expression de chaîne et représente les informations sous une forme clé/valeur.
opérateur d’analyse Analysez plusieurs valeurs à partir d’une chaîne arbitraire à l’aide d’un modèle, qui peut être un modèle simplifié avec de meilleures performances ou une expression régulière.
fonction extract_all() Analysez des valeurs uniques à partir d’une chaîne arbitraire à l’aide d’une expression régulière. extract_all a des performances similaires à parse si cette dernière utilise une expression régulière.
fonction extract() Extrayez une valeur unique d’une chaîne arbitraire à l’aide d’une expression régulière.

L’utilisation extract offre de meilleures performances que parse ou extract_all si une seule valeur est nécessaire. Toutefois, l’utilisation de plusieurs activations de extract sur la même chaîne source est moins efficace qu’une seule parse ou extract_all et doit être évitée.
fonction parse_json() Analysez les valeurs dans une chaîne au format JSON. Si seules quelques valeurs sont nécessaires à partir du JSON, l’utilisation parsede , extractou extract_all offre de meilleures performances.
fonction parse_xml() Analysez les valeurs dans une chaîne au format XML. Si seules quelques valeurs sont nécessaires à partir du code XML, l’utilisation parsede , extractou extract_all offre de meilleures performances.

Normalisation

Mappage des noms de champs

La forme la plus simple de normalisation consiste à renommer un champ d’origine à son nom normalisé. Utilisez l’opérateur project-rename pour cela. L’utilisation de project-rename garantit que le champ est toujours géré en tant que champ physique et que la gestion du champ est plus performante. Par exemple :

 | project-rename
    ActorUserId = InitiatingProcessAccountSid,
    ActorUserAadId = InitiatingProcessAccountObjectId,
    ActorUserUpn = InitiatingProcessAccountUpn,

Normalisation du format et du type des champs

Dans de nombreux cas, la valeur d’origine extraite doit être normalisée. Par exemple, dans ASIM, une adresse MAC utilise les deux-points comme séparateur, tandis que la source peut envoyer une adresse MAC délimitée par un trait d’union. L’opérateur principal pour la transformation des valeurs est extend, ainsi qu’un large ensemble de fonctions de chaîne KQL, numériques et de date.

En outre, il est essentiel de s’assurer que les champs de sortie de l’analyseur correspondent au type défini dans le schéma pour que les analyseurs fonctionnent. Par exemple, vous devrez peut-être convertir une chaîne représentant la date et l’heure en champ datetime. Les fonctions telles que todatetime et tohex sont utiles dans ces cas.

Par exemple, l’ID d’événement unique d’origine peut être envoyé sous forme d’entier, mais ASIM exige que la valeur soit une chaîne, pour garantir une compatibilité étendue entre les sources de données. Par conséquent, lors de l’attribution du champ source, utilisez extend et tostring au lieu de project-rename:

  | extend EventOriginalUid = tostring(ReportId),

Champs et valeurs dérivés

La valeur du champ source, une fois extraite, peut avoir besoin d’être mappée à l’ensemble de valeurs spécifié pour le champ de schéma cible. Les fonctions iff, caseet lookup peuvent être utiles pour mapper les données disponibles aux valeurs cibles.

Par exemple, l’analyseur DNS Microsoft attribue le EventResult champ en fonction de l’ID d’événement et du code de réponse à l’aide d’une iff instruction, comme suit :

   extend EventResult = iff(EventId==257 and ResponseCode==0 ,'Success','Failure')

Pour mapper plusieurs valeurs, définissez le mappage à l’aide de l’opérateur datatable et utilisez lookup pour effectuer le mappage. Par exemple, certaines sources signalent des codes de réponse DNS numériques et le protocole réseau, tandis que le schéma impose la représentation des étiquettes de texte les plus courantes pour les deux. L’exemple suivant montre comment dériver les valeurs nécessaires à l’aide de datatable et lookup:

   let NetworkProtocolLookup = datatable(Proto:real, NetworkProtocol:string)[
        6, 'TCP',
        17, 'UDP'
   ];
    let DnsResponseCodeLookup=datatable(DnsResponseCode:int,DnsResponseCodeName:string)[
      0,'NOERROR',
      1,'FORMERR',
      2,'SERVFAIL',
      3,'NXDOMAIN',
      ...
   ];
   ...
   | lookup DnsResponseCodeLookup on DnsResponseCode
   | lookup NetworkProtocolLookup on Proto

Notez que la recherche est utile et efficace également lorsque le mappage n’a que deux valeurs possibles.

Lorsque les conditions de mappage sont plus complexes, combinez iff, caseet lookup. L’exemple ci-dessous montre comment combiner lookup et case. L’exemple lookup ci-dessus retourne une valeur vide dans le champ DnsResponseCodeName si la valeur de recherche est introuvable. L’exemple case ci-dessous l’augmente en utilisant le résultat de l’opération lookup , le cas échéant, et en spécifiant des conditions supplémentaires dans le cas contraire.

   | extend DnsResponseCodeName = 
      case (
        DnsResponseCodeName != "", DnsResponseCodeName,
        DnsResponseCode between (3841 .. 4095), 'Reserved for Private Use',
        'Unassigned'
      )

Microsoft Sentinel fournit des fonctions pratiques pour les valeurs de recherche courantes. Par exemple, la DnsResponseCodeName recherche ci-dessus peut être implémentée à l’aide de l’une des fonctions suivantes :


| extend DnsResponseCodeName = _ASIM_LookupDnsResponseCode(DnsResponseCode)

| invoke _ASIM_ResolveDnsResponseCode('DnsResponseCode')

La première option accepte comme paramètre la valeur à rechercher et vous permet de choisir le champ de sortie et donc utile en tant que fonction de recherche générale. La deuxième option est plus orientée vers les analyseurs, prend comme entrée le nom du champ source et met à jour le champ ASIM nécessaire, dans ce cas DnsResponseCodeName.

Pour obtenir la liste complète des fonctions d’aide ASIM, consultez Fonctions ASIM

Champs d’enrichissement

En plus des champs disponibles à partir de la source, un événement ASIM résultant inclut des champs d’enrichissement que l’analyseur doit générer. Dans de nombreux cas, les analyseurs peuvent affecter une valeur constante aux champs, par exemple :

  | extend                  
     EventCount = int(1),
     EventProduct = 'M365 Defender for Endpoint',
     EventVendor = 'Microsoft',
     EventSchemaVersion = '0.1.0',
     EventSchema = 'ProcessEvent'

Un autre type de champs d’enrichissement que vos analyseurs doivent définir sont les champs de type, qui désignent le type de la valeur stockée dans un champ associé. Par exemple, le SrcUsernameType champ désigne le type de valeur stocké dans le SrcUsername champ. Vous trouverez plus d’informations sur les champs de type dans la description des entités.

Dans la plupart des cas, une valeur constante est également affectée aux types. Toutefois, dans certains cas, le type doit être déterminé en fonction de la valeur réelle, par exemple :

   DomainType = iif (array_length(SplitHostname) > 1, 'FQDN', '')

Microsoft Sentinel fournit des fonctions utiles pour gérer l’enrichissement. Par exemple, utilisez la fonction suivante pour affecter automatiquement les champs SrcHostname, SrcDomainet SrcFQDNSrcDomainType en fonction de la valeur dans le champ Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Cette fonction définit les champs comme suit :

Champ Ordinateur Champs de sortie
server1 SrcHostname : server1
SrcDomain, SrcDomainType, SrcFQDN tous vides
server1.microsoft.com SrcHostname : server1
SrcDomain : microsoft.com
SrcDomainType : nom de domaine complet
SrcFQDN:server1.microsoft.com

Les fonctions _ASIM_ResolveDstFQDN et _ASIM_ResolveDvcFQDN effectuent une tâche similaire qui remplit les champs et associés DstDvc . Pour obtenir la liste complète des fonctions d’aide ASIM, consultez Fonctions ASIM

Sélectionner des champs dans le jeu de résultats

L’analyseur peut éventuellement sélectionner des champs dans le jeu de résultats. La suppression de champs inutiles peut améliorer les performances et ajouter de la clarté en évitant toute confusion entre les champs normalisés et les champs sources restants.

Les opérateurs KQL suivants sont utilisés pour sélectionner des champs dans votre jeu de résultats :

Opérateur Description Quand utiliser dans un analyseur
projet-away Supprime les champs. Utilisez project-away pour les champs spécifiques que vous souhaitez supprimer du jeu de résultats. Nous vous recommandons de ne pas supprimer les champs d’origine qui ne sont pas normalisés du jeu de résultats, sauf s’ils créent une confusion ou sont très volumineux et peuvent avoir des implications sur les performances.
Projet Sélectionne les champs qui existaient auparavant ou qui ont été créés dans le cadre de l’instruction et supprime tous les autres champs. Non recommandé pour une utilisation dans un analyseur, car l’analyseur ne doit pas supprimer les autres champs qui ne sont pas normalisés.

Si vous devez supprimer des champs spécifiques, tels que des valeurs temporaires utilisées lors de l’analyse, utilisez project-away pour les supprimer des résultats.

Par exemple, lors de l’analyse d’une table de journaux personnalisée, utilisez ce qui suit pour supprimer les champs d’origine restants qui ont toujours un descripteur de type :

    | project-away
        *_d, *_s, *_b, *_g

Gérer les variantes d’analyse

Importante

Les différentes variantes représentent différents types d’événements, généralement mappés à différents schémas, développent des analyseurs distincts

Dans de nombreux cas, les événements d’un flux d’événements incluent des variantes qui nécessitent une logique d’analyse différente. Pour analyser différentes variantes dans un analyseur unique, utilisez des instructions conditionnelles telles que iff et case, ou utilisez une structure d’union.

Pour gérer union plusieurs variantes, créez une fonction distincte pour chaque variante et utilisez l’instruction union pour combiner les résultats :

let AzureFirewallNetworkRuleLogs = AzureDiagnostics
    | where Category == "AzureFirewallNetworkRule"
    | where isnotempty(msg_s);
let parseLogs = AzureFirewallNetworkRuleLogs
    | where msg_s has_any("TCP", "UDP")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        ":"                  srcPortNumber:int
    …
    | project-away msg_s;
let parseLogsWithUrls = AzureFirewallNetworkRuleLogs
    | where msg_s has_all ("Url:","ThreatIntel:")
    | parse-where
        msg_s with           networkProtocol:string 
        " request from "     srcIpAddr:string
        " to "               dstIpAddr:string
    ...
union parseLogs,  parseLogsWithUrls…

Pour éviter les événements en double et le traitement excessif, assurez-vous que chaque fonction commence par filtrer, à l’aide de champs natifs, uniquement les événements qu’elle est destinée à analyser. En outre, si nécessaire, utilisez project-away à chaque branche, avant l’union.

Déployer des analyseurs

Déployez manuellement des analyseurs en les copiant dans la page journal Azure Monitor et en enregistrant la requête en tant que fonction. Cette méthode est utile pour les tests. Pour plus d’informations, consultez Créer une fonction.

Pour déployer un grand nombre d’analyseurs, nous vous recommandons d’utiliser des modèles ARM d’analyseur, comme suit :

  1. Créez un fichier YAML basé sur le modèle approprié pour chaque schéma et incluez-y votre requête. Commencez par le modèle YAML approprié pour votre type de schéma et d’analyseur, en filtrant ou sans paramètre.

  2. Utilisez le convertisseur de modèle ASIM YAML vers ARM pour convertir votre fichier YAML en modèle ARM.

  3. Si vous déployez une mise à jour, supprimez les anciennes versions des fonctions à l’aide du portail ou de l’outil PowerShell de suppression de fonction.

  4. Déployez votre modèle à l’aide du Portail Azure ou de PowerShell.

Vous pouvez également combiner plusieurs modèles à un seul processus de déploiement à l’aide de modèles liés

Conseil

Les modèles ARM peuvent combiner différentes ressources, de sorte que les analyseurs peuvent être déployés avec des connecteurs, des règles analytiques ou des watchlists, pour ne citer que quelques options utiles. Par exemple, votre analyseur peut référencer une watchlist déployée à côté de celle-ci.

Analyseurs de test

Cette section décrit les outils de test qu’ASIM fournit qui vous permettent de tester vos analyseurs. Cela dit, les analyseurs sont du code, parfois complexes, et des pratiques d’assurance qualité standard telles que les révisions de code sont recommandées en plus des tests automatisés.

Installer les outils de test ASIM

Pour tester ASIM, déployez l’outil de test ASIM dans un espace de travail Microsoft Sentinel où :

  • Votre analyseur est déployé.
  • La table source utilisée par l’analyseur est disponible.
  • La table source utilisée par l’analyseur est remplie d’une collection variée d’événements pertinents.

Valider le schéma de sortie

Pour vous assurer que votre analyseur produit un schéma valide, utilisez le testeur de schéma ASIM en exécutant la requête suivante dans la page journaux Microsoft Sentinel :

<parser name> | getschema | invoke ASimSchemaTester('<schema>')

Gérez les résultats comme suit :

Erreur Action
Champ obligatoire manquant [<Champ>] Ajoutez le champ à votre analyseur. Dans de nombreux cas, il s’agit d’une valeur dérivée ou d’une valeur constante, et non d’un champ déjà disponible à partir de la source.
Le champ manquant [<Champ>] est obligatoire lorsque la colonne obligatoire [<Champ>] existe Ajoutez le champ à votre analyseur. Dans de nombreux cas, ce champ désigne les types de la colonne existante à laquelle il fait référence.
Le champ manquant [<Champ>] est obligatoire lorsque la colonne [<Champ>] existe Ajoutez le champ à votre analyseur. Dans de nombreux cas, ce champ désigne les types de la colonne existante à laquelle il fait référence.
Alias obligatoire [<Champ>] manquant pour l’alias de colonne existante [<Champ>] Ajouter l’alias à votre analyseur
Alias recommandé [<Champ>] manquant pour l’alias de colonne existante [<Champ>] Ajouter l’alias à votre analyseur
Alias facultatif [<Champ>] manquant pour l’alias de colonne existante [<Champ>] Ajouter l’alias à votre analyseur
Alias obligatoire manquant [<Champ>] colonne manquante d’alias [<Champ>] Cette erreur accompagne une erreur similaire pour le champ avec alias. Corrigez l’erreur de champ avec alias et ajoutez cet alias à votre analyseur.
Incompatibilité de type pour le champ [<Champ>]. Il s’agit actuellement de [<Type>] et doit être [<Type>] Assurez-vous que le type de champ normalisé est correct, généralement à l’aide d’une fonction de conversion telle que tostring.
Info Action
Champ recommandé manquant [<Champ>] Envisagez d’ajouter ce champ à votre analyseur.
Info Action
Alias recommandé [<Champ>] manquant pour la colonne inexistante d’alias [<Champ>] Si vous ajoutez le champ avec alias à l’analyseur, veillez également à ajouter cet alias.
Alias facultatif [<Champ>] manquant avec alias de colonne inexistante [<Champ>] Si vous ajoutez le champ avec alias à l’analyseur, veillez également à ajouter cet alias.
Champ facultatif manquant [<Champ>] Bien que les champs facultatifs soient souvent manquants, il est utile d’examiner la liste pour déterminer si l’un des champs facultatifs peut être mappé à partir de la source.
Champ nonnormalisé supplémentaire [<Champ>] Bien que les champs nonnormalisés soient valides, il est utile d’examiner la liste pour déterminer si l’une des valeurs nonnormalisées peut être mappée à un champ facultatif.

Remarque

Les erreurs empêchent le contenu qui utilise l’analyseur de fonctionner correctement. Les avertissements n’empêchent pas le contenu de fonctionner, mais peuvent réduire la qualité des résultats.

Valider les valeurs de sortie

Pour vous assurer que votre analyseur produit des valeurs valides, utilisez le testeur de données ASIM en exécutant la requête suivante dans la page journaux Microsoft Sentinel :

<parser name> | limit <X> | invoke ASimDataTester ('<schema>')

La spécification d’un schéma est facultative. Si aucun schéma n’est spécifié, le EventSchema champ est utilisé pour identifier le schéma auquel l’événement doit adhérer. Si un événement n’inclut pas de EventSchema champ, seuls les champs courants sont vérifiés. Si un schéma est spécifié en tant que paramètre, ce schéma sera utilisé pour tester tous les enregistrements. Cela est utile pour les analyseurs plus anciens qui ne définissent pas le EventSchema champ.

Remarque

Même si aucun schéma n’est spécifié, des parenthèses vides sont nécessaires après le nom de la fonction.

Ce test nécessite beaucoup de ressources et peut ne pas fonctionner sur l’ensemble de votre jeu de données. Définissez X sur le plus grand nombre pour lequel la requête n’expirera pas, ou définissez l’intervalle de temps pour la requête à l’aide du sélecteur d’intervalles de temps.

Gérez les résultats comme suit :

Message Action
(0) Erreur : incompatibilité de type pour la colonne [<Champ>]. Il s’agit actuellement de [<Type>] et doit être [<Type>] Assurez-vous que le type de champ normalisé est correct, généralement à l’aide d’une fonction de conversion telle que tostring.
(0) Erreur : Valeur(s) non valide(s) (jusqu’à 10 listées) pour le champ [<Champ>] de type [<Type> logique] Assurez-vous que l’analyseur mappe le champ source correct au champ de sortie. S’il est mappé correctement, mettez à jour l’analyseur pour transformer la valeur source en type, valeur ou format approprié. Reportez-vous à la liste des types logiques pour plus d’informations sur les valeurs et formats corrects pour chaque type logique.

Notez que l’outil de test répertorie uniquement un échantillon de 10 valeurs non valides.
(1) Avertissement : Valeur vide dans le champ obligatoire [<Champ>] Les champs obligatoires doivent être renseignés, pas seulement définis. Vérifiez si le champ peut être rempli à partir d’autres sources pour les enregistrements pour lesquels la source actuelle est vide.
(2) Informations : Valeur vide dans le champ recommandé [<Champ>] Les champs recommandés doivent généralement être renseignés. Vérifiez si le champ peut être rempli à partir d’autres sources pour les enregistrements pour lesquels la source actuelle est vide.
(2) Informations : valeur vide dans le champ facultatif [<Champ>] Vérifiez si le champ avec alias est obligatoire ou recommandé et, le cas échéant, s’il peut être rempli à partir d’autres sources.

La plupart des messages indiquent également le nombre d’enregistrements qui ont généré le message et leur pourcentage dans l’échantillon total. Ce pourcentage est un bon indicateur de l’importance de la question. Par exemple, pour un champ recommandé :

  • Des valeurs vides de 90 % peuvent indiquer un problème d’analyse général.
  • 25 % de valeurs vides peuvent indiquer une variante d’événement qui n’a pas été analysée correctement.
  • Une poignée de valeurs vides peut être un problème négligeable.

Remarque

Les erreurs empêchent le contenu qui utilise l’analyseur de fonctionner correctement. Les avertissements n’empêchent pas le contenu de fonctionner, mais peuvent réduire la qualité des résultats.

Analyseurs de contribution

Vous pouvez contribuer à l’analyseur à la distribution ASIM principale. S’ils sont acceptés, les analyseurs sont disponibles pour chaque client en tant qu’analyseurs intégrés ASIM.

Pour contribuer à vos analyseurs :

Documentation des avertissements acceptés

Si les avertissements répertoriés par les outils de test ASIM sont considérés comme valides pour un analyseur, documentez les avertissements acceptés dans le fichier YAML de l’analyseur à l’aide de la section Exceptions, comme indiqué dans l’exemple ci-dessous.

Exceptions:
- Field: DnsQuery 
  Warning: Invalid value
  Exception: May have values such as "1164-ms-7.1440-9fdc2aab.3b2bd806-978e-11ec-8bb3-aad815b5cd42" which are not valid domains names. Those are related to TKEY RR requests.
- Field: DnsQuery
  Warning: Empty value in mandatory field
  Exception: May be empty for requests for root servers and for requests for RR type DNSKEY

L’avertissement spécifié dans le fichier YAML doit être une forme courte du message d’avertissement identifiant de manière unique. La valeur est utilisée pour faire correspondre les messages d’avertissement lors de l’exécution de tests automatisés et les ignorer.

Instructions pour l’envoi d’exemples

Des exemples de données sont nécessaires pour résoudre les problèmes liés à l’analyseur et pour garantir que les futures mises à jour de l’analyseur sont conformes aux exemples plus anciens. Les exemples que vous envoyez doivent inclure toute variante d’événement prise en charge par l’analyseur. Assurez-vous que les exemples d’événements incluent tous les types d’événements, formats d’événements et variantes possibles, tels que les événements représentant une activité réussie et ayant échoué. Assurez-vous également que les variations dans les formats de valeur sont représentées. Par exemple, si un nom d’hôte peut être représenté sous la forme d’un nom de domaine complet ou d’un nom d’hôte simple, les exemples d’événements doivent inclure les deux formats.

Pour envoyer les exemples d’événements, procédez comme suit :

  • Dans l’écran Logs , exécutez une requête qui extrait de la table source uniquement les événements sélectionnés par l’analyseur. Par exemple, pour l’analyseur DNS Infoblox, utilisez la requête suivante :
    Syslog
    | where ProcessName == "named"
  • Exportez les résultats à l’aide de l’option Exporter vers un fichier nommé <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, Où EventProduct, EventProductet EventSchema sont les valeurs affectées par l’analyseur à ces champs.

  • Dans l’écran Logs , exécutez une requête qui génère le schéma ou la table d’entrée de l’analyseur. Par exemple, pour le même analyseur DNS Infoblox, la requête est la suivante :

    Syslog
    | getschema
  • Exportez les résultats à l’aide de l’option Exporter vers un fichier nommé <TableName>_schema.csv, où TableName est le nom de la table source utilisée par l’analyseur.

  • Incluez les deux fichiers dans votre demande de tirage dans le dossier /Sample Data/ASIM. Si le fichier existe déjà, ajoutez votre handle GitHub au nom, par exemple : <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHandle>.csv

Instructions pour la soumission des résultats des tests

Les résultats des tests sont importants pour vérifier l’exactitude de l’analyseur et comprendre toute exception signalée.

Pour soumettre les résultats de vos tests, procédez comme suit :

  • Exécutez les tests de l’analyseur et décrits dans la section tests.

  • et exportez les résultats des tests à l’aide de l’option Exporter au format CSV vers des fichiers nommés <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest.csv et <EventVendor>_<EventProduct>_<EventSchema>_DataTest.csv respectivement.

  • Incluez les deux fichiers dans votre demande de tirage dans le dossier /Parsers/ASim<schema>/Tests.

Étapes suivantes

Cet article décrit le développement d’analyseurs ASIM.

En savoir plus sur les analyseurs ASIM :

En savoir plus sur L’ASIM en général :