Criar e publicar regras de análise para soluções do Microsoft Sentinel

As regras de análise do Microsoft Sentinel são conjuntos de critérios. Essas regras definem como os dados são monitorados, o que é detectado e quais ações são tomadas quando determinadas condições são atendidas. Além disso, ajudam a identificar comportamentos suspeitos, anomalias e possíveis ameaças à segurança ao analisar logs e sinais de diversas fontes de dados.

As regras de análise do Microsoft Sentinel são ferramentas poderosas para fortalecer a postura de segurança de uma organização, pois detectam e respondem proativamente a possíveis ameaças. Ao seguir uma abordagem estruturada para criar e gerenciar essas regras, as organizações podem aproveitar as funcionalidades do Microsoft Sentinel para proteger seus ativos digitais e manter uma infraestrutura de segurança robusta. Para obter mais informações, veja Detecção de ameaças no Microsoft Sentinel.

Este artigo orienta você no processo de criação e publicação de regras de análise para soluções do Microsoft Sentinel.

Casos de uso das regras de análise do Microsoft Sentinel

As regras de análise do Microsoft Sentinel podem ser aplicadas a diversos cenários para aprimorar o monitoramento de segurança e a detecção de ameaças. Os casos de uso comuns incluem:

• Detecção de intrusões: identifica tentativas de acesso não autorizado ou atividades de entrada suspeitas que podem indicar uma possível violação.
• Detecção de malware: monitora assinaturas conhecidas de malware ou comportamentos incomuns que possam sugerir a presença de software mal-intencionado.
• Exfiltração dos dados: detecta transferências de dados grandes ou incomuns que podem significar uma tentativa de exfiltração de informações da rede.
• Ameaças internas: identifica comportamentos anômalos de usuários internos, como acesso a dados confidenciais fora dos horários ou padrões normais.
• Monitoramento de conformidade: garante a aderência a requisitos regulatórios ao monitorar atividades ou padrões de acesso específicos.
• Busca por ameaças: pesquisa proativamente indicadores de comprometimento ou outros sinais de atividades maliciosas na rede.
• Comprometimento da conta: detecta sinais de que as contas de usuário podem estar comprometidas, como padrões de entrada geográfica incomuns ou várias tentativas de entrada com falha.
• Anomalias de rede: identifica padrões de tráfego de rede incomuns que possam indicar a presença de uma ameaça ou configuração incorreta.
• Elevação de privilégio: monitora tentativas de obter privilégios elevados dentro da rede, o que pode ser um precursor para outras atividades mal-intencionadas.
• Segurança dos pontos de extremidade: garante a segurança dos pontos de extremidade ao detectar desvios do comportamento normal ou a presença de software não autorizado.

Criar e publicar regras de análise

Você cria regras de análise no formato YAML. Use estes exemplos de regras de análise como referências para criar seus próprios:

• Microsoft Entra ID — FailedLogonToAzurePortal.yaml
• CrowdStrike Falcon — CriticalOrHighSeverityDetectionsByUser.yaml
• XBOW — XbowCriticalHighFindings.yaml

As seções a seguir oferecem um passo a passo detalhado dos diversos atributos de uma regra de análise.

Regra de exemplo para análise

Veja a seguir uma regra de análise de exemplo no formato YAML.

id: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
name: Anomalous login from unknown IP
description: |
  Identifies login attempts from IP addresses not seen in the past 14 days.
severity: Medium
requiredDataConnectors:
  - connectorId: ContosoMyProduct
    dataTypes:
      - ContosoMyProduct_CL
queryFrequency: 1h
queryPeriod: 14d
triggerOperator: gt
triggerThreshold: 0
tactics:
  - InitialAccess
relevantTechniques:
  - T1078
status: Available
query: |
  ContosoMyProduct_CL
  | where TimeGenerated > ago(1h)
  | where EventType == "Login"
  | summarize count() by SrcIpAddr, UserName
  | extend Name = tostring(split(UserName, '@', 0)[0])
  | extend UPNSuffix = tostring(split(UserName, '@', 1)[0])
entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: Name
        columnName: Name
      - identifier: UPNSuffix
        columnName: UPNSuffix
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: SrcIpAddr
version: 1.0.0
kind: Scheduled

ID

O atributo id consiste em um GUID (identificador global exclusivo) padrão. Gere-o usando qualquer ferramenta de desenvolvimento, um gerador online ou o cmdlet New-GUID do PowerShell. Precisa ser exclusiva em relação a outros GUIDs.

Este campo é obrigatório.

Variante

O atributo kind representa o tipo de regra.

Aceita dois valores: scheduled e NRT (quase em tempo real). O valor scheduled exige que você defina outras propriedades, como queryFrequency, queryPeriod, triggerThreshold e triggerOperator. Para NRT regras, omita queryFrequency, queryPeriod, triggerOperatore triggerThreshold.

Este campo é obrigatório.

Name

O atributo name fornece um rótulo breve que resume a detecção. O rótulo precisa ser claro e conciso para ajudar os usuários a entender a finalidade da regra. Use alertDetailsOverride para gerar nomes dinâmicos que ajudem os analistas a entender o alerta. Este atributo:

• Usa a primeira letra da frase em maiúscula.
• Não termina com ponto final.
• Tem um comprimento recomendado de menos de 50 caracteres e um máximo rígido de 100 caracteres.
• Evita as palavras "suspeito" e "sob suspeita". Em vez disso, use "Inesperado", "Anômalo" ou "Raro".

Este campo é obrigatório.

Description

O atributo description fornece uma descrição detalhada da detecção. A descrição inclui informações sobre o comportamento detectado, o possível efeito e ações recomendadas. Este atributo:

• Usa a primeira letra da frase em maiúscula.
• Começa com “Esta consulta busca por” ou “Identifica”.
• É diferente e mais descritivo do que o campo de nome.
• Tem no máximo 255 caracteres.
• Possui cinco frases ou menos.
• Não descreve a fonte de dados (conector ou tipo de dado).
• Não fornece uma explicação técnica sobre a linguagem da consulta.
• Usa apenas caracteres ASCII. Travessões, aspas curvas e outros caracteres não ASCII não passam na validação.

Este campo é obrigatório.

Severidade

O atributo severity define o nível de severidade da detecção. A severidade reflete o possível efeito do comportamento detectado e a urgência da resposta.

• Informativa: o incidente pode não representar diretamente uma ameaça à segurança, mas pode ser relevante para uma investigação de acompanhamento ou adicionar contexto ou conscientização situacional para os analistas.
• Baixa: o efeito imediato é mínimo e um ator de ameaças precisaria executar várias etapas antes de produzir um efeito no ambiente.
• Média: o ator de ameaças pode causar algum efeito no ambiente com esta atividade, mas de forma limitada ou exigindo ações adicionais.
• Alta: a atividade identificada fornece ao ator de ameaças amplo acesso para realizar ações no ambiente.

Status

O atributo status indica a prontidão para produção da regra:

• Available: regras prontas para produção.
• InPreview: regras Beta.
• Deprecated: regras sendo eliminadas gradualmente.

Conectores de dados necessários

O atributo requiredDataConnectors representa a lista de conectores de dados que a regra precisa para funcionar corretamente, como as fontes de dados nas quais a regra faz consultas. Se não houver um mapeamento atual de conectores de dados, você precisa usar uma chave de abertura: requiredDataConnectors: [].

O atributo connectorId especifica a ID do conector de dados necessário para que a consulta funcione corretamente. Se a sua consulta de detecção depender de dados recuperados de um conector específico, você deve especificar a ID do conector aqui. Por exemplo, se sua regra de análise depender dos dados deste conector, você deve especificar a connectorID como 1PasswordCCPDefinition.

O atributo dataTypes representa os tipos de dados dos quais a regra de análise depende e menciona o nome do tipo de dados referenciado na seção dataTypes do conector. Por exemplo, se sua consulta de busca depender dos dados deste conector, você deve definir o tipo de dados como OnePasswordEventLogs_CL. Se a consulta de busca operar sobre uma função/analisador do Kusto em vez de uma tabela (como Syslog, CommonEventFormat ou _CL), dataTypes será o nome da função/analisador do Kusto e não o nome da tabela.

Período da consulta

O atributo queryPeriod representa um período específico durante o qual a consulta é executada. Por exemplo: os últimos 3 dias. Para este atributo:

• Use o formato TimeSpan da KQL (Linguagem de Consulta Kusto). Por exemplo, 3 dias é 3d, 2 horas é 2h.
• Verifique se os períodos de aprendizado ou referência estão dentro desse período.
• Não utilize um valor superior ao máximo permitido, que é 14d.

Este campo é obrigatório para regras de análise agendadas.

Frequência da consulta

O atributo queryFrequency representa a frequência com que a consulta é executada. Para este atributo:

• Use o formato TimeSpan da KQL. Por exemplo, 3 dias é 3d, 2 horas é 2h.
• Utilize um queryFrequency que seja menor ou igual ao queryPeriod.
• Siga esta regra: se o queryPeriod for maior ou igual a 2 dias (2d), o valor de queryFrequency não pode ser inferior a 1 hora (1h) e é usado apenas para detecções de alta severidade.

Este campo é obrigatório para regras de análise agendadas.

Operador de acionador

O atributo triggerOperator indica o mecanismo que dispara o alerta. Por exemplo: maior que (gt) o número definido no atributo triggerThreshold (veja Valor limite de disparo).

• gt: maior que.
• lt: menor que.
• eq: igual a.

Este campo é obrigatório para regras de análise agendadas.

Limite de gatilho

O atributo triggerThreshold representa o limite que dispara o alerta. O valor limite é aquele ao qual o atributo triggerOperator faz referência. Os valores aceitos podem ser qualquer número inteiro entre 0 e 10.000.

Por exemplo, se o triggerOperator estiver definido como gt e o triggerThreshold for 1, o alerta será acionado quando um valor for maior que 1.

Este campo é obrigatório para regras de análise agendadas.

Táticas

O atributo tactics define a MITRE ATT&CK tactics à qual a detecção está relacionada. Ao definir as táticas, você ajuda os usuários a entenderem o contexto da detecção e como ela se encaixa no panorama geral das ameaças. Para este atributo:

• ATT&CK Framework v16 é suportado.
• Os nomes usam PascalCase e não podem incluir espaços. Por exemplo: InitialAccess ou LateralMovement.
• No máximo cinco táticas podem ser definidas por regra.
• Os valores válidos são: Reconnaissance, , ResourceDevelopment, InitialAccess, Execution, Persistence, PrivilegeEscalation, , DefenseEvasion, CredentialAccess, Discovery, , LateralMovement, , Collection, , CommandAndControl, , , Exfiltratione Impact.

Este campo é obrigatório.

Técnicas relevantes

O atributo relevantTechniques define a MITRE ATT&CK techniques à qual a detecção está relacionada. Ao definir as técnicas, você ajuda os usuários a entenderem o contexto da detecção e como ela se encaixa no panorama geral das ameaças. Para este atributo:

• ATT&CK Framework v16 é suportado.
• Cada técnica deve pertencer a pelo menos um dos listados tactics.
• Os nomes não podem incluir espaços. Por exemplo: T1078 ou T1078.001.
• No máximo 10 técnicas podem ser definidas por regra.

Este campo é obrigatório.

Query

O atributo query define a lógica de detecção. Recomendamos que você escreva a consulta em KQL, que ela esteja estruturada e seja fácil de entender. Recomendamos criar uma consulta eficiente e otimizada para garantir sua execução em grandes conjuntos de dados sem comprometer o desempenho. Verifique se a consulta atende aos critérios a seguir.

Limite a consulta a 10.000 caracteres. Se a seção da consulta exceder esse limite, reduza o número de caracteres. Uma lista estática de itens usados para comparação dentro do corpo da consulta pode fazer com que você exceda o limite. Recomendamos que você mova essas listas para uma das seguintes opções:

• Uma função de lista de observação
• JSON/CSV personalizado
• Um função personalizada

Cada linha no corpo da consulta deve ter pelo menos um espaço no início, mas dois espaços são recomendados para melhorar a legibilidade.

Se você enviar uma consulta para um tipo de dado que não está presente nas pastas Detecções ou Consultas de Busca, nomeie a subpasta que contém os arquivos YAML com o nome da tabela consultada. Por exemplo, se a sua consulta pertencer à tabela AzureDevOpsAuditing, crie uma pasta chamada AzureDevOpsAuditing.

Defina nomes legíveis para constantes explícitas:

• let FailedLoginEventID = 4625;
• let countThreshold = 6;

Recomendamos fortemente que você use comentários para explicar a consulta. Evite adicionar comentários no final de uma linha de comando de consulta. Em vez disso, adicione os comentários em uma linha separada. Por exemplo:

  // Removing noisy processes for an environment, adjust as needed

Se estiver referenciando um analisador em vez de um nome de tabela, inclua um comentário ao lado da referência para esclarecer a função do analisador. O analisador deve ser importado primeiro para o espaço de trabalho. Caso contrário, as consultas SQL não reconhecerão como válido.

Verifique se todos os campos de entidade disponíveis são retornados para fins de mapeamento. (Confira a seção Mapeamento de entidades.) Sanitize a tabela retornada para incluir apenas as propriedades necessárias para a investigação. Você não precisa de um filtro TimeGenerated ao usar um comando lookback simples em toda a consulta. O valor queryPeriod no YAML controla esse processo.

Para estabelecer uma linha de base ou realizar comparações históricas (por exemplo, comparar hoje com os últimos sete dias), inclua um filtro com limite de tempo, como | where TimeGenerated >= ago(lookback), pois o modelo YAML não suporta vários valores queryPeriod no momento. Evite intervalos de tempo menores que um dia, a menos que haja um motivo específico. Não recomendamos intervalos maiores que 14 dias, pois podem impactar o desempenho.

Resuma quando necessário. Inclua o campo de tempo (geralmente TimeGenerated), pois ele é necessário no campo de entidade. Inclua os valores min() e max() da seguinte forma: | summarize StartTime = max(TimeGenerated), EndTime = min(TimeGenerated). Use exclusivamente os termos StartTime e EndTime. Não atribua aos campos os nomes StartTimeUtc ou EndTimeUtc, pois esses nomes podem entrar em conflito com as preferências de experiência do usuário.

Sempre que possível, inclua o máximo de campos para ajudar o usuário a entender o contexto do alerta. Recomendamos que você inclua pelo menos uma das entidades primárias: Host, Account ou IP.

Os nomes de coluna na tabela personalizada devem usar camelCase (por exemplo, SrcIpAddr ou UserName).

Este campo é obrigatório.

Configurações de agrupamento de eventos

O atributo eventGroupingSettings está relacionado aos alertas. Uma regra de alerta pode gerar um alerta separado para cada resultado da consulta. Por exemplo, uma regra que identifica alertas que não são da Microsoft no fluxo de eventos pode criar um alerta no Microsoft Sentinel para cada alerta de origem.

• Para produzir um único alerta para todos os resultados da consulta (padrão), use:

  eventGroupingSettings:
  aggregationKind: SingleAlert
  

• Para produzir um alerta separado para cada resultado da consulta, use:

  eventGroupingSettings:
  aggregationKind: AlertPerResult
  

Mapeamentos de entidades

O atributo entityMappings é essencial ao configurar regras de análise agendadas. Ele enriquece a saída da consulta (alertas e incidentes) com informações essenciais que servem como base para processos investigativos e ações corretivas que virão.

O entityType representa a lista padrão de entidades reconhecidas pelo Microsoft Sentinel. Os tipos com suporte incluem Account, Host, , IP, URL, File, Process, DNS, AzureResource, , FileHash, RegistryKey, RegistryValue, , SecurityGroup, , Mailboxe MailMessage. Veja os valores permitidos na coluna ¨Tipo de entidade na Tabela de mapeamento de entidades.

Este campo é obrigatório.

Mapeamentos de campos

O atributo fieldMappings representa o identificador do campo na saída da consulta que corresponde ao tipo de entidade. Confira os valores permitidos na coluna Identificadores na Tabela de mapeamento de entidades. Para este atributo:

• Cada modelo pode ter até 10 mapeamentos de entidade.

• Cada mapeamento de entidade pode ter até três mapeamentos de campo (ou seja, identificadores).

  entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: FullName
        columnName: AccountCustomEntity
  - entityType: Host
    fieldMappings:
      - identifier: FullName
        columnName: HostCustomEntity
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: ClientIP
  - entityType: DNS
    fieldMappings:
      - identifier: DomainName
        columnName: Name
  
  

Detalhes personalizados

O atributo customDetails integra os dados do evento aos alertas, tornando-os visíveis nos incidentes de segurança para facilitar a triagem, investigação e resposta. Os detalhes personalizados são pares chave-valor de nomes de propriedades e colunas. Para mais informações, confira o artigo Exibir detalhes personalizados de eventos em alertas no Microsoft Sentinel. É possível definir até 20 detalhes personalizados (pares chave/valor) por modelo. Os nomes de chave devem ter 20 caracteres ou menos.

    customDetails:
      Computers: Computer
      IPs: ComputerIP

Substituição de detalhes do alerta

O atributo alertDetailsOverride é um campo dinâmico que você pode usar para substituir os detalhes do alerta. Você pode usar esse atributo para fornecer mais contexto ou informações aos analistas quando o alerta é disparado. Ao usar esse recurso, você garante que os analistas recebam informações pertinentes, como nomes de entidade relevantes, para que haja uma compreensão mais rápida e precisa do incidente. As limitações incluem:

• No máximo três parâmetros podem ser incluídos em name ou description.

• O valor name não deve exceder 256 caracteres, enquanto description é limitado a 5.000 caracteres.

• O nome da coluna dentro das chaves deve corresponder exatamente ao nome esperado da coluna, sem espaços em branco antes ou depois (por exemplo, {{columnName}}, e não {{ columnName }}). No exemplo a seguir, columnName1, columnName2, dynamicTactic e dynamicSeverity são campos de saída da consulta de alerta agendado.

      alertDetailsOverride:
        alertDisplayNameFormat: free text with field names embedded using the format {{columnName}} # Up to 256 chars and 3 placeholders
        alertDescriptionFormat: free text with field names embedded using the format  {{columnName}} # Up to 5000 chars and 3 placeholders
        alertTacticsColumnName: dynamicTacticColumnName
        alertSeverityColumnName: dynamicSeverityColumnName
  
  

      alertDetailsOverride:
        alertDisplayNameFormat: rule {{columnName1}} display name
        alertDescriptionFormat: rule {{columnName2}} display name
        alertTacticsColumnName: dynamicTactic
        alertSeverityColumnName: dynamicSeverity
  

Configuração de incidente

O incidentConfiguration atributo controla a criação de incidentes e o agrupamento de alertas em incidentes. Use-o para definir como os alertas gerados por essa regra são agregados em incidentes.

Versão

Quando um cliente cria uma nova consulta de busca a partir de um modelo, o modelo version é salvo. Se uma nova versão do modelo for publicada, os clientes serão notificados na interface do usuário. As versões seguem o formato a, b, c, onde: a representa a versão principal, b representa a versão secundária ec representa o patch. O campo versão é a última linha do modelo.

Este campo é obrigatório.