Verifica delle policy App Control: WDAC oltre il marcatore GPO

Che cos’è la verifica delle policy App Control?

La verifica delle policy App Control stabilisce quali policy App Control for Business siano presenti su un dispositivo Windows, come siano arrivate e se il loro comportamento osservato corrisponda alle regole applicative approvate. Un oggetto Criteri di gruppo (GPO) contenente un percorso di distribuzione descrive l’intento della configurazione. Non dimostra che il dispositivo di destinazione abbia ottenuto il binario, caricato la versione prevista o applicato la policy.

Per un team Active Directory che indaga su un rilievo relativo alla distribuzione di WDAC, il risultato utile è un registro delle evidenze specifico per ogni dispositivo. Identifica la policy e il responsabile della sua distribuzione, testa i flussi di lavoro richiesti in modalità audit, esamina le regole proposte e approva l’applicazione con una procedura di recupero. Mantieni visibili i dispositivi non raggiungibili e le misurazioni mancanti come casi irrisolti.

Questa guida usa la documentazione Microsoft Learn consultata il 4 ottobre 2026 e l’implementazione del collector identificata più avanti. I comandi sono esempi documentati per un amministratore Windows autorizzato; non sono stati eseguiti su un parco Windows per questo articolo. Non si dichiara alcuna distribuzione riuscita, copertura dei dispositivi, esposizione a CVE o conformità ANSSI.

La nostra guida all’integrità della memoria HVCI spiega l’isolamento in memoria dell’integrità del codice del kernel e la compatibilità dei driver. Questa procedura verifica le policy di autorizzazione delle applicazioni, il loro formato e i loro eventi. Registra entrambe le protezioni quando pertinenti, con evidenze distinte per ciascuna.

Come funziona: formato e distribuzione della policy devono essere coerenti

La procedura di distribuzione tramite GPO di Microsoft supporta solo il formato a policy singola. L’impostazione si trova in Computer Configuration → Administrative Templates → System → Device Guard → Deploy App Control for Business. L’impostazione abilitata indica un percorso di distribuzione locale o UNC; una condivisione deve essere accessibile agli account computer. La procedura termina con il riavvio di un computer di test.

La stessa pagina indica agli amministratori che distribuiscono una nuova policy di base firmata con l’integrità della memoria abilitata di usare la distribuzione tramite script e di attivarla con un riavvio. Non sostituire questa istruzione con un aggiornamento a caldo solo perché uno strumento di gestione lo offre. La procedura tramite script di Microsoft identifica il caso interessato di Windows 11 precedente a 24H2 e le copie richieste nelle posizioni di sistema ed EFI, seguite dal riavvio. Verifica la build di destinazione e la procedura pertinente prima di scegliere un meccanismo di attivazione.

La panoramica della distribuzione di Microsoft distingue l’XML con un PolicyID per il formato a policy multiple dal caso a policy singola. Descrive la conversione in un binario e la distribuzione tramite MDM, Configuration Manager, script o Group Policy. L’assenza di un marcatore GPO non può escludere questi altri metodi di distribuzione.

Prima di modificare qualsiasi elemento, crea un registro per ogni popolazione pilota:

Questi campi sono una proposta di registro d’indagine, non misurazioni di un ambiente cliente. Chiarisci le responsabilità mancanti prima di emettere modifiche: un amministratore dovrebbe poter spiegare quale origine distribuirà la prossima versione e quale operatore potrà ritirarla.

Rilevamento: inventariare il dispositivo di destinazione e correlare gli eventi

Passaggio 1: identificare le policy sul dispositivo pilota

La documentazione tecnica di CiTool descrive --list-policies, con l’alias -lp, come comando che elenca le policy attive o inattive. CiTool è incluso a partire da Windows 11 22H2 e Windows Server 2025. Su un dispositivo di destinazione supportato, conserva l’output completo:

CiTool --list-policies

L’output documentato include Policy ID, Base Policy ID, nome descrittivo, versione, stato della firma, presenza del file e stato di attivazione. Confronta identità e versioni con l’artefatto approvato. La documentazione definisce Is Currently Enforced come indicazione del fatto che il file della policy sia attivo; non usare solo questa etichetta per decidere se le sue opzioni delle regole siano in modalità Audit o Enforcement.

Per i sistemi su cui lo strumento non è disponibile, usa la procedura di distribuzione specifica per il sistema operativo e gli artefatti di policy conservati. Un comando non disponibile è un limite dell’inventario, non una prova dell’assenza di App Control. Distingui una raccolta fallita da un inventario riuscito senza la policy attesa.

Passaggio 2: leggere i registri corretti

Nel Visualizzatore eventi, esamina Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational e Applications and Services Logs → Microsoft → Windows → AppLocker → MSI and Script. La documentazione degli eventi di Microsoft descrive questi segnali:

Il registro MSI and Script non è disponibile su Windows Server Core. Inoltre, App Control normalmente non registra ogni binario consentito. Di conseguenza, registri senza eventi non costituiscono un inventario completo delle esecuzioni o una prova che tutte le applicazioni siano autorizzate.

Conserva i dettagli degli eventi con dispositivo, ora, identità della policy quando fornita, opzioni osservate e flusso di lavoro testato. Confronta l’osservazione della policy caricata con identità, versione e modalità previste. Indaga sugli identificativi inattesi e spiega ogni cambio di versione prima di attribuire attività successive alla distribuzione.

Passaggio 3: testare le attività richieste in modalità audit

Esegui i flussi autorizzati di installazione, avvio, aggiornamento e amministrazione sul pilota. Chiedi ai responsabili applicativi di identificare dipendenze e risultati attesi. Tieni traccia di ciò che è stato effettivamente testato; un computer inattivo fornisce poche evidenze di compatibilità. Conserva le lacune nella raccolta e i limiti di conservazione dei registri insieme alla revisione.

La nostra guida alle regole Defender ASR tramite GPO confronta GUID, azioni ed esclusioni delle regole comportamentali con la configurazione dei dispositivi. Qui la revisione riguarda identità e formato della policy App Control e le decisioni su binari e script. Un’osservazione della configurazione ASR non può chiudere questa indagine su App Control.

Correzione: esaminare le evidenze di audit prima dell’applicazione (Remediation)

Passaggio 1: approvare un pilota recuperabile

Nomina il responsabile della distribuzione, l’approvatore delle regole applicative e l’operatore di recupero. Definisci quali dispositivi entrano nel pilota, quali flussi di lavoro devono riuscire e quali errori fermano l’espansione. Chiedi esplicitamente: quali formato e metodo di distribuzione sono in uso, se le nuove policy di base firmate sono combinate con l’integrità della memoria e chi approva eccezioni e rollback.

Microsoft raccomanda anelli di distribuzione e valutazione in audit prima dell’applicazione nella sua panoramica della distribuzione. Scegli il metodo dal registro di sistema operativo, formato e firma riportato sopra. Conserva gli artefatti precedenti e una procedura operativa di recupero testata prima di distribuire la versione candidata.

Passaggio 2: generare proposte, poi esaminare ogni regola

Il flusso di lavoro con gli eventi di audit di Microsoft richiede una policy in modalità audit già distribuita. Esegui il comando documentato in una sessione PowerShell con privilegi elevati per generare regole candidate dagli eventi di audit:

$EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
$EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings

Questo esempio produce il formato a policy multiple; non è un binario da distribuire tramite l’impostazione GPO a policy singola. Esamina l’XML generato e gli avvisi. Conserva solo le regole per applicazioni, binari e script approvati, quindi uniscile alla policy di base o usa una policy supplementare consentita. I file non più presenti sul disco non ricevono regole generate automaticamente tramite questo processo.

Esegui nuovamente i flussi di lavoro richiesti dopo la distribuzione della policy di audit esaminata. Mantieni vietate le attività non consentite; un evento di audit non è un’istruzione a fidarsi della sua origine. Indaga sugli eventi inspiegati e sugli avvisi irrisolti prima di proseguire.

Passaggio 3: preparare l’artefatto di applicazione

La procedura di applicazione di Microsoft parte da policy di audit esaminate. Copia l’XML di audit in un file di applicazione separato e consente facoltativamente di cambiare l’identità della policy per una distribuzione affiancata. Decidi deliberatamente se sostituirla sul posto o usare una nuova identità; le relazioni con le policy supplementari devono seguire tale scelta.

Con $EnforcedPolicyXML che punta alla copia preparata, il cambio di modalità documentato è:

Set-RuleOption -FilePath $EnforcedPolicyXML -Option 3 -Delete

La stessa procedura raccomanda di considerare le opzioni 9 e 10 per il primo anello di applicazione: un’opzione prima dell’avvio per disabilitare l’applicazione durante una sessione di avvio e un ripiego in audit quando viene bloccato un driver critico per l’avvio. Converti l’XML esaminato in binario, applica il processo di firma richiesto e distribuisci usando il metodo supportato scelto. Conserva l’identità dell’artefatto e la modalità attesa nel registro delle modifiche.

Dopo l’attivazione, ripeti inventario, revisione della policy caricata e test funzionali. Esamina gli eventi di applicazione rispetto alle aspettative approvate. Passa all’anello successivo solo dopo che i revisori designati hanno accettato evidenze, eccezioni e preparazione al recupero; la modifica della GPO in sé non è il criterio di chiusura.

Passaggio 4: testare il ritiro e il recupero

La procedura di rimozione delle policy di Microsoft richiede innanzitutto di disabilitare il metodo di distribuzione per evitare che la policy venga ridistribuita. Per una policy di base firmata, distribuisci una sostituzione firmata con l’opzione 6, lo stesso PolicyId, una versione uguale o superiore e una sezione UpdatePolicySigners. Firmala con un certificato elencato nella sezione UpdatePolicySigners della policy originale, quindi riavvia prima della rimozione. Non presumere che un’eliminazione locale ritiri in sicurezza una policy di base firmata.

Su un sistema supportato, dopo aver soddisfatto questi prerequisiti, esegui l’esempio di rimozione documentato da una finestra dei comandi con privilegi elevati:

CiTool.exe -rp "{PolicyId GUID}" -json

Sostituisci il segnaposto con l’identificativo della policy approvato. I requisiti di riavvio variano in base alla versione di Windows e alla firma della policy; usa la procedura collegata per il dispositivo di destinazione. La procedura operativa deve coprire anche un dispositivo che non si avvia, l’accesso autorizzato al firmware e la disponibilità delle chiavi di recupero. Testa questo percorso su apparecchiature recuperabili prima dell’applicazione.

Come EtcSec rileva questo caso

L’etc-collector di EtcSec include BP039_CCI_NOT_DEPLOYED. Nel commit esaminato 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85, il suo Detect() in bp039-cci-not-deployed.go scorre ogni voce raccolta di GPOPolicies, ignorando gli oggetti di policy o impostazioni mancanti. Qualsiasi stringa DeviceGuardConfigCIPolicyFilePath non vuota restituisce nil, ossia nessun rilievo. Altrimenti restituisce gravità Low, Count 1, anche quando non è stata raccolta alcuna policy.

Quel ramo verifica un solo marcatore. Non convalida il file referenziato né il suo formato binario, firma, versione, ambito di destinazione o stato di applicazione. Un valore positivo in una GPO non pertinente basta a sopprimere il rilievo; il codice non calcola i criteri risultanti per ogni dispositivo. Count 1 è un conteggio dei rilievi, non dei computer non protetti.

Il registrypol_parser.go esaminato richiede una chiave contenente codeintegrity per mappare ConfigCIPolicyFilePath. L’impostazione GPO reale usa il ramo DeviceGuard, quindi questo percorso non popola il marcatore atteso. Separatamente, CollectGPOPolicies in smb/client.go inserisce un oggetto di policy anche quando i suoi file non sono stati letti correttamente. Un oggetto nella mappa non è quindi prova di una raccolta riuscita delle impostazioni.

Allega all’indagine l’inventario indipendente dei dispositivi, gli artefatti di policy approvati, gli eventi pertinenti e le decisioni di revisione delle regole. Risolvi esplicitamente gli errori di raccolta. Chiudi la questione operativa sulla base di queste evidenze e dei criteri di accettazione concordati, invece di modificare una GPO soltanto per silenziare un controllo del marcatore.