Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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.
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: não são apresentados eventos nos resultados da consulta
Quando o agrupamento de eventos está definido para acionar um alerta para cada evento, os resultados da consulta visualizados posteriormente podem parecer estar em falta ou diferentes do esperado. Por exemplo, pode ver os resultados de uma consulta mais tarde ao investigar um incidente relacionado e, como parte dessa investigação, decide voltar aos resultados anteriores desta consulta.
Os resultados são guardados automaticamente com os alertas. No entanto, se os resultados forem demasiado grandes, não serão guardados resultados e não serão apresentados dados ao ver novamente os resultados da consulta.
Nos casos em que existe um atraso na ingestão ou se a consulta não for determinista devido à agregação, o resultado do alerta poderá ser diferente do resultado apresentado ao executar a consulta manualmente.
Para resolver este problema, quando uma regra tem esta definição de agrupamento de eventos, Microsoft Sentinel adiciona o campo OriginalQuery aos resultados da consulta. Eis uma comparação do campo Consulta existente e do novo campo:
| Nome do campo | Contains | Executar a consulta neste campo resulta em... |
|---|---|---|
| Query | O registo comprimido do evento que gerou esta 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. |
Por outras palavras, o campo OriginalQuery comporta-se como o campo Consulta comporta-se na definição de agrupamento de eventos predefinida.
Problema: falha na execução de uma regra agendada ou aparece com DESATIVADO AUTOMATICamente adicionado ao nome
É uma ocorrência rara que uma regra de consulta agendada não seja executada, mas pode acontecer. Microsoft Sentinel classifica as falhas antecipadamente como transitórias ou permanentes, com base no tipo específico da falha e nas circunstâncias que o levaram.
Falha transitória
Uma falha transitória ocorre devido a uma circunstância temporária e que em breve regressa ao normal, altura em que a execução da regra é bem-sucedida. Alguns exemplos de falhas que Microsoft Sentinel classificam como transitórias são:
- Uma consulta de regra demora demasiado tempo a ser executada e excede o limite de tempo.
- Problemas de conectividade entre origens de dados e Log Analytics ou entre o Log Analytics e Microsoft Sentinel.
- Qualquer outra falha nova e desconhecida é considerada transitória.
Em caso de falha transitória, Microsoft Sentinel continuar a tentar executar a regra novamente após intervalos pré-determinadas e cada vez maiores, até um ponto. Depois disso, a regra será executada novamente apenas na hora agendada seguinte. Uma regra nunca é automaticamente desativada devido a uma falha transitória.
Falha permanente — regra autodisabled
Uma falha permanente ocorre devido a uma alteração nas condições que permitem a execução da regra, que sem intervenção humana não pode voltar aos seus antigos status. Seguem-se alguns exemplos de falhas classificadas como permanentes:
- A área de trabalho de destino (na qual a consulta de regra funcionava) foi eliminada.
- A tabela de destino (na qual a consulta de regra funcionava) foi eliminada.
- Microsoft Sentinel foi removido da área de trabalho de destino.
- Uma função utilizada pela consulta de regra já não é válida; foi modificado ou removido.
- As permissões para uma das origens de dados da consulta de regra foram alteradas (veja exemplo).
- Uma das origens de dados da consulta de regra foi eliminada.
Em caso de um número predeterminado de falhas permanentes consecutivas, do mesmo tipo e na mesma regra, Microsoft Sentinel deixa de tentar executar a regra e também executa os seguintes passos:
- Desativa a regra.
- Adiciona as palavras "AUTO DISABLED" ao início do nome da regra.
- Adiciona o motivo da falha (e a desativação) à descrição da regra.
Pode determinar facilmente a presença de quaisquer regras autodisabled, ao ordenar a lista de regras por nome. As regras de deteção automática encontram-se na parte superior ou próxima da parte superior da lista.
Os gestores do SOC devem certificar-se de que marcar a lista de regras regularmente para a presença de regras autodisabled.
Falha permanente devido à drenagem 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 nos seus sistemas. Quando Microsoft Sentinel identifica uma regra deste tipo, segue os mesmos três passos mencionados para os outros tipos de falhas permanentes— desativa a regra, anexa "AUTO DISABLED" ao nome da regra e adiciona o motivo da falha à descrição.
Para reativar a regra, tem de resolver os problemas na consulta que fazem com que utilize demasiados recursos. Para saber mais, confira:
- Melhores práticas de consulta – documentação do Kusto
- Otimizar as consultas de registo no Monitor do Azure
- recursos de aprendizagem do Linguagem de Consulta Kusto
Falha permanente devido à perda de acesso entre subscrições/inquilinos
Um exemplo específico de quando pode ocorrer uma falha permanente devido a uma alteração de permissões numa origem de dados (veja a lista) diz respeito ao caso de um Fornecedor de Soluções de Segurança da Microsoft (MSSP) ou qualquer outro cenário em que as regras de análise consultam entre subscrições ou inquilinos.
Quando cria uma regra de análise, é aplicado um token de permissões de acesso à regra e guardado juntamente com a mesma. Este token garante que a regra pode aceder à área de trabalho que contém as tabelas referenciadas pela consulta da regra e que este acesso é mantido mesmo que o criador da regra perca o acesso a essa área de trabalho.
No entanto, existe uma exceção: quando é criada uma regra para aceder a áreas de trabalho noutras subscrições ou inquilinos, como o que acontece no caso de um MSSP, Microsoft Sentinel toma medidas de segurança adicionais para impedir o acesso não autorizado aos dados do cliente. Estes tipos de regras têm as credenciais do utilizador que criou a regra aplicada, em vez de um token de acesso independente. Quando o utilizador já não tem acesso ao outro inquilino, a regra deixa de funcionar.
Se operar Microsoft Sentinel num cenário entre subscrições ou entre inquilinos e se um dos seus analistas ou engenheiros perder o acesso a uma área de trabalho específica, quaisquer regras criadas por esse utilizador deixarão de funcionar. Receberá uma mensagem de monitorização do estado de funcionamento relativamente a "acesso insuficiente ao recurso" e a regra será automaticamente de acordo com o procedimento descrito anteriormente.
Próximas etapas
Para saber mais, confira:
- Tutorial: Investigar incidentes com Microsoft Sentinel
- Navegar e investigar incidentes no Microsoft Sentinel – Pré-visualização
- Classificar e analisar dados com entidades no Microsoft Sentinel
- Tutorial: Utilizar manuais de procedimentos com regras de automatização no Microsoft Sentinel
Além disso, saiba a partir de um exemplo de utilização de regras de análise personalizadas ao monitorizar o Zoom com um conector personalizado.