VBS, Speicherintegrität (HVCI) und Kernel DMA Protection

Sobald ein Angreifer Code im Windows-Kernel ausführt, sind die meisten anderen Schutzmaßnahmen verhandelbar: Er kann Sicherheitswerkzeuge abschalten, LSASS auslesen und sich verbergen. Drei hardwaregestützte Funktionen halten dagegen:

• Virtualisierungsbasierte Sicherheit (VBS) nutzt den Windows-Hypervisor, um eine isolierte Umgebung (Virtual Trust Level 1) zu schaffen, die der normale Kernel weder lesen noch verändern kann.
• Speicherintegrität, auch hypervisorgeschützte Codeintegrität oder HVCI genannt, führt die Codeintegritätsprüfungen des Kernels innerhalb von VBS aus. Kernel-Speicherseiten sind beschreibbar oder ausführbar, nie beides, und nur signierter Code kann ausführbar werden, selbst wenn der Kernel kompromittiert ist.
• Kernel DMA Protection nutzt die IOMMU, um externe Geräte an Thunderbolt-, USB4- oder PCIe-Hot-Plug-Ports daran zu hindern, per Direct Memory Access Speicher zu lesen oder zu schreiben.

Der Leitfaden zur BitLocker-Härtung erwähnt den DMA-Schutz als Teil der Startkette, und der Leitfaden zu Credential Guard behandelt die Isolation von Anmeldedaten, die auf VBS aufsetzt. Dieser Leitfaden stellt VBS und Speicherintegrität flottenweit bereit und macht Kernel DMA Protection zum Teil Ihres Hardwarestandards. Den Rest der Reihe finden Sie im Thema BitLocker & Startsicherheit.

Voraussetzungen

Windows 11 auf Hardware, die seine Mindestanforderungen erfüllt, unterstützt alle drei. Vielen Desktops und älteren Laptops fehlt Kernel DMA Protection, selbst wenn VBS funktioniert.

Schritt 1: die Bereitschaft prüfen

Auf einer Stichprobe jedes Hardwaremodells zeigt msinfo32 > System Summary die Einträge Virtualization-based security, Kernel DMA Protection und die Liste der konfigurierten und laufenden VBS-Dienste. Dieselben Daten per PowerShell:

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
$dg.VirtualizationBasedSecurityStatus     # 0 aus, 1 aktiviert, aber nicht aktiv, 2 aktiv
$dg.AvailableSecurityProperties           # 1 Hypervisor, 2 Secure Boot, 3 DMA-Schutz, 7 MBEC/GMET, ...
$dg.SecurityServicesConfigured
$dg.SecurityServicesRunning               # 1 Credential Guard, 2 Speicherintegrität, 3 System Guard Secure Launch

Für Treiber listet die App Windows-Sicherheit unter Device security > Core isolation details inkompatible Treiber auf, die die Speicherintegrität verhindern. In Flottengröße ist eine Überwachungsphase die zuverlässigere Methode: Aktivieren Sie die Speicherintegrität in einem Pilotring pro Hardwaremodell und prüfen Sie das Protokoll Microsoft > Windows > CodeIntegrity > Operational auf Treiber, deren Laden blockiert wurde. Aktualisieren oder ersetzen Sie diese vor dem breiten Rollout. Typische Kandidaten sind alte Hardware-Dienstprogramme, Anti-Cheat-Engines, ältere VPN- und Virtualisierungstreiber und nicht mehr gepflegte Herstellerwerkzeuge.

Schritt 2: VBS und Speicherintegrität per Gruppenrichtlinie aktivieren

GPO-Pfad: Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security, auf Enabled gesetzt:

Die UEFI-Sperre speichert die Einstellung in einer Firmwarevariablen, sodass sie sich nicht durch Bearbeiten der Registrierung oder der Richtlinie abschalten lässt; das spätere Entfernen erfordert ein dokumentiertes Verfahren mit physischer Anwesenheit. Beginnen Sie ohne sie.

Registrierungsäquivalente für Images oder Geräte außerhalb der Domäne:

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

Ein Neustart ist erforderlich. Unter Windows 11 ist Kernel-mode Hardware-enforced Stack Protection eine weitere Option der Kernisolierung, die auf der Speicherintegrität und der Shadow-Stack-Unterstützung der CPU aufbaut; bewerten Sie sie, sobald die Speicherintegrität stabil läuft.

Schritt 3: das Intune-Äquivalent

Im Einstellungskatalog enthalten die Kategorien Device Guard und Virtualization Based Technology dieselben Einstellungen:

• Enable Virtualization Based Security und Require Platform Security Features (Policy CSP DeviceGuard/EnableVirtualizationBasedSecurity, DeviceGuard/RequirePlatformSecurityFeatures).
• Hypervisor Enforced Code Integrity: deaktiviert, aktiviert mit UEFI-Sperre oder aktiviert ohne Sperre (Policy CSP VirtualizationBasedTechnology/HypervisorEnforcedCodeIntegrity, Werte 0, 1 und 2).
• Require UEFI Memory Attributes Table (VirtualizationBasedTechnology/RequireUEFIMemoryAttributesTable).

Endpoint security > Account protection stellt außerdem Credential Guard bereit. Konfigurieren Sie dieselbe Einstellung nicht in zwei Profilen oder auf hybriden Geräten sowohl per GPO als auch per Intune, denn Konflikte lassen Geräte in einem Fehlerzustand zurück.

Ergänzen Sie in Ihrer Compliancerichtlinie Require code integrity unter Device Health, um auf Basis der attestierten Codeintegrität zu berichten oder den Zugriff zu steuern.

Schritt 4: Kernel DMA Protection

Kernel DMA Protection wird von der Firmware eingeschaltet, nicht von Windows. Ihre Aufgaben sind, Hardware zu kaufen, die sie hat, sie aktiviert zu lassen und zu entscheiden, wie inkompatible Geräte behandelt werden.

1. Hardwarestandard: Verlangen Sie Kernel DMA Protection: On in msinfo32 als Beschaffungskriterium für alle Laptops und für Desktops mit Thunderbolt oder USB4.
2. Firmwareeinstellungen: Lassen Sie VT-d / AMD-Vi und die IOMMU aktiviert; sie lassen sich im BIOS-Setup abschalten, ein weiterer Grund für ein Firmwarekennwort.
3. Aufzählungsrichtlinie: GPO Computer Configuration > Administrative Templates > System > Kernel DMA Protection > Enumeration policy for external devices incompatible with Kernel DMA Protection. Die Optionen sind Block all, Only while logged in (Standardverhalten) und Allow all. Wählen Sie Block all für Geräte mit hohem Risiko, in dem Wissen, dass einige ältere Docks und Peripheriegeräte, deren Treiber kein DMA-Remapping unterstützen, nicht mehr funktionieren. Intune: Policy CSP DmaGuard/DeviceEnumerationPolicy (0 alle blockieren, 1 nur nach Anmeldung, 2 alle zulassen).

Für Geräte ohne Kernel DMA Protection gleichen Sie aus:

• BitLocker mit TPM und PIN für Hochrisikobenutzer, damit sich vor der Authentifizierung keine Schlüssel im Speicher befinden.
• Die BitLocker-Einstellung Disable new DMA devices when this computer is locked unter Windows Components > BitLocker Drive Encryption.
• Thunderbolt in der Firmware deaktivieren oder dessen Sicherheitsstufe festlegen, wo keine Docks verwendet werden.

Was kaputtgeht

• Inkompatible Kernel-Treiber werden bei aktivierter Speicherintegrität nicht geladen; davon abhängige Hardware verliert Funktionen, und ein startkritischer Speicher- oder Sicherheitstreiber kann das System am Starten hindern. Pilotieren Sie immer pro Modell.
• Hypervisoren und Emulatoren von Drittanbietern müssen bei aktivem VBS auf der Windows Hypervisor Platform laufen; aktuelle Versionen der großen Produkte tun das, ältere nicht.
• Leistung auf Prozessoren ohne MBEC/GMET, insbesondere bei Spielen und Grafiklasten.
• Die UEFI-Sperre macht ein Zurückrollen langsam. Lassen Sie sie ausgeschaltet, bis die Flotte stabil ist.
• Docks und Peripheriegeräte ohne Treiber mit DMA-Remapping-Unterstützung werden bei Block all nicht mehr erkannt.

Die Speicherintegrität erschwert außerdem treiberbasierte Angriffe; kombinieren Sie sie mit der Sperrliste für anfällige Treiber, die auf Geräten mit aktivierter Speicherintegrität automatisch erzwungen wird, und mit App Control for Business für Code im Benutzermodus.

Überprüfen

Auf dem Gerät:

$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
}

Bestätigen Sie Kernel DMA Protection: On in msinfo32 für das Hardwaremodell. Sammeln Sie dieselben Werte flottenweit und alarmieren Sie bei Geräten, auf denen VBS konfiguriert ist, aber nicht läuft: Das bedeutet meist, dass die Virtualisierung in der Firmware deaktiviert wurde, ein BIOS-Reset stattfand oder ein inkompatibler Treiber installiert wurde.

Checkliste

• Hardwareinventar: VBS-Fähigkeit, MBEC/GMET, IOMMU und Kernel DMA Protection pro Modell
• Inkompatible Treiber in einem Pilot identifiziert und aktualisiert oder entfernt
• VBS und Speicherintegrität per GPO oder Intune erzwungen, UEFI-Sperre nach der Stabilisierung
• Plattformsicherheitsstufe umfasst DMA-Schutz, wo jedes Gerät eine IOMMU hat
• Kernel DMA Protection im Hardware-Beschaffungsstandard vorgeschrieben
• Aufzählungsrichtlinie gesetzt; ausgleichende Maßnahmen auf Geräten ohne DMA-Schutz
• Flottenbericht zu SecurityServicesRunning; Alarme, wenn VBS nicht mehr läuft