Плейбук реагирования в TheHive: от Word-чеклиста к единой карточке инцидента

14 алертов за четырёхчасовую смену — обычная нагрузка L1-аналитика (первая линия SOC, принимает и сортирует входящие события) в среднем SOC (Security Operations Center — центр мониторинга и реагирования на киберинциденты). Проблема не в количестве. Проблема в том, что три из этих алертов — фишинговое письмо с вложением, запуск PowerShell на хосте получателя и аномальный исходящий трафик к внешнему IP — были звеньями одной атаки. В Excel-таблице они превратились в три разрозненные строки без связи. Корреляцию нашёл L2 (вторая линия, расследует подтверждённые инциденты) только утром — вручную сопоставив IP-адреса. В TheHive эти три алерта стали бы одним кейсом за минуту: артефакты связаны, задачи назначены, обогащение запущено автоматически. Ниже — как я строю плейбук реагирования в TheHive и почему шаблон кейса заменяет Word-чеклист.

Почему чек-лист в Word не работает для управления инцидентами

Word-документ с таблицей реагирования — не шутка, а реальность многих команд на старте. Типичный формат: колонки «Дата», «Тип», «Действия», «Статус», «Ответственный». Работает, пока инцидентов меньше двух в день и аналитик один.

Три проблемы, которые повторяются из проекта в проект:

Нет связи между объектами. Алерт из SIEM (Security Information and Event Management — система сбора и корреляции событий безопасности) — одна строка. Хеш вредоносного файла — комментарий в ячейке «Дополнительно». IP-адрес C2-сервера (Command & Control — сервер, через который атакующий управляет вредоносным ПО на заражённых хостах) — в примечаниях. Когда через неделю тот же IP всплывает в новом алерте, найти связь можно только полнотекстовым поиском по десяткам файлов. На практике — никто не ищет.

Нет аудита действий. Кто перевёл статус инцидента из «В работе» в «Закрыт»? Когда? На каком основании? В Word этой информации нет. При постинцидентном разборе восстановить хронологию действий команды невозможно. Это прямое противоречие практике RS.AN-01 из NIST CSF 2.0 (фреймворк кибербезопасности от NIST; RS.AN-01 требует, чтобы уведомления от систем обнаружения расследовались и документировались с полным аудитом — кто, что, когда сделал).

Нет масштабирования. Два аналитика не могут работать над одним файлом без конфликтов версий. Двадцать открытых кейсов в команде из трёх человек — координация разваливается. Кто взял какой инцидент? Какие задачи закрыты? Это видно только если позвонить коллеге.

TheHive — open-source платформа для управления инцидентами, созданная CERT Banque de France (CERT BDF) специально для SOC-команд. Не переделанный helpdesk и не тикетная система с ИБ-ярлыками. Платформа изначально спроектирована для работы с обсервейблами (observables — наблюдаемые артефакты инцидента: IP-адреса, хеши файлов, домены), уровнями TLP и автоматическим анализом индикаторов через движок Cortex. Развитием сейчас занимается компания StrangeBee.

IR-кейс в TheHive: алерт, задача и обсервейбл

Прежде чем настраивать интеграции, стоит разобраться с тремя базовыми объектами TheHive и их связью. Без этого настройка превращается в ковыряние в интерфейсе вслепую.

Алерт (Alert) — входящее событие из внешнего источника: SIEM, почтовый шлюз, IDS (Intrusion Detection System — система обнаружения вторжений), ручное создание. Содержит заголовок, описание, severity (уровень критичности), источник и набор артефактов. Это «сырой» сигнал, который ещё не стал инцидентом. В интерфейсе алерты попадают в очередь на вкладке Alerts — аналитик просматривает список и решает, какие требуют расследования, а какие можно закрыть как false positive.

Кейс (Case) — расследование. Создаётся вручную или эскалацией алерта (promote/merge). Кейс содержит задачи, обсервейблы, теги, TLP (Traffic Light Protocol — протокол маркировки конфиденциальности: TLP:RED — только для конкретных получателей, TLP:AMBER — для организации, TLP:GREEN — для профильного сообщества, TLP:CLEAR — публично), severity и метрики времени. Каждое действие внутри кейса логируется в ленте аудита справа — кто что сделал и когда. Тот самый аудит, которого нет в Word.

Обсервейбл (Observable) — конкретный артефакт расследования: IP-адрес, доменное имя, хеш файла, email-адрес, URL. Обсервейблы привязаны к кейсу и доступны для автоматического анализа через Cortex. Если один и тот же IP фигурирует в нескольких кейсах — TheHive покажет эту связь автоматически. Не нужно вспоминать, «где-то этот адрес уже был».

Цепочка работает так: SIEM отправляет алерт через webhook (HTTP-запрос с данными события) или API. Алерт попадает в очередь. Аналитик просматривает, при необходимости объединяет несколько связанных алертов и эскалирует в кейс. Артефакты из алерта автоматически переносятся в кейс как обсервейблы. Задачи создаются по шаблону.

Именно эта цепочка — алерт → эскалация → кейс с обсервейблами и задачами — и есть единая карточка инцидента TheHive. Всё в одном месте, связано между собой, документируется.

Шаблон кейса — SOAR-плейбук реагирования в TheHive

Шаблон кейса (case template) — та штука, которая превращает TheHive из базы инцидентов в систему с плейбуками. Крис Сандерс, автор Applied Network Security Monitoring и одного из первых публичных обзоров TheHive, назвал шаблоны «hands down, my favorite feature». Через несколько лет работы с платформой я понимаю почему.

Шаблон задаёт:

Пример: шаблон для фишингового инцидента. Теги содержат T1566.001 из MITRE ATT&CK (открытая база тактик и техник атак — по сути, каталог того, как именно атакуют; T-коды — идентификаторы конкретных техник; T1566.001 = Spearphishing Attachment, тактика Initial Access — первоначальный доступ к инфраструктуре жертвы). Кастомные поля: affected_user (учётная запись получателя письма) и mail_gateway_id (ID письма на шлюзе — пригодится для быстрого поиска и удаления).

Задачи шаблона — это и есть плейбук реагирования:

1. Верифицировать алерт — проверить заголовки письма, подтвердить наличие вложения или ссылки
2. Извлечь артефакты — добавить обсервейблы: email отправителя, домен, хеш вложения, URL из тела
3. Обогатить артефакты — запустить анализаторы Cortex (VirusTotal, AbuseIPDB, URLhaus)
4. Определить масштаб — запросить у почтового сервера список всех получателей этого письма
5. Containment — заблокировать отправителя на шлюзе, изолировать хост при необходимости
6. Связаться с пользователем — выяснить, открывал ли вложение
7. Remediation — удалить письмо из ящиков, проверить хост на IoC (Indicators of Compromise — индикаторы компрометации: хеши файлов, IP-адреса, домены, по которым можно определить, был ли хост заражён)
8. Закрыть кейс — заполнить резолюцию, обновить метрики

Когда аналитик эскалирует алерт с типом «phishing», TheHive автоматически создаёт кейс по шаблону. Все восемь задач появляются в очереди Waiting Tasks в верхнем меню. Аналитик берёт задачу, выполняет, записывает результат в task log (встроенный журнал задачи) и закрывает. Конкретный пошаговый чеклист с отслеживанием каждого действия — не абстрактное «реагируйте согласно процедуре» из Word.

Типовые шаблоны, которые я создаю в каждом проекте: фишинг (T1566.001 / T1566.002 — Spearphishing Attachment и Spearphishing Link), подозрительный логин или brute-force (T1078 — Valid Accounts, тактики Initial Access и Persistence), подозрительный RAT или C2-коммуникация (T1105 — Ingress Tool Transfer, тактика Command and Control), вирусное заражение рабочей станции.

Интеграция алертов из SIEM в карточку инцидента TheHive

Без потока алертов TheHive — база для ручного заполнения. Интеграция с SIEM превращает платформу в рабочий инструмент автоматизации реагирования на инциденты.

Два способа подключения:

Webhook из SIEM. При срабатывании правила корреляции SIEM отправляет HTTP POST на API TheHive с JSON-телом алерта. Работает с ELK Stack, Splunk и с российскими решениями — MaxPatrol SIEM и KUMA (Kaspersky Unified Monitoring and Analysis). Формат JSON одинаковый, различается только настройка исходящего вебхука в конкретном продукте.

Пример создания алерта через curl (предпосылки: TheHive запущен и доступен по http://thehive:9000, получен API-ключ пользователя с ролью analyst или org-admin):

curl -X POST http://thehive:9000/api/alert \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"title":"Suspicious PowerShell on WS-042",
       "type":"siem_alert","source":"ELK","severity":2,
       "description":"Encoded PowerShell command detected",
       "artifacts":[{"dataType":"ip","data":"10.0.1.42"},
                    {"dataType":"hostname","data":"WS-042"}]}'

Если запрос прошёл — TheHive вернёт JSON с полем id созданного алерта, и тот появится на вкладке Alerts. Ошибка 401 — проблема с API-ключом (проверь, не истёк ли он). Ошибка 400 — не хватает обязательных полей: title, type, source.

TheHive4py — Python-библиотека для программного взаимодействия с API TheHive. Нужна, когда логика сложнее одного webhook: обогащение алерта данными из нескольких источников перед отправкой, дедупликация по артефактам, фильтрация по severity. Установка: pip install thehive4py. Типовой сценарий — скрипт, который опрашивает SIEM и создаёт алерты в TheHive с уже подготовленными обсервейблами.

Объединение алертов (merge) — функция, которой нет ни в одном чек-листе. Когда по одному хосту приходит три алерта (подозрительный процесс, сетевая аномалия, срабатывание антивируса), аналитик объединяет их в один кейс. Все артефакты из каждого алерта собираются в общий список обсервейблов. Именно такую корреляцию L2 из начала статьи делал вручную — в TheHive это один клик.

Артефакты инцидента TheHive и автоматизация обогащения через Cortex

Обсервейбл без контекста — сырые данные. IP-адрес 185.220.101.42 сам по себе ничего не говорит. Cortex — отдельный компонент в связке с TheHive — запускает анализаторы (analyzers) по каждому обсервейблу и возвращает результат прямо в карточку инцидента.

Цепочка:

1. Cortex принимает обсервейбл из TheHive (IP, хеш, домен, URL)
2. Запускает один или несколько анализаторов — Python-модулей, обращающихся к внешним сервисам
3. Возвращает отчёт в TheHive, привязанный к конкретному обсервейблу

Cortex-анализаторы из штатного набора:

На практике это выглядит так: аналитик открывает кейс, переходит на вкладку Observables, выделяет нужный артефакт и нажимает «Run Analyzers». Через 10–30 секунд рядом с обсервейблом появляется иконка с результатом. Клик — и видно: VirusTotal показывает «15/68 malicious» для хеша вложения, AbuseIPDB даёт confidence 87% для IP отправителя. Это уже не «подозрительный алерт», а подтверждённый вредоносный артефакт с конкретными цифрами.

Следующий уровень — auto-run. В настройках Cortex можно включить автозапуск анализаторов при добавлении обсервейбла определённого типа. Добавил IP в кейс — AbuseIPDB и Shodan запустились сами. Добавил хеш — VirusTotal отработал без клика аналитика. По сути, базовая функция SOAR (Security Orchestration, Automation and Response — платформа оркестрации и автоматизации реагирования), не требующая написания кода.

Маркировка TLP для обсервейблов — рабочий инструмент, а не формальность. IP-адрес C2-сервера с TLP:GREEN можно передать в отраслевой CERT для блокировки на периметре других организаций. Внутренний IP скомпрометированного хоста с TLP:AMBER остаётся строго внутри организации. TheHive отслеживает TLP на уровне каждого обсервейбла и при экспорте данных предупредит о нарушении протокола.

Workflow реагирования на инциденты ИБ: фишинг от алерта до закрытия

Сквозной сценарий — от срабатывания SIEM до закрытого кейса. Предпосылки: TheHive и Cortex установлены (Docker-контейнер с обоими компонентами поднимается одной командой, описанной в документации проекта), настроен webhook из SIEM, создан шаблон кейса для фишинга по структуре из предыдущего раздела.

Шаг 1. Алерт из SIEM. Почтовый шлюз зафиксировал вложение .docm с макросом. Правило корреляции сработало, webhook отправил JSON в TheHive. Алерт появляется на вкладке Alerts: severity Medium, тип phishing, артефакты — email отправителя, хеш вложения, IP источника.

Как убедиться, что работает: на вкладке Alerts — новая запись. Значок уведомлений в правом верхнем углу показывает количество непросмотренных алертов.

Шаг 2. Эскалация алерта в кейс. Аналитик открывает алерт, просматривает артефакты. Нажимает «Create case» и выбирает шаблон Phishing — Spearphishing Attachment. TheHive создаёт кейс с заполненными полями и восемью задачами из шаблона. Артефакты алерта переносятся как обсервейблы кейса.

Ожидаемый результат: кейс с номером (например, #247) появился в списке Cases. В ленте аудита справа — запись вида «analyst1 created case #247 from alert #1052».

Шаг 3. Обогащение через Cortex. Вкладка Observables — три обсервейбла. Выбрать все, нажать «Run Analyzers». Cortex отправит запросы к VirusTotal, AbuseIPDB и URLhaus.

Ожидаемый результат: через 15–30 секунд рядом с каждым обсервейблом появляется иконка отчёта. Клик — детали: количество детектов, репутация IP, статус URL.

Шаг 4. Работа по задачам. Аналитик берёт задачу «Определить масштаб» из очереди Waiting Tasks. Запрашивает у почтового сервера всех получателей с тем же Message-ID. Находит ещё четверых. Фиксирует результат в task log.

Допустим, один из получателей открыл вложение и на его хосте обнаружен PowerShell с закодированной командой. Аналитик добавляет новый обсервейбл (хеш скрипта), проставляет тег T1059.001 (PowerShell, тактика Execution — выполнение вредоносного кода) и повышает severity кейса до High. Вся история изменений остаётся в ленте аудита.

Шаг 5. Containment и remediation. Задачи из шаблона: блокировка отправителя на шлюзе, удаление письма из всех ящиков, изоляция скомпрометированного хоста. Каждое действие — запись в task log с временной меткой.

Шаг 6. Закрытие кейса. Все задачи завершены. Аналитик выбирает резолюцию: True Positive, impact: impactful, добавляет summary с описанием цепочки: T1566.001 → T1059.001. Кейс закрыт. Метрики — время от алерта до эскалации, от эскалации до закрытия — рассчитаны автоматически. Через месяц руководитель SOC видит в дашборде: средний MTTR (Mean Time to Respond — среднее время от получения алерта до завершения реагирования) по фишингу — 47 минут. В Word-таблице эту цифру пришлось бы высчитывать вручную.

Когда TheHive не закроет задачу

TheHive решает кейс-менеджмент и базовую автоматизацию обогащения. Но это не полноценный SOAR. Для автоматического реагирования без участия аналитика — изоляция хоста через EDR по API, блокировка IP на файрволе — придётся дописывать логику через TheHive4py и внешние скрипты либо подключать отдельную SOAR-платформу (Shuffle, n8n с кастомными сценариями).

Для команды из одного-двух человек с пятью инцидентами в месяц TheHive может быть избыточен — хватит структурированного шаблона в Notion. Порог, где платформа начинает окупать затраты на настройку — примерно 15 алертов в день при команде от трёх аналитиков.

Отдельная тема — Security Logging and Monitoring Failures (A09:2021 по OWASP — недостаточное логирование и мониторинг). TheHive документирует действия команды реагирования, но если на входе нет качественных алертов из SIEM, шаблоны останутся пустыми. Плейбук реагирования в TheHive работает ровно настолько, насколько хорош поток событий на входе.

Я видел это много раз: команда ставит TheHive с энтузиазмом — пять шаблонов кейсов, десять анализаторов Cortex, аккуратные теги MITRE ATT&CK. Через три месяца шаблоны устаревают, API-ключи к VirusTotal протухают, новый аналитик не понимает, зачем в задаче «Определить масштаб» нужно искать Message-ID, а не просто звонить пользователю. Инструмент без процесса — мёртвый инструмент.

Реальная ценность TheHive не в интерфейсе. Она в том, что создание шаблона вынуждает формализовать процесс. Пока описываешь задачи фишингового кейса, проговариваешь каждый шаг: кто делает, что проверяет, какой результат, что дальше. Это упражнение стоит больше, чем любой SOAR. Я видел команды, которые позже перенесли шаблоны обратно в Wiki — и продолжали по ним работать, потому что процесс уже был формализован.

Мой прогноз: через два-три года TheHive-подобные платформы станут стандартом для SOC любого размера. Не потому что инструмент сильно изменится, а потому что регуляторы начнут требовать аудит действий при реагировании — и Word-таблица этот аудит не обеспечит. Тем, кто переходит в ИБ и хочет разобраться в SOC-процессах системно — на IB Basics эту базу закрывают за пару месяцев без воды.