Paramètres de Windows Defender à modifier aujourd’hui (sans tout casser)

Les paramètres qu’il vaut la peine de modifier (et ceux à laisser tranquilles)

1) Activer Tamper Protection (et le considérer comme non négociable)

Tamper Protection bloque les modifications non autorisées des paramètres Defender. En clair : les malwares (et les scripts « utiles ») auront plus de peine
à couper l’alarme avant de voler la télé.

Si vous gérez les appareils centralement, vous voulez Tamper Protection activé et piloté par une stratégie, pas laissé aux humeurs des administrateurs locaux.
Le mode de défaillance est évident : vous enquêterez sur un incident et réaliserez que la moitié du parc avait des protections clés désactivées parce qu’un
guide de dépannage de 2018 conseillait de « désactiver la protection en temps réel temporairement » et que la notion de « temporairement » a été oubliée.

2) Utiliser la protection fournie par le cloud et l’envoi automatique d’échantillons (avec des limites de politique sensées)

La protection cloud accélère la détection des menaces émergentes. Le compromis est que certaines organisations ont des règles strictes de gestion des données
et ne veulent pas d’envois d’échantillons arbitraires vers Microsoft. Très bien. Définissez la politique de manière intentionnelle. La mauvaise posture est « la désactiver parce que la conformité pourrait demander. »
La conformité posera des questions plus précises après un incident.

3) Ajuster le comportement des analyses pour une prévisibilité des performances (ne pas viser une CPU minimale absolue)

Defender peut provoquer des pics CPU et disque, surtout sur postes de développeurs, VDI et agents de build massivement orientés fichiers.
Votre objectif n’est pas zéro surcharge ; c’est une surcharge stable.

Concentrez-vous sur :

• La limite CPU pour les analyses (pour qu’une analyse planifiée n’écrase pas tout le monde à 10h).
• La planification des analyses (éviter les heures de pointe ; éviter les surprises à l’heure du déjeuner).
• Les exclusions uniquement lorsque vous pouvez les justifier (chemins/processus/extensions avec garde-fous).

4) Déployer les règles ASR en mode audit d’abord, puis appliquer celles à faible rayon d’impact

Les règles Attack Surface Reduction (ASR) sont l’une des meilleures fonctionnalités pour « compliquer la tâche des attaquants » sans nécessiter un nouveau produit.
L’astuce est la discipline de déploiement : commencez en Audit, collectez les événements, puis appliquez-les sélectivement.

5) Utiliser Controlled Folder Access avec précaution : efficace contre les ransomwares, dur pour les applications sur-mesure

Controlled Folder Access (CFA) est vraiment efficace contre les schémas de ransomware—bloquant les processus non fiables qui écrivent dans des dossiers protégés.
Il a aussi une personnalité : il casse des applications anciennes qui écrivent n’importe où.
Déployez-le avec un processus d’autorisation et un chemin d’escalade, pas à l’instinct.

Paramètres qu’il ne faut généralement PAS changer sans raison solide

• Désactiver la protection en temps réel comme « correctif de performance ». C’est un échec de sécurité déguisé en optimisation.
• Exclusions globales de chemin comme exclure C:\ ou des profils utilisateurs entiers. Ce n’est pas un réglage ; c’est une reddition.
• Désactiver la surveillance comportementale pour éviter les « blocages agaçants ». La surveillance comportementale détecte ce que les signatures manquent.

Une vérité sèche de l’exploitation : on n’obtient pas la fiabilité en désactivant les systèmes de sécurité ; on obtient la fiabilité en les rendant prévisibles et testables.

Faits intéressants et contexte (court, concret, utile)

1. Defender a commencé comme un produit séparé. « Microsoft AntiSpyware » existait avant de devenir Windows Defender puis Microsoft Defender Antivirus.
2. Le moteur a changé de nom, pas seulement de marketing. Le Defender d’aujourd’hui intègre des recherches cloud, des modèles comportementaux et des fonctions d’atténuation d’exploits qui n’existaient pas dans les outils de l’époque Windows 7.
3. Les règles ASR proviennent de besoins de durcissement en entreprise. L’idée était de bloquer des techniques d’intrusion courantes (processus enfants Office, abus de scripts) sans exiger un remplacement complet EDR.
4. Les mises à jour de la plateforme sont distinctes des signatures. Les mises à jour de signatures sont fréquentes ; les mises à jour de plateforme changent des composants centraux et peuvent modifier le comportement des performances.
5. Controlled Folder Access a été conçu autour des schémas de ransomware. Ce n’est pas des « permissions de fichiers » ; c’est la confiance applicative pilotée par une politique contrôlant les écritures dans des emplacements protégés.
6. Defender utilise plusieurs modes d’analyse. Il y a l’analyse en temps réel (à l’accès), planifiée et à la demande—chacun ayant des compromis performance/détection différents.
7. Les exclusions sont évaluées à plus d’un endroit. Il existe des exclusions par chemin, extension et processus—et mal choisir l’une d’elles peut silencieusement élargir la contournement.
8. Windows Security est une interface ; Defender est la pile. Les gens « cliquent un truc » et pensent que cela a changé l’application, mais l’état réel vit dans les politiques et préférences Defender.
9. Les logs d’événements sont la source de vérité. L’interface est conviviale. La réponse aux incidents ne l’est pas. Les journaux opérationnels de Defender sont là où vous confirmez ce qui s’est passé.

Playbook de diagnostic rapide (trouver le goulot vite)

Quand quelqu’un dit « Defender est lent », ce qu’il veut généralement dire est : « Quelque chose consomme du CPU/disque et le processus Defender est visible. »
Votre travail est de prouver le goulot et décider s’il faut régler, exclure, reprogrammer ou escalader.

Premier point : confirmer ce qui travaille maintenant

• Vérifier si MsMpEng.exe est le processus chaud (CPU), ou si la latence disque est le vrai coupable.
• Vérifier s’il s’agit d’une analyse planifiée, d’une analyse en temps réel déclenchée par une compilation, ou de mises à jour de définitions.
• Vérifier les boucles de détection répétées (le même fichier scanné plusieurs fois à cause du churn dans les dossiers temporaires).

Deuxième point : classifier la charge

• Développeur / agent CI : des millions de petits fichiers, écritures fréquentes, extraction d’archives, caches de paquets.
• VDI / hôte partagé : de nombreux profils utilisateurs, conteneurs de profil, analyses dupliquées entre sessions.
• Serveur de fichiers : analyse au moment de l’écriture plus analyse à la lecture depuis les clients.
• Endpoint pendant un incident : Defender est occupé parce qu’il attrape réellement quelque chose (ou essaie).

Troisième point : décider du changement minimal et sûr

• Si c’est une douleur d’analyse planifiée : limiter la CPU, déplacer la planification, assurer un comportement d’analyse en idle.
• Si c’est le churn des caches de build : envisager des exclusions ciblées avec traçabilité, ou déplacer les caches vers un chemin contrôlé.
• Si ce sont des faux positifs : capturer les métadonnées d’échantillon, mettre à jour signatures/plateforme, considérer des indicateurs d’autorisation (si vous avez des outils EDR), éviter les exclusions globales.
• Si ce sont les contrôles anti-ransomware qui cassent des applis : passer en mode Audit, collecter des événements, puis allow-lister les binaires exacts qui ont besoin d’accès.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : Tout échoue, tout le temps—donc concevez et exploitez les systèmes en supposant que l’échec est normal.

Tâches pratiques : contrôles réels avec commandes, sorties et décisions

Ceux-ci sont volontairement opérationnels. Chaque tâche comporte : une commande, une sortie d’exemple, ce que signifie la sortie, et quelle décision prendre.
Les commandes s’exécutent depuis un contexte PowerShell élevé, mais je les formate comme des blocs shell parce que c’est l’apparence des runbooks de production.

Tâche 1 : Confirmer que le service Defender et le moteur sont vivants

cr0x@server:~$ powershell -NoProfile -Command "Get-Service WinDefend | Format-List Name,Status,StartType"
Name      : WinDefend
Status    : Running
StartType : Automatic

Signification : Le service Defender Antivirus est en cours et configuré pour démarrer automatiquement.

Décision : S’il est arrêté/désactivé de façon inattendue, traitez cela comme un incident de sécurité ou une dérive de politique. Ne faites pas « juste le démarrer » et passer à autre chose—trouvez qui l’a changé.

Tâche 2 : Vérifier l’état global de Defender (temps réel, tamper, signatures)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMServiceEnabled,AntispywareEnabled,AntivirusEnabled,RealTimeProtectionEnabled,BehaviorMonitorEnabled,OnAccessProtectionEnabled,IoavProtectionEnabled,NISEnabled,TamperProtection,AntivirusSignatureLastUpdated | Format-List"
AMServiceEnabled              : True
AntispywareEnabled            : True
AntivirusEnabled              : True
RealTimeProtectionEnabled     : True
BehaviorMonitorEnabled        : True
OnAccessProtectionEnabled     : True
IoavProtectionEnabled         : True
NISEnabled                    : True
TamperProtection              : True
AntivirusSignatureLastUpdated : 2/5/2026 9:12:41 AM

Signification : Les protections de base sont activées ; les signatures ont été mises à jour récemment ; Tamper Protection est activé.

Décision : Si RealTimeProtectionEnabled est false, vous n’êtes pas en train de « tuner », vous roulez sans freins. Corrigez la politique d’abord.

Tâche 3 : Inspecter les préférences d’analyse et de limitation CPU

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object ScanAvgCPULoadFactor,DisableCpuThrottleOnIdleScans,ScanScheduleDay,ScanScheduleTime,DisableEmailScanning | Format-List"
ScanAvgCPULoadFactor          : 25
DisableCpuThrottleOnIdleScans : False
ScanScheduleDay               : 0
ScanScheduleTime              : 02:00:00
DisableEmailScanning          : False

Signification : Les analyses planifiées s’exécutent quotidiennement à 2h ; le facteur de charge CPU moyen visé est 25%.

Décision : Si le facteur CPU est élevé (ou si la planification est pendant les heures de travail), ajustez pour réduire l’impact visible par les utilisateurs.

Tâche 4 : Identifier les exclusions actuelles (chemins, processus, extensions)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object ExclusionPath,ExclusionProcess,ExclusionExtension | Format-List"
ExclusionPath      : {C:\BuildCache, D:\Agent\_work\_temp}
ExclusionProcess   : {C:\Program Files\Git\usr\bin\ssh.exe}
ExclusionExtension : {.iso}

Signification : Il existe des exclusions. Certaines peuvent être justifiées ; d’autres peuvent être des « hacks ponctuels devenus politique ».

Décision : Auditez les exclusions chaque trimestre. Si vous ne pouvez pas expliquer une exclusion en une phrase, retirez-la ou justifiez-la avec des données.

Tâche 5 : Vérifier les menaces récentes et les actions prises

cr0x@server:~$ powershell -NoProfile -Command "Get-MpThreatDetection | Select-Object ThreatName,Resources,ActionSuccess,InitialDetectionTime | Format-Table -AutoSize"
ThreatName                 Resources                                  ActionSuccess InitialDetectionTime
----------                 ---------                                  ------------- --------------------
Trojan:Win32/Wacatac.B!ml  file:_C:\Users\alex\Downloads\setup.exe    True          2/5/2026 8:04:12 AM

Signification : Defender a détecté quelque chose et a réussi son action (mise en quarantaine/suppression).

Décision : Si les détections sont fréquentes sur des postes métiers, vous avez peut-être un problème de formation utilisateur, un manque de filtrage web, ou une chaîne d’approvisionnement compromise. N’excluez pas le dossier Downloads.

Tâche 6 : Extraire les événements opérationnels récents de Defender (ce qui a été bloqué, ce qui fait du bruit)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 10 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
2/5/2026 9:30:02 AM  1116 Warning         Malware detected...
2/5/2026 9:28:10 AM  5007 Information     Configuration has changed...

Signification : L’ID d’événement 5007 indique souvent un changement de configuration ; 1116 indique une détection.

Décision : Si vous voyez des changements 5007 répétés, trouvez la source (GPO/Intune/admin local). Des paramètres qui oscillent sont un signe opérationnel.

Tâche 7 : Confirmer l’état de Tamper Protection depuis la vue des préférences

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object TamperProtection | Format-List"
TamperProtection : True

Signification : Tamper Protection est activé.

Décision : Si c’est false sur des appareils gérés, corrigez votre posture de gestion. Les attaquants aiment les endpoints qui font trop confiance aux admins locaux.

Tâche 8 : Mesurer si les analyses sont liées au disque ou au CPU (rapide et approximatif)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write','\Processor(_Total)\% Processor Time' -SampleInterval 1 -MaxSamples 5"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 9:41:01 AM       \\...\Avg. Disk sec/Read : 0.045
                          \\...\Avg. Disk sec/Write: 0.062
                          \\...\% Processor Time   : 38.112

Signification : La latence disque (45–62ms) est suffisamment élevée pour tout rendre lent ; le CPU n’est pas saturé.

Décision : Si la latence est élevée, les exclusions ne résoudront pas magiquement le stockage. Cherchez si l’antivirus amplifie un mauvais disque, ou si le mauvais disque amplifie le temps d’analyse. Parfois la correction est « remplacer le disque » ou « arrêter d’utiliser un niveau VDI sous-dimensionné ».

Tâche 9 : Vérifier les heures des dernières analyses et si elles correspondent à ce que vous pensez

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object QuickScanStartTime,QuickScanEndTime,FullScanStartTime,FullScanEndTime | Format-List"
QuickScanStartTime : 2/5/2026 2:00:12 AM
QuickScanEndTime   : 2/5/2026 2:04:58 AM
FullScanStartTime  :
FullScanEndTime    :

Signification : Les analyses rapides s’exécutent ; l’analyse complète ne l’est pas (peut-être par conception).

Décision : Pour beaucoup d’endpoints, des analyses rapides fréquentes plus la protection en temps réel suffisent ; les analyses complètes peuvent être planifiées moins souvent ou lancées pendant des fenêtres de maintenance.

Tâche 10 : Valider les versions de signatures et du moteur (et arrêter de dire « Defender » en abstraction)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMProductVersion,AMEngineVersion,AntivirusSignatureVersion,NISSignatureVersion | Format-List"
AMProductVersion          : 4.18.24090.11
AMEngineVersion           : 1.1.24090.6
AntivirusSignatureVersion : 1.409.1234.0
NISSignatureVersion       : 1.409.1234.0

Signification : Les versions produit/plateforme et signatures sont visibles et peuvent être comparées sur le parc.

Décision : Si un sous-ensemble de machines a de vieilles versions de plateforme, attendez-vous à des comportements et détections inconsistants. Corrigez la conformité des mises à jour avant d’appliquer des réglages astucieux.

Tâche 11 : Forcer une mise à jour de signatures (utile quand vous poursuivez un faux positif)

cr0x@server:~$ powershell -NoProfile -Command "Update-MpSignature"

Signification : Defender demande les dernières signatures depuis les sources configurées.

Décision : Si les faux positifs disparaissent après la mise à jour, votre « correctif » est d’améliorer la cadence des mises à jour, pas d’ajouter des exclusions.

Tâche 12 : Lancer une analyse ciblée sur un fichier ou répertoire suspect

cr0x@server:~$ powershell -NoProfile -Command "Start-MpScan -ScanType CustomScan -ScanPath 'C:\Users\alex\Downloads'"

Signification : Exécute une analyse personnalisée ; les résultats vont dans les journaux d’événements Defender et l’historique des menaces.

Décision : Utilisez ceci pour le triage d’incident. Si l’analyse martèle sans cesse le même répertoire, demandez-vous si le répertoire est juste du churn (temp/build) et si vous pouvez le rediriger plutôt que l’exclure.

Tâche 13 : Vérifier l’état de configuration des règles ASR (audit vs blocage)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object AttackSurfaceReductionRules_Actions,AttackSurfaceReductionRules_Ids | Format-List"
AttackSurfaceReductionRules_Actions : {2, 2, 1}
AttackSurfaceReductionRules_Ids     : {D4F940AB-401B-4EFC-AADC-AD5F3C50688A, 3B576869-A4EC-4529-8536-B80A7769E899, BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550}

Signification : Les actions correspondent à Disabled(0), Block(1), Audit(2), Warn(6) selon la règle ; vous voyez un mélange.

Décision : Si vous ne savez pas quel GUID correspond à quoi, ce n’est pas grave—votre prochaine étape est de standardiser via une politique et surveiller les événements. Évitez de modifier manuellement les endpoints.

Tâche 14 : Vérifier l’état de Controlled Folder Access

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object EnableControlledFolderAccess | Format-List"
EnableControlledFolderAccess : 1

Signification : 0=Désactivé, 1=Activé, 2=Mode Audit (les valeurs varient selon la build/politique) ; ici c’est activé.

Décision : Si activé et que les utilisateurs se plaignent de « impossibilité d’enregistrer des fichiers », vous devrez consulter les événements CFA et allow-lister des applis spécifiques.

Tâche 15 : Lire les événements liés à CFA (là où vit la vérité)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -FilterXPath \"*[System[(EventID=1123 or EventID=1124)]]\" -MaxEvents 5 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated           Id   Message
-----------           --   -------
2/5/2026 9:11:20 AM   1123 Controlled Folder Access blocked C:\Program Files\LegacyApp\app.exe from making changes to the folder...

Signification : CFA a bloqué une application tentant d’écrire dans un dossier protégé.

Décision : Si l’application est légitime et critique, allow-liste ce binaire exact (éditeur/chemin selon le cas). Ne désactivez pas CFA globalement parce qu’une application est exigeante.

Blague #1 : Désactiver Defender pour « améliorer les performances » ressemble à retirer les détecteurs de fumée pour arrêter le bip—silencieux, oui. Aussi : en feu.

Règles Attack Surface Reduction : durcissement qui n’abîme généralement pas

Les règles ASR sont un compromis pratique entre « on n’a rien » et « on a déployé un programme EDR complet avec un SOC et un thérapeute. »
Elles ciblent des chaînes d’attaque courantes : macros Office lançant des processus enfants, scripts exécutés depuis les e-mails, vol de credentials, etc.

Comment déployer ASR sans casser l’entreprise

1. Commencez en Audit pendant au moins un cycle métier. Vous voulez voir ce qui aurait été bloqué.
2. Revoir les événements avec les propriétaires : applications financières, add-ins ERP, outils PDF bizarres—intégrez les propriétaires d’applications tôt dans la conversation.
3. Appliquez d’abord les règles à faible risque (celles qui bloquent surtout des comportements manifestement malveillants).
4. Gardez un processus d’exception qui exige justification et dates d’expiration.

À surveiller

• Machines de développeurs : les chaînes d’outils script et compilateur peuvent ressembler à des « comportements suspects » si les règles sont trop agressives.
• Automatisation Office legacy : des macros qui lancent des processus ou déposent des fichiers peuvent déclencher les règles.
• Automatisation IT : les scripts de gestion s’exécutant depuis des partages réseau peuvent être affectés.

L’avantage : ASR réduit le nombre de chemins « un clic et vous êtes compromis ». Le coût : vous devez surveiller, régler et communiquer.
Si vous le déployez comme une taxe surprise, les utilisateurs chercheront des contournements. Ils le feront toujours.

Controlled Folder Access : défense anti-ransomware avec des bords tranchants

CFA est l’une des rares fonctionnalités endpoint Windows qui perturbe grossièrement le comportement des ransomwares : des processus aléatoires chiffrant des documents utilisateurs.
Il protège par défaut des dossiers spécifiques (Documents, Images, Bureau) et peut être étendu.

Où CFA rapporte

• Dirigeants et finance : cibles à haute valeur, données précieuses.
• Kiosques partagés et VDI : les utilisateurs installent des utilitaires « utiles » ; les attaquants adorent ça.
• Endpoints avec beaucoup de pièces jointes : les workflows email-driven sont une voie d’entrée commune.

Où CFA pose problème

• Anciennes applications qui écrivent dans des emplacements protégés sans patterns applicatifs modernes.
• Outils maison fournis comme binaires non signés et exécutés depuis les profils utilisateurs.
• Certaines solutions de sauvegarde/synchronisation qui ne sont pas reconnues comme applis autorisées.

Discipline opérationnelle pour CFA

Vous avez besoin d’une boucle : déployer (audit), collecter les blocs, allow-lister les applis légitimes, appliquer. Répétez.
Si vous sautez la boucle d’allow-list, CFA devient une « fonctionnalité de sécurité » que les utilisateurs perçoivent comme « l’informatique a cassé l’enregistrement des fichiers. »
Et ils auront raison.

Exclusions : en faire moins, avec précision, et documenter

Les exclusions sont la fonctionnalité Defender la plus mal utilisée. Elles sont aussi parfois nécessaires.
La différence entre « nécessaire » et « paresseux » est si vous pouvez expliquer le compromis de menace et mesurer le gain de performance.

Principes pour des exclusions sûres

• Privilégier les exclusions de processus plutôt que les exclusions de chemin quand c’est approprié. Un chemin exclu peut être abusé en déposant un malware dedans.
• Éviter d’exclure des emplacements modifiables par l’utilisateur (Downloads, Temp, AppData). C’est là que l’internet vient faire la fête.
• Exclure les caches de build, pas les espaces de travail entiers—et garder le chemin de cache dédié.
• Expirer les exclusions : ajouter des dates de revue. Ce qui avait du sens pendant une migration peut être dangereux un an plus tard.
• Mesurer l’impact : ne conservez pas des exclusions qui n’améliorent rien.

Candidats communs relativement sûrs (avec réserves)

• Répertoires de cache CI sur des agents dédiés, si l’agent est éphémère et que les artefacts sont analysés ailleurs.
• Grosses images de disques VM dans des répertoires contrôlés (toujours risqué ; dépend de la provenance et de l’utilisation).
• Répertoires de données de base de données pour des bases locales de développeurs (mais préférez un bon tuning DB et des disques séparés d’abord).

Si vous excluez quelque chose parce que « ça chauffe le portable », vous ignorez probablement le vrai problème : une charge qui génère un churn de fichiers pathologique.
Corrigez le churn (placement des caches, options de build, nettoyage des temporaires) et Defender devient moins dramatique.

Planification des analyses et limitation CPU

En milieu professionnel, les deux pires moments pour lancer des analyses lourdes sont : 9h et « quand ça lui chante ».
Les analyses planifiées devraient être ennuyeuses. Prévisibles. Documentées.

Définir un plafond CPU raisonnable pour les analyses planifiées

Le throttling CPU des analyses de Defender n’est pas parfait, mais c’est mieux que de laisser les analyses rivaliser avec un appel Teams, une build et un client VPN.
Un point de départ typique pour postes est 15–30. Pour les serveurs, cela dépend de la charge et des fenêtres de maintenance.

cr0x@server:~$ powershell -NoProfile -Command "Set-MpPreference -ScanAvgCPULoadFactor 20"

Signification : Limite la charge CPU moyenne que Defender vise à utiliser pendant les analyses.

Décision : Si les utilisateurs signalent encore un impact visible, ajustez d’abord la planification, puis envisagez de réduire davantage. Ne le mettez pas si bas que les analyses ne se terminent jamais.

Déplacer les analyses planifiées hors des heures de pointe

cr0x@server:~$ powershell -NoProfile -Command "Set-MpPreference -ScanScheduleDay 0 -ScanScheduleTime 03:00:00"

Signification : Analyse quotidienne à 3h (day=0 signifie souvent « tous les jours »).

Décision : Si les appareils sont en veille la nuit, vous pouvez préférer le comportement d’analyse en idle, ou une analyse hebdomadaire pendant une fenêtre prévisible où les appareils sont allumés (par exemple lundi 12:30 dans une organisation à laptop). Choisissez ce qui correspond à la réalité.

Vérifier si les analyses planifiées empiètent sur les fenêtres de maintenance

Les analyses Defender plus le patching plus l’indexation plus la sauvegarde peuvent produire un délicieux mystère « pourquoi tout est lent à 2h du matin ».
Échelonnez les tâches lourdes. Vous voulez un seul bully par cour de récréation.

Mises à jour des signatures et de la plateforme : la partie ennuyeuse qui compte

Les mises à jour sont là où Defender gagne ou perd silencieusement.
Des signatures périmées provoquent des faux positifs et des faux négatifs.
Des versions de plateforme obsolètes provoquent des bizarreries de performance et des comportements de politique inattendus.

Position pratique

• Rendre la conformité des mises à jour de signatures visible. Si vous ne pouvez pas la mesurer, vous ne remarquerez que lorsque quelque chose casse.
• Déployer les mises à jour de plateforme avec contrôle de changement. Pas parce qu’elles sont effrayantes—parce qu’elles peuvent changer les performances et la compatibilité des analyses.
• Pendant le dépannage, capturez les versions. « Defender l’a fait » n’est pas un rapport d’incident exploitable.

Blague #2 : La seule chose plus éternelle qu’une application legacy est la réunion sur pourquoi on ne peut pas mettre à jour l’application legacy.

Trois mini-histoires du monde corporate (toutes assez réelles pour faire mal)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé une politique de durcissement pour postes développeurs. L’équipe sécurité a fait ce qu’elle jugeait raisonnable :
ils ont activé Controlled Folder Access et quelques règles ASR. Ils ont testé sur un laptop propre, avec une installation fraîche, et tout semblait OK.

L’hypothèse erronée était subtile : ils ont supposé que les développeurs utilisaient principalement des toolchains modernes installés sous Program Files.
En réalité, la moitié de l’équipe dev utilisait des toolchains portables depuis leur profil utilisateur, y compris des utilitaires de build non signés et un outil de packaging personnalisé.
L’outil écrivait des artefacts de build dans des dossiers protégés dans le but de « sauvegarder sur le Bureau par commodité ».

Lundi matin, les builds ont commencé à échouer. Pas toutes. Juste assez pour semer le chaos.
Les erreurs étaient inconsistantes : « accès refusé » ici, « fichier introuvable » là, et beaucoup de développeurs accusant le système de build, le réseau, et les uns les autres.
Defender faisait exactement ce qu’on lui demandait : bloquer des processus non fiables d’écrire dans des emplacements protégés.

La récupération a été une leçon d’empathie opérationnelle. Ils ont mis CFA en Audit pour l’unité OU des devs, collecté les événements, et construit une allow-list pour les vrais outils.
Ils ont aussi modifié les recommandations d’environnement dev : les sorties de build vont dans un chemin d’espace de travail dédié, pas sur le Bureau/Documents.
La sécurité a récupéré sa protection. Les devs ont retrouvé un comportement prévisible. La seule vraie perte fut la croyance collective en « on a testé une fois. »

Mini-histoire 2 : L’optimisation qui s’est retournée

Une équipe infra gérait un parc d’agents CI Windows exécutant des builds conteneurisés, avec beaucoup de checkouts source et restore de paquets.
Ils ont vu Defender ronger le disque et ont décidé d’« optimiser » : ils ont ajouté des exclusions larges pour l’ensemble de l’espace de travail agent et des répertoires temp.
Les builds sont devenus plus rapides. Tout le monde a fêté. C’est là qu’il faut se méfier.

Quelques semaines plus tard, un développeur a introduit une dépendance compromise via un gestionnaire de paquets. La charge malveillante a atterri dans l’espace de travail exclu.
Defender ne l’a pas scanné—parce qu’on lui a dit de ne pas le faire. La charge s’est exécutée pendant une étape de build, a récupéré des identifiants depuis des variables d’environnement,
et les a utilisés pour accéder à un dépôt d’artefacts interne.

La réponse à l’incident n’a pas été amusante, mais instructive. L’équipe a réalisé qu’elle avait optimisé la mauvaise couche.
Ils n’avaient pas besoin d’exclure l’espace de travail entier ; ils devaient gérer précisément les caches à fort churn et rendre les agents plus éphémères.
Ils ont déplacé les caches vers un chemin dédié, exclu seulement ce chemin sur les agents éphémères, et ajouté des contrôles d’analyse lors de la publication d’artefacts.

La leçon durable : les gains de performance obtenus en « ne regardant pas ici » ne sont pas des gains.
Ce sont des incidents différés avec meilleur PR jusqu’au jour où ce n’est plus le cas.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une grande entreprise gérait des endpoints Windows mixtes et avait un contrôle de changement strict. Ce n’était pas glamour.
Mais elle avait une habitude qui rapportait : elle enregistrait centralement les changements de configuration Defender et les examinait lors du dépannage.

Un semaine, les tickets helpdesk ont explosé : des machines « perdaient aléatoirement » la protection en temps réel. Certains utilisateurs voyaient une alerte ; d’autres avaient juste des bizarreries :
téléchargements étranges, scripts qui échouent, et des rapports de posture sécuritaire montrant des trous.

L’équipe n’a pas deviné. Ils ont extrait les logs opérationnels Defender et trouvé des événements de changement de configuration répétés.
Corrélés avec les logs de gestion des endpoints, ils ont tracé cela à une GPO pilote destinée à un petit groupe de test.
Quelqu’un l’avait liée trop haut dans la structure OU. La politique a désactivé quelques protections pour « réduire la friction des développeurs » du groupe test.
Elle s’est propagée largement.

Parce que l’équipe avait des pratiques ennuyeuses et correctes—revue centrale des logs, traçabilité des changements, et la discipline de corréler les événements—ils ont reverté rapidement le lien,
validé l’état des protections, et réduit le temps d’exposition.
Personne n’a écrit un postmortem héroïque. C’est le but. La fiabilité est souvent l’absence de drame.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : « MsMpEng.exe utilise 30–60% CPU toute la journée »

Cause racine : Analyse en temps réel déclenchée par un churn élevé de fichiers (sorties de build, caches de paquets, dossiers de logs), ou une analyse bloquée sur un grand arbre d’archives.

Correction : Identifier les répertoires à churn, déplacer les caches vers des chemins dédiés, puis envisager des exclusions ciblées. Limiter aussi la CPU des analyses planifiées et reprogrammer les scans.

2) Symptom : « Le disque est saturé à 100% pendant les analyses ; tout se fige »

Cause racine : Système lié au disque (HDD lent/stockage VDI contentieux) + grand ensemble de fichiers scannés. Defender amplifie une situation d’E/S déjà faible.

Correction : Mesurer la latence disque avec des compteurs ; améliorer le niveau de stockage ou réduire la concurrence des analyses via la planification. Ne traitez pas des contraintes de stockage comme un problème de configuration antivirus.

3) Symptom : « Un outil interne ne peut plus enregistrer dans Documents/Bureau »

Cause racine : Controlled Folder Access bloquant un binaire non fiable/non signé, ou des patterns d’écriture d’application signalés comme ransomware.

Correction : Vérifier les événements CFA (1123/1124). Allow-lister le binaire exact si légitime ; envisager de signer le code ; ou modifier l’outil pour écrire dans des chemins approuvés.

4) Symptom : « Les scripts ont cessé de fonctionner ; l’automatisation Office est cassée »

Cause racine : Des règles ASR sont passées d’Audit à Bloc sans validation des workflows métiers requis.

Correction : Revenir en Audit pour les groupes impactés, revoir les événements ASR, puis appliquer seulement les règles qui ne cassent pas l’automatisation requise—ou ajouter des exceptions très ciblées.

5) Symptom : « Defender marque notre installateur comme malware »

Cause racine : Détection basée sur la réputation/heuristiques cloud déclenchée par des binaires peu répandus, installateurs non signés, ou artefacts de packaging.

Correction : Assurer que l’installateur est signé, stabiliser les entrées du pipeline de build, mettre à jour signatures/plateforme. Éviter des exclusions permanentes pour des installateurs largement distribués.

6) Symptom : « Les paramètres Defender continuent de se modifier tout seuls »

Cause racine : Politique gérée (GPO/MDM) qui écrase les changements locaux, ou Tamper Protection empêchant les bascules locales.

Correction : Arrêtez de changer les paramètres localement. Identifiez la source de la politique ; mettez-la à jour centralement ; validez avec les logs et Get-MpPreference.

7) Symptom : « L’analyse ne se termine jamais »

Cause racine : Conflits de planification avec les modes veille/hibernation, ou throttling CPU trop bas pour finir dans la fenêtre, ou boucles de chemins sur des répertoires volatiles.

Correction : Vérifier les heures de début/fin des dernières analyses. Ajuster la planification pour une fenêtre où les machines sont allumées ; augmenter légèrement le facteur CPU ; réduire le scanning de churn en déplaçant/contrôlant les dossiers temporaires.

Listes de contrôle / plan étape par étape

Plan A : Rendre Defender plus sûr sans casser les workflows (aujourd’hui)

1. Établir l’état de base sur une machine représentative :
   • Exécuter Get-MpComputerStatus et stocker la sortie.
   • Exécuter Get-MpPreference et stocker la sortie.
2. Activer/vérifier Tamper Protection via votre plateforme de gestion. Confirmer avec Get-MpComputerStatus.
3. Vérifier la posture de protection cloud pour qu’elle corresponde à votre tolérance au risque ; ne la laissez pas indéfinie.
4. Définir un plafond CPU pour les analyses à une valeur conservatrice (commencer à 20–30 pour postes).
5. Reprogrammer les analyses hors des heures de pointe. Confirmer en regardant les champs de dernière analyse.
6. Activer ASR en Audit pour un groupe pilote. Collecter les événements pendant 1–2 semaines.
7. Activer CFA en Audit pour un groupe pilote si le risque ransomware est significatif. Créer un processus pour les demandes d’allow-list.
8. Revoir les exclusions existantes. Supprimer tout ce qui est large ou modifiable par l’utilisateur sauf justification.

Plan B : Stabiliser les plaintes de performance (sans démanteler la sécurité)

1. Confirmer le goulot avec des compteurs (CPU vs latence disque).
2. Trouver les chemins à churn en demandant : quel répertoire est constamment écrit ? Builds, clients de sync, extraction temporaire, caches de navigateurs.
3. Relocaliser les caches vers un répertoire dédié que vous pouvez justifier d’exclure si nécessaire.
4. Privilégier les exclusions de processus quand la surcharge de scan est liée à une chaîne d’outils connue.
5. Mesurer avant/après avec des compteurs et des métriques visibles par l’utilisateur (durée de build, temps de connexion, réactivité VDI).

Plan C : Se préparer aux audits et à la réponse aux incidents (le plan fiabilité pas glamour)

1. Centraliser les logs Defender ou au minimum standardiser la collecte d’événements sur les endpoints.
2. Suivre les changements de configuration (IDs d’événement comme 5007) et corréler avec les déploiements de politique.
3. Standardiser les niveaux de politique : serveurs, VDI, postes développeurs, postes standards.
4. Revue trimestrielle des exclusions avec propriétaires et dates d’expiration.

FAQ

1) Dois-je désactiver la protection en temps réel pour accélérer les builds ?

Non. Si les builds sont lents, identifiez les répertoires à fort churn et corrigez d’abord le placement des caches. Si nécessaire, ajoutez des exclusions limitées sur des agents CI éphémères, pas sur les portables des développeurs.

2) Est-il sûr d’ajouter des exclusions pour mon dossier de code source ?

Généralement non. Les arbres de source sont souvent modifiables par des outils et peuvent recevoir du contenu depuis des dépôts externes. Si vous devez le faire, excluez seulement des sorties de build ou des répertoires de cache spécifiques, pas tout le repo.

3) Pourquoi Defender réactive-t-il des paramètres que j’ai désactivés ?

Parce que la gestion par politique et Tamper Protection font leur travail. Les bascules locales ne sont pas une stratégie de configuration. Trouvez la politique qui gère et changez-la là-bas.

4) Quelle est la différence entre signatures et mises à jour de plateforme ?

Les signatures sont des données de détection qui se mettent à jour fréquemment. Les mises à jour de la plateforme modifient le moteur/components Defender et peuvent impacter les performances et le comportement des fonctionnalités.

5) Controlled Folder Access remplace-t-il les sauvegardes ?

Non. CFA réduit la probabilité qu’un ransomware chiffre des dossiers importants. Les sauvegardes sont la manière de récupérer quand quelque chose tourne mal—parce que quelque chose tournera mal.

6) Si j’active les règles ASR, cela cassera-t-il les macros Office ?

Cela peut arriver, selon l’ensemble de règles et votre usage des macros. Déployez d’abord en Audit, examinez les événements, puis appliquez de manière sélective.

7) Pourquoi Defender scanne-t-il mes grosses images VM ou fichiers ISO ?

Parce que ce sont des fichiers. Defender ne sait pas qu’ils sont « juste des images » à moins que vous ne le précisez via des exclusions—et c’est risqué. Préférez stocker ces artefacts dans des chemins contrôlés et les scanner à l’ingestion/publication.

8) Comment prouver que Defender est le goulot et pas le sous-système de stockage ?

Utilisez des compteurs de performance. Si la latence disque est élevée pendant l’activité de scan, le stockage est le goulot. Defender peut être le déclencheur, mais la plateforme est le limiteur.

9) Les exclusions de processus sont-elles plus sûres que les exclusions de chemin ?

Souvent oui—parce qu’un chemin exclu peut être exploité en déposant des fichiers malveillants dans ce répertoire. Les exclusions de processus restent risquées si un attaquant peut détourner le processus exclu.

10) Quel est le changement « quick win » le plus sûr ?

Activer/vérifier Tamper Protection et s’assurer que les signatures/plateforme sont à jour. Ensuite limiter la CPU des analyses et rescheduler les scans hors des heures de pointe.

Conclusion : prochaines étapes que vous pouvez réellement faire aujourd’hui

Si vous ne changez rien d’autre : vérifiez Tamper Protection, vérifiez que les protections sont activées, et arrêtez de laisser les analyses surprendre les utilisateurs.
Ensuite montez en maturité : ASR en Audit, CFA en Audit, allow-list disciplinée, et des exclusions étroites, revues et mesurées.

Une liste d’étapes pratiques :

1. Exécuter Get-MpComputerStatus et Get-MpPreference sur trois types de machines (standard utilisateur, développeur, VDI/serveur) et comparer.
2. Définir un plafond CPU pour les analyses et une planification pour la prévisibilité.
3. Inventorier les exclusions et supprimer tout élément que vous ne pouvez pas défendre lors d’une revue de sécurité.
4. Activer les règles ASR en Audit pour un groupe pilote et revoir les événements chaque semaine.
5. Activer CFA en Audit là où le risque ransomware est réel, et construire un processus d’allow-list avant d’appliquer en bloc.

Defender n’est pas parfait. Mais il est déjà sur vos machines, profondément intégré au système d’exploitation, et peut être exploité comme un système de production : mesuré, contrôlé et ennuyeux.
L’ennui, c’est bien. L’ennui, c’est comment on dort tranquille.