Autorizar aplicativos confiáveis com o Gráfico de Segurança Inteligente (ISG)

Observação

Alguns recursos do Controle de Aplicativos para Empresas estão disponíveis apenas em versões específicas do Windows. Saiba mais sobre a disponibilidade de recursos do Controle de Aplicativos.

O Controle de Aplicativos pode ser difícil de implementar em organizações que não implantam e gerenciam aplicativos por meio de um sistema gerenciado pela TI. Nesses ambientes, os usuários podem adquirir os aplicativos que desejam usar para o trabalho, dificultando a criação de uma política de Controle de Aplicativos eficaz.

Para reduzir o atrito do usuário final e as chamadas de assistência técnica, você pode definir o Controle de Aplicativos para Empresas para permitir automaticamente aplicativos que o ISG (Gráfico de Segurança Inteligente) da Microsoft reconhece como tendo boa reputação conhecida. A opção ISG ajuda as organizações a começar a implementar o Controle de Aplicativos mesmo quando a organização tem controle limitado sobre seu ecossistema de aplicativos. Para saber mais sobre o ISG, consulte a seção Segurança nos principais serviços e recursos do Microsoft Graph.

Aviso

Os binários que são críticos para inicializar o sistema devem ter permissão usando regras explícitas em sua política de Controle de Aplicativos. Não confie no ISG para autorizar esses arquivos.

A opção ISG não é a maneira recomendada de permitir aplicativos comercialmente críticos. Você deve sempre autorizar aplicativos comercialmente críticos usando regras de permissão explícitas ou instalando-os com um instalador gerenciado.

Como o Controle de Aplicativos funciona com o ISG?

O ISG não é uma "lista" de aplicativos. Em vez disso, ele usa a mesma vasta inteligência de segurança e análise de aprendizado de máquina que alimenta o Microsoft Defender SmartScreen e o Microsoft Defender Antivírus para ajudar a classificar aplicativos como tendo reputação "boa conhecida", "ruim conhecida" ou "desconhecida". Essa IA baseada em nuvem é baseada em trilhões de sinais coletados de pontos de extremidade do Windows e outras fontes de dados e processada a cada 24 horas. Como resultado, a decisão da nuvem pode mudar.

O Controle de Aplicativos verifica apenas o ISG em busca de binários que não são explicitamente permitidos ou negados por sua política e que não foram instalados por um instalador gerenciado. Quando esse binário for executado em um sistema com o Controle de Aplicativos habilitado com a opção ISG, o Controle de Aplicativos marcará a reputação do arquivo enviando seu hash e informações de assinatura para a nuvem. Se o ISG relatar que o arquivo tem uma reputação de "bom conhecido", o arquivo terá permissão para ser executado. Caso contrário, ele será bloqueado pelo Controle de Aplicativos.

Se o arquivo com boa reputação for um instalador de aplicativos, a reputação do instalador será passada para todos os arquivos que ele gravar em disco. Dessa forma, todos os arquivos necessários para instalar e executar um aplicativo herdam os dados de reputação positivos do instalador. Files autorizados com base na reputação do instalador terão o $KERNEL.SMARTLOCKER.ORIGINCLAIM Atributo Estendido (EA) do kernel gravado no arquivo.

O Controle de Aplicativos repete periodicamente os dados de reputação em um arquivo. Além disso, as empresas podem especificar que quaisquer resultados de reputação armazenados em cache sejam liberados na reinicialização usando a opção Enabled:Invalidate EAs na reinicialização .

Entender as declarações de origem

Quando o instalador gerenciado ou o Gráfico de Segurança Inteligente (ISG) autoriza um arquivo, o Controle de Aplicativos registra por que esse arquivo é confiável adicionando um atributo estendido (EA) gerenciado pelo kernel ao arquivo. Conhecido como sua declaração de origem, o EA captura a origem da reputação do arquivo, para que a Integridade do Código possa avaliar posteriormente o arquivo sem verificar novamente sua origem original. A declaração de origem é chamada de $KERNEL.SMARTLOCKER.ORIGINCLAIM. Uma declaração de origem registra o que gravou o arquivo, indica que o processo que gravou o arquivo era confiável como um instalador gerenciado ou baseado na reputação e se a confiança foi herdada de um pai. Você pode usar o fsutil comando para visualizar este EA em um arquivo. Para obter as etapas exatas, consulte Usando fsutil para consultar atributos estendidos para o MI (instalador gerenciado).

  • Origem do instalador gerenciado: O arquivo foi escrito por um processo em que sua política confia como um instalador gerenciado (por exemplo, uma ferramenta de implantação como o Microsoft Configuration Manager ou o Microsoft Intune). Essa confiança é baseada em como o arquivo chegou ao dispositivo, não nas propriedades, assinaturas ou valor de hash do arquivo. Para obter mais informações, consulte Considerações de segurança com o instalador gerenciado.
  • Origem do Gráfico de Segurança Inteligente (ISG): O arquivo recebeu uma resposta de reputação favorável ou herdou a resposta de reputação favorável do processo pai, que foi um instalador que criou o arquivo. Essas respostas de reputação vêm dos serviços de inteligência de segurança da Microsoft, chamados de Gráfico de Segurança Inteligente. A reputação está vinculada ao arquivo específico, portanto, se o arquivo for modificado, a reputação não se aplicará mais e a declaração de origem não será mais honrada. Se isso acontecer, o arquivo será reavaliado pelo Controle de Aplicativos na próxima vez que for executado. Para obter mais informações, consulte Autorizar aplicativos confiáveis com o Gráfico de Segurança Inteligente (ISG).

As declarações de origem se propagam para baixo em uma árvore de processos. Quando um instalador gerenciado é executado ou quando recebe uma resposta de reputação de instalador confiável do ISG, ele passa confiança equivalente para os arquivos que grava e para os processos filho que inicia. Essa confiança continua a fluir pela árvore de processos ao vivo por meio de processos filho, seus filhos e gerações posteriores, de modo que todos os arquivos de que um instalador precisa para instalar e executar um aplicativo sejam autorizados.

A propagação não é ilimitada. Ela termina quando a árvore de processos confiáveis é interrompida, incluindo nestes casos:

  • O processo do instalador original termina. A relação de confiança tem como escopo o tempo de vida da árvore de processos confiáveis. Um arquivo criado após o encerramento do processo original do instalador gerenciado ou do instalador confiável ISG não herda sua declaração de origem. Nos dados de atributo estendido, esse arquivo é marcado como "filho de um filho" e não está autorizado a ser executado por conta própria — ele deve ser permitido por outros meios, como uma regra explícita, origem do instalador gerenciado ou reputação de ISG.
  • Um processo cruza um limite de segurança. Se um processo for gerado em um usuário ou contexto de segurança diferente, o processo pai poderá passar sua declaração de origem para o processo filho. Caso contrário, a árvore de processos será interrompida e todos os arquivos criados pelo processo filho ou seus filhos não serão autorizados com base na declaração de origem do processo inicial.

Após a quebra da árvore de processos por qualquer motivo, todos os arquivos criados devem ser autorizados por outros meios, incluindo se forem executados como um instalador gerenciado ou receberem uma resposta de reputação de instalador confiável do ISG.

Configurando a autorização do ISG para sua política de Controle de Aplicativos

Configurar o ISG é fácil usando qualquer solução de gerenciamento que você desejar. A configuração da opção ISG envolve estas etapas básicas:

Verifique se a opção ISG está definida no XML da política de Controle de Aplicativos

Para permitir aplicativos e binários com base no Gráfico de Segurança Inteligente da Microsoft, a opção de autorização Enabled:Intelligent Security Graph deve ser especificada na política de Controle de Aplicativos. Esta etapa pode ser feita com o Set-RuleOption cmdlet. Você também deve definir a opção Enabled:Invalidate EAs na reinicialização para que os resultados do ISG sejam verificados novamente após cada reinicialização. A opção ISG não é recomendada para dispositivos que não têm acesso regular à Internet. O exemplo a seguir mostra ambas as opções definidas.

<Rules>
    <Rule>
      <Option>Enabled:Unsigned System Integrity Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Advanced Boot Options Menu</Option>
    </Rule>
    <Rule>
      <Option>Required:Enforce Store Applications</Option>
    </Rule>
    <Rule>
      <Option>Enabled:UMCI</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Managed Installer</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Intelligent Security Graph Authorization</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Invalidate EAs on Reboot</Option>
    </Rule>
</Rules>

Habilitar os serviços necessários para permitir que o controle de aplicativos use o ISG corretamente no cliente

Para que a heurística usada pelo ISG funcione corretamente, outros componentes no Windows devem ser habilitados. Você pode configurar esses componentes executando o executável appidtel no c:\windows\system32formato .

appidtel start

Esta etapa não é necessária para políticas de Controle de Aplicativos implantadas no MDM, pois o CSP habilitará os componentes necessários. Essa etapa também não é necessária quando o ISG está configurado usando a integração do Controle de Aplicativos do Gerenciador de Configurações.

Considerações de segurança com a opção ISG

Como o ISG é um mecanismo baseado em heurística, ele não fornece as mesmas garantias de segurança que as regras explícitas de permissão ou negação. É mais adequado quando os usuários operam com direitos de usuário padrão e onde uma solução de monitoramento de segurança, como o Microsoft Defender para Ponto de Extremidade, é usada.

Precedência de regra com ISG

Quando você combina a opção ISG com regras explícitas de permissão ou negação, o controle de aplicativos avalia as regras explícitas antes de usar a reputação. Uma regra de negação explícita sempre tem precedência sobre a reputação do ISG, portanto, o Controle de Aplicativos bloqueia um arquivo negado, independentemente de sua reputação. Uma regra de permissão explícita também tem precedência sobre a reputação. O ISG influencia apenas arquivos que nenhuma regra explícita de permissão ou negação cobre.

Você pode criar qualquer regra estática em sua política que possa autorizar de forma confiável binários críticos de inicialização, pois a Integridade do Código a avalia localmente a partir da política durante a inicialização sem nenhuma dependência de nuvem ou tempo de execução disponível. Isso inclui regras AllowAll, regras curinga FileName='*' , regras de signatário, regras de atributo de arquivo e regras de hash. Nunca confie no ISG ou em um instalador gerenciado para autorizar arquivos críticos de inicialização: suas decisões dependem da reputação da nuvem ou dos atributos estendidos do kernel que nem sempre estão disponíveis no início do caminho de inicialização, o que pode bloquear esses arquivos ou causar tempo limite de inicialização ou início do serviço.

Importante

As regras de FilePath não podem ser usadas para autorizar o código no modo kernel. Autorize drivers críticos de inicialização usando um signatário, atributo de arquivo ou regra de hash em vez de uma regra de caminho de arquivo.

Se você usar um modelo AllowAll com regras de negação explícitas, as regras de negação explícitas ainda terão precedência. Para obter mais informações, consulte Criar uma política de controle de aplicativos para bloquear drivers ou aplicativos. Para obter mais informações sobre o instalador gerenciado e o comportamento do ISG, consulte Referência técnica do instalador gerenciado e do ISG e guia de solução de problemas.

Os processos em execução com privilégios de kernel podem contornar o Controle de Aplicativos definindo o atributo de arquivo estendido ISG para fazer com que um binário pareça ter boa reputação conhecida.

Além disso, como a opção ISG passa a reputação dos instaladores de aplicativos para os binários que eles gravam no disco, ela pode autorizar arquivos em excesso em alguns casos. Por exemplo, se o instalador iniciar o aplicativo após a conclusão, o Controle de Aplicativos também permitirá todos os arquivos que o aplicativo gravar durante a primeira execução.

Limitações conhecidas com o uso do ISG

Como o ISG só permite binários que sejam "válidos", há casos em que o ISG pode não ser capaz de prever se o software legítimo é seguro para executar. Se isso acontecer, o software será bloqueado pelo Controle de Aplicativos. Nesse caso, você precisa permitir o software com uma regra em sua política de Controle de Aplicativos, implantar um catálogo assinado por um certificado confiável na política de Controle de Aplicativos ou instalar o software de um instalador gerenciado de Controle de Aplicativos. Instaladores ou aplicativos que criam binários dinamicamente em tempo de execução e aplicativos com atualização automática podem apresentar esse sintoma.

Os aplicativos empacotados não têm suporte com o ISG e precisarão ser autorizados separadamente em sua política de controle de aplicativos. Como os aplicativos empacotados têm uma identidade de aplicativo forte e devem ser assinados, é simples autorizar aplicativos empacotados com sua política de Controle de Aplicativos.

O ISG não autoriza drivers no modo kernel. A política de controle de aplicativos deve ter regras que permitam a execução dos drivers necessários.

Observação

Uma regra que nega ou permite explicitamente um arquivo terá precedência sobre os dados de reputação desse arquivo. O suporte interno ao Controle de Aplicativos do Microsoft Intune inclui a opção de confiar em aplicativos com boa reputação por meio do ISG, mas não tem a opção de adicionar regras explícitas de permissão ou negação. Na maioria dos casos, os clientes que usam o Controle de Aplicativos precisarão implantar uma política personalizada de Controle de Aplicativos (que pode incluir a opção ISG, se desejado) usando a funcionalidade OMA-URI do Intune.

  • Last updated on