Обзор ГОСТа по безопасной разработке ПО

Привет! Меня зовут Женя Шмидт, в Selectel я менеджер продуктов информационной безопасности. В последнее время коллеги — разработчики, DevOps, тестировщики и продакт-менеджеры — все чаще спрашивают меня про ГОСТ «Разработка безопасного программного обеспечения». Хочу рассказать об этом стандарте не только им, но и всем остальным сотрудникам IT-компаний. Документ будет интересен всем, кто так или иначе связан с разработкой ПО. 
В статье расскажу, кого коснется ГОСТ, на что повлияет и как подготовиться к соблюдению требований, перечисленных в нем.

Предыстория. Почему появился этот документ

26 апреля 2024 года вышло информационное сообщение ФСТЭК России № 240/24/1958, в котором утвердили порядок сертификации процессов безопасной разработки программного обеспечения средств защиты информации. В этом документе упоминается ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Стандарт рассматривает общие определения и положения, описывающие разработку безопасного ПО. 

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

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

Кого коснется новый ГОСТ

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

Документ особенно важен разработчикам средств защиты информации, которые проходят сертификацию ФСТЭК. Продуктами могут быть:

• антивирусные средства,
• межсетевые экраны,
• средства доверенной загрузки,
• платформы виртуализации,
• операционные системы.

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

Наличие сертификата существенно сокращает time-to-market новой версии ПО для применения в тех сферах, где необходимо использовать сертифицированные средства. Речь о государственных информационных системах и об объектах критической информационной инфраструктуры.

Обзор ГОСТа

Стандарт описывает 25 процессов разработки, от планирования процессов до вывода ПО из эксплуатации. Для каждого этапа в стандарте описаны цели, задачи и свидетельства выполнения. Рассмотрим каждый из них.

1. Планирование процессов разработки безопасного программного обеспечения

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

2. Обучение сотрудников

Конечно, необходимо организовать обучение сотрудников безопасной разработке и использованию необходимых инструментов. Для этого нужно выполнить несколько действий.

• Проанализировать существующие обучающие материалы, курсы и тренинги.
• Разработать план обучения с учетом потребностей разработчика в части его компетенций и используемых технологий.
• Провести обучение.
• Завести журнал учета обучения.
• Определить критерии пересмотра программ обучения в случае, если что-то в процессах меняется. Например, если вы решили перейти на другой язык разработки. 
• Периодически повышать осведомленность о возможных новых угрозах, уязвимостях и механизмах недопущения или минимизации последствий их реализации. Это тоже фиксируется в журнале обучения.

3. Формирование и предъявление требований безопасности к программному обеспечению

На этом шаге нужно разработать процедуру управления требованиями безопасности и сформировать сам набор требований безопасности. Отдельно в стандарте указано, что требования должны однозначно толковаться и их набор должен быть непротиворечивым — потребуется завести журнал предъявленных требований. Набор требований должен пересматриваться периодически (не реже раза в год) или при наступлении определенных событий.

4. Управление конфигурацией программного обеспечения

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

5. Управление недостатками ПО и запросами на его изменение 

Разработайте регламенты управления недостатками и запросами на изменение ПО. Контролируйте реализацию изменений и запросов изменений в рамках жизненного цикла продукта.

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

6. Разработка, уточнение и анализ архитектуры программного обеспечения

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

7. Моделирование угроз и разработка описания поверхности атаки

Про моделирование угроз можно писать отдельную статью. Однако важно знать, что на этом этапе формируются: 

• модель угроз с указанием перечня мер по нейтрализации для каждого продукта;
• описание поверхности атаки для каждого продукта — иногда включают в состав модели угроз;
• перечень подсистем или модулей ПО, подлежащих дополнительному дальнейшему анализу с точки зрения безопасности — например, fuzzing-тестированию;
• уточнения для модели угроз и поверхности атаки на основе сканирования интерфейсов ПО. 

8. Формирование и поддержание в актуальном состоянии правил кодирования

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

9. Экспертиза исходного кода

В стандарте не сказано, кто должен выполнять экспертизу исходного кода — внутренний эксперт или внешний приглашенный. Необходимо разработать регламент и проводить экспертизу с использованием автоматизации, которая интегрирована с системой контроля версий.

10. Статический анализ исходного кода

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

11. Динамический анализ кода программы

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

12. Использование безопасной системы сборки программного обеспечения

Разработайте регламент безопасной сборки ПО и зафиксируйте информацию о сборочной среде. Выполняйте рекомендации вендора по безопасному использованию инструмента.

13. Обеспечение безопасности сборочной среды программного обеспечения

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

14. Обеспечение целостности кода при разработке программного обеспечения и управление доступом

Разработайте регламент доступа к исходному коду. Опишите обязанности сотрудников, их права и роли при разработке, правила хранения и резервного копирования исходников, внесения изменений в исходный код. Опишите процедуру контроля целостности исходного кода.

15. Обеспечение безопасности используемых секретов

Стандарт предписывает использовать систему управления секретами: нельзя хранить пароли прямо в коде приложения для доступа к другим сервисам. Для этого должна использоваться система управления секретами — такая есть в Selectel.

16. Использование инструментов композиционного анализа

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

17. Проверка кода на предмет внедрения вредоносного кода через цепочки поставок

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

18. Функциональное тестирование

Разработайте план функционального тестирования и организуйте процесс с регистрацией хода проведения и фиксацией результатов. Исправьте ошибки, если они возникнут.

19. Нефункциональное тестирование

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

20. Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения

Тоже относится к процессам контроля качества ПО. Разработайте регламент приемки и обеспечения целостности ПО, передаваемого пользователям.

21. Безопасная доставка программного обеспечения пользователям

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

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

Организуйте работу технической поддержки и разработайте для нее свою документацию. Организуйте процесс обучения специалистов работе с ПО, его особенностями установки и функционирования, ограничениям и указаниям по эксплуатации.

23. Обеспечение реагирования на информацию об уязвимостях

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

24. Поиск уязвимостей в программном обеспечении при эксплуатации

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

25. Обеспечение безопасности при выводе программного обеспечения из эксплуатации

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

Конечно, такой подход не для всех. Он не подходит для сервисов, где скорость разработки и адаптация к изменениям требований стоит на первом месте. Тем не менее, я бы посоветовал всем, кто разрабатывает любое пользовательское ПО, пройтись по списку и задуматься над тем, есть ли у вас что-то подобное.

С чего начать подготовку к сертификации

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

1. Ознакомьтесь со стандартом.

2. Оцените текущее состояние разработки. Проведите внутренний аудит, сравните процессы с требованиями стандарта и выявите слабые места. Составьте таблицу из 25 строк (по количеству пунктов в стандарте) и пройдитесь по каждому. Отметьте, что полностью реализовано в соответствии с требованиями, что — с необходимостью доработок, а что не сделано вообще.

3. Разработайте и внедрите необходимые процессы. Отталкиваясь от результата внутреннего аудита, доработайте и создайте с нуля все, что необходимо. Ознакомьте сотрудников с новыми вводными.

4. Создайте документацию. Для процессов — и новых для компании, и уже существующих — разработайте документацию, включая политики, инструкции и отчеты.  

5. Проведите внутренний аудит. После внесения изменений повторите второй пункт.

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

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

В процессе аудита вам придется предоставлять необходимую информацию и документацию, отвечать на вопросы и устранять на ходу выявленные замечания.

8. Получите сертификат. После успешного прохождения аудита вы получите сертификат. Но расслабляться рано!

Регулярно проводите внутренние аудиты и поддерживайте все процессы на уровне соответствия стандарту в дальнейшем. Следите за изменениями в стандарте и внедряйте изменения на их основе или на основе обратной связи.

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

Selectel и безопасная разработка

Дело в том, что Selectel проходит большое количество внутренних и внешних аудитов по информационной безопасности. Это и аудит СМИБ по ISO 27001/27017/27018, и сертификация PCI DSS, и оценка соответствия стандарту для банковских (финансовых организаций) ГОСТ 57580.1-2017. Проведение этих мероприятий требует от нас разработки документации и регламентов, перестраивания процессов для успешного прохождения аудита. Многие пункты из требований пересекаются с пунктами из стандарта ГОСТа. 

Деталей раскрывать не могу, но из 25 процессов в Selectel 20 уже соответствуют, 2 в процессе реализации и 3 для нас не актуальны. Оцениваем, что при необходимости получения сертификата мы сможем успешно пройти аудит без серьезных неудобств для разработки и бизнеса.

Заключение

Основные вызовы ГОСТа

1. Документооборот. 25 процессов — это сотни страниц документации. Для Agile-команд такое новшество, безусловно, будет сложно принять.

2. Затраты. Обучение, инструменты (SAST/DAST), аудиты — для малого бизнеса или стартапа это может оказаться большой статьей расходов, которая ставит рентабельность проекта под вопрос.

3. Регуляторные риски. Требования заказчиков в части соответствия могут ужесточаться, а стандарт может обновляться. Даже если к вам сейчас не предъявляются требования по сертификации, все может измениться.

Совет: даже если сертификация вам пока не нужна, используйте ГОСТ как чек-лист для улучшения процессов. Безопасность ПО — это не просто бумаги, а культура, которую стоит развивать уже сегодня.