Azure Sentinel Detection Engineering

Инженерная разработка обнаружений в работающей среде Microsoft Sentinel и Defender XDR, которой я управляю. Девять пользовательских аналитических правил охватывают три плоскости, каждое сопоставлено с MITRE ATT&CK и проверено от начала до конца: контролируемое действие запускает правило, правило создаёт инцидент, а инцидент расследуется и документируется. Семь правил следят за плоскостью управления Azure (AzureActivity), включая многостадийную корреляцию и правило с контентом на основе ARG; одно — за конечной точкой (Defender for Endpoint), причём Defender Vulnerability Management питает библиотеку охоты; одно — за идентификацией (Entra ID SigninLogs). Все развёртываются одним и тем же конвейером с проверкой через PR.

Арендатор с одним клиентом, которым я управляю от начала до конца. Идентификаторы арендатора, подписки и любая PII-информация скрыты на всех скриншотах.

Показатели отслеживаемы: покрытие — к слою ATT&CK, валидация — к RESULTS.md. Умышленно отсутствует бейдж доли ложных срабатываний: в среде с одним арендатором невозможно получить осмысленный уровень ложных срабатываний, поэтому репозиторий сообщает о измеренных ложных срабатываниях на реальном безвредном наборе, а не о вымышленном проценте (metrics.yaml полностью это объясняет).

---

Краткий старт

Запустите модульные тесты обнаружений на форке, Azure не требуется. Каждое правило использует реальный KQL для работы с синтетическими тестовыми данными в локальном эмуляторе Kusto, поэтому логика обнаружения проверяема без моего арендатора:

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

Это точная проверка, которую CI выполняет для каждого пул-реквеста (detection-tests): она подтверждает, что каждое правило срабатывает на вредоносные тестовые данные и молчит на безвредных. Живой тестовый стенд в validation/ идёт дальше: запускает реальный набор безвредных и атакующих действий в арендаторе и измеряет истинные срабатывания и ложные срабатывания, но для этого нужна собственная подписка Azure и az login (см. validation/README), поэтому это не «локально». Конвейер развёртывания: docs/03. Предложение правила: CONTRIBUTING.

Зачем это существует

Обнаружение заслуживает доверия только тогда, когда можно показать его срабатывание. Этот репозиторий замыкает этот цикл для трёх плоскостей: плоскости управления Azure, конечной точки и идентификации: логика правила, контролируемый триггер, созданный инцидент, расследование и сопоставление с MITRE. Он выходит за рамки правил на одно событие, включая многостадийную корреляцию (предоставление прав, затем развёртывание) и правило с учётом контента, которое объединяет данные Azure Resource Graph о состоянии с событием изменения. Это аналитические правила Sentinel, KQL и реагирование на инциденты на основе реальной телеметрии, а не синтетических образцов.

Обнаружение как код

Правила не вводятся щелчками в портале. Они представляют собой версионированные YAML, развёртываемые конвейером с проверкой через PR. Редактирование обнаружения означает открытие пул-реквеста; CI выполняет проверку, рецензент одобряет, и слияние в main развёртывает правило в Sentinel через OIDC (без сохранённых секретов), идемпотентно по GUID правила (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 · Конвейер: .github/workflows/deploy-detections.yml · Развёртыватель/проверяющий: cicd/ · Подробности: docs/03-cicd.md

Через это прошло реальное изменение: PR #1 ужесточил порог DET-001 (с 10 до 8); CI проверил его, и слияние развернуло обновлённое правило в работающем sc200-ws. Этот шаг — автоматическое развёртывание правил из git с проверенным PR — отличает инженера по обнаружениям от аналитика, завершившего курс.

Архитектура

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]

Каталог обнаружений