Полгода назад наш SOC агрегировал 47 TI-фидов в одном MISP-инстансе - отраслевой ISAC, CIRCL OSINT, abuse.ch, несколько коммерческих потоков. IoC автоматически уходили в Splunk через PyMISP, блоклисты обновлялись на Palo Alto NGFW. Схема работала ровно до момента, когда L3-аналитик задал вопрос: «Какие группировки реально таргетируют наш сектор и какие техники ATT&CK мы не покрываем правилами корреляции?»
MISP на этот вопрос не отвечает. Он для этого не проектировался. OpenCTI - отвечает. Но цена ответа - Elasticsearch, Redis, RabbitMQ, MinIO и несколько недель настройки коннекторов. Эта статья - о том, как принять решение, не потратив полгода на платформу, которая решает не вашу задачу.
Критерии отбора: почему именно MISP и OpenCTI
На рынке TI-платформ десятки решений: коммерческие Anomali ThreatStream и ThreatConnect, отечественные Kaspersky TIP, BI.ZONE Threat Intelligence, R-Vision TIP, PT ESC Threat Intelligence. Статья фокусируется на двух open-source платформах по трём причинам.Первая - бюджетный порог входа. MISP и OpenCTI - единственные зрелые open-source TIP с живым сообществом и регулярными релизами. MISP разрабатывается CIRCL (национальный CERT Люксембурга, еженедельные коммиты). OpenCTI - компанией Filigran (регулярные мажорные релизы, активный GitHub).
Вторая - де-факто стандарт. По данным Cosive, MISP - «lingua franca» для TI-sharing сообществ: ISAC, CERT, отраслевые группы доверия. OpenCTI занимает аналогичную позицию в аналитическом слое.
Третья - взаимодополняемость. MISP и OpenCTI - не конкуренты. Они закрывают разные этапы цикла обработки разведданных: collection и distribution (MISP) против analysis и production (OpenCTI). Зрелые SOC запускают обе платформы в связке. Собственно, об этом и поговорим.
Коммерческие и отечественные TIP остаются за рамками - они заслуживают отдельного разбора с учётом стоимости лицензий, сертификации ФСТЭК и наличия в реестре Минцифры. Для субъектов КИИ последний пункт может оказаться решающим, и ни MISP, ни OpenCTI его не закрывают - коллеги на Хабр справедливо это отмечают.
MISP: архитектура обмена индикаторами
MISP (Malware Information Sharing Platform) - движок распределения IoC. Центральная сущность - событие (event): пакет связанных индикаторов (IP, домены, хеши, URL) с контекстом через галактики и таксономии. Данные организуются в sharing groups с гранулярным контролем видимости по TLP.Конкретный пример: в CIRCL OSINT feed за июнь 2026 года опубликовано событие «Phishing Campaign Targeting Hotel Customers in Luxembourg» с тегами
tlp:clear и misp-galaxy:financial-fraud="Phishing". Параллельно поступают ежедневные IDS-алерты с тегами kill-chain:Reconnaissance от участников сообщества. Типичный поток, который MISP принимает, нормализует и раздаёт подписчикам.Интеграция MISP с SIEM и средствами обнаружения
MISP работает по принципу «индикатор + контекст → действие в средствах детекции». Каждый атрибут (IP, хеш, домен) несёт флагto_ids - маркер пригодности для автоматического экспорта в IDS/IPS, SIEM, NGFW. Поддерживаемые форматы: STIX 1.x/2.0, OpenIOC, MISP JSON, CSV. Архитектура API-first - всё доступно через REST API, так что автоматизация здесь штатная, а не костыльная.Типовая интеграция через PyMISP для отправки IoC в SIEM:
Python:
from pymisp import PyMISP
misp = PyMISP('https://misp.local', 'API_KEY', ssl=False)
# IoC за последние сутки, только пригодные для детекции
results = misp.search(
controller='attributes',
type_attribute='ip-dst',
last='1d',
to_ids=True
)Где MISP упирается в потолок:
- Связь «хеш → малварь → группировка → кампания → техники ATT&CK» архитектурно возможна через галактики, но это не core-функция. Модель данных плоская: события и атрибуты, а не граф. Попытка строить на этом атрибуцию - как рисовать карту метро в Excel: можно, но зачем.
- UI устарел. Навигация функциональна, но workflow неинтуитивен для аналитиков, привыкших к современным интерфейсам. Привыкнуть можно, полюбить - вряд ли.
- Качество фидов - ответственность оператора. Подключение 30+ фидов без курирования и выставления confidence levels утопит SIEM в ложноположительных срабатываниях. Коллеги на Хабр отмечают, что MISP «начинает задыхаться» при потоке свыше 50–100 тысяч индикаторов в сутки.
- Нет встроенного механизма автоматической деградации устаревших IoC (decay). Ротация старых индикаторов - ручной процесс или кастомная доработка.
OpenCTI: граф знаний на STIX 2.1
OpenCTI (Open Cyber Threat Intelligence) - платформа аналитического уровня, построенная на стандарте STIX 2.1. Разведданные представляются как граф: threat actors, intrusion sets, кампании, малварь, инструменты, техники - сущности (entities), связанные отношениями (relationships).Отдельный IoC - наименее интересная единица в OpenCTI. Ценность - в связях: этот хеш принадлежит этому малварю, который использует этот intrusion set, атрибутированный этому актору, проводящему кампании, замапленные на конкретные техники MITRE ATT&CK. OpenCTI отвечает на вопрос «кто, как и зачем», а не только «этот IP плохой». Для SOC из двух человек это избыточно. Для TI-команды из трёх-пяти аналитиков - необходимость.
ATT&CK-маппинг и покрытие техник
MITRE ATT&CK встроен в ядро модели OpenCTI. Каждая кампания, intrusion set или образец малвари связывается с тактиками и техниками нативно. Это позволяет строить coverage matrix - карту того, какие техники ATT&CK покрыты правилами корреляции в SIEM, а какие остаются слепыми зонами.Для SOC это критично - и вот почему в цифрах. По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access - 62 минуты (рекорд - 51 секунда). По данным Mandiant M-Trends 2025, медианное время обнаружения злоумышленника - 11 дней. Разрыв между первым проникновением и обнаружением - то пространство, которое TI-платформа должна сокращать. MISP помогает быстрее обнаружить IoC на периметре (техники Reconnaissance: Search Open Websites/Domains, T1593; Search Open Technical Databases, T1596). OpenCTI помогает понять, какие TTP стоит искать дальше в сети - после того как initial access уже произошёл.
Где OpenCTI создаёт проблемы:
- Концептуальная сложность. STIX 2.1 и графовый подход требуют нескольких недель, чтобы команда начала думать графами, а не списками. Если аналитики работали только с плоскими таблицами индикаторов - будет больно.
- Тяжёлая инфраструктура. Под капотом - Elasticsearch (или OpenSearch), Redis, RabbitMQ, MinIO. Принципиально другой уровень эксплуатационных затрат по сравнению с MISP.
- Не замена sharing-слоя. OpenCTI потребляет и анализирует разведданные, но не является платформой доверенного обмена. Sharing groups, гранулярный TLP-контроль, федеративная синхронизация между CERT - всё это остаётся за MISP.
- Коннекторы ломаются при мажорных обновлениях. На практике это значит: после каждого апгрейда нужен инженер, который знает Python и GraphQL API OpenCTI, чтобы починить кастомные интеграции. Бюджетируйте это время заранее.
Сравнение MISP и OpenCTI для SOC: trade-off таблица
| Критерий | MISP | OpenCTI |
|---|---|---|
| Основная задача | Сбор и распределение IoC | Анализ и моделирование угроз |
| Модель данных | События + атрибуты (плоская) | Граф знаний STIX 2.1 |
| ATT&CK-маппинг | Через галактики (ограниченно) | Нативно в ядре модели |
| Обмен с партнёрами (ISAC, CERT) | Нативно, sharing groups, TLP | Ограниченно, требует ручной настройки |
| Интеграция с SIEM | API-first, PyMISP, STIX/TAXII | GraphQL API, коннекторы |
| Управление фидами | Большая библиотека публичных фидов | Через коннекторы (MISP, OTX и др.) |
| Атрибуция кампаний и акторов | Слабая | Сильная - граф связей |
| Кривая обучения | Умеренная (дни до операционной готовности) | Высокая (недели до продуктивного использования) |
| UI/UX | Функциональный, устаревший | Современный, граф-ориентированный |
| Decay/ротация IoC | Ручная или через модули | Встроенный механизм aging |
| Инфраструктурная нагрузка | Низкая (PHP, MySQL, Redis) | Высокая (ES + Redis + RabbitMQ + MinIO) |
| Оптимален для | SOC с IoC-driven detection | TI-команда с задачей атрибуции и TTP-анализа |
Требования к инфраструктуре для развёртывания TI-платформы
Разница в ресурсах - не формальность. Это решающий фактор для команд с ограниченным бюджетом, и я видел не один проект, который захлебнулся именно на инфраструктуре.MISP:
| Параметр | Минимум | Рекомендуется |
|---|---|---|
| RAM | 4 ГБ | 8 ГБ |
| CPU | 2 ядра | 4 ядра |
| Диск | 50 ГБ SSD | 100 ГБ SSD |
| Компоненты | Apache/Nginx, PHP, MySQL/MariaDB, Redis | + MISP modules для enrichment |
| Развёртывание | Один сервер (VM или bare metal) | Docker Compose или Ansible |
MISP поднимается за 2–4 часа на одной VM. Основная сложность - не инфраструктура, а настройка sharing groups и курирование фидов. Сам движок нетребователен.
OpenCTI:
| Параметр | Минимум | Рекомендуется |
|---|---|---|
| RAM | 16 ГБ | 32 ГБ |
| CPU | 4 ядра | 8 ядер |
| Диск | 100 ГБ SSD | 250+ ГБ SSD |
| Компоненты | Elasticsearch/OpenSearch, Redis, RabbitMQ, MinIO, PostgreSQL, OpenCTI Platform, Workers | + коннекторы (каждый - отдельный контейнер) |
| Развёртывание | Docker Compose (8+ контейнеров) | Kubernetes для production |
Elasticsearch один забирает 8+ ГБ RAM в production-конфигурации. При 50+ фидах и активном enrichment объём данных растёт на 5–10 ГБ в месяц. Бюджетировать серверные ресурсы стоит с двукратным запасом от минимума - иначе через полгода начнёте воевать с OOM-killer'ом.
Когда MISP достаточно, а когда нужен OpenCTI
Решение зависит не от «какая TI-платформа лучше», а от зрелости процесса в SOC.MISP достаточно, если:
- Основная задача - агрегация фидов и автоматическая доставка IoC в SIEM/NGFW/EDR (Splunk, QRadar, ELK, Palo Alto, CrowdStrike Falcon)
- SOC работает в режиме IoC-matching: есть совпадение - есть алерт
- Организация участвует в ISAC или обменивается данными с CERT
- TI-функция - 1–2 человека, задача атрибуции кампаний не стоит
- Бюджет на инфраструктуру ограничен одной VM с 8 ГБ RAM
- SOC переходит от IoC-driven detection к TTP-based hunting
- Есть выделенная TI-команда (3+ аналитиков), которая готовит брифинги по группировкам для руководства
- Необходим ATT&CK coverage tracking - карта покрытия техник правилами корреляции
- Задача: связать разрозненные IoC от разных инцидентов в единую картину кампании
- Бюджет позволяет выделить сервер с 32+ ГБ RAM под TI-стек
Связка MISP + OpenCTI: архитектура зрелого SOC
Выбор между MISP и OpenCTI - не вопрос «какая open-source TI-платформа лучше». Это вопрос о том, на каком этапе находится TI-процесс в SOC. Большинство команд, которые я наблюдал за последние три года, совершают одну и ту же ошибку: разворачивают OpenCTI слишком рано. Разворачивают, потому что граф красивый, UI современный, ATT&CK-маппинг из коробки. Через три месяца Elasticsearch съедает 24 ГБ RAM, коннекторы ломаются при апгрейде, а аналитики по-прежнему смотрят в Splunk и ищут IoC по хешам. Граф знаний пустует - в SOC из двух человек некому его наполнять и эксплуатировать.
MISP при этом решает 80% операционных задач: приём фидов, нормализация, экспорт в SIEM, обмен с партнёрами. Если у вас нет выделенной TI-функции с задачей атрибуции кампаний - OpenCTI превращается в дорогую инфраструктуру без хозяина. По данным IBM X-Force Threat Intelligence Index 2025, 32% всех детектируемых угроз - infostealers. Для их обнаружения достаточно качественных IoC-фидов, доставленных в SIEM вовремя.
Начинайте с MISP. Стройте процесс курирования фидов и автоматического экспорта в средства детекции. OpenCTI подключайте, когда аналитики начнут задавать вопросы, на которые плоский список индикаторов не отвечает - вопросы о группировках, кампаниях и непокрытых техниках ATT&CK. На codeby.net идёт обсуждение архитектурных решений для TI-стека в корпоративном SOC - если строите связку TI-платформа + SIEM, там коллеги делятся опытом с конкретными конфигурациями.
