sentinel-detection-engineering

Production-grade KQL detection rules for Microsoft Sentinel, mapped to MITRE ATT&CK.

Built by a Cybersecurity Architect for real-world SOC deployment. Every rule includes tuning guidance, false positive analysis, and entity mappings.

---

Purpose

This repository contains production-ready Microsoft Sentinel detection rules that a security team can deploy directly into their environment. Rules are built to the same standard used in real enterprise SOC deployments — not academic exercises.

Every detection rule in this repository:

• Is mapped to a specific MITRE ATT&CK technique
• • Uses let variables for all tunable thresholds (never hardcoded)
  • • Includes tuning guidance for different environment sizes
    • • Includes entity mappings for Sentinel incident enrichment

      • • Includes false positive guidance with specific investigation steps

        • • Follows the KQL style guide in docs/kql-style-guide.md

          ---

Problem Statement

Most public Sentinel detection rule repositories suffer from three problems:

1. No tuning guidance — rules fire constantly in real environments, get disabled, and provide zero value
2. 2. No false positive analysis — analysts waste hours investigating benign activity

   3. 3. KQL written for demos, not production — hardcoded thresholds, missing filters, poor performance at scale

      4. This repository solves all three.

      5. ---

      6. Repository Structure

sentinel-detection-engineering/
├── detections/
│   ├── identity/
│   │   ├── mfa-fatigue-attack.yaml          # T1621 — MFA Fatigue
│   │   └── impossible-travel.yaml           # T1078 — Impossible Travel
│   ├── persistence/
│   │   └── privileged-role-assignment.yaml  # T1098.003 — Privileged Role Assignment
│   ├── lateral-movement/
│   │   └── pass-the-hash.yaml               # T1550.002 — Pass-the-Hash
│   └── cloud/
│       └── azure-storage-exfiltration.yaml  # T1567.002 — Storage Exfiltration
├── docs/
│   ├── mitre-coverage-matrix.md
│   └── kql-style-guide.md
└── README.md

---

MITRE ATT&CK Coverage

Tactic	Technique	Rule Name	Severity	Status	Data Source
Credential Access	T1621 — MFA Fatigue	mfa-fatigue-attack	High	✅ Live	SigninLogs
Initial Access / Defense Evasion	T1078 — Valid Accounts	impossible-travel	High	✅ Live	SigninLogs
Persistence	T1098.003 — Account Manipulation	privileged-role-assignment	High	✅ Live	AuditLogs
Lateral Movement	T1550.002 — Pass the Hash	pass-the-hash	High	✅ Live	SecurityEvent
Exfiltration	T1567.002 — Exfiltration to Cloud Storage	azure-storage-exfiltration	High	✅ Live	StorageBlobLogs
Collection	T1213.003 — SharePoint Data	sharepoint-mass-download	Medium	🗓️ Planned	OfficeActivity
Command & Control	T1071.001 — Web Protocols	c2-beaconing-dns	High	🗓️ Planned	DnsEvents
Discovery	T1087 — Account Discovery	ldap-recon	Medium	🗓️ Planned	SecurityEvent

Live: 5 rules across 5 tactic categories | Planned: 3 rules

---

Detection Rule Template

All rules follow this structure. See any .yaml file for a full production example.

id: <uuid>
name: <descriptive name>
description: |
  <what it detects and why it matters>
severity: High | Medium | Low
status: Production | Testing | Deprecated
requiredDataConnectors: [...]
tactics: [...]
techniques: [...]
# TUNING GUIDANCE: <environment-specific threshold guidance>
query: |
  let Threshold = 10;  # Always use let variables
  TableName
  | where TimeGenerated >= ago(1h)  # TimeGenerated always first
  ...
entityMappings: [...]
customDetails: {...}
falsePositiveGuidance: |
  <specific scenarios with remediation steps>

---

KQL Style Standards

Detailed in docs/kql-style-guide.md. Key rules:

• TimeGenerated filter always first where clause
• • All thresholds in let variables at top of query — never inline
  • • Use dynamic([...]) lists for exclusion sets, not repeated != chains
    • • make_set() always capped with a limit (e.g., make_set(Column, 20))

      • • Performance filter before join, never after

        • • Every column projected explicitly — never use | project *

          ---

Security Considerations

These are detection rules only — they generate alerts but do not block or remediate. Before deploying:

• Test in a non-production workspace first
• • Establish a 2-week baseline before enabling threshold-based rules
  • • Review all ExcludedAccounts and ExcludedSourceIPs lists against your environment

    • • Validate entity mappings match your workspace schema

      • • Connect all required data connectors listed in each rule's requiredDataConnectors field

        ---

Author

Surya | Cybersecurity Architect | CISSP

Specializing in Microsoft Sentinel, Azure Security, and Detection Engineering.

---

References

• MITRE ATT&CK Framework
• • Microsoft Sentinel Documentation
  • • KQL Reference
    • • Sentinel Analytics Rules Schema