azure-sentinel-detection-engineering

9 обнаружений KQL, сопоставленных с MITRE ATT&CK, в реальной среде Microsoft Sentinel + Defender XDR (control-plane, endpoint, identity), с PR-управляемым конвейером Detection-as-Code (GitHub Actions, OIDC), сценариями SOAR и картой контроля SOC 2.

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

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

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

Это точная проверка, которую 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).

• Источник истины: detections/rules/*.yaml · Конвейер: .github/workflows/deploy-detections.yml · Развёртыватель/проверяющий: cicd/ · Подробности: docs/03-cicd.md

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

Архитектура

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

Результаты

Каждое обнаружение было запущено с контролируемым, самоотменяемым административным действием и создало реальный инцидент:

Текущее рабочее состояние рабочей области: 10 аналитических правил включено, 4 активных коннектора данных, правило автоматизации и поступающие живые данные. 10 включённых правил — это девять пользовательских правил [DET] по расписанию из этого каталога плюс встроенное правило слияния Microsoft (Advanced Multistage Attack Detection), которое включено по умолчанию и не создано здесь; число 9 в другом месте этого README учитывает только пользовательские правила.

Пять инцидентов оформлены как полные расследования:

• INV-01, Массовое удаление ресурсов (Высокая)
• INV-02, Эскалация привилегий RBAC
• INV-03, LSASS-доступ к учётным данным (Высокая), конечная точка, Инцидент #65
• INV-04, NSG открыт входящий доступ от Any (Высокая), корреляция контента ARG (DET-009)
• INV-05, Предоставление привилегий затем развёртывание (Высокая), многостадийная корреляция (DET-007)

Помимо одноразовых запусков, тестовый стенд валидации запускает реальный набор безвредных + атакующих действий в арендаторе и выполняет KQL каждого правила по нему, так что ложные срабатывания измеряются, а не предполагаются. Последний запуск (результаты): 5/5 сценариев атак сработали (DET-002/003/004/007/009) и 0 ложных срабатываний на безвредном потоке (развёртывание владельцем из белого списка, удаления ниже порога, развёртывание без предоставления прав). Он не имитирует производственный объём; он преобразует «0% ЛС при N=1» в измеренное «0 ложных срабатываний на реальном безвредном наборе».

Покрытие ATT&CK

Карта покрытия с явными пробелами честнее, чем просто список правил. Слой ATT&CK Navigator (как загрузить) показывает и то, и другое:

Пробелы — не статический текст. Каждый из них — это живая задача detection-gap, так что дорожная карта представляет собой кликабельный бэклог.

Почему именно эти правила, а не другие: docs/08, стратегия обнаружения и модель угроз сопоставляет каталог с облачной цепочкой атак и ранжирует пробелы по риску. Как настраивается правило: docs/09, измеренный цикл настройки DET-005 превращает правило, которое «срабатывает на каждую запись», в измеренное нулевое количество ложных срабатываний на тестовом стенде валидации.

Автоматизированное реагирование (SOAR)

Обнаружение с наивысшей степенью серьёзности замыкает цикл от обнаружения до реагирования. Правило автоматизации Sentinel запускает Logic App playbook для каждого инцидента DET-004 (массовое удаление): он размещает комментарий с обогащением, содержащий рекомендуемые меры сдерживания (отключить вызывающего, заблокировать группы ресурсов, восстановить, охотиться). Playbook аутентифицируется с помощью собственного управляемого удостоверения напрямую к ARM API, без секретов и без внешнего коннектора.

Второй playbook расширяет цикл до обнаружение → реагирование → AI-расследование с помощью Microsoft Security Copilot: promptbook + Logic App вызывает promptbook Copilot для того же инцидента DET-004 и публикует сводку AI-расследования в виде комментария. Он построен и развёртывается без каких-либо вычислительных ресурсов; живой захват AI-сводки выполняется в одном ограниченном по стоимости (~$4) платном сеансе и не заявляется до тех пор, пока не будет захвачен. Стоимость и процедура снятия: docs/06.

Управление конечными точками и уязвимостями

Обнаружения начинаются на плоскости управления Azure; этот этап добавляет плоскость конечной точки. Сенсор Defender for Endpoint на хосте Windows подаёт данные в ту же рабочую область, поэтому конвейер Detection-as-Code развёртывает правило для конечной точки, DET-006 LSASS credential access, рядом с правилами плоскости управления. DET-006 является многовходовым и подтверждённым: три метода кражи учётных данных были запущены против сенсора, защищённый хост (LSASS RunAsPPL, AMSI, поведенческая защита) предотвратил каждый, и правило сработало на основе соответствующих оповещений Defender, создав инцидент (INV-03). Defender Vulnerability Management добавляет второй вход: библиотеку охоты, которая выявляет критические CVE по уязвимому ПО, неудачные базовые конфигурации безопасности и уязвимые активы под активными оповещениями. Таблицы DeviceTvm* существуют только в расширенной охоте Defender, поэтому эти корреляции являются охотами, а не развёрнутыми правилами, и репозиторий указывает, где фактически выполняется каждый запрос. Архитектура и поток данных: docs/07.

Устранение проблем с состоянием системы

Обнаружения следят за атаками; этот этап считывает собственный показатель состояния арендатора и исправляет то, что он отмечает, а затем доказывает, что цифра изменилась. Базовый уровень Secure Score Defender for Cloud извлекается в виде машиночитаемого снимка с помощью collect-posture.ps1, так что состояние «до/после» — это отличие файлов, а не сравнение скриншотов. На исходном уровне оценка составляет 68.81% (21.33 / 31), а разбивка по элементам управления показывает, что весь разрыв в 9.67 пункта приходится на четыре элемента управления (шифрование в покое, доступ и разрешения, сетевой доступ, аудит). Устранение упорядочено по радиусу поражения, сначала аддитивные исправления, и каждый элемент сопоставлен с правилом каталога, которое обнаруживает его регрессию (экспонирование хранилища — DET-002 / DET-009, разрастание RBAC — DET-003 / DET-007, потеря журналирования — весь каталог). В этот раз были применены три исправления и проверены на уровне ресурса: контакт по безопасности и уведомления об оповещениях, диагностическое журналирование на обоих playbook SOAR (+1 аудит) и шифрование на хосте для виртуальной машины сенсора (+4 шифрования в покое). Defender for Cloud повторно оценивает и пересчитывает оценку в течение следующих 24–72 часов, поэтому оценка «после» документируется как последующее наблюдение, а не утверждается сейчас. Полный метод, упорядоченный план и таблица привязки к обнаружениям: docs/10, устранение проблем с состоянием.

Соответствие контролю SOC 2

Эта работа поддерживает признанную структуру контроля, поэтому репозиторий указывает, где. Каждая часть каталога сопоставляется с критериями доверия SOC 2: каталог из девяти правил и инциденты — с серией мониторинга и реагирования (CC7.2–CC7.4), playbook SOAR — с реагированием на инциденты (CC7.4), конвейер Detection-as-Code с проверкой через PR — с управлением изменениями (CC8.1), а тестовый стенд валидации и сравнение состояния «до/после» — с эффективностью функционирования управления (CC4.1). Это сформулировано как сопоставление, а не как заявление о соответствии: это один арендатор, которым я управляю, а не аудированная организация, поэтому документ сопоставляет технические действия по управлению и явно указывает на обёртку управления, необходимую для реального отчёта SOC 2, которую репозиторий обнаружений не несёт. Полная таблица по критериям и примечание «как это читается при аудите»: docs/11, сопоставление с управлением SOC 2.

Структура репозитория

Продемонстрированные навыки

KQL · Аналитические правила по расписанию Microsoft Sentinel · Правила многостадийной корреляции · Обнаружение идентификации Entra ID (SigninLogs) · Списки наблюдения белого списка (_GetWatchlist) · Контент состояния Azure Resource Graph (запланированное действие) · Microsoft Defender XDR · Microsoft Defender for Endpoint · Defender Vulnerability Management (TVM) · Расширенная охота (таблицы Device / DeviceTvm) · Microsoft Secure Score · Устранение проблем с состоянием Defender for Cloud (CSPM, MCSB) · Сопоставление с общими критериями SOC 2 · Detection-as-Code (GitHub Actions, OIDC) · SOAR (правила автоматизации Logic Apps) · Sigma (не зависит от вендора) · Валидация Atomic Red Team · Обработка и расследование инцидентов · Сопоставление с MITRE ATT&CK · Мониторинг плоскости управления Azure (Activity Log).

Вклад

Это личное портфолио, но оно структурировано так, что изменение обнаружения — это пул-реквест, который можно проверить, а не щелчок в портале. Если вы форкнули репозиторий или хотите предложить правило, CONTRIBUTING.md описывает рабочий процесс: отредактируйте YAML правила, сгенерируйте зеркало KQL, расширьте тестовый набор, запустите модульные тесты локально и откройте PR, который будет проверен тем же CI.

Сертификация

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

Отказ от ответственности

Среда, которой я управляю, не является производственным арендатором работодателя или третьей стороны. Обнаружения проверяются с помощью контролируемых, самоотменяемых административных действий над моими собственными ресурсами; никакие производственные системы и третьи стороны не задействованы. Идентификаторы арендатора, подписки и PII скрыты на всех скриншотах.

Лицензия

MIT