Compartilhar via

Controlo de aplicação Essential Eight

  • Artigo

Este artigo detalha os métodos para alcançar o Modelo De Oito Maturidades Essenciais do Centro de Cibersegurança australiano (ACSC) para o Controlo de Aplicações, utilizando o Microsoft App Locker e o Controlo de Aplicações do Windows Defender.

Porquê seguir as diretrizes de controlo de aplicações do ACSC Essential Eight?

O controlo de aplicações é uma abordagem de segurança concebida para proteger contra a execução de código malicioso em sistemas. Quando esta abordagem de segurança é implementada, garante que apenas o código aprovado, como executáveis, bibliotecas de software, scripts, instaladores e controladores, está autorizado a ser executado. Devido à sua eficácia, o controlo de aplicações é um dos Oito Essenciais das Estratégias do ACSC para Mitigar Incidentes de Cibersegurança.

Controle da aplicação

O controlo de aplicações é uma abordagem de segurança concebida para proteger contra a execução de código malicioso em sistemas. Quando esta abordagem de segurança é implementada, garante que apenas o código aprovado, como executáveis, bibliotecas de software, scripts, instaladores e controladores, está autorizado a ser executado.

Embora o controlo de aplicações tenha sido concebido principalmente para impedir a execução e propagação de código malicioso num sistema, também pode impedir a instalação e a utilização de aplicações não aprovadas.

Alcançar requisitos de nível de maturidade organizacional

  • Nível de maturidade 1 (ML1): pode ser alcançado com o Microsoft AppLocker
  • Níveis de maturidade 2 e 3 (ML2 & ML3): podem ser alcançados com o Controlo de Aplicações do Microsoft Windows Defender

Implementação do controlo de aplicações

A implementação do controlo de aplicações envolve os seguintes passos de alto nível para uma organização:

  • Identificar aplicações aprovadas
  • Desenvolver regras de controlo de aplicações para garantir que apenas as aplicações aprovadas podem ser executadas
  • Manter as regras de controlo de aplicações através de um processo de gestão de alterações
  • Validar regras de controlo de aplicações com frequência

Ao determinar como impor a autorização de aplicação na sua organização, o Centro de Cibersegurança da Austrália considera os seguintes métodos adequados quando implementados corretamente:

  • Regras de hash criptográfico
  • Regras de certificação do Publisher
  • Regras de Caminho (quando as permissões do sistema de ficheiros são configuradas para impedir a modificação não autorizada de permissões de pastas e ficheiros, conteúdos de pastas e ficheiros individuais)

O controlo de aplicações pode impedir a execução não autorizada de aplicações não aprovadas. O controlo de aplicações também pode contribuir para a identificação de tentativas de execução de código malicioso num sistema por parte de um ator de ameaças. Configurar o WDAC para gerar registos de eventos para execuções autorizadas e não autorizadas pode fornecer informações valiosas ao centro de operações de segurança de uma organização.

É importante ter em atenção que uma solução de controlo de aplicações não substitui o antivírus e outras soluções de software de segurança que já estão implementadas. O WDAC funciona sempre em conjunto com soluções antivírus, como Defender Antivírus. A utilização de soluções de segurança da Microsoft em conjunto contribui para uma abordagem eficaz de defesa em profundidade para impedir o comprometimento dos sistemas.

Níveis de Maturidade (ML) para o controlo de aplicações

O Centro de Cibersegurança da Austrália tem três níveis de maturidade para as suas estratégias de mitigação que constituem o Essential Eight. Os níveis de maturidade baseiam-se na mitigação dos níveis crescentes de ofícios comerciais utilizados por um actor de ameaças. No contexto do controlo de aplicações, o Centro de Cibersegurança da Austrália determina o que é necessário para cumprir o ML 1, 2 e 3.

Controlo ISM Set 2024 Nível de maturidade Mitigação
ISM-0109 3 Os registos de eventos de estações de trabalho são analisados em tempo útil para detetar eventos de cibersegurança.
ISM-0140 2, 3 Os incidentes de cibersegurança são reportados ao ASD assim que possível após ocorrerem ou serem detetados.
ISM-0123 2, 3 Os incidentes de cibersegurança são comunicados ao Diretor de Segurança de Informações, ou a um dos seus delegados, assim que possível após ocorrerem ou serem detetados.
ISM-0843 1, 2, 3 O controlo de aplicações é implementado em estações de trabalho.
ISM-1490 2, 3 O controlo de aplicações é implementado em servidores com acesso à Internet.
ISM-1656 3 O controlo de aplicações é implementado em servidores que não têm acesso à Internet.
ISM-1544 2, 3 A lista de bloqueio de aplicações recomendada da Microsoft está implementada.
ISM-1657 1, 2, 3 O controlo de aplicações restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, HTML compilado, aplicações HTML e applets do painel de controlo para um conjunto aprovado pela organização.
ISM-1658 3 O controlo de aplicação restringe a execução de controladores para um conjunto aprovado pela organização.
ISM-1582 2, 3 Os conjuntos de regras de controlo de aplicações são validados numa base anual ou mais frequente.
ISM-1659 3 A lista de bloqueio de controladores vulneráveis da Microsoft está implementada.
ISM-1660 2, 3 Os eventos de controlo de aplicações permitidos e bloqueados são registados centralmente.
ISM-1815 2, 3 Os registos de eventos estão protegidos contra modificações e eliminações não autorizadas.
ISM-1819 2, 3 Após a identificação de um incidente de cibersegurança, o plano de resposta a incidentes de cibersegurança é decretado.
ISM-1870 1, 2, 3 O controlo de aplicações é aplicado a perfis de utilizador e pastas temporárias utilizadas por sistemas operativos, browsers e clientes de e-mail.
ISM-1871 2, 3 O controlo de aplicações é aplicado a todas as localizações que não os perfis de utilizador e pastas temporárias utilizadas por sistemas operativos, browsers e clientes de e-mail.
ISM-1228 2, 3 Os eventos de cibersegurança são analisados em tempo útil para identificar incidentes de cibersegurança.
ISM-1906 2, 3 Os registos de eventos de servidores com acesso à Internet são analisados em tempo útil para detetar eventos de cibersegurança.
ISM-1907 3 Os registos de eventos de servidores com acesso à Internet são analisados em tempo útil para detetar eventos de cibersegurança.
Controlo ISM Set 2024 Nível de maturidade Control Measure
ISM-0109 3 Os registos de eventos de estações de trabalho são analisados em tempo útil para detetar eventos de cibersegurança. Utilize o Defender para Ponto Final P2. Os Registos de Eventos do Windows são capturados em Microsoft Sentinel e Microsoft Defender XDR através de Eventos Segurança do Windows através de soluções de Eventos Reencaminhados do Windows ou AMA.
ISM-0140 2, 3 Os incidentes de cibersegurança são reportados ao ASD assim que possível após ocorrerem ou serem detetados. Não está no âmbito deste documento. Veja a nota a seguir a esta tabela. 3
ISM-0123 2, 3 Os incidentes de cibersegurança são comunicados ao Diretor de Segurança de Informações, ou a um dos seus delegados, assim que possível após ocorrerem ou serem detetados. Não está no âmbito deste documento. Veja a nota a seguir a esta tabela. 3
ISM-0843 1, 2, 3 O controlo de aplicações é implementado em estações de trabalho. Configure e utilize o Controlo de Aplicações do Windows Defender/AppLocker consoante os requisitos de nível de maturidade da organização.
ISM-1490 2, 3 O controlo de aplicações é implementado em servidores com acesso à Internet. Configurar e utilizar o Controlo de Aplicações do Windows Defender
ISM-1656 3 O controlo de aplicações é implementado em servidores que não têm acesso à Internet. Configurar e utilizar o Controlo de Aplicações do Windows Defender
ISM-1544 2, 3 A lista de bloqueio de aplicações recomendada da Microsoft está implementada. As "regras de bloqueio recomendadas" da Microsoft são implementadas
ISM-1657 1, 2, 3 O controlo de aplicações restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, HTML compilado, aplicações HTML e applets do painel de controlo para um conjunto aprovado pela organização. A Microsoft recomenda que seja criada uma lista definida de Regras do Editor de Ficheiros ou Hashes de Ficheiros numa política de controlo de aplicações. 1
ISM-1658 3 O controlo de aplicação restringe a execução de controladores para um conjunto aprovado pela organização. A integridade do código protegido pelo hipervisor está ativada e está predefinida para Windows 11 2022+
ISM-1582 2, 3 Os conjuntos de regras de controlo de aplicações são validados numa base anual ou mais frequente. Não está no âmbito deste documento. Veja a nota abaixo desta tabela. 3
ISM-1659 3 A lista de bloqueio de controladores vulneráveis da Microsoft está implementada. As "regras de bloqueio de controladores recomendadas" da Microsoft são implementadas
ISM-1660 2, 3 Os eventos de controlo de aplicações permitidos e bloqueados são registados centralmente. Utilize o Defender para Ponto Final P2. Os Registos de Eventos do Windows são capturados em Microsoft Sentinel e Microsoft Defender XDR através de soluções "Eventos Segurança do Windows" através de AMA ou "Eventos Reencaminhados do Windows".
ISM-1815 2, 3 Os registos de eventos estão protegidos contra modificações e eliminações não autorizadas. Role-Based Controle de Acesso para Microsoft Defender XDR e Microsoft Sentinel é imposta.
ISM-1819 2, 3 Após a identificação de um incidente de cibersegurança, o plano de resposta a incidentes de cibersegurança é decretado. Não está no âmbito deste documento.  Veja a nota abaixo desta tabela. 3
ISM-1870 1, 2, 3 O controlo de aplicações é aplicado a perfis de utilizador e pastas temporárias utilizadas por sistemas operativos, browsers e clientes de e-mail. A Microsoft recomenda que seja criada uma lista definida de Regras do Editor de Ficheiros ou Hashes de Ficheiros numa política de controlo de aplicações. O Nível de Maturidade 1 pode ser alcançado com o Microsoft AppLocker. O Nível de Maturidade 2 e 3 requer o Controlo de Aplicações do Windows Defender. 2
ISM-1871 2, 3 O controlo de aplicações é aplicado a todas as localizações que não os perfis de utilizador e pastas temporárias utilizadas por sistemas operativos, browsers e clientes de e-mail. Implementação e configuração do Controlo de Aplicações do Windows Defender
ISM-1228 2, 3 Os eventos de cibersegurança são analisados em tempo útil para identificar incidentes de cibersegurança. Não está no âmbito deste documento.  Veja a nota a seguir a esta tabela. 3
ISM-1906 2, 3 Os registos de eventos de servidores com acesso à Internet são analisados em tempo útil para detetar eventos de cibersegurança. Utilize o Defender para Ponto Final P2. Os Registos de Eventos do Windows são capturados em Microsoft Sentinel e Microsoft Defender XDR através de Eventos Segurança do Windows através de soluções de Eventos Reencaminhados do Windows ou AMA.
ISM-1907 3 Os registos de eventos de servidores com acesso à Internet são analisados em tempo útil para detetar eventos de cibersegurança. Utilize o Defender para Ponto Final P2. Os Registos de Eventos do Windows são capturados em Microsoft Sentinel e Microsoft Defender XDR através de Eventos Segurança do Windows através de soluções de Eventos Reencaminhados do Windows ou AMA.

Importante

1 Para cumprir o ISM-1657, a Microsoft recomenda que tenha sido criada uma lista definida de Regras do Editor de Ficheiros ou Hashes de Ficheiros numa política de controlo de aplicações. Se as Regras de Caminho de Ficheiro também estiverem a ser aproveitadas, uma organização tem de garantir que o utilizador está impedido de modificar permissões de pastas e ficheiros, ficheiros e ficheiros individuais. Por exemplo, o utilizador não deve ter Acesso de Escrita no NTFS para a localização da Regra de Caminho de Ficheiro.

2 Para cumprir o ISM-1870, a Microsoft recomenda a criação de uma lista definida de Regras do Editor de Ficheiros ou Hashes de Ficheiros numa política de controlo de aplicações. 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 o Controlo de Aplicações do Windows Defender devido aos requisitos adicionais do ISM. As Regras de Caminho de Ficheiro não são recomendadas para ISM-1870 devido ao utilizador ter permissão de sistema de ficheiros no perfil do utilizador e pastas temporárias.

3 Os controlos ISM-0140, 0123, 1582, 1819 e 1228 são explicitamente principais e controlos de processo. A Microsoft recomenda que as pessoas e os processos sejam documentados e armazenados como artefactos no Gestor de Conformidade do Purview, como parte de provas tecnológicas automatizadas para revisões de conformidade do Essential 8.

Controlo de aplicações para Windows

Que solução utilizar?

A Microsoft recomenda que os clientes implementem o Controlo de Aplicações do Windows Defender (WDAC) em vez do AppLocker. O Controlo de Aplicações do Windows Defender está a sofrer melhorias contínuas. Embora o AppLocker continue a receber correções de segurança, não recebe melhoramentos de funcionalidades.

No entanto, o AppLocker também pode ser implementado como um complemento do Controlo de Aplicações do Windows Defender para cenários como dispositivos partilhados, onde é importante impedir que alguns utilizadores executem uma aplicação específica. A Microsoft recomenda que a sua organização aplique o Controlo de Aplicações do Windows Defender como o nível mais restritivo possível para a sua organização e que utilize o AppLocker para otimizar ainda mais as restrições do modo de utilizador, se necessário.

Dica

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

AppLocker

O AppLocker foi introduzido com o Windows 7 e permite que a organização controle que processos de modo de utilizador (aplicações) podem ser executados nos seus Sistemas Operativos Windows. As Políticas do AppLocker podem aplicar-se a todos os utilizadores num sistema ou a utilizadores e grupos individuais com regras que podem ser definidas com base em:

  • Regras de hash criptográfico
  • Regras de certificação do Publisher
  • Regras de caminho

As políticas do AppLocker podem ser criadas em todas as versões e adições suportadas do Sistema Operativo Windows e podem ser implementadas com Política de Grupo, o PowerShell ou uma solução de Gerenciamento de Dispositivos Móvel.

Controle de Aplicativos do Windows Defender

O Controlo de Aplicações do Windows Defender (WDAC) foi introduzido com Windows 10. Permite que as organizações controlem que processos de modo de utilizador (aplicações) e modo kernel (controladores) podem ser executados nos seus Sistemas Operativos Windows. As políticas WDAC são aplicadas ao sistema gerido como um todo e afetam todos os utilizadores do dispositivo com regras que podem ser definidas com base em:

  • Regras de hash criptográfico
  • Regras de certificação do Publisher
  • Regras de Caminho
  • Reputação da aplicação conforme determinado pelo Gráfico de Segurança Inteligente da Microsoft
  • Identidade do processo que iniciou a instalação da aplicação pelo instalador gerido

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

Devido ao Windows as a Service da Microsoft permitir o desenvolvimento e implementação de novas funcionalidades para os nossos clientes, algumas capacidades do WDAC só estão disponíveis em versões específicas do Windows.

Para obter informações detalhadas sobre o Controlo de Aplicações do Windows Defender e o Applocker, consulte Controlo de Aplicações do Windows Defender e disponibilidade de funcionalidades do AppLocker.

Controlo de aplicação Essential Eight com o AppLocker para ML1

Utilizar o AppLocker para alcançar o ML1

Quando o administrador está a implementar uma política do AppLocker para o controlo de aplicações baseado no utilizador, as seguintes regras podem ser utilizadas como uma implementação baseada no caminho de exemplo. Isto inclui as regras, a imposição de regras e o início automático do serviço de Identidade da Aplicação.

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 na ML1, consulte os seguintes artigos:

Criar a política appLocker para alcançar o ML1

As políticas do Microsoft AppLocker podem ser criadas com vários métodos. A Microsoft recomenda a utilização do projeto Microsoft Open source AaronLocker para ajudar na criação de políticas AppLocker. O AaronLocker permite a criação e manutenção de um controlo de aplicações robusto, rigoroso e rigoroso para o AppLocker o mais fácil e prático possível como utilizar o serviço de Scripts do PowerShell. O AaronLocker foi concebido para restringir a execução de programas e scripts por utilizadores não administrativos.

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

Implementar a política do AppLocker para alcançar o ML1

O Microsoft AppLocker pode ser implementado com Microsoft Intune, Política de Grupo ou PowerShell. O método de implementação dependeria da solução de gestão atual da organização.

Para obter informações detalhadas sobre a implementação do Cacifo de Aplicações, consulte os seguintes artigos:

Monitorizar eventos de política do AppLocker

Os eventos relacionados com o Microsoft AppLocker são monitorizados por uma solução de Gestão de Informações e Eventos de Segurança, como o Sentinel da Microsoft. Os eventos também são monitorizados com as informações avançadas de investigação 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 Investigação avançada, consulte os seguintes artigos:

Controlo de aplicação Essential Eight com o WDAC para ML2

A Microsoft está a destacar o processo de conceção, a gestão do ciclo de vida, a implementação e a documentação de orientação operacional para cumprir o controlo de aplicações Essential Eight ML2 e ML3 com o WDAC.

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

São necessários os pré-requisitos para utilizar esta documentação de orientação:

  • Windows 11 22H2 Enterprise
  • Utilizar Intune para solução de gestão
  • Defender para Endpoint, para solução de segurança de ponto final
  • Microsoft Sentinel para informações de segurança e gestão de eventos; e
  • Permissões adequadas dos administradores nas soluções utilizadas neste documento

WDAC em Sistemas Operativos Windows Server no âmbito deste guia. A documentação de orientação para o Windows Server será fornecida numa versão futura.

Requisitos de licenciamento

O serviço relacionado com o M365 pode estar localizado no Microsoft 365 e Office 365 descrições do serviço para compreender os serviços necessários necessários, as propostas de valor e os requisitos de licenciamento:

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

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

Introdução ao WDAC

Estrutura da política

Quando uma organização começa a planear o WDAC, a consideração das decisões de design forma como afeta a implementação de políticas e a manutenção da política de controlo de aplicações.

O WDAC deve ser utilizado como parte das políticas de controlo de aplicações da sua organização se o seguinte for verdadeiro:

  • Implementou ou planeou implementar as versões suportadas do Windows na sua organização
  • Precisa de um controlo melhorado sobre o acesso às aplicações da sua organização e aos dados de acesso do utilizador
  • A sua organização tem um processo bem definido para a gestão e implementação de aplicações
  • Tem recursos para testar políticas em relação aos requisitos da organização
  • Tem recursos para envolver o Suporte Técnico ou criar um processo de ajuda autónoma para problemas de acesso à aplicação do utilizador final
  • Os requisitos do grupo para produtividade, capacidade de gestão 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" exclusivo para os seus requisitos comerciais. A definição relacionada com o ACSC Essential 8 é o controlo ISM 1657 – "O controlo de aplicações restringe a execução de executáveis, bibliotecas de software, scripts, instaladores, HTML compilado, aplicações HTML e applets de painel de controlo para 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 a 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 a conceção de políticas, consulte os seguintes artigos:

Formatos de política

O WDAC suporta 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ó suporta uma única política ativa num sistema a qualquer momento

  • Formato de várias políticas (recomendado): este formato de política é suportado no Windows 10 1903+, Windows 11 e Windows Server 2022. Um formato de política múltipla permite uma maior flexibilidade para implementar o Controlo de Aplicações do Windows Defender e suporta até 32 políticas ativas num dispositivo. Além disso, permite os seguintes cenários:

    • Impor e auditar lado a lado: para validar as alterações de política antes de implementar a imposição. Os utilizadores podem implementar a política base do modo de auditoria lado a lado com uma política baseada no modo de imposição existente
    • Várias políticas base: os utilizadores podem impor duas ou mais políticas de base em simultâneo
    • Políticas suplementares: os utilizadores podem implementar uma ou mais políticas suplementares para expandir uma política base. Pode utilizar políticas suplementares para diferentes pessoas na sua organização, por exemplo, RH e TI

A Microsoft recomenda a utilização de múltiplos formatos de política e apenas a utilização do formato de política única para cenários bem definidos ou em que não sejam possíveis vários formatos de política, como Windows Server 2016 e o Windows Server 2019.

Para obter informações detalhadas sobre as políticas de controlo do WDAC, veja Utilizar várias Políticas de Controlo de Aplicações do Windows Defender.

Regras de políticas e regras de ficheiros

O WDAC contém dois conceitos:

  • Regras de política WDAC: as regras de política WDAC especificam configurações como o Modo de Auditoria, instalador gerido, Imposição de Scripts, Políticas de Suplemento (Formato de Política Múltipla), inteligência de Reputation-Based (Autorização ISG/Controlo de Aplicações Inteligentes) e talvez outras. As Regras de Política também determinam se o WDAC para binários de modo kernel e de modo de utilizador
  • Regras de ficheiro WDAC: as regras de ficheiro wDAC especificam autorização e reautorização para execução no Windows. As regras de ficheiro suportam hash, nome de ficheiro, caminho de ficheiro e regras do Publisher permitem que um cliente defina um conjunto aprovado pela organização de aplicações permitidas. A regra processa primeiro todas as regras de negação explícitas que encontra e, em seguida, processa todas as regras de permissão explícitas. Se não existir nenhuma regra de negação ou permissão, o WDAC verifica o instalador gerido. Por último, se nenhum destes conjuntos existir, o WDAC reverterá para Reputation-Based inteligência

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

Criação de políticas

Existem duas formas principais de criar uma Política WDAC com o PowerShell ou o Assistente do WDAC:

  • PowerShell: as políticas WDAC são criadas com Cmdlets de Integridade de Código Configuráveis no PowerShell. O PowerShell permite que um Profissional de TI automatize a análise do sistema de políticas WDAC, o que gera um XML de política. O PowerShell pode ser utilizado para intercalar XMLs de política, definir regras de política e adicionar outras regras de ficheiro de política, se necessário Os Cmdlets de Integridade do Código Configurável também podem ser utilizados para modificar as políticas de exemplo do WDAC para satisfazer os requisitos da sua organização.
  • Assistente de Controlo de Aplicações do Windows Defender (recomendado): o assistente de política do WDAC é uma aplicação de ambiente de trabalho windows open source escrita em C# e agrupada como um pacote MSIX. Foi criado para fornecer aos arquitetos de segurança segurança e administradores de sistema um meio mais adequado para criar, editar e intercalar políticas de Controlo de Aplicações. Esta ferramenta utiliza os cmdlets do PowerShell da CI de Configuração no back-end, pelo que 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, veja os seguintes artigos:

A Microsoft recomenda a utilização do Assistente de Controlo de Aplicações do Windows Defender para implementar o Essential Eight para o Controlo de Aplicações. Em alternativa, o PowerShell pode ser utilizado por organizações com requisitos avançados num modelo operacional de DevOps com as políticas de exemplo como base ou que pretendam criar uma política para cenários bem definidos a partir de um sistema de referência.

Ciclo de vida da política

Antes de uma organização começar a implementar uma solução de controlo de aplicações, tem de considerar como as suas políticas são geridas e mantidas ao longo do tempo. A maioria das políticas WDAC evoluem ao longo do tempo e continuam através de um conjunto de fases identificáveis durante a sua duração. Estas 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, os eventos de bloqueio são gerados, mas os ficheiros não são impedidos de ser executados
  2. Implementar a política do modo de auditoria nos sistemas pretendidos
  3. Monitorizar eventos de bloqueio de auditoria a partir dos sistemas pretendidos e refinar as regras conforme necessário para resolver blocos inesperados/indesejados
  4. Repita estes passos até que os restantes eventos de bloco satisfaçam as suas expectativas durante a auditoria
  5. Gere a versão do modo imposto da política. No modo de imposição, os ficheiros 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. Implementar a política de modo de imposição nos sistemas pretendidos
  7. Repita todos estes passos continuamente para abordar quaisquer ações de bloqueio inesperadas/indesejadas

Para gerir eficazmente as políticas WDAC, deve armazenar e manter os documentos XML de política num repositório central. A Microsoft recomenda uma solução de controlo de código fonte, como o GitHub ou a solução de gestão de documentos, como o SharePoint, que fornece controlo de versões.

Pré-requisitos do WDAC para o instalador gerido

Esta secção destina-se a fornecer orientações do cliente sobre os requisitos de configuração do instalador gerido pelo WDAC com o PowerShell e Microsoft Intune.

  • Reveja a proteção contra ameaças do Windows automaticamente para permitir aplicações implementadas por um instalador gerido com o Controlo de Aplicações do Windows Defender (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)

Observação

Este script de exemplo não utiliza o AppLocker, pelo que as regras DENY benignas não estão presentes no passo 1. Esta configuração do AppLocker seria criada para todos os dispositivos que necessitam do instalador gerido.

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

Segue-se um exemplo de um script que pode ser implementado com Intune extensão de gestão – 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 tem de adicionar o script de configuração à política de Regra de Ficheiro WDAC através de Hash ou Publisher.

Instalador gerido pelo WDAC

Visão Geral

A funcionalidade do WDAC denominada instalador gerido permite que uma organização equilibre a segurança e a capacidade de gestão ao impor políticas de controlo de aplicações. Isto permite que as aplicações sejam instaladas por uma solução de distribuição de software, como Microsoft Configuration Manager ou Intune.

Um equívoco comum é configurar a regra do "instalador gerido" na política do WDAC são os únicos passos necessários. Isto está incorreto e é necessária outra configuração do AppLocker para que esta funcionalidade funcione.

O instalador gerido utiliza uma coleção de regras no AppLocker para designar binários considerados fidedignos pela sua organização para instalação de aplicações. O Windows monitoriza o processo do binário configurado e todos os processos subordinados que inicia enquanto monitoriza os ficheiros associados que estão a ser escritos no disco. Estes ficheiros são identificados como provenientes de um instalador gerido, pelo que podem ser executados.

Implementação do instalador gerido

A criação da política appLocker no GPO Edit e os cmdlets do PowerShell do AppLocker não podem ser utilizados diretamente para criar regras para a coleção do instalador gerido. Tem de utilizar o VS Code ou outra ferramenta de editor para criar uma coleção de Regras do instalador gerido.

Atualmente, o Fornecedor de Serviços de Configuração (CSP) do AppLocker não suporta o tipo de coleção de regras do instalador gerido, pelo que a política appLocker tem de estar a entrar com o PowerShell para Microsoft Intune.

Uma vez que a funcionalidade "Imposição de Scripts" do Controlo de Aplicações do Windows Defender é necessária para cumprir o ISM-1657, é necessária a imposição de scripts para controlar o PowerShell, o VBscript, o cscript, o HSMTA e o MSXML. O script do PowerShell para configurar o "instalador gerido" tem de estar dentro da regra de política de ficheiros WDAC com Hash ou Publisher.

A Microsoft recomenda a configuração do instalador gerido para Microsoft Intune. Intune permite uma gestão robusta das Aplicações empacotadas com Microsoft Intune sem o requisito de atualizar frequentemente uma política de Controlo de Aplicações do Windows Defender.

Implementação do script do PowerShell para o instalador gerido

A implementação deste script de configuração para o instalador gerido pode ser obtida de duas formas ao utilizar Microsoft Intune consoante o cenário:

  • Hash: o hash do script teria de ser conhecido na Política de Ficheiros WDAC, empacotado e implementado com a Ferramenta de Preparação de Conteúdos do Microsoft Win32 ou a funcionalidade Script do PowerShell no Microsoft Intune.
  • Assinado por código (Publisher): o Script do PowerShell foi assinado por uma autoridade fidedigna e conhecido com a Política de Ficheiros WDAC, empacotado e implementado com a Ferramenta de Preparação de Conteúdos do Microsoft Win32 ou a funcionalidade script do PowerShell no Microsoft Intune.

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

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

Criar uma política de auditoria

Com as opções compreendidas e as decisões de conceção tomadas, a organização é capaz de criar a primeira política de auditoria com o Assistente de Controlo de Aplicações do Windows Defender:

  1. Abra o Assistente de Controlo de Aplicações do 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, em seguida, selecione Seguinte.

  3. No Modelo de Política, são-lhe apresentadas três opções:

    • O Modo Predefinido do Windows inclui SO windows, Aplicações da Loja, Microsoft 365 Apps para Enterprise (Office 365 Pro Plus) e controladores de kernel assinados whQL.
    • Permitir o Modo Microsoft inclui todas as secções no Modo Predefinido do Windows e Todas as aplicações assinadas pela Microsoft.
    • O Modo Assinado e Respeitável inclui todas as secções anteriores e Reputation-Based inteligência.

Importante

Reputation-Based Intelligence for Application Control não cumpre o Controlo de Aplicações Essential Eight devido ao requisito "Conjunto aprovado pela organização" (ISM 1657) e "Os conjuntos de regras de controlo de aplicações são validados numa base anual ou mais frequente" (ISM 1582). Esta funcionalidade no WDAC não cumprirá os requisitos para ML2 ou ML3. A Microsoft recomenda a utilização do Reputation-Based Intelligence para a adoção organizacional do WDAC fora do contexto do Controlo de Aplicações Essential Eight.

  1. Selecione Modo Predefinido do Windows ou Permitir Modo Microsoft consoante os requisitos da sua organização. Para este documento, a Microsoft está a utilizar Permitir o Modo Microsoft.
  2. Modifique o Nome da Política e a Localização para o Nome da Política e a Localização do Ficheiro de Política pretendidos para armazenar o ficheiro e selecione Seguinte.

Observação

As Informações Detalhadas do WDAC – Regras de Política podem ser encontradas aqui.

  • Desativar a Imposição de Script definida como "Desativado" é necessária para a ISM 1657 e 1658 para controlar Scripts, Aplicações HTML e HTML aplicadas.
  • O Gráfico de Segurança Inteligente definido como "Desativado" é necessário para ISM 1657, 1658 e 1582.
  • O instalador gerido é recomendado para ser "Ativado" para ajudar uma organização com o ciclo de vida da política WDAC.
  • A Integridade do Código do Modo de Utilizador é necessária para que as políticas WDAC se apliquem tanto ao modo kernel como aos binários do modo de utilizador.
  • A opção Permitir Políticas suplementares é necessária para utilizar 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 numa organização.

  1. Nas Regras de Assinatura, o administrador consegue ver todos os certificados da Microsoft que foram adicionados como Permitir Regras do Publicador. Vamos abordar Adicionar Regra Personalizada mais à frente neste artigo.
  2. Selecione Avançar.

O Assistente de Controlo de Aplicações do Windows Defender gera:

  • XML de Política
  • {GUID}. CIP

As Informações Detalhadas do WDAC – Regras de Política podem ser encontradas aqui.

Observação

Cada política gerada através do Assistente de Controlo de Aplicações do Windows Defender obtém um novo Identificador Exclusivo Global (GUID).

A política WDAC foi criada com êxito.

XML de Política

Uma vez que a organização criou a política WDAC com o Assistente do WDAC, a organização consegue ver o contexto deste ficheiro num editor de texto. O XML é dividido em várias secções diferentes, para o contexto do Essential Eight, tome nota do PolicyID e do BasePolicyID.

Observação

Embora seja possível editar diretamente o XML da Política. A Microsoft recomenda que todas as alterações adicionais às regras de política ou aos ficheiros de assinatura sejam efetuadas através do Assistente de Controlo de Aplicações do Windows Defender ou cmdlets de Integridade de Código Configuráveis no PowerShell.

Implementação da política de Auditoria do WDAC

Implementar a política de auditoria do WDAC através de Intune

Agora que a organização criou uma política de auditoria, está na altura de implementá-la com Intune gestão de dispositivos.

  1. Inicie sessão no centro de administração do Intune.
  2. No Intune centro de administração, aceda a Dispositivos e, em seguida, Perfis de Configuração.
  3. Em seguida, crie uma Plataforma de Perfis>– Windows 10 ou Posterior, Modelos de Tipo de Perfil e Personalizado.
  4. Crie um nome para a política (por exemplo, "Controlo de Aplicações – Permitir Microsoft – Auditoria") e selecione Seguinte.
  5. Em Definições OMA-URI, selecione Adicionar.

Observação

Estas Informações dependem do ID da Política gerado a partir do Assistente de Controlo de Aplicações do Windows >Defender para o XML de política criado a partir de "Criar Política de Auditoria" na secção acima:

- Nome = Permitir Auditoria da Microsoft
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- Tipo de Dados = Base64 (Ficheiro)

  1. Quando o Assistente de Controlo de Aplicações do Windows Defender gerou o XML da política, também criou um (GUID). Ficheiro CIP. O ficheiro CIP tem de ser copiado e mudar o nome da extensão de ficheiro para . BIN por exemplo {CB46B243-C19C-4870-B098-A2080923755C}.bin.
  2. Carregue o BIN em Base64 (Ficheiro).
  3. Selecione Salvar.
  4. Siga as instruções para criar o Perfil de Configuração.
  5. Implemente a política que criou, por exemplo, "Controlo de Aplicações – Permissão da Microsoft – Auditoria", Perfil de Configuração no sistema pretendido.

WDAC – monitorização da política de auditoria

Após o ciclo de vida da política WDAC, a organização tem de rever os eventos gerados a partir da política "Permitir Auditoria da Microsoft". A monitorização da política de auditoria do WDAC pode ser obtida com dois métodos:

  • IDs de eventos do Controlo de Aplicações: os IDs de Eventos do controlo de aplicações são o método tradicional de revisão de eventos auditados num Sistema Operativo Windows. Estes IDs de evento podem ser reencaminhados para uma localização centralizada através do Reencaminhamento do Registo de Eventos do Windows ou da gestão de informações e eventos de Segurança de terceiros.

Para obter informações sobre os IDs de eventos, veja Compreender os IDs de eventos do Controlo de Aplicações – segurança do Windows.

A Microsoft recomenda a utilização da integração de Microsoft Defender XDR (MDPE) para Microsoft Sentinel. MDPE e Sentinel permitem que os dados telemétricos de Investigação Avançada sejam armazenados durante mais de 30 dias, em comparação com o Microsoft Defender para Ponto de Extremidade.

Para obter informações detalhadas sobre ligações e monitorização, consulte os seguintes artigos:

Monitorizar o WDAC com Microsoft Defender para Ponto de Extremidade

O exemplo seguinte demonstra que um utilizador tem várias aplicações utilizadas para as tarefas diárias de uma organização. O exemplo contém aplicações da Microsoft e várias aplicações código aberto.

Como o exemplo está no modo de auditoria de imposição, pode ser visto pelo administrador (mas não afeta o utilizador) que os eventos acionados para WinSCP, VLC, Putty e FileZilla, uma vez que estas aplicações não fazem parte da política de auditoria inicial.

Agora, através do portal Microsoft Defender, introduza Investigação Avançada para restringir os eventos de auditoria para compreender que blocos inesperados/indesejados estariam a ocorrer se o modo de auditoria fosse desativado e, assim, transformado em modo de imposição neste exemplo.

Captura de ecrã da investigação avançada.

Com o esquema de referência da página anterior, procure todos os eventos de Auditoria de Política acionados pelo WDAC dos últimos sete dias e apresenta informações relevantes com a consulta KQL (Keyboard Query Language) 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

Eis um exemplo de uma saída com a consulta KQL anterior.

Captura de ecrã a mostrar o resultado da Investigação Avançada.

Nos registos, existe um relatório detalhado de informações como a Árvore de Processos, Caminho do Ficheiro, Informações SHA, Signatário e Informações do Emissor.

O próximo passo consiste em restringir os resultados.

Com a mesma consulta KQL, adicione outro campo em que o Nome do Ficheiro do Processo de Início é Windows Explorer. A consulta KQL apresenta as aplicações executadas pelos utilizadores 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

Eis um exemplo de uma saída com a consulta KQL anterior. Captura de ecrã a mostrar a saída da consulta.

A ação de consulta KQL reduziu agora as informações para um conjunto de dados mais de gestão. O que se pode ver são as aplicações que estão a ser utilizadas pelos sistemas pretendidos. Estas aplicações têm de ser adicionadas à política da organização ou consideradas como adicionadas através do controlo de alterações organizacionais.

Observação

O KQL é uma ferramenta avançada para apresentar conjuntos de dados estruturados e não estruturados. Este é apenas um exemplo de utilização de KQL e a Microsoft recomendaria rever a seguinte documentação: Saiba mais sobre a linguagem de consulta de investigação avançada no Microsoft Defender XDR

WDAC – Atualizar política de auditoria

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

Com uma redução dos nossos resultados de pesquisa através de KQL, o passo seguinte é atualizar a política base do WDAC ou utilizar uma política de suplementos. O exemplo seguinte utiliza políticas de suplementos.

  1. Abra o Assistente de Controlo de Aplicações do 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 para a sua política base, atualize a localização para guardar a sua Política Suplementar e selecione Seguinte.

  3. Selecione Seguinte em Regras de Política.

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

  5. Dentro das Condições de Regra Personalizada, estão disponíveis muitas opções:

    • Regra de Modo de Utilizador do Âmbito da Regra/Regra do Modo de Kernel
    • Ação de Regra: Permitir/Negar
    • Tipo de Regra
      • Publicador (recomendado)
      • Arquivo
      • File Attribute
      • Aplicação Empacotada
      • Hash
    • Ficheiro de Referência

Observação

A Microsoft recomenda a utilização de regras baseadas no Publisher, sempre que adequado, e reverter para regras baseadas em Hash para ficheiros de referência não assinados para implementar o Controlo de Aplicações Essential Eight.

Utilizar Microsoft Defender para Ponto de Extremidade

  1. Pesquise Nome do Ficheiro na Pesquisa , navegue para o ficheiro Informações e transfira o ficheiro. Captura de ecrã a mostrar a atualização da política de auditoria 2.
  2. Inspecione o registo diretamente a partir da Investigação Avançada e transfira o ficheiro que, em seguida, transfere os binários necessários. Captura de ecrã a mostrar a atualização da política de auditoria 3.
  3. Com os binários necessários, continue a criar outra política para as aplicações ISV da sua organização.
  4. No Assistente de Controlo de Aplicações do Windows Defender, selecione o Tipo de Regra pretendido e navegue para os binários de referência do passo anterior. O exemplo seguinte demonstra que o VLC cumpre as informações necessárias do publicador. Captura de ecrã a mostrar a atualização da política de auditoria 4.

Observação

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

  1. Prima Seguinte e Criar.
  2. Implemente esta Política suplementar com os passos descritos anteriormente na secção "Implementar a Política de Auditoria de Controlo de Aplicações do Windows Defender através de Microsoft Intune".

WDAC – Mudar para impor a política

Para mudar para impor a política:

  1. Abra o Assistente de Controlo de Aplicações do Windows Defender e selecione Política Editor.

  2. Navegue para o XML de Política que deve ser alterado para imposto.

  3. Desative o comutador Modo de Auditoria nas Regras de Política.

  4. Selecione Seguinte em Regras de Política.

  5. É criada uma Política de Atualização com um número de versão alterado e foi criado um novo ficheiro CIP.

  6. No Centro de Administração do Microsoft Endpoint Manager, aceda a Dispositivos e, em seguida, a Perfis de Configuração.

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

  8. Crie um nome para a política, por exemplo Controlo de Aplicações – Impor Política e selecione Seguinte.

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

    Observação

    Estas Informações dependem do ID da Política gerado a partir do Assistente de Controlo de Aplicações do Windows Defender para a política XML criada na secção criar auditoria acima.

    - Name = Microsoft Allow Enforce
    - OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
    - Tipo de Dados = Base64 (Ficheiro)

  10. Quando o Assistente de Controlo de Aplicações do Windows Defender gerou o XML da política, também criou um (GUID). Ficheiro CIP. O passo seguinte é copiar este Ficheiro CIP e mudar o nome da extensão de ficheiro para . BIN por exemplo {CB46B243-C19C-4870-B098-A2080923755C}.bin.

  11. Carregue o BIN em Base64 (Ficheiro).

  12. Selecione Salvar.

  13. Siga as instruções para criar o Perfil de Configuração.

  14. Implementar o Controlo de Aplicações – Impor o Perfil de Configuração de Políticas ao sistema pretendido.

    Observação

    O administrador tem de excluir a Aplicação criada anteriormente – Política de Auditoria do sistema pretendido que está a ser mudado para impor