В консоли SIEM - алерт: indicator match по IP-адресу из коммерческого TI-фида. L1-аналитик открывает карточку: IP лежит в lookup два месяца, confidence score неизвестен, контекст - "malicious activity". Действие: закрыл как false positive. Через три дня тот же IP всплыл в постмортеме - активный C2-сервер, с которого атакующий рулил lateral movement 14 часов.
Знакомо? По данным Mandiant M-Trends 2025, медианное время обнаружения злоумышленника в сети - 11 дней, а 57% организаций узнают об инциденте от внешней стороны. Разрыв между "у нас есть TI-подписка" и "TI реально останавливает атаку" - это и есть задача операционализации threat intelligence. И в большинстве SOC-ов, с которыми я сталкивался, этот разрыв шире, чем кажется.
Почему TI-фиды не превращаются в детекты
Три барьера, которые встречаются в каждом втором SOC.Перегрузка без контекста. Коммерческий фид выдаёт тысячи индикаторов в сутки. Без привязки к конкретным TTPs и релевантности для вашей отрасли - это шум. По данным IBM X-Force Threat Intelligence Index 2025, infostealers составляют 32% всего malware, а в dark web ежедневно появляется более 6 000 свежих учётных данных. Какие из них относятся к вашей инфраструктуре - фид не скажет. Как точно заметили в Cyware: "intelligence without attacker TTPs, motivations, or impact details is hard to prioritize or act on""Сведения без TTP атакующего, мотивации, или важных деталий это сложно определить в первую очередь или принятия меры". Вот и причина, по которой SOC-аналитики тупо игнорируют алерты по IOC.
Интеграционный разрыв. Как писал пользователь на форуме Elastic (discuss.elastic.co), до версии 7.10 в Elastic SIEM "невозможно было нативно обрабатывать threat intel - приходилось поднимать отдельный сервер MISP и экспортировать фиды вручную". Indicator match rules появились, но "результирующий алерт не содержал явной информации о том, какие поля события совпали с какими полями индикатора". Паттерн остался: TI-интеграция в SIEM - инженерная задача, а не коробочная фича.
Отсутствие приоритизации. В 2014 году David Bianco предложил модель Pyramid of Pain (упоминается Wiz в контексте IOC Security): хеши файлов тривиально меняются перекомпиляцией, IP-адреса - сменой хостинга, а TTPs (тактики, техники, процедуры) требуют от злоумышленника полной перестройки операционной модели. Большинство TI-фидов работают в нижней части пирамиды - там, где атакующему дешевле всего уклониться. Регуляторный контекст добавляет финансовый вес: оборотные штрафы за утечки ПДн делают бездействующий TI-стек не только техническим, но и юридическим риском.
Атомарные IOC vs поведенческие правила: сравнение подходов
Это ключевой выбор при операционализации threat intelligence: загружать "сырые" индикаторы компрометации в lookup-таблицы SIEM или конвертировать TI-аналитику в поведенческие Sigma-правила. На практике нужны оба подхода, но пропорция зависит от зрелости SOC.
| Критерий | Атомарные IOC (hash, IP, domain) | Поведенческие правила (TTP, Sigma) |
|---|---|---|
| Время внедрения | Минуты (автозагрузка через STIX/TAXII) | Часы-дни (разработка + тюнинг) |
| Срок жизни правила | Часы - недели | Месяцы - годы |
| False positive rate | Низкий при свежих IOC, растёт с возрастом | Средний, требует baseline |
| Устойчивость к evasion | Низкая (атакующий меняет hash/IP за минуты) | Высокая (смена TTP - дорого и долго) |
| Автоматизация | Полная (STIX/TAXII SIEM интеграция) | Частичная (Sigma-конвертеры) |
| Покрытие MITRE ATT&CK | Фрагментарное (known threats) | Системное (по тактикам) |
| Когда использовать | Свежий отчёт о кампании с C2-инфраструктурой | Детектирование living-off-the-land и insider |
| Когда не использовать | IOC старше 30 дней без переподтверждения | Нет baseline, нет ресурсов на тюнинг FP |
Когда атомарные IOC работают. Свежий отчёт о кампании с конкретными C2-доменами - загрузка в lookup, блокировка на firewall, алерт в SIEM. По данным CrowdStrike Global Threat Report 2025, среднее время lateral movement после initial access - 62 минуты (рекорд - 51 секунда). Если C2-домен из TI-фида заблокирован на периметре до начала lateral movement - цепочка обрывается. Тут скорость решает всё.
Когда нужны поведенческие правила. Атакующий использует PowerShell (T1059.001, Execution) для загрузки инструментов (T1105, Ingress Tool Transfer, Command and Control), отключает логирование (T1685.001, Disable Windows Event Logging, Stealth), чистит журналы (T1685.005, Clear Windows Event Logs, Stealth). Ни один хеш и ни один IP из фида тут не поможет - нужно правило на аномальное поведение. Это living-off-the-land в чистом виде, и фиды против него бессильны.
TI-интеграция в SIEM: Elastic, Splunk и MaxPatrol
Архитектура TI-пайплайна радикально различается в зависимости от SIEM-платформы. Ниже - три стека, каждый со своими граблями.
Elastic Security (8.x+)
Полноценная TI-интеграция появилась в 8.x с Threat Intelligence view и нативными Filebeat-модулями для AbuseCH, AlienVault OTX и MISP. Индикаторы попадают в индексlogs-ti_*, корреляция - через indicator match rule type.Ограничение: indicator match rules ресурсоёмкие. На инстансе с 50 000+ IOC в lookup и высоким event rate время выполнения растёт нелинейно - запрос, который отрабатывал за секунды, начинает висеть минутами. Рекомендация: фильтровать IOC по типу и возрасту перед загрузкой, использовать поле
indicator.confidence для отсечения шума.Splunk Enterprise Security
TI-данные загружаются через Threat Intelligence Management. Поддержка STIX/TAXII - через Splunk Add-on for TAXII. Корреляция -| tstats с threat_key или search-time lookup.Ограничение: lookup-таблицы при объёме более 500 000 записей деградируют. Для масштабных фидов - kvstore с TTL и ротацией устаревших индикаторов компрометации. Без ротации lookup превращается в свалку, и каждый поиск тормозит всё сильнее.
MaxPatrol SIEM (PT)
Импорт IOC через встроенный механизм Indicators of Compromise и интеграцию с PT Threat Intelligence Feeds. Корреляция - на PDQL. Формат загрузки: CSV, STIX (через промежуточный обработчик). Нативного TAXII-клиента на момент написания нет - требуется скрипт-прослойка.Ограничение: официального конвертера Sigma в PDQL (в отличие от pySigma для Splunk SPL и Elastic EQL) не существует. Community-проекты покрывают не все модификаторы Sigma - часть правил приходится адаптировать вручную. На практике это означает, что каждое второе Sigma-правило при конвертации потребует ручной доработки.
| Параметр | Elastic 8.x+ | Splunk ES | MaxPatrol SIEM |
|---|---|---|---|
| Нативный TAXII-клиент | Через Filebeat модули | Через Add-on for TAXII | Нет (скрипт) |
| Sigma-конвертер | pySigma (elasticsearch backend) | pySigma (splunk backend) | Community, неполный |
| Порог деградации IOC lookup | ~50 000 записей | ~500 000 записей | Зависит от лицензии |
| TI enrichment в алерте | Да (с 8.x) | Да (ES Adaptive Response) | Частично |
IOC decay: почему вчерашний индикатор генерирует false positive
Типичная ошибка: TI-команда загружает IOC в SIEM один раз и забывает. IP-адрес C2-сервера, актуальный в понедельник, к пятнице переназначен легитимному хостингу. А алерт на него продолжает прилетать.Жизненный цикл IOC (по модели, описанной Palo Alto Networks в руководстве по IoC management): Discovery -> Dissemination -> Implementation -> Deprecation -> Archiving. На этапе Deprecation индикатор утрачивает актуальность и начинает генерировать ложные срабатывания. На этапе Archiving - перемещается в исторический индекс для ретроспективного анализа.
Decay-политика (практические TTL):
- IP-адреса: 7–14 дней (C2-инфраструктура ротируется быстрее всего)
- Домены: 30 дней (регистрация дешёвая, но DNS-записи живут дольше)
- Хеши файлов: 90 дней (malware перекомпилируется реже, чем меняется сетевая инфраструктура)
OSINT-фиды типа MISP CIRCL (circl.lu) публикуют события с типизацией по kill chain - удобная база для отработки decay-процессов: свежие наблюдения приходят ежедневно, каждое с тегами TLP и типом события.
От TI-отчёта к Sigma-правилу: пошаговый разбор
Допустим, TI-команда получила отчёт: группировка применяет PowerShell для загрузки payload с C2 через HTTPS. Три техники из отчёта:- PowerShell (T1059.001, Execution)
- Web Protocols (T1071.001, Command and Control)
- Ingress Tool Transfer (T1105, Command and Control)
Шаг 2. Пишем Sigma-правило:
YAML:
title: TI-based PowerShell Download Detection
logsource:
category: process_creation
product: windows
detection:
selection:
CommandLine|contains|all:
- 'powershell'
- 'Invoke-WebRequest'
condition: selection
level: medium
tags:
- attack.execution
- attack.t1059.001splunk):
Код:
index=windows sourcetype=WinEventLog CommandLine="*powershell*Invoke-WebRequest*"
| lookup ti_ioc_domain domain AS url_domain OUTPUT threat_source
| where isnotnull(threat_source)sigma convert -t elasticsearch генерирует EQL-запрос для event correlation rule.Где это правило не работает. Оно ловит только явный вызов
Invoke-WebRequest. Атакующий с минимальной обфускацией (T1027, Obfuscated Files or Information, Stealth) - IEX (New-Object Net.WebClient).DownloadString(), base64-кодирование или вызов через Windows Command Shell (T1059.003, Execution) - обойдёт его на раз. Для production нужен набор из 5–7 вариантов с разными паттернами загрузки. Один Sigma-файл не покрывает технику - покрывает набор. И этот набор придётся поддерживать, когда появятся новые обфускации.Скомпрометированные легитимные хосты: слепое пятно IOC
Атомарные IOC бессильны в сценарии, когда атакующий работает через валидные учётные данные. По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные credentials. По данным Verizon DBIR 2025, 68% утечек связаны с человеческим фактором.В этом сценарии C2-канала в привычном виде может не быть: атакующий аутентифицируется через VPN с легитимного устройства, перемещается по сети штатными инструментами, выгружает данные через разрешённые облачные сервисы. Ни один IP из фида не совпадёт. Фид тут бесполезен как зонтик в подводной лодке.
Здесь работает только поведенческий подход, выстроенный поверх baseline (NIST CSF v2.0, DE.AE-01: "A baseline of network operations and expected data flows for users and systems is established and managed""Устанавливается и контролируется базовый уровень работы сети и ожидаемые потоки данных для пользователей и систем"):
- Массовое обращение к файлам вне рабочего профиля пользователя
- Отключение средств защиты (T1685, Disable or Modify Tools, Stealth) - алерт на изменение конфигурации EDR-агента. Для CrowdStrike Falcon это событие типа SensorTamper, для Elastic 8.x+ - изменение политики Endpoint Security, для SentinelOne - модификация Agent Policy
- Аутентификация в нетипичное время или из нетипичной геолокации
- UEBA-корреляция: один алерт - не инцидент; три алерта за 15 минут от одной учётной записи - повод для расследования (RS.AN-01: "Notifications from detection systems are investigated""Уведомления систем обнаружения расследуются")
Чеклист операционализации TI для SOC
Большинство SOC-команд, с которыми я работал, покупают TI-подписку и считают задачу решённой. По факту подписка - это сырьё, а не продукт. Операционализация threat intelligence начинается не с выбора фида, а с ответа на вопрос: какие три техники из MITRE ATT&CK сейчас представляют наибольший риск для вашей конкретной инфраструктуры? Если SOC не может назвать эти три техники - никакой фид не поможет, потому что нет критериев фильтрации. Я видел организации, которые тратили сотни тысяч рублей в год на коммерческие TI-платформы и при этом не имели ни одного Sigma-правила, написанного на основе данных из этих платформ. Фид превращается в детект не автоматически - через инженерную работу: маппинг, приоритизация, написание правила, тюнинг false positives, decay-ротация. Это CTI операционный процесс, и без него деньги на TI - благотворительность в пользу вендора. Если в вашем SOC обкатываете decay-политику для IOC или подбираете подход к конвертации Sigma под нестандартный SIEM - на codeby.net коллеги делятся рабочими TTL-конфигурациями и граблями конвертации в тематическом треде.
Последнее редактирование модератором:
