Regras de análise agendada do Microsoft Sentinel

• Aplica-se a:

  Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

De longe, o tipo mais comum de regra de análise, as regras Agendadas, é baseado em consultas Kusto que são configuradas para serem executadas em intervalos regulares e examinam dados brutos de um período de "lookback" definido. As consultas podem executar operações estatísticas complexas em seus dados de destino, revelando linhas de base e exceções em grupos de eventos. Se o número de resultados capturados pela consulta ultrapassar o limite configurado na regra, a regra produzirá um alerta.

Este artigo ajuda você a entender como as regras de análise agendada são criadas e apresenta todas as opções de configuração e os respectivos significados. As informações contidas neste artigo são úteis em dois cenários:

• Criar uma regra de análise com base em um modelo: use a lógica de consulta e as configurações de agendamento e retrospectiva, conforme definido no modelo, ou personalize-as para criar regras.

• Criar uma regra de análise do zero: crie sua consulta e regra do zero. Para fazer isso de maneira eficaz, você deve conhecer amplamente os conceitos de ciência de dados e da Linguagem de Consulta Kusto.

Importante

O Microsoft Sentinel agora está disponível em geral na plataforma de operações de segurança unificada da Microsoft no portal do Microsoft Defender. Para saber mais, confira Microsoft Sentinel no portal do Microsoft Defender.

Modelos de regra de análise

As consultas em modelos de regra agendada foram escritas por especialistas em segurança e ciência de dados, da Microsoft ou do fornecedor da solução que fornece o modelo.

Use um modelo de regra de análise selecionando um nome de modelo na lista de modelos e criando uma regra com base nele.

Cada modelo tem uma lista de fontes de dados necessárias. Quando você abre o modelo, as fontes de dados são verificadas automaticamente quanto à disponibilidade. A disponibilidade significa que a fonte de dados está conectada e que os dados estão sendo ingeridos regularmente por meio dela. Se qualquer uma das fontes de dados necessárias não estiver disponível, você não poderá criar a regra e talvez também veja uma mensagem de erro referente a isso.

Quando você cria uma regra baseada em um modelo, o assistente de criação de regra é aberto com base no modelo selecionado. Todos os detalhes são preenchidos automaticamente e você pode personalizar a lógica e outras configurações de regra para atender melhor às suas necessidades específicas. Você pode repetir esse processo para criar mais regras com base no modelo. Quando você chega ao final do assistente de criação de regra, suas personalizações são validadas e a regra é criada. As novas regras aparecem na guia Regras ativas da página Análise. Da mesma forma, na guia Modelos de regra, o modelo do qual você criou a regra agora é exibido com a marca In use.

Os modelos de regra de análise são constantemente mantidos pelos respectivos autores, seja para corrigir bugs ou para refinar a consulta. Quando um modelo recebe uma atualização, todas as regras baseadas nesse modelo são exibidas com a marca Update e você tem a chance de modificar essas regras para incluir as alterações feitas no modelo. Você também pode reverter as alterações feitas em uma regra de volta para a versão original baseada em modelo. Para obter mais informações, confira Gerenciar versões de modelo para suas regras de análise agendada no Microsoft Sentinel.

Depois de se familiarizar com as opções de configuração contidas neste artigo, confira Criar regras de análise agendada com base em modelos.

O restante deste artigo explica todas as possibilidades para personalizar a configuração das regras.

Configuração da regra de análise

Esta seção explica as principais considerações que você precisa levar em conta antes de começar a configurar suas regras.

Nome da regra de análise e detalhes

A primeira página do assistente de regra de análise contém as informações básicas da regra.

Nome: o nome da regra que aparece na lista de regras e em qualquer filtro baseado em regra. O nome precisa ser exclusivo no workspace.

Descrição: uma descrição de texto livre da finalidade da regra.

ID: o GUID da regra como um recurso do Azure, usado em solicitações e respostas de API, entre outras coisas. Esse GUID é atribuído somente quando a regra é criada, portanto, ele só é exibido quando você edita uma regra existente. Como é um campo somente leitura, ele é exibido de modo esmaecido e não pode ser alterado. Quando uma regra é criada, seja com base em um modelo ou do zero, ele ainda não existe.

Gravidade: uma classificação para dar aos alertas produzidos por essa regra. A gravidade de uma atividade é um cálculo do impacto potencial negativo da ocorrência da atividade.

Severidade	Descrição
Informativo	Nenhum impacto em seu sistema, mas as informações podem ser indicativas de etapas futuras planejadas por um ator de ameaça.
Baixa	O impacto imediato seria mínimo. Um ator de ameaça provavelmente precisaria realizar várias etapas antes de obter um impacto em um ambiente.
Médio	O ator de ameaça pode ter algum impacto sobre o ambiente com essa atividade, mas seria limitado no escopo ou exigiria atividade adicional.
Alto	A atividade identificada fornece ao ator de ameaças amplo acesso para realizar ações no ambiente ou é disparada pelo impacto no ambiente.

Os padrões de nível de gravidade não são uma garantia do nível de impacto atual ou ambiental. Personalize os detalhes do alerta para personalizar a gravidade, as táticas e outras propriedades de uma determinada instância de um alerta com os valores de quaisquer campos relevantes de uma saída de consulta.

As definições de severidade para modelos de regra de análise do Microsoft Sentinel são relevantes apenas para alertas criados por regras de análise. Para alertas ingeridos de outros serviços, a gravidade é definida pelo serviço de segurança de origem.

MITRE ATT&CK: uma especificação das táticas e técnicas de ataque representadas pelas atividades capturadas por essa regra. Elas se baseiam nas táticas e nas técnicas da estrutura MITRE ATT&CK®.

As táticas e técnicas do MITRE ATT&CK definidas aqui na regra se aplicam a quaisquer alertas gerados pela regra. Também se aplicam aos incidentes criados com base nesses alertas.

Para obter mais informações sobre como maximizar sua cobertura do cenário de ameaças do MITRE ATT&CK, confira Noções básicas sobre a cobertura de segurança da estrutura MITRE ATT&CK®.

Status: quando você cria a regra, o Status dela fica Habilitado por padrão, o que significa que ela é executada imediatamente depois que você terminar de criá-la. Se você não quiser que ela seja executada imediatamente, terá duas opções:

• Selecione desabilitado, e a regra é criada sem ser executada. Quando você quiser que a regra seja executada, localize-a na guia Regras ativas e habilite-a.
• Agende a regra para que ela seja executada pela primeira vez em uma data e hora específicas. Atualmente, esse método está em VERSÃO PRÉVIA. Confira Agendamento de consulta mais adiante neste artigo.

Consulta de regra

Essa é a essência da regra: você decide quais informações estarão nos alertas criados por essa regra e como elas serão organizadas. Essa configuração tem efeitos de acompanhamento sobre a aparência dos incidentes resultantes e do nível de dificuldade de investigação, correção e resolução. É importante dar aos alertas o máximo de informações possível e torná-las facilmente acessíveis.

Exiba ou insira a consulta Kusto que analisa os dados brutos do log. Se você estiver criando uma regra do zero, será uma boa ideia planejar e projetar a consulta antes de abrir esse assistente. Crie e teste as consultas na página Logs.

Tudo o que você digitar na janela de consulta de regra é validado instantaneamente, para que você descubra imediatamente se cometeu algum erro.

Melhores práticas de consultas de regra de análise

• Recomendamos que você use um Analisador ASIM (Modelo de Informação de Segurança Avançada) como fonte de consulta, em vez de usar uma tabela nativa. Isso garantirá que a consulta dê suporte a qualquer fonte de dados relevante atual ou futura ou família de fontes de dados, em vez de depender de apenas uma fonte de dados.

• O comprimento da consulta deve ter entre 1 e 10.000 caracteres e não pode conter "search *" ou "union *". Você pode usar funções definidas pelo usuário para superar a limitação do comprimento da consulta, pois uma única função pode substituir dezenas de linhas de código.

• Não há suportepara o uso de funções ADX para criar consultas do Azure Data Explorer dentro da janela de consulta do Log Analytics.

• Ao usar a função bag_unpackem uma consulta, se você projetar as colunas como campos usando "project field1" e a coluna não existir, a consulta falhará. Para evitar que isso aconteça, você deve projetar a coluna da seguinte maneira:

  project field1 = column_ifexists("field1","")

Para obter mais ajuda na criação de consultas Kusto, consulte Linguagem de Consulta Kusto no Microsoft Sentinel e Melhores práticas para consultas em Linguagem de Consulta Kusto.

Aprimoramento de alertas

Se você quiser que os alertas exibam as descobertas para que elas possam estar imediatamente visíveis nos incidentes e serem acompanhadas e investigadas de acordo, use a configuração de aprimoramento de alertas para exibir todas as informações importantes neles.

Esse aprimoramento de alertas traz o benefício adicional de apresentar as descobertas de maneira facilmente visível e acessível.

Há três tipos de aprimoramentos de alertas que você pode configurar:

• Mapeamento de entidade
• Detalhes personalizados
• Detalhes do alerta (também conhecidos como conteúdo dinâmico)

Mapeamento de entidade

As entidades são os jogadores dos dois lados de qualquer história de ataque. Identificar todas as entidades em um alerta é essencial para detectar e investigar as ameaças. Para garantir que o Microsoft Sentinel identifique as entidades em seus dados brutos, você precisa mapear os tipos de entidade reconhecidos pelo Microsoft Sentinel em campos nos resultados da consulta. Esse mapeamento integra as entidades identificadas ao campo Entidades no esquema de alerta.

Para saber mais sobre o mapeamento de entidades e obter instruções completas, confira Mapear campos de dados para entidades no Microsoft Sentinel.

Detalhes personalizados

Por padrão, somente metadados e entidades de alerta são visíveis em incidentes sem detalhar os eventos brutos nos resultados da consulta. Para dar a outros campos da consulta a visibilidade imediata dos seus alertas e incidentes, defina-os como detalhes personalizados. O Microsoft Sentinel integra esses detalhes personalizados ao campo ExtendedProperties em seus alertas, fazendo com que eles sejam exibidos antecipadamente nos alertas e em quaisquer incidentes criados com base nesses alertas.

Para saber mais sobre como exibir detalhes personalizados e obter instruções completas, confira Exibir detalhes de eventos personalizados em alertas do Microsoft Sentinel.

Detalhes do alerta

Essa configuração permite personalizar propriedades de alerta não padrão de acordo com o conteúdo de vários campos em cada alerta individual. Essas personalizações são integradas ao campo ExtendedProperties em seus alertas. Por exemplo, você pode personalizar a descrição ou o nome do alerta para incluir um nome de usuário ou endereço IP apresentado no alerta.

Para saber mais sobre como personalizar os detalhes de alertas e obter instruções completas, confira Personalizar detalhes de alertas do Microsoft Sentinel.

Observação

Na plataforma de operações de segurança unificada, o mecanismo de correlação do Defender XDR é responsável apenas por nomear os incidentes. Portanto, todos os nomes de alertas personalizados podem ser substituídos quando incidentes são criados com base nesses alertas.

Agendamento de consulta

Os parâmetros a seguir determinam a frequência com que a regra agendada será executada e qual período ela analisará sempre que for executada.

Configuração	Comportamento
Executar consulta a cada	Controla o intervalo de consulta: com que frequência a consulta é executada.
Pesquisar nos dados das últimas	Determina o período de pesquisa: o período de tempo coberto pela consulta.

• O intervalo permitido para ambos os parâmetros é de 5 minutos a 14 dias.

• O intervalo de consulta deve ser menor ou igual ao período de pesquisa. Se for menor, os períodos de consulta vão se sobrepor e isso pode causar duplicação de resultados. No entanto, a validação da regra não permitirá que você defina um intervalo maior do que o período de pesquisa, pois isso resultaria em lacunas na cobertura.

A configuração Iniciar a execução, já em VERSÃO PRÉVIA, permite que você crie uma regra com o status Habilitado, mas atrase a primeira execução até uma data e hora predeterminadas. Essa configuração é útil se você deseja cronometrar a execução das regras de acordo com o período em que os dados devem ser ingeridos da origem ou quando os analistas do SOC iniciam o dia de trabalho.

Configuração	Comportamento
Automaticamente	A regra será executada pela primeira vez imediatamente após ser criada e, depois disso, no intervalo definido na configuração Executar consulta a cada.
Em um horário específico (versão prévia)	Defina uma data e hora para a primeira execução da regra, após a qual ela será executada no intervalo definido na configuração Executar consulta a cada.

• A hora de início da execução deve estar entre 10 minutos e 30 dias após o tempo de criação (ou habilitação) da regra.

• A linha de texto na configuração Iniciar execução (com o ícone de informações à esquerda) resume as configurações atuais de agendamento e de retorno de consulta.

  

Observação

Atraso de ingestão

Considerando a latência que pode ocorrer entre a geração de um evento na origem e sua ingestão no Microsoft Sentinel, e para garantir a cobertura completa sem a duplicação de dados, o Microsoft Sentinel executa regras de análise agendadas em um atraso de cinco minutos em relação ao horário agendado.

Para saber mais informações, confira Tratar atraso de ingestão em regras de análise agendada.

Limite de alerta

Muitos tipos de eventos de segurança são normais ou até mesmo esperados em números pequenos, mas são um sinal de uma ameaça em números maiores. Diferentes escalas de números grandes podem significar diferentes tipos de ameaças. Por exemplo, duas ou três tentativas de entrada com falha no espaço de um minuto são um sinal de um usuário que não se lembra de uma senha, mas cinquenta em um minuto pode ser um sinal de um ataque humano, e mil provavelmente é um ataque automatizado.

Dependendo do tipo de atividade que a regra está tentando detectar, você pode definir um número mínimo de eventos (resultados da consulta) necessários para disparar um alerta. O limite se aplica separadamente a cada vez que a regra é executada, não coletivamente.

O limite também pode ser definido como um número máximo de resultados ou um número exato.

Agrupamento de eventos

Há duas maneiras de lidar com o agrupamento de eventos em alertas:

• Agrupar todos os eventos em um só alerta: esse é o padrão. A regra gera um só alerta toda vez que ela é executada, desde que a consulta retorne mais resultados do que o limite de alerta explicado na seção anterior. Esse único alerta resume todos os eventos retornados nos resultados da consulta.

• Disparar um alerta para cada evento: a regra gera um alerta exclusivo para cada evento (resultado) retornado pela consulta. Esse modo é útil se você deseja que os eventos sejam exibidos individualmente ou se deseja agrupá-los por determinados parâmetros: por usuário, nome do host ou outro. Você pode definir esses parâmetros na consulta. |

As regras de análise podem gerar até 150 alertas. Se Agrupamento de eventos estiver definido como Disparar um alerta para cada evento e a consulta da regra retornar mais de 150 eventos, cada um dos primeiros 149 eventos gerará um alerta exclusivo (dos 149 alertas) e o alerta 150º resumirá todo o conjunto de eventos retornados. Em outras palavras, o alerta 150º é o que teria sido gerado se a opção Agrupamento de evento estivesse definido como Agrupar todos os eventos em um único alerta.

A configuração Disparar um alerta para cada evento pode causar um problema em que os resultados da consulta parecem estar ausentes ou são diferentes do esperado. Para obter mais informações sobre esse cenário, confira Solução de problemas de regras de análise do Microsoft Sentinel | Problema: nenhum evento é exibido nos resultados da consulta.

Supressão

Se você quiser que essa regra pare de funcionar por um período após gerar um alerta, mude a configuração Parar de executar a consulta depois que o alerta for gerado para Ativado. Em seguida, defina Parar de executar a consulta por com o tempo durante o qual a consulta deve parar de ser executada, até 24 horas.

Simulação de resultados

O assistente de regra de análise permite que você teste a eficácia dela executando-a no conjunto de dados atual. Quando você executa o teste, a janela Simulação dos resultados mostra um grafo dos resultados que a consulta teria gerado nas últimas 50 vezes que teria sido executada, de acordo com o agendamento definido no momento. Se você modificar a consulta, poderá executar o teste novamente para atualizar o grafo. O grafo mostra o número de resultados no período definido, que é determinado pelo agendamento de consulta que você definiu.

Esta é a aparência da simulação de resultados para a consulta na captura de tela acima. O lado esquerdo é a exibição padrão e o lado direito é o que você vê quando passa o mouse sobre um ponto no tempo no grafo.

Se você observar que a consulta dispararia um excesso de alertas ou muitos alertas frequentes, teste outras configurações de agendamento e limite e execute a simulação novamente.

Configurações de incidentes

Escolha se o Microsoft Sentinel transformará os alertas em incidentes acionáveis.

A criação de incidentes é habilitada por padrão. O Microsoft Sentinel cria um só incidente separado de cada alerta gerado pela regra.

Se você não quiser que essa regra resulte na criação de quaisquer incidentes (por exemplo, se essa regra for apenas para coletar informações para análise subsequente), defina isso como desabilitado.

Importante

Se você integrou o Microsoft Sentinel à plataforma de operações de segurança unificada, o Microsoft Defender XDR é responsável pela criação de incidentes. No entanto, se você quiser que o Defender XDR crie incidentes para esse alerta, deixe essa configuração Habilitada. O Defender XDR usa a instrução definida aqui.

Isso não deve ser confundido com o tipo de regra de análise Segurança da Microsoft que cria incidentes para os alertas gerados nos serviços do Microsoft Defender. Essas regras são desabilitadas automaticamente quando você integra o Microsoft Sentinel à plataforma de operações de segurança unificada.

Se você quiser que um único incidente seja criado a partir de um grupo de alertas, em vez de um para cada alerta, consulte a próxima seção.

Agrupamento de alertas

Escolha se os alertas serão agrupados em incidentes. Por padrão, o Microsoft Sentinel cria um incidente para cada alerta gerado. Você tem a opção de agrupar vários alertas em um só incidente.

O incidente só é criado após a geração de todos os alertas. Todos os alertas são adicionados ao incidente imediatamente após a criação.

Até 150 alertas podem ser agrupados em um único incidente. Se mais de 150 alertas forem gerados por uma regra que os agrupa em um só incidente, um novo incidente será gerado com os mesmos detalhes de incidente que o original e os alertas em excesso serão agrupados no novo incidente.

Para agrupar os alertas, defina a configuração de agrupamento de alertas como Habilitado.

Há algumas opções a serem consideradas ao agrupar alertas:

• Período: por padrão, os alertas criados até 5 horas após o primeiro alerta em um incidente são adicionados ao mesmo incidente. Após 5 horas, outro incidente é criado. Você pode alterar esse período para qualquer tempo entre 5 minutos e 7 dias.

• Critérios de agrupamento: escolha como determinar quais alertas serão incluídos no grupo. A seguinte tabela mostra as escolhas possíveis:

  Opção	Descrição
  Agrupar alertas em um único incidente se todas as entidades corresponderem	Os alertas são agrupados se compartilharem valores idênticos para cada uma das entidades mapeadas definidas anteriormente. Esta é a configuração recomendável.
  Agrupar todos os alertas disparados por essa regra em um único incidente	Todos os alertas gerados por essa regra são agrupados em conjunto mesmo que não compartilhem valores idênticos.
  Agrupar alertas em um único incidente se as entidades e os detalhes selecionados corresponderem	Os alertas serão agrupados se compartilharem valores idênticos para todas as entidades mapeadas, detalhes de alertas e detalhes personalizados que você selecionou nessa configuração. Escolha as entidades e os detalhes nas listas suspensas exibidas quando você seleciona essa opção. Você talvez queira usar essa configuração se, por exemplo, desejar criar incidentes separados com base nos endereços IP de origem ou de destino, ou se desejar agrupar alertas que correspondam a uma entidade e severidade específicas. Observação: ao selecionar essa opção, você precisa ter, pelo menos, uma entidade ou detalhe selecionado para a regra. Caso contrário, a validação da regra falhará e a regra não será criada.

• Como reabrir incidentes: se um incidente tiver sido resolvido e fechado e posteriormente for gerado outro alerta que deve pertencer a esse incidente, defina essa configuração como Habilitado se quiser que o incidente fechado seja reaberto e deixe-a como Desabilitado se desejar que o alerta crie um incidente.

  A opção de reabrir incidentes fechados não está disponível se você integrou o Microsoft Sentinel à plataforma de operações de segurança unificada.

Resposta automatizada

O Microsoft Sentinel permite que você defina respostas automatizadas para ocorrer quando:

• Um alerta é gerado por essa regra de análise.
• Um incidente é criado com base em alertas gerados por essa regra de análise.
• Um incidente é atualizado com alertas gerados por essa regra de análise.

Para saber tudo sobre os diferentes tipos de respostas que podem ser criadas e automatizadas, confira Automatizar a resposta a ameaças no Microsoft Sentinel com regras de automação.

No título Regras de automação, o assistente exibe uma lista das regras de automação já definidas em todo o workspace, cujas condições se aplicam a essa regra de análise. Você pode editar qualquer uma dessas regras existentes ou criar uma regra de automação que se aplique apenas a essa regra de análise.

Use as regras de automação para realizar triagem básica, atribuição, fluxo de trabalho e fechamento de incidentes.

Automatize tarefas mais complexas e invoque respostas de sistemas remotos para corrigir ameaças, ao chamar guias estratégicos dessas regras de automação. Você pode invocar guias estratégicos para incidentes, bem como para alertas individuais.

• Para obter mais informações e instruções sobre a criação de guias estratégicos e as regras de automação, confira Automatizar respostas a ameaças.

• Para obter mais informações sobre quando usar o gatilho criado pelo incidente, o gatilho atualizado pelo incidente ou o gatilho criado pelo alerta, confira a seção Usar gatilhos e ações nos guias estratégicos do Microsoft Sentinel.

• No título Automação de alertas (clássico), talvez você veja uma lista de guias estratégicos configurados para serem executados automaticamente usando um método antigo que será preterido em março de 2026. Não é possível adicionar nada a essa lista. Todos os guias estratégicos listados aqui devem ter regras de automação criadas, com base no gatilho criado pelo alerta, para invocar os guias estratégicos. Depois de fazer isso, selecione as reticências no final da linha do guia estratégico listado aqui e selecione Remover. Confira Migrar seus guias estratégicos de gatilho de alerta do Microsoft Sentinel para regras de automação para ver instruções completas.

Próximas etapas

Ao usar as regras de análise do Microsoft Sentinel para detectar ameaças em seu ambiente, habilite todas as regras associadas às fontes de dados conectadas para garantir a cobertura de segurança total para seu ambiente.

Para automatizar a habilitação de regras, efetue push das regras para o Microsoft Sentinel por meio da API e do PowerShell, embora isso exija um esforço adicional. Ao usar a API ou o PowerShell, você precisa primeiro exportar as regras ao JSON para depois habilitar as regras. A API ou o PowerShell pode ser útil ao habilitar regras em várias instâncias do Microsoft Sentinel com configurações idênticas em cada instância.

Para saber mais, veja:

• Exportar e importar regras de análise de/para modelos do ARM
• Solução de problemas de regras de análise no Microsoft Sentinel
• Navegar e investigar incidentes no Microsoft Sentinel
• 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.