Разработка правил обнаружения атак
Detection Engineering для SIEM
Last updated
Detection Engineering для SIEM
Last updated
Detection Engineering — это процесс разработки, внедрения и оптимизации правил обнаружения киберугроз, направленный на своевременное выявление атак и минимизацию их последствий. Основная задача Detection Engineering — создавать эффективные механизмы обнаружения, которые позволяют снизить время обнаружения (MTTD) и время реагирования (MTTR), а также минимизировать количество ложных срабатываний.
Аналитики, занимающиеся Detection Engineering, работают с различными источниками данных (логи ОС, сетевой трафик, данные EDR/XDR).
Вот тут я писала о том, что полезно завести в SIEM: Логи: что собирать и откуда, чтобы эффективно обнаруживать атаки А вот тут про ТОП-10 полезных событий: [Cheat Sheet] ТОП-10 событий для мониторинга
А еще используют модели угроз (например, MITRE ATT&CK). Про матрицу я рассказывала тут: Матрица MITRE ATT&CK, Cyber Kill Chain, UKC
Идея → Разработка → Тестирование → Внедрение → Мониторинг → Обновление
Жизненный цикл правил обнаружения начинается с идеи, и источников для таких идей может быть множество:
Покрытие всей матрицы ATT&CK — это долгосрочная цель, но начинать стоит с наиболее актуальных для вашей организации техник.
Твиттер, блоги, статьи (например, от CrowdStrike, FireEye, Kaspersky, Microsoft Threat Intelligence, Telegram-каналы по кибербезопасности). Изучение инструментов из отчетов про APT или блоги/cheatsheet RedTeam.
Открытые репозитории с правилами: , , . Но надо понимать, что правила в открытом доступе не всегда высокого качества. Самые лучшие и крутые правила продаются по платным подпискам.
Совместная работа Red Team и Blue Team для тестирования и улучшения правил. Анализ результатов пентестов или прошлых инцидентов. Какие правила могли бы их предотвратить или обнаружить раньше?
Новые CVE и уязвимости: Новые уязвимости часто становятся мишенью для атак, и под них нужно создавать правила.
А еще читать этот блог, где я между строк оставляю очень много подсказок и идей для правил.
Важно комбинировать эти подходы, чтобы создавать правила, которые покрывают как известные угрозы, так и новые, еще не описанные в публичных источниках.
На этом этапе наступает исследование и сбор данных. Лучший способ написать правило на процедуру, атаку или инструмент - это воспроизвести ее самому.
Для этого обычно используются лабораторные среды, где развернута небольшая инфраструктура и настроено логирование. У нас оно настроено даже чуть шире, чем мы рекомендуем, для того чтобы не пропустить важные события и индикаторы.
Запускай атаку с разными параметрами, чтобы увидеть, как она выглядит в логах. Поищи cheat sheet для red team, там как правило описывают большинство возмодных вариаций запуска и использования.
Далее надо проанализировать артефакты, что остались в результате выполнения атаки. Анализируй логи и ищи, что может помочь выделить эту технику на фоне легитимной активности.
Если информации в логах не хвататет, можно прибегнуть к помощи сторонних инструментов:
API Monitor:
Утилита для мониторинга вызовов API в Windows. Позволяет увидеть, какие системные вызовы делает процесс.
Пример: Исследование, как Mimikatz взаимодействует с LSASS.
ProcMon (Process Monitor):
Инструмент от Sysinternals для мониторинга файловых операций, реестра, процессов и сетевой активности.
Пример: Отслеживание, какие файлы читает или изменяет вредоносный процесс.
(Да и весь Sysinternals Suite)
Для трафика можно использовать WireShark. PE Studio поможет выявить подозрительные строки, импорты и другие артефакты.
И только, когда ты продумал логику, можно приступать непосредственно к написанию правила.
К тестированию правил можно подходить с двух сторон.
Работоспособность правила. С течение времени важно понимать, что правило все еще акутально и обнаруживает угрозу. Для этого можно использовать фреймворки для тестирования: Atomic Red Team, Caldera, Metta. Мы, например, сохраняем все артефакты и добавляем их в автотесты, которые периодически прогоняем на CI/CD.
Тестирование на реальных данных. Проверка правила на исторических логах, чтобы убедиться, что оно не создает очень много ложных срабатываний. Немного шума - это нормально для некоторого вида правил. Но если правило генерирует 40 тысяч срабатываний в час, то хакера таким правилом не найти никогда. Именно отличная практика - проверять правило на реальном потоке событий вашей инфраструктуры.
После того как правило разработано и протестировано, наступает этап его внедрения в рабочую среду.
Внедрение правила — это не просто его загрузка в SIEM, а комплексный процесс, включающий настройку алертов, обучение команды и интеграцию в рабочие процессы SOC.
Правила можно помечать как "экспериментальные" на первых этапах. Некоторые команды сразу пишут плейбуки по расследованию и реагированию.
После внедрения необходимо следить за срабатываниями, чтобы убедиться, что правило работает корректно. А также собирать обратную связь о ложных срабатываниях или пропущенных атаках.
Каждое правило как минимум на первых этапах требует вайтлистинга. Даже самое точное правило требует тюнинга под особенности конкретной инфраструктуры: Представьте правило, которое обнаруживает создание новых доменных пользователей. Но аналитик может знать, что этим занимается конкретный администратор по заявкам и делает он это специальным скриптом на терминальном сервере. Тогда он может добавить легитимную активность в исключения, но продолжить получать алерты о новых доменных пользователях, созданных в обход принятых договоренностей и правил. И тем самым обнаружить нелегитимную активность.
Этап мониторинга о том, что экспертиза продукта не может жить в вакууме, нельзя написать правило, установить его в SIEM и забыть о нем. Разработка и поддержка правил обнаружения - это непрерывный процесс, хорошо, если у вас налажен процесс обратной связи в команде.
После внедрения правила важно регулярно оценивать его эффективность и актуальность. Этот процесс включает мониторинг, оптимизацию и обновление правил в соответствии с новыми угрозами и изменениями в инфраструктуре.
Раз в некоторое ремя надо пересматривать свои правила обнаружения. Для того чтобы это делать более системно, можно внедрять различные метрики, такие как различные отношения True Positive (Сколько срабатываний были действительно угрозами), False Positive (Ложные срабатывания) и False Negative (Пропущенные срабатывания).
Некоторые правила нуждаются в оптимизации с точки зрения нагрузки: сколько ресурсов SIEM/EDR тратит на обработку правила. Снизить нагрузку можно за счет упрощения логики, агрегации событий, фильтрации ложных срабатываний и других. Для этого надо хорошо понимать архитектуру вашего SIEM и отталкиваться от его особенностей обработки правил.
Ну и конечно необходимо следить за трендами, обновлениями инструментов и новыми векторами атак.
Пирамида боли — это концепция, предложенная Дэвидом Бьянко, которая ранжирует индикаторы компрометации (IoC) по уровню сложности, которую они создают для злоумышленника. Чем выше уровень в пирамиде, тем сложнее атакующему обойти обнаружение, и тем больше "боли" он испытывает.
Адаптированная версия для правил обнаружения SIEM:
1. Хэши файлов (File Hashes), IP-адреса, домены (Network Indicators)
Уровень: Самый низкий.
Описание: Правила, основанные на хэшах файлов (например, MD5, SHA256), на конкретных IP или доменных именах. И любых других индикаторах (IoC) из TI-отчетов.
Плюсы: Простота создания и внедрения.
Минусы: Легко обойти, изменив файл даже на один байт. Атакующие могут быстро сменить инфраструктуру (например, использовать DGA или CDN). Могут обнаружить только уже изученные атаки и группировки, которые удалось атрибуцировать. И что, наверное, немаловажно, слепы во время самого простого пентеста.
Оценка качества: Низкая. Такие правила легко обходятся и имеют ограниченную эффективность.
2. Имена файлов и строки запуска (cmdline)
Уровень: Низкий.
Описание: Правила, основанные на названиях конкретных инструментов, утилит или регулярных выражениях в строках запуска.
Плюсы: Простота создания и внедрения. Могут быть эффективны при использовании LolBas или GTFObins. Эффективны при локальной разведке. Малое количество False Positive срабатываний для хакерских утилит - можно генерировать инциденты с высоким уровнем опасности.
Минусы: Все еще легко обойти, переименовав файл или используя менее популярные инструменты и техники.
Оценка качества: Низкая-средняя. Эффективны против простых угроз.
3. Артефакты (Artifacts)
Примером такого артефакта может служить имя службы BTOBTO при использовании impacket-smbexec. Избавиться от него чуть сложнее, чем просто переименовать файл: надо изменить код или запустить со специальным параметром, но для этого об этом надо знать. А еще у impacket очень специфичные команды вывода, кто видел - ни с чем не перепутает. И от чтобы от этого избавиться, надо постараться.
Уровень: Средний.
Описание: Правила, основанные на артефактах (например, имена служб, именованных каналов, ключи реестра, мета информация процесса).
Плюсы: Сложнее обойти, надо пересобирать инстурменты.
Минусы: Работает только с известными инструментами и известными артефактами. Не может выявлять "подозрительную" активность.
Оценка качества: Средняя. Более устойчивы, но всё ещё могут быть обойдены.
4. Поведенческие индикаторы (Behavioral Indicators)
Уровень: Высокий.
Описание: Правила, основанные на поведении (например, подозрительные последовательности процессов, обращение к памяти sysmon).
Плюсы: Сложно обойти, так как требуют пересмотра вектора атаки, смены инструментария или качественной маскировки. Например вызывать в макросе создание процесса через WMI, чтобы разоврать цепочку процессов. Либо знаний, что антивирус может обращаться к памяти процесса lsass.exe, чтобы под него замаскироваться.
Минусы: Требуют глубокого анализа и высоких компетенций при разработке, могут вызывать ложные срабатывания.
Оценка качества: Высокая. Такие правила сложнее обойти, и они более эффективны.
5. Тактики и техники (TTPs)
Примером такого правила может служить создание локального пользователя, при котором регистрируется событие 4720, каким бы способом ты его не создавал. Либо закрепление через автозапуск в реесте, которое требует изменение определенного ключа. Ну или если не отходить далеко от impacket, то паттерн его поведения: обращение к RPC для создания службы или запланированной задачи, запуск задачи/службы с выводом результатов в файл и забор этого файла через SMB.
Уровень: Самый высокий.
Описание: Правила, основанные на тактиках и техниках атак.
Плюсы: Очень сложно обойти, так как требуют изменения всей стратегии атаки.
Минусы: Требуют глубокого понимания TTPs и регулярного обновления.
Оценка качества: Очень высокая. Такие правила наиболее устойчивы и эффективны.
Низкий уровень правила в пирамиде боли не делает его бесполезным — такие правила, хоть и легко обходятся, часто обладают высокой точностью и минимальным количеством ложных срабатываний (FP). Например, правило на основе хэша вредоносного файла может быть тривиальным для обхода, но если оно срабатывает, то с почти 100% вероятностью указывает на реальную угрозу. С другой стороны, правила на верхних уровнях пирамиды (например, поведенческие или основанные на TTPs) сложнее обойти, но они могут быть более шумными и требовать тонкой настройки. Поэтому эффективная экспертиза должна сочетать правила на всех уровнях: низкоуровневые — для точного обнаружения известных угроз, а высокоуровневые — для выявления сложных и новых атак. Такой подход обеспечивает баланс между точностью, устойчивостью к обходу и покрытием угроз.
Выше речь шла о сигнатурных правилах - основанных на поиске известных шаблонов. Но они неэффективны против новых или неизвестных угроз. Либо генерируют такое количество False Positive, что становятся практически бесполезными (избегайте таких).
Такие правила можно использовать вместе с аномалиями и поведенческими правилами - обнаружение отклонений от нормального поведения (например, сетевые соединения от системных процессов или вход пользователя в почту с нового адреса). Внедрение таких правил не всегда тривиально. Во-первых, это всегда сопряжено с большим числом False Positive: для некоторых системных процессов нормально открывать сетевые соединения. Надо долго профилировать такие правила. Во-вторых, когда активность перестать считать аномальной? Пользователь подключился второй раз с IP - это еще аномально или уже нормально? Да и домашние адреса провайдеров меняются, люди могут проверить почту в отпуске. На практике подобное профилирование много раз показывало пользу. Иногда, когда атакующие максимально мимикрируют под легитимную активность, это чуть ли не единственный способ их обнаружить. Но поддержка таких механизмов - дорогое удовольствие.
И есть третий подход - статистика и машинное обучение: Использование ML для выявления сложных аномалий.
: Готовая среда с SIEM, EDR, Windows и Linux хостами. Подходит для тестирования атак и создания правил.
: Набор готовых сценариев для тестирования атак, которые можно запускать в лаборатории.
Еще можно использовать ресурсы вроде от SBousseaden, где собраны примеры логов для разных техник MITRE ATT&CK.
Похожая концепция описана в проекте . Но там оценка детекта представлена в виде матрицы, где учитывается не только сложность обхода правила, но и уровень, на котором работает обнаружение (Application, User-Mode, Kernel-Mode).