Linee guida sulla creazione di criteri di negazione del controllo app

Articolo
10/01/2024
Si applica a:

✅ Windows 11, ✅ Windows 10

Con Controllo app per le aziende è possibile creare criteri per negare in modo esplicito driver e applicazioni specifici. Per creare criteri di negazione di Controllo app per le aziende efficaci, è necessario comprendere l'ordine di precedenza delle regole applicato a Controllo app durante la valutazione dei file rispetto ai criteri attivi.

Criteri di negazione autonomi

Quando si crea un criterio costituito esclusivamente da regole di negazione, è necessario includere regole "Consenti tutte" nelle sezioni kernel e modalità utente del criterio oltre alle regole di negazione esplicite. Le regole "Consenti tutto" garantiscono che l'esecuzione di qualsiasi elemento non esplicitamente negato dai criteri sia consentito. Se non si aggiungono regole "Consenti tutto" a un criterio di sola negazione, si rischia di bloccare tutto. Questo risultato si verifica perché il codice viene negato in modo esplicito e tutto il codice viene negato in modo implicito , perché non sono presenti regole per autorizzarlo. È consigliabile usare il modello di criteri AllowAll durante la creazione dei criteri di negazione autonomi.

<FileRules>
  <Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
  <Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />
</FileRules>
<SigningScenarios>
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_1" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_2" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
</SigningScenarios>

L'aggiunta delle regole "Consenti tutto" precedenti non influisce sugli altri criteri di controllo app distribuiti che applicano un elenco di elementi consentiti espliciti. Per illustrare, si consideri l'esempio seguente:

Policy1 è un elenco di elementi consentiti per le applicazioni firmate da Windows e Microsoft.

Policy2 è il nuovo criterio di negazione, che blocca MaliciousApp.exe e anche il wmic.exe binario del componente Windows. Include anche le regole "Consenti tutto".

MaliciousApp.exe è bloccato perché è presente una regola di blocco esplicita in Policy2. È anche implicitamente bloccato da Policy1 perché non esistono regole di autorizzazione che coprono il file in tale criterio.
Il file firmato da Windows wmic.exe è bloccato perché è presente una regola di blocco esplicita in Policy2.
Tutte le altre applicazioni firmate da Windows e Microsoft sono consentite perché è presente una regola di autorizzazione esplicita sia in Policy1 che in Policy2 che copre il file.
Tutte le altre applicazioni vengono negate in modo implicito. Ad esempio, ExampleApp.exe, non è consentito perché è considerato attendibile solo da Policy2 (a causa delle regole Consenti tutte) e non da Policy1.

Considerazioni miste relative ai criteri Consenti e Nega

Se il set di regole di negazione deve essere aggiunto a un criterio esistente che include regole di autorizzazione esplicite, non includere le regole "Consenti tutto" precedenti. Le regole di negazione devono invece essere unite ai criteri di controllo app esistenti tramite la Creazione guidata controllo app o usando il comando powershell seguente:

$DenyPolicy = <path_to_deny_policy>
$ExistingPolicy = <path_to_existing_policy>
Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $ExistingPolicy

Procedure consigliate

Test prima in modalità di controllo : come per tutti i nuovi criteri, è consigliabile implementare i nuovi criteri di rifiuto in modalità di controllo e monitorare gli eventi del blocco di controllo 3076 per garantire che vengano bloccate solo le applicazioni che si intende bloccare. Altre informazioni sul monitoraggio degli eventi di blocco tramite i log di Visualizzatore eventi e Ricerca avanzata: Gestione e risoluzione dei problemi relativi ai criteri di controllo delle app per le aziende
Tipi di regole di negazione consigliati : le regole di firma e di attributo file sono consigliate dal punto di vista della sicurezza, della gestibilità e delle prestazioni. Le regole hash devono essere usate solo se necessario. Poiché l'hash di un file cambia con qualsiasi modifica al file, è difficile tenere il passo con un criterio di blocco basato su hash in cui l'utente malintenzionato può aggiornare facilmente il file. Mentre Controllo app ha ottimizzato l'analisi delle regole hash, alcuni dispositivi potrebbero visualizzare effetti sulle prestazioni durante la valutazione del runtime se i criteri hanno decine di migliaia o più regole hash.

Esercitazione sulla creazione di criteri di negazione

È possibile creare regole e criteri di negazione usando i cmdlet di PowerShell o la Creazione guidata controllo app. È consigliabile creare regole del firmatario (PCACertificate, Publisher e FilePublisher) laddove possibile. Nei casi di file binari senza segno, è necessario creare regole sugli attributi del file, ad esempio il nome file originale o l'hash.

Regola di negazione basata su Server di pubblicazione software

$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Fallback SignedVersion,Publisher,Hash -Deny

Regola di negazione basata su attributi software

$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Fallback Hash -Deny

Regola di negazione basata su hash

$DenyRules += New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny

Unire le regole di negazione con i criteri modello AllowAll

Dopo aver creato le regole di negazione, è possibile unirle ai criteri del modello AllowAll:

$DenyPolicy = <path_to_deny_policy_destination>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $AllowAllPolicy -OutputFilePath $DenyPolicy -Rules $DenyRules
Set-CiPolicyIdInfo -FilePath $DenyPolicy -PolicyName "My Deny Policy" -ResetPolicyID

Distribuire i criteri di negazione

È ora necessario disporre di un criterio di negazione pronto per la distribuzione. Vedere la Guida alla distribuzione del controllo app per distribuire i criteri negli endpoint gestiti.

Condividi tramite