Gérer les faux positifs dans Microsoft Azure Sentinel

Les règles d’analyse de Microsoft Sentinel vous avertissent lorsque quelque chose de suspect se produit sur votre réseau. Aucune règle analytique n’est parfaite et il est possible que vous receviez des faux positifs qu’il vous faudra gérer. Cet article explique comment gérer les faux positifs à l’aide de l’automatisation ou en modifiant les règles analytiques planifiées.

Causes et prévention des faux positifs

Même en présence d’une règle analytique correctement créée, les faux positifs proviennent souvent d’entités spécifiques telles que des utilisateurs ou adresses IP qui devraient en être exclus.

Scénarios courants :

• Les activités normales de certains utilisateurs, généralement les principaux de service, présentent un modèle qui semble suspect.
• L’activité d’analyse de sécurité intentionnelle 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 non privées.

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

• Les règles d’automatisation créent des exceptions sans modifier les règles analytiques.
• Les modifications planifiées des règles analytiques autorisent 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	Peuvent s’appliquer à plusieurs règles analytiques. Conservent une piste d’audit. Les exceptions ferment immédiatement et automatiquement les incidents créés, en enregistrant le motif de la fermeture et les commentaires. Sont souvent générées par des analystes. Autorisent l’application d’exceptions pendant une période limitée. Par exemple, le travail de maintenance peut déclencher des faux positifs qui, en dehors de la période de maintenance, constitueraient de véritables incidents.
Modifications des règles analytiques	Autorisent les expressions booléennes avancées et les exceptions basées sur le sous-réseau. Vous permettent d’utiliser des watchlists pour centraliser la gestion des exceptions. Nécessitent généralement une implémentation par des ingénieurs du centre d’opérations de sécurité (SOC). Constituent la solution la plus souple et la plus complète en matière de faux positifs, mais se révèlent plus complexes.

Ajouter des exceptions à l’aide de règles d’automatisation

La façon la plus simple d’ajouter une exception consiste à Ajouter une règle d’automatisation lorsque vous constatez un incident de faux positif.

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. Sélectionnez Créer une règle d’automatisation.

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

4. Sous Conditions, vous pouvez ajouter plusieurs noms de règles analytiques auxquelles appliquer l’exception. Sélectionnez la zone déroulante contenant le nom de règle analytique et sélectionnez plus de règles analytiques dans la liste.

5. La barre latérale présente les entités spécifiques de l’incident susceptible d’avoir provoqué 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 à appliquer à un sous-réseau entier.

   

6. Une fois satisfait des conditions, vous pouvez continuer à définir ce que fait la règle :

   

   • La règle est déjà configurée pour fermer un incident répondant aux critères de l’exception.
   • Vous pouvez conserver la raison de fermeture spécifiée comme elle est, ou vous pouvez la modifier si une autre raison est plus appropriée.
   • Vous pouvez ajouter un commentaire à l’incident automatiquement fermé expliquant l’exception. Par exemple, vous pouvez indiquer que l’incident est lié à une activité administrative connue.
   • Par défaut, la règle est configurée 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. Pour une exception plus longue, définissez Expiration de la règle sur une période ultérieure.

7. Vous pouvez ajouter des actions supplémentaires si vous le souhaitez. Par exemple, vous pouvez ajouter une étiquette à l’incident ou 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.

Conseil

Vous pouvez également créer une règle d’automatisation de zéro, sans utiliser d’incident. Sélectionnez Automatisation dans le menu de navigation gauche de Microsoft Sentinel, puis Créer>Ajouter une nouvelle règle. En savoir plus sur les règles d’automatisation.

Ajouter des exceptions en modifiant les règles analytiques

Pour implémenter des exceptions, une autre option consiste à modifier la requête de règle 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 modifier des règles d’analyse existantes, sélectionnez Automatisation dans le menu de navigation gauche de Microsoft Sentinel. Sélectionnez la règle que vous souhaitez modifier, puis Modifier en bas à droite pour ouvrir l'Assistant règles analytiques.

Pour obtenir des instructions détaillées sur l’utilisation de l’Assistant Règles analytiques afin de créer et de modifier des règles analytiques, consultez Créer des règles analytiques personnalisées pour détecter des 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>') près du 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 ne se limite pas aux adresses IP. Vous pouvez exclure des utilisateurs spécifiques à l’aide du champ UserPrincipalName ou des applications spécifiques à l’aide de AppDisplayName.

Vous pouvez également exclure plusieurs attributs. Par exemple, pour exclure les alertes de l’adresse IP 10.0.0.8 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 affinée, 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 s’affichent dans la même alerte :

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

Exclure sous-réseaux

L’exclusion des plages d’adresses IP utilisées par une organisation implique l’exclusion du 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 ligne where isempty(network) effectue 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 est davantage conforme aux meilleures pratiques SOC.
• La même watchlist peut s’appliquer à plusieurs règles, activant ainsi la gestion centralisée des exceptions.

L’utilisation d’une watchlist s’apparente à 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édents, vous pouvez remplacer la définition des sous-réseaux datatable par une watchlist :

let subnets = _GetWatchlist('subnetallowlist');

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

Les applications Solution Microsoft Sentinel pour SAP® fournissent des fonctions que vous pouvez utiliser pour exclure des utilisateurs ou des systèmes du déclenchement d’alertes.

• Exclure des utilisateurs. Utilisez la fonction SAPUsersGetVIP pour :

  • Appeler les étiquettes des utilisateurs que vous souhaitez exclure du déclenchement d’alertes. Étiqueter les utilisateurs dans la liste de suivi SAP_User_Config en utilisant des astérisques (*) comme caractères génériques pour étiqueter tous les utilisateurs avec une syntaxe de nommage spécifiée.
  • Lister les rôles SAP spécifiques et/ou les profils que vous souhaitez exclure du déclenchement d’alertes.

• Exclure des systèmes. Utilisez des fonctions qui prennent en charge le paramètre SelectedSystemRoles pour déterminer que seuls des types spécifiques de systèmes 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 Informations de référence sur les données des applications Solution Microsoft Sentinel pour SAP®.

Contenu connexe

Pour plus d’informations, consultez l’article suivant :

• 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’analytique personnalisées pour détecter des menaces
• Utiliser les listes de surveillance Microsoft Sentinel