VBS, intégrité de la mémoire (HVCI) et Kernel DMA Protection

Dès qu'un attaquant exécute du code dans le noyau Windows, la plupart des autres défenses deviennent négociables : il peut désactiver les outils de sécurité, lire LSASS et se dissimuler. Trois fonctionnalités adossées au matériel s'y opposent :

• La sécurité basée sur la virtualisation (VBS) utilise l'hyperviseur Windows pour créer un environnement isolé (Virtual Trust Level 1) que le noyau normal ne peut ni lire ni modifier.
• L'intégrité de la mémoire, aussi appelée intégrité du code protégée par l'hyperviseur ou HVCI, exécute les contrôles d'intégrité du code noyau à l'intérieur de VBS. Les pages de mémoire du noyau sont inscriptibles ou exécutables, jamais les deux, et seul du code signé peut devenir exécutable, même si le noyau est compromis.
• Kernel DMA Protection utilise l'IOMMU pour empêcher les périphériques externes branchés sur des ports Thunderbolt, USB4 ou PCIe enfichables à chaud de lire ou d'écrire la mémoire par accès direct à la mémoire (DMA).

Le guide pilier sur le durcissement de BitLocker mentionne la protection DMA dans le cadre de la chaîne de démarrage, et le guide Credential Guard couvre l'isolation des identifiants qui s'exécute au-dessus de VBS. Ce guide déploie VBS et l'intégrité de la mémoire sur un parc et fait de Kernel DMA Protection un élément de votre standard matériel. Le reste de la série se trouve sur la thématique BitLocker & sécurité du démarrage.

Prérequis

Windows 11 sur du matériel conforme à sa configuration minimale prend en charge les trois. Beaucoup de postes fixes et de portables anciens n'ont pas Kernel DMA Protection, même quand VBS fonctionne.

Étape 1 : vérifier l'état de préparation

Sur un échantillon de chaque modèle matériel, msinfo32 > System Summary affiche Virtualization-based security, Kernel DMA Protection et la liste des services VBS configurés et en cours d'exécution. Les mêmes données en PowerShell :

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
$dg.VirtualizationBasedSecurityStatus     # 0 off, 1 enabled but not running, 2 running
$dg.AvailableSecurityProperties           # 1 hypervisor, 2 Secure Boot, 3 DMA protection, 7 MBEC/GMET, ...
$dg.SecurityServicesConfigured
$dg.SecurityServicesRunning               # 1 Credential Guard, 2 memory integrity, 3 System Guard Secure Launch

Pour les pilotes, l'application Sécurité Windows, sous Device security > Core isolation details, liste les pilotes incompatibles qui empêchent l'intégrité de la mémoire. À l'échelle d'un parc, la méthode la plus fiable est une phase d'audit : activez l'intégrité de la mémoire sur un anneau pilote par modèle matériel et consultez le journal Microsoft > Windows > CodeIntegrity > Operational pour repérer les pilotes dont le chargement est bloqué. Mettez-les à jour ou remplacez-les avant le déploiement large. Les coupables habituels sont les vieux utilitaires matériels, les moteurs anti-triche, les anciens pilotes VPN et de virtualisation, et les outils constructeurs non maintenus.

Étape 2 : activer VBS et l'intégrité de la mémoire par stratégie de groupe

Chemin GPO : Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, réglé sur Enabled :

Le verrou UEFI stocke le paramètre dans une variable du micrologiciel : il ne peut plus être désactivé en modifiant le registre ou la stratégie, et le retirer plus tard exige une procédure documentée avec présence physique. Commencez sans lui.

Équivalents registre, pour les images ou les appareils hors domaine :

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
  EnableVirtualizationBasedSecurity   REG_DWORD 1
  RequirePlatformSecurityFeatures     REG_DWORD 1 (Secure Boot) or 3 (Secure Boot and DMA protection)

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity
  Enabled                             REG_DWORD 1
  Locked                              REG_DWORD 0 (no UEFI lock) or 1

Un redémarrage est nécessaire. Sous Windows 11, Kernel-mode Hardware-enforced Stack Protection est une option supplémentaire d'isolation du noyau qui s'appuie sur l'intégrité de la mémoire et la prise en charge des shadow stacks par le processeur ; évaluez-la une fois l'intégrité de la mémoire stabilisée.

Étape 3 : l'équivalent Intune

Dans le catalogue de paramètres, les catégories Device Guard et Virtualization Based Technology portent les mêmes paramètres :

• Enable Virtualization Based Security et Require Platform Security Features (Policy CSP DeviceGuard/EnableVirtualizationBasedSecurity, DeviceGuard/RequirePlatformSecurityFeatures).
• Hypervisor Enforced Code Integrity : désactivé, activé avec verrou UEFI, ou activé sans verrou (Policy CSP VirtualizationBasedTechnology/HypervisorEnforcedCodeIntegrity, valeurs 0, 1 et 2).
• Require UEFI Memory Attributes Table (VirtualizationBasedTechnology/RequireUEFIMemoryAttributesTable).

Endpoint security > Account protection expose aussi Credential Guard. Évitez de configurer le même paramètre dans deux profils, ou à la fois par GPO et Intune sur les appareils hybrides : les conflits laissent les appareils en état d'erreur.

Ajoutez Require code integrity sous Device Health dans votre stratégie de conformité pour signaler l'intégrité du code attestée ou conditionner l'accès à celle-ci.

Étape 4 : Kernel DMA Protection

Kernel DMA Protection est activé par le micrologiciel, pas par Windows. Votre rôle : acheter du matériel qui en dispose, le garder activé et décider du traitement des périphériques incompatibles.

1. Standard matériel : exigez Kernel DMA Protection: On dans msinfo32 comme critère d'achat pour tous les portables et pour les postes fixes dotés de Thunderbolt ou USB4.
2. Paramètres du micrologiciel : gardez VT-d / AMD-Vi et l'IOMMU activés ; ils peuvent être désactivés dans la configuration du BIOS, raison de plus pour définir un mot de passe du micrologiciel.
3. Stratégie d'énumération : GPO Computer Configuration > Administrative Templates > System > Kernel DMA Protection > Enumeration policy for external devices incompatible with Kernel DMA Protection. Les options sont Block all, Only while logged in (comportement par défaut) et Allow all. Choisissez Block all pour les appareils à risque élevé, en sachant que certaines stations d'accueil et certains périphériques anciens dont les pilotes ne prennent pas en charge le remappage DMA cesseront de fonctionner. Intune : Policy CSP DmaGuard/DeviceEnumerationPolicy (0 tout bloquer, 1 uniquement après l'ouverture de session, 2 tout autoriser).

Pour les appareils sans Kernel DMA Protection, compensez :

• BitLocker avec TPM et PIN pour les utilisateurs à risque élevé, afin que les clés ne soient pas en mémoire avant l'authentification.
• Le paramètre BitLocker Disable new DMA devices when this computer is locked sous Windows Components > BitLocker Drive Encryption.
• Désactivez Thunderbolt ou réglez son niveau de sécurité dans le micrologiciel là où les stations d'accueil ne sont pas utilisées.

Ce qui casse

• Les pilotes noyau incompatibles ne se chargent plus quand l'intégrité de la mémoire est activée ; le matériel qui en dépend perd des fonctionnalités, et un pilote de stockage ou de sécurité critique pour le démarrage peut empêcher le système de démarrer. Pilotez toujours par modèle.
• Les hyperviseurs et émulateurs tiers doivent s'exécuter sur la Windows Hypervisor Platform une fois VBS activé ; les versions actuelles des principaux produits le font, les anciennes non.
• Performances sur les processeurs sans MBEC/GMET, en particulier pour les jeux et les charges graphiques.
• Le verrou UEFI ralentit le retour arrière. Laissez-le désactivé tant que le parc n'est pas stable.
• Stations d'accueil et périphériques sans pilotes compatibles avec le remappage DMA ne sont plus énumérés avec Block all.

L'intégrité de la mémoire complique aussi les attaques par pilotes ; combinez-la avec la liste de blocage des pilotes vulnérables, appliquée automatiquement sur les appareils où l'intégrité de la mémoire est activée, et avec App Control for Business pour le code en mode utilisateur.

Vérifier

Sur l'appareil :

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
[pscustomobject]@{
  VBS              = $dg.VirtualizationBasedSecurityStatus -eq 2
  MemoryIntegrity  = $dg.SecurityServicesRunning -contains 2
  CredentialGuard  = $dg.SecurityServicesRunning -contains 1
  DmaAvailable     = $dg.AvailableSecurityProperties -contains 3
}

Confirmez Kernel DMA Protection: On dans msinfo32 pour le modèle matériel. Collectez les mêmes valeurs sur tout le parc et alertez sur les appareils où VBS est configuré mais ne s'exécute pas : cela signifie généralement que la virtualisation a été désactivée dans le micrologiciel, qu'une réinitialisation du BIOS a eu lieu ou qu'un pilote incompatible a été installé.

Liste de contrôle

• Inventaire matériel : compatibilité VBS, MBEC/GMET, IOMMU et Kernel DMA Protection par modèle
• Pilotes incompatibles identifiés lors d'une phase pilote, puis mis à jour ou supprimés
• VBS et intégrité de la mémoire imposés par GPO ou Intune, verrou UEFI après stabilisation
• Le niveau de sécurité de la plateforme inclut la protection DMA là où chaque appareil dispose d'un IOMMU
• Kernel DMA Protection exigé dans le standard d'achat matériel
• Stratégie d'énumération définie ; contrôles compensatoires sur les appareils sans protection DMA
• Rapport de parc sur SecurityServicesRunning ; alertes quand VBS cesse de s'exécuter