Lidar com falsos positivos no Microsoft Sentinel

Artigo
01/22/2024

As regras de análise do Microsoft Sentinel notificam-no quando algo suspeito ocorre na sua rede. Nenhuma regra de análise é perfeita, e você está fadado a obter alguns falsos positivos que precisam ser manipulados. Este artigo descreve como lidar com falsos positivos, usando automação ou modificando regras de análise agendada.

Causas e prevenção de falsos positivos

Mesmo em uma regra de análise criada corretamente, os falsos positivos geralmente provêm de entidades específicas, como usuários ou endereços IP, que devem ser excluídos da regra.

Cenários comuns incluem:

As atividades normais de certos usuários, geralmente entidades de serviço, mostram um padrão que parece suspeito.
A atividade intencional de verificação de segurança proveniente de endereços IP conhecidos é detetada como maliciosa.
Uma regra que exclui 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 automação criam exceções sem modificar as regras de análise.
As modificações programadas das regras de análise permitem exceções mais detalhadas e permanentes.

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

Método	Characteristic
Regras de automatização	Pode aplicar-se a várias regras de análise. Mantenha uma trilha de auditoria. Exceções fecham imediata e automaticamente os incidentes criados, registrando o motivo do encerramento e comentários. São muitas vezes gerados por analistas. Permitir a aplicação de exceções por um período limitado. Por exemplo, o trabalho de manutenção pode desencadear falsos positivos que, fora do período de manutenção, seriam verdadeiros incidentes.
Modificações nas regras do Google Analytics	Permitir expressões booleanas avançadas e exceções baseadas em sub-rede. Permita que você use listas de observação para centralizar o gerenciamento de exceções. Normalmente exigem implementação por engenheiros do Security Operations Center (SOC). São a solução mais flexível e completa de falsos positivos, mas são mais complexas.

Método

Characteristic

Regras de automatização

Pode aplicar-se a várias regras de análise.
Mantenha uma trilha de auditoria. Exceções fecham imediata e automaticamente os incidentes criados, registrando o motivo do encerramento e comentários.
São muitas vezes gerados por analistas.
Permitir a aplicação de exceções por um período limitado. Por exemplo, o trabalho de manutenção pode desencadear falsos positivos que, fora do período de manutenção, seriam verdadeiros incidentes.

Modificações nas regras do Google Analytics

Permitir expressões booleanas avançadas e exceções baseadas em sub-rede.
Permita que você use listas de observação para centralizar o gerenciamento de exceções.
Normalmente exigem implementação por engenheiros do Security Operations Center (SOC).
São a solução mais flexível e completa de falsos positivos, mas são mais complexas.

Adicionar exceções usando regras de automação

A maneira mais simples de adicionar uma exceção é adicionar uma regra de automação quando você vê um incidente falso positivo.

Para adicionar uma regra de automação para lidar com um falso positivo:

No Microsoft Sentinel, em Incidentes, selecione o incidente para o qual deseja criar uma exceção.
Selecione Criar regra de automação.
Na barra lateral Criar nova regra de automação, modifique opcionalmente o nome da nova regra para identificar a exceção, em vez de apenas o nome da regra de alerta.
Em Condições, opcionalmente, adicione mais nomesde regras do Google Analytics aos quais aplicar a exceção. Selecione a caixa suspensa que contém o nome da regra de análise e selecione mais regras de análise na lista.
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 para ajustar a exceção. Por exemplo, você pode alterar uma condição em um endereço IP para aplicar a uma sub-rede inteira.
Depois de estar satisfeito com as condições, você pode continuar a definir o que a regra faz:
- A regra já está configurada para fechar um incidente que atenda aos critérios de exceção.
- Você pode manter o motivo de fechamento especificado como está, ou pode alterá-lo se outro motivo for mais apropriado.
- Você pode adicionar um comentário ao incidente fechado automaticamente que explica a exceção. Por exemplo, você pode especificar que o incidente se originou de atividade administrativa conhecida.
- Por padrão, a regra é definida para expirar automaticamente após 24 horas. Essa expiração pode ser o que você deseja e reduz a chance de erros falsos negativos. Se você quiser uma exceção mais longa, defina a expiração da regra para um momento posterior.
Você pode adicionar mais ações, se desejar. Por exemplo, você pode adicionar uma tag ao incidente ou executar um playbook para enviar um e-mail ou uma notificação ou para sincronizar com um sistema externo.
Selecione Aplicar para ativar a exceção.

Gorjeta

Você também pode criar uma regra de automação do zero, sem começar de um incidente. Selecione Automação no menu de navegação esquerdo do Microsoft Sentinel e, em seguida, selecione Criar>nova regra. Saiba mais sobre regras de automação.

Adicionar exceções modificando regras de análise

Outra opção para implementar exceções é modificar a consulta de regra de análise. Você pode incluir exceções diretamente na regra ou, de preferência, quando possível, usar uma referência a uma lista de observação. Em seguida, você pode gerenciar a lista de exceções na lista de observação.

Modificar a consulta

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

Para obter instruções detalhadas sobre como usar o Assistente de regras do Google Analytics para criar e editar regras de análise, consulte Criar regras de análise personalizadas para detetar ameaças.

Para implementar uma exceção em um preâmbulo de regra típico, você 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 se limita aos endereços IP. Você pode excluir usuários específicos usando o UserPrincipalName campo ou excluir aplicativos específicos usando AppDisplayName.

Você também pode excluir vários atributos. Por exemplo, para excluir alertas do endereço 10.0.0.8 IP ou do usuário user@microsoft.com, use:

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

Para implementar uma exceção mais refinada quando aplicável e reduzir a chance de falsos negativos, você pode combinar atributos. A exceção a seguir se aplica somente se ambos os valores aparecerem no mesmo alerta:

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

Excluir sub-redes

A exclusão de intervalos de IP usados por uma organização requer a exclusão de sub-rede. O exemplo a seguir mostra como excluir sub-redes.

O ipv4_lookup operador é um operador de enriquecimento e não um operador de filtragem. A where isempty(network) linha realmente faz a filtragem, inspecionando os eventos que não mostram uma correspondência.

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)
...

Usar listas de observação para gerenciar exceções

Você pode usar uma lista de observação para gerenciar a lista de exceções fora da própria regra. Quando aplicável, esta solução apresenta as seguintes vantagens:

Um analista pode adicionar exceções sem editar a regra, que segue melhor as práticas recomendadas de SOC.
A mesma lista de observação pode ser aplicada a várias regras, permitindo o gerenciamento central de exceções.

Usar uma lista de observação é semelhante a usar uma exceção direta. Use _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)
...

Você também pode fazer a filtragem de sub-rede usando uma lista de observação. Por exemplo, no código de exclusão de sub-redes anterior, você pode substituir a definição de sub-redes por uma lista de datatable observação:

let subnets = _GetWatchlist('subnetallowlist');

Exemplo: gerenciar exceções para a solução Microsoft Sentinel para aplicativos SAP®

A solução Microsoft Sentinel para aplicativos SAP® fornece funções que você pode usar para excluir usuários ou sistemas do disparo de alertas.

Excluir usuários. Use a função SAPUsersGetVIP para:
- Chamar tags para usuários que você deseja excluir do disparo de alertas. Marque usuários na lista de observação SAP_User_Config, usando asteriscos (*) como curingas para marcar todos os usuários com uma sintaxe de nomenclatura especificada.
- Liste funções e/ou perfis específicos do SAP que você deseja excluir do acionamento de alertas.
Excluir sistemas. Use funções que suportam o parâmetro SelectedSystemRoles para determinar que apenas tipos específicos de sistemas disparam alertas, incluindo apenas sistemas de produção , somente sistemas UAT ou ambos.

Para obter mais informações, consulte Referência de dados da solução Microsoft Sentinel para aplicativos SAP®.

Próximos passos

Para obter mais informações, consulte: