Criteri effettivi AppLocker: testare le regole dell'utente

Che cosa sono i criteri effettivi AppLocker?

I criteri effettivi AppLocker sono i criteri applicati a uno specifico computer Windows tramite Group Policy, che combinano i criteri AppLocker locali con quelli AppLocker di dominio applicati al computer. Esaminarli aiuta a stabilire quali regole dovrebbero riguardare un file per l'utente previsto. Una GPO denominata «AppLocker» è un'etichetta amministrativa; non dimostra quali siano le regole, la loro modalità o il blocco di un'esecuzione. Riferimento di Get-AppLockerPolicy

Per un team Active Directory che indaga su un rilievo relativo al controllo delle applicazioni, il risultato utile è un registro di evidenze collegato a un dispositivo, un utente e un carico di lavoro. Identificate il canale di distribuzione, conservate i criteri effettivi, esaminate le raccolte, valutate file rappresentativi e pianificate una prova di esecuzione controllata. Mantenete visibili le misurazioni mancanti finché un amministratore non può raccoglierle.

Questa procedura utilizza documentazione primaria verificata il 4 ottobre 2026 e l'implementazione del collector descritta di seguito. I comandi PowerShell sono esempi basati sulla documentazione per amministratori autorizzati. Non sono stati eseguiti su un endpoint per questo articolo; non vengono dichiarati risultati di test o interventi correttivi riusciti.

Funzionamento: identificare il canale di distribuzione e le raccolte

Passaggio 1: distinguere la distribuzione Group Policy dalla distribuzione CSP

Chiedete al responsabile della gestione del dispositivo se AppLocker viene distribuito tramite Group Policy o tramite il provider di servizi di configurazione AppLocker (CSP). Il riferimento Microsoft di Get-AppLockerPolicy afferma esplicitamente che il cmdlet comprende solo le distribuzioni GP e può restituire dati errati quando i criteri sono stati applicati tramite CSP. Un'esportazione GP vuota non risolve la questione del CSP.

Il riferimento del CSP AppLocker documenta le restrizioni di avvio delle applicazioni con nodi di criteri specifici per ciascuna raccolta. Per un dispositivo gestito tramite CSP, conservate il profilo di gestione responsabile, i payload dei criteri delle raccolte e le evidenze di applicazione al dispositivo ottenute attraverso quel canale. Definite come il team di gestione stabilirà lo stato applicato del dispositivo prima di dichiarare la copertura. La procedura di esportazione GP di questo articolo non può fornire queste evidenze per CSP.

Registrate quanto segue prima di scegliere il percorso di verifica:

Questi campi costituiscono una proposta di registro di revisione. Compilateli con osservazioni reali; il nome di un criterio o un'assegnazione non confermata non bastano per chiudere una riga.

Passaggio 2: registrare le raccolte e le modalità di applicazione

Microsoft definisce cinque raccolte di regole AppLocker: file eseguibili, file Windows Installer, script, DLL e app in pacchetto con i relativi programmi di installazione. Un test limitato agli eseguibili lascia inesaminate le altre raccolte applicabili. La raccolta DLL non è abilitata per impostazione predefinita; esaminatene le implicazioni di compatibilità e prestazioni prima di aggiungerla al progetto pilota.

Per ogni raccolta pertinente, conservate regole, SID di utenti o gruppi, condizioni, eccezioni e modalità configurata. Lo schema XML del riferimento CSP include i valori AuditOnly, Enabled e NotConfigured per l'applicazione delle raccolte. Conservate il valore esatto osservato, insieme all'impostazione della console e all'origine della distribuzione; non riassumete tutti i criteri come «abilitati» perché una raccolta applica le regole.

La procedura Audit only di Microsoft distingue la valutazione delle regole e la registrazione delle decisioni dalla loro applicazione. Una raccolta in modalità di audit può identificare file che verrebbero negati mentre quei file continuano a essere eseguiti. Registrate una raccolta assente o una modalità ambigua come questione di revisione separata, anziché dedurre la protezione da un'altra raccolta.

Se l'ambiente utilizza anche WDAC, la nostra guida alla verifica dell'identità e dell'attivazione dei criteri App Control spiega l'inventario CiTool e le evidenze dei criteri Code Integrity. La nostra guida alla verifica di GUID e azioni Defender ASR sugli endpoint controlla la configurazione delle regole di comportamento con Get-MpPreference. Conservate le evidenze proprie di ogni controllo quando coesistono.

Rilevamento: esportare, valutare e correlare le evidenze di esecuzione

Passaggio 1: esportare i criteri effettivi distribuiti tramite GP

Sul computer valutato e gestito tramite GP, la procedura di test di Microsoft utilizza una sessione amministrativa di Windows PowerShell per esportare i criteri:

Get-AppLockerPolicy -Effective -XML > C:\Effective.xml

Scegliete una posizione autorizzata per le evidenze e conservate l'esportazione originale con i dettagli dell'host, dell'ora e del canale di distribuzione. Esaminate tutte le raccolte applicabili prima di testare i file. Un errore di esportazione è un errore di raccolta; un'esportazione con contenuti inattesi richiede un'indagine rispetto alla configurazione prevista. Nessuno dei due esiti diventa conforme omettendo il dispositivo.

Utilizzate questa esportazione per valutare lo stato GP osservato. Se invece valutate criteri proposti, identificateli come candidati e conservateli separatamente. Testare un file XML candidato non dimostra che un dispositivo abbia ricevuto quei criteri candidati.

Passaggio 2: testare file rappresentativi per l'utente previsto

La stessa procedura Microsoft fornisce questo esempio, che utilizza una directory Office e un utente di esempio:

Get-ChildItem 'C:\Program Files\Microsoft Office\' -filter *.exe -Recurse | Convert-Path | Test-AppLockerPolicy -XMLPolicy C:\Effective.xml -User contoso\zwie -Filter Denied,DeniedByDefault | Export-CSV C:\BlockedFiles.csv

Sostituite la directory, l'identità e la posizione di output con valori approvati per la valutazione. Questo comando valuta i file rispetto ai criteri specificati ed esporta decisioni filtrate. Il nome del file non trasforma il CSV in un registro di blocchi dell'esecuzione. Il filtro degli eseguibili nell'esempio non testa neppure script, programmi di installazione, dipendenze DLL o app in pacchetto.

Il riferimento di Test-AppLockerPolicy elenca Allowed, AllowedByDefault, Denied e DeniedByDefault come filtri delle decisioni. Conservate una valutazione non filtrata oltre a qualsiasi report mirato ai file negati. Altrimenti un report vuoto limitato ai rifiuti non può rivelare quali file siano stati valutati né confermare che siano stati inclusi i casi vietati previsti.

Specificate un account individuale rappresentativo per le regole con gruppi annidati, come raccomanda il riferimento del cmdlet. Testare il nome di un gruppo o l'amministratore che ha raccolto l'esportazione può rispondere a una domanda di autorizzazione diversa dall'accesso dell'utente previsto. Ripetete la valutazione per popolazioni di utenti sostanzialmente diverse e conservate le loro identità insieme ai risultati.

Definite un insieme finito di test con i responsabili delle applicazioni. Includete, ove pertinenti, i flussi approvati di avvio, installazione, aggiornamento ed esecuzione di script, oltre a file innocui deliberatamente esterni all'insieme di applicazioni approvato. Per ogni caso registrate la decisione attesa, l'identità del file o del pacchetto, la raccolta applicabile, l'utente e il risultato della valutazione. I file mancanti e gli errori di valutazione restano lacune esplicite. Non costruite artificialmente un esito positivo a partire da una scansione limitata a una directory.

Passaggio 3: esaminare i registri AppLocker corretti

La procedura di monitoraggio di Microsoft colloca i registri AppLocker in Applications and Services Logs → Microsoft → Windows → AppLocker. Esaminate EXE and DLL per questi tipi di file e MSI and Script per programmi di installazione e script; includete Packaged app-Deployment e Packaged app-Execution quando tali raccolte rientrano nell'ambito.

Il riferimento degli eventi AppLocker documenta queste distinzioni utili:

La documentazione Microsoft sulle regole degli script precisa il significato degli eventi di blocco degli script: è l'host dello script a implementare l'applicazione delle regole. Gli script PowerShell segnalati come bloccati possono comunque essere eseguiti in Constrained Language Mode; gli script autorizzati vengono eseguiti in Full Language Mode. Per un test di script, registrate l'host, la modalità del linguaggio e le operazioni osservate, anziché considerare il solo evento 8007 come prova che non sia stato eseguito alcun codice dello script.

Conservate tutti i dettagli degli eventi, inclusi file, ora, contesto della regola e identità, insieme al registro del test. Un evento relativo a un file di cui si è tentata l'esecuzione non può dimostrare la copertura di ogni carico di lavoro o utente. Prima di interpretare registri senza attività, verificate l'attività esercitata, i permessi di raccolta e la conservazione.

Correzione: validare un progetto pilota ripristinabile dall'audit all'applicazione (Remediation)

Passaggio 1: approvare il comportamento atteso prima di modificare le regole

Risolvete tre decisioni operative: quali evidenze coprono il canale di distribuzione, quali raccolte e modalità interessano l'utente previsto e quali scenari consentiti e vietati saranno validati in laboratorio. Designate il responsabile dei criteri, gli approvatori delle applicazioni e l'operatore incaricato del ripristino. Conservate i criteri attuali e una procedura di ripristino approvata prima di distribuire una modifica.

Utilizzate dispositivi pilota ripristinabili e materiale di test innocuo. Concordate quali flussi necessari devono restare disponibili e quali casi vietati devono fallire dopo l'applicazione delle regole. Un errore in un flusso amministrativo o aziendale necessario interrompe l'estensione finché il responsabile non esamina la regola. Anche un'autorizzazione inattesa per un caso vietato richiede un'indagine; il solo utilizzo riuscito delle applicazioni aziendali non dimostra la restrizione prevista.

Passaggio 2: configurare Audit only ed esercitare il progetto pilota

Per criteri gestiti tramite GPO, utilizzate Group Policy Management Console per gestire la GPO responsabile. La procedura Audit only di Microsoft indica agli amministratori di aprire AppLocker → Properties → Enforcement, selezionare Configured per ogni raccolta scelta, scegliere Audit only e confermare. Local Security Policy è lo strumento corrispondente per la gestione dei criteri locali.

Prima di esercitare il progetto pilota, verificate che Application Identity (AppIDSvc) sia in esecuzione. Microsoft afferma che l'arresto di questo servizio impedisce l'applicazione delle regole AppLocker. Per la distribuzione tramite Group Policy, configurate l'avvio automatico in almeno una GPO che applichi regole AppLocker, in Computer Configuration → Windows Settings → Security Settings → System Services → Application Identity. Conservate lo stato osservato del servizio insieme all'esportazione dei criteri. Procedura del servizio Application Identity

Dopo l'applicazione, raccogliete nuovamente i criteri e ripetete le valutazioni per l'utente previsto. Eseguite gli scenari approvati nel progetto pilota e confrontate gli eventi di audit con le decisioni attese. Chiedete ai responsabili delle applicazioni di spiegare le dipendenze e le eccezioni proposte. Collegate ogni eccezione a un requisito specifico, un approvatore e una decisione di revisione. Non trasformate ogni file sottoposto ad audit in una regola di autorizzazione soltanto per eliminare il rumore dell'audit.

Passaggio 3: applicare le raccolte approvate e validare l'esecuzione

La procedura Enforce rules di Microsoft utilizza la stessa scheda Properties → Enforcement: selezionate Configured per la raccolta da modificare e scegliete Enforce rules. Effettuate la modifica attraverso il responsabile e il canale stabiliti dopo la revisione del progetto pilota. Una distribuzione CSP richiede una propria procedura di gestione approvata.

Esportate nuovamente i criteri GP dopo l'applicazione, confrontate raccolte e modalità e ripetete la valutazione delle regole. Eseguite poi i test di esecuzione approvati come utente previsto sul progetto pilota. Registrate il comportamento effettivo e gli eventi corrispondenti sia per gli scenari necessari sia per quelli vietati. Se il comportamento differisce dalla valutazione, indagate sull'artefatto dei criteri, sullo stato dell'applicazione, sul contesto dell'utente e sulla raccolta applicabile prima di estendere la distribuzione.

Passate a ulteriori popolazioni solo quando i revisori designati accettano le evidenze e la preparazione al ripristino. Conservate i dispositivi sconosciuti e i carichi di lavoro non testati nel registro della modifica. Il criterio di completamento è il comportamento approvato osservato sulla popolazione valutata, con limiti ed eccezioni registrati.

Come EtcSec rileva questo problema

L'etc-collector di EtcSec include ANSSI_R37_APPLOCKER_NOT_ENFORCED. Al commit 0423094759d50002457031317098417993e19510, Detect() in public/internal/audit/detectors/ad/compliance/anssi/anssi-r37-applocker-not-enforced.go:41 converte in minuscolo il DisplayName di ogni GPO raccolta e cerca applocker, wdac, code integrity o srp. Un solo nome corrispondente è sufficiente a lasciare Count 0; nessun nome corrispondente produce Count 1, con gravità Medium. Questo conteggio non rappresenta il numero di endpoint non protetti.

Il predicato non legge regole XML AppLocker, modalità delle raccolte o autorizzazioni specifiche dell'utente. Non dimostra l'applicazione di una GPO a un dispositivo. Un nome evocativo può sopprimere il segnale senza applicazione delle regole; criteri reali con un altro nome possono lasciare il segnale presente. Rinominare una GPO modifica questa euristica senza dimostrare alcun miglioramento della sicurezza.

Il provider LDAP in public/internal/providers/ldap/client.go:1007 recupera i metadati delle GPO. Il fallimento della ricerca restituisce un errore, ma public/internal/audit/engine.go:521 scarta l'errore di GetGPOs mentre assegna le GPO restituite. Di conseguenza, questo segnale da solo non può distinguere una raccolta di GPO fallita da una raccolta riuscita senza indizi nei nomi. Stabilite la qualità della raccolta in modo indipendente prima di interpretarlo.

R37 è un identificatore storico del detector, non il numero della raccomandazione normativa AppLocker. Il codice associa questo controllo a ANSSI PA-099 R11. La guida PA-099, datata 2 ottobre 2023, pagina 28 raccomanda il rafforzamento del sistema e del software che contribuisce all'isolamento dei Tier. Questa raccomandazione generale non trasforma l'euristica sui nomi in un test di conformità specifico per AppLocker.