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 as deteções personalizadas, pode reduzir os custos de ingestão, obter deteções ilimitadas em tempo real e beneficiar da integração totalmente integrada com Defender XDR dados, funções e ações de remediação com o mapeamento automático de entidades. Para obter mais informações, leia este blogue.

Microsoft Sentinel regras de análise notificam-no quando algo suspeito ocorre na sua rede. Nenhuma regra de análise é perfeita e é obrigado a obter alguns falsos positivos que precisam 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 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:

• As atividades normais de determinados utilizadores, normalmente principais de serviço, 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 imediatamente e automaticamente os incidentes criados, registando o motivo do encerramento 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 acionar falsos positivos que fora do período de tempo de manutenção seriam verdadeiros incidentes.
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, os engenheiros do Centro de Operações de Segurança (SOC) exigem a implementação. 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)

Este procedimento descreve como adicionar uma regra de automatização quando vê um incidente 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 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.
   • Pode adicionar um comentário ao incidente fechado automaticamente que explica 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 ao modificar regras de análise

Outra opção para implementar exceções é modificar a consulta da regra 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 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 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 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. Na where isempty(network) verdade, a linha faz a filtragem ao inspecionar 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)
...

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');

Veja mais informações sobre os seguintes itens utilizados nos exemplos anteriores, na documentação do Kusto:

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

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. Identifique os utilizadores na lista de observação SAP_User_Config , utilizando asteriscos (*) como carateres universais para etiquetar todos os utilizadores com 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ú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