РТ-ИБ

IOC: от индикатора к расследованию

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

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

📢 Разберем, откуда берутся IOC, как их внедряют в инфраструктуру и почему большое количество индикаторов без должной фильтрации может не усилить защиту, а увеличить нагрузку на специалистов.

😀😀😀😀😀
Что относится к IOC
Индикатором компрометации может быть технический признак, связанный с потенциально вредоносной активностью:
📎IP-адрес
📎домен, URL
📎хеш файла
📎имя процесса
📎путь к файлу
📎ключ реестра
📎адрес командного сервера
📎тема фишингового письма
📎необычная запись в журнале

Обнаружение такого признака в сети, на рабочей станции, сервере, почтовом шлюзе или в SIEM становится основанием для дальнейшей проверки. При этом отдельное совпадение не подтверждает факт компрометации — это лишь гипотеза, которую Threat Hunters проверяют. Его основная практическая ценность заключается в возможности сузить область поиска и быстрее найти связанные события.

Как встроить IOC в инфраструктуру
Работа с индикаторами начинается с определения систем, в которых они будут использоваться. В зависимости от задач это могут быть SIEM, EDR, межсетевые экраны, системы DNS-фильтрации, почтовые шлюзы, песочницы и платформы киберразведки.

Один и тот же индикатор требует разной логики проверки в зависимости от точки контроля. Например, обнаружение подозрительного домена на прокси-сервере, DNS-сервере, почтовом фильтре и EDR выполняется по разным сценариям.
Практический процесс включает несколько этапов:
1️⃣ Получение индикаторов. Источником может быть отчет, аналитический фид, MISP, поставщик защитных решений, CERT или результаты внутреннего расследования.
2️⃣ Проверка контекста. Необходимо учитывать дату, связанную кампанию, тип вредоносного кода, страну, отрасль и вектор атаки.
3️⃣ Фильтрация. Из набора исключаются слабые признаки, включая общие домены, популярные облачные сервисы, устаревшие адреса и неполные строки.
4️⃣ Интеграция. Релевантные индикаторы загружаются в соответствующие системы защиты: SIEM, EDR, DNS, почтовый фильтр или межсетевой экран.
5️⃣ Анализ срабатываний. Специалисты отделяют реальные инциденты от фонового шума и настраивают правила для обнаружения аналогичной активности.

Почему большое количество IOC не усиливает защиту автоматически
Одна из распространенных проблем заключается в механической загрузке всех доступных фидов. Большой объем индикаторов без предварительной оценки не повышает качество обнаружения угроз. Напротив, он может привести к росту информационного шума и количества ложных срабатываний.

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

Для защиты предприятий ОПК от внешних угроз важны не только технические меры, но и системная поддержка со стороны государства.

Именно этому был посвящен круглый стол «Государственная поддержка обеспечения безопасности критической инфраструктуры стратегических предприятий Российской Федерации», который состоялся сегодня в Совете Федерации.

📢 В мероприятии принял участие Артем Сычев, первый заместитель генерального директора АО «РТ-ИБ». Эксперт выступил с темой

📎

«Опыт функционирования Центра мониторинга и реагирования на компьютерные инциденты на промышленных предприятиях: актуальные векторы угроз и статистика атак».

В обсуждении приняли участие представители министерств цифрового развития, энергетики, промышленности, а также представитель Федеральной службы по техническому и экспортному контролю (ФСТЭК России).

#ИБ_в_лицах

Не совершай ошибку!
[Версия: шифровальщик]

При атаке шифровальщика первые минуты инцидента критичны не только для восстановления работы, но и для расследования произошедшего.

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

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

📢 В карточках выше — чек-лист от команды РТ-ИБ с разбором распространенных действий и их последствий.

RT Protect TI
[Версия: 3.5.0]

Аналитика угроз ценна ровно настолько, насколько быстро она превращается в действие.

Массив индикаторов, отчетов и данных о группировках теряет смысл, если аналитик часами сопоставляет факты, средства защиты получают информацию с задержкой, а обмен с партнерами упирается в риск утечки за пределы доверенного круга.

📢 Команда РТ-ИБ выпустила RT Protect TI версии 3.5.0 — обновление, которое сокращает дистанцию между данными и решением.

😀😀😀😀😀
Что нового в RT Protect TI 3.5.0
1️⃣ Переработана карточка артефакта под расширенную объектную модель:
информация об индикаторах компрометации стала более наглядной благодаря проработке UX/UI, а также предоставлению расширенного контекста. Меньше времени на ручной поиск и сопоставление, быстрее и обоснованнее решения.
2️⃣ Реализована полная поддержка формирования фидов для распространения аналитики в формате STIX:
аналитика передается в средства защиты, а также партнерам и отраслевым центрам обмена в международном стандарте, без ручной адаптации.
3️⃣ Обновлены страницы сущностей APT, Malware, Tool:
расширенные досье на группировки, вредоносное ПО и инструменты атакующих позволяют приоритизировать меры защиты с учетом реальных угроз отрасли, а доработанный дизайн радует взгляд унифицированным интерфейсом.
4️⃣ Добавлена возможность ограничения списков IOC для потоковой проверки артефактов клиентов:
меньше ложных срабатываний и «шума». Команда безопасности не тонет в оповещениях, а реагирует на действительно значимые события. Проверка идет быстрее и точнее, потому что система сверяется только с релевантными для клиента данными.
5️⃣ Реализована поддержка протокола TLP:
компания может безопасно делиться чувствительной аналитикой с партнёрами, регуляторами и коллегами по отрасли, не опасаясь утечки. Правила распространения заданы заранее и понятны всем сторонам.

🛡 Безопасность доступна каждому, независимо от отрасли и задач. Будьте на шаг впереди угроз с RT Protect TI 3.5.0!

5 шагов к защите
[версия: MAX]

Мессенджер — не только средство коммуникации, но и учетная запись, которая может стать целью злоумышленников.

В MAX вышла новая статья о том, как защитить аккаунт от основных сценариев компрометации — от SIM-свапинга и фишинга до несанкционированного доступа к устройству.

В материале разобрали 5 практических шагов, которые помогут повысить уровень защиты:
1️⃣ Установить облачный пароль
2️⃣ Ограничить обнаружение аккаунта
3️⃣ Проверять активные сессии
4️⃣ Защитить локальный доступ к приложению
5️⃣ Использовать Семейную защиту

📢 Читайте статью в MAX и проверьте настройки безопасности своего аккаунта.

😀😀😀😀😀
За прошедший год эксперты РТ-ИБ исследовали тысячи событий и инцидентов, анализировали тактики и инструменты злоумышленников, изучали новые образцы вредоносного ПО и применение ИИ в кибератаках.

Весь этот опыт, накопленный в условиях постоянного противостояния киберугрозам, лег в основу RT Protect SOC 2026.

Если вы еще не успели подробно изучить материалы, предлагаем начать с одного из реальных расследований. Это лишь часть экспертизы, собранной в RT Protect SOC, но за этим кейсом — длительное присутствие злоумышленников в инфраструктуре, признаки компрометации, обнаруженные задолго до шифрования, и три недели криминалистического исследования.

📢 Как развивался инцидент, какие следы удалось обнаружить и к каким выводам пришли специалисты — в карточках выше. А полную версию отчета можно найти у нас на канале.

Backup ≠ Recovery

Представьте компанию, которая каждую ночь создает резервные копии.

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

Формально защита была. Фактически — нет.

Backup и Recovery — разные процессы с разными задачами. Backup обеспечивает создание и хранение копии данных, Recovery — их возврат в рабочее состояние в приемлемые сроки.

Разрыв между «копия создана» и «система восстановлена» — зона риска, в которой формальная защищенность может не совпадать с реальной готовностью к аварии.

📢 О том, как проверить резервные копии на профпригодность, читайте в предыдущем материале.

📢 Дмитрий Невструев, руководитель Центра искусственного интеллекта АО «РТ-ИБ», прокомментировал для CISOCLUB расходы компаний на внедрение и защиту ИИ и рассказал, почему стремительное распространение новых технологий сопровождается новыми вызовами для информационной безопасности.

Бизнес активно внедряет ИИ и расширяет круг задач, которые передает интеллектуальным системам. При этом подходы к их защите пока не всегда успевают за темпами внедрения.

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

«При внедрении ИИ вопросы ИБ пока остаются на периферии внимания для большинства компаний»,

— отметил руководитель Центра искусственного интеллекта.

Среди новых векторов атак:
📎промпт-инъекции
📎подмена контекста
📎небезопасные вызовы инструментов
📎избыточные права доступа

Службам ИБ еще предстоит адаптировать существующие подходы, а злоумышленники только начинают искать эффективные способы атак на ИИ-системы. Однако это лишь вопрос времени.

«Пройдет год-два — и всё изменится. Мы будем постоянно слышать об атаках, ориентированных именно на ИИ-сервисы»,

— заявил эксперт.

Поэтому вопросы безопасности важно учитывать уже на этапе внедрения ИИ. Защита таких систем должна быть частью проекта и соответствующего бюджета с самого начала, а не подключаться после первого инцидента.

🔥 Подробнее — в материале CISOCLUB.