Детектирование (обнаружение) — один из традиционных видов контроля кибербезопасности, реализуемый наравне с блокирующими, корректирующими, административными и другими мерами. И, если раньше (до 2015 года) основной вопрос был «А что нужно детектировать?», то с развитием MITRE ATT&CK центры мониторинга получили практически неограниченное поле для идей по созданию сценариев обнаружения.
Однако при наличии бесконечного множества сценариев неизбежно возникает другой вопрос: «А что нужно детектировать в первую очередь?». Учитывая это и тот факт, что операционная деятельность центров мониторинга — это «вечная игра вдолгую», в ходе которой приходится реагировать на меняющийся ландшафт угроз, развивающиеся технологии и эволюцию злоумышленников в условиях ограниченных ресурсов, приоритизация разработки детектирующей логики становится неотъемлемой частью любого современного SOC.
Описываемую задачу можно легко представить в практической плоскости: основной деятельностью большинства центров мониторинга (за исключением некоторых специализированных типов SOC) является обнаружение инцидентов ИБ и реагирование на них. Обнаружение напрямую связано с подготовкой определенных алгоритмов (сигнатуры, «жесткая» логика, статистические аномалии, машинное обучение и т. д.), позволяющих его автоматизировать. Эта подготовка состоит как минимум из двух процессов: управления сценариями обнаружения и разработки детектирующей логики, в рамках которых определяется жизненный цикл, этапы разработки, способы тестирования, выпуск в «боевую» среду, стандартизация и т. д. Эти процессы, как и любые другие, требуют некоторой входной информации — идеи, которая, как минимум, абстрактно описывает ожидаемый результат.
В этот момент начинаются первые сложности. Идей, благодаря MITRE ATT&CK, слишком много: на текущий момент описано более 200 техник, большая часть которых разбивается на несколько подтехник (например, MITRE T1098 Account Manipulation содержит шесть подтехник) — а возможности центра мониторинга ограничены. Кроме того, вероятнее всего, специалистам доступны не все возможные источники данных для формирования детектирующей логики, а из тех, что доступны, не все интегрированы с SIEM-системой. При этом одни источники позволяют реализовать лишь очень специфичные детекты, тогда как другие, наоборот, могут быть использованы для покрытия большей части матрицы MITRE. Наконец, на этих источниках в ряде случаев необходимо включать дополнительно настройки аудита или реализовать точечную фильтрацию для защиты от спама. Сами техники тоже отличаются друг от друга: есть те, что используются в большинстве атак, но есть и достаточно уникальные, с которыми отдельно взятый центр мониторинга никогда не столкнется. Таким образом, приоритизация заключается не только в определении подмножества техник, которые можно детектировать с учетом доступных данных, но и в ранжировании техник внутри этого подмножества. В результате мы получим оптимизированный перечень сценариев обнаружения, позволяющий реализовать детектирующий контроль с учетом доступных ресурсов и в изначальном духе MITRE ATT&CK — для выявления атаки достаточно обнаружить лишь часть из множества атомарных действий злоумышленника.
Небольшое отступление: прежде чем перейти к конкретной реализации способов приоритизации, стоит упомянуть, что в этой статье мы рассматриваем варианты, в основе которых лежат инструменты, созданные вокруг матрицы MITRE. Релевантность угроз при этом оценивается в целом, а не для конкретных организаций и их бизнес-процессов. Рекомендации, приведенные в этой статье, можно использовать в качестве отправной точки для приоритизации детектирующих сценариев. Более зрелый подход должен включать оценку ландшафта актуальных для вашей организации угроз безопасности, учет собственной модели угроз и текущий реестр рисков, возможности по автоматизации и ручной разработке. Все это требует детализированной проработки и взаимодействия различных процессов и ролей внутри вашего SOC. Более подробную информацию по повышению зрелости мы предоставляем в рамках консалтинговых услуг для центров мониторинга.
Оглавление
MITRE Data Sources
Задачу по оптимизированной приоритизации бэклога применительно к текущему состоянию мониторинга можно разделить на следующие этапы:
Определение доступных источников данных и качества их подключения.
Определение релевантных техник и подтехник MITRE.
Поиск оптимального соотношения между состоянием источника и актуальностью техник.
Расстановка приоритетов.
Один из ключевых моментов в реализации этой последовательности — возможность связать информацию, получаемую центром мониторинга из источников данных, и конкретную технику, которую можно с помощью этой информации детектировать. В 2021 году MITRE завершила проект ATT&CK Data Sources и сформировала методологию описания объектов данных, которые могут использоваться для детектирования той или иной техники. Основными элементами описания объектов данных являются:
Наименование (Data Source) — узнаваемое название, с помощью которого определяется объект данных (Active Directory, журнал приложения, драйвер, файл, процесс и т. д.).
Типы событий (Data Components) — возможные действия с объектом данных, его состояния и параметры (например, для объекта данных «файл» типами событий будут создание файла, удаление файла, модификация файла, доступ к файлу, метаданные файла и т. д.).
На текущий момент матрица MITRE практически для каждой техники содержит раздел Detection, предоставляющий перечень объектов данных и релевантных для них типов событий, которые могут использоваться для создания детектирующей логики. На момент выхода статьи всего определен 41 объект данных.
MITRE Most Relevant Data Components
На рисунке выше правый столбец (Event Logs) иллюстрирует возможности по расширению методологии под конкретные события, получаемые из реальных источников данных. Реализация такого маппинга не входит в цели проекта ATT&CK Data Sources. Пример Event Logs создан для наглядности. редполагается, что каждый конкретный центр мониторинга самостоятельно определит перечень событий, релевантных для своих источников, что является достаточно трудоемкой задачей.
В целях оптимизации подхода к приоритизации можно для начала выделить наиболее часто встречающиеся типы событий, которые фигурируют в наибольшем количестве техник MITRE.
На графике ниже представлены актуальные данные (ТОП-10) для матрицы MITRE версии 15.1 (последней на момент написания статьи).
Наиболее релевантные типы событий (скачать)
Для этих типов можно определить собственные источники, работа с которыми принесет наибольший результат. В этом вам помогут:
Экспертные знания и общая логика. Объекты данных и типы событий в большинстве своем предоставляют инженерам или аналитикам, работающим с источниками данных, достаточно информации для формирования первичного суждения о конкретных источниках, которые могут быть использованы.
Проверка непосредственно в системе сбора событий. Инженер или аналитик может посмотреть на имеющиеся источники и сопоставить события с объектами данных и типами событий.
Доступные в интернете ресурсы, например проект Sensor Mappings to ATT&CK, созданный командой The Center for Threat-Informed Defense, или отличный ресурс по событиям Windows: UltimateWindowsSecurity.
При этом большинство источников достаточно стандартны и обычно подключаются в рамках внедрения системы мониторинга. То есть маппинг можно свести к выбору тех из них, которые подключены в инфраструктуре организации или которые легко подключить.
В результате получается неранжированный перечень интегрированных источников данных, которые можно использовать для разработки детектирующих логик, например:
Для типа событий Command Execution: журналы ОС, EDR, журналы администрирования сетевых устройств и т. д.
Для типа событий Process Creation: журналы ОС, EDR.
Для типа событий Network Traffic Content: WAF, прокси, DNS, VPN и т. д.
Для типа событий File Modification: DLP, EDR, журналы ОС и т. д.
Однако для приоритизации этого перечня недостаточно. Необходимо также учитывать следующие параметры:
Качество интеграции источников. Два одинаковых источника данных могут быть по-разному интегрированы в инфраструктуру (например, могут применяться разные настройки журналирования, один из источников может быть размещен только в одном сетевом сегменте и т. д.).
Полезность техник MITRE. Не все техники одинаково полезны с точки зрения оптимизации работ. Некоторые техники более специализированные и направлены на детектирование редко встречающихся действий атакующих.
Детектирование одних и тех же техник различными (несколькими одновременно) источниками данных. В целом, чем больше настроено вариантов детектирования для конкретной техники, тем больше вероятность ее обнаружить.
Вариативность типов событий. Выбранный источник данных может быть полезен не только для детектирования техник, которые связаны с типами данных из ТОП-10, но и для обнаружения других. Например, журнал ОС можно использовать как для выявления событий типа Process Creation, так и для событий типа User Account Authentication, не указанных на графике.
Приоритизация с помощью DeTT&CT и ATT&CK Navigator
Теперь, когда у нас есть первичный перечень источников данных, которые доступны для создания детектирующей логики, можно приступить к их оценке и приоритизации. Эту работу можно частично автоматизировать с помощью инструмента DeTT&CT, созданного независимыми от MITRE разработчиками с целью помочь центрам мониторинга использовать MITRE ATT&CK для оценки и сравнения качества источников данных, покрытия и охвата обнаружения по техникам MITRE. Инструмент доступен по лицензии GPL-3.0.
DETT&CT работает с расширенным перечнем источников данных относительно модели MITRE. Это расширение уже учтено в функциональности инструмента и не требует ручного переопределения матрицы MITRE. Оно включает в себя, например, несколько источников, которые в MITRE Data Sources объединены в источник Network Traffic: Web, Email, Internal DNS, DHCP.
Установка DETT&CT выполняется с помощью двух команд: git clone и pip install -r. После этого становится доступен DETT&CT Editor — веб-интерфейс для описания источников данных, а также инструмент DETT&CT CLI для автоматизированного анализа подготовленных входных данных, который поможет в приоритизации детектирующих логик (и не только).
Первым шагом после определения релевантных источников данных является их описание. Для этого в DETT&CT Editor в разделе Data Sources необходимо нажать New file и заполнить следующие поля:
Domain — версия матрицы MITRE, с которой необходимо работать (enterprise, mobile, ICS).
Name — наименование. Это поле не используется в аналитике. Оно предназначено для различения файлов с описанием источников.
Systems — выбор платформ, к которым будет относиться тот или иной источник данных. Позволяет как разделить платформы, например Windows и Linux, так и указать несколько платформ в рамках одной системы. В дальнейшем необходимо учитывать, что источник данных привязывается к системе, а не к конкретной платформе. То есть если источник собирает данные и из Windows, и из Linux, то можно оставить одну систему с двумя платформами, но если источник собирает данные только из Windows, а другой только из Linux, то необходимо создавать две системы: одну для Windows, другую для Linux.
После заполнения общих разделов можно приступать к анализу источников данных и маппингу на MITRE Data Sources. Для этого для каждого компонента объекта данных MITRE необходимо нажать Add Data Source и заполнить соответствующие поля. Подробное описание всех полей и примеры заполнения представлены на странице проекта по ссылке выше. В данной статье выделим наиболее интересное поле: Data quality — качество интеграции источника данных, которое определяется по пяти параметрам:
Devicecompleteness (полнота покрытия инфраструктуры) — определяет покрытие источником инфраструктуры (например, различных версий Windows или сегментов подсети и т. д.).
Datafieldcompleteness (полнота данных в событиях от источника) — определяет полноту информации в событии из источника данных. Например, информация может считаться неполной, если для ProcessCreation мы можем видеть факт создания процесса, но не сведения о родительском процессе или если для CommandExecution можно видеть команду, но не ее параметры и т. д.
Timeliness (актуальность) — определяет наличие задержки между временем возникновения события и его попаданием в SIEM-систему или другую систему для детектирования.
Consistency (нормализация) — степень соответствия наименований полей данных в событии из этого источника стандартным наименованиям.
Retention (срок доступности) — сравнивает период, за который данные из этого источника доступны для детектирования, с определенной для этого источника политикой хранения данных. Например, данные из конкретного источника могут быть доступны в течение месяца, тогда как политика или требования регулятора определяют период хранения как один год.
Подробное описание системы оценки (скоринга) для заполнения этого поля представлено в описании проекта.
Стоит отметить, что на этом этапе можно описать не только те типы событий, которые покрывают наибольшее количество техник матрицы MITRE и представлены в нашем ТОП-10. Некоторые источники могут предоставлять дополнительную информацию, например Windows Security Event Log помимо событий типа Process Creation предоставляет данные по типу событий User Account Authentication. Подобное расширение позволит в дальнейшем анализировать матрицу без ограничений.
После описания всех источников из перечня, определенного ранее, можно приступать к их анализу относительно матрицы MITRE.
Первой и наиболее тривиальной аналитикой является определение техник MITRE, которые так или иначе можно обнаружить с помощью имеющихся источников данных. Для формирования такой аналитики используется конфигурационный файл с описанием источников данных и инструмент DETT&CT CLI, который на выходе выдает файл JSON с покрытием техник MITRE. Для этого используется следующая команда:
python dettect.py ds -fd <data-source-yaml-dir>/<data-sources-file.yaml> -l
Полученный JSON полностью подготовлен для использования в инструменте визуализации матрицы MITRE — MITRE ATT&CK Navigator. Пример представлен на рисунке ниже.
Такая визуализация помогает понять, какие техники центр мониторинга может обнаружить при текущем наборе источников данных. Цифры в правом нижнем углу некоторых ячеек отображают, сколько подтехник покрыто источниками данных, а цвета — сколько различных источников можно использовать для детектирования конкретной техники. Чем цвет темнее, тем источников больше.
Помимо этого, DETT&CT CLI позволяет сформировать файл XLSX, который удобнее для дальнейшей обработки в рамках развития интеграции существующих источников (эта параллельная задачаявляется частью процесса управления источниками данных). Для формирования такого файла используется следующая команда:
python dettect.py ds -fd <data-source-yaml-dir>/<data-sources-file.yaml> -e
Следующая интересующая нас аналитика — определение возможностей центра мониторинга по детектированию техник и подтехник MITRE с учетом проведенной ранее оценки качества интегрированных источников. Команда для выполнения аналитики:
python dettect.py ds -fd <data-source-yaml-dir>/<data-sources-file.yaml> —yaml
В данном случае формируется конфигурационный файл DETT&CT, который содержит не только информацию по покрытию матрицы, но и учитывает качество источников данных, позволяя глубже понять уровень видимости для каждой техники. С помощью этой аналитики можно выделить те техники, для которых центр мониторинга в его текущем состоянии может добиться наилучшего результата с точки зрения полноты детектирования и покрытия инфраструктуры.
Эту информацию также можно визуализировать с помощью MITRE ATT&CK Navigator. Для этого используется следующая команда DETT&CT CLI:
python dettect.py v -ft output/<techniques-administration-file.yaml> -l
Пример представлен на рисунке ниже.
Для каждой техники скоринг рассчитывается как среднее арифметическое между всеми релевантными источниками данных. Для каждого источника данных скоринг рассчитывается на основании указанных параметров. При этом следующие параметры имеют увеличенный вес:
Device completeness.
Data field completeness.
Retention.
Настройка скоринговой модели может быть выполнена путем изменения исходного кода проекта.
Стоит отметить, что система скоринга, представленная разработчиками DETT&CT, в ряде случаев может быть довольно субъективна, например:
У вас может быть один источник данных из трех, упомянутых в рамках конкретной техники. Однако в некоторых случаях одного источника данных может быть недостаточно даже для минимального уровня обнаружения этой техники.
В другом случае, наоборот, единственный источник данных может предоставлять исчерпывающую информацию для полноценного детектирования техники.
Детектирование техники может быть основано на источнике данных, который в настоящее время не упоминается в MITRE ATT&CK Data Sources или Detections для этой конкретной техники.
В этих случаях конфигурационный файл DETT&CT techniques-administration-file.yaml можно скорректировать вручную. Теперь, когда существующие источники данных и качество их интеграции связаны с матрицей MITRE, остается ранжировать доступные техники. Для этого можно использовать раздел матрицы Procedure Examples, в котором определены группировки, применяющие ту или иную технику или подтехнику в своих атаках. В DETT&CT для целой матрицы MITRE эта операция выполняется с помощью следующей команды:
python dettect.py g
В целях приоритизации мы можем объединить два набора данных (данные по реализуемости техник с учетом доступных источников данных и их качества и данные по наиболее часто используемым техникам MITRE):
python dettect.py g -p PLATFORM -o output/<techniques-administration-
file.yaml> -t visibility
В результате получается файл JSON, содержащий техники, с которыми центр мониторинга может работать, и их описание, включающее:
скоринг по возможностям детектирования;
скоринг по частоте использования в известных атаках.
Пример представлен на рисунке ниже.
Часть техник на рисунке покрашена в оттенки красного цвета — это означает, что они использовались в атаках (по данным MITRE), но при этом у центра мониторинга отсутствуют возможности по их детектированию. Другие техники покрашены в оттенки синего цвета — это означает, что центр мониторинга может их детектировать, но об использовании их в какой-либо атаке у MITRE нет данных. И наконец, оттенками оранжевого цвета выделены техники, которые применяются известными MITRE группировками и для которых у центра мониторинга есть возможности по детектированию.
Стоит отметить, что группировки, атаки и программное обеспечение, использованное в атаках, которые привязаны к технике MITRE, представляют собой ретроспективу за все время существования матрицы. В некоторых случаях это может привести к повышенному приоритету для техники, атаки по которой были, например, актуальны в период с 2015 по 2020 год, что не совсем релевантно для 2024 года.
Так или иначе, выделение подмножества техник, когда-либо применяемых в атаках, даст более осмысленный результат по сравнению с простым перебором. Полученное подмножество можно дополнительно ранжировать следующими способами:
С помощью матрицы MITRE в формате Excel-таблицы — каждый объект (Software, Campaigns, Groups) содержит параметр Created (дата создания объекта), по которому можно выделить наиболее релевантные объекты, после чего на основе полученного перечня актуальных объектов сформировать пересечение, описанное выше:
python dettect.py g -g sample-data/groups.yaml -p PLATFORM -o
output/<techniques-administration-file.yaml> -t visibility
С помощью проекта TOP ATT&CK TECHNIQUES, реализованного компанией MITRE Engenuity
Проект TOP ATT&CK TECHNIQUES был нацелен на разработку инструмента для ранжирования техник матрицы MITRE и по своим входным данным очень похож на DETT&CT. Результатом работы этого инструмента является определение 10 наиболее актуальных техник MITRE для детектирования при имеющихся возможностях мониторинга различных областей инфраструктуры организации (сетевые взаимодействия, процессы, файловая система, облачные решения, аппаратная часть). Помимо этого, проект учитывает следующие параметры:
Узкие места — специфичные техники в матрице, в которых другие техники сходятся или расходятся. К таким техникам можно отнести, например, T1047 WMI, поскольку она позволяет реализовать множество других техник, которые используют WMI, или T1059 Command and Scripting Interpreter, поскольку множество других техник подразумевает использование командной строки или иных оболочек — PowerShell, Bash и т. д. Детектирование подобной техники с большей вероятностью приведет к обнаружению широкого спектра атак.
Распространенность — изменение частоты использования техники с течением времени.
Однако стоит учитывать, что проект не поддерживается и основан на MITRE v10.
Финализация приоритизации
Выполнив все вышеуказанные шаги, центр мониторинга получает подмножество техник MITRE, которые фигурируют, в той или иной степени, в известных атаках, а также могут быть обнаружены при помощи имеющихся источников данных с учетом их конфигурации в инфраструктуре. К сожалению, DETT&CT не имеет функциональности для создания удобного файла XLSX с пересечением техник, используемых в атаках, и техник, которые центр мониторинга может детектировать. Однако у нас есть JSON, на основании которого это пересечение отрисовывается в MITRE ATT&CK Navigator. Таким образом, для приоритизации техник остается разобрать этот JSON (например, с помощью Python). Финальные условия приоритизации могут быть, например, следующими:
Приоритет 1 (критический): Visibility_score >= 3 and Attacker_score >= 75. С прикладной точки зрения это выделит техники MITRE, которые встречаются в атаках наиболее часто и для детектирования которых центру мониторинга не требуется (или требуется минимальная) подготовка.
Приоритет 2 (высокий): (Visibility_score < 3 and Visibility_score >= 1) and Attacker_score >= 75 — техники MITRE, которые встречаются в атаках наиболее часто и для детектирования которых центр мониторинга имеет возможности, но может потребоваться доработка журналов, или покрытие средствами мониторинга недостаточно хорошее.
Приоритет 3 (средний): Visibility_score >= 3 and Attacker_score < 75 — техники MITRE, со средней или низкой частотой использования, для детектирования которых центру мониторинга не требуется (или требуется минимальная) подготовка.
Приоритет 4 (низкий): (Visibility_score < 3 and Visibility_score >= 1) and Attacker_score < 75 — все остальные техники MITRE, которые встречаются в атаках и для детектирования которых у центра мониторинга есть возможности.
В результате центр мониторинга получает ранжирование техник MITRE по четырем группам с привязкой к собственным возможностям и глобальной статистике по действиям злоумышленников в рамках проведения атак. Этот перечень оптимизирован с точки зрения затрат на подготовку для написания детектов и может использоваться в качестве приоритизированного бэклога по их разработке.
Расширение приоритизации и параллельные задачи
В заключение хочется еще раз отметить основные допущения и рекомендации к использованию предложенного метода приоритизации.
Как было упомянуто ранее, использование статистики MITRE по частоте возникновения техник в атаках не совсем корректно. Для более зрелой приоритизации центр мониторинга должен опираться на актуальные угрозы. Для этого нужно определить ландшафт угроз на основе анализа информации об угрозах, сопоставить релевантные угрозы с конкретными устройствами и системами и выделить наиболее актуальные техники, которые могут быть применены против конкретной системы в окружении конкретной организации. Подобный подход требует достаточно глубокой проработки всех активностей и взаимосвязей процессов в центре мониторинга. Так, при формировании библиотеки сценариев обнаружения для заказчика в рамках оказания консультационных услуг мы используем данные сервисов Kaspersky Threat Intelligence по актуальным угрозам для конкретной организации, статистику сервиса Managed Detection and Response по выявляемым инцидентам, а также информацию о техниках, полученную в рамках расследования реальных инцидентов и анализа цифровых улик сервисом Incident Response.
Предложенный метод основывается на имеющихся у центра мониторинга возможностях и базовой аналитике по MITRE. При этом он оптимизирован с точки зрения минимизации трудозатрат на подготовку и позволяет сразу приступить к реализации наиболее актуальных детектов в текущих условиях. Это в свою очередь позволяет использовать его даже в небольших SOC, в которых есть только администратор SIEM-системы или аналитик. Помимо этого, центр мониторинга формирует, по сути, дорожную карту развития функциональности обнаружения, которая может быть использована в качестве демонстрации прогресса, определения KPI или обоснования необходимости расширения.
И в самом конце приведем несколько тезисов о возможностях по улучшению описанного подхода, а также параллельных задачах, которые можно выполнять с использованием описанных в этой статье инструментов:
Для дальнейшего улучшения процесса приоритизации можно использовать:
Группировку по месту детектирования. В базовом варианте можно выделить две группы детектов — сетевое обнаружение или обнаружение на устройстве. Учет особенностей инфраструктуры и источников данных при создании детектов для разных групп позволит избежать перекосов в ту или иную сторону и сформировать более целостное покрытие инфраструктуры.
Группировку по стадиям атаки. Детектирование на стадии Initial Access более трудоемко, но даст больше времени для реагирования, чем обнаружение на стадии Exfiltration.
Коэффициент критичности: некоторые техники не могут быть покрыты на 100%, например все, связанные с эксплуатацией уязвимостей или с подозрительными командами PowerShell. В этом случае дополнительным критерием ранжирования может выступать степень критичности угрозы.
Гранулирование при описании качества источников. Как мы упоминали ранее, DETT&CT позволяет качественно описывать имеющиеся источники данных, однако функциональность исключений в нем отсутствует. Иногда источник данных просто не требуется во всей инфраструктуре, или существует более одного источника данных, предоставляющих информацию для одинаковых систем. В этом случае более гранулированный подход, основанный на конкретных системах, подсетях или устройствах, позволит сделать оценку более релевантной. Однако такой подход требует взаимодействия с подразделениями организации, отвечающими за изменение конфигурации и инвентаризацию устройств, от которых, как минимум, потребуется информация о бизнес-критичности активов.
Помимо улучшения метода приоритизации детектов предложенные инструменты могут использоваться для выполнения ряда параллельных задач, способствующих развитию центра мониторинга:
Расширение перечня источников: как было показано ранее, для покрытия матрицы MITRE требуются очень разные источники данных. С помощью маппинга существующих источников на техники можно определить недостающие журналы и сформировать дорожную карту по подключению или внедрению этих источников.
Улучшение качества источников: на основании скоринга по качеству источников данных можно сформировать дорожную карту по улучшению существующих источников, например с точки зрения покрытия инфраструктуры, нормализации или периода хранения данных.
Трекинг детектирования: помимо прочего, DETT&CT предоставляет функциональность скоринга разработанных детектов, с помощью которого можно выстроить процесс пересмотра сценариев обнаружения.
Securelist