Développer des analyseurs ASIM (Modèle Avancé d'Information de Sécurité)

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, à leur tour, utilisent des analyseurs propres à 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 propres à la source dans les cas suivants :

  • 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 a peut-être 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 workflow suivant décrit les étapes générales de développement d’un analyseur ASIM personnalisé propre à la source :

  1. Collectez des exemples de journaux.

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

  3. Mappez les champs d’événement source 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. Deploy 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 souhaiterez peut-être aussi contribuer vos analyseurs à la distribution principale d’ASIM. Les analyseurs contributeurs 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.

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 et des exemples du fournisseur pour les journaux peut aider à accélérer le développement et à réduire les erreurs en garantissant une couverture de format de journal large.

Un ensemble représentatif de logs doit inclure :

  • Événements avec différents résultats.
  • É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 la normalisation des valeurs.

Tip

Démarrez un nouvel analyseur personnalisé à partir 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.

Cartographie de la planification

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

  • Mappez tous les champs obligatoires et de préférence également les champs recommandés.
  • Essayez de mapper toutes les informations disponibles à partir de la source aux champs normalisés. S’il n’est pas disponible dans le schéma sélectionné, envisagez de faire correspondre cet élément aux champs disponibles dans d’autres schémas.
  • Mappez les valeurs des champs de 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 Microsoft Sentinel Logs. La requête de l’analyseur a trois parties :

Filtrer>Analyser>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 source unique 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

Important

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 proprement dit ne contient pas d’informations permettant de filtrer des types de 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 depuis 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 maintenue dans la liste de suivi Sources_by_SourceType.

Pour utiliser la Watchlist ASimSourceType dans vos analyseurs, utilisez la fonction _ASIM_GetSourceBySourceType dans la section de 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 échantillon 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 jeton InfobloxNIOS par la valeur de votre choix pour votre analyseur. Informez les utilisateurs de l’analyseur qu’ils doivent mettre à jour la Watchlist ASimSourceType à l’aide de la valeur que vous avez 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

Quand vous développez des analyseurs de filtrage, vérifiez que votre analyseur accepte les paramètres de filtrage pour le schéma correspondant, comme décrit 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 comprend la signature de fonction appropriée. 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 d’analyser à 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. Même s’il est parfois plus facile de filtrer en utilisant des champs analysés, l’impact est considérable sur les performances.
  • Utilisez des opérateurs qui fournissent des performances optimisées. En particulier, ==, has et 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 optimiser les performances peuvent ne pas être toujours faciles à suivre. Par exemple, l’utilisation de has est moins précise que contains. Dans d’autres cas, faire correspondre le champ intégré, tel que SyslogMessage, est moins précis que de comparer un champ extrait, tel que DvcAction. Dans ce type de cas, nous vous recommandons de toujours préfiltrer les données avec un opérateur d’optimisation des performances sur un champ prédéfini et de répéter le filtre en utilisant des conditions plus exactes 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 SyslogMessage a (has) le mot client. Toutefois, comme le terme peut être utilisé à un autre endroit du message, après l’analyse du champ Log_Type, l’analyseur revérifie 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"

Note

Les analyseurs ne doivent pas filtrer en fonction de critères de temps, car la requête qui utilise l’analyseur le fait déjà.

Analyse syntaxique

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. Le premier offre les performances les plus optimisées, tandis que le dernier offre les performances les moins optimisées.

Opérateur/fonction() 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 les informations structurées d’une expression de chaîne, et les représente sous forme de 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 présente un niveau de performance similaire à parse si ce dernier 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 de 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’un seul parse ou extract_all et doit être évitée.
Fonction parse_json() Analyser les valeurs d’une chaîne au format JSON. Si seules quelques valeurs sont nécessaires à partir des données JSON, l’utilisation de parse, extract ou extract_all offre de meilleures performances.
Fonction parse_xml() Analyser les valeurs d’une chaîne au format XML. Si seules quelques valeurs sont nécessaires à partir des données XML, l’utilisation de parse, extract ou 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 des points-virgules 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 de valeurs est extend, en plus d’un large ensemble de fonctions KQL de chaîne, de données numériques et de date.

En outre, s’assurer que les champs de sortie de l’analyseur correspondent au type défini dans le schéma est essentiel 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é en tant qu’entier, mais ASIM exige que la valeur soit une chaîne, afin de 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, case et lookup peuvent être utiles pour mapper les données disponibles aux valeurs cibles.

Par exemple, l’analyseur DNS Microsoft attribue le champ EventResult en fonction de l’ID d’événement et du code de réponse en utilisant une instruction iff, 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, case et 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 n’est pas trouvée. L’exemple case ci-dessous l’augmente en utilisant le résultat de l’opération lookup si disponible et en spécifiant d’autres conditions 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 recherche DnsResponseCodeName 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

Outre les 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 champ SrcUsernameType désigne le type de valeur stocké dans le champ SrcUsername. Vous trouverez plus d’informations sur les champs de type dans la description des entités.

Dans la plupart des cas, les types se voient également attribuer une valeur constante. 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 champsSrcHostname, SrcDomain, SrcDomainType et SrcFQDN en fonction de la valeur du champ Computer.

  | invoke _ASIM_ResolveSrcFQDN('Computer')

Cette fonction définit les champs comme suit :

Domaine de l'informatique 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 en remplissant les champs Dst et Dvc associés. 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 l’utiliser dans un analyseur syntaxique
project-away Supprime des champs. Utilisez project-away pour des 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 déjà 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 les valeurs temporaires utilisées pendant 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 comportent encore un descripteur de type :

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

Gérer les variantes d’analyse

Important

Les différentes variantes représentent différents types d’événements, généralement mappés à des schémas différents; développer 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 seul analyseur, utilisez des instructions conditionnelles telles que iff et case, ou utilisez une structure d’union.

Pour utiliser union pour gérer plusieurs variantes, créez une fonction distincte pour chaque variante et utilisez l’instruction d’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 vise à analyser. En outre, si nécessaire, utilisez project-away à chaque branche, avant l’union.

Déployer des analyseurs

Déployez manuellement les 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 effectuer des 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, de la façon suivante :

  1. Créez un fichier YAML basé sur le modèle correspondant à chaque schéma et ajoutez-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 PowerShell.

Vous pouvez également combiner plusieurs modèles dans un même processus de déploiement en utilisant des modèles liés

Tip

Comme les modèles ARM peuvent comprendre des ressources différentes, des analyseurs peuvent être déployés avec des connecteurs, des règles analytiques ou des listes de surveillance, pour ne citer que quelques options utiles. Par exemple, votre analyseur peut référencer une liste de surveillance déployée parallèlement.

Parseurs de test

Cette section décrit les outils de test que fournit ASIM et 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 Microsoft Sentinel Logs :

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

Traitez les résultats de la façon suivante :

Error 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 dans 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 indique 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 indique les types de la colonne existante à laquelle il fait référence.
Alias obligatoire manquant [<Champ>] pour la colonne existante [<Champ>] Ajouter l’alias à votre analyseur syntaxique
Alias recommandé manquant [<Champ>] servant d’alias pour la colonne existante [<Champ>] Ajouter l’alias à votre analyseur syntaxique
Alias optionnel manquant [<Champ>] servant d’alias pour la colonne existante [<Champ>] Ajouter l’alias à votre analyseur syntaxique
Alias obligatoire manquant [<Champ>] servant d’alias pour la colonne existante [<Champ>] Cette erreur est accompagnée d’une erreur similaire pour le champ avec alias. Corrigez l’erreur du 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>] Vérifiez que le type de champ normalisé est correct, généralement en utilisant une fonction de conversion comme tostring.
Informations Action
Champ recommandé manquant [<Champ>] Envisagez d’ajouter ce champ à votre analyseur.
Informations Action
Alias recommandé manquant [<Champ>] servant d’alias pour une colonne non-existante [<Champ>] Si vous ajoutez le champ avec alias à l’analyseur, veillez à ajouter également cet alias.
Alias facultatif manquant [<Champ>] servant d’alias pour la colonne non-existante [<Champ>] Si vous ajoutez le champ avec alias à l’analyseur, veillez à ajouter également 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 non normalisé 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.

Note

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

Valider les valeurs de sortie

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

<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 champ EventSchema est utilisé pour identifier le schéma auquel l’événement doit se conformer. Si un événement n’inclut pas de EventSchema champ, seuls les champs communs 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 anciens analyseurs qui ne définissent pas le champ EventSchema.

Note

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 une valeur maximale pour X afin que la requête n’expire pas, ou définissez l’intervalle de temps de la requête à partir du sélecteur d’intervalle de temps.

Traitez les résultats de la façon suivante :

Message Action
(0) Erreur : incompatibilité de type pour la colonne [<Champ>]. Il s’agit actuellement de [<Type>] et doit être [<Type>] Vérifiez que le type de champ normalisé est correct, généralement en utilisant une fonction de conversion comme tostring.
(0) Erreur : Valeur(s) non valide(s) (jusqu’à 10 listées) pour le champ [<Champ>] de type [<Type> logique] Vérifiez que l’analyseur mappe le champ source approprié au champ de sortie. Si le mappage est correct, 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 liste uniquement un échantillon de 10 valeurs non valides.
(1) Avertissement : Valeur vide dans le champ obligatoire [<Champ>] Les champs obligatoires doivent être remplis, 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 du problème. 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.

Note

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

Faire contribuer les analyseurs

Vous souhaiterez peut-être faire contribuer l’analyseur à la distribution ASIM principale. Si cela est accepté, les analyseurs seront disponibles pour chaque client en tant qu’analyseurs intégrés ASIM.

Pour soumettre vos analyseurs syntaxiques :

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 courte forme du message d’avertissement, permettant de l'identifier 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

Les données d’échantillons sont nécessaires lors de la résolution des problèmes de l’analyseur et pour garantir que les futures mises à jour de l’analyseur sont conformes aux échantillons plus anciens. Les échantillons que vous envoyez doivent inclure toute variante d’événement prise en charge par l’analyseur. Assurez-vous que les échantillons d’événements incluent tous les types d’événements possibles, les formats d’événements et les variations, tels que les événements représentant une activité réussie ou 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 échantillons 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 extraira 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 au format CSV dans un fichier nommé <EventVendor>_<EventProduct>_<EventSchema>_IngestedLogs.csv, où EventProduct, EventProduct et EventSchema sont les valeurs attribuées par l’analyseur à ces champs.

  • Dans l’écran Logs, exécutez une requête qui générera 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 CSV dans un fichier nommé <TableName>_schema.csv, où TableName correspond au 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 de 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 décrits dans la section testings.

  • 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.

Contenu connexe

En savoir plus sur les analyseurs ASIM :

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

  • Last updated on