Лекция 2. Стандарты на организацию жизненного цикла при разработке защищенного программного обеспечения и программных средств

1.

Лекция 2. Стандарты на организацию жизненного цикла при
разработке защищенного программного обеспечения и программных
средств
Вопросы:
1. Функции и классификация стандартов информационной безопасности
2. Стандарты, регламентирующие жизненный цикл программного обеспечения
3.
Стандарты, регламентирующие функциональную безопасность
программным средствам
Литература
1. Фот, Ю. Д. Стандарты информационной безопасности : учебное пособие / Ю. Д.
Фот. — Оренбург : ОГУ, 2018. — 226 с. — ISBN 978-5-7410-2297-9. — Текст :
электронный //
Лань
:
электронно-библиотечная
система.
—
URL:
https://e.lanbook.com/book/159804 (дата обращения: 30.08.2024). — Режим доступа:
для авториз. пользователей.
2. Гвоздева, Т. В. Проектирование информационных систем. Стандартизация,
техническое документирование информационных систем : учебное пособие для спо /
Т. В. Гвоздева, Б. А. Баллод. — 2-е изд., стер. — Санкт-Петербург : Лань, 2021. —
216 с. — ISBN 978-5-8114-8414-0. — Текст : электронный // Лань : электроннобиблиотечная система. — URL: https://e.lanbook.com/book/176672 (дата обращения:
03.09.2024). — Режим доступа: для авториз. пользователей.
3. Краковский, Ю. М. Методы защиты информации : учебное пособие для вузов / Ю.
М. Краковский. — 3-е изд., перераб. — Санкт-Петербург : Лань, 2021. — 236 с. —
ISBN 978-5-8114-5632-1. — Текст : электронный // Лань : электронно-библиотечная
система. — URL: https://e.lanbook.com/book/156401 (дата обращения: 03.09.2024). —
Режим доступа: для авториз. пользователей.
1.
Функции
безопасности
и
классификация
стандартов
информационной
Стандарты по информационной безопасности определяют необходимые
требования, предоставляемые к
организации
защиты
информации.
В
частности, государственные стандарты задают требования к информационной
безопасности, определяемые с помощью систематической оценки рисков.
Стандарты
информационной
безопасности
–
это
обязательные
или
рекомендуемые к выполнению документы, в которых определены подходы к оценке
уровня ИБ и установлены требования к безопасным информационным системам.
Стандарты в области информационной безопасности выполняют следующие
важнейшие функции:

2.

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

3.

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

4.

2. Стандарты, регламентирующие жизненный цикл программного обеспечения
В
основе
деятельности
по
разработке
защищенного
программного
обеспечения лежит понятие жизненного цикла программного обеспечения.
Жизненный цикл программного обеспечения (ЖЦ ПО) - период времени,
который начинается с момента принятия решения о необходимости создания
программного продукта и заканчивается в момент его полного изъятия из
эксплуатации [2].
Жизненный цикл - развитие системы, продукта, услуги, проекта или других
изготовленных человеком объектов, начиная со стадии разработки концепции и
заканчивая прекращением применения [54].
Жизненный цикл системы - развитие рассматриваемой системы во времени,
начиная от замысла и заканчивая списанием [54].
Существует целый ряд стандартов, регламентирующих жизненный цикл
программного
обеспечения
и
процессы
разработки.
Наиболее
известные
следующие:
-
ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная
и программная инженерия. Процессы жизненного цикла программных средств»
(ISO/IEC 12207:2008 «System and software engineering — Software
lifecycle
processes») - стандарт определяет процессы, виды деятельности и задачи, которые
используются при приобретении программного продукта или услуги, а также при
поставке, разработке, применении по назначению, сопровождении и прекращении
применения программных продуктов [54].
ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на
-
автоматизированные системы. Автоматизированные системы. Стадии создания» распространяется на автоматизированные системы и устанавливает стадии и этапы
их создания, содержится описание содержания работ на каждом этапе [20].
-
ГОСТ Р 57318-2016. «Национальный стандарт Российской Федерации.
Системы промышленной автоматизации и интеграция. Применение и управление
процессами
системной
инженерии»
определяет
требования
к
процессам

5.

предприятия, связанным с разработкой новой продукции (включая вычислительную
технику и программное обеспечение), а также процессам, которые обеспечивают
поддержку жизненного цикла продукции [50].
-
Серия стандартов ГОСТ Р ИСО/МЭК 15504 «Национальный стандарт
Российской
Федерации.
Информационная
технология.
Оценка
процесса»,
детализирующих и конкретизирующих базовые процессы жизненного цикла.
2.1.1 Особенности процессов жизненного цикла программных средств в
стандарте ГОСТ Р ИСО/МЭК 12207
ГОСТ Р ИСО/МЭК 12207-2010. «Информационная технология. Системная и
программная
инженерия.
Процессы
жизненного
цикла
программных
средств»идентичен международному стандарту ИСО/МЭК 12207-2008 «Системная
и программная инженерия. Процессы жизненного цикла программных средств»
(ISO/IEC 12207:2008 «System and software
engineering
–Software
lifecycle
processes»), разработанному подкомитетом ПК 7 «Системная и программная
инженерия» (SC 7 System and Software Engineering) Совместного технического
комитета №1 ИСО/МЭК - СТК 1 «Информационные технологии» (ISO/IEC JTC 1
Information Technology)[54].
Данный стандарт стал основой для дальнейшей детализации в некоторых
методологиях разработки ПО, однако сам по себе лишь устанавливает структуру
основных, вспомогательных и организационных процессов ЖЦ программных
средств, определяя необходимые в их рамках работы и задачи. Согласно [59],
стандарт группирует различные виды деятельности, которые могут выполняться в
течение жизненного цикла программных систем, в семь групп процессов,
представленных на рисунке 2.1.

6.

Группы процессов жизненного цикла согласно
ГОСТ Р ИСО/МЭК 12207-2010.
Процессы соглашения
2 процесса
Процессы организационного обеспечения проекта
5 процессов
Процессы проекта
7 процессов
Технические процессы
11 процессов
Процессы реализации программных средств
7 процессов
Процессы поддержки программных средств
8 процессов
Процессы повторного применения программных средств
3 процесса
Рисунок 2.1 – Группы процессов жизненного цикла согласно ГОСТ Р
ИСО/МЭК 12207-2010. «Информационная технология. Системная и программная
инженерия. Процессы жизненного цикла программных средств»
Процессы соглашения определяют действия, необходимые для выработки
соглашений между двумя организациями. Если реализуется процесс приобретения,
то он обеспечивает средства для проведения деловой деятельности с поставщиком
продуктов, предоставляемых для применения в функционирующей системе,
услугах поддержки этой системы или элементах системы, разработанных в рамках
проекта. Если реализуется процесс поставки, то он обеспечивает средства для
проведения проекта, в котором результатом является продукт или услуга,
поставляемые приобретающей стороне [54].
Процессы
организационного
обеспечения
проекта
осуществляют
менеджмент возможностей организаций приобретать и поставлять продукты или
услуги через инициализацию, поддержку и управление проектами. Эти процессы
обеспечивают ресурсы и инфраструктуру, необходимые для поддержки проектов, и
гарантируют
удовлетворение
соглашений [54].
организационных
целей
и
установленных

7.

Процессы проекта, согласно [54], подразделяются на две категории: процессы
менеджмента проекта и процессы поддержки проекта. Процессы менеджмента
проекта применяются для создания и развития планов проекта, оценки фактического
выполнения и продвижения относительно плановых заданий и управления
выполнением проекта вплоть до полного его завершения. Процессы поддержки
проекта формируют специфическую совокупность задач, ориентированных на
выполнение специальных целей менеджмента.
Технические процессы используются для определения требований к системе,
преобразования требований в полезный продукт, для разрешения постоянного
копирования продукта (где это необходимо), применения продукта, обеспечения
требуемых услуг, поддержания обеспечения этих услуг и изъятия продукта из
обращения, если он не используется при оказании услуги [54].
Процессы реализации программных средств используются для создания
конкретного
элемента
системы
(составной
части),
выполненного
в
виде
программного средства. Эти процессы преобразуют заданные характеристики
поведения, интерфейсы и ограничения на реализацию в действия, результатом
которых
становится
системный
элемент,
удовлетворяющий
требованиям,
вытекающим из системных требований [54].
Процессы поддержки программных средств предусматривают специально
сфокусированную
совокупность
действий,
направленных
на
выполнение
специализированного программного процесса. Любой поддерживающий процесс
помогает процессу реализации программных средств как единое целое с
обособленной целью, внося вклад в успех и качество программного проекта [54].
Процессы повторного применения программных средств поддерживают
возможности организации использовать повторно составные части программных
средств за границами проекта [54].
Приведенные рекомендации по переходу от стандарта к деятельности
предприятия в основном концентрируются на выборе из всего приведенного
множества процессов работ, которые необходимы для реализации программного

8.

проекта, но практические рекомендации по организации внедрения ГОСТ 122072010 остаются за границами самого документа.
2.1.2 Особенности создания автоматизированных систем в стандарте ГОСТ
34.601-90
ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на
автоматизированные системы. Автоматизированные системы. Стадии создания»
распространяется на автоматизированные системы, используемые в различных
видах деятельности (исследование, проектирование, управление и т. п.), включая их
сочетания, создаваемые в организациях, объединениях и на предприятиях [20].
Включает в себя стадии создания автоматизированной системы, представленные на
рисунке 2.2.
Стадии создания автоматизированной системы согласно
ГОСТ 34.601-90
Формирование требований к АС
3 этапа
Разработка концепции АС
4 этапа
Техническое задание
1 этап
Эскизный проект
2 этапа
Технический проект
4 этапа
Рабочая документация
2 этапа
Ввод в действие
8 этапов
Сопровождение АС
2 этапа
Рисунок 2.2 – Стадии создания автоматизированной системы согласно ГОСТ
34.601-90
ГОСТ 34.601-90 достаточно структурирован и его можно адаптировать к
конкретным условиям деятельности предприятия. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной модели

9.

жизненного цикла. Справочное приложение к ГОСТ 34.601 устанавливает, что
программное обеспечение автоматизированных систем –
это
совокупность
программ на носителях информации с программной документацией по ГОСТ
19.101. Таким образом, при разработке программного обеспечения можно
пользоваться как стандартом ГОСТ 19.102, так и ГОСТ 34.601.
2.1.3 Особенности процессов жизненного цикла в серии стандартов ГОСТ Р
ИСО/МЭК 15504
К серии ИСО/МЭК 15504 относят стандарты:
-
ГОСТ Р ИСО/МЭК 15504-1-2009 «Информационные технологии. Оценка
процессов. Часть 1. Концепция и словарь»;
-
ГОСТ
Р
ИСО/МЭК
15504-2-2009
«Информационная технология.
Оценка процесса. Часть 2. Проведение оценки»;
-
ГОСТ Р ИСО/МЭК 15504-3-2009 «Информационная технология. Оценка
процесса. Часть 3. Руководство по проведению оценки»;
-
ГОСТ Р ИСО/МЭК 15504-4-2012 «Информационная технология. Оценка
процесса. Часть 4. Руководство по применению для улучшения и оценки
возможностей процесса»;
-
ГОСТ Р ИСО/МЭК 15504-5-2016 «Информационные технологии (ИТ).
Оценка процессов. Часть 5. Образец модели оценки процессов жизненного цикла
программного обеспечения»;
-
ISO/IEC 15504-6:2013 «Информационные технологии. Оценка процессов.
Часть 6. Пример модели оценки процессов жизненного цикла системы»;
-
ISO/IEC TR 15504-7:2008 «Information technology - Process assessment - Part
7: Assessment of organizational maturity»;
-
ISO/IEC TS 15504-8:2012 «Information technology - Process assessment - Part
8: An exemplar process assessment model for IT service management»;
-
ISO/IEC
TS
15504-9:2011
«Информационные
процессов. Часть 9. Профили целевого процесса»;
технологии.
Оценка

10.

- ISO/IEC
TS
15504-10:2011
«Информационные
технологии.
Оценка
процессов. Часть 10. Расширение безопасности».
Стандарты устанавливают подход к оценке процессов организации с целью
объективного понимания состояния ее собственных процессов для их улучшения,
объективного определения пригодности ее собственных процессов для конкретного
требования или совокупности требований, объективного определения пригодности
процессов другой организации для конкретного контракта или совокупности
контрактов [59].
Для достижения устойчивых результатов в процессе развития технологии и
организации управления жизненным циклом ПС в серии стандартов ГОСТ Р
ИСО/МЭК 15504 рекомендуется методология обеспечения качества сложных
программных средств СММ (Capability Maturity Model) — система и модель оценки
зрелости комплекса, применяемых технологических процессов [77]. Модель
основана на формализации и использовании пяти уровней зрелости технологий
поддержки ЖЦ ПС, которые определяют потенциально возможное качество и
безопасность
создаваемых
характеризуются
степенью
комплексов
программ.
формализации,
Эти
уровни
адекватностью
зрелости
измерения
и
документирования процессов и продуктов ЖЦ ПС, широтой применения стандартов
и инструментальных средств автоматизации работ, наличием
и
полнотой
реализации функций системой обеспечения качества технологических процессов и
их результатов. Они, в некоторой степени, подобны семи оценочным уровням
доверия в стандарте ГОСТ Р ИСО/МЭК 15504-3-2009.
Уровень 1. Начальный. Наиболее массовые разработки проектов ПС
характеризуются относительно небольшими объемами программ в несколько тысяч
строк, создаваемых несколькими специалистами. Они применяют простейшие не
формализованные технологии с использованием типовых инструментальных
компонентов операционных систем. Основные процессы ЖЦ ПС на этом уровне не
регламентированы,
выполняются
не
совсем
упорядоченно
и
зависят
некоординированных индивидуальных усилий специалистов. Успех проекта, как
от

11.

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

12.

выполнения, механизмы проверки качества результатов, выходные данные, условия
и документы завершения процессов. В описания процессов включаются сведения об
инструментальных
средствах,
необходимых
для
их
выполнения,
роль,
ответственность и квалификация специалистов.
Уровень 4. Предсказуемый. Для реализации проектов крупномасштабных,
особенно сложных ПС в жестко ограниченные сроки и с высоким гарантированным
качеством, необходимы активные меры для предотвращения и выявления дефектов
и ошибок на всех этапах ЖЦ ПС. Управление должно обеспечивать выполнение
процессов в соответствии с текущими требованиями к характеристикам качества
компонентов и ПС в целом. На этом уровне должна применяться система детального
поэтапного оценивания характеристик качества, как технологических
процессов
ЖЦ, так и самого создаваемого программного продукта и его компонентов. Должны
разрабатываться и применяться универсальные методики количественной оценки
реализации процессов и их качества. Одновременно с повышением сложности и
требований к качеству ПС, следует совершенствовать управление проектами за счет
сокращения текущих корректировок и исправлений дефектов при выполнении
процессов. Результаты процессов становятся предсказуемыми по срокам и качеству
в связи с тем, что они измеряются в ходе их выполнения и реализуются в рамках
заданных ресурсных ограничений.
Уровень
5.
Оптимизируемый. Дальнейшее
последовательное
совершенствование и модернизация технологических процессов ЖЦ ПС для
повышения качества их выполнения и расширение глубины контроля за их
реализацией. Одна из основных целей этого уровня сокращение проявлений
и
потерь от случайных дефектов и ошибок путем выявления сильных и слабых сторон
используемых процессов. При этом приоритетным является анализ рисков, дефектов
и отклонений от заданных требований заказчика. Эти данные также используются
для снижения себестоимости ЖЦ особо сложных ПС в результате внедрения новых
технологий и инструментария, а также для планирования и осуществления
модернизации всех видов процессов. Технологические нововведения, которые могут

13.

принести наибольшую выгоду, должны стандартизироваться и адаптироваться в
комплексную технологию обеспечения и оценивания системы качества предприятияи
его продукции.
Все десять частей стандарта, посвящены различным базовым задачам,
относящимся к оцениванию, аттестации и совершенствованию зрелости процессов
ЖЦ ПС на предприятии. ГОСТ 15504 связан с другими международными
стандартами, он дополняет некоторые стандарты и другие модели для оценки
зрелости, качества и эффективности предприятий и процессов ЖЦ ПС. Этот стандарт
преследует ту же цель, что и серия стандартов ISO 9000:2000 - формализации и
обеспечения уверенности в достаточности системы управления
качеством продукции у поставщика. Одновременно предоставляется потребителям
основа для оценки того, обладают ли потенциальные поставщики производственными
возможностями, отвечающими потребностям заказчиков. Аттестация процессов дает
пользователям возможность оценивать зрелость процессов обеспечения ЖЦ ПС по
непрерывной шкале таким образом, что эти оценки сопоставимы, и повторяемы [119].
3. Стандарты, регламентирующие функциональную безопасность
программным средствам
Базовым задачам обеспечения безопасности программных средств и систем с
использованием ЭВМ посвящена значительная группа стандартов, среди которых
следует выделить:
-
ГОСТ Р ИСО/МЭК 15408-1-2012 «Критерии оценки безопасности
информационных технологий. Часть 1. Введение и общая модель» (Information
technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction
and general model);
- ГОСТ Р ИСО/МЭК 13335-1-2006 «Информационная технология. Методы и
средства обеспечения безопасности. Часть 1. Концепция и модели менеджмента
безопасности информационных и телекоммуникационных технологий» (Information

14.

technology. Security techniques. Part 1. Concepts and models for information and
communications technology security management);
- ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем. Общие
требования к разработке и документированию».
Рекомендуемые процессы и структура жизненного цикла ПС в этих стандартах
несколько различаются, однако по составу процессов они весьма близки. В них
акцентируется внимание на информационной безопасности, а также на обеспечении ее
качества в жизненном цикле систем обработки информации и управления.
Значительная часть содержания этих стандартов уделена требованиям, методам и
процессам разработки и всего жизненного цикла программных средств и систем,
которые, в частности, могут использоваться для обеспечения безопасности. Многие
рекомендации этих стандартов могут быть адаптированы и полезны для обеспечения
функциональной безопасности, в том числе, встроенных программных систем [119].
Целиком проблему функциональной безопасности ПС и систем отражают
стандарты: ГОСТ Р МЭК 61508-3-2012«Функциональная безопасность систем
электрических,
электронных,
программируемых
электронных,
связанных
с
безопасностью. Часть 3. Требования к программному обеспечению», ГОСТ Р 519042002 «Программное обеспечение встроенных систем. Общие требования к разработке
и документированию» и ГОСТ Р МЭК 60880-2010 «Атомные электростанции.
Системы
контроля
и
управления,
важные
для
обеспечение компьютерных систем, выполняющих
которых,
как
и
в
остальных,
значительная
безопасности.
Программное
функции категории А», в
часть
содержания
посвящена
регламентированию процессов жизненного цикла сложных комплексов программ
[120], [121]. Из них для обеспечения функциональной безопасности
жизненного цикла встроенных комплексов программ целесообразно применять, в
основном, первые два стандарта [119].
Значительно более полно, систематично и подробно процессы жизненногоцикла
сложных программных средств представлены в базовых стандартах ГОСТ Р
ИСО/МЭК
12207
«Информационная
технология.
Системная
и
программная
инженерия. Процессы жизненного цикла программных средств», серии ИСО/МЭК

15.

15504 «Информационные технологии. Оценка процессов», и в свыше десяти
сопутствующих им стандартах, детализирующих и углубляющих требования и
процессы жизненного цикла программного обеспечения [79], [80]. Этот комплекс
стандартов целесообразно учитывать при создании и применении программного
обеспечения и систем, обеспечивающих функциональную безопасность [119].
2.1.4
Процессы
обеспечения
функциональной
безопасности
в
серии
стандартов МЭК 61508
МЭК 61508 представляет собой верхний уровень целого семейства отраслевых
стандартов, которые детализируют требования к функциональной безопасности для
систем
управления
медицинским
оборудованием,
автомобильным
и
железнодорожного транспортом, АСУ ТП и т.д.Первая редакция МЭК 61508 была
разработана с 1998 по 2000 годы. В Российской Федерации первая редакция была
принята в качестве государственного стандарта ГОСТ Р МЭК 61508 в 2007 году. В
настоящее время в мире действует вторая редакция МЭК 61508, выпущенная в 2010.В
Российской Федерации вторая редакция МЭК 61508 также является актуальной с 2012
года (ГОСТ Р МЭК 61508-2012).
Серия стандартов МЭК 61508 включает 7 частей:
- ГОСТ Р МЭК
61508-1-2012
«Функциональная безопасность систем
электрических,
электронных, программируемых электронных,
связанных с
безопасностью. Часть 1.Общие требования». Сложность для понимания первой части
состоит в том, что эта часть во многом описывает уровень объекта контроля и
управления, не очень привычный для IT-специалистов.
- ГОСТ
Р
электрических,
МЭК
61508-2-2012
электронных,
«Функциональная
программируемых
безопасность
электронных,
систем
связанных
с
безопасностью. Часть 2. Требования к системам.»Вторая часть, относится к
управляющей системе. Рассматриваются три типа архитектур управляющих систем:
встроенные системы (Embedded Systems), АСУ ТП на базе ПЛК (Industrial Control
Systems) и Device Layer интернета вещей. Кроме системных требований, МЭК 61508-2
определяет также требования к аппаратной (hardware) составляющей систем.
- ГОСТ
электрических,
Р
МЭК
61508-3-2012
электронных,
«Функциональная
программируемых
безопасность
электронных,
систем
связанных
с

16.

безопасностью. Часть 3. Требования к программному обеспечению». Третья часть,
определяет требования к программному обеспечению, которое может быть, как
компонентом системы, так и отдельным объектом оценивания и сертификации.
Р
- ГОСТ
МЭК
61508-4-2012
электрических, электронных,
«Функциональная
программируемых
безопасность
электронных
систем
связанных
с
безопасностью. Часть 4. Термины и определения». Четвертая часть содержит
структурированный перечень используемых терминов и определений.
-
ГОСТ
Р
МЭК
61508-5-2012
«Функциональная безопасность систем
электрических, электронных, программируемых электронных, связанных с
безопасностью.
Часть 5.
Рекомендации по применению методов определения
уровней полноты безопасности».
Пятая часть приводит примеры того, как
определять уровень полноты безопасности (safetyintegritylevel, SIL).
-
ГОСТ
Р
электрических,
МЭК
61508-6-2012
электронных,
«Функциональная
программируемых
безопасность
электронных,
систем
связанных
с
безопасностью. Часть 6. Руководство по применению ГОСТ Р МЭК 61508-2 и ГОСТ Р
МЭК 61508-3». часть содержит ряд требований к системе, аппаратному и
программному обеспечению.
ГОСТ
Р
МЭК
61508-7-2012
«Функциональная
безопасность
систем
электрических, электронных, программируемых электронных, связанных с
безопасностью. Часть 7. Методы и средства». Седьмая часть содержит перечень
методов защиты от случайных отказов аппаратных средств и от систематических
ошибок проектирования (как системы и аппаратных средств, так и программного
обеспечения).
Особенностью серии стандартов МЭК 61508 является риск-ориентированный
подход. В зависимости от риска, который техногенный объект создает для
окружающей среды, жизни и здоровья людей, устанавливаются риски для отказов
систем управления. В МЭК 61508-4, раздел 3.1 «Термины, относящиеся к
безопасности» отражает множество показателей.
Рисунок 2.3 – Структура окружения для объекта безопасности

17.

Риск является показателем безопасности, и на понятии риска основаны другие
показатели серии стандартов. Компьютерная система управления (КСУ) является
лишь одной из многих мер по снижению рисков, так же существует множество
пассивных мер защиты. В МЭК 61508-4, раздел 3.5 «Функции безопасности и полнота
безопасности» приводятся соответствующие термины. Полнота безопасности, в серии
МЭК
61508,
свойство,
сводящееся
к
безотказному
выполнению
функций
безопасности, т.е. рассматривается, как часть безотказности, которая, в свою очередь,
является составляющей классической надежности. Из других положений МЭК 61508
следует, что полнота безопасности является более сложным свойством, связанным с
такими атрибутами, как ремонтопригодность,
готовность, долговечность, информационная безопасность. Еще одним центральным
понятием в МЭК 61508 является уровень полноты безопасности [122]. Из структуры
определений также следует, что полнота безопасности делится на две составляющие:
полнота безопасности, касающаяся систематических отказов (сюда же попадает
полнота
безопасности
программного
обеспечения)
и
полнота
безопасности
аппаратных средств [122].
Первая составляющая требует применять меры защиты от систематических
отказов,
вызванных
ошибками
проектирования.
Для
этого
необходимо
совершенствовать процессы проектирования и разработки, тестирования, управления
конфигурацией,
проектного
менеджмента
и
т.п. Полнота безопасности
аппаратных средств связана с защитой от случайных отказов и обеспечивается
применением компонентов с высоким уровнем безотказности и самодиагностики, и,
конечно же, резервированием. Структуру окружения (опасность, ущерб, риски,
контрмеры, управляемое оборудование) для компьютерной системы управления
(КСУ), представлена на рисунке 2.4. Здесь речь идет об опасностях для выполнения
функций безопасности КСУ, поскольку их невыполнение связано с риском. Для
снижения этого риска применяются различные меры по обеспечению полноты
безопасности. Как мы уже знаем, эти меры направлены на защиту от случайных и
систематических отказов [122].

18.

Рисунок 2.4 - Структура окружения для компьютерной системы управления
(КСУ)
Процессы обеспечения функциональной безопасности в серии стандартов
МЭК 61508 можно представить следующим образом (рисунок 2.5).
Ко нтрме
Контрм
ы
ры
Риски
функционирования
КСУ
Риски
Для
Для
Рисунок 2.5 - Процессы обеспечения функциональной безопасности в серии
стандартов МЭК 61508
2.2.2 Особенности процессов обеспечения функциональной безопасности в
серии стандартов ГОСТ Р ИСО/МЭК 15408
В 2002 г. Постановлением Госстандарта Российской Федерации от4.04.2002 г.
№ 133-ст был принят стандарт ГОСТ Р ИСО/МЭК 15408-2002. Стандарт был введен
в действие 01.01.2004 г.
Серия стандартов ГОСТ Р ИСО/МЭК 15408 содержит следующие части:
- ГОСТ Р ИСО/МЭК 15408-1-2012 «Информационная технология. Методы и
средства
обеспечения
безопасности.
Критерии
оценки
информационных технологий. Часть 1. Введение и общая модель».
безопасности

19.

- ГОСТ Р ИСО/МЭК 15408-2-2013 «Методы и средства обеспечения
безопасности. Критерии Оценки безопасности информационных технологий. Часть
2. Функциональные требования безопасности».
- ГОСТ Р ИСО/МЭК 15408-3-2013 «Информационная технология. Методы и
средства
обеспечения
безопасности.
Критерии
оценки
безопасности
информационных технологий. Часть 3. Требования доверия к безопасности».
Первая часть определяет концепцию всего стандарта, а вторая самая большая
часть формализует методы и требования к информационной безопасности. Его
третья часть полностью посвящена процессам обеспечения доверия - (качества)
компонентов
информационных
систем
(ИС),
реализующих
функции
их
безопасности. В серии стандартов ГОСТ Р ИСО/МЭК 15408рассматривается
регламентирование технологии и процессов обеспечения жизненного цикла
программных
средств,
создаваемых
для
обеспечения
безопасности
функционирования и применения систем, особое место выделено информационной
безопасности
сложных
программных
ИСО/МЭК15408 рассматривается
с
средств
ИС.
Безопасность
использованием
совокупности
понятий безопасности: актив, владелец актива,
риск,
угрозы,
источники угроз. В стандарте представлена схема их взаимосвязи.
Владельцы
Хотят минимизировать
Контрмеры
Чтобы уменьшить
Которые
Уязвимости
используют
Риск
Источники угроз (нарушители)
Порождают
повяшают
Угрозы
Рисунок 2.6 – Понятие безопасности и их взаимосвязь
Активы
в
серии
базовых
контрмеры,

20.

При оценке достаточность контрмер анализируется через заключение о
степени доверия контрмерам по уменьшению рисков для защищаемых активов.
Методы доверия
Предоставляет
свидетельство
Дающее
Уверенность
Что
Риск
Для
Рисунок 2.7 - Понятия, используемые при оценке, и их взаимосвязь
При разработке программного средства в стандарте применяется иерархия
детализации требований к безопасности и качеству систем и программных средств
(ПС) с использованием специфических терминов: класс - наиболее общая
характеристика
качества,
которая
структурируется семейством -
субхарактеристиками.
Каждое семейство может иметь несколько компонентов - атрибутов,
состоящих из элементов качества. Семейство доверия (качества) в стандарте может
содержать один или несколько компонентов доверия. Этот подраздел семейства
доверия включает описание имеющихся компонентов и объяснение их содержания и
разграничения. Подраздел идентификации компонента содержит описательную
информацию, необходимую для категорирования, регистрации и ссылок на
компонент. Каждый элемент представляет собой требование для выполнения.
Формулировки этих требований к ПС должны быть четкими, краткими и

21.

однозначными. Поэтому каждое требование рекомендуется излагать как отдельный
элемент.
Структура процессов жизненного цикла систем и программных средств,
обеспечивающих информационную и функциональную безопасность применения в
соответствии с классами и семействами стандарта, представлена на рисунке 2.8 [80].
Управление конфигурацией программных средств.
Автоматизация управления конфигурацией.
Возможности управления конфигурацией.
Область управления конфигурацией
Поставка и эксплуатация программных средств.
Поставка программного продукта.
Установка, генерация и запуск.
Разработка программного средства.
Функциональная спецификация программного средства. Проект верхнего
уровня программного средства. Представление реализации программного
средства. Внутренняя структура функциональной безопасности объекта.
Проект нижнего уровня. Соответствие представлений.
Моделирование политики безопасности.
Руководства по безопасности программного средства.
Руководство администратора.
Руководство пользователя.
Поддержка жизненного цикла безопасности программного средства.
Безопасность разработки программного средства. Устранение дефектов.
Определение жизненного цикла программного средства.
Инструментальные средства и методы.
Тестирование программного средства.
Покрытие тестами программными средствами. Глубина тестирования.
Функциональное тестирование. Независимое тестирование.
Оценка уязвимости программного средства.
Анализ скрытых каналов. Неправильное применение программных
средств. Стойкость функций безопасности объекта. Анализ уязвимостей
объекта
Рисунок 2.8 - Структура процессов жизненного цикла систем и программных
средств согласно серии стандартов ГОСТ Р ИСО/МЭК 15408
Для систематичного применения приведенных на рисунке классов и семейств
требований в стандарте введено понятие профиль защиты (ПЗ) - независимая от

22.

реализации совокупность требований безопасности для некоторой категории
объектов, отвечающая специфическим требованиям проекта и потребителя [56].
Цель
разработки
и
оценки
ПЗ
—
показать,
что
он
является
полным,
непротиворечивым, технически правильным и поэтому пригоден для изложения
конкретных требований к одному или нескольким типам объектов. Оцененный ПЗ
пригоден в качестве основы для разработки задания по безопасности. Для принятия
решения о достаточности требований безопасности в составе ПЗ важно, чтобы
решаемая задача безопасности ясно понималась всеми участниками оценки [122].
В зависимости от сложности и критичности требования к безопасности
функционирования системы и доступных ресурсов для ее реализации, стандартом
рекомендуется выбирать набор классов и семейств процессов, достаточных для
обеспечения необходимого качества комплекса функциональной безопасности
проекта - оценочный уровень доверия. Оценочные уровни доверия (ОУД) образуют
возрастающую шкалу достигаемого качества безопасности, которая позволяет
соотнести получаемый уровень качества с трудоемкостью его реализации и
возможностью достижения этой степени доверия [80].
Не все классы и семейства настоящего стандарта включены в каждый из
перечисленных ниже оценочных уровней доверия. Эти семейства рекомендуется
использовать для повышения уровней доверия в тех профилях защиты (ПЗ) и
заданий безопасности (ЗБ), для которых они действительно полезны и необходимы.
Определены семь иерархически упорядоченных оценочных уровней доверия для
ранжирования при выборе доверия к безопасности объектов оценки [80].
Связь уровней доверия с классами и семействами технологических процессов
обеспечения ЖЦ безопасности систем и программных средств в стандарте
иллюстрированы семью таблицами. В каждой из них выделены и отмечены
обязательные и рекомендуемые классы и семейства процессов, обеспечивающие
определенный уровень доверия при создании и применении методов и средств
соответствующей безопасности. Во второй части стандарта ИСО/МЭК 15408
содержится
систематизированный
каталог
функциональных
требований
безопасности, разбитый на 11 классов, 65 семейств и 133 компонента.
С целью унификации процедуры сертификации по «Общим критериям»

23.

практически одновременно разрабатывались версии документа, известного под
названием «Общая методология оценки», который в дальнейшем был принят в
качестве международного стандарта ISO/IEC 18045 [96].
В 2000 г. ряд стран подписал и Соглашение о взаимном признании
сертификатов на изделия ИТ, полученных на основе «Общих критериев». Участие в
Соглашении предполагает соблюдение двух условий: признание сертификатов,
органами
по
сертификации
других
стран-участниц,
а
также
возможность
осуществления сертификации. Соглашение о взаимном признании оценок на конец
2013 г. подписал и 26 стран. В рамках Соглашения в 17 странах действуют
аккредитованные органы по сертификации [96].
Российская Федерация также присоединилась к работам по проведению
сертификации в соответствии с методологией международного стандарта 15408.
2.2.3 Особенности методологии обеспечения безопасности в серии стандартов
ИСО/МЭК 13335
Серия стандартов ИСО/МЭК 13335 состоит из следующих частей:
- ГОСТ Р ИСО/МЭК 13335-1-2006 «Информационная технология. Методы и
средства обеспечения безопасности. Часть 1. Концепция и модели менеджмента
безопасности
информационных
и
телекоммуникационных
технологий».
Представляет собой руководство по управлению безопасностью информационных и
телекоммуникационных технологий (ИТТ), устанавливает концепцию и модели,
лежащие в основе базового понимания безопасности ИТТ, и раскрывает общие
вопросы управления, которые важны для успешного планирования, реализации и
поддержки безопасности. Приведенные в стандарте положения носят общий
характер, они применимы к различным методам управления и организациям.
Стандарт устанавливает, что руководство организации несет ответственность за
обеспечение безопасности активов, а обязанности и ответственность должны быть
определены и доведены до сведения персонала. Это значит, что в каждой
должностной инструкции сотрудника, связанного с обеспечением безопасности ИТТ
должна быть установлена такая ответственность. Кроме того, стандарт (как и
отмененный ГОСТ Р ИСО/МЭК 17799-2005) предписывает разработать цели,

24.

стратегии и политики в данной области. Вне зависимости от организационной
структуры или документации, принятой в организации, важно, чтобы учитывались
различные стороны политики, и поддерживалась их согласованность (бизнес
политика – политика маркетинга – политика ИТТ – политика безопасности –
политика информационной безопасности – политика безопасности ИТТ и др.).
Жизненный цикл системы ИТТ разделен в стандарте на четыре типовые фазы:
планирование,
приобретение,
тестирование,
эксплуатация.
Обеспечение
безопасности ИТТ рассматривается в стандарте как постоянный процесс с
множеством обратных связей внутри и между фазами жизненного цикла системы
ИТТ [55].
- ГОСТ Р ИСО/МЭК ТО 13335-5-2006 «Информационная
Методы и средства обеспечения
технология.
безопасности. Часть 5. Руководство
по
менеджменту безопасности сети». Представляет собой руководство по управлению
безопасностью сетями для персонала, ответственного за эту деятельность, и
содержит основные положения по выявлению и анализу факторов, имеющих
отношение к компонентам безопасности связи.
Стандарт основан на положениях ИСО/МЭК 13335-5 путем описания метода
идентификации и анализа выбора контролируемых зон, имеющих отношение к
сетевым соединениям, с точки зрения обеспечения безопасности [55].
2.2.4 Особенности процессов разработки и документирования встроенных
программных средств в стандарте ГОСТ Р 51904
Стандарт ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем.
Общие требования к разработке и документированию» создан в развитие ISO
12207 с целью учета специфики жизненного цикла программных средств
встроенных систем реального времени высокого качества, преимущественно для
авиационных, космических и транспортных систем [119].
В стандарте представлены: общие требования, системные аспекты, связанные
с разработкой ПС, и шесть крупных разделов, подробно описывающие и
рекомендующие основные процессы ЖЦ встроенных программных средств.
Последовательно, детально рассмотрены требования и методы
реализации

25.

процессов жизненного
цикла
сложных
программных
средств.
Выделена
группа процессов планирования, которые определяют и координируют для проекта
действия процессов разработки и интегральных процессов [119].
Таблица 2.1 - Цели и результаты процессов жизненного цикла программного
обеспечения [119]
Цель
Результат
Процесс планирования ПО
Определить виды работ процессов
План сертификации в части ПО
разработки ПО и интегральных процессов
План разработки ПО
План верификации ПО
Определить критерии перехода,
План квалификационного тестирования ПО
взаимосвязи и последовательность
План управления конфигурацией ПО
выполнения процессов
Определить среду жизненного цикла ПО
План обеспечения качества ПО
План установки ПО
Рассмотреть дополнительные вопросы
План передачи ПО
Определить стандарты на разработку ПО
Стандарты на разработку требований к ПО
Стандарты на процесс проектирования ПО
Стандарты кодирования ПО
Протоколы обеспечения качества ПО
Согласование планов ПО с настоящим
Результаты верификации ПО
стандартом
Координация планов создания ПО
Протоколы обеспечения качества ПО
Результаты верификации ПО
Процессы разработки ПО
Разработать требования верхнего уровня
Спецификация системы/подсистемы
Спецификация требований к ПО
Спецификация требований к интерфейсу
Определить производные требования
Спецификация требований к ПО
верхнего уровня
Спецификация требований к интерфейсу
Разработать архитектуру ПО
Описание проекта системы/ подсистемы
Описание проекта ПО
Описание проекта интерфейса
Описание проекта базы данных
Разработать требования нижнего уровня
Описание проекта ПО

26.

Продолжение таблицы 2.1
Цель
Определить производные требования
нижнего уровня
Разработать исходный код
Получить исполняемый объектный код и
выполнить интеграцию ПО/аппаратуры
Результат
Описание проекта ПО
Исходный код ПО
Исполняемый объектный код ПО
Спецификация программного средства
Описание эксплуатационной концепции
Руководство по эксплуатации компьютера
Подготовить руководства пользователя и
Руководство по программированию для компьютера
руководства поддержки
Руководство поддержки программно- аппаратных
средств
Руководство оператора ПО
Руководство по входной / выходной информации
ПО
Руководство пользователя ПО
Описание версии ПО
Верификация результатов процесса разработки требований к ПО
Результаты верификации ПО
Требования верхнего уровня к ПО
согласуются с требованиями к системе
Результаты верификации ПО
Требования верхнего уровня точны и
непротиворечивы
Требования верхнего уровня совместимы с Результаты верификации ПО
объектным компьютером
Результаты верификации ПО
Требования верхнего уровня
верифицируемы
Требования верхнего уровня соответствуют Результаты верификации ПО
стандартам на разработку требований к ПО
Требования верхнего уровня трассируемы к Результаты верификации ПО
системным требованиям
Алгоритмы точны и корректны
Результаты верификации ПО
Верификация результатов процесса проектирования ПО
Требования нижнего уровня к ПО
Результаты верификации ПО
согласуются с требованиями верхнего
уровня
Результаты верификации ПО
Требования нижнего уровня точны и
непротиворечивы
Требования нижнего уровня совместимы с Результаты верификации ПО
объектным компьютером
Результаты верификации ПО
Требования нижнего уровня
верифицируемы
Требования нижнего уровня соответствуют Результаты верификации ПО
стандартам
Требования нижнего уровня трассируемы к Результаты верификации ПО
требованиям верхнего уровня
Алгоритмы точны и корректны
Результаты верификации ПО
Результаты верификации ПО
Архитектура ПО согласуется с
требованиями верхнего уровня
Архитектура ПО непротиворечива
Результаты верификации ПО
Результаты верификации ПО
Архитектура ПО совместима с объектным
компьютером

27.

Продолжение таблицы 2.1
Цель
Результат
Архитектура ПО верифицируема
Результаты верификации ПО
Архитектура ПО соответствует стандартам Результаты верификации ПО
на процесс проектирования ПО
Подтверждается целостность разбиения ПО Результаты верификации ПО
Верификация результатов процесса кодирования и интеграции ПО
Исходный код согласуется с требованиями Результаты верификации ПО
нижнего уровня
Результаты верификации ПО
Исходный код согласуется с архитектурой
ПО
Исходный код верифицируем
Результаты верификации ПО
Исходный код соответствует стандартам
Результаты верификации ПО
Результаты верификации ПО
Исходный код трассируем к требованиям
нижнего уровня
Исходный код точен и непротиворечив
Результаты верификации ПО
Результаты процесса интеграции ПО полны Результаты верификации ПО
и корректны
Тестирование результатов процесса интеграции ПО
Исполняемый объектный код согласуется с Процедуры верификации ПО
требованиями верхнего уровня
Описание квалификационного тестирования ПО
Результаты верификации ПО
Отчет о квалификационном тестировании ПО
Процедуры верификации ПО
Исполняемый объектный код устойчив
Описание квалификационного тестирования ПО
относительно входов, определенных
Результаты верификации ПО
требованиями верхнего уровня
Отчет о квалификационном тестировании ПО
Исполняемый объектный код согласуется с Процедуры верификации ПО
Результаты верификации ПО
требованиями нижнего уровня
Процедуры верификации ПО
Исполняемый объектный код устойчив
относительно входов, определенных
Результаты верификации ПО
требованиями нижнего уровня
Исполняемый код совместим с объектным Процедуры верификации ПО
Описание квалификационного тестирования ПО
компьютером
Результаты верификации ПО
Отчет о квалификационном тестировании ПО
Верификация результатов процесса верификации ПО
Тестовые процедуры корректны
Процедуры верификации ПО
Описание квалификационного тестирования ПО
Результаты верификации ПО
Результаты тестов корректны и все
Отчет о квалификационном тестировании ПО
расхождения объяснены
Результаты верификации ПО
Тестовое покрытие требований верхнего
Отчет о квалификационном тестировании ПО
уровня достигнуто
Результаты верификации ПО
Тестовое покрытие требований нижнего
уровня достигнуто
Результаты верификации ПО
Тестовое покрытие структуры ПО
(модифицированное покрытие
условий/решений) достигнуто
Результаты верификации ПО
Тестовое покрытие структуры ПО
(покрытие решений) достигнуто

28.

Продолжение таблицы 2.1
Цель
Результат
Результаты верификации ПО
Тестовое покрытие структуры ПО
(покрытие операторов) достигнуто
Тестовое покрытие структуры ПО (связи по Результаты верификации ПО
управлению и связи по данным) достигнуто
Процесс управления конфигурацией ПО
Протоколы управления конфигурацией ПО
Элементы конфигурации
идентифицированы
Указатель конфигурации ПО
Установлены базовая линия и
трассируемость
Протоколы управления конфигурацией ПО
Установлены отчетность о дефектах,
Сообщения о дефектах
просмотры изменений, регистрация
Протоколы управления конфигурацией ПО
состояния конфигурацией
Установлены архивирование, получение из Протоколы управления конфигурацией ПО
архива и выпуск версии
Установлено управление загрузкой ПО
Протоколы управления конфигурацией ПО
Установлен контроль среды жизненного
Указатель конфигурации среды жизненного цикла
ПО
цикла ПО
Протоколы управления конфигурацией ПО
Процесс обеспечения качества ПО
Обеспечена уверенность в том, что
Протоколы обеспечения качества ПО
процессы разработки ПО и интегральные
процессы соответствуют утвержденным
планам и стандартам ПО
Обеспечена уверенность, что
Протоколы обеспечения качества ПО
удовлетворены критерии переходов между
процессами жизненного цикла ПО
Выполнен просмотр соответствия ПО
Протоколы обеспечения качества ПО
Процесс сертификационного сопровождения ПО
Установлено взаимодействие и
План сертификации в части ПО
взаимопонимание между соискателем и
сертифицирующей организацией
Предложены средства достижения согласия План сертификации в части ПО
и достигнута согласованность с Планом
сертификации в части ПО
Итоговый документ разработки ПО
Представлены доказательства
согласованности
Указатель конфигурации ПО