Secured-Core PC¶

Un poste Windows peut démarrer proprement et être compromis avant même que l'utilisateur ne se connecte. Les attaques firmware, les rootkits noyau et les manipulations de la chaîne de démarrage ciblent les couches que le système d'exploitation ne surveille pas lui-même.

Secured-Core PC est la réponse de Microsoft à cette classe de menaces. Le label désigne un ensemble de garanties matérielles et logicielles qui protègent le poste avant, pendant et après le démarrage.

1. Qu'est-ce qu'un Secured-Core PC¶

1.1 Périmètre du label¶

Secured-Core PC n'est pas une fonctionnalité unique. C'est un ensemble de prérequis matériels, firmware et logiciels que le constructeur et le système d'exploitation doivent satisfaire conjointement.

L'objectif est de protéger le chemin de démarrage et d'isoler les secrets du système, même face à un attaquant disposant d'un accès physique ou d'une capacité de modification firmware.

Les composants couverts par le label sont les suivants :

1.2 Ce que Secured-Core ajoute à Secure Boot¶

Secure Boot valide la chaîne de chargement UEFI. Il vérifie que le bootloader, le noyau et les drivers de démarrage sont signés par une autorité reconnue.

C'est une condition nécessaire, mais pas suffisante.

Secured-Core va plus loin sur trois axes :

• Isolation matérielle du noyau via VBS : le noyau Windows classique ne peut pas accéder aux secrets gérés dans le Secure Kernel.
• Attestation firmware via DRTM : l'état du firmware est mesuré dynamiquement, pas seulement au moment de la mise sous tension.
• Protection des secrets dans une enclave matérielle : Credential Guard isole les secrets d'authentification via LSAIso.exe dans un environnement inaccessible au système principal.

2. Virtualization-Based Security (VBS)¶

2.1 Principe¶

VBS utilise l'hyperviseur Windows (Hyper-V) pour créer un environnement d'exécution isolé du noyau principal.

Le poste fonctionne alors avec deux zones distinctes :

• Normal World : le noyau Windows classique, les drivers et les applications.
• Secure World : le Secure Kernel, qui gère les secrets et valide l'intégrité du code noyau.

Les secrets gérés dans le Secure World ne sont pas accessibles depuis le Normal World. Même un attaquant avec des droits SYSTEM dans le noyau classique ne peut pas lire la mémoire du Secure Kernel.

2.2 Composants qui s'appuient sur VBS¶

VBS est une fondation sur laquelle s'appuient plusieurs mécanismes de sécurité.

2.3 Prérequis matériels VBS¶

VBS ne fonctionne pas sur n'importe quel matériel. Les prérequis suivants sont tous nécessaires :

• CPU avec extensions de virtualisation : Intel VT-x ou AMD-V.
• SLAT (Second Level Address Translation) : Intel EPT ou AMD NPT.
• IOMMU : Intel VT-d ou AMD-Vi, pour protéger contre les attaques DMA.
• UEFI en mode 64 bits avec Secure Boot actif.
• TPM 2.0 recommandé pour le stockage des mesures.

3. HVCI (Hypervisor-Protected Code Integrity)¶

3.1 Rôle¶

HVCI impose que tout code exécuté dans le noyau Windows soit signé et validé par le Secure Kernel avant exécution.

Un rootkit qui tente d'injecter du code non signé dans le noyau est bloqué par cette validation. Le noyau classique (Normal World) ne peut pas charger un driver ou un module sans que le Secure Kernel l'ait d'abord approuvé.

La différence avec Secure Boot est temporelle. Secure Boot valide au démarrage. HVCI valide en continu, à chaque chargement de code noyau.

3.2 Clés de registre HVCI¶

Les clés HVCI se trouvent sous HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard.

3.3 Vérification¶

Plusieurs méthodes permettent de confirmer que HVCI est actif.

Via msinfo32.exe : ouvrir avec Win+R puis taper msinfo32. Vérifier les lignes suivantes :

• Virtualization-based security : doit indiquer Running.
• Virtualization-based security Services Running : doit inclure Hypervisor enforced Code Integrity.

Via PowerShell :

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

4. System Guard et DRTM¶

4.1 System Guard Runtime Monitor¶

System Guard utilise DRTM pour mesurer l'état du système après le démarrage, pas seulement au moment du boot.

Les mesures sont stockées dans le TPM (valeurs PCR) et peuvent être transmises à un serveur de gestion pour attester l'intégrité du poste à distance.

Ce mécanisme permet de répondre à une question simple : le poste est-il dans l'état attendu en ce moment, ou quelque chose a-t-il été modifié depuis le dernier démarrage fiable ?

4.2 DRTM vs SRTM¶

La mesure de l'intégrité du système repose sur deux approches.

SRTM mesure depuis la mise sous tension. Si le firmware est compromis avant que la mesure ne commence, SRTM ne le détecte pas car il fait confiance au point de départ.

DRTM peut prendre une mesure à tout moment durant l'exécution. Il utilise une instruction CPU (Intel GETSEC[SENTER] ou AMD SKINIT) pour établir un point de confiance indépendant du firmware.

5. Activation via GPO¶

5.1 Chemin GPO¶

Les paramètres de Device Guard se configurent dans :

Computer Configuration
  > Administrative Templates
    > System
      > Device Guard

Le paramètre principal est Turn on Virtualization Based Security. Il expose les sous-options suivantes :

• Platform Security Level : Secure Boot, ou Secure Boot and DMA Protection.
• Virtualization Based Protection of Code Integrity : active HVCI.
• Credential Guard Configuration : active Credential Guard via VBS.

5.2 Clés de registre associées¶

La plupart des cles se trouvent sous HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard, sauf LsaCfgFlags qui appartient a HKLM\SYSTEM\CurrentControlSet\Control\Lsa.

5.3 Déploiement progressif¶

Un déploiement HVCI sur un parc hétérogène nécessite une phase de validation préalable.

Les drivers incompatibles HVCI provoquent des comportements variés : BSOD au démarrage, périphérique non fonctionnel, ou refus de chargement silencieux.

Le mode audit de HVCI permet de journaliser les violations sans bloquer le chargement des drivers non conformes. Ce mode est utile pour identifier les incompatibilités avant de passer en mode enforcement.

6. Vérification de conformité¶

6.1 msinfo32¶

Ouvrir avec Win+R puis taper msinfo32. Les lignes suivantes confirment l'état Secured-Core :

6.2 PowerShell¶

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

6.3 Event Log¶

Le journal Microsoft-Windows-DeviceGuard/Operational enregistre les événements liés à VBS et HVCI.

7. Tableau récapitulatif¶

flowchart TD
    A[Démarrage UEFI] --> B[Secure Boot]
    B --> C{DRTM disponible ?}
    C -- Oui --> D[Mesure DRTM via Intel TXT / AMD SKINIT]
    C -- Non --> E[Mesure SRTM uniquement]
    D --> F[Hyperviseur Hyper-V démarre]
    E --> F
    F --> G[Secure Kernel - VBS Secure World]
    G --> H[HVCI protège le code noyau]
    G --> I[Credential Guard isole les secrets via LSAIso.exe]
    F --> J[Normal World - OS Windows]
    J --> K[Noyau Windows classique]
    K -.->|Accès bloqué| G