Integrità della memoria HVCI: verificare driver, esecuzione e blocco UEFI

Che cos’è l’integrità della memoria HVCI?

L’integrità della memoria HVCI è una protezione di Windows che esegue l’integrità del codice del kernel nell’ambiente isolato fornito dalla sicurezza basata sulla virtualizzazione (VBS). Il suo deployment richiede tre risposte distinte: quale configurazione si intende applicare, se l’integrità della memoria è effettivamente in esecuzione su ogni dispositivo destinatario e se il ripristino resta possibile dopo la scelta della modalità di blocco UEFI. Una GPO di dominio risponde solo a una parte della prima domanda. Guida Microsoft all’abilitazione

Per un team AD, il risultato utile è un deployment collaudato con evidenze per dispositivo. Iniziate con una popolazione rappresentativa, risolvete le dipendenze dei driver, misurate il servizio dopo il riavvio e registrate la decisione sul blocco. Includete nel rapporto le macchine che non è stato possibile misurare; ometterle senza indicarlo fa apparire la copertura della policy come una protezione verificata.

Questa guida utilizza la documentazione Microsoft Learn verificata il 3 ottobre 2026 e i due controlli del collector descritti di seguito. I comandi Windows sono esempi della documentazione o adattamenti in sola lettura identificati come tali; non sono stati eseguiti su un parco Windows per questo articolo. Non si dichiara alcuna copertura del parco né alcun test di compatibilità riuscito.

La nostra guida a Credential Guard dopo un aggiornamento utilizza lo stesso metodo di evidenza WMI per un servizio diverso: l’isolamento di determinati segreti. L’integrità della memoria riguarda l’integrità del codice del kernel. La prova che un servizio è in esecuzione non dimostra che lo sia anche l’altro.

Distinguere policy, stato di esecuzione e blocco UEFI

Lo stesso numero ha significati diversi a seconda dell’impostazione. Il riferimento della policy VirtualizationBasedTechnology di Microsoft documenta la modalità della policy e la sua corrispondenza con la GPO Device Guard. La pagina di abilitazione documenta separatamente i valori locali Enabled e Locked.

I percorsi locali della tabella si trovano sotto HKLM\SYSTEM\CurrentControlSet\Control. Il valore della policy si trova sotto HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. Non scrivete Enabled=2 per riprodurre la modalità senza blocco della policy. Non interpretate un identificatore di servizio WMI come una modalità del registro. Conservate il percorso completo e il nome del valore nelle evidenze, affinché un altro amministratore possa interpretarli senza ricostruire la raccolta.

Una registrazione utile della modifica conserva l’intento della policy, la policy applicata, le impostazioni locali e l’osservazione dell’esecuzione in campi distinti. Se una GPO specifica una modalità mentre un endpoint ne mostra un’altra, esaminate la configurazione applicata prima di dichiarare conclusa la modifica. Se le impostazioni concordano ma l’esecuzione differisce, esaminate l’endpoint anziché modificare ripetutamente la stessa GPO.

Il blocco UEFI cambia anche la decisione sul ripristino. La procedura GPO di Microsoft prevede un deployment senza blocco e avverte che la scelta della modalità bloccata limita la disabilitazione da remoto. Stabilite chi può accedere al menu del firmware e ripristinare la macchina prima di integrare tale restrizione nell’amministrazione di produzione. Istruzioni GPO di Microsoft

Rilevamento: raccogliere evidenze sul dispositivo destinatario

Utilizzate una sessione PowerShell con privilegi elevati sul dispositivo destinatario. Microsoft fornisce questo comando nel suo riferimento Win32_DeviceGuard:

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

Il seguente adattamento in sola lettura seleziona i campi necessari a questa indagine:

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

Interpretate gli array di servizi in base all’appartenenza. Un risultato che contiene sia 1 sia 2 include l’integrità della memoria; 1 identifica Credential Guard. VirtualizationBasedSecurityStatus=2 descrive VBS in esecuzione, mentre la presenza di 2 in SecurityServicesRunning identifica l’integrità della memoria in esecuzione. Definizioni Microsoft delle proprietà WMI

Trattate la raccolta come un’osservazione associata a un host, un orario e un contesto di avvio. Conservate gli array completi, anche se il pannello mostrerà successivamente un booleano. Distinguete una query riuscita senza integrità della memoria da una query fallita. Gli errori di autenticazione, i dispositivi irraggiungibili e gli output mancanti appartengono a una categoria di stato sconosciuto con un’azione di follow-up.

Confrontare la policy e le impostazioni locali del blocco

Questo adattamento PowerShell in sola lettura legge le impostazioni indicate; i percorsi o i valori mancanti devono essere registrati come assenti, senza sostituirli silenziosamente con zero:

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

Confrontate queste osservazioni con la modalità approvata e con un rapporto della policy risultante per quell’host. Un’impostazione esportata da una GPO estranea al destinatario non è una prova sufficiente che questi l’abbia ricevuta. Registrate le configurazioni in conflitto e gli errori di raccolta anziché convertirli in un semplice punteggio protetto/non protetto.

Le proprietà documentate di Win32_DeviceGuard indicate sopra non forniscono una proprietà Locked. Leggete separatamente i marcatori del registro indicati. Descrivono la configurazione del blocco e non devono essere presentati come un’attestazione indipendente del firmware. Analogamente, un risultato CIM che mostra l’integrità della memoria in esecuzione non dimostra che il blocco UEFI sia applicato. Riferimento Microsoft per configurazione e convalida

Compatibilità dei driver: progettare un pilota che eserciti il lavoro reale

La guida Microsoft alla compatibilità dei driver combina i controlli Code Integrity in Driver Verifier, i test funzionali con l’integrità della memoria abilitata e Windows HLK HyperVisor Code Integrity Readiness Test. Distingue la preparazione alla firma dai test funzionali approfonditi. Un driver che si carica durante un avvio non ha necessariamente esercitato ogni percorso di esecuzione pertinente.

Per il responsabile di un driver o un team di ingegneria, il comando documentato del verificatore è:

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

Sostituite il segnaposto con il driver selezionato in un ambiente di test ripristinabile. Driver Verifier è uno strumento di test, non un comando da distribuire indiscriminatamente agli endpoint di produzione. Registrate il driver selezionato, le condizioni di test, i risultati e il percorso di ripristino. Gestite i problemi con il fornitore del driver anziché considerare la disabilitazione permanente come l’unica soluzione.

Per il team di deployment, costruite una matrice di modelli dei dispositivi, revisioni del firmware, build Windows, pacchetti di driver e flussi di lavoro aziendali. Includete le combinazioni effettivamente presenti nella popolazione destinataria. Scegliete macchine pilota che evidenzino differenze significative; un comodo insieme di portatili identici può lasciare altre famiglie di hardware non testate.

Testate il lavoro che queste macchine devono svolgere: avvio, periferiche, applicazioni necessarie e operazioni dipendenti dai relativi driver. Definite i risultati attesi prima di iniziare e associate i problemi a un pacchetto e a un responsabile identificati. Si tratta di raccomandazioni per il deployment, non dell’affermazione che una particolare applicazione o un dispositivo del vostro ambiente sia incompatibile.

Assegnate a ogni eccezione una motivazione, la popolazione interessata, un responsabile, una correzione pianificata e una data di revisione. Distinguete un problema di compatibilità dimostrato dall’ipotesi che una vecchia eccezione sia ancora necessaria. Chiedete ai fornitori un pacchetto aggiornato o evidenze di test a supporto, quindi ripetete il flusso di lavoro pertinente con l’integrità della memoria attiva. L’inventario delle eccezioni delimita la successiva ondata di deployment.

Correzione: distribuire la GPO per fasi e dimostrare il risultato dopo il riavvio (Remediation)

1. Approvare la popolazione e il piano di ripristino

Assegnate responsabili per la revisione dell’hardware, i test dei driver, le modifiche GPO e il ripristino. Registrate la modalità di blocco prevista, l’ambito del pilota e le esclusioni prima di modificare la policy. Stabilite una regola di accettazione che richieda sia un’osservazione dell’esecuzione sia il superamento dei flussi di lavoro necessari; la sola creazione di una GPO non deve chiudere l’attività.

Per le postazioni di amministrazione, inserite questa decisione nell’architettura più ampia descritta dalla nostra guida ANSSI Active Directory: percorsi di amministrazione, uso dedicato e confini di fiducia. Il rafforzamento di una funzionalità Windows non dimostra che l’architettura di amministrazione sia solida né attesta la conformità ANSSI.

2. Applicare una configurazione supportata con un ambito definito

Seguite la procedura GPO di Microsoft sotto Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security. Abilitate la policy e selezionate l’opzione prevista sotto Virtualization Based Protection of Code Integrity. Collegate e filtrate la GPO per la popolazione pilota approvata; esaminate la policy applicata al destinatario prima di ampliare l’ambito. Procedura Microsoft di deployment

Il comando documentato per aggiornare la policy, eseguito da una Command Prompt con privilegi elevati, è:

gpupdate /force

Pianificate un riavvio per la raccolta delle evidenze del pilota. Dopo l’avvio, ripetete l’osservazione CIM e il confronto delle impostazioni locali. Registrate gli array e la modalità osservati insieme alla richiesta di modifica. Non deducete un risultato per l’intero parco da una singola macchina riuscita; ogni destinatario non misurato mantiene il proprio stato irrisolto.

3. Documentare il ripristino prima di selezionare il blocco UEFI

In caso di instabilità dopo l’abilitazione, la procedura di risoluzione dei problemi di Microsoft inizia disabilitando le policy che abilitano la funzione, quindi utilizza Windows Recovery Environment (Windows RE) per impostare il valore Enabled dello scenario a 0 e riavviare. Il comando documentato è:

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

Costruite la procedura di ripristino specifica della macchina attorno a questo processo. Convalidate l’accesso a Windows RE e al registro dell’installazione interessata, identificate l’operatore e testate come verrà ritirata la policy di abilitazione. Non presumete che una normale modifica remota del registro possa ripristinare una macchina che non si avvia.

Con il blocco UEFI, Microsoft richiede inoltre la disabilitazione di Secure Boot per completare questi passaggi di ripristino. Questo requisito integra l’accesso al firmware nel piano. Selezionate il blocco solo quando il percorso fisico di ripristino, l’operatore autorizzato e la procedura di rollback sono documentati. Includete nella procedura il ripristino della configurazione del firmware approvata e una nuova convalida. Guida Microsoft al ripristino

4. Espandere utilizzando le evidenze conservate

Esaminate le osservazioni e i problemi del pilota prima dell’ondata successiva. Conservate le eccezioni e i dispositivi di stato sconosciuto nello stesso inventario delle misurazioni riuscite. Ripetete i controlli dopo modifiche pertinenti dei driver o della piattaforma. Una registrazione utile di chiusura contiene la policy approvata, l’ambito destinatario, il contesto di avvio, l’evidenza del servizio in esecuzione, l’esito del test funzionale e il responsabile del ripristino.

Come EtcSec rileva questa configurazione

L’etc-collector di EtcSec espone due controlli di configurazione GPO per questo argomento. Il comportamento seguente deriva dai loro rami effettivi di Detect(), non da un test di endpoint:

gpoSetsAtLeast e gpoMaxValue iterano le GPO raccolte, saltano gli oggetti di policy/impostazioni mancanti e ignorano i valori non impostati. Il massimo parte da -1. Il parser Registry.pol associa un DWORD denominato HypervisorEnforcedCodeIntegrity in una chiave contenente deviceguard a HVCIEnabled. Non ottiene le misurazioni separate Enabled e Locked dello scenario di esecuzione.

Il massimo è un aggregato numerico, non una classifica di sicurezza né un calcolo della precedenza delle GPO. Se una policy ha 1 e un’altra ha 2, il massimo è 2 e si attiva il controllo Low. Anche i valori superiori a 2 entrano nello stesso ramo di rilievo, perché il codice non valida l’enumerazione. Non sono modalità di blocco valide documentate e vanno esaminati come dati inattesi.

Count 1 è il numero di rilievi del rilevatore, non un conteggio degli endpoint esposti. Nessuno dei due controlli calcola il Resultant Set of Policy (RSoP) per macchina, valuta i collegamenti/filtri GPO o interroga l’esecuzione tramite WMI. Un’impostazione positiva in qualunque punto può sopprimere il controllo OFF anche quando la copertura destinataria è incompleta. Un valore GPO assente può coesistere con l’abilitazione tramite un altro meccanismo; non dimostra che l’integrità della memoria sia disabilitata durante l’esecuzione.

Utilizzate questi controlli per avviare l’indagine sulle policy, quindi aggiungete evidenze indipendenti dei dispositivi. I nomi e i commenti dei rilevatori non dimostrano da soli la conformità ANSSI, l’effettivo blocco del firmware, la compatibilità dei driver o la protezione riuscita nell’intero parco. Queste conclusioni richiedono evidenze e una revisione proprie.

Fonti

• Microsoft Learn: abilitare l’integrità della memoria, GPO, registro, WMI e ripristino
• Microsoft Learn: compatibilità dei driver con l’integrità della memoria e VBS
• Microsoft Learn: valori della policy VirtualizationBasedTechnology e corrispondenza GPO