Documentação de orientação sobre a criação de políticas de negação de controlo de aplicações
Com o Controlo de Aplicações para Empresas, pode criar políticas para negar explicitamente aplicações e controladores específicos. Para criar políticas de negação eficazes do Controlo de Aplicações para Empresas, deve compreender a ordem de precedência de regras que o Controlo de Aplicações aplica à medida que avalia os ficheiros relativamente às políticas ativas.
Política de Negação Autónoma
Ao criar uma política que consiste exclusivamente em regras de negação, tem de incluir regras "Permitir Tudo" nas secções kernel e modo de utilizador da política, além das regras de negação explícitas. As regras "Permitir Tudo" garantem que tudo o que não for explicitamente negado pela sua política tem permissão para ser executado. Se não conseguir adicionar regras "Permitir Tudo" a uma política só de negação, corre o risco de bloquear tudo. Este resultado acontece porque alguns códigos são explicitamente negados e todos os outros códigos são implicitamente negados, porque não existem regras para o autorizar. Recomendamos que utilize o modelo de política PermitirTodos ao criar as suas políticas de negação autónomas.
<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>
Adicionar as regras "Permitir Tudo" anteriores não afeta quaisquer outras políticas de Controlo de Aplicações que tenha implementado que apliquem uma lista de permissões explícita. Para ilustrar, considere o seguinte exemplo:
Policy1 é uma lista de permissões para aplicações assinadas pela Microsoft e windows.
Policy2 é a nossa nova política de negação, que bloqueia MaliciousApp.exe e também a wmic.exe binária de componentes do Windows. Também inclui as regras "Permitir Tudo".
- MaliciousApp.exe está bloqueada, uma vez que existe uma regra de bloqueio explícita na Política2. Também é implicitamente bloqueado pelo Policy1, uma vez que não existem regras de permissão que cubram o ficheiro nessa política.
- O ficheiro assinado pelo Windows wmic.exe está bloqueado, uma vez que existe uma regra de bloqueio explícita na Política2.
- Todas as outras aplicações assinadas pelo Windows e pela Microsoft são permitidas, uma vez que existe uma regra de permissão explícita na Política1 e na Política2 que abrange o ficheiro.
- Todas as outras aplicações são implicitamente negadas. Por exemplo, ExampleApp.exe, não é permitido, uma vez que é apenas fidedigno pela Policy2 (devido às regras Permitir Tudo) e não pela Política1.
Considerações de políticas de Permissão e Negação Mistas
Se o conjunto de regras de negação for adicionado a uma política existente que inclua regras de permissão explícitas, não inclua as regras "Permitir Tudo" anteriores. Em vez disso, as regras de negação devem ser intercaladas com a política de Controlo de Aplicações existente através do Assistente de Controlo de Aplicações ou através do seguinte comando do PowerShell:
$DenyPolicy = <path_to_deny_policy>
$ExistingPolicy = <path_to_existing_policy>
Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $ExistingPolicy
Práticas recomendadas
Teste primeiro no Modo de auditoria – tal como acontece com todas as novas políticas, recomendamos a implementação da nova política de negação no Modo de Auditoria e a monitorização dos eventos do bloco de auditoria 3076 para garantir que apenas as aplicações que pretendia bloquear são bloqueadas. Mais informações sobre a monitorização de eventos de bloqueio através dos registos de Visualizador de Eventos e Investigação Avançada: Gerir e resolver problemas de políticas do Controlo de Aplicações para Empresas
Tipos de Regras de Negação Recomendados – as regras de atributos de ficheiros e signatários são recomendadas a partir de uma perspetiva de segurança, capacidade de gestão e desempenho. As regras de hash só devem ser utilizadas se necessário. Uma vez que o hash de um ficheiro é alterado com qualquer alteração ao ficheiro, é difícil acompanhar uma política de bloqueio baseada em hash em que o atacante pode atualizar o ficheiro de forma trivial. Embora o Controlo de Aplicações tenha otimizado a análise de regras hash, alguns dispositivos poderão ver impactos de desempenho na avaliação do runtime se as políticas tiverem dezenas de milhares ou mais regras de hash.
Criar um tutorial de política Negar
As regras e políticas de negação podem ser criadas com os cmdlets do PowerShell ou o Assistente de Controlo de Aplicações. Recomendamos a criação de regras de signatário (PCACertificate, Publisher e FilePublisher) sempre que possível. Nos casos de binários não assinados, as regras têm de ser criadas em atributos do ficheiro, como o nome de ficheiro original ou o hash.
Regra de negação baseada no Software Publisher
$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Fallback SignedVersion,Publisher,Hash -Deny
Regra de negação baseada em atributos de software
$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Fallback Hash -Deny
Regra de negação baseada em hash
$DenyRules += New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny
Intercalar regras de negação com a política permitirTodos os modelos
Depois de criar as regras de negação, pode intercalá-las com a política de modelo PermitirTodos:
$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
Implementar a Política de Negação
Deverá agora ter uma política de negação preparada para implementar. Veja o Guia de Implementação do Controlo de Aplicações para implementar a política nos pontos finais geridos.