Gérer les faux positifs dans Microsoft Sentinel

Importante

Les détections personnalisées constituent désormais le meilleur moyen de créer de nouvelles règles dans Microsoft Sentinel Microsoft Defender XDR SIEM. Les détections personnalisées vous permettent de réduire les coûts d’ingestion, d’obtenir des détections en temps réel illimitées et de bénéficier d’une intégration transparente avec Defender XDR données, fonctions et actions de correction avec le mappage automatique d’entités. Pour plus d’informations, consultez ce blog.

Microsoft Sentinel règles d’analyse vous avertissent lorsqu’un événement suspect se produit dans votre réseau. Aucune règle d’analyse n’est parfaite, et vous êtes obligé d’obtenir des faux positifs qui doivent être gérés. Cet article explique comment gérer les faux positifs, soit à l’aide de l’automatisation, soit en modifiant des règles d’analyse planifiées.

Causes et prévention des faux positifs

Même dans une règle d’analyse correctement générée, les faux positifs proviennent souvent d’entités spécifiques telles que des utilisateurs ou des adresses IP qui doivent être exclues de la règle.

Les scénarios courants sont les suivants :

• Les activités normales de certains utilisateurs, généralement des principaux de service, présentent un modèle qui semble suspect.
• Une activité intentionnelle d’analyse de la sécurité provenant d’adresses IP connues est détectée comme malveillante.
• Une règle qui exclut les adresses IP privées doit également exclure certaines adresses IP internes qui ne sont pas privées.

Cet article décrit deux méthodes pour éviter les faux positifs :

• Les règles d’automatisation créent des exceptions sans modifier les règles d’analyse.
• Les modifications des règles d’analyse planifiées permettent des exceptions plus détaillées et permanentes.

Le tableau suivant décrit les caractéristiques de chaque méthode :

Méthode	Caractéristique
Règles d’automatisation	Peut s’appliquer à plusieurs règles d’analyse. Conservez une piste d’audit. Les exceptions ferment immédiatement et automatiquement les incidents créés, en enregistrant la raison de la fermeture et les commentaires. Sont souvent générés par les analystes. Autorisez l’application d’exceptions pendant une durée limitée. Par exemple, le travail de maintenance peut déclencher des faux positifs qui, en dehors de la période de maintenance, seraient de vrais incidents.
Modifications des règles d’analyse	Autorisez les expressions booléennes avancées et les exceptions basées sur les sous-réseaux. Vous permet d’utiliser des watchlists pour centraliser la gestion des exceptions. Nécessite généralement l’implémentation par les ingénieurs SOC (Security Operations Center). Sont la solution de faux positifs la plus flexible et complète, mais sont plus complexes.

Ajouter des exceptions avec des règles d’automatisation (Portail Azure uniquement)

Cette procédure explique comment ajouter une règle d’automatisation lorsque vous voyez un incident de faux positif. Cette procédure est prise en charge dans la Portail Azure uniquement.

Si Microsoft Sentinel est intégré au portail Defender, créez des règles d’automatisation à partir de zéro en fonction des détails de votre incident. Pour plus d’informations, consultez Automatiser la réponse aux menaces dans Microsoft Sentinel avec des règles d’automatisation.

Pour ajouter une règle d’automatisation afin de gérer un faux positif :

1. Dans Microsoft Sentinel, sous Incidents, sélectionnez l’incident pour lequel vous souhaitez créer une exception.

2. Dans le volet détails de l’incident sur le côté, sélectionnez Actions > Créer une règle d’automatisation.

3. Dans la barre latérale Créer une règle d’automatisation , modifiez éventuellement le nom de la nouvelle règle pour identifier l’exception, plutôt que simplement le nom de la règle d’alerte.

4. Sous Conditions, ajoutez éventuellement d’autres noms de règle Analyticsà appliquer à l’exception. Sélectionnez la zone de liste déroulante contenant le nom de la règle d’analyse, puis sélectionnez d’autres règles d’analyse dans la liste.

5. La barre latérale présente les entités spécifiques dans l’incident actuel qui ont pu provoquer le faux positif. Conservez les suggestions automatiques ou modifiez-les pour affiner l’exception. Par exemple, vous pouvez modifier une condition sur une adresse IP pour qu’elle s’applique à l’ensemble d’un sous-réseau.

   

6. Une fois que vous êtes satisfait des conditions, faites défiler vers le bas dans le volet latéral pour continuer à définir ce que fait la règle :

   

   • La règle est déjà configurée pour fermer un incident qui répond aux critères d’exception.
   • Vous pouvez conserver le motif de fermeture spécifié tel qu’il est, ou vous pouvez le modifier si une autre raison est plus appropriée.
   • Vous pouvez ajouter un commentaire à l’incident fermé automatiquement qui explique l’exception. Par exemple, vous pouvez spécifier que l’incident provient d’une activité administrative connue.
   • Par défaut, la règle est définie pour expirer automatiquement après 24 heures. Cette expiration peut correspondre à ce que vous souhaitez et réduit le risque d’erreurs de faux négatifs. Si vous souhaitez une exception plus longue, définissez expiration de la règle sur une date ultérieure.

7. Vous pouvez ajouter d’autres actions si vous le souhaitez. Par exemple, vous pouvez ajouter une balise à l’incident, ou vous pouvez exécuter un playbook pour envoyer un e-mail ou une notification ou pour effectuer une synchronisation avec un système externe.

8. Sélectionnez Appliquer pour activer l’exception.

Ajouter des exceptions en modifiant les règles d’analyse

Une autre option pour implémenter des exceptions consiste à modifier la requête de règle d’analyse. Vous pouvez inclure des exceptions directement dans la règle ou, de préférence, si possible, utiliser une référence à une watchlist. Vous pouvez ensuite gérer la liste d’exceptions dans la watchlist.

Modifier la requête

Pour modifier les règles d’analyse existantes, sélectionnez Automation dans le menu de navigation Microsoft Sentinel gauche. Sélectionnez la règle que vous souhaitez modifier, puis sélectionnez Modifier en bas à droite pour ouvrir l’Assistant Règles d’analyse.

Pour obtenir des instructions détaillées sur l’utilisation de l’Assistant Règles d’analyse pour créer et modifier des règles d’analyse, consultez Créer des règles d’analyse personnalisées pour détecter les menaces.

Pour implémenter une exception dans un préambule de règle classique, vous pouvez ajouter une condition comme where IPAddress !in ('<ip addresses>') au début de la requête de règle. Cette ligne exclut des adresses IP spécifiques de la règle.

let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in ('10.0.0.8', '192.168.12.1')
...

Ce type d’exception n’est pas limité aux adresses IP. Vous pouvez exclure des utilisateurs spécifiques à l’aide du UserPrincipalName champ ou exclure des applications spécifiques à l’aide de AppDisplayName.

Vous pouvez également exclure plusieurs attributs. Par exemple, pour exclure les alertes de l’adresse 10.0.0.8 IP ou de l’utilisateur user@microsoft.com, utilisez :

| where IPAddress !in ('10.0.0.8')
| where UserPrincipalName != 'user@microsoft.com'

Pour implémenter une exception plus fine, le cas échéant, et réduire le risque de faux négatifs, vous pouvez combiner des attributs. L’exception suivante s’applique uniquement si les deux valeurs apparaissent dans la même alerte :

| where IPAddress != '10.0.0.8' and UserPrincipalName != 'user@microsoft.com'

Exclure des sous-réseaux

L’exclusion des plages d’adresses IP utilisées par un organization nécessite l’exclusion de sous-réseau. L’exemple suivant montre comment exclure des sous-réseaux.

L’opérateur ipv4_lookup est un opérateur d’enrichissement, et non un opérateur de filtrage. La where isempty(network) ligne effectue en fait le filtrage, en inspectant les événements qui n’affichent pas de correspondance.

let subnets = datatable(network:string) [ "111.68.128.0/17", "5.8.0.0/19", ...];
let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| evaluate ipv4_lookup(subnets, IPAddress, network, return_unmatched = true)
| where isempty(network)
...

Utiliser des watchlists pour gérer les exceptions

Vous pouvez utiliser une watchlist pour gérer la liste des exceptions en dehors de la règle elle-même. Le cas échéant, cette solution présente les avantages suivants :

• Un analyste peut ajouter des exceptions sans modifier la règle, ce qui suit mieux les meilleures pratiques soc.
• La même watchlist peut s’appliquer à plusieurs règles, ce qui permet une gestion centralisée des exceptions.

L’utilisation d’une watchlist est similaire à l’utilisation d’une exception directe. Utilisez _GetWatchlist('<watchlist name>') pour appeler la watchlist :

let timeFrame = 1d;
let logonDiff = 10m;
let allowlist = (_GetWatchlist('ipallowlist') | project IPAddress);
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in (allowlist)
...

Vous pouvez également effectuer un filtrage de sous-réseau à l’aide d’une watchlist. Par exemple, dans le code d’exclusion des sous-réseaux précédent, vous pouvez remplacer la définition des datatable sous-réseaux par une watchlist :

let subnets = _GetWatchlist('subnetallowlist');

Pour plus d’informations sur les éléments suivants utilisés dans les exemples précédents, consultez la documentation Kusto :

• let , instruction
• where, opérateur
• opérateur de projet
• opérateur datatable
• evaluate , opérateur de plug-in
• ago() , fonction
• isempty() , fonction
• plug-in ipv4_lookup

Pour plus d’informations sur KQL, consultez vue d’ensemble de Langage de requête Kusto (KQL).

Autres ressources :

• Informations de référence rapides sur KQL
• ressources d’apprentissage Langage de requête Kusto

Exemple : Gérer les exceptions pour la solution Microsoft Sentinel pour les applications SAP®

La solution Microsoft Sentinel pour les applications SAP® fournit des fonctions que vous pouvez utiliser pour exclure les utilisateurs ou les systèmes du déclenchement d’alertes.

• Exclure les utilisateurs. Utilisez la fonction SAPUsersGetVIP pour :

  • Étiquettes d’appel pour les utilisateurs que vous souhaitez exclure du déclenchement d’alertes. Étiquetez les utilisateurs de la watchlist SAP_User_Config , en utilisant des astérisque (*) comme caractères génériques pour étiqueter tous les utilisateurs avec une syntaxe de nommage spécifiée.
  • Répertoriez les rôles et/ou profils SAP spécifiques que vous souhaitez exclure du déclenchement d’alertes.

• Excluez les systèmes. Utilisez des fonctions qui prennent en charge le paramètre SelectedSystemRoles pour déterminer que seuls des types de systèmes spécifiques déclenchent des alertes, y compris uniquement les systèmes de production , uniquement les systèmes UAT , ou les deux.

Pour plus d’informations, consultez Microsoft Sentinel solution pour les informations de référence sur les données des applications SAP®.

Contenu connexe

Pour plus d’informations, reportez-vous aux rubriques suivantes :

• Utiliser les données UEBA pour analyser les faux positifs
• Automatiser la gestion des incidents dans Microsoft Sentinel avec des règles d’automatisation
• Créer des règles d’analyse personnalisées pour détecter les menaces
• Utiliser Microsoft Sentinel watchlists