惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
人人都是产品经理
人人都是产品经理
Hugging Face - Blog
Hugging Face - Blog
罗磊的独立博客
博客园 - 【当耐特】
D
Docker
Y
Y Combinator Blog
L
LangChain Blog
博客园 - 三生石上(FineUI控件)
I
InfoQ
阮一峰的网络日志
阮一峰的网络日志
F
Fortinet All Blogs
J
Java Code Geeks
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
B
Blog
The GitHub Blog
The GitHub Blog
腾讯CDC
MongoDB | Blog
MongoDB | Blog
博客园 - Franky
爱范儿
爱范儿
A
About on SuperTechFans
量子位
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Смерть от тысячи алертов: как отфильтровать мусор из TI-ф...
PR · 2026-05-14 · via Все публикации подряд на Хабре

Простой

6 мин

8.9K

Есть типовой путь, по которому команды приходят к разочарованию в Threat intelligence. Сначала кто-то в компании слышит, что фиды помогут раньше видеть атаки, быстрее реагировать, меньше пропускать. Потом кто-то другой берет пачку индикаторов из разных источников и по-быстрому заливает их в NGFW, прокси, SIEM или IDS. После СЗИ начинает сходить с ума: сыпятся алерты, в логах всплывают легитимные сервисы, аналитики несколько дней разгребают мусор… 

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

В статье поговорим, почему именно так происходит, какие фиды стоит брать, а какие выкидывать, и как не превратить TI в генератор ложных срабатываний. Но сперва покажем немного цифр, потому что история выше не единичный кейс, а довольно распространённая картина.


Мы опросили специалистов по ИБ, инженеров, аналитиков SOC и архитекторов из разных отраслей. В опросе приняли участие 144 респондента. Они рассказали о текущем стеке инструментов защиты, методах работы с ложноположительными срабатываниями и о том, какие дополнительные меры считают необходимыми для усиления безопасности. Отдельно поговорили о барьерах, с которыми специалисты сталкиваются при интеграции новых технологий в рабочую среду.

По данным нашего опроса, около половины респондентов фиды пока не используют, но планируют. Ещё треть (31%) использует уже сейчас, а 16% не планируют вовсе. Как мы видим, у большинства специалистов сохраняется недоверие к этому классу решений. 

Если посмотреть, почему именно люди не хотят идти в TI, там нет ничего сверхъестественного: 40% честно говорят, что у них нет ресурса на интеграцию, настройку и обучение. Остальные боятся фолзов, не верят, что найдут релевантные фиды под свою инфраструктуру, или вообще не понимают, как встроить такие решения в текущий стек. И знаете, это вполне рациональный страх. Ведь фиды действительно могут быть опасны, если работать с ними без фильтрации и контекста.

Поэтому давайте разбираться, и первое, с чего стоит начать, — разделить понятия, которые на рынке постоянно путают.

Платформа и данные — это не одно и то же

Люди слышат «TI» и сразу представляют Threat Intelligence Platform: красивый интерфейс, графы связей, тактики MITRE, пачки артефактов, enrichment, расследования. Но сама по себе платформа не делает ничего особенного. Она только переваривает, хранит, обогащает и раздаёт данные, это просто движок.

Фиды — это как раз топливо для этого двигателя. Это форматированные списки индикаторов: IP, домены, URL, хэши и иногда что-то сложнее — вроде индикаторов атаки. Их можно использовать и без отдельной платформы, если есть куда положить. Для этого и существуют коннекторы, шаблоны выгрузки, API и прочая скучная, но полезная автоматизация.

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

На практике всё проще. Полноценный процесс TI действительно дорогой и тяжёлый, но готовые фиды — нет. Главное — работать с ними осмысленно, а не просто выгружать всё, что есть, в прод.

Почему фиды начинают фолзить

Самая частая ошибка в настройке такого класса решений, это собрать всё, до чего удалось дотянуться, и загрузить миллион другой строк напрямую в СЗИ. В такой большой базе индикаторов будут IP, домены, хэши вперемешку: разные источники, разное качество, разная степень доверия. 

Так делать не стоит, ведь у любого индикатора есть срок полезной жизни. Например, DDoS-адреса протухают быстро. С фишинговыми доменами жизнь индикатора подлиннее, а хэши вредоносных файлов можно хранить и подольше. 

IP вообще штука нестабильная, особенно в облаках, на арендованной инфраструктуре и у крупных сервисов. Отсюда вытекает простое правило, которое почему-то часто игнорируют: IP нельзя бездумно кидать в blacklist навсегда.

Есть показательный кейс. Когда Google запускал новый стриминговый сервис, часть домашних роутеров и фаерволов начала воспринимать этот трафик как DDoS и блокировать его. Причина банальная: адреса годами висели в старых чёрных списках, а потом на них пришёл легитимный сервис. Никто не пересмотрел контекст, никто не проверил последнюю активность, никто не подумал, что IP за это время мог сменить «профессию».

Вот так и появляются фолзы, которые потом принято списывать на сам класс решений.

Хотя дело не в фидах, а в том, что из миллиона записей никто не попытался оставить двести действительно актуальных. Суть не в том, хороший это индикатор или плохой, а в том, когда его видели в последний раз и в каком контексте.

Так что если иметь в виду, что у разных типов угроз разный срок годности, а также вести белые списки хотя бы на базовом уровне, мусора становится в разы меньше.

Скрытая стоимость Open Source

Ещё одно распространённое заблуждение, которое портит репутацию TI, — вера в то, что open source и бесплатные источники закрывают задачу почти так же хорошо, как коммерческие фиды.

В нашем опросе 44% респондентов сказали, что используют бесплатные источники. Действительно, зачем платить вендору, если индикаторы общедоступны?

У всех есть ФСТЭК, ФинЦЕРТ, публичные дайджесты, OSINT-каналы, рассылки, GitHub-репозитории, и всевозможные списки IP и доменов из открытых источников.

Вот только общедоступны не равно — «готовы к использованию». Такой фид чаще всего представляет собой простой список IP, URL или доменов почти без контекста. По нему не очень понятно, насколько индикатор актуален, к чему он относится и стоит ли вообще на него реагировать. Иногда это даже не тот формат, который можно без боли загрузить в TIP.

Бесплатность таких источников и вовсе во многом иллюзорна. Кто-то всё равно должен искать источники, писать парсеры, приводить данные к единому формату, вычищать дубликаты и мусор, как-то размечать это по категориям и придумывать, сколько вообще живёт каждый индикатор. И это ещё до того, как данные начнут нормально выгружаться в SIEM, NGFW и остальной стек. А потом ваш внешний источник меняет формат, и всё это начинает ломаться.

В какой-то момент оказывается, что «бесплатный» фид стоит зарплату senior-разработчика, а лучше двух, плюс время ИБ-инженеров, которые будут объяснять, почему после последнего обновления списков половина срабатываний уехала в фолзы.

Поэтому к open source стоит относиться как с сырью, очистка которого — отдельный затратный процесс. Если компания умеет это делать — прекрасно. Многие действительно строят такие пайплайны у себя, часто на OpenCTI, MISP, контейнерах с коннекторами и наборе кастомной логики вокруг. 

Но если рук нет, то бесплатное решение очень быстро становится самым дорогим. Именно поэтому средний бизнес чаще берёт платные фиды, а вот большие компании с командами и платформами могут позволить себе микс из коммерческих и открытых источников. Малый бизнес чаще всего ограничивается открытыми списками, но нередко даже не знает, что с ними делать дальше.

Где заканчиваются IoC и начинается что-то полезнее

Порой мы слышим, что индикаторы компрометации не помогут найти реальную атаку, потому что IoC — это про то, что уже где-то засветилось: адрес, домен, хэш, какой-то узел. То есть ты смотришь на уже известную историю. 

Если работать только с IoC, так и получится, но существуют также IoA — индикаторы атаки, и это уже другой уровень полезности. Тут мы смотрим не только на конкретный адрес или хэш, а на то, как ведёт себя трафик.

Эту разницу проще всего разобрать на практике, например, на кейсе с Cobalt Strike. Если трафик зашифрован, сигнатурой там мало что увидишь. Payload спрятан, а DNS может идти поверх HTTPS, но если подключить NDR и смотреть не на содержимое пакета, а на профиль поведения, всё меняется.

Допустим, у нас есть IP, который относится к C2 Cobalt Strike. Если хост изнутри сети обращается к нему не один раз, а повторяет запросы с чёткой периодикой, это уже не просто сработавший IoC. Это зачаток IoA.

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

В 2026 году фиды сами по себе почти ничего не решают. Они действительно полезны в сочетании с другими инструментами: NDR, SIEM, корреляцией, анализом трафика.

TI здорового человека

Вернёмся к команде из начала статьи, той, что залила миллион индикаторов в NGFW и через сутки утонула в алертах. Проблема в том, что у них не было ни одного слоя обработки между источником и средством защиты. 

На самом деле в грамотной работе с индикаторами компрометации нет ничего особенно сложного. Сначала берёте ровно то, что нужно под конкретные задачи, а не все фиды. Потом настраиваете, как резать фолзы. Необходимый минимум, это Last Seen, TTL, белые списки и скоринг. И только после этого имеет смысл говорить о качестве конкретного поставщика.

Есть соблазн сказать, что Threat Intelligence нужен только большим организациям. Им действительно проще, у них больше источников, чаще есть платформа и люди, которые могут построить внутренний процесс. Средний бизнес обычно решает вопрос покупкой готового фида, потому что нет рук делать всё с нуля. Малый часто думает, что TI вообще не для него. Но процесс Threat Intelligence и готовые фиды — разные вещи. Процесс действительно не для всех, а вот фиды как источник контекста — уже вполне для всех. Ничто не мешает взять список актуальных вредоносных доменов, ботнетов и фишинговых URL и положить в прокси или NGFW. С этого, собственно, и стоит вкатываться в TI на практике.