Regras de análise agendadas no Microsoft Sentinel

De longe o tipo mais comum de regra de análise, as regras agendadas são baseadas em consultas Kusto configuradas para serem executadas em intervalos regulares e examinarem dados brutos de um período de "retrospetiva" definido. As consultas podem realizar operações estatísticas complexas em seus dados de destino, revelando linhas de base e valores atípicos 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 seus significados. As informações neste artigo são úteis em dois cenários:

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

• Crie uma regra de análise do zero: crie sua própria consulta e regra do zero. Para fazer isso de forma eficaz, você deve ter uma base completa em ciência de dados e linguagem de consulta Kusto.

Modelos de regras do Google Analytics

As consultas em modelos de regras agendadas 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, a disponibilidade das fontes de dados é verificada automaticamente. Disponibilidade significa que a fonte de dados está conectada e que os dados estão sendo ingeridos regularmente por meio dela. Se alguma das fontes de dados necessárias não estiver disponível, você não terá permissão para criar a regra e também poderá ver uma mensagem de erro nesse sentido.

Quando você cria uma regra a partir de um modelo, o assistente de criação de regras é 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 regras para melhor atender à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 regras, suas personalizações são validadas e a regra é criada. As novas regras aparecem na guia Regras ativas na página Análise . Da mesma forma, na guia Modelos de regra, o modelo a partir do qual você criou a regra agora é exibido com a In use tag .

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

Depois de se familiarizar com as opções de configuração neste artigo, consulte Criar regras de análise agendadas a partir de modelos.

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

Configuração da regra do Google Analytics

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

Nome e detalhes da regra de análise

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 tal como aparece na lista de regras e em quaisquer filtros baseados em regras. O nome deve ser exclusivo para o seu espaço de trabalho.

Descrição: descrição em 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 é exibido somente quando você está editando uma regra existente. Como é um campo somente leitura, ele é exibido como acinzentado e não pode ser alterado. Ele ainda não existe ao criar uma nova regra, seja a partir de um modelo ou do zero.

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

Os padrões de nível de severidade 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 gravidade para modelos de regras 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 esta regra. Estes são baseados nas táticas e técnicas do framework MITRE ATT&CK®.

As táticas e técnicas MITRE ATT&CK definidas aqui na regra aplicam-se a quaisquer alertas gerados pela regra. Aplicam-se igualmente a quaisquer incidentes criados a partir destes alertas.

Para obter mais informações sobre como maximizar sua cobertura do cenário de ameaças MITRE ATT&CK, consulte Compreender a cobertura de segurança pela estrutura MITRE ATT&CK®.

Status: Quando você cria a regra, seu Status é Habilitado por padrão, o que significa que ela é executada imediatamente após você terminar de criá-la. Se você não quiser que ele seja executado imediatamente, você tem duas opções:

• Selecione Desativado e a regra é criada sem ser executada. Quando quiser que a regra seja executada, encontre-a na guia Regras ativas e ative-a a partir daí.
• Agende a regra para ser executada pela primeira vez em uma data e hora específicas. Este método está atualmente em pré-visualização. Consulte Agendamento de consultas mais adiante neste artigo.

Consulta da regra

Esta é a essência da regra: você decide quais informações estão nos alertas criados por essa regra e como as informações são organizadas. Essa configuração tem efeitos de acompanhamento sobre a aparência dos incidentes resultantes e como eles são fáceis ou difíceis de investigar, remediar e resolver. É importante tornar seus alertas o mais ricos possível em informações e torná-las facilmente acessíveis.

Exiba ou insira a consulta Kusto que analisa os dados brutos de log. Se você estiver criando uma regra do zero, é uma boa ideia planejar e projetar sua consulta antes de abrir este assistente. Você pode criar e testar consultas na página Logs .

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

Práticas recomendadas para consultas de regras de análise

• Recomendamos que você use um analisador ASIM (Advanced Security Information Model) como fonte de consulta, em vez de usar uma tabela nativa. Isso garantirá que a consulta ofereça suporte a qualquer fonte de dados relevante atual ou futura ou família de fontes de dados, em vez de depender de uma única fonte de dados.

• O comprimento da consulta deve estar 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á suporte para o uso de funções ADX para criar consultas do Azure Data Explorer dentro da janela de consulta do Log Analytics.

• Ao usar a bag_unpack função em 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 forma:

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

Para obter mais ajuda na criação de consultas Kusto, consulte Kusto Query Language no Microsoft Sentinel e Práticas recomendadas para consultas Kusto Query Language.

Aprimoramento de alertas

Se você quiser que seus alertas apresentem suas descobertas para que possam ser imediatamente visíveis em incidentes e rastreados e investigados adequadamente, use a configuração de aprimoramento de alerta para exibir todas as informações importantes nos alertas.

Esta melhoria do alerta tem a vantagem adicional de apresentar os resultados de uma forma facilmente visível e acessível.

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

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

Mapeamento de entidades

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

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

Detalhes personalizados

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

Para saber mais sobre como revelar detalhes personalizados e obter instruções completas, consulte Detalhes de eventos personalizados do Surface em alertas no Microsoft Sentinel.

Detalhes do alerta

Essa configuração permite personalizar propriedades de alerta 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 o nome ou a descrição do alerta para incluir um nome de usuário ou endereço IP apresentado no alerta.

Para saber mais sobre como personalizar detalhes de alerta e obter instruções completas, consulte Personalizar detalhes de alerta no Microsoft Sentinel.

Agendamento de consultas

Os parâmetros a seguir determinam com que frequência sua regra agendada será executada e qual período de tempo ela examinará cada vez que for executada.

• 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 retrospetiva. Se for mais curto, os períodos de consulta irão sobrepor-se e isso pode causar alguma 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 retrospetiva, pois isso resultaria em lacunas em sua cobertura.

A configuração Iniciar execução , agora em VISUALIZAÇÃO, permite criar uma regra com status Habilitado, mas atrasar sua primeira execução até uma data e hora predeterminadas. Essa configuração é útil se você quiser cronometrar a execução de suas regras de acordo com quando se espera que os dados sejam ingeridos da fonte ou quando os analistas SOC começarem o dia de trabalho.

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

• A linha de texto sob a configuração Iniciar execução (com o ícone de informações à esquerda) resume as configurações atuais de agendamento e retrospetiva de consultas.

  

Limiar de alerta

Muitos tipos de eventos de segurança são normais ou mesmo esperados em pequenos números, mas são um sinal de uma ameaça em maior número. Escalas diferentes de grandes números podem significar diferentes tipos de ameaças. Por exemplo, duas ou três tentativas de início de sessão falhadas no espaço de um minuto é um sinal de um utilizador que não se lembra de uma palavra-passe, mas cinquenta num minuto pode ser um sinal de um ataque humano, e mil é provavelmente um ataque automatizado.

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

O limite também pode ser definido para 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:

• Agrupe todos os eventos em um único alerta: esse é o padrão. A regra gera um único alerta sempre que é executada, desde que a consulta retorne mais resultados do que o limite de alerta especificado explicado na seção anterior. Este alerta único 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ê quiser que os eventos sejam exibidos individualmente ou se quiser agrupá-los por determinados parâmetros — por usuário, nome de host ou outra coisa. Você pode definir esses parâmetros na consulta. |

As regras do Google Analytics podem gerar até 150 alertas. Se o agrupamento de eventos estiver definido como Disparar um alerta para cada evento e a consulta da regra retornar mais de 150 eventos, os primeiros 149 eventos gerarão um alerta exclusivo (para 149 alertas) e o 150º alerta resumirá todo o conjunto de eventos retornados. Em outras palavras, o 150º alerta é o que teria sido gerado se o agrupamento de eventos tivesse sido definido para 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 diferentes do esperado. Para obter mais informações sobre esse cenário, consulte Solução de problemas de regras de análise no Microsoft Sentinel | Problema: nenhum evento aparece nos resultados da consulta.

Supressão

Se pretender que esta regra deixe de funcionar durante um período de tempo depois de gerar um alerta, ative a definição Parar consulta em execução após a geração de alerta. Em seguida, você deve definir Parar consulta de execução para a quantidade de tempo que a consulta deve parar de ser executada, até 24 horas.

Simulação de resultados

O assistente de regras de análise permite testar sua eficácia executando-o no conjunto de dados atual. Quando você executa o teste, a janela Simulação de resultados mostra um gráfico dos resultados que a consulta teria gerado nas últimas 50 vezes que teria sido executada, de acordo com o cronograma definido atualmente. Se você modificar a consulta, poderá executar o teste novamente para atualizar o gráfico. O gráfico mostra o número de resultados ao longo do período de tempo definido, que é determinado pelo agendamento de consulta definido.

Veja como a simulação de resultados pode parecer para a consulta na captura de tela acima. O lado esquerdo é a visualização padrão, e o lado direito é o que você vê quando passa o mouse sobre um ponto no tempo no gráfico.

Se você vir que sua consulta acionaria muitos alertas ou muito frequentes, você pode experimentar as configurações de agendamento e limite e executar a simulação novamente.

Definições de incidentes

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

A criação de incidentes está habilitada por padrão. O Microsoft Sentinel cria um incidente único e separado de cada alerta gerado pela regra.

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

Se 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 são agrupados em incidentes. Por padrão, o Microsoft Sentinel cria um incidente para cada alerta gerado. Em vez disso, você tem a opção de agrupar vários alertas em um único incidente.

O incidente só é criado depois de todos os alertas terem sido gerados. Todos os alertas são adicionados ao incidente imediatamente após a sua 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 único incidente, um novo incidente será gerado com os mesmos detalhes do incidente que o original e os alertas em excesso serão agrupados no novo incidente.

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

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

• Período de tempo: por padrão, alertas criados até 5 horas após o primeiro alerta em um incidente são adicionados ao mesmo incidente. Após 5 horas, um novo incidente é criado. Pode alterar este período de tempo para qualquer lugar entre 5 minutos e 7 dias.

• Critérios de agrupamento: escolha como determinar quais alertas são incluídos no grupo. A tabela a seguir mostra as opções possíveis:

  Opção	Description
  Alertas de grupo em um único incidente se todas as entidades corresponderem	Os alertas são agrupados se partilharem valores idênticos para cada uma das entidades mapeadas definidas anteriormente. Esta é a definição recomendada.
  Agrupe todos os alertas acionados por essa regra em um único incidente	Todos os alertas gerados por esta regra são agrupados, mesmo que não partilhem valores idênticos.
  Agrupar alertas em um único incidente se as entidades e os detalhes selecionados corresponderem	Os alertas são agrupados se compartilharem valores idênticos para todas as entidades mapeadas, detalhes de alerta e detalhes personalizados selecionados para essa configuração. Escolha as entidades e os detalhes nas listas suspensas que aparecem quando você seleciona essa opção. Talvez você queira usar essa configuração se, por exemplo, quiser criar incidentes separados com base nos endereços IP de origem ou de destino ou se quiser agrupar alertas que correspondam a uma entidade e gravidade específicas. Nota: Ao selecionar essa opção, você deve 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.

• Incidentes de reabertura: se um incidente tiver sido resolvido e fechado e, posteriormente, for gerado outro alerta que deva pertencer a esse incidente, defina esta definição como Ativado se pretender que o incidente fechado seja reaberto e deixe como Desativado se pretender que o novo alerta crie um novo incidente.

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

Resposta automática

O Microsoft Sentinel permite definir respostas automatizadas para ocorrer quando:

• Um alerta é gerado por esta regra de análise.
• Um incidente é criado a partir de alertas gerados por esta regra de análise.
• Um incidente é atualizado com alertas gerados por esta regra de análise.

Para saber tudo sobre os diferentes tipos de respostas que podem ser criadas e automatizadas, consulte 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 espaço de trabalho, cujas condições se aplicam a essa regra de análise. Você pode editar qualquer uma dessas regras existentes ou criar uma nova regra de automação que se aplique somente a essa regra de análise.

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

Automatize tarefas mais complexas e invoque respostas de sistemas remotos para remediar ameaças chamando playbooks a partir dessas regras de automação. Você pode invocar playbooks para incidentes, bem como para alertas individuais.

• Para obter mais informações e instruções sobre como criar playbooks e regras de automação, consulte 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, consulte Usar gatilhos e ações nos manuais do Microsoft Sentinel.

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

Próximos passos

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

Para automatizar a habilitação de regras, envie regras para o Microsoft Sentinel via API e PowerShell, embora isso exija esforço adicional. Ao usar a API ou o PowerShell, você deve primeiro exportar as regras para JSON antes de habilitar as regras. A API ou o PowerShell podem ser úteis ao habilitar regras em várias instâncias do Microsoft Sentinel com configurações idênticas em cada instância.

Para obter mais informações, consulte:

• Exportar e importar regras de análise de e para modelos 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 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.