Повышенное внимание в последнее время уделяется безопасной разработке программного обеспечения. Специалисты следят за изменениями нормативных документов, введение которых сопровождается дополнительными рисками и обязательствами. В декабре прошлого года вступил в силу обновленный ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Эксперты прогнозируют, что требования к безопасной разработке ПО будут ужесточаться и дальше. На основании чего делается такой вывод?
О специфике положений стандарта старший консультант департамента консалтинга, отдела безопасности жизненного цикла ПО компании Infosecurity Сергей Гаркуша рассказал на вебинаре. Утвержденная в октябре 2024 г. новая версия стандарта ГОСТ Р 56939-2024 («Защита информации. Разработка безопасного программного обеспечения. Общие требования») вступила в силу с 20 декабря прошлого года. С 1 марта 2026 г. начнет действовать обновленный Приказ ФСТЭК России № 17, один из разделов которого посвящен требованиям безопасной разработки. Все это говорит о том, что процессы безопасной разработки находятся в фокусе внимания регулятора.
Предпосылки пересмотра
Предыдущий ГОСТ Р 56939-2016 нуждался в пересмотре. Во-первых, описанные в нем меры были недостаточно конкретными, не позволяли оценить качество реализации той или иной меры. Во-вторых, указанные меры не содержали требований к составу и содержанию свидетельств разработчика. И в-третьих, с момента выхода стандарта значительно возрос запрос на повышение безопасности ПО.
В новом ГОСТе предусмотрен порядок действий оценщика (что именно необходимо проверить), более подробно описываются процессы безопасной разработки. По мнению регулятора, этот документ может служить аналогом международных практик, таких как OWASP SAMM и BSIMM.
ГОСТ предусматривает 24 процесса (в предыдущем было девять практик), охватывает все этапы жизненного цикла: начиная от планирования процессов и заканчивая выводом ПО из эксплуатации. Для каждого процесса определяются порядок реализации, артефакты и требования к их содержанию.
К этому ГОСТу выпущены дополнительные документы, конкретизирующие ряд требований, но не все из них вступили в силу. Например, один из ГОСТов описывает архитектуру и правила ее безопасного проектирования, другой определяет требования к анализатору, третий – порядок безопасной компиляции языков.
Примеры процессов
На примере процесса разработки, уточнения и анализа архитектуры ПО эксперт рассмотрел требования, которые следует соблюдать. В частности, ГОСТ требует отразить принятые подходы и принципы проектирования архитектуры ПО (инкапсуляция, уникальность, разделение задач, применение заимствованных компонентов и т. д.), в том числе с точки зрения ИБ («нулевое доверие», «протоколирование событий», резервное копирование», формирование перечня недопустимых событий» и т. д.).
Критерии необходимости уточнения архитектуры ПО должны содержать информацию о периодичности пересмотра (уточнения) архитектуры ПО в процессе разработки программного обеспечения. Вначале требуется выполнить первичное проектирование архитектуры ПО, затем уточнять архитектуру ПО в процессе разработки кода и его изменений (периодически или при наступлении определенных событий).
Описание архитектуры ПО должно включать как минимум следующую информацию:
- назначение ПО и сценарии его использования;
- описание среды функционирования;
- ограничения и указания по применению;
- проект ПО на уровне подсистем (модулей), включающий описание их назначения, структуры, особенностей реализации, взаимодействия, в том числе с другим ПО, с указанием соответствующих интерфейсов, сетевых портов, протоколов.
Детально прописана и процедура использования инструментов композиционного анализа. На каждый процесс рекомендуется написать регламент и критерии. ГОСТ формирует требования, позволяющие выстроить процесс. В частности, следует формировать перечень зависимостей ПО, контролировать и актуализировать список зависимостей ПО в соответствии с регламентом композиционного анализа, анализировать заимствованные компоненты, составляющие поверхность атаки на предмет наличия уязвимостей. По результатам анализа заимствованных компонентов необходимо применять корректирующие воздействия.
Наряду с этим нужно описывать процедуру контроля перечня зависимостей ПО и его актуализации; инструменты контроля актуальности зависимостей ПО. Предписано также вести журналы регистрации событий, связанных с контролем актуальности списка зависимостей и с обновлениями модулей (компонентов) заимствованного ПО, участвующих в сборке программного обеспечения.
Таким образом, применительно к процессу использования инструментов композиционного анализа ГОСТ предусматривает регламент композиционного анализа, требования к нему, составление перечня заимствованных компонентов, контроль актуальности перечня зависимостей ПО.
Руководство к действию
В ходе вебинара эксперт ответил на вопрос, зачем соблюдать установленные положения. ГОСТ содержит регуляторные требования, актуальные для разработчиков средств защиты информации, субъектов КИИ, операторов государственных информационных систем. Данные положения можно рассматривать как методические рекомендации, помогающие интерпретировать и детализировать требования, указанные в других правовых актах.
ГОСТ – это руководство к действию для компаний, которые заинтересованы в составлении дорожной карты и распространении практики для внедрения процессов безопасной разработки ПО. Тем самым документ помогает найти золотую середину, когда и регуляторные требования не нарушены, и дорожная карта выстроена так, чтобы оптимизировать инвестиционные затраты. Инвестиции в безопасную разработку окупаются в результате повышения уровня защиты приложений и инфраструктуры от атак, в частности, вирусов-шифровальщиков, способных приостановить деятельность компании, что повлечет за собой финансовые потери. Соответствующие меры защиты позволяют предотвратить утечки персональных данных, а значит, избежать штрафных санкций.
К ГОСТу следует обращаться за детализацией требований, предусмотренных в Приказе ФСТЭК № 17. В частности, в нем указано «Проведение экспертизы исходного кода программного обеспечения на наличие уязвимостей» (п. 43). При этом не приводятся ни методика, ни роли, ни критерии или артефакты. Понять, выполнено ли указанное требование, поможет ГОСТ по безопасной разработке. В нем отражены действия оценщика: что именно ему надлежит проверить, чтобы подтвердить выполнение того или иного требования.
Приказом ФСТЭК № 239 (п. 29.3.2) установлены требования к испытаниям по выявлению уязвимостей в программном обеспечении. В частности, нужно выполнить:
– статический анализ исходного кода программы;
– фаззинг-тестирование программы, направленное на обнаружение в ней уязвимостей;
– программу динамического анализа кода.
За деталями также рекомендуется обращаться к ГОСТ 56939–2024 (раздел 5.10: Статический анализ исходного кода). В нем указан регламент проведения статического анализа исходного кода ПО (п. 5.10.2.1), описывается порядок реализации требований.
Требования повышаются
Что касается ожиданий от применения ГОСТ Р 56939–2024, то, как заметил Сергей Гаркуша, важно знать, к чему готовиться. Эволюция требований ФСТЭК в этом направлении показывает, что они будут ужесточаться. Стандарты и приказы регулятора обновляются, причем упор делается на выстраивание процессов безопасной разработки ПО.
Обновленный ГОСТ не только содержит детализированные нормы (более четкие и в большем количестве), но и предписывает соответствующие требования оценщика, который проводит оценку соответствия. Более того, уже известно, что ГОСТ планируется дорабатывать и уточнять применительно к уровням зрелости. В данном документе, как следует из его наименования, отражены общие требования.
Одновременно ужесточаются меры контроля за соблюдением ГОСТа. Например, для сертификации средств защиты информации предоставляются артефакты, подтверждающие выполнение требований, а лаборатория может запросить снять логи с инструментов (чтобы убедиться, что артефакты не подделаны). Либо аудитор может выехать на объект или запросить удаленную демонстрацию всех процессов, изучить историю выполнения анализов, заполнения журналов, провести интервью с сотрудниками, чтобы проверить, насколько они знакомы с процессом. Усиление требований объясняется тем, что на практике компания может разработать документы, но не внедрить процессы.
Культура разработки
Эксперты полагают, что ГОСТ Р 56939–2024 будет распространяться за рамки сертификации процессов безопасной разработки для создателей средств защиты информации. Положения документа находятся в поле зрения Банка России, Минобороны, ФСБ России.
В конце вебинара Сергей Гаркуша отметил, что в России развивается культура безопасной разработки ПО. В подтверждение этого тезиса он привел несколько аргументов. Например, ряд финансовых организаций обратились к Центральному Банку с предложением внедрять процессы РБПО для снижения издержек, в Сети огромное количество тематических форумов. Кроме того, сам ГОСТ писали не сотрудники ФСТЭК, а представители не менее десяти компаний (которые обращали снимание на международную практику), документ прошел процедуру утверждения техническим комитетом.
На внедрение процессов и практик безопасной разработки нужно время, поэтому эксперты рекомендуют компаниям действовать, не откладывая дело в долгий ящик. Но движение в заданном направлении должно быть постепенным, чтобы оградить продуктовые команды от стресса, вызванного быстрой сменой рабочих процессов. Соблюдение предложенного сценария позволит грамотно распределить бюджет.
