Минцифры ужесточает требования безопасности для доверенного ПО на объектах КИИ

6 часов назад

© Сгенерировано ИИ

Министерство цифрового развития подготовило проект постановления, устанавливающий новые правила информационной безопасности для российского программного обеспечения из категории «доверенного», применяемого на значимых объектах критической информационной инфраструктуры. Инициатива вводит регламенты контроля за исходным кодом, процессом сборки и порядком доставки обновлений, что потребует от разработчиков и заказчиков адаптации привычных процессов. Как ранее сообщал RUБЕЖ, на фоне возросших инфраструктурных рисков государство уделяет первостепенное внимание комплексной защите критических цифровых объектов.

Согласно проекту документа, опубликованному на официальном портале нормативных актов, к доверенному ПО предъявляется ряд обязательных критериев:

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

- Контролируемая среда: Исходный код, инфраструктура разработки и сборочная среда должны находиться в защищенном контуре, требования к которому определяет ФСТЭК.

- Безопасная доставка обновлений: Установка патчей должна происходить исключительно с разрешения пользователя и только через технические средства, расположенные на территории России. Запрещается задействовать зарубежные инфраструктурные узлы.

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

Максим Долгинин, руководитель направления развития продуктов кибербезопасности Cloud.ru, отмечает важную новацию проекта — исключение требования об обязательном наличии сразу двух доверенных операционных систем для облачного ПО и средств защиты:

«Это важный момент, так как поддержка двух доверенных ОС — это избыточное требование для облачного ПО, которое по своей задумке не предназначено для самостоятельной установки пользователями».

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

Оценка рисков для разработчиков и сборочной инфраструктуры

Для вендоров, у которых не выстроены процессы безопасной разработки, новые требования могут стать серьезной проблемой. Им придется организовывать контролируемую сборочную среду, устранять уязвимости из БДУ во всех компонентах и вести их детальный учет.

Владислав Шелепов, аналитик угроз GSOC компании «Газинформсервис», обращает внимание на ряд сложностей, заложенных в проекте:

«Одна из сложностей проекта заключается в том, что часть важных условий вынесена за пределы самого проекта. Например, требования к контролируемому окружению и сроки устранения уязвимостей должны определяться документами ФСТЭК России».

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

Влияние новых стандартов на проекты интеграции и архитектуру 

Своим видением новых правил поделился эксперт практики UC и ПО для совместной работы К2Тех Владимир Сергеев. Владимир Сергеев подчеркивает, что выбор программного обеспечения для значимых объектов КИИ больше не может ограничиваться простым наличием продукта в реестре:

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

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

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

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

Эксперт отмечает, что в сложных корпоративных инфраструктурах это потребует от ИТ-отделов выстроить отдельный процесс проверки источников обновлений, их влияния на совместимость и соблюдения сроков устранения уязвимостей.

О компании

К2Тех – ИТ-компания с комплексной экспертизой для поддержки цифрового развития отраслевых лидеров. Компания занимается проектированием и построением ИТ-инфраструктуры, оснащением объектов и сооружений, бизнес- и промышленными решениями, а также оказывает техническую поддержку в собственном Центре экспертизы по комплексному сервису. В экосистему К2Тех входят облачный провайдер K2 Cloud, бизнес-партнер по выстраиванию практической кибербезопасности К2 Кибербезопасность и самостоятельное подразделение К2 НейроТех, специализирующееся на ИИ-инфраструктуре и суперкомпьютерах.