Lidar com 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 as detecções personalizadas, você pode reduzir os custos de ingestão, obter detecções ilimitadas em tempo real e se beneficiar da 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 obter mais informações, leia As detecções personalizadas agora representam a experiência unificada para criar detecçõ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 ter alguns falsos positivos que precisam 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 usuários, geralmente principais de serviço (identidades automatizadas usadas por aplicativos 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 fecham incidentes criados imediata e automaticamente, registrando o motivo do fechamento e dos 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, o trabalho de manutenção pode disparar falsos positivos que fora do período de manutenção seriam incidentes verdadeiros.
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, exigem 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 a seguir descreve como adicionar uma regra de automação quando você 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 ajustar 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.
   • Você pode adicionar ao incidente fechado automaticamente um comentário 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. Esse prazo de expiração pode ser o que você deseja e reduz a chance de erros falso-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.

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

Você 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 os eventos cujo endereço IP não corresponde a nenhuma entrada de sub-rede.

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, veja a documentação Kusto:

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

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

Outros recursos:

• Referência rápida do KQL
• recursos de aprendizagem do Linguagem de Consulta Kusto

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 usuários na lista de monitoramento SAP_User_Config, usando asteriscos (*) como caracteres curinga para marcar todos os usuários com um padrão de nomenclatura especificado.
  • 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údo relacionado

Para saber mais, confira:

• 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