Введение

Эта статья — продолжение цикла про поиск и применение TI-информации. В нем мы делимся нашим опытом и надеемся, что он поможет сэкономить время на самостоятельное изучение. Мы расскажем про то, как загрузить и применить индикаторы компрометации в SIEM на примере IBM QRadar. IBM ушла с российского рынка в 2022 году, но продукт все еще распространен, и вряд ли ситуация поменяется в ближайшее время.

Предыдущая статья.

Почему SIEM:

• Здесь, как правило, собираются все необходимые журналы, например, средств защиты информации (СЗИ), сетевых устройств и проч.

• Наличие SIEM говорит об определенном уровне зрелости кибербезопасности (КБ) в организации, поскольку до применения TI еще нужно дорасти.

• В SIEM есть встроенные механизмы корреляции, которые позволяют писать правила сложнее полного совпадения.

• SIEM сейчас один из основных инструментов КБ-специалиста.

Источники TI

Коротко про источники, откуда можно получать данные TI.

1. OSINT — это бесплатные источники информации по индикаторам и не только, которые находятся в свободном доступе в интернете. Они дают различные варианты предоставления данных об угрозах. Это может быть сайт, где публикуют информацию о новых киберугрозах, или какой-нибудь сетевой ресурс, где размещают файлы со списками индикаторов в формате csv, txt и т. д. У каждого источника свой набор данных и свой метод их предоставления. Один дает только списки подозрительных IP-адресов, другой — список вредоносных URL, третий — хеши вредоносного ПО. Отдельно про OSINT можно почитать в нашей предыдущей статье.

2. MISP — это TI-платформа с открытым исходным кодом. Имеет множество интеграций с различными OSINT и позволяет удобно агрегировать их. В MISP также реализован API, что дает ей дружить с внешними системами.

3. Коммерческие источники TI — обычно это облачные сервисы по платной подписке. Многие провайдеры предоставляют возможности интеграции с наиболее популярными сетевыми устройствами. Также многие СЗИ уже поддерживают интеграцию с коммерческими поставщиками TI из коробки.

4. Собственные источники — данные из собственных расследований, реверс-инжиниринга вредоносного ПО, результаты Threat Hunting, данные из песочницы и проч.

Цель и задачи интеграции

Цели интеграции — выявить инциденты КБ и получить дополнительный контекст при их расследовании.

Перечислим типовые задачи для их достижения:

1. Получить или загрузить индикаторы автоматизированным способом из источника TI.

   • Загрузить данные посредством API, предоставляемого источником TI.

   • Загрузить данные по протоколу TAXII в формате STIX — разработанном MITRE стандарте для обмена информацией по киберугрозам.

   • Загрузить индикаторы иным способом, предоставляемым источником TI.

2. Доставить индикаторы в SIEM.

   • Определить технические возможности и способы загрузки индикаторов в SIEM.

   • Определить набор индикаторов и их контекст, которые можно загрузить и использовать в SIEM.

3. Применить индикаторы в SIEM.

   • Создать правила корреляции, использующие индикаторы в SIEM.

   • Коррелировать события с использованием TI.

   • Анализировать журналы безопасности на предмет наличия индикаторов компрометации, получить контекст TI.

4. Выявить и расследовать инциденты КБ.

   • Выявить реальные инциденты, отсеять ложноположительные срабатывания.

   • Расследовать инциденты с использованием информации из TI.

В рамках статьи мы рассказываем про интеграцию с IBM QRadar. Но для других SIEM-систем принцип решения задачи остается тот же, отличается только способ реализации.

Общая схема интеграции изображена на рис. 1.

Задача 1. Как найти индикаторы

OSINT. Находим открытые источники в интернете, читаем описания, изучаем возможности загрузки интересующей нас информации. 

MISP. Часто используется в качестве локальной TI-платформы и предоставляет готовые интеграции со множеством OSINT-источников.

Коммерческий поставщик. У вас может быть платная подписка от поставщика TI. В этом случае необходимо обратиться к вендору и узнать о возможностях интеграции с вашими СЗИ.

Собственная база данных TI. Возможно, у вас уже есть свой TI.

Плюсы и минусы различных источников приведены в таблице. Серебряной пули не существует, и лучше попробовать различные варианты в рамках бюджета, чтобы найти подходящий, или их комбинацию.

Задача 2. Загрузка индикаторов в SIEM

В SIEM-системах обычно есть возможность хранить в списках TI-информацию, которую затем можно использовать в правилах корреляции. Например, загружаем информацию о «плохих» IP-адресах, делаем простое правило корреляции и детектируем все попытки доступа к ним.

Для решения этой задачи необходимо определиться с набором индикаторов и контекстом, которые можно использовать в правилах корреляции, и изучить технические возможности SIEM-системы.

В QRadar такие списки называются Reference Sets. Как они выглядят, показано на рис. 2.

Технические возможности SIEM-системы

Как правило, SIEM-системы позволяют импортировать информацию во внутренние списки, которые мы планируем использовать для хранения индикаторов компрометации и контекста к ним. В первую очередь нас интересует возможность автоматизированной загрузки информации в такие списки, например, через предоставляемый REST API или другим способом.

Используемые индикаторы

Какие индикаторы можно применить, зависит от информации в логах SIEM. В общем случае ограничиться теми, которые встречаются чаще всего:

• URL — обращение пользователей к веб-ресурсу, например, при попытке скачивания вредоносного ПО. Такую информацию можно получить с серверов Proxy, которые используются в организации.

• FQDN — запросы пользователей и сетевых устройств на разрешение доменного имени. Обычно информацию берут с серверов DNS в корпоративном сегменте.

• IP — сетевые соединения с подозрительными IP-адресами, например C&C. Информацию обычно предоставляют межсетевые экраны и другие устройства, которые ведут журналы сетевых соединений.

• Hash — информация по хешам вредоносного ПО.

• Email — скомпрометированные адреса пользователей электронной почты, адреса, используемые злоумышленниками для рассылки фишинговых писем и т. д. Такую информацию SIEM собирает с серверов электронной почты.

Это базовые типы индикаторов, набор которых применяется практически в любой SIEM-системе. Его всегда можно расширить по мере необходимости, если в доступных логах есть то, что вы хотите найти.

Задача 3. Применение индикаторов в SIEM

Правила корреляции

Основной механизм применения TI в SIEM — правила корреляции. Обычно применяют один из подходов:

• писать правила корреляции, которые основаны только на индикаторах компрометации и доступном контексте;

• дополнять существующие правила новыми условиями.

Лучшего подхода не существует, однако дадим несколько рекомендаций по подготовке и применению правил.

1. Не стоит использовать правила, которые формируют инцидент по индикатору без контекста. В особенности это касается индикаторов типа IP: получите огромное количество ложноположительных срабатываний.

2. Желательно провести разбор, если в инфраструктуре встретились индикаторы Hash и URL. Могут быть исключения, и все зависит от используемых источников TI, доступных логов и преследуемых целей.

3. Разделять правила под индикаторы. Например, на те, которые детектят только C&C или DGA, и другие, для которых есть необходимый контекст или которые имеют определенный скоринг.

4. Коррелировать выявленные инциденты КБ с индикаторами компрометации. Так удастся получить больше контекста для события КБ и повысить его значимость.

5. Не стоит создавать инцидент КБ, если событие было заблокировано СЗИ. Такую информацию можно использовать, чтобы собирать статистику и проверять готовность СЗИ к обеспечению безопасности инфраструктуры.

На рис. 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).

Нас в первую очередь интересуют методы для работы со списками Reference Sets (рис. 5).

Необязательно разрабатывать полноценное приложение. Можно, например, сделать скрипт на Python, который будет выполнять основную задачу. В нашем случае это скачивание индикаторов из TI-источника и загрузка их в список. Запускается такой скрипт вне приложения, а для его работы потребуется только указать учетные данные и адрес SIEM. Возможно, кому-то такой способ интеграции покажется наиболее простым и удобным. Если в дальнейшем мы захотим сделать полноценное приложение, то логику нашего Python-скрипта можно будет без проблем использовать снова.

Пример скрипта для загрузки индикаторов в списки:

import base64
import sys
import json
import requests
 
# QRadar Address and creds (Token)
QR_SERVER = 'https://10.10.10.10'
QR_user = ''
QR_password = ''
QR_auth_token = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx '
QR_version = '16.0'
 
 
# QRadar Authorization
def create_qradar_headers(user, password, version, sec):
    headers = {'Accept': 'application/json', 'Version': version}
    if sec:
        headers['SEC'] = sec
    elif user and password:
        headers['Authorization'] = b"Basic " + base64.b64encode((user + ':' + password).encode('ascii'))
    else:
        print('No valid credentials found in configuration')
        sys.exit(1)
    if not version:
        print('Expect version')
        sys.exit(1)
    return headers
 
def loading(data):
    headers = create_qradar_headers(QR_user, QR_password, QR_version, QR_auth_token)
    dataset = json.dumps(data)
    response = requests.post('{}/api/reference_data/sets/bulk_load/Suspicious_IPs'.format(QR_SERVER),
                                        headers=headers, verify=False, data=dataset)
    return response
 
if len(sys.argv) < 2:
    print("Usage: python load_iocs.py file.txt")
    sys.exit(1)
with open(sys.argv[1], 'r', newline='') as f_inp:
    data = f_inp.read().splitlines()
    response = loading(data)
    print(response.text)

Этот скрипт загружает индикаторы из текстового файла в список QRadar с именем Suspicious_IPs.

Параметры запуска: python3 script.py iocs.txt, где iocs.txt — текстовый файл с индикаторами вида:

1.1.1.1
2.2.2.2
3.3.3.3
4.4.4.4

При запуске скрипта загрузим в QRadar список этих IP-адресов. Таким образом, самая простая интеграция у нас уже есть и остается только написать правила корреляции.

Наша первая интеграция была именно такой: скрипт заполнял списки, а правила корреляции использовали индикаторы из них. Такой способ вполне подходит небольшим командам для проверки гипотезы, но в то же время не годится для применения в рамках регулярных процессов: обеспечения непрерывной работы, корректировки настроек через конфигурационный файл и прочего. Тогда лучше задуматься о полноценном приложении, ориентированном на конечного пользователя.

Приложение TI для QRadar

Рассмотрим вариант создания собственного приложения 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, который работает в фоне:

[program:watcher]
command=python3 -m app.watcher
autorestart=true
stderr_logfile=/opt/app-root/store/log/supervisord.log
stdout_logfile=/opt/app-root/store/log/supervisord.log
environment=MALLOC_MMAP_THRESHOLD_=4096
directory=/opt/app-root

База данных — место, где хранятся настройки приложения. Рекомендуем использовать встроенную в образ докера 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:

customrule,100552,100502,102002,101552,102252,101752,101652,101602,101952,102202,101852,102102,102152,100602,102052,101902,101802,101702,100402
referencedata,22,23,24,25,26,27,28,29,30,31
installed_application,1001

Выполнив команду, мы получим архив с приложением и контентом, который в дальнейшем можно установить в 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, и список будет выглядеть следующим образом:

{
“1.1.1.1”: ["123", "345", "555"],
“2.2.2.2”: ["321", "333", "111"]
}

Такой список имеет формат JSON, и каждому IP соответствуют номера портов, соединение с которыми мы будем считать подозрительными. Как будет выглядеть правило в данном случае, показано на рис. 10.

В этом правиле мы используем список Maps of Sets и проверяем, есть ли у нас в списке Suspicious_IPs_Port IP-адрес назначения и соответствующие ему порты, по которым происходит подключение.

• Разделить списки для различных IP-адресов, например сделать отдельный список для C&C-серверов и настроить отдельное правило на такой список.

• Настроить пороги по количеству событий, при превышении которых создавался бы инцидент.

• Если у вас уже есть собственные правила, можно также добавить для них дополнительное условие проверки по спискам TI. В этом случае информация будет обогащаться контекстом от поставщика TI.