Développer des analyseurs de l’Advanced SIEM Information Model (ASIM) (préversion publique)

Les utilisateurs de l’Advanced SIEM Information Model (ASIM) utilisent des analyseurs d’unification plutôt que des noms de tableaux dans leurs requêtes afin de voir les données dans un format normalisé et d’ajouter toutes les données pertinentes au 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 prédéfinis propres à la source pour de nombreuses sources de données. Vous pouvez modifier ou développer ces analyseurs propres à la source dans les cas suivants :

• Quand votre appareil fournit des événements qui correspondent à un schéma ASIM, mais qu’un analyseur propre à la source pour votre appareil et le schéma approprié ne sont pas disponibles dans Microsoft Sentinel.

• Quand des analyseurs ASIM propres à la source sont disponibles pour votre appareil, mais que votre appareil envoie des événements dans une méthode ou un format différent de ceux attendus par les analyseurs ASIM. Par exemple :

  • Votre appareil source est peut-être configuré pour envoyer des événements de 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 sont peut-être collectés, modifiés et transférés par un système intermédiaire.

Pour comprendre le fonctionnement des analyseurs dans l’architecture ASIM, consultez le Diagramme d’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 les schémas, y compris ceux représentés par les événements envoyés par la source. Pour plus d’informations, consultez la Vue d’ensemble des schémas.

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. 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 faire contribuer vos analyseurs à la distribution ASIM principale. Les analyseurs qui contribuent 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 de paiement à l’utilisation cloud vous permettent de déployer de nombreux appareils pour le développement et les tests.

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 journaux doit inclure :

• Événements avec différents résultats d’événement.
• É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.

Mappage de 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. Si cela n’est pas disponible dans le cadre du schéma sélectionné, envisagez de mapper les 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 analyseur de filtrage et sans paramètre pour chaque schéma approprié.

Un analyseur personnalisé est une requête KQL développée dans la page Journaux de Microsoft Sentinel. 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 comprend 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 en KQL s’effectue à l’aide de l’opérateur where. Par exemple, Sysmon event 1 rapporte la création du processus et doit donc être normalisé dans le schéma ProcessEvent. Comme l’événement Sysmon event 1 fait partie de la table Event, vous utilisez le filtre suivant :

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

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 conservée dans la Watchlist 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 comprend les éléments suivants dans la section de filtrage :

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

Pour utiliser cet échantillon dans votre analyseur :

• Remplacez Computer par le nom du champ qui contient les informations sources de votre source. Vous pouvez le conserver 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 identique aussi pour les analyseurs de filtrage du même schéma.

Lors du filtrage, assurez-vous de :

• 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 possède 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)

Optimisation du filtrage

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

• Filtrez toujours les données sur des champs prédéfinis plutôt que sur des 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, le fait de faire correspondre le champ intégré, tel SyslogMessage, est moins précis que la comparaison d’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 d’analyseur Infoblox DNS 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"

Analyse

Une fois que la requête sélectionne les enregistrements appropriés, elle peut être amenée à 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 listés ci-dessous, classés par 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	Description
split	Analyse une chaîne de valeurs délimitées.
parse_csv	Analyser une chaîne de valeurs au format CSV (valeurs séparées par des virgules).
parse-kv	Extrait les informations structurées d’une expression de chaîne, et les représente sous forme de clé/valeur.
parse	Analyser plusieurs valeurs à partir d’une chaîne arbitraire avec un modèle, qui peut être un modèle simplifié offrant de meilleures performances ou une expression régulière.
extract_all	Analyser des valeurs uniques à partir d’une chaîne arbitraire avec une expression régulière. extract_all présente un niveau de performance similaire à parse si ce dernier utilise une expression régulière.
extract	Extraire une valeur unique à partir d’une chaîne arbitraire avec 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.
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.
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 types de champs

La forme la plus simple de normalisation consiste à renommer un champ d’origine en son nom normalisé. Utilisez l’opérateur project-rename pour cela. L’utilisation du changement de nom de projet 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 pouvez être amené à convertir une chaîne représentant la date et l’heure en un champ DateHeure. 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’affectation du champ source, utilisez extend et tostring, et non project-rename :

  | extend EventOriginalUid = tostring(ReportId),

Champs et valeurs dérivés

La valeur du champ source, une fois extraite, peut devoir ê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, par conséquent, utile comme 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, reportez-vous aux 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 :

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 Dst et Dvcassociés. Pour obtenir la liste complète des fonctions d’aide ASIM, reportez-vous aux 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 améliorer la clarté en évitant la 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	Utilisation dans un analyseur
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.
project	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 ce dernier 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 ont toujours un descripteur de type :

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

Gérer les variantes d’analyse

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 des analyseurs manuellement en les copiant dans la page Journal d’Azure Monitor et en enregistrant la demande 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 correspondant à votre schéma et votre type d’analyseur, filtrage ou omission de paramètre.

2. Utilisez le convertisseur de fichier YAML ASIM en modèle 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 en utilisant le 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

Tester les analyseurs

Cette section décrit que les outils de test fournis par ASIM pour tester vos analyseurs. Cela dit, les analyseurs sont du code, parfois complexe, 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 sur 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 avec une collection variée d’événements pertinents.

Valider le schéma de sortie

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

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

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

Erreur	Action
Champ obligatoire manquant [<Field>]	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 [<Champs>] servant d’alias pour la colonne existante [<Champ>]	Ajouter l’alias à votre analyseur
Alias recommandé manquant [<Champ>] servant d’alias pour la colonne existante [<Champ>]	Ajouter l’alias à votre analyseur
Alias optionnel manquant [<Champ>] servant d’alias pour la colonne existante [<Champ>]	Ajouter l’alias à votre analyseur
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>]. It is currently [<Type>] and should be [<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>]	Ajoutez 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, passez en revue la liste pour déterminer si un des champs facultatifs peut être mappé à partir de la source.
Champ non normalisé supplémentaire [<Champ>]	Bien que les champs non normalisés soient valides, passez en revue la liste pour déterminer si une des valeurs non normalisées peut être mappée à un champ facultatif.

Valider les valeurs de sortie

Pour que votre analyseur produise des valeurs valides, utilisez le testeur de données ASIM en exécutant la requête suivante dans la page Journaux de 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 champ EventSchema est utilisé pour identifier le schéma auquel l’événement doit se conformer. Si un événement ne comporte pas de champ EventSchema, seuls les champs communs sont vérifiés. Si un schéma est spécifié en tant que paramètre, ce schéma est utilisé pour tester tous les enregistrements. Cela est utile pour les anciens analyseurs qui ne définissent pas le champ EventSchema.

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) Error: type mismatch for column [<Field>]. It is currently [<Type>] and should be [<Type>]	Vérifiez que le type de champ normalisé est correct, généralement en utilisant une fonction de conversion comme tostring.
(0) Error: Invalid value(s) (up to 10 listed) for field [<Field>] of type [<Logical Type>]	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é. Consultez la liste des types logiques pour plus d’informations sur les valeurs et formats correspondant à 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 remplis. 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.

De nombreux messages signalent également le nombre d’enregistrements qui ont généré le message et leur pourcentage de l’échantillon total. Ce pourcentage est un bon indicateur de l’importance du problème. Par exemple, pour un champ recommandé :

• Les valeurs vides de 90 % peuvent indiquer un problème d’analyse général.
• Les valeurs vides de 25 % 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.

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 faire contribuer vos analyseurs :

• Développez à la fois un analyseur de filtrage et un analyseur sans paramètre.
• Créez un fichier YAML pour l’analyseur, comme décrit dans Déploiement des analyseurs ci-dessus.
• Assurez-vous que vos analyseurs réussissent tous les tests sans erreur. Si des avertissements sont laissés, documentez-les dans le fichier YAML de l’analyseur.
• Créez une demande de tirage sur le référentiel GitHub Microsoft Sentinel , incluant :
  • Fichiers YAML de vos analyseurs dans les dossiers de l’analyseur ASIM (/Parsers/ASim<schema>/Parsers)
  • Représentation des données d’échantillon conformément aux instructions de soumission d’échantillons.
  • Résultats des tests conformément aux instructions de soumission des résultats de test.

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 tests automatisés et les ignorer.

Instructions pour la soumission d’échantillons

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 échantillons 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 au format CSV dans 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 descripteur GitHub au nom, par exemple : <EventVendor>_<EventProduct>_<EventSchema>_SchemaTest_<GitHubHanlde>.csv

Instructions de soumission des résultats de test

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

Pour envoyer vos résultats de test, 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 dans 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 traite du développement d’analyseurs ASIM.

En savoir plus sur les analyseurs ASIM :

• Vue d’ensemble des analyseurs ASIM
• Utiliser des analyseurs ASIM
• Gérer les analyseurs ASIM
• Liste des analyseurs ASIM

En savoir plus sur le modèle ASIM en général :

• 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 de l’Advanced SIEM Information Model (ASIM)
• Schémas de l’Advanced SIEM Information Model (ASIM)
• Contenu de l’Advanced SIEM Information Model (ASIM)