Как написать Analytics Rule в Microsoft Sentinel

Шаг 1: Напишите спецификацию Detection перед KQL

Use Case должен отвечать на четкие вопросы: какое поведение мы будем обнаруживать? Почему оно опасно? Какие Data sources необходимы? Какова Expected benign activity? Кто Owner? Что будет делать аналитик, когда правило сработает? С какой MITRE technique оно связано?

Также определите границы. Правило не доказывает Account compromise. Оно обнаруживает Pattern, который требует расследования. Если есть успех, это может повысить Priority, но все равно необходимо убедиться в последовательности и контексте.

Шаг 2: Убедитесь в готовности данных

Откройте таблицу и проверьте Sample events. Является ли ResultType числом или строкой? Является ли IPAddress пустым в некоторых событиях? Появляются ли Service principals рядом с пользователями? Какова Ingestion delay? Существуют ли Tenant или Application, которые требуют исключения?

Правило, основанное на нестабильном поле, сломается. Задокументируйте Schema, Connector, Normalization и Data health query. Если источник перестает отправлять данные, Dashboard должен выдавать предупреждение; «нет Alerts» не обязательно означает безопасное состояние.

Шаг 3: Напишите Query, которая возвращает полезные Evidence

Базовая Query для Password Spray в лаборатории может группировать сбои по IP и временному окну и требовать определенное количество уникальных пользователей:

let Lookback = 15m;
let MinimumAttempts = 20;
let MinimumUsers = 5;
SigninLogs
| where TimeGenerated > ago(Lookback)
| where tostring(ResultType) != "0"
| summarize Attempts=count(),
            Users=dcount(UserPrincipalName),
            UserList=make_set(UserPrincipalName, 20),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
  by IPAddress, bin(TimeGenerated, 5m)
| where Attempts >= MinimumAttempts and Users >= MinimumUsers
| project TimeGenerated, IPAddress, Attempts, Users, UserList, FirstSeen, LastSeen

Результат должен содержать поля, необходимые аналитику, и поля, которые будут сопоставлены с Entities. В данном случае IPAddress является центральной Entity, а UserList — Context. Динамический список пользователей не обязательно подходит для сопоставления с одной учетной записью, поэтому можно создать Alert по IP и добавить Custom details, или изменить структуру результата в соответствии с Workflow.

Проверьте Query для нескольких диапазонов: час, день и неделя. Вручную пометьте True, False и Benign Positives. Посмотрите, обнаруживает ли оно активность VPN или Health checks. Не корректируйте Threshold только для того, чтобы получить ноль Alerts.

Шаг 4: Частота и Lookback

Query frequency определяет, как часто выполняется правило. Query period или Lookback определяет, как далеко назад оно проверяет данные. Если правило выполняется каждые пять минут и проверяет 15 минут, один и тот же Pattern может появиться в нескольких выполнениях. Механизмы Event grouping, Alert grouping или Suppression могут уменьшить дублирование, но необходимо понимать их влияние.

Lookback должен быть достаточно длинным, чтобы охватить Ingestion delay и обнаружить поведение, но не слишком широким. Медленный Password Spray может потребовать более широкого окна или другого Baseline. Слишком быстрое правило может создать шум; слишком медленное правило увеличивает время обнаружения.

Шаг 5: Severity, MITRE и сведения об Alert

Severity должна отражать риск при выполнении условия, а не конечный результат расследования. Password Spray без успеха может быть Medium, но попытка против Privileged учетных записей или успех после сбоев может оправдать другую оценку. Можно использовать Alert details override для динамического отображения IP, пользователя или Count в заголовке, сохраняя при этом читаемый заголовок.

Сопоставление MITRE ATT&CK помогает объяснить поведение противника и построить Coverage map. Выберите Tactics и Techniques, которые соответствуют фактической логике. Не сопоставляйте длинный список только для того, чтобы выглядеть всеобъемлющим.

Custom details должны отображать Context, который сокращает Triage: Attempts, Users, FirstSeen, LastSeen, Application или Tenant. Избегайте передачи конфиденциальной информации, которая не требуется.

Шаг 6: Сопоставление сущностей

Entity mapping позволяет Sentinel идентифицировать IP, Account, Host, URL и многое другое. Качественная Entity позволяет проводить Investigation, Enrichment, UEBA и связываться с другими Incidents. Убедитесь, что поле в выходных данных является Scalar и имеет соответствующий формат.

В примере IP.Address сопоставляется с IPAddress. Если правило возвращает один UserPrincipalName для каждой строки, можно сопоставить Account.FullName или AadUserId в соответствии с Schema. Когда Query суммирует многих пользователей в списке, не заставляйте сопоставлять, которое не представляет одну Entity.

Шаг 7: Группировка событий и группировка предупреждений

Event grouping определяет, станет ли каждая строка Query отдельным Alert или все результаты будут объединены. Если каждый IP является отдельным Case, строка для каждого IP и Alert для каждого Result могут быть логичными. Если все объединено в один Alert, аналитик может получить огромный Incident с несвязанными IP-адресами.

Alert grouping может присоединять Alerts к Incident по Entities или деталям. Определите окно и обнаружение реальной связи. Слишком агрессивная Grouping скрывает развитие и смешивает Scopes; слишком слабая Grouping создает Incident для каждого запуска.

Шаг 8: Автоматизация и задачи

На первом этапе автоматизация может назначить Owner, добавить Tags, создать Tasks, обогатить IP или отправить Notification. Автоматические действия Containment требуют высокого Confidence, Exceptions, утверждения и возможности Rollback. Новое Detection обычно требует периода Monitor перед значимой автоматической реакцией.

Приложите Tasks, которые направляют аналитика: проверьте успехи с того же IP, проверьте MFA, проверьте Reputation, ищите дальнейшую активность и свяжитесь с владельцем учетной записи. Таким образом, Rule генерирует процесс, а не только Alert.

Тестирование и настройка

1. Вручную выполните Query на исторических данных и отметьте результаты.
2. Выполните Unit test с имитированными событиями, представляющими Positive и Negative cases.
3. Активируйте Rule в режиме мониторинга без опасной Automation.
4. Измерьте Volume, True/False/Benign Positive, время Triage и качество Context.
5. Измените Threshold, exclusions или grouping с документацией причины.
6. Выполните Regression test после изменения Parser, Connector или Query.
7. Установите Review date и Owner; Rule без обслуживания становится долгом обнаружения.

Контрольный список перед запуском

• ✓Use Case и гипотеза задокументированы.
• ✓Data source, Schema и Delay проверены.
• ✓Query возвращает четкую единицу расследования.
• ✓Frequency и Lookback охватывают поведение без необычного дублирования.
• ✓Severity и MITRE соответствуют логике.
• ✓Entities и Custom details корректны.
• ✓Grouping проверен по нескольким результатам.
• ✓Существуют Playbook, Owner и Review date.
• ✓Проверены Privacy, стоимость и разрешения.
• ✓Существует Rollback для изменений и Automation.

Распространенные ошибки

• Начинать с Query, найденной в Интернете, без локального Use Case.
• Сопоставлять Entity из списка или из нестабильного поля.
• Использовать перекрывающийся Lookback без понимания дублирования.
• Устанавливать High severity для каждого Rule.
• Исключать IP или пользователя навсегда без Expiration.
• Добавлять Suppression, которое скрывает эскалацию активности.
• Активировать автоматическую блокировку до периода Tuning.
• Не проверять Data health и Schema changes.

Резюме и CTA

Выберите один Use Case в лаборатории и напишите одностраничную спецификацию Detection перед KQL. Затем создайте Rule, запустите ее на смоделированных данных и задокументируйте три результата: True, False и Benign Positive. Самое важное улучшение — это не еще одно условие в Query, а Incident, который следующий аналитик может быстро и последовательно расследовать.

Вопросы и ответы