Solução de problemas de regras de análise no Microsoft Sentinel

Este artigo explica como lidar com determinados problemas que podem surgir com a execução de regras de análise agendada no Microsoft Sentinel.

Problema: nenhum evento aparece nos resultados da consulta

Quando o agrupamento de eventos é definido para disparar um alerta para cada evento, os resultados da consulta exibidos posteriormente podem parecer ausentes ou diferentes do esperado. Por exemplo, você pode exibir os resultados de uma consulta posteriormente ao investigar um incidente relacionado e, como parte dessa investigação, decidir voltar para os resultados anteriores dessa consulta.

Os resultados são guardados automaticamente com os alertas. No entanto, se os resultados forem muito grandes, nenhum resultado será salvo e nenhum dado será exibido ao exibir os resultados da consulta novamente.

Nos casos em que há atraso na ingestão ou a consulta não é determinística devido à agregação, o resultado do alerta pode ser diferente do resultado mostrado ao executar a consulta manualmente.

Para resolver esse problema, quando uma regra tem essa configuração de agrupamento de eventos, o Microsoft Sentinel adiciona o campo OriginalQuery aos resultados da consulta. Aqui está uma comparação entre o campo Consulta existente e o novo campo:

Nome do campo	Contains	Executando a consulta neste campo resulta em...
Consulta	O registro compactado do evento que gerou essa instância do alerta.	O evento que gerou esta instância do alerta; limitado a 10 kilobytes.
OriginalQuery	A consulta original conforme escrito na regra de análise.	O evento mais recente no período de tempo em que a consulta é executada, que se ajusta aos parâmetros definidos pela consulta.

Em outras palavras, o campo OriginalQuery se comporta como o campo Consulta se comporta na configuração padrão de agrupamento de eventos.

Problema: uma regra agendada não foi executada ou é apresentada com DESATIVADA AUTOMATICAMENTE adicionado ao nome

É raro que uma regra de consulta agendada não seja executada, mas isso pode acontecer. O Microsoft Sentinel classifica as falhas iniciais como transitórias ou permanentes, com base no tipo específico da falha e nas circunstâncias que levaram a ela.

Falha transitória

Uma falha transitória ocorre devido a uma circunstância que é temporária e logo volta ao normal, momento em que a execução da regra é bem-sucedida. Alguns exemplos de falhas que o Microsoft Sentinel classifica como transitórias são:

• Uma consulta de regra leva muito tempo para ser executada e expira.
• Problemas de conectividade entre fontes de dados e o Log Analytics ou entre o Log Analytics e o Microsoft Sentinel.
• Qualquer outra falha nova e desconhecida é considerada transitória.

No caso de uma falha transitória, o Microsoft Sentinel continua tentando executar a regra novamente após intervalos pré-determinados e cada vez maiores, até certo ponto. Depois disso, a regra será executada novamente apenas no próximo horário agendado. Uma regra nunca é desativada automaticamente devido a uma falha transitória.

Falha permanente — regra desativada automaticamente

Uma falha permanente ocorre devido a uma mudança nas condições que permitem que a regra funcione, que sem intervenção humana não pode voltar ao seu status anterior. Seguem-se alguns exemplos de falhas classificadas como permanentes:

• O espaço de trabalho de destino (no qual a consulta de regra operava) foi excluído.
• A tabela de destino (na qual a consulta de regra operava) foi excluída.
• O Microsoft Sentinel foi removido do espaço de trabalho de destino.
• Uma função usada pela consulta de regra não é mais válida; foi modificado ou removido.
• As permissões para uma das fontes de dados da consulta de regra foram alteradas (veja o exemplo).
• Uma das fontes de dados da consulta de regra foi excluída.

No caso de um número predeterminado de falhas permanentes consecutivas, do mesmo tipo e na mesma regra, o Microsoft Sentinel para de tentar executar a regra e também executa as seguintes etapas:

1. Desativa a regra.
2. Adiciona as palavras "AUTO DISABLED" ao início do nome da regra.
3. Adiciona o motivo da falha (e da desativação) à descrição da regra.

Você pode determinar facilmente a presença de quaisquer regras desativadas automaticamente, classificando a lista de regras por nome. As regras de desativação automática estão no topo da lista ou perto dele.

Os gerentes de SOC devem verificar a lista de regras regularmente para a presença de regras desativadas automaticamente.

Falha permanente devido à drenagem de recursos

Outro tipo de falha permanente ocorre devido a uma consulta construída incorretamente que faz com que a regra consuma recursos de computação excessivos e corre o risco de ser um dreno de desempenho em seus sistemas. Quando o Microsoft Sentinel identifica tal regra, ele executa as mesmas três etapas mencionadas para os outros tipos de falhas permanentes: desabilita a regra, precede "AUTO DISABLED" ao nome da regra e adiciona o motivo da falha à descrição.

Para reativar a regra, você deve resolver os problemas na consulta que fazem com que ela use muitos recursos. Consulte os seguintes artigos para obter as melhores práticas para otimizar suas consultas Kusto:

• Práticas recomendadas de consulta - Azure Data Explorer
• Otimizar as consultas de pesquisa no Azure Monitor

Consulte também Recursos úteis para trabalhar com Kusto Query Language no Microsoft Sentinel para obter mais assistência.

Falha permanente devido à perda de acesso entre subscrições/inquilinos

Um exemplo específico de quando uma falha permanente pode ocorrer devido a uma alteração de permissões em uma fonte de dados (consulte a lista) diz respeito ao caso de um Microsoft Security Solution Provider (MSSP) — ou qualquer outro cenário em que as regras de análise consultem assinaturas ou locatários.

Quando você cria uma regra de análise, um token de permissões de acesso é aplicado à regra e salvo junto com ela. Esse token garante que a regra possa acessar o espaço de trabalho que contém as tabelas referenciadas pela consulta da regra e que esse acesso seja mantido mesmo que o criador da regra perca o acesso a esse espaço de trabalho.

No entanto, há uma exceção: quando uma regra é criada para acessar espaços de trabalho em outras assinaturas ou locatários, como o que acontece no caso de um MSSP, o Microsoft Sentinel toma medidas de segurança extras para impedir o acesso não autorizado aos dados do cliente. Esses tipos de regras têm as credenciais do usuário que criou a regra aplicada a elas, em vez de um token de acesso independente. Quando o usuário não tem mais acesso ao outro locatário, a regra para de funcionar.

Se você operar o Microsoft Sentinel em um cenário de assinatura cruzada ou locatário cruzado e se um de seus analistas ou engenheiros perder o acesso a um espaço de trabalho específico, todas as regras criadas por esse usuário deixarão de funcionar. Você receberá uma mensagem de monitoramento de integridade sobre "acesso insuficiente ao recurso" e a regra será desativada automaticamente de acordo com o procedimento descrito anteriormente.

Próximos passos

Para obter mais informações, consulte:

• Tutorial: Investigar incidentes com o Microsoft Sentinel
• Navegar e investigar incidentes no Microsoft Sentinel - Pré-visualização
• Classificar e analisar dados usando entidades no Microsoft Sentinel
• Tutorial: Usar playbooks com regras de automação no Microsoft Sentinel

Além disso, aprenda com um exemplo de uso de regras de análise personalizadas ao monitorar o Zoom com um conector personalizado.