Названы приоритеты в ИБ киберфизических систем до 2040 года

Названы приоритеты в ИБ киберфизических систем до 2040 года

Названы приоритеты в ИБ киберфизических систем до 2040 года

Компания «Актив» подвела итоги форсайт-сессии «Будущее безопасности киберфизических систем в России», которая прошла в марте 2025 года в Москве. В итоговом документе участники сформулировали рекомендации и прогнозы развития отрасли до 2040 года.

Что обсуждали

В дискуссиях приняли участие около 30 специалистов: представители вузов, технологических компаний и отраслевых ассоциаций. Среди них — эксперты из МЭИ, «Лаборатории Касперского», Ассоциации Интернета вещей, НИИМЭ, «ИнфоТеКС», «С Терра СиЭсПи», «Zelax», НТУ «Сириус», ИКТИБ ЮФУ и других организаций.

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

Сессия прошла на базе МТУСИ в рамках международного фестиваля отраслевой науки ComInfFest 2025.

Основные выводы

  • Экосистема вместо разрозненности. Киберфизические системы — это история про много разных участников, от производителей до регуляторов. Чтобы всё работало слаженно, нужно выстраивать гибкую и масштабируемую экосистему с понятными правилами.
  • Безопасность — на старте, а не в конце. Современные подходы к защите предлагают внедрять безопасность не постфактум, а ещё на стадии архитектуры системы. Идея — создать «цепочку доверия»: каждый элемент, от железа до софта, должен быть верифицирован и защищён. Такой подход называют Security-by-Design.
  • Квантовые угрозы — не ближайшая проблема. Судя по текущим темпам развития, серьёзного влияния квантовых технологий на IoT-инфраструктуру не ожидается до 2040 года. Это даёт время на постепенное совершенствование существующих решений, без спешки с переходом на постквантовые алгоритмы.
  • Гибкость в криптографии. Чтобы не переделывать всё с нуля при переходе на новые криптоалгоритмы, уже сейчас стоит закладывать в системы архитектуру, позволяющую быстро заменять криптомодули. Такой подход называется crypto agility.
  • Свой путь важнее гонки. Копировать зарубежные решения не всегда эффективно. Российские компании могут быть сильны в создании оригинальных, нишевых технологий. Главное — развивать именно то, в чём есть потенциал, и ставить амбициозные цели.
  • Сложность внутри одной системы. Даже одна киберфизическая система может включать в себя множество устройств разного типа. Защитить такую гетерогенную структуру — непростая задача, особенно если думать о защите на годы вперёд. Форсайт помог лучше понять, как с этим работать в долгосрочной перспективе.

Форсайт-сессия стала для участников возможностью не только зафиксировать ключевые вызовы, но и выработать подходы к проектированию и защите сложных систем, которые будут актуальны в ближайшие 10–15 лет.

В ядре Linux нашли первую уязвимость в коде на Rust

В ядре Linux зафиксировали первую уязвимость (CVE), связанную с кодом на Rust. Об этом сообщил один из ключевых разработчиков ядра Грег Кроа-Хартман, а подробности появились в рассылке Linux. Речь идёт о проблеме под идентификатором CVE-2025-68260, которая затрагивает переписанный на Rust драйвер Android Binder.

Проблема, согласно публикации Phoronix, связана с состоянием гонки (race condition), возникающим из-за использования небезопасного Rust-кода. В определённых условиях это может привести к повреждению указателей в памяти и, как следствие, к сбою системы.

Уязвимость затрагивает версии ядра Linux 6.18 и новее, то есть те сборки, где появился Rust-драйвер Binder. Важно отметить, что речь идёт именно о потенциальном сбое в работе системы — удалённого выполнения кода или компрометации здесь нет.

Сам Грег Кроа-Хартман подчёркивает, что это первый подобный случай с момента появления Rust-кода в основном дереве ядра Linux. И хотя для кого-то новость может прозвучать тревожно, разработчики призывают не делать поспешных выводов: уязвимость не критическая, а сам факт её обнаружения — скорее показатель того, что Rust-код в ядре теперь проходит тот же путь зрелости, что и C-код десятилетиями ранее.

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

Подробности по CVE-2025-68260 уже опубликованы в официальной рассылке Linux CVE, а исправления, как ожидается, появятся в ближайших обновлениях ядра.

RSS: Новости на портале Anti-Malware.ru