Créer une stratégie de contrôle d’application à l’aide d’un ordinateur de référence

Cette section décrit le processus de création d’une stratégie App Control for Business à l’aide d’un ordinateur de référence déjà configuré avec le logiciel que vous souhaitez autoriser. Vous pouvez utiliser cette approche pour les appareils à charge de travail fixe qui sont dédiés à un objectif fonctionnel spécifique et qui partagent des attributs de configuration communs avec d’autres appareils qui prennent en charge le même rôle fonctionnel. Des exemples d’appareils à charge de travail fixe peuvent inclure des contrôleurs domaine Active Directory, des stations de travail Administration sécurisées, des équipements de mélange de médicaments pharmaceutiques, des appareils de fabrication, des caisses enregistreuses, des distributeurs automatiques de billets, etc. Cette approche peut également être utilisée pour activer le contrôle d’application sur les systèmes « dans la nature » et vous souhaitez réduire l’impact potentiel sur la productivité des utilisateurs.

Comme décrit dans les scénarios de déploiement d’App Control for Business courants, nous allons utiliser l’exemple de Lamna Healthcare Company (Lamna) pour illustrer ce scénario. Lamna tente d’adopter des stratégies d’application plus fortes, notamment l’utilisation d’App Control pour empêcher les applications indésirables ou non autorisées de s’exécuter sur leurs appareils gérés.

Alice Pena est la responsable de l’équipe informatique chargée du déploiement d’App Control.

Créer une stratégie de base personnalisée à l’aide d’un appareil de référence

Alice a précédemment créé une stratégie pour les appareils des utilisateurs finaux entièrement gérés de l’organization. Elle souhaite maintenant utiliser App Control pour protéger les serveurs d’infrastructure critique de Lamna. La pratique d’imagerie de Lamna pour les systèmes d’infrastructure consiste à établir une image « dorée » comme référence pour ce à quoi un système idéal doit ressembler, puis à utiliser cette image pour cloner d’autres ressources de l’entreprise. Alice décide d’utiliser ces mêmes systèmes d’image « golden » pour créer les stratégies App Control, ce qui entraîne des stratégies de base personnalisées distinctes pour chaque type de serveur d’infrastructure. Comme pour l’imagerie, elle doit créer des stratégies à partir de plusieurs ordinateurs dorés en fonction du modèle, du service, de l’ensemble d’applications, etc.

Alice identifie les facteurs clés suivants pour arriver au « cercle de confiance » pour les serveurs d’infrastructure critique de Lamna :

• Tous les appareils exécutent Windows Server 2019 ou version ultérieure ;
• Toutes les applications sont gérées et déployées de manière centralisée ;
• Aucun utilisateur interactif.

Sur la base de ce qui précède, Alice définit les pseudo-règles pour la stratégie :

1. Règles « Windows works » qui autorisent :

   • Windows
   • WHQL (pilotes de noyau tiers)
   • Applications signées du Windows Store

2. Règles pour les fichiers analysés qui autorisent tous les fichiers binaires d’application préexistants trouvés sur l’appareil

Pour créer la stratégie De contrôle d’application, Alice exécute chacune des commandes suivantes dans une session Windows PowerShell avec élévation de privilèges, dans l’ordre :

1. Initialiser des variables.

   $PolicyPath=$env:userprofile+"\Desktop\"
   $PolicyName="FixedWorkloadPolicy_Audit"
   $LamnaServerPolicy=$PolicyPath+$PolicyName+".xml"
   $DefaultWindowsPolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml"
   

2. Utilisez New-CIPolicy pour créer une stratégie App Control en analysant le système à la recherche d’applications installées :

   New-CIPolicy -FilePath $LamnaServerPolicy -Level SignedVersion -Fallback FilePublisher,FileName,Hash -ScanPath c:\ -UserPEs -MultiplePolicyFormat -OmitPaths c:\Windows,'C:\Program Files\WindowsApps\',c:\windows.old\,c:\users\ 3> CIPolicyLog.txt
   

   Remarque

   • Vous pouvez ajouter le paramètre -Fallback pour identifier toutes les applications non découvertes à l’aide du niveau de règle de fichier principal spécifié par le paramètre -Level. Pour plus d’informations sur les options de niveau de règle de fichier, consultez Niveaux de règle de fichier App Control for Business.
   • Pour spécifier que la stratégie App Control analyse uniquement un lecteur spécifique, incluez le paramètre -ScanPath suivi d’un chemin d’accès. Sans ce paramètre, l’outil analyse le lecteur C par défaut.
   • Lorsque vous spécifiez le paramètre -UserPEs (pour inclure des exécutables en mode utilisateur dans l’analyse), l’option de règle 0 Enabled :UMCI est automatiquement ajoutée à la stratégie App Control. Si vous ne spécifiez pas -UserPEs, la stratégie sera vide d’exécutables en mode utilisateur et aura uniquement des règles pour les fichiers binaires en mode noyau comme les pilotes. En d’autres termes, la liste verte n’inclut pas d’applications. Si vous créez une telle stratégie et ajoutez ultérieurement l’option de règle 0 Enabled :UMCI, toutes les tentatives de démarrage d’applications entraînent une réponse de App Control for Business. En mode audit, la réponse consiste à enregistrer un événement et en mode appliqué, la réponse bloque l’application.
   • Pour créer une stratégie pour Windows 10 1903 et versions ultérieures, y compris la prise en charge des stratégies supplémentaires, utilisez -MultiplePolicyFormat.
   • Pour spécifier une liste de chemins d’accès à exclure de l’analyse, utilisez l’option -OmitPaths et fournissez une liste de chemins délimités par des virgules.
   • L’exemple précédent inclut 3> CIPolicylog.txt, qui redirige les messages d’avertissement vers le fichier texte CIPolicylog.txt.

3. Fusionnez la nouvelle stratégie avec la stratégie WindowsDefault_Audit pour vous assurer que tous les fichiers binaires windows et les pilotes de noyau seront chargés.

   Merge-CIPolicy -OutputFilePath $LamnaServerPolicy -PolicyPaths $LamnaServerPolicy,$DefaultWindowsPolicy
   

4. Donnez à la nouvelle stratégie un nom descriptif et un numéro de version initiale :

   Set-CIPolicyIdInfo -FilePath $LamnaServerPolicy -PolicyName $PolicyName
   Set-CIPolicyVersion -FilePath $LamnaServerPolicy -Version "1.0.0.0"
   

5. Modifiez la stratégie fusionnée pour définir des règles de stratégie :

   Set-RuleOption -FilePath $LamnaServerPolicy -Option 3 # Audit Mode
   Set-RuleOption -FilePath $LamnaServerPolicy -Option 6 # Unsigned Policy
   Set-RuleOption -FilePath $LamnaServerPolicy -Option 9 # Advanced Boot Menu
   Set-RuleOption -FilePath $LamnaServerPolicy -Option 12 # Enforce Store Apps
   Set-RuleOption -FilePath $LamnaServerPolicy -Option 16 # No Reboot
   Set-RuleOption -FilePath $LamnaServerPolicy -Option 17 # Allow Supplemental
   Set-RuleOption -FilePath $LamnaServerPolicy -Option 19 # Dynamic Code Security
   

6. Si nécessaire, ajoutez d’autres règles de signataire ou de fichier pour personnaliser davantage la stratégie pour votre organization.

7. Utilisez ConvertFrom-CIPolicy pour convertir la stratégie App Control au format binaire :

   [xml]$LamnaServerPolicyXML = Get-Content $LamnaServerPolicy
   $PolicyId = $LamnaServerPolicyXML.SiPolicy.PolicyId
   $LamnaServerPolicyBin = $PolicyPath+$PolicyId+".cip"
   ConvertFrom-CIPolicy $LamnaServerPolicy $LamnaServerPolicyBin
   

8. Chargez le xml de stratégie de base et le fichier binaire associé vers une solution de contrôle de code source telle que GitHub ou une solution de gestion de documents telle que Office 365 SharePoint.

Alice dispose désormais d’une stratégie initiale pour les serveurs d’infrastructure critique de Lamna, prête à être déployée en mode audit.

Créer une stratégie de base personnalisée pour réduire l’impact utilisateur sur les appareils clients en cours d’utilisation

Alice a précédemment créé une stratégie pour les appareils entièrement gérés du organization. Alice a inclus la stratégie d’appareil entièrement managée dans le cadre du processus de génération de l’appareil de Lamna afin que tous les nouveaux appareils commencent maintenant avec App Control activé. Elle se prépare à déployer la stratégie sur des systèmes déjà utilisés, mais elle s’inquiète de provoquer une interruption de la productivité des utilisateurs. Pour réduire ce risque, Alice décide d’adopter une approche différente pour ces systèmes. Elle continuera à déployer la stratégie d’appareil entièrement managée en mode audit sur ces appareils, mais pour le mode d’application, elle fusionnera les règles de stratégie d’appareil entièrement managées avec une stratégie créée en analysant l’appareil pour tous les logiciels précédemment installés. De cette façon, chaque appareil est traité comme son propre système « golden ».

Alice identifie les facteurs clés suivants pour arriver au « cercle de confiance » pour les appareils entièrement gérés en cours d’utilisation de Lamna :

• Tout ce qui est décrit pour les appareils entièrement managés de Lamna ;
• Les utilisateurs ont installé des applications dont ils ont besoin pour continuer à s’exécuter.

Sur la base de ce qui précède, Alice définit les pseudo-règles pour la stratégie :

1. Tout ce qui est inclus dans la stratégie Appareils entièrement managés
2. Règles pour les fichiers analysés qui autorisent tous les fichiers binaires d’application préexistants trouvés sur l’appareil

Pour les appareils existants et en cours d’utilisation de Lamna, Alice déploie un script avec le XML de stratégie Appareils complètement managés (et non le binaire de stratégie App Control converti). Le script génère ensuite une stratégie personnalisée localement sur le client, comme décrit dans la section précédente, mais au lieu de fusionner avec la stratégie DefaultWindows, le script fusionne avec la stratégie Appareils entièrement managés de Lamna. Alice modifie également les étapes ci-dessus pour répondre aux exigences de ce cas d’usage différent.