> ## Documentation Index > Fetch the complete documentation index at: https://docs.wirespeed.co/llms.txt > Use this file to discover all available pages before exploring further. # Présentation des exclusions > Clôturez automatiquement des détections grâce à des exclusions créées par Ask Wirespeed et affinées par vos soins > [!WARNING] > > Les exclusions sont une fonctionnalité très puissante qui, bien utilisée, peut ramener votre taux de faux positifs à zéro. Mal configurées, en revanche, elles peuvent masquer des détections importantes et critiques. Ask Wirespeed rédige pour vous la règle sûre la plus restrictive, et l’équipe Wirespeed est toujours disponible pour vous aider à revoir vos exclusions avant leur déploiement. Une exclusion clôture automatiquement une détection qui correspond à sa requête. Les requêtes suivent un format simple `property=value`, combinent les expressions avec `AND` ou `OR`, et vous pouvez entourer des groupes de conditions de parenthèses pour contrôler la priorité. Un exemple simple est `category=IDENTITY__LOGIN AND prevented=true`, qui clôture automatiquement les dossiers de connexion déjà bloqués par le système source. ## Créer avec Ask Wirespeed Pour créer une exclusion, utilisez la compétence `/exclusion` et laissez Ask Wirespeed la rédiger pour vous. Partout où vous pouvez créer une exclusion — **Paramètres → Exclusions**, un dossier, une détection ou un actif —, vous trouverez un bouton **Créer avec Ask Wirespeed** (ou **Ask Wirespeed**) qui ouvre le chat avec le processus d’exclusion déjà chargé et le contexte pertinent prérempli. Décrivez en langage courant ce pour quoi vous ne souhaitez plus recevoir d’alertes. L’agent procède alors ainsi : * **Il lit les éléments réels.** Il examine le dossier ou la détection sélectionné(e) et construit la requête uniquement à partir des valeurs de champ qui y figurent réellement — jamais d’e-mails, d’hôtes, d’IP, de hachages ou d’emplacements inventés. * **Il limite la portée à la règle sûre la plus restrictive.** Il privilégie plusieurs contraintes indépendantes reliées par `AND` (catégorie exacte, compte spécifique, terminal, réseau/emplacement, commande de processus ou hachage de fichier) afin que la règle couvre le schéma bénin visé sans masquer de vrais positifs. * **Il tient compte de la période.** Il détermine si l’activité est limitée dans le temps (test d’intrusion, déplacement, fenêtre de maintenance ou de migration) ou s’il s’agit d’un schéma récurrent, et définit un [TTL](#ttl) approprié pour que les autorisations temporaires expirent d’elles-mêmes. * **Il pose une question en cas de doute.** Si la portée ou la durée est ambiguë — ou si vous demandez quelque chose de plus large que ce que les éléments justifient —, il pose une seule question ciblée (souvent sous forme de choix à sélectionner) plutôt que de deviner. * **Il présente un brouillon à confirmer.** Rien n’est enregistré tant que vous n’avez pas confirmé. Vous voyez le nom, la requête, la description et le TTL proposés. Si vous souhaitez une règle plus restrictive ou plus large, il suffit de le dire et il rédige une nouvelle version. > [!TIP] > > Ask Wirespeed ne refuse jamais purement et simplement une demande — même pour des outils à double usage comme les logiciels de gestion à distance ou PowerShell. Il restreint plutôt la portée (par exemple à un hachage exact ou à une commande exacte associée à une catégorie et à un acteur) et vous demande les informations manquantes. ## Modifier une exclusion Une fois une exclusion créée, vous pouvez toujours la modifier — y compris la requête brute, le TTL et les paramètres — depuis **Paramètres → Exclusions**. Comme vous y modifiez directement la requête, la suite de cette page documente la syntaxe des requêtes afin que vous puissiez lire, revoir et ajuster ce que l’agent a produit. ## Format des requêtes ### Exemples de format de requête de détection * `property=value` * `property.sub=value` * `property=value AND property=value` * `property=value OR property=value` * `(property=value AND property=value) OR property=value` *Assez de `property=value` pour vous ?* ### Opérateurs | Opérateur | Description | | - | - | | = | égal | | != | différent | | >= | supérieur ou égal | | \<= | inférieur ou égal | | > | supérieur | | \< | inférieur | | \~ | contient | | !\~ | ne contient pas | | @= | toutes les valeurs du tableau sont égales | | @\~ | toutes les valeurs du tableau contiennent | | @\~= | certaines valeurs du tableau sont égales | | @\~\~ | certaines valeurs du tableau contiennent | | @!= | aucune valeur du tableau n’est égale | | @!\~ | aucune valeur du tableau ne contient | ### Valeurs des propriétés Vous disposez d’un document JSON contenant les valeurs de propriété que vous pouvez interroger. Il s’agit des valeurs de votre détection et de tous ses actifs associés. Lors de la saisie dans la recherche, les noms de propriété sont complétés automatiquement. ```json theme={null} { "id": "WSPD-24", "name": "Late stage tools", "description": "LST \"Mimikatz\" discovered", "users": [{ "email": "jake@wirespeed.co" }, { "email": "tim@wirespeed.co" }], "externalIP": "1.1.1.1", "internalIPs": ["10.0.0.1", "10.0.0.2"], "files": [{ "name": "powershell.exe", "path": "C:\\Users\\Tim" }], "locations": [], "createdAt": "2024-11-02T15:36:00.433Z" } ``` | Requête | Résultat | Description | | - | - | - | | `name="Late stage tools"` | true | `name` est égal à `"Late stage tools"` | | `id~WSPD` | true | `id` contient `WSPD` | | `createdAt>2024-11-01T15:36:00.433Z` | true | `createdAt` est postérieur à `2024-11-02T15:36:00.433Z` | | `name=null` | false | `name` est vide | | `externalIP~"1.1.1.0/24"` | true | `externalIP` se trouve dans la plage CIDR `1.1.1.0/24` | | `description=/.*mimikatz.*/i` | true | `description` correspond à l’expression régulière `/.*mimikatz.*/i` | | `description="LST Mimikatz discovered"` | true | `description` est égal à `"LST Mimikatz discovered"` | ### Tableaux Les tableaux sont aplatis et peuvent être interrogés avec les opérateurs spéciaux @. \[!WARNING] Soyez particulièrement attentif à l’opérateur de tableau que vous utilisez. Par exemple, l’opérateur « certaines valeurs du tableau sont égales » (@\~=) clôture automatiquement tout dossier contenant au moins une correspondance, même si les autres valeurs du tableau ne correspondent pas. Assurez-vous que c’est bien l’action souhaitée. | Requête | Résultat | Description | | - | - | - | | `files.name@=powershell.exe` | true | Le nom de tous les fichiers est égal à `powershell.exe` | | `files.path@=C:\Users\Tim` | true | Le chemin de tous les fichiers est égal à `C:\Users\Tim` | | `files.name@~shell` | true | Le nom de tous les fichiers contient `shell` | | `internalIPs@~"10.0.0.0/24"` | true | Toutes les internalIPs se trouvent dans la plage CIDR `10.0.0.0/24` | | `users.email@~="jake@wirespeed.co"` | true | L’e-mail de certains utilisateurs est égal à `jake@wirespeed.co` | | `users.email@~~jake` | true | L’e-mail de certains utilisateurs contient `jake` | | `users.email@!="some value"` | true | L’e-mail d’aucun utilisateur n’est égal à `some value` | | `users.email@!~none` | true | L’e-mail d’aucun utilisateur ne contient `none` | | `locations=null` | true | Aucune valeur dans locations | > [!WARNING] > > Les dates doivent être fournies au format ISO 8601\ > \ > Les adresses e-mail, les plages CIDR et les chaînes contenant des espaces doivent être placées entre guillemets\ > \ > Les tableaux d’objets à double imbrication (par exemple `indicators.observables.type`) sont aplatis en valeurs terminales pour la comparaison — les correspondances ne sont pas corrélées au même objet parent d’une clause à l’autre\ > \ > Si une chaîne contient des guillemets, ceux-ci sont supprimés lors de la comparaison\ > \ > Les barres obliques inverses dans les chaînes apparaissent doublement échappées dans l’interface ; vous n’avez besoin que d’un seul échappement pour y faire référence ## Paramètres Les exclusions peuvent être désactivées et ne sont alors plus utilisées tant qu’elles ne sont pas réactivées. Dès qu’une exclusion a entraîné la clôture automatique d’une détection, elle ne peut plus être supprimée, seulement désactivée. Si vous souhaitez qu’une exclusion soit supprimée et retirée de votre journal d’audit, ouvrez un ticket d’assistance. ### TTL Vous pouvez définir un TTL (durée de vie) pour une exclusion. L’exclusion est alors automatiquement désactivée au terme de la durée indiquée. Lorsqu’Ask Wirespeed reconnaît une activité limitée dans le temps, il fixe le TTL à la fenêtre la plus courte qui la couvre, de sorte que la règle expire sans que vous ayez à penser à la supprimer. #### TTL glissants Les TTL glissants réinitialisent leur minuteur chaque fois que l’exclusion correspond à une détection. Ainsi, les schémas courants de votre environnement restent exclus tant qu’ils se produisent régulièrement. Si le schéma cesse de se produire, le TTL finit par expirer et les occurrences futures ne sont plus exclues. Ask Wirespeed n’utilise un TTL glissant que pour un schéma récurrent, et un TTL fixe (non glissant) pour une fenêtre ponctuelle telle qu’un test d’intrusion. ### Ne pas mettre à jour le système source Par défaut, lorsque Wirespeed clôture automatiquement une détection parce qu’elle correspond à une exclusion, nous synchronisons également ce résultat avec l’intégration (par exemple en clôturant ou en mettant à jour l’alerte dans la console du fournisseur). Vous pouvez activer **Ne pas mettre à jour le système source** sur une exclusion pour interrompre cette synchronisation sortante pour les détections correspondant à cette règle. Utilisez cette option lorsque vous souhaitez uniquement masquer ou clôturer automatiquement des détections dans Wirespeed, sans modifier l’affichage ni le traitement de l’alerte dans le produit source. ## Exemples et compromis Rédiger des exclusions peut réduire le bruit causé par les faux positifs, mais cela peut aussi se faire au prix de vrais positifs ignorés, exposant votre organisation à des risques qui empêchent Wirespeed de vous protéger. Ask Wirespeed applique les mêmes compromis que ceux présentés ci-dessous et retient par défaut la version la plus restrictive d’une règle — les exemples qui suivent expliquent ce raisonnement afin que vous puissiez revoir un brouillon, ou modifier une requête, en toute confiance. ### Gérer les exécutables sûrs Il est possible d’utiliser des exclusions pour empêcher les escalades ou la remédiation pour des applications connues comme légitimes. Cela exige toutefois un regard critique pour être fait efficacement, avec un bon compromis en matière de risque. #### Un exemple simple Voici un exemple permettant d’autoriser l’exécution d’une version précise d’un exécutable connu comme légitime. Dans ce cas, l’exécutable était une application d’assistance pour un logiciel bancaire. Il n’a qu’une seule fonction, est publié directement par la banque de l’entreprise et n’a jamais été détourné par des attaquants. Idéalement, de tels fichiers seraient enrichis grâce à leurs hachages, comme ici le hachage `SHA256`, mais celui-ci ne figurait pas dans la bibliothèque de plus de 40 milliards de fichiers de Reversing Labs. La meilleure solution serait de soumettre ce fichier pour analyse et inclusion dans leur référentiel, mais ce n’est pas souvent réalisable ; une simple exclusion comme celle-ci peut donc être suffisamment sûre pour éviter de futurs faux positifs : ``` files.sha256@~=e7fc1d55726578f20d3336ed4391e4f7ee362ef77da3ccd4b5a38d18e31ccab5 ``` #### Exclure des outils de gestion à distance L’exemple suivant peut sembler trompeusement similaire au précédent, mais il expose votre organisation à des risques que Wirespeed ne recommande PAS : ``` files.sha256@~=9cfd2c521d6d41c3a86b6b2c3d9b6a042b84f2f192f988f65062f0e1bfd99cab ``` La différence tient ici au fait que ce hachage correspond à `ScreenConnect.WindowsClient.exe`, l’exécutable principal du produit ScreenConnect, un outil de gestion à distance et d’assistance informatique. Il est aussi couramment détourné par des attaquants qui recourent à l’ingénierie sociale pour se faire passer auprès de vos utilisateurs pour votre support informatique et les amènent à exécuter cette application légitime, mais connectée à leur propre instance de gestion à distance, afin de mener des actions malveillantes qui aboutissent souvent à un rançongiciel. Il est essentiel de savoir si un exécutable présente une capacité à double usage avant de l’ajouter comme exclusion. #### Exclure des outils Living off the Land Voici une autre exclusion trompeusement simple qui introduit un risque important : ``` files.sha256@~=1f9ffc2227f8dea8b771d543c464cf8166c22a39420a5322b5892a640c4b34b6 ``` Cette exclusion ignore les alertes provenant du binaire Microsoft `powershell.exe`. Il s’agit bien sûr d’un binaire officiel, mais l’exclure permet aux attaquants d’exécuter toutes sortes d’actions malveillantes, du logiciel malveillant de premier stade à l’élévation de privilèges, jusqu’à, dans certains cas, vous priver de l’accès à vos fichiers avec un rançongiciel. Wirespeed recommande vivement de ne jamais ajouter d’exclusions pour des outils Living off the Land connus. #### Utiliser plutôt les processus Une autre approche pour gérer `powershell` consiste à exclure un processus spécifique acceptable, comme dans cet exemple où powershell récupère le nom du domaine DNS auquel l’ordinateur est joint. C’est une opération courante pour des logiciels légitimes (et également courante chez les attaquants qui cherchent à s’orienter dans votre environnement, mais qu’il est probablement acceptable d’ignorer, car d’autres détections plus fiables signaleraient vraisemblablement leur présence) : ``` processes.command@="powershell $env:USERDNSDOMAIN" ``` Notez que l’opérateur est `@=` et non `@~=`. Processes est un tableau (une collection de plusieurs processus) ; nous devons donc utiliser un opérateur de tableau. L’opérateur choisi exige que chaque processus corresponde à « powershell \$env:USERDNSDOMAIN », contrairement à l’exclusion suivante, pour laquelle il suffit qu’un seul processus de la détection corresponde : ``` processes.command@~="powershell $env:USERDNSDOMAIN" ``` Dans cet exemple, la détection pourrait contenir d’autres processus révélant bien plus nettement un comportement d’attaquant, ce qui aboutirait à écarter à tort une alerte importante comme faux positif. La logique des exclusions est puissante, mais elle doit être précise. En cas de doute, laissez Ask Wirespeed en définir la portée pour vous ou demandez de l’aide via le chat d’assistance. ### VPN de confidentialité Autoriser votre organisation à utiliser des VPN de confidentialité lors des connexions peut compliquer considérablement la détection des connexions malveillantes. Une meilleure approche consiste à en interdire l’usage dans vos systèmes SSO et d’authentification, par exemple avec les Conditional Access Policies de Microsoft. Si ce n’est pas possible, voici néanmoins quelques exemples. Par ailleurs, même sans créer d’exclusions, Wirespeed apprend à faire confiance à certains attributs des dossiers à mesure que vous les marquez comme Malveillants ou Bénins. Par exemple, un dossier de connexion suspecte clôturé comme Bénin amène Wirespeed à mémoriser cette adresse IP pendant 30 jours. Lorsqu’un utilisateur fait l’objet d’une détection depuis cette IP au cours des 30 jours suivants, celle-ci est automatiquement clôturée comme Bénigne, et le compteur repart pour 30 jours supplémentaires à partir de ce moment pour les connexions suivantes. En outre, pour réduire la charge que représente pour l’équipe de sécurité le traitement des escalades de Wirespeed, nous recommandons vivement d’activer le ChatOps pour effectuer ce travail à votre place. Nous contacterons les utilisateurs finaux, leur demanderons s’ils viennent de se connecter depuis un emplacement inhabituel, les authentifierons par un canal distinct (si cette option est activée) et apprendrons les emplacements sûrs… le tout sans vous imposer la moindre charge. #### Comment NE PAS créer d’exclusion pour les VPN de confidentialité L’exclusion suivante est très permissive et expose votre organisation à un risque important, puisqu’elle ignore (exclut) purement et simplement toute détection ou alerte associée à NordVPN. Cette logique ne se limite pas aux détections de connexion et pourrait exclure des dossiers de logiciel malveillant impliquant une adresse IP de NordVPN, ainsi que n’importe quel utilisateur de toute votre organisation. Les attaquants utilisent eux aussi NordVPN ; cette exclusion n’est donc PAS recommandée. ``` ips.metadata.privacy.service="NordVPN" ``` #### Un peu mieux En ajoutant la catégorie Connexion, cette exclusion ne s’applique plus aux autres types, comme Exécution (logiciel malveillant) ou Appel de service (plan de contrôle cloud). Elle reste toutefois assez permissive et n’est pas recommandée, car elle autorise n’importe quel utilisateur : il est probable qu’un attaquant utilisant NordVPN à un moment donné puisse voler des identifiants ou des sessions, se connecter avec eux depuis ce fournisseur, déclencher cette règle d’exclusion, et aucune alerte ne serait émise : ``` category="IDENTITY__LOGIN" AND ips.metadata.privacy.service="NordVPN" ``` #### Utilisateurs spécifiques En partant de l’exemple précédent, si nous ajoutons une autre clause AND, l’entourons de parenthèses et indiquons les adresses e-mail des utilisateurs spécifiques censés utiliser NordVPN, nous obtenons une règle encore plus restrictive. Le risque subsiste néanmoins qu’un attaquant vole les identifiants de ces utilisateurs précis et tente de se connecter avec eux : ``` category="IDENTITY__LOGIN" AND ips.metadata.privacy.service="NordVPN" AND (directory.email="tim@taco.company" OR directory.email="jake@taco.company") ``` #### Un exemple très restrictif Cet exemple reprend le précédent en le limitant en plus à Austin, au Texas. Il devient alors très improbable qu’un attaquant parvienne à voler les identifiants des utilisateurs nommés et à utiliser ce VPN de confidentialité précis depuis cette ville et cette région précises, ce qui réduit fortement le risque de manquer un vrai positif. Il reste préférable de bloquer les VPN de confidentialité dans les paramètres d’authentification ou de laisser le ChatOps s’en charger pour vous, mais si ces options ne conviennent pas pour une raison quelconque, cette solution est disponible : ``` category="IDENTITY__LOGIN" AND ips.metadata.privacy.service="NordVPN" AND (directory.email="tim@taco.company" OR directory.email="jake@taco.company") AND ips.metadata.city="Austin" AND ips.metadata.region="Texas" ``` ### Gérer les comptes partagés Voici un exemple de création d’exclusion pour un compte utilisateur spécifique partagé et utilisé pour se connecter depuis différents emplacements. Il implique toutefois de sérieux compromis en matière de risque. Il est TOUJOURS préférable de suivre les bonnes pratiques de sécurité, d’avoir une bonne hygiène, d’utiliser une authentification forte (MFA) et de NE PAS PARTAGER DE COMPTES. Mais il arrive que l’équipe de sécurité soit contredite par les métiers ; voici donc un exemple pour gérer ce scénario. Premièrement, cette exclusion est limitée à la catégorie Connexion ; elle ne laisse donc pas le champ libre à des situations comme un logiciel malveillant qui contacte un emplacement observé, ou un utilisateur qui effectue des modifications suspectes dans votre plan de contrôle cloud AWS ou Azure (Appel de service). Deuxièmement, cette exclusion est limitée à plusieurs États américains : la Californie, l’Arizona, l’État de Washington, l’Oregon et le Nevada. Ce n’est pas idéal, mais dans ce cas précis, une raison métier le justifie. Troisièmement, pour compenser la logique large couvrant plusieurs États américains, aucune des adresses IP correspondantes ne doit porter l’un des indicateurs de confidentialité suivants : VPN, Proxy, TOR, Relay ou Hosting Provider. Si aucun jeu de données n’est parfait, nous disposons d’un excellent enrichissement géographique que nous appliquons à chaque adresse IP que nous traitons. Cette logique limite la correspondance aux seules IP physiquement situées dans des entreprises et des domiciles de ces États américains. Les adresses IP de centres de données (à l’exception des petits centres de données privés appartenant à des entreprises spécifiques, et non des colocations ou des fournisseurs cloud) ne correspondront pas à la logique. Résultat : un attaquant doit se trouver physiquement dans ces États. La plupart (mais pas la totalité) des acteurs criminels motivés par l’appât du gain utilisent probablement une infrastructure hébergée pour s’interposer entre vous et leur identification et attribution. Ainsi, même si cette approche n’est pas à privilégier (il vaut toujours mieux éviter cette situation), elle permet de gérer ce scénario de manière plus sûre que d’autres. ``` category="IDENTITY__LOGIN" AND directory.email="shared-user@taco.company" AND (locations.state="California" OR locations.state="Arizona" OR locations.state="Washington" OR locations.state="Oregon" OR locations.state="Nevada") AND ips.metadata.privacy.vpn=false AND ips.metadata.privacy.proxy=false AND ips.metadata.privacy.tor=false AND ips.metadata.privacy.relay=false AND ips.metadata.privacy.hosting=false ``` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.