Conseils Administration de contrôle d’application & problèmes connus

Cet article présente des conseils et des astuces pour les administrateurs et les problèmes connus liés à App Control for Business. Testez cette configuration dans votre laboratoire avant de l’activer en production.

Emplacements des fichiers de stratégie App Control

Les stratégies de contrôle d’application de plusieurs formats de stratégie se trouvent aux emplacements suivants, selon que la stratégie est signée ou non, et selon la méthode de déploiement de stratégie utilisée.

• <Os Volume>\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId GUID}.cip
• <Partition> système EFI\Microsoft\Boot\CiPolicies\Active\{PolicyId GUID}.cip

La valeur {PolicyId GUID} est unique par stratégie et définie dans le xml de stratégie avec l’élément <PolicyId> .

Pour les stratégies de contrôle d’application au format de stratégie unique, en plus des deux emplacements précédents, recherchez également un fichier appelé SiPolicy.p7b aux emplacements suivants :

• <Partition> système EFI\Microsoft\Boot\SiPolicy.p7b
• <Os Volume>\Windows\System32\CodeIntegrity\SiPolicy.p7b

Ordre de priorité de la règle de fichier

Lorsque le moteur de contrôle d’application évalue des fichiers par rapport à l’ensemble actif de stratégies sur l’appareil, les règles sont appliquées dans l’ordre suivant. Une fois qu’un fichier rencontre une correspondance, le contrôle d’application arrête le traitement ultérieur.

1. Règles de refus explicites : un fichier est bloqué s’il existe une règle de refus explicite, même si d’autres règles sont créées pour essayer de l’autoriser. Les règles de refus peuvent utiliser n’importe quel niveau de règle. Utilisez le niveau de règle le plus spécifique lors de la création de règles de refus pour éviter un blocage plus important que prévu.

2. Règles d’autorisation explicites : si une règle d’autorisation explicite existe pour le fichier, le fichier s’exécute.

3. Le contrôle d’application recherche ensuite l’attribut étendu (EA) du programme d’installation managé ou l’EA ISG (Intelligent Security Graph) sur le fichier. Si l’un des contrats EA existe et que la stratégie active l’option correspondante, le fichier est autorisé.

4. Enfin, App Control effectue un appel cloud à l’ISG pour obtenir la réputation du fichier, si la stratégie active l’option ISG.

5. Tout fichier non autorisé par une règle explicite ou basé sur ISG ou MI est bloqué implicitement.

Problèmes connus

L’échec de l’arrêt du démarrage (écran bleu) se produit si plus de 32 stratégies sont actives

Tant que vous n’appliquez pas la mise à jour de sécurité Windows publiée le 9 avril 2024 ou après, votre appareil est limité à 32 stratégies actives. Si le nombre maximal de stratégies est dépassé, les écrans bleus de l’appareil font référence à ci.dll avec un bogue case activée valeur de 0x0000003b. Tenez compte de cette limite maximale de stratégies lors de la planification de vos stratégies De contrôle d’application. Toutes les stratégies de boîte de réception Windows actives sur l’appareil comptent également pour cette limite. Pour supprimer la limite de stratégie maximale, installez la mise à jour de sécurité Windows publiée le ou après le 9 avril 2024, puis redémarrez l’appareil. Sinon, réduisez le nombre de stratégies sur l’appareil pour qu’il reste inférieur à 32 stratégies.

Les stratégies de mode d’audit peuvent modifier le comportement de certaines applications ou provoquer des plantages d’applications

Bien que le mode d’audit App Control soit conçu pour éviter l’impact sur les applications, certaines fonctionnalités sont toujours activées/toujours appliquées avec toute stratégie De contrôle d’application qui active l’intégrité du code en mode utilisateur (UMCI) avec l’option 0 Enabled :UMCI. Voici une liste des modifications système connues en mode audit :

• Certains hôtes de script peuvent bloquer du code ou exécuter du code avec moins de privilèges, même en mode audit. Pour plus d’informations sur les comportements individuels de l’hôte de script, consultez Application de script avec App Control .
• Option 19 Activé :La sécurité du code dynamique est toujours appliquée si une stratégie UMCI inclut cette option. Consultez Contrôle d’application et .NET.

Les images natives .NET peuvent générer des événements de bloc de faux positifs

Dans certains cas, les journaux d’intégrité du code où les erreurs et avertissements App Control for Business sont écrits incluent des événements d’erreur pour les images natives générées pour les assemblys .NET. En règle générale, les blocs d’images natives sont fonctionnellement inoffensifs, car une image native bloquée revient à son assembly correspondant et .NET régénère l’image native à sa prochaine fenêtre de maintenance planifiée.

Les signatures utilisant le chiffrement à courbe elliptique (ECC) ne sont pas prises en charge

Les règles basées sur les signataires app Control fonctionnent uniquement avec le chiffrement RSA. Les algorithmes ECC, tels que ECDSA, ne sont pas pris en charge. Si App Control bloque un fichier basé sur des signatures ECC, les événements d’informations de signature 3089 correspondants affichent VerificationError = 23. Vous pouvez autoriser les fichiers à 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.

Les programmes d’installation MSI sont traités comme pouvant être écrits par l’utilisateur sur Windows 10 lorsqu’ils sont autorisés par la règle FilePath

Les fichiers du programme d’installation MSI sont toujours détectés comme pouvant être écrits par l’utilisateur sur Windows 10 et sur Windows Server 2022 et versions antérieures. Si vous devez autoriser les fichiers MSI à l’aide de règles FilePath, vous devez définir l’option 18 Disabled :Runtime FilePath Rule Protection dans votre stratégie De contrôle d’application.

Les installations MSI lancées directement à partir d’Internet sont bloquées par App Control

L’installation de fichiers .msi directement à partir d’Internet sur un ordinateur protégé par App Control échoue. Par exemple, cette commande échoue :

msiexec -i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi

Pour contourner ce problème, téléchargez le fichier MSI et exécutez-le localement :

msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi

Démarrage et performances lents avec des stratégies personnalisées

App Control évalue tous les processus qui s’exécutent, y compris les processus Windows de boîte de réception. Vous pouvez entraîner des temps de démarrage plus lents, des performances dégradées et éventuellement des problèmes de démarrage si vos stratégies ne s’appuient pas sur les modèles App Control ou ne font pas confiance aux signataires Windows. Pour ces raisons, vous devez utiliser les modèles de base App Control chaque fois que possible pour créer vos stratégies.

Considérations relatives à la stratégie d’étiquetage AppId

Les stratégies d’étiquetage AppId qui ne sont pas basées sur les modèles de base App Control ou qui n’autorisent pas les signataires windows intégrés peuvent entraîner une augmentation significative des temps de démarrage (environ 2 minutes).

Si vous ne pouvez pas autoriser les signataires Windows ou générer à partir des modèles de base App Control, ajoutez la règle suivante à vos stratégies pour améliorer les performances :

Étant donné que les stratégies d’étiquetage AppId évaluent mais ne peuvent pas baliser les fichiers DLL, cette règle court-circuite l’évaluation des DLL et améliore les performances d’évaluation.