Сергей Дмитриев: «Наша задача — создавать баланс между эффективной защитой и возможностью успешно вести бизнес»

22 мая 2026, 16:28

© Фото: ПАО "Ростелеком"

Объекты критической информационной инфраструктуры становятся целью всё более точечных атак: злоумышленники используют не только классические уязвимости, но и особенности конфигурации оборудования, человеческий фактор и слабые места в процессах эксплуатации. При этом чрезмерная изоляция технологических сетей уже не решает проблему: бизнесу нужна безопасная интеграция, управляемая связность и защита, которая не мешает работе. О том, как меняется профиль угроз для КИИ, почему главный риск для телекома — потеря управления сетью и какие ошибки чаще всего становятся критичными для проектов по защите технологических сетей, рассказал Сергей Дмитриев, директор Департамента экспертного сопровождения блока ИБ «Ростелекома». 

Эволюция угроз в технологических сетях (2025–2026)

RUБЕЖ: Как за последний год изменился профиль угроз для объектов КИИ? Если можно, опишите сценарий, который стал возможен именно сейчас — чего не фиксировали 12–18 месяцев назад. 

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

RUБЕЖ: Какая уязвимость чаще всего приводит к инцидентам? Насколько различаются уязвимости с высоким риском инцидента для объектов различных категорий — ТЭК, транспорт, ЦОДы и др.? Можете привести примеры? 

С. Дмитриев: Лидер среди уязвимостей — ошибки контроля доступа (Broken Access Control). Обычно они становятся следствием использования систем в небезопасной конфигурации: например, с «заводскими» паролями, активными функциями отладки или настройками, которые не в полной мере удовлетворяют требованиям информационной безопасности.

Согласно данным перечня OWASP Top 10[1] и отчетов CERT[2], эта уязвимость встречается примерно в 30–40% инцидентов, связанных с веб-приложениями и корпоративными системами. Причина — в использовании легитимных учетных данных: злоумышленники крадут пароли или сессии, а система ошибочно считает их «своими».

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

Замыкают тройку ошибки конфигурации: публичный доступ к API, незащищенные бэкапы, использование JWT-токенов без проверки.

Однако с точки зрения критичности (частоты инцидентов с тяжелыми последствиями) лидирует другая проблема — человеческий фактор: фишинг, социальная инженерия, ошибки персонала, слабые пароли. Технически это нельзя отнести к уязвимостям инфраструктуры, но статистически сегодня это становится главной причиной успешных атак на инфраструктуру практически всех организаций и предприятий.

Что касается уязвимостей с высоким риском инцидента, то различия между отраслями — кардинальные: то, что смертельно для ТЭК, может не представлять угрозы для безопасности ЦОДов, и наоборот.

Проиллюстрирую сказанное простой метафорой: угроза для ТЭК — это «взять под контроль физический процесс», для транспорта — «нарушить безопасность движения», а для ЦОДа — «сломать изоляцию между клиентами/приложениями». Отрасли настолько разные, что даже хакеры обычно специализируются лишь на одной из них.

RUБЕЖ: Можете привести обезличенный пример угрозы или аномалии, которая ранее оставалась невидимой, а после внедрения определенных решений стала определяться на ранней стадии?

С. Дмитриев: Конкретно в такой постановке вопроса — нет.

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

Баланс безопасности и технологической непрерывности

RUБЕЖ: Какой основной риск вы закрываете в первую очередь: несанкционированный доступ, утечку технологических данных или внедрение вредоносного кода в управляющие команды? Или что-то другое? Почему именно этот вектор оказался приоритетным?

С. Дмитриев: В приоритете — несанкционированный доступ к инфраструктуре управления сетью: OSS (Operation Support System)[3], BSS (Business Support System)[4], маршрутизаторы, ядро сети.

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

Еще одна метафора для понимания. Телеком-инфраструктура — это распределенный «мозг» миллионов абонентов. Если хакер получает доступ к консоли управления маршрутизатором или ядру сети IMS (IP Multimedia Subsystem)[5], он может отключить от связи целый регион. Утечка данных в этом случае будет уже следствием. Первичной и главной угрозой станет потеря управления сетью.

RUБЕЖ: Были ли случаи конфликта между требованиями информационной безопасности и операционной необходимостью? Как такие ситуации разрешаются на практике?

С. Дмитриев: Безопасность никогда не бывает удобной. Наша задача — создавать баланс между эффективной защитой и возможностью успешно вести бизнес.

Запретить легко. Найти способ защитить, не разрушив бизнес, — сложно. Тут нет универсального ответа, каждая ситуация индивидуальна, но компромисс всегда один: жестко защищать самое критичное, а там, где нельзя запретить — автоматизировать контроль.

Эффективность, уроки и перспективы

RUБЕЖ: Какой измеримый результат от внедрения решений вы считаете наиболее репрезентативным для оценки эффективности защиты КИИ? Чем это обусловлено?

С. Дмитриев: На мой взгляд, это количество инцидентов, дошедших до абонента. Для КИИ эффективность заключается не в отсутствии атак, а в скорости реакции на них и в минимизации количества инцидентов, дошедших до абонента.

Почему это самый честный измеримый результат для телекома? Внутренние метрики — это иллюзия. Можно отлично ловить атаки, построив собственный центр мониторинга информационной безопасности (Security Operations Center), иметь низкий показатель MTTD (Mean Time to Detect — среднее время обнаружения инцидента) и MTTR (Mean Time to Respond — среднее время реагирования на инцидент), а также высокий процент автоматических блокировок атак, но если, хотя бы, один абонент лишился связи, или его SMS перехватили — для бизнеса это провал. Абоненты такого не прощают.

Отключили интернет на час два раза за день из-за атаки — люди уходят к другому оператору. Перехватили SMS с кодом подтверждения — это уже репутационные риски и штрафы.

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

RUБЕЖ: Где (в чём) чаще всего «проваливаются» проекты по защите технологических сетей? Какой урок вы вынесли из таких ситуаций? 

С. Дмитриев: Чаще всего проекты страдают не из-за технологий. Главные причины — в людях и процессах.

На мой взгляд, три главных фактора «провала»: избыточная сложность сервисов ИБ для пользователей, незнание технологического процесса и игнорирование унаследованного технологического стека (Legacy).

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

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

Игнорирование Legacy — еще одна фатальная ошибка. В технологических сетях много оборудования 10–15-летней давности, которое нельзя обновить или заменить одним днем. В то же время проект требует «установить агента безопасности на все». Агент не работает на устаревшей операционной системе (ОС), поставщика которой уже нет на рынке. Замена системы обойдется компании в сотни миллионов рублей, а процессы будут остановлены на месяцы.

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

Требование «запретить все» — прямой путь к провалу, ведь тот же админ все равно найдет лазейку. Гораздо эффективнее сегментировать, мониторить аномалии поведения и научиться быстро восстанавливаться после инцидента. Лучшая система безопасности та, с которой администраторы будут согласны работать, а не та, которую они будут ненавидеть и стремиться обойти.

RUБЕЖ: Как будет меняться баланс между изоляцией технологических сетей и необходимостью их интеграции с внешними системами? Что станет главным двигателем этих изменений в горизонте 2026–2027 годов?

С. Дмитриев: Полагаю, что скоро мы станем свидетелями перехода от изоляции к «предсказуемости». «Ростелеком» и другие крупные операторы никогда не строили монолитные сети из оборудования одного вендора. Мы собираем инфраструктуру из разнородных компонентов — иностранное и отечественное оборудование, Open source, корпоративные облачные решения — и делаем так, чтобы все это работало как единое целое.

Новая парадигма: не «закрыть все и запретить доступ», а «обеспечить безопасную и управляемую связность всего со всем». Компонент может быть любым: российским, китайским, Open source. Если он проходит всестороннее тестирование, встроен в общую систему мониторинга и подчиняется единой политике безопасности, то решение работает.

Изоляция технологических сетей сохранится только для самых критичных элементов (транспорт, ядро, магистрали). Все остальное будет интегрированным, но контролируемым.

Ключевой фактор выживания современного телеком-оператора — умение безопасно интегрироваться с ИТ-сервисами и государственными информационными системами (ГИС). Иначе он рискует быть уничтоженным более гибкими конкурентами, которые строят параллельные цифровые вселенные, не привязанные к конкретному оператору связи.

[1] OWASP Top 10 — проект международной организации OWASP (Open Web Application Security Project), представляющий собой перечень наиболее критичных рисков безопасности веб-приложений.

[2] Отчеты об уязвимостях от CERT (Computer Emergency Response Team) — это информация о выявленных уязвимостях в программном обеспечении и информационных системах, которую собирает и анализирует координационный центр CERT (CERT/CC). 

[3] OSS (Operation Support System) — программное обеспечение, которое взаимодействует с телекоммуникационной средой: сетями электросвязи, коммутационным оборудованием, АТС, аппаратными комплексами обеспечения связи. Предназначено для поддержки эксплуатации телекоммуникационных систем предприятия связи.

[4] BSS (Business Support System) — комплексная система, которая объединяет процессы управления клиентами, услугами и расчетами.

[5] IMS (IP Multimedia Subsystem) — открытая сетевая архитектура, поддерживающая широкий спектр услуг на основе IP для сетей с коммутацией как каналов (CS), так и пакетов (PS).

Читайте также: Павел Костюрин: «Главный риск в ЦОД — это не оборудование, а остановка сервиса»