Из ГОСТ Р 56939–2016 Защита информации. Разработка безопасного программного обеспечения. Общие требования

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

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

Настоящий стандарт можно применять в качестве источника для формирования мер и средств контроля и управления безопасностью программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 27034–1. Настоящий стандарт можно использовать для конкретизации или расширения компонентов доверия из ГОСТ Р ИСО/МЭК 15408–3 [из 1 Область применения ГОСТ Р 56939–2016]

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

• ГОСТ 2.001 Единая система конструкторской документации. Общие положения
• ГОСТ 19.101 Единая система программной документации. Виды программ и программных документов
• ГОСТ 19.201 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
• ГОСТ 19.402 Единая система программной документации. Описание программы
• ГОСТ 19.404 Единая система программной документации. Пояснительная записка. Требования к содержанию и оформлению
• ГОСТ Р ИСО/МЭК 15408–1 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель
• ГОСТ Р ИСО/МЭК 15408–2 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности
• ГОСТ Р ИСО/МЭК 15408–3 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности
• ГОСТ Р ИСО 10007 Менеджмент организации. Руководящие указания по управлению конфигурацией
• ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
• ГОСТ Р ИСО/МЭК 27001 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования
• ГОСТ Р ИСО/МЭК 27034–1 Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия

[из 2 Нормативные ссылки ГОСТ Р 56939–2016]

В настоящем стандарте применены следующие термины с соответствующими определениями:

4.1 Предотвращение появления и устранение уязвимостей программы может быть достигнуто путем реализации разработчиком программного обеспечения (ПО) мер по разработке безопасного ПО в процессах жизненного цикла ПО, установленных ГОСТ Р ИСО/МЭК 12207 [из 4.1 ГОСТ Р 56939–2016]

4.10 Разработчик ПО должен создать руководство по разработке безопасного ПО, содержащее:

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

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

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

[из 4.10 ГОСТ Р 56939–2016]

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

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

[из 4.11 ГОСТ Р 56939–2016]

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

• на организацию работ по созданию безопасного ПО, выполняемых в рамках процессов жизненного цикла ПО;
• подтверждение соответствия требованиям настоящего стандарта.

В перечень документации разработчика ПО могут входить эксплуатационные документы, а также документ:

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

Требования к содержанию указанных документов представлены в разделе 5. Требований к количеству и номенклатуре документов не предъявляется. Разработчик ПО может скомпоновать необходимые сведения по своему усмотрению. Документы могут быть выполнены в виде бумажных или электронных документов. Для организации работ, выполняемых в рамках процесса эксплуатации ПО, разработчик ПО должен передать пользователю эксплуатационные документы [из 4.12 ГОСТ Р 56939–2016]

4.13 Разработчик ПО должен определить и документировать политику информационной безопасности в соответствии с ГОСТ Р ИСО/МЭК 27001. Разработчик ПО должен соблюдать в своей деятельности, связанной с разработкой безопасного ПО, требования, установленные в политике информационной безопасности организации [из 4.13 ГОСТ Р 56939–2016]

4.2 Меры по разработке безопасного ПО, представленные в настоящем стандарте, выражены в форме требования, рекомендации или допустимого действия, предназначенных для поддержки достижения результатов реализации мер. Для этой цели в настоящем стандарте используют вспомогательные глаголы «должен», «следует» и «может», чтобы подчеркнуть различие между разными формами требований к реализации мер. Глагол «должен» использован для выражения условия, требуемого для соответствия, «следует» — для выражения рекомендации среди других возможностей, «может» — для того, чтобы отразить направление допустимых действий в пределах ограничений настоящего стандарта [из 4.2 ГОСТ Р 56939–2016]