От оценочного уровня финансового программного обеспечения к безопасной разработке

Не так давно разработчикам финансовых приложений необходимо было проводить повторную оценку соответствия по требованиям ОУД4 при внесении любых изменений в функции безопасности программных продуктов. В случае с СЗИ, аналогом такой процедуры являлась сертификация. Ее необходимо было осуществлять при внесении любых изменений в ПО. Такой подход к проверкам безопасности приводил к существенной задержке выпуска новых версий программных продуктов.

В данной статье Андрей Боев, руководитель направления безопасной разработки программного обеспечения RTM Group, обсудит новую редакцию ГОСТ Р 56939-2024, который устанавливает правила и методы сертификации процессов безопасной разработки программного обеспечения. Узнаем, что выгоднее: проводить ОУД 4 или сертификацию процессов безопасной разработки. Также расскажем о «подводных камнях» и о том, какие специалисты должны быть в штате для соответствия требованиям. Данная статья предназначена для руководителей компаний, разработчиков ПО, специалистов информационной безопасности, планирующих прохождение ОУД 4 или сертификацию процессов безопасной разработки по проектной версии 821-П.

Позиция регулятора по безопасной разработке

Проектная версия 821-П Центрального Банка РФ предполагает оценку программного обеспечения (ОУД 4), которое используется для финансовой деятельности. Регулятор уточняет, что:

1. Оценка Программного обеспечения (ПО) должна производиться вновь при внесении изменений в текст программы.
2. Оценка ПО (ОУД 4) может не проводиться, если разработчик (Некредитная финансовая организация или субъекты 821-П) имеет сертификат, удостоверяющий, что его «процессы безопасного жизненного цикла соответствуют ГОСТ Р 56939-2024» (далее ГОСТ).

Позже проектная версия 821-П ЦБ РФ была удалена с сайта регулятора. Однако, информация осталась в системе Гарант, где есть упоминание о безопасном жизненном цикле, что дает предположить, что в будущем ЦБ РФ может внедрить практику безопасной разработки программного обеспечения вместо ОУД 4.

Что нового в ГОСТ Р 56939-2024?

Новая редакция ГОСТ вступила в силу 20 декабря 2024 года. Основной упор в ней сделан на процессы безопасной разработки программного обеспечения.

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

У многих организаций возникает вопрос: «По какому пути пойти в будущем и нужна ли сертификация процессов безопасной разработки программного обеспечения?» Мы рассмотрим ответ на этот вопрос в следующем блоке статьи.

ОУД 4 с профилем ЦБ РФ и без

Оценка в рамках ОУД 4 может проводиться на соответствие профилю защиты ЦБ РФ или частному заданию по безопасности. Рассмотрим подробнее эти варианты.

Работы по ОУД 4 можно разбить на следующие этапы:

1. Предварительное обследование объекта оценки и разработка рекомендаций по его приведению в соответствие требованиям ОУД4 по ГОСТ 15408-3-2013
2. Разработка документов Заявителя для проведения оценки соответствия ОУД4 по
    ГОСТ 15408-3-2013
3. Оценка соответствия ОУД4 по ГОСТ 15408-3-2013

Рассмотрим подробнее второй этап, так как он является ключевым для положительной оценки. Для разработки документации заявителя без профиля защиты необходимо подготовить порядка пятнадцати документов. В процессе выполнения этой задачи нужно привлечь около 15 разных специалистов (разработчики, тестировщики, специалисты ИБ, технические писатели и др.).

Для того, чтобы оценить расходы, приведем средние расходы на таких специалистов (по секторам) для Москвы на основе данных с сайтов hh.ru и superjob.ru:

Также следует учесть, что для составления такой документации необходима соответствующая квалификация персонала, так как не всем специалистам понятна специфика оценки. Из-за этого многие компании заказывают все необходимое в компаниях, оказывающих такие услуги. В зависимости от архитектуры, используемых языков программирования и функций безопасности у нас получится разный объем документации. Однако в среднем рыночная стоимость такой услуги начинается от 512 тыс. рублей и могут доходить до 3,5 млн. рублей [1].

Из чего складывается стоимость? Она обусловлена следующими факторами:

1. Заказчик не всегда хочет предоставлять исходные коды подрядчику, а потому последний должен выезжать на объект и проводить анализ на месте. Учитывая, что сторонние специалисты не могут в командировках параллельно заниматься другими проектами, эти потери включаются в цену. Исходные коды необходимы для документов «Представление реализации функций безопасности» и «Базовый модульный проект», в которых описывается взаимодействие между модулями программы. Подготовить их без исходных кодов не представляется возможным.
2. Мало специалистов в этой сфере, обладающих соответствующей квалификацией для разработки такой документации. Помимо знаний нормативной базы, необходимо разбираться в программировании для описания функций безопасности в исходных кодах. Также важно иметь представление о функциях, классах, методах, которые реализуют или поддерживают функции безопасности. Ну и не забудем про необходимость тестирования.
3. Высокие зарплаты в IT-сфере.

Разработка документации заявителя по профилю защиты ЦБ обойдется дороже, так как количество «бумаг» больше на треть. Так же следует учесть, что все функции безопасности, представленные в профиле ЦБ РФ, должны быть реализованы в оцениваемом ПО. Из-за большого перечня функций безопасности объем такой документации больше.

Ну и еще к стоимости услуги по составлению документации нужно добавить 30% на анализ исходного кода, пентест и другие работы по оценке, чтобы получить итоговую стоимость работ. Конечно, здесь есть разные варианты, но в целом все это обойдется не более чем в 5 млн рублей. Стоит также отметить, что при выполнении оценки соответствия с применением профиля защиты ЦБ РФ анализ уязвимостей исходного кода проводится по более высокому классу доверия AVA_VAN.5. Все это также приводит почти к двукратному увеличению конечной стоимости проводимых работ.

Плюсы такого подхода:

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

Минусы:

• при изменении функций безопасности объекта оценки необходимо проводить новую оценку.

Подготовка организаций к сертификации процессов безопасной разработки

Подготовка организаций к сертификации процессов безопасной разработки реализуется в несколько этапов:

1. Предварительный аудит готовности организации к сертификации существующих процессов безопасной разработки программных продуктов в соответствии с требованиями ГОСТ 56939-2024.
2. Формирование дорожной карты развития и внедрения процессов безопасной разработки программных продуктов в организации.
3. Разработка необходимой технической и организационно-распорядительной документации по безопасной разработке программных продуктов в организации
4. Внедрение необходимых организационных и технических мер защиты информации, обеспечивающих безопасность в процессе разработки ПО в организации.
5. Сопровождение организации при оформлении заявки на сертификацию процессов безопасной разработки программных продуктов.

Данные виды работ еще не проводятся, так как регламентирующие документы не вступили в силу, поэтому мы будем сравнивать ценообразование по видам работ, наличию необходимых специалистов (их рыночную зарплату) и объему.

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

Следует учесть, что для сертификации необходимо разработать большой пакет документов, причем новый ГОСТ устанавливает требования к новым мерам, обеспечивающим ИБ. Более подробно мы перечислим их в разделе «Сильно ли отличается ГОСТ 2016 года от ГОСТ 2024г.?» Также важно отметить, что для сертификации потребуется другой состав документов, нежели для ОУД 4 (более большой). Это также повлияет на увеличение стоимости.

Для разработки документации по сертификации требуется такой же состав специалистов, как и для ОУД 4, но еще с расширенными знаниями в области безопасной разработки.

Вот кто нужен еще:

• DevSecOps инженер;
• Offensive инженер;
• Defensive инженер;
• Security Champion.

Рассмотрим среднюю зарплату этих специалистов по данным сайтов hh.ru и Superjob.

DevSecOps инженер: от 130,000 до 250,000 рублей в месяц. Эта роль требует знаний как в DevOps, так и в безопасности.

Offensive инженер (пентестер): от 100,000 до 250,000 рублей в месяц. Профессионалы с большим опытом могут зарабатывать больше, особенно в крупных компаниях или при выполнении сложных проектов.

Defensive инженер (аналитик по безопасности, инженер по защите информации): от 80,000 до 200,000 рублей в месяц. Зарплата зависит от конкретных обязанностей и уровня ответственности.

Security Champion: от 90,000 до 250,000 рублей в месяц. Требуемый набор компетенций и выполняемых задач может значительно варьироваться в зависимости от уровня внедрения практик безопасности в организации.

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

Далее рассмотрим порядок сертификации по 240 приказу ФСТЭК. Итак, при прохождении сертификации процессов безопасной разработки необходимо подготовить руководство по безопасной разработке и другую документацию. Новый ГОСТ устанавливает дополнительные требования к процессам. Следовательно, нужно создать новые шаблоны документов, в том числе, для внедрения этих процессов в среду разработки. Также стоит учесть, что компаний, занимающихся разработкой такой документации, на сегодняшний день немного. Сам процесс сертификации производится в соответствии с приказом ФСТЭК 240. Его можно представить в виде упрощенной схемы.

На сегодняшний день, в соответствии с реестром аккредитованных ФСТЭК органов по сертификации, провести сертификацию процессов безопасной разработки может только ИСП РАН. Поскольку сертификации по новому ГОСТ еще не проводилось, мы можем только по косвенным признакам судить о стоимости услуги. Конкуренции в нише практически нет, а сам процесс занимает довольно много времени (по сравнению с ОУД 4), включая выстраивание безопасной разработки и оплату дорогостоящих кадров. Можно лишь прогнозировать, что стоимость будет очень высокой. 

Рассмотрим плюсы сертификации процессов безопасной разработки:

• Возможность изменять ПО без необходимости повторной оценки (ОУД 4);
• Улучшение безопасности – сертифицированные процессы гарантируют, что лучшие практики в области безопасности интегрированы в разработку, что снижает риски;
• Оптимизация процессов, которая может привести к более эффективной работе команд;
• Снижение затрат, в том числе, на исправление ошибок в будущем;
• Внедрение сертифицированных процессов способствует формированию культуры безопасности в команде.

Минусы сертификации процессов безопасной разработки:

• Стоимость намного превосходит расценки на ОУД 4;
• Отсутствие полного стека сертифицированных средств среды разработки;
• Проблема использования коммерческих зарубежных инструментов из-за санкций;
• Высокие риски использования зарубежных инструментов на базе Open Source;
• Ограниченный срок действия сертификата, необходимость повторной сертификации.

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

Так, например, австралийская компания Atlassian предлагала инструменты, которые помогают следовать принципам безопасной разработки (SSDLC), включая управление доступом, шифрование данных, контроль версий и интеграцию с системами управления уязвимостями. Наиболее известные продукты компании: Jira (система отслеживания ошибок и задач), Confluence (инструмент для создания и совместной работы над документацией) и Trello (сервис для организации проектов с использованием карточек).

Компания была основана в 2002 году и с тех пор стала одним из лидеров на рынке инструментов для разработки и управления проектами. Atlassian предлагала свои продукты как в виде облачных решений, так и в формате ПО для установки на собственных серверах клиентов. В августе 2023 стало известно, что аккаунты пользователей в сервисах Atlassian будут заблокированы через 30 дней. Об этом вендор сообщил клиентам посредством e-mail рассылки.

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

Сильно ли отличается ГОСТ 2016 года от ГОСТ 2024 года?

Отличия ГОСТ 2016 г. от ГОСТ 2024г. представлены в ГОСТ Р 56939-2024,
приложение А, таблица 1 – Сопоставление мер по разработке безопасного программного обеспечения из ГОСТ Р 56939-2016 и требований к процессам настоящего стандарта.

Вот список новых мер, которых не было в ГОСТ 2016:

• Планирование процессов разработки безопасного программного обеспечения;
• Обеспечение безопасности используемых секретов;
• Использование инструментов композиционного анализа;
• Проверка кода на предмет внедрения вредоносного кода через цепочки поставок;
• Обеспечение безопасности при выводе программного обеспечения из эксплуатации.

Следовательно, для повторной сертификации необходимо доработать эти меры.

Заключение

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

Если процессы безопасной разработки выстроены, у вас есть необходимая документация и вы используете российские средства безопасной разработки, а ваше ПО часто обновляется и в нем регулярно меняются функции безопасности, и вы заложили большой бюджет на сертификацию процессов безопасной разработки, то сертификация по ГОСТ Р 56939-2024 - ваш выбор. 

[1] Цены актуальны на ноябрь 2024 года