Тактический, оперативный и стратегический Threat Intelligence: кому какой нужен и как не перепутать

Threat Intelligence (TI) приносит пользу ровно в тот момент, когда помогает принимать решения быстрее и точнее: SOC — в часах, IR и хантинг — в неделях, CISO — в кварталах. Самая дорогая ошибка — пытаться одним и тем же потоком закрыть всё сразу: тогда тактический слой превращается в шум, а стратегический — в «дайджест тревожности». Развести уровни TI можно по трём признакам: кто потребитель, какой горизонт и какое действие должно стать лучше. Ниже — компактная модель трёх уровней с минимально‑достаточными шагами по сбору/анализу и встраиванию в процессы.

TI часто продают как универсальный «витамин безопасности»: выпил — и сразу стал зрелым. На практике TI скорее похож на хороший навигатор в тумане: двигатель (процессы, люди, инструменты) он не заменит, но заметно снижает шанс улететь в кювет, когда видимость нулевая. Проблема начинается, когда навигатор пытаются использовать как молоток: одним и тем же набором индикаторов закрывают и ночные блокировки, и охоты, и разговор о бюджете. Результат предсказуем: SOC получает шум и исключения «потому что мешает», а руководство — цифры без смысла.

В зрелых методологиях TI повторяется один тезис: информация об угрозах ценна не сама по себе, а как материал для решений. Поэтому в авторитетных определениях TI обычно понимают широко: это и индикаторы компрометации, и поведение противника (TTP), и выводы из расследований, и рекомендации по обнаружению/сдерживанию/предотвращению. 

Из одного и того же «сырья» можно делать разные продукты — и именно здесь чаще всего всё и путают: разные продукты начинают требовать от одного потока одновременно скоростной автоматизации, глубокой аналитики и красивой коммуникации для руководства.

Чтобы не спорить о терминологии, зафиксируем правило: уровень TI определяется тем, какое решение он улучшает. Это совпадает и с распространённой трёхуровневой классификацией (tactical/operational/strategic), которую можно встретить в отраслевых справочниках.

Практическая проверка простая:

• если артефакт «живёт» часами, он должен быть машинно‑читаемым и встроенным в контуры действия;

• если «живёт» месяцами, ему нужен контекст, связи и сценарии применения;

• если «живёт» годами, он обязан превращаться в решения о приоритетах — иначе это красиво оформленная тревожность.

Нормальный TI‑процесс начинается с направления и требований, затем проходит сбор, обработку, анализ/производство, распространение и обратную связь. Если вы не делаете хотя бы первые и последние шаги (требования и feedback), середина будет производить много текста и мало эффекта. 

Отдельно о «языке», на котором TI разговаривает с инженерами. Для оперативного TI (и зрелого тактического) полезна база знаний по тактикам и техникам атак: она даёт общий словарь поведения противника и помогает маппить наблюдения на покрытие детектов и контрольных мер. 

Если смотреть на распределение по уровням TI, то следующий таймлайн наглядно его показывает:

Такой таймлайн помогает соблюдать TIP (Threat Intelligence Platform). TIP в зрелой схеме — это не «ещё одна база индикаторов», а инструмент, который связывает TI с операционными контурами: приём данных → нормализация/связи → обогащение → доставка в потребителей → обратная связь. На уровне обмена и автоматизации индустрия давно опирается на машинно‑читаемые форматы и протоколы: STIX как язык/формат представления CTI и TAXII как протокол обмена CTI по HTTPS — именно для того, чтобы поддерживать автоматизированную обработку и использование данных (включая обнаружение и response).

Отдельная боль реального мира — «доверие и границы распространения». Для этого существует TLP 2.0: простая маркировка, кому и как можно дальше делиться информацией (и да, это именно про границы распространения, а не про лицензии и юридические тонкости).

Security Vision TIP в теме «тактический/оперативный/стратегический TI» — это, по сути, переводчик и диспетчер: он умеет превращать разрозненные индикаторы, события и контекст в поток, который доходит до решений (и, желательно, не превращает SOC в кружок любителей ложных срабатываний).

Он позволяет обеспечить три самых важных функции в контексте уровней TI:

1. Агрегация и нормализация: сбор данных из внутренних источников (например, SIEM/NGFW/proxy/email и др.), из фидов (коммерческих и open source), плюс поддержка универсальных форматов событий для загрузки и долгосрочного хранения.

2. Обогащение и контекст: формирование аналитической базы из технических индикаторов (хэши, IP, домены, URL, email), а также расширение контекста «стратегическими атрибутами», чтобы быстрее понимать, с чем связано событие (угроза, злоумышленник, ВПО, уязвимости).

3. Участие в детектировании и реагировании: есть механики обнаружения (включая DGA‑механизмы с ML), match‑ и retro‑поиск совпадений по собранным данным, а также встроенные действия реагирования/оркестрации (например, запуск команд реагирования из карточек/представлений, операции блокировки/изменений политик, действия на хостах и с учётными записями). Также помимо этих механизмов, существует “second match” как вторичная проверка IoC через дополнительную корреляцию с внешними системами (SIEM/VM) и внутренними источниками для формирования контекстно обогащённых событий и снижения FP/улучшения triage.

TIP может быть не только «складом индикаторов», но и местом, где TI становится действием — через enrichment, корреляцию, ретро‑проверки и оркестрацию. Однако TIP не заменяет выбора уровня TI: он лишь ускоряет реализацию того, что вы решили делать на тактическом/оперативном/стратегическом горизонте.

Тактический TI

Тактический TI — это всё, что помогает техкомандам быстро распознавать угрозы и действовать в моменте. Типовой потребитель — SOC L1–L3, инженеры detection engineering, дежурный IR. Здесь ценятся скорость, качество обогащения и «срок годности» артефактов.

Тактика отвечает на вопросы «это вредно?», «насколько срочно?», «что блокировать/детектить/эскалировать». Её смысл — сократить время triage и уменьшить шум: быстрее перейти от «что это за событие» к «что мы делаем». На уровне данных это почти всегда работа с наблюдаемыми объектами (IOC и смежные артефакты) плюс минимально достаточный контекст.

В тактике лучше всего работает микс внешнего и внутреннего:

• внутренние: SIEM‑события, телеметрия EDR/XDR, DNS/Proxy/Firewall, почта, IAM‑логи, результаты сканов;

• внешние: репутационные фиды и IOC‑пакеты, бюллетени активной эксплуатации, партнёрские обмены.

Приземлённый пример, как это выглядит у разных организаций:

• малая: обогащение в EDR/почте + аккуратные блокировки + договорённость «кто подтверждает срабатывания»;

• средняя: 1–2 качественных источника в SIEM/SOAR, простые плейбуки, ручной контроль качества;

• крупная: управляемый конвейер (скоринг, TTL, политики enrich/detect/block, метрики качества).

Сбор и анализ: минимальный конвейер, который не превращает SOC в заложника индикаторов. Тактический TI обычно ломается в трёх местах: дедупликация, контекст и устаревание. Практические шаги:

     1. нормализация и дедупликация (один домен из пяти источников — всё ещё один домен);

     2. минимальный контекст: источник/доверие, first_seen/last_seen, тип объекта, связанная активность (если известна);

     3. TTL и политика «enrich / detect / block»: далеко не всё, что полезно для обогащения, стоит блокировать автоматически;

     4. обратная связь от SOC: «полезно/шум/ложное» — иначе вы оптимизируете не безопасность, а страдания.

Тактика должна «подключаться», а не «прочитываться». Поэтому ключ — машинно‑читаемые форматы и доставка в контуры действия. Для стандартизованного обмена CTI часто используют STIX как язык/формат представления и TAXII как протокол обмена CTI поверх HTTPS; это снижает стоимость интеграций и делает данные повторно используемыми между инструментами.
Если вы обмениваетесь TI внутри доверенных сообществ, важно маркировать материалы по режиму распространения: TLP 2.0 считается authoritative с августа 2022 и задаёт правила «кому можно дальше».

Частые ошибки здесь следующие:
Ошибка №1 — «подключили 20 фидов, стало безопаснее». Чаще стало шумнее. Лекарство: требования к источникам, фильтрация и скоринг, TTL.
Ошибка №2 — авто‑block без контекста: приводит к само‑DoS и «теневым исключениям». Лекарство: начинайте с enrich и controlled response.
Ошибка №3 — отсутствие жизненного цикла индикаторов: IOC стареют быстро, а блок‑лист пухнет. Лекарство: истечение, переоценка, чистка, и не бойтесь удалять «когда‑то вредное».

Рассмотрим пример. В среднем SOC вводят правило: репутационный фид сам по себе не блокирует, а повышает приоритет алерта и добавляет контекст (источник, «впервые увидели», тип активности). Через 2–4 недели появляется статистика: какие источники реально помогают расследованиям, какие дают шум, какие индикаторы живут 48 часов. После этого часть сигналов переводят в авто‑block (только для высокодоверенных источников и с коротким TTL), а часть оставляют в enrich — и уже потом честно обсуждают автоматизацию (а не наоборот, когда автоматизация сначала ломает бизнес, а затем рождает «политику исключений на коленке»).

Оперативный TI

Оперативный TI — уровень «связей и сценариев»: он соединяет разрозненные следы в картину кампании или типового сценария атаки и превращает это в задачи подготовки. Если тактика отвечает «что это?», то оперативка отвечает «как это обычно выглядит у нас» — и даёт план проверки.

Оперативный TI отвечает на вопросы «кто/зачем/как» в прикладном смысле: что противник делает на каждом шаге, где мы увидим первые признаки, какие контрольные точки критичны. Типовой потребитель — менеджер SOC/IR, threat hunters, лиды detection engineering; реже — CISO, когда нужно быстро понять приоритеты на горизонте квартала.

Источники данных для него следующие:

• результаты DFIR и расследований (ваших и партнёрских);

• исследовательские отчёты и наблюдения «с фронта» у IR‑практик;

• собственная телеметрия (цепочки событий и инфраструктурные связи).

Оперативный TI особенно хорошо питается «фронтлайновой» статистикой расследований: там обычно есть устойчивые сигналы о том, как меняются векторы initial access и какие сценарии реально повторяются. Например, в данных за 2024 год подчёркивается, что exploits сохраняются как самый частый вектор первичного заражения (33%), а stolen credentials выросли до второго места (16%).
Это прямой повод пересобрать приоритизацию: от hardening edge‑устройств и патч‑дисциплины до контроля идентичностей, фишинг‑устойчивого MFA и охот по признакам злоупотребления сессиями/токенами.

Сбор и анализ: что отличает «оперативку» от «толстого отчёта». Оперативный TI должен приводить к действиям в backlog’е. Практика, которая обычно работает:

     1. кластеризовать наблюдения в кампании/сценарии (что связано, а что просто «случилось рядом»);

     2. описать сценарий через TTP и маппинг на общую модель техник (чтобы говорить с инженерами на одном языке);

     3. собрать hunt package: гипотезы → источники логов → запросы/детект‑идеи → критерии подтверждения;

     4. перевести выводы в backlog: какие детекты, какие требования к логированию, какие изменения в конфигурациях и кто владелец.

Самый применимый формат — короткий briefing (1–3 страницы) + приложения: запросы, детект‑идеи, проверочные шаги. В крупной организации это почти неизбежно превращается в knowledge base со связями «кампания ↔ инфраструктура ↔ техника ↔ меры», иначе вы тонете в собственной библиотеке PDF.

Частые ошибки здесь следующие:
Ошибка №1 — «энциклопедия угроз» вместо инструмента: 40 страниц, которые некому читать во время инцидента. Лекарство: короткий brief и отдельный пакет действий.
Ошибка №2 — отчёт описывает техники, но у вас нет логов/аудита, чтобы их увидеть. Лекарство: в каждый пакет — список обязательных источников данных и «что сделать, если данных нет».
Ошибка №3 — атрибуция ради атрибуции: громкое имя противника не добавляет покрытия детектов. Лекарство: фокус на повторяемых TTP и на том, что можно закрыть.

Рассмотрим пример. Компания видит серию входов в облако «с правильными паролями», без следов фишинга. Тактический слой даёт триггеры (аномалии входа, странные сессии). Оперативный слой связывает это с ростом сценариев компрометации учётных данных и цепочкой «компрометация → злоупотребление токенами/правами → эксфильтрация». Hunt package включает проверку условного доступа, журналов токенов, необычных OAuth‑приложений, новых правил пересылки почты и нестандартных источников входа. Параллельно в backlog уходит конкретика: включить/усилить фишинг‑устойчивый MFA для админов, закрыть «дыры» в логировании, и договориться с владельцами сервисов, какие сигналы считаем «критическими» и эскалируем сразу.

Стратегический TI

Стратегический TI — уровень управления риском и приоритизацией ресурсов. Он нужен, чтобы решения CISO и руководства опирались не на «самую громкую новость недели», а на вероятные сценарии ущерба именно для вашей организации.

Стратегический TI отвечает на вопросы «что меняется в ландшафте угроз», «что это значит для нашей отрасли/географии/модели бизнеса», «какие 3–5 сценариев наиболее критичны в ближайший год», «какие инициативы уменьшают риск сильнее всего». Хорошие threat‑landscape методологии строятся вокруг аудитории, требований и цикла «direction → collection → processing → analysis → dissemination → feedback»: без требований и обратной связи стратегический продукт быстро деградирует в «интересно, но бесполезно».

Источники данных у него следующие:

• обзоры ландшафта угроз и отраслевые аналитические отчёты;

• статистика инцидентов и почти‑инцидентов внутри организации;

• данные про экспозицию: активы, уязвимости, поверхность атаки, цепочка поставок;

• бизнес‑контекст и регуляторика.

Методы анализа: как превратить «угрозы в мире» в «решения у нас». Рабочий каркас обычно выглядит так:

     1. зафиксировать intelligence requirements руководства (какие решения поддерживаем: бюджет, инициативы, политика, приоритеты);

     2. описать критичные активы и процессы (что реально дорого терять и что нельзя останавливать);

     3. выбрать 2–5 сценариев ущерба и разложить их по вероятности и влиянию;

     4. связать сценарии с инициативами и KPI (зрелость IAM, полнота логирования, качество резервного копирования, скорость обнаружения, готовность IR);

     5. делать deliverable коротким: несколько страниц или слайдов с тезисами и решениями, а не «книгу про зло».

Короткий пример масштаба:
в малой компании стратегический TI — это чаще всего «три сценария, которые нас реально убьют» и базовые инициативы с максимальной отдачей (MFA, резервные копии, видимость, обкатанные плейбуки). В средней — добавляется квартальный обзор и формализованный риск‑реестр. В крупной — отдельный продукт для руководства плюс «переводчик» стратегических выводов в портфель проектов и метрики.

На практике лучше всего работает quarterly brief («что изменилось и что это значит для нас»), decision memos под конкретные решения и карта сценариев риска, привязанная к дорожной карте ИБ.

Частые ошибки здесь следующие:
Ошибка №1 — дайджест вместо разведки: новости есть, выводов нет. В бизнес‑терминах это как отчёт о погоде без решения «берём зонт или переносим мероприятие».
Ошибка №2 — отчёт «про всё» и финал «усилить безопасность». Лекарство: сценарии и приоритизация.
Ошибка №3 — стратегию меряют тактикой: «сколько IP заблокировали» не равно «насколько снизили риск». Лекарство: метрики уровня решений и снижение экспозиции по ключевым сценариям.

Рассмотрим пример. Руководство просит обосновать инвестиции в IAM и мониторинг облака. Стратегический TI берёт внешние тренды: exploits остаются частым initial access, а stolen credentials — заметно растущим вектором.
Дальше накладывает это на внутреннюю реальность: сколько привилегированных аккаунтов, где нет фишинг‑устойчивого MFA, насколько полно логируются действия в облаке, сколько критичных сервисов завязано на облачные идентичности. Итог — сценарный документ: какая цепочка событий ведёт к максимальному ущербу, какие меры снижают вероятность/влияние быстрее всего, какие KPI покажут прогресс через квартал (и какие — не покажут, даже если очень хочется поставить зелёную галочку в отчёте).

Сравнительная таблица уровней

Главная мысль сравнения проста: три уровня TI — это три разных продукта, даже если сырьё похоже. Если заставить один продукт обслуживать все уровни сразу, он обычно обслужит ни один (зато загрузит почту и психику).

Чтобы быстро понять, куда вкладываться первым шагом, начинайте от решения и горизонта, а не от витрины фидов. Ровно так же устроен общий цикл TI: требования → сбор → обработка → анализ → распространение → обратная связь.

Выводы

TI стоит рассматривать как линейку продуктов под разные решения, а не как «один бесконечный фид про зло». Как только вы жёстко привязываете TI к потребителю и горизонту, становятся очевидны три практические истины.

Тактический TI живёт в контурах действия: ему нужны автоматизация, TTL и обратная связь, иначе он превращается в шум и конфликт с бизнесом. Оперативный TI живёт в подготовке: он ценен только тогда, когда превращается в сценарии, hunt packages и изменения в backlog’е детектов/логирования/контролей. Стратегический TI живёт в управлении риском: он обязан отвечать «что это значит для нас» и приводить к приоритетам и решениям — иначе это корпоративный жанр «страшно, но непонятно что делать».

Лёгкая ирония в том, что самый быстрый путь «повзрослеть в TI» почти всегда начинается не с покупки ещё одного фида, а с трёх скучных артефактов: требований, владельца решения и обратной связи. Когда эти три штуки есть, даже «обычные» источники начинают работать лучше, а дорогие — наконец-то начинают окупаться.