Information protection. Secure software development. General requirements
Предисловие
1 Разработан Федеральной службой по техническому и экспортному контролю (ФСТЭК России), Акционерным обществом "Лаборатория Касперского" (АО "Лаборатория Касперского"), Федеральным государственным бюджетным учреждением науки Институт системного программирования им. В.П. Иванникова Российской академии наук (ИСП РАН), Акционерным обществом "Информационные технологии и коммуникационные системы" (АО "ИнфоТеКС"), Акционерным обществом "Позитив Текнолоджиз" (АО "Позитив Текнолоджиз"), Обществом с ограниченной ответственностью "РусБИТех-Астра" (ООО "РусБИТех-Астра"), Акционерным обществом "Сбербанк-Технологии" (АО "СберТех"), Обществом с ограниченной ответственностью Научно-технический центр "Фобос-НТ" (ООО НТЦ "Фобос-НТ"), Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ"), Акционерным обществом "Научно-производственное объединение "Эшелон" (АО НПО "Эшелон")
2 Внесен Техническим комитетом по стандартизации ТК 362 "Защита информации"
3 Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 24 октября 2024 г. N 1504-ст
4 Взамен ГОСТ Р 56939-2016
Введение
Настоящий стандарт направлен на достижение целей, связанных с предотвращением появления, выявлением и устранением недостатков, в том числе уязвимостей, в программном обеспечении, и содержит общие требования, предъявляемые к разработчикам и производителям программного обеспечения при реализации процессов разработки безопасного программного обеспечения.
1 Область применения
Настоящий стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного программного обеспечения (ПО) и устранением выявленных недостатков, в том числе уязвимостей, ПО.
Настоящий стандарт предназначен для разработчиков и производителей ПО, а также для организаций, выполняющих оценку соответствия процессов разработки ПО положениям настоящего стандарта.
П р и м е ч а н и е - В настоящем стандарте разработчики и производители ПО обозначены термином "разработчик(и)".
Настоящий стандарт предусматривает применение в комплексе с другими национальными стандартами по разработке безопасного ПО, в которых раскрываются вопросы внедрения и оценки соответствия положениям настоящего стандарта, задаются требования к отдельным технологиям, применяемым в процессах разработки.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
ГОСТ Р 50922 Защита информации. Основные термины и определения
ГОСТ Р 58412 Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения
П р и м е ч а н и е - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящем стандарте применены термины по ГОСТ Р 50922, а также следующие термины с соответствующими определениями:
3.1 безопасное программное обеспечение: Программное обеспечение, разработанное в ходе реализации совокупности процессов (мер), направленных на предотвращение появления и устранение недостатков программы.
3.2 динамический анализ кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода.
3.3 документация разработчика программного обеспечения: Совокупность программных и иных документов, предназначенных для организации и проведения работ по созданию программного обеспечения и/или подтверждения соответствия требованиям настоящего стандарта.
П р и м е ч а н и е - К программным относятся документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ. К иным документам относятся документы, не относящиеся к программным, и содержащие сведения, подтверждающие соответствие требованиям настоящего стандарта.
3.4
|
инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
[ГОСТ Р 51904-2002, пункт 3.17]
|
3.5 интерфейс программного обеспечения: Способ взаимодействия между программами или между программами и пользователями.
3.6 компонент программного обеспечения: Составная часть (программный модуль) программного обеспечения, выполняющая определенную функцию.
3.7
|
компьютерная атака: Целенаправленное несанкционированное воздействие на информацию, на ресурс автоматизированной информационной системы или получение несанкционированного доступа к ним с применением программных или программно-аппаратных средств.
[ГОСТ Р 51275-2006, пункт 3.11]
|
3.8 недостаток программы: Любое несоответствие программы заданным требованиям или любая ошибка, допущенная в ходе проектирования или реализации программы, которая в случае ее неисправления может являться причиной невозможности выполнения требуемых функциональных возможностей или уязвимости программы.
3.9
|
поверхность атаки: Множество подпрограмм (функций, модулей) программного обеспечения, обрабатывающих данные, поступающие посредством интерфейсов, напрямую или косвенно подверженных риску атаки.
[адаптировано из ГОСТ Р 56498-2015, пункт 3.1.7]
|
3.10 пользователь (программного обеспечения): Лицо, применяющее программное обеспечение.
3.11
|
программа: Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
[ГОСТ 19781-90, статья 1]
|
3.12
|
программное обеспечение: Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.
[ГОСТ 19781-90, статья 2]
|
3.13
|
программный модуль (модуль программного обеспечения): Программа или функционально завершенный фрагмент программы, предназначенный для хранения, трансляции, объединения с другими программными модулями и загрузки в оперативную память.
[ГОСТ 19781-90, статья 15]
|
3.14 сборка программного обеспечения: Процесс построения из исходного кода программ программных модулей, готовых к выполнению или интерпретации, и/или библиотек.
3.15
|
сборочная среда: Совокупность программных и аппаратных средств, служб связи, интерфейсов, форматов данных, протоколов, стандартов, обеспечивающих преобразование исходного кода программ в программные модули в соответствии с представленными метаданными и с учетом зависимостей программного модуля.
[Адаптировано из ГОСТ Р 54593-2011, пункт 3.13]
|
3.16 система сборки программного обеспечения: Совокупность программных средств и конфигурационных файлов, которая позволяет выполнить сборку конкретного экземпляра конкретной программы.
3.17
|
среда разработки программного обеспечения: Интегрированная система, включающая в себя аппаратные средства, программное обеспечение, программно-аппаратные средства, процедуры и документы, необходимые для разработки программного обеспечения.
[ГОСТ Р 51904-2002, пункт 3.62]
|
3.18 статический анализ исходного кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе исходных текстов программы с использованием специализированных инструментальных средств (статических анализаторов) в режиме, не предусматривающем исполнения кода, и выполняемый для определения свойств программы; в частности, статический анализ применяется для выявления потенциальных ошибок в программе.
П р и м е ч а н и е - Термины "анализ исходных текстов" и "анализ исходного кода" взаимозаменяемы в силу устоявшейся профессиональной терминологии.
3.19 управление конфигурацией программного обеспечения: Скоординированные действия, направленные на формирование и контроль конфигурации программного обеспечения.
3.20 уязвимость программы: Недостаток программы, который может быть использован для реализации угроз безопасности информации.
П р и м е ч а н и е - Уязвимость программы может быть результатом ее разработки без учета требований по обеспечению безопасности информации, вследствие наличия ошибок проектирования или реализации или в результате применения небезопасных инструментальных средств и языков программирования, имеющих ошибки проектирования, реализации или конфигурирования.
3.21 функциональное тестирование программы: Вид работ по исследованию программы, направленный на выявление отличий между ее реально существующими и требуемыми свойствами.
3.22 фаззинг-тестирование программы: Вид работ по исследованию программы, основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы.
3.23 экспертиза исходного кода программы: Вид работ по выявлению недостатков программы в исходном коде программы, направленный на оценку ее свойств и основанный на анализе исходного кода программы в режиме, не предусматривающем реального выполнения кода.
4 Общие требования к разработке безопасного программного обеспечения
4.1 Основной целью разработки безопасного ПО является:
- выявление недостатков, в том числе уязвимостей, в разрабатываемом ПО;
- снижение количества недостатков, в том числе уязвимостей ПО;
- снижение ущерба от невыявленных уязвимостей ПО;
- оперативное устранение выявляемых уязвимостей в ПО.
4.2 В настоящем стандарте общие требования к разработке безопасного ПО представлены в виде описания процессов, реализация которых направлена на достижение цели разработки безопасного ПО.
4.3 Поскольку модель жизненного цикла ПО зависит от специфики, масштаба, сложности ПО и условий, в которых ПО создается и функционирует, приведенные в настоящем стандарте процессы намеренно не связываются с конкретной моделью жизненного цикла ПО. По тексту стандарта процессы могут быть соотнесены с обобщенными этапами жизненного цикла ПО (например, с этапом эксплуатации), что дает разработчику гибкость реализации процессов и используемых подходов, таких как изложенных в ГОСТ Р ИСО/МЭК 12207.
4.4 Методика оценки соответствия реализации процессов разработки безопасного ПО установленным настоящим стандартом требованиям является предметом рассмотрения отдельного национального стандарта.
4.5 Внедрение и реализация процессов разработки безопасного ПО подразумевают непосредственное участие руководства разработчика и выделение необходимых ресурсов.
4.6 Процессы разработки безопасного ПО реализуются комплексом организационных и технических мероприятий.
4.7 Условия реализации процессов разработки безопасного ПО выражены в форме следующих понятий: требование, рекомендация или допустимое действие. С целью подчеркнуть различие между разными формами условий для реализации процессов разработки безопасного ПО в настоящем стандарте используются вспомогательные глаголы "должен", "следует" "рекомендуется" и "может". Глаголы "должен" и "следует" - для выражения условия, требуемого для соответствия требованию; "рекомендуется" - для выражения рекомендации по реализации, "может" - для того чтобы отразить возможные направления допустимых действий.
4.8 Процессы разработки безопасного ПО изложены в виде следующей структуры: наименование процесса (наименование соответствующего подраздела раздела 5), цели, требования к реализации, артефакты реализации требований (пункты соответствующих подразделов).
4.9 Пункт "Цели" включает формулировки целей реализации процесса разработки безопасного ПО.
4.10 Пункт "Требования к реализации" включает формулировки требований к реализации процесса разработки безопасного ПО.
4.11 Пункт "Артефакты реализации требований" включает формулировки наименования артефактов, подтверждающих выполнение требований к реализации процессов разработки безопасного ПО, и их содержание. Под артефактами реализации требований в настоящем стандарте понимается любая информация (документы, отчеты, файлы, журналы, результаты работы инструментов, процессов), сохраненная в любом виде (электронном, физическом), на основании которой возможно подтвердить реализацию соответствующих требований.
4.12 Наиболее общими для большинства рассматриваемых процессов артефактами реализации требований разработчика в настоящем стандарте являются регламенты. В общем случае регламент осуществления процесса разработки безопасного ПО должен содержать информацию об обязанностях сотрудников и их ролях при реализации соответствующих процессов, а также информацию, непосредственно относящуюся к особенностям реализации процесса. Требований к оформлению регламентов не предъявляется. Регламенты, относящиеся к различным процессам разработки безопасного ПО, могут быть оформлены как самостоятельные документы в электронном или физическом виде или объединены в рамках общего документа (например, в виде руководства по разработке безопасного ПО).
4.13 При разработке ПО средой разработки ПО должны быть обеспечены контроль версий разрабатываемого ПО, непрерывная интеграция разрабатываемого ПО, управление задачами, в том числе по отслеживанию ошибок в коде ПО. Процессы разработки безопасного ПО необходимо интегрировать с применяемыми в среде разработки ПО системами в целях обеспечения регулярности и своевременности проверок кода, прослеживаемости устранения выявленных ошибок.
П р и м е ч а н и е - Под непрерывной интеграцией здесь понимается автоматизация внесений изменений кода ПО (модулей ПО, компонентов ПО) от нескольких разработчиков в единый проект ПО.
4.14 Конкретная совокупность процессов разработки безопасного ПО, подлежащая реализации разработчиком ПО, определяется требованиями нормативных правовых актов, национальных и отраслевых стандартов, технических заданий на выполнение научно-исследовательских и опытно-конструкторских работ, иными документами. В случае, когда в соответствующих документах определена необходимость соответствия настоящему стандарту, обязательной реализации подлежат все требования стандарта, за исключением рекомендуемых к реализации требований, в формулировках таких требований используются вспомогательные глаголы "рекомендуется" и "может".
4.15 Предъявление требований настоящего стандарта к ПО, разрабатываемому в рамках научно-исследовательских и опытно-конструкторских работ, возможно только в форме явного перечисления в техническом задании процессов, подлежащих реализации. Допускается предъявлять требования настоящего стандарта не в полном объеме, указывать условия применимости каждого из реализуемых процессов, требований к ним, состава и содержания артефактов реализации требований.
4.16 В приложении А в качестве справочной информации приведено описание инициализации процессов разработки безопасного ПО. Оценка указанных процессов не является обязательной при внешнем контроле реализации (аудите).
4.17 В ходе реализации процессов разработки безопасного ПО должны быть реализованы меры по защите информации, относящейся к этим процессам, - разграничение доступа к результатам исследований и тестирования, обеспечение защищенного хранения соответствующей информации и антивирусная защита. Меры защиты информации для процессов разработки безопасного ПО могут быть включены в регламенты реализации соответствующих процессов разработки безопасного ПО или содержаться в отдельном документе разработчика.
5 Процессы разработки безопасного программного обеспечения
5.1 Планирование процессов разработки безопасного программного обеспечения
5.1.1 Цели
5.1.1.1 Обеспечение потребностей в ресурсах, необходимых для реализации процессов разработки безопасного ПО.
5.1.1.2 Подготовка и планирование внедрения и улучшения процессов разработки безопасного ПО.
5.1.1.3 Определение области применения процессов разработки безопасного ПО.
5.1.2 Требования к реализации
5.1.2.1 Выполнять периодический анализ текущего статуса реализации процессов разработки безопасного ПО.
5.1.2.2 Выполнять периодический анализ потребностей в ресурсах, необходимых для реализации процессов разработки безопасного ПО.
5.1.2.3 Разрабатывать план развития процессов разработки безопасного ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.1.3.1, 5.1.3.2.
5.1.2.4 Разрабатывать план реализации процессов разработки безопасного ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.1.3.1, 5.1.3.2.
5.1.2.5 Определять область применения процессов разработки безопасного ПО.
5.1.3 Артефакты реализации требований
5.1.3.1 Результаты анализа текущего статуса реализации процессов разработки безопасного ПО должны содержать следующие сведения:
- перечень процессов разработки безопасного ПО, реализованных и не реализованных разработчиком;
- результаты определения достаточности и соответствия процессов разработки безопасного ПО, реализованных разработчиком, положениям настоящего стандарта и иным стандартам, содержащим требования к разработке безопасного ПО, используемым инструментам и технологиям.
5.1.3.2 Результаты анализа потребностей в ресурсах, необходимых для реализации процессов разработки безопасного ПО, могут содержать оценочные показатели в материальных и людских ресурсах для каждого реализуемого или планируемого к реализации процесса разработки безопасного ПО.
5.1.3.3 План развития процессов разработки безопасного ПО должен содержать порядок (очередность) внедрения процессов разработки безопасного ПО с учетом приоритетов разработчика и имеющихся ресурсов, планируемые изменения в организационно-штатной структуре разработчика, планируемые закупки необходимых инструментов, затраты на обучение и др.
П р и м е ч а н и е - План развития процессов разработки безопасного ПО может разрабатываться и быть представлен в системе управления задачами.
5.1.3.4 План реализации процессов разработки безопасного ПО должен содержать цели, сроки и этапы внедрения процессов разработки безопасного ПО; перечень необходимых ресурсов; информацию об ответственных за внедрение процессов сотрудниках.
П р и м е ч а н и е - План реализации процессов разработки безопасного ПО может разрабатываться и быть представлен в системе управления задачами.
5.1.3.5 Описание области применения процессов разработки безопасного ПО должно содержать состав ПО (версии, модули, компоненты, функциональные подсистемы и т.п.), в отношении которого должны быть реализованы процессы разработки безопасного ПО, с обоснованием выбора указанного состава ПО.
5.2 Обучение сотрудников
П р и м е ч а н и е - В данном подразделе под обучением понимается совокупность методов и подходов, направленных на постоянное повышение квалификации, развитие профессиональных навыков, знаний и компетенций сотрудников разработчика, реализуемых как с привлечением сторонних организаций, так и самим разработчиком.
5.2.1 Цели
5.2.1.1 Получение актуальной информации о существующих (доступных для анализа) практиках, документах, обучающих курсах и тренингах по разработке безопасного ПО.
5.2.1.2 Организация обучения сотрудников типовым практикам разработки безопасного ПО с учетом актуальных потребностей.
5.2.1.3 Создание условий для снижения количества возможных типовых ошибок и уязвимостей в разрабатываемом ПО.
5.2.2 Требования к реализации
5.2.2.1 Проводить анализ существующих (доступных для анализа) практик, документов, обучающих курсов и тренингов по разработке безопасного ПО.
Входными данными требования к реализации являются существующие (доступные для анализа) практики, документы, обучающие курсы и тренинги по разработке безопасного ПО.
5.2.2.2 Разрабатывать план обучения с учетом потребностей разработчика в части используемых средств и технологий разработки.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.2.3.1.
5.2.2.3 Проводить обучение сотрудников.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.2.3.2.
5.2.2.4 Вести учет обучения сотрудников.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.2.3.2, 5.2.3.3, 5.2.3.6.
5.2.2.5 Определить критерии пересмотра программ обучения (курсов, тренингов и т.п.).
5.2.2.6 Повышать осведомленность сотрудников разработчика о возможных типовых угрозах, ошибках и уязвимостях в разрабатываемом ПО, механизмах их недопущения или минимизации вероятности их возникновения, порядке сопровождения ПО и управления жизненным циклом.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.2.3.1.
5.2.3 Артефакты реализации требований
5.2.3.1 Результаты анализа существующих (доступных для анализа) практик, документов, обучающих курсов и тренингов по разработке безопасного ПО с точки зрения их применимости для обучения сотрудников разработчика.
5.2.3.2 План обучения, включающий:
- список сотрудников, направляемых на обучение;
- сроки прохождения обучения;
- наименование программы (курса, тренинга) обучения;
- ожидаемый результат обучения.
5.2.3.3 Артефакты реализации требований, подтверждающие прохождение обучения, включают (в зависимости от учебной программы, курса) свидетельства, дипломы, отчеты обучающих платформ и иные документы и материалы, подтверждающие прохождение сотрудником обучения.
5.2.3.4 Артефакты реализации требований, подтверждающие осуществление учета обучения сотрудников, должны содержать информацию о сотрудниках, прошедших обучение, пройденных программах (курсах) и результатах прохождения обучения.
5.2.3.5 Критерии необходимости пересмотра программ обучения (курсов, тренингов и т.п.) должны содержать информацию о периодичности пересмотра (уточнения) программ обучения (курсов, тренингов и т.п.) или о событиях, при наступлении которых необходимо изменение программ обучения (курсов, тренингов и т.п.).
5.2.3.6 Артефакты реализации требований, подтверждающие осуществление повышения осведомленности сотрудников, должны содержать информацию о проведенных мероприятиях по повышению осведомленности сотрудников о возможных типовых угрозах, ошибках и уязвимостях в разрабатываемом ПО, механизмах их недопущения или минимизации вероятности их возникновения, порядке сопровождения ПО и управления жизненным циклом, а также о сотрудниках (подразделениях), для которых проводились мероприятия по повышению осведомленности.
5.3 Формирование и предъявление требований безопасности к программному обеспечению
5.3.1 Цели
5.3.1.1 Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО.
5.3.2 Требования к реализации
5.3.2.1 Разработать регламент управления требованиями безопасности ПО.
5.3.2.2 Предъявлять к ПО требования безопасности.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.1.
5.3.2.3 Вести учет предъявленных требований безопасности и контроль однозначности трактования и непротиворечивости набора требований безопасности ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.2.
П р и м е ч а н и е - Критерии однозначности трактования и непротиворечивости набора требований безопасности ПО определяются разработчиком экспертным методом.
5.3.2.4 Осуществлять пересмотр набора требований безопасности на основе выполнения критериев пересмотра - с установленной периодичностью или при наступлении определенных событий.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.1, 5.3.3.2.
5.3.3 Артефакты реализации требований
5.3.3.1 Регламент управления требованиями безопасности ПО должен включать следующие положения:
- порядок предъявления требований безопасности ПО;
- порядок предоставления требований безопасности ПО исполнителям;
- порядок отслеживания процесса предоставления, получения и выполнения требований безопасности ПО;
- критерии пересмотра требований безопасности ПО (периодически, при наступлении определенных событий).
5.3.3.2 Набор требований безопасности ПО должен содержать следующую информацию:
- идентификатор требования безопасности ПО;
- формулировку требования безопасности ПО;
- дату предъявления требований безопасности ПО;
- приоритет/важность требования безопасности ПО;
- предполагаемые сроки реализации;
- сведения о сотрудниках (подразделениях), предъявивших требования;
- сведения о сотрудниках (подразделениях), принявших требования к реализации.
5.3.3.3 Артефакты реализации требований, подтверждающие осуществление учета предъявленных требований безопасности ПО, должны включать, как минимум, следующую информацию:
- сведения о принятии требований к реализации, подтверждающие однозначность трактования и непротиворечивость набора требований безопасности ПО;
- текущий статус реализации требований;
- сведения об изменениях статуса реализации предъявленных требований безопасности ПО;
- сведения об изменениях предъявленных требований безопасности ПО.
П р и м е ч а н и е - Управление требованиями безопасности ПО рекомендуется осуществлять с использованием средств автоматизации (например, системы управления изменениями, системы управления задачами и т.п.).
5.3.3.4 Набор требований безопасности ПО, уточненный по результатам выполнения требований 5.3.2.4, должен содержать информацию об особенностях реализации требований безопасности ПО в процессе разработки ПО, принятых решениях по корректировкам требований безопасности ПО в процессе разработки.
5.4 Управление конфигурацией программного обеспечения
5.4.1 Цели
5.4.1.1 Осуществление уникальной идентификации ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
5.4.1.2 Контроль реализации изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
5.4.2 Требования к реализации
5.4.2.1 Разработать регламент управления конфигурацией в рамках жизненного цикла ПО.
5.4.2.2 Определить перечень элементов конфигурации, подлежащих отслеживанию в рамках управления конфигурацией ПО.
5.4.2.3 Контролировать реализацию изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).
5.4.3 Артефакты реализации требований
5.4.3.1 Регламент управления конфигурацией ПО должен содержать:
- порядок формирования перечня элементов ПО (компонентов, модулей и т.п.), документации на ПО, подлежащих отслеживанию в рамках жизненного цикла ПО;
- порядок идентификации ПО (версий ПО, модулей ПО), документации для отслеживаемых элементов.
5.4.3.2 Перечень элементов конфигурации, подлежащих отслеживанию в рамках управления конфигурацией ПО.
5.4.3.3 Артефакты реализации требований, подтверждающие реализацию управления изменениями ПО, документации на ПО в рамках управления конфигурацией ПО, должны отображать факты изменения ПО (модулей ПО), документации на ПО.
5.5 Управление недостатками и запросами на изменение программного обеспечения
5.5.1 Цели
5.5.1.1 Обеспечение управления недостатками ПО.
5.5.1.2 Обеспечение управления запросами на изменение ПО.
П р и м е ч а н и е - Управление недостатками и запросами на изменение ПО способствует систематическому устранению ошибок программирования, отклонений от заданных требований и корректировке требований в необходимых случаях путем осуществления запросов на изменение ПО - предложений о добавлении, модификации или удалении каких-либо элементов (модулей, компонентов, функциональных возможностей) ПО.
5.5.2 Требования к реализации
5.5.2.1 Разработать регламент управления недостатками ПО.
5.5.2.2 Разработать регламент управления запросами на изменение ПО.
5.5.2.3 Контролировать реализацию изменений, связанных с недостатками ПО.
5.5.2.4 Контролировать реализацию запросов на изменение в рамках жизненного цикла ПО.
5.5.2.5 Использовать средства автоматизации для управления недостатками и запросами на изменение разрабатываемого ПО.
П р и м е ч а н и е - В качестве средств автоматизации рекомендуется использовать системы управления изменениями, системы управления задачами, системы контроля версий и т.п. При этом рекомендуется обеспечивать взаимосвязь (перекрестные ссылки) между такими системами при исправлении недостатков.
5.5.3 Артефакты реализации требований
5.5.3.1 Регламент управления недостатками ПО должен содержать:
- порядок идентификации недостатков ПО;
- порядок управления недостатками ПО, включающий сведения о действиях, выполняемых при выявлении, устранении, тестировании, принятии решения об окончании работы с недостатком (закрытии недостатка).
5.5.3.2 Регламент управления запросами на изменение ПО должен содержать:
- порядок идентификации запросов на изменение ПО;
- порядок управления запросами на изменение ПО, включающий сведения о действиях, выполняемых при осуществлении запроса на изменение, тестировании, принятии решения о закрытии запроса на изменение.
5.5.3.3 Артефакты реализации требований, подтверждающие реализацию управления недостатками ПО, должны содержать зафиксированные факты изменений, связанных с недостатками, включающие следующую информацию:
- уникальный идентификатор недостатка ПО;
- описание недостатка ПО;
- версию ПО (модуля ПО, компонента ПО), к которому относится недостаток ПО;
- приоритет выполнения действий с недостатком ПО;
- текущий статус обработки изменений, связанных с недостатками ПО.
5.5.3.4 Артефакты реализации требований, подтверждающие реализации управления запросами на изменение ПО, должны содержать следующую информацию:
- уникальный идентификатор запроса на изменение ПО;
- краткую характеристику запроса на изменение ПО;
- версию ПО (модуля ПО, компонента ПО), к которому относится запрос на изменение;
- приоритет выполнения действий с запросом на изменение ПО;
- текущий статус обработки запроса на изменение ПО.
5.6 Разработка, уточнение и анализ архитектуры программного обеспечения
5.6.1 Цели
5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.
5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.
5.6.2 Требования к реализации
5.6.2.1 Определить требования безопасности к принципам проектирования архитектуры ПО, направленным на снижение количества возможных недостатков в разрабатываемом ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.2.
5.6.2.2 Выполнить первичное проектирование архитектуры ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.1, 5.6.3.1.
5.6.2.3 Установить критерии необходимости уточнения архитектуры ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.
5.6.2.4 Выполнять уточнение архитектуры ПО в процессе разработки кода и его изменений с установленной периодичностью или при наступлении определенных событий.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.6.3.3.
5.6.3 Артефакты реализации требований
5.6.3.1 Требования к принципам проектирования архитектуры ПО должны содержать информацию, позволяющую на начальном этапе проектирования ПО получить представление о принятых подходах и принципах проектирования архитектуры ПО (например, инкапсуляция, уникальность, разделение задач, применение заимствованных компонентов и т.п.), в том числе с точки зрения безопасности ("нулевое доверие", "протоколирование событий", "резервное копирование", "формирование перечня недопустимых событий", "приоритетное использование языков с безопасной моделью памяти" и т.п.).
5.6.3.2 Описание архитектуры ПО должно включать, как минимум, следующую информацию:
- назначение ПО и сценарии его использования;
- описание среды функционирования;
- ограничения и указания по применению;
- проект ПО на уровне подсистем (модулей), включающий описание их назначения, структуры, особенностей реализации, применяемых языков программирования, взаимодействия друг с другом и другим ПО с указанием соответствующих интерфейсов, сетевых портов, протоколов.
5.6.3.3 Критерии необходимости уточнения архитектуры ПО должны содержать информацию о периодичности пересмотра (уточнения) архитектуры ПО в процессе разработки ПО или о событиях, при наступлении которых необходимо уточнять архитектуру ПО.
5.6.3.4 Архитектура ПО, уточненная по результатам выполнения требований 5.6.2.4, должна содержать информацию об особенностях реализации ПО в процессе разработки ПО, принятых решениях по корректировкам архитектурных решений в процессе разработки, в том числе связанных с безопасностью, и причинах, их вызвавших.
5.7 Моделирование угроз и разработка описания поверхности атаки
5.7.1 Цели
5.7.1.1 Создание условий для снижения количества недостатков, связанных с особенностями реализации архитектуры ПО и логики его функционирования, выработка мер по нейтрализации угроз безопасности, связанных с особенностями реализации архитектуры ПО.
5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.
5.7.2 Требования к реализации
5.7.2.1 Выполнить первичное моделирование угроз для ПО (разработать модель угроз ПО); для выявленных угроз безопасности информации составить перечень мер по их нейтрализации (снижению вероятности возникновения).
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.
5.7.2.2 Выполнить первичное описание поверхности атаки.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.
5.7.2.3 Сформировать перечень целей (функциональных подсистем, модулей (компонентов) ПО и их интерфейсов) для проведения дальнейших исследований безопасности ПО (например, фаззинг-тестирования) с учетом архитектуры ПО, результатов моделирования угроз и выполнения анализа поверхности атаки.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.
5.7.2.4 Выполнять уточнение модели угроз ПО для изменяемого в ходе разработки ПО кода с установленной периодичностью или при наступлении определенных событий.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.7.3.1, 5.7.3.3, 5.7.3.4.
5.7.2.5 Выполнять уточнение описания поверхности атаки для изменяемого в ходе разработки ПО кода с установленной периодичностью или при наступлении определенных событий.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.7.3.1, 5.7.3.3, 5.7.3.4.
5.7.2.6 При уточнении описания поверхности атаки выполнять анализ поверхности атаки методом идентификации интерфейсов ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.7.3.1, 5.7.3.3, 5.7.3.4.
П р и м е ч а н и е - Используемые методы анализа сетевых интерфейсов способствуют получению информации об узлах сети, именах устройств, IP-адресах, операционных системах, запущенных программах и службах, именах пользователей, группах и открытых портах и могут включать анализ локальных и сетевых интерфейсов взаимодействия пользователя с ПО (модулями ПО, компонентами ПО) и взаимодействий модулей (компонентов) ПО между собой, средой функционирования и внешними объектами при их наличии.
5.7.2.7 Уточнять перечень целей (функциональных подсистем, модулей (компонентов) ПО и их интерфейсов) для проведения дальнейших исследований безопасности ПО (например, фаззинг-тестирования) с учетом уточненной архитектуры ПО, результатов моделирования угроз и выполнения анализа поверхности атаки для разработанного кода ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.7.3.1, 5.7.3.3, 5.7.3.4.
5.7.3 Артефакты реализации требований
5.7.3.1 Модель угроз должна включать совокупность угроз безопасности, актуальных для разрабатываемого ПО.
Каждая угроза безопасности представляется в виде совокупности свойств (характеристик), включающей, как минимум, краткое описание угрозы, предполагаемый объект воздействия и возможные последствия реализации угрозы.
П р и м е ч а н и е - При составлении перечня угроз безопасности и их описания рекомендуется учитывать положения ГОСТ Р 58412, а также угрозы безопасности информации Банка данных угроз безопасности информации ФСТЭК России, других источников (например, методологии STRIDE, Open Web Application Security Project (OWASP), DREAD и пр.). В модели угроз рекомендуется указывать использованную при моделировании методологию, в том числе в случае ее собственной разработки.
5.7.3.2 Перечень мер по нейтрализации (снижению вероятности возникновения) угроз безопасности информации содержит перечень необходимых действий (доработок ПО, иных мер). Перечень мер по нейтрализации (снижению вероятности возникновения) угроз безопасности информации должен быть приоритизирован с точки зрения критичности возможного ущерба от реализации угроз безопасности информации.
5.7.3.3 Описание поверхности атаки должно включать совокупность потенциальных областей воздействия на информационную (автоматизированную) систему с использованием разрабатываемого ПО, которые могут быть использованы нарушителем для проведения компьютерной атаки. Описание поверхности атаки может быть частью модели угроз.
5.7.3.4 Перечень целей должен включать список функциональных подсистем, модулей (компонентов) ПО и их интерфейсов, составляющих поверхность атаки, подлежащих дополнительному анализу с точки зрения безопасности.
5.7.3.5 Модель угроз, уточненная по результатам выполнения требований 5.7.2.4, должна дополнительно (в случае применимости) содержать угрозы безопасности ПО, актуальные для выполненных изменений.
5.7.3.6 Описание поверхности атаки, уточненное по результатам выполнения требований 5.7.2.5, должно включать перечень функциональных подсистем, модулей (компонентов) ПО и их интерфейсов, составляющих поверхность атаки, актуальных для разработанного кода ПО.
5.7.3.7 Перечень целей, уточненный по результатам выполнения требований 5.7.2.7, для проведения дальнейших исследований безопасности ПО должен содержать описание функциональных подсистем, модулей (компонентов) ПО, их интерфейсов, для которых предполагаются дальнейшие исследования в части безопасности при реализации других процессов разработки безопасного ПО.
5.8 Формирование и поддержание в актуальном состоянии правил кодирования
5.8.1 Цели
5.8.1.1 Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.
5.8.2 Требования к реализации
5.8.2.1 Принять и использовать в процессе разработки кода ПО регламент оформления исходного кода и безопасного кодирования для используемых разработчиком языков программирования.
П р и м е ч а н и е - Под безопасным кодированием здесь и далее понимаются практики разработки ПО в соответствии с предъявляемыми в указанном выше регламенте требованиями по безопасности.
5.8.2.2 Учитывать при разработке регламента оформления исходного кода и безопасного кодирования примеры опасных и безопасных конструкций для используемых в ПО языков программирования.
5.8.2.3 Учитывать при разработке регламента оформления исходного кода и безопасного кодирования общепринятые стандарты и рекомендации разработчиков (экспертов, специалистов) для соответствующих языков программирования.
5.8.2.4 При разработке ПО рекомендуется использовать программные средства автоматической проверки правил кодирования.
П р и м е ч а н и е - Допускается реализовывать проверку правил кодирования средствами компиляции или статического анализа.
5.8.3 Артефакты реализации требований
5.8.3.1 Регламент оформления исходного кода и безопасного кодирования должен содержать:
- информацию о способах оформления исходного кода (например, способы выбора наименований переменных, функций, классов и т.п.; стиль отступов при оформлении логических блоков; способы ограничения логических блоков; правила использования пробелов при оформлении логических и арифметических выражений; стиль комментариев и правила документирования кода; ограничения [например, размер строк кода по горизонтали, строк в модуле и т.п.)];
- перечень запрещенных способов кодирования, конструкций и т.п. (например, указание паролей в исходном коде ПО в явном виде, использование "магических чисел" и т.п.);
- примеры опасных и безопасных конструкций для используемых языков программирования;
- область применения правил кодирования;
- порядок проверки выполнения правил кодирования для вносимых изменений в исходный код ПО;
- рекомендации разработчиков языков программирования по использованию стандартов кодирования (языков программирования, в том числе собственной разработки), принятые разработчиком ПО.
5.9 Экспертиза исходного кода
5.9.1 Цели
5.9.1.1 Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.
5.9.2 Требования к реализации
П р и м е ч а н и е - Требования настоящего подраздела затрагивают анализ исходного кода ПО разработчиком, непосредственно не участвовавшем в разработке анализируемого кода ПО, а также анализ кода ПО, для которого отсутствуют инструменты статического анализа или результаты их работы нуждаются в подтверждении.
5.9.2.1 Разработать регламент проведения экспертизы исходного кода ПО.
5.9.2.2 Проводить экспертизу определенных областей кода ПО (в первую очередь для модулей (компонентов) ПО, составляющих поверхность атаки) в соответствии с регламентом проведения экспертизы исходного кода ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.9.3.1.
5.9.2.3 Проводить экспертизу кода рекомендуется с использованием программных средств, автоматизирующих проведение экспертизы и интегрированных с системой контроля версий разрабатываемого ПО.
5.9.3 Артефакты реализации требований
5.9.3.1 Регламент проведения экспертизы исходного кода ПО должен содержать следующие сведения:
- обязанности сотрудников и их роли при проведении экспертизы исходного кода ПО;
- базовые требования к экспертизе (количество участников; области кода, подлежащего экспертизе; используемые инструменты и т.д.);
- описание основных проверок (например, сценариев, шаблонов, чек-листов) проведения экспертизы исходного кода ПО.
5.9.3.2 Результаты экспертизы кода должны содержать следующие сведения:
- информацию о проанализированных модулях (компонентах) ПО;
- перечень необходимых изменений;
- вопросы к частям кода, экспертиза которых затруднена и требует дополнительных разъяснений;
- предложения по улучшению.
5.10 Статический анализ исходного кода
5.10.1 Цели
5.10.1.1 Предотвращение внесения потенциально опасных конструкций и ошибок в ПО, а также использования опасных конструкций и уязвимостей из заимствованного кода.
5.10.2 Требования к реализации
5.10.2.1 Разработать регламент проведения статического анализа исходного кода ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.
5.10.2.2 Определить инструменты статического анализа для каждого используемого в ПО языка программирования.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.10.3.1.
5.10.2.3 Определить конфигурацию и параметры настройки инструментов статического анализа.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.10.3.1, 5.10.3.2.
5.10.2.4 Проводить статический анализ с использованием инструментов статического анализа с регистрацией всех предупреждений о потенциальных ошибках, полученных по результатам работы инструментов статического анализа.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.10.3.1, 5.10.3.2, 5.10.3.3.
5.10.2.5 Осуществлять пересмотр конфигурации и параметров настройки инструментов статического анализа при выполнении установленных событий (изменениях в правилах сборки, применяемых статических анализаторах, получении информации об уязвимостях и т.п.).
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.10.3.1, 5.10.3.2, 5.10.3.3.
5.10.2.6 Осуществлять повторный статический анализ ПО после устранения ранее выявленных ошибок и уязвимостей; внесения изменений в ходе разработки в исходные тексты ПО; изменения используемых версий компиляторов, сред выполнения (для компилируемого в промежуточное представление или интерпретируемого кода), обновлений используемых инструментов статического анализа.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.10.3.1, 5.10.3.2.
5.10.3 Артефакты реализации требований
5.10.3.1 Регламент проведения статического анализа исходного кода ПО должен содержать следующие сведения:
- обязанности сотрудников и их роли при проведении статического анализа;
- критерии выбора инструментов статического анализа;
- критерии выбора ПО (модулей ПО, компонентов ПО, функциональных подсистем ПО), подлежащих проведению статического анализа;
- правила обработки срабатываний средств статического анализа;
- типы и критичность ошибок (уязвимостей), выявляемых статическим анализатором, подлежащих устранению, и приоритеты устранения ошибок (уязвимостей);
- периодичность проведения статического анализа или события, при наступлении которых необходимо выполнять повторный статический анализ;
- критерии пересмотра конфигурации и параметров настройки инструментов статического анализа.
5.10.3.2 Перечень инструментов статического анализа должен включать наименования инструментов статического анализа, их версии и информацию о соответствии используемым языкам программирования.
5.10.3.3 Конфигурации и параметры настройки инструментов статического анализа должны обеспечивать выполнение требований регламента проведения статического анализа в части выявления типов и критичности ошибок (уязвимостей), периодичности проведения статического анализа или событий, при наступлении которых необходимо выполнять повторный статический анализ.
5.10.3.4 Отчеты по результатам проведения статического анализа должны включать:
- срабатывания инструментов статического анализа;
- результаты анализа (разметки) выявленных ошибок (срабатываний статического анализатора).
5.10.3.5 Конфигурации и параметры настройки инструментов статического анализа, уточненные по результатам выполнения требований 5.10.2.5, должны обеспечивать выполнение требований регламента проведения статического анализа в части выполнения критериев их пересмотра.
5.11 Динамический анализ кода программы
5.11.1 Цели
5.11.1.1 Обнаружение недостатков и уязвимостей в коде ПО в процессе его выполнения.
5.11.2 Требования к реализации
5.11.2.1 Разработать регламент проведения динамического анализа кода ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3.
5.11.2.2 Определить инструменты динамического анализа и фаззинг-тестирования, порядок их применения.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3, 5.7.3.4, 5.11.3.1.
5.11.2.3 Определить перечень модулей (компонентов) ПО, которые необходимо подвергнуть динамическому анализу, включая фаззинг-тестирование.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3, 5.7.3.4, 5.11.3.1, 5.11.3.2.
5.11.2.4 Определить сценарии проведения тестирования для каждого исследуемого модуля (компонента) ПО средствами динамического анализа, включая инструменты проведения фаззинг-тестирования.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3, 5.7.3.4, 5.11.3.1, 5.11.3.2, 5.11.3.3.
5.11.2.5 Проводить динамический анализ с использованием инструментов динамического анализа.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.11.3.1, 5.11.3.2, 5.11.3.3, 5.11.3.4.
П р и м е ч а н и е - Используемые методы динамического анализа могут позволять осуществлять динамический анализ кода программы путем подачи заведомо некорректных входных данных, динамического профилирования, путем отладки программы, путем поиска защищаемой информации (в оперативной памяти, других местах среды исполнения кода), путем исследования поведения программы с использованием встраиваемых инструментальных датчиков срабатывания ошибок (санитайзеров) или инструментированных с использованием средств динамического двоичного инструментирования, другими применимыми методами, в том числе определенными соответствующими национальными стандартами.
5.11.2.6 Проводить повторный динамический анализ модулей (компонентов) ПО с целью контроля устранения ошибок.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.11.3.1, 5.11.3.2, 5.11.3.3, 5.11.3.4.
5.11.2.8 При проведении фаззинг-тестирования использовать тестовые коллекции входных данных, подлежащие дальнейшим мутациям, для каждого из подвергаемых фаззинг-тестированию модуля (компонента) ПО (при использовании инструментов выполнения фаззинг-тестирования, использующих коллекции входных данных), вызывающие использование различных функциональных возможностей тестируемого модуля (компонента) ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3, 5.7.3.4, 5.11.3.1, 5.11.3.2, 5.11.3.3, 5.11.3.4.
5.11.2.9 Устранять выявленные в процессе динамического анализа, включая фаззинг-тестирование, ошибки в соответствии с принятыми процедурами устранения найденных средствами динамического анализа ошибок.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.11.3.1, 5.11.3.5, 5.11.3.6.
5.11.3 Артефакты реализации требований
5.11.3.1 Регламент проведения динамического анализа кода ПО должен содержать следующие сведения:
- обязанности сотрудников и их роли при проведении динамического анализа и фаззинг-тестирования;
- критерии выбора инструментов динамического анализа, включая инструменты проведения фаззинг-тестирования;
- критерии выбора методов и способов динамического анализа;
- критерии выбора модулей (компонентов) ПО, которые необходимо подвергнуть динамическому анализу, включая фаззинг-тестирование;
- правила обработки срабатываний средств динамического анализа, требующих обработки (аварийная остановка, зависание и т.п.);
- процедуры устранения найденных средствами динамического анализа ошибок;
- периодичность проведения динамического анализа или события, при наступлении которых необходимо выполнять повторный динамический анализ (критерии проведения повторного динамического анализа);
- периодичность проведения фаззинг-тестирования и критерии его завершения.
5.11.3.2 Перечень инструментов динамического анализа, включая инструменты проведения фаззинг-тестирования, должен включать:
- наименования инструментов динамического анализа, их версии и их соответствие исследуемым модулям (компонентам) ПО;
- параметры эксплуатации инструментов динамического анализа (для платформ, языков программирования и т.п.).
5.11.3.3 Перечень модулей (компонентов) ПО, которые необходимо подвергнуть динамическому анализу, включая фаззинг-тестирование, отвечающий требованиям регламента проведения динамического анализа, должен включать:
- наименование модуля (компонента) ПО;
- идентификатор модуля (компонента) ПО.
5.11.3.4 Сценарии проведения тестирования для каждого исследуемого модуля (компонента) ПО средствами динамического анализа, включая инструменты проведения фаззинг-тестирования, обеспечивающие выполнение требований регламента проведения динамического анализа, должны включать:
- идентификатор модуля (компонента) ПО;
- наименование используемого инструмента;
- параметры настройки инструмента;
- критерии запуска и остановки тестирования.
5.11.3.5 Отчеты по результатам проведения динамического анализа должны включать:
- срабатывания инструментов динамического анализа;
- результаты анализа (обработки) выявленных ошибок (срабатываний динамического анализатора) для определенных регламентом типов ошибок, требующих обработки (аварийная остановка, зависание и т.п.).
5.11.3.6 Отчеты по результатам проведения фаззинг-тестирования должны включать:
- сведения о результатах работы инструментов фаззинг-тестирования (длительность проведения фаззинг-тестирования, количество аварийных завершений работы ПО, количество найденных путей выполнения и др.);
- результаты анализа (обработки) аварийных завершений работы ПО, выявленных при проведении фаззинг-тестирования.
5.12 Использование безопасной системы сборки программного обеспечения
5.12.1 Цели
5.12.1.1 Обеспечение безопасности при сборке ПО, недопущение привнесения в код ошибок, обусловленных небезопасными преобразованиями кода.
5.12.2 Требования к реализации
5.12.2.1 Разработать регламент использования системы безопасной сборки ПО.
5.12.2.2 Для разрабатываемого ПО должна быть зафиксирована информация о системе сборки ПО и сборочной среде.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.12.3.1.
П р и м е ч а н и е - Составлять и актуализировать перечень программных инструментов системы сборки ПО допустимо как вручную, так и средствами композиционного анализа.
5.12.2.3 Обеспечивать выполнение рекомендаций производителя по безопасному использованию инструмента из состава системы сборки ПО (при их наличии).
5.12.3 Артефакты реализации требований
5.12.3.1 Регламент использования системы безопасной сборки ПО должен содержать, как минимум, следующие сведения:
- обязанности сотрудников и их роли при выполнении сборки ПО;
- критерии выбора инструментов сборки ПО;
- критерии приемки результатов сборки;
- порядок регистрации событий, генерируемых инструментами сборки ПО.
5.12.3.2 Информация о сборочной среде должна содержать:
- описание особенностей функционирования сборочной среды;
- перечень программных инструментов, применяемых в системе сборки ПО, их версий и конфигураций.
5.12.3.3 Артефакты реализации требований, подтверждающие соответствие инструмента из состава системы сборки ПО рекомендациям производителя по безопасному использованию, должны содержать перечень выполненных рекомендаций производителя инструмента сборки ПО с указанием конкретных параметров настроек и конфигураций.
5.13 Обеспечение безопасности сборочной среды программного обеспечения
5.13.1 Цели
5.13.1.1 Обеспечение безопасности при сборке ПО, недопущение привнесения в результаты сборки ПО уязвимостей и ошибок со стороны сборочной среды.
5.13.2 Требования к реализации
5.13.2.1 Разработать регламент обеспечения безопасности сборочной среды.
5.13.2.2 Зафиксировать описание ожидаемых результатов сборки ПО, прав доступа к среде сборки ПО и хранилищу результатов сборки ПО и ролей пользователей, участвующих в процессе сборки ПО.
5.13.2.3 Разработать схему сборочной среды.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.13.3.2.
5.13.2.4 Обеспечивать регистрацию всех выполняемых действий при сборке ПО в журналах аудита; журналы аудита должны храниться способом, обеспечивающим их целостность; сроки хранения журналов аудита должны быть зафиксированы в регламенте обеспечения безопасности сборочной среды.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.13.3.1, 5.13.3.2.
5.13.2.5 Обеспечивать хранение результатов сборки ПО в выделенном хранилище - хранилище результатов сборки ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.13.3.1, 5.13.3.2.
5.13.2.6 Обеспечивать повторяемость сборки ПО (если применимо).
П р и м е ч а н и е - Под повторяемостью сборки имеется в виду обеспечение предсказуемости результатов сборок, обеспечение полного бинарного соответствия результатов повторных сборок не требуется.
5.13.2.7 Обеспечивать управление доступом к среде сборки ПО и хранилищу результатов сборки ПО на основе ролей пользователей.
5.13.2.8 Обеспечивать защиту каналов связи с внешними источниками данных для обеспечения конфиденциальности информации, обрабатываемой в сборочной среде.
5.13.3 Артефакты реализации требований
5.13.3.1 Регламент обеспечения безопасности сборочной среды должен содержать, как минимум, следующие сведения:
- обязанности сотрудников и их роли при проведении сборок ПО;
- порядок регистрации событий безопасности при реализации сборок ПО в журналах аудита;
- сроки хранения журналов аудита;
- описание мер безопасности, необходимых для реализации в сборочной среде.
5.13.3.2 Информация о безопасности сборочной среды должна содержать:
- описание ожидаемых результатов сборки ПО;
- описание прав доступа к сборочной среде и хранилищу результатов сборки ПО, а также ролей пользователей, участвующих в процессе сборки ПО.
5.13.3.3 Схематическое изображение сборочной среды должно содержать:
- элементы сборочной среды (серверы, узлы, виртуальные узлы, элементы среды контейнеризации и т.п.);
- связи между элементами сборочной среды, позволяющие отследить порядок (очередность) выполнения сборочных действий;
- компоненты сборочной среды, реализующие отдельные функции, в том числе меры безопасности (средства защиты информации, инструменты статического анализа и др.).
П р и м е ч а н и е - При изображении сборочной среды в графическом виде рекомендуется использовать стандартизированные графические нотации (UML, IDEF, С4 и т.п.).
5.13.3.4 Журналы аудита процессов сборки ПО должны содержать следующую информацию:
- дату и время начала и завершения сборки ПО;
- информацию о версии собираемого ПО (модуля ПО, компонента ПО);
- информацию об используемой конфигурации сборки ПО;
- информацию о шагах сборки ПО;
- информацию о событиях безопасности в соответствии с регламентом обеспечения безопасности сборочной среды.
5.13.3.5 В качестве артефакта реализации требований, подтверждающих хранение результатов сборки ПО в выделенном хранилище, может использоваться журнал аудита сборки ПО, в котором указано место сохранения собранного модуля (компонента) ПО, результаты контрольного суммирования файлов, скачанных из хранилища результатов сборки ПО, и последующего сравнения их с контрольными суммами, указанными в журнале аудита сборки ПО или в графическом интерфейсе системы хранения результатов сборки ПО.
П р и м е ч а н и е - При разработке и реализации регламента доступа к исходному коду ПО рекомендуется руководствоваться принципами минимизации привилегий и разделения полномочий.
5.13.3.6 В качестве артефактов реализации требований, подтверждающих повторяемость сборки ПО, могут использоваться журналы аудита выполненных сборок, сравненные друг с другом; результаты контрольного суммирования файлов, полученных при разных запусках сборок, и последующего их сравнения (по контрольным суммам, по бинарному представлению, по наименованию и размеру и др.).
5.14 Управление доступом и контроль целостности кода при разработке программного обеспечения
5.14.1 Цели
5.14.1.1 Обеспечение управления доступом к исходному коду и его целостности.
5.14.2 Требования к реализации
5.14.2.1 Разработать регламент доступа к исходному коду ПО и обеспечения его целостности.
П р и м е ч а н и е - При разработке и реализации регламента доступа к исходному коду ПО рекомендуется руководствоваться принципами минимизации привилегий и разделения полномочий.
5.14.2.2 Осуществлять управление доступом к исходному коду ПО на основе выбранной модели управления доступом.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.14.3.1.
5.14.2.3 Осуществлять контроль целостности собственного исходного кода.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.14.3.1, 5.14.3.2.
5.14.3 Артефакты реализации требований
5.14.3.1 Регламент доступа к исходному коду ПО и обеспечения его целостности должен содержать следующие сведения:
- обязанности сотрудников, их права и роли при разработке ПО;
- правила хранения исходного кода ПО, включая правила резервного копирования исходного кода ПО;
- правила внесения изменений (модификации, добавления, удаления) в исходный код ПО;
- критерии выбора способов и инструментов контроля целостности ПО;
- критерии выбора модулей (компонентов) ПО, подлежащих контролю целостности;
- описание процедуры контроля целостности исходного кода ПО.
5.14.3.2 Описание модели управления доступом к исходному коду ПО должно включать:
- перечень сотрудников, их права и обязанности при разработке ПО;
- описание выбранной модели управления доступом и используемых инструментов управления доступом.
5.14.3.3 Результаты выполнения контроля целостности собственного исходного кода должны обеспечивать соответствие требованиям регламента доступа к исходному коду ПО и обеспечения его целостности и позволять сделать однозначный вывод о целостности собственного исходного кода.
5.15 Обеспечение безопасности используемых секретов
5.15.1 Цели
5.15.1.1 Обеспечение безопасного использования секретов.
П р и м е ч а н и е - В данном подразделе под секретами понимаются данные в любом виде, которые могут использоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т.п.), в том числе путем применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации или иными методами.
5.15.2 Требования к реализации
П р и м е ч а н и е - Требования к реализации, изложенные в данном подразделе, применяются пользователями стандарта по их усмотрению и в необходимых им объемах.
5.15.2.1 Разрабатывать регламент использования секретов.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3.
5.15.2.2 Использовать секреты.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.15.3.1.
5.15.2.3 Проверять код и конфигурационные файлы ПО на предмет включения секретов для вносимых изменений в ПО.
П р и м е ч а н и е - Допускается реализовывать проверку безопасности используемых секретов средствами статического или композиционного анализа.
5.15.2.4 Для хранения, управления и предоставления секретов использовать систему управления секретами.
5.15.3 Артефакты реализации требований
5.15.3.1 Регламент использования секретов может содержать следующие сведения:
- обязанности сотрудников и их роли при использовании секретов;
- основные принципы использования секретов;
- зоны ответственности подразделений и сотрудников в части использования секретов;
- порядок предоставления доступа к секретам;
- типы секретов, сроки их эксплуатации, действия при компрометации;
- порядок формирования и хранения секретов;
- порядок ротации секретов;
- требования к системам хранения секретов.
5.15.3.2 Описание реализации процедуры использования секретов может включать следующие сведения:
- порядок подписи исполняемого кода ПО (например, с использованием цифровых сертификатов);
- порядок подписи исходного кода (например, с использованием цифровых сертификатов).
5.16 Использование инструментов композиционного анализа
5.16.1 Цели
5.16.1.1 Создание условий для снижения рисков наследования уязвимостей и недекларированных возможностей при использовании заимствованного кода в коде ПО разработчика.
5.16.2 Требования к реализации
5.16.2.1 Разработать регламент композиционного анализа.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3.
П р и м е ч а н и е - В данном подразделе под композиционным анализом понимается вид работ, основанный на формировании перечня зависимостей ПО, определении особенностей их использования, выявлении наличия уязвимостей и/или иных недостатков в зависимостях ПО.
5.16.2.2 Формировать перечень зависимостей ПО.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.16.3.1.
5.16.2.3 Контролировать и актуализировать перечень зависимостей ПО в соответствии с регламентом композиционного анализа на предмет наличия известных уязвимостей.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.16.3.1, 5.16.3.2.
5.16.2.4 Осуществлять анализ заимствованных компонентов, составляющих поверхность атаки, на предмет наличия известных уязвимостей при сборке (непосредственно перед сборкой) ПО (модулей ПО, компонентов ПО).
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.16.3.1, 5.16.3.2.
5.16.2.5 Применять корректирующие воздействия по результатам анализа заимствованных компонентов на предмет наличия известных уязвимостей.
Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.16.3.1, 5.16.3.2, 5.16.3.3, 5.16.3.4, 5.16.3.5.
5.16.3 Артефакты реализации требований
5.16.3.1 Регламент композиционного анализа должен содержать следующие сведения:
- обязанности сотрудников и их роли при проведении композиционного анализа;
- правила отслеживания уязвимостей для заимствованных компонентов, участвующих в сборке ПО;
- правила проведения анализа заимствованных компонентов на предмет наличия известных уязвимостей;
- правила принятия компенсирующих и защитных мер по противодействию выявленным угрозам безопасности в цепочке поставки сторонних компонентов;
- периодичность проведения композиционного анализа в соответствии с установленными практиками сборки ПО.
5.16.3.2 Перечень зависимостей ПО должен включать следующие сведения:
- перечень модулей (комп
