Всем привет! У нас новый автор - Виктор Дрынов, руководитель отдела безопасной разработки Angara Security. Сегодня он расскажет, как стандарты могут помочь минимизировать риски и повысить качество разработки

Немного о требованиях регуляторов

С чего стоит начать подход к безопасной разработке? С изучения требований национальных стандартов и иных нормативно-правовых документов (НПА), разработанных регуляторами.

В России разработаны и приняты национальные стандарты по разработке безопасного программного обеспечения (РБПО), а именно:

• ГОСТ Р 56 939–2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»;

• ГОСТ Р 58 412–2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения»;

• ГОСТ Р 71 206–2024 «Защита информации. Разработка безопасного программного обеспечения. Безопасный компилятор языков C/C++. Общие требования»;

• ГОСТ Р 71 207–2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования».

Также Федеральной службой по техническому и экспортному контролю (ФСТЭК России) приняты дополнительные нормативно-правовые акты:

• Приказ ФСТЭК России от 01.12.2023 № 240 «Об утверждении Порядка проведения сертификации процессов безопасной разработки программного обеспечения средств защиты информации»;

• Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении (ФСТЭК России);

• Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации».

Положения Банка России 851-П, 757-П, 821-П, 802-П содержат требования финансового регулятора по оценочному уровню доверия 4 ГОСТ Р ИСО/МЭК 15408-3-2013 (ОУД4), которые также имеют требования по безопасной разработке.

Стоит отметить, что:

• ГОСТ Р 58412-2019 применяется совместно с ГОСТом Р 56939 и способствует его реализации, так как перечень и описание угроз безопасности информации, представленные в стандарте, помогут в определении актуальных для среды разработки угроз.

• ГОСТ Р 71207-2024 применяется совместно с ГОСТом Р 56939 и способствует его реализации, более детально описывая порядок внедрения и выполнения статического анализа.

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

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

Также стоит учитывать, что, согласно «Требованиям по обеспечению безопасности значимых объектов КИИ РФ» ФСТЭК России в случае, если в ходе проектирования подсистемы безопасности значимого объекта предусмотрена разработка программного обеспечения, в том числе ПО средств защиты информации, такая разработка проводится в соответствии со стандартами безопасной разработки программного обеспечения (п. 11.2). Документ включает и требования по безопасной разработке программного обеспечения (п. 29.3.1–29.3.3).

 С чего начать процесс безопасной разработки ПО?

 С оценки текущего состояния процессов, инструментов, команды. Стоит ответить на вопросы:

• Есть ли в компании описание актуальных процессов разработки ПО и зон ответственности или «вон тот человек» все знает и за это отвечает?

• Какие информационные системы используются, кем и на каком этапе?

• По какому принципу выдаются права на использование инструментов, кем и когда отзываются?

• Определена ли структура команды разработки, зоны ответственности и технический стек?

• Прописаны ли регламенты взаимодействия или руководство полагается на абстрактный здравый смысл?

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

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

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

Формирование потребностей, бюджета, сроков. Звучит банально, но на практике охватить все сразу сложно. Нужно понять, какой именно статический анализатор лучше подойдет к имеющемуся стеку (и впишется в бюджет). Стоит заложить в смету полноценное вендорское решение для композиционного анализа или же использовать опенсорс-решение и запланировать покупку динамического инструмента? Необходимо учитывать появление новых задач и увеличение объемов работы по текущим проектам, расширение команды, объем допустимого технического долга. Мало DevSecOps-команд в принципе готовых формализовать свои планы с четким соблюдением сроков и расходов.

Составление верхнеуровневого плана по внедрению новых практик и процессов. Появление новых практик необходимо согласовывать с руководителем разработки для учета дополнительных трудозатрат, новых процессов и определения ответственных со стороны разработки. А это зачастую занимает куда больше времени, чем инсталляция и тестирование нового инструмента.

Регламент по реализации новых практик: кто, почему и зачем

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

Планы по формированию DevSecOps-команды: количество, роли, грейд

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

Обоснование нововведений для команд разработки. Звучит просто, но любые новые практики — это дополнительные трудозатраты. Руководителю разработки нужно будет учитывать в планах и сроках новые задачи по устранению уязвимостей. Также у разработчиков возникают вопросы по поводу обоснования и новых обязанностей в плане устранения уязвимостей: зачем это нужно, кто будет заниматься этой задачей? На практике AppSec-инженер зачастую отрезан от команд разработки и взаимодействие осложняется желанием разработчиков заниматься закрытием поставленных задач по разработке/доработке функционала от руководителя, а не устранением уязвимостей.

Обоснование необходимости аудита процессов безопасной разработки

Еще один интересный вопрос — аудит безопасности ПО на всех этапах жизненного цикла. Существуют как иностранные фреймворки, например открытый BSIMM (от англ. Building Security In Maturity Model — модель оценки безопасности ПО), так и российские фреймворки DAF и TableTop. Они позволяют проводить аудит самостоятельно, но для этого требуется подробное изучение документации по практическому применению. Почему бы не сделать все самому? И тут возникают ключевые вопросы:

1. Как оценить текущее состояние разработки и в чем сложность?

2. Какой результат нам нужен и для чего?

3. Все ли получится оценить своими силами?

4. Формализация процессов и проект регламента.

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

Вроде бы звучит не так уж и сложно. Что может пойти не так? При небольшой команде разработки минимальное время оценки — от двух недель при готовой методике использования фреймворка. Если такой нет, время на изучение и реализацию займет еще несколько недель. И все это при полной занятости и без формирования итоговой документации. Помимо этого, на выполнение задачи будет выделен специалист DevSecOps/AppSec. Готов ли инженер длительное время заниматься документацией и опросами? Насколько хорошо у него это получится?

Какой результат нам нужен? Допустим, вы провели анализ процессов разработки на основе фреймворка. Как и в каком виде оформить результаты? Процесс полноценного аудита весьма трудоемкий и запускается при наличии веской цели, например при необходимости оценки состояния разработки за большой период времени или для обоснования новых трат и увеличения бюджета для руководства. В первом случае это немалый список ОРД, а во втором — наглядный расчет метрик, трудозатрат и рисков на основе полученных данных.

Формализация процессов и проект регламента. Процесс аудита подразумевает не только опрос команды разработки и заполнение excel-документа галочками «да»/«нет». Необходимо знать не только о наличии описания процесса безопасной разработки, но и о том, что процесс работает. Как в команде разработки, так и в команде DevSecOps. Итог подобных действий — сформированный проект регламента процессов безопасной разработки, к которому всегда можно обратиться.

Также это поможет при интеграции новых команд DevSecOps, масштабировании, в случае изменения текущих процессов и сильно упростит работу при сертификации РБПО.

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

К чему стоит стремиться:

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

• сформирован бюджет для новых инструментов и расширения команды;

• есть понимание, какие процессы требуется формализовать и зачем;

• сформирован план добавления новых практик и их масштабирования на команды разработки.

Формализация планов и процессов — неизбежная часть пути на этапе роста и масштабирования команды DevSecOps. И если раньше это было необходимостью только в особо крупных командах для борьбы с растущим хаосом (несколько тысяч разработчиков, огромное количество проектов и необходимых инструментов), то сейчас появляется практический интерес для реализации все новых ГОСТов, для которых наличие регламентов является обязательным.