Comprendre Windows Defender règles de stratégie de contrôle d’application (WDAC) et les règles de fichier

  • Article
  • 20 minutes de lecture

S’applique à :

  • Windows 10
  • Windows 11
  • Windows Server 2016 et versions ultérieures

Remarque

Certaines fonctionnalités de Windows Defender Contrôle d’application ne sont disponibles que sur des versions spécifiques de Windows. En savoir plus sur la disponibilité des fonctionnalités WDAC.

Windows Defender Contrôle d’application (WDAC) peut contrôler ce qui s’exécute sur Windows 10 et Windows 11, en définissant des stratégies qui spécifient si un pilote ou une application est approuvé. Une stratégie inclut des règles de stratégie qui contrôlent des options telles que le mode d’audit et des règles de fichier (ou des niveaux de règle de fichier) qui spécifient la façon dont les applications sont identifiées et approuvées.

WDAC est utilisé pour limiter les appareils à exécuter uniquement des applications approuvées, tandis que le système d’exploitation est renforcé contre les attaques de mémoire du noyau à l’aide de l’intégrité du code protégé par l’hyperviseur (HVCI).

Règles des stratégies Windows Defender Application Control

Pour modifier les options de règle de stratégie d’un xml de stratégie WDAC existant, utilisez Set-RuleOption. Les exemples suivants montrent comment utiliser cette applet de commande pour ajouter et supprimer une option de règle sur une stratégie WDAC existante :

  • Pour vous assurer que l’UMCI est activée pour une stratégie WDAC créée avec l’option (mode utilisateur), ajoutez l’option -UserPEs de règle 0 à une stratégie existante, en exécutant la commande suivante :

    Set-RuleOption -FilePath <Path to policy XML> -Option 0

    Une stratégie créée sans l’option -UserPEs n’a pas de règles pour le code en mode utilisateur. Si vous activez UMCI (Option 0) pour une telle stratégie, toutes les applications, y compris le code de session utilisateur Windows critique, sont bloquées. En mode audit, WDAC enregistre simplement un événement, mais lorsqu’il est appliqué, tout le code du mode utilisateur est bloqué. Pour créer une stratégie qui inclut des exécutables en mode utilisateur (applications), exécutez New-CIPolicy avec l’option -UserPEs .

  • Pour désactiver l’intégrité UMCI sur une stratégie WDAC existante, supprimez l’option de règle 0 en exécutant la commande suivante :

    Set-RuleOption -FilePath <Path to policy XML> -Option 0 -Delete

Vous pouvez définir plusieurs options de règle au sein d’une stratégie WDAC. Le tableau 1 décrit chaque option de règle et indique si elles ont des stratégies supplémentaires. Toutefois, l’option 5 n’est pas implémentée, car elle est réservée aux travaux futurs, et l’option 7 n’est pas prise en charge.

Remarque

Nous vous recommandons d’utiliser initialement Enabled:Audit Mode , car il vous permet de tester les nouvelles stratégies WDAC avant de les appliquer. Avec le mode audit, aucune application n’est bloquée ; à la place, la stratégie enregistre un événement chaque fois qu’une application en dehors de la stratégie est démarrée. Pour autoriser ces applications, vous pouvez capturer les informations de stratégie à partir du journal des événements, puis fusionner ces informations dans la stratégie existante. Lorsque le mode Enabled:Audit est supprimé, la stratégie s’exécute en mode appliqué.

Tableau 1. Stratégie Windows Defender Application Control - options de règle de stratégie

Option de règle Description Option supplémentaire valide
0 - Activé:UMCI Les stratégies WDAC limitent les fichiers binaires en mode noyau et en mode utilisateur. Par défaut, seuls les fichiers binaires en mode noyau sont limités. L’activation de cette option de règle permet de valider les scripts et fichiers exécutables du mode utilisateur. Non
1 - Activé:Protection du menu de démarrage Cette option n’est pas prise en charge actuellement. Non
2 - Requis:WHQL Par défaut, les pilotes hérités qui ne sont pas signés WHQL (Hardware Quality Labs) Windows sont autorisés à s’exécuter. L’activation de cette règle nécessite que chaque pilote exécuté soit signé par le laboratoire WHQL et supprime la prise en charge des pilotes hérités. Les pilotes de noyau créés pour Windows 10 doivent être certifiés WHQL. Non
3 - Activé:Mode audit (valeur par défaut) Demande à WDAC de journaliser les informations sur les applications, les fichiers binaires et les scripts qui auraient été bloqués si la stratégie avait été appliquée. Vous pouvez utiliser cette option pour identifier l’impact potentiel de votre stratégie WDAC et utiliser les événements d’audit pour affiner la stratégie avant son application. Pour appliquer une stratégie WDAC, supprimez cette option. Non
4 - Désactivé:Signature de la version d’évaluation Si cette option est activée, les fichiers binaires signés par flightroot ne sont pas approuvés. Cette option est utile pour les organisations qui souhaitent uniquement exécuter des fichiers binaires publiés, et non des builds Windows en préversion. Non
5 - Activé:Hériter la stratégie par défaut Cette option est réservée à une utilisation ultérieure et n’a actuellement aucun effet. Oui
6 - Activé:Stratégie d’intégrité système non signée (par défaut) Permet à la stratégie de rester non signée. Lorsque cette option est supprimée, la stratégie doit être signée. Les certificats approuvés pour les futures mises à jour de stratégie doivent être identifiés dans la section UpdatePolicySigners. Oui
7 - Autorisé:Stratégie de débogage augmentée Cette option n’est pas prise en charge actuellement. Oui
8 - Requis:Signataires de validation étendue Cette option n’est pas prise en charge actuellement. Non
9 - Activé:Menu des options de démarrage avancées Le menu d’options préalables au démarrage F8 est désactivé par défaut pour toutes les stratégies WDAC. Si vous définissez cette option de règle, le menu F8 s’affiche pour les utilisateurs physiquement présents. Non
10 - Activé:Audit au démarrage en cas d’échec Cette option est utilisée lorsque la stratégie WDAC est en mode de mise en conformité. Lorsqu’un pilote critique au démarrage échoue au démarrage, la stratégie WDAC est placée en mode audit afin que Windows se charge. Les administrateurs peuvent valider la cause de l’échec dans le journal des événements CodeIntegrity. Non
11 - Désactivé:Application de script Cette option désactive les options d’application de script, couvrant PowerShell, l’hôte de script Windows (wscript.exe), l’hôte de script basé sur la console Windows (cscript.exe), les fichiers HTA exécutés dans Microsoft HTML Application Host (mshta.exe) et MSXML. Pour plus d’informations sur l’application des scripts, consultez Application de script avec WDAC.
REMARQUE : cette option n’est pas prise en charge sur Windows Server 2016 et ne doit pas être utilisée sur ce système d’exploitation.		 Non
12 - Obligatoire:Appliquer les applications du Store Si cette option de règle est activée, les stratégies WDAC s’appliquent également aux applications Windows universelles. Non
13 - Activé:Programme d’installation géré Utilisez cette option pour autoriser automatiquement les applications installées par un programme d’installation géré. Pour plus d’informations, consultez Autoriser les applications déployées avec un programme d’installation managé WDAC. Oui
14 - Activé:Autorisation de Intelligent Security Graph Utilisez cette option pour autoriser automatiquement les applications dont la réputation est « bonne » telle que définie par l’Intelligent Security Graph (ISG) de Microsoft. Oui
15 - Activé:Invalider les AE au redémarrage Lorsque l’option Intelligent Security Graph (14) est utilisée, WDAC définit un attribut de fichier étendu qui indique que le fichier a été autorisé à s’exécuter. Cette option permet à WDAC de revalider régulièrement la réputation des fichiers précédemment autorisés par l’ISG. Non
16 - Activé:Mettre à jour la stratégie Aucun redémarrage Utilisez cette option pour autoriser les futures mises à jour de stratégie WDAC à appliquer sans exiger de redémarrage du système.
REMARQUE : cette option n’est prise en charge que sur Windows 10, version 1709 et ultérieure.		 Non
17 Activé :Autoriser les stratégies supplémentaires Utilisez cette option sur une stratégie de base pour permettre aux stratégies supplémentaires de la développer.
REMARQUE : cette option est uniquement prise en charge sur Windows 10, version 1903 et ultérieure.		 Non
18 Désactivé :Protection des règles FilePath runtime Cette option désactive la vérification du runtime par défaut qui autorise uniquement les règles FilePath pour les chemins d’accès accessibles en écriture uniquement par un administrateur.
REMARQUE : cette option est uniquement prise en charge sur Windows 10, version 1903 et ultérieure.		 Oui
19 Activé :Sécurité du code dynamique Active l’application de stratégie pour les applications .NET et les bibliothèques chargées dynamiquement.
REMARQUE : cette option est uniquement prise en charge sur Windows 10, version 1803 et ultérieure.		 Non
20 Activé :Révoqué expiré comme non signé Utilisez cette option pour traiter les fichiers binaires signés avec des certificats expirés et/ou révoqués comme des « binaires non signés » pour les processus/composants en mode utilisateur, dans les scénarios de signature d’entreprise. Non

Niveaux de règle de fichier de Windows Defender Application Control

Les niveaux de règle de fichier permettent aux administrateurs de spécifier le niveau auquel ils souhaitent approuver leurs applications. Ce niveau de confiance peut être aussi granulaire que le hachage de chaque binaire, ou aussi général qu’un certificat d’autorité de certification. Vous spécifiez des niveaux de règle de fichier lors de l’utilisation des applets de commande WDAC PowerShell pour créer et modifier des stratégies.

Chaque niveau de règle de fichier présente des avantages et des inconvénients. Utilisez le tableau 2 pour sélectionner le niveau de protection approprié pour vos ressources d’administration disponibles et le scénario de déploiement WDAC.

Tableau 2. Stratégie Windows Defender Application Control - niveaux de règle de fichier

Niveau de règle Description
Hash Spécifie des valeurs de hachage d’image Authenticode/PE individuelles pour chaque binaire découvert. Ce niveau est le niveau le plus spécifique et nécessite plus d’efforts pour maintenir les valeurs de hachage des versions de produit actuelles. Chaque fois qu’un fichier binaire est mis à jour, la valeur de hachage change, ce qui nécessite la mise à jour de la stratégie.
FileName Spécifie le nom de fichier d’origine pour chaque fichier binaire. Bien que les valeurs de hachage d’une application soient modifiées lors de la mise à jour, les noms de fichiers ne le sont généralement pas. Ce niveau offre une sécurité moins spécifique que le niveau de hachage, mais il ne nécessite généralement pas de mise à jour de stratégie lorsqu’un fichier binaire est modifié.
FilePath À compter de Windows 10 version 1903, ce niveau permet aux fichiers binaires de s’exécuter à partir d’emplacements de chemin d’accès de fichier spécifiques. Les règles FilePath s’appliquent uniquement aux fichiers binaires en mode utilisateur et ne peuvent pas être utilisées pour autoriser les pilotes en mode noyau. Vous trouverez plus d’informations sur les règles de niveau FilePath plus loin dans cet article.
SignedVersion Ce niveau combine la règle d’éditeur avec un numéro de version. Il permet à tout ce qui est exécuté à partir du serveur de publication spécifié avec une version au-dessus ou au-dessus du numéro de version spécifié.
Éditeur Ce niveau combine le niveau PcaCertificate (généralement un certificat sous la racine) et le nom commun (CN) du certificat feuille. Vous pouvez utiliser ce niveau de règle pour approuver un certificat émis par une autorité de certification particulière et émis à une société spécifique que vous approuvez (comme Intel, pour les pilotes de périphérique).
FilePublisher Ce niveau combine l’attribut « FileName » du fichier signé, plus « Publisher » (certificat PCA avec cn de feuille), ainsi qu’un numéro de version minimal. Cette option permet d’approuver des fichiers spécifiques de l’éditeur spécifié, dont la version est égale ou supérieure au numéro de version spécifié.
LeafCertificate Ajoute les signataires approuvés au niveau du certificat de signature individuel. Ce niveau présente un avantage par rapport au niveau de hachage individuel : les nouvelles versions du produit présenteront des valeurs de hachage différentes, mais un même certificat de signature. Lorsque ce niveau est utilisé, aucune mise à jour de stratégie n’est nécessaire pour exécuter la nouvelle version de l’application. Toutefois, les certificats feuille ont généralement des périodes de validité plus courtes que les autres niveaux de certificat. La stratégie WDAC doit donc être mise à jour chaque fois que ces certificats changent.
PcaCertificate Ajoute le certificat disponible le plus élevé à la chaîne de certificats fournie aux signataires. Ce niveau est généralement un certificat sous la racine, car l’analyse ne résout pas la chaîne de certificats complète via les magasins racines locaux ou avec une vérification en ligne.
RootCertificate Non pris en charge.
WHQL Approuve uniquement les fichiers binaires qui ont été soumis à Microsoft et signés par le Laboratoire de qualification matérielle Windows (WHQL). Ce niveau concerne principalement les fichiers binaires du noyau.
WHQLPublisher Ce niveau combine le niveau WHQL et le cn sur le certificat feuille, et est principalement destiné aux fichiers binaires du noyau.
WHQLFilePublisher Ce niveau combine l’attribut « FileName » du fichier signé, ainsi que « WHQLPublisher », ainsi qu’un numéro de version minimal. Ce niveau concerne principalement les fichiers binaires du noyau.

Remarque

Lorsque vous créez des stratégies WDAC avec New-CIPolicy, vous pouvez spécifier un niveau de règle de fichier principal, en incluant le paramètre -Level . Pour les fichiers binaires découverts qui ne peuvent pas être approuvés en fonction des critères de règle de fichier principaux, utilisez le paramètre -Fallback. Par exemple, si le niveau de règle de fichier principal est PCACertificate, mais que vous souhaitez également approuver les applications non signées, l’utilisation du niveau de règle de hachage comme secours ajoute les valeurs de hachage des fichiers binaires qui n’ont pas de certificat de signature.

Remarque

  • WDAC prend uniquement en charge les règles de signataire pour les clés de signature de certificat RSA avec un maximum de 4 096 bits.
  • Le code utilise cn pour les champs CertSubject et CertIssuer dans la stratégie. Vous pouvez utiliser le certutil de boîte de réception pour examiner le format sous-jacent afin de vous assurer que UTF-8 n’est pas utilisé pour le cn. Par exemple, vous pouvez utiliser une chaîne imprimable, IA5 ou BMP.

Remarque

Le cas échéant, les numéros de version minimum et maximal dans une règle de fichier sont référencés respectivement en tant que MinimumFileVersion et MaximumFileVersion dans le code XML de stratégie.

  • MinimumFileVersion et MaximumFileVersion spécifiés : pour les règles Allow, les fichiers dont la version est supérieure ou égale à MinimumFileVersion et inférieure ou égale à MaximumFileVersion sont autorisés. Pour les règles de refus, les fichiers dont la version est supérieure ou égale à MinimumFileVersion et inférieure ou égale à MaximumFileVersion sont refusés.
  • MinimumFileVersion spécifié sans MaximumFileVersion : pour les règles d’autorisation, les fichiers dont la version est supérieure ou égale à la version spécifiée sont autorisés à s’exécuter. Pour les règles de refus, les fichiers dont la version est inférieure ou égale à la version spécifiée sont bloqués.
  • MaximumFileVersion spécifié sans MinimumFileVersion : pour les règles d’autorisation, les fichiers dont la version est inférieure ou égale à la version spécifiée sont autorisés à s’exécuter. Pour les règles de refus, les fichiers dont la version est supérieure ou égale à la version spécifiée sont bloqués.

Exemple de niveaux de règle de fichier en cours d’utilisation

Par exemple, prenons l’exemple d’un professionnel de l’informatique dans un service qui exécute de nombreux serveurs. Ils veulent uniquement exécuter des logiciels signés par les entreprises qui fournissent leur matériel, système d’exploitation, antivirus et autres logiciels importants. Ils savent que leurs serveurs exécutent également une application écrite en interne qui n’est pas signée, mais est rarement mise à jour. Ils souhaitent autoriser l’exécution de cette application.

Pour créer la stratégie WDAC, ils créent un serveur de référence sur leur matériel standard, et installent tous les logiciels que leurs serveurs exécutent habituellement. Ensuite, ils exécutent New CIPolicy avec -Level Publisher (pour autoriser les logiciels de leurs fournisseurs de logiciels, les « éditeurs ») et -Fallback Hash (pour autoriser l’application interne, non signée). Ils déploient la stratégie en mode audit pour déterminer l’impact potentiel de l’application de la stratégie. À l’aide des données d’audit, ils mettent à jour leurs stratégies WDAC pour inclure tout autre logiciel qu’ils souhaitent exécuter. Ensuite, ils activent la stratégie WDAC en mode imposé pour leurs serveurs.

Dans le cadre des opérations normales, ils finiront par installer des mises à jour logicielles, ou peut-être ajouter des logiciels des mêmes fournisseurs de logiciels. Étant donné que le « serveur de publication » reste le même sur ces mises à jour et logiciels, il n’a pas besoin de mettre à jour sa stratégie WDAC. Si l’application interne non signée est mise à jour, elle doit également mettre à jour la stratégie WDAC pour autoriser la nouvelle version.

Ordre de priorité de la règle de fichier

WDAC a une logique de conflit de règle de fichier intégrée qui se traduit par ordre de priorité. Il traite d’abord toutes les règles de refus explicites qu’il trouve. Ensuite, il traite toutes les règles d’autorisation explicites. S’il n’existe aucune règle de refus ou d’autorisation, WDAC recherche une revendication Programme d’installation managée si elle est autorisée par la stratégie. Enfin, WDAC revient à l’ISG si la stratégie l’autorise.

Remarque

Pour faciliter la raison de vos stratégies WDAC, nous vous recommandons de conserver des stratégies ALLOW et DENY distinctes sur Windows 10, version 1903 et ultérieure.

Plus d’informations sur les règles de chemin de fichier

Les règles filepath ne fournissent pas les mêmes garanties de sécurité que les règles de signataire explicites, car elles sont basées sur des autorisations d’accès mutables. Les règles filepath sont mieux adaptées aux environnements où la plupart des utilisateurs s’exécutent en tant que standard plutôt qu’en tant qu’administrateur. Les règles de chemin d’accès sont mieux adaptées pour autoriser les chemins d’accès que vous prévoyez de rester accessibles en écriture par l’administrateur uniquement. Vous souhaiterez peut-être éviter les règles de chemin d’accès pour les répertoires où les utilisateurs standard peuvent modifier les listes de contrôle d’accès sur le dossier.

Chemins de fichiers accessibles en écriture par l’utilisateur

Par défaut, WDAC effectue une vérification d’écriture utilisateur au moment de l’exécution qui garantit que les autorisations actuelles sur le chemin de fichier spécifié et ses répertoires parents (de manière récursive) n’autorisent pas l’accès en écriture aux utilisateurs standard.

Il existe une liste définie de SID que WDAC reconnaît en tant qu’administrateurs. Si un chemin de fichier autorise des autorisations d’écriture pour tout SID ne figurant pas dans cette liste, le chemin d’accès est considéré comme pouvant être écrit par l’utilisateur, même si le SID est associé à un utilisateur administrateur personnalisé. Pour gérer ces cas spéciaux, vous pouvez remplacer la vérification d’administration du runtime de WDAC par l’option Disabled:Runtime FilePath Rule Protection décrite précédemment.

La liste des SID d’administration connus de WDAC est la suivante :

S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-127792394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.

Lorsque des règles de chemin d’accès aux fichiers sont générées à l’aide de New-CIPolicy, une règle de chemin d’accès complet unique est générée pour chaque fichier découvert dans le ou les chemins analysés. Pour créer des règles qui autorisent à la place tous les fichiers sous un chemin d’accès de dossier spécifié, utilisez New-CIPolicyRule pour définir des règles contenant des caractères génériques, à l’aide du commutateur -FilePathRules .

Utilisation de caractères génériques dans les règles de chemin de fichier WDAC

Les caractères génériques suivants peuvent être utilisés dans les règles de chemin de fichier WDAC :

Caractère générique Signification Systèmes d’exploitation pris en charge
* Correspond à zéro ou plusieurs caractères. Windows 11, Windows 10 et Windows Server 2022
? Correspond à un caractère unique. Windows 11 uniquement

Vous pouvez également utiliser les macros suivantes lorsque le volume exact peut varier : %OSDRIVE%, %WINDIR%, %SYSTEM32%. Ces macros peuvent être utilisées en combinaison avec les caractères génériques ci-dessus.

Remarque

Sur Windows 11, vous pouvez utiliser un ou plusieurs caractères génériques n’importe où dans une règle de chemin de fichier.

Sur toutes les autres versions de Windows et Windows Server, un seul caractère générique est autorisé par règle de chemin d’accès et doit être au début ou à la fin d’une règle de chemin d’accès.

Exemples de règles de chemin de fichier avec des caractères génériques

Exemples Description Systèmes d’exploitation pris en charge
C:\windows\*
D:\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*		 Les caractères génériques placés à la fin d’un chemin autorisent tous les fichiers dans le chemin immédiat et ses sous-répertoires de manière récursive. Windows 11, Windows 10 et Windows Server 2022
*\bar.exe Les caractères génériques placés au début d’un chemin d’accès autorisent le nom de fichier exact spécifié à n’importe quel emplacement. Windows 11, Windows 10 et Windows Server 2022
C:\*\CCMCACHE\*\7z???? -x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe		 Les caractères génériques utilisés au milieu d’un chemin d’accès autorisent tous les fichiers qui correspondent à ce modèle. Examinez soigneusement toutes les correspondances possibles, en particulier si votre stratégie désactive la vérification accessible en écriture par l’administrateur avec l’option Disabled:Runtime FilePath Rule Protection . Dans cet exemple, ces deux chemins hypothétiques correspondent à :
C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe
C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe		 Windows 11 uniquement

Sans caractère générique, la règle de chemin de fichier autorise uniquement un fichier spécifique (par exemple C:\foo\bar.exe).

Remarque

Lors de la création de stratégies WDAC avec Configuration Manager, il existe une option permettant de créer des règles pour les fichiers et dossiers spécifiés. Ces règles ne sont pas des règles de chemin de fichier WDAC. Au lieu de cela, Configuration Manager effectue une analyse unique des fichiers et dossiers spécifiés et génère des règles pour tous les fichiers binaires trouvés à ces emplacements au moment de cette analyse. Les modifications apportées aux fichiers et dossiers spécifiés après cette analyse ne seront pas autorisées, sauf si la stratégie de Configuration Manager est réappliquée.

Remarque

Il existe actuellement un bogue dans lequel les MPI ne peuvent pas être autorisés dans les règles de chemin d’accès de fichier. Les msis doivent être autorisés répertoriés à l’aide d’autres types de règles, par exemple des règles d’éditeur ou des règles d’attribut de fichier.

Plus d’informations sur les hachages

WDAC utilise l’algorithme de hachage d’image Authenticode/PE lors du calcul du hachage d’un fichier. Contrairement au hachage de fichier plat plus connu, le calcul de hachage Authenticode omet la somme de contrôle du fichier, la table de certificats et la table de certificats d’attributs. Par conséquent, le hachage Authenticode d’un fichier ne change pas lorsque les signatures et les horodatages du fichier sont modifiés, ou lorsqu’une signature numérique est supprimée du fichier. Avec l’aide du hachage Authenticode, WDAC offre une sécurité accrue et moins de charge de gestion, de sorte que les clients n’ont pas besoin de réviser les règles de hachage de stratégie lorsque la signature numérique sur le fichier est mise à jour.

Le hachage d’image Authenticode/PE peut être calculé pour les fichiers signés numériquement et non signés.

Pourquoi l’analyse crée-t-elle quatre règles de hachage par fichier XML ?

L’applet de commande PowerShell produit un hachage Sha1 Authenticode, un hachage Sha256, un hachage de page Sha1 et un hachage de page Sha256. Lors de la validation, WDAC sélectionne les hachages qui sont calculés en fonction de la façon dont le fichier est signé et du scénario dans lequel le fichier est utilisé. Par exemple, si le fichier est signé par hachage de page, WDAC valide chaque page du fichier et évite de charger le fichier entier en mémoire pour calculer le hachage sha256 authenticode complet.

Dans les applets de commande, au lieu d’essayer de prédire quel hachage sera utilisé, nous prédéfinyons et utilisons les quatre hachages (sha1/sha2 authenticode et sha1/sha2 de la première page). Cette méthode est également résiliente aux modifications apportées à la façon dont le fichier est signé, car votre stratégie WDAC dispose déjà de plusieurs hachages disponibles pour le fichier.

Pourquoi l’analyse crée-t-elle huit règles de hachage pour certains fichiers XML ?

Des règles distinctes sont créées pour UMCI et KMCI. Si les applets de commande ne peuvent pas déterminer qu’un fichier ne s’exécutera qu’en mode utilisateur ou dans le noyau, des règles sont créées pour les deux scénarios de déconnexion, avec une grande prudence. Si vous savez qu’un fichier particulier se charge uniquement en mode utilisateur ou noyau, vous pouvez supprimer les règles supplémentaires en toute sécurité.

Windows Defender règles de nom de fichier du contrôle d’application

Les niveaux de règle de nom de fichier vous permettent de spécifier les attributs de fichier sur lesquels baser une règle. Les règles de nom de fichier fournissent les mêmes garanties de sécurité que les règles de signataire explicites, car elles sont basées sur des attributs de fichier non mutables. La spécification du niveau de nom de fichier se produit lors de la création de règles de stratégie.

Utilisez le tableau 3 pour sélectionner le niveau de nom de fichier approprié pour vos cas d’usage. Par exemple, une application métier ou de production et ses fichiers binaires peuvent tous partager le même nom de produit. Cette option vous permet de créer facilement des stratégies ciblées en fonction du niveau de règle nom de fichier nom de produit.

Tableau 3. Windows Defender stratégie De contrôle d’application - niveaux de nom de fichier

Niveau de règle Description
Description du fichier Spécifie la description du fichier fournie par le développeur du fichier binaire.
Nom interne Spécifie le nom interne du fichier binaire.
Nom de fichier d’origine Spécifie le nom de fichier d’origine, ou le nom avec lequel le fichier a été créé pour la première fois, du fichier binaire.
Nom de la famille de packages Spécifie le nom de la famille de packages du fichier binaire. Le nom de la famille de packages se compose de deux parties : le nom du fichier et l’ID de l’éditeur.
Nom du produit Spécifie le nom du produit avec lequel le fichier binaire est fourni.