Привет. Меня зовут Андрей Урывко, я инженер ИБ.
Это цикл статей о том, как мы перешли с Wazuh на коммерческий SIEM, а затем построили цепочку автоматизации обработки алертов с использованием IRIS (case management), Cortex, MISP и n8n.
В предыдущей части статьи об Интеграция SIEM с IRIS, Cortex, MISP, n8n я рассказывал о том, почему мы перешли с Wazuh и о том, как установить все необходимые приложение и подключить SIEM к n8n.
В этой части я покажу:
базовую настройку IRIS;
логику обработки события «переход по опасной ссылке»;
добавление активов в кейс IRIS.
Настройка IRIS
IRIS в данной схеме используется как case management система SOC: в ней хранятся инциденты, активы и история обработки.
После развертывания IRIS необходимо перейти по ссылке, которую указали в docker-compose - https://iris.hostname.
При первом запуске будет создана УЗ administrator. Пароль можно найти в логах IRIS "WARNING :: post_init :: create_safe_admin". Также пароль для первого входа можно указать через переменную в .env IRIS_ADM_PASSWORD. После первого входа переменная перестанет действовать
Перед началом работы необходимо создать пользователя, из-под которого мы и будем работать. Делается это во вкладке "Advanced" -> "Access Control" -> "Add user". После создания новой УЗ перезаходим под ней.
На вкладке "Case" можно увидеть всю информацию о тестовом кейсе, который был создан при первом запуске.
Подробно про все вкладки можно почитать в официальной документации
Для подтверждённых инцидентов создаётся case, так как они требуют реагирования и трекинга. Подозрительные события оформляются как alert, чтобы не перегружать case management систему.
Если с alerts все просто, достаточно просто по API передать нужные поля, то для case предварительно нужно создать case_template. Необходимо перейти "Advanced" -> "Case Templates" -> "Add case template". Здесь есть готовый пример шаблона кейса. После создания, рядом с новым шаблонов появится его #ID этот id мы будем указывать при создании case.
Обрабатывать события мы будем через сервисную УЗ, поэтому её необходимо создать и добавить в нужную группу. Запоминаем User API Key, он нам понадобится для создания интеграции с n8n.
Зафиксирован переход по опасной ссылке
В качестве примера возьмем кейс "Зафиксирован переход по опасной ссылке" коробочного набора SIEM.
В правиле детектируется событие "переход заблокирован" так же и "переход не был заблокирован". Первое, что необходимо сделать — отсечь события, которые были заблокированы антивирусным средством защиты (АВЗ).Для этого через ноду If проверяем были ли переход заблокирован. Если да, то событие можно закрывать, если нет - пускать на дальнейшую обработку.
Для enrichment я использую Cortex как прокси-слой, который обращается к MISP и возвращает нормализованный вердикт (тут так же можно использовать VirusTotal, Censys и прочее).
Для использования ноды Cortex необходимо указать креды подключения. Делается это через создания новых кред в поле "Credential to connect with". В полях указываем локальный адрес cortex и API ключ.
После создания задания на проверку URL необходимо подождать, пока Cortex сделает запрос в MISP и получит ответ. Задержка в 30 секунд выбрана исходя из среднего времени, за которое Cortex успевает получить ответ от MISP в нашем окружении.
Через 30 секунд идет запрос на получение результатов выполнения задачи в cortex. В качестве аргумента указывает ID задачи, который был получен после выполнения предыдущей ноды cortex.
Следом я проверяю вердикт. Cortex проставляет статус "suspicious" если есть данные в базе MISP и "info", если нет. Если Cortex возвращает статус info, создаётся alert. При статусе suspicious создаётся case, так как индикатор уже подтверждён внешним источником.
Предварительно перед созданием алерта, я собираю итоговый json через ноду code.
Также как и для Cortex создаем креды подключения для IRIS.
Следом создаю алерт через ноду IRIS.
| Набор полей можно посмотреть на сайте разработчика
Кейс создается несколько иначе, так как для него можно указать case_template, который мы создавали недавно.
Вот так выглядит созданный алерт и кейс
Добавление активов
В отличие от алертов, при создании кейса нельзя сразу указать активы, поэтому приходится добавлять их отдельно.
Первое, что я делаю — собираю всю необходимую информацию в одну ноду для дальнейшей обработки.
Следом я получаю активы. Имя пользователей и имена машин для моей SIEM находятся в конкретных полях, поэтому я и прописываю строго обращение к этим полям. Далее я проверяю каждый актив на его наличие и потом с помощью ноды Switch я распределяю активы на свои ноды. Запрос для user_name и host_name различаются, отсюда и несколько нод создания активов.
На вкладке "Case" -> "Assets" можно увидеть созданные активы
В результате мы получили автоматизированную цепочку обработки событий, которая снижает нагрузку на SOC и позволяет заводить кейсы только по подтверждённым инцидентам.
В следующей части я расскажу как настроить Cortex и MISP. А так же как запускать задачи на проверки ioc.
