ГОСТ 34009—2016
67 В рамках проведения анализа требований к системе управления единицей ТПС и анализа
риска для нее. из совокупности опасностей для системы управления единицей ТПС в целом должны
быть выделены опасности и угрозы для ПО ТПС. включая угрозы информационной, функциональной
безопасности и угрозы, связанные с киберзащищенностью. По результатам формируют протокол угроз.
Протокол угроз оформляют аналогичножурналуучета опасностей поГОСТ33433—2015. пункт6.2.5.
Если риски для выявленных угроз превышают допустимый уровень риска, то они должны быть
снижены посредством применения различных защитных мер.
Общий процесс менеджмента риска для программного обеспечения в соответствии с [3] особен
ности менеджмента риска для угроз информационной безопасности по [4].
6.8 Разработка архитектуры ПО ТПС включает в себя следующие задачи (для каждого компонента
ПО ТПС):
- трансформацию требований к ПО ТПС в архитектуру, определяющую на высоком уровнеструктуру
ПО ТПС и состав его компонентов;
- разработку и документирование программных интерфейсов ПО ТПС и баз данных;
- разработку предварительной версии документации пользователей;
- разработку предварительных плана интеграции ПО ТПС и требований к тестированию (испыта
ниям).
Архитектура компонентов ПО ТПС должна соответствовать предъявляемым к ним в техническом
задании требованиям (в том числе УПБ ПО ТПС). а также принятым методам проектирования.
6.9 При кодировании осуществляют написание исходного кода программы с применением выбран
ного языка программирования и по заданному алгоритму. Данный вид работы документируют в виде
файловой структуры текста программы, в которой по согласованию с заказчиком приводят ссылку на
носитель информации с исходным текстом программы по ГОСТ 19.401 или в ином формате, удовлетво
ряющем требования заказчика.
6.10 Интеграция ПО ТПС предусматривает сборку разработанных модулей и встроенного про
граммного обеспечения реального времени в соответствии с планом интеграции и тестирование агре
гированных компонентов. Интеграция системы управления единицей ТПС заключается в сборке всех ее
компонентов, включая ПО ТПС и оборудование.
При интеграции необходимо обеспечить интероперабельность, правильность и контролируемость
программ в аппаратной среде.
6.11 Для обеспечения приемлемого уровня безошибочности ПО ТПС целесообразно при разра
ботке ПО ТПС:
- применять методы нисходящего проектирования;
- обеспечивать модульность программ;
- осуществлять верификацию на кахщой стадии жизненного цикла ПО ТПС;
- использовать проверенные модули и библиотеки модулей;
- разрабатывать документацию, которая пригодна для аудита;
- проводить аттестационные испытания.
Основные приемы, используемые при разработке ПО ТПС с заданным УПБ. и необходимость их
применения приведены в [1].
6.12 После каждой стадии разработки ПО ТПС необходимо проводить верификацию, основными
аспектами которой являются:
а) подтверждение выполнения ПО ТПС и его программных компонентов требований безопасности,
установленных в технологической и эксплуатационной документации ПО ТПС с целью установления:
1) полноты и корректности реализации ПО ТПС функций управления и функций обеспечения
безопасности движения поездов, установленных техническим заданием;
2) полноты соответствия требованиям киберзащищенности, установленных техническим зада
нием;
3) достаточности и обоснованности технических приемов и мероприятий, которые применены
при разработке ПО ТПС;
4) полноты и корректности программ и методик испытаний;
5) полноты и корректности результатов испытаний ПО ТПС и системы управления ТПС в целом:
б) подтверждение выполнения ПО ТПС требований безопасности при проведении стендовых ис
пытаний.
Основными целями верификации по аспекту, указанному в перечислении б), являются:
- подтверждение соответствия полученных характеристик ПО ТПС требуемым значениям;
6