Gérer les faux positifs dans Microsoft Sentinel

Important

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 Les détections personnalisées constituent désormais l’expérience unifiée pour créer des détections dans Microsoft Defender XDR.

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 les principaux de service (identités automatisées utilisées par les applications et services), montrent un schéma 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 un historique d’audit. Les exceptions clôturent immédiatement et automatiquement les incidents créés, en consignant le motif de clôture 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). Constituent la solution la plus flexible et la plus complète pour les faux positifs, mais sont plus complexes.

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

La procédure suivante décrit comment ajouter une règle d’automatisation lorsque vous constatez un 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 conditions suggérées 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. Cet expiration correspond peut-être à vos attentes et réduit les risques 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 requêtes des règles analytiques

Vous pouvez aussi mettre en place des exceptions en modifiant la requête des règles d’analytique. 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 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 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 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 une organisation nécessite l’exclusion de sous-réseaux. 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 réellement le filtrage, en conservant uniquement les événements dont l’adresse IP ne correspond à aucune entrée de sous-réseau.

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 est davantage conforme aux 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 opérateurs et fonctions Kusto utilisés dans les exemples de requêtes d’exception, consultez la documentation Kusto :

• let instruction
• opérateur où
• opérateur de projet
• opérateur table de données
• Opérateur de plug-in evaluate
• ago() , fonction
• fonction isempty()
• 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 du langage Kusto Query Language

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. Identifiez les utilisateurs dans la liste de surveillance SAP_User_Config, en utilisant des astérisques (*) comme caractères génériques pour identifier tous les utilisateurs correspondant à 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