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

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

1 июня 2021 года

1 ПОДГОТОВЛЕН Федеральным государственным учреждением «Федеральный исследовательский центр „Информатика и управление“ Российской академии наук» (ФИЦ ИУ РАН) и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 10 ноября 2020 г. № 1043-ст

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).

ИСО/МЭК 27034-5 подготовлен подкомитетом 27 «Методы и средства обеспечения безопасности» Совместного технического комитета ИСО/МЭК СТК 1 «Информационные технологии».

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

5 ВВЕДЕН ВПЕРВЫЕ

6 Некоторые положения международного документа, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

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

Общая информация

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

Все части ИСО/МЭК 27034 описывают понятия, принципы, структуры, компоненты и процессы в целях помощи организациям последовательно интегрировать средства и механизмы безопасности на протяжении жизненного цикла приложений.

Ключевыми компонентами настоящего стандарта являются меры обеспечения безопасности приложений (МОБП).

Для облегчения внедрения комплексов мер защиты приложений, а также механизмов передачи и обмена МОБП, описанных в ИСО/МЭК 27034 (все части), требуется задокументировать и объяснить минимальный набор наиболее важных атрибутов для реализации МОБП и других определенных компонентов этой структуры.

В настоящем стандарте описывается минимальный набор наиболее важных атрибутов МОБП, а также даются дополнительные сведения об эталонной модели жизненного цикла безопасности приложений (ЭМЖЦБП).

Назначение

В настоящем стандарте представлены основные сведения и требования к структуре данных МОБП. Наличие стандартизированного набора основных атрибутов информации и структуры данных МОБП имеет следующие преимущества:

a) нормализация процессов создания, передачи, защиты и верификации МОБП в соответствии с требованиями настоящего стандарта;

b) снижение затрат на безопасность в проектах приложений до минимума путем облегчения повторного использования одобренных мер обеспечения безопасности, а также получения МОБП из разных источников.

Кроме того, в настоящем стандарте определяются и подробно описываются процессы, мероприятия и должностные роли внутри эталонной модели жизненного цикла безопасности приложений (ЭМЖЦБП).

Целевая аудитория

Общая информация

Настоящий стандарт полезен для следующих групп лиц при осуществлении своих ролей в организации:

a) руководители;

b) группа нормативной структуры организации (группа НСО);

c) эксперты в предметной области;

d) поставщики;

e) приобретающие стороны.

Руководители

Руководителям необходимо ознакомиться с настоящим стандартом, поскольку в их обязанности входит:

a) обеспечение возможности повторного использования МОБП внутри организации;

b) обеспечение доступности МОБП, а также их передача и использование в проектах приложений с помощью надлежащих инструментов и процедур во всей организации.

Группа НСО

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

a) внедрение библиотеки МОБП;

b) утверждение МОБП, которые адекватно снижают угрозы безопасности приложений;

c) управление затратами на внедрение и сопровождение МОБП.

Эксперты в предметной области

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

a) участие в разработке, валидации и верификации МОБП;

b) участие во внедрении и сопровождении МОБП, предлагая стратегии, компоненты и процессы внедрения для встраивания МОБП в условиях организации;

c) подтверждение пригодности и полезности МОБП для применения в прикладных проектах.

Поставщики инструментов обеспечения безопасности и МОБП

Поставщики содействуют разработке, обслуживанию и распространению инструментов и (или) МОБП. В обязанности поставщиков входят следующие мероприятия:

a) создание, проверка, обеспечение целостности (с помощью принятых методов, например, подписания), распространение и применение МОБП;

b) действия в соответствии с общим и стандартизированным протоколом (структура и формат) обмена МОБП.

Приобретатель инструментов обеспечения безопасности и МОБП

Приобретающей стороной являются физические или юридические лица, которые хотят получить МОБП. В обязанности приобретающей стороны входят следующие мероприятия:

a) интегрирование МОБП в структуре организации и обеспечение взаимодействия любых внутренних и сторонних МОБП;

b) адаптация и обеспечение целостности МОБП;

c) обеспечение соответствия задач и мероприятий, связанных с приобретенными МОБП, и жизненного цикла приложения организации.

1 Область применения

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных — последнее издание (включая все изменения).

ИСО/МЭК 27034-1, Information technology — Information technology — Security techniques — Application security — Part 1: Overview and concepts (Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия)

3 Термины и определения

В настоящем стандарте используются термины и определения по ИСО/МЭК 27034-1, а также следующие термины и определения.

ИСО и МЭК ведут терминологические базы данных для использования в стандартизации по следующим адресам:

• просмотр ISO Online: доступ по адресу https://www.iso.org/obp;
• IEC Electropedia: доступно по адресу http://www.electropedia.org/.

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

3.2 информационная группа (information group): Список информационных элементов, которым организация может присвоить обозначения, например имена, описания и значения категорий.

Примечание - Во избежание путаницы, название информационной группы внутри организации должно быть уникальным.

3.3 информационный элемент (information element): Часть информации, которую необходимо классифицировать и идентифицировать по имени, описанию и значению домена (например, полю в базе данных).

Примечание - Информационная группа может рассматриваться как информационный элемент.

4 Обозначения и сокращения

МОБП	Меры обеспечения безопасности приложений (ASC)
ЖЦБП	Жизненный цикл безопасности приложения (ASLC)
ЭМЖЦБП	Эталонная модель жизненного цикла безопасности приложения (ASLCRM)
ИКТ	Информационно-коммуникационные технологии (ICT)
НСО	Нормативная структура организации (ONF)

5 Структура мер обеспечения безопасности приложений

5.1 Общая информация

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

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

Примечания

1 Для установки минимального набора атрибутов, необходимых для определения эффективных МОБП, название каждого атрибута МОБП, определяемого в настоящем стандарте, снабжено пометкой (О), если атрибут является обязательным, или (Н), если атрибут является необязательным.

2 Включение необязательных атрибутов может потребовать реализации последующих обязательных атрибутов. Обязательные атрибуты, связанные с необязательными, должны использоваться, только если эти необязательные атрибуты применяются (для примера см. 5.2.4.2, e).

Цель данного раздела состоит в том, чтобы предоставить перечень возможных мероприятий, с помощью которых группа НСО может внедрить МОБП в ЭМЖЦБП.

При описании активов разработчики МОБП должны пользоваться терминологией, соответствующей всем частям ИСО/МЭК 27034.

5.2 Информационные требования к МОБП

5.2.1 Общие сведения

Подраздел 5.2 определяет рекомендованные информационные требования к отдельным мерам и средствам контроля и управления безопасностью приложения. Конкретная реализация настоящего стандарта в формате XML-схемы приведена в ИСО/МЭК 27034-5-1.

Следует отметить, что настоящий стандарт не определяет, как идентифицируются или управляются различные информационные элементы МОБП. Подробная информация о последних приведена в описании процессов управления и аудита в ИСО/МЭК 27034-2, ИСО/МЭК 27034-3 и ИСО/МЭК 27034-4.

Примечание - Четкое указание на иерархию наследования в настоящий момент не реализовано в структуре МОБП, но может быть внедрено в будущих версиях.

Рисунок 1 — Основные разделы информации МОБП

Как определено в 8.1.2.6.5 ИСО/МЭК 27034-1:2011 и показано на рисунке 1, каждое описание МОБП должно содержать следующие разделы:

a) идентификация МОБП (О): этот раздел должен содержать следующую информацию:

1. идентификационную информацию об МОБП (идентификатор, имя и т.д.),

2. высокоуровневое описание области и цели применения МОБП,

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

4. ссылки на МОБП, находящиеся выше и ниже по иерархии;

b) цель применения МОБП (О): этот раздел должен содержать следующую информацию:

1. детальное описание целей применения МОБП для обеспечения безопасности,

2. указание на одно или несколько требований по обеспечению защиты, которые обосновывают необходимость МОБП, а также информацию о контексте и функциях приложения, для которых необходима защита,

3. описание одного или нескольких уровней доверия, для которых МОБП является обязательным, вместе с описанием диапазона уровня доверия,

4. предварительные условия и критерии для применения МОБП, в частности:

i) список предварительных условий;

ii) список предполагаемых угроз безопасности (неформальный);

iii) описание среды эксплуатации (контекста использования);

c) мероприятия по обеспечению безопасности, связанные с применением МОБП (О): этот раздел должен содержать информацию, касающуюся мероприятий по обеспечению безопасности, связанных с МОБП:

1. высокоуровневое описание мероприятия по обеспечению безопасности (что),

2. описание актива, защищаемого (целевого) с помощью мероприятия (где),

3. определение ролей (и требуемой квалификации) сотрудников, вовлеченных в выполнение задач и действий в рамках мероприятия (кто),

4. указание сложности и стоимости мероприятий по обеспечению безопасности (сколько),

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

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

d) верификационные измерения, связанные с МОБП (О): этот раздел должен содержать информацию, касающуюся верификационных измерений, связанных с МОБП:

1. высокоуровневое описание верификационных измерений (что),

2. описание актива, в отношении которого проводятся верификационные измерения (где),

3. определение ролей (и требуемой квалификации) сотрудников, вовлеченных в верификационные измерения в рамках мероприятия (кто),

4. указание сложности и стоимости верификационных измерений (сколько),

5. детальное описание задач и действий в рамках мероприятия по верификации, ожидаемые результаты и предварительные условия (как),

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

Пункт 5.2.4 содержит дополнительные сведения о каждом требовании к информации.

5.2.2 Обеспечение целостности

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

5.2.3 Представление данных на нескольких языках или для нескольких регионов

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

5.2.4 Требования к информации, связанной с МОБП

5.2.4.1 Идентификация (О)

Как показано на рисунке 2, описание МОБП должно содержать следующие сведения:

a) идентифицирующая информация об МОБП, в том числе:

1. уникальный идентификатор (О): уникальный идентификатор внутри схемы,

2. имя (О): соответствующее имя;

b) описание (О): высокоуровневое описание целей и области применения МОБП;

c) версия (О): информация, описывающая версию МОБП, в том числе:

1. номер (О): текущий номер версии МОБП в допустимых числах (например, 0.1.1 или 1.2),

2. дата (О): дата создания текущей версии МОБП,

3. стадия жизненного цикла (О): текущая стадия жизненного цикла МОБП. Допустимы следующие значения стадии жизненного цикла:

i) запрос на создание;

ii) проектирование;

iii) анализ и валидация проекта;

iv) разработка;

v) верификация;

vi) утверждение;

vii) окончательное утверждение владельцами;

viii) публикация для обучения;

ix) активно;

x) срок действия истек;

xi) собственное значение;

4. указание степени зрелости (Н): указание уровня готовности этой версии,

5. записи об изменениях (Н): описание того, как изменились МОБП по сравнению с предыдущей версией;

d) автор (Н): авторы текущей версии МОБП и указание их принадлежности, в том числе имена и контактная информация;

e) владелец (Н): владельцы текущей версии МОБП и указание их принадлежности, в том числе имена и контактная информация;

f) взаимосвязи между подчиненными и подчиняющими МОБП определяются, как показано на рисунке 3:

1. подчиненность (О): ссылки на отсутствующие, один или несколько уникальных идентификационных номеров подчиненных МОБП с целью указать, что выполнение мероприятий, связанных со всеми подчиненными (дочерними) МОБП (в определенном порядке) является необходимым условием для завершения мероприятий, связанных с подчиняющими МОБП. Допускается включать краткое описание МОБП, на которые указывают ссылки,

2. подчинение (О): ссылка на отсутствующие, один или несколько уникальных идентификационных номеров подчиняющих МОБП с целью указать материнские МОБП. Допускается включать краткое описание материнских МОБП, на которые указывают ссылки.

5.2.4.2 Цели

Как показано на рисунке 4, описание МОБП должно содержать следующие сведения, касающиеся целей по обеспечению безопасности:

a) описание (О): детальное описание целей и задач по обеспечению безопасности, решаемых МОБП;

b) удовлетворяемые требования к безопасности (О): непустой набор требований, удовлетворяемых с помощью выполнения мероприятий по обеспечению безопасности, связанных с МОБП (см. рисунок 5). Для каждого требования необходимо собрать следующую информацию:

1. контекст (Н): определяет контекст (источник), исходя из которого возникли требования. Допустимы следующие значения типа контекста:

i) нормативные документы;

ii) бизнес-контекст;

iii) технологический контекст;

iv) функциональность приложения;

v) собственное значение;

2. тип (Н): тип требований по обеспечению безопасности. Допустимы следующие значения:

i) требования бизнеса;

ii) правила бизнеса;

iii) требования нормативных документов;

iv) пользовательские требования;

v) требования к квалификации действующих субъектов;

vi) атрибуты качества;

vii) системные требования;

viii) требования к процессу;

ix) функциональные требования;

x) внешние интерфейсы;

xi) требования к инфраструктуре;

xii) ограничения;

xiii) собственное значение;

3. имя (О): соответствующее имя для требования,

4. описание (О): качественное описание для требования,

5. источник (Н): исходный документ, являющийся источником требования;

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

d) условие (Н): описание предварительных условий, предположений и контекста использования для применения МОБП, как показано на рисунке 6:

1. тип условия (Н): тип условия. Допустимы следующие значения:

i) предварительное условие;

ii) предположение;

iii) описание среды эксплуатации;

iv) собственное значение;

2. описание (О): может включать следующие сведения:

i) список предварительных условий для использования МОБП;

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

iii) описание среды эксплуатации (контекста использования);

Когда существует диапазон уровней доверия, связанный с МОБП, следующая информация, как показано на рисунке 7, должна описывать каждый уровень доверия, включенный в диапазон:

1. уникальный идентификационный номер уровня доверия (О): уникальный идентификационный номер в схеме для этого уровня доверия,

2. имя (О): имя уровня доверия,

3. обозначение (О): обозначение, представляющее этот уровень доверия,

4. описание (О): краткое описание уровня доверия с целью помочь приобретателю или получателю интегрировать этот МОБП на нужном уровне библиотеки МОБП приобретателя;

f) указатель возможности прогнозирования (Н): определяет, допускается ли прогнозирование для МОБП. То есть необходимо ли будет подтверждать корректное функционирование МОБП повторно, если контекст эксплуатации изменится в незначительной степени. Более подробная информация приведена в ИСО/МЭК 27034-7.

5.2.4.3 Мероприятие по обеспечению безопасности и верификационное измерение

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

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

a) краткое содержание (О): краткое описание данного мероприятия. При этом должна присутствовать следующая информация:

1. имя (О): название мероприятия,

2. описание (О): неофициальное описание масштаба мероприятия, в том числе охвата и планируемого результата,

3. информация о цели (О): указатель на масштаб мероприятия. Определяет, какая группа информационных элементов находится под защитой или верифицируется с помощью мероприятия в результате применения МОБП в отношении людей, процессов или информационно-коммуникационных технологий, взаимодействующих с этими информационными элементами. Чтобы связанное с МОБП мероприятие было действенным и полезным, необходимо, чтобы по крайней мере один информационный элемент был под защитой или верифицировался МОБП. Для каждого информационного элемента предусмотрены следующие сведения:

i) имя (О): соответствующее имя для информационного элемента, процессов или ИКТ;

ii) тип информационной группы (О): связывает один или несколько типов с информационным элементом, процессами или ИКТ. Допустимы следующие значения:

I) законы и нормы;

II) директивы и нормы, связанные с организацией или направлением бизнеса;

III) процессы жизненного цикла приложения;

IV) определение процесса приложения;

V) спецификация;

VI) данные приложения;

VII) организация и данные пользователя;

VIII) описание полномочий для разных ролей;

IX) определение технологического контекста;

X) собственное значение;

iii) описание (О): описание информационного элемента, процессов или ИКТ;

iv) классификация информации (Н): указание того, насколько чувствительным (применительно к конфиденциальности, целостности и доступности) является информационный элемент;

v) владелец информации (Н): указывает на владельца информационного элемента;

4. описание результата (О): описание ожидаемого результата мероприятия,

5. дополнительные экспертные ресурсы (Н): ссылки на дополнительные (экспертные) ресурсы, призванные облегчить выполнение мероприятия;

b) сложность мероприятия (О): указание сложности мероприятия с применением качественных и количественных измерений.

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

c) при этом должна присутствовать следующая информация:

1. обозначение (О): обозначение, указывающее на сложность. Допустимы следующие значения сложности:

i) низкая;

ii) средняя;

iii) высокая;

iv) чрезвычайно высокая;

v) собственное значение;

2. описание (О): описание сложности,

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

4. общие показатели требуемых усилий (Н): объем усилий, необходимый для проведения мероприятия (например, дни/число сотрудников),

5. предполагаемое время (Н): время, необходимое для осуществления мероприятия,

6. примечание (Н): дополнительная информация о сложности мероприятия;

d) спецификация мероприятия (Н): детальное описание мероприятия.

Примечание — Атрибут спецификация мероприятия является необязательным (Н), поскольку он не нужен, когда МОБП является «главным МОБП» в иерархии МОБП (см. рисунок 7 в подпункте 8.1.2.6.5 ИСО/МЭК 27034-1:2011) (см. рисунок 3). В противном случае он необходим.

Каждая спецификация мероприятия содержит атрибут Используемая матрица обязанностей (О), определяющий тип матрицы обязанностей, используемой в описании этого мероприятия. Допустимы следующие значения:

1. RACI <1>,

2. RASCI <2>.

---

<1> RACI — Схема «Ответственность, подотчетность, консультирование, информирование» (ОПКИ) для обозначения ролей и обязанностей при выполнении действий в бизнес-процессах.

<2> RASCI — Схема «Ответственность, подотчетность, поддержка, консультирование, информирование» (ОППКИ) для обозначения ролей и обязанностей при выполнении действий в бизнес-процессах.

Для описания обязанностей допускается использовать следующие обозначения:

1. исполняет;

2. несет ответственность;

3. оказывает сопровождение;

4. консультирует;

5. получает уведомления.

Каждая спецификация мероприятия включает последовательность задач (О) в определенном порядке. Каждая задача должна содержать следующую информацию:

1. очередность (Н): номер в очереди выполнения, по которому задачи в рамках мероприятия выстраиваются в правильный порядок;

2. описание (О): описание задачи;

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

4. требуемые ресурсы (О): ресурсы, используемые (и требуемые) для выполнения задачи. Для каждого случая выделения ресурсов предусмотрена следующая информация:

i) имя роли (О): ссылка на роль, которую будет играть ресурс. Набор возможных ролей определяется ASLCRM (см. 6.6),

ii) обязанность (О): обязанность RACI, принимаемая ролью в отношении задачи,

iii) описание (Н): описание характера выделения ресурса,

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

5. моменты выполнения (О): указание на то, когда (относительно мероприятий в эталонной модели жизненного цикла безопасности приложений (см. раздел 6)) должна выполняться задача. Для каждого момента исполнения необходимо указать следующую информацию:

i) порядок выполнения (О): порядок выполнения относительно указанного мероприятия. Допустимы следующие значения:

I) до,

II) во время,

III) после,

IV) собственное значение;

ii) эталон жизненного цикла (О): ссылка на мероприятие в эталонной модели жизненного цикла безопасности приложений. Допустимые значения ролей определяются ЭМЖЦБП (см. раздел 6);

iii) имя (Н): название мероприятия, если в модели жизненного цикла оно указано как «собственное»;

iv) описание (О): указание на то, когда будет выполняться задача;

v) интервальное значение, единица измерения и обозначение (О): значение частоты выполнения задачи.

I) Для описания внутреннего значения допускается использовать следующие единицы времени:

i) секунды;

ii) минуты;

iii) часы;

iv) дни;

v) недели;

vi) месяцы;

vii) полугодия;

viii) годы.

II) Для описания интервалов допускается использовать следующие обозначения:

i) один раз;

ii) периодически;

iii) по мере необходимости;

iv) собственное значение.

6. список действий (О): последовательность низкоуровневых элементарных описаний действий, которые необходимо выполнить, чтобы завершить задачу,

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

i) тип (О): тип произведенного артефакта. Допустимы следующие значения:

I) отчет;

II) документ;

III) исходный код;

IV) скомпилированный код;

V) исполняемый код;

VI) сценарий;

VII) библиотека;

VIII) диаграмма;

IX) файл параметров;

X) ссылка;

XI) собственное значение.

ii) содержимое (О): ожидаемое содержимое произведенного артефакта.

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

9. примечание (Н): дополнительная информация об этой задаче, если необходимо.

5.2.4.4 Рекомендации по обеспечению содержания всех необходимых компонентов

Во время операции импорта необходимо импортировать весь набор МОБП, т.е. все МОБП, связанные через иерархию, должны импортироваться вместе.

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

5.3 Рекомендации относительно структуры данных МОБП

5.3.1 Общая информация

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

5.3.2 Обмен

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

5.3.3 Содержание всех необходимых компонентов

В целях обеспечения понимания и применения МОБП, не обращаясь к внешним документам, структура данных МОБП должна поддерживать включение сложных (нетекстовых) элементов данных, таких как документы, источник исполняемого кода и т.д.

Для обеспечения понимания и использования МОБП без обращения к внешним документам, структура данных МОБП должна поддерживать возможность включения сложных (нетекстовых) элементов данных, таких как документы, источник исполняемого кода и т.д. Рекомендуется включить диапазон уровней доверия, на основании которых были определены рекомендуемые уровни доверия для МОБП.

Определение и описание элемента в МОБП должны быть понятными без контекста, если используются стандартизированные схемы. Например, ИСО/МЭК 19770-5, ИСО/МЭК 19770-2.

6 Эталонная модель жизненного цикла безопасности приложения

6.1 Общая информация

В разделе 6 приведена дополнительная информация и перечислены обозначения мероприятий, предложенные в ЭМЖЦБП, определенной в ИСО/МЭК 27034-1. Согласно рисунку 9, жизненный цикл приложения в основном состоит из двух стадий: создание и эксплуатация. Первая стадия подразделяется на фазы подготовки, реализации и ввода в действие. Вторая стадия делится на фазы использования и поддержки, архивирования и уничтожения. В каждой фазе выполняются мероприятия, связанные с подготовкой к работе, эксплуатацией и аудитом приложений, а также менеджментом инфраструктурой и менеджментом приложений. Для этого задействованы несколько субъектов. Дополнительная информация об обозначениях мероприятий и общие определения вовлеченных субъектов даны в подразделах 6.2 - 6.6.

Различные стадии, фазы и мероприятия, определенные в ЭМЖЦБП, должны использоваться в качестве эталона при описании МОБП с целью указать, когда мероприятие, связанное с МОБП, должно быть выполнено. Также действующие субъекты и роли, определенные в ЭМЖЦБП, должны использоваться в качестве ориентира при описании МОБП с целью указать, какие ресурсы должны быть выделены для выполнения мероприятий или задач, связанных с МОБП.

На рисунке 10 элементы ЭМЖЦБП представлены в виде дерева, где элемент «Эталон жизненного цикла» является корневым, первый уровень представлен элементом «уровень», второй уровень — элементом «стадия», третий уровень — элементом «сфера мероприятий», четвертый уровень — элементом «часть сферы мероприятий», пятый уровень — элементом «обозначение мероприятия». Чтобы указать одно определенное обозначение мероприятия, в качестве момента исполнения можно выбрать путь, представленный в виде последовательности элементов (см. 5.2.4.3, d) 5) моменты выполнения).

Рисунок 10 — Обозначение мероприятия, выбранное из эталонной модели жизненного цикла безопасности приложений

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

6.2 Уровень менеджмента приложений

6.2.1 Общие положения

Рисунок 11 — Процессы менеджмента приложений

Примечание — На рисунке 11 элементы «Менеджмент подготовки приложений к работе» и «Менеджмент эксплуатации приложений» представляют две сферы мероприятий, а элементы «Инициирование», «Планирование», «Выполнение», «Мониторинг и контроль», а также «Завершение» представляют части внутри этих сфер мероприятий. Мероприятия, указанные внутри каждой части сферы, представлены на рисунке 10 с помощью элемента «Обозначение мероприятия» и перечислены в 6.2.1 - 6.5.6.

Уровень менеджмента приложений составляют процессы из предметной области менеджмента, выполняемые во время стадий подготовки к работе и эксплуатации приложений. Мероприятия в сфере менеджмента подготовки приложений выполняются проектными менеджерами и менеджерами организаций во время стадии подготовки приложения к работе. Мероприятия в сфере менеджмента эксплуатации приложений связаны с менеджментом и использованием приложения во время стадий эксплуатации. Как показано на рисунке 11, в соответствии с ИСО/МЭК 15288 обе стадии состоят из процессов инициирования, планирования, выполнения, мониторинга и контроля, а также завершения проектов.

6.2.2 Инициирование

Согласно ИСО/МЭК 15288, цель процесса инициирования проекта состоит в определении требований проекта, который предполагается выполнить. После того как требования проекта определены, необходимо установить степень осуществимости проекта, удостоверившись, что ресурсы (персонал, материалы, технологии и среды), необходимые для выполнения проекта и управления им, доступны и соответствуют требованиям. Также необходимо удостовериться, что отведенный период времени достаточен для выполнения проекта. В случае необходимости и по согласию всех участвующих сторон требования проекта могут быть изменены на этой стадии в целях его выполнения.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) разработка паспорта проекта приложения для его реализации;

b) определение необходимых навыков;

c) определение правообладателей;

d) назначение владельца приложения;

e) назначение архитектора приложения;

f) назначение архитектора средств безопасности приложения;

g) менеджмент знаний;

h) развитие, приобретение или предоставление навыков;

i) сопоставление жизненных циклов приложений, используемых в организации, с эталонной моделью.

6.2.3 Планирование

Согласно ИСО/МЭК 15288, цель проектного планирования заключается в подготовке планов для выполнения проекта. План, связанный с выполнением проекта, должен содержать описания связанных мероприятий, задач, а также описание программных продуктов, которые будут предоставлены.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) разработка плана менеджмента проекта;

b) сбор требований;

c) определение масштаба проекта;

d) планирование мер по управлению рисками, связанными с безопасностью приложений;

e) планирование мер по управлению рисками, связанными с проектом;

f) создание структуры разделения работ;

g) описание мероприятий;

h) определение порядка выполнения мероприятий;

i) оценка количества ресурсов, необходимых для выполнения мероприятий;

j) оценка сроков проведения мероприятий;

k) разработка графика работы;

l) оценка стоимости;

m) определение бюджета;

n) планирование показателей качества;

o) планирование человеческих ресурсов;

p) планирование средств коммуникации;

q) планирование закупок.

6.2.4 Выполнение

Согласно ИСО/МЭК 15288, цель выполнения проекта состоит в осуществлении проектных планов, определенных ранее.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) руководство выполнением проекта;

b) обеспечение качества;

c) создание проектной группы;

d) укрепление проектной группы;

e) управление проектной группой;

f) распространение информации;

g) управление ожиданиями правообладателей;

h) проведение закупок.

6.2.5 Мониторинг и контроль

Согласно ИСО/МЭК 15288, цель мониторинга и контроля проекта заключается в определении статуса проекта и обеспечении того, чтобы он выполнялся согласно планам и графикам, а также в соответствии с запланированным бюджетом и техническими требованиями.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) мониторинг и контроль работ по проекту;

b) интегрированный контроль изменений;

c) верификация целей и задач;

d) контроль целей и задач;

e) контроль графика выполнения;

f) контроль стоимости;

g) осуществление контроля качества;

h) создание отчетов о выполнении;

i) мониторинг и контроль рисков;

j) администрирование закупок.

6.2.6 Закрытие

Согласно ИСО/МЭК 15288, цель закрытия проекта заключается в завершении мероприятий по проекту.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) финальный анализ нерешенных вопросов;

b) анализ решенных важных проблем и полученных знаний;

c) отправка результатов анализа соответствующим организациям с целью постоянного совершенствования;

d) завершение проекта или фазы;

e) завершение закупок.

6.3 Уровень подготовки к работе и эксплуатации приложений

6.3.1 Общие положения

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

6.3.2 Подготовка: Инициирование

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

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) выработка технического видения;

b) валидация контекстов и спецификаций, связанных со сферой действия приложения;

c) идентификация и широкая категоризация информации, которая будет обрабатываться системой;

d) первоначальный высокоуровневый анализ рисков, связанных с приложением;

e) определение требований безопасности и целевого уровня доверия приложения;

f) выбор МОБП согласно этому уровню;

g) оценка стоимости и затрат, связанных с выполнением мероприятий по обеспечению безопасности в рамках проекта;

h) определение и приобретение МОБП согласно определенному целевому уровню доверия приложения;

i) определение мероприятий, связанных с безопасностью, верификацией и измерениями для МОБП, выбранных согласно определенному целевому уровню доверия приложения.

6.3.3 Подготовка: Планирование

Цель процесса планирования на стадии подготовки заключается в определении шагов по реализации мероприятий, включая начало и планирование проекта разработки. Сюда входит определение того, какие части проекта будут реализованы через аутсорсинг, разработку и приобретение.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) определение и планирование требуемых стадий и сфер мероприятий согласно эталонной модели жизненного цикла безопасности приложений;

b) планирование мероприятий, связанных с безопасностью, верификацией и измерениями для МОБП, выбранных согласно определенному целевому уровню доверия приложения.

6.3.4 Аутсорсинг: Реализация

Согласно ИСО/МЭК 37500, цель процесса аутсорсинга заключается в передаче разработки приложения, полностью или частично, третьей стороне. Аутсорсинг обычно включает определение целей и стратегии аутсорсинга, валидацию стратегии с учетом коммерческих и проектных целей, спецификацию требований к обслуживанию, а также описание модели управления и механизма поставки.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) подготовка к аутсорсингу;

b) размещение объявлений аутсорсинга;

c) выбор поставщика;

d) заключение контрактного соглашения;

e) мониторинг соглашения.

6.3.5 Аутсорсинг: Ввод в действие

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

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) приемка приобретающей стороной;

b) закрытие.

6.3.6 Разработка: Начальная стадия

Согласно ИСО/МЭК 12207, цель процесса разработки заключается в создании части или всего приложения. Начальная стадия обычно включает создание и валидацию проектного плана разработки.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) инициация проекта;

b) итерация стадий планирования и менеджмента;

c) определение и уточнение требований;

d) достижение согласия о техническом подходе.

6.3.7 Разработка: Подготовка

Согласно ИСО/МЭК 12207, цель подготовки заключается в создании части или всего приложения. Разработка обычно включает в себя следующее: анализ и определение требований, проектирование архитектуры, детальное проектирование, создание программных средств, интеграцию программных средств, пригодность программных средств и тестирование.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) итерация стадий планирования и менеджмента;

b) определение и уточнение требований;

c) разработка архитектуры;

d) инкрементная разработка решения;

e) тестирование решения;

f) текущие задачи.

6.3.8 Разработка: Конструирование

Согласно ИСО/МЭК 12207, цель процесса конструирования заключается в создании части или всего приложения. Создание обычно включает анализ и определение требований, проектирование архитектуры, детальное проектирование, создание программных средств, интеграцию программных средств, пригодность программных средств и тестирование.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) итерация стадий планирования и менеджмента;

b) определение и уточнение требований;

c) инкрементная разработка решения;

d) тестирование решения;

e) текущие задачи.

6.3.9 Приобретение: Планирование

Согласно ИСО/МЭК 12207, цель процессов планирования и приобретения состоит в получении продукта и (или) услуги в соответствии с потребностями приобретающей стороны. Процесс приобретения начинается с выяснения потребностей заказчика.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) подготовка к приобретению;

b) объявление о приобретении;

c) выбор поставщика;

d) заключение контрактного соглашения;

e) мониторинг соглашения.

6.3.10 Приобретение: Закрытие

Согласно ИСО/МЭК 12207, цель процесса закрытия состоит в завершении процесса приобретения продукта и (или) услуги, после того как установлено, что они соответствуют потребностями приобретающей стороны. Процесс приобретения заканчивается приемкой продукта и (или) услуги, необходимых приобретающей стороне.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) приемка приобретающей стороной;

b) закрытие.

6.3.11 Ввод в действие: Планирование

Согласно ИСО/МЭК 15288, цель процесса ввода в действие состоит в определении возможности предоставлять услуги, определенные требованиями правообладателя, в среде применения. Ввод в действие заключается в инсталляции верифицированного приложения вместе с соответствующими обеспечивающими системами, например операционной системой, системой сопровождения, системой обучения операторов, системой обучения пользователей, как это определено в соглашениях. Цель стадии планирования в процессе ввода в действие заключается в создании плана ввода в действие.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) итерация стадии планирования;

b) управление итерациями;

c) оценка результатов.

6.3.12 Ввод в действие: Разработка

Согласно ИСО/МЭК 15288, цель процесса ввода в действие состоит в определении возможности предоставлять услуги, определенные требованиями правообладателя, в среде применения. Ввод в действие заключается в инсталляции верифицированного приложения вместе с соответствующими обеспечивающими системами, например операционной системой, системой сопровождения, системой обучения операторов, системой обучения пользователей, как это определено в соглашениях. Цель стадии выполнения в процессе ввода в действие состоит в реализации ввода в действие.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) проектирование решения;

b) тестирования разработчиками;

c) реализация решения;

d) проведение тестирования разработчиками;

e) интеграция и создание сборки.

6.3.13 Ввод в действие: Тестирование

Согласно ИСО/МЭК 15288, цель процесса ввода в действие состоит в определении возможности предоставлять услуги, определенные требованиями правообладателя, в среде применения. Ввод в действие заключается в инсталляции верифицированного приложения вместе с соответствующими обеспечивающими системами, например операционной системой, системой сопровождения, системой обучения операторов, системой обучения пользователей, как это определено в соглашениях. Цель стадии тестирования в процессе ввода в действие заключается в проверке успешности ввода в действие.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) реализация тестирования;

b) проведение тестирования.

6.3.14 Использование: Применение

Согласно ИСО/МЭК 15288, цель использования состоит в применении приложения для того, чтобы оказывать услуги. Процесс использования включает назначение сотрудников для управления приложением и мониторинга услуг, а также производительности операторов и приложения. Для обеспечения непрерывности предоставления услуг, персонал определяет и анализирует проблемы, возникающие при функционировании по отношению к соглашениям, правообладателям, требованиям и организационным ограничениям.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) определение организационных процессов, на которые воздействует приложение;

b) адаптация важных организационных процессов к приложению;

c) определение ролей;

d) определение информационных групп (записей);

e) анализ рисков, связанных с доступом к приложению;

f) присвоение ролей, обязанностей, квалификаций и полномочий;

g) одобрение запросов на доступ и управление ими;

h) обучение пользователей;

i) осуществление действий и предоставление услуг, связанных с приложением;

j) выполнение запросов;

k) управление инцидентами;

l) управление проблемами;

m) управление доступом;

n) управление событиями;

o) управление запросами на внесение изменений;

p) выполнение гибкой и оперативной валидации;

q) мониторинг и контроль действий приложения;

r) мониторинг и контроль использования ресурсов приложением.

6.3.15 Использование: Сопровождение

Согласно ИСО/МЭК 15288, цель процесса сопровождения заключается в том, чтобы обеспечить приложению возможность предоставлять услуги. Мероприятия сопровождения направлены на мониторинг возможности приложения предоставлять услуги, регистрацию проблем для анализа, принятие корректирующих, адаптивных, улучшающих и предотвращающих действий, а также подтверждение восстановления работоспособности.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) определение обязанностей по обеспечению сопровождения и средств связи;

b) получение результатов из собранной информации о сопровождении;

c) создание плана работ по обеспечению сопровождения;

d) определение процессов и услуг, связанных с сопровождением;

e) обучение в области сопровождения;

f) осуществление процесса сопровождения;

g) введение новшеств и развертывание средств сопровождения;

h) управление событиями и запросами;

i) планирование сопровождения;

j) мониторинг и контроль запросов и событий;

k) соглашение об уровне услуг и управление соглашениями с поставщиками;

l) оказание услуг перед поставкой и вводом в действие;

m) оказание услуг сопровождения во время эксплуатации;

n) оказание услуг по развитию программного обеспечения и устранению ошибок;

o) верификация и валидация;

p) конфигурирование и управление версиями;

q) обеспечение качества процессов, услуг и программного обеспечения (продукта);

r) анализ и измерение результатов сопровождения;

s) причинный анализ и решение проблем;

t) обновление, перенос и вывод из эксплуатации программных средств.

6.3.16 Архивирование: Обеспечение

Согласно ИСО/МЭК 15489, цель процесса архивирования заключается в ведении всех важных электронных и бумажных записей. Процесс архивирования призван обеспечить надлежащее хранение, легкий доступ и правильное документирование записей с момента создания до утилизации.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) определение и анализ политики организации в сфере сбора данных;

b) определение правил хранения данных;

c) предоставление доступа к записям;

d) сохранение записей;

e) контроль архивного использования;

f) содействие в использовании архивов;

g) управление услугами по администрированию архивов;

h) управление услугами по поиску и обучению работе с архивами;

i) управление публичным доступом к архивам и публичными программами.

6.3.17 Уничтожение: Обеспечение

Согласно ИСО/МЭК 15288, цель процесса уничтожения заключается в прекращении существования приложения. В ходе процесса уничтожения происходят деактивация, разборка и снятие системы и остаточных продуктов, их приведение в финальное состояние и возврат среды в первоначальное или приемлемое состояние.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) определение общего графика изъятия и списания программных средств;

b) определение графика классификации и сохранения записей;

c) определение графиков изъятия операционных записей;

d) определение графиков передачи прав владения собственностью;

e) определение стандартных административных процедур;

f) определение процедур ведения записей;

g) определение действий по процедуре списания;

h) управление изменениями в организации;

i) определение действия по изъятию;

j) авторизация уничтожения записей;

k) управление процедурами ведения записей;

l) подготовка записей к получению разрешения на уничтожение;

m) выбор процесса удаления записей;

n) осуществление процесса удаления записей;

o) верификация удаления записей;

p) мониторинг и анализ результативности управления записями;

q) отправка отчета с информацией о ключевых показателях результативности руководству;

r) внедрение регулярного режима отправки отчетов в целях мониторинга и анализа результативности управления записями;

s) проведение оценки управления записями.

6.4 Менеджмент инфраструктуры

6.4.1 Общие положения

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

6.4.2 Создание инфраструктуры

Согласно ИСО/МЭК 15288, цель процесса создания инфраструктуры состоит в определении требований к проектной инфраструктуре, а также коммерческих ограничений, которые влияют на выделение инфраструктурных ресурсов и услуг для проекта. Процесс включает определение и предоставление инфраструктурных ресурсов и услуг, необходимых для реализации и поддержки ввода в действие и эксплуатации приложений.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) подготовка, настройка и установка сред разработки, тестирования, эксплуатации и архивирования;

b) создание и обновление документов по конфигурации;

c) валидация и обновление плана по обеспечению бесперебойного функционирования и планов на случай внештатных ситуаций;

d) создание руководства пользователя;

e) создание руководства администратора;

f) корректировка корпоративных процедур и политик, затронутых в результате перевода систем на работу онлайн, а также информирование действующих субъектов и правообладателей, затронутых этими изменениями;

g) проведение приемочных испытаний для проверки основных функций.

6.4.3 Сопровождение инфраструктуры

Согласно ИСО/МЭК 15288, цель процесса сопровождения инфраструктуры состоит в непрерывной или регулярной сверке с требованиями проектов, чтобы определить, насколько предоставляемые инфраструктурные ресурсы им удовлетворяют. Процесс включает определение и внесение улучшений или изменений в инфраструктурные ресурсы по мере того, как проектные требования меняются. Обычно этот процесс выполняется несколько раз на основе цикла планирование-исполнение-проверка-принятие мер.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) сопровождение системы при запланированном уровне доверия;

b) применение лучших методов при управлении идентификационной информацией и конфигурацией;

c) проведение периодических аудитов и проверок внутренней безопасности;

d) осуществление контроля изменений;

e) подготовка сред эксплуатации;

f) создание и обновление документов, описывающих конфигурацию;

g) валидация и обновление плана по обеспечению бесперебойного функционирования и планов на случай внештатных ситуаций;

h) создание руководства пользователя;

i) создание руководства администратора;

j) корректировка корпоративных процедур и политик, затронутых в результате перевода систем на работу онлайн, а также информирование действующих субъектов и правообладателей, затронутых этими изменениями.

6.5 Аудит приложений

6.5.1 Общие положения

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

6.5.2 Инициирование аудита

Согласно ИСО 19011, цель процесса инициирования аудита состоит в установлении первоначального контакта с объектом аудита и определении осуществимости аудита.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) установление первоначального контакта с объектом аудита;

b) подтверждение полномочий для проведения аудита;

c) предоставление информации о целях, объеме, методах аудита, а также составе аудиторской группы, в том числе технических экспертах;

d) запрос доступа к соответствующим документам и записям;

e) определение применимых юридических и контрактных требований, а также других требований, относящихся к действиям и продуктам объекта аудита;

f) подтверждение соглашения с объектом аудита относительно объемов раскрытия и использования конфиденциальной информации;

g) установление договоренностей о присутствии наблюдателей и необходимости назначения кураторов для аудиторской группы;

h) определение конкретных вопросов, связанных со взаимодействием, в том числе относящихся к площадке взаимодействия или областям интересов и проблем объектов аудита;

i) ограничение количества выполняемых задач исходя из временных и ресурсных ограничений, а также характера сотрудничества объекта аудита;

j) достижение договоренностей по проведению аудита, в том числе относительно графика.

6.5.3 Подготовка аудита

Согласно ИСО 19011, цель процесса подготовки аудита состоит в проверке документации перед аудитом, подготовке плана аудита, распределении работ в аудиторской группе и подготовке рабочей документации.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) анализ целей и объемов аудита;

b) анализ и определение рисков, связанных с отраслью деятельности объекта аудита, включая экономические условия, законы и нормативы, а также технологические изменения;

c) анализ и определение риска, связанного со структурой объекта аудита, ключевыми бизнес-процессами, системами и приложениями;

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

e) оценка рисков нарушений и противоправных действий во время аудита;

f) оценка риска, который аудит несет организации объекта аудита;

g) оценка потенциальных слабых мест или отсутствия мер контроля, а также их потенциальное влияние на выводы (наблюдения) аудита;

h) определение плана сотрудничества, включая объем аудита, цели, риски, коммуникационный план, сроки, объем затрачиваемых ресурсов и выводы;

i) определение методов сбор и оценки информации о рассматриваемом(ых) процессе(ах);

j) определение методов для валидации мер и средств контроля и управления, а также результатов;

k) определение методов для выявления остаточного риска там, где оценка эффективности управления недопустима.

6.5.4 Проведение аудита

Согласно ИСО 19011, цель проведения аудита заключается в выполнении фактических мероприятий аудита, в том числе проведении открытых собраний, проверке документации во время аудита, общении во время аудита, распределении ролей и обязанностей наблюдателей и кураторов, сборе и верификации информации, получении выводов, подготовке заключений по результатам аудита и проведении финальных встреч.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) проведение открытого собрания;

b) распределение ролей и обязанностей между наблюдателями и кураторами;

c) уточнение понимания целей аудита и уточнение его объема;

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

e) осуществление контроля и действия по утвержденному плану аудита для покрытия выявленных рисков согласно утвержденному графику;

f) получение достаточных и надлежащих доказательств для проведения анализа, который позволит сделать обоснованные выводы об эффективности структуры мер и средств контроля и управления и (или) результатах достижения целей контроля;

g) применение дополнительных процедур тестирования для получения достаточных и надлежащих доказательств в случаях, когда работа внутренних и (или) внешних экспертов не дает достаточных и надлежащих доказательств;

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

i) подготовка надлежащего заключения по аудиту или выводов, подкрепленных анализом и доказательствами, а также описанием факторов, ограничивающих объем аудита в случаях, когда требуемые доказательства не были получены во время дополнительных процедур тестирования;

j) проведение заключительного собрания.

6.5.5 Отчет

Согласно ИСО 19011, цель представления отчетов заключается в подготовке и распространении отчета об аудите.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) представление отчета в соответствии с утвержденными стандартами;

b) распространение отчета об аудите, учитывая ограничения.

Примечание - Стандарты отчетности включают:

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

6.5.6 Завершение аудита

Согласно ИСО 19011, цель завершения аудита состоит в закрытии процедуры аудита. Аудит объявляется закрытым, когда выполнены все запланированные мероприятия или иная договоренность с объектом аудита (например, в случае непредвиденной ситуации, которая может помешать завершению аудита согласно плану).

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) документирование и обобщение полученного опыта;

b) архивирование и ликвидация свидетельств согласно контракту и применимым положениям.

6.5.7 Последующие мероприятия

Согласно ИСО 19011, цель проведения последующих мероприятий по итогам аудита заключается в том, чтобы сделать выводы о необходимости изменений или корректирующих, превентивных действий или мероприятий по улучшению.

Обозначения мероприятий, определенных согласно ЭМЖЦБП для этой области, включают следующие:

a) проведение последующего собрания;

b) анализ плана действий, а также выполненных мероприятий;

c) анализ соответствия плана и выполненных действий выводам (наблюдениям) аудита и рекомендациям.

6.6 Роли

Действующие субъекты и роли, определенные в ЭМЖЦБП, должны использоваться в качестве ориентира при описании МОБП с целью указать, какие ресурсы должны быть выделены для выполнения мероприятий или задач, связанных с МОБП.

Допустимы следующие значения ролей:

a) Приобретающая сторона

Отдельное лицо, которое приобретает или получает продукт или услугу у поставщика. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению бизнесом.

b) Любая роль

Отдельное лицо, занятое в работе над приложением. Эту роль выполняют все действующие субъекты и правообладатели.

c) Администратор приложения

Отдельное лицо, ответственное за параметризацию и предоставление доступа к приложению. Действующие субъекты, выступающие в этой роли, могут быть членами группы по управлению ИТ.

d) Архитектор приложения

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

e) Оператор приложения

Отдельное лицо, ответственное за работу приложения и управление им.

Примечание - Оператор приложения может отвечать за управление правами пользователя приложения, функциональность и интерфейсы приложения.

Эта роль также известна как системный оператор или системный администратор.

f) Владелец приложения

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

g) Соответствующее руководство, несущее ответственность

Самый высокопоставленный персонал, несущий ответственность за безопасное использование приложения в организации. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению.

h) Аудитор

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

i) Главный сотрудник по вопросам (информационной) безопасности

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

j) Индивидуально определяемая роль

Роль, определяемая организацией. Добавляет гибкости для адаптирования эталонной модели к особым организационным контекстам и требованиям.

k) Разработчик

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

l) Специалист в предметной области

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

m) Архитектор ИТ-инфраструктуры

Отдельное лицо, ответственное за проектирование технологической инфраструктуры, требуемой для предоставления услуг. Действующие субъекты, выступающие в этой роли, являются членами группы по управлению ИТ.

n) Эксперт по ИТ-инфраструктуре

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

o) Эксперт в области законов и нормативных актов

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

p) Руководитель

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

q) Владелец

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

r) Проектный менеджер

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

s) Архитектор по безопасности

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

t) Поставщик

Юридическое или физическое лицо, заключающее соглашение с приобретающей стороной о поставке продукта или услуги. Действующие субъекты, выступающие в этой роли, являются членами группы внешних экспертов.

u) Тестировщик

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

v) Инструктор

Отдельное лицо, которое обучает людей. Физическое лицо, выступающее в этой роли, может быть членом внутренней или внешней группы экспертов.

w) Пользователь

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

7 Пакет МОБП

Пакет МОБП — контейнер, в котором связанные МОБП сгруппированы и объединены вместе в целях облегчения их передачи (см. рисунок 15). В случае необходимости должна быть возможность определить источник происхождения пакета МОБП и подтвердить его целостность.

Пакет МОБП должен содержать следующую информацию:

a) Содержимое пакета (О): в том числе:

1. идентификационная информация о пакете (О): информация, необходимая для того, чтобы идентифицировать пакет МОБП, например:

i) уникальный ID (О): уникальный идентификационный номер этого пакета (например, находящийся в ведении редакторов);

ii) дата (О): дата создания;

iii) номер версии (Н): номер версии;

iv) имя (О): название пакета МОБП;

v) цель (Н): цель использования этого пакета МОБП (например: МОБП используется для удовлетворения требований, связанных с онлайн-платежами);

vi) описание (Н): описание пакета;

vii) редактор (Н): имя и координаты редактора;

2. МОБП (О): один или множество МОБП (см. раздел 5).

b) Электронная подпись редактора пакета (Н): цифровые подписи для валидации источника и целостности пакета.

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

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ISO/IEC 27034-1	IDT	ГОСТ Р ИСО/МЭК 27034-1-2014 «Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия»
Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: - IDT — идентичный стандарт.

[1]	ISO/IEC 12207 System and software engineering — Software life cycle processes (Системная и программная инженерия. Процессы жизненного цикла программных средств)
[2]	ISO/IEC 15288 System and software engineering — System life cycle processes (Системная инженерия. Процессы жизненного цикла систем)
[3]	ISO/IEC 15489 Information and documentation — Records management (Информация и документация. Управление документами)
[4]	ISO/IEC 19011 Guidelines for auditing management system (Руководящие указания по аудиту систем менеджмента)
[5]	ISO/IEC 20000 Information technology — Service management (Управление услугами)
[6]	ISO/IEC 27034-2:2015 Information technology — Security techniques — Application security — Part 2: Organization normative framework (Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 2. Нормативная структура организации)
[7]	ISO/IEC 27034-3 Information technology — Security techniques — Application security — Part 3: Application security management process (Информационная технология. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 3. Процесс менеджмента безопасности приложений)
[8]	ISO/IEC 37500 Guidance on outsourcing (Руководство по аутсорсингу)

УДК 006.34:004.056:004.056.5:004.056.53:006.354	ОКС 35.030
Ключевые слова: методы и средства обеспечения безопасности, меры обеспечения безопасности приложений, управление безопасностью протоколов и приложений, информационный элемент

---