Conseils sur la création de stratégies de refus de contrôle d’application

Article
10/01/2024
S’applique à:

✅ Windows 11, ✅ Windows 10

Avec App Control for Business, vous pouvez créer des stratégies pour refuser explicitement des pilotes et des applications spécifiques. Pour créer des stratégies de refus de contrôle d’application pour les entreprises effectives, vous devez comprendre l’ordre de priorité de règle appliqué par Le contrôle d’application, car il évalue les fichiers par rapport aux stratégies actives.

Stratégie de refus autonome

Lors de la création d’une stratégie qui se compose uniquement de règles de refus, vous devez inclure des règles « Autoriser tout » dans les sections en mode noyau et utilisateur de la stratégie en plus de vos règles de refus explicites. Les règles « Autoriser tout » garantissent que tout ce qui n’est pas explicitement refusé par votre stratégie est autorisé à s’exécuter. Si vous ne parvenez pas à ajouter des règles « Autoriser tout » à une stratégie de refus uniquement, vous risquez de tout bloquer. Ce résultat se produit parce qu’un code est explicitement refusé et que tout autre code est implicitement refusé, car il n’existe aucune règle pour l’autoriser. Nous vous recommandons d’utiliser le modèle de stratégie AllowAll lors de la création de vos stratégies de refus autonomes.

<FileRules>
  <Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
  <Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />
</FileRules>
<SigningScenarios>
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_1" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_2" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
</SigningScenarios>

L’ajout des règles « Autoriser tout » précédentes n’affecte pas les autres stratégies de contrôle d’application que vous avez déployées qui appliquent une liste d’autorisation explicite. À titre d’exemple, considérez l’exemple suivant :

Policy1 est une liste d’autorisation pour les applications signées Windows et Microsoft.

Policy2 est notre nouvelle stratégie de refus, qui bloque MaliciousApp.exe ainsi que les wmic.exe binaires des composants Windows. Il inclut également les règles « Autoriser tout ».

MaliciousApp.exe est bloqué, car il existe une règle de blocage explicite dans Policy2. Il est également implicitement bloqué par Policy1, car il n’existe aucune règle d’autorisation qui couvre le fichier dans cette stratégie.
Le wmic.exe de fichier signé Windows est bloqué, car il existe une règle de blocage explicite dans Policy2.
Toutes les autres applications signées Windows et Microsoft sont autorisées, car il existe une règle d’autorisation explicite dans Policy1 et Policy2 qui couvre le fichier.
Toutes les autres applications sont implicitement refusées. Par exemple, ExampleApp.exe n’est pas autorisé, car il est uniquement approuvé par Policy2 (en raison des règles Autoriser tout) et non par Policy1.

Considérations de stratégie d’autorisation et de refus mixtes

Si l’ensemble de règles de refus doit être ajouté à une stratégie existante qui inclut des règles d’autorisation explicites, n’incluez pas les règles « Autoriser tout » précédentes. Au lieu de cela, les règles de refus doivent être fusionnées avec la stratégie de contrôle d’application existante via l’Assistant Contrôle d’application ou à l’aide de la commande PowerShell suivante :

$DenyPolicy = <path_to_deny_policy>
$ExistingPolicy = <path_to_existing_policy>
Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $ExistingPolicy

Meilleures pratiques

Testez d’abord en mode Audit : comme avec toutes les nouvelles stratégies, nous vous recommandons de déployer votre nouvelle stratégie de refus en mode Audit et de surveiller les événements de bloc d’audit 3076 pour vous assurer que seules les applications que vous aviez l’intention de bloquer sont bloquées. Plus d’informations sur la surveillance des événements de bloc via les journaux d’activité observateur d'événements et la chasse avancée : gestion et résolution des problèmes liés aux stratégies App Control for Business
Types de règles de refus recommandés : les règles d’attribut de signataire et de fichier sont recommandées du point de vue de la sécurité, de la facilité de gestion et des performances. Les règles de hachage ne doivent être utilisées que si nécessaire. Étant donné que le hachage d’un fichier change avec toute modification apportée au fichier, il est difficile de suivre une stratégie de blocage basée sur le hachage où l’attaquant peut mettre à jour le fichier de manière triviale. Bien qu’App Control ait optimisé l’analyse des règles de hachage, certains appareils peuvent voir des impacts sur les performances lors de l’évaluation de l’exécution si les stratégies ont des dizaines de milliers ou plus de règles de hachage.

Tutoriel sur la création d’une stratégie de refus

Les règles et stratégies de refus peuvent être créées à l’aide des applets de commande PowerShell ou de l’Assistant Contrôle d’application. Nous vous recommandons de créer des règles de signataire (PCACertificate, Publisher et FilePublisher) dans la mesure du possible. Dans le cas de fichiers binaires non signés, des règles doivent être créées sur les attributs du fichier, tels que le nom de fichier d’origine ou le hachage.

Règle de refus basée sur l’éditeur de logiciels

$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Fallback SignedVersion,Publisher,Hash -Deny

Règle de refus basée sur les attributs logiciels

$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Fallback Hash -Deny

Règle de refus basée sur le hachage

$DenyRules += New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny

Fusionner des règles de refus avec la stratégie de modèle AllowAll

Après avoir créé vos règles de refus, vous pouvez les fusionner avec la stratégie de modèle AllowAll :

$DenyPolicy = <path_to_deny_policy_destination>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $AllowAllPolicy -OutputFilePath $DenyPolicy -Rules $DenyRules
Set-CiPolicyIdInfo -FilePath $DenyPolicy -PolicyName "My Deny Policy" -ResetPolicyID

Déployer la stratégie de refus

Vous devez maintenant disposer d’une stratégie de refus prête à être déployée. Consultez le Guide de déploiement du contrôle d’application pour déployer votre stratégie sur vos points de terminaison managés.

Partager via