Применение threat intelligence в SIEM на примере QRadar
Почему SIEM
- Здесь, как правило, собираются все необходимые журналы — например, средств защиты информации (СЗИ), сетевых устройств и проч.
- Наличие SIEM говорит об определенном уровне зрелости кибербезопасности (КБ) в организации, поскольку до применения TI еще нужно дорасти.
- В SIEM есть встроенные механизмы корреляции, которые позволяют писать правила сложнее полного совпадения.
- SIEM сейчас один из основных инструментов КБ‑специалиста.
Источники TI
Коротко про источники, откуда можно получать данные 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.
Рис. 1. Схема интеграции TI и SIEM
Задача 1. Поиск индикаторов
OSINT. Находим открытые источники в интернете, читаем описания, изучаем возможности загрузки интересующей нас информации.
MISP. Часто используется в качестве локальной TI‑платформы и предоставляет готовые интеграции со множеством OSINT‑источников.
Коммерческий поставщик. У вас может быть платная подписка от поставщика TI. В этом случае необходимо обратиться к вендору и узнать о возможностях интеграции с вашими СЗИ.
Собственная база данных TI. Возможно, у вас уже есть свой TI. Например, наша команда использует BI.ZONE ThreatVision.
Плюсы и минусы различных источников приведены в таблице. Серебряной пули не существует, и лучше попробовать различные варианты в рамках бюджета, чтобы найти подходящий, или их комбинацию.
| Источник | Плюсы | Минусы |
|---|---|---|
| OSINT |
|
|
| MISP |
|
|
| Коммерческий поставщик |
|
|
| Собственная база данных TI |
|
|
Задача 2. Загрузка индикаторов в SIEM
В SIEM‑системах обычно есть возможность хранить в списках TI‑информацию, которую затем можно использовать в правилах корреляции. Например, загружаем информацию о «плохих» IP‑адресах, делаем простое правило корреляции и детектируем все попытки доступа к ним.
Для решения этой задачи необходимо определиться с набором индикаторов и контекстом, которые можно использовать в правилах корреляции, и изучить технические возможности SIEM‑системы.
В QRadar такие списки называются Reference Sets. Как они выглядят, показано на рис. 2.
Рис. 2. Пример Reference Set из IBM QRadar
Технические возможности SIEM‑системы
Как правило, SIEM‑системы позволяют импортировать информацию во внутренние списки, которые мы планируем использовать для хранения индикаторов компрометации и контекста к ним. В первую очередь нас интересует возможность автоматизированной загрузки информации в такие списки, например, через предоставляемый REST API или другим способом.
Используемые индикаторы
Какие индикаторы можно применить, зависит от информации в логах SIEM. В общем случае ограничиться теми, которые встречаются чаще всего:
- URL — обращение пользователей к веб‑ресурсу, например, при попытке скачивания вредоносного ПО. Такую информацию можно получить с серверов Proxy, которые используются в организации.
- FQDN — запросы пользователей и сетевых устройств на разрешение доменного имени. Обычно информацию берут с серверов DNS в корпоративном сегменте.
- IP — сетевые соединения с подозрительными IP‑адресами, например C&C. Информацию обычно предоставляют межсетевые экраны и другие устройства, которые ведут журналы сетевых соединений.
- Hash — информация по хешам вредоносного ПО.
- Email — скомпрометированные адреса пользователей электронной почты, адреса, используемые злоумышленниками для рассылки фишинговых писем и т. д. Такую информацию SIEM собирает с серверов электронной почты.
Это базовые типы индикаторов, набор которых применяется практически в любой SIEM‑системе. Его всегда можно расширить по мере необходимости, если в доступных логах есть то, что вы хотите найти.
Задача 3. Применение индикаторов в SIEM
Правила корреляции
Основной механизм применения TI в SIEM — правила корреляции. Обычно применяют один из подходов:
- писать правила корреляции, которые основаны только на индикаторах компрометации и доступном контексте;
- дополнять существующие правила новыми условиями.
Лучшего подхода не существует, однако дадим несколько рекомендаций по подготовке и применению правил.
- Не стоит использовать правила, которые формируют инцидент по индикатору без контекста. В особенности это касается индикаторов типа IP: получите огромное количество ложноположительных срабатываний.
- Желательно провести разбор, если в инфраструктуре встретились индикаторы Hash и URL. Могут быть исключения, и все зависит от используемых источников TI, доступных логов и преследуемых целей.
- Разделять правила под индикаторы. Например, на те, которые детектят только C&C или DGA, и другие, для которых есть необходимый контекст или которые имеют определенный скоринг.
- Коррелировать выявленные инциденты КБ с индикаторами компрометации. Так удастся получить больше контекста для события КБ и повысить его значимость.
- Не стоит создавать инцидент КБ, если событие было заблокировано СЗИ. Такую информацию можно использовать, чтобы собирать статистику и проверять готовность СЗИ к обеспечению безопасности инфраструктуры.
На рис. 3 показали, как работает правило корреляции с применением TI.
Рис. 3. Схема работы правила корреляции с применением TI
Поиск индикаторов в истории логов
SIEM‑системы позволяют искать индикаторы в приходящих событиях в реальном времени и в логах, накопленных ранее. Первый способ применяется на потоке, а второй, как правило, только при расследовании инцидентов. Однако бывают исключения, и на потоке также ищут индикаторы в истории событий за последнюю неделю‑месяц. Таким образом исключаются ситуации, когда индикаторы пришли позднее попыток компрометации инфраструктуры, но требуют больших ресурсов для хранения, поиска и разбора таких инцидентов.
Задача 4. Выявление и расследование инцидентов КБ
Результатом применения индикаторов компрометации в SIEM может быть:
- выявление инцидентов КБ в реальном времени или в истории логов;
- обогащение информации по инциденту дополнительным контекстом для упрощения расследования.
Качество результатов напрямую зависит от следующих факторов:
- качества индикаторов, понимания их происхождения и способов применения;
- надежности и релевантности источника, предоставляющего данные по индикаторам;
- правил корреляции — правила по умолчанию или из интернета приносят меньше пользы, чем разработанные под конкретную IT‑инфраструктуру.
Практика на примере IBM QRadar
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).
Рис. 4. Swagger для QRadar
Нас в первую очередь интересуют методы для работы со списками Reference Sets (рис. 5).
Рис. 5. Swagger — Reference Set для QRadar
Необязательно разрабатывать полноценное приложение. Можно, например, сделать скрипт на Python, который будет выполнять основную задачу. В нашем случае это скачивание индикаторов из TI‑источника и загрузка их в список. Запускается такой скрипт вне приложения, а для его работы потребуется только указать учетные данные и адрес SIEM. Возможно, кому‑то такой способ интеграции покажется наиболее простым и удобным. Если в дальнейшем мы захотим сделать полноценное приложение, то логику нашего Python‑скрипта можно будет без проблем использовать снова.
Пример скрипта для загрузки индикаторов в списки:
Этот скрипт загружает индикаторы из текстового файла в список QRadar с именем Suspicious_IPs.
Параметры запуска: python3 script.py iocs.txt, где iocs.txt — текстовый файл с индикаторами вида:
При запуске скрипта загрузим в QRadar список этих IP‑адресов. Таким образом, самая простая интеграция у нас уже есть и остается только написать правила корреляции.
Наша первая интеграция была именно такой: скрипт заполнял списки, а правила корреляции использовали индикаторы из них. Такой способ вполне подходит небольшим командам для проверки гипотезы, но в то же время не годится для применения в рамках регулярных процессов: обеспечения непрерывной работы, корректировки настроек через конфигурационный файл и прочего. Тогда лучше задуматься о полноценном приложении, ориентированном на конечного пользователя.
Приложение TI для QRadar
Рассмотрим вариант создания собственного приложения TI, в котором будут:
- все необходимые для его работы компоненты;
- дополнительный контент, включая правила корреляции, списки, поисковые запросы, отчеты и дашборды.
Скачиваем SDK и приступаем к изучению. Потребуются знания Python и HTML. SDK устанавливается под macOS и Linux, на Windows его можно использовать с помощью WSL v2 (Windows Subsystem for Linux).
Приложение, которое мы создаем с помощью SDK, разворачивается в докер‑контейнере. Такой способ формирует изолированную среду для приложения и дает возможность безопасно взаимодействовать с SIEM‑системой посредством REST API.
Как выглядит архитектура нашего приложения, показываем на рис. 6.
Рис. 6. Архитектура приложения для QRadar
Веб‑интерфейс служит для взаимодействия пользователя с приложением. В нашем случае пользователь настраивает учетные данные для подключения к TI, может определить индикаторы и источники для загрузки в SIEM, а также задать им расписание. SDK QRadar позволяет создать интерфейс, используя Flask (Python Web Framework) и JS. На рис. 7 изображен интерфейс нашего приложения, написанный на React JS.
Рис. 7. Интерфейс настройки задач для приложения QRadar
Бэкенд‑сервер — приложение на 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).
Рис. 8. Выгрузка контента из QRadar
Все 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.
Рис. 9. Простое правило корреляции
В этом примере правило детектирует любые попытки соединения с IP‑адресом из списка, в который мы загрузили информацию о подозрительных IP. Вот как можно усовершенствовать правило.
-
Использовать номер порта, если такая информация существует для индикатора. Например, это может быть IP‑адрес командного центра, связь с которым происходит по определенному порту. Так как наш список может содержать только одно значение, то в него нельзя записать информацию о порте. Для этого можно использовать другой формат списка, в QRadar называемый Reference Map of Sets. В нем для одного IP‑адреса можно указать все порты, информация по которым есть у нас в TI, и список будет выглядеть следующим образом:
{ “1.1.1.1”: ["123", "345", "555"], “2.2.2.2”: ["321", "333", "111"] }
Такой список имеет формат JSON, и каждому IP соответствуют номера портов, соединение с которыми мы будем считать подозрительным. Как будет выглядеть правило в данном случае, показано на рис. 10.
Рис. 10. Простое правило корреляции с портом
В этом правиле мы используем список Maps of Sets и проверяем, есть ли у нас в списке
Suspicious_IPs_PortIP‑адрес назначения и соответствующие ему порты, по которым происходит подключение. - Разделить списки для различных IP‑адресов, например сделать отдельный список для C&C‑серверов и настроить отдельное правило на такой список.
- Настроить пороги по количеству событий, при превышении которых создавался бы инцидент.
- Если у вас уже есть собственные правила, можно также добавить для них дополнительное условие проверки по спискам TI. В этом случае информация будет обогащаться контекстом от поставщика TI.