ibondarenko1/azure-sentinel-detection-engineering9 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.
Engenharia de detecção em um ambiente Microsoft Sentinel e Defender XDR ao vivo que opero. Nove regras analíticas personalizadas abrangem três planos, cada uma mapeada para MITRE ATT&CK e comprovada de ponta a ponta: uma ação controlada aciona a regra, a regra gera um incidente, e o incidente é investigado e documentado. Sete monitoram o plano de controle do Azure (AzureActivity), incluindo uma correlação em vários estágios e uma regra com conteúdo baseado em ARG; uma monitora o endpoint (Defender for Endpoint), com o Defender Vulnerability Management alimentando uma biblioteca de caça; uma monitora identidade (Entra ID SigninLogs). Todas implantadas pelo mesmo pipeline com gate de PR.
Um ambiente de locatário único ao vivo que opero de ponta a ponta. Identificadores de locatário e assinatura e quaisquer PII estão ocultos em todas as capturas de tela.
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).
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:
git clone https://github.com/ibondarenko1/azure-sentinel-detection-engineering
cd azure-sentinel-detection-engineering
docker run -d --rm -p 8080:8080 -e ACCEPT_EULA=Y mcr.microsoft.com/azuredataexplorer/kustainer-linux:latest
pip install pyyaml
python tests/run-detection-tests.py
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.
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.
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).
flowchart LR
D[Edit rule YAML] --> PR[Pull request] --> V[CI validate] -->|review| M[Merge main] --> CD[OIDC deploy] --> S[Sentinel sc200-ws]
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.
flowchart LR
subgraph Sources
A[Microsoft Defender XDR<br/>Email · Endpoint]
B[Azure subscription<br/>Activity Log]
C[Entra ID<br/>sign-ins]
end
A --> W[Log Analytics workspace<br/>sc200-ws]
B --> W
C --> W
W --> R[9 scheduled<br/>analytics rules]
R --> I[Incidents]
I --> V[Investigation<br/>+ MITRE mapping]
