Может ли объект КИИ, обеспечивающий защиту сети оператора связи, содержать открытый код?
На примере пограничного контроллера сессий (SBC) партнер "AC&M Консалтинг" Михаил Алексеев разбирается, как современные модели ИИ приводят к появлению качественно новых угроз безопасности для объектов КИИ, если в них использованы компоненты на основе модифицированного свободного кода и Linux приложений.
Немного об открытом коде (Open Source)
Использование программных модулей с открытым кодом при создании программных продуктов – весьма распространенная практика. И это неудивительно – такой подход позволят быстро и с минимальными затратами создавать нужные решения и выводить их на рынок. Главное преимущество такого подхода – экономическая эффективность и скорость внедрения. Если исходный код доступен для изучения, модификации и адаптации под конкретные нужды, то можно быстро дать рынку недорогие и относительно надежные решения для поддержания критически важных процессов.
Оказалось, что использование открытого кода делает уязвимыми для вмешательства извне даже самые ответственные системы, начиная от пограничных контроллеров сессий и сетевых фильтров, до сложнейших систем NDR (Network Detection and Response) или DPI (Deep Packet Inspection). В апреле, выступая на конференции Data Fusion 2026 в Москве, глава АО "Лаборатория Касперского" Евгений Касперский констатировал, что в период с 2022 г. компания выявила более 20 тыс. проблемных проектов open source, содержащих вредоносные элементы. "Open source верить нельзя", – констатировал самый большой российский авторитет в области кибербезопасности.
По иронии судьбы за день до выступления Евгения Касперского на конференции в Москве, 7 апреля 2026 г., компания Anthropic анонсировала новую версию ИИ модели Claude Mythos Preview, предоставив доступ к ней дюжине глобальных компаний и государственных организаций. В ходе тестирования Claude Mythos Preview только за первые две недели модель обнаружила тысячи уязвимостей, в т. ч. в OpenBSD, FFmpeg и Linux. Например, была выявлена 27‑летняя уязвимость в OpenBSD и 16-летняя ошибка в FFmpeg. Эти результаты имели эффект, сравнимый лишь с испытанием ядерной бомбы. Модель обнаружила не только массу так называемых уязвимостей "нулевого дня", которые не удастся устранить в кратчайшие сроки, но и показала нечто совершенно новое – способность связывать несколько уязвимостей в цепочки. Модель может объединять несколько слабостей в системе, чтобы создать более серьезную угрозу. Например, в ядре Linux новая модель нашла цепочку багов для эскалации привилегий. В итоге удалось многократно обходить KASLR (Kernel Address Space Layout Randomization) — механизм защиты ядра операционной системы, который рандомизирует расположение ключевых структур данных в памяти при каждой загрузке ОС. Таким образом, и сама операционная система Linux представляет собой серьезную уязвимость.
Страшно представить себе, что могла бы сделать модель, если бы она оказалась в руках злоумышленников. Взлом любой системы с открытым кодом становится, что называется, делом техники. На ум приходят фильмы в жанре антиутопий или научно-фантастические триллеры. Разница лишь в том, что в реальном мире все это может выглядеть не так же комично, как Доктор Зло из пародийного триллера "Остин Пауэрс".
Мораль для операторов связи и крупных корпораций
Давайте посмотрим, что все это означает для уязвимости критической информационной инфраструктуры в практическом плане. Одним из обязательных и наиболее распространенных сетевых элементов, отвечающих за целостность сети и отпор разнообразным внешним атакам, является пограничный контроллер сессий (Session Border Controller или SBC).
Распоряжение правительства РФ № 360-р, утвердившее перечень типовых отраслевых объектов критической информационной инфраструктуры (КИИ), не оставляет сомнений в том, что "управление трафиком пограничных сетевых устройств" относится к области КИИ. Следуя требованиям закона №187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации", операторы могут использовать SBC из реестра отечественного ПО. Сейчас на российском рынке имеется множество различных SBC-решений для обслуживания небольших ведомственных сетей. Есть и решения, которые претендуют на принадлежность к операторскому классу устройств – потенциально на замену оборудования двух глобальных лидеров: Oracle и Huawei.
Детальный анализ таких решений показывает, однако, что подавляющее их большинство используют по крайней мере один или даже несколько элементов с открытым кодом для ключевых функциональных модулей, такие, например, как:
pjsip - открытая библиотека для мультимедийной коммуникации; rtpengine - открытый проект, который представляет собой компонент для обработки медиапотоков в реальном времени; а также, hazelcast, netfilter, fail2ban, TCP/IP стек linux (для медиа интерфейсов) и др.
В этом контексте возникает неприятный вопрос - каким же образом SBC, если в нем используется открытый код, сможет защитить сеть оператора связи, если устройство само по себе является уязвимостью и нуждается в защите? SBC на границе сети должен служить щитом, защищающим сеть от различного рода вредоносных воздействий, но SBC с открытым кодом - это щит с дырой. "Пробить" такую защиту теперь может практически каждый, кто имеет доступ к достаточно мощной ИИ-модели. Возможно, применение таких технологий в SBC вполне оправдано для защиты небольших домашних сетей или ведомственных сетей отдельных коммерческих компаний. Однако, применение открытого кода в ключевых процессах для пограничных контроллеров у федеральных операторов связи однозначно создает очень опасную уязвимость и угрозу национальной безопасности для страны.
Очевидно, что SBC операторского класса - устройство, обслуживающее миллионы абонентов и относящееся по своей сути к КИИ - не может использовать компоненты с открытым кодом для реализации всех критически важных процессов обработки трафика. Более того, эти критически важные процессы должны быть полностью изолированы и от операционной системы Linux, которая сама по себе представляет серьезную уязвимость и в которой в процессе эволюции могут появляться все новые и новые уязвимости. Именно такая архитектура SBC является единственно приемлемым решением для российских федеральных операторов связи.
Есть ли возможность исключить появление масштабных уязвимостей на уровне такого сетевого элемента, как SBC? Это возможно, если не экономить на разработке, используя компоненты с открытым кодом для реализации ключевых процессов, а разрабатывать проприетарные протокольные стеки, тщательно изолировать критически важные ресурсы обработки VoIP-трафика друг от друга, от сегмента управления и операционной системы сервера, на котором развернуто SBC-решение. По существу, это требует создавать код "с нуля" и является более дорогим решением (больше затрат по людским ресурсам и времени). Тем не менее, такой подход гарантирует неуязвимость, а параллельно открывает возможность увеличения производительности таких решений до уровней, недостижимых для программных модулей из стандартных библиотек, ограниченных возможностями операционной системы.
Будут ли такие, относительно более дорогие, решения востребованы на рынке? Если в приоритете регулятора и федеральных операторов - вопросы безопасности, устойчивости сети и защиты от потенциальных уязвимостей, то пограничные контроллеры сессий без открытого кода станут нормой индустрии. Если у операторов и Минцифры будет задача быстрее и дешевле решить вопрос замены элемента критической информационной инфраструктуры, то мы рискуем в недалеком будущем увидеть масштабные сетевые инциденты, которые смогут организовать при помощи искусственного интеллекта даже небольшие группы тинэйджеров ради самоутверждения или дешевой популярности.