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

6 Этапы процесса менеджмента безопасности приложений

 

6.1 Определение среды и требований приложения

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

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

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

Первый этап ПМБП направлен на установление всех требований приложения, в том числе:

a) действующие субъекты;

b) спецификации;

c) информация;

d) среда.

Среда приложения состоит:

a) из технологического контекста;

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

c) регулятивного контекста.

Подробнее описание контекстов приведено в ИСО/МЭК 27034-1:2011 (подпункты 8.1.2.1 - 8.1.2.2).

6.1.2 Назначение

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

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

b) идентифицировать, провести инвентаризацию и консолидировать информацию для анализа рисков безопасности приложений;

c) определить предварительную версию НСП.

6.1.3 Результаты

Основные результаты данного этапа включают в себя:

a) определение лица, официально назначенного владельцем приложения;

b) предварительную нормативную структуру приложения, в том числе:

1) краткое описание трех контекстов;

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

3) архитектуру приложения (в том числе с учетом среды эксплуатации);

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

6.1.4 Мероприятия по реализации

В таблице 3 приведены роли и обязанности, связанные с действиями по реализации процесса "Определение среды и требований приложения".

 

Таблица 3

 

Диаграмма RACI для процесса "Определение среды

и требований приложения"

 

Мероприятия по реализации	Группа НСО	Владелец приложения	Менеджер проекта
1) Определение и назначение владельца приложения	A/R
2) Реализация ПМБП в проекте		A	R
3) Определение потребностей организации, влияющих на характеристики приложения	A	A/R	I
4) Определение требования приложения, то есть все требования и спецификации, которым должно соответствовать приложение	C	A/R	I
5) Идентификация и классификация информационных групп, используемых приложением, и потока информации между компонентами приложения, а также между приложением и другими системами (см. рисунок 1)	C	A/R	I
6) Определение бизнес-контекста приложения, включая процессы, участников и бизнес-требования, связанные с реализацией и использованием приложения	A/R
7) Определение регулятивного контекста приложения, т.е. законов и нормативных актов, которые применяются к приложению	C	A/R	I
8) Определение технологического контекста приложения, т.е. все ИТ-компоненты, необходимые для разработки, развертывания, мониторинга и обслуживания приложения	C	A/R	C/I
9) Валидация, верификация и интегрирование результатов этой деятельности в предварительную НСП	C	A/R	C/I

 

6.1.5 Мероприятия по верификации

Роли и обязанности, связанные с действиями по верификации процесса "Определение среды и требований приложения", приведены в таблице 4.

 

Таблица 4

 

Диаграмма RACI для верификации процесса

"Определение среды и требований приложения"

 

Мероприятия по верификации	Группа НСО	Менеджер проекта	Владелец приложения	Аудиторы	Проектная группа
1) Подтверждение того, что владелец приложения был назначен для этого проекта приложения	A			R
2) Сбор документации о контекстах безопасности приложений (бизнес-контекст, регулятивный и технологический контексты)		C	I	A/R	C
3) Сбор спецификации приложения и описание связанных с ним процессов		C	I	A/R	C
4) Сбор классифицированных информационных групп и диаграмм потоков информации.		C	I	A/R	C
5) Сбор доказательств того, что действующие субъекты были идентифицированы, и сведения о каждом из них были задокументированы		C	I	A/R	C
6) Сбор спецификаций приложений, документов с требованиями и архитектурных диаграмм		C	I	A/R	C

 

6.1.6 Рекомендации

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

Процесс, определяющий требования и среду приложения, включает в себя идентификацию компонентов, начиная с действующих субъектов.

Выявленные действующие субъекты предоставляют информацию для определения среды и контекста приложения.

Действия, необходимые для определения требований и среды приложения, включают в себя:

a) определение действующих субъектов;

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

c) анализ информации, используемой приложением;

d) определение среды приложения.

6.1.6.2 Определение действующих субъектов

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

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

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

6.1.6.3 Определение спецификации организационной безопасности приложения

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

a) спецификации требований к программному обеспечению, например TLS <1>, SSH <2>, SFTP <3>;

--------------------------------

<1> Сетевой протокол транспортного уровня (протокол TCP).

<2> Сетевой протокол прикладного уровня (протокол SSH).

<3> Сетевой протокол прикладного уровня (протокол SFTP).

 

b) политики безопасности организации, включая требования к паролю;

c) нормативно-правовые документы;

d) организационные и бизнес-цели и (или) видения;

e) архитектурные диаграммы.

6.1.6.4 Анализ информации, используемой приложением

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

Поток пакетов данных во внутренней сети имеет решающее значение с точки зрения проверки запрашиваемых данных от источника до места назначения.

6.1.6.5 Развертывание среды приложения

Среда приложения определяется путем подробного описания его технологического, регулятивного контекстов и бизнес-контекста.

Примечание - Для создания НСП необходимо задокументировать всю значимую информацию, полученную в результате реализации каждого мероприятия, а также проверить правильность информации и самого процесса на последующих этапах.

 

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

Примеры

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

2 Организации могут согласовать МОБП для каждого этапа разработки. МОБП содержат заранее определенные процессы обеспечения безопасности и выполнения верификации, критерии и ожидаемые результаты для обработки ошибок или угроз для безопасности приложения. Например, они могут согласовать, что все уязвимости вида SQL<4>-инъекция, должны быть отработаны и исправлены определенным образом до проверки кода.

--------------------------------

<4> Язык структурированных запросов (SQL).

 

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

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

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