Lire en anglais

Partager via


Contrôle d’application Essential Huit

Cet article décrit en détail les méthodes permettant d’atteindre le modèle acscc (Australian Cyber Security Centre) Essential Eight Maturity Model for Application Control, à l’aide de Microsoft App Locker et windows Defender Application Control.

Pourquoi suivre les instructions de contrôle des applications ACSC Essential Eight ?

Le contrôle d’application est une approche de sécurité conçue pour se protéger contre le code malveillant s’exécutant sur les systèmes. Lorsque cette approche de sécurité est implémentée, elle garantit que seul le code approuvé, tel que les exécutables, les bibliothèques de logiciels, les scripts, les programmes d’installation et les pilotes, est autorisé à s’exécuter. En raison de son efficacité, le contrôle des applications est l’un des huit éléments essentiels des stratégies d’atténuation des incidents de cybersécurité de l’ACSC.

Contrôle d’application

Le contrôle d’application est une approche de sécurité conçue pour se protéger contre le code malveillant s’exécutant sur les systèmes. Lorsque cette approche de sécurité est implémentée, elle garantit que seul le code approuvé, tel que les exécutables, les bibliothèques de logiciels, les scripts, les programmes d’installation et les pilotes, est autorisé à s’exécuter.

Bien que le contrôle d’application soit principalement conçu pour empêcher l’exécution et la propagation de code malveillant sur un système, il peut également empêcher l’installation et l’utilisation d’applications non approuvées.

Atteindre les exigences de niveau de maturité de l’organisation

  • Niveau de maturité 1 (ML1) : peut être atteint à l’aide de Microsoft AppLocker
  • Niveaux de maturité 2 et 3 (ML2 & ML3) : peut être atteint à l’aide du contrôle d’application Microsoft Windows Defender

Implémentation du contrôle d’application

L’implémentation du contrôle d’application implique les étapes générales suivantes pour un organization :

  • Identification des applications approuvées
  • Développement de règles de contrôle d’application pour garantir que seules les applications approuvées peuvent être exécutées
  • Gestion des règles de contrôle d’application à l’aide d’un processus de gestion des modifications
  • Validation fréquente des règles de contrôle d’application

Lorsque vous déterminez comment appliquer l’autorisation d’application dans votre organization, l’Australia Cyber Security Centre considère les méthodes suivantes appropriées lorsqu’elles sont implémentées correctement :

  • Règles de hachage de chiffrement
  • Règles de certification de l’éditeur
  • Règles de chemin d’accès (lorsque les autorisations du système de fichiers sont configurées pour empêcher la modification non autorisée des autorisations de dossier et de fichier, du contenu des dossiers et des fichiers individuels)

Le contrôle d’application peut empêcher l’exécution non autorisée d’applications non approuvées. Le contrôle d’application peut également contribuer à l’identification des tentatives par un acteur de menace d’exécuter du code malveillant sur un système. La configuration de WDAC pour générer des journaux d’événements pour les exécutions autorisées et non autorisées peut fournir des informations précieuses au centre des opérations de sécurité d’un organization.

Il est important de noter qu’une solution de contrôle d’application ne remplace pas l’antivirus et d’autres solutions logicielles de sécurité déjà en place. WDAC fonctionne toujours de concert avec des solutions antivirus telles que Defender Antivirus. L’utilisation de solutions de sécurité Microsoft contribue à une approche de défense en profondeur efficace pour empêcher la compromission des systèmes.

Niveaux de maturité (ML) pour le contrôle d’application

Le Centre australien de cybersécurité a trois niveaux de maturité pour ses stratégies d’atténuation qui constituent le huit essentiel. Les niveaux de maturité sont basés sur l’atténuation des niveaux croissants d’artisanat utilisés par un acteur de menace. Dans le contexte du contrôle des applications, le Centre de cybersécurité de l’Australie détermine ce qui est nécessaire pour respecter les ml 1, 2 et 3.

Contrôle ISM Sep 2024 Niveau de maturité Atténuation
ISM-0109 3 Les journaux des événements des stations de travail sont analysés en temps voulu pour détecter les événements de cybersécurité.
ISM-0140 2, 3 Les incidents de cybersécurité sont signalés aux ASD dès que possible après qu’ils se produisent ou qu’ils ont été découverts.
ISM-0123 2, 3 Les incidents de cybersécurité sont signalés au responsable de la sécurité de l’information, ou à l’un de leurs délégués, dès que possible après qu’ils se produisent ou qu’ils ont été découverts.
ISM-0843 1, 2, 3 Le contrôle d’application est implémenté sur les stations de travail.
ISM-1490 2, 3 Le contrôle d’application est implémenté sur les serveurs accessibles sur Internet.
ISM-1656 3 Le contrôle d’application est implémenté sur les serveurs non accessibles sur Internet.
ISM-1544 2, 3 La liste de blocage des applications recommandée par Microsoft est implémentée.
ISM-1657 1, 2, 3 Le contrôle d’application limite l’exécution d’exécutables, de bibliothèques de logiciels, de scripts, de programmes d’installation, d’applications HTML compilées et d’applets du panneau de configuration à un ensemble approuvé organization.
ISM-1658 3 Le contrôle d’application limite l’exécution des pilotes à un ensemble approuvé organization.
ISM-1582 2, 3 Les ensembles de règles de contrôle d’application sont validés sur une base annuelle ou plus fréquente.
ISM-1659 3 La liste de blocage des pilotes vulnérables de Microsoft est implémentée.
ISM-1660 2, 3 Les événements de contrôle d’application autorisés et bloqués sont consignés de manière centralisée.
ISM-1815 2, 3 Les journaux des événements sont protégés contre toute modification et suppression non autorisée.
ISM-1819 2, 3 Après l’identification d’un incident de cybersécurité, le plan de réponse aux incidents de cybersécurité est mis en œuvre.
ISM-1870 1, 2, 3 Le contrôle d’application est appliqué aux profils utilisateur et aux dossiers temporaires utilisés par les systèmes d’exploitation, les navigateurs web et les clients de messagerie.
ISM-1871 2, 3 Le contrôle d’application est appliqué à tous les emplacements autres que les profils utilisateur et les dossiers temporaires utilisés par les systèmes d’exploitation, les navigateurs web et les clients de messagerie.
ISM-1228 2, 3 Les événements de cybersécurité sont analysés en temps voulu pour identifier les incidents de cybersécurité.
ISM-1906 2, 3 Les journaux des événements des serveurs accessibles sur Internet sont analysés en temps voulu pour détecter les événements de cybersécurité.
ISM-1907 3 Les journaux des événements provenant de serveurs non accessibles sur Internet sont analysés en temps voulu pour détecter les événements de cybersécurité.
Contrôle ISM Sep 2024 Niveau de maturité Contrôle Measure
ISM-0109 3 Les journaux des événements des stations de travail sont analysés en temps voulu pour détecter les événements de cybersécurité. Utilisez Defender pour point de terminaison P2. Les journaux des événements Windows sont capturés dans Microsoft Sentinel et Microsoft Defender XDR à l’aide d’événements Sécurité Windows via ama ou des solutions d’événements transférés Windows.
ISM-0140 2, 3 Les incidents de cybersécurité sont signalés aux ASD dès que possible après qu’ils se produisent ou qu’ils ont été découverts. Non dans l’étendue de ce document. Voir la remarque après ce tableau. 3
ISM-0123 2, 3 Les incidents de cybersécurité sont signalés au responsable de la sécurité de l’information, ou à l’un de leurs délégués, dès que possible après qu’ils se produisent ou qu’ils ont été découverts. Non dans l’étendue de ce document. Voir la remarque après ce tableau. 3
ISM-0843 1, 2, 3 Le contrôle d’application est implémenté sur les stations de travail. Configurez et utilisez Windows Defender Application Control/AppLocker en fonction des exigences de niveau de maturité de l’organization.
ISM-1490 2, 3 Le contrôle d’application est implémenté sur les serveurs accessibles sur Internet. Configurer et utiliser le contrôle d’application Windows Defender
ISM-1656 3 Le contrôle d’application est implémenté sur les serveurs non accessibles sur Internet. Configurer et utiliser le contrôle d’application Windows Defender
ISM-1544 2, 3 La liste de blocage des applications recommandée par Microsoft est implémentée. Les « règles de blocage recommandées » de Microsoft sont implémentées
ISM-1657 1, 2, 3 Le contrôle d’application limite l’exécution d’exécutables, de bibliothèques de logiciels, de scripts, de programmes d’installation, d’applications HTML compilées et d’applets du panneau de configuration à un ensemble approuvé organization. Microsoft recommande la création d’une liste définie de règles d’éditeur de fichiers ou de hachages de fichiers dans une stratégie de contrôle d’application. 1
ISM-1658 3 Le contrôle d’application limite l’exécution des pilotes à un ensemble approuvé organization. L’intégrité du code protégé par hyperviseur est activée et est par défaut pour Windows 11 2022 et versions ultérieures
ISM-1582 2, 3 Les ensembles de règles de contrôle d’application sont validés sur une base annuelle ou plus fréquente. Non dans l’étendue de ce document. Consultez la remarque ci-dessous. 3
ISM-1659 3 La liste de blocage des pilotes vulnérables de Microsoft est implémentée. Les « règles de blocage de pilotes recommandées » de Microsoft sont implémentées
ISM-1660 2, 3 Les événements de contrôle d’application autorisés et bloqués sont consignés de manière centralisée. Utilisez Defender pour point de terminaison P2. Les journaux des événements Windows sont capturés dans Microsoft Sentinel et Microsoft Defender XDR à l’aide de « Sécurité Windows événements » via les solutions AMA ou « Événements transférés Windows ».
ISM-1815 2, 3 Les journaux des événements sont protégés contre toute modification et suppression non autorisée. Role-Based Access Control pour Microsoft Defender XDR et Microsoft Sentinel sont appliqués.
ISM-1819 2, 3 Après l’identification d’un incident de cybersécurité, le plan de réponse aux incidents de cybersécurité est mis en œuvre. Non dans l’étendue de ce document.  Consultez la remarque ci-dessous. 3
ISM-1870 1, 2, 3 Le contrôle d’application est appliqué aux profils utilisateur et aux dossiers temporaires utilisés par les systèmes d’exploitation, les navigateurs web et les clients de messagerie. Microsoft recommande la création d’une liste définie de règles d’éditeur de fichiers ou de hachages de fichiers dans une stratégie de contrôle d’application. Le niveau de maturité 1 peut être atteint avec Microsoft AppLocker. Les niveaux de maturité 2 et 3 nécessitent le contrôle d’application Windows Defender. 2
ISM-1871 2, 3 Le contrôle d’application est appliqué à tous les emplacements autres que les profils utilisateur et les dossiers temporaires utilisés par les systèmes d’exploitation, les navigateurs web et les clients de messagerie. Implémentation et configuration du contrôle d’application Windows Defender
ISM-1228 2, 3 Les événements de cybersécurité sont analysés en temps voulu pour identifier les incidents de cybersécurité. Non dans l’étendue de ce document.  Voir la remarque après ce tableau. 3
ISM-1906 2, 3 Les journaux des événements des serveurs accessibles sur Internet sont analysés en temps voulu pour détecter les événements de cybersécurité. Utilisez Defender pour point de terminaison P2. Les journaux des événements Windows sont capturés dans Microsoft Sentinel et Microsoft Defender XDR à l’aide d’événements Sécurité Windows via ama ou des solutions d’événements transférés Windows.
ISM-1907 3 Les journaux des événements provenant de serveurs non accessibles sur Internet sont analysés en temps voulu pour détecter les événements de cybersécurité. Utilisez Defender pour point de terminaison P2. Les journaux des événements Windows sont capturés dans Microsoft Sentinel et Microsoft Defender XDR à l’aide d’événements Sécurité Windows via ama ou des solutions d’événements transférés Windows.

Important

1 Pour respecter ism-1657, Microsoft recommande la création d’une liste définie de règles d’éditeur de fichiers ou de hachages de fichiers dans une stratégie de contrôle d’application. Si les règles de chemin d’accès aux fichiers sont trop exploitées, une organization doit s’assurer que l’utilisateur ne peut pas modifier de manière non autorisée les autorisations de dossier et de fichier, le contenu des dossiers et les fichiers individuels. Par exemple, l’utilisateur ne doit pas disposer d’un accès en écriture dans NTFS à l’emplacement de la règle de chemin d’accès au fichier.

2 Pour respecter ism-1870, Microsoft recommande la création d’une liste définie de règles d’éditeur de fichiers ou de hachages de fichiers dans une stratégie de contrôle d’application. Le niveau de maturité 1 peut être atteint avec Microsoft AppLocker. Les niveaux de maturité 2 et 3 ont une exigence pour le contrôle d’application Windows Defender en raison des exigences ISM supplémentaires. Les règles de chemin d’accès aux fichiers ne sont pas recommandées pour ISM-1870, car l’utilisateur dispose d’une autorisation de système de fichiers dans le profil de l’utilisateur et les dossiers temporaires.

3 Les contrôles ISM-0140, 0123, 1582, 1819 et 1228 sont explicitement des contrôles de personnes et de processus principaux. Microsoft recommande que les personnes et les processus soient documentés et stockés en tant qu’artefacts dans le Gestionnaire de conformité Purview, dans le cadre de la preuve de technologie automatisée pour les révisions de conformité Essential 8.

Contrôle d’application pour Windows

Quelle solution utiliser ?

Microsoft recommande aux clients d’implémenter Windows Defender Application Control (WDAC) plutôt qu’AppLocker. Windows Defender Application Control fait l’objet d’améliorations continues. Bien qu’AppLocker continue de recevoir des correctifs de sécurité, il ne reçoit pas d’améliorations des fonctionnalités.

Toutefois, AppLocker peut également être déployé en complément de Windows Defender Application Control pour des scénarios tels que des appareils partagés, où il est important d’empêcher certains utilisateurs d’exécuter une application spécifique. Microsoft recommande que votre organization applique le contrôle d’application Windows Defender comme niveau le plus restrictif possible pour votre organization, et à l’aide d’AppLocker pour affiner les restrictions de mode utilisateur, si nécessaire.

Conseil

Bien que WDAC soit préférable, il peut être plus simple et plus facile pour la plupart des organisations d’obtenir ML1 en utilisant uniquement AppLocker comme point de départ. Les deux solutions sont gratuites.

AppLocker

AppLocker a été introduit avec Windows 7 et permet aux organization de contrôler les processus en mode utilisateur (applications) autorisés à s’exécuter sur leurs systèmes d’exploitation Windows. Les stratégies AppLocker peuvent s’appliquer à tous les utilisateurs sur un système, ou à des utilisateurs et groupes individuels avec des règles qui peuvent être définies en fonction des éléments suivants :

  • Règles de hachage de chiffrement
  • Règles de certification de l’éditeur
  • Règles de chemin d’accès

Les stratégies AppLocker peuvent être créées sur toutes les versions et ajouts pris en charge du système d’exploitation Windows, et peuvent être déployées à l’aide de stratégie de groupe, De PowerShell ou d’une solution Mobile Gestion des appareils.

Windows Defender Application Control

Windows Defender Application Control (WDAC) a été introduit avec Windows 10. Il permet aux organisations de contrôler quels processus en mode utilisateur (applications) et en mode noyau (pilotes) sont autorisés à s’exécuter sur leurs systèmes d’exploitation Windows. Les stratégies WDAC sont appliquées au système managé dans son ensemble et affectent tous les utilisateurs de l’appareil avec des règles qui peuvent être définies en fonction des éléments suivants :

  • Règles de hachage de chiffrement
  • Règles de certification de l’éditeur
  • Règles de chemin d’accès
  • Réputation de l’application telle qu’elle est déterminée par Intelligent Security Graph de Microsoft
  • Identité du processus qui a lancé l’installation de l’application par le programme d’installation managé

Les stratégies WDAC peuvent être créées sur n’importe quelle édition cliente prise en charge de Windows 10, Windows 11 ou sur Windows Server 2016 et versions ultérieures. Les stratégies WDAC peuvent être déployées à l’aide de stratégie de groupe, d’une solution Mobile Gestion des appareils, Configuration Manager ou PowerShell.

En raison de Windows as a Service de Microsoft permettant le développement et le déploiement de nouvelles fonctionnalités pour nos clients, certaines fonctionnalités de WDAC ne sont disponibles que sur des versions spécifiques de Windows.

Pour plus d’informations sur Windows Defender Application Control et Applocker, consultez Windows Defender Application Control et disponibilité des fonctionnalités AppLocker.

Contrôle d’application Essential Huit à l’aide d’AppLocker pour ML1

Utiliser AppLocker pour atteindre ML1

Lorsque l’administrateur déploie une stratégie AppLocker pour le contrôle d’application basé sur l’utilisateur, les règles suivantes peuvent être utilisées comme exemple d’implémentation basée sur le chemin d’accès. Cela inclut les règles, l’application des règles et le démarrage automatique du service Application Identity.

La suggestion consiste à bloquer (au minimum) les chemins d’accès suivants :

  • C :\Windows\Temp\*.*
  • %USERPROFILE%\AppData\Local\*.*
    • Ajouter une exception pour %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
  • %USERPROFILE%\AppData\Roaming\*.*

Pour plus d’informations sur AppLocker sur ML1, consultez les articles suivants :

Création d’une stratégie AppLocker pour atteindre ML1

Les stratégies Microsoft AppLocker peuvent être créées à l’aide de plusieurs méthodes. Microsoft recommande d’utiliser le projet Open source Microsoft AaronLocker pour faciliter la création de stratégies AppLocker. AaronLocker permet la création et la maintenance d’un contrôle d’application robuste et strict pour AppLocker aussi simple et pratique que possible que l’utilisation du service de scripts PowerShell. AaronLocker est conçu pour restreindre l’exécution de programmes et de scripts par des utilisateurs non administrateurs.

Pour plus d’informations sur Aaronlocker, consultez AaronLocker : contrôle d’application robuste et pratique pour Windows.

Déploiement de la stratégie AppLocker pour atteindre ML1

Microsoft AppLocker peut être déployé à l’aide de Microsoft Intune, stratégie de groupe ou PowerShell. La méthode de déploiement dépend de la solution de gestion actuelle du organization.

Pour plus d’informations sur le déploiement d’App Locker, consultez les articles suivants :

Surveillance des événements de stratégie AppLocker

Les événements liés à Microsoft AppLocker sont surveillés par une solution de gestion des informations de sécurité et des événements telle que Sentinel de Microsoft. Les événements sont également surveillés à l’aide des informations de chasse avancées de Microsoft Defender pour point de terminaison.

Microsoft Defender pour point de terminaison : Informations de référence sur AppLocker

Microsoft Defender pour point de terminaison capture les événements suivants par rapport à Microsoft AppLocker.

Nom de l’ActionType ID de source d’événement
AppControlExecutableAudited 8003
AppControlExecutableBlocked 8004
AppControlPackagedAppAudited 8021
AppControlPackagedAppBlocked 8022
AppControlPackagedAppBlocked 8006
AppControlScriptBlocked 8007
AppControlCIScriptAudited 8001

Pour plus d’informations sur observateur d'événements et la chasse avancée, consultez les articles suivants :

Contrôle d’application Essential Huit à l’aide de WDAC pour ML2

Microsoft décrit le processus de conception, la gestion du cycle de vie, le déploiement et les conseils opérationnels pour répondre aux contrôles d’application Essential Eight ML2 et ML3 à l’aide de WDAC.

Les clients qui ont besoin d’Essential Eight Application Control ML1 peuvent être atteints à l’aide de Microsoft AppLocker.

Les conditions préalables à l’utilisation de ces conseils sont requises :

  • Windows 11 22H2 Entreprise
  • Utilisation de Intune pour la solution de gestion
  • Defender pour point de terminaison, pour la solution de sécurité de point de terminaison
  • Microsoft Sentinel pour la gestion des informations et des événements de sécurité ; et
  • Autorisations appropriées par les administrateurs sur les solutions utilisées dans ce document

WDAC sur les systèmes d’exploitation Windows Server n’est pas dans l’étendue de ce guide. Des conseils pour Windows Server doivent être fournis sur une version ultérieure.

Conditions d'octroi de licence

Le service associé à M365 peut se trouver dans les descriptions de service Microsoft 365 et Office 365 pour comprendre les services nécessaires, les propositions de valeur et les exigences de licence :

Descriptions des services Microsoft 365 et Office 365

Pour plus d’informations sur les produits associés à WDAC, consultez les articles suivants :

Prise en main de WDAC

Conception de stratégie

Lorsqu’un organization commence à planifier WDAC, la prise en compte des décisions de conception détermine la façon dont elle affecte le déploiement de stratégie et la maintenance de la stratégie de contrôle des applications.

WDAC doit être utilisé dans le cadre des stratégies de contrôle d’application de votre organization si les conditions suivantes sont vraies :

  • Vous avez déployé ou envisagez de déployer les versions prises en charge de Windows dans votre organization
  • Vous avez besoin d’un contrôle amélioré sur l’accès aux applications de votre organization et aux données d’accès de votre utilisateur
  • Votre organization dispose d’un processus bien défini pour la gestion et le déploiement des applications
  • Vous disposez de ressources pour tester les stratégies par rapport aux exigences de l’organization
  • Vous disposez de ressources pour impliquer le support technique ou créer un processus d’assistance autonome pour les problèmes d’accès aux applications des utilisateurs finaux
  • Les exigences du groupe en matière de productivité, de facilité de gestion et de sécurité peuvent être contrôlées par des stratégies restrictives

WDAC incorpore un concept de « cercle de confiance ». Chaque organization a une définition différente de « cercle de confiance » propre à ses besoins métier. La définition associée à ACSC Essential 8 est le contrôle ISM 1657 : « Le contrôle d’application limite l’exécution d’exécutables, de bibliothèques logicielles, de scripts, de programmes d’installation, d’applications HTML compilées et d’applets du panneau de configuration à un ensemble approuvé par organization. »

Microsoft fournit plusieurs exemples de stratégies au format XML situé dans Windows sous %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies. Les exemples de stratégies Microsoft peuvent permettre à votre organization de démarrer à partir d’une stratégie de base existante et d’ajouter ou de supprimer des règles pour créer des stratégies personnalisées, si nécessaire.

Pour plus d’informations sur la conception de stratégie, consultez les articles suivants :

Formats de stratégie

WDAC prend en charge deux formats de stratégie :

  • Format de stratégie unique : format de stratégie d’origine publié avec Windows 10 RTM et Windows Server 2016. Le format de stratégie unique ne prend en charge qu’une seule stratégie active sur un système à un moment donné

  • Format de stratégie multiple (recommandé) : ce format de stratégie est pris en charge sur Windows 10 1903+, Windows 11 et Windows Server 2022. Un format de stratégie multiple offre plus de flexibilité pour le déploiement de Windows Defender Application Control et prend en charge jusqu’à 32 stratégies actives sur un appareil. En outre, il permet les scénarios suivants :

    • Appliquer et auditer côte à côte : pour valider les modifications de stratégie avant de déployer l’application. Les utilisateurs peuvent déployer une stratégie de base en mode audit côte à côte avec une stratégie existante basée sur le mode d’application
    • Stratégies de base multiples : les utilisateurs peuvent appliquer au moins deux stratégies de base simultanément
    • Stratégies supplémentaires : les utilisateurs peuvent déployer une ou plusieurs stratégies supplémentaires pour développer une stratégie de base. Vous pouvez utiliser des stratégies supplémentaires pour différents personnages au sein de votre organization, par exemple, rh et informatique

Microsoft recommande l’utilisation de plusieurs formats de stratégie et l’utilisation d’un seul format de stratégie pour les scénarios bien définis ou lorsque plusieurs formats de stratégie ne sont pas possibles, comme Windows Server 2016 et Windows Server 2019.

Pour plus d’informations sur les stratégies de contrôle WDAC, consultez Utiliser plusieurs stratégies de contrôle d’application Windows Defender.

Règles de stratégie et règles de fichier

WDAC contient deux concepts qui sont :

  • Règles de stratégie WDAC : les règles de stratégie WDAC spécifient des configurations telles que le mode Audit, le programme d’installation managé, l’application de script, les stratégies de supplément (format de stratégie multiple), Reputation-Based intelligence (autorisation ISG / Contrôle d’application intelligente) et peut-être d’autres. Les règles de stratégie déterminent également si WDAC pour les fichiers binaires en mode noyau et en mode utilisateur
  • Règles de fichier WDAC : les règles de fichier WDAC spécifient l’autorisation et la réautorisation pour l’exécution sur Windows. Les règles de fichier prennent en charge le hachage, le nom de fichier, le chemin d’accès au fichier et les règles de serveur de publication permettent à un client de définir un ensemble d’applications autorisées approuvé organization. La règle traite d’abord toutes les règles de refus explicites qu’elle trouve, puis traite toutes les règles d’autorisation explicites. S’il n’existe aucune règle de refus ou d’autorisation, WDAC recherche le programme d’installation géré. Enfin, si aucun de ces ensembles n’existe, WDAC revient à Reputation-Based intelligence

Pour plus d’informations sur les règles de stratégie et les règles de fichier, consultez l’article suivant :

Création de stratégie

Il existe deux méthodes principales pour créer une stratégie WDAC à l’aide de PowerShell ou de l’Assistant WDAC :

  • PowerShell : les stratégies WDAC sont créées à l’aide d’applets de commande configurables d’intégrité du code dans PowerShell. PowerShell permet à un professionnel de l’informatique d’automatiser l’analyse du système de stratégie WDAC, ce qui génère un xml de stratégie. PowerShell peut être utilisé pour fusionner des fichiers XML de stratégie, définir des règles de stratégie et ajouter d’autres règles de fichier de stratégie si nécessaire. Les applets de commande configurables d’intégrité du code peuvent également être utilisées pour modifier les exemples de stratégies WDAC afin de répondre aux exigences de votre organization.
  • Assistant Contrôle d’application Windows Defender (recommandé) : l’Assistant Stratégie WDAC est une application de bureau Windows open source écrite en C# et fournie en tant que package MSIX. Il a été conçu pour fournir aux architectes de sécurité la sécurité et aux administrateurs système un moyen plus convivial de créer, modifier et fusionner des stratégies de contrôle d’application. Cet outil utilise les applets de commande Config CI PowerShell dans le back-end, de sorte que la stratégie de sortie de l’outil et des applets de commande PowerShell est identique

Pour plus d’informations sur la création de stratégie, consultez les articles suivants :

Microsoft recommande l’utilisation de l’Assistant Contrôle d’application Windows Defender pour implémenter Essential Eight pour le contrôle d’application. PowerShell peut également être utilisé par les organisations ayant des exigences avancées dans un modèle d’exploitation DevOps en utilisant les exemples de stratégies comme base ou qui souhaitent créer une stratégie pour des scénarios bien définis à partir d’un système de référence.

Cycle de vie de la stratégie

Avant qu’un organization commence à implémenter une solution de contrôle d’application, vous devez prendre en compte la façon dont vos stratégies sont gérées et gérées au fil du temps. La plupart des stratégies WDAC évoluent au fil du temps et passent par un ensemble de phases identifiables pendant leur durée de vie. Ces phases sont les suivantes :

  1. Définissez la stratégie et générez une version en mode audit du xml de stratégie. En mode audit, les événements de bloc sont générés, mais les fichiers ne sont pas empêchés de s’exécuter
  2. Déployer la stratégie de mode d’audit sur les systèmes prévus
  3. Surveiller les événements de bloc d’audit des systèmes prévus et affiner les règles en fonction des besoins pour traiter les blocs inattendus/indésirables
  4. Répétez ces étapes jusqu’à ce que les événements de bloc restants répondent à vos attentes pendant l’audit
  5. Générez la version en mode appliqué de la stratégie. En mode d’application, les fichiers qui ne sont pas définis comme autorisés par la stratégie ne peuvent pas s’exécuter et les événements de bloc correspondants sont générés
  6. Déployer la stratégie de mode d’application sur les systèmes prévus
  7. Répétez toutes ces étapes en continu pour résoudre les actions de blocage inattendues/indésirables

Pour gérer efficacement les stratégies WDAC, vous devez stocker et gérer vos documents XML de stratégie dans un référentiel central. Microsoft recommande une solution de contrôle de code source telle que GitHub ou une solution de gestion de documents telle que SharePoint, qui fournit un contrôle de version.

Prérequis WDAC pour le programme d’installation managé

Cette section est destinée à fournir des conseils au client sur les exigences de configuration du programme d’installation managé WDAC à l’aide de PowerShell et de Microsoft Intune.

  • Passez en revue Protection Windows contre les menaces autoriser automatiquement les applications déployées par un programme d’installation géré avec windows Defender Application Control (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)

Notes

Cet exemple de script n’utilise pas AppLocker, donc les règles DENY sans gravité ne sont pas présentes à l’étape 1. Cette configuration d’AppLocker est créée pour tous les appareils nécessitant un programme d’installation géré.

  • Créez un script PowerShell qui effectue les opérations suivantes :
    • Stocker le code XML AppLocker
    • Exporter le code XML AppLocker
    • Définir une stratégie AppLocker
    • Démarrer le service AppLocker

Voici un exemple de script qui peut être déployé à l’aide de l’extension de gestion Intune – scripts PowerShell :

$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path

$AppLockerMIPolicy = 
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
  <FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
          <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
        </FilePublisherCondition>
  </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection> 
</AppLockerPolicy>
"@

$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml

Important

L’administrateur doit ajouter le script de configuration à la stratégie de règle de fichier WDAC par le biais du hachage ou du serveur de publication.

Programme d’installation managé WDAC

Vue d’ensemble

La fonctionnalité WDAC appelée programme d’installation managé permet un organization pour équilibrer la sécurité et la facilité de gestion lors de l’application de stratégies de contrôle d’application. Cela permet aux applications d’être installées par une solution de distribution de logiciels telle que Microsoft Configuration Manager ou Intune.

Une idée fausse courante consiste à configurer la règle de « programme d’installation managé » dans la stratégie de WDAC est la seule étape requise. Cette erreur est incorrecte et une autre configuration d’AppLocker est nécessaire pour que cette fonctionnalité fonctionne.

Le programme d’installation managé utilise une collection de règles dans AppLocker pour désigner les fichiers binaires approuvés par votre organization pour l’installation de l’application. Windows surveille le processus du binaire configuré et tous les processus enfants qu’il lance lors de la surveillance des fichiers associés en cours d’écriture sur le disque. Ces fichiers sont étiquetés comme provenant d’un programme d’installation managé et sont donc autorisés à s’exécuter.

Déploiement du programme d’installation managé

La création de stratégie AppLocker dans L’objet de stratégie de groupe Edit et les applets de commande PowerShell AppLocker ne peuvent pas être utilisées directement pour créer des règles pour le regroupement de programmes d’installation managés. Vous devez utiliser VS Code ou un autre outil d’éditeur pour créer une collection de règles de programme d’installation managée.

Le fournisseur de services de configuration (CSP) AppLocker ne prend actuellement pas en charge le type de collection de règles du programme d’installation managé. Par conséquent, la stratégie AppLocker doit être entrée à l’aide de PowerShell pour Microsoft Intune.

Étant donné que la fonctionnalité « Application des scripts » du contrôle d’application Windows Defender est requise pour répondre à ISM-1657, l’application de script est nécessaire pour contrôler PowerShell, VBscript, cscript, cscript, HSMTA et MSXML. Le script PowerShell pour configurer le « programme d’installation managé » doit se trouver dans la règle de stratégie de fichier WDAC à l’aide du hachage ou du serveur de publication.

Microsoft recommande la configuration du programme d’installation géré pour Microsoft Intune. Intune permet une gestion robuste des applications empaquetées à l’aide de Microsoft Intune sans qu’il soit nécessaire de mettre à jour fréquemment une stratégie de contrôle d’application Windows Defender.

Déploiement du script PowerShell pour le programme d’installation managé

Le déploiement de ce script de configuration pour le programme d’installation managé peut être effectué de deux manières à l’aide de Microsoft Intune selon le scénario :

  • Hachage : le hachage du script doit être connu dans la stratégie de fichier WDAC, empaqueté et déployé à l’aide de l’outil de préparation de contenu Microsoft Win32 ou de la fonctionnalité script PowerShell dans Microsoft Intune.
  • Code signé (éditeur) : le script PowerShell a été signé par une autorité approuvée et connu avec la stratégie de fichier WDAC, empaqueté et déployé à l’aide de l’outil de préparation de contenu Microsoft Win32 ou de la fonctionnalité script PowerShell dans Microsoft Intune.

Pour plus d’informations sur le déploiement de scripts PowerShell, consultez les articles suivants :

Création d’une stratégie d’audit WDAC

Créer une stratégie d’audit

Une fois les options comprises et les décisions de conception prises, le organization est en mesure de créer la première stratégie d’audit à l’aide de l’Assistant Contrôle d’application Windows Defender :

  1. Ouvrez l’Assistant Contrôle d’application Windows Defender et sélectionnez « Créateur de stratégie ».

  2. Dans Créateur de stratégie, sélectionnez Plusieurs formats de stratégie et Stratégie de base , puis sélectionnez Suivant.

  3. Dans le modèle de stratégie, trois options s’offrent à vous :

    • Le mode Windows par défaut inclut le système d’exploitation Windows, les applications du Windows Store, Microsoft 365 Apps pour entreprise (Office 365 Pro Plus) et les pilotes de noyau signés WHQL.
    • Autoriser le mode Microsoft inclut toutes les sections du mode Windows par défaut et toutes les applications signées Par Microsoft.
    • Le mode Signé et fiable inclut toutes les sections précédentes et Reputation-Based intelligence.

Important

Reputation-Based Intelligence pour le contrôle d’application ne répond pas au contrôle d’application Essential Huit en raison de l’exigence « Ensemble approuvé par l’organisation » (ISM 1657) et « Les ensembles de règles de contrôle d’application sont validés sur une base annuelle ou plus fréquente » (ISM 1582). Cette fonctionnalité dans WDAC ne répond pas aux exigences de ML2 ou ML3. Microsoft recommande l’utilisation de Reputation-Based Intelligence pour l’adoption de WDAC par l’organisation en dehors du contexte du contrôle d’application Essential Eight.

  1. Sélectionnez Mode Windows par défaut ou Autoriser le mode Microsoft en fonction des exigences de votre organization. Pour ce document, Microsoft utilise le mode Autoriser Microsoft.
  2. Modifiez le nom et l’emplacement de la stratégie en fonction du nom de la stratégie et de l’emplacement du fichier de stratégie souhaités pour stocker le fichier, puis sélectionnez Suivant.

Notes

Des informations détaillées sur les règles de stratégie WDAC sont disponibles ici.

  • Désactiver l’application du script défini sur « Désactivé » est nécessaire pour ISM 1657 et 1658 pour contrôler les scripts, les applications HTML et HTML conformes.
  • Intelligent Security Graph défini sur « Désactivé » est requis pour ISM 1657, 1658 et 1582.
  • Le programme d’installation managé est recommandé pour être « Activé » pour aider un organization avec le cycle de vie de la stratégie WDAC.
  • L’intégrité du code en mode utilisateur est requise pour que les stratégies WDAC s’appliquent à la fois aux fichiers binaires en mode noyau et en mode utilisateur.
  • Autoriser les stratégies de supplément est nécessaire pour utiliser le format multi-stratégie pour aider un organization avec le cycle de vie de la stratégie WDAC.

Notes

Toutes les autres règles de stratégie WDAC dépendent des exigences au sein d’un organization.

  1. Dans Les règles de signature, l’administrateur peut voir tous les certificats Microsoft qui ont été ajoutés en tant que Règles d’autorisation de l’éditeur. Nous aborderons Ajouter une règle personnalisée plus loin dans cet article.
  2. Sélectionnez Suivant.

L’Assistant Contrôle d’application Windows Defender génère :

  • XML de stratégie
  • {GUID}. CIP

Des informations détaillées sur les règles de stratégie WDAC sont disponibles ici.

Notes

Chaque stratégie générée à l’aide de l’Assistant Contrôle d’application Windows Defender fournit un nouvel identificateur global unique (GUID).

La stratégie WDAC a été créée avec succès.

XML de stratégie

Comme le organization a créé la stratégie WDAC à l’aide de l’Assistant WDAC, le organization est en mesure d’afficher le contexte de ce fichier dans un éditeur de texte. Le code XML est divisé en plusieurs sections différentes, pour le contexte de Essential Eight, notez les id de stratégie et de basepolicyID.

Notes

Bien qu’il soit possible de modifier directement le xml de stratégie. Microsoft recommande d’apporter toutes les modifications supplémentaires aux règles de stratégie ou aux fichiers de signature à l’aide de l’Assistant Contrôle d’application Windows Defender ou des applets de commande configurables d’intégrité du code dans PowerShell.

Déploiement de stratégie d’audit WDAC

Déployer la stratégie d’audit WDAC via Intune

Maintenant que le organization a créé une stratégie d’audit, il est temps de la déployer à l’aide de Intune gestion des appareils.

  1. Connectez-vous à Intune Centre d’administration.
  2. Dans Intune Centre d’administration, accédez à Appareils, puis Profils de configuration.
  3. Ensuite, créez une plateforme de profil>: Windows 10 ou version ultérieure, modèles de type de profil et personnalisé.
  4. Créez un nom pour la stratégie (par exemple, « Contrôle d’application - Microsoft Allow – Audit ») et sélectionnez Suivant.
  5. Sous Paramètres OMA-URI, sélectionnez Ajouter.

Notes

Ces informations dépendent de l’ID de stratégie généré à partir de l’Assistant Contrôle d’application Windows >Defender pour le code XML de stratégie créé à partir de la section ci-dessus :

- Name = Microsoft Allow Audit
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- Type de données = Base64 (Fichier)

  1. Lorsque l’Assistant Contrôle d’application Windows Defender a généré le XML de stratégie, il a également créé un (GUID). Fichier CIP. Le fichier CIP doit être copié et renommer l’extension de fichier en . BIN, par exemple, {CB46B243-C19C-4870-B098-A2080923755C}.bin.
  2. Chargez le fichier BIN sous Base64 (Fichier).
  3. Sélectionnez Enregistrer.
  4. Suivez les invites pour créer le profil de configuration.
  5. Déployez la stratégie que vous avez créée, par exemple, « Contrôle d’application - Microsoft Allow – Audit », profil de configuration sur le système prévu.

WDAC : auditer la surveillance de la stratégie

Après le cycle de vie de la stratégie WDAC, le organization doit passer en revue les événements générés à partir de la stratégie « Autoriser l’audit Microsoft ». La surveillance de la stratégie d’audit WDAC peut être effectuée avec deux méthodes :

  • ID d’événement Application Control : Les ID d’événement de contrôle d’application sont la méthode traditionnelle d’examen des événements audités sur un système d’exploitation Windows. Ces ID d’événement peuvent être transférés vers un emplacement centralisé à l’aide du transfert du journal des événements Windows ou d’informations de sécurité tierces et de la gestion des événements.

Pour plus d’informations sur les ID d’événement, consultez Présentation des ID d’événement Application Control - Sécurité Windows.

Microsoft recommande d’utiliser l’intégration Microsoft Defender XDR (MDE) pour Microsoft Sentinel. MDE et Sentinel permettent de stocker les données de télémétrie advanced hunting pendant plus de 30 jours par rapport aux Microsoft Defender pour point de terminaison.

Pour plus d’informations sur les connexions et la surveillance, consultez les articles suivants :

Surveillance de WDAC avec Microsoft Defender pour point de terminaison

L’exemple suivant montre qu’un utilisateur a plusieurs applications utilisées pour les tâches quotidiennes d’un organization. L’exemple contient à la fois des applications Microsoft et diverses applications open source.

Comme l’exemple est en mode d’audit de l’application, l’administrateur (mais pas l’utilisateur) peut voir que les événements déclenchés pour WinSCP, VLC, Putty et FileZilla, car ces applications ne font pas partie de la stratégie d’audit initiale.

Maintenant, à l’aide du portail Microsoft Defender, entrez Repérage avancé pour limiter les événements d’audit afin de comprendre quels blocs inattendus/indésirables se produisent si le mode audit est désactivé, et donc mis en mode d’application dans cet exemple.

Capture d’écran de la chasse avancée.

À l’aide du schéma de référence de la page précédente, recherchez tous les événements d’audit de stratégie déclenchés par WDAC au cours des sept derniers jours et présente des informations pertinentes à l’aide de l’exemple de requête KQL (Keyboard Query Language) :

DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

Voici un exemple de sortie utilisant la requête KQL précédente.

Capture d’écran de la sortie De la chasse avancée.

Dans les enregistrements, il y a un rapport détaillé d’informations telles que l’arborescence de processus, le chemin d’accès au fichier, les informations SHA, le signataire et les informations sur l’émetteur.

L’étape suivante consiste à affiner les résultats.

À l’aide de la même requête KQL, ajoutez un autre champ où le nom de fichier de processus d’initialisation est Windows Explorer. La requête KQL affiche les applications exécutées par les utilisateurs dans l’interface graphique utilisateur.

 DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

Voici un exemple de sortie utilisant la requête KQL précédente. Capture d’écran de la sortie de la requête.

L’action de requête KQL a maintenant réduit les informations à un jeu de données plus de gestion. Ce qui peut être vu sont les applications utilisées par les systèmes prévus. Ces applications doivent être ajoutées à la stratégie de l’organization ou être considérées comme ajoutées via le contrôle des modifications de l’organisation.

Notes

KQL est un outil puissant pour afficher des jeux de données non structurés et structurés. Il s’agit simplement d’un exemple d’utilisation de KQL et Microsoft recommande de consulter la documentation suivante : Découvrir le langage de requête de repérage avancé dans Microsoft Defender XDR

WDAC – Mettre à jour la stratégie d’audit

Mettre à jour la stratégie d’audit à l’aide de Microsoft Defender pour point de terminaison et de l’Assistant WDAC

Avec une réduction de nos résultats de recherche à l’aide de KQL, l’étape suivante consiste à mettre à jour la stratégie de base WDAC ou à utiliser une stratégie de supplément. L’exemple suivant utilise des stratégies de supplément.

  1. Ouvrez l’Assistant Contrôle d’application Windows Defender et sélectionnez Créateur de stratégie.

  2. Dans Créateur de stratégie, sélectionnez Format de stratégie multiple et Stratégie supplémentaire, accédez à votre stratégie de base, mettez à jour l’emplacement pour enregistrer votre stratégie supplémentaire, puis sélectionnez Suivant.

  3. Sélectionnez Suivant dans Règles de stratégie.

  4. Dans Règles de signature de stratégie, sélectionnez Règle personnalisée.

  5. Dans conditions de règle personnalisée, de nombreuses options sont disponibles :

    • Règle d’étendue de règle en mode utilisateur/règle en mode noyau
    • Action de règle : Autoriser/Refuser
    • Type de règle
      • Éditeur (recommandé)
      • Fichier
      • File Attribute
      • Application empaquetée
      • Hachis
    • Fichier de référence

Notes

Microsoft recommande d’utiliser des règles basées sur publisher le cas échéant et de revenir aux règles basées sur le hachage pour les fichiers de référence non signés afin d’implémenter le contrôle d’application Essential Eight.

Utilisation de Microsoft Defender pour point de terminaison

  1. Recherchez nom de fichier dans Rechercher , accédez au fichier Informations et téléchargez le fichier. Capture d’écran de la mise à jour de la stratégie d’audit 2.
  2. Inspectez l’enregistrement directement à partir de La chasse avancée et téléchargez le fichier qui télécharge ensuite les fichiers binaires requis. Capture d’écran de la mise à jour de la stratégie d’audit 3.
  3. Avec les fichiers binaires requis, continuez à créer une autre stratégie pour les applications ISV de votre organization.
  4. Dans l’Assistant Contrôle d’application Windows Defender, sélectionnez le type de règle souhaité et accédez aux fichiers binaires de référence de l’étape précédente. L’exemple suivant montre que VLC répond aux informations de l’éditeur requises. Capture d’écran de la mise à jour de la stratégie d’audit 4.

Notes

Microsoft recommande l’émission de l’autorité de certification et du serveur de publication d’être sélective au minimum pour la création d’une règle basée sur un éditeur. Le nom du produit peut être inclus et est recommandé par l’ACSC pour les règles basées sur l’éditeur.

  1. Appuyez sur Suivant , puis sur Créer.
  2. Déployez cette stratégie de supplément en suivant les étapes décrites précédemment dans la section « Déployer la stratégie d’audit du contrôle d’application Windows Defender via Microsoft Intune ».

WDAC – Basculer pour appliquer la stratégie

Pour passer à l’application de la stratégie :

  1. Ouvrez l’Assistant Contrôle d’application Windows Defender et sélectionnez Stratégie Rédacteur.

  2. Accédez au xml de stratégie qui doit être modifié pour être appliqué.

  3. Désactivez le commutateur Mode Audit dans règles de stratégie.

  4. Sélectionnez Suivant dans Règles de stratégie.

  5. Une stratégie de mise à jour est créée avec un numéro de version modifié et un fichier CIP a été créé.

  6. Dans le Centre de Administration Microsoft Endpoint Manager, accédez à Appareils, puis Profils de configuration.

  7. Ensuite, créez un profil, une plateforme Windows 10 ou ultérieure, des modèles de type de profil et des modèles personnalisés.

  8. Créez un nom pour la stratégie, par exemple Contrôle d’application – Appliquer la stratégie, puis sélectionnez Suivant.

  9. Sous Paramètres OMA-URI, sélectionnez Ajouter.

    Notes

    Ces informations dépendent de l’ID de stratégie généré à partir de l’Assistant Contrôle d’application Windows Defender pour le code XML de stratégie créé à partir de la section Créer un audit ci-dessus.

    - Name = Microsoft Allow Enforce
    - OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
    - Type de données = Base64 (Fichier)

  10. Lorsque l’Assistant Contrôle d’application Windows Defender a généré le XML de stratégie, il a également créé un (GUID). Fichier CIP. L’étape suivante consiste à copier ce fichier CIP et à renommer l’extension de fichier en . BIN, par exemple, {CB46B243-C19C-4870-B098-A2080923755C}.bin.

  11. Chargez le fichier BIN sous Base64 (Fichier).

  12. Sélectionnez Enregistrer.

  13. Suivez les invites pour créer le profil de configuration.

  14. Déployer le contrôle d’application : appliquer le profil de configuration de stratégie sur le système prévu.

    Notes

    L’administrateur doit exclure la stratégie d’audit d’application créée précédemment du système prévu qui est basculé pour l’appliquer