Processar falsos positivos no Microsoft Sentinel

Importante

As deteções personalizadas são agora a melhor forma de criar novas regras no Microsoft Sentinel Microsoft Defender XDR SIEM. Com deteções personalizadas, pode reduzir os custos de ingestão, obter deteções ilimitadas em tempo real e beneficiar de uma integração perfeita com os dados, as funções e as ações de remediação do Defender XDR, com mapeamento automático de entidades. Para mais informações, leia As deteções personalizadas são agora a experiência unificada para criar deteções no Microsoft Defender XDR.

Microsoft Sentinel regras de análise notificam-no quando algo suspeito ocorre na sua rede. Nenhuma regra de análise é perfeita, e é inevitável que surjam alguns falsos positivos que têm de ser tratados. Este artigo descreve como lidar com falsos positivos, quer através da automatização, quer através da modificação de regras de análise agendada.

Causas e prevenção de falsos positivos

Mesmo numa regra de análise corretamente criada, os falsos positivos provêm frequentemente de entidades específicas, como utilizadores ou endereços IP, que devem ser excluídos da regra.

Os cenários comuns incluem:

• Atividades normais de certos utilizadores, normalmente princípios de serviço (identidades automatizadas usadas por aplicações e serviços), mostram um padrão que parece suspeito.
• A atividade de análise de segurança intencional proveniente de endereços IP conhecidos é detetada como maliciosa.
• Uma regra que exclua endereços IP privados também deve excluir alguns endereços IP internos que não são privados.

Este artigo descreve dois métodos para evitar falsos positivos:

• As regras de automatização criam exceções sem modificar as regras de análise.
• As modificações das regras de análise agendada permitem exceções mais detalhadas e permanentes.

A tabela seguinte descreve as características de cada método:

Método	Característica
Regras de automatização	Pode aplicar-se a várias regras de análise. Mantenha um registo de auditoria. As exceções encerram imediatamente e automaticamente os incidentes criados, registando o motivo do encerramento e os comentários. São muitas vezes gerados por analistas. Permitir a aplicação de exceções durante um período de tempo limitado. Por exemplo, os trabalhos de manutenção podem desencadear falsos positivos que, fora do período de manutenção, seriam incidentes reais.
Modificações de regras de análise	Permitir expressões booleanas avançadas e exceções baseadas em sub-rede. Permite-lhe utilizar listas de observação para centralizar a gestão de exceções. Normalmente, requerem implementação por engenheiros do Centro de Operações de Segurança (SOC). São a solução falsa positiva mais flexível e completa, mas são mais complexas.

Adicionar exceções com regras de automatização (apenas portal do Azure)

O procedimento seguinte descreve como adicionar uma regra de automação quando se observa um incidente de falso positivo. Este procedimento é suportado apenas no portal do Azure.

Se Microsoft Sentinel estiver integrado no portal do Defender, crie regras de automatização do zero com base nos detalhes do incidente. Para obter mais informações, veja Automatizar a resposta a ameaças em Microsoft Sentinel com regras de automatização.

Para adicionar uma regra de automatização para processar um falso positivo:

1. Em Microsoft Sentinel, em Incidentes, selecione o incidente para o qual pretende criar uma exceção.

2. No painel de detalhes do incidente no lado, selecione Ações > Criar regra de automatização.

3. Na barra lateral Criar nova regra de automatização , modifique opcionalmente o novo nome da regra para identificar a exceção, em vez de apenas o nome da regra de alerta.

4. Em Condições, opcionalmente, adicione mais nomes de regras de Análiseaos quais aplicar a exceção. Selecione a caixa pendente que contém o nome da regra de análise e selecione mais regras de análise na lista.

5. A barra lateral apresenta as entidades específicas no incidente atual que podem ter causado o falso positivo. Mantenha as sugestões automáticas ou modifique as condições sugeridas para afinar a exceção. Por exemplo, pode alterar uma condição num endereço IP para aplicar a uma sub-rede inteira.

   

6. Depois de estar satisfeito com as condições, desloque-se para baixo no painel lateral para continuar a definir o que a regra faz:

   

   • A regra já está configurada para fechar um incidente que cumpre os critérios de exceção.
   • Pode manter o motivo de fecho especificado tal como está ou pode alterá-lo se outro motivo for mais adequado.
   • Pode adicionar um comentário ao incidente encerrado automaticamente que explique a exceção. Por exemplo, pode especificar que o incidente teve origem numa atividade administrativa conhecida.
   • Por predefinição, a regra está definida para expirar automaticamente após 24 horas. Esta expiração pode ser o que pretende e reduz a probabilidade de erros falsos negativos. Se quiser uma exceção mais longa, defina Expiração da regra para uma hora posterior.

7. Se quiser, pode adicionar mais ações. Por exemplo, pode adicionar uma etiqueta ao incidente ou executar um manual de procedimentos para enviar um e-mail ou uma notificação ou para sincronizar com um sistema externo.

8. Selecione Aplicar para ativar a exceção.

Adicionar exceções modificando consultas de regras de análise

Também pode implementar exceções modificando a consulta de regras de análise. Pode incluir exceções diretamente na regra ou, de preferência, sempre que possível, utilizar uma referência a uma lista de observação. Em seguida, pode gerir a lista de exceções na lista de observação.

Modificar a consulta

Para obter instruções detalhadas sobre como utilizar o Assistente de Regras de Análise para criar e editar regras de análise, veja Criar regras de análise personalizadas para detetar ameaças.

Para editar regras de análise existentes, selecione Automatização no Microsoft Sentinel menu de navegação esquerdo. Selecione a regra que pretende editar e, em seguida, selecione Editar no canto inferior direito para abrir o Assistente de Regras de Análise.

Para implementar uma exceção num preâmbulo de regra normal, pode adicionar uma condição como where IPAddress !in ('<ip addresses>') perto do início da consulta de regra. Esta linha exclui endereços IP específicos da regra.

let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in ('10.0.0.8', '192.168.12.1')
...

Este tipo de exceção não está limitado a endereços IP. Pode excluir utilizadores específicos através do UserPrincipalName campo ou excluir aplicações específicas com AppDisplayName.

Também pode excluir múltiplos atributos. Por exemplo, para excluir alertas do endereço 10.0.0.8 IP ou do utilizador user@microsoft.com, utilize:

| where IPAddress !in ('10.0.0.8')
| where UserPrincipalName != 'user@microsoft.com'

Para implementar uma exceção mais detalhada quando aplicável e reduzir a probabilidade de falsos negativos, pode combinar atributos. A seguinte exceção aplica-se apenas se ambos os valores aparecerem no mesmo alerta:

| where IPAddress != '10.0.0.8' and UserPrincipalName != 'user@microsoft.com'

Excluir sub-redes

Excluir os intervalos de IP utilizados por uma organização requer exclusão de sub-rede. O exemplo seguinte mostra como excluir sub-redes.

O ipv4_lookup operador é um operador de melhoramento, não um operador de filtragem. A where isempty(network) linha realmente faz a filtragem, mantendo apenas eventos cujo endereço IP não corresponde a nenhuma entrada de subrede.

let subnets = datatable(network:string) [ "111.68.128.0/17", "5.8.0.0/19", ...];
let timeFrame = 1d;
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| evaluate ipv4_lookup(subnets, IPAddress, network, return_unmatched = true)
| where isempty(network)
...

Utilizar listas de observação para gerir exceções

Pode utilizar uma lista de observação para gerir a lista de exceções fora da própria regra. Quando aplicável, esta solução tem as seguintes vantagens:

• Um analista pode adicionar exceções sem editar a regra, o que melhor segue as melhores práticas do SOC.
• A mesma lista de observação pode aplicar-se a várias regras, ativando a gestão de exceções central.

A utilização de uma lista de observação é semelhante à utilização de uma exceção direta. Utilize _GetWatchlist('<watchlist name>') para chamar a lista de observação:

let timeFrame = 1d;
let logonDiff = 10m;
let allowlist = (_GetWatchlist('ipallowlist') | project IPAddress);
SigninLogs
| where TimeGenerated >= ago(timeFrame)
| where IPAddress !in (allowlist)
...

Também pode efetuar a filtragem de sub-rede através de uma lista de observação. Por exemplo, no código de exclusão de sub-redes anterior, pode substituir a definição de sub-redes datatable por uma lista de observação:

let subnets = _GetWatchlist('subnetallowlist');

Para mais informações sobre os operadores e funções Kusto usados nos exemplos de consultas de exceção, consulte a documentação Kusto:

• instrução let
• where operador
• projeto operador
• operador de tabela de dados
• avaliar operador do plug-in
• função ago()
• função isempty()
• ipv4_lookup plugin

Para obter mais informações sobre o KQL, veja Descrição geral do Linguagem de Pesquisa Kusto (KQL).

Outros recursos:

• Referência rápida do KQL
• recursos de aprendizagem da Kusto Query Language

Exemplo: Gerir exceções para a solução de Microsoft Sentinel para aplicações SAP®

A solução Microsoft Sentinel para aplicações SAP® fornece funções que pode utilizar para excluir utilizadores ou sistemas de acionar alertas.

• Excluir utilizadores. Utilize a função SAPUsersGetVIP para:

  • Etiquetas de chamada para os utilizadores que pretende excluir do acionamento de alertas. Marque os utilizadores na lista de observação SAP_User_Config, utilizando asteriscos (*) como carateres joker para marcar todos os utilizadores que sigam uma sintaxe de nomenclatura especificada.
  • Liste funções e/ou perfis SAP específicos que pretende excluir do acionamento de alertas.

• Excluir sistemas. Utilize funções que suportem o parâmetro SelectedSystemRoles para determinar que apenas tipos específicos de sistemas acionam alertas, incluindo apenas sistemas de Produção , apenas sistemas UAT ou ambos.

Para obter mais informações, veja Microsoft Sentinel solução para referência de dados de aplicações SAP®.

Conteúdos relacionados

Para mais informações, consulte:

• Utilizar dados UEBA para analisar falsos positivos
• Automatizar o processamento de incidentes em Microsoft Sentinel com regras de automatização
• Criar regras de análise personalizadas para detetar ameaças
• Utilizar Microsoft Sentinel listas de observação