---
title: "\"ГОСТ Р ИСО/МЭК 27034-5-2020. Национальный стандарт Российской Федерации. Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 5. Структуры данных протоколов и мер обеспечения безопасности приложений\""
number: "ГОСТ Р ИСО/МЭК 27034-5-2020"
issuer: "Федеральное агентство по техническому регулированию и метрологии"
status: действует
canonical: "https://bukva.ai/docs/standart-gost-r-isomek-27034-5-2020"
---

## "ГОСТ Р ИСО/МЭК 27034-5-2020. Национальный стандарт Российской Федерации. Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 5. Структуры данных протоколов и мер обеспечения безопасности приложений"

# "ГОСТ Р ИСО/МЭК 27034-5-2020. Национальный стандарт Российской Федерации. Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 5. Структуры данных протоколов и мер обеспечения безопасности приложений"

(утв. и введен в действие Приказом Росстандарта от 10.11.2020 N 1043-ст)

> [!IMPORTANT]
> Документ [введен](#p100012) в действие с 01.06.2021.


<div align="right">

<a id="p100001"></a>Утвержден и введен в действие<br>
Приказом Федерального агентства<br>
по техническому регулированию<br>
и метрологии<br>
от 10 ноября 2020 г. N 1043-ст

</div>


<div align="center">

<a id="p100002"></a>**НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ**

<a id="p100003"></a>**ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ**

<a id="p100004"></a>**МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ**

<a id="p100005"></a>**БЕЗОПАСНОСТЬ ПРИЛОЖЕНИЙ**

<a id="p100006"></a>**ЧАСТЬ 5**

<a id="p100007"></a>**СТРУКТУРЫ ДАННЫХ ПРОТОКОЛОВ И МЕР ОБЕСПЕЧЕНИЯ**<br>
**БЕЗОПАСНОСТИ ПРИЛОЖЕНИЙ**

<a id="p100008"></a>**Information technology. Security techniques. Application**<br>
**security. Part 5. Protocols and application security**<br>
**controls data structure**

<a id="p100009"></a>**(ISO/IEC 27034-5:2017, IDT)**

<a id="p100010"></a>**ГОСТ Р ИСО/МЭК 27034-5-2020**

</div>


<div align="right">

<a id="p100011"></a>ОКС 35.030

<a id="p100012"></a>Дата введения

</div>

1 июня 2021 года

<div align="center">

<a id="p100013"></a>**Предисловие**

</div>


<a id="p100014"></a>1 ПОДГОТОВЛЕН Федеральным государственным учреждением "Федеральный исследовательский центр "Информатика и управление" Российской академии наук" (ФИЦ ИУ РАН) и Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в [пункте 4](#p100017)
<a id="p100015"></a>2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
<a id="p100016"></a>3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 10 ноября 2020 г. N 1043-ст
<a id="p100017"></a>4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 27034-5:2017 "Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 5. Структуры данных протоколов и мер обеспечения безопасности приложений" (ISO/IEC 27034-5:2017 "Information technology - Security techniques - Application security - Part 5: Protocols and application security controls data structure", IDT).
<a id="p100018"></a>ИСО/МЭК 27034-5 подготовлен подкомитетом 27 "Методы и средства обеспечения безопасности" Совместного технического комитета ИСО/МЭК СТК 1 "Информационные технологии".
<a id="p100019"></a>При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном [приложении ДА](#p100763)
<a id="p100020"></a>5 ВВЕДЕН ВПЕРВЫЕ
<a id="p100021"></a>6 Некоторые положения международного документа, указанного в [пункте 4](#p100017), могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

<a id="p100022"></a>Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

<div align="center">

<a id="p100023"></a>**Введение**

</div>


<a id="p100024"></a>Общая информация
<a id="p100025"></a>В настоящее время организации сталкиваются с постоянно растущей потребностью уделять внимание защите информации на уровне приложений. Систематический подход к повышению уровня защиты приложений дает организациям основания полагать, что информация, используемая или хранимая приложениями, надежно защищена.
<a id="p100026"></a>Все части ИСО/МЭК 27034 описывают понятия, принципы, структуры, компоненты и процессы в целях помощи организациям последовательно интегрировать средства и механизмы безопасности на протяжении жизненного цикла приложений.
<a id="p100027"></a>Ключевыми компонентами настоящего стандарта являются меры обеспечения безопасности приложений (МОБП).
<a id="p100028"></a>Для облегчения внедрения комплексов мер защиты приложений, а также механизмов передачи и обмена МОБП, описанных в ИСО/МЭК 27034 (все части), требуется задокументировать и объяснить минимальный набор наиболее важных атрибутов для реализации МОБП и других определенных компонентов этой структуры.
<a id="p100029"></a>В настоящем стандарте описывается минимальный набор наиболее важных атрибутов МОБП, а также даются дополнительные сведения об эталонной модели жизненного цикла безопасности приложений (ЭМЖЦБП).
<a id="p100030"></a>Назначение
<a id="p100031"></a>В настоящем стандарте представлены основные сведения и требования к структуре данных МОБП. Наличие стандартизированного набора основных атрибутов информации и структуры данных МОБП имеет следующие преимущества:
<a id="p100032"></a>a) нормализация процессов создания, передачи, защиты и верификации МОБП в соответствии с требованиями настоящего стандарта;
<a id="p100033"></a>b) снижение затрат на безопасность в проектах приложений до минимума путем облегчения повторного использования одобренных мер обеспечения безопасности, а также получения МОБП из разных источников.
<a id="p100034"></a>Кроме того, в настоящем стандарте определяются и подробно описываются процессы, мероприятия и должностные роли внутри эталонной модели жизненного цикла безопасности приложений (ЭМЖЦБП).
<a id="p100035"></a>Целевая аудитория
<a id="p100036"></a>Общая информация
<a id="p100037"></a>Настоящий стандарт полезен для следующих групп лиц при осуществлении своих ролей в организации:
<a id="p100038"></a>a) [руководители](#p100043);
<a id="p100039"></a>b) [группа нормативной структуры организации](#p100047) (группа НСО);
<a id="p100040"></a>c) [эксперты в предметной области](#p100052);
<a id="p100041"></a>d) [поставщики](#p100057);
<a id="p100042"></a>e) [приобретающие стороны](#p100061).
<a id="p100043"></a>Руководители
<a id="p100044"></a>Руководителям необходимо ознакомиться с настоящим стандартом, поскольку в их обязанности входит:
<a id="p100045"></a>a) обеспечение возможности повторного использования МОБП внутри организации;
<a id="p100046"></a>b) обеспечение доступности МОБП, а также их передача и использование в проектах приложений с помощью надлежащих инструментов и процедур во всей организации.
<a id="p100047"></a>Группа НСО
<a id="p100048"></a>Группа НСО несет ответственность за управление, внедрение и обслуживание компонентов и процессов, связанных с безопасностью приложений, в нормативной базе организации. В обязанности группы НСО входят следующие мероприятия:
<a id="p100049"></a>a) внедрение библиотеки МОБП;
<a id="p100050"></a>b) утверждение МОБП, которые адекватно снижают угрозы безопасности приложений;
<a id="p100051"></a>c) управление затратами на внедрение и сопровождение МОБП.
<a id="p100052"></a>Эксперты в предметной области
<a id="p100053"></a>Эксперты в предметной области обеспечивают знания, необходимые для подготовки к работе, эксплуатации и аудита приложений. В обязанности экспертов входят следующие мероприятия:
<a id="p100054"></a>a) участие в разработке, валидации и верификации МОБП;
<a id="p100055"></a>b) участие во внедрении и сопровождении МОБП, предлагая стратегии, компоненты и процессы внедрения для встраивания МОБП в условиях организации;
<a id="p100056"></a>c) подтверждение пригодности и полезности МОБП для применения в прикладных проектах.
<a id="p100057"></a>Поставщики инструментов обеспечения безопасности и МОБП
<a id="p100058"></a>Поставщики содействуют разработке, обслуживанию и распространению инструментов и (или) МОБП. В обязанности поставщиков входят следующие мероприятия:
<a id="p100059"></a>a) создание, проверка, обеспечение целостности (с помощью принятых методов, например, подписания), распространение и применение МОБП;
<a id="p100060"></a>b) действия в соответствии с общим и стандартизированным протоколом (структура и формат) обмена МОБП.
<a id="p100061"></a>Приобретатель инструментов обеспечения безопасности и МОБП
<a id="p100062"></a>Приобретающей стороной являются физические или юридические лица, которые хотят получить МОБП. В обязанности приобретающей стороны входят следующие мероприятия:
<a id="p100063"></a>a) интегрирование МОБП в структуре организации и обеспечение взаимодействия любых внутренних и сторонних МОБП;
<a id="p100064"></a>b) адаптация и обеспечение целостности МОБП;
<a id="p100065"></a>c) обеспечение соответствия задач и мероприятий, связанных с приобретенными МОБП, и жизненного цикла приложения организации.

<a id="p100066"></a>**1 Область применения**

<a id="p100067"></a>Настоящий стандарт содержит сведения о минимальном наборе основных атрибутов МОБП, а также описывает мероприятия и роли в рамках эталонной модели жизненного цикла безопасности приложений (ЭМЖЦБП).

<a id="p100068"></a>**2 Нормативные ссылки**

<a id="p100069"></a>В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения).
<a id="p100070"></a>ИСО/МЭК 27034-1, Information technology - Information technology - Security techniques - Application security - Part 1: Overview and concepts (Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия)

<a id="p100071"></a>**3 Термины и определения**

<a id="p100072"></a>В настоящем стандарте используются термины и определения по ИСО/МЭК 27034-1, а также следующие термины и определения.
<a id="p100073"></a>ИСО и МЭК ведут терминологические базы данных для использования в стандартизации по следующим адресам:
- <a id="p100074"></a>просмотр ISO Online: доступ по адресу https://www.iso.org/obp;
- <a id="p100075"></a>IEC Electropedia: доступно по адресу http://www.electropedia.org/.
<a id="p100076"></a>3.1 мероприятие (activity): Набор действий или задач, выполняемых действующим субъектом в течение жизненного цикла приложения.
<a id="p100077"></a>3.2 информационная группа (information group): Список информационных элементов, которым организация может присвоить обозначения, например имена, описания и значения категорий.
<a id="p100078"></a>*Примечание* - Во избежание путаницы, название информационной группы внутри организации должно быть уникальным.

<a id="p100079"></a>3.3 информационный элемент (information element): Часть информации, которую необходимо классифицировать и идентифицировать по имени, описанию и значению домена (например, полю в базе данных).
<a id="p100080"></a>*Примечание* - Информационная группа может рассматриваться как информационный элемент.

<a id="p100081"></a>**4 Обозначения и сокращения**


| <a id="p100082"></a>МОБП | <a id="p100083"></a>Меры обеспечения безопасности приложений (ASC) |
| --- | --- |
| <a id="p100084"></a>ЖЦБП | <a id="p100085"></a>Жизненный цикл безопасности приложения (ASLC) |
| <a id="p100086"></a>ЭМЖЦБП | <a id="p100087"></a>Эталонная модель жизненного цикла безопасности приложения (ASLCRM) |
| <a id="p100088"></a>ИКТ | <a id="p100089"></a>Информационно-коммуникационные технологии (ICT) |
| <a id="p100090"></a>НСО | <a id="p100091"></a>Нормативная структура организации (ONF) |


<a id="p100092"></a>5 Структура мер обеспечения безопасности приложений


#### <a id="p100093"></a>5.1 Общая информация

<a id="p100094"></a>Каждая МОБП определяет мероприятия, связанные с безопасностью, которые проводятся в определенной точке жизненного цикла приложения с целью снизить угрозу безопасности или удовлетворить определенное требование. Мероприятие по обеспечению безопасности дополняется верификационными измерениями, которые определяют действия, необходимые для подтверждения успеха осуществления этого мероприятия. В отношении мероприятия по обеспечению безопасности и верификационных измерений МОБП устанавливают, как, где, когда и кем должно быть проведено мероприятие. Также указывается информация о требуемых действиях.
<a id="p100095"></a>В данном разделе описываются информационные требования к МОБП и даются рекомендации относительно структуры данных. Организации могут реализовать информационные требования, а также требования к структуре данных в виде описания или любой другой подходящей структуры данных, которая лучше всего соответствует требованиям и нуждам организации.
<a id="p100096"></a>Примечания
<a id="p100097"></a>1 Для установки минимального набора атрибутов, необходимых для определения эффективных МОБП, название каждого атрибута МОБП, определяемого в настоящем стандарте, снабжено пометкой (О), если атрибут является обязательным, или (Н), если атрибут является необязательным.
<a id="p100098"></a>2 Включение необязательных атрибутов может потребовать реализации последующих обязательных атрибутов. Обязательные атрибуты, связанные с необязательными, должны использоваться, только если эти необязательные атрибуты применяются (для примера см. [5.2.4.2, e)](#p100221).

<a id="p100099"></a>**Цель данного раздела состоит в том, чтобы предоставить перечень возможных мероприятий, с помощью которых группа НСО может внедрить МОБП в ЭМЖЦБП.**
<a id="p100100"></a>При описании активов разработчики МОБП должны пользоваться терминологией, соответствующей всем частям ИСО/МЭК 27034.

#### <a id="p100101"></a>5.2 Информационные требования к МОБП


##### <a id="p100102"></a>5.2.1 Общие сведения

<a id="p100103"></a>Подраздел 5.2 определяет рекомендованные информационные требования к отдельным мерам и средствам контроля и управления безопасностью приложения. Конкретная реализация настоящего стандарта в формате XML-схемы приведена в ИСО/МЭК 27034-5-1.
<a id="p100104"></a>Следует отметить, что настоящий стандарт не определяет, как идентифицируются или управляются различные информационные элементы МОБП. Подробная информация о последних приведена в описании процессов управления и аудита в ИСО/МЭК 27034-2, ИСО/МЭК 27034-3 и ИСО/МЭК 27034-4.
<a id="p100105"></a>*Примечание* - Четкое указание на иерархию наследования в настоящий момент не реализовано в структуре МОБП, но может быть внедрено в будущих версиях.

<div align="center">

<a id="p100106"></a>Основные разделы информации МОБП показаны на [рисунке 1](#p100108).

</div>


<a id="p100107"></a> ![рис. 1](https://i.bukva.ai/fYlMD6Tq/img_0.png) 

<a id="p100108"></a>Рисунок 1 - Основные разделы информации МОБП

<a id="p100109"></a>Как определено в 8.1.2.6.5 ИСО/МЭК 27034-1:2011 и показано на [рисунке 1](#p100108), каждое описание МОБП должно содержать следующие разделы:
<a id="p100110"></a>a) идентификация МОБП (О): этот раздел должен содержать следующую информацию:
1) <a id="p100111"></a>идентификационную информацию об МОБП (идентификатор, имя и т.д.),
2) <a id="p100112"></a>высокоуровневое описание области и цели применения МОБП,
3) <a id="p100113"></a>информацию о текущей версии, в том числе дату создания, текущий этап жизненного цикла, примечания о внесенных изменениях и идентификационную информацию об авторе и владельце,
4) <a id="p100114"></a>ссылки на МОБП, находящиеся выше и ниже по иерархии;
<a id="p100115"></a>b) цель применения МОБП (О): этот раздел должен содержать следующую информацию:
1) <a id="p100116"></a>детальное описание целей применения МОБП для обеспечения безопасности,
2) <a id="p100117"></a>указание на одно или несколько требований по обеспечению защиты, которые обосновывают необходимость МОБП, а также информацию о контексте и функциях приложения, для которых необходима защита,
3) <a id="p100118"></a>описание одного или нескольких уровней доверия, для которых МОБП является обязательным, вместе с описанием диапазона уровня доверия,
4) <a id="p100119"></a>предварительные условия и критерии для применения МОБП, в частности:
<a id="p100120"></a>i) список предварительных условий;
<a id="p100121"></a>ii) список предполагаемых угроз безопасности (неформальный);
<a id="p100122"></a>iii) описание среды эксплуатации (контекста использования);
<a id="p100123"></a>c) мероприятия по обеспечению безопасности, связанные с применением МОБП (О): этот раздел должен содержать информацию, касающуюся мероприятий по обеспечению безопасности, связанных с МОБП:
1) <a id="p100124"></a>высокоуровневое описание мероприятия по обеспечению безопасности (что),
2) <a id="p100125"></a>описание актива, защищаемого (целевого) с помощью мероприятия (где),
3) <a id="p100126"></a>определение ролей (и требуемой квалификации) сотрудников, вовлеченных в выполнение задач и действий в рамках мероприятия (кто),
4) <a id="p100127"></a>указание сложности и стоимости мероприятий по обеспечению безопасности (сколько),
5) <a id="p100128"></a>детальное описание задач и действий в рамках мероприятия по обеспечению безопасности, ожидаемые результаты и предварительные условия (как),
6) <a id="p100129"></a>указание того, когда (согласно эталонной модели жизненного цикла безопасности приложения) должны быть выполнены задачи и действия в рамках мероприятия по обеспечению безопасности (когда);
<a id="p100130"></a>d) верификационные измерения, связанные с МОБП (О): этот раздел должен содержать информацию, касающуюся верификационных измерений, связанных с МОБП:
1) <a id="p100131"></a>высокоуровневое описание верификационных измерений (что),
2) <a id="p100132"></a>описание актива, в отношении которого проводятся верификационные измерения (где),
3) <a id="p100133"></a>определение ролей (и требуемой квалификации) сотрудников, вовлеченных в верификационные измерения в рамках мероприятия (кто),
4) <a id="p100134"></a>указание сложности и стоимости верификационных измерений (сколько),
5) <a id="p100135"></a>детальное описание задач и действий в рамках мероприятия по верификации, ожидаемые результаты и предварительные условия (как),
6) <a id="p100136"></a>указание того, когда (согласно эталонной модели жизненного цикла безопасности приложения) должны быть выполнены задачи и действия в рамках мероприятия по верификации (когда).
<a id="p100137"></a>[Пункт 5.2.4](#p100142) содержит дополнительные сведения о каждом требовании к информации.

##### <a id="p100138"></a>5.2.2 Обеспечение целостности

<a id="p100139"></a>Для обеспечения целостности содержимого МОБП, необходимо использовать механизм подписей (или аналогичный принятый метод). Меры и средства контроля и управления безопасностью приложений должны поддерживать каскадные и множественные электронные подписи, а также временные отметки.

##### <a id="p100140"></a>5.2.3 Представление данных на нескольких языках или для нескольких регионов

<a id="p100141"></a>В целях обеспечения распространения МОБП по всему миру, их структура данных должна поддерживать локализацию текста и описание различных информационных элементов, процессов или информационно-коммуникационных технологий на разных языках.

##### <a id="p100142"></a>5.2.4 Требования к информации, связанной с МОБП


###### <a id="p100143"></a>5.2.4.1 Идентификация (О)

<div align="center">

<a id="p100144"></a>На [рисунке 2](#p100146) показан раздел идентификации МОБП.

</div>


<a id="p100145"></a> ![рис. 2](https://i.bukva.ai/fYlMD6Tq/img_1.png) 

<div align="center">

<a id="p100146"></a>Рисунок 2 - Раздел идентификации МОБП

</div>


<a id="p100147"></a>Как показано на [рисунке 2](#p100146), описание МОБП должно содержать следующие сведения:
<a id="p100148"></a>a) идентифицирующая информация об МОБП, в том числе:
1) <a id="p100149"></a>уникальный идентификатор (О): уникальный идентификатор внутри схемы,
2) <a id="p100150"></a>имя (О): соответствующее имя;
<a id="p100151"></a>b) описание (О): высокоуровневое описание целей и области применения МОБП;
<a id="p100152"></a>c) версия (О): информация, описывающая версию МОБП, в том числе:
1) <a id="p100153"></a>номер (О): текущий номер версии МОБП в допустимых числах (например, 0.1.1 или 1.2),
2) <a id="p100154"></a>дата (О): дата создания текущей версии МОБП,
3) <a id="p100155"></a>стадия жизненного цикла (О): текущая стадия жизненного цикла МОБП. Допустимы следующие значения стадии жизненного цикла:
<a id="p100156"></a>i) запрос на создание;
<a id="p100157"></a>ii) проектирование;
<a id="p100158"></a>iii) анализ и валидация проекта;
<a id="p100159"></a>iv) разработка;
<a id="p100160"></a>v) верификация;
<a id="p100161"></a>vi) утверждение;
<a id="p100162"></a>vii) окончательное утверждение владельцами;
<a id="p100163"></a>viii) публикация для обучения;
<a id="p100164"></a>ix) активно;
<a id="p100165"></a>x) срок действия истек;
<a id="p100166"></a>xi) собственное значение;
4) <a id="p100167"></a>указание степени зрелости (Н): указание уровня готовности этой версии,
5) <a id="p100168"></a>записи об изменениях (Н): описание того, как изменились МОБП по сравнению с предыдущей версией;
<a id="p100169"></a>d) автор (Н): авторы текущей версии МОБП и указание их принадлежности, в том числе имена и контактная информация;
<a id="p100170"></a>e) владелец (Н): владельцы текущей версии МОБП и указание их принадлежности, в том числе имена и контактная информация;
<a id="p100171"></a>f) взаимосвязи между подчиненными и подчиняющими МОБП определяются, как показано на [рисунке 3](#p100175):
1) <a id="p100172"></a>подчиненность (О): ссылки на отсутствующие, один или несколько уникальных идентификационных номеров подчиненных МОБП с целью указать, что выполнение мероприятий, связанных со всеми подчиненными (дочерними) МОБП (в определенном порядке) является необходимым условием для завершения мероприятий, связанных с подчиняющими МОБП. Допускается включать краткое описание МОБП, на которые указывают ссылки,
2) <a id="p100173"></a>подчинение (О): ссылка на отсутствующие, один или несколько уникальных идентификационных номеров подчиняющих МОБП с целью указать материнские МОБП. Допускается включать краткое описание материнских МОБП, на которые указывают ссылки.

<a id="p100174"></a> ![рис. 3](https://i.bukva.ai/fYlMD6Tq/img_2.jpg) 

<div align="center">

<a id="p100175"></a>Рисунок 3 - Взаимосвязи между МОБП

</div>



###### <a id="p100176"></a>5.2.4.2 Цели

<div align="center">

<a id="p100177"></a>Раздел с описанием целей МОБП показан на [рисунке 4](#p100179).

</div>


<a id="p100178"></a> ![рис. 4](https://i.bukva.ai/fYlMD6Tq/img_3.png) 

<div align="center">

<a id="p100179"></a>Рисунок 4 - Раздел с описанием целей МОБП

</div>


<a id="p100180"></a>Как показано на [рисунке 4](#p100179), описание МОБП должно содержать следующие сведения, касающиеся целей по обеспечению безопасности:
<a id="p100181"></a>a) описание (О): детальное описание целей и задач по обеспечению безопасности, решаемых МОБП;
<a id="p100182"></a>b) удовлетворяемые требования к безопасности (О): непустой набор требований, удовлетворяемых с помощью выполнения мероприятий по обеспечению безопасности, связанных с МОБП (см. [рисунок 5](#p100184)). Для каждого требования необходимо собрать следующую информацию:

<a id="p100183"></a> ![рис. 5](https://i.bukva.ai/fYlMD6Tq/img_4.png) 

<div align="center">

<a id="p100184"></a>Рисунок 5 - Раздел с описанием требований по обеспечению<br>
безопасности, связанных с МОБП

</div>


1) <a id="p100185"></a>контекст (Н): определяет контекст (источник), исходя из которого возникли требования. Допустимы следующие значения типа контекста:
<a id="p100186"></a>i) нормативные документы;
<a id="p100187"></a>ii) бизнес-контекст;
<a id="p100188"></a>iii) технологический контекст;
<a id="p100189"></a>iv) функциональность приложения;
<a id="p100190"></a>v) собственное значение;
2) <a id="p100191"></a>тип (Н): тип требований по обеспечению безопасности. Допустимы следующие значения:
<a id="p100192"></a>i) требования бизнеса;
<a id="p100193"></a>ii) правила бизнеса;
<a id="p100194"></a>iii) требования нормативных документов;
<a id="p100195"></a>iv) пользовательские требования;
<a id="p100196"></a>v) требования к квалификации действующих субъектов;
<a id="p100197"></a>vi) атрибуты качества;
<a id="p100198"></a>vii) системные требования;
<a id="p100199"></a>viii) требования к процессу;
<a id="p100200"></a>ix) функциональные требования;
<a id="p100201"></a>x) внешние интерфейсы;
<a id="p100202"></a>xi) требования к инфраструктуре;
<a id="p100203"></a>xii) ограничения;
<a id="p100204"></a>xiii) собственное значение;
3) <a id="p100205"></a>имя (О): соответствующее имя для требования,
4) <a id="p100206"></a>описание (О): качественное описание для требования,
5) <a id="p100207"></a>источник (Н): исходный документ, являющийся источником требования;
<a id="p100208"></a>c) присвоенные уровни доверия (О): список одного или нескольких уровней доверия, для которых МОБП являются обязательными. Чтобы описание МОБП содержало всю информацию, необходимо добавить к ней сведения о диапазоне уровней доверия, которые описывают соответствующие уровни доверия и показывают преимущества каждого из них;
<a id="p100209"></a>d) условие (Н): описание предварительных условий, предположений и контекста использования для применения МОБП, как показано на [рисунке 6](#p100211):

<a id="p100210"></a> ![рис. 6](https://i.bukva.ai/fYlMD6Tq/img_5.png) 

<div align="center">

<a id="p100211"></a>Рисунок 6 - Раздел с описанием условий, связанных с МОБП

</div>


1) <a id="p100212"></a>тип условия (Н): тип условия. Допустимы следующие значения:
<a id="p100213"></a>i) предварительное условие;
<a id="p100214"></a>ii) предположение;
<a id="p100215"></a>iii) описание среды эксплуатации;
<a id="p100216"></a>iv) собственное значение;
2) <a id="p100217"></a>описание (О): может включать следующие сведения:
<a id="p100218"></a>i) список предварительных условий для использования МОБП;
<a id="p100219"></a>ii) список (неофициальный) предполагаемых угроз безопасности, которые можно смягчить с помощью МОБП;
<a id="p100220"></a>iii) описание среды эксплуатации (контекста использования);

<div align="center">

<a id="p100221"></a>e) диапазон уровней доверия (Н) (см. [рисунок 7](#p100223)):

</div>


<a id="p100222"></a> ![рис. 7](https://i.bukva.ai/fYlMD6Tq/img_6.png) 

<div align="center">

<a id="p100223"></a>Рисунок 7 - Секция с описанием диапазона<br>
уровней доверия, связанная с МОБП

</div>


<a id="p100224"></a>Когда существует диапазон уровней доверия, связанный с МОБП, следующая информация, как показано на [рисунке 7](#p100223), должна описывать каждый уровень доверия, включенный в диапазон:
1) <a id="p100225"></a>уникальный идентификационный номер уровня доверия (О): уникальный идентификационный номер в схеме для этого уровня доверия,
2) <a id="p100226"></a>имя (О): имя уровня доверия,
3) <a id="p100227"></a>обозначение (О): обозначение, представляющее этот уровень доверия,
4) <a id="p100228"></a>описание (О): краткое описание уровня доверия с целью помочь приобретателю или получателю интегрировать этот МОБП на нужном уровне библиотеки МОБП приобретателя;
<a id="p100229"></a>f) указатель возможности прогнозирования (Н): определяет, допускается ли прогнозирование для МОБП. То есть необходимо ли будет подтверждать корректное функционирование МОБП повторно, если контекст эксплуатации изменится в незначительной степени. Более подробная информация приведена в ИСО/МЭК 27034-7.

###### <a id="p100230"></a>5.2.4.3 Мероприятие по обеспечению безопасности и верификационное измерение

<a id="p100231"></a>Описание МОБП должно содержать сведения об одном мероприятии по обеспечению безопасности и связанном с ним верификационном измерении. Мероприятие по обеспечению безопасности определяет набор задач и действий, которое необходимо выполнить, чтобы удовлетворить требованиям безопасности, связанным с МОБП. Верификационное измерение определяет задачи и действия, которые необходимо осуществить, чтобы убедиться, что требования безопасности, связанные с МОБП, удовлетворены (см. [рисунок 8](#p100233)).

<a id="p100232"></a> ![рис. 8](https://i.bukva.ai/fYlMD6Tq/img_7.png) 

<div align="center">

<a id="p100233"></a>Рисунок 8 - Разделы, описывающие мероприятие по обеспечению<br>
безопасности и верификационное измерение, связанное с МОБП

</div>


<a id="p100234"></a>Как показано на [рисунке 8](#p100233), описание МОБП должно содержать следующую информацию, касающуюся мероприятия по обеспечению безопасности и верификационного измерения:
<a id="p100235"></a>a) краткое содержание (О): краткое описание данного мероприятия. При этом должна присутствовать следующая информация:
1) <a id="p100236"></a>имя (О): название мероприятия,
2) <a id="p100237"></a>описание (О): неофициальное описание масштаба мероприятия, в том числе охвата и планируемого результата,
3) <a id="p100238"></a>информация о цели (О): указатель на масштаб мероприятия. Определяет, какая группа информационных элементов находится под защитой или верифицируется с помощью мероприятия в результате применения МОБП в отношении людей, процессов или информационно-коммуникационных технологий, взаимодействующих с этими информационными элементами. Чтобы связанное с МОБП мероприятие было действенным и полезным, необходимо, чтобы по крайней мере один информационный элемент был под защитой или верифицировался МОБП. Для каждого информационного элемента предусмотрены следующие сведения:
<a id="p100239"></a>i) имя (О): соответствующее имя для информационного элемента, процессов или ИКТ;
<a id="p100240"></a>ii) тип информационной группы (О): связывает один или несколько типов с информационным элементом, процессами или ИКТ. Допустимы следующие значения:
<a id="p100241"></a>I) законы и нормы;
<a id="p100242"></a>II) директивы и нормы, связанные с организацией или направлением бизнеса;
<a id="p100243"></a>III) процессы жизненного цикла приложения;
<a id="p100244"></a>IV) определение процесса приложения;
<a id="p100245"></a>V) спецификация;
<a id="p100246"></a>VI) данные приложения;
<a id="p100247"></a>VII) организация и данные пользователя;
<a id="p100248"></a>VIII) описание полномочий для разных ролей;
<a id="p100249"></a>IX) определение технологического контекста;
<a id="p100250"></a>X) собственное значение;
<a id="p100251"></a>iii) описание (О): описание информационного элемента, процессов или ИКТ;
<a id="p100252"></a>iv) классификация информации (Н): указание того, насколько чувствительным (применительно к конфиденциальности, целостности и доступности) является информационный элемент;
<a id="p100253"></a>v) владелец информации (Н): указывает на владельца информационного элемента;
4) <a id="p100254"></a>описание результата (О): описание ожидаемого результата мероприятия,
5) <a id="p100255"></a>дополнительные экспертные ресурсы (Н): ссылки на дополнительные (экспертные) ресурсы, призванные облегчить выполнение мероприятия;
<a id="p100256"></a>b) сложность мероприятия (О): указание сложности мероприятия с применением качественных и количественных измерений.
<a id="p100257"></a>*Примечание* - Атрибут, указывающий на сложность мероприятия, является обязательным (О), если существует атрибут спецификация мероприятия.

<a id="p100258"></a>c) при этом должна присутствовать следующая информация:
1) <a id="p100259"></a>обозначение (О): обозначение, указывающее на сложность. Допустимы следующие значения сложности:
<a id="p100260"></a>i) низкая;
<a id="p100261"></a>ii) средняя;
<a id="p100262"></a>iii) высокая;
<a id="p100263"></a>iv) чрезвычайно высокая;
<a id="p100264"></a>v) собственное значение;
2) <a id="p100265"></a>описание (О): описание сложности,
3) <a id="p100266"></a>общие сметные расходы (Н): прогнозируемая (в денежном исчислении) стоимость мероприятия,
4) <a id="p100267"></a>общие показатели требуемых усилий (Н): объем усилий, необходимый для проведения мероприятия (например, дни/число сотрудников),
5) <a id="p100268"></a>предполагаемое время (Н): время, необходимое для осуществления мероприятия,
6) <a id="p100269"></a>примечание (Н): дополнительная информация о сложности мероприятия;
<a id="p100270"></a>d) спецификация мероприятия (Н): детальное описание мероприятия.
<a id="p100271"></a>Примечание - Атрибут спецификация мероприятия является необязательным (Н), поскольку он не нужен, когда МОБП является "главным МОБП" в иерархии МОБП (см. рисунок 7 в подпункте 8.1.2.6.5 ИСО/МЭК 27034-1:2011) (см. [рисунок 3](#p100175)). В противном случае он необходим.

<a id="p100272"></a>Каждая спецификация мероприятия содержит атрибут Используемая матрица обязанностей (О), определяющий тип матрицы обязанностей, используемой в описании этого мероприятия. Допустимы следующие значения:
1) <a id="p100273"></a>RACI <1>,
2) <a id="p100274"></a>RASCI <2>.

<a id="p100275"></a>

---

<a id="p100276"></a><1> RACI - Схема "Ответственность, подотчетность, консультирование, информирование" (ОПКИ) для обозначения ролей и обязанностей при выполнении действий в бизнес-процессах.
<a id="p100277"></a><2> RASCI - Схема "Ответственность, подотчетность, поддержка, консультирование, информирование" (ОППКИ) для обозначения ролей и обязанностей при выполнении действий в бизнес-процессах.

<a id="p100278"></a>Для описания обязанностей допускается использовать следующие обозначения:
1) <a id="p100279"></a>исполняет;
2) <a id="p100280"></a>несет ответственность;
3) <a id="p100281"></a>оказывает сопровождение;
4) <a id="p100282"></a>консультирует;
5) <a id="p100283"></a>получает уведомления.
<a id="p100284"></a>Каждая спецификация мероприятия включает последовательность задач (О) в определенном порядке. Каждая задача должна содержать следующую информацию:
1) <a id="p100285"></a>очередность (Н): номер в очереди выполнения, по которому задачи в рамках мероприятия выстраиваются в правильный порядок;
2) <a id="p100286"></a>описание (О): описание задачи;
3) <a id="p100287"></a>предварительные условия (Н): набор предварительных условий (в том числе требований предшествования), которые должны быть удовлетворены перед выполнением задачи;
4) <a id="p100288"></a>требуемые ресурсы (О): ресурсы, используемые (и требуемые) для выполнения задачи. Для каждого случая выделения ресурсов предусмотрена следующая информация:
<a id="p100289"></a>i) имя роли (О): ссылка на роль, которую будет играть ресурс. Набор возможных ролей определяется ASLCRM (см. [6.6](#p100695)),
<a id="p100290"></a>ii) обязанность (О): обязанность RACI, принимаемая ролью в отношении задачи,
<a id="p100291"></a>iii) описание (Н): описание характера выделения ресурса,
<a id="p100292"></a>iv) требуемые квалификации (Н): список квалификаций, требуемых для того, чтобы сотрудник с определенной ролью мог взять на себя выполнение задач и действий в рамках мероприятия. Для каждой роли необходимо определить требуемые квалификации;
5) <a id="p100293"></a>моменты выполнения (О): указание на то, когда (относительно мероприятий в эталонной модели жизненного цикла безопасности приложений (см. [раздел 6](#p100346))) должна выполняться задача. Для каждого момента исполнения необходимо указать следующую информацию:
<a id="p100294"></a>i) порядок выполнения (О): порядок выполнения относительно указанного мероприятия. Допустимы следующие значения:
<a id="p100295"></a>I) до,
<a id="p100296"></a>II) во время,
<a id="p100297"></a>III) после,
<a id="p100298"></a>IV) собственное значение;
<a id="p100299"></a>ii) эталон жизненного цикла (О): ссылка на мероприятие в эталонной модели жизненного цикла безопасности приложений. Допустимые значения ролей определяются ЭМЖЦБП (см. [раздел 6](#p100346));
<a id="p100300"></a>iii) имя (Н): название мероприятия, если в модели жизненного цикла оно указано как "собственное";
<a id="p100301"></a>iv) описание (О): указание на то, когда будет выполняться задача;
<a id="p100302"></a>v) интервальное значение, единица измерения и обозначение (О): значение частоты выполнения задачи.
<a id="p100303"></a>I) Для описания внутреннего значения допускается использовать следующие единицы времени:
<a id="p100304"></a>i) секунды;
<a id="p100305"></a>ii) минуты;
<a id="p100306"></a>iii) часы;
<a id="p100307"></a>iv) дни;
<a id="p100308"></a>v) недели;
<a id="p100309"></a>vi) месяцы;
<a id="p100310"></a>vii) полугодия;
<a id="p100311"></a>viii) годы.
<a id="p100312"></a>II) Для описания интервалов допускается использовать следующие обозначения:
<a id="p100313"></a>i) один раз;
<a id="p100314"></a>ii) периодически;
<a id="p100315"></a>iii) по мере необходимости;
<a id="p100316"></a>iv) собственное значение.
6) <a id="p100317"></a>список действий (О): последовательность низкоуровневых элементарных описаний действий, которые необходимо выполнить, чтобы завершить задачу,
7) <a id="p100318"></a>результат (О): ожидаемый результат выполнения задачи, выраженный в артефактах, которые должны быть получены в результате выполнения задачи. Для каждого ожидаемого артефакта необходимо указать следующую информацию:
<a id="p100319"></a>i) тип (О): тип произведенного артефакта. Допустимы следующие значения:
<a id="p100320"></a>I) отчет;
<a id="p100321"></a>II) документ;
<a id="p100322"></a>III) исходный код;
<a id="p100323"></a>IV) скомпилированный код;
<a id="p100324"></a>V) исполняемый код;
<a id="p100325"></a>VI) сценарий;
<a id="p100326"></a>VII) библиотека;
<a id="p100327"></a>VIII) диаграмма;
<a id="p100328"></a>IX) файл параметров;
<a id="p100329"></a>X) ссылка;
<a id="p100330"></a>XI) собственное значение.
<a id="p100331"></a>ii) содержимое (О): ожидаемое содержимое произведенного артефакта.
8) <a id="p100332"></a>показатели объема усилий, необходимых для выполнения задачи (Н): прогнозируемый объем усилий на размещение ресурса в целях выполнения задачи,
9) <a id="p100333"></a>примечание (Н): дополнительная информация об этой задаче, если необходимо.

###### <a id="p100334"></a>5.2.4.4 Рекомендации по обеспечению содержания всех необходимых компонентов

<a id="p100335"></a>Во время операции импорта необходимо импортировать весь набор МОБП, т.е. все МОБП, связанные через иерархию, должны импортироваться вместе.
<a id="p100336"></a>**Аналогичным образом ссылки между МОБП, приобретенными у поставщика, должны быть включены в схему ссылок библиотеки МОБП приобретателя.**

#### <a id="p100337"></a>5.3 Рекомендации относительно структуры данных МОБП


##### <a id="p100338"></a>5.3.1 Общая информация

<a id="p100339"></a>Далее следует список рекомендаций относительно определения подходящей структуры данных для МОБП. Данные рекомендации призваны облегчить передачу и обмен МОБП, сохраняя их целостность.

##### <a id="p100340"></a>5.3.2 Обмен

<a id="p100341"></a>Для того чтобы способствовать широкому внедрению и совместному использованию МОБП, МОБП следует определять независимо от платформы и портативного способа. МОБП должны передаваться с помощью обозначений, описанных в ИСО/МЭК 27034-5-1.

##### <a id="p100342"></a>5.3.3 Содержание всех необходимых компонентов

<a id="p100343"></a>В целях обеспечения понимания и применения МОБП, не обращаясь к внешним документам, структура данных МОБП должна поддерживать включение сложных (нетекстовых) элементов данных, таких как документы, источник исполняемого кода и т.д.
<a id="p100344"></a>Для обеспечения понимания и использования МОБП без обращения к внешним документам, структура данных МОБП должна поддерживать возможность включения сложных (нетекстовых) элементов данных, таких как документы, источник исполняемого кода и т.д. Рекомендуется включить диапазон уровней доверия, на основании которых были определены рекомендуемые уровни доверия для МОБП.
<a id="p100345"></a>Определение и описание элемента в МОБП должны быть понятными без контекста, если используются стандартизированные схемы. Например, ИСО/МЭК 19770-5, ИСО/МЭК 19770-2.

<a id="p100346"></a>**6 Эталонная модель жизненного цикла безопасности приложения**


#### <a id="p100347"></a>6.1 Общая информация

<a id="p100348"></a>В разделе 6 приведена дополнительная информация и перечислены обозначения мероприятий, предложенные в ЭМЖЦБП, определенной в ИСО/МЭК 27034-1. Согласно [рисунку 9](#p100350), жизненный цикл приложения в основном состоит из двух стадий: создание и эксплуатация. Первая стадия подразделяется на фазы подготовки, реализации и ввода в действие. Вторая стадия делится на фазы использования и поддержки, архивирования и уничтожения. В каждой фазе выполняются мероприятия, связанные с подготовкой к работе, эксплуатацией и аудитом приложений, а также менеджментом инфраструктурой и менеджментом приложений. Для этого задействованы несколько субъектов. Дополнительная информация об обозначениях мероприятий и общие определения вовлеченных субъектов даны в [подразделах 6.2](#p100356) - [6.6](#p100695).

<a id="p100349"></a> ![рис. 9](https://i.bukva.ai/fYlMD6Tq/img_8.png) 

<div align="center">

<a id="p100350"></a>Рисунок 9 - Высокоуровневое представление эталонной модели<br>
жизненного цикла безопасности приложений

</div>


<a id="p100351"></a>Различные стадии, фазы и мероприятия, определенные в ЭМЖЦБП, должны использоваться в качестве эталона при описании МОБП с целью указать, когда мероприятие, связанное с МОБП, должно быть выполнено. Также действующие субъекты и роли, определенные в ЭМЖЦБП, должны использоваться в качестве ориентира при описании МОБП с целью указать, какие ресурсы должны быть выделены для выполнения мероприятий или задач, связанных с МОБП.
<a id="p100352"></a>На [рисунке 10](#p100354) элементы ЭМЖЦБП представлены в виде дерева, где элемент "Эталон жизненного цикла" является корневым, первый уровень представлен элементом "уровень", второй уровень - элементом "стадия", третий уровень - элементом "сфера мероприятий", четвертый уровень - элементом "часть сферы мероприятий", пятый уровень - элементом "обозначение мероприятия". Чтобы указать одно определенное обозначение мероприятия, в качестве момента исполнения можно выбрать путь, представленный в виде последовательности элементов (см. [5.2.4.3, d) 5)](#p100283) моменты выполнения).

<div align="center">

<a id="p100353"></a> ![рис. 10](https://i.bukva.ai/fYlMD6Tq/img_9.png) 

</div>


<a id="p100354"></a>Рисунок 10 - Обозначение мероприятия, выбранное из эталонной
**модели жизненного цикла безопасности приложений**

<a id="p100355"></a>В данном примере полная последовательность для определения обозначения мероприятия выглядит следующим образом: "Эталон жизненного цикла/Уровень инфраструктуры приложений/Стадия эксплуатации/Менеджмент инфраструктуры эксплуатации/.../Обозначение мероприятия".

#### <a id="p100356"></a>6.2 Уровень менеджмента приложений


##### <a id="p100357"></a>6.2.1 Общие положения

<div align="center">

<a id="p100358"></a>Процессы менеджмента приложений показаны на [рисунке 11](#p100360).

</div>


<a id="p100359"></a> ![рис. 11](https://i.bukva.ai/fYlMD6Tq/img_10.png) 

<a id="p100360"></a>Рисунок 11 - Процессы менеджмента приложений

<a id="p100361"></a>Примечание - На [рисунке 11](#p100360) элементы "Менеджмент подготовки приложений к работе" и "Менеджмент эксплуатации приложений" представляют две сферы мероприятий, а элементы "Инициирование", "Планирование", "Выполнение", "Мониторинг и контроль", а также "Завершение" представляют части внутри этих сфер мероприятий. Мероприятия, указанные внутри каждой части сферы, представлены на [рисунке 10](#p100354) с помощью элемента "Обозначение мероприятия" и перечислены в 6.2.1 - [6.5.6](#p100684).

<a id="p100362"></a>Уровень менеджмента приложений составляют процессы из предметной области менеджмента, выполняемые во время стадий подготовки к работе и эксплуатации приложений. Мероприятия в сфере менеджмента подготовки приложений выполняются проектными менеджерами и менеджерами организаций во время стадии подготовки приложения к работе. Мероприятия в сфере менеджмента эксплуатации приложений связаны с менеджментом и использованием приложения во время стадий эксплуатации. Как показано на [рисунке 11](#p100360), в соответствии с ИСО/МЭК 15288 обе стадии состоят из процессов инициирования, планирования, выполнения, мониторинга и контроля, а также завершения проектов.

##### <a id="p100363"></a>6.2.2 Инициирование

<a id="p100364"></a>Согласно ИСО/МЭК 15288, цель процесса инициирования проекта состоит в определении требований проекта, который предполагается выполнить. После того как требования проекта определены, необходимо установить степень осуществимости проекта, удостоверившись, что ресурсы (персонал, материалы, технологии и среды), необходимые для выполнения проекта и управления им, доступны и соответствуют требованиям. Также необходимо удостовериться, что отведенный период времени достаточен для выполнения проекта. В случае необходимости и по согласию всех участвующих сторон требования проекта могут быть изменены на этой стадии в целях его выполнения.
<a id="p100365"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100366"></a>a) разработка паспорта проекта приложения для его реализации;
<a id="p100367"></a>b) определение необходимых навыков;
<a id="p100368"></a>c) определение правообладателей;
<a id="p100369"></a>d) назначение владельца приложения;
<a id="p100370"></a>e) назначение архитектора приложения;
<a id="p100371"></a>f) назначение архитектора средств безопасности приложения;
<a id="p100372"></a>g) менеджмент знаний;
<a id="p100373"></a>h) развитие, приобретение или предоставление навыков;
<a id="p100374"></a>i) сопоставление жизненных циклов приложений, используемых в организации, с эталонной моделью.

##### <a id="p100375"></a>6.2.3 Планирование

<a id="p100376"></a>Согласно ИСО/МЭК 15288, цель проектного планирования заключается в подготовке планов для выполнения проекта. План, связанный с выполнением проекта, должен содержать описания связанных мероприятий, задач, а также описание программных продуктов, которые будут предоставлены.
<a id="p100377"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100378"></a>a) разработка плана менеджмента проекта;
<a id="p100379"></a>b) сбор требований;
<a id="p100380"></a>c) определение масштаба проекта;
<a id="p100381"></a>d) планирование мер по управлению рисками, связанными с безопасностью приложений;
<a id="p100382"></a>e) планирование мер по управлению рисками, связанными с проектом;
<a id="p100383"></a>f) создание структуры разделения работ;
<a id="p100384"></a>g) описание мероприятий;
<a id="p100385"></a>h) определение порядка выполнения мероприятий;
<a id="p100386"></a>i) оценка количества ресурсов, необходимых для выполнения мероприятий;
<a id="p100387"></a>j) оценка сроков проведения мероприятий;
<a id="p100388"></a>k) разработка графика работы;
<a id="p100389"></a>l) оценка стоимости;
<a id="p100390"></a>m) определение бюджета;
<a id="p100391"></a>n) планирование показателей качества;
<a id="p100392"></a>o) планирование человеческих ресурсов;
<a id="p100393"></a>p) планирование средств коммуникации;
<a id="p100394"></a>q) планирование закупок.

##### <a id="p100395"></a>6.2.4 Выполнение

<a id="p100396"></a>Согласно ИСО/МЭК 15288, цель выполнения проекта состоит в осуществлении проектных планов, определенных ранее.
<a id="p100397"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100398"></a>a) руководство выполнением проекта;
<a id="p100399"></a>b) обеспечение качества;
<a id="p100400"></a>c) создание проектной группы;
<a id="p100401"></a>d) укрепление проектной группы;
<a id="p100402"></a>e) управление проектной группой;
<a id="p100403"></a>f) распространение информации;
<a id="p100404"></a>g) управление ожиданиями правообладателей;
<a id="p100405"></a>h) проведение закупок.

##### <a id="p100406"></a>6.2.5 Мониторинг и контроль

<a id="p100407"></a>Согласно ИСО/МЭК 15288, цель мониторинга и контроля проекта заключается в определении статуса проекта и обеспечении того, чтобы он выполнялся согласно планам и графикам, а также в соответствии с запланированным бюджетом и техническими требованиями.
<a id="p100408"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100409"></a>a) мониторинг и контроль работ по проекту;
<a id="p100410"></a>b) интегрированный контроль изменений;
<a id="p100411"></a>c) верификация целей и задач;
<a id="p100412"></a>d) контроль целей и задач;
<a id="p100413"></a>e) контроль графика выполнения;
<a id="p100414"></a>f) контроль стоимости;
<a id="p100415"></a>g) осуществление контроля качества;
<a id="p100416"></a>h) создание отчетов о выполнении;
<a id="p100417"></a>i) мониторинг и контроль рисков;
<a id="p100418"></a>j) администрирование закупок.

##### <a id="p100419"></a>6.2.6 Закрытие

<a id="p100420"></a>Согласно ИСО/МЭК 15288, цель закрытия проекта заключается в завершении мероприятий по проекту.
<a id="p100421"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100422"></a>a) финальный анализ нерешенных вопросов;
<a id="p100423"></a>b) анализ решенных важных проблем и полученных знаний;
<a id="p100424"></a>c) отправка результатов анализа соответствующим организациям с целью постоянного совершенствования;
<a id="p100425"></a>**d) завершение проекта или фазы;**
<a id="p100426"></a>e) завершение закупок.

#### <a id="p100427"></a>6.3 Уровень подготовки к работе и эксплуатации приложений


##### <a id="p100428"></a>6.3.1 Общие положения

<div align="center">

<a id="p100429"></a>Подготовка к работе и эксплуатации приложений показана на [рисунке 12](#p100431).

</div>


<a id="p100430"></a> ![рис. 12](https://i.bukva.ai/fYlMD6Tq/img_11.png) 

<div align="center">

<a id="p100431"></a>Рисунок 12 - Подготовка к работе и эксплуатации приложений

</div>


<a id="p100432"></a>Уровень подготовки к работе и эксплуатации приложений включает мероприятия из области программной инженерии, связанные с подготовкой к работе, сопровождением, архивированием и удалением приложений. В соответствии с рекомендациями таких стандартов, как ИСО/МЭК 12207, ИСО/МЭК 15288, ИСО/МЭК 37500, ИСО/МЭК 15489 и другими, важными областями мероприятий в этом случае являются подготовка, аутсорсинг, разработка, приобретение, ввод в действие, использование, обслуживание, архивирование и уничтожение.

##### <a id="p100433"></a>6.3.2 Подготовка: Инициирование

<a id="p100434"></a>Цель процесса инициирования на стадии подготовки заключается в проведении предварительных или подготовительных мероприятий, в том числе связанных с началом и планированием проекта разработки. Сюда входит определение того, какие части проекта будут реализованы через аутсорсинг, разработку и приобретение.
<a id="p100435"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100436"></a>a) выработка технического видения;
<a id="p100437"></a>b) валидация контекстов и спецификаций, связанных со сферой действия приложения;
<a id="p100438"></a>c) идентификация и широкая категоризация информации, которая будет обрабатываться системой;
<a id="p100439"></a>d) первоначальный высокоуровневый анализ рисков, связанных с приложением;
<a id="p100440"></a>e) определение требований безопасности и целевого уровня доверия приложения;
<a id="p100441"></a>f) выбор МОБП согласно этому уровню;
<a id="p100442"></a>g) оценка стоимости и затрат, связанных с выполнением мероприятий по обеспечению безопасности в рамках проекта;
<a id="p100443"></a>h) определение и приобретение МОБП согласно определенному целевому уровню доверия приложения;
<a id="p100444"></a>i) определение мероприятий, связанных с безопасностью, верификацией и измерениями для МОБП, выбранных согласно определенному целевому уровню доверия приложения.

##### <a id="p100445"></a>6.3.3 Подготовка: Планирование

<a id="p100446"></a>Цель процесса планирования на стадии подготовки заключается в определении шагов по реализации мероприятий, включая начало и планирование проекта разработки. Сюда входит определение того, какие части проекта будут реализованы через аутсорсинг, разработку и приобретение.
<a id="p100447"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100448"></a>a) определение и планирование требуемых стадий и сфер мероприятий согласно эталонной модели жизненного цикла безопасности приложений;
<a id="p100449"></a>b) планирование мероприятий, связанных с безопасностью, верификацией и измерениями для МОБП, выбранных согласно определенному целевому уровню доверия приложения.

##### <a id="p100450"></a>6.3.4 Аутсорсинг: Реализация

<a id="p100451"></a>Согласно ИСО/МЭК 37500, цель процесса аутсорсинга заключается в передаче разработки приложения, полностью или частично, третьей стороне. Аутсорсинг обычно включает определение целей и стратегии аутсорсинга, валидацию стратегии с учетом коммерческих и проектных целей, спецификацию требований к обслуживанию, а также описание модели управления и механизма поставки.
<a id="p100452"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100453"></a>a) подготовка к аутсорсингу;
<a id="p100454"></a>b) размещение объявлений аутсорсинга;
<a id="p100455"></a>c) выбор поставщика;
<a id="p100456"></a>d) заключение контрактного соглашения;
<a id="p100457"></a>e) мониторинг соглашения.

##### <a id="p100458"></a>6.3.5 Аутсорсинг: Ввод в действие

<a id="p100459"></a>Ввод в действие на стадии аутсорсинга обычно включает определение целей и стратегии аутсорсинга, валидацию стратегии с учетом коммерческих и проектных целей, спецификацию требований к обслуживанию, а также описание модели управления и механизма поставки.
<a id="p100460"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100461"></a>a) приемка приобретающей стороной;
<a id="p100462"></a>b) закрытие.

##### <a id="p100463"></a>6.3.6 Разработка: Начальная стадия

<a id="p100464"></a>Согласно ИСО/МЭК 12207, цель процесса разработки заключается в создании части или всего приложения. Начальная стадия обычно включает создание и валидацию проектного плана разработки.
<a id="p100465"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100466"></a>a) инициация проекта;
<a id="p100467"></a>b) итерация стадий планирования и менеджмента;
<a id="p100468"></a>c) определение и уточнение требований;
<a id="p100469"></a>d) достижение согласия о техническом подходе.

##### <a id="p100470"></a>6.3.7 Разработка: Подготовка

<a id="p100471"></a>Согласно ИСО/МЭК 12207, цель подготовки заключается в создании части или всего приложения. Разработка обычно включает в себя следующее: анализ и определение требований, проектирование архитектуры, детальное проектирование, создание программных средств, интеграцию программных средств, пригодность программных средств и тестирование.
<a id="p100472"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100473"></a>a) итерация стадий планирования и менеджмента;
<a id="p100474"></a>b) определение и уточнение требований;
<a id="p100475"></a>c) разработка архитектуры;
<a id="p100476"></a>d) инкрементная разработка решения;
<a id="p100477"></a>e) тестирование решения;
<a id="p100478"></a>f) текущие задачи.

##### <a id="p100479"></a>6.3.8 Разработка: Конструирование

<a id="p100480"></a>Согласно ИСО/МЭК 12207, цель процесса конструирования заключается в создании части или всего приложения. Создание обычно включает анализ и определение требований, проектирование архитектуры, детальное проектирование, создание программных средств, интеграцию программных средств, пригодность программных средств и тестирование.
<a id="p100481"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100482"></a>a) итерация стадий планирования и менеджмента;
<a id="p100483"></a>b) определение и уточнение требований;
<a id="p100484"></a>c) инкрементная разработка решения;
<a id="p100485"></a>d) тестирование решения;
<a id="p100486"></a>e) текущие задачи.

##### <a id="p100487"></a>6.3.9 Приобретение: Планирование

<a id="p100488"></a>Согласно ИСО/МЭК 12207, цель процессов планирования и приобретения состоит в получении продукта и (или) услуги в соответствии с потребностями приобретающей стороны. Процесс приобретения начинается с выяснения потребностей заказчика.
<a id="p100489"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100490"></a>a) подготовка к приобретению;
<a id="p100491"></a>b) объявление о приобретении;
<a id="p100492"></a>c) выбор поставщика;
<a id="p100493"></a>d) заключение контрактного соглашения;
<a id="p100494"></a>e) мониторинг соглашения.

##### <a id="p100495"></a>6.3.10 Приобретение: Закрытие

<a id="p100496"></a>Согласно ИСО/МЭК 12207, цель процесса закрытия состоит в завершении процесса приобретения продукта и (или) услуги, после того как установлено, что они соответствуют потребностями приобретающей стороны. Процесс приобретения заканчивается приемкой продукта и (или) услуги, необходимых приобретающей стороне.
<a id="p100497"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100498"></a>a) приемка приобретающей стороной;
<a id="p100499"></a>b) закрытие.

##### <a id="p100500"></a>6.3.11 Ввод в действие: Планирование

<a id="p100501"></a>Согласно ИСО/МЭК 15288, цель процесса ввода в действие состоит в определении возможности предоставлять услуги, определенные требованиями правообладателя, в среде применения. Ввод в действие заключается в инсталляции верифицированного приложения вместе с соответствующими обеспечивающими системами, например операционной системой, системой сопровождения, системой обучения операторов, системой обучения пользователей, как это определено в соглашениях. Цель стадии планирования в процессе ввода в действие заключается в создании плана ввода в действие.
<a id="p100502"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100503"></a>a) итерация стадии планирования;
<a id="p100504"></a>b) управление итерациями;
<a id="p100505"></a>c) оценка результатов.

##### <a id="p100506"></a>6.3.12 Ввод в действие: Разработка

<a id="p100507"></a>Согласно ИСО/МЭК 15288, цель процесса ввода в действие состоит в определении возможности предоставлять услуги, определенные требованиями правообладателя, в среде применения. Ввод в действие заключается в инсталляции верифицированного приложения вместе с соответствующими обеспечивающими системами, например операционной системой, системой сопровождения, системой обучения операторов, системой обучения пользователей, как это определено в соглашениях. Цель стадии выполнения в процессе ввода в действие состоит в реализации ввода в действие.
<a id="p100508"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100509"></a>a) проектирование решения;
<a id="p100510"></a>b) тестирования разработчиками;
<a id="p100511"></a>c) реализация решения;
<a id="p100512"></a>d) проведение тестирования разработчиками;
<a id="p100513"></a>e) интеграция и создание сборки.

##### <a id="p100514"></a>6.3.13 Ввод в действие: Тестирование

<a id="p100515"></a>Согласно ИСО/МЭК 15288, цель процесса ввода в действие состоит в определении возможности предоставлять услуги, определенные требованиями правообладателя, в среде применения. Ввод в действие заключается в инсталляции верифицированного приложения вместе с соответствующими обеспечивающими системами, например операционной системой, системой сопровождения, системой обучения операторов, системой обучения пользователей, как это определено в соглашениях. Цель стадии тестирования в процессе ввода в действие заключается в проверке успешности ввода в действие.
<a id="p100516"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100517"></a>a) реализация тестирования;
<a id="p100518"></a>b) проведение тестирования.

##### <a id="p100519"></a>6.3.14 Использование: Применение

<a id="p100520"></a>Согласно ИСО/МЭК 15288, цель использования состоит в применении приложения для того, чтобы оказывать услуги. Процесс использования включает назначение сотрудников для управления приложением и мониторинга услуг, а также производительности операторов и приложения. Для обеспечения непрерывности предоставления услуг, персонал определяет и анализирует проблемы, возникающие при функционировании по отношению к соглашениям, правообладателям, требованиям и организационным ограничениям.
<a id="p100521"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100522"></a>a) определение организационных процессов, на которые воздействует приложение;
<a id="p100523"></a>b) адаптация важных организационных процессов к приложению;
<a id="p100524"></a>c) определение ролей;
<a id="p100525"></a>d) определение информационных групп (записей);
<a id="p100526"></a>e) анализ рисков, связанных с доступом к приложению;
<a id="p100527"></a>f) присвоение ролей, обязанностей, квалификаций и полномочий;
<a id="p100528"></a>g) одобрение запросов на доступ и управление ими;
<a id="p100529"></a>h) обучение пользователей;
<a id="p100530"></a>i) осуществление действий и предоставление услуг, связанных с приложением;
<a id="p100531"></a>j) выполнение запросов;
<a id="p100532"></a>k) управление инцидентами;
<a id="p100533"></a>l) управление проблемами;
<a id="p100534"></a>m) управление доступом;
<a id="p100535"></a>n) управление событиями;
<a id="p100536"></a>o) управление запросами на внесение изменений;
<a id="p100537"></a>p) выполнение гибкой и оперативной валидации;
<a id="p100538"></a>q) мониторинг и контроль действий приложения;
<a id="p100539"></a>r) мониторинг и контроль использования ресурсов приложением.

##### <a id="p100540"></a>6.3.15 Использование: Сопровождение

<a id="p100541"></a>Согласно ИСО/МЭК 15288, цель процесса сопровождения заключается в том, чтобы обеспечить приложению возможность предоставлять услуги. Мероприятия сопровождения направлены на мониторинг возможности приложения предоставлять услуги, регистрацию проблем для анализа, принятие корректирующих, адаптивных, улучшающих и предотвращающих действий, а также подтверждение восстановления работоспособности.
<a id="p100542"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100543"></a>a) определение обязанностей по обеспечению сопровождения и средств связи;
<a id="p100544"></a>b) получение результатов из собранной информации о сопровождении;
<a id="p100545"></a>c) создание плана работ по обеспечению сопровождения;
<a id="p100546"></a>d) определение процессов и услуг, связанных с сопровождением;
<a id="p100547"></a>e) обучение в области сопровождения;
<a id="p100548"></a>f) осуществление процесса сопровождения;
<a id="p100549"></a>g) введение новшеств и развертывание средств сопровождения;
<a id="p100550"></a>h) управление событиями и запросами;
<a id="p100551"></a>i) планирование сопровождения;
<a id="p100552"></a>j) мониторинг и контроль запросов и событий;
<a id="p100553"></a>k) соглашение об уровне услуг и управление соглашениями с поставщиками;
<a id="p100554"></a>l) оказание услуг перед поставкой и вводом в действие;
<a id="p100555"></a>m) оказание услуг сопровождения во время эксплуатации;
<a id="p100556"></a>n) оказание услуг по развитию программного обеспечения и устранению ошибок;
<a id="p100557"></a>o) верификация и валидация;
<a id="p100558"></a>p) конфигурирование и управление версиями;
<a id="p100559"></a>q) обеспечение качества процессов, услуг и программного обеспечения (продукта);
<a id="p100560"></a>r) анализ и измерение результатов сопровождения;
<a id="p100561"></a>s) причинный анализ и решение проблем;
<a id="p100562"></a>t) обновление, перенос и вывод из эксплуатации программных средств.

##### <a id="p100563"></a>6.3.16 Архивирование: Обеспечение

<a id="p100564"></a>Согласно ИСО/МЭК 15489, цель процесса архивирования заключается в ведении всех важных электронных и бумажных записей. Процесс архивирования призван обеспечить надлежащее хранение, легкий доступ и правильное документирование записей с момента создания до утилизации.
<a id="p100565"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100566"></a>a) определение и анализ политики организации в сфере сбора данных;
<a id="p100567"></a>b) определение правил хранения данных;
<a id="p100568"></a>c) предоставление доступа к записям;
<a id="p100569"></a>d) сохранение записей;
<a id="p100570"></a>e) контроль архивного использования;
<a id="p100571"></a>f) содействие в использовании архивов;
<a id="p100572"></a>g) управление услугами по администрированию архивов;
<a id="p100573"></a>h) управление услугами по поиску и обучению работе с архивами;
<a id="p100574"></a>i) управление публичным доступом к архивам и публичными программами.

##### <a id="p100575"></a>6.3.17 Уничтожение: Обеспечение

<a id="p100576"></a>Согласно ИСО/МЭК 15288, цель процесса уничтожения заключается в прекращении существования приложения. В ходе процесса уничтожения происходят деактивация, разборка и снятие системы и остаточных продуктов, их приведение в финальное состояние и возврат среды в первоначальное или приемлемое состояние.
<a id="p100577"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100578"></a>a) определение общего графика изъятия и списания программных средств;
<a id="p100579"></a>b) определение графика классификации и сохранения записей;
<a id="p100580"></a>c) определение графиков изъятия операционных записей;
<a id="p100581"></a>d) определение графиков передачи прав владения собственностью;
<a id="p100582"></a>e) определение стандартных административных процедур;
<a id="p100583"></a>f) определение процедур ведения записей;
<a id="p100584"></a>g) определение действий по процедуре списания;
<a id="p100585"></a>h) управление изменениями в организации;
<a id="p100586"></a>i) определение действия по изъятию;
<a id="p100587"></a>j) авторизация уничтожения записей;
<a id="p100588"></a>k) управление процедурами ведения записей;
<a id="p100589"></a>l) подготовка записей к получению разрешения на уничтожение;
<a id="p100590"></a>m) выбор процесса удаления записей;
<a id="p100591"></a>n) осуществление процесса удаления записей;
<a id="p100592"></a>o) верификация удаления записей;
<a id="p100593"></a>p) мониторинг и анализ результативности управления записями;
<a id="p100594"></a>q) отправка отчета с информацией о ключевых показателях результативности руководству;
<a id="p100595"></a>r) внедрение регулярного режима отправки отчетов в целях мониторинга и анализа результативности управления записями;
<a id="p100596"></a>**s) проведение оценки управления записями.**

#### <a id="p100597"></a>6.4 Менеджмент инфраструктуры


##### <a id="p100598"></a>6.4.1 Общие положения

<div align="center">

<a id="p100599"></a>Менеджмент инфраструктуры показан на [рисунке 13](#p100601).

</div>


<a id="p100600"></a> ![рис. 13](https://i.bukva.ai/fYlMD6Tq/img_12.png) 

<div align="center">

<a id="p100601"></a>Рисунок 13 - Менеджмент инфраструктуры

</div>


<a id="p100602"></a>Этот уровень состоит из областей мероприятий, связанных с менеджментом инфраструктуры ИТ-услуг, поддерживающей использование приложений в организации. Эти мероприятия обычно рекомендованы такими стандартами, как ИСО/МЭК 20000. Цель менеджмента инфраструктуры заключается в предоставлении необходимой инфраструктуры и услуг для поддержки целей проектов организации и проектов приложений на протяжении всего жизненного цикла. Менеджмент обычно включает три области мероприятий: менеджмент обеспечения инфраструктуры приложений, менеджмент инфраструктуры эксплуатации приложений, менеджмент инфраструктуры архивирования и изъятия приложений. Каждая из областей делится на две сферы: создание инфраструктуры и сопровождение инфраструктуры.

##### <a id="p100603"></a>6.4.2 Создание инфраструктуры

<a id="p100604"></a>Согласно ИСО/МЭК 15288, цель процесса создания инфраструктуры состоит в определении требований к проектной инфраструктуре, а также коммерческих ограничений, которые влияют на выделение инфраструктурных ресурсов и услуг для проекта. Процесс включает определение и предоставление инфраструктурных ресурсов и услуг, необходимых для реализации и поддержки ввода в действие и эксплуатации приложений.
<a id="p100605"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100606"></a>a) подготовка, настройка и установка сред разработки, тестирования, эксплуатации и архивирования;
<a id="p100607"></a>b) создание и обновление документов по конфигурации;
<a id="p100608"></a>c) валидация и обновление плана по обеспечению бесперебойного функционирования и планов на случай внештатных ситуаций;
<a id="p100609"></a>d) создание руководства пользователя;
<a id="p100610"></a>e) создание руководства администратора;
<a id="p100611"></a>f) корректировка корпоративных процедур и политик, затронутых в результате перевода систем на работу онлайн, а также информирование действующих субъектов и правообладателей, затронутых этими изменениями;
<a id="p100612"></a>g) проведение приемочных испытаний для проверки основных функций.

##### <a id="p100613"></a>6.4.3 Сопровождение инфраструктуры

<a id="p100614"></a>Согласно ИСО/МЭК 15288, цель процесса сопровождения инфраструктуры состоит в непрерывной или регулярной сверке с требованиями проектов, чтобы определить, насколько предоставляемые инфраструктурные ресурсы им удовлетворяют. Процесс включает определение и внесение улучшений или изменений в инфраструктурные ресурсы по мере того, как проектные требования меняются. Обычно этот процесс выполняется несколько раз на основе цикла планирование-исполнение-проверка-принятие мер.
<a id="p100615"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100616"></a>a) сопровождение системы при запланированном уровне доверия;
<a id="p100617"></a>b) применение лучших методов при управлении идентификационной информацией и конфигурацией;
<a id="p100618"></a>c) проведение периодических аудитов и проверок внутренней безопасности;
<a id="p100619"></a>d) осуществление контроля изменений;
<a id="p100620"></a>e) подготовка сред эксплуатации;
<a id="p100621"></a>f) создание и обновление документов, описывающих конфигурацию;
<a id="p100622"></a>g) валидация и обновление плана по обеспечению бесперебойного функционирования и планов на случай внештатных ситуаций;
<a id="p100623"></a>h) создание руководства пользователя;
<a id="p100624"></a>i) создание руководства администратора;
<a id="p100625"></a>**j) корректировка корпоративных процедур и политик, затронутых в результате перевода систем на работу онлайн, а также информирование действующих субъектов и правообладателей, затронутых этими изменениями.**

#### <a id="p100626"></a>6.5 Аудит приложений


##### <a id="p100627"></a>6.5.1 Общие положения

<div align="center">

<a id="p100628"></a>Аудит приложений показан на [рисунке 14](#p100630).

</div>


<a id="p100629"></a> ![рис. 14](https://i.bukva.ai/fYlMD6Tq/img_13.png) 

<div align="center">

<a id="p100630"></a>Рисунок 14 - Аудит приложений

</div>


<a id="p100631"></a>Уровень аудита приложений состоит из мероприятий, связанных с контролем и верификацией. Эти мероприятия обычно выполняются в рамках процессов, рекомендованных такими стандартами, как ИСО 19011, ИСО/МЭК 15288, ИСО/МЭК 12207, а также документами, содержащими описание промышленных практик, например CobiT. Типичный жизненный цикл аудита состоит из стадий инициирования аудита, подготовки аудита, проведения аудита, создания отчетов по аудиту и завершения аудита, а также последующих мероприятий.

##### <a id="p100632"></a>6.5.2 Инициирование аудита

<a id="p100633"></a>Согласно ИСО 19011, цель процесса инициирования аудита состоит в установлении первоначального контакта с объектом аудита и определении осуществимости аудита.
<a id="p100634"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100635"></a>a) установление первоначального контакта с объектом аудита;
<a id="p100636"></a>b) подтверждение полномочий для проведения аудита;
<a id="p100637"></a>c) предоставление информации о целях, объеме, методах аудита, а также составе аудиторской группы, в том числе технических экспертах;
<a id="p100638"></a>d) запрос доступа к соответствующим документам и записям;
<a id="p100639"></a>e) определение применимых юридических и контрактных требований, а также других требований, относящихся к действиям и продуктам объекта аудита;
<a id="p100640"></a>f) подтверждение соглашения с объектом аудита относительно объемов раскрытия и использования конфиденциальной информации;
<a id="p100641"></a>g) установление договоренностей о присутствии наблюдателей и необходимости назначения кураторов для аудиторской группы;
<a id="p100642"></a>h) определение конкретных вопросов, связанных со взаимодействием, в том числе относящихся к площадке взаимодействия или областям интересов и проблем объектов аудита;
<a id="p100643"></a>i) ограничение количества выполняемых задач исходя из временных и ресурсных ограничений, а также характера сотрудничества объекта аудита;
<a id="p100644"></a>j) достижение договоренностей по проведению аудита, в том числе относительно графика.

##### <a id="p100645"></a>6.5.3 Подготовка аудита

<a id="p100646"></a>Согласно ИСО 19011, цель процесса подготовки аудита состоит в проверке документации перед аудитом, подготовке плана аудита, распределении работ в аудиторской группе и подготовке рабочей документации.
<a id="p100647"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100648"></a>a) анализ целей и объемов аудита;
<a id="p100649"></a>b) анализ и определение рисков, связанных с отраслью деятельности объекта аудита, включая экономические условия, законы и нормативы, а также технологические изменения;
<a id="p100650"></a>c) анализ и определение риска, связанного со структурой объекта аудита, ключевыми бизнес-процессами, системами и приложениями;
<a id="p100651"></a>d) просмотр и оценка отчетов по предыдущим случаям аудита, а также результатов работы других экспертов, не входящих в аудиторскую группу;
<a id="p100652"></a>e) оценка рисков нарушений и противоправных действий во время аудита;
<a id="p100653"></a>f) оценка риска, который аудит несет организации объекта аудита;
<a id="p100654"></a>g) оценка потенциальных слабых мест или отсутствия мер контроля, а также их потенциальное влияние на выводы (наблюдения) аудита;
<a id="p100655"></a>h) определение плана сотрудничества, включая объем аудита, цели, риски, коммуникационный план, сроки, объем затрачиваемых ресурсов и выводы;
<a id="p100656"></a>i) определение методов сбор и оценки информации о рассматриваемом(ых) процессе(ах);
<a id="p100657"></a>j) определение методов для валидации мер и средств контроля и управления, а также результатов;
<a id="p100658"></a>k) определение методов для выявления остаточного риска там, где оценка эффективности управления недопустима.

##### <a id="p100659"></a>6.5.4 Проведение аудита

<a id="p100660"></a>Согласно ИСО 19011, цель проведения аудита заключается в выполнении фактических мероприятий аудита, в том числе проведении открытых собраний, проверке документации во время аудита, общении во время аудита, распределении ролей и обязанностей наблюдателей и кураторов, сборе и верификации информации, получении выводов, подготовке заключений по результатам аудита и проведении финальных встреч.
<a id="p100661"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100662"></a>a) проведение открытого собрания;
<a id="p100663"></a>b) распределение ролей и обязанностей между наблюдателями и кураторами;
<a id="p100664"></a>c) уточнение понимания целей аудита и уточнение его объема;
<a id="p100665"></a>d) взаимодействие с руководством во время осуществления данного аудита, чтобы содействовать пониманию аудиторской работы, утверждению изменений объемов аудита, достижению согласия с выводами (наблюдениями) аудита, а также осведомленности о нелегальных действиях и правонарушениях;
<a id="p100666"></a>e) осуществление контроля и действия по утвержденному плану аудита для покрытия выявленных рисков согласно утвержденному графику;
<a id="p100667"></a>f) получение достаточных и надлежащих доказательств для проведения анализа, который позволит сделать обоснованные выводы об эффективности структуры мер и средств контроля и управления и (или) результатах достижения целей контроля;
<a id="p100668"></a>g) применение дополнительных процедур тестирования для получения достаточных и надлежащих доказательств в случаях, когда работа внутренних и (или) внешних экспертов не дает достаточных и надлежащих доказательств;
<a id="p100669"></a>h) рассмотрение совокупного воздействия мелких недостатков в сфере контроля или слабых мест, а также анализ того, превращается ли отсутствие мер контроля в значительный недостаток или уязвимость;
<a id="p100670"></a>i) подготовка надлежащего заключения по аудиту или выводов, подкрепленных анализом и доказательствами, а также описанием факторов, ограничивающих объем аудита в случаях, когда требуемые доказательства не были получены во время дополнительных процедур тестирования;
<a id="p100671"></a>j) проведение заключительного собрания.

##### <a id="p100672"></a>6.5.5 Отчет

<a id="p100673"></a>Согласно ИСО 19011, цель представления отчетов заключается в подготовке и распространении отчета об аудите.
<a id="p100674"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100675"></a>a) представление отчета в соответствии с утвержденными стандартами;
<a id="p100676"></a>b) распространение отчета об аудите, учитывая ограничения.
<a id="p100677"></a>*Примечание* - Стандарты отчетности включают:
- <a id="p100678"></a>описание предприятия, предполагаемых получателей и любых ограничений на содержание или распространение;
- <a id="p100679"></a>описание объема, целей взаимодействия, период охвата, а также характер, сроки и масштабы выполненных работ;
- <a id="p100680"></a>описание результатов, выводов и рекомендаций;
- <a id="p100681"></a>описание любых квалификационных показателей или ограничений по объему, представленное аудиторами и специалистами по контролю качества в отношении взаимодействия;
- <a id="p100682"></a>круг ведения;
- <a id="p100683"></a>подпись, дата, описание порядка распространения согласно уставу аудита или письму-обязательству.


##### <a id="p100684"></a>6.5.6 Завершение аудита

<a id="p100685"></a>Согласно ИСО 19011, цель завершения аудита состоит в закрытии процедуры аудита. Аудит объявляется закрытым, когда выполнены все запланированные мероприятия или иная договоренность с объектом аудита (например, в случае непредвиденной ситуации, которая может помешать завершению аудита согласно плану).
<a id="p100686"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100687"></a>a) документирование и обобщение полученного опыта;
<a id="p100688"></a>b) архивирование и ликвидация свидетельств согласно контракту и применимым положениям.

##### <a id="p100689"></a>6.5.7 Последующие мероприятия

<a id="p100690"></a>Согласно ИСО 19011, цель проведения последующих мероприятий по итогам аудита заключается в том, чтобы сделать выводы о необходимости изменений или корректирующих, превентивных действий или мероприятий по улучшению.
<a id="p100691"></a>Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:
<a id="p100692"></a>a) проведение последующего собрания;
<a id="p100693"></a>b) анализ плана действий, а также выполненных мероприятий;
<a id="p100694"></a>c) анализ соответствия плана и выполненных действий выводам (наблюдениям) аудита и рекомендациям.

#### <a id="p100695"></a>6.6 Роли

<a id="p100696"></a>Действующие субъекты и роли, определенные в ЭМЖЦБП, должны использоваться в качестве ориентира при описании МОБП с целью указать, какие ресурсы должны быть выделены для выполнения мероприятий или задач, связанных с МОБП.
<a id="p100697"></a>Допустимы следующие значения ролей:
<a id="p100698"></a>a) Приобретающая сторона
<a id="p100699"></a>Отдельное лицо, которое приобретает или получает продукт или услугу у поставщика. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению бизнесом.
<a id="p100700"></a>b) Любая роль
<a id="p100701"></a>Отдельное лицо, занятое в работе над приложением. Эту роль выполняют все действующие субъекты и правообладатели.
<a id="p100702"></a>c) Администратор приложения
<a id="p100703"></a>Отдельное лицо, ответственное за параметризацию и предоставление доступа к приложению. Действующие субъекты, выступающие в этой роли, могут быть членами группы по управлению ИТ.
<a id="p100704"></a>d) Архитектор приложения
<a id="p100705"></a>Отдельное лицо, ответственное за определение архитектуры приложения, в том числе ключевых технических решений, которые определяют его общую конструкцию, обеспечение сопровождения и реализацию. Действующие субъекты, выступающие в этой роли, являются членами группы разработки.
<a id="p100706"></a>e) Оператор приложения
<a id="p100707"></a>Отдельное лицо, ответственное за работу приложения и управление им.
<a id="p100708"></a>*Примечание* - Оператор приложения может отвечать за управление правами пользователя приложения, функциональность и интерфейсы приложения.

<a id="p100709"></a>Эта роль также известна как системный оператор или системный администратор.
<a id="p100710"></a>f) Владелец приложения
<a id="p100711"></a>Отдельное лицо, отвечающее за определение, сопровождение и утверждение порядка безопасного использования приложения. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению бизнесом.
<a id="p100712"></a>g) Соответствующее руководство, несущее ответственность
<a id="p100713"></a>Самый высокопоставленный персонал, несущий ответственность за безопасное использование приложения в организации. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению.
<a id="p100714"></a>h) Аудитор
<a id="p100715"></a>Отдельное лицо, которое проводит официальную, систематическую проверку безопасности приложения. Отдельное лицо, выполняющее данную роль, может быть членом внутренней (проводящей внутренний аудит) или внешней (проводящей внешний аудит) группы экспертов.
<a id="p100716"></a>i) Главный сотрудник по вопросам (информационной) безопасности
<a id="p100717"></a>Отдельное лицо, ответственное за определение и сопровождение средств и мер управления безопасностью в соответствующем проекте или корпоративной организации. Действующие субъекты, выступающие в этой роли, являются членами руководящего состава организации.
<a id="p100718"></a>j) Индивидуально определяемая роль
<a id="p100719"></a>Роль, определяемая организацией. Добавляет гибкости для адаптирования эталонной модели к особым организационным контекстам и требованиям.
<a id="p100720"></a>k) Разработчик
<a id="p100721"></a>Отдельное лицо, ответственное за разработку части или всего приложения, в том числе конструирование, прототипирование, реализацию, тестирование элементов и интеграцию компонентов в решение. Действующие субъекты, выступающие в этой роли, являются членами группы разработки.
<a id="p100722"></a>l) Специалист в предметной области
<a id="p100723"></a>Отдельное лицо, знакомое с предметной областью, которое может предоставить детальную информацию о предметной области. Действующие субъекты, выступающие в этой роли, являются членами группы внешних экспертов.
<a id="p100724"></a>m) Архитектор ИТ-инфраструктуры
<a id="p100725"></a>Отдельное лицо, ответственное за проектирование технологической инфраструктуры, требуемой для предоставления услуг. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению ИТ.
<a id="p100726"></a>n) Эксперт по ИТ-инфраструктуре
<a id="p100727"></a>Отдельное лицо, ответственное за реализацию и сопровождение технологической инфраструктуры. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению ИТ.
<a id="p100728"></a>o) Эксперт в области законов и нормативных актов
<a id="p100729"></a>Отдельное лицо, знакомое с областью законодательства и регламентирующих норм, которое может предоставить детальную информацию о предметной области. Действующие субъекты, выступающие в этой роли, являются членами группы внешних экспертов.
<a id="p100730"></a>p) Руководитель
<a id="p100731"></a>Отдельное лицо, ответственное за планирование и управление работой группы лиц, мониторинг их работы и принятие корректирующих мер в случае необходимости. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению бизнесом.
<a id="p100732"></a>q) Владелец
<a id="p100733"></a>Отдельное лицо, отвечающее за определение, сопровождение и утверждение порядка безопасного использования элемента под свою ответственность, например приложения, процесса или проекта. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению бизнесом.
<a id="p100734"></a>r) Проектный менеджер
<a id="p100735"></a>Отдельное лицо, ответственное за планирование и координацию ресурсов, необходимых для достижения целей проекта в рамках запланированной цены, сроков и показателей качества. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению бизнесом.
<a id="p100736"></a>s) Архитектор по безопасности
<a id="p100737"></a>Отдельное лицо, ответственное за проектирование средств управления безопасностью в целях снижения уровня угроз безопасности. Действующие субъекты, выступающие в этой роли, являются членами группы разработки.
<a id="p100738"></a>t) Поставщик
<a id="p100739"></a>Юридическое или физическое лицо, заключающее соглашение с приобретающей стороной о поставке продукта или услуги. Действующие субъекты, выступающие в этой роли, являются членами группы внешних экспертов.
<a id="p100740"></a>u) Тестировщик
<a id="p100741"></a>Отдельное лицо, ответственное за внедрение и реализацию тестов в целях обеспечить соответствие развертываемых релизов и сервисов требованиям. Действующие субъекты, выступающие в этой роли, являются членами группы разработки.
<a id="p100742"></a>v) Инструктор
<a id="p100743"></a>Отдельное лицо, которое обучает людей. Физическое лицо, выступающее в этой роли, может быть членом внутренней или внешней группы экспертов.
<a id="p100744"></a>w) Пользователь
<a id="p100745"></a>Отдельное лицо, выполняющее одну или несколько задач с приложением. Действующие субъекты, выступающие в этой роли, являются членами группы пользователей.

<a id="p100746"></a>**7 Пакет МОБП**

<a id="p100747"></a>Пакет МОБП - контейнер, в котором связанные МОБП сгруппированы и объединены вместе в целях облегчения их передачи (см. [рисунок 15](#p100749)). В случае необходимости должна быть возможность определить источник происхождения пакета МОБП и подтвердить его целостность.

<a id="p100748"></a> ![рис. 15](https://i.bukva.ai/fYlMD6Tq/img_14.png) 

<div align="center">

<a id="p100749"></a>Рисунок 15 - Пакет МОБП

</div>


<a id="p100750"></a>Пакет МОБП должен содержать следующую информацию:
<a id="p100751"></a>a) Содержимое пакета (О): в том числе:
1) <a id="p100752"></a>идентификационная информация о пакете (О): информация, необходимая для того, чтобы идентифицировать пакет МОБП, например:
<a id="p100753"></a>i) уникальный ID (О): уникальный идентификационный номер этого пакета (например, находящийся в ведении редакторов);
<a id="p100754"></a>ii) дата (О): дата создания;
<a id="p100755"></a>iii) номер версии (Н): номер версии;
<a id="p100756"></a>iv) имя (О): название пакета МОБП;
<a id="p100757"></a>v) цель (Н): цель использования этого пакета МОБП (например: МОБП используется для удовлетворения требований, связанных с онлайн-платежами);
<a id="p100758"></a>vi) описание (Н): описание пакета;
<a id="p100759"></a>vii) редактор (Н): имя и координаты редактора;
2) <a id="p100760"></a>МОБП (О): один или множество МОБП (см. [раздел 5](#p100092)).
<a id="p100761"></a>b) Электронная подпись редактора пакета (Н): цифровые подписи для валидации источника и целостности пакета.





<div align="right">

<a id="p100762"></a>Приложение ДА

</div>

(справочное)

<div align="center">

<a id="p100763"></a>**СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ**<br>
**НАЦИОНАЛЬНЫМ СТАНДАРТАМ**

</div>


<div align="right">

<a id="p100764"></a>Таблица ДА.1

</div>



<table>
<colgroup><col width="31%"><col width="14%"><col width="56%"></colgroup>
<tr><td><a id="p100765"></a>Обозначение ссылочного международного стандарта</td><td><a id="p100766"></a>Степень соответствия</td><td><a id="p100767"></a>Обозначение и наименование соответствующего национального стандарта</td></tr>
<tr><td><a id="p100768"></a>ISO/IEC 27034-1</td><td><a id="p100769"></a>IDT</td><td><a id="p100770"></a><a href="https://bukva.ai/docs/standart-gost-r-isomek-27034-1-2014">ГОСТ Р ИСО/МЭК 27034-1-2014</a> "Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия"</td></tr>
<tr><td colspan="3"><a id="p100771"></a><a id="p100772"></a>Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта:<br>- IDT - идентичный стандарт.</td></tr>
</table>






<div align="center">

<a id="p100773"></a>**БИБЛИОГРАФИЯ**

</div>



| <a id="p100774"></a>[1] | <a id="p100775"></a>ISO/IEC 12207 System and software engineering - Software life cycle processes (Системная и программная инженерия. Процессы жизненного цикла программных средств) |
| --- | --- |
| <a id="p100776"></a>[2] | <a id="p100777"></a>ISO/IEC 15288 System and software engineering - System life cycle processes (Системная инженерия. Процессы жизненного цикла систем) |
| <a id="p100778"></a>[3] | <a id="p100779"></a>ISO/IEC 15489 Information and documentation - Records management (Информация и документация. Управление документами) |
| <a id="p100780"></a>[4] | <a id="p100781"></a>ISO/IEC 19011 Guidelines for auditing management system (Руководящие указания по аудиту систем менеджмента) |
| <a id="p100782"></a>[5] | <a id="p100783"></a>ISO/IEC 20000 Information technology - Service management (Управление услугами) |
| <a id="p100784"></a>[6] | <a id="p100785"></a>ISO/IEC 27034-2:2015 Information technology - Security techniques - Application security - Part 2: Organization normative framework (Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 2. Нормативная структура организации) |
| <a id="p100786"></a>[7] | <a id="p100787"></a>ISO/IEC 27034-3 Information technology - Security techniques - Application security - Part 3: Application security management process (Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 3. Процесс менеджмента безопасности приложений) |
| <a id="p100788"></a>[8] | <a id="p100789"></a>ISO/IEC 37500 Guidance on outsourcing (Руководство по аутсорсингу) |







<table>
<colgroup><col width="68%"><col width="32%"></colgroup>
<tr><td><a id="p100790"></a>УДК 006.34:004.056:004.056.5:004.056.53:006.354</td><td><a id="p100791"></a>ОКС 35.030</td></tr>
<tr><td colspan="2"><a id="p100792"></a>Ключевые слова: методы и средства обеспечения безопасности, меры обеспечения безопасности приложений, управление безопасностью протоколов и приложений, информационный элемент</td></tr>
</table>




<a id="p100793"></a>

---