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

    ГОСТ Р ИСО/МЭК 27034-3-2021

 

 НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

 

 

 Информационные технологии

 

 МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

 

 Безопасность приложений

 

 Часть 3

 

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

 

 Information technology. Security techniques. Application security. Part 3. Application security management process

ОКС 35.030

Дата введения 2021-11-30

 

 Предисловие

     

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

 

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

 

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ

Приказом Федерального агентства по техническому регулированию и метрологии от 14 мая 2021 г. N 351-ст

 

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 27034-3:2018 "Информационные технологии. Безопасность приложений. Часть 3. Процесс менеджмента безопасности приложений" (ISO/IEC 27034-3:2018 "Information technology - Application security - Part 3: Application security management process", IDT).

 

           

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

 

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с

ГОСТ Р 1.5-2012  (пункт 3.5).

 

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

приложении ДА .

 

Дополнительные сноски в тексте стандарта, выделенные курсивом, приведены для пояснения текста оригинала

 

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

 

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

 

Правила применения настоящего стандарта установлены в

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

 

 

 Введение

     

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

 

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

 

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

 

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

 

Таблица 1 - Обзор структуры ИСО/МЭК 27034

 

 

 

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

Структура ИСО/МЭК 27034

Описание

Организация

Нормативная структура организации (НСО)

Единый централизованный репозиторий информации о безопасности приложений

 

Процесс менеджмента НСО

Процесс сопровождения и постоянного улучшения НСО

Приложение

Нормативная структура приложения (НСП)

Репозиторий для всех мер обеспечения безопасности приложения

 

Процесс менеджмента безопасности приложения

Процесс, основанный на оценке риска, который использует НСП для создания и валидации приложений

 

Как показано в таблице 1, структура и процессы на уровне организации основаны на нормативной структуре организации (НСО). НСО, ее элементы и поддерживающие процессы определены в ИСО/МЭК 27034-2.

 

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

 

Описание процессов определения требований приложения и его среды содержится в 6.1-6.5. Идентификация требований приложения и его среды, а также оценка рисков с точки зрения безопасности приложения описывается в 6.1. Оценка целевого уровня доверия приложения рассматривается в 6.2; создание и поддержание нормативной структуры приложения (НСП), а также меры обеспечения безопасности приложения (МОБП) определены в 6.3; процессы, относящиеся к реализации и эксплуатации приложения, приведены в 6.4. Наконец, в 6.5 содержится описание процесса проверки правильности реализации НСП и МОБП.

0.2 Назначение

 

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

________________

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

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

 

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

 

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

 

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

 

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

 

c) приобретающих сторон;

 

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

 

e) аудиторов;

 

f) пользователей.

 

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

 

Руководители - это лица, вовлеченные в процесс управления приложением. К руководителям относятся:

 

a) менеджеры по информационной безопасности, включая директора по информационной безопасности (Chief Information Security Officer, CISO);

 

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

 

c) менеджеры по продуктовой линейке;

 

d) менеджеры по развитию;

 

e) владельцы приложений;

 

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

 

Руководители обязаны:

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

m) гарантировать, что недостатки безопасности устраняются с помощью методов безопасного кодирования;

 

n) основывать свои решения на уроках, извлеченных из записей базы знаний.

 

0.3.3 Члены групп подготовки к работе и эксплуатации

 

Члены групп подготовки к работе и эксплуатации (проектная группа или команда приложения) - это лица, вовлеченные в проектирование, разработку и поддержку приложения на протяжение всего жизненного цикла. К членам групп подготовки к работе и эксплуатации относятся:

 

a) архитекторы;

 

b) аналитики;

 

c) программисты;

 

d) специалисты по тестированию;

 

e) ИТ-администраторы, в том числе системные администраторы, администраторы баз данных, сетевые администраторы и администраторы приложений.

 

В обязанности членов группы входит:

 

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

 

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

 

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

 

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

 

e) получение доступа к инструментальным средствам и лучшим практикам с целью оптимизации процессов разработки, тестирования и документирования;

 

f) проведение экспертной оценки;

 

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

 

h) организация мероприятий по утилизации остаточных элементов после завершения работы (например, управление имуществом/утилизация).

 

0.3.4 Приобретающие стороны

 

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

 

В обязанности приобретающих сторон входит:

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

 

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

 

c) выбор поставщиков, которые соответствуют необходимым требованиям;

 

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

 

e) оценка продуктов, подтверждающая доказательства правильности внедрения мер обеспечения безопасности приложений.

 

0.3.5 Поставщики

 

В эту категорию входят все лица, вовлеченные в поставку продукта или услуги.

 

В обязанности поставщика входит:

 

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

 

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

 

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

 

0.3.6 Аудиторы

 

Аудиторы - лица, которые должны:

 

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

 

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

 

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

 

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

 

0.3.7 Пользователи

 

Пользователи должны быть уверены в том, что:

 

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

 

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

 

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

 

 

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

Настоящий стандарт содержит подробное описание и рекомендации по внедрению процесса менеджмента безопасности приложений.

 

 

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

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

 

ISO/IEC 27000, Information technology - Security techniques - Information security management systems - Overview and vocabulary (Информационные технологии. Методы и средства обеспечения безопасности. Система менеджмента информационной безопасности. Общий обзор и терминология)

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

 

ISO/IEC 27034-2, Information technology - Security techniques - Application security - Part 2: Organization normative framework (Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 2. Нормативная структура организации)

 

ISO/IEC 27034-5, Information technology - Security techniques - Application security - Part 5: Protocols and application security controls data structure (Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 5. Структуры данных протоколов и мер обеспечения безопасности приложений)

 

 

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

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

 

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

 

- платформа ИСО для онлайн-просмотра: доступна по адресу http://www.iso.org/obp;

 

- Электропедия МЭК (IEC Electropedia): доступна по адресу http://www.electropedia.org/

          

3.1 аудит безопасности приложения (application security audit): Систематический, независимый и документированный процесс получения аудиторских доказательств при проверке действий в области безопасности приложения и его объективной оценки для определения степени выполнения критериев аудита, требуемых органом контроля безопасности приложений.

 

3.2 проверка безопасности приложения (application security verification): Процесс анализа и проверки результатов деятельности по обеспечению безопасности приложений путем выполнения верификационных измерений.

 

Примечания

 

1 Для организации требуемые элементы НСО и меры безопасности соответствуют спецификациям НСО и процессу менеджмента НСО.

 

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

 

3.3 критическая информация (critical information): Информация, которая в случае компрометации может привести к неприемлемому риску.

 

3.4 эксперт в предметной области (domain expert): Человек, который является экспертом в определенной области или теме.

 

3.5 менеджмент риска (risk management): Скоординированные действия по руководству и управлению организацией в отношении риска.

 

[Руководство ИСО 73:2009, статья 2.1]

 

Примечание - В настоящем стандарте используется термин "процесс" для описания управления рисками в целом. Элементы процесса менеджмента рисков называются "действиями".

 

 

      4 Сокращения

БП - безопасность приложений (AS);

 

МОБП - меры обеспечения безопасности приложений (ASC);

 

НСО - нормативная структура организации (ONF);

 

НСП - нормативная структура приложений (ANF);

 

ПМБП - процесс менеджмента безопасности приложений (ASMP);

 

ЭМЖЦБП - эталонная модель жизненного цикла безопасности приложений (ASLCRM).

 

 

      5 Процесс менеджмента безопасности приложений

 

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

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

 

Группа НСО отвечает за внедрение и поддержку ПМБП с использованием процесса менеджмента НСО [см. ИСО/МЭК 27034-2:2015 (пункт 5.4.3)]. Эта группа также несет ответственность за обеспечение применения ПМБП ко всем проектам приложений в организации.

 

Владелец приложения несет ответственность за обеспечение наличия ПМБП для проекта приложения (см. таблицу 3).

 

В рамках каждого проекта приложения руководитель проекта отвечает за реализацию и использование ПМБП в ходе реализации проекта (см. таблицу 3).

 

Процесс менеджмента безопасности приложения включает в себя пять этапов:

 

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

 

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

 

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

 

d) подготовку к работе и эксплуатацию приложения;

 

e) аудит безопасности приложения.

 

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

 

Заключительные два этапа ПМБП направлены на внедрение и проверку МОБП.

 

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

 

Как показано на рисунке 1, эти компоненты, процессы и структуры являются частью двух общих процессов:

 

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

 

b) процесса менеджмента безопасности приложения (ПМБП).

 

 

 

 

Рисунок 1 - Процесс менеджмента безопасности приложений

Указанные процессы используются в организации на разных уровнях и временных интервалах, а также имеют разные цели. Процесс менеджмента НСО (см. ИСО/МЭК 27034-2) представляет собой непрерывный процесс организационного уровня, а ПМБП используется для управления безопасностью в каждом конкретном проекте приложения.

 

 

      5.2 Назначение

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

 

 

      5.3 Принципы и понятия

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

 

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

 

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

 

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

 

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

5.3.2 Определение ролей и обязанностей

 

В настоящем стандарте для назначения ролей и обязанностей по выполнению мероприятий, входящих в процессы, используются диаграммы RACI
(Responsible - Accountable - Consulted - Informed). С помощью таких диаграмм определяются субъекты, ответственные, отчитывающиеся, консультирующие и сообщающие о выполнении действий. Для описания обязанностей субъектов используются сокращения (таблица 2).
 

________________

Ответственный за выполнение действия - Отчитывающийся за выполнение действия - Консультирующий во время выполнения действия - Сообщающий о выполнении действия (RACI).
 

Таблица 2 - Сокращения, используемые в диаграммах RACI для описания обязанностей субъектов

 

 

Код

Обязанность

R

Ответственный за выполнение действия

A

Отчитывающийся за выполнение действия

C

Консультирующий во время выполнения действия

I

Сообщающий о выполнении действия

 

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

 

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

 

5.3.3 Взаимосвязь процесса менеджмента безопасности приложений с нормативной структурой организации

 

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

 

5.3.4 Использование утвержденных инструментальных средств

 

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

 

Примечание - Описание, назначение и роль группы НСО определены в ИСО/МЭК 27034-2:2015 (пункт 5.4.3).

 

5.3.5 Уровень доверия приложения

 

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

 

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

 

b) фактический уровень доверия приложения.

 

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

 

5.3.6 Целевой уровень доверия приложения

 

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

 

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

 

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

 

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

 

Целевой уровень доверия приложения должен принадлежать одному из уровней доверия приложения (или находиться в пределах диапазона), определенных в библиотеке МОБП организации [см. ИСО/МЭК 27034-1:2011 (подпункт 8.1.2.6)], которая является частью НСО.

 

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

 

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

Примеры

 

1 Критически важные бизнес-приложения, внутренние приложения, общедоступные приложения.

 

2 Универсальное общедоступное веб-приложение: целевой уровень доверия приложения - это общедоступное приложение, технологический контекст - веб-приложение с базой данных, бизнес-контекст - приложение хранит и обрабатывает пароли конечных пользователей.

 

5.3.7 Фактический уровень доверия приложения

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

5.3.8 Влияние настоящего стандарта на проект приложения

 

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

 

На рисунке 2 показано, как настоящий стандарт помогает добавить новые роли, обязанности, компоненты и процессы в типовой проект приложения.

 

 

 

 

Рисунок 2 - Влияние настоящего стандарта на роли и обязанности в типовом проекте приложения

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

 

 

      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
, SSH
, SFTP
;
 

________________

Сетевой протокол транспортного уровня (протокол TCP).
 
Сетевой протокол прикладного уровня (протокол SSH).
 
Сетевой протокол прикладного уровня (протокол SFTP).
 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Примеры

 

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

 

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

________________

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

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

 

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

 

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

 

 

      6.2 Оценка рисков безопасности приложений

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

 

Второй этап ПМБП соответствует процессу оценки риска для конкретного проекта приложения.

 

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

 

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

 

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

 

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

 

 

 

 

Рисунок 3 - Логический поток от рисков безопасности приложения к снижению рисков

Риски безопасности приложения, вытекающие из его контекста и среды [которые определены на шаге 1 (подраздел 6.1)], устанавливают требования безопасности и соответствующий набор применимых МОБП. На рисунке 3 обозначение "n..n" соответствует отношению "многие ко многим", а "1..n" - "один ко многим".

 

Этап оценки риска ПМБП завершается определением целевого уровня доверия приложения [см. ИСО/МЭК 27034-1:2011 (пункт 8.2.4)], который должен быть одобрен его владельцем.

 

Примечания

 

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

 

2 Для приложений, которые работают с персональными данными, риски для конфиденциальности также учитываются в процессе оценки риска.

 

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

 

6.2.2 Назначение

 

Задачей процесса оценки рисков является:

 

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

 

b) для организации: консолидировать и поддерживать информацию о рисках, связанных с приложением, в НСО.

 

6.2.3 Результаты

 

Результатами выполнения мероприятий данного процесса являются:

 

a) создание предварительной версии НСП, которая содержит информацию о среде приложения, а также информацию, полученную в результате выполнения этого процесса, в том числе:

 

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

 

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

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

 

b) обновление информации о безопасности приложения в НСО.

 

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

 

В таблице 5 показаны роли и обязанности по выполнению действий в ходе реализации процесса "Оценка рисков безопасности приложения".

 

Таблица 5 - Диаграмма RACI для реализации этапа ПМБП "Оценка рисков безопасности приложения"

 

 

 

 

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

Группа НСО

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

Проектная группа

1) Выявление и оценка рисков безопасности, связанных с приложением

C

A/R

C

2) Выявление и оценка степени, в которой ранее выявленные угрозы безопасности были устранены в приложении

C

A

R

3) Определение минимальных требований безопасности для приложения (с учетом недопустимых угроз безопасности)

C

A/R

C

4) Определение целевого уровня доверия приложений для приложения, отвечающего всем определенным требованиям безопасности

C

A/R

C

5) Подтверждение и утверждение целевого уровня доверия приложения

I

A

R

6) Сбор информации по результатам анализа рисков в соответствии с 6.1.3

C

A/R

C

7) Обновление содержимого НСП

A

I

R

8) Обновление содержимого НСО

A/R

C

C

9) Обеспечение доступности к информации заинтересованных сторон

I

A/R

I

 

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

 

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

 

Таблица 6 - Диаграмма RACI для верификации этапа ПМБП "Оценка рисков безопасности приложения"

 

 

 

 

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

Менеджеры

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

Группа проверки

1) Сбор исходных данных и результатов анализа рисков безопасности приложений

C

C/I

A/R

2) Сбор исходных данных и результатов анализа рисков безопасности приложения

C

C/I

A/R

3) Гарантия того, что риск безопасности приложения был точно оценен с учетом определенного набора мер обеспечения безопасности приложения

C

C/I

A/R

4) Подтверждение того, что целевой уровень доверия приложения был определен и утвержден

C

C/I

A/R

5) Подтверждение того, что владелец приложения согласился с остаточными рисками, связанными с приложением

C

C/I

A/R

 

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

 

6.2.6.1 Область оценки рисков для безопасности приложения

 

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

 

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

 

 

 

 

Рисунок 4 - Пример жизненного цикла безопасности приложения

6.2.6.2 Идентификация рисков, связанных с приложением

 

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

 

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

 

6.2.6.3 Анализ рисков, связанных с приложением

 

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

 

Анализ рисков является первым шагом в процессе оценки риска. Анализ рисков для приложений часто выполняется в два этапа:

 

a) высокоуровневый анализ рисков;

b) детальный анализ рисков.

 

6.2.6.3.2 Высокоуровневый анализ рисков безопасности приложения

 

Процесс высокоуровневого анализа рисков безопасности приложения обычно выполняется на этапе подготовки в жизненном цикле приложения, как приведено в ИСО/МЭК 27034-1:2011 (подпункт 8.2.2.1).

 

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

 

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

 

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

 

Примеры

 

1 Применяется ли приложение только внутренними пользователями или используется через Интернет?

 

2 Это веб-приложение или приложение для ПК?

 

3 Обрабатывает ли приложение данные кредитных карт?

 

4 Имеется ли в приложении компонент для мобильных устройств?

 

6.2.6.3.3 Детальный анализ рисков безопасности приложения

 

Процесс детального анализа рисков выполняется на этапе реализации жизненного цикла приложения, как приведено в ИСО/МЭК 27034-1:2011 (подпункт 8.2.2.2).

 

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

 

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

 

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

 

Ниже приведены примеры вопросов, задаваемых в ходе выполнения детального анализа рисков для приложения.

 

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

 

Пример 2 - Используется ли для аутентификации база данных или Active Directory?

 

Пример 3 - Поддерживает ли приложение авторизацию на основе ролей?

 

Пример 4 - Включает ли приложение код JavaScript?

 

На основе ответов на вопросы, которые задаются в процессе анализа рисков, формулируются требования безопасности. Эти требования безопасности должны быть задокументированы в НСП (подробнее см. подраздел 6.3). Например:

 

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

 

6.2.6.3.4 Методы детального анализа рисков приложений

 

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

 

6.2.6.3.4.1 Моделирование угроз

 

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

Моделирование угроз выполняется группой, включающей в себя руководителей программ/проектов, разработчиков и тестировщиков, и является основной задачей анализа безопасности, выполняемой на этапе разработки программного обеспечения.

 

6.2.6.3.4.2 Анализ модели угроз и поверхности атаки

 

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

 

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

 

6.2.6.4 Анализ рисков, связанных с приложением

 

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

 

a) необходимость в какой-либо процедуре;

 

b) приоритеты при обработке рисков с учетом установленных значений уровней рисков.

 

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

 

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

 

6.2.6.5 Мероприятия по оценке рисков, связанных с безопасностью приложений

 

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

 

a) получение необходимой информации от НСП. Эта информация, обычно предоставляемая на первом этапе ПМБП, должна включать в себя:

 

1) требования приложения;

 

2) среду приложения:

 

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

 

ii) регулятивный контекст;

 

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

 

3) информацию, полученную, сохраненную, обработанную или предоставленную приложением;

 

4) категорию безопасности для этой информации;

 

5) поток этой информации в приложении;

 

6) определение критической для организации информации;

 

7) спецификации, функции и компоненты приложения, а также информацию, с которой они работают;

 

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

 

9) действующие субъекты, вовлеченные в эти спецификации и процессы;

 

b) категоризация спецификаций, процессов и действующих субъектов в соответствии с категоризацией информации, с которой они работают (они наследуют категории информации);

 

c) определение критических спецификаций, процессов и действующих субъектов;

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

 

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

 

f) определение влияния на организацию на основе внутренней и эксплуатационной ценности критической информации в приложении;

 

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

 

h) определение стратегии по снижению этих рисков;

 

i) для каждого неприемлемого риска необходимо определить предпочтительную стратегию снижения, например: обработку, перенос, допущение или прекращение;

 

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

 

6.2.6.6 Требования безопасности приложений

 

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

 

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

 

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

 

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

 

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

 

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