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 agendadas 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 em um momento posterior 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, você decide voltar aos resultados anteriores dessa consulta.
Os resultados são salvos 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 de ingestão ou a consulta não é determinística devido à agregação, o resultado do alerta pode ser diferente do resultado mostrado executando 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 do campo Consulta existente e do novo campo:
| Nome do campo | Contém | Executar 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 quilobytes. |
| OriginalQuery | A consulta original, conforme escrito na regra de análise. | O evento mais recente no período em que a consulta é executada, que se ajusta aos parâmetros definidos pela consulta. |
Em outras palavras, o campo OriginalQuery se comporta como se o campo Consulta se comporta na configuração de agrupamento de eventos padrão.
Problema: uma regra agendada não pôde ser executada ou aparece com DESABILITADO automaticamente adicionado ao nome
É uma rara ocorrência de falha na execução de uma regra de consulta agendada, mas isso pode acontecer. O Microsoft Sentinel classifica as falhas como transitórias ou permanentes antecipadamente, com base no tipo específico da falha e nas circunstâncias que levaram a ela.
Falha temporária
Uma falha transitória ocorre devido a uma circunstância temporária e que logo retorna 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 atinge o tempo limite.
- Problemas de conectividade entre fontes de dados e Log Analytics, ou entre 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 os intervalos predeterminados e cada vez maiores, até um ponto. Depois disso, a regra será executada novamente apenas no próximo horário agendado. Uma regra nunca é desabilitada automaticamente devido a uma falha transitória.
Falha permanente – regra desabilitada automaticamente
Uma falha permanente ocorre devido a uma mudança nas condições que permitem a execução da regra, que sem intervenção humana não pode retornar ao seu status anterior. Veja a seguir alguns exemplos de falhas que são classificadas como permanentes:
- O workspace 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 workspace 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 exemplo).
- Uma das fontes de dados da consulta de regras foi excluída.
No caso de um número predeterminado de falhas permanentes consecutivas, do mesmo tipo e da mesma regra, o Microsoft Sentinel interrompe a tentativa de executar a regra e também executa as seguintes etapas:
- Desabilita a regra.
- Adiciona as palavras "desabilitadas automaticamente" ao início do nome da regra.
- Adiciona o motivo da falha (e a desabilitação) à descrição da regra.
Você pode determinar facilmente a presença de qualquer regra desabilitada automaticamente, classificando a lista de regras por nome. As regras desabilitadas automáticas estão na parte superior ou próxima da lista.
Os gerentes do SOC devem verificar a lista de regras regularmente quanto à presença de regras desabilitadas automaticamente.
Falha permanente devido ao esvaziamento de recursos
Outro tipo de falha permanente ocorre devido a uma consulta criada 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 essa regra, ele executa as mesmas três etapas mencionadas para os outros tipos de falhas permanentes: desabilita a regra, anexa "AUTO DISABLED" ao nome da regra e adiciona o motivo da falha à descrição.
Para reabilitar a regra, você deve resolver os problemas na consulta que fazem com que ela use muitos recursos. Consulte os seguintes artigos para obter as práticas recomendadas para otimizar suas consultas Kusto:
Consulte também os Recursos úteis para trabalhar com a Linguagem de Consulta Kusto no Microsoft Sentinel
Falha permanente devido à perda de acesso entre assinaturas/locatários
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 MSSP (Provedor de Soluções de Segurança da Microsoft) ou a qualquer outro cenário em que as regras de análise consultam entre 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 workspace que contém as tabelas referenciadas pela consulta da regra e que esse acesso seja mantido mesmo se o criador da regra perder o acesso a esse workspace.
No entanto, há uma exceção: quando uma regra é criada para acessar workspaces 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 entre assinaturas ou entre locatários e se um de seus analistas ou engenheiros perder o acesso a um determinado workspace, 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á desabilitada automaticamente de acordo com o procedimento descrito anteriormente.
Próximas etapas
Para obter mais informações, consulte:
- Tutorial: investigar incidentes com o Microsoft Sentinel
- Navegar e investigar incidentes no Microsoft Sentinel: versão prévia
- Classificar e analisar dados usando entidades no Microsoft Sentinel
- Tutorial: usar guias estratégicos com regras de automação no Microsoft Sentinel
Além disso, veja um exemplo de como usar regras de análise personalizadas ao monitorar o Zoom com um conector personalizado.