azure-sentinel-detection-engineering

9 detecções KQL mapeadas pelo MITRE ATT&CK em um ambiente Microsoft Sentinel + Defender XDR ao vivo (plano de controle, endpoint, identidade), com um pipeline Detecção-como-Código protegido por PR (GitHub Actions, OIDC), playbooks SOAR e um mapeamento de controles SOC 2.

Os números são rastreáveis: cobertura para a camada ATT&CK, validação para RESULTS.md. Não há deliberadamente nenhum badge de taxa de falsos positivos: um ambiente de locatário único não pode produzir uma taxa de FP significativa, então o repositório relata falsos disparos medidos em um lote benigno real em vez de uma porcentagem fabricada (metrics.yaml declara isso na íntegra).

Início rápido

Execute os testes unitários de detecção em um fork, sem necessidade do Azure. O KQL real de cada regra é executado contra fixtures sintéticas em um emulador Kusto local, para que a lógica de detecção seja verificável sem meu locatário:

Esta é exatamente a verificação que o CI realiza em cada pull request (detection-tests): ele afirma que cada regra dispara em fixtures maliciosas e permanece silenciosa em benignas. O harness ao vivo em validation/ vai além, executando um lote real benigno e de ataque em um locatário e medindo verdadeiros positivos e falsos disparos, mas esse requer sua própria assinatura do Azure e az login (veja validation/README), então não é "local". Pipeline de implantação: docs/03. Contribuição de regra: CONTRIBUTING.

Por que isso existe

Uma detecção só é crível quando você pode mostrá-la disparando. Este repositório fecha esse ciclo em três planos: o plano de controle do Azure, o endpoint e a identidade: lógica da regra, acionador controlado, incidente gerado, investigação e mapeamento MITRE. Vai além de regras de evento único com uma correlação em vários estágios (concessão seguida de implantação) e uma regra ciente de conteúdo que une a postura do Azure Resource Graph ao evento de alteração. São regras analíticas do Sentinel, KQL e resposta a incidentes contra telemetria real, em vez de amostras sintéticas.

Detecção-como-Código

As regras não são clicadas no portal. Elas são YAML versionado implantado por um pipeline com gate de PR. Editar uma detecção significa abrir um pull request; o CI valida, um revisor aprova, e o merge para main a implanta no Sentinel via OIDC (sem segredos armazenados), idempotentemente pelo GUID da regra (API 2025-09-01).

• Fonte da verdade: detections/rules/*.yaml · Pipeline: .github/workflows/deploy-detections.yml · Implantador/validador: cicd/ · Detalhes: docs/03-cicd.md

Uma mudança real passou por ele: PR #1 apertou o limite do DET-001 (10 para 8); o CI validou, e o merge implantou na regra ativa sc200-ws. Esse passo - regras sendo implantadas automaticamente a partir do git por PR revisado - é o que separa um engenheiro de detecção de um analista que concluiu um curso.

Arquitetura

Catálogo de detecções

Resultados

Cada detecção foi acionada com uma ação administrativa controlada e auto-revertida e produziu um incidente real:

Estado operacional atual do workspace: 10 regras analíticas habilitadas, 4 conectores de dados ativos, uma regra de automação e dados ao vivo fluindo. As 10 regras habilitadas são as nove regras agendadas personalizadas [DET] deste catálogo mais a regra Fusion integrada da Microsoft (Advanced Multistage Attack Detection), que está ativada por padrão e não foi criada aqui; o número nove mencionado em outras partes deste README conta apenas as regras personalizadas.

Cinco incidentes são documentados como investigações completas:

• INV-01, Exclusão em massa de recursos (Alto)
• INV-02, Escalação de privilégio RBAC
• INV-03, Acesso a credenciais LSASS (Alto), endpoint, Incidente #65
• INV-04, NSG aberto entrada de Any (Alto), correlação de conteúdo ARG (DET-009)
• INV-05, Concessão de privilégio seguida de implantação (Alto), correlação multi-estágio (DET-007)

Além de acionamentos únicos, um harness de validação executa um lote real benigno + ataque no locatário e executa o KQL de cada regra contra ele, de modo que os falsos positivos são medidos, não assumidos. Última execução (resultados): 5/5 cenários de ataque dispararam (DET-002/003/004/007/009) e 0 falsos disparos no fluxo benigno (implantação de proprietário na lista de permissões, exclusões abaixo do limite, implantação sem concessão). Ele não falsifica volume de produção; converte "0% FP em N=1" em um "0 falsos disparos medidos em um lote benigno real".

Cobertura ATT&CK

Um mapa de cobertura com lacunas explícitas é mais honesto do que uma lista de regras. A camada do ATT&CK Navigator (como carregar) mostra ambos:

As lacunas não são texto estático. Cada uma é uma issue viva detection-gap, então o roadmap é um backlog clicável.

Por que essas regras e não outras: docs/08, estratégia de detecção e modelo de ameaça mapeia o catálogo para uma cadeia de eliminação em nuvem e classifica as lacunas por risco. Como uma regra é ajustada: docs/09, um loop de ajuste medido do DET-005 leva uma regra de "dispara em toda escrita" para zero falsos positivos medidos no harness de validação.

Resposta automatizada (SOAR)

A detecção de maior severidade fecha o ciclo de detectar a responder. Uma regra de automação do Sentinel executa um playbook do Logic App em cada incidente DET-004 (exclusão em massa): ele posta um comentário de enriquecimento com a contenção recomendada (desabilitar o autor, bloquear os grupos de recursos, restaurar, caçar). O playbook autentica-se com sua própria identidade gerenciada diretamente na API ARM, sem segredos e sem conector externo.

Um segundo playbook estende o loop para detectar → responder → investigar com IA com Microsoft Security Copilot: um promptbook + Logic App invoca um promptbook do Copilot no mesmo incidente DET-004 e posta um resumo de investigação de IA como comentário. Ele é construído e implantado sem unidades de computação; a captura ao vivo do resumo de IA é executada em uma única janela paga com custo limitado (~$4) e não é reivindicada até ser capturada. Runbook de custo e desmontagem: docs/06.

Gerenciamento de endpoint e vulnerabilidades

As detecções começam no plano de controle do Azure; esta fase adiciona o plano do endpoint. Um sensor do Defender for Endpoint em um host Windows alimenta o mesmo workspace, de modo que o pipeline de Detecção-como-Código implanta uma regra de endpoint, DET-006 LSASS credential access, ao lado das regras do plano de controle. O DET-006 é multi-fonte e testemunhado: três técnicas de despejo de credenciais foram executadas contra o sensor, o host endurecido (LSASS RunAsPPL, AMSI, proteção comportamental) impediu todas, e a regra disparou com base nos alertas resultantes do Defender para gerar um incidente (INV-03). O Defender Vulnerability Management adiciona uma segunda entrada: uma biblioteca de caça que exibe CVEs críticas por software exposto, linhas de base de configuração segura com falha e ativos vulneráveis sob alerta ativo. As tabelas DeviceTvm* existem apenas na caça avançada do Defender, então essas correlações são caçadas, não regras implantadas, e o repositório diz onde cada consulta realmente é executada. Arquitetura e fluxo de dados: docs/07.

Remediação de postura

As detecções observam ataques; esta fase lê a própria pontuação de postura do locatário e corrige o que ela sinaliza, depois prova que o número mudou. A linha de base do Secure Score do Defender for Cloud é coletada como um snapshot legível por máquina por collect-posture.ps1, de modo que o antes/depois é um diff de arquivo, não uma comparação de captura de tela. Na linha de base, a pontuação é 68,81% (21,33 / 31), e a discriminação por controle coloca toda a lacuna de 9,67 pontos em quatro controles (criptografia em repouso, acesso e permissões, acesso à rede, auditoria). A remediação é ordenada por raio de explosão, correções aditivas primeiro, e cada item é mapeado para a regra do catálogo que captura sua regressão (exposição de armazenamento para DET-002 / DET-009, proliferação RBAC para DET-003 / DET-007, perda de registro para todo o catálogo). Três correções foram aplicadas nesta passagem e verificadas no nível do recurso: o contato de segurança e notificações de alerta, registro de diagnóstico em ambos os playbooks SOAR (+1 auditoria), e criptografia no host na VM do sensor (+4 criptografia em repouso). O Defender for Cloud reavalia e recalcula a pontuação nas 24 a 72 horas seguintes, então a pontuação posterior é documentada como acompanhamento, não afirmada agora. Método completo, plano ordenado e tabela de vinculação de detecção: docs/10, remediação de postura.

Mapeamento de controles SOC 2

Este trabalho suporta uma estrutura de controle reconhecida, então o repositório informa onde. Cada parte do catálogo mapeia para um Critério de Serviços de Confiança do SOC 2: o catálogo de nove regras e incidentes para a série monitorar-e-responder (CC7.2 a CC7.4), os playbooks SOAR para resposta a incidentes (CC7.4), o pipeline de Detecção-como-Código com gate de PR para gerenciamento de mudanças (CC8.1), e o harness de validação e postura antes/depois para eficácia operacional do controle (CC4.1). É apresentado como um mapeamento, não uma alegação de conformidade: este é um locatário que opero, não uma organização auditada, então o documento mapeia as atividades de controle técnico e é explícito sobre o invólucro de governança que um relatório SOC 2 real precisa e que um repositório de detecção não carrega. Tabela completa critério por critério e nota sobre como seria lido em uma auditoria: docs/11, mapeamento de controles SOC 2.

Estrutura do repositório

Habilidades demonstradas

KQL · Regras analíticas agendadas do Microsoft Sentinel · Regras de correlação multi-estágio · Detecção de identidade do Entra ID (SigninLogs) · Listas de permissão (_GetWatchlist) · Postura como conteúdo do Azure Resource Graph (Ação agendada) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · Caça avançada (tabelas Device / DeviceTvm) · Microsoft Secure Score · Remediação de postura do Defender for Cloud (CSPM, MCSB) · Mapeamento de controles Common Criteria do SOC 2 · Detecção-como-Código (GitHub Actions, OIDC) · SOAR (regras de automação do Logic Apps) · Sigma (neutro de fornecedor) · Validação com Atomic Red Team · Triagem e investigação de incidentes · Mapeamento MITRE ATT&CK · Monitoramento do plano de controle do Azure (Activity Log).

Contribuição

Este é um portfólio pessoal, mas está estruturado para que uma alteração de detecção seja um pull request revisável, não um clique no portal. Se você fizer um fork ou quiser propor uma regra, o CONTRIBUTING.md cobre o fluxo de trabalho: edite o YAML da regra, regenere o espelho KQL, estenda o fixture de teste, execute os testes unitários localmente e abra um PR que os mesmos gates do CI verificam.

Credenciais

Microsoft Certified: Security Operations Analyst Associate (SC-200).

Aviso Legal

Um ambiente que opero, não um locatário de produção de qualquer empregador ou terceiros. As detecções são validadas com ações administrativas controladas e auto-revertidas contra meus próprios recursos; nenhum sistema de produção e nenhum terceiro estão envolvidos. Identificadores de locatário e assinatura e PII estão ocultos em todas as capturas de tela.

Licença

MIT