По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access - 62 минуты. Рекорд - 51 секунда. В команде из пяти аналитиков, где я выстраивал TI-процесс, цикл обработки нового IOC от появления в фиде до срабатывания правила в SIEM занимал шесть часов - вручную. За этот разрыв мы платили пропущенными инцидентами: пока хеш попадал в блок-лист, C2-сервер уже свёрнут, payload переупакован. За полгода сократили окно до пятнадцати минут - без бюджета на коммерческие платформы, силами Python-скрипта на cron и бесплатного MISP. Ниже - конспект того, что сработало, с кодом, Sigma-правилами и чеклистом для запуска за две недели.
Сбор threat intelligence: источники и инструменты без коммерческого бюджета
Два вопроса определяют весь TI-процесс в малом SOC. Первый очевиден: какие фиды подключать при нулевом бюджете? Второй задают реже, но он важнее: как быстро эти фиды сжигают инфраструктуру атакующего - и что это значит для ваших detection-окон?Бесплатные cyber threat intelligence инструменты и фиды
Минимальный набор, покрывающий 80% потребностей threat intelligence для SOC численностью 3-8 человек:- CIRCL MISP OSINT feed - агрегирует события от CERT Люксембурга. Из свежего - фишинговая кампания против гостиничного сектора (июнь 2026) и серия IDS-наблюдений с тегами
kill-chain:Reconnaissance. Формат MISP-событий, подключение в один клик через Server Settings -> Feeds - Abuse.ch (URLhaus, MalwareBazaar, ThreatFox) - хеши, URL, C2-домены. Обновления каждые 5 минут, без лимитов на скачивание. Основной источник IOC по infostealers и ransomware
- AlienVault OTX - пользовательские пульсы с IOC, привязанными к конкретным кампаниям. Качество плавает: берите пульсы только от верифицированных авторов с историей, остальное - шум
- AbuseIPDB - краудсорсинговая репутация IP. Бесплатный тариф: 1000 запросов/сутки через
/api/v2/check. Confidence score от 0 до 100, порог 75+ - для автоматической блокировки
Как атакующие видят ваши TI-фиды
Здесь threat intelligence для SOC становится интересным не только аналитикам, но и пентестерам. Атакующие не работают вслепую: техника Threat Intel Vendors (T1597.001, Reconnaissance) описывает целенаправленный мониторинг TI-платформ для проверки, попала ли инфраструктура в фиды. Оператор C2 проверяет свой домен через VirusTotal и AbuseIPDB перед началом кампании и в процессе - это стандарт, а не паранойя.Из этого вытекают выводы для обеих сторон:
- SOC-аналитик: IOC с момента попадания в публичный фид имеет ограниченный TTL - атакующий сменит инфраструктуру за часы. Фид полезен, только если обрабатывается быстрее, чем атакующий ротирует C2
- Пентестер / Red Team: shared-хостинг на VPS с "грязной" репутацией ASN (bulletproof-провайдеры типа Stark Industries) сокращает TTL инфраструктуры до часов. Dedicated-хостинг на чистом IP-диапазоне остаётся незамеченным неделями - но стоит кратно дороже. Для внешнего пентеста это критично; для внутреннего - менее релевантно, если C2 ходит через легитимный канал
Настройка MISP и OpenCTI: TI платформа для SOC малой команды
Обе платформы бесплатны, обе решают задачу сбора и обработки threat intelligence, но архитектурно это разные звери с разными trade-off.
| Критерий | MISP | OpenCTI |
|---|---|---|
| Модель данных | Плоская: события и атрибуты (IP, hash, domain) | Графовая: сущности и связи (STIX 2.1 нативно) |
| Порог входа | Низкий: установка за час, импорт фидов - за вечер | Средний: ElasticSearch, RabbitMQ, MinIO |
| RAM для продакшна | 4-8 ГБ | 16-32 ГБ (ElasticSearch - основной потребитель) |
| TAXII-совместимость | Нативно (TAXII 2.0 сервер и клиент) | Нативно (TAXII 2.1) |
| Визуализация связей | Базовая (корреляционный граф) | Продвинутая (графы знаний, таймлайны кампаний) |
| Интеграция с SIEM | Через ZMQ/API в lookup-таблицы | Коннекторы - прямая выгрузка в Elastic/Splunk |
| Оптимальный сценарий | Команда 2-5 человек, фокус на IOC-обмен, быстрый старт | Команда 5+, фокус на TTP-анализ и граф связей между кампаниями |
Для малого SOC - начинайте с MISP. Через 3-6 месяцев, когда появится потребность в анализе связей между кампаниями и группировками, добавляйте OpenCTI с коннектором к уже работающему MISP. Оба проекта активно поддерживаются (MISP - последний релиз июнь 2026, OpenCTI - стабильный цикл релизов каждые 2-3 недели).
Ограничения и когда обе платформы не помогут. Ни MISP, ни OpenCTI не решают проблему insider threat. TI-платформы работают с внешними индикаторами: C2-домены, вредоносные хеши, IP-адреса атакующих. Скомпрометированный легитимный хост внутри периметра - слепая зона для фидовой модели. Здесь нужны UEBA и baseline-отклонения (DE.AE-01 по NIST CSF 2.0: установление baseline сетевых операций и ожидаемых потоков данных). Я видел SOC, который обвешался фидами как новогодняя ёлка, но пропустил lateral movement через RDP между двумя серверами в одном VLAN - потому что оба IP были "свои".
Требования к окружению для MISP
- ОС: Ubuntu 22.04/24.04 LTS или RHEL 8+
- RAM: минимум 4 ГБ, рекомендуется 8 ГБ при подключении 5+ фидов
- Диск: 50 ГБ SSD (прирост ~5 ГБ/год при стандартном наборе фидов)
- Сеть: исходящий HTTPS к эндпоинтам фидов; входящий - только из внутренней сети SOC
- Режим: online (для обновления фидов); веб-интерфейс работает локально
Обработка индикаторов компрометации и обогащение IOC
Сырой IOC без контекста - шум. IP-адрес в фиде не имеет операционной ценности, пока неизвестно: это C2 ransomware-группы, выходная нода Tor или CDN Cloudflare. Я на этом обжёгся в первый месяц - заблокировали IP из фида, а он оказался Cloudflare-адресом для половины клиентских сервисов. Тикетов было больше, чем от самих атак.
Обогащение через AbuseIPDB - первый уровень контекстуализации для threat intelligence в SOC. Сервис отдаёт
abuseConfidenceScore от 0 до 100, рассчитанный на основе частоты репортов, разнообразия источников и давности. Порог для автоматики: блокировка при score > 75, ручная проверка при 50–75, игнорирование при < 50.Белый список перед блокировкой - обязателен. Без него вы рано или поздно заблокируете что-то важное:
- Tor exit nodes: список на
torproject.org/exit-addresses. Высокий confidence на AbuseIPDB - норма для Tor. Блокировка = потеря легитимных пользователей - CDN ASN: Cloudflare (AS13335), Fastly (AS54113), Akamai - блокировка IP из этих диапазонов положит половину интернета
- CGNAT-выходы: провайдеры с Carrier-Grade NAT генерируют ложные срабатывания. Один IP делят тысячи пользователей
Автоматизация threat intelligence: пайплайн MISP -> AbuseIPDB -> Wazuh
Три уровня зрелости автоматизации TI для SOC:- Ручной (неделя 1): аналитик выгружает CSV из MISP, проверяет IP в AbuseIPDB вручную, вносит в CDB-list Wazuh через текстовый редактор. Время цикла: 4-6 часов. Унизительно, но работает как стартовая точка
- Скриптовый (неделя 2-3): Python-скрипт по cron забирает IOC из MISP, обогащает через AbuseIPDB, записывает в CDB-list. Время цикла: 15 минут
- Оркестрированный (месяц 2+): SOAR-платформа (Shuffle, n8n) управляет конвейером, добавляет нотификации и ретроспективный поиск по историческим логам
Требования к окружению для пайплайна
- Python: 3.10+
- Библиотеки:
pymisp(pip install pymisp),requests - API-ключи: MISP (Settings -> Auth Keys), AbuseIPDB (бесплатный тариф - 1000 запросов/сутки; кешируйте результаты в SQLite/Redis на 24-72 часа, иначе лимит кончится при >10 уникальных IP за запуск)
- Wazuh: доступ на запись в
/var/ossec/etc/lists/на сервере Wazuh Manager - Cron: рекомендуемый интервал - каждые 15 минут
Скрипт обогащения IOC для threat intelligence в SOC
Блок 1 - получение IP-индикаторов из MISP за последние 15 минут:
Python:
from pymisp import PyMISP
import requests, os
MISP_URL = os.environ["MISP_URL"]
MISP_KEY = os.environ["MISP_KEY"]
ABUSE_KEY = os.environ["ABUSEIPDB_KEY"]
CDB_PATH = "/var/ossec/etc/lists/threat_intel"
misp = PyMISP(MISP_URL, MISP_KEY, ssl=False)
attributes = misp.search(controller="attributes", type_attribute="ip-dst", last="15m", pythonify=True)
ips = {a.value for a in attributes}
Python:
enriched = {}
for ip in ips:
try:
r = requests.get("https://api.abuseipdb.com/api/v2/check",
headers={"Key": ABUSE_KEY, "Accept": "application/json"},
params={"ipAddress": ip, "maxAgeInDays": 90})
r.raise_for_status()
score = r.json()["data"]["abuseConfidenceScore"]
except (requests.RequestException, KeyError):
continue # пропускаем при ошибке API или rate limit (429)
if score >= 75:
enriched[ip] = f"score:{score}"
with open(CDB_PATH, "a") as f:
for ip, meta in enriched.items():
f.write(f"{ip}:{meta}\n")local_rules.xml добавляется правило с <list field="srcip" lookup="address_match_key">etc/lists/threat_intel</list> - оно срабатывает при совпадении source IP с записями из нашего списка, level 12 (high). Перезапуск Wazuh Manager (systemctl restart wazuh-manager) применяет изменения и компилирует CDB-list (в Wazuh 4.x это происходит автоматически при рестарте; в более ранних версиях может потребоваться ручной запуск /var/ossec/bin/ossec-makelists).В реальной эксплуатации добавьте дедупликацию (проверку, есть ли IP уже в CDB-list) и ротацию записей старше 30 дней. Без этого список разрастается и тормозит lookup - у нас за три месяца набралось 40 тысяч записей, из которых 90% уже были мертвы.
Применение TI в мониторинге: от IOC до detection rule
Threat intelligence для SOC полезен ровно настолько, насколько интегрирован в detection-конвейер. IOC в MISP, не подключённый к SIEM - каталог, а не защита.Sigma-правила на основе TI-фидов
Sigma - универсальный формат detection rules, конвертируемый в запросы для Splunk (черезsigmac), Elastic (через sigmahq backend) и Wazuh. Пример правила для DNS-запросов к доменам из фида:
YAML:
title: DNS query to TI-flagged domain
logsource:
category: dns
detection:
selection:
query|endswith: # подставьте IOC из вашего фида
- ".malwaredomain.example" # шаблон: замените на актуальный C2
- ".phishkit.example" # шаблон: замените на актуальный фишинг
condition: selection
level: highthreat_intel ECS-поля с автообновлением через Filebeat TI-модуль; в Splunk Enterprise 9.x - inputlookup с CDB-файлом, который обновляет тот же Python-скрипт; в Wazuh 4.x - CDB-list из предыдущего раздела. Sigma позволяет один раз описать логику detection и конвертировать под ваш конкретный стек.Что TI-мониторинг означает для Red Team и пентестеров
Понимание TI-конвейера SOC - оперативная необходимость для наступательной стороны. Если вы ломаете организацию и не знаете, какие фиды подключены к их SIEM, вы работаете вслепую:- TTL домена на engagement: если целевой SOC подключён к CIRCL OSINT или Abuse.ch, свежезарегистрированный домен попадёт в фид в течение 2-48 часов после первого репорта. Это задаёт максимальное окно для initial access. Техники Vulnerability Scanning (T1595.002) и IP Addresses (T1590.005) в фазе Reconnaissance оставляют следы, которые TI-фиды подхватывают. При внешнем пентесте это ваш главный таймер; при внутреннем - менее критично, если initial access уже получен через физический доступ или VPN
- IP-репутация перед кампанией: проверяйте IP через AbuseIPDB до начала. Score > 0 - сигнал сменить провайдера. Я видел, как Red Team-операция сгорела в первый час из-за IP с confidence 45 - SOC получил алерт ещё до того, как beacon вышел на связь
- Ротация C2 как вынужденная мера: по данным Mandiant M-Trends 2025, медианное время обнаружения - 11 дней (исторический минимум). Но SOC с работающим TI-пайплайном детектирует infostealer-инфраструктуру за часы. 57% организаций узнают об инциденте от внешней стороны - и чаще всего причина в том, что TI-данные были доступны, но не дошли до detection-правила вовремя
Что реально работает в threat intelligence для малого SOC
Из всех метрик TI-процесса одна важнее остальных: latency пайплайна - время от появления IOC в фиде до первого алерта в SIEM. Не количество подключённых фидов, не объём базы IOC, а скорость. По данным Verizon DBIR 2025, 68% утечек включают человеческий фактор, а 36% начинаются с фишинга. Если ваш SOC защищает корпоративную инфраструктуру, фиды по фишинговым доменам и стилерам дадут в разы больше, чем полная подписка на APT-трекинг другого региона.
MISP с двадцатью фидами, из которых восемнадцать генерируют шум для вашего стека, хуже, чем три целевых фида с пятнадцатиминутным циклом обогащения.
Я вижу одну системную ошибку в подходе малых SOC-команд к threat intelligence: начинают с выбора платформы, а не с ответа на вопрос "какие угрозы релевантны нашей инфраструктуре". IBM X-Force фиксирует рост атак с использованием действительных учётных данных на 71% год к году - если вы не обогащаете IOC из стилер-фидов и не коррелируете их с аутентификационными логами, вы защищаетесь от прошлогодних угроз. Замерьте latency своего пайплайна прямо сейчас: добавьте тестовый IOC в MISP и засеките, через сколько минут он появится в SIEM как активное правило. Если больше часа - возвращайтесь к шагу 2 из чеклиста. Кто строит или отлаживает TI-to-SIEM интеграцию и хочет сверить подход - на codeby.net коллеги обсуждают рабочие конфигурации MISP-коннекторов и скрипты обогащения под конкретные SIEM-стеки в профильном треде.
Последнее редактирование модератором:
