Controle de aplicativo Essential Eight

Este artigo detalha os métodos para alcançar o modelo de maturidade de oito maturidade essencial do Centro australiano de Segurança Cibernética (ACSC) para controle de aplicativo, usando o Microsoft App Locker e Windows Defender Controle de Aplicativos.

Por que seguir as diretrizes de controle do aplicativo ACSC Essential Eight?

O controle de aplicativo é uma abordagem de segurança projetada para proteger contra a execução de código mal-intencionado em sistemas. Quando essa abordagem de segurança é implementada, ela garante que apenas o código aprovado, como executáveis, bibliotecas de software, scripts, instaladores e drivers, esteja autorizado a ser executado. Devido à sua eficácia, o controle de aplicativo é um dos Oito Essenciais das Estratégias do ACSC para mitigar incidentes de segurança cibernética.

Controle da aplicação

O controle de aplicativo é uma abordagem de segurança projetada para proteger contra a execução de código mal-intencionado em sistemas. Quando essa abordagem de segurança é implementada, ela garante que apenas o código aprovado, como executáveis, bibliotecas de software, scripts, instaladores e drivers, esteja autorizado a ser executado.

Embora o controle de aplicativo seja projetado principalmente para impedir a execução e a propagação de código mal-intencionado em um sistema, ele também pode impedir a instalação e o uso de aplicativos não aprovados.

Alcançar requisitos de nível de maturidade organizacional

• Nível de maturidade 1 (ML1): pode ser alcançado usando o Microsoft AppLocker
• Níveis de maturidade 2 e 3 (ML2 & ML3): podem ser alcançados usando o Microsoft Windows Defender Application Control

Implementação do controle de aplicativo

Implementar o controle de aplicativo envolve as seguintes etapas de alto nível para uma organização:

• Identificando aplicativos aprovados
• Desenvolver regras de controle de aplicativo para garantir que somente aplicativos aprovados possam ser executados
• Manter as regras de controle do aplicativo usando um processo de gerenciamento de alterações
• Validar regras de controle de aplicativo com frequência

Ao determinar como impor a autorização de aplicativo em sua organização, o Centro de Segurança Cibernética da Austrália considera os seguintes métodos adequados quando implementados corretamente:

• Regras de hash criptográficas
• Regras de certificação do editor
• Regras de caminho (quando as permissões do sistema de arquivos são configuradas para impedir a modificação não autorizada de permissões de pasta e arquivo, conteúdo de pasta e arquivos individuais)

O controle de aplicativo pode impedir a execução não autorizada de aplicativos não aprovados. O controle de aplicativo também pode contribuir para a identificação de tentativas de um ator de ameaça para executar código mal-intencionado em um sistema. Configurar o WDAC para gerar logs de eventos para execuções autorizadas e não autorizadas pode fornecer informações valiosas para o centro de operações de segurança de uma organização.

É importante observar que uma solução de controle de aplicativo não substitui o antivírus e outras soluções de software de segurança que já estão em vigor. O WDAC sempre funciona em conjunto com soluções antivírus, como o Defender Antivírus. O uso de soluções de segurança da Microsoft em conjunto contribui para uma abordagem eficaz de defesa detalhada para evitar o comprometimento dos sistemas.

ML (Níveis de Maturidade) para controle de aplicativo

O Centro de Segurança Cibernética da Austrália tem três níveis de maturidade para suas estratégias de mitigação que constituem o Essential Eight. Os níveis de maturidade baseiam-se na mitigação de níveis crescentes de artesanato comercial usados por um ator de ameaça. No contexto do controle de aplicativos, o Centro de Segurança Cibernética da Austrália determina o que é necessário para atender à ML 1, 2 e 3.

Controle ISM Mar 2024	Nível de maturidade	Mitigação
ISM-0109	3	Os logs de eventos de estações de trabalho são analisados em tempo hábil para detectar eventos de segurança cibernética.
ISM-0140	2, 3	Incidentes de segurança cibernética são relatados ao ASD o mais rápido possível depois que ocorrem ou são descobertos.
ISM-0123	2, 3	Incidentes de segurança cibernética são relatados ao Diretor de Segurança da Informação, ou a um de seus delegados, o mais rápido possível depois que ocorrem ou são descobertos.
ISM-0843	1, 2, 3	O controle do aplicativo é implementado em estações de trabalho.
ISM-1490	2, 3	O controle de aplicativo é implementado em servidores voltados para a Internet.
ISM-1656	3	O controle de aplicativo é implementado em servidores que não são voltados para a Internet.
ISM-1544	2, 3	A lista de bloqueio de aplicativos recomendada da Microsoft é implementada.
ISM-1657	1, 2, 3	O controle do aplicativo restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, aplicativos HTML compilados, aplicativos HTML e applets de painel de controle a um conjunto aprovado pela organização.
ISM-1658	3	O controle de aplicativo restringe a execução de drivers a um conjunto aprovado pela organização.
ISM-1582	2, 3	Os conjuntos de regras de controle de aplicativo são validados anualmente ou com mais frequência.
ISM-1659	3	A lista de bloqueios de driver vulneráveis da Microsoft é implementada.
ISM-1660	2, 3	Eventos de controle de aplicativo permitidos e bloqueados são registrados centralmente.
ISM-1815	2, 3	Os logs de eventos são protegidos contra modificações e exclusões não autorizadas.
ISM-1819	2, 3	Após a identificação de um incidente de segurança cibernética, o plano de resposta a incidentes de segurança cibernética é decretado.
ISM-1870	1, 2, 3	O controle de aplicativo é aplicado a perfis de usuário e pastas temporárias usadas por sistemas operacionais, navegadores da Web e clientes de email.
ISM-1871	2, 3	O controle do aplicativo é aplicado a todos os locais que não sejam perfis de usuário e pastas temporárias usadas por sistemas operacionais, navegadores da Web e clientes de email.
ISM-1228	2, 3	Eventos de segurança cibernética são analisados em tempo hábil para identificar incidentes de segurança cibernética.
ISM-1906	2, 3	Os logs de eventos de servidores voltados para a Internet são analisados em tempo hábil para detectar eventos de segurança cibernética.
ISM-1907	3	Os logs de eventos de servidores não voltados para a Internet são analisados em tempo hábil para detectar eventos de segurança cibernética.

Controle ISM Mar 2024	Nível de maturidade	Control	Measure
ISM-0109	3	Os logs de eventos de estações de trabalho são analisados em tempo hábil para detectar eventos de segurança cibernética.	Use o Defender para Ponto de Extremidade P2. Os logs de eventos do Windows são capturados no Microsoft Sentinel e Microsoft Defender XDR usando eventos de Segurança do Windows por meio de soluções ama ou eventos encaminhados pelo Windows.
ISM-0140	2, 3	Incidentes de segurança cibernética são relatados ao ASD o mais rápido possível depois que ocorrem ou são descobertos.	Não no escopo deste documento. Consulte observação após esta tabela. 3
ISM-0123	2, 3	Incidentes de segurança cibernética são relatados ao Diretor de Segurança da Informação, ou a um de seus delegados, o mais rápido possível depois que ocorrem ou são descobertos.	Não no escopo deste documento. Consulte observação após esta tabela. 3
ISM-0843	1, 2, 3	O controle do aplicativo é implementado em estações de trabalho.	Configure e use Windows Defender Controle de Aplicativo/AppLocker dependendo dos requisitos de nível de maturidade da organização.
ISM-1490	2, 3	O controle de aplicativo é implementado em servidores voltados para a Internet.	Configurar e usar Windows Defender Controle de Aplicativo
ISM-1656	3	O controle de aplicativo é implementado em servidores que não são voltados para a Internet.	Configurar e usar Windows Defender Controle de Aplicativo
ISM-1544	2, 3	A lista de bloqueio de aplicativos recomendada da Microsoft é implementada.	As 'regras de bloco recomendadas' da Microsoft são implementadas
ISM-1657	1, 2, 3	O controle do aplicativo restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, aplicativos HTML compilados, aplicativos HTML e applets de painel de controle a um conjunto aprovado pela organização.	A Microsoft recomenda que uma lista definida de Regras do Editor de Arquivos ou Hashes de Arquivo seja criada dentro de uma política de controle de aplicativo. 1
ISM-1658	3	O controle de aplicativo restringe a execução de drivers a um conjunto aprovado pela organização.	A integridade de código protegida pelo hipervisor está habilitada e é padrão para Windows 11 2022+
ISM-1582	2, 3	Os conjuntos de regras de controle de aplicativo são validados anualmente ou com mais frequência.	Não no escopo deste documento. Confira a observação abaixo desta tabela. 3
ISM-1659	3	A lista de bloqueios de driver vulneráveis da Microsoft é implementada.	As 'regras recomendadas de bloqueio de driver' da Microsoft são implementadas
ISM-1660	2, 3	Eventos de controle de aplicativo permitidos e bloqueados são registrados centralmente.	Use o Defender para Ponto de Extremidade P2. Os logs de eventos do Windows são capturados no Microsoft Sentinel e Microsoft Defender XDR usando soluções "eventos Segurança do Windows" por meio da AMA ou de "Eventos encaminhados pelo Windows".
ISM-1815	2, 3	Os logs de eventos são protegidos contra modificações e exclusões não autorizadas.	Role-Based Controle de Acesso para Microsoft Defender XDR e o Microsoft Sentinel é imposto.
ISM-1819	2, 3	Após a identificação de um incidente de segurança cibernética, o plano de resposta a incidentes de segurança cibernética é decretado.	Não no escopo deste documento.  Confira a observação abaixo desta tabela. 3
ISM-1870	1, 2, 3	O controle de aplicativo é aplicado a perfis de usuário e pastas temporárias usadas por sistemas operacionais, navegadores da Web e clientes de email.	A Microsoft recomenda que uma lista definida de Regras do Editor de Arquivos ou Hashes de Arquivo seja criada dentro de uma política de controle de aplicativo. O nível de maturidade 1 pode ser alcançado com o Microsoft AppLocker. O nível de maturidade 2 e 3 requer Windows Defender Controle de Aplicativo. 2
ISM-1871	2, 3	O controle do aplicativo é aplicado a todos os locais que não sejam perfis de usuário e pastas temporárias usadas por sistemas operacionais, navegadores da Web e clientes de email.	Implementação e configuração do controle de aplicativo Windows Defender
ISM-1228	2, 3	Eventos de segurança cibernética são analisados em tempo hábil para identificar incidentes de segurança cibernética.	Não no escopo deste documento.  Consulte observação após esta tabela. 3
ISM-1906	2, 3	Os logs de eventos de servidores voltados para a Internet são analisados em tempo hábil para detectar eventos de segurança cibernética.	Use o Defender para Ponto de Extremidade P2. Os logs de eventos do Windows são capturados no Microsoft Sentinel e Microsoft Defender XDR usando eventos de Segurança do Windows por meio de soluções ama ou eventos encaminhados pelo Windows.
ISM-1907	3	Os logs de eventos de servidores não voltados para a Internet são analisados em tempo hábil para detectar eventos de segurança cibernética.	Use o Defender para Ponto de Extremidade P2. Os logs de eventos do Windows são capturados no Microsoft Sentinel e Microsoft Defender XDR usando eventos de Segurança do Windows por meio de soluções ama ou eventos encaminhados pelo Windows.

Importante

¹ Para atender ao ISM-1657, a Microsoft recomenda que uma lista definida de Regras do Editor de Arquivos ou Hashes de Arquivo tenha sido criada dentro de uma política de controle de aplicativo. Se as Regras de Caminho de Arquivo forem muito aproveitadas, uma organização deverá garantir que o usuário seja impedido da modificação não autorizada de permissões de pasta e arquivo, conteúdo de pasta e arquivos individuais. Por exemplo, o usuário não deve ter Acesso de Gravação no NTFS para o local da Regra de Caminho do Arquivo.

² Para atender ao ISM-1870, a Microsoft recomenda que uma lista definida de Regras do Editor de Arquivos ou Hashes de Arquivo tenha sido criada dentro de uma política de controle de aplicativo. O nível de maturidade 1 pode ser alcançado com o Microsoft AppLocker. O nível de maturidade 2 e 3 tem um requisito para Windows Defender Controle de Aplicativo devido aos requisitos adicionais de ISM. Regras de caminho de arquivo não são recomendadas para ISM-1870 devido ao usuário ter permissão do sistema de arquivos dentro do perfil do usuário e pastas temporárias.

³ Controles ISM-0140, 0123, 1582, 1819 e 1228 são pessoas explicitamente primárias e controles de processo. A Microsoft recomenda que pessoas e processos sejam documentados e armazenados como artefatos no Purview Compliance Manager, como parte de evidências de tecnologia automatizadas para revisões de conformidade do Essential 8.

Controle de aplicativo para Windows

Qual solução usar?

A Microsoft recomenda que os clientes implementem Windows Defender WDAC (Controle de Aplicativo) em vez do AppLocker. Windows Defender Controle de Aplicativo está passando por melhorias contínuas. Embora o AppLocker continue recebendo correções de segurança, ele não recebe melhorias de recursos.

No entanto, o AppLocker também pode ser implantado como um complemento para Windows Defender Controle de Aplicativo para cenários como dispositivos compartilhados, em que é importante impedir que alguns usuários executem um aplicativo específico. A Microsoft recomenda que sua organização imponha Windows Defender Controle de Aplicativo como o nível mais restritivo possível para sua organização e usar o AppLocker para ajustar ainda mais as restrições de modo de usuário, se necessário.

Dica

Embora o WDAC seja preferencial, pode ser mais simples e fácil para a maioria das organizações alcançar o ML1 usando apenas o AppLocker como ponto de partida, ambas as soluções são complementares.

AppLocker

O AppLocker foi introduzido com o Windows 7 e permite que a organização controle quais processos de modo de usuário (aplicativos) podem ser executados em seus Sistemas Operacionais Windows. As Políticas do AppLocker podem ser aplicadas a todos os usuários em um sistema ou a usuários e grupos individuais com regras que podem ser definidas com base em:

• Regras de hash criptográficas
• Regras de certificação do editor
• Regras de caminho

As políticas do AppLocker podem ser criadas em todas as versões e adições com suporte do Sistema Operacional Windows e podem ser implantadas usando Política de Grupo, PowerShell ou uma solução mobile Gerenciamento de Dispositivos.

Controle de Aplicativos do Windows Defender

Windows Defender WDAC (Controle de Aplicativo) foi introduzido com Windows 10. Ele permite que as organizações controlem quais processos do modo de usuário (aplicativos) e do modo kernel (drivers) podem ser executados em seus Sistemas Operacionais Windows. As políticas WDAC são aplicadas ao sistema gerenciado como um todo e afetam todos os usuários do dispositivo com regras que podem ser definidas com base em:

• Regras de hash criptográficas
• Regras de certificação do editor
• Regras de caminho
• Reputação do aplicativo conforme determinado pelo Grafo de Segurança Inteligente da Microsoft
• Identidade do processo que iniciou a instalação do aplicativo por instalador gerenciado

As políticas do WDAC podem ser criadas em qualquer edição de cliente com suporte de Windows 10, Windows 11 ou em Windows Server 2016 e superior. As políticas do WDAC podem ser implantadas usando Política de Grupo, uma solução de Gerenciamento de Dispositivos Móvel, Configuration Manager ou PowerShell.

Devido ao Windows como serviço da Microsoft para permitir o desenvolvimento e a implantação de novos recursos para nossos clientes, alguns recursos do WDAC só estão disponíveis em versões específicas do Windows.

Para obter informações detalhadas sobre Windows Defender Controle de Aplicativo e Applocker, consulte Windows Defender Disponibilidade de recursos do Controle de Aplicativo e do AppLocker.

Controle de aplicativo Essential Eight usando AppLocker para ML1

Usar o AppLocker para alcançar o ML1

Quando o administrador está implantando uma política AppLocker para controle de aplicativo baseado no usuário, as regras a seguir podem ser usadas como uma implementação baseada em caminho de exemplo. Isso inclui as regras, a aplicação de regras e o início automático do serviço de Identidade de Aplicativo.

A sugestão é bloquear (no mínimo) os seguintes caminhos:

• C:\Windows\Temp\*.*
• %USERPROFILE%\AppData\Local\*.*
  • Adicionar exceção para %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
• %USERPROFILE%\AppData\Roaming\*.*

Para obter informações sobre o AppLocker no ML1, confira os seguintes artigos:

• ACSC – Implementando o controle de aplicativo
• Visão geral do AppLocker

Criando a política AppLocker para alcançar o ML1

As políticas do Microsoft AppLocker podem ser criadas usando vários métodos. A Microsoft recomenda usar o projeto do Microsoft Open source AaronLocker para ajudar na criação de políticas do AppLocker. O AaronLocker permite a criação e manutenção de um controle de aplicativo robusto e rigoroso para AppLocker o mais fácil e prático possível quanto usar o serviço de Scripts do PowerShell. O AaronLocker foi projetado para restringir a execução de programas e scripts por usuários nãoministrativos.

Para obter informações detalhadas sobre o Aaronlocker, consulte AaronLocker: controle de aplicativo robusto e prático para Windows.

Implantando a política AppLocker para alcançar o ML1

O Microsoft AppLocker pode ser implantado usando Microsoft Intune, Política de Grupo ou PowerShell. O método de implantação dependeria da solução de gerenciamento atual da organização.

Para obter informações detalhadas sobre como implantar o armário de aplicativos, confira os seguintes artigos:

• Guia de implantação do AppLocker
• CSP do AppLocker

Monitoramento de eventos de política do AppLocker

Os eventos relacionados ao Microsoft AppLocker são monitorados por uma solução de gerenciamento de eventos e informações de segurança, como o Sentinel da Microsoft. Os eventos também são monitorados usando as informações avançadas de caça do Microsoft Defender para Ponto de Extremidade.

Microsoft Defender para Ponto de Extremidade: referência do AppLocker

Microsoft Defender para Ponto de Extremidade captura os seguintes eventos em relação ao Microsoft AppLocker.

Nome do ActionType	ID da origem do evento
AppControlExecutableAudited	8003
AppControlExecutableBlocked	8004
AppControlPackagedAppAudited	8021
AppControlPackagedAppBlocked	8022
AppControlPackagedAppBlocked	8006
AppControlScriptBlocked	8007
AppControlCIScriptAudited	8001

Para obter informações detalhadas sobre Visualizador de Eventos e a caça avançada, confira os seguintes artigos:

• Usando Visualizador de Eventos com AppLocker
• Consultar eventos do Controle de Aplicativo centralmente usando a caça avançada

Controle de aplicativo Essential Eight usando o WDAC para ML2

A Microsoft está delineando o processo de design, o gerenciamento do ciclo de vida, a implantação e as diretrizes operacionais para atender ao controle de aplicativo ML2 e ML3 do Essential Eight usando o WDAC.

Os clientes com o requisito do Essential Eight Application Control ML1 podem ser alcançados usando o Microsoft AppLocker.

Os pré-requisitos para usar essas diretrizes são necessários:

• Windows 11 22H2 Enterprise
• Usando Intune para a solução de gerenciamento
• Defender para Ponto de Extremidade, para solução de segurança de ponto de extremidade
• Gerenciamento de eventos e informações do Microsoft Sentinel for Security; E
• Permissões apropriadas por administradores em todas as soluções usadas neste documento

WDAC em Sistemas Operacionais do Windows Server não está no escopo deste guia. As diretrizes para o Windows Server devem ser fornecidas em uma versão futura.

Requisitos de licenciamento

O serviço relacionado ao M365 pode estar localizado dentro das descrições de serviço do Microsoft 365 e Office 365 para entender os serviços necessários, propostas de valor e requisitos de licenciamento:

Descrições de serviços do Microsoft 365 e do Office 365

Para obter informações sobre produtos associados ao WDAC, consulte os seguintes artigos:

• Controle de Aplicativos para Windows
• Microsoft Intune
• Microsoft Azure Sentinel

Introdução ao WDAC

Design de política

Quando uma organização começa a planejar o WDAC, a consideração das decisões de design molda como ela afeta a implantação da política e a manutenção da política de controle de aplicativo.

O WDAC deve ser usado como parte das políticas de controle de aplicativo da sua organização se o seguinte for verdadeiro:

• Você implantou ou planeja implantar as versões com suporte do Windows em sua organização
• Você precisa de um controle aprimorado sobre o acesso aos aplicativos da sua organização e os dados de acesso do usuário
• Sua organização tem um processo bem definido para gerenciamento e implantação de aplicativos
• Você tem recursos para testar políticas em relação aos requisitos da organização
• Você tem recursos para envolver o Help Desk ou criar um processo de autoajuda para problemas de acesso de aplicativo do usuário final
• Os requisitos do grupo para produtividade, gerenciabilidade e segurança podem ser controlados por políticas restritivas

O WDAC incorpora um conceito de "círculo de confiança". Cada organização tem uma definição diferente de "círculo de confiança" exclusiva para seus requisitos comerciais. A definição relacionada ao ACSC Essential 8 é o controle ISM 1657 – 'O controle de aplicativo restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, HTML compilado, aplicativos HTML e applets de painel de controle a um conjunto aprovado pela organização.'

A Microsoft fornece várias políticas de exemplo no formato XML localizado no Windows em %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies. As políticas de exemplo da Microsoft podem permitir que sua organização comece a partir de uma política base existente e adicione ou remova regras para criar políticas personalizadas, se necessário.

Para obter mais informações sobre o design da política, confira os seguintes artigos:

• Documentação do Microsoft Intune
• Windows Defender políticas de base de exemplo do Controle de Aplicativo

Formatos de política

O WDAC dá suporte a dois formatos de política:

• Formato de política única: o formato de política original que foi lançado com Windows 10 RTM e Windows Server 2016. O formato de política única só dá suporte a uma única política ativa em um sistema a qualquer momento

• Formato de política múltipla (recomendado): esse formato de política tem suporte em Windows 10 1903+, Windows 11 e Windows Server 2022. Um formato de política múltipla permite mais flexibilidade para implantar Windows Defender Controle de Aplicativo e dá suporte a até 32 políticas ativas em um dispositivo. Além disso, ele permite os seguintes cenários:

  • Impor e auditar lado a lado: para validar as alterações de política antes de implantar a aplicação. Os usuários podem implantar a política base do modo de auditoria lado a lado com uma política baseada em modo de aplicação existente
  • Várias políticas de base: os usuários podem impor duas ou mais políticas base simultaneamente
  • Políticas complementares: os usuários podem implantar uma ou mais políticas complementares para expandir uma política de base. Você pode usar políticas complementares para personas diferentes em sua organização, por exemplo, RH e TI

A Microsoft recomenda o uso de vários formatos de política e apenas o uso de formato de política única para cenários bem definidos ou em que vários formatos de política não são possíveis, como Windows Server 2016 e Windows Server 2019.

Para obter informações detalhadas sobre políticas de controle do WDAC, consulte Usar várias políticas de controle de aplicativo Windows Defender.'''

Regras de política e regras de arquivo

O WDAC contém dois conceitos que são:

• Regras de política do WDAC: as regras de política do WDAC especificam configurações como Modo de Auditoria, instalador gerenciado, Execução de Script, Políticas de Suplemento (Formato de Política Múltipla), inteligência Reputation-Based (Autorização ISG/Controle de Aplicativo Inteligente) e talvez outras. Regras de política também determinam se o WDAC para binários do modo kernel e do modo de usuário
• Regras de arquivo WDAC: as regras de arquivo WDAC especificam autorização e reautorização para execução no Windows. As regras de arquivo dão suporte às regras Hash, Nome do Arquivo, Caminho do Arquivo e Publisher permitem que um cliente defina um conjunto de aplicativos permitidos aprovado pela organização. A regra primeiro processa todas as regras de negação explícitas encontradas e, em seguida, processa todas as regras de permissão explícitas. Se não houver nenhuma regra de negação ou permissão, o WDAC verificará se há instalador gerenciado. Por fim, se nenhum desses conjuntos existir, o WDAC retornará à inteligência Reputation-Based

Para obter informações detalhadas sobre regras de política e regras de arquivo, consulte o seguinte artigo:

• Entender Windows Defender regras de política e regras de arquivo do WDAC (Controle de Aplicativo)

Criação de política

Há duas maneiras primárias de criar uma Política WDAC usando o PowerShell ou o Assistente WDAC:

• PowerShell: as políticas do WDAC são criadas usando cmdlets de integridade de código configuráveis no PowerShell. O PowerShell permite que um IT Pro automatize a verificação do sistema de política do WDAC, que gera um XML de política. O PowerShell pode ser usado para mesclar XMLs de política, definir regras de política e adicionar outras regras de arquivo de política se necessário Os Cmdlets de Integridade de Código Configurável também podem ser usados para modificar as políticas de exemplo do WDAC para atender aos requisitos da sua organização.
• Windows Defender Assistente de Controle de Aplicativo (recomendado): o assistente de política do WDAC é um aplicativo de área de trabalho do Windows de código aberto escrito em C# e empacotado como um pacote MSIX. Ele foi criado para fornecer aos arquitetos de segurança segurança e administradores do sistema um meio mais amigável para criar, editar e mesclar políticas de Controle de Aplicativo. Essa ferramenta usa os cmdlets do Config CI PowerShell no back-end, portanto, a política de saída da ferramenta e os cmdlets do PowerShell são idênticos

Para obter informações detalhadas sobre a criação de políticas, confira os seguintes artigos:

• Create uma política WDAC usando um computador de referência
• Assistente de controle de aplicativo Windows Defender
• ConfigCI
• Assistente de Política do WDAC

A Microsoft recomenda o uso do Assistente de Controle de Aplicativo Windows Defender para implementar o Essential Eight para Controle de Aplicativo. Como alternativa, o PowerShell pode ser usado por organizações com requisitos avançados em um modelo operacional DevOps usando as políticas de exemplo como base ou que deseja criar uma política para cenários bem definidos de um sistema de referência.

Ciclo de vida da política

Antes que uma organização comece a implementar uma solução de controle de aplicativo, você deve considerar como suas políticas são gerenciadas e mantidas ao longo do tempo. A maioria das políticas do WDAC evolui ao longo do tempo e continua por um conjunto de fases identificáveis durante o tempo de vida. Essas fases incluem:

1. Defina a política e crie uma versão do modo de auditoria do XML da política. No modo de auditoria, eventos de bloco são gerados, mas os arquivos não são impedidos de executar
2. Implantar a política de modo de auditoria nos sistemas pretendidos
3. Monitorar eventos de bloco de auditoria dos sistemas pretendidos e refinar as regras conforme necessário para abordar blocos inesperados/indesejados
4. Repita estas etapas até que os eventos de bloco restantes atendam às suas expectativas durante a auditoria
5. Gere a versão do modo imposto da política. No modo de impor, os arquivos que não são definidos como permitidos pela política são impedidos de executar e os eventos de bloco correspondentes são gerados
6. Implantar a política de modo de impor aos sistemas pretendidos
7. Repita todas essas etapas continuamente para resolver quaisquer ações de bloco inesperadas/indesejadas

Para gerenciar efetivamente as políticas do WDAC, você deve armazenar e manter seus documentos XML de política em um repositório central. A Microsoft recomenda uma solução de controle de origem, como o GitHub ou uma solução de gerenciamento de documentos, como o SharePoint, que fornece controle de versão.

• Planejar Windows Defender gerenciamento de política de ciclo de vida do Controle de Aplicativo

Pré-requisitos do WDAC para instalador gerenciado

Esta seção destina-se a fornecer as diretrizes do cliente sobre os requisitos de configurar o instalador gerenciado do WDAC usando o PowerShell e Microsoft Intune.

• Examine a proteção contra ameaças do Windows permitir automaticamente aplicativos implantados por um instalador gerenciado com Windows Defender Controle de Aplicativo (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)

Observação

Este script de exemplo não usa o AppLocker para que as regras DENY benignas não estejam presentes na etapa 1. Essa configuração do AppLocker seria criada para todos os dispositivos que exigem instalador gerenciado.

• Create um Script do PowerShell que conclui o seguinte:
  • Armazenar o AppLocker XML
  • Exportar o AppLocker XML
  • Definir Política AppLocker
  • Iniciar o Serviço AppLocker

Veja a seguir um exemplo de um script que pode ser implantado usando Intune extensão de gerenciamento – scripts do PowerShell:

$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path

$AppLockerMIPolicy = 
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
  <FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
          <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
        </FilePublisherCondition>
  </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection> 
</AppLockerPolicy>
"@

$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml

Importante

O administrador precisa adicionar o script de configuração à política de Regra de Arquivo WDAC por meio de Hash ou Publisher.

Instalador gerenciado do WDAC

Visão Geral

O recurso do WDAC chamado instalador gerenciado permite que uma organização balancee a segurança e a capacidade de gerenciamento ao impor políticas de controle de aplicativo. Isso permite que os aplicativos sejam instalados por uma solução de distribuição de software, como Microsoft Configuration Manager ou Intune.

Um equívoco comum é configurar a regra do "instalador gerenciado" dentro da política do WDAC são as únicas etapas necessárias. Isso está incorreto e outra configuração do AppLocker é necessária para que esse recurso opere.

O instalador gerenciado usa uma coleção de regras no AppLocker para designar binários confiáveis pela sua organização para instalação do aplicativo. O Windows monitora o processo do binário configurado e todos os processos filho que ele inicia durante o monitoramento de arquivos associados que estão sendo gravados no disco. Esses arquivos são marcados como originários de um instalador gerenciado, portanto, autorizados a serem executados.

Implantação do instalador gerenciado

A criação da política AppLocker no GPO Editar e nos cmdlets do PowerShell do AppLocker não pode ser usada diretamente para criar regras para a coleção de instalador gerenciado. Você precisa usar o VS Code ou outra ferramenta de editor para criar uma coleção de regras do instalador gerenciado.

O CSP (Provedor de Serviços de Configuração do AppLocker) atualmente não dá suporte ao tipo de coleção de regras do instalador gerenciado, portanto, a política AppLocker deve ser ingress usando o PowerShell para Microsoft Intune.

Como Windows Defender o recurso do Controle de Aplicativo "Script Enforcement" é necessário para atender ao ISM-1657, a aplicação do script é necessária para controlar PowerShell, VBscript, cscript, cscript, HSMTA e MSXML. O script do PowerShell para configurar o 'instalador gerenciado' precisa estar dentro da regra de política de arquivo WDAC usando Hash ou Publisher.

A Microsoft recomenda a configuração do instalador gerenciado para Microsoft Intune. Intune permite um gerenciamento robusto de aplicativos empacotados usando Microsoft Intune sem o requisito de atualizar frequentemente uma política de controle de aplicativo Windows Defender.

Implantação do script do PowerShell para instalador gerenciado

A implantação desse script de configuração para o instalador gerenciado pode ser obtida de duas maneiras usando Microsoft Intune dependendo do cenário:

• Hash: o hash do script precisaria ser conhecido dentro da Política de Arquivos WDAC, empacotado e implantado usando a Ferramenta de Preparação de Conteúdo do Microsoft Win32 ou o recurso de Script do PowerShell no Microsoft Intune.
• Assinado por código (Publisher): o Script do PowerShell foi assinado por uma autoridade confiável e conhecido com a Política de Arquivo WDAC, empacotada e implantada usando a Ferramenta de Preparação de Conteúdo do Microsoft Win32 ou o recurso de Script do PowerShell no Microsoft Intune.

Para obter informações detalhadas sobre a implantação de scripts do PowerShell, confira os seguintes artigos:

• Permitir automaticamente aplicativos implantados por um instalador gerenciado com Windows Defender Controle de Aplicativo
• CSP do AppLocker
• Imposição de script com Windows Defender WDAC (Controle de Aplicativo)
• Gerenciamento de aplicativos Win32 no Microsoft Intune
• Use scripts do PowerShell em dispositivos Windows 10/11 no Intune

Criação de política de auditoria do WDAC

Create uma política de auditoria

Com as opções compreendidas e as decisões de design tomadas, a organização é capaz de criar a primeira política de auditoria usando o Assistente de Controle de Aplicativo Windows Defender:

1. Abra o Assistente de Controle de Aplicativo Windows Defender e selecione "Criador de Políticas".

2. No Criador de Políticas, selecione Formato de Política Múltipla e Política base e selecione Avançar.

3. No Modelo de Política, você tem três opções:

   • O Modo Windows padrão inclui os drivers de kernel assinados pelo Windows OS, Store Apps, Microsoft 365 Apps for Enterprise (Office 365 Pro Plus) e WHQL.
   • Permitir o Modo Microsoft inclui todas as seções no Modo Windows Padrão e todos os aplicativos assinados pela Microsoft.
   • O Modo Assinado e Respeitável inclui todas as seções anteriores e Reputation-Based inteligência.

Importante

Reputation-Based Intelligence for Application Control não atende ao Essential Eight Application Control devido ao requisito "Conjunto aprovado pela organização" (ISM 1657) e "Os conjuntos de regras de controle de aplicativo são validados anualmente ou com mais frequência" (ISM 1582). Esse recurso no WDAC não atenderá aos requisitos de ML2 ou ML3. A Microsoft recomenda o uso do Reputation-Based Intelligence para a adoção organizacional do WDAC fora do contexto do Essential Eight Application Control.

4. Selecione Modo Windows Padrão ou Permitir Modo Microsoft , dependendo dos requisitos da sua organização. Para este documento, a Microsoft está usando Permitir o Modo Microsoft.
5. Modifique o Nome e o Local da Política para o Nome da Política desejado e o Local do Arquivo de Política para armazenar o arquivo e selecione Avançar.

Observação

Informações detalhadas do WDAC – Regras de política podem ser encontradas aqui.

• Desabilitar o Script Enforcement definido como "Desabilitado" é necessário para o ISM 1657 e 1658 controlar scripts, aplicativos HTML e HTML cumpridos.
• O Grafo de Segurança Inteligente definido como "Desabilitado" é necessário para ISM 1657, 1658 e 1582.
• É recomendável que o instalador gerenciado esteja "Habilitado" para ajudar uma organização com o ciclo de vida da política WDAC.
• A Integridade do Código do Modo de Usuário é necessária para que as políticas do WDAC se apliquem tanto ao modo kernel quanto aos binários do modo de usuário.
• Permitir políticas de suplemento é necessário para usar o formato de várias políticas para ajudar uma organização com o ciclo de vida da política WDAC.

Observação

Todas as outras regras de política do WDAC dependem dos requisitos dentro de uma organização.

6. Dentro de Regras de Assinatura, o administrador é capaz de ver todos os certificados da Microsoft que foram adicionados como Permitir Regras do Editor. Abordamos Adicionar Regra Personalizada posteriormente neste artigo.
7. Selecione Avançar.

O Assistente de Controle de Aplicativo Windows Defender gera:

• Política XML
• {GUID}. CIP

Informações detalhadas do WDAC – Regras de política podem ser encontradas aqui.

Observação

Cada política gerada usando o Assistente de Controle de Aplicativo Windows Defender adquiriu um novo GUID (Identificador Globalmente Exclusivo).

A política WDAC foi criada com êxito.

Política XML

Como a organização criou a política WDAC usando o Assistente WDAC, a organização pode exibir o contexto desse arquivo dentro de um editor de texto. O XML é dividido em várias seções diferentes, para o contexto de Essential Eight anotar o PolicyID e o BasePolicyID.

Observação

Embora seja possível editar diretamente o XML da Política. A Microsoft recomenda todas as alterações adicionais nas regras de política ou na assinatura de arquivos a serem feitas usando o Assistente de Controle de Aplicativo Windows Defender ou Cmdlets de Integridade de Código Configurável no PowerShell.

Implantação da política de auditoria do WDAC

Implantar a política de auditoria do WDAC por meio de Intune

Agora que a organização criou uma política de auditoria, é hora de implantá-la usando Intune gerenciamento de dispositivos.

1. Entre no Intune centro de administração.
2. Em Intune centro de administração, acesse Dispositivos e, em seguida, Perfis de Configuração.
3. Em seguida, crie uma Plataforma de Perfil>– Windows 10 ou Posterior, Modelos de Tipo de Perfil e Personalizados.
4. Create um nome para a política (por exemplo, 'Controle de Aplicativo – Microsoft Allow – Auditoria') e selecione Avançar.
5. Em Configurações OMA-URI, selecione Adicionar.

Observação

Essas informações dependem da ID da política gerada do Assistente de Controle de Aplicativo do Windows >Defender para a política XML criada a partir de "Create Audit Policy" da seção acima:

- Nome = Microsoft Allow Audit
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- Tipo de dados = Base64 (Arquivo)

6. Quando o Assistente de Controle de Aplicativo Windows Defender gerou a política XML, ele também criou um (GUID). Arquivo CIP. O arquivo CIP precisa ser copiado e renomear a extensão de arquivo como . BIN, por exemplo, {CB46B243-C19C-4870-B098-A2080923755C}.bin.
7. Carregue o BIN em Base64 (Arquivo).
8. Selecione Salvar.
9. Siga os prompts para criar o Perfil de Configuração.
10. Implante a política que você criou, por exemplo, 'Controle de Aplicativo – Microsoft Allow – Audit', Perfil de Configuração no sistema pretendido.

WDAC – monitoramento de política de auditoria

Seguindo o ciclo de vida da política WDAC, a organização precisa examinar os eventos gerados da política "Permitir Auditoria da Microsoft". O monitoramento da política de auditoria do WDAC pode ser alcançado com dois métodos:

• IDs de evento do Controle de Aplicativo: IDs de evento de controle de aplicativo são o método tradicional de revisão de eventos auditados em um Sistema Operacional Windows. Essas IDs de evento podem ser encaminhadas para um local centralizado usando o Encaminhamento de Log de Eventos do Windows ou informações de segurança de terceiros e gerenciamento de eventos.

Para obter informações sobre IDs de evento, consulte Noções básicas sobre IDs de evento do Controle de Aplicativo – Segurança do Windows.

• Microsoft Defender para Ponto de Extremidade (recomendado): Windows Defender para eventos relacionados ao Endpoint e AppLocker são capturados no Advanced Hunting for Microsoft Defender para Ponto de Extremidade. As informações incluídas nos eventos são Device, FileName, FolderPath, InitiatingProcessFileName, File Hashes e muito mais. Confira: Consultar eventos de Controle de Aplicativo com a Caça Avançada (Windows) – Segurança do Windows

A Microsoft recomenda usar a integração Microsoft Defender XDR (MDPE) ao Microsoft Sentinel. MDPE e o Sentinel permitem que os dados de telemetria de Caça Avançada sejam armazenados por mais de 30 dias em comparação com o Microsoft Defender para Ponto de Extremidade.

Para obter informações detalhadas sobre conexões e monitoramento, confira os seguintes artigos:

• Conectar dados de Microsoft Defender XDR ao Microsoft Sentinel
• Agente do Azure Monitor em dispositivos cliente Windows
• Coletar eventos e contadores de desempenho de máquinas virtuais com o Agente do Azure Monitor

Monitorando o WDAC com Microsoft Defender para Ponto de Extremidade

O exemplo a seguir demonstra que um usuário tem vários aplicativos usados para tarefas diárias de uma organização. O exemplo contém aplicativos Microsoft e vários aplicativos código aberto.

Como o exemplo está no modo de auditoria de execução, ele pode ser visto pelo administrador (mas não afeta o usuário) que os eventos disparados para WinSCP, VLC, Putty e FileZilla, já que esses aplicativos não fazem parte da política de auditoria inicial.

Agora, usando o portal Microsoft Defender, insira a Caça Avançada para restringir eventos de auditoria para entender quais blocos inesperados/indesejados estariam ocorrendo se o modo de auditoria desabilitado e, portanto, transformado em modo de impor neste exemplo.

Usando o esquema de referência da página anterior, procure todos os eventos de Auditoria de Política disparados pelo WDAC nos últimos sete dias e apresente informações relevantes usando a consulta KQL (Linguagem de Consulta de Teclado) de exemplo:

DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

Aqui está um exemplo de uma saída usando a consulta KQL anterior.

Dentro dos registros, há um relatório detalhado de informações, como a Árvore de Processo, Caminho do Arquivo, Informações SHA, Signer e Informações do Emissor.

A próxima etapa é reduzir os resultados.

Usando a mesma consulta KQL, adicione outro campo em que o nome do arquivo de processo de iniciação é Windows Explorer. A consulta KQL exibe os aplicativos executados pelos usuários na GUI.

 DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

Aqui está um exemplo de uma saída usando a consulta KQL anterior.

A ação de consulta KQL reduziu as informações para um conjunto de dados de gerenciamento mais. O que pode ser visto são os aplicativos que estão sendo usados pelos sistemas pretendidos. Esses aplicativos precisam ser adicionados à política da organização ou serem considerados adicionados por meio do controle de alterações organizacionais.

Observação

O KQL é uma ferramenta poderosa para exibir conjuntos de dados não estruturados e estruturados. Este é apenas um exemplo de uso do KQL e a Microsoft recomendaria revisar a seguinte documentação: Aprenda a linguagem avançada de consulta de caça em Microsoft Defender XDR

WDAC – Atualizar política de auditoria

Atualizar a política de auditoria usando Microsoft Defender para Ponto de Extremidade e assistente WDAC

Com uma limitação de nossos resultados de pesquisa usando o KQL, a próxima etapa é atualizar a política de base do WDAC ou usar uma política de suplemento. O próximo exemplo usa políticas de suplemento.

1. Abra o Assistente de Controle de Aplicativo Windows Defender e selecione Criador de Políticas.

2. No Criador de Políticas, selecione Formato de Política Múltipla e Política Suplementar, navegue até sua política base, atualize o local para salvar sua Política Suplementar e selecione Avançar.

3. Selecione Avançar dentro das Regras de Política.

4. Em Regras de Assinatura de Política , selecione Regra Personalizada.

5. Dentro das condições de regra personalizadas, muitas opções estão disponíveis:

   • Regra do modo de usuário do escopo de regra / Regra do modo kernel
   • Ação de Regra: Permitir/Negar
   • Tipo de Regra
     • Publicador (recomendado)
     • Arquivo
     • File Attribute
     • Aplicativo empacotado
     • Hash
   • Arquivo de referência

Observação

A Microsoft recomenda usar regras baseadas em Publisher quando apropriado e voltar às regras baseadas em Hash para arquivos de referência não assinados para implementar o Controle de Aplicativo Essential Eight.

Usando Microsoft Defender para Ponto de Extremidade

1. Pesquisa Nome do Arquivo no Pesquisa e navegue até o arquivo Informações e baixe o arquivo.
2. Inspecione o registro diretamente da Caça Avançada e baixe o arquivo que, em seguida, baixe os binários necessários.
3. Com os binários necessários, em seguida, continue criando outra política para os aplicativos ISV da sua organização.
4. Em Windows Defender Assistente de Controle de Aplicativo, selecione o Tipo de Regra desejado e navegue até os binários de referência da etapa anterior. O próximo exemplo demonstra que a VLC atende às informações necessárias do editor.

Observação

A Microsoft recomenda que a Emissão de AC, Publisher seja seletiva no mínimo para criar uma regra baseada em editor. O nome do produto pode ser incluído e é recomendado pelo ACSC para regras baseadas em editor.

5. Pressione Avançar e Create.
6. Implante essa Política de Suplemento usando as etapas descritas anteriormente na seção "Implantar Windows Defender Política de Auditoria de Controle de Aplicativo por meio de Microsoft Intune".

WDAC – Alternar para impor a política

Para alternar para impor a política:

1. Abra o Assistente de Controle de Aplicativo Windows Defender e selecione Política Editor.

2. Navegue até o XML da Política que deve ser alterado para imposto.

3. Desabilitar a opção Modo de Auditoria dentro das Regras de Política.

4. Selecione Avançar dentro das Regras de Política.

5. Uma Política de Atualização é criada com um número de versão alterado e um novo arquivo CIP foi criado.

6. No Microsoft Endpoint Manager Administração Center, acesse Dispositivos e, em seguida, Perfis de Configuração.

7. Em seguida, crie um Perfil, Plataforma – Windows 10 ou Posterior, Modelos de Tipo de Perfil e Personalizados.

8. Create um nome para a política, por exemplo, Controle de Aplicativo – Impor Política e selecione Avançar.

9. Em Configurações OMA-URI, selecione Adicionar.

   Observação

   Essas informações dependem da ID da política gerada do Assistente de Controle de Aplicativo Windows Defender para a política XML criada na seção criar auditoria acima.
   
   - Nome = Microsoft Allow Enforce
   - OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
   - Tipo de dados = Base64 (Arquivo)

10. Quando o Assistente de Controle de Aplicativo Windows Defender gerou a política XML, ele também criou um (GUID). Arquivo CIP. A próxima etapa é copiar esse Arquivo CIP e renomear a extensão de arquivo como . BIN, por exemplo, {CB46B243-C19C-4870-B098-A2080923755C}.bin.

11. Carregue o BIN em Base64 (Arquivo).

12. Selecione Salvar.

13. Siga os prompts para criar o Perfil de Configuração.

14. Implantar o Controle de Aplicativo – Impor o Perfil de Configuração de Política ao sistema pretendido.

    Observação

    O administrador precisa excluir o aplicativo criado anteriormente – Política de Auditoria do sistema pretendido que está sendo alternado para impor