Elastic Security: Создание правил обнаружения и руководство по расследованию

Шаг 1: Определите вариант использования и выберите тип правила

Начните с поведенческого утверждения: «Выявление процесса определенного типа, запускаемого в неожиданном контексте на пользовательских рабочих станциях». Затем определите, что считается совпадением, какой контекст необходим и что является законным объяснением. Только после этого выбирайте тип правила.

Неправильный выбор приводит к сложному запросу или нестабильным оповещениям. Если порядок событий имеет значение, EQL более естественен, чем ES|QL. Если требуется агрегация, ES|QL или Threshold более подходят. Custom query хорош для прямого сопоставления полей.

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

Elastic Common Schema — ECS — определяет общие имена и структуры, такие как event.category, event.type, host.name, user.name, process.name, process.command_line и process.parent.name. Правило, которое зависит от полей, не сопоставленных согласованно, будет работать с одной интеграцией и давать сбой с другой.

Откройте примеры событий и проверьте: является ли event.category процессом? Включает ли event.type start? Собирается ли process.command_line или скрыт? Существует ли process.entity_id? Является ли @timestamp временем события или временем приема? Задокументируйте шаблоны индексов, интеграции, версии и обязательные поля. Список обязательных полей в интерфейсе является информацией для пользователя и не исправляет фактическое сопоставление.

Шаг 3: Напишите сфокусированный запрос

В лабораторном примере мы хотим обнаружить создание процесса под названием lab-admin-tool.exe, когда родительский процесс не является ожидаемым программным обеспечением для администрирования. Имя вымышленное. В Custom query можно написать простой KQL:

event.category:process and event.type:start and process.name:"lab-admin-tool.exe" and not process.parent.name:"approved-manager.exe"

Запрос указывает на отклонение, но не доказывает вредоносность. Необходимо проверить Signer, Hash, Path, User, Host, Parent command line и частоту. Перед созданием правила запустите его в Discover или Timeline в разных диапазонах. Проверьте наличие полей Null, Variant в имени или ненадежных источников.

Если поведение требует последовательности — например, Process, а затем Network connection от того же process.entity_id — переключитесь на EQL. Если вы хотите обобщить, сколько хостов запустили инструмент, или рассчитать Count по Parent, ES|QL может подойти.

Шаг 4: Расписание и Lookback

Правило включает запрос, расписание и действия. Interval определяет, как часто оно запускается. Lookback расширяет окно поиска для охвата событий, поступающих с задержкой. Перекрывающиеся окна могут создавать дублирующиеся оповещения, если нет подходящей дедупликации или подавления. Слишком короткое окно пропускает более поздние данные.

Проверьте задержку приема по источнику. События конечных точек могут поступать почти в реальном времени, тогда как источник Cloud или Batch может быть задержан. Установите Run every и Additional look-back на основе измерения. После изменения Pipeline или Integration измерьте снова.

Шаг 5: Серьезность, риск и MITRE

Severity описывает серьезность совпадения в соответствии с вариантом использования; Risk score позволяет числовую оценку. Не используйте High для каждого правила. Аномальный процесс на лабораторном хосте отличается от того же процесса на контроллере домена. Вы можете использовать Risk score override, когда надежное поле предоставляет контекст, но необходимо проверить Missing values и Range.

Сопоставление MITRE ATT&CK должно соответствовать поведению, которое обнаруживает правило, а не полному сценарию атаки, который вы себе представляете. Правило, которое обнаруживает выполнение процесса, не обязательно доказывает Persistence или Exfiltration.

Шаг 6: Подавление и исключения

Подавление оповещений группирует повторяющиеся совпадения по полям для уменьшения объема. Оно не заменяет правильный запрос. Подавление по host.name может скрывать развитие, если один и тот же хост генерирует несколько различных поведений. Выберите поля, которые представляют единицу расследования, например host.id и process.hash, и определите Window на основе Baseline.

Исключения исключают известные совпадения. Создайте ограниченное исключение: подписанный Hash, Path, определенный Parent и определенная группа хостов, вместо исключения process.name во всей организации. Добавьте Comment, Owner и дату Review. По возможности, предпочитайте управляемый список исключений запросу с десятками NOT clauses.

Шаг 7: Напишите руководство по расследованию

Руководство по расследованию — это документ Markdown, который прилагается к правилу и отображается рядом с оповещением. Согласно Elastic, хорошее руководство строится вокруг Triage, Analysis и Response, начинается с контекста, а не со списка команд, и ссылается на поля Alert, Timeline queries и Osquery, когда это уместно.

Можно ссылаться на динамические поля, такие как host.name или user.name, и добавлять кнопки Timeline, когда версия и лицензия поддерживают это. Сохраняйте руководство кратким и легко сканируемым. Аналитик работает под давлением; длинные абзацы без порядка останутся непрочитанными.

Шаг 8: Проверка и настройка

1. Запустите Preview или исторический запрос и отметьте примеры True, False и Benign Positive.
2. Проверьте правило на смоделированном Positive sample и на Negative sample. Убедитесь, что оно дает сбой, когда поле отсутствует, и не создает ошибочное совпадение.
3. Запустите сначала без опасного Response. Измерьте объем оповещений, время расследования и качество Context.
4. Проверьте статус выполнения правила, пробелы, разрешения и API key. Правила запускаются с разрешениями последнего пользователя, который их редактировал.
5. Настройте Query, Schedule, Suppression и Exceptions по отдельности, чтобы знать, что решило проблему.
6. Выполните Regression test после обновления Integration, сопоставления ECS или версии Elastic.

Чек-лист

• ✓Тип правила соответствует вопросу.
• ✓Проверены Indices, Data view, ECS и Required fields.
• ✓Запрос возвращает четкую единицу расследования.
• ✓Schedule и Lookback покрывают Delay без чрезмерных дубликатов.
• ✓Severity, Risk и MITRE соответствуют поведению.
• ✓Suppression и Exceptions ограничены и задокументированы.
• ✓Investigation Guide включает Triage, Analysis и Response.
• ✓Существуют Owner, Review date, Metrics и Regression test.

Частые ошибки

• Выбор EQL, KQL или ES|QL по предпочтению, а не по вопросу.
• Копирование Prebuilt Rule без проверки Data requirements.
• Предположение, что ECS сопоставлен, потому что поле появляется в некоторых событиях.
• Увеличение Lookback без понимания дубликатов.
• Создание широкого исключения по имени процесса.
• Активация автоматического Response до Validation.
• Написание Investigation Guide, который содержит только «проверьте, является ли вредоносным».

Резюме и призыв к действию

Выберите вымышленный процесс в лаборатории и создайте полное правило: Data contract, Query, Schedule, Risk, одно исключение, Investigation Guide и Test cases. Затем попросите другого аналитика исследовать оповещение без устного объяснения. Если руководства и полей недостаточно, улучшите правило, прежде чем добавлять дополнительную логику.

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