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

As regras de análise do Microsoft Sentinel são conjuntos de critérios. Eles definem como os dados são monitorados, o que é detetado e quais ações são tomadas quando condições específicas são atendidas. Essas regras ajudam a identificar comportamentos suspeitos, anomalias e possíveis ameaças à segurança analisando logs e sinais de várias fontes de dados.

As regras de análise do Microsoft Sentinel são ferramentas poderosas para melhorar a postura de segurança de uma organização, pois detetam e respondem proativamente a ameaças potenciais. Ao seguir uma abordagem estruturada para criar e gerenciar essas regras, as organizações podem usar os recursos do Microsoft Sentinel para proteger seus ativos digitais e manter uma infraestrutura de segurança robusta. Para obter mais informações, consulte Deteção de ameaças no Microsoft Sentinel.

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

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

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

  • Deteção de intrusão: identifique tentativas de acesso não autorizado ou atividades de início de sessão suspeitas que possam indicar uma potencial violação.
  • Deteção de malware: monitore assinaturas de malware conhecidas ou comportamentos incomuns que possam sugerir a presença de software mal-intencionado.
  • Exfiltração de dados: detete transferências de dados grandes ou incomuns que possam significar que os dados estão sendo exfiltrados da rede.
  • Ameaças internas: identifique comportamentos anômalos de usuários internos, como acessar dados confidenciais fora do horário ou padrões normais.
  • Monitoramento de conformidade: Garanta a aderência aos requisitos regulatórios monitorando atividades específicas ou padrões de acesso.
  • Caça a ameaças: procure proativamente indicadores de comprometimento ou outros sinais de atividade maliciosa dentro da rede.
  • Comprometimento da conta: detete sinais de que as contas de usuário podem estar comprometidas, como padrões de entrada geográficos incomuns ou várias tentativas de entrada com falha.
  • Anomalias de rede: identifique padrões de tráfego de rede incomuns que possam indicar a presença de uma ameaça ou configuração incorreta.
  • Escalonamento de privilégios: monitore tentativas de obter privilégios elevados dentro da rede, o que pode ser um precursor de outras atividades maliciosas.
  • Segurança de endpoints: certifique-se de que os endpoints estão seguros detetando 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 a sua própria:

As seções a seguir fornecem um passo a passo detalhado de vários atributos de uma regra de análise.

Regra de análise de exemplo

Segue-se uma regra de análise de exemplo em 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 id atributo consiste em um GUID (identificador global exclusivo) padrão. Gere-o usando qualquer ferramenta de desenvolvimento, um gerador online ou o novo cmdlet PowerShell New-GUID. Deve ser único entre os outros GUIDs.

Este campo é obrigatório.

Variante

O kind atributo representa o tipo de regra.

Há dois valores aceitos: scheduled e NRT (quase em tempo real). O scheduled valor requer que você defina outras propriedades, incluindo queryFrequency, queryPeriod, triggerThresholde triggerOperator. Para NRT regras, omita queryFrequency, queryPeriod, triggerOperator, e triggerThreshold.

Este campo é obrigatório.

Name

O name atributo fornece um breve rótulo que resume a deteção. Certifique-se de que o rótulo é claro e conciso para ajudar os utilizadores a compreender o objetivo da regra. Use alertDetailsOverride para gerar nomes dinâmicos para ajudar os analistas a entender o alerta. Este atributo:

  • Usa maiúsculas e minúsculas de frase.
  • Não termina em um período.
  • Tem uma duração recomendada inferior a 50 caracteres e um máximo rígido de 100 caracteres.
  • Evita as palavras "Suspeito" e "Suspeita". Use "Inesperado", "Anómalo" ou "Raro" em vez disso.

Este campo é obrigatório.

Description

O description atributo fornece uma descrição detalhada da deteção. A descrição inclui informações sobre o comportamento que está sendo detetado, o efeito potencial e quaisquer ações recomendadas. Este atributo:

  • Utiliza a capitalização em frases.
  • Começa com "Esta consulta procura" ou "Identifica".
  • É diferente e mais descritivo do que o campo de nome.
  • Tem um comprimento máximo de 255 caracteres.
  • São cinco frases ou menos.
  • Não descreve a fonte de dados (conector ou tipo de dados).
  • Não fornece uma explicação técnica para a linguagem de consulta.
  • Usa apenas caracteres ASCII. Traços EM, aspas inteligentes e outros caracteres não ASCII falham na validação.

Este campo é obrigatório.

Severity

O severity atributo define o nível de gravidade da deteção. A gravidade reflete o efeito potencial do comportamento que está sendo detetado e a urgência da resposta.

  • Informativo: o incidente pode não representar diretamente uma ameaça à segurança, mas pode ser de interesse para uma investigação de acompanhamento ou para adicionar contexto ou consciência situacional a um analista.
  • Baixo: o efeito imediato é mínimo, e um agente de ameaça precisaria realizar várias etapas antes de obter um efeito em um ambiente.
  • Médio: O agente da ameaça poderia alcançar algum efeito no ambiente com esta atividade, mas o efeito seria limitado em escopo ou exigiria atividade extra.
  • Alta: A atividade identificada fornece ao agente da ameaça um amplo acesso para conduzir ações no meio ambiente.

Note

Os padrões de nível de severidade não são uma garantia do nível de impacto atual ou ambiental. O nível de gravidade aplica-se apenas aos modelos de análise do Microsoft Sentinel. Caso contrário, o serviço de segurança que emitiu o alerta controla o severity atributo na tabela Alertas. Você pode usar alertDetailsOverride para fornecer um atributo dinâmico severity que depende do resultado real da consulta.

Situação

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

  • Available: Regras prontas para produção.
  • InPreview: Regras da versão beta.
  • Deprecated: Regras a serem eliminadas gradualmente.

Conectores de dados necessários

O requiredDataConnectors atributo representa a lista de conectores de dados que a regra precisa para funcionar corretamente, incluindo as fontes de dados nas quais a regra é consultada. Se não houver nenhum mapeamento de conector de dados atual, você deverá usar uma chave aberta: requiredDataConnectors: [].

O connectorId atributo especifica a ID do conector de dados que você precisa para que a consulta funcione corretamente. Se a consulta de deteção depender dos dados obtidos de um conector específico, especifique o ID do conector aqui. Por exemplo, se sua regra de análise depender dos dados desse conector, você deverá especificar o connectorID como 1PasswordCCPDefinition.

O dataTypes atributo representa os tipos de dados dos quais a regra de análise depende e menciona o nome do tipo de dados referenciado na dataTypes seção do conector. Por exemplo, se sua consulta de caça depender dos dados desse conector, você deverá especificar o tipo de dados como OnePasswordEventLogs_CL. Se a consulta de caça operar numa função ou analisador Kusto em vez de numa tabela (como Syslog, CommonEventFormat, ou _CL), dataTypes é o nome da função ou analisador Kusto e não o nome da tabela.

Período de consulta

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

  • Use o formato KQL (Kusto Query Language) TimeSpan (por exemplo, 3 dias é 3d, 2 horas é 2h).
  • Certifique-se de que qualquer período de aprendizagem ou de referência está dentro deste período de tempo.
  • Não use um valor maior do que o valor máximo suportado, que é 14d.

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

Frequência de consulta

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

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

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

Operador de gatilho

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

  • gt: Maior que.
  • lt: Menos que.
  • eq: Igual a.

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

Limiar de desencadeamento

O triggerThreshold atributo representa o limite que dispara o alerta. O limiar é o valor a que triggerOperator se refere. Os valores suportados incluem qualquer número inteiro entre 0 e 10.000.

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

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

Tactics

O atributo tactics define o MITRE ATT&CK tactics ao qual a detecção está relacionada. Quando você define as táticas, isso ajuda os usuários a entender o contexto da deteção e como ela se encaixa no cenário geral de ameaças. Para este atributo:

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

Este campo é obrigatório.

Técnicas relevantes

O atributo relevantTechniques define o MITRE ATT&CK techniques ao qual a detecção está relacionada. Quando você define as técnicas, ele ajuda os usuários a entender o contexto da deteção e como ela se encaixa no cenário geral de ameaças. Para este atributo:

  • ATT&CK Framework v16 está suportado.
  • Cada técnica deve pertencer a pelo menos uma das listas tactics.
  • Os nomes não podem incluir espaços. Por exemplo: T1078 ou T1078.001.
  • Pode ser definido um máximo de 10 técnicas por regra.

Este campo é obrigatório.

Query

O query atributo define a lógica de deteção. Recomendamos que escreva a consulta no KQL e certifique-se de que está estruturada e é fácil de compreender. Recomendamos que você crie uma consulta eficiente otimizada para desempenho para garantir que ela possa ser executada em grandes conjuntos de dados sem afetar o desempenho. Certifique-se de que sua consulta atende aos seguintes critérios.

Limite a consulta a 10.000 caracteres. Se a seção de consulta exceder esse limite, considere reduzir 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ê ultrapasse o limite. Recomendamos que você mova essas listas para uma das seguintes opções:

Cada linha no corpo da consulta deve ter pelo menos um espaço no início, mas dois espaços são padrão para oferecer suporte à legibilidade.

Quando você envia uma consulta para um tipo de dados que não está presente na pasta Deteções ou Consultas de Caça, nomeie a subpasta que contém os arquivos YAML após a tabela que está sendo consultada. Por exemplo, se a sua consulta pertencer à tabela AzureDevOpsAuditing, crie uma pasta chamada AzureDevOpsAuditing.

Defina nomes legíveis por humanos para constantes explícitas:

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

É altamente recomendável que você use comentários para esclarecer a consulta. Evite adicionar comentários no final de uma linha de declaração de consulta. Em vez disso, adicione seus comentários em uma linha separada. Por exemplo:

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

Se você estiver fazendo referência a um analisador em vez de um nome de tabela, garanta clareza na descrição incluindo um comentário ao lado da referência da função do analisador. O analisador deve ser importado para o espaço de trabalho primeiro. Caso contrário, as consultas não reconhecerão isso como válido.

Certifique-se de que todos os campos de entidade disponíveis sejam retornados para fins de mapeamento. (Consulte a secção de mapeamentos de entidade.) Saneie a tabela retornada para que ela forneça apenas as propriedades que necessita investigar mais. Você não precisa de um TimeGenerated filtro quando usa um comando simples lookback em toda a consulta. O queryPeriod valor no YAML controla esse processo.

Para linha de base ou para executar uma comparação histórica, como comparar hoje com os sete dias anteriores, inclua um filtro com limite de tempo, como | where TimeGenerated >= ago(lookback), porque o modelo YAML atualmente não oferece suporte a vários queryPeriod valores. Evite usar períodos de tempo inferiores a um dia, a menos que haja um motivo específico. Não recomendamos prazos superiores a 14 dias devido a potenciais impactos no desempenho.

Resuma quando necessário. Certifique-se de incluir o campo de tempo (geralmente TimeGenerated) porque você precisa dele no campo de entidade. Inclua tanto os valores min() como max() da seguinte forma: | summarize StartTime = max(TimeGenerated), EndTime = min(TimeGenerated). Use os termos StartTime e EndTime exclusivamente. Não atribua aos campos os nomes StartTimeUtc ou EndTimeUtc, porque esses nomes podem entrar em conflito com as preferências do utilizador.

Além disso, inclua o maior número possível de campos para ajudar o usuário a entender o contexto do alerta. Recomendamos que você inclua pelo menos uma das entidades principais: Host, Account, ou IP.

Os nomes das colunas na sua tabela personalizada devem usar camelCase (por exemplo, SrcIpAddr ou UserName).

Este campo é obrigatório.

Configurações de agrupamento de eventos

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

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

    eventGroupingSettings:
aggregationKind: SingleAlert

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

    eventGroupingSettings:
aggregationKind: AlertPerResult

Mapeamentos de entidades

O entityMappings atributo é integral quando você configura regras de análise agendadas. Ele enriquece a saída da consulta (alertas e incidentes) com informações essenciais que servem como blocos de construção de quaisquer processos de investigação e ações corretivas que se seguem.

O entityType representa a lista padrão de entidades reconhecidas pelo Microsoft Sentinel. Os tipos suportados incluem Account, Host, IP, URLFile, Process, DNS, AzureResource, FileHashRegistryKeyRegistryValueSecurityGroupMailbox, e .MailMessage Consulte os valores permitidos na coluna Tipo de entidade na tabela de Mapeamento de entidade.

Este campo é obrigatório.

Mapeamentos de campos

O fieldMappings atributo representa o identificador do campo na saída da consulta que corresponde ao tipo de entidade. Consulte os valores permitidos sob o valor da coluna de identificadores na tabela de mapeamento de entidade. 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 customDetails atributo integra dados de eventos em alertas, tornando-os visíveis em incidentes de segurança para triagem, investigação e resposta mais rápidas. Os detalhes personalizados são pares de chave/valor referentes aos nomes de propriedades e colunas. Para obter mais informações, consulte Detalhes de eventos personalizados do Surface em alertas no Microsoft Sentinel. Até 20 detalhes personalizados (ou seja, pares chave/valor) podem ser definidos por modelo. Os nomes-chave devem ter 20 caracteres ou menos.

    customDetails:
      Computers: Computer
      IPs: ComputerIP

Sobrescrever detalhes do alerta

O alertDetailsOverride atributo é 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 ao analista quando o alerta for acionado. Ao usar esse recurso, você garante que os analistas recebam informações pertinentes, incluindo nomes de entidades relevantes, para facilitar uma compreensão mais rápida e precisa do incidente. As limitações incluem:

  • Um máximo de três parâmetros podem ser incluídos no name ou description.

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

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

        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 do incidente

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

Versão

Quando um cliente cria uma nova consulta de busca a partir do modelo, o modelo version é salvo. Se uma nova versão do modelo for publicada, os clientes serão notificados na UX. As versões seguem o formato a, be c, em que a é a versão principal, b é a versão secundária, e c é o patch. O campo de versão é a última linha do modelo.

Este campo é obrigatório.

  • Last updated on