Informazioni sulle regole dei criteri e sui file del controllo delle applicazioni (WDAC) Windows Defender

Nota

Alcune funzionalità di controllo delle applicazioni Windows Defender sono disponibili solo in versioni specifiche di Windows. Altre informazioni sulla disponibilità delle funzionalità WDAC.

Windows Defender controllo delle applicazioni (WDAC) può controllare le esecuzioni nei dispositivi Windows impostando criteri che specificano se un driver o un'applicazione è attendibile. Un criterio include regole di criteri che controllano opzioni come la modalità di controllo e regole di file (o livelli di regole file) che specificano come identificare le applicazioni attendibili dall'organizzazione.

Regole dei criteri Windows Defender Application Control

Per modificare le opzioni delle regole dei criteri di un xml dei criteri WDAC esistente, usare la Creazione guidata criteri WDAC o il cmdlet Di PowerShell Set-RuleOption .

All'interno di un criterio WDAC puoi impostare diverse opzioni delle regole. La tabella 1 descrive ogni opzione di regola e indica se i criteri supplementari possono impostarli. Alcune opzioni delle regole sono riservate per il lavoro futuro o non sono supportate.

Nota

È consigliabile usare inizialmente la modalità Enabled:Audit perché consente di testare nuovi criteri WDAC prima di applicarli. Con la modalità di controllo, le applicazioni vengono eseguite normalmente, ma WDAC registra gli eventi ogni volta che viene eseguito un file non consentito dai criteri. Per consentire questi file, è possibile acquisire le informazioni sui criteri dal registro eventi e quindi unire tali informazioni nei criteri esistenti. Quando la modalità Enabled:Audit viene eliminata, i criteri vengono eseguiti in modalità applicata.

Alcune app possono comportarsi in modo diverso anche quando i criteri sono in modalità di controllo. Quando un'opzione può modificare i comportamenti in modalità di controllo, come indicato nella tabella 1. Quando si distribuiscono aggiornamenti significativi nei criteri WDAC, è consigliabile testare sempre accuratamente le app.

Tabella 1. Criteri Windows Defender Application Control: opzioni delle regole dei criteri

Opzione della regola Descrizione Opzione supplementare valida
0 Enabled:UMCI I criteri WDAC limitano i file binari sia in modalità kernel che in modalità utente. Per impostazione predefinita, sono limitati solo i file binari in modalità kernel. Abilitando questa opzione della regola vengono convalidati script ed eseguibili in modalità utente. No
1 Enabled:Boot Menu Protection Questa opzione non è attualmente supportata. No
2 Required:WHQL Per impostazione predefinita, i driver del kernel non firmati da Windows Hardware Quality Labs (WHQL) possono essere eseguiti. L'abilitazione di questa regola richiede che ogni driver sia firmato WHQL e rimuova il supporto dei driver legacy. I driver del kernel creati per Windows 10 devono essere certificati WHQL. No
3 Enabled:Audit Mode (impostazione predefinita) Indica a WDAC di registrare informazioni su applicazioni, file binari e script che sarebbero stati bloccati, se i criteri sono stati applicati. È possibile usare questa opzione per identificare il potenziale impatto dei criteri WDAC e usare gli eventi di controllo per perfezionare i criteri prima dell'imposizione. Per applicare un criterio WDAC, eliminare questa opzione. No
4 Disabled:Flight Signing Se abilitata, i file binari delle build di Windows Insider non sono attendibili. Questa opzione è utile per le organizzazioni che vogliono eseguire solo i file binari rilasciati, non le build di Windows non definitive. No
5 Enabled:Inherit Default Policy Questa opzione è riservata per uso futuro e attualmente non ha alcun effetto. Sì
6 Enabled:Unsigned System Integrity Policy (impostazione predefinita) Consente che il criterio resti senza firma. Quando questa opzione viene rimossa, i criteri devono essere firmati e devono essere firmati anche eventuali criteri supplementari. I certificati attendibili per gli aggiornamenti futuri dei criteri devono essere identificati nella sezione UpdatePolicySigners. I certificati considerati attendibili per i criteri supplementari devono essere identificati nella sezione SupplementalPolicySigners. No
7 Allowed:Debug Policy Augmented Questa opzione non è attualmente supportata. Sì
8 Required:EV Signers Questa opzione non è attualmente supportata. No
9 Enabled:Advanced Boot Options Menu Il menu delle opzioni prima dell'avvio F8 è disabilitato per impostazione predefinita per tutti i criteri WDAC. Impostando questa opzione della regola, gli utenti fisicamente presenti possono visualizzare il menu F8. No
10 Enabled:Boot Audit on Failure Usato quando il criterio WDAC è in modalità di imposizione. Quando un driver critico per l'avvio non riesce durante l'avvio, i criteri WDAC vengono inseriti in modalità di controllo in modo che Windows venga caricato. Gli amministratori possono verificare il motivo dell'errore nel registro eventi CodeIntegrity. No
11 Disabled:Script Enforcement Questa opzione disabilita le opzioni di imposizione degli script, che riguardano PowerShell, Windows Based Script Host (wscript.exe), Windows Console Based Script Host (cscript.exe), i file HTA eseguiti in Microsoft HTML Application Host (mshta.exe) e MSXML. Alcuni host di script possono comportarsi in modo diverso anche quando i criteri sono in modalità di controllo. Per altre informazioni sull'imposizione degli script, vedere Applicazione di script con WDAC.
NOTA: questa opzione non è supportata in Windows Server 2016 o Windows 10 1607 LTSB e non deve essere usata in tali sistemi operativi.		 No
12 Required:Enforce Store Applications Se questa opzione della regola è abilitata, i criteri WDAC si applicano anche alle applicazioni di Windows universale. No
13 Enabled:Managed Installer Usare questa opzione per consentire automaticamente le applicazioni installate da un programma di installazione gestito. Per altre informazioni, vedere Autorizzare le app distribuite con un programma di installazione gestito di WDAC Sì
14 Enabled:Intelligent Security Graph Authorization Usare questa opzione per consentire automaticamente alle applicazioni con reputazione "nota" come definito da Intelligent Security Graph (ISG) di Microsoft. Sì
15 Enabled:Invalidate EAs on Reboot Quando viene utilizzata l'opzione Intelligent Security Graph (14), WDAC imposta un attributo di file esteso che indica che è stata autorizzata l'esecuzione del file. Questa opzione fa sì che WDAC riconvalidi periodicamente la reputazione per i file precedentemente autorizzati dall'ISG. No
16 Enabled:Update Policy No Reboot Utilizza questa opzione per autorizzare l'applicazione degli aggiornamenti futuri dei criteri WDAC senza che sia necessario riavviare il sistema.
NOTA: questa opzione è supportata solo in Windows 10, versione 1709 e successive o Windows Server 2019 e versioni successive.		 No
17 Abilitato:Consenti criteri supplementari Usare questa opzione in un criterio di base per consentire ai criteri supplementari di espanderla.
NOTA: questa opzione è supportata solo in Windows 10, versione 1903 e successive o Windows Server 2022 e versioni successive.		 No
18 Disabilitato:Runtime FilePath Rule Protection Questa opzione disabilita il controllo di runtime predefinito che consente solo regole FilePath per i percorsi scrivibili solo da un amministratore.
NOTA: questa opzione è supportata solo in Windows 10, versione 1903 e successive o Windows Server 2022 e versioni successive.		 Sì
19 Abilitato:Sicurezza dinamica del codice Abilita l'imposizione dei criteri per le applicazioni .NET e le librerie caricate in modo dinamico.
NOTA: questa opzione è supportata solo in Windows 10, versione 1803 e successive o Windows Server 2019 e versioni successive.
NOTA: questa opzione viene sempre applicata se i criteri WDAC UMCI lo abilitano. Non è disponibile alcuna modalità di controllo per la protezione avanzata della sicurezza del codice dinamico .NET.		 No
20 Abilitato:Revocato scaduto come non firmato Usare questa opzione per considerare i file binari firmati con certificati revocati o i certificati scaduti con l'EKU di firma a durata nella firma, come "file binari non firmati" per processi/componenti in modalità utente, in scenari di firma aziendale. No
Enabled:Developer Mode Dynamic Code Trust Usare questa opzione per considerare attendibili le app UWP sottoposte a debug in Visual Studio o distribuite tramite il portale del dispositivo quando la modalità sviluppatore è abilitata nel sistema. No

Livelli delle regole dei file Windows Defender Application Control

I livelli delle regole dei file permettono agli amministratori di specificare il livello di attendibilità delle applicazioni. Questo livello di attendibilità può essere granulare come l'hash di ogni file binario o generale come un certificato CA. È possibile specificare i livelli delle regole di file quando si usano i cmdlet WDAC Wizard o PowerShell di WDAC per creare e modificare i criteri.

Ogni livello di regola del file presenta vantaggi e svantaggi. Usare la tabella 2 per selezionare il livello di protezione appropriato per le risorse amministrative disponibili e lo scenario di distribuzione WDAC.

Nota

Le regole basate sul firmatario WDAC funzionano solo con la crittografia RSA. Gli algoritmi ECC, ad esempio ECDSA, non sono supportati. Se si tenta di consentire i file in base alla firma in base alle firme ECC, verrà visualizzato VerificationError = 23 negli eventi di informazioni sulla firma 3089 corrispondenti. I file possono essere consentiti invece da regole di hash o di attributi di file o usando altre regole del firmatario se il file è firmato anche con firme usando RSA.

Tabella 2. Criteri Windows Defender Application Control: livello delle regole dei file

Livello regola Descrizione
Hash Specifica i singoli valori hash dell'immagine Authenticode/PE per ogni file binario individuato. Questo livello è il livello più specifico e richiede maggiore impegno per mantenere i valori hash delle versioni del prodotto correnti. Ogni volta che un file binario viene aggiornato il valore hash cambia, pertanto è necessario aggiornare i criteri.
FileName Specifica il nome file originale per ogni file binario. Anche se i valori hash di un'applicazione cambiano quando viene aggiornata, in genere i nomi del file restano invariati. Questo livello offre una sicurezza meno specifica rispetto al livello hash, ma in genere non richiede un aggiornamento dei criteri quando viene modificato un file binario. Per impostazione predefinita, questo livello usa l'attributo OriginalFileName dell'intestazione della risorsa del file. Utilizzare -SpecificFileNameLevel per scegliere un attributo alternativo, ad esempio ProductName.
FilePath A partire da Windows 10 versione 1903, questo livello consente l'esecuzione di file binari da percorsi di file specifici. Le regole FilePath si applicano solo ai file binari in modalità utente e non possono essere usate per consentire i driver in modalità kernel. Altre informazioni sulle regole a livello di FilePath sono disponibili più avanti in questo articolo.
SignedVersion Questo livello combina la regola del server di pubblicazione con un numero di versione. Consente l'esecuzione di qualsiasi elemento dal server di pubblicazione specificato con una versione in corrispondenza o superiore al numero di versione specificato.
Pubblicato da Questo livello combina il livello PcaCertificate (in genere un certificato sotto la radice) e il nome comune (CN) del certificato foglia. È possibile usare questo livello di regola per considerare attendibile un certificato emesso da una ca specifica e rilasciato a una società specifica considerata attendibile (ad esempio Intel, per i driver di dispositivo).
FilePublisher Questo livello combina l'attributo "FileName" del file firmato, più "Publisher" (certificato PCA con CN di foglia), più un numero di versione minimo. Questa opzione considera attendibili i file specifici dell'autore specificato con versione uguale o superiore al numero di versione specificato. Per impostazione predefinita, questo livello usa l'attributo OriginalFileName dell'intestazione della risorsa del file. Utilizzare -SpecificFileNameLevel per scegliere un attributo alternativo, ad esempio ProductName.
LeafCertificate Aggiunge firmatari attendibili a livello di certificato di firma singolo. Il vantaggio dell'uso di questo livello rispetto al singolo livello hash è che le nuove versioni del prodotto hanno valori hash diversi, ma in genere lo stesso certificato di firma. Quando si usa questo livello, non è necessario alcun aggiornamento dei criteri per eseguire la nuova versione dell'applicazione. Tuttavia, i certificati foglia hanno in genere periodi di validità più brevi rispetto ad altri livelli di certificato, quindi i criteri WDAC devono essere aggiornati ogni volta che questi certificati cambiano.
PcaCertificate Aggiunge ai firmatari il certificato disponibile più elevato della catena di certificati. Questo livello è in genere un certificato sotto la radice perché l'analisi non risolve la catena di certificati completa tramite gli archivi radice locali o con un controllo online.
RootCertificate Non supportato.
WHQL Considera attendibili solo i file binari inviati a Microsoft e firmati da Windows Hardware Qualification Lab (WHQL). Questo livello è principalmente per i file binari del kernel.
WHQLPublisher Questo livello combina il livello WHQL e il cn nel certificato foglia ed è principalmente per i file binari del kernel.
WHQLFilePublisher Questo livello combina l'attributo "FileName" del file firmato, più "WHQLPublisher", più un numero di versione minimo. Questo livello è principalmente per i file binari del kernel. Per impostazione predefinita, questo livello usa l'attributo OriginalFileName dell'intestazione della risorsa del file. Utilizzare -SpecificFileNameLevel per scegliere un attributo alternativo, ad esempio ProductName.

Nota

Quando si creano criteri WDAC con New-CIPolicy, è possibile specificare un livello di regola del file primario, includendo il parametro -Level . Per i file binari individuati che non possono essere considerati attendibili in base ai criteri del livello primario delle regole dei file, usa il parametro -Fallback. Ad esempio, se il livello della regola del file primario è PCACertificate, ma si vuole considerare attendibili anche le applicazioni non firmate, l'uso del livello di regola Hash come fallback aggiunge i valori hash dei file binari che non avevano un certificato di firma.

Nota

  • WDAC supporta solo le regole del firmatario per le chiavi di firma del certificato RSA con un massimo di 4096 bit.
  • Il codice usa CN per i campi CertSubject e CertIssuer nei criteri. È possibile usare il certutil della posta in arrivo per esaminare il formato sottostante per assicurarsi che UTF-8 non venga usato per il CN. Ad esempio, è possibile usare stringa stampabile, IA5 o BMP.

Nota

Se applicabile, i numeri di versione minima e massima in una regola di file vengono indicati rispettivamente come MinimumFileVersion e MaximumFileVersion nel codice XML dei criteri.

  • Specificati sia MinimumFileVersion che MaximumFileVersion: per le regole Allow sono consentiti file con versione maggiore o uguale a MinimumFileVersion e minore o uguale a MaximumFileVersion. Per le regole deny, il file con versione maggiore o uguale a MinimumFileVersion e minore o uguale a MaximumFileVersion viene negato.
  • MinimumFileVersion specificato senza MaximumFileVersion: per le regole Consenti, è consentito l'esecuzione di file con versione maggiore o uguale alla versione specificata. Per le regole di negazione, il file con versione minore o uguale alla versione specificata viene bloccato.
  • MaximumFileVersion specificato senza MinimumFileVersion: per le regole Allow è consentito l'esecuzione di file con versione minore o uguale alla versione specificata. Per le regole deny, il file con versione maggiore o uguale alla versione specificata viene bloccato.

Esempio di livelli delle regole dei file in uso

Si consideri, ad esempio, un professionista IT in un reparto che esegue molti server. Vogliono eseguire solo software firmato dalle aziende che forniscono il loro hardware, sistema operativo, antivirus e altro software importante. I professionisti IT sanno che i server eseguono anche un'applicazione scritta internamente che non è firmata, ma viene raramente aggiornata, e vogliono consentirne l'esecuzione.

Per creare i criteri WDAC, creano un server di riferimento sul loro hardware standard e installano tutto il software in esecuzione nei server. Quindi eseguono New-CIPolicy con -Level Publisher (per consentire il software dei loro provider software, gli "Autori") e -Fallback Hash (per consentire l'applicazione interna non firmata). Distribuiscono i criteri in modalità di controllo per determinare il potenziale impatto dell'applicazione dei criteri. Con l'aiuto dei dati di controllo, aggiornano i criteri WDAC per includere qualsiasi altro software che vogliono eseguire. Quindi abilitano i criteri WDAC in modalità di imposizione per i server.

Come parte delle normali operazioni, alla fine installeranno gli aggiornamenti software o potrebbero aggiungere software dagli stessi provider di software. Poiché il "server di pubblicazione" rimane lo stesso per gli aggiornamenti e il software, non è necessario aggiornare i criteri WDAC. Se l'applicazione interna non firmata viene aggiornata, è necessario aggiornare anche i criteri WDAC per consentire la nuova versione.

Ordine di precedenza delle regole di file

WDAC ha una logica di conflitto di regole file predefinita che si traduce in ordine di precedenza. Prima di tutto elabora tutte le regole di negazione esplicite trovate. Elabora quindi tutte le regole di autorizzazione esplicite. Se non esiste alcuna regola di negazione o autorizzazione, WDAC verifica la presenza di un'attestazione del programma di installazione gestita , se consentita dai criteri. Infine, WDAC torna all'ISG se consentito dai criteri.

Nota

Per semplificare il ragionamento sui criteri WDAC, è consigliabile mantenere criteri ALLOW e DENY separati nelle versioni di Windows che supportano più criteri WDAC.

Usare -SpecificFileNameLevel con regole di livello FileName, FilePublisher o WHQLFilePublisher

Per impostazione predefinita, i livelli di regola FileName, FilePublisher e WHQLFilePublisher usano l'attributo OriginalFileName dall'intestazione della risorsa del file. È possibile usare un attributo di intestazione di risorsa alternativo per le regole impostando -SpecificFileNameLevel. Ad esempio, uno sviluppatore di software potrebbe usare lo stesso ProductName per tutti i file binari che fanno parte di un'app. Usando -SpecificFileNameLevel, è possibile creare una singola regola per coprire tutti i file binari nei criteri anziché le singole regole per ogni file.

La tabella 3 descrive le opzioni disponibili per gli attributi dell'intestazione della risorsa che è possibile impostare con -SpecificFileNameLevel.

Tabella 3. Opzioni -SpecificFileNameLevel

Valore SpecificFileNameLevel Descrizione
FileDescription Specifica la descrizione del file fornita dallo sviluppatore del file binario.
InternalName Specifica il nome interno del file binario.
OriginalFileName Specifica il nome del file originale, o il nome con cui il file è stato creato per la prima volta, del file binario.
PackageFamilyName Specifica il nome della famiglia di pacchetti del file binario. Il nome della famiglia di pacchetti è costituito da due parti: il nome del file e l'ID editore.
Productname Specifica il nome del prodotto con cui viene fornito il file binario.
Filepath Specifica il percorso del file binario.

Altre informazioni sulle regole del percorso file

Le regole di percorso file non offrono le stesse garanzie di sicurezza offerte dalle regole esplicite del firmatario, poiché si basano sulle autorizzazioni di accesso modificabili. Le regole filepath sono più adatte per gli ambienti in cui la maggior parte degli utenti è in esecuzione come standard anziché come amministratore. Le regole di percorso sono più adatte per consentire percorsi che si prevede rimangano solo scrivibili dall'amministratore. È possibile evitare le regole di percorso per le directory in cui gli utenti standard possono modificare gli elenchi di controllo di accesso nella cartella.

Percorsi file scrivibili dall'utente

Per impostazione predefinita, WDAC esegue un controllo di scrivibilità utente in fase di esecuzione che garantisce che le autorizzazioni correnti nel percorso file specificato consentano l'accesso in scrittura solo agli utenti amministratori.

È disponibile un elenco definito di SID riconosciuti da WDAC come amministratori. Se un percorso file consente autorizzazioni di scrittura per qualsiasi SID non incluso in questo elenco, il percorso file viene considerato scrivibile dall'utente, anche se il SID è associato a un utente amministratore personalizzato. Per gestire questi casi speciali, è possibile eseguire l'override del controllo di scrittura dell'amministratore di runtime di WDAC con l'opzione Disabled:Runtime FilePath Rule Protection descritta in precedenza.

L'elenco di SID di amministrazione noti di WDAC è:

S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-16855971119-444378811-2746676523.

Quando le regole del percorso file vengono generate usando New-CIPolicy, viene generata una regola di percorso completa univoca per ogni file individuato nei percorsi analizzati. Per creare regole che consentano invece tutti i file in un percorso di cartella specificato, usare New-CIPolicyRule per definire regole contenenti caratteri jolly, usando l'opzione -FilePathRules .

Uso di caratteri jolly nelle regole del percorso file WDAC

I caratteri jolly seguenti possono essere usati nelle regole del percorso file WDAC:

Carattere jolly Significato Sistemi operativi supportati
* Corrisponde a zero o più caratteri. Windows 11, Windows 10 e Windows Server 2022
? Corrisponde a un singolo carattere. solo Windows 11

È anche possibile utilizzare le macro seguenti quando il volume esatto può variare: %OSDRIVE%, , %WINDIR%%SYSTEM32%. Queste macro possono essere usate in combinazione con i caratteri jolly sopra indicati.

Nota

In Windows 11 è possibile usare uno o più caratteri jolly in qualsiasi punto all'interno di una regola di percorso file.

In tutte le altre versioni di Windows e Windows Server è consentito un solo carattere jolly per ogni regola di percorso e deve trovarsi all'inizio o alla fine di una regola di percorso.

Regole di filepath di esempio con caratteri jolly

Esempi Descrizione Sistemi operativi supportati
C:\windows\*
D:\EnterpriseApps\MyApp\*
%OSDRIVE%\Windows\*		 I caratteri jolly posizionati alla fine di un percorso autorizzano tutti i file nel percorso immediato e le relative sottodirectory in modo ricorsivo. Windows 11, Windows 10 e Windows Server 2022
*\bar.exe I caratteri jolly posizionati all'inizio di un percorso consentono il nome file specificato esatto in qualsiasi percorso. Windows 11, Windows 10 e Windows Server 2022
C:\*\CCMCACHE\*\7z???? -x64.exe
%OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe		 I caratteri jolly usati al centro di un percorso consentono tutti i file che corrispondono a tale modello. Valutare attentamente tutte le corrispondenze possibili, in particolare se il criterio disabilita il controllo scrivibile dall'amministratore con l'opzione Disabled:Runtime FilePath Rule Protection . In questo esempio, entrambi questi percorsi ipotetici corrisponderebbero:
C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe
C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe		 solo Windows 11

Senza un carattere jolly, la regola filepath consente solo un file specifico (ad esempio C:\foo\bar.exe).

Nota

Quando si creano criteri WDAC con Configuration Manager, è disponibile un'opzione per creare regole per file e cartelle specificati. Queste regole non sono regole del percorso file WDAC. Piuttosto, Configuration Manager esegue un'analisi una tantum dei file e delle cartelle specificati e compila le regole per tutti i file binari presenti in tali posizioni al momento dell'analisi. Le modifiche ai file e alle cartelle specificate dopo l'analisi non saranno consentite a meno che il criterio di Configuration Manager non venga riapplicato.

Altre informazioni sugli hash

WDAC usa l'algoritmo hash dell'immagine Authenticode/PE durante il calcolo dell'hash di un file. A differenza dell'hash di file flat più comunemente noto, il calcolo dell'hash Authenticode omette il checksum del file, la tabella dei certificati e la tabella del certificato degli attributi. Pertanto, l'hash Authenticode di un file non cambia quando le firme e i timestamp del file vengono modificati o quando una firma digitale viene rimossa dal file. Con l'aiuto dell'hash Authenticode, WDAC offre una maggiore sicurezza e un minor sovraccarico di gestione in modo che i clienti non debbano rivedere le regole hash dei criteri quando la firma digitale nel file viene aggiornata.

L'hash dell'immagine Authenticode/PE può essere calcolato per i file con firma digitale e senza firma.

Perché l'analisi crea quattro regole hash per ogni file XML?

Il cmdlet di PowerShell produce un hash Sha1 Authenticode, un hash Sha256, un hash di pagina Sha1 e un hash di pagina Sha256. Durante la convalida, WDAC seleziona gli hash calcolati in base alla modalità di firma del file e allo scenario in cui viene usato il file. Ad esempio, se il file è firmato con hash di pagina, WDAC convalida ogni pagina del file ed evita di caricare l'intero file in memoria per calcolare l'hash di authenticode sha256 completo.

Nei cmdlet, invece di provare a stimare quale hash verrà usato, si precalcolano e si usano i quattro hash (sha1/sha2 authenticode e sha1/sha2 della prima pagina). Questo metodo è anche resiliente alle modifiche apportate alla modalità di firma del file poiché i criteri WDAC hanno già più di un hash disponibile per il file.

Perché l'analisi crea otto regole hash per determinati file?

Vengono create regole separate per UMCI e KMCI. Se i cmdlet non riescono a determinare che un file viene eseguito solo in modalità utente o nel kernel, vengono create regole per entrambi gli scenari di firma con molta cautela. Se si sa che un determinato file viene caricato solo in modalità utente o kernel, è possibile rimuovere in modo sicuro le regole aggiuntive.

Quando WDAC usa il valore hash del file flat?

Esistono alcuni rari casi in cui il formato di un file non è conforme alla specifica Authenticode e quindi WDAC restituisce l'uso dell'hash del file flat. Questo comportamento può verificarsi per molti motivi, ad esempio se vengono apportate modifiche alla versione in memoria del file in fase di esecuzione. In questi casi, si noterà che l'hash visualizzato nell'evento di informazioni sulla firma 3089 correlato corrisponde all'hash del file flat dell'evento di blocco 3076/3077. Per creare regole per i file con un formato non valido, è possibile aggiungere regole hash ai criteri per l'hash dei file flat usando la Creazione guidata WDAC o modificando direttamente il codice XML dei criteri.