Эта статья — продолжение цикла про поиск и применение TI-информации. В нем мы делимся нашим опытом и надеемся, что он поможет сэкономить время на самостоятельное изучение. Мы расскажем про то, как загрузить и применить индикаторы компрометации в SIEM на примере IBM QRadar. IBM ушла с российского рынка в 2022 году, но продукт все еще распространен, и вряд ли ситуация поменяется в ближайшее время. Предыдущая статья. Почему SIEM: Здесь, как правило, собираются все необходимые журналы, например, средств защиты информации (СЗИ), сетевых устройств и проч. Наличие SIEM говорит об определенном уровне зрелости кибербезопасности (КБ) в организации, поскольку до применения TI еще нужно дорасти. В SIEM есть встроенные механизмы корреляции, которые позволяют писать правила сложнее полного совпадения. SIEM сейчас один из основных инструментов КБ-специалиста. Коротко про источники, откуда можно получать данные TI. OSINT — это бесплатные источники информации по индикаторам и не только, которые находятся в свободном доступе в интернете. Они дают различные варианты предоставления данных об угрозах. Это может быть сайт, где публикуют информацию о новых киберугрозах, или какой-нибудь сетевой ресурс, где размещают файлы со списками индикаторов в формате csv, txt и т. д. У каждого источника свой набор данных и свой метод их предоставления. Один дает только списки подозрительных IP-адресов, другой — список вредоносных URL, третий — хеши вредоносного ПО. Отдельно про OSINT можно почитать в нашей предыдущей статье. MISP — это TI-платформа с открытым исходным кодом. Имеет множество интеграций с различными OSINT и позволяет удобно агрегировать их. В MISP также реализован API, что дает ей дружить с внешними системами. Коммерческие источники TI — обычно это облачные сервисы по платной подписке. Многие провайдеры предоставляют возможности интеграции с наиболее популярными сетевыми устройствами. Также многие СЗИ уже поддерживают интеграцию с коммерческими поставщиками TI из коробки. Собственные источники — данные из собственных расследований, реверс-инжиниринга вредоносного ПО, результаты Threat Hunting, данные из песочницы и проч. Цели интеграции — выявить инциденты КБ и получить дополнительный контекст при их расследовании. Перечислим типовые задачи для их достижения: Получить или загрузить индикаторы автоматизированным способом из источника TI. Загрузить данные посредством API, предоставляемого источником TI. Загрузить данные по протоколу TAXII в формате STIX — разработанном MITRE стандарте для обмена информацией по киберугрозам. Загрузить индикаторы иным способом, предоставляемым источником TI. Доставить индикаторы в SIEM. Определить технические возможности и способы загрузки индикаторов в SIEM. Определить набор индикаторов и их контекст, которые можно загрузить и использовать в SIEM. Применить индикаторы в SIEM. Создать правила корреляции, использующие индикаторы в SIEM. Коррелировать события с использованием TI. Анализировать журналы безопасности на предмет наличия индикаторов компрометации, получить контекст TI. Выявить и расследовать инциденты КБ. Выявить реальные инциденты, отсеять ложноположительные срабатывания. Расследовать инциденты с использованием информации из TI. В рамках статьи мы рассказываем про интеграцию с IBM QRadar. Но для других SIEM-систем принцип решения задачи остается тот же, отличается только способ реализации. Общая схема интеграции изображена на рис. 1. OSINT. Находим открытые источники в интернете, читаем описания, изучаем возможности загрузки интересующей нас информации.  MISP. Часто используется в качестве локальной TI-платформы и предоставляет готовые интеграции со множеством OSINT-источников. Коммерческий поставщик. У вас может быть платная подписка от поставщика TI. В этом случае необходимо обратиться к вендору и узнать о возможностях интеграции с вашими СЗИ. Собственная база данных TI. Возможно, у вас уже есть свой TI. Плюсы и минусы различных источников приведены в таблице. Серебряной пули не существует, и лучше попробовать различные варианты в рамках бюджета, чтобы найти подходящий, или их комбинацию.  Источник Плюсы Минусы OSINT • Бесплатная подписка• Широкое покрытие • Данные предоставляются в разных форматах• Информация загружается различными методами• Дается мало контекста• Необходимо валидировать и фильтровать, чтобы избежать фолзов• Может сломаться в любой момент• Потребуется время, чтобы выбрать релевантные данные MISP • Много коробочных интеграций с OSINT• Бесплатная подписка• Широкое покрытие• Встроенный менеджмент источников TI• Множество дополнительных community-модулей• Модули интеграции с СЗИ, готовые библиотеки и примеры кода • Требуется умение готовить и кастомизировать под свои нужды• Требуются ресурсы для развертывания и команда для поддержки• Потребуется время, чтобы выбрать релевантные данные Коммерческий поставщик • Уникальный контент• Агрегация информации от различных источников TI (в том числе OSINT)• Техническая поддержка• Готовый скоринг, фильтрация, ранжирование и проч.• Модули интеграции с СЗИ, готовые библиотеки и примеры кода • Подписка оплачивается• Предоставляемый контент (пилот) предварительно оценивается  Собственная база данных TI • Наиболее релевантные данные • Оценивается как самый дорогой вариант во всех смыслах• Требуется определенный уровень зрелости, нужен как минимум функционирующий SOC• Требуется содержать штат разработчиков и редких специалистов для поиска и анализа информации по киберугрозам• Развертывается и поддерживается инфраструктура, различные программные продукты В SIEM-системах обычно есть возможность хранить в списках TI-информацию, которую затем можно использовать в правилах корреляции. Например, загружаем информацию о «плохих» IP-адресах, делаем простое правило корреляции и детектируем все попытки доступа к ним. Для решения этой задачи необходимо определиться с набором индикаторов и контекстом, которые можно использовать в правилах корреляции, и изучить технические возможности SIEM-системы. В QRadar такие списки называются Reference Sets. Как они выглядят, показано на рис. 2. Как правило, SIEM-системы позволяют импортировать информацию во внутренние списки, которые мы планируем использовать для хранения индикаторов компрометации и контекста к ним. В первую очередь нас интересует возможность автоматизированной загрузки информации в такие списки, например, через предоставляемый REST API или другим способом. Какие индикаторы можно применить, зависит от информации в логах SIEM. В общем случае ограничиться теми, которые встречаются чаще всего: URL — обращение пользователей к веб-ресурсу, например, при попытке скачивания вредоносного ПО. Такую информацию можно получить с серверов Proxy, которые используются в организации. FQDN — запросы пользователей и сетевых устройств на разрешение доменного имени. Обычно информацию берут с серверов DNS в корпоративном сегменте. IP — сетевые соединения с подозрительными IP-адресами, например C&C. Информацию обычно предоставляют межсетевые экраны и другие устройства, которые ведут журналы сетевых соединений. Hash — информация по хешам вредоносного ПО. Email — скомпрометированные адреса пользователей электронной почты, адреса, используемые злоумышленниками для рассылки фишинговых писем и т. д. Такую информацию SIEM собирает с серверов электронной почты. Это базовые типы индикаторов, набор которых применяется практически в любой SIEM-системе. Его всегда можно расширить по мере необходимости, если в доступных логах есть то, что вы хотите найти. Основной механизм применения TI в SIEM — правила корреляции. Обычно применяют один из подходов: писать правила корреляции, которые основаны только на индикаторах компрометации и доступном контексте; дополнять существующие правила новыми условиями. Лучшего подхода не существует, однако дадим несколько рекомендаций по подготовке и применению правил. Не стоит использовать правила, которые формируют инцидент по индикатору без контекста. В особенности это касается индикаторов типа IP: получите огромное количество ложноположительных срабатываний. Желательно провести разбор, если в инфраструктуре встретились индикаторы Hash и URL. Могут быть исключения, и все зависит от используемых источников TI, доступных логов и преследуемых целей. Разделять правила под индикаторы. Например, на те, которые детектят только C&C или DGA, и другие, для которых есть необходимый контекст или которые имеют определенный скоринг. Коррелировать выявленные инциденты КБ с индикаторами компрометации. Так удастся получить больше контекста для события КБ и повысить его значимость. Не стоит создавать инцидент КБ, если событие было заблокировано СЗИ. Такую информацию можно использовать, чтобы собирать статистику и проверять готовность СЗИ к обеспечению безопасности инфраструктуры. На рис. 3 показали, как работает правило корреляции с применением TI. SIEM-системы позволяют искать индикаторы в приходящих событиях в реальном времени и в логах, накопленных ранее. Первый способ применяется на потоке, а второй, как правило, только при расследовании инцидентов. Однако бывают исключения, и на потоке также ищут индикаторы в истории событий за последнюю неделю-месяц. Таким образом исключаются ситуации, когда индикаторы пришли позднее попыток компрометации инфраструктуры, но требуют больших ресурсов для хранения, поиска и разбора таких инцидентов. Результатом применения индикаторов компрометации в SIEM может быть: выявление инцидентов КБ в реальном времени или в истории логов; обогащение информации по инциденту дополнительным контекстом для упрощения расследования. Качество результатов напрямую зависит от следующих факторов: качества индикаторов, понимания их происхождения и способов применения; надежности и релевантности источника, предоставляющего данные по индикаторам; правил корреляции — правила по умолчанию или из интернета приносят меньше пользы, чем разработанные под конкретную IT-инфраструктуру. IBM QRadar предоставляет собственное приложение TI для работы с TIP по протоколу TAXII. Не все TIP поддерживают этот стандарт, а некоторые версии поддерживают не в полном объеме. На официальном сайте есть инструменты, необходимые для разработки собственного приложения, в виде SDK. На момент написания статьи доступна версия 2.0.0. Основной язык программирования — Python, а для создания простого веб-интерфейса используется веб-фреймворк Flask, который реализован на том же Python. Отсюда можно начать свое знакомство с SDK. Здесь много хороших примеров работы с API QRadar. Начать лучше с изучения API SIEM. В QRadar имеется Swagger, с помощью которого можно поиграть с API, попробовать различные методы работы со списками, которые необходимы для интеграции. Чтобы добраться до него, выбираем в меню пункт Interaсtive API for Developers (рис. 4). Нас в первую очередь интересуют методы для работы со списками Reference Sets (рис. 5). Необязательно разрабатывать полноценное приложение. Можно, например, сделать скрипт на Python, который будет выполнять основную задачу. В нашем случае это скачивание индикаторов из TI-источника и загрузка их в список. Запускается такой скрипт вне приложения, а для его работы потребуется только указать учетные данные и адрес SIEM. Возможно, кому-то такой способ интеграции покажется наиболее простым и удобным. Если в дальнейшем мы захотим сделать полноценное приложение, то логику нашего Python-скрипта можно будет без проблем использовать снова. Пример скрипта для загрузки индикаторов в списки: Этот скрипт загружает индикаторы из текстового файла в список QRadar с именем Suspicious_IPs. Параметры запуска: python3 script.py iocs.txt, где iocs.txt — текстовый файл с индикаторами вида: При запуске скрипта загрузим в QRadar список этих IP-адресов. Таким образом, самая простая интеграция у нас уже есть и остается только написать правила корреляции. Наша первая интеграция была именно такой: скрипт заполнял списки, а правила корреляции использовали индикаторы из них. Такой способ вполне подходит небольшим командам для проверки гипотезы, но в то же время не годится для применения в рамках регулярных процессов: обеспечения непрерывной работы, корректировки настроек через конфигурационный файл и прочего. Тогда лучше задуматься о полноценном приложении, ориентированном на конечного пользователя. Рассмотрим вариант создания собственного приложения TI, в котором будут: все необходимые для его работы компоненты; дополнительный контент, включая правила корреляции, списки, поисковые запросы, отчеты и дашборды. Скачиваем SDK и приступаем к изучению. Потребуются знания Python и HTML. SDK устанавливается под MacOS и Linux, на Windows его можно использовать с помощью WSL v2 (Windows Subsystem for Linux). Приложение, которое мы создаем с помощью SDK, разворачивается в докер-контейнере. Такой способ формирует изолированную среду для приложения и дает возможность безопасно взаимодействовать с SIEM-системой посредством REST API. Как выглядит архитектура нашего приложения, показываем на рис. 6. Веб-интерфейс служит для взаимодействия пользователя с приложением. В нашем случае пользователь настраивает учетные данные для подключения к TI, может определить индикаторы и источники для загрузки в SIEM, а также задать им расписание. SDK QRadar позволяет создать интерфейс, используя Flask (Python Web Framework) и JS. На рис. 7 изображен интерфейс нашего приложения, написанный на React JS. Бэкенд-сервер — приложение на Flask (Python Web Framework) реализует API, с которым работает веб-интерфейс, и взаимодействует с API QRadar. Фоновый процесс необходим для автоматической загрузки индикаторов в списки. Для запуска фоновых процессов внутри докера используется сервис supervisord. Его конфигурация достаточно простая. Например, с помощью этого сервиса мы запускаем отдельный скрипт app.watcher, который работает в фоне: База данных — место, где хранятся настройки приложения. Рекомендуем использовать встроенную в образ докера SQLite. Ее хватает для хранения настроек приложения. Выбор любой другой (например, PostgreSQL или Mongo) часто приводит к ошибкам тайм-аута при установке приложения: чем оно легковеснее, тем меньше проблем в том числе при обновлении. Правила, дополнительные запросы, отчеты и прочий контент создаются непосредственно в QRadar. Затем они выгружаются вместе с приложением в единый пакет, который можно установить как расширение в другой инсталляции. Консольные команды QRadar для выгрузки контента: /opt/qradar/bin/contentManagement.pl --action search — отобразит список типов выгружаемого контента и их ID; /opt/qradar/bin/contentManagement.pl –action search -c 100 -r "Threat" — отобразит ID приложения, в названии которого есть слово Threat (рис. 8). Все ID своего контента можно сохранить в файл и выгрузить в архив одной командой: /opt/qradar/bin/contentManagement.pl -a export -c package -f TIAppContent. Пример содержимого файла TIAppContent: Выполнив команду, мы получим архив с приложением и контентом, который в дальнейшем можно установить в QRadar. Надеемся, наши советы упростят вам жизнь при разработке собственного приложения. Для удобства мы сгруппировали их по темам. Загрузка индикаторов. Индикаторов может быть много, и загружать их по одному долго. Загружайте данные в списки пачкой. В API QRadar для этого существует отдельный метод /reference_data/sets/bulk_load/{name}. В других SIEM наверняка есть подобная возможность, поэтому используйте ее — это существенно повысит скорость загрузки данных. Фолзы. Тем, кто работает с SIEM, это понятие не чуждо. Как с ними бороться? Подход к решению данной проблемы должен быть комплексным. Вот четыре действия, которые помогут: Тестировать TI (проводить пилоты) перед подключением к боевой системе и выбирать наиболее полезные источники. Исключать и/или фильтровать данные из источников. Фильтрация может быть по скорингу, категориям, тегам и т. д. Понимать, что разбираем как инциденты, а что игнорируем. Это позволит, например, исключать из разбора заблокированный на NGFW трафик или внешние сканирования. Поставить на поток процесс обработки инцидентов. Автоматизация, готовые процедуры и инструкции — наше все. Время жизни индикатора (TTL). Большинство индикаторов имеют срок эффективного применения, или срок жизни, который стоит учитывать, чтобы списки не переполнялись. Для решения проблемы можно: Удалять индикаторы из списков, если они уже потеряли свою актуальность или были отмечены как ложноположительные. Вариант более гибкий и приоритетный, но сложнее в реализации. Использовать механизм TTL, встроенный в SIEM. Простой вариант автоматической очистки списков в QRadar — задать TTL для списка. Правила корреляции. Проще всего настроить правило, которое будет срабатывать при наличии индикатора в событии. На деле использовать такие простые правила можно только в том случае, если индикатор достаточно надежен (Hash или URL) и при его обнаружении можно сразу создавать инцидент. Или же использовать такие правила для формирования статистики и фильтрации полезных сработок для уменьшения фолзов в дальнейшем. Также индикаторы можно применять в существующих правилах корреляции для обогащения дополнительным контекстом, что помогает в расследованиях. Как выглядит правило в самом простом случае, показали на рис. 9. В этом примере правило детектирует любые попытки соединения с IP-адресом из списка, в который мы загрузили информацию о подозрительных IP. Вот как можно усовершенствовать правило. Использовать номер порта, если такая информация существует для индикатора. Например, это может быть IP-адрес командного центра, связь с которым происходит по определенному порту. Так как наш список может содержать только одно значение, то в него нельзя записать информацию о порте. Для этого можно использовать другой формат списка, в QRadar называемый Reference Map of Sets. В нем для одного IP-адреса можно указать все порты, информация по которым есть у нас в TI, и список будет выглядеть следующим образом: Такой список имеет формат JSON, и каждому IP соответствуют номера портов, соединение с которыми мы будем считать подозрительными. Как будет выглядеть правило в данном случае, показано на рис. 10. В этом правиле мы используем список Maps of Sets и проверяем, есть ли у нас в списке Suspicious_IPs_Port IP-адрес назначения и соответствующие ему порты, по которым происходит подключение. Разделить списки для различных IP-адресов, например сделать отдельный список для C&C-серверов и настроить отдельное правило на такой список. Настроить пороги по количеству событий, при превышении которых создавался бы инцидент. Если у вас уже есть собственные правила, можно также добавить для них дополнительное условие проверки по спискам TI. В этом случае информация будет обогащаться контекстом от поставщика TI.