Como escrever uma Regra de Análise no Microsoft Sentinel

Passo 1: Escreva a especificação de Deteção antes da KQL

Um Caso de Uso deve responder a perguntas claras: Que comportamento vamos detetar? Por que é perigoso? Quais fontes de dados são necessárias? O que é uma atividade benigna esperada? Quem é o Dono? O que o analista fará quando a regra for acionada? A que técnica MITRE está relacionada?

Defina também limites. Uma Regra não prova um Account compromise. Ela identifica um Padrão que requer investigação. Se houver um sucesso, pode aumentar a Prioridade, mas ainda é preciso verificar a sequência e o contexto.

Passo 2: Verifique a prontidão dos Dados

Abra a tabela e verifique os Sample events. O ResultType é um número ou uma string? O IPAddress está vazio em alguns eventos? Os Service principals aparecem ao lado dos utilizadores? Qual é o Ingestion delay? Existem Tenant ou Application que exigem exclusão?

Uma Regra que se baseia num campo instável irá falhar. Documente o Schema, Connector, Normalization e Data health query. Se a fonte parar de enviar, um Dashboard deve alertar; “nenhum Alerta” não é necessariamente uma condição segura.

Passo 3: Escreva uma Query que retorne Evidências úteis

Uma Query básica para Password Spray num laboratório pode agrupar falhas por IP e janela de tempo e exigir um número de utilizadores únicos:

let Lookback = 15m;
let MinimumAttempts = 20;
let MinimumUsers = 5;
SigninLogs
| where TimeGenerated > ago(Lookback)
| where tostring(ResultType) != "0"
| summarize Attempts=count(),
            Users=dcount(UserPrincipalName),
            UserList=make_set(UserPrincipalName, 20),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
  by IPAddress, bin(TimeGenerated, 5m)
| where Attempts >= MinimumAttempts and Users >= MinimumUsers
| project TimeGenerated, IPAddress, Attempts, Users, UserList, FirstSeen, LastSeen

O resultado deve conter os campos que o analista necessita e os campos que serão mapeados para Entidades. Neste caso, o IPAddress é uma Entidade central, e UserList é Context. Uma lista dinâmica de utilizadores não é necessariamente adequada para mapear uma única Account, por isso pode-se criar um Alerta por IP e adicionar Custom details, ou alterar a estrutura do resultado de acordo com o Workflow.

Teste a Query em vários intervalos: hora, dia e semana. Marque manualmente Positivos Verdadeiros, Falsos e Benignos. Veja se ela deteta atividade de VPN ou Health checks. Não ajuste o Threshold apenas para obter zero Alertas.

Passo 4: Frequência e Lookback

A Query frequency determina quantas vezes a regra é executada. O Query period ou Lookback determina por quanto tempo ele verifica. Se uma Regra for executada a cada cinco minutos e verificar 15 minutos, o mesmo Padrão pode aparecer em várias execuções. Mecanismos de Event grouping, Alert grouping ou Suppression podem reduzir duplicações, mas é preciso entender o impacto.

O Lookback deve ser longo o suficiente para cobrir o Ingestion delay e detetar o comportamento, mas não muito amplo. Um Password Spray lento pode exigir uma janela maior ou uma Linha de Base diferente. Uma Regra muito rápida pode gerar ruído; uma Regra muito lenta aumenta o tempo de deteção.

Passo 5: Severity, MITRE e detalhes do Alerta

A Severity deve refletir o risco quando a condição é satisfeita, não o resultado final da investigação. Um Password Spray sem sucesso pode ser Médio, mas uma tentativa contra contas Privileged ou sucesso após falhas pode justificar uma classificação diferente. Pode-se usar o Alert details override para exibir IP, utilizador ou Contagem no título dinamicamente, mantendo um título legível.

O mapeamento MITRE ATT&CK ajuda a explicar o comportamento do adversário e a construir um mapa de Cobertura. Escolha as Táticas e Técnicas que se encaixam na lógica real. Não mapeie uma lista longa apenas para parecer abrangente.

Os Custom details devem apresentar Contexto que encurte o Triage: Tentativas, Utilizadores, Primeira Vez Visto, Última Vez Visto, Aplicação ou Tenant. Evite a transferência de informações sensíveis desnecessárias.

Passo 6: Mapeamento de Entidades

O mapeamento de Entidades permite que o Sentinel identifique IP, Account, Host, URL e outros. Uma Entidade de qualidade permite Investigação, Enriquecimento, UEBA e ligação a outros Incidentes. Certifique-se de que o campo na saída é Escalar e no formato apropriado.

No exemplo, mapeamos IP.Address para IPAddress. Se a regra retornar um único UserPrincipalName por linha, pode-se mapear Account.FullName ou AadUserId dependendo do Schema. Quando uma Query resume muitos utilizadores numa lista, não force um Mapeamento que não represente uma única Entidade.

Passo 7: Agrupamento de Eventos e Agrupamento de Alertas

O Event grouping determina se cada linha da Query se tornará um Alerta separado ou se todos os resultados serão agregados. Se cada IP for um Caso separado, uma linha para cada IP e um Alerta para cada Resultado podem ser lógicos. Se tudo for agregado num único Alerta, um analista pode receber um Incidente enorme com IPs não relacionados.

O Alert grouping pode anexar Alertas a um Incidente por Entidades ou detalhes. Defina uma janela e a identificação de uma conexão real. Um agrupamento demasiado agressivo esconde o desenvolvimento e mistura Scopes; um agrupamento demasiado fraco cria um Incidente para cada execução.

Passo 8: Automação e Tarefas

Na primeira fase, a automação pode atribuir um Dono, adicionar Tags, criar Tarefas, enriquecer IP ou enviar Notificações. Ações de Contenção automáticas exigem Alta Confiança, Exceções, aprovação e capacidade de Rollback. Uma Deteção nova geralmente precisa de um período de Monitorização antes de uma resposta automática significativa.

Anexe Tarefas que orientem o analista: verifique sucessos do mesmo IP, verifique MFA, verifique Reputação, procure atividade subsequente e contacte o proprietário da conta. Assim, a Regra gera um processo e não apenas um Alerta.

Testes e Ajustes

1. Execute a Query manualmente em dados históricos e marque os resultados.
2. Teste a Unidade com eventos simulados que representam casos Positivos e Negativos.
3. Ative a Regra em modo de monitorização sem Automação perigosa.
4. Meça Volume, Positivos Verdadeiros/Falsos/Benignos, tempo de Triage e qualidade do Contexto.
5. Altere Threshold, exclusões ou agrupamento com documentação da razão.
6. Realize um teste de Regressão após a alteração do Parser, Connector ou Query.
7. Defina uma data de Revisão e um Dono; uma Regra sem manutenção torna-se uma dívida de deteção.

Checklist antes da ativação

• ✓Caso de Uso e hipótese documentados.
• ✓Fonte de dados, Schema e Atraso verificados.
• ✓A Query retorna uma unidade de investigação clara.
• ✓Frequência e Lookback cobrem o comportamento sem duplicação excessiva.
• ✓Severity e MITRE correspondem à lógica.
• ✓Entidades e Custom details estão corretos.
• ✓O agrupamento foi testado em vários resultados.
• ✓Existem Playbook, Dono e data de Revisão.
• ✓Privacidade, custo e permissões verificados.
• ✓Existe Rollback para alterações e Automação.

Erros comuns

• Começar com uma Query encontrada na internet sem um Caso de Uso local.
• Mapear uma Entidade de uma lista ou de um campo instável.
• Usar um Lookback sobreposto sem entender as duplicações.
• Definir Severity Alta para cada Regra.
• Excluir um IP ou utilizador permanentemente sem Expiration.
• Adicionar Supressão que esconde uma escalada de atividade.
• Ativar um bloqueio automático antes de um período de Ajuste.
• Não verificar a saúde dos Dados e as alterações de Schema.

Resumo e CTA

Escolha um Caso de Uso num laboratório e escreva uma especificação de Deteção de uma página antes da KQL. Em seguida, construa a Regra, execute-a em dados simulados e documente três resultados: Verdadeiro, Falso e Positivo Benigno. A melhoria mais importante não é mais uma condição na Query, mas um Incidente que o próximo analista pode investigar de forma rápida e consistente.

Perguntas frequentes