Национальный стандарт РФ ГОСТ Р ИСО/МЭК ТО 15446-2008 "Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности" (утв. введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2008 г. N 526-ст) (утратил силу)

Национальный стандарт РФ ГОСТ Р ИСО/МЭК ТО 15446-2008
"Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности"
(утв. приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2008 г. N 526-ст)

Information technology. Security techniques. Guide for the production of protection profiles and security targets

Дата введения 1 октября 2009 г.

Введен впервые

ГАРАНТ:

Приказом Росстандарта от 25 августа 2017 г. N 967-ст взамен настоящего ГОСТа с 1 января 2018 г. введен в действие ГОСТ Р 57628-2017 "Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности"

Введение

Предназначение профиля защиты (ПЗ) состоит в том, чтобы изложить проблему безопасности для определенной совокупности систем или продуктов информационных технологий (ИТ), далее - "объекты оценки" (ОО), и сформулировать требования безопасности для решения данной проблемы. При этом ПЗ не регламентирует то, как данные требования будут выполнены, обеспечивая таким образом независимое от реализации описание требований безопасности.

Профиль защиты включает в себя взаимосвязанную информацию, имеющую отношение к безопасности ИТ, в том числе:

a) формулировку потребности в безопасности, соответствующую проблеме безопасности и выраженную в терминах, ориентированных на пользователей ИТ;

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

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

d) функциональные требования безопасности и требования доверия к безопасности, направленные на решение проблемы безопасности в соответствии с описанием среды безопасности ОО и целями безопасности для ОО и ИТ-среды. Функциональные требования безопасности выражают то, что должно выполняться ОО и ИТ-средой для удовлетворения целей безопасности. Требования доверия к безопасности определяют степень уверенности в правильности реализации функций безопасности ОО;

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

Задание по безопасности (ЗБ) во многом похоже на ПЗ, но содержит дополнительную информацию, ориентированную на конкретную реализацию продукта или системы ИТ и разъясняющую, каким образом требования ПЗ реализуются в конкретном продукте или системе. ЗБ содержит следующую дополнительную информацию, отсутствующую в ПЗ:

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

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

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

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

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

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

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

Настоящий стандарт представляет собой руководство по разработке профилей защиты и заданий по безопасности продуктов и систем ИТ в соответствии с комплексом стандартов ИСО/МЭК 15408 (общие критерии).

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

Предполагается, что пользователи настоящего стандарта хорошо знакомы с требованиями ИСО/МЭК 15408-1 и, в частности, с приложениями В и С к нему, в которых приведено описание ПЗ и ЗБ. Авторам ПЗ и ЗБ, конечно, следует быть хорошо знакомыми с другими стандартами комплекса ИСО/МЭК 15408, включая введение, например, с парадигмой функциональных требований, описанной в ИСО/МЭК 15408-2 (подраздел 1.3).

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

В настоящем стандарте не рассматриваются такие вопросы, как регистрация ПЗ и связанные с этим задачи - обращение с защищаемой интеллектуальной собственностью (например, патентами) в ПЗ. Информацию по регистрации ПЗ см. в [1].

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

В настоящем документе использованы ссылки на следующие международные стандарты:

ИСО/МЭК 2382-8:1998 Информационная технология - Словарь - Часть 8: Безопасность

ИСО/МЭК 15408-1-2008 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель

ИСО/МЭК 15408-2-2008 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности

ИСО/МЭК 15408-3-2008 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. - Часть 3. Требования доверия к безопасности

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

В настоящем стандарте применены термины по ИСО/МЭК 15408-1.

4 Сокращения

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

ПБОр (OSP) - политика безопасности организации;

СУБД (DBMS) - система управления базами данных;

ТДБ (SAR) - требование доверия к безопасности;

ФТБ (SFR) - функциональное требование безопасности;

ЗП (RFP) - запрос предложения;

КСО (TSS) - краткая спецификация ОО;

ТДС (ТТР) - третья доверенная сторона.

5 Цель

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

В остальных приложениях приводятся примеры, иллюстрирующие применение настоящего стандарта.

Разделы 1 - 4 содержат вводные и ссылочные материалы.

Раздел 5 содержит цели и направленности настоящего стандарта.

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

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

Разделы 8 - 13 придерживаются той структуры ПЗ и ЗБ, которая установлена в ИСО/МЭК 15408-1 (см. приложение В, рисунок В.1, приложение С, рисунок С.1).

Раздел 8 представляет собой руководство по определению среды безопасности ОО в ПЗ и ЗБ в виде исходных "потребностей в безопасности" ОО.

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

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

Разделы 11 и 12 представляют собой руководство по разработке ЗБ в части краткой спецификации ОО и утверждений о соответствии ПЗ. Разделы 10 - 13 будут в основном представлять интерес для авторов и оценщиков ПЗ и ЗБ.

Раздел 13 представляет собой руководство по составлению и представлению разделов "Обоснование" в ПЗ и ЗБ.

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

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

Как упоминалось выше, в приложении А руководство вкратце представлено в виде инструкции.

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

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

Возможности применения настоящего стандарта при разработке ПЗ и ЗБ для различных типов ОО представлены в приложениях D - F. Так, в приложении D рассмотрена возможность использования настоящего стандарта при разработке ПЗ и ЗБ для межсетевых экранов, в приложении Е - для СУБД, в котором подчеркивается особая важность решения вопросов, связанных с ИТ-средой. В приложении F рассматриваются вопросы, связанные с разработкой ПЗ для третьей доверенной стороны (ТДС).

6 Краткий обзор профилей защиты и заданий по безопасности

6.1 Введение

В настоящем разделе приводится краткий обзор и содержание ПЗ и ЗБ. Рассматриваются взаимосвязи между ПЗ и ЗБ и процесс их разработки (см. также ИСО/МЭК 15408-1, приложения В и С).

6.2 Содержание профилей защиты и заданий по безопасности

Требуемое содержание ПЗ и ЗБ приведено в ИСО/МЭК 15408-1, приложение В. Пример содержания ПЗ представлен ниже:

1 Введение ПЗ

1.1 Идентификация ПЗ

1.2 Аннотация ПЗ

2 Описание ОО

3 Среда безопасности ОО

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

3.2 Угрозы

3.3 Политика безопасности организации

4 Цели безопасности

4.1 Цели безопасности для ОО

4.2 Цели безопасности для среды

5 Требования безопасности ИТ

5.1 Функциональные требования безопасности ОО

5.2 Требования доверия к безопасности ОО

5.3 Требования безопасности для ИТ-среды

6 Замечания по применению

7 Обоснование

7.1 Обоснование целей безопасности

7.2 Обоснование требований безопасности.

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

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

В раздел ПЗ "Среда безопасности ОО" включают описание аспектов среды безопасности ОО, которые должны учитываться для объекта оценки, в частности - детальное описание предположений безопасности, определяющих границы среды безопасности, угроз активам, требующим защиты (включая описание этих активов), и ПБОр, которой должен соответствовать ОО. Этот раздел ПЗ более подробно рассмотрен в разделе 8.

В раздел ПЗ "Цели безопасности" включают краткое изложение предполагаемой реакции на аспекты среды безопасности как с точки зрения целей безопасности, которые должны быть удовлетворены ОО, так и с точки зрения целей безопасности, которые должны быть удовлетворены ИТ- и не ИТ-мерами в пределах среды ОО. Данный раздел ПЗ более подробно рассмотрен в разделе 9.

В раздел ПЗ "Требования безопасности ИТ" включают функциональные требования безопасности ОО, требования доверия к безопасности, а также требования безопасности программного, программно-аппаратного и аппаратного обеспечения ИТ-среды ОО. Требования безопасности ИТ должны быть определены путем использования, где возможно, функциональных компонентов и компонентов доверия к безопасности в соответствии с ИСО/МЭК 15408-2 и ИСО/МЭК15408-3. Раздел ПЗ "Требования безопасности ИТ" более подробно рассмотрен в разделе 10.

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

В разделе ПЗ "Обоснование" демонстрируется то, что ПЗ специфицирует полную и взаимосвязанную совокупность требований безопасности ИТ и соответствующий ОО учитывает идентифицированные аспекты среды безопасности. Раздел ПЗ "Обоснование" более подробно рассмотрен в разделе 12.

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

a) раздел "Введение ПЗ" может включать в себя подраздел, описывающий организацию ПЗ, а также ссылки на другие ПЗ и другие документы;

b) раздел "Среда безопасности ОО" может включать в себя отдельные подразделы для различных доменов в ИТ-среде для ОО;

c) раздел "Требования безопасности ИТ" может быть расширен за счет включения, где необходимо, требований безопасности для не ИТ-среды.

В случае если подраздел не используется (например, политика безопасности организации, требования безопасности ИТ для среды ОО), необходимо включить в ПЗ соответствующее пояснение.

Содержание ЗБ приведено в ИСО/МЭК 15408-1, приложение С. Пример содержания ЗБ представлен в таблице 2.

В разделе "Введение ЗБ" идентифицируется ЗБ и ОО (включая номер версии) и приводится аннотация ЗБ в форме, наиболее подходящей для включения в перечень оцененных (сертифицированных) продуктов ИТ. Раздел "Введение ЗБ" более подробно рассмотрен в разделе 7.

В раздел ЗБ "Описание ОО" включают сопроводительную информацию об ОО, предназначенную для пояснения его назначения и требований безопасности. Раздел ЗБ "Описание ОО" должен также включать в себя описание конфигурации, в которой ОО подлежит оценке. Раздел ЗБ "Описание ОО" более подробно рассмотрен в разделе 7.

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

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

1.1 Идентификация ЗБ

1.2 Аннотация ЗБ

2 Описание ОО

3 Среда безопасности ОО

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

3.2 Угрозы

3.3 Политика безопасности организации

4 Цели безопасности

4.1 Цели безопасности для ОО

4.2 Цели безопасности для среды ОО

5 Требования безопасности ИТ

5.1 Функциональные требования безопасности ОО

5.2 Требования доверия к безопасности ОО

5.3 Требования безопасности для ИТ-среды

6 Краткая спецификация ОО

6.1 Функции безопасности ОО

6.2 Меры обеспечения доверия к безопасности

7 Утверждения о соответствии ПЗ

7.1 Ссылка на ПЗ

7.2 Уточнение ПЗ

7.3 Дополнение ПЗ

8 Обоснование

8.1 Обоснование целей безопасности

8.2 Обоснование требований безопасности

8.3 Обоснование краткой спецификации ОО

8.4 Обоснование утверждений о соответствии ПЗ.

В раздел ЗБ "Цели безопасности" включают краткое изложение предполагаемой реакции на аспекты среды безопасности как с точки зрения целей безопасности, которые должны соответствовать ОО, так и с точки зрения целей безопасности, которые должны соответствовать ИТ- и не ИТ-мерам в пределах среды ОО. Данный раздел ЗБ более подробно рассмотрен в разделе 9.

В раздел ЗБ "Требования безопасности ИТ" включают функциональные требования безопасности ОО, требования доверия к безопасности, а также требования безопасности программного, программно-аппаратного и аппаратного обеспечения ИТ-среды ОО. Требования безопасности ИТ должны быть определены путем использования, где это возможно, функциональных компонентов и компонентов доверия к безопасности в соответствии с ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3. Раздел ЗБ "Требования безопасности ИТ" более подробно рассмотрен в разделе 10.

В раздел "Краткая спецификация ОО" включают описание функций безопасности ИТ, реализуемых ОО и соответствующих специфицированным функциональным требованиям безопасности, а также любых мер доверия к безопасности, соответствующих специфицированным требованиям доверия к безопасности. Раздел ЗБ "Краткая спецификация ОО" более подробно рассмотрен в разделе 11.

В разделе "Утверждения о соответствии ПЗ" идентифицируются ПЗ, о соответствии которым заявляется в ЗБ, а также любые дополнения или уточнения целей или требований из этих ПЗ. Раздел ЗБ "Утверждения о соответствии ПЗ" более подробно рассмотрен в разделе 13.

В разделе ЗБ "Обоснование" демонстрируют, что ЗБ специфицирует полную и взаимосвязанную совокупность требований безопасности ИТ, соответствующий ОО учитывает определенные аспекты среды безопасности ИТ и функции безопасности ИТ и меры доверия к безопасности соответствуют требованиям безопасности ОО. Раздел ЗБ "Обоснование" более подробно рассмотрен в разделе 13.

Как и для ПЗ (см. 6.1) при разработке ЗБ допускается отступать от вышеуказанной структуры путем включения дополнительных и исключения необязательных разделов (и/или подразделов) ЗБ.

6.3 Взаимосвязь между профилями защиты и заданиями по безопасности

При сопоставлении таблиц 1 и 2 становится очевидной взаимосвязь между ПЗ и ЗБ вследствие высокой степени общности данных документов, в особенности разделов "Среда безопасности ОО", "Цели безопасности", "Требования безопасности ИТ" и, частично, - раздела "Обоснование". Если в ЗБ утверждается о соответствии ПЗ и при этом не специфицируются дополнительные функциональные требования и требования доверия к безопасности, то содержание упомянутых выше разделов ЗБ может быть идентично содержанию соответствующих разделов ПЗ. В таких случаях рекомендуется ссылка в ЗБ на содержание ПЗ с добавлением (там, где необходимо) деталей, отличающих ЗБ от ПЗ.

Следующие разделы ЗБ не имеют аналогов в ПЗ и, таким образом, являются специфичными для ЗБ:

a) раздел "Краткая спецификация ОО" - включает в себя функции безопасности ИТ, механизмы и способы обеспечения безопасности, а также меры доверия к безопасности;

b) раздел "Утверждения о соответствии ПЗ" - мотивирует и детализирует требования соответствия ПЗ;

c) подразделы раздела "Обоснование" - демонстрируют адекватность функций безопасности ИТ и мер доверия к безопасности требованиям безопасности ОО.

6.4 Учет информационных потребностей потенциальных пользователей профилей защиты и заданий по безопасности

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

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

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

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

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

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

Раздел "Требования безопасности ИТ", относящийся к ПЗ, предназначен прежде всего для разработчиков ОО, хотя информация, содержащаяся в этом разделе, вероятно, также будет интересна потребителям. Раздел ЗБ "Краткая спецификация ОО" предназначен прежде всего для оценщиков и потребителей. Если последние два раздела ПЗ не содержат достаточного количества информации, то в них необходимо поместить ссылку на другие разделы (подразделы) ПЗ (например, "Аннотация ПЗ") и документы, необходимые для полного и точного понимания представленных требований безопасности ИТ.

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

6.5 Процесс разработки профилей защиты и заданий по безопасности

Анализ приложений В и С ИСО/МЭК 15408-1 и разделов 3 - 5 ИСО/МЭК 15408-3 показывает, что разработка ПЗ и ЗБ осуществляется в следующей (нисходящей) последовательности:

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

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

c) формирование требований безопасности ИТ, направленных на удовлетворение целей безопасности.

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

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

a) идентификацию новых угроз;

b) изменение ПБОр;

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

d) корректировку требований безопасности ИТ, функций безопасности и/или мер доверия к безопасности, связанную с изменениями в технологии и затратах на разработку ОО.

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

6.6 Семейства профилей защиты

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

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

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

Если семейство ПЗ относится к конкретному типу ОО, важно, чтобы было четкое различие между различными членами семейства. Другими словами, должны быть четкие различия в требованиях безопасности ОО. Это связано с тем, что ПЗ должен, по крайней мере, отличаться целями безопасности, которые определяют выбор требований безопасности ИТ. В качестве примера можно рассмотреть случай, когда два ПЗ специфицируют одну и ту же совокупность ФТБ, но разные ТДБ. Допускается мотивировать более низкое требование безопасности возрастанием безопасности среды ОО. Такие различия должны быть отражены в целях безопасности. Там же, где семейство ПЗ применяется к различным компонентам системы ИТ (в конкретной или предполагаемой среде), должны быть четко определены ПЗ, включенные в семейство (см. также раздел 14, в котором рассматриваются вопросы разработки ПЗ для компонентов системы ИТ).

8 Среда безопасности объекта оценки

8.1 Введение

В данном разделе представлены рекомендации по спецификации раздела ПЗ и ЗБ "Среда безопасности ОО". Требования к содержанию этого раздела ПЗ и ЗБ определены в ИСО/МЭК 15408-1, приложение В, подраздел В.2.4 и приложение С, подраздел С.2.4.

Содержание разделов "Среда безопасности ОО" в ПЗ и "Среда безопасности ОО" в ЗБ не имеют серьезных различий.

Цель раздела "Среда безопасности ОО" состоит в определении аспектов безопасности среды ОО (см. рисунок 1).

В данном разделе предметом рассмотрения становятся следующие аспекты:

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

b) активы, требующие защиты (обычно информация или ресурсы в пределах ИТ-среды или непосредственно ОО), идентифицированные источники угроз и сами угрозы, которые они порождают для активов;

c) ПБОр или правила, которым должен соответствовать ОО.

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

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

8.2 Идентификация и спецификация предположений безопасности

В соответствии со стандартами серии ИСО/МЭК 15408 в раздел "Среда безопасности ОО" ПЗ и ЗБ необходимо включать перечень предположений относительно среды безопасности ОО или предполагаемого использования ОО.

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

В ПЗ и ЗБ целесообразно включать следующие группы предположений:

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

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

c) предположения связности [например, межсетевой экран должен быть единственным сетевым соединением между частной (защищаемой) и внешней (потенциально враждебной) сетью];

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

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

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

Наряду с использованием итерационного подхода к идентификации предположений безопасности, необходимо избегать включения в раздел "Среда безопасности ОО" любых предположений, связанных с эффективным использованием конкретных функций безопасности ОО (ФБО), которые идентифицированы в процессе формирования раздела "Обоснование". Соответствующую этим "предположениям" информацию целесообразно включать в ПЗ и ЗБ в виде требований безопасности для не ИТ-среды (см. 10.5.2).

ГАРАНТ:

По-видимому, в тексте предыдущего абзаца допущена опечатка. Имеется в виду "10.4.2"

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

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

Примеры предположений приведены в приложении В.

8.3 Идентификация и спецификация угроз

8.3.1 Краткий обзор

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

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

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

8.3.2 Идентификация угроз

8.3.2.1 Понятие угрозы

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

Примечание - Нарушения ПБОр не должны трактоваться как угрозы.

В целях идентификации угроз необходимо выяснить:

a) какие активы требуют защиты;

b) кто или что является источником угрозы;

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

8.3.2.2 Идентификация активов

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

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

В примере ПЗ для третьей доверенной стороны (ТДС) (см. приложение F) различные криптографические ключи будут иметь разных владельцев: подписчиков ТДС и владельца самого ТДС. Другой пример - медицинские системы ИТ. Хранимая и обрабатываемая в них информация не имеет одного владельца, а предназначена для использования всеми заинтересованными сторонами в соответствии с заданным набором правил ее использования и контроля такого использования.

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

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

a) нечеткому пониманию основного предназначения ОО (обеспечение защиты первичных активов или их представлений в пределах ИТ-среды);

b) слишком раннему (еще до описания угроз и целей безопасности) ознакомлению пользователя ПЗ и ЗБ с деталями реализации.

8.3.2.3 Идентификация источников угроз

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

При идентификации источников угроз необходимо рассмотреть:

а) кто и по каким причинам может быть заинтересован в компрометации идентифицированных активов;

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

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

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

8.3.2.4 Идентификация методов нападения

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

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

b) возможности нарушителей, имеющих доступ к среде безопасности ОО.

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

8.3.2.5 Влияние результатов анализа рисков на идентификацию угроз

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

a) вероятность и последствия компрометации активов с учетом:

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

2) вероятности успешной реализации нападения,

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

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

8.3.3 Спецификация угроз

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

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

ГАРАНТ:

По-видимому, в тексте предыдущего абзаца допущена опечатка. Имеется в виду "8.3.1"

a) источники угроз (например, уполномоченный пользователь ОО);

b) активы, подверженные нападению (например, конфиденциальные данные);

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

Ниже приведены примеры формулирования угроз:

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

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

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

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

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

Каждая угроза должна иметь уникальную метку. Это необходимо для упрощения использования ссылок (например, в тех частях раздела ПЗ "Обоснование", которые показывают связь изложенных целей безопасности и угроз). Угрозы маркируют одним из перечисленных ниже способов:

a) последовательная нумерация угроз (например, У1, У2, У3 и т.д.);

b) присвоение уникальной метки, обеспечивающей краткое, но значащее "имя" (см. примеры в приложении В).

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

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

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

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

b) они (угрозы) не попадали в область действия существующих угроз.

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

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

Примеры угроз приведены в приложении В.

8.3.4 Окончательное формулирование угроз

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

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

a) физическое нападение на ОО;

b) злоупотребление правами со стороны привилегированных пользователей;

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

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

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

8.4 Идентификация и спецификация политики безопасности организации

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

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

Если ПЗ и ЗБ определяет и ПБОр, и угрозы, то следует кратко излагать в разделе "Среда безопасности ОО" аспекты среды безопасности ОО. Так, например, нецелесообразно включать в ПЗ и ЗБ правило ПБОр, являющееся простой переформулировкой угрозы.

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

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

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

a) идентификация применяемых правил управления информационными потоками;

b) идентификация применяемых правил управления доступом;

c) определение правил ПБОр для аудита безопасности;

d) решения, предписанные организацией, например, использование определенных криптографических алгоритмов или следование определенным стандартам.

Каждое правило ПБОр должно иметь уникальную метку.

Примеры правил ПБОр приведены в приложении В.

9 Цели безопасности

9.1 Введение

Данный раздел содержит рекомендации по идентификации и спецификации целей безопасности в ПЗ или ЗБ.

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

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

В ПЗ и ЗБ необходимо различать два типа целей безопасности (см. рисунок 2):

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

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

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

9.2 Спецификация целей безопасности для объекта оценки

Цели безопасности ОО должны установить (в заданном разработчиком ПЗ и ЗБ объеме) возлагаемую на ОО ответственность за противостояние угрозам и следование ПБОр. Цели безопасности ОО (см. рисунок 2) можно рассматривать как промежуточный этап формирования требований безопасности ИТ, исходя из идентифицированных аспектов среды безопасности ОО, что необходимо всегда учитывать при спецификации целей безопасности для ОО.

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

a) с одной стороны, цели безопасности должны помочь пользователю ПЗ и ЗБ без углубленного изучения деталей реализации понять объем решения объектом оценки проблемы безопасности (степень учета аспектов среды безопасности ОО). В идеале цели безопасности для ОО должны быть независимы от реализации. Таким образом, основное внимание необходимо сосредоточить на том, какое решение предпочтительнее, а не на том, как это решение достигается;

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

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

Сформированный надлежащим образом набор целей безопасности для ОО дает определенную уверенность в том, что формулируемые на его основе требования безопасности ИТ не будут избыточными (в части ФТБ см. 10.1.1; в части ТДБ см. 10.2.1), что в свою очередь служит основой для минимизации средств и времени, затрачиваемых на оценку ОО.

С точки зрения противостояния идентифицированным угрозам существует три типа целей безопасности для ОО:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соответствие целей безопасности для ОО угрозам и ПБОр достигается с учетом:

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

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

Наглядность такого соответствия может быть достигнута, например, за счет использования перекрестных ссылок или отображения рассматриваемого соответствия в форме таблицы. Несмотря на то, что демонстрация соответствия целей безопасности угрозам и ПБОр будет приведена в разделе "Обоснование" (см. разделы 12 и 13), для пользователя ПЗ и ЗБ было бы полезно отображение такого соответствия уже в разделе "Цели безопасности". В случае, если цель безопасности предполагает реализацию какого-либо правила ПБОр, предпочтительнее в раздел "Цели безопасности" включить ссылку на соответствующее правило ПБОр, а не повторять установленные ПБОр правила, подлежащие реализации (см. пример цели безопасности O.DAC, приведенный в приложении В).

Цели безопасности для ОО должны быть уникально маркированы. Маркировка может быть основана на последовательной нумерации (например, Ц1, Ц2, Ц3 и т.д.) либо на использовании значащих меток (см. примеры, приведенные в приложении В).

9.3 Спецификация целей безопасности для среды объекта оценки

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

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

a) противостояние угрозам (или отдельным аспектам угроз), которым ОО не противостоит;

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

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

d) поддержку идентифицированных предположений о среде.

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

a) сформулировать новую цель безопасности для учета рассматриваемого аспекта среды безопасности ОО;

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

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

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

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

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

Типовые не ИТ-цели безопасности для среды могут предусматривать:

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

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

Таким образом, в состав целей безопасности для среды необходимо включать в том числе цели безопасности, связанные с действиями управления, направленными на обеспечение эффективности функций безопасности, предоставляемых объектом оценки. В некоторых случаях требуемые действия управления являются очевидными и могут быть выражены в форме не ИТ-целей безопасности для среды (например, при рассмотрении вопроса о необходимости надлежащего управления функциями аудита). В других случаях требуемые действия управления могут зависеть от детализованных требований безопасности, используемых для реализации целей безопасности ОО. Например, цель безопасности "идентификация и аутентификация" (см. цель Ц1 в 9.1) может быть реализована путем использования механизма пользовательских паролей. Использование механизма пользовательских паролей предполагает необходимость формулирования соответствующего требования к пользователям, связанного с обеспечением последними недоступности паролей для других лиц. Данное требование безопасности представляет собой требование безопасности для не ИТ-среды (см. 10.5.2) и, в свою очередь, уточняет соответствующую цель безопасности для среды ОО.

ГАРАНТ:

По-видимому, в тексте предыдущего абзаца допущена опечатка. Вместо слов "10.5.2" следует читать "10.4.2"

Если противостояние угрозе или проведение ПБОр частично возлагается на ОО, а частично на его среду, соответствующая цель безопасности должна повторяться в каждой категории (цели безопасности - для ОО, цели безопасности для среды). Так, цель Ц1 "идентификация и аутентификация" (см. 9.1) для включения в состав целей безопасности как для ОО, так и для среды ОО может быть переформулирована следующим образом:

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

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

Типичным примером цели безопасности для ИТ-среды является цепь безопасности "Идентификация и аутентификация пользователей ОО" для операционной системы, под управлением которой работает СУБД. Далее (см. 10.4.2) путем уточнения целей безопасности для ИТ-среды формулируются требования безопасности для ИТ-среды.

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

10 Требования безопасности

10.1 Введение

Данный раздел содержит рекомендации по формированию в ПЗ и ЗБ требований безопасности ИТ как для ОО, так и для ИТ-среды. Кроме того, в данном разделе кратко излагаются вопросы формирования требований безопасности для не ИТ-среды (требования для не ИТ-среды не являются обязательными для ПЗ и ЗБ).

В ПЗ и ЗБ формулируют следующие типы требований безопасности ИТ:

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

b) требования доверия к безопасности ОО. Требования доверия к безопасности определяют требуемый уровень уверенности в надлежащей реализации ФТБ;

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

Как показано на рисунке 3, требования безопасности ИТ могут быть сформированы, где это возможно, с использованием каталога функциональных компонентов, определенных в ИСО/МЭК 15408-2, и каталога компонентов доверия к безопасности, определенных в ИСО/МЭК 15408-3.

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

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

Рекомендации по спецификации ФТБ и ТДБ в случаях, если в ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 соответственно нет подходящих компонентов требований для формулирования рассматриваемых ФТБ и ТДБ, приведены в 10.1.5 и 10.2.3.

Стандарты серии ИСО/МЭК 15408 обеспечивают определенную степень гибкости формирования ФТБ и ТДБ на основе компонентов требований, определяя набор разрешенных операций над компонентами. Разрешенными операциями являются: назначение, итерация, выбор и уточнение.

Рекомендации по выполнению операций над функциональными компонентами, определенных в ИСО/МЭК 15408, включены в 10.1.2; компонентами доверия к безопасности - в 10.2.2.

Следует отметить, что в ИСО/МЭК 15408 каждому компоненту требований безопасности назначена предусмотренная на определенной классификации уникальная метка. Например, для FAU_GEN.1.2 компонента FAU_GEN.1 метка имеет вид:

a) 'F'-метка указывает на то, что это - функциональное требование;

b) 'AU'-метка указывает на то, что ФТБ принадлежит классу ФТБ "Аудит безопасности";

c) 'GEN'-метка указывает на то, что ФТБ принадлежит семейству "Генерация данных аудита безопасности" класса FAU;

d) '1'-метка указывает на то, что ФТБ принадлежит компоненту "Генерация данных аудита" семейства FAU_GEN;

e) '2'-метка указывает на то, что ФТБ является вторым элементом компонента FAU_GEN.1.

Требования ФТБ и ТДБ выбирают на уровне компонентов: элементы, входящие в компонент, должны быть включены в ПЗ и ЗБ, если в ПЗ и ЗБ включается данный компонент.

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

1) компоненты одного семейства могут находиться в иерархической связи. Иерархия предполагает, что один компонент включает в себя все элементы требований, определенные в другом компоненте этого семейства. Например, FAU_STG.4 иерархичен по отношению к FAU_STG.3, потому что все функциональные элементы, определенные в FAU_STG.3, также включены в FAU_STG.4. Однако FAU_STG.4 не иерархичен по отношению к FAU_STG.1 и поэтому может потребоваться включение в разрабатываемые ПЗ и ЗБ обоих этих компонентов;

2) компоненты могут зависеть от компонентов других семейств. Например, компонент FIA_UAU.1 (связанный с требованием аутентификации пользователей) зависит от компонента FIA_UID.1 (связанный с требованием идентификации пользователей).

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

В дополнение к ФТБ и ТДБ в разделе ПЗ и ЗБ "Требования безопасности ИТ" требуется (где необходимо) определить минимальный уровень стойкости функции безопасности ОО, а также (где необходимо) требования к точному значению стойкости.

10.2 Спецификация функциональных требований безопасности в профиле защиты или задании по безопасности

10.2.1 Выбор функциональных требований безопасности

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

В процессе формирования ФТБ выделяют несколько этапов. Исходя из них, различают следующие два типа ФТБ:

a) основные ФТБ, непосредственно удовлетворяющие конкретные цели безопасности для ОО;

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

Хотя в ПЗ не обязательно делить ФТБ на основные и поддерживающие, такое деление может оказаться полезным при формировании раздела ПЗ "Обоснование".

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

Взаимосвязь между основными и поддерживающими ФТБ показана на рисунке 4. Данную взаимосвязь учитывают при формировании раздела ПЗ "Обоснование", в котором требуется показать взаимную поддержку ФТБ (см. 12.2.4). При этом требуется раскрыть характер поддержки, выполняемой поддерживающими ФТБ для достижения целей безопасности ОО.

Формирование полной совокупности поддерживающих ФТБ подразделяют на следующие стадии:

1) идентификация дополнительных ФТБ, необходимых (с точки зрения разработчика ПЗ) для удовлетворения зависимостей всех основных ФТБ;

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

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

Идентификация поддерживающих ФТБ представляет собой итерационный процесс, например:

a) предположим, что ПЗ включает в себя цель безопасности, требующую, чтобы ОО определенным образом реагировал на события, являющиеся показателем предстоящего нарушения безопасности. Наличие в ПЗ подобной цели предполагает идентификацию основного ФТБ на базе компонента FAU_ARP.1 "Сигналы нарушения безопасности";

b) компонент FAU_ARP.1 имеет зависимость от компонента FAU_SAA.1 "Анализ потенциальных нарушений", который также должен быть включен в ПЗ в качестве поддерживающего ФТБ;

c) компонент FAU_SAA.1 имеет зависимость от FAU_GEN.1 "Генерация данных аудита";

d) компонент FAU_GEN.1 имеет зависимость от FPT_STM.1 "Надежные метки времени";

e) компонент FPT_STM.1 не требует ввода дополнительных функциональных компонентов.

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

При удовлетворении зависимостей необходимо обеспечить согласованность соответствующих компонентов. Например, в случае FAU_ARP.1 согласованность достигается характером требований (FAU_ARP.1 зависит от ожидания потенциального нарушения безопасности, которое определено применением FAU_SAA.1.2).

Для других компонентов согласованность может быть более проблематичной. Например, при включении в ПЗ компонента FDP_ACC.1 одновременно идентифицируется конкретная политика управления доступом. При удовлетворении зависимости FDP_ACC.1 от компонента FDP_ACF.1 необходимо обеспечить применение FDP_ACF.1 к той же политике управления доступом, которая идентифицировалась при включении в ПЗ компонента FDP_ACC.1. Если к компоненту FDP_ACC.1 применяется операция "итерация" для различных политик управления доступом, то зависимость от компонента FDP_ACF.1 должна быть удовлетворена несколько раз, принимая во внимание каждую политику управления доступом.

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

a) ФТБ, основанные на соответствующих компонентах того же класса, что и основные ФТБ. Например, если компонент FAU_GEN.1 "Генерация данных аудита" включен в ПЗ, то может возникнуть необходимость в создании и ведении журнала аудита безопасности для хранения сгенерированных данных (для формулирования подобного требования необходим один или более функциональных компонентов из семейства FAU_STG), а также потребность в средствах просмотра сгенерированных данных аудита (для формулирования подобного требования необходим один или более функциональных компонентов из семейства FAU_SAR). В качестве альтернативы включению поддерживающих ФТБ, сгенерированные данные аудита безопасности могут быть экспортированы для просмотра в другую систему;

b) ФТБ, основанные на соответствующих компонентах класса FPT "Защита функций безопасности ОО". Такие ФТБ обычно направлены на защиту целостности и/или доступности ФБО или данных ФБО, на которые полагаются другие ФТБ. Например, для защиты ФБО от нарушений и модификаций в ПЗ могут быть включены ФТБ на основе компонента FPT_AMT.1 "Тестирование абстрактной машины" и компонентов семейства FPT_SEP "Разделение домена";

c) ФТБ, основанные на соответствующих компонентах класса FMT "Управление безопасностью". Эти компоненты могут использоваться для спецификации поддерживающих ФТБ управления безопасностью. Так, например, в ПЗ может быть включено поддерживающее ФТБ на базе компонента FMT_REV.1, связанное с отменой атрибутов безопасности, если в ПЗ включено ФТБ, связанное с атрибутами безопасности (например, атрибутами управления доступом).

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

a) некоторые ОО могут быть не способны удовлетворить избыточные поддерживающие ФТБ;

b) увеличение числа ФТБ увеличивает стоимость оценки.

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

10.2.2 Выполнение операций над функциональными требованиями безопасности

10.2.2.1 Разрешенные операции

Над функциональными компонентами могут выполняться разрешенные операции. Выполняя операции над функциональными компонентами, разработчик ПЗ может сформировать соответствующее данному ПЗ требование безопасности. Допустимыми операциями являются:

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

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

c) выбор - позволяет специфицировать один или несколько элементов из списка;

d) уточнение - позволяет добавить детали к требованиям безопасности, ограничивая, таким образом, возможную совокупность приемлемых решений без необходимости введения новых зависимостей от других ФТБ.

10.2.2.2 Операция "итерация"

Операция "итерация" часто используется для определения ФТБ на основе компонентов класса FMT ("Управление безопасности"), которые включаются в ПЗ для удовлетворения зависимостей многих других функциональных компонентов. Для того чтобы удовлетворить такие зависимости, обычно необходимо использовать компоненты класса FMT, над которыми операции "назначение" и "выбор" выполняют по-разному. Например, компонент FMT_MSA.1 может быть использован многократно для определения отдельных ФТБ, соответствующих управлению различными типами атрибутов безопасности. Подобным образом может потребоваться неоднократное использование компонентов семейств FDP_ACC и FDP_ACF в случаях, если требуется, чтобы ОО реализовывал различные политики управления доступом, например, дискреционную и ролевую.

Целесообразно использовать операцию "итерация" для улучшения читабельности ПЗ, например, для того, чтобы разбить сложное и громоздкое ФТБ на отдельные понятные ФТБ. Использование операции "итерация" тем не менее может породить другие потенциальные проблемы при представлении ФТБ в ПЗ и ЗБ (см. 10.1.6).

Для каждого ФТБ, включаемого в ПЗ, необходимо принять следующее решение:

a) выполнить операции "назначение" и "выбор", предусмотренные функциональным компонентом для изложения ФТБ;

b) специфицировать операцию "уточнение" для ФТБ.

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

Результат операции "уточнение" выделяют полужирным шрифтом.

Результат операции "выбор" выделяют подчеркиванием и курсивом.

Результат операции "назначение" значение параметра заключают в квадратные скобки [например (назначаемое значение)].

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

10.2.2.3 Операции "назначение" и "выбор"

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

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

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

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

Следовательно, операции "назначение" и "выбор" целесообразно выполнять, исходя из необходимости демонстрации достижения целей безопасности. Важным тестом правильности выполнения операции над компонентом является процесс формирования "Обоснования требований безопасности ИТ": аргументы, используемые для демонстрации пригодности требований безопасности ИТ для удовлетворения целей безопасности, не должны опираться на детали, которые не были специфицированы в ФТБ. Например, для ФТБ управления доступом, основанного на компоненте FDP_ACF.1, спецификацию правил управления доступом можно возложить на разработчика ЗБ в том случае, если такие правила уже определены в ПБОр, для удовлетворения которой предназначена соответствующая (управлению доступом) цель безопасности.

Один из рекомендуемых подходов к решению упомянутой выше проблемы - частичное выполнение операций. Следуя данному подходу, можно представить разработчику ЗБ максимальную свободу действий и, вместе с тем, предотвратить выполнение операций "назначение" и "выбор", несовместимое с целями безопасности для ОО.

По первому примеру ФТБ (основанном на FAU_STG.4.1) операция "выбор" выполнена частично путем предотвращения выбора варианта "игнорирование подвергаемых аудиту событий", который разработчик считает несовместимым с целями безопасности для ОО. Таким образом, ФТБ предоставляет разработчику ЗБ два (а не три) варианта выбора:

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

Второй пример - ФТБ (основанное на компоненте FPT_ITT.1), которое показывает, как частичное выполнение операции "выбор" предписывает применение одного из вариантов выбора. Компонент FPT_ITT.1 допускает спецификацию требования защиты передаваемых данных ФБО от раскрытия и/или модификации. В рассматриваемом примере разработчик ПЗ определил, что для достижения целей безопасности требуется защита передаваемых данных ФБО от раскрытия. Наряду с этим разработчик ПЗ не преследует цели запретить наличие в ЗБ для соответствующего ОО специфицированной защиты от модификации. Таким образом, частичное выполнение операции "выбор" заключается в исключении нежелательного варианта (защита только от модификации):

"ФБО должны защитить свои данные от [выбор: раскрытие, раскрытие и модификация] при их передаче между разделенными частями ОО".

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

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

Например, требование на основе элемента FMT_SAE.1.1 могло быть представлено следующим образом:

"ФБО должны ограничить возможность назначать срок действия для [паролей пользователя] только [уполномоченным администратором]".

Если операция остается невыполненной, то необходимо пояснить, что выполнение операции возлагается на разработчика ЗБ. Например, требование на основе элемента FDP_RIP.1.1 могло бы быть специфицировано в ПЗ следующим образом:

"ФБО должны обеспечить недоступность любого предыдущего информационного содержания ресурсов при распределении ресурса для следующих объектов: [назначение: список специфицируемых разработчиком ЗБ объектов]".

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

10.2.2.4 Операция "уточнение"

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

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

Ниже приведен пример выполнения операции "уточнение" применительно к требованию на основе элемента FMT_MTD.3.1:

"ФБО должны обеспечить присвоение данным ФБО только безопасных значений".

Уточнение: ФБО должны обеспечить, чтобы минимальная длина пароля, требуемого ОО, была, по крайней мере, 6 символов.

Рекомендации по использованию операции "уточнение" для улучшения читабельности ФТБ приведены в 10.1.6.

10.2.3 Спецификация требований аудита

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

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

a) определенные в ПБОр требования к аудиту безопасности;

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

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

d) анализ "стоимость - эффективность".

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

При проведении анализа "стоимость - эффективность" должны быть рассмотрены следующие вопросы:

a) является ли регистрируемая информация полезной для ее последующего анализа;

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

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

В стандартах серии ИСО/МЭК 15408 определены три предопределенных уровня аудита: минимальный, базовый и детализированный. Для каждого предопределенного уровня в ИСО/МЭК 15408-2 определен минимальный набор событий, подлежащих аудиту, а также минимальный объем подлежащей регистрации информации с привязкой к функциональным компонентам.

Предопределенные уровни аудита могут быть охарактеризованы следующим образом:

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

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

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

Если ни один из перечисленных уровней не является надлежащим, то целесообразно выбрать неопределенный уровень аудита и в явном виде перечислить все подлежащие аудиту события в элементе FAU_GEN.1.1. Например, допускается принять за основу минимальный уровень аудита, но в ряде случаев отклониться от минимальных требований вследствие того, что какое-либо подмножество действий или событий является более значимым для достижения целей безопасности. Например, если компонент FDP_ACF.1 включен в ПЗ, то может потребоваться более детальный аудит неудачных попыток доступа по сравнению с успешными.

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

10.2.4 Спецификация требований управления

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

Таким образом, возможные действия управления специфицируются, если функциональные компоненты ссылаются на конфигурированные данные ФБО, которые подлежат управлению и контролю. Например, цели безопасности для ОО могут быть не достигнуты в том случае, если администраторы ОО не были ограничены в возможности модификации данных ФБО по своему усмотрению. Поэтому компоненты класса FMT часто включаются в ПЗ для того, чтобы сформировать на их основе поддерживающие ФТБ, способствующие достижению целей безопасности для ОО, и чтобы ФТБ в целом являлись взаимно поддерживающими (см. 12.1.1 и 12.1.4).

10.2.5 Спецификация стойкости функции безопасности

В ИСО/МЭК 15408-3 идентифицированы три предопределенных уровня СФБ (стойкости функции безопасности), а именно "базовая", "средняя" и "высокая" для всех функций безопасности ИТ, которые реализуются вероятностными или перестановочными механизмами (например, пароль или хэш-функция), идентифицированных в ПЗ или ЗБ (см. также ИСО/МЭК 15408-1, приложение В, раздел В.2). Эти уровни характеризуются следующим образом:

a) функция предоставляет адекватную защиту от случайного нарушения безопасности ОО нарушителями с низким потенциалом нападения;

b) функция предоставляет адекватную защиту от прямого или умышленного нарушения безопасности ОО нарушителями с умеренным потенциалом нападения;

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

Выбор уровня должен основываться на ряде факторов, относящихся к источнику (источникам) угрозы:

a) затрачиваемое время;

b) компетентность;

c) знание ОО;

d) доступ к ОО;

е) оборудование.

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

Для некоторых вероятностных и перестановочных механизмов могут быть определены дополнительные явные метрики, а не более общие заявления "базовая", "средняя" и "высокая".

10.2.6 Спецификация функциональных требований, приведенных в профиле защиты

Если в ЗБ заявлено соответствие одному или нескольким ПЗ, то, вероятно, ФТБ уже специфицированы в ПЗ. В таких случаях необходимо принять решение - специфицировать ФТБ в ЗБ полностью (для того, чтобы весь текст был в одном месте) либо включить в ЗБ ссылку на ФТБ, специфицированные в ПЗ, и специфицировать ФТБ, которых нет в ПЗ, либо отличающиеся от специфицированных в ПЗ.

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

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

10.2.7 Спецификация функциональных требований, отсутствующих в профиле защиты

В некоторых случаях необходимо специфицировать ФТБ, которые отсутствуют в соответствующем ПЗ. Это может быть в случае, если:

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

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

В этих случаях целесообразно использовать подход к спецификации ФТБ, аналогичный подходу, описанному в 10.1. Если в ЗБ включаются дополнительные по отношению к ПЗ требования, то необходимо обеспечить отсутствие противоречия между ними и ФТБ, включенными в ПЗ (в разделе ЗБ "Обосновании" необходимо продемонстрировать отсутствие противоречия).

10.2.8 Спецификация в профиле защиты функциональных требований, не изложенных в ИСО/МЭК 15408-2

Если при разработке ПЗ требуется включить в документ функциональное требование, для которого в стандартах серии ИСО/МЭК 15408 отсутствует соответствующий функциональный компонент, то в качестве формы представления рассматриваемого ФТБ необходимо использовать форму представления функциональных компонентов в соответствии со стандартами серии ИСО/МЭК 15408.

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

Спецификация ФТБ в явном виде включает в себя:

a) определение ФТБ на том же уровне абстракции, что и функциональные компоненты стандартов серии ИСО/МЭК 15408;

b) использование стиля и фразеологии (языка) функциональных компонентов стандартов серии ИСО/МЭК 15408.

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

Стиль представления функциональных компонентов стандартов серии ИСО/МЭК 15408 предусматривает:

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

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

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

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

При формировании ФТБ в явном виде необходимо решить:

a) будут ли над ФТБ совершаться операции "выбор" и "назначение", подлежащие выполнению разработчиком ЗБ;

b) предполагает ли ФТБ какие-либо зависимости от других ФТБ, которые должны быть удовлетворены в ПЗ;

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

d) будет ли ФТБ включать в себя параметры безопасности, подлежащие управлению, например, зависеть от атрибутов безопасности, которые подлежат управлению.

Именование ФТБ, не основанных на компонентах ИСО/МЭК 15408-2, должно показывать, что это - дополнительное по отношению к стандартам серии ИСО/МЭК 15408 требование безопасности.

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

Разработчик ЗБ также может сформулировать ФТБ в ЗБ в явном виде, то есть без ссылки на функциональные компоненты, определенные в ИСО/МЭК 15408-2. Также нет необходимости для формулируемых в явном виде ФТБ определять операции, описанные в стандартах серии ИСО/МЭК 15408 ("назначение", "выбор"), если не предполагается их повторное использование в ПЗ, других ЗБ, функциональных пакетах.

10.2.9 Представление функциональных требований безопасности

При формировании перечня ФТБ разработчик ПЗ должен представить их так, чтобы обеспечить наилучшее понимание требований безопасности пользователями и согласование ФТБ с требованиями стандартов серии ИСО/МЭК 15408.

В процессе представления ФТБ необходимо учитывать следующие рекомендации.

Во-первых, целесообразно объединить ФТБ в группы и озаглавить данные группы ФТБ, исходя из контекста ПЗ. Заголовки групп ФТБ могут отличаться от заголовков классов, семейств и компонентов, определенных в ИСО/МЭК 15408-2.

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

Ниже приведен пример выполнения операции "уточнение" над элементом FMT_MSA.3.1 функционального компонента FMT_MSA.3 "Инициализация статических атрибутов".

Элемент FMT_MSA.3.1 в ИСО/МЭК 15408-2 имеет следующий вид:

FMT_MSA.3.1. ФБО должны осуществлять [назначение: ПФБ управления доступом, ПФБ управления информационными потоками], чтобы обеспечить [выбор: ограничительные, разрешающие, с другими свойствами] значения по умолчанию для атрибутов безопасности, которые используются для осуществления ПФБ.

После выполнения операций "назначение", "выбор" и "уточнение", соответствующих элементу FMT_MSA.3.1, ФТБ принимает следующий вид:

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

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

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

Реализация описанного подхода к представлению ФТБ проиллюстрирована на примере формирования ПЗ, приведенном в приложении F.

10.3 Спецификация в профилях защиты или заданиях по безопасности требований доверия к безопасности

10.3.1 Выбор требований доверия к безопасности

Выбор требований доверия к безопасности зависит от следующих факторов:

a) ценности активов, подлежащих защите, и риска их компрометации;

b) технической реализуемости;

c) стоимости разработки и оценки;

d) требуемого времени для разработки и оценки ОО;

e) требований рынка (для продуктов ИТ);

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

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

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

Изложение целей безопасности может также указывать на то, какие конкретные требования доверия к безопасности должны быть включены в набор ТДБ, например:

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

b) цели безопасности могут требовать анализа скрытых каналов, что однозначно определяет включение в ПЗ и ЗБ компонента из семейства AVA_CCA "Анализ скрытых каналов", требующего проведения анализа скрытых каналов;

c) при формулировке целей безопасности может быть отмечено, что безопасность ОО серьезно зависит от безопасности среды разработки. В этом случае настоятельно рекомендуется включить в набор ТДБ компонент из семейства ALC_DVS "безопасность разработки", содержащий требование анализа безопасности среды разработки.

Выбор ТДБ относительно несложен, если требуется просто выбрать подходящий пакет доверия к безопасности (см. раздел 15), например, ОУД, определенный в стандартах серии ИСО/МЭК 15408. Для того, чтобы выбрать подходящий с точки зрения сформулированных целей безопасности пакет доверия к безопасности, необходимо изучить его описание (например, при выборе ОУД см. раздел 6 ИСО/МЭК 15408-3).

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

Если в ПЗ включены расширенные требования доверия к безопасности, то необходимо удовлетворить все зависимости компонентов доверия к безопасности, содержащих эти дополнительные требования. Например, если в ПЗ пакет ОУД3 расширен путем использования компонента AVA_VLA.2 "Независимый анализ уязвимостей", то в ПЗ также необходимо включить компоненты ADV_LLD.1 "Описательный проект нижнего уровня" и ADV_IMP.1 "Подмножество реализации ФБО".

10.3.2 Выполнение операций над требованиями доверия к безопасности

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

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

b) "уточнение", позволяющее добавить детали к требованию доверия к безопасности.

На практике выполнение операции "итерация" может потребоваться в тех случаях, когда требуются разные "уточнения" для того же компонента доверия к безопасности, который используется для разных частей ОО, либо, если в ПЗ и ЗБ определены различные наборы ТДБ для разных компонентов составного ОО (см. 14.2.4). В последнем случае итерация требуется для компонентов доверия к безопасности (уточненных или нет), которые используются для более чем одного компонента составного ОО. Применение операции "уточнение" к ТДБ может быть выполнены:

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

b) предписания действий оценщика, например:

1) компонент ADV_IMP.1 определяет, какие части представления реализации ОО должны быть оценены,

2) компонент ADV_IMP.1 идентифицирует известные уязвимости, которые необходимо рассматривать как "явные" уязвимости в контексте данного ОО.

10.3.3 Спецификация в профиле защиты требований доверия к безопасности, не включенных в ИСО/МЭК 15408-3

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

Сформулированные в явном виде ТДБ должны содержать определение:

a) действий разработчика;

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

c) действий оценщика.

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

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

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

Целесообразно излагать формулируемые в явном виде ТДБ так же, как изложены компоненты доверия к безопасности, определенные в ИСО/МЭК 15408-3. Поэтому отдельное требование необходимо оформлять в виде отдельного элемента требований (см. 2.1.4 ИСО/МЭК 15408-3). При этом необходимо использовать терминологию, приведенную в 2.4 ИСО/МЭК 15408-3.

Принципы спецификации ТДБ в ЗБ аналогичны принципам спецификации ТДБ в ПЗ. В большинстве случаев ТДБ в ЗБ определяется ПЗ, о соответствии которому заявляется в ЗБ, а также общепринятым пакетом доверия к безопасности (например, ОУД из стандартов серии ИСО/МЭК 15408).

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

10.4 Требования безопасности для среды

10.4.1 Требования безопасности для ИТ-среды

В ПЗ и ЗБ должны включаться требования безопасности для ИТ-среды. Ниже приведены примеры случаев, когда необходимость задания требований безопасности для ИТ-среды очевидна:

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

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

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

Отличия требований безопасности для ИТ-среды и предположения о среде состоят в следующем:

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

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

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

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

Требования безопасности для ИТ-среды, как и требования безопасности ОО, целесообразно формировать (где это возможно) на основе функциональных компонентов и компонентов доверия к безопасности, определенных в стандартах серии ИСО/МЭК 15408. Любое отклонение от этих компонентов должно сопровождаться строгим обоснованием в ПЗ и ЗБ.

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

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

1) разделение ответственности между ОО и ИТ-средой полностью определено. В этом случае требования безопасности для ИТ-среды должны быть специфицированы в одном или более (по числу компонентов ИТ-среды) подразделе ПЗ;

2) разделение ответственности между ОО и ИТ-средой не определено в ПЗ. В этом случае не делается различий между ФТБ для ОО и ФТБ для ИТ-среды. При этом разработчик ПЗ должен максимально исключить возможность для разработчика ЗБ утверждать о соответствии ПЗ, в то время как ОО реализует незначительное число ФТБ, а ИТ-среда - все остальные ФТБ.

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

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

Уровень доверия к реализации ФТБ для ИТ-среды должен быть не ниже уровня доверия к реализации ФТБ объектом оценки. Например, если уровень доверия к реализации функциональных возможностей СУБД по управлению доступом должен соответствовать ОУД4, то будет считаться недостаточным уровень доверия к реализации функций идентификации и аутентификации, ответственность за реализацию которых возложена на ОС (ИТ-среду), соответствующий ОУД2.

10.4.2 Требования безопасности для не ИТ-среды

Требования безопасности для не ИТ-среды в ПЗ и ЗБ могут не включаться, вследствие того что данные требования не имеют непосредственного отношения к реализации ОО.

Необходимость во включении в ПЗ и ЗБ требований безопасности для не ИТ-среды появится в тех случаях, когда сформулированы нетривиальные, с точки зрения реализации, не ИТ-цели безопасности или когда "Обоснование" непосредственно зависит от способа реализации не ИТ-целей безопасности. Последний случай имеет место, если появляется необходимость в детальном согласовании требований безопасности ИТ в ПЗ и ЗБ и соответствующих методов управления безопасностью, с тем чтобы два вида требований (ИТ и не ИТ) находились на одинаковом уровне абстракции.

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

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

Четкая идентификация в ПЗ и ЗБ требований безопасности для не ИТ-среды в дальнейшем будет способствовать включению данных требований в пользовательскую документацию (если соответствующие требования к документации из класса AGD включены в ПЗ и ЗБ).

11 Краткая спецификация объекта оценки

11.1 Введение

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

a) определение функций безопасности ИТ;

b) ссылки на механизмы или методы защиты, используемые для осуществления функций безопасности ИТ (необязательно);

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

Содержание раздела "Краткая спецификация ОО" представлено на рисунке 5:

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

В разделе ЗБ "Краткая спецификация ОО" целесообразно формулировать функции безопасности ИТ так, чтобы представить функциональные возможности безопасности ОО в более понятном для пользователя ЗБ виде по сравнению с ФТБ. В частности:

a) функции безопасности ИТ могут быть изложены так, чтобы показать, что ОО предпринимает для обеспечения безопасности;

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

c) специфическая для конкретного ОО терминология может быть учтена для того, чтобы описания, например, функций безопасности ИТ лучше соотносились с терминологией проекта руководства пользователя или администратора. Может потребоваться введение характерных терминов - таких как "субъект", "объект" или "роль администратора". Поэтому раздел "Краткая спецификация ОО" может быть охарактеризован как развитие требований, которым должен соответствовать конкретный ОО. При этом отсутствует необходимость в описании деталей реализации ОО, его архитектуры или принципов проектирования, или в подробном описании того, как, например, разработчик проводит функциональное тестирование безопасности ОО.

11.2 Спецификация функций безопасности информационных технологий

Как проиллюстрировано в рисунке 5, раздел ЗБ "Краткая спецификация ОО" должен включать в себя спецификацию функций безопасности ОО. Задание по безопасности должно демонстрировать, что функции безопасности ИТ включают в себя все ФТБ, а также то, что каждая функция безопасности ИТ отображается, по крайней мере, на одном ФТБ.

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

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

a) функция безопасности ИТ может отображаться более чем на одно ФТБ (например, в случае с поддерживающими функциями) или

b) ФТБ может отображаться более чем на одну функцию безопасности ИТ (например, в случае с функциями, которые определяют основное назначение ОО с точки зрения обеспечения безопасности информации).

При выполнении таких преобразований необходимо:

a) не потерять детали, содержащиеся в ФТБ;

b) не допустить слишком сложного отображения ФТБ на функции безопасности ИТ, увеличения стоимости рассмотрения и оценки ЗБ, а также увеличения вероятности ошибок.

11.3 Спецификация механизмов безопасности

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

Необходимо отметить, что ссылки на механизмы безопасности в ЗБ необязательны.

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

а) для системы ИТ существует требование использования конкретного механизма безопасности;

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

11.4 Спецификация мер доверия к безопасности

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

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

На практике, вероятно, для более низких уровней доверия к безопасности раздел ЗБ "Краткая спецификация ОО" не будет содержать значительного объема дополнительной информации, кроме общих утверждений о том, что используются (или будут использоваться) необходимые для удовлетворения требований доверия к безопасности меры доверия. Один из рекомендуемых подходов заключается в демонстрации отображения документации или свидетельств разработчика на соответствующие требования доверия к безопасности.

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

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

b) методики разработки и модели жизненного цикла;

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

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

e) методы анализа скрытых каналов.

12 Утверждения о соответствии профилей защиты

12.1 Введение

Данный раздел представляет собой руководство по формированию раздела ЗБ "Утверждения о соответствии ПЗ".

В соответствии с приложением С, подраздел С.2.8, ИСО/МЭК 15408-1 требуется включение в каждое ПЗ, о соответствии которому сделано утверждение, следующей информации:

a) ссылки, идентифицирующая ПЗ, о соответствии которому сделано утверждение;

b) конкретизации, выполненной по отношению к ПЗ;

c) дополнения в ЗБ в составе целей и требований безопасности ОО, определенных в ПЗ.

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

Если утверждений о соответствии ПЗ нет, то утверждение об этом - это все, что требуется для данного раздела ЗБ.

12.2 Ссылка на профили защиты

Каждый ПЗ должен быть идентифицирован так, чтобы позволить пользователям ЗБ найти соответствующую спецификацию ПЗ. Рекомендованный способ сделать это - ссылка на запись в реестре пакетов и профилей защиты ИСО (см. [1]); однако, этот реестр не является широко распространенным и используемым. Различные национальные системы оценки ведут реестры ПЗ, что, несомненно, удобнее. Необходимо обеспечить идентификацию конкретной версии и источника ссылки для каждого ПЗ, на который дается ссылка.

12.3 Конкретизация профилей защиты

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

12.4 Дополнение профилей защиты

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

14 Профили защиты и задания по безопасности для составных объектов оценки и объектов оценки, входящих в состав других объектов оценки

14.1 Введение

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

a) ПЗ и ЗБ формируют для составного ОО, который состоит из двух или более компонентов (которые также могут быть составными объектами), на каждый из которых имеются отдельные ПЗ или ЗБ (далее - ПЗ ОО-компонента или ЗБ ОО-компонента);

b) ПЗ и ЗБ формируют для ОО-компонента, в которых определяются зависимости от ИТ-среды, которая включает в себя другие ОО-компоненты, являющиеся частью составного ОО (заметим, что могут также существовать зависимости, связанные с требованиями для не ИТ-среды, однако их не обязательно включать в ПЗ и ЗБ).

Существует несколько возможных сценариев декомпозиции, например:

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

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

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

14.2 Составной объект оценки

14.2.1 Описательные части профиля защиты и задания по безопасности

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

14.2.2 Среда безопасности объекта оценки

Раздел ПЗ или ЗБ составного ОО "Среда безопасности ОО" может:

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

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

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

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

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

Независимо от используемого подхода необходимо обеспечить непротиворечивость и согласованность между ПЗ и ЗБ составного ОО и ПЗ и ЗБ ОО-компонентов.

14.2.3 Цели безопасности

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

Если цели безопасности, изложенные в ЗБ составного ОО, не полностью эквивалентны целям безопасности для ОО-компонентов, то целесообразно представить отображение целей безопасности для составного ОО на цели безопасности для ОО-компонентов.

14.2.4 Требования безопасности

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

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

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

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

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

14.2.5 Краткая спецификация объекта оценки

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

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

14.2.6 Обоснование профиля защиты

В профиле защиты для составного ОО необходимо показать, что набор целей безопасности учитывает все аспекты среды безопасности ОО, а требования безопасности ИТ удовлетворяют целям безопасности. Для некоторых аспектов раздела ПЗ "Обоснование" возможна ссылка на информацию из разделов "Обоснование" ПЗ ОО-компонентов. Целесообразно придерживаться следующих принципов:

1) для того, чтобы показать, что набор целей безопасности для составного ОО в целом учитывает аспекты среды безопасности для составного ОО, в первую очередь необходимо представить отображение каждой цели безопасности для ОО-компонентов на угрозы и ПБОр, приведенные в ПЗ составного ОО. Затем необходимо пояснить, почему цели безопасности направлены на то, чтобы противостоять угрозам и удовлетворять ПБОр. Ссылка на разделы "Обоснование" ПЗ отдельных ОО-компонентов возможна только в случае точного отображения угроз и/или ПБОр для составного ОО на угрозы и/или ПБОр для ОО-компонентов;

2) для того, чтобы показать, что набор требований безопасности ИТ является надлежащим для удовлетворения целей безопасности, целесообразно ссылаться на разделы "Обоснование" ПЗ для отдельных ОО-компонентов, если ОО-компонент удовлетворяет цели безопасности для составного ОО. В ПЗ для составного ОО необходимо показать, что все цели безопасности для составного ОО надлежащим образом удовлетворяются, по крайней мере, одним ОО-компонентом, или, что цель удовлетворяется благодаря взаимодействию двух или более ОО-компонентов;

3) для того, чтобы показать, что зависимости требований безопасности удовлетворяются, можно использовать ссылку на разделы "Обоснование" ПЗ отдельных ОО-компонентов. При этом необходимо обеспечить, чтобы в разделе "Обоснование" ПЗ составного ОО:

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

- рассматривались зависимости, которые в разделах "Обоснование" ПЗ ОО-компонентов обосновывались как не подлежащие удовлетворению, но с учетом среды безопасности составного ОО все-таки подлежат удовлетворению;

4) для демонстрации взаимной поддержки требований безопасности ИТ можно использовать результаты анализа взаимосвязей между требованиями безопасности ИТ в рамках каждого ОО-компонента, представленные в разделах "Обоснование" ПЗ ОО-компонентов. При этом в разделе "Обоснование" ПЗ составного ОО необходимо рассмотреть взаимосвязи и зависимости между требованиями безопасности ИТ различных ОО-компонентов, если они не были должным образом учтены в разделах "Обоснование" ПЗ для ОО-компонентов.

14.2.7 Обоснование задания по безопасности

Рекомендации по формированию раздела ЗБ "Обоснование" во многом подобны рекомендациям по формированию раздела "Обоснование" ПЗ составного ОО. В частности:

a) для демонстрации того, что функции безопасности ИТ и меры доверия подходят для удовлетворения требований безопасности ОО, можно просто использовать ссылку на разделы "Обоснование" ЗБ для ОО-компонентов;

b) для демонстрации взаимной поддержки функций безопасности ИТ можно использовать результаты анализа взаимной поддержки функций безопасности ИТ в рамках каждого ОО-компонента, представленные в разделах "Обоснование" ЗБ для ОО-компонентов. При этом в разделе "Обоснование" ЗБ составного ОО необходимо рассмотреть взаимосвязи и зависимости между функциями безопасности ИТ различных ОО-компонентов.

14.3 Объект оценки - компонент

14.3.1 Описательные части профиля защиты и задания по безопасности

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

14.3.2 Среда безопасности объекта оценки

Раздел ПЗ и ЗБ "Среда безопасности ОО" предназначен для определения границы среды безопасности ОО-компонента и, сточки зрения оценщика, границы оценки ОО-компонента. Например, среда безопасности ИТ для ОО-компонента может включать в себя в том числе другие ИТ-компоненты, с которыми предполагается взаимодействие ОО-компонента. В таких случаях наличие зависимостей ОО-компонента от ИТ-среды следует трактовать как предположение о среде безопасности ОО. При формулировании такого предположения следует избегать включения деталей реализации, которые специфицируются в ПЗ и ЗБ.

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

14.3.3 Цели безопасности

Любые зависимости от ИТ-среды следует трактовать как цели безопасности для ИТ-среды.

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

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

14.3.4 Требования безопасности

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

Примечание - Требования безопасности для среды могут быть определены путем заявления о соответствии другим ПЗ.

14.3.5 Краткая спецификация объекта оценки

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

14.3.6 Обоснование профиля защиты

Если в ПЗ определяются требования безопасности для ИТ-среды, то они должны быть рассмотрены в разделе ПЗ "Обоснование". В частности необходимо:

а) продемонстрировать, каким образом требования безопасности для ИТ-среды способствуют удовлетворению целей безопасности для ОО;

b) показать, что все зависимости требований безопасности для ИТ-среды удовлетворены;

c) продемонстрировать взаимную поддержку требований безопасности для ИТ-среды и показать поддержку с их стороны по отношению к требованиям безопасности ИТ.

14.3.7 Обоснование задания по безопасности

Если в ЗБ определяются требования безопасности для ИТ-среды, то они должны быть рассмотрены в разделе ЗБ "Обоснование". В частности, должны быть рассмотрены вопросы, аналогичные тем, которые рассматриваются в ПЗ (см. 14.2.6). Дополнительные детали, например, связанные с зависимостями, введенными в ЗБ, должны быть также рассмотрены в соответствующих частях ЗБ "Обоснование".

15 Функциональные пакеты и пакеты требований доверия к безопасности

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

Настоящий раздел содержит методические рекомендации по формированию пакетов требований безопасности. Концепция пакета требований представлена в 4.4.2.1 ИСО/МЭК 15408-1. Пакет можно охарактеризовать следующим образом:

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

b) предназначен для:

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

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

Основное преимущество пакетов требований заключается в снижении рабочей нагрузки на разработчиков ПЗ и ЗБ при формулировании требований безопасности ИТ (см. раздел 10).

Оценочные уровни доверия к безопасности, определенные в разделе 6 ИСО/МЭК 15408-3, необходимо рассматривать как пример оформления пакетов требований доверия к безопасности.

15.2 Формирование функционального пакета

15.2.1 Разработчики функциональных пакетов

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

15.2.2 Содержимое функционального пакета

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

При разработке ФП можно использовать один из двух подходов (или их комбинацию):

- формировать совокупность ФТБ, исходя из уже изложенных конкретных целей безопасности;

- формулировать цели безопасности, исходя из определенной совокупности ФТБ.

15.2.3 Информация, включаемая в функциональный пакет

Кроме собственно функциональных требований, в ФП следует включать следующую информацию, представляющую интерес при разработке больших ФП, ПЗ и ЗБ:

a) идентификацию целей безопасности, которым удовлетворяют ФТБ;

b) информацию об использовании функциональных компонентов в соответствии со стандартами серии ИСО/МЭК 15408 или об отклонениях от требований стандартов серии ИСО/МЭК 15408;

с) обоснование ФТБ, включая:

1) демонстрацию адекватности ФТБ для удовлетворения идентифицированных целей безопасности,

2) анализ зависимостей между ФТБ,

3) демонстрацию взаимной поддержки ФТБ.

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

15.3 Спецификация пакета требований доверия к безопасности

15.3.1 Разработчики пакетов требований доверия к безопасности

В качестве разработчиков пакетов требований доверия к безопасности (ПД) может выступать орган по сертификации, а также любая организация, которая проводит оценку продуктов и систем ИТ. Такие пакеты могут определять альтернативные уровни доверия к безопасности либо определять комбинацию компонентов класса АМА "Поддержка доверия к безопасности".

15.3.2 Содержание пакета требований доверия к безопасности

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

15.3.3 Информация, включаемая в пакет доверия

В целях многократного использования ПД должен включать в себя информацию о назначении ТДБ. Эта информация позволяет пользователю ПД определить, в каких случаях его целесообразно использовать и какие ТДБ к нему можно добавить.

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

Библиография

[1]	ИСО/МЭК 15292:2001	Информационная технология. Методы и средства обеспечения безопасности. Процедуры регистрации профилей защиты
	(ISO/IEC 15292:2001)	(Protection Profile registration procedures)
[2]	ИСО/МЭК 13335:2004	Информационная технология. Методы и средства обеспечения безопасности. Менеджмент информационной и телекоммуникационной безопасности
	(ISO/IEC 13335:2004)	(Information technology - Security Techniques - Management of information and communications technology security)
[3]	ИСО/МЭК 14516:2002	Информационная технология. Методы и средства обеспечения безопасности. Рекомендации по использованию услуг доверенных третьих сторон и управлению ими
	(ISO/IEC 14516:2002)	(Information technology - Security Techniques - Guidelines on the use and management of Trusted Third Parties services)
[4]	ИСО/МЭК 9798-1:1997	Информационная технология. Методы и средства обеспечения безопасности. Аутентификация логического объекта. Часть 1. Общие положения
	(ISO/IEC 14516:1997)	(Information technology - Security Techniques - Entity authentication - Part 1: General)
[5]	ИСО/МЭК 10118-1:1994	Информационная технология. Методы и средства обеспечения безопасности. Хэш-функции. Часть 1. Общие положения
	(ISO/IEC 10118-1:1994)	(Information technology - Security Techniques - Hash functions - Part 1: General)
[6]	ИСО/МЭК 11770-1:1996	Информационная технология. Методы и средства обеспечения безопасности. Распределение ключей. Часть 1. Основные положения
	(ISO/IEC 11770-1:1996)	(Information technology - Security Techniques - Key management - Part 1: Framework)
[7]	ИСО/МЭК 13888-1:1997	Информационная технология. Методы и средства обеспечения безопасности. Неотказуемость. Часть 1. Общие положения
	(ISO/IEC 13888-1:1997)	(Information technology - Security Techniques - Non-repudiation - Part 1: General)
[8]	ИСО/МЭК 14888-1:1998	Информационная технология. Методы и средства обеспечения безопасности. Электронная цифровая подпись с приложением. Часть 1. Общие положения
	(ISO/IEC 14888-1:1998)	(Information technology - Security Techniques - Digital signature with appendix - Part 1: General)
[9]	ИСО/МЭК 18031:2005	Информационная технология. Методы и средства обеспечения безопасности. Генерация случайных чисел
	(ISO/IEC 18031:2005)	(Information technology - Security Techniques - Random number generation)
[10]	ИСО/МЭК 18032:2005	Информационная технология. Методы и средства обеспечения безопасности. Генерация простых чисел
	(ISO/IEC 18032:2005)	(Information technology - Security Techniques - Prime number generation)