Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
De longe, o tipo mais comum de regra de análise, as regras Agendadas baseiam-se em consultas Kusto configuradas para serem executadas em intervalos regulares e examinar dados não processados de um período de "lookback" definido. As consultas podem realizar operações estatísticas complexas nos dados de destino, revelando linhas de base e valores atípicos em grupos de eventos. Se o número de resultados capturados pela consulta passar o limiar configurado na regra, a regra produzirá um alerta.
Este artigo ajuda-o a compreender como as regras de análise agendadas são criadas e apresenta-lhe todas as opções de configuração e os respetivos significados. As informações neste artigo são úteis em dois cenários:
Criar uma regra de análise a partir de um modelo: utilize a lógica de consulta e as definições de agendamento e de pesquisa, conforme definido no modelo, ou personalize-as para criar novas regras.
Crie uma regra de análise do zero: crie a sua própria consulta e regra do zero. Para fazê-lo de forma eficaz, deve ter uma base completa na ciência de dados e na linguagem de consulta Kusto.
Importante
Após 31 de março de 2027, Microsoft Sentinel deixarão de ser suportados no portal do Azure e só estarão disponíveis no portal do Microsoft Defender. Todos os clientes que utilizem Microsoft Sentinel no portal do Azure serão redirecionados para o portal do Defender e utilizarão apenas Microsoft Sentinel no portal do Defender.
Se ainda estiver a utilizar Microsoft Sentinel no portal do Azure, recomendamos que comece a planear a transição para o portal do Defender para garantir uma transição suave e tirar o máximo partido da experiência de operações de segurança unificada oferecida pelo Microsoft Defender.
Modelos de regras de análise
As consultas nos modelos de regras agendadas foram escritas por especialistas em ciência de dados e segurança, da Microsoft ou do fornecedor da solução que fornece o modelo.
Utilize um modelo de regra de análise ao selecionar um nome de modelo na lista de modelos e ao criar uma regra com base no mesmo.
Cada modelo tem uma lista das origens de dados necessárias. Quando abre o modelo, as origens de dados são verificadas automaticamente quanto à disponibilidade. A disponibilidade significa que a origem de dados está ligada e que os dados são ingeridos regularmente através da mesma. Se alguma das origens de dados necessárias não estiver disponível, não poderá criar a regra e também poderá ver uma mensagem de erro nesse sentido.
Quando 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 pode personalizar a lógica e outras definições de regras para se adequarem melhor às suas necessidades específicas. Pode repetir este processo para criar mais regras com base no modelo. Quando chegar ao fim do assistente de criação de regras, as personalizações são validadas e a regra é criada. As novas regras são apresentadas no separador Regrasativas na página Análise. Da mesma forma, no separador Modelos de regra, o modelo a partir do qual criou a regra é agora apresentado com a In use etiqueta .
Os modelos de regras de análise são constantemente mantidos pelos respetivos autores, quer para corrigir erros, quer para refinar a consulta. Quando um modelo recebe uma atualização, todas as regras baseadas nesse modelo são apresentadas com a Update etiqueta e terá a oportunidade de modificar essas regras para incluir as alterações efetuadas ao modelo. Também pode reverter as alterações efetuadas numa regra para a versão original baseada no modelo. Para obter mais informações, veja Manage template versions for your scheduled analytics rules in Microsoft Sentinel (Gerir versões de modelos para as regras de análise agendadas no Microsoft Sentinel).
Depois de se familiarizar com as opções de configuração neste artigo, veja Criar regras de análise agendada a partir de modelos.
O resto deste artigo explica todas as possibilidades de personalização da configuração das suas regras.
Configuração da regra de análise
Esta secção explica as principais considerações que tem de ter em conta antes de começar a configurar as regras.
Nome e detalhes da regra de análise
A primeira página do assistente de regras 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 todos os filtros baseados em regras. O nome tem de ser exclusivo da área de trabalho.
Descrição: Uma descrição de texto livre da finalidade da regra.
ID: O GUID da regra como um recurso Azure, utilizado em pedidos e respostas da API, entre outras coisas. Este GUID só é atribuído quando a regra é criada, pelo que é apresentada apenas quando estiver a editar uma regra existente. Como é um campo só de leitura, é apresentado como desativado e não pode ser alterado. 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.
| Gravidade | Descrição |
|---|---|
| Informativo | Não tem impacto no seu sistema, mas as informações podem ser indicativas dos passos futuros planeados por um ator de ameaças. |
| Baixo | O impacto imediato seria mínimo. Um ator de ameaças provavelmente teria de realizar vários passos antes de alcançar um impacto num ambiente. |
| Média | O ator de ameaças pode ter algum impacto no ambiente com esta atividade, mas seria limitado no âmbito ou exigiria atividade adicional. |
| High | A atividade identificada fornece ao ator de ameaças um amplo acesso à realização de ações no ambiente ou é acionada pelo impacto no ambiente. |
As predefiniçõ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 gravidade para Microsoft Sentinel modelos de regras de análise são relevantes apenas para alertas criados por regras de análise. Para alertas ingeridos a partir 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. Baseiam-se nas táticas e técnicas da arquitetura MITRE ATT&CK®.
A MITRE ATT&táticas e técnicas CK definidas aqui na regra aplicam-se a quaisquer alertas gerados pela regra. Também se aplicam a quaisquer incidentes criados a partir destes alertas.
Para obter mais informações sobre como maximizar a cobertura do mitre ATT&cenário de ameaças CK, veja Compreender a cobertura de segurança pela arquitetura MITRE ATT&CK®.
Estado: Quando cria a regra, o respetivo Estado está Ativado por predefinição, o que significa que é executado imediatamente após concluir a sua criação. Se não quiser que seja executada imediatamente, tem duas opções:
- Selecione Desativado e a regra é criada sem ser executada. Quando quiser que a regra seja executada, localize-a no separador Regras ativas e ative-a a partir daí.
- Agende a regra para ser executada pela primeira vez numa data e hora específicas. Este método está atualmente em PRÉ-VISUALIZAÇÃO. Veja Agendamento de consultas mais adiante neste artigo.
Consulta de regra
Esta é a essência da regra: decide que informações estão nos alertas criados por esta regra e como as informações são organizadas. Esta configuração tem efeitos de seguimento sobre o aspeto dos incidentes resultantes e como são fáceis ou difíceis de investigar, remediar e resolver. É importante tornar os alertas o mais avançados possível em informações e tornar essas informações facilmente acessíveis.
Veja ou introduza a consulta Kusto que analisa os dados de registo não processados. Se estiver a criar uma regra de raiz, é aconselhável planear e estruturar a consulta antes de abrir este assistente. Pode criar e testar consultas na página Registos .
Tudo o que escrever na janela de consulta da regra é validado instantaneamente, pelo que pode descobrir imediatamente se comete algum erro.
Melhores práticas para consultas de regras de análise
Recomendamos que utilize um analisador do Modelo de Informação de Segurança Avançada (ASIM) como origem de consulta, em vez de utilizar uma tabela nativa. Isto irá garantir que a consulta suporta qualquer origem de dados ou família de origens de dados relevante atual ou futura, em vez de depender de uma única origem de dados.
O comprimento da consulta deve ter entre 1 e 10 000 carateres e não pode conter "
search *" ou "union *". Pode utilizar funções definidas pelo utilizador para ultrapassar a limitação do comprimento da consulta, uma vez que uma única função pode substituir dezenas de linhas de código.A utilização de funções ADX para criar consultas Azure Data Explorer dentro da janela de consulta do Log Analytics não é suportada.
Ao utilizar a
bag_unpackfunção numa consulta, se projetar as colunas como campos com "project field1" e a coluna não existir, a consulta falhará. Para evitar que isto aconteça, tem de projetar a coluna da seguinte forma:project field1 = column_ifexists("field1","")
Para mais informações, consulte:
- Linguagem de Pesquisa Kusto em Microsoft Sentinel
- Guia de referência rápida do KQL
- Melhores práticas para consultas de Linguagem de Pesquisa Kusto
Melhoramento de alertas
Se quiser que os alertas sejam apresentados para que possam ser imediatamente visíveis em incidentes e controlados e investigados adequadamente, utilize a configuração de melhoramento do alerta para ver todas as informações importantes nos alertas.
Esta melhoria de alerta tem o benefício adicional de apresentar resultados de uma forma facilmente visível e acessível.
Existem três tipos de melhorias de alertas que 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. Identificar todas as entidades num alerta é essencial para detetar e investigar ameaças. Para garantir que Microsoft Sentinel identifica as entidades nos seus dados não processados, tem de mapear os tipos de entidade reconhecidos pelo Microsoft Sentinel para campos nos resultados da consulta. Este mapeamento integra as entidades identificadas no campo Entidades no esquema de alerta.
Para saber mais sobre o mapeamento de entidades e obter instruções completas, veja Mapear campos de dados para entidades no Microsoft Sentinel.
Detalhes personalizados
Por predefinição, apenas as entidades de alerta e os metadados são visíveis em incidentes sem desagregar os eventos não processados nos resultados da consulta. Para dar visibilidade imediata aos outros campos dos resultados da consulta nos seus alertas e incidentes, defina-os como detalhes personalizados. Microsoft Sentinel integra estes detalhes personalizados no campo ExtendedProperties nos alertas, fazendo com que sejam apresentados antecipadamente nos alertas e em quaisquer incidentes criados a partir desses alertas.
Para saber mais sobre a apresentação de detalhes personalizados e para obter instruções completas, consulte Detalhes de eventos personalizados do Surface em alertas no Microsoft Sentinel.
Detalhes do alerta
Esta definição permite-lhe personalizar propriedades de alerta padrão de outra forma de acordo com o conteúdo de vários campos em cada alerta individual. Estas personalizações estão integradas no campo ExtendedProperties nos alertas. Por exemplo, pode personalizar o nome ou a descrição do alerta para incluir um nome de utilizador ou endereço IP em destaque no alerta.
Para saber mais sobre como personalizar os detalhes do alerta e obter instruções completas, veja Personalizar detalhes do alerta no Microsoft Sentinel.
Nota
No portal de Microsoft Defender, o motor de correlação Defender XDR é responsável exclusivamente por incidentes de nomenclatura, pelo que quaisquer nomes de alerta personalizados podem ser substituídos quando os incidentes são criados a partir destes alertas.
Agendamento de consultas
Os parâmetros seguintes determinam a frequência com que a regra agendada é executada e o período de tempo que examina sempre que é executada.
| Definição | Comportamento |
|---|---|
| Executar consulta a cada | Controla o intervalo de consulta: a frequência com que a consulta é executada. |
| Procurar dados do último | Determina o período de procura: o período de tempo abrangido pela consulta. |
O intervalo permitido para ambos os parâmetros é de 5 minutos a 14 dias.
O intervalo de consulta tem de ser mais curto ou igual ao período de pesquisa. Se for mais curto, os períodos de consulta sobrepõem-se, o que pode causar alguma duplicação de resultados. No entanto, a validação da regra não lhe permite definir um intervalo mais longo do que o período de procura, uma vez que tal resultaria em lacunas na sua cobertura.
A definição Começar a executar , agora em PRÉ-VISUALIZAÇÃO, permite-lhe criar uma regra com o estado Ativado, mas atrasar a sua primeira execução até uma data e hora pré-determinadas. Esta definição é útil se quiser cronometrar a execução das suas regras de acordo com quando se espera que os dados sejam ingeridos a partir da origem ou para quando os analistas do SOC começarem o dia de trabalho.
| Definição | Comportamento |
|---|---|
| Automaticamente | A regra é executada pela primeira vez imediatamente após ser criada e, depois disso, no intervalo definido na definição Executar consulta a cada . |
| No momento específico (Pré-visualização) | Defina uma data e hora para a regra ser executada pela primeira vez, após a qual é executada no intervalo definido na definição Executar consulta a cada definição. |
O tempo de execução do início tem de ser entre 10 minutos e 30 dias após a hora de criação (ou ativação) da regra.
A linha de texto na definição Começar a executar (com o ícone de informações à esquerda) resume as definições de agendamento e pesquisa de consultas atuais.
Nota
Atraso na ingestão
Para ter em conta a latência que pode ocorrer entre a geração de um evento na origem e a ingestão em Microsoft Sentinel e para garantir uma cobertura completa sem duplicação de dados, Microsoft Sentinel executa regras de análise agendadas com um atraso de cinco minutos a partir da hora agendada.
Para obter mais informações, veja Lidar com o atraso da ingestão nas regras de análise agendada.
Limiar de alerta
Muitos tipos de eventos de segurança são normais ou mesmo esperados em números pequenos, mas são um sinal de uma ameaça em maior número. Diferentes escalas de números grandes 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 que um utilizador não se lembra de uma palavra-passe, mas 50 num minuto pode ser um sinal de um ataque humano e mil é provavelmente um ataque automatizado.
Dependendo do tipo de atividade que a regra está a tentar detetar, pode definir um número mínimo de eventos (resultados da consulta) necessário para acionar um alerta. O limiar aplica-se separadamente a cada vez que a regra é executada, não coletivamente.
O limiar também pode ser definido para um número máximo de resultados ou um número exato.
Agrupamento de eventos
Existem duas formas de lidar com o agrupamento de eventos em alertas:
Agrupar todos os eventos num único alerta: Esta é a predefinição. A regra gera um único alerta sempre que é executada, desde que a consulta devolva mais resultados do que o limiar de alerta especificado explicado na secção anterior. Este alerta único resume todos os eventos devolvidos nos resultados da consulta.
Acionar um alerta para cada evento: A regra gera um alerta exclusivo para cada evento (resultado) devolvido pela consulta. Este modo é útil se quiser que os eventos sejam apresentados individualmente ou se quiser agrupá-los por determinados parâmetros, por utilizador, nome de anfitrião ou outra coisa qualquer. Pode definir estes parâmetros na consulta.
As regras de análise podem gerar até 150 alertas. Se o Agrupamento de eventos estiver definido como Acionar um alerta para cada evento e a consulta da regra devolver mais de 150 eventos, os primeiros 149 eventos irão gerar um alerta exclusivo (para 149 alertas) e o 150.º alerta irá resumir todo o conjunto de eventos devolvidos. Por outras palavras, o 150.º alerta seria o que teria sido gerado se o agrupamento de Eventos tivesse sido definido como Agrupar todos os eventos num único alerta.
A secção Consulta do alerta é diferente em cada um destes dois modos. No modo Agrupar todos os eventos num único alerta , o alerta devolve uma consulta que lhe permite ver todos os eventos que acionaram o alerta. Pode desagregar os resultados da consulta para ver os eventos individuais. No modo Acionar um alerta para cada evento , o alerta devolve um resultado codificado com base64 na área de consulta. Copie e execute esta saída no Log Analytics para descodificar a base64 e mostrar o evento original.
A definição Acionar um alerta para cada evento pode causar um problema em que os resultados da consulta parecem estar em falta ou diferentes do esperado. Para obter mais informações sobre este cenário, veja Resolver problemas de regras de análise no Microsoft Sentinel | Problema: não são apresentados eventos nos resultados da consulta.
Supressão
Se pretender que esta regra deixe de funcionar durante um período de tempo após gerar um alerta, ative a definiçãoParar a execução da consulta após o alerta ser gerado. Em seguida, tem de definir Parar a execução da consulta durante o período de tempo durante o qual a consulta deve parar de ser executada, até 24 horas.
Simulação de resultados
O assistente de regras de análise permite-lhe testar a eficácia ao executá-la no conjunto de dados atual. Quando executa o teste, a janela Simulação de resultados mostra-lhe um gráfico dos resultados que a consulta teria gerado nas últimas 50 vezes que teria sido executada, de acordo com a agenda atualmente definida. Se modificar a consulta, pode 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 pela agenda de consulta que definiu.
Eis o aspeto que a simulação de resultados poderá ter para a consulta na captura de ecrã anterior. O lado esquerdo é a vista predefinida e o lado direito é o que vê quando paira o cursor sobre um ponto anterior no tempo no gráfico.
Se vir que a consulta acionaria demasiados alertas ou demasiado frequentes, pode experimentar as definições de agendamento e limiar e executar a simulação novamente.
Definições de incidentes
Escolha se Microsoft Sentinel transforma alertas em incidentes acionáveis.
A criação de incidentes está ativada por predefinição. Microsoft Sentinel cria um único incidente separado de cada alerta gerado pela regra.
Se não quiser que esta regra resulte na criação de incidentes (por exemplo, se esta regra for apenas para recolher informações para análise subsequente), defina esta opção como Desativado.
Importante
Se tiver integrado Microsoft Sentinel no portal do Defender, Microsoft Defender é responsável pela criação de incidentes. No entanto, se quiser Defender XDR criar incidentes para este alerta, tem de deixar esta definição Ativada. Defender XDR recebe a instrução definida aqui.
Isto não deve ser confundido com o tipo de segurança da Regra de análise da Microsoft que cria incidentes para alertas gerados nos serviços Microsoft Defender. Essas regras são automaticamente desativadas ao integrar Microsoft Sentinel no portal do Defender.
Se quiser criar um único incidente a partir de um grupo de alertas, em vez de um para cada alerta, consulte a secção seguinte.
Agrupamento de alertas
Escolha se os alertas são agrupados em incidentes. Por predefinição, Microsoft Sentinel cria um incidente para cada alerta gerado. Em alternativa, tem a opção de agrupar vários alertas num ú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.
Podem ser agrupados até 150 alertas num único incidente. Se forem gerados mais de 150 alertas por uma regra que os agrupa num único incidente, é gerado um novo incidente com os mesmos detalhes do incidente que o original e os alertas em excesso são agrupados no novo incidente.
Para agrupar alertas, defina a definição de agrupamento de alertas como Ativado.
Existem algumas opções a considerar ao agrupar alertas:
Intervalo de tempo: Por predefinição, os alertas criados até 5 horas após o primeiro alerta num incidente são adicionados ao mesmo incidente. Após 5 horas, é criado um novo incidente. Pode alterar este período de tempo para qualquer lugar entre 5 minutos e sete dias.
Critérios de agrupamento: Escolha como determinar que alertas estão incluídos no grupo. A tabela seguinte mostra as opções possíveis:
Opção Descrição Agrupar alertas num ú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. Agrupar todos os alertas acionados por esta regra num único incidente Todos os alertas gerados por esta regra são agrupados, mesmo que não partilhem valores idênticos. Agrupar alertas num único incidente se as entidades e os detalhes selecionados corresponderem Os alertas são agrupados se partilharem valores idênticos para todas as entidades mapeadas, detalhes do alerta e detalhes personalizados que selecionar para esta definição. Selecione as entidades e os detalhes nas listas pendentes que aparecem quando seleciona esta opção.
Poderá querer utilizar esta definiçã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: quando seleciona esta opção, tem de ter, pelo menos, uma entidade ou detalhe selecionado para a regra. Caso contrário, a validação da regra falha e a regra não é criada.Reabrir incidentes: se um incidente tiver sido resolvido e fechado e posteriormente for gerado outro alerta que deve pertencer a esse incidente, defina esta definição como Ativado se pretender que o incidente fechado seja reaberto e deixe como Desativado se quiser que o novo alerta crie um novo incidente.
A opção para reabrir incidentes fechados não está disponível se tiver integrado Microsoft Sentinel no portal do Defender.
Resposta automatizada
Microsoft Sentinel permite-lhe definir respostas automatizadas para ocorrerem quando:
- Este 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, veja Automatizar a resposta a ameaças em Microsoft Sentinel com regras de automatização.
No cabeçalho Regras de automatização , o assistente apresenta uma lista das regras de automatização já definidas em toda a área de trabalho, cujas condições se aplicam a esta regra de análise. Pode editar qualquer uma destas regras existentes ou pode criar uma nova regra de automatização que se aplique apenas a esta regra de análise.
Utilize regras de automatização para efetuar a triagem básica, a atribuição, o fluxo de trabalho e o encerramento de incidentes.
Automatize tarefas mais complexas e invoque respostas de sistemas remotos para remediar ameaças ao chamar manuais de procedimentos a partir destas regras de automatização. Pode invocar manuais de procedimentos para incidentes, bem como para alertas individuais.
Para obter mais informações e instruções sobre como criar manuais de procedimentos e regras de automatização, veja Automatizar respostas a ameaças.
Para obter mais informações sobre quando utilizar o acionador criado pelo incidente, o acionador atualizado do incidente ou o acionador criado pelo alerta, veja Utilizar acionadores e ações no Microsoft Sentinel manuais de procedimentos.
No cabeçalho Automatização de alertas (clássico), poderá ver uma lista de manuais de procedimentos configurados para serem executados automaticamente com um método antigo que deverá ser preterido em março de 2026. Não pode adicionar nada a esta lista. Todos os manuais de procedimentos aqui listados devem ter regras de automatização criadas, com base no acionador criado pelo alerta, para invocar os manuais de procedimentos. Depois de o fazer, selecione as reticências no final da linha do manual de procedimentos listado aqui e selecione Remover. Veja Migrar os manuais de procedimentos Microsoft Sentinel acionador de alertas para regras de automatização para obter instruções completas.
Passos seguintes
Ao utilizar Microsoft Sentinel regras de análise para detetar ameaças em todo o ambiente, certifique-se de que ativa todas as regras associadas às origens de dados ligadas para garantir uma cobertura de segurança total para o seu ambiente.
Para automatizar a ativação de regras, envie regras para Microsoft Sentinel através da API e do PowerShell, embora isso exija mais esforço. Ao utilizar a API ou o PowerShell, primeiro tem de exportar as regras para JSON antes de ativar as regras. A API ou o PowerShell podem ajudar a ativar regras em várias instâncias de Microsoft Sentinel com definições idênticas em cada instância.
Para mais informações, consulte:
- Exportar e importar regras de análise de e para modelos do ARM
- Resolver problemas de regras de análise no Microsoft Sentinel
- Navegar e investigar incidentes no Microsoft Sentinel
- 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.