Сегодня в отечественной индустрии разработки программных продуктов сложилась уникальная ситуация, когда практически все субъекты КИИ и разработчики прикладного ПО, планирующие поставлять свои продукты для ЗО КИИ, сталкиваются с необходимостью внедрения процессов безопасной разработки ПО (БРПО). В этой статье мы хотим рассказать о предпосылках такой ситуации, а затем рассмотрим возможные подходы, перечислим минимальный набор процессов для обеспечения БРПО в организациях и опишем ход проекта по их внедрению.
Почему нельзя откладывать внедрение безопасной разработки ПО?
С 1 января 2023 года вступает в силу новая редакция Приказа ФСТЭК России № 239 от 25.12.2017 г., согласно которой при создании либо модернизации значимых объектов критической информационной инфраструктуры (ЗО КИИ) прикладное программное обеспечение (ПО) должно соответствовать следующим условиям:
- должны быть реализованы требования по безопасной разработке,
- проведены испытания по выявлению уязвимостей,
- обеспечена поддержка безопасности в ходе жизненного цикла (ЖЦ).
Также до 1 января 2025 года в рамках 166 Указа президента все прикладное ПО на значимых объектах КИИ должно быть импортозамещено. В сумме два этих условия создают уникальную ситуацию, когда практически все субъекты КИИ и разработчики прикладного ПО, которые хотят поставлять свое ПО для ЗО КИИ, столкнутся с необходимостью внедрения процессов безопасной разработки ПО.
Для примера приведем требования по безопасности прикладного ПО из различных отраслевых нормативных документов, для финансовой отрасли данные требования устанавливаются Положениями ЦБ РФ, а также национальными стандартами (п.9.5 ГОСТ 57580.1), а в атомной энергетике предъявляются особые требования по контролю скрытых функций в прикладном ПО (п.5.7.4.2 ГОСТ Р 60880) и исключению небезопасных методов написания кода (п.6.3.5а IEC 62859).
Подходы к внедрению процессов БРПО
Рассматривая существующие подходы к внедрению процессов безопасной разработки ПО (БРПО), можно выделить три основных направления: отечественная регуляторика, гармонизированные международные стандарты, международные стандарты и практики. К последним двум можно отнести стандарты серии ГОСТ/ИСО МЭК 27034 «Безопасности приложений», систему стандартов ГОСТ Р ИСО/МЭК 15408 «Общие критерии», а также стандарты, разработанные на основе накопленного опыта крупных международных вендоров и некоммерческих организаций, таких как Microsoft, Cisco, OWASP и других.
Если говорить про отечественную регуляторику, то это уже упомянутый выше Приказ № 239 ФСТЭК России, а также система национальных стандартов ГОСТ Р 56939, к которой относится один утвержденный стандарт и пять опубликованных проектов стандартов. Изложенные в них подходы хорошо знакомы разработчикам средств защиты информации, которые в ходе сертификационных испытаний проводят проверки безопасности своих программных продуктов по «Методике выявления уязвимостей и недекларированных возможностей» (документ утвержден в 2020 году и имеет ограниченное распространение), а также в соответствии с требованиям Приказа № 76 ФСТЭК России.
Минимально требуемые процессы для обеспечения БРПО
Подробно рассмотрим систему стандартов ГОСТ Р 56939 (Рис. 1):
«Первая книга» устанавливает требования к 22 основным мерам безопасности, которые распределены по 9 основным этапам жизненного цикла ПО.
«Вторая книга» содержит рекомендации по реализации каждой меры безопасности. В ней приводятся типовые действия в ходе подготовки и реализации меры, а также возможное распределение ролей и обязанностей участников.
«Третья книга» устанавливает требования по оценке соответствия: критерии, подходы и методы проведения оценки, а также перечень оцениваемых показателей. То есть мероприятия, которые должен формально провести оценщик для того, чтобы удостовериться, что требования стандарта 56939 выполняются.
- «Первая книга» устанавливает требования к 22 основным мерам безопасности, которые распределены по 9 основным этапам жизненного цикла ПО.
- «Вторая книга» содержит рекомендации по реализации каждой меры безопасности: описывает ее, приводятся типовые действия в ходе подготовки и реализации меры, а также возможное распределение ролей и обязанностей участников.
- «Третья книга» устанавливает требования по оценке соответствия: критерии, подходы и методы проведения оценки, а также перечень оцениваемых показателей. То есть мероприятия, которые должен формально провести оценщик для того, чтобы удостовериться, что требования стандарта 56939 выполняются.
Описывать отдельно следующие три книги мы в рамках данной статьи не будем, скажем лишь кратко, что они содержат требования к методикам и инструментам, реализующим конкретные меры, в том числе требования к процессу проведения статического и динамического анализов кода.
Теперь рассмотрим подробнее требования Приказа № 239 ФСТЭК РФ.
1. Разработка документа «Руководства по безопасной разработке ПО».
Данное руководство, помимо общих организационных моментов, касающихся области действия, определения целей, распределения ролей, должно включать указания на все процедуры безопасной разработки. Для оперативного внесения всех изменений, связанных с разработкой ПО и проведением проверок безопасности, рекомендуем данное руководство разрабатывать в виде электронного документа (с учетом Федерального закона № 63 «Об электронной подписи»).
2. Анализ и моделирование угроз информационной безопасности.
На данном этапе происходит моделирование тех угроз, которые рабочая группа специалистов выявляет в предположении на каждом этапе жизненного цикла и разрабатывает компенсирующие мероприятия, которые затем отражаются на архитектуре разрабатываемого проекта ПО. Для моделирования угроз можно использовать такие опорные материалы, как ГОСТ Р 58412, Методику моделирования угроз ФСТЭК от 2021, БДУ ФСТЭК.
3. Обеспечение прослеживаемости.
Суть процесса заключается в том, чтобы функциональную спецификацию ПО можно было проследить до конкретных блоков функций, которые их реализуют. Это упрощает контроль недекларированных возможностей в ходе реализации проекта ПО и внесения в него изменений.
4. Статический анализ кода (без его исполнения).
Это уже техническая мера, и она требует внедрения специального инструмента — статического анализатора кода. По результатам анализа нескольких проверок безопасности статическим анализатором проекта ПО необходимо провести так называемую «разметку»: сопоставить выявленные ошибки и предупреждения с тем, являются ли они на самом деле недостатками ПО. Также в правила статического анализатора можно добавить необходимую стилистику оформления исходного кода, которая принята в проекте. При каком-либо отступлении от нее разработчику необходимо будет в комментариях указывать причину.
5. Динамический анализ кода (с его исполнением).
В простейшем случае динамический анализ кода проводится в виде ряда тестов: модульного, регрессионного и системного. Модульные тесты разрабатываются на те функции, которые принимают входные значения из внешних данных (т. е. составляют поверхность атаки). В ходе инструментирования кода счетчиками ошибок (санитайзерами и отладочными аллокаторами) необходимо провести автоматизированный запуск этих тестов, собрать тестовое покрытие и проанализировать результаты. На основании результатов можно в том числе увидеть участки кода, которые в ходе выполнения не были задействованы, а значит, требуют дополнительного внимания. К примеру, они могут быть проверены на отсутствие недекларированных возможностей в ручном режиме.
6. Фаззинг-тестирование (с его исполнением).
Для данного процесса необходимо разработать специальные функции либо наборы входных данных (методами «мутационного» или «генерационного» фаззинга), которые подаются на вход тех же самых функций, составляющих поверхность атаки. И точно так же, как в динамическом анализе, для фаззинга собирается покрытие и анализируются результаты, а выявленные ошибки включаются в план устранения недостатков.
7. Отслеживание исправления ошибок, уязвимостей в ходе жизненного цикла.
На данном этапе проводится автоматизация процедур реагирования на выявленные уязвимости, которые возникли в ходе разработки либо по сообщениям от пользователей. Как правило, в информационных системах разработки заводятся тикеты. По данным тикетам разработчикам ставится в план задача по устранению критических уязвимостей и уязвимостей, имеющих высокий приоритет. Устранив уязвимость, разработчик в комментариях может сделать пометку с идентификатором тикета. Тем самым будет обеспечена прослеживаемость закрытия выявленных уязвимостей.
8. Информирование о выявленных уязвимостях и компенсирующих мероприятиях конечных пользователей.
В качестве примера можно привести сообщения на сайтах крупных разработчиков средств защиты информации. Там публикуются сообщения, в которых дается ссылка на источник скачивания обновлений, указываются идентификаторы уязвимостей, а также даются ссылки на инструкции по устранению уязвимостей и проведению дополнительных мероприятий.
9. Оповещение конечного пользователя об окончании жизненного цикла ПО.
К примеру, в специальном разделе сайта разработчика могут быть организованы специальные «фильтры» по продуктам, которые ведут на страницы с планами по поддержке ПО в ходе жизненного цикла.
На рис. 2 видно, что 22 меры, содержащиеся в требованиях ГОСТ Р 56939, накладываются на 9 новых процессов по требованиям 239-го приказа ФСТЭК РФ. Рекомендуем закладывать процессы таким образом, чтобы в дальнейшем расширять их до охвата всех необходимых этапов жизненного цикла.
Далее мы рассмотрим проект по внедрению процесса БРПО в соответствии с требованиями регулятора.
Проект по внедрению процесса БРПО
Масштабы проекта для субъекта КИИ зависят от типа разработки: собственная, заказная или вендорская. Когда прикладное ПО разрабатывается силами собственных разработчиков, необходимо внедрить наиболее полный состав процессов безопасности. В случае заказной разработки или использования вендорского ПО необходимо обеспечить наличие всех необходимых свидетельств по процессам безопасности, выстроенным на стороне вендора — производителя ПО, и приобщить их в проектную документацию на ЗО КИИ.
Как правило, типовой проект внедрения процессов безопасной разработки ПО разделяется на пять основных этапов.
На первом этапе готовится технико-экономическое обоснование для руководства с верхнеуровневыми финансовыми параметрами проекта, основными этапами работ, основными результатами, которые достигаются в ходе проекта, а также персоналом, который требуется привлечь.
На втором этапе проводится аудит текущих бизнес-процессов разработки, формируется целевое состояние процессов разработки, исходя из требований регулятора либо бизнес-потребностей, далее выявляются несоответствия и формируются рекомендации по внедрению организационных и технических мероприятий.
На третьем этапе рекомендации ранжируются по степени их реализуемости и сводятся в дорожную карту. Настоятельно рекомендуем разрабатывать детальный план перехода и пояснительную записку с обоснованием принятых решений, чтобы всегда можно было поднять историю и причины принятых решений.
Четвертый этап — это уже непосредственно работа проектной команды, которая движется по дорожной карте. Исходя из практики, оптимальным вариантом является тот, в котором техническое лидерство в проекте остается за разработчиками, а организационное лидерство, то есть руководство проектом, возложено на специалиста по информационной безопасности. В этом случае происходит тесная интеграция компетенций безопасников и разработчиков.
И наконец, на последнем этапе происходит контроль функционирования внедренных процессов. Через несколько месяцев после завершения внедрения производится сбор и анализ всех свидетельств и записей процессов безопасной разработки ПО на предмет их полноты и достаточности.
В данной статье мы рассмотрели минимально необходимый набор процессов, которые должны быть внедрены по Приказу № 239 ФСТЭК России. Разумеется, подобных процессов безопасности и проверок может быть гораздо больше: сканирование на уязвимости, сканирование зависимостей, антивирусная проверка, анализ дампа сетевого трафика при динамическом анализе ПО или анализ логов при сборке проекта, любые другие виды проверок ПО на стендах или проведение пентестов.
Хочется отметить, что для внедрения процесса БРПО можно ориентироваться на ГОСТ Р 56939. Это позволит не только выполнить требования приказа ФСТЭК, но и охватить все необходимые этапы жизненного цикла разработки ПО.
При реализации проекта по внедрению БРПО необходимо учитывать существующие процессы разработки, специфику организации и ее значимых объектов КИИ. Старт проекту должно дать руководство при полном понимании выгод от его реализации и затрат на него.