Comprendre les règles de stratégie et les règles de fichier app Control for Business
Remarque
Certaines fonctionnalités d’App Control for Business sont disponibles uniquement sur des versions spécifiques de Windows. En savoir plus sur la disponibilité des fonctionnalités De contrôle d’application.
App Control for Business peut contrôler ce qui s’exécute sur vos appareils Windows 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 comment identifier les applications approuvées par votre organization.
Règles de stratégie App Control for Business
Pour modifier les options de règle de stratégie d’un code XML de stratégie App Control existant, utilisez l’Assistant Stratégie de contrôle d’application ou l’applet de commande PowerShell Set-RuleOption .
Vous pouvez définir plusieurs options de règle dans une stratégie De contrôle d’application. Le tableau 1 décrit chaque option de règle et indique si des stratégies supplémentaires peuvent les définir. Certaines options de règle sont réservées pour un travail futur ou ne sont pas prises en charge.
Remarque
Nous vous recommandons d’utiliser initialement Enabled :Audit Mode , car il vous permet de tester les nouvelles stratégies App Control avant de les appliquer. Avec le mode audit, les applications s’exécutent normalement, mais le contrôle d’application journalise les événements chaque fois qu’un fichier s’exécute qui n’est pas autorisé par la stratégie. Pour autoriser ces fichiers, 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é.
Certaines applications peuvent se comporter différemment même lorsque votre stratégie est en mode audit. Lorsqu’une option peut modifier les comportements en mode audit, cela est indiqué dans le tableau 1. Vous devez toujours tester soigneusement vos applications lors du déploiement de mises à jour significatives de vos stratégies App Control.
Tableau 1. Stratégie App Control for Business - Options de règle de stratégie
| Option de règle | Description | Option supplémentaire valide |
|---|---|---|
| 0 - Activé:UMCI | Les stratégies de contrôle d’application 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 actuellement pas prise en charge. | Non |
| 2 - Requis:WHQL | Par défaut, les pilotes de noyau qui ne sont pas signés WHQL (Windows Hardware Quality Labs) sont autorisés à s’exécuter. L’activation de cette règle nécessite que chaque pilote soit signé 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) | Indique au contrôle d’application 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 De contrôle d’application et utiliser les événements d’audit pour affiner la stratégie avant son application. Pour appliquer une stratégie De contrôle d’application, supprimez cette option. | Non |
| 4 - Désactivé:Signature de la version d’évaluation | Si cette option est activée, les fichiers binaires des builds Windows Insider ne sont pas approuvés. Cette option est utile pour les organisations qui souhaitent uniquement exécuter des fichiers binaires publiés, et non pas préversion des builds Windows. | 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 et toutes les stratégies supplémentaires doivent également être signées. Les certificats approuvés pour les futures mises à jour de stratégie doivent être identifiés dans la section UpdatePolicySigners. Les certificats approuvés pour les stratégies supplémentaires doivent être identifiés dans la section SupplementalPolicySigners. | Oui |
| 7 - Autorisé:Stratégie de débogage augmentée | Cette option n’est actuellement pas prise en charge. | Oui |
| 8 - Requis:Signataires de validation étendue | Cette option n’est actuellement pas prise en charge. | Non |
| 9 - Activé:Menu des options de démarrage avancées | Le menu de prédémarrage F8 est désactivé par défaut pour toutes les stratégies de contrôle d’application. 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 | Utilisé lorsque la stratégie De contrôle d’application est en mode d’application. Lorsqu’un pilote critique au démarrage échoue au démarrage, la stratégie App Control 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. Certains hôtes de script peuvent se comporter différemment même lorsque votre stratégie est en mode audit. Pour plus d’informations sur l’application des scripts, consultez Application de scripts avec Le contrôle d’application. REMARQUE : cette option n’est pas prise en charge sur Windows Server 2016 ou Windows 10 1607 LTSB et ne doit pas être utilisée sur ces systèmes d’exploitation. |
Non |
| 12 - Obligatoire:Appliquer les applications du Store | Si cette option de règle est activée, les stratégies De contrôle d’application 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 géré par App Control. | 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, App Control définit un attribut de fichier étendu qui indique que le fichier a été autorisé à s’exécuter. Cette option permet à App Control 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 App Control à s’appliquer sans nécessiter de redémarrage du système. REMARQUE : cette option est uniquement prise en charge sur Windows 10, version 1709 et ultérieure, ou Windows Server 2019 et versions ultérieures. |
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, ou Windows Server 2022 et versions ultérieures. |
Non |
| 18 Désactivé :Protection des règles FilePath runtime | Cette option désactive le runtime par défaut case activée 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, ou Windows Server 2022 et versions ultérieures. |
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 n’est prise en charge que sur Windows 10, version 1803 et ultérieure, ou Windows Server 2019 et versions ultérieures. REMARQUE : cette option est toujours appliquée si une stratégie UMCI de contrôle d’application l’active. Il n’existe aucun mode d’audit pour le renforcement de la sécurité du code dynamique .NET. |
Non |
| 20 Activé :Révoqué expiré comme non signé | Utilisez cette option pour traiter les fichiers binaires signés avec des certificats révoqués ou les certificats arrivés à expiration avec la référence EKU de signature à durée de vie sur la signature, en tant que « fichiers binaires non signés » pour les processus/composants en mode utilisateur, dans les scénarios de signature d’entreprise. | Non |
| Activé :Approbation de code dynamique en mode développeur | Utilisez cette option pour approuver les applications UWP qui sont déboguées dans Visual Studio ou déployées via le portail des appareils lorsque le mode développeur est activé sur le système. | Non |
Niveaux de règle de fichier App Control for Business
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 de l’Assistant Contrôle d’application ou des applets de commande PowerShell App Control 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 App Control.
Remarque
Les règles basées sur les signataires app Control fonctionnent uniquement avec le chiffrement RSA avec une longueur de clé maximale de 4 096 bits. Les algorithmes ECC, tels que ECDSA, ne sont pas pris en charge. Si vous essayez d’autoriser des fichiers par signature basées sur des signatures ECC, vous verrez VerificationError = 23 sur les événements d’informations de signature 3089 correspondants. Les fichiers peuvent être autorisés à la place par des règles de hachage ou d’attribut de fichier, ou à l’aide d’autres règles de signataire si le fichier est également signé avec des signatures à l’aide de RSA.
Tableau 2. Stratégie App Control for Business - 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é. Par défaut, ce niveau utilise l’attribut OriginalFileName de l’en-tête de ressource du fichier. Utilisez -SpecificFileNameLevel pour choisir un autre attribut, tel que ProductName. |
| 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é. Par défaut, ce niveau utilise l’attribut OriginalFileName de l’en-tête de ressource du fichier. Utilisez -SpecificFileNameLevel pour choisir un autre attribut, tel que ProductName. |
| LeafCertificate | Ajoute les signataires approuvés au niveau du certificat de signature individuel. L’avantage de l’utilisation de ce niveau par rapport au niveau de hachage individuel est que les nouvelles versions du produit ont des valeurs de hachage différentes, mais généralement le 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 d’autres niveaux de certificat. La stratégie App Control 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 un case activée 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 concerne principalement les 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. Par défaut, ce niveau utilise l’attribut OriginalFileName de l’en-tête de ressource du fichier. Utilisez -SpecificFileNameLevel pour choisir un autre attribut, tel que ProductName. |
Remarque
Lorsque vous créez des stratégies De contrôle d’application 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
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 App Control, ils créent un serveur de référence sur leur matériel standard et installent tous les logiciels que leurs serveurs sont connus pour exécuter. 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 App Control pour inclure tout autre logiciel qu’ils souhaitent exécuter. Ensuite, ils activent la stratégie De contrôle d’application en mode appliqué 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 de contrôle d’application. Si l’application interne non signée est mise à jour, elle doit également mettre à jour la stratégie De contrôle d’application pour autoriser la nouvelle version.
Ordre de priorité de la règle de fichier
App Control a une logique de conflit de règle de fichier intégrée qui se traduit par l’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, le contrôle d’application recherche une revendication programme d’installation managée si elle est autorisée par la stratégie. Enfin, le contrôle d’application revient à l’ISG si la stratégie l’autorise.
Remarque
Pour faciliter la raison de vos stratégies App Control, nous vous recommandons de conserver des stratégies ALLOW et DENY distinctes sur les versions de Windows qui prennent en charge plusieurs stratégies App Control.
Utiliser -SpecificFileNameLevel avec les règles de niveau FileName, FilePublisher ou WHQLFilePublisher
Par défaut, les niveaux de règle FileName, FilePublisher et WHQLFilePublisher utilisent l’attribut OriginalFileName de l’en-tête de ressource du fichier. Vous pouvez utiliser un autre attribut d’en-tête de ressource pour vos règles en définissant -SpecificFileNameLevel. Par instance, un développeur de logiciels peut utiliser le même ProductName pour tous les fichiers binaires qui font partie d’une application. À l’aide de -SpecificFileNameLevel, vous pouvez créer une seule règle pour couvrir tous les fichiers binaires de votre stratégie plutôt que des règles individuelles pour chaque fichier.
Le tableau 3 décrit les options d’attribut d’en-tête de ressource disponibles que vous pouvez définir avec -SpecificFileNameLevel.
Tableau 3. Options -SpecificFileNameLevel
| Valeur SpecificFileNameLevel | Description |
|---|---|
| FileDescription | Spécifie la description du fichier fournie par le développeur du fichier binaire. |
| InternalName | Spécifie le nom interne du fichier binaire. |
| OriginalFileName | 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. |
| PackageFamilyName | 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. |
| ProductName | Spécifie le nom du produit avec lequel le fichier binaire est fourni. |
| Chemin d’accès aux fichiers | Spécifie le chemin d’accès du fichier binaire. |
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 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, Le contrôle d’application effectue une case activée d’écriture utilisateur au moment de l’exécution qui garantit que les autorisations actuelles sur le chemin de fichier spécifié autorisent uniquement l’accès en écriture pour les utilisateurs administrateurs.
Il existe une liste définie de SID que App Control 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 les case activée d’administration du runtime du contrôle d’exécution avec l’option Disabled :Runtime FilePath Rule Protection décrite précédemment.
La liste des SID d’administrateur connus d’App Control 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-1277922394 ; 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 App Control
Les caractères génériques suivants peuvent être utilisés dans les règles de chemin de fichier App Control :
| 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 du chemin d’accès 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 le case activée 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\AppControlUSER\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 de contrôle d’application 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 App Control. Au lieu de cela, Configuration Manager effectue une analyse ponctuelle 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.
Plus d’informations sur les hachages
App Control 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, App Control 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, App Control 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, Le contrôle d’application valide chaque page du fichier et évite de charger l’intégralité du fichier 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écalculons 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 App Control dispose déjà de plusieurs hachages pour le fichier.
Pourquoi l’analyse crée-t-elle huit règles de hachage pour certains fichiers ?
Des règles distinctes sont créées pour UMCI et KMCI. Si les applets de commande ne peuvent pas déterminer qu’un fichier s’exécute uniquement en mode utilisateur ou dans le noyau, des règles sont créées pour les deux scénarios de déconnexion, ce qui vous permet de faire preuve de 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é.
Quand App Control utilise-t-il la valeur de hachage de fichier plat ?
Il existe de rares cas où le format d’un fichier n’est pas conforme à la spécification Authenticode et app Control revient donc à utiliser le hachage de fichier plat. Ce comportement peut se produire pour de nombreuses raisons, par exemple si des modifications sont apportées à la version en mémoire du fichier au moment de l’exécution. Dans ce cas, vous verrez que le hachage affiché dans l’événement d’informations de signature 3089 corrélé correspond au hachage de fichier plat de l’événement de bloc 3076/3077. Pour créer des règles pour les fichiers dont le format n’est pas valide, vous pouvez ajouter des règles de hachage à la stratégie pour le hachage de fichier plat à l’aide de l’Assistant Contrôle d’application ou en modifiant directement le code XML de stratégie.