Как обеспечить эффективную логику обнаружения угроз в SOC
Детектирование кибератак — это процесс выявления и анализа подозрительных с точки зрения безопасности действий в IT‑инфраструктуре. Его цель — обнаружить попытки несанкционированного доступа, нарушения политик безопасности и другие признаки кибератак. Процесс обнаружения основан на использовании различных технологий, методов и инструментов, способных с помощью определенной логики выявить подозрительную активность, которая с высокой вероятностью свидетельствует о кибератаке.
В этой статье мы разберем процесс разработки детектирующей логики в SOC на примере того, как это устроено в нашем сервисе BI.ZONE TDR, начиная с формирования идей и гипотез для обнаружения, заканчивая оценкой эффективности.
Детектирующая логика — это не только правила корреляции в SIEM-системе
Детектирующая логика BI.ZONE
Этапы разработки детектирующего контента представлены в общем виде на схеме ниже.
Этапы разработки
При разработке детектирующей логики мы опираемся на множество источников для формирования идей и гипотез. Вот список основных:
- Киберразведданные от команды BI.ZONE Threat Intelligence — информация об атаках реальных злоумышленников, их тактиках, техниках и процедурах (TTP).
- Обезличенные данные из отчетов по реагированию на инциденты от команды BI.ZONE DFIR — информация о TTP злоумышленников, полученная в результате реагирования на инциденты.
- Данные об инструментах и TTP от команды анализа внутренней и внешней защищенности — информация об используемых нашей командой пентеста TTP, которая может послужить источником для превентивного детектирования сложных атак.
- Собственные исследования и эмуляции — данные, полученные в ходе эмуляции вредоносной активности на лабораторных стендах или в процессе исследования ПО и механизмов на предмет возможности реализовать вредоносную активность.
- Публично доступные отчеты и публикации о новых уязвимостях — данные о TTP атакующих, вредоносных утилитах и уязвимостях, агрегируемые из множества источников.
Стоит отдельно выделить практику анализа внутренней и внешней защищенности. Во время проектов по пентесту и red team иногда можно увидеть сложные техники, которые вряд ли будут использовать злоумышленники в ближайшее время. Но детектирование таких атак сейчас может митигировать риски в будущем. Стоит внимательно подходить к анализу этих данных и учитывать текущий уровень зрелости кибербезопасности в компании при создании детектирующей логики.
Наполнение бэклога разработки
Важную роль в наполнении бэклога играют киберразведданные. Они показывают актуальное состояние ландшафта киберугроз, поэтому критически важны для разработки детектирующей логики. Без этих сведений алгоритмы детектов могут быть неактуальными и не охватывать процедуры злоумышленников, которые те используют в реальных атаках. Также данные TI позволяют не только ответить на вопрос «На какую вредоносную активность нужно разработать детектирующую логику?», но и правильно приоритизировать процесс разработки.
Рассмотрим на примере данных от нашей команды киберразведки, которыми мы пользуемся для создания детектирующей логики:
- TTP — детальное описание тактик и техник, конкретных процедур кибергруппировок, вплоть до команд CLI
, что не всегда можно найти в описании процедур MITRE ATT&CK. - YARA — YARA‑правила для детектирования вредоносного ПО (ВПО), hack tools
, С&C-фреймворков и др. - REMA — телеметрия, полученная в ходе обратной разработки образцов ВПО. Прежде всего, она дает понимание о поведении ВПО в системе: какие системные объекты и ресурсы использует или изменяет ВПО (файлы, ключи реестра, сетевые порты и т. д.), какие уязвимости эксплуатирует, какие механизмы распространения использует, как взаимодействует с C&C‑серверами и т. д.
- IoC — индикаторы компрометации. Они позволяют реализовать достаточно простую логику обнаружения, которая направлена на поиск совпадений доменных имен, IP‑адресов, хеш‑сумм в анализируемых событиях. При использовании IoC в детектирующей логике очень важно, чтобы индикаторы были максимально точными.
Новые отчеты о деятельности группировок, описания образцов ВПО, новых техник и уязвимостей появляются постоянно. Для разных организаций актуальны разные угрозы в зависимости от отрасли и особенно от географии. Поэтому после формирования бэклога идей для разработки логики обнаружения атак необходимо их приоритизировать. Мы используем следующую классификацию:
- Highest — актуальная для наших клиентов угроза, которая реально исходит от атакующих «в дикой природе» (in the wild). Данные о таких угрозах обычно поступают от TI и DFIR.
- High — новая угроза, которая с большой вероятностью будет реализована атакующими. Данные о подобных угрозах, как правило, поступают от TI, а также благодаря анализу публичных источников.
- Medium — менее актуальные угрозы. Данные о них получаем благодаря анализу публичных источников, а также от команд пентеста и red team.
- Low — исследования для проактивного выявления новых угроз. Они могут проводиться на основе данных от команд пентеста и red team, а также анализа публичных источников и собственных эмуляций.
При анализе идей мы учитываем следующие параметры:
- актуальность угрозы, встречаемость «в дикой природе»;
- сложность реализации, возможность достижения быстрых побед (quick wins);
- потенциальная «точность» работы правила;
- наличие необходимого источника телеметрии и ее достаточность;
- возможность реализации нескольких правил на базе одного источника, вариативность событий от необходимого источника для детектирования других процедур.
Именно от правильной приоритизации бэклога зависит эффективность детектирующей логики. Количественные метрики, такие как покрытие матрицы MITRE ATT&CK, помогают оценить полноту детектирующего контента. Но стоит помнить об их ограничениях: как правило, целевой атакой управляет человек, а не автоматика и злоумышленник совершает много «шумных» действий, по которым его можно обнаружить. Если создавать детектирующий контент на каждый возможный шаг атакующего или любое атомарное действие, SOC получит множество правил, генерирующих большое количество ложноположительных срабатываний. На их разбор аналитики будут тратить лишнее время. Это ошибочный подход. Главное — обнаружить и остановить атакующего до того, как он достигнет своей цели.
Но прежде чем переходить к созданию детектирующей логики, необходимо получить телеметрию, на основе которой ее можно реализовать.
Детектирующая логика работает поверх телеметрии, которая содержит данные о действиях в сети или на конечных устройствах. Ее поставляют различные системы, устройства, приложения и другие компоненты IT‑инфраструктуры.
Важно понимать, какие источники использовать в первую очередь, чтобы получить больше возможностей для создания актуальной детектирующей логики. Значительную часть вредоносных техник можно выявить на конечных точках. Это критически важный источник данных о событиях, но не единственный возможный. Например, сетевые решения безопасности позволяют использовать для детектирования не события, а подозрения на угрозу. Также полезно подключать средства защиты на периметре (сетевые экраны, почтовые шлюзы, веб‑прокси), инфраструктурные внутренние источники (каталоги Active Directory, FreeIPA, сервисы аутентификации).
Еще есть источники, которые не помогут при детектировании, но пригодятся для восстановления хронологии действий атакующего, например некоторые журналы ОС, отличные от штатного аудита, балансировщики трафика, точки доступа, логи прикладного ПО и др.
В начале статьи мы уже говорили, что детектирующая логика не ограничивается правилами корреляции внутри SIEM. Детектирующий контент можно создавать внутри EDR, NTA и других систем. Распределение контроля поможет сократить нагрузку на SIEM. Можно пересылать в нее алерты о срабатывании правил, а сырую телеметрию хранить в системах‑источниках. Помимо экономии ресурсов, компания получает дополнительные возможности с точки зрения реагирования на конечных хостах за счет использования средств EDR.
Разработка логики обнаружения — это поиск баланса между широтой логики и объемом ложных срабатываний. Слишком узкие ограничения позволят обнаружить только конкретную активность. В большинстве случаев этого недостаточно для детектирования действий злоумышленника. С другой стороны, чрезмерно общий детект будет генерировать ложные алерты. Даже если он поможет обнаружить злоумышленника, такая логика может негативно повлиять на работу SIEM и IRP
Типы правил в BI.ZONE TDR
Процесс разработки детектирующей логики (detection engineering) включает в себя множество этапов. Среди наиболее важных выделим эмуляцию (тестирование) и профилирование.
Эмуляция
Перед тем как выпустить правило корреляции, мы должны быть уверены в том, что оно детектирует соответствующую активность в полной мере. Для этого мы проводим тестирование на лабораторных стендах и улучшаем правило, добавляя необходимые поля событий и корреляцию.
Профилирование
После достаточного количества испытаний в лабораторных условиях мы профилируем правило на реальной телеметрии без формирования алерта. Реальные инфраструктуры сильно отличаются от лабораторных, поэтому на этапе эмуляции невозможно предусмотреть все возможные ложноположительные срабатывания. Профилирование позволяет улучшить правило, подсветив их.
По результатам некоторых этапов detection engineering мы можем перевести правило в другой тип или вовсе отказаться от него. Однако некоторые правила предоставляют важный контекст аналитикам, хоть и генерируют множество ложноположительных срабатываний. Такие правила мы относим к правилам обогащения или Hunting‑правилам. Рассмотрим процесс работы с последним типом более подробно.
Аналитик может изучить по отчетам большое количество событий с неочевидной степенью вредоносности и вынести вердикт, опираясь на свой опыт и насмотренность. Это частый случай при оценке активности легитимных инструментов, где данные командной строки при легитимном и нелегитимном использовании не различаются. Загнать подобные детекты в рамки жесткой логики не получится — необходимо анализировать, опираясь на множество параметров, например результаты статистического анализа популярности файлов, командных строк, функций и т. д. В ходе такого анализа нужно переработать огромный объем данных, большая часть которых ничего не скажет о вредоносной активности в инфраструктуре. Упростить процесс помогают данные TI об инструментах, которые используют злоумышленники в настоящий момент. Так аналитик сможет искать конкретные паттерны.
Threat hunting — важный процесс для совершенствования детектирующей логики. Формируя удачную гипотезу на основе обнаруженной вредоносной активности, можно оценить возможность создания автоматического правила. В итоге получим данные о неизвестных ранее техниках злоумышленников, которые лягут в основу соответствующей детектирующей логики.
Большинство ложных срабатываний связано с особенностями конкретной компании — инфраструктурными или организационными. Для подавляющего большинства детектов нужны исключения. В нашей практике мы чаще всего создаем их на этапе подключения клиента к SOC и в первое время после этого. Так мы сокращаем поток алертов, который может повлиять на результат работы аналитиков.
На протяжении своего жизненного цикла правила постоянно проходят через проверки и тюнинг. При разработке правил команда тестирует их на большом количестве данных, в том числе исторических. После тестирования правила поэтапно выпускают в продуктовую среду. Со временем их эффективность может снижаться: злоумышленники адаптируют процедуры, появляются новые инфраструктурные особенности, влияющие на точность работы. Важно отслеживать показатели обнаружения и дорабатывать на их основе логику.
В сервисе BI.ZONE TDR мы оцениваем эффективность правил по десяткам метрик. Ниже приведены основные из них:
- конверсия в инцидент — процент алертов по данному правилу, на основе которых был сгенерирован инцидент;
- true positive rate — процент алертов по данному правилу, на основе которых был сгенерирован инцидент, решенный как true positive (TP);
- результативность — соотношение TP‑инцидентов, выявленных с помощью данного правила и общего количества TP‑инцидентов;
- показатели, аналогичные первым трем, только с учетом критичности конечного инцидента;
- количество глобальных или клиентских фильтров для правила;
- различные временные метрики обработки алертов и инцидентов.
Это далеко не полный список, но достаточный для базовой оценки эффективности правил. Он также поможет принять решение о необходимости донастройки или других действий, например перехода правила между типами: из детектирующего в Hunting и т. д. Аналогично данные метрики можно отслеживать в разрезе источников данных, на базе которых генерируются алерты. В совокупности с данными по объему поставляемой ими телеметрии получится оценить их эффективность.
Детектирующая логика играет важную роль в мониторинге и реагировании, поскольку позволяет оперативно выявлять угрозы, предотвращать инциденты и минимизировать ущерб. Она автоматизирует процессы мониторинга, снижая нагрузку на аналитиков SOC и сокращая время реакции на киберугрозы. Оперативная адаптация к новым техникам злоумышленников обеспечивает защиту от сложных атак. Кроме того, правильно выстроенная логика снижает количество ложных срабатываний. Это позволяет фокусироваться на реальных инцидентах, а не тратить ресурсы на анализ несущественных событий.
За 7 лет работы нашего SOC мы сформировали большую базу правил корреляции и лучших практик по написанию детектирующего контента. И сейчас мы используем их не только в BI.ZONE TDR, но и для того, чтобы помочь другим компаниям построить свой собственный центр мониторинга.