Стоит напомнить, что данный документ необходимо применять при проведении работ по оценке соответствия (анализу защищенности) прикладного программного обеспечения по требованиям к оценочному уровню доверия (далее – ОУД)!
Новая редакция дополняет «Профиль защиты» разделом 7.4, в котором приводит требования к гибкой безопасной разработке и тестированию прикладного программного обеспечения с соблюдением требований положений нормативных актов Банка России.
Новый раздел описывает безопасность жизненного цикла объектов оценки и требования к их разработке и тестированию. Иными словами, в изменениях приведено, как правильно выстраивать DevSecOps процессы при разработке ПО. И в этой статье рассмотрим, что предлагает новый раздел профиля защиты.
В новой версии документа добавлено два новых сокращения:
- СМИБ – система менеджмента информационной безопасности;
- СОИБ – система обеспечения информационной безопасности.
Добавились новые термины:
- Безопасный жизненный цикл разработки ПО (DevSecOps);
- Команда безопасной разработки ПО (команда DevSecOps).
Большое изменение произошло в приложениях. Добавлено новое Приложение В, в котором детализирован ориентировочный процесс безопасного жизненного цикла объекта оценки (далее – ОО) в виде BPMNдиаграмм следующих процессов:
- общий цикл;
- цикл разработки требований;
- цикл мониторинга выполнения требований;
- цикл разработки кода;
- цикл статического анализа;
- цикл динамического анализа;
- цикл проверки кода (Code Review) и проверки безопасности (Security Review);
- цикл фаззинг тестирования;
- цикл тестирования на проникновение;
- цикл функционального тестирования;
- цикл внедрения.
Использование данной методологии жизненного цикла предполагается для целей предотвращения и устранения уязвимостей в ОО, поддержания доверия на всем протяжении жизненного цикла и обеспечения необходимого и достаточного уровня безопасности.
При этом использование предлагаемой методологии позволяет выполнить переход от требования доверия к безопасности (далее – ТДБ), связанных с оценочным уровнем доверия, к настоящей методологии безопасного жизненного цикла. Но это возможно только при условии соответствия отдельных процессов разработчика критериям и условиям, указанным в п.7.4.2 новой редакции «Профиля защиты».
Так, согласно данному пункту существуют 4 условия для перехода к оценке безопасности процесса разработки ОО:
- ОО не должен использоваться в составе объектов критической информационной инфраструктуры (КИИ), которым присвоена категория значимости;
- Разработчик должен иметь документированный процесс разработки, тестирования и эксплуатации, включая описания реализуемых мер, контролей (security controls) и проверок по обеспечению информационной безопасности;
- Разработчик должен иметь документированный процесс управления версиями и изменениями программного обеспечения;
- Инфраструктура Разработчика, на которой выполняются процессы разработки, тестирования и развертывания, а также среды постоянной эксплуатации финансовой организации, должна соответствовать требованиям ГОСТ Р 57580.1-2017 с учетом определенного уровня защиты информации для финансовой организации и иметь соответствующее подтверждение оценки соответствия по ГОСТ Р 57580.2-2018. Инфраструктурные системы по обеспечению информационной безопасности и соответствующие требования к ним должны быть документированы.
Также в документе отдельно выделены три критерия для реализации безопасного жизненного цикла:
- В команде разработки ОО должны участвовать ИТ-архитектор, аналитик ИБ (aka «Application Security», «AppSec»), DevOps-инженеры и тестировщики, а также Security Champion – член команды с высокой осведомленностью в вопросах обеспечения информационной безопасности;
- Наличие программного обеспечения для реализации процессов жизненного цикла безопасной разработки, обеспечения условий непрерывности процесса разработки и тестирования, автоматизации процессов тестирования, а также переноса и взаимодействия между средами, использования общих ресурсов в условиях обеспечения информационной безопасности;
- Функциональные требования и описание реализации ОО должны быть документированы: основные функции безопасности, роли, применяемые архитектурные, технологические и технические решения, категории защищаемой информации.
Начинать оценку соответствия можно после того, как успешно пройдены все этапы жизненного цикла ОО; об этом получено формальное заключение; документально подтвержден выпуск ОО в продакшн.
Разработчик сам решает, когда именно проводить оценку соответствия, главное, чтобы это было не реже сроков, установленных нормативными правовыми актами. Например, можно привести оценку соответствия при выходе мажорной версии ОО или изменениях, добавляющих или изменяющих функции, или структуру ОО. Конкретные условия, при которых требуется прохождение оценки соответствия, нужно задокументировать в функциональных требованиях.
Жизненный цикл ОО состоит из задач, каждая из которых в свою очередь имеет шаги выполнения. Всего в документе представлено 8 задач безопасного жизненного цикла:
- «Организационная подготовка» – определение требований по подготовке и организации процесса безопасного жизненного цикла ОО, а также требований к организационной модели команды, ролевому составу, ответственности, компетенции и обучению;
- «Формирование требований к ОО» – формулирование (не)функциональных требований к разрабатываемому ОО, включая требования к обеспечению информационной безопасности ОО;
- «Архитектура и проектирование ОО» – разработка архитектурного решения и проектного описания ОО;
- «Реализация (разработка) ОО» – непосредственное кодирование и процесс реализации ОО;
- «Тестирование ОО» – проверка реализации ОО и качества его исполнения на соответствие функциональным и нефункциональным требованиям, включая требования к обеспечению информационной безопасности ОО;
- «Подготовка и перенос ОО в промышленную эксплуатацию» – проверка ОО на готовность выполнять требований ИБ и корректный перенос в продакшн;
- «Эксплуатация и сопровождение ОО» – мониторинг, обновление, сопровождение и сопутствующая эксплуатация ОО;
- «Вывод из эксплуатации ОО» – снятие с эксплуатации ОО.
В таблице 1 главы 7.4.3 профиля защиты приводится взаимосвязь задач и шагов ориентировочного процесса безопасного жизненного цикла ОО.
Разработчик должен
- 1.Задокументировать процесс безопасного жизненного цикла;
- 2.Проводить внутренние проверки соответствия мер требованиям ПЗ;
- 3.Постоянно совершенствовать процессы на основе внутренних проверок, изменении рисков в модели угроз и изменении требований раздела 7.4 ПЗ;
- 4.Определить требования ИБ для разработки ОО (безопасное кодирование, архитектура ПО, защита инфраструктуры);
- 5.Обеспечить целостность исходного кода, защитить инфраструктуру от НСД, хранить код в репозитории;
- 6.Определить роли участников команды проекта, ответственной за жизненный цикл.
Базовые роли участников жизненного цикла:
- Аналитик ИБ (AppSec) – обычно роль выполняет сотрудник подразделения информационной безопасности и защиты информации);
- Security Champion – специалист с высокой осведомленностью в вопросах информационной безопасности, имеющего также определенные компетенции в области безопасности прикладного программного обеспечения и принципов безопасной разработки.
При необходимости можно создать новые роли или изменить обязанности существующих.
Как несложно заметить, изменения в новой редакции достаточно масштабные. И на наш взгляд, самое сложное – для того, чтобы соответствовать данным требованиям большинству разработчиков придется менять процесс разработки финансового программного обеспечения.
С другой стороны, понятна и логика появления данных требований – перестройка процесса разработки программного обеспечения позволяет выстроить такой процесс разработки, в результате которого разрабатываемое ПО всегда будет соответствовать требованиям ОУД.
При этом, согласно новой редакции «Профиля защиты» разработчик может отказаться от классической оценки соответствия ПО по требованиям к ОУД и, по сути, перейти от оценки соответствия ОО к оценке соответствия требованиям безопасности процесса разработки ОО (с учетом вышеуказанных ограничений). Теперь у финансовых организаций есть добровольный выбор: либо однократно потратить много ресурсов на внедрение процесса безопасной разработки, но такое по силам только крупным организациям, либо с определенной периодичностью проводить обычную оценку соответствия ПО по требованиям к ОУД за меньшие деньги и без необходимости что-либо менять в налаженных бизнес-процессах.
Для каждой организации будут свои «за» и «против» того или иного подхода, связанные не только с финансовыми затратами.
И вместо заключения, стоит отметить, что согласно новой редакции «Профиля защиты» оценка соответствия требованиям безопасности процесса разработки ОО проводится разработчиком самостоятельно, либо с участием организации, независимой от организаций, осуществлявших или осуществляющих оказание услуг разработчику в области информатизации и защиты информации. Возможно Банк России уточнит данные требования в новых редакций соответствующих Положений.
Решить мой вопрос
