ФСТЭК ужесточает сертификацию средств защиты информации

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

Что конкретно требуется от разработчиков

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

Если в продукте используется open source, придётся составить и приложить к заявке на сертификацию полный перечень таких компонентов. То же самое касается образов контейнеров. Оба перечня стали полноценными документами сертификации.

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

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

Отдельное внимание открытому коду

Самая чувствительная новация касается изменений в составе open source. Если разработчик вносит правки в перечень заимствованных компонентов с открытым исходным кодом, он обязан в течение пяти календарных дней сообщить об этом в ФСТЭК и представить скорректированный перечень. Пять дней — это очень короткий срок. На практике это означает, что процессы управления зависимостями и контроля версий должны быть выстроены практически в реальном времени. Автоматическая генерация обновлённого перечня при каждом изменении в репозитории становится не роскошью, а необходимостью.

За нарушение этого требования предусмотрены наказания. В перечень оснований для аннулирования сертификата добавили пункт о непредставлении сведений об изменениях в перечне open source компонентов. Иными словами, не успел уведомить — можешь лишиться сертификата.

Что ещё меняется в процедуре сертификации

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

Также изменились требования к формату подачи материалов. Часть документов, включая технические условия, задание по безопасности и формуляр, нужно подавать и на бумаге, и в электронном виде. А вот протоколы испытаний, перечни open source и контейнеров — только в электронном виде. Важно, что электронные копии должны быть идентичны подписанным бумажным оригиналам.

Какие обязанности будут возложены на российские IT‑компании

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

При любом изменении в составе open source разработчик обязан в пятидневный срок уведомить ФСТЭК и передать обновлённый перечень. Промедление или сокрытие изменений грозит аннулированием сертификата.

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

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

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

К чему приведёт неисполнение новых правил

Самое прямое последствие — аннулирование сертификата соответствия. В перечень оснований для аннулирования добавлено непредставление сведений о внесении изменений в перечень заимствованных программных компонентов с открытым исходным кодом. Если компания поменяла open source в продукте и не уведомила ФСТЭК в течение пяти дней, сертификат могут отозвать. Причём неважно, ухудшилась безопасность или нет — сам факт неуведомления становится достаточным поводом.

Ещё одно последствие вытекает из требований к испытательной лаборатории. Если лаборатория найдёт недостатки в перечнях open source или контейнеров, она направит заявителю предложения по доработке. Это приведёт к затягиванию сертификации, дополнительным согласованиям и дополнительным расходам. В худшем случае сертификат может быть не выдан вовсе, если компания не сможет доказать полноту и корректность своих перечней.

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

Наконец, неисполнение правил ведёт к репутационным и рыночным потерям. Заказчики из госсектора и сферы КИИ просто не смогут покупать несертифицированные средства защиты информации. Компания, потерявшая сертификат из‑за нарушения сроков уведомления или неполноты перечней, выпадает из этого рынка как минимум на время переоформления. А переоформление с учётом новых требований может занять месяцы.

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

SBOM (Software Bill of Materials — «ведомость материалов ПО») — это структурированный список всех компонентов, библиотек, модулей и зависимостей, используемых в программном обеспечении. Подобно «списку ингредиентов» на продуктах, SBOM помогает выявлять уязвимости, управлять рисками безопасности и контролировать лицензионную чистоту стороннего кода.

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

В целом ФСТЭК последовательно двигается к модели, где безопасность определяется не только тем, что умеет система, но и тем, как она устроена внутри. Прозрачность состава и управляемость изменений становятся такими же обязательными атрибутами, как и сертификационные испытания. Видимо, российским IT-компаниям, работающим в области защиты информации, вскоре придется привыкать к новой реальности.

С цифровой копией документа можно ознакомиться здесь.