1. Contexte métier

En tant qu’ingénieurs en cyberdéfense, notre métier est de contribuer à la protection des données et systèmes de nos clients. Avant de formuler des conseils, il convient déjà de s’appliquer à soi-même les bonnes pratiques. Cet article est donc l’occasion de présenter un modèle de sécurisation de poste de travail pour consultant cybersécurité tout-terrain, avec un focus sur une mesure de durcissement très utile en environnement Windows : Windows Defender Application Control, ou WDAC pour les intimes (notons que depuis janvier 2025, WDAC s’appelle “App Control for Business”, mais comme nous ne savons pas comment cette fonctionnalité s’appellera le mois prochain, nous gardons l’appelation WDAC pour la suite).

Rappelons qu’il n’existe pas d’absolu en sécurité informatique : tout niveau de sécurité correspond en miroir à une acceptation des risques. Une analyse de risques pourra alors répondre à la question de savoir si ce modèle correspond à une cible satisfaisante dans d’autres contextes.

2. Modèle d’architecture du poste de travail à sécuriser

Dans note modèle du parfait poste de travail pour ingénieur en cyberdéfense, nous implémentons l’architecture suivante :

• Un hôte Windows Hyper-V natif (ci-après “l’hôte”), installé directement sur le socle matériel, qui a pour seul rôle d’instancier des machines virtuelles qui vont permettre de répondre aux besoins métiers ;
• Une machine invitée Windows (dite “bureautique”) qui instancie l’environnement bureautique d’entreprise : cette machine virtuelle permet d’utiliser la suite bureautique Office, un navigateur Edge pour accéder aux services en ligne de l’entreprise (SharePoint, consultation Internet des interfaces de gestion - comptabilité, paye, etc.), ainsi que les moyens de communication privilégiés de nos clients (Teams, Tixéo, ou même Zoom pour les plus débridés d’entre eux), et quelques logiciels bien identifiés pour répondre à des cas d’usages spécifiques (par exemple Greenshot pour la prise de capture d’écran de l’auditeur alerte).
• Une machine invitée qui manipule les secrets de l’utilisateur final : gestionnaire de mots de passe et de certificats par exemple.
• D’autres machines invitées répondant à des besoins métiers divers (navigation Internet débridée, développement, etc.).

Pour l’ensemble de ces systèmes, les recommandations classiques de sécurisation s’appliquent quelque soient les surcouches de sécurité qui vont être ajoutées par la suite selon le principe roi de la défense en profondeur.

L’hôte est bien sûr le système le plus durci puisque sa compromission entraine celles des machines invitées. On prend soin notamment, via un paramétrage du pare-feu Windows, de restreindre son accès Internet en autorisant uniquement :

• Le service Windows Update en charge des mises à jour du système via quelques autorisations clefs dans le pare-feu ;
• Les services Hyper-V qui fournissent un accès Internet aux machines virtuelles via des commutateurs virtuels.

Evidemment, on n’installe aucun logiciel tiers sur cet hôte.

La machine “bureautique” permet d’interagir (au moins partiellement) avec Internet via les moyens d’entreprise agréés et les restrictions d’hygiène que nous imposerons (notamment pare-feu).

La machine “coffre” n’instancie pas d’interface réseau virtuelle ce qui induit une absence d’interaction directe avec Internet : on prévoit cependant une mise à jour régulière via une ré-instanciation régulière.

En complément de ce socle de base, nous rajouterons à la volée ou de manière plus pérenne des machines virtuelles connectées ou non à Internet selon le principe de réduction des fonctionnalités inutiles, avec ou sans durcissement propre selon les besoins (l’hygiène de base s’applique en tant que prérequis).

3. Le contrôle d’applications comme composant de la défense en profondeur

(i) Principe du contrôle d’applications

L’objet du contrôle d’applications est de bloquer l’exécution de programmes sur la base de critères discrétionnaires. L’enjeu associé est de réduire les opportunités d’atteinte à la sécurité d’un système qui se manifesterait par :

• L’exécution de programmes malveillants (exécution involontaire par un utilisateur légitime piégé ou imprudent, ou exécution volontaire par un attaquant) ; ou,
• Le détournement d’un programme légitime à des fins offensives par un attaquant.

Le scénario de risque associé est celui d’un attaquant disposant d’un accès préalable au système, ou d’une capacité d’exécution de programme directe ou indirecte (par l’intermédiaire de l’utilisateur final). Le contrôle d’applications s’inscrit donc pleinement dans la famille des mesures de durcissement de sécurité des systèmes informatiques. A titre d’illustration, on peut citer comme mécanismes classiques de contrôle d’applications :

• AppArmor ou SELinux sur Linux ;
• WDAC (Windows Defender Application Control) ou AppLocker sur Windows.

C’est WDAC qui va nous intéresser par la suite.

(ii) Point clef différenciant entre WDAC et AppLocker

AppLocker et WDAC répondent fonctionnellement au même besoin, mais les deux fonctionnalités ne présentent pas les mêmes garanties de sécurité : WDAC offre une sécurité accrue en fournissant un cadre d’application de politiques qui s’intègre au niveau du noyau Windows, contrairement à AppLocker qui opère en espace utilisateur. Ainsi, Microsoft ne considère pas AppLocker comme une fonctionnalité de sécurité, contrairement à WDAC .

Bien que certains contextes métiers spécifiques peuvent justifier l’emploi d’AppLocker plutôt que celui de WDAC (les deux technologies pouvant également s’utiliser conjointement), le choix préférentiel d’un point de vue sécurité restera WDAC.

4. Mise en oeuvre de WDAC

(i) Principes de conception

La difficulté principale réside dans le dualisme d’une sélection restrictive des programmes autorisés à s’exécuter (dans une logique de réduction de la surface d’attaque), et le maintien d’un système utilisable (tant au niveau du socle applicatif, ici Windows, que des logiciels métiers) : une politique WDAC non maîtrisée peut entrainer le “briquage” un système, ou tout simplement d’empêcher un utilisateur d’utiliser son logiciel métier.

La démarche de conception des politiques est un processus itératif impliquant :

• La définition des critères d’autorisation des applications constituant la politique cible ;
• Un déploiement de la politique en mode “audit”, qui n’impose pas de restriction dans l’exécution des programmes en tant que tel : dans ce mode, les applications qui auraient dû être bloquées par la politique sont consignées dans les journaux d’événements Windows permettant ainsi de contrôler le comportement et d’affiner graduellement la politique pou rempêcher tout blocage non voulu.
• Le déploiement de la politique en mode “forcé” : dans ce mode, la politique est effective sur le système cible, et les restrictions d’exécution des programmes s’appliquent.

Ce mode itératif permet de confronter en conditions réelles le comportement du système aux usages métiers. La démarche de déploiement peut être fractionnée en plusieurs phases de niveau d’ambition croissant dans la restriction d’applications (notamment sur des périmètres complexes qui impliquent de nombreux usages métiers).

(ii) Cibles WDAC

Dans notre modèle, nous avons a minima trois politiques WDAC à concevoir, chacune reflétant une stratégie de sécurisation spécifique :

• L’hôte Hyper-V : sa compromission entraîne mécaniquement la compromission de toutes les machines virtuelles instanciées et de leurs données ;
• La machine virtuelle “bureautique” : elle opère les données usuelles d’entreprise à impact réputationnel à défaut d’être très sensibles (les données clients confidentielles ou données d’entreprise plus sensibles sont opérées dans des systèmes d’information dédiés), et elle est exposée à Internet via les logiciels de communication embarqués (le courriel au premier chef) ;
• La machine virtuelle “coffre” qui opère des données de nature à compromettre des accès utilisateurs (comme des mots de passe).

Les systèmes cibles partageant un socle commun (même système d’exploitation avec déploiement manuel ou scripté des logiciels), les mêmes principes de conception vont être appliqués avec : une politique WDAC mère commune (la plus restrictive en termes d’exécution logicielle) et une politique adjointe par système (dite politique “supplemental”) pour ajouter des autorisations applicatives choisies. Cette approche est ensuite réplicable pour toute nouvelle machine invitée Windows.

(iii) Paramétrage WDAC

Une politique WDAC est constituée d’options et de règles. Les options WDAC définissent un comportement du système plus ou moins permissif relativement à une politique. Dans notre contexte, nous faisons la sélection des options suivantes pour notre politique de base en mode “audit” :

• Enabled:UMCI : pour instaurer un blocage au niveau noyau et utilisateur ;
• Required:WHQL : pour n’autoriser que les pilotes signés par l’autorité Microsoft WHQL (Windows Hardware Quality Labs) ;
• Enabled:Audit Mode : pour activer le mode audit (il s’agira ensuite de désactiver l’option pour passer en mode forcé) ;
• Disabled:Flight Signing : pour ne pas autoriser les binaires issus des pre-release Windows ;
• Enabled:Unsigned System Integrity Policy : pour permettre de s’affranchir de la signature des politiques WDAC (choix est fait pour cette première version en production de faire ce compromis de ne pas signer les politiques : la signature des politiques est bien sûr une cible plus satisfaisante en termes de sécurité, mais nécessite d’organiser le processus technique et organisationnel associé) ;
• Enabled:Advanced Boot Options Menu : pour permettre l’utilisation du menu de preboot, toujours dans la logique du recherche de compromis acceptable, cette fois pour permettre un éventuel debug du système ;
• Required:Enforce Store Applications : évidemment nous voulons activer WDAC sur toutes les applications UWP (Plateforme Windows Universelles), notamment celles issues du Windows store car nous n’avons aujourd’hui aucune confiance dans cet outil mercantile et son processus de validation laxiste d’inspiration libéraliste-hippie ;
• Enabled:Allow Supplemental Policies : pour permettre l’extension future de notre politique de base avec une certaine flexibilité et sans altération de la politique mère ;
• Enabled:Dynamic Code Security : pour restreindre l’exécution de code dynamique .NET en mode compilation Just In Time ;
• Enabled:Revoked Expired As Unsigned : les binaires signés avec des certificats révoqués ou arrivés à expiration sont considérés comme non-signés.
• Enabled:Inherit Default Policy : aucun effet aujourd’hui d’après la documentation Microsoft, il faudra sortir un windbg pour aller regarder ca, ici on le fixe arbitrairement.

Nous adapterons par la suite la politique pour passer en mode “forcé” en :

• Supprimant la directive Enabled:Audit Mode ;
• Activant Enabled:Boot Audit on Failure : là encore un compromis assumé pour permettre au poste de travail de démarrer en cas d’échec d’un pilote critique au démarrage du système, WDAC repasse en mode audit si le mode forcé est actif (cette option n’étant activable qu’en mode forcé).

Des choix liés à notre contexte d’usage relativement simple sont évidemment à revoir dans des environnements métiers plus complexes qui invitent à plus de flexibilité (pour illustration, la règle Enabled:Managed Installer qui autorise le déploiement d’application par un installeur géré - managed installer - va s’inscrire comme un prérequis dans de nombreux cas d’usage au prix d’un compromis sécurité-fonctionnalité).

(iv) Conception de la politique de base

Le deuxième volet de la stratégie WDAC est l’écriture des règles qui vont s’appliquer vis-à-vis des binaires pour autoriser ou non leur exécution. Ces règles attribuent un niveau de confiance à un programme selon différents niveaux de granularité et de permissivité : par exemple, une approbation sur base d’un certificat signataire reconnu, sur un contrôle de condensat, sur une arborescence, etc. Les règles permettent de définir une approbation (mode “allow”, le binaire est autorisé) ou un refus d’exécution (mode deny, l’exécution de binaire est explicitement refusée). Celles-ci sont combinables, et des règles de précédence s’appliquent en cas de conflit.

L’efficience d’une stratégie WDAC repose sur un bon équilibrage au regard du contexte métier (n’est-ce pas toujours le cas ?) en prenant en compte les contraintes associées à la mise à jour des applicatifs, au maintien de logiciels historiques, etc. Nous sommes ici dans un contexte de bisounours de l’IT avec peu d’applicatifs, des technologies récentes, et des utilisateurs éclairés : nous allons faire simple sur l’écriture de ces règles pour une première version.

Microsoft fournit des politiques WDAC prête à l’emploi. Il est aisé de repartir de celles-ci pour un premier jet. Les politiques sont livrées sous la forme de fichiers XML, donc aisément manipulables. La structure du fichier XML et les contraintes applicables (nomenclature, typage, etc.) sont observables dans le fichier de schéma XML “cipolicy.xsd” embarqué dans l’arborescence Windows ($Env:SystemDrive\Windows\schemas\CodeIntegrity\cipolicy.xsd).

On choisit la politique “DefaultWindows_Audit” comme inspiration pour créer la politique commune à tous nos systèmes. Cette politique contient notamment une liste de certificats références EKU (Extended Key Usage, les EKU correspondent à des extensions de certificats numériques qui spécifient les usages pour lesquels une clé de signature est valide). Ces certificats permettent d’autoriser (en mode allow) l’exécution des binaires signés par l’autorité associée (en l’occurrence, Microsoft sur cette politique “DefaultWindows_Audit”), ou non-signés mais présents au sein d’un catalogue de binaires signé par l’autorité.

Ci-dessous, les EKUs embarqués dans la politique DefaultWindows_Audit.xml.

Pour aller un peu plus loin avec les EKUs, on pourra se référer à cet article.

Dans la politique “DefaultWindows_Audit”, ne sont référencés que des certificats provenant d’autorités de certification (CA) intrinsèquement fiables pour Windows (autorités de certification racines préinstallées dans le magasin de certificats Windows et que l’on identfie avec le typage wellknown dans le fichier XML). La politique “DefaultWindows_Audit” constitue donc un début, mais dans notre contexte, certaines références heurtent notre sensibilité de puristes, et nous allons enlever les références aux certificats :

• En lien avec les applications du Microsoft Store : concrètement on ne veut pas que les applications du Microsoft Store puisse s’exécuter, même celles qui pourraient êtres embarquées nativement ;
• De type Windows insiders (Flighting related signers) : dans un environnement de production un peu conservateur, on n’utilisera pas les fonctionnalités du programme Insiders soit les fonctionnalités expérimentales de Windows ;
• De type test signer : laissons Microsoft faire ses tests, on ne veut pas des binaires associés !

Voilà qui est déjà légèrement mieux, on respire déjà un peu moins mal avec ce premier fichier de configuration WDAC qui commence à être un peu plus restrictif. On va ajouter à ce jeu de règles un complément non négligeable : Microsoft documente une liste de contournements de WDAC et fournit une politique permettant de s’en prémunir. Nous allons donc fusionner cette politique fournie par Microsoft avec notre premier jeu de règles. Comme notre jeu inclut déjà des règles d’autorisation, nous pouvons extraire uniquement les règles de refus de la politique Microsoft (règles deny) pour la fusionner avec notre précédente production grace à une petit commande de notre magnifique terminal PowerShell (oxymore) :

PS> Merge-CIPolicy -OutputFilePath DfsoBasePolicy.xml -PolicyPaths ".\DfsoBasePolicy-AllowEKUs-0.1.xml" , ".\Microsoft-WDAC-Bypass-Deny-0.1.xml"

Ensuite c’est parti pour appliquer le résultat en convertissant préalablement le XML en un format binaire ingérable par l’OS via les bonnes cmdlets. Nous appliquons donc cette politique sur l’ensemble des trois systèmes à durcir : hôte, coffre, et bureautique.

PS> $WDACPolicyXMLFile = "$env:userprofile\Templates\DfsoBasePolicy.xml"
PS> [xml]$WDACPolicy = Get-Content -Path $WDACPolicyXMLFile
PS> $PolicyID = $WDACPolicy.SiPolicy.PolicyID
PS> $PolicyBinary = "$env:userprofile\Templates\$PolicyID"+".cip"
PS> ConvertFrom-CIPolicy -XmlFilePath $WDACPolicyXMLFile -BinaryFilePath $PolicyBinary
C:\Users\dfso\Templates\{6E3EB6B2-4061-4C75-BF30-4C20B17BEA73}.cip
PS> CiTool --update-policy $PolicyBinary

On a conservé le mode “audit” à ce stade vu qu’on n’est jamais vraiment à l’aise avec Windows, ça peut vite déraper. Pour les plus casse-cou, on désactive évidemment le mode audit et le menu de preboot en cas de briquage, histoire d’être sûr de ne plus pouvoir brouillonner le moindre PowerPoint au redémarrage : on n’aura plus de travail, mais c’est peut être le chemin vers la liberté.

(v) Analyse des journaux d’évènements en mode “audit”

Maintenant on regarde ce qu’il se passe. Déjà tout semble fonctionner après le reboot : on aura donc évité le briquage, mais ce n’est que partie remise. Regardons les journaux d’évènements de l’enfer dans le gestionnaire d’évènements Windows pour voir les trous dans la raquette fonctionnelle (journaux d’évènements ou logs pour les plus anglo-saxons d’entre-nous, je les pardonne). Sans surprise, il y en a une ribambelle qu’on retrouve dans le gestionnaire d’évènements sous Applications and Services logs > Microsoft > Windows > CodeIntegrity > Operational. Dans ces journaux, Windows, grand prince, nous notifie de sa magnanimité quant à l’exécution autorisée des programmes qui seraient bloqués si nous passions en mode forcé, ainsi que des éléments permettant de déboguer WDAC le cas échéant.

C’est donc chacun des évènements qu’il faut revoir pour savoir si nous souhaitons conserver le blocage et donc se priver de son usage. Sinon, il faut ajouter une exclusion à notre politique de blocage pour permettre malgré tout à votre consultant préféré de finir ses slides (en réalité PowerPoint est déjà autorisé si vous avez bien suivi, sinon relisez ce qui précède).

(vi) Construction des politiques de surcharge

Bon, ici on a l’impression qu’on a vraiment envie de travailler vu l’effort qu’on met en pro-bono pour rédiger ce billet… Maintenant, on ne touche plus à la politique socle qui intègre globalement l’environnement Windows et les anti-countournements suggérés par Microsoft (qui a osé dire “bypass” ???). Celle-ci équipera notre hôte et toutes les machines virtuelles concernées. Il faut donc maintenant s’attaquer aux machines invitées qui vont disposer chacune de leur propre politique additionnelle (ou supplemental) adaptée à leur contexte et outils métiers.

Il existe différentes méthodes d’autorisation des programmes, par exemple :

• Autoriser uniquement les applications signées par des certificats spécifiques : c’est ce que nous avons déjà fait pour notre politique de base en faisant confiance aux EKU Microsoft ;
• Autoriser uniquement les applications signées par des certificats d’éditeurs donnés : on est sur une variante plus laxiste que la précédente option (on fait explicitement confiance à l’éditeur pour bien protéger ses clefs de signature, c’est donc à vos risques et péril) ;
• Autoriser les condensats de fichiers : chaque fichier autorisé voit son condensat inscrit dans la politique et celui-ci est contrôle à l’exécution ainsi que ses dépendances (attention, ca casse en cas de mise à jour dudit programme) ;
• Et d’autres encore, mais loin de nous l’envie de vous souffler de trop mauvaises pratiques : le lecteur curieux pourra combler le vide par sa sagacité et ses envies de disruption 5.0.

N’oubiez pas que les stratégies sont cumulatives selon les options : il y a donc des compromis acceptables qui peuvent être faits. Ici, nous allons travailler modestement programme par programme puisqu’on a déjà un socle système fonctionnel par conception, et que nous utilisons un nombre restreint d’applications hors écosystème professionnel Microsoft : cela reste ici abordable pour nos trois machines virtuelles. Nous irons néanmoins droit au but avec un seul exemple illustratif et simple pour la suite du billet. Dans un parc de plusieurs milliers de machines, nous pourrions bien sûr avoir envie d’une stratégie différente.

Vu que nous utilisons un gestionnaire de mot de passe, nous allons par exemple autoriser KeePass dans la politique de la machine “coffre”. On choisit le format d’autorisation par condensats, ce qui nous obligera à chaque mise à jour mettre à jour la politique. Evidemment, nous scripterons l’approche pour démontrer à notre client combien nous sommes agiles et résilients face aux mises à jour. On utilise notamment la cmdlet New-CIPolicy avec l’argument --ScanPath : le lecteur (oui c’est vous !) n’hésitera pas à lire le manuel.

PS> New-CIPolicy -MultiplePolicyFormat -ScanPath 'C:\Program Files\KeePassXC\' -UserPEs -NoScript -FilePath KeePassXC-0.1.xml -Level Hash
PS> Set-CIPolicyIdInfo -FilePath ".\KeePassXC-0.1.xml" -SupplementsBasePolicyID "{6e3eb6b2-4061-4c75-bf30-4c20b17bea73}" -PolicyName "Allow-KeePassXC"

Une fois le fichier XML généré, on produit le format binaire de la politique puis on l’applique.

Une fois ceci fait, on retourne dans les journaux d’évènements CodeIntegrity : on contrôle que notre KeePass n’apparait plus, puis on s’attaque au logiciel suivant. C’est sans fin ou presque : je vous laisse poursuivre sans moi, j’ai déjà donné.

(vii) Déploiement effectif de notre politique WDAC

Il serait temps d’appliquer enfin la politique : à ce stade, à part générer des évènements dans les journaux, nous n’avons pas fait grand chose. Ne nous contentons pas des promesses : soyons des consultants productifs !

Les modes de déploiement possibles des politiques WDAC incluent :

• Un déploiement via une solution de gestion des appareils mobiles, typiquement Intune ;
• L’usage de Microsoft Configuration Manager ;
• Un déploiement via les politiques de groupes (GPO) ;
• Un déploiement scripté.

Le mode de déploiement choisi doit évidemment s’inscrire en cohérence avec le contexte métier. Dans notre cas d’usage comprenant un petit parc informatique et des individus aguerris au terminal en noir et blanc (ce billet est évidemment écrit avec vi), l’option naturelle est bien l’usage de PowerShell.

Une fois satisfaits de notre politique en mode audit, le passage en mode forcé est très simple grace à la cmdlet CiToolparée de son plus bel argument --update-policy. On reprend les fichiers générés précédemment en commençant par la politique socle commune à tous nos systèmes, on enlève le mode audit (Set-RuleOption avec -Option 3 -Delete), et c’est parti.

PS> $WDACPolicyXMLFile = ".\DfsobasePolicy.xml"
PS> Set-RuleOption -FilePath $WDACPolicyXMLFile -Option 3 -Delete
PS> [xml]$WDACPolicy = Get-Content -Path $WDACPolicyXMLFile
PS> $PolicyID = $WDACPolicy.SiPolicy.PolicyID
PS> $PolicyBinary = "$env:userprofile\Templates\$PolicyID"+".cip"
PS> ConvertFrom-CIPolicy -XmlFilePath $WDACPolicyXMLFile -BinaryFilePath $PolicyBinary
C:\Users\dfso\Templates\{6E3EB6B2-4061-4C75-BF30-4C20B17BEA73}.cip
PS> CiTool --update-policy $PolicyBinary
Operation Successful
Press Enter to Continue

On vérifie avec ` CiTool` que notre politique est bien forcée.

C’est l’heure de croiser les doigts et de redémarrer. Ensuite il faut répéter l’opération pour les politiques socle et additionnelles pour tous les systèmes.

4. Epilogue

Le système redémarre, et on remarque à l’ouverture de session l’agressive fenêtre bleue qui nous informe qu’une application non souhaitée est bloquée.

L’inconvénient c’est qu’à l’usage on se sent un peu agressé par ces visuels qui reviennent de temps à autres (dès qu’un programme non autorisé est lancé… oups, c’était le but) et qui nous rappelle le nombre indécent de programmes qui tournent dans notre dos (en plus de l’OS qui est volontairement autorisé). Nous pouvons cependant repartir l’esprit léger avec la sensation du devoir accompli. Pour s’en convaincre définitivement (la conscience de l’auditeur qui s’exprime), on retourne dans les journaux, et on constate tous les évènements WDAC, parés cette fois-ci de gros points d’exclamation rouges.

On est content. Nous ne pouvons plus visualiser d’images avec la visionneuse intégrée native Windows, preuve qu’on y a été un peu fort, mais notre petit côté extrémiste de la sécurité aime bien ça malgré le handicap que cela peut représenter en cas de visio inoppinée avec nos clients préférés (relisons l’introduction : nous avons évoqué une acceptation des risques, donc nous acceptons la contrainte et ne souhaitons surtout pas y remédier ; si on ne voulait pas s’embêter on aurait installé un Ubuntu et on serait devenu consultant en strat).

Il reste évidemment encore plein de choses à faire pour renforcer notre sensation de sécurité. Tout bon consultant qui se respecte étant biberonné à la roue de Deming, il faudra bien sûr penser à la gestion évolutive des politiques, et au cycle d’amélioration continue, et il y a de quoi faire. La suite donc peut-être dans un prochain épisode.