Intégrité de la mémoire HVCI : vérifier pilotes, exécution et verrou UEFI

Qu’est-ce que l’intégrité de la mémoire HVCI ?

L’intégrité de la mémoire HVCI est une protection Windows qui exécute l’intégrité du code noyau dans l’environnement isolé fourni par la sécurité basée sur la virtualisation (VBS). Son déploiement exige trois réponses distinctes : quelle configuration est souhaitée, si l’intégrité de la mémoire fonctionne réellement sur chaque appareil cible, et si la récupération reste possible après le choix du mode de verrouillage UEFI. Une GPO de domaine ne répond qu’à une partie de la première question. Guide d’activation Microsoft

Pour une équipe AD, le résultat utile est un déploiement testé, accompagné de preuves par appareil. Commencez par une population représentative, résolvez les dépendances des pilotes, mesurez le service après redémarrage et consignez la décision de verrouillage. Incluez dans le rapport les machines qui n’ont pas pu être mesurées ; les omettre silencieusement donne à la couverture de la politique l’apparence d’une protection vérifiée.

Ce guide utilise la documentation Microsoft Learn vérifiée le 3 octobre 2026 et les deux contrôles du collector décrits ci-dessous. Les commandes Windows sont des exemples documentaires ou des adaptations en lecture seule identifiées comme telles ; elles n’ont pas été exécutées sur un parc Windows pour cet article. Aucune couverture du parc ni aucun test de compatibilité réussi ne sont revendiqués.

Notre guide Credential Guard après une mise à niveau utilise la même méthode de preuve WMI pour un autre service : l’isolation de certains secrets. L’intégrité de la mémoire concerne l’intégrité du code noyau. La preuve qu’un service fonctionne ne démontre pas que l’autre fonctionne.

Distinguer politique, état d’exécution et verrouillage UEFI

Un même nombre a des significations différentes selon le paramètre. La référence de politique VirtualizationBasedTechnology de Microsoft documente le mode de politique et sa correspondance avec la GPO Device Guard. La page d’activation documente séparément les valeurs locales Enabled et Locked.

Les chemins locaux du tableau se trouvent sous HKLM\SYSTEM\CurrentControlSet\Control. La valeur de politique se trouve sous HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. N’écrivez pas Enabled=2 pour reproduire le mode sans verrouillage de la politique. N’interprétez pas un identifiant de service WMI comme un mode du registre. Conservez le chemin complet et le nom de la valeur dans les preuves afin qu’un autre administrateur puisse les interpréter sans reconstituer la collecte.

Un dossier de changement utile conserve l’intention de la politique, la politique appliquée, les paramètres locaux et l’observation de l’exécution dans des champs distincts. Si une GPO indique un mode et qu’un poste en affiche un autre, examinez la configuration appliquée avant de déclarer le changement terminé. Si les paramètres concordent mais que l’exécution diffère, examinez le poste au lieu de modifier à répétition la même GPO.

Le verrouillage UEFI modifie aussi la décision de récupération. La procédure GPO de Microsoft propose un déploiement sans verrouillage et avertit que le choix du mode verrouillé restreint la désactivation à distance. Déterminez qui peut accéder au menu du firmware et restaurer la machine avant d’intégrer cette restriction à l’administration de production. Instructions GPO de Microsoft

Détection : recueillir les preuves sur l’appareil cible

Utilisez une session PowerShell avec élévation de privilèges sur la cible. Microsoft fournit cette commande dans sa référence Win32_DeviceGuard :

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

L’adaptation suivante, en lecture seule, sélectionne les champs nécessaires à cette investigation :

$state = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
$state | Select-Object SecurityServicesConfigured, SecurityServicesRunning, VirtualizationBasedSecurityStatus

Interprétez les tableaux de services par appartenance. Un résultat contenant à la fois 1 et 2 inclut l’intégrité de la mémoire ; 1 identifie Credential Guard. VirtualizationBasedSecurityStatus=2 décrit une VBS en cours d’exécution, tandis que la présence de 2 dans SecurityServicesRunning identifie l’intégrité de la mémoire en cours d’exécution. Définitions Microsoft des propriétés WMI

Traitez la collecte comme une observation associée à un hôte, une heure et un contexte de démarrage. Conservez les tableaux complets, même si le tableau de bord affiche ensuite un booléen. Distinguez une requête réussie sans intégrité de la mémoire d’une requête qui a échoué. Les échecs d’authentification, les appareils injoignables et les sorties manquantes appartiennent à une catégorie inconnue assortie d’une action de suivi.

Comparer la politique et les paramètres locaux de verrouillage

Cette adaptation PowerShell en lecture seule lit les paramètres nommés ; les chemins ou valeurs manquants doivent être consignés comme absents, sans être remplacés silencieusement par zéro :

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard' -Name HypervisorEnforcedCodeIntegrity
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity' -Name Enabled, Locked
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard' -Name EnableVirtualizationBasedSecurity, RequirePlatformSecurityFeatures, Locked

Comparez ces observations au mode approuvé et à un rapport de stratégie résultante pour cet hôte. Un paramètre exporté d’une GPO sans rapport avec la cible ne prouve pas que celle-ci l’a reçu. Consignez les configurations contradictoires et les erreurs de collecte au lieu de les transformer en un simple score protégé/non protégé.

Les propriétés documentées de Win32_DeviceGuard ci-dessus ne fournissent pas de propriété Locked. Lisez séparément les marqueurs du registre nommés. Ils décrivent la configuration du verrouillage et ne doivent pas être présentés comme une attestation indépendante du firmware. De même, un résultat CIM indiquant que l’intégrité de la mémoire fonctionne ne prouve pas que le verrouillage UEFI est effectif. Référence Microsoft de configuration et de validation

Compatibilité des pilotes : concevoir un pilote de déploiement qui exerce le travail réel

Le guide Microsoft de compatibilité des pilotes combine les contrôles Code Integrity dans Driver Verifier, les tests fonctionnels avec l’intégrité de la mémoire activée et le Windows HLK HyperVisor Code Integrity Readiness Test. Il distingue l’aptitude à la signature des tests fonctionnels approfondis. Un pilote chargé lors d’un démarrage n’a pas nécessairement exercé tous les chemins d’exécution pertinents.

Pour le responsable d’un pilote ou une équipe d’ingénierie, la commande documentée du vérificateur est :

verifier.exe /flags 0x02000000 /driver <driver.sys>

Remplacez l’emplacement réservé par le pilote choisi dans un environnement de test récupérable. Driver Verifier est un outil de test, pas une commande à distribuer sans discernement aux postes de production. Consignez le pilote sélectionné, les conditions de test, les constats et le chemin de récupération. Traitez les échecs avec le fournisseur du pilote au lieu de considérer une désactivation permanente comme la seule solution.

Pour l’équipe de déploiement, construisez une matrice des modèles d’appareils, révisions du firmware, builds Windows, packages de pilotes et processus métier. Incluez les combinaisons réellement présentes dans la population cible. Choisissez des machines pilotes qui révèlent des différences significatives ; un ensemble commode de portables identiques peut laisser d’autres familles de matériel sans test.

Testez le travail que ces machines doivent réaliser : démarrage, périphériques, applications requises et opérations dépendant de leurs pilotes. Définissez les résultats attendus avant de commencer et rattachez les échecs à un package et à un responsable identifiés. Il s’agit de recommandations de déploiement, pas d’une affirmation qu’une application ou un appareil précis de votre environnement est incompatible.

Attribuez à chaque exception un motif, une population concernée, un responsable, un correctif prévu et une date de révision. Distinguez un échec de compatibilité démontré de l’hypothèse qu’une ancienne exception reste nécessaire. Demandez aux fournisseurs un package mis à jour ou des preuves de test, puis réexécutez le processus pertinent avec l’intégrité de la mémoire active. L’inventaire des exceptions délimite la prochaine vague de déploiement.

Remédiation : déployer la GPO par étapes et prouver le résultat après redémarrage (Remediation)

1. Approuver la population et le plan de récupération

Désignez des responsables pour l’examen du matériel, les tests des pilotes, les changements GPO et la récupération. Consignez le mode de verrouillage souhaité, le périmètre pilote et les exclusions avant de modifier la politique. Fixez une règle d’acceptation exigeant à la fois une observation de l’exécution et la réussite des processus requis ; la seule création d’une GPO ne doit pas clore la tâche.

Pour les postes d’administration, inscrivez cette décision dans l’architecture plus large décrite par notre guide ANSSI Active Directory : chemins d’administration, usage dédié et frontières de confiance. Le durcissement d’une fonctionnalité Windows ne démontre pas la solidité de l’architecture d’administration et n’établit pas la conformité ANSSI.

2. Appliquer une configuration prise en charge à un périmètre défini

Suivez la procédure GPO de Microsoft sous Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Activez la politique et sélectionnez l’option souhaitée sous Virtualization Based Protection of Code Integrity. Liez et filtrez la GPO pour la population pilote approuvée ; examinez la politique appliquée à la cible avant d’étendre le périmètre. Procédure de déploiement Microsoft

La commande documentée de rafraîchissement de la politique, exécutée depuis une Command Prompt avec élévation de privilèges, est :

gpupdate /force

Planifiez un redémarrage pour la collecte des preuves du pilote. Après le démarrage, répétez l’observation CIM et la comparaison des paramètres locaux. Consignez les tableaux et le mode observés avec la demande de changement. Ne déduisez pas un résultat pour tout le parc d’une seule machine réussie ; chaque cible non mesurée conserve son propre état non résolu.

3. Documenter la récupération avant de choisir le verrouillage UEFI

En cas d’instabilité après activation, la procédure de dépannage de Microsoft commence par la désactivation des politiques qui activent la fonction, puis l’utilisation de Windows Recovery Environment (Windows RE) pour mettre la valeur Enabled du scénario à 0 et redémarrer. La commande documentée est :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 0 /f

Construisez la procédure de récupération propre à la machine autour de cette démarche. Validez l’accès à Windows RE et au registre de l’installation concernée, identifiez l’opérateur et testez le retrait de la politique d’activation. Ne supposez pas qu’une modification ordinaire du registre à distance peut récupérer une machine qui ne démarre pas.

Avec le verrouillage UEFI, Microsoft exige en plus la désactivation de Secure Boot pour achever ces étapes de récupération. Cette exigence intègre l’accès au firmware dans le plan. Ne choisissez le verrouillage que lorsque le chemin de récupération physique, l’opérateur autorisé et la procédure de retour arrière sont documentés. Incluez dans la procédure la restauration de la configuration approuvée du firmware et une nouvelle validation. Guide Microsoft de récupération

4. Étendre le déploiement à partir des preuves conservées

Examinez les observations et les échecs du pilote avant la vague suivante. Conservez les exceptions et les appareils inconnus dans le même inventaire que les mesures réussies. Revérifiez après les changements pertinents de pilotes ou de plateforme. Un dossier de clôture utile contient la politique approuvée, le périmètre cible, le contexte de démarrage, les preuves du service en cours d’exécution, le résultat du test fonctionnel et le responsable de la récupération.

Comment EtcSec détecte cette configuration

L’etc-collector d’EtcSec expose deux contrôles de configuration GPO pour ce sujet. Le comportement suivant provient de leurs branches Detect() réelles, pas d’un test de poste :

gpoSetsAtLeast et gpoMaxValue parcourent les GPO collectées, sautent les objets de politique/paramètres manquants et ignorent les valeurs non renseignées. Le maximum commence à -1. Le parseur Registry.pol associe un DWORD nommé HypervisorEnforcedCodeIntegrity dans une clé contenant deviceguard à HVCIEnabled. Il ne recueille pas les mesures distinctes Enabled et Locked du scénario d’exécution.

Le maximum est un agrégat numérique, pas un classement de sécurité ni un calcul de précédence GPO. Si une politique vaut 1 et une autre 2, le maximum est 2 et le contrôle Low se déclenche. Les valeurs supérieures à 2 entrent également dans cette même branche de constat, car le code ne valide pas l’énumération. Elles ne constituent pas des modes de verrouillage valides documentés et doivent être examinées comme des données inattendues.

Count 1 est le nombre de constats du détecteur, pas un nombre de postes exposés. Aucun des deux contrôles ne calcule le Resultant Set of Policy (RSoP) par machine, n’évalue les liens/filtres GPO ni n’interroge l’exécution via WMI. Un paramètre positif n’importe où peut supprimer le contrôle OFF même si la couverture cible est incomplète. Une valeur GPO absente peut coexister avec une activation par un autre mécanisme ; elle ne démontre pas que l’intégrité de la mémoire est désactivée à l’exécution.

Utilisez ces contrôles pour commencer l’investigation des politiques, puis ajoutez des preuves indépendantes provenant des appareils. Les noms et commentaires des détecteurs ne prouvent pas à eux seuls la conformité ANSSI, le verrouillage réel du firmware, la compatibilité des pilotes ni la réussite de la protection sur tout le parc. Ces conclusions exigent leurs propres preuves et leur propre examen.

Sources

• Microsoft Learn : activer l’intégrité de la mémoire, GPO, registre, WMI et récupération
• Microsoft Learn : compatibilité des pilotes avec l’intégrité de la mémoire et VBS
• Microsoft Learn : valeurs de politique VirtualizationBasedTechnology et correspondance GPO