Lidar com falsos positivos no Microsoft Sentinel

Observação

O Azure Sentinel agora é chamado de Microsoft Sentinel, e atualizaremos essas páginas nas próximas semanas. Saiba mais sobre os recentes aprimoramentos de segurança da Microsoft.

As regras de análise do Microsoft Sentinel notificam quando algo suspeito ocorre em sua rede. Nenhuma regra de análise é perfeita, e você está sujeito a ter que lidar com alguns falsos positivos. Este artigo descreve como lidar com falsos positivos usando automação ou modificando regras de análise agendadas.

Causas e prevenção de falsos positivos

Mesmo quando as regras de análise são criadas corretamente, costumam ocorrer falsos positivos provenientes de entidades específicas como usuários ou endereços IP que deveriam ser excluídos da regra.

Cenários comuns incluem:

  • 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 é detectada como mal-intencionada.
  • Uma regra que exclui endereços IP privados deveria também 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 de regras de análise agendadas permitem exceções mais detalhadas e permanentes.

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

Método Característica
Regras de automação
  • Aplicam-se a várias regras de análise.
  • Mantêm uma trilha de auditoria. As exceções impedem a criação de incidentes, mas os alertas ainda são registrados para fins de auditoria.
  • Geralmente são gerados por analistas.
  • Permitem a aplicação de exceções por um período 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
  • Permite expressões boolianas avançadas e exceções baseadas em sub-rede.
  • Permite que você use watchlists para centralizar o gerenciamento de exceções.
  • Normalmente, exige a implementação por engenheiros do Centro de operações de segurança (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 ao se deparar com um incidente de falso positivo.

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

  1. No Microsoft Sentinel, em Incidentes, selecione o incidente para o qual você deseja criar uma exceção.

  2. Selecione Criar regra de automação.

  3. Na barra lateral Criar regra de automação, você pode, opcionalmente, modificar o nome da nova regra para identificar a exceção, em vez de apenas o nome da regra de alerta.

  4. Em Condições, você pode adicionar mais Nomes de regras de análise às 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.

  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 para ajustar a exceção. Por exemplo, você pode alterar uma condição em um endereço IP e aplicá-la a uma sub-rede inteira.

    Screenshot showing how to create an automation rule for an incident in Microsoft Sentinel.

  6. Quando estiver contente com as condições, você poderá continuar definindo o que a regra faz:

    Screenshot showing how to finish creating and applying an automation rule in Microsoft Sentinel.

    • A regra já está configurada para fechar um incidente que atenda aos critérios de exceção.
    • Você pode manter como está o motivo de fechamento especificado ou 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 originou de atividade administrativa conhecida.
    • Por padrão, a regra é definida para expirar automaticamente após 24 horas. Esse prazo de expiração pode atender às suas necessidades. Ele reduz a probabilidade de erros de falsos negativos. Se você quiser uma exceção mais longa, defina a Expiração da regra para um momento posterior.
  7. Você poderá adicionar mais ações se desejar. Por exemplo, você pode adicionar uma marca ao incidente ou executar um guia estratégico para enviar um email ou uma notificação ou sincronizar com um sistema externo.

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

Dica

Também é possível criar uma regra de automação do zero, sem iniciar a partir de um incidente. Selecione Automação no menu de navegação à esquerda no Microsoft Sentinel e, em seguida, selecione Criar>Adicionar nova regra. Saiba mais sobre as 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, preferencialmente, quando for possível, usar uma referência a uma watchlist. Em seguida, você pode gerenciar a lista de exceções na watchlist.

Modificar a consulta

Para editar as regras de análise existentes, selecione Automação no menu de navegação à esquerda do Microsoft Sentinel. Selecione a regra que você deseja editar e, em seguida, selecione Editar no canto inferior direito para abrir o Assistente de regras de análise.

Para obter instruções detalhadas sobre como usar o Assistente de regras de análise para criar e editar regras de análise, consulte Criar regras de análise personalizadas para detectar 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>') próximo ao início da consulta de regra. Essa 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')
...

Esse tipo de exceção não é limitado a endereços IP. Você pode excluir usuários específicos usando o campo UserPrincipalName ou excluir aplicativos específicos usando o campo AppDisplayName.

Você também pode excluir vários atributos. Por exemplo, para excluir alertas do endereço IP 10.0.0.8 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 for o caso e reduzir a chance de falsos negativos, você pode combinar atributos. A exceção a seguir se aplicará 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-redes. O exemplo a seguir mostra como excluir sub-redes.

O operador ipv4_lookup é um operador de enriquecimento, não um operador de filtragem. De fato, a linha where isempty(network) faz a filtragem inspecionando os eventos que não mostram combinações.

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 watchlists para gerenciar exceções

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

  • Um analista pode adicionar exceções sem editar a regra, o que está mais alinhado às práticas recomendadas do SOC.
  • A mesma watchlist pode ser aplicada a várias regras, permitindo o gerenciamento central de exceções.

Usar uma watchlist é semelhante a usar uma exceção direta. Use _GetWatchlist('<watchlist name>') para chamar a watchlist:

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-redes usando uma watchlist. Por exemplo, no código de exclusão de sub-redes anterior, você pode substituir a definição de sub-redes datatable por uma watchlist:

let subnets = _GetWatchlist('subnetallowlist');

Próximas etapas

Para obter mais informações, consulte: