Приложение А (справочное). Спецификация заданий по безопасности

Приложение А
(справочное)

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

А.1 Цель и структура данного приложения

Цель данного приложения состоит в изложении концепции задания по безопасности (ЗБ). В данном приложении не определены критерии класса ASE; соответствующее определение содержится в ИСО/МЭК 15408-3 и поддержано документами, приведенными в разделе "Библиография".

Приложение А состоит из четырех основных частей:

a) Что должно содержать ЗБ. Краткая информация по этому вопросу изложена в А.2, более подробно в А.4 - А.10. В указанных подразделах описано обязательное содержание ЗБ, взаимосвязи в рамках содержания ЗБ, а также представлены примеры.

b) Как следует использовать ЗБ. Краткая информация по этому вопросу изложена в А.3, более подробно - в А.11. В указанных разделах описано, каким образом следует использовать ЗБ, а также приведены вопросы, на которые могут быть даны ответы в ЗБ.

c) ЗБ для низкого уровня доверия (упрощенное ЗБ). ЗБ для низкого уровня доверия представляют собой ЗБ с сокращенным содержанием. Такие ЗБ описаны в А.12.

d) Утверждение о соответствии стандартам. В разделе А.13 описано, каким образом разработчик ЗБ может сделать утверждение, что ОО удовлетворяет некоторому конкретному стандарту.

А.2 Обязательное содержание ЗБ

На рисунке А.1 представлено содержание ЗБ, установленное в ИСО/МЭК 15408-3. Рисунок А.1 также можно использовать как структурную схему ЗБ, хотя допустимы и альтернативные структуры. Например, если обоснование требований безопасности является очень объемным, то оно может быть вынесено в приложение к ЗБ вместо включения в раздел "Требования безопасности". Разделы ЗБ и содержание этих разделов кратко рассмотрены ниже; в А.4 - А.10 приведены более подробные пояснения. ЗБ обычно содержит:

a) раздел "Введение ЗБ", содержащий описание ОО на трех различных уровнях абстракции;

b) раздел "Утверждения о соответствии", указывающий, утверждается ли в ЗБ о соответствии каким-либо ПЗ и/или пакетам, и если "да", то каким ПЗ и/или пакетам;

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

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

e) раздел "Определение расширенных компонентов" (опционально), в котором могут быть определены новые компоненты (т.е. компоненты, не содержащиеся в ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3). Эти новые компоненты необходимы, чтобы определить расширенные функциональные требования и расширенные требования доверия;

f) раздел "Требования безопасности", в котором цели безопасности для ОО преобразованы в изложение на стандартизованном языке. Этот стандартизированный язык представляет собой форму представления ФТБ. Кроме того, в рассматриваемом разделе определяют ТДБ;

д) раздел "Краткая спецификация ОО", показывающий, как ФТБ реализованы в ОО.

Существуют также ЗБ для низкого уровня доверия, имеющие сокращенное содержание; подробно такие ЗБ описаны в А.12. Все остальные части данного приложения предполагают ЗБ с полным содержанием.

А.3 Использование ЗБ

А.3.1 Как следует использовать ЗБ

Типовое ЗБ выполняет две роли:

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

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

А.3.2 Как не следует использовать ЗБ

Две роли (из многих), для которых не следует использовать ЗБ:

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

"Рисунок А.1 - Содержание задания по безопасности"

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

А.4 Введение ЗБ (ASE_INT)

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

a) ссылка на ЗБ и ссылка на ОО, обеспечивающие идентификационные материалы для ЗБ и ОО, на который ссылается ЗБ;

b) аннотация ОО, в которой кратко описывается ОО;

c) описание ОО, в котором более подробно описывается ОО.

А.4.1 Ссылка на ЗБ и ссылка на ОО

ЗБ содержит четкую ссылку на ЗБ, которая идентифицирует данное ЗБ. Типичная ссылка на ЗБ состоит из наименования ЗБ, версии, разработчика и даты выпуска. Пример ссылки на ЗБ - "MauveRAM Database ST, version 1.3, MauveCorp Specification Team, 11 October 2002".

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

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

Ссылка на ЗБ и ссылка на ОО облегчают индексацию и ссылку на ЗБ и ОО и их включение в состав сводной информации списков оцененных ОО/продуктов.

А.4.2 Аннотация ОО

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

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

А.4.2.1 Использование и основные характеристики безопасности ОО

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

Пример такого описания: "The MauveCorp MauveRAM Database v2.11 является многопользовательской системой управления базами данных, предназначенной для использования в сетевой среде. Она предоставляет возможность одновременной работы до 1024 пользователей, возможность использовать аутентификацию, основанную на пароле/токене, а также - биометрическую аутентификацию; обеспечивает защиту от случайного повреждения данных и откат назад на десять тысяч транзакций. Существует возможность настройки механизмов аудита в широком диапазоне, позволяющая осуществлять детальный аудит по отношению к некоторым пользователям и транзакциям, обеспечивая при этом приватность для других пользователей и транзакций".

А.4.2.2 Тип ОО

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

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

В некоторых случаях тип ОО может ввести в заблуждение потребителей. Например:

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

ОО типа "АТМ-карта", который не поддерживает какие-либо функциональные возможности идентификации/аутентификации;

ОО типа "межсетевой экран", который не поддерживает протоколы, используемые почти повсеместно;

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

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

ОО типа "операционная система ПК", который не может безопасно функционировать при наличии у ПК сетевого подключения, накопителя на гибких дисках, CD/DVD-дисковода;

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

А.4.2.3 Требуемые аппаратные средства/программное обеспечение/программно-аппаратные средства, не входящие в ОО

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

Примеры идентификации аппаратных средств/программного обеспечения/программно-аппаратных средств:

- стандартный ПК с процессором 1 ГГц или более и ОП 512 Мб или более, функционирующий под управлением операционной системы Yaiza версии 3.0 с установленным обновлением 6d, с или 7 или версии 4.0;

- стандартный ПК с процессором 1 ГГц или более и ОП 512 Мб или более, функционирующий под управлением операционной системы Yaiza версии 3.0 с установленным обновлением 6d, с, установленной графической картой WonderMagic 1.0 с набором драйверов для WM версии 1.0;

- стандартный ПК с операционной системой Yaiza версии 3.0 (или выше);

- интегральная схема CleverCard SB2067;

- интегральная схема CleverCard SB2067 с установленной операционной системой для смарт-карт QuickOS;

- локальная вычислительная сеть департамента транспорта по состоянию на декабрь 2002 года.

А.4.3 Описание ОО

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

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

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

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

Примеры, когда ОО интегрирован с сущностями, не входящими в ОО:

- ОО является ИС смарт-карты, за исключением криптографического сопроцессора;

- ОО является частью межсетевого экрана MinuteGap версии 18.5, связанной с трансляцией сетевых адресов.

А.5 Утверждения о соответствии (ASE_CCL)

В данном подразделе ЗБ описывается соответствие ЗБ:

- части 2 и части 3 настоящего стандарта;

- профилям защиты (если применимо);

- пакетам (если применимо).

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

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

Описание соответствия ЗБ пакетам предусматривает перечисление в ЗБ пакетов, по отношению к которым требуется соответствие. Пояснения см. в 9.4.

А.6 Определение проблемы безопасности (ASE_SPD)

А.6.1 Введение

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

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

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

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

А.6.2 Угрозы

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

Угроза определяется негативным действием, выполняемым источником угрозы по отношению к некоторому активу.

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

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

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

Примеры угроз:

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

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

- системный администратор, нарушающий приватность пользователя;

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

А.6.3 Политика безопасности организации (ПБОр)

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

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

Примеры ПБОр:

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

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

А.6.4 Предположения

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

Примеры предположений:

- предположения, связанные с физическими аспектами среды функционирования:

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

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

- предположения, связанные с персоналом среды функционирования:

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

- предполагается, что пользователи ОО допущены к информации ограниченного доступа;

- предполагается, что пользователи ОО не будут записывать свои пароли.

- предположения по отношению к аспектам связности среды функционирования:

- предполагается, что на автоматизированном рабочем месте на базе ПК для работы ОО доступно как минимум 10 Гб дискового пространства;

- предполагается, что ОО является единственным, кроме ОС, приложением, работающим на конкретной рабочей станции;

- предполагается, что ОО не будет связан с недоверенной сетью.

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

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

А.7 Цели безопасности (ASE_OBJ)

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

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

- разделить данное решение на две части, отражающие, что различные сущности решают свою часть проблемы;

- продемонстрировать, что эти части решения формируют полное решение проблемы.

А.7.1 Высокоуровневое решение

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

А.7.2 Части решения проблемы

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

А.7.2.1 Цели безопасности для ОО

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

Примеры целей безопасности для ОО:

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

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

- ОО должен ограничить доступ пользователей к данным согласно политике доступа к данным, описанной в приложении к ЗБ.

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

А.7.2.2 Цели безопасности для среды функционирования

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

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

- в среде функционирования должно быть предоставлено автоматизированное рабочее место с установленной ОС Inux версии 3.01b для функционирования ОО на его базе;

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

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

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

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

А.7.3 Взаимосвязь между целями безопасности и определением проблемы безопасности

ЗБ также содержит подраздел "Обоснование целей безопасности", включающий два пункта:

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

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

А.7.3.1 Прослеживание целей безопасности к определению проблемы безопасности

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

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

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

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

"Рисунок А.2 - Сопоставление целей безопасности и определения проблемы безопасности"

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

А.7.3.2 Предоставление логического обоснования для сопоставления

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

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

В некоторых случаях, когда элементы "Определения проблемы безопасности" являются очень близкими к изложению некоторых целей безопасности, демонстрация может быть очень простой. Пример: угроза "Т17: Источник угрозы X читает конфиденциальную информацию при ее передаче между А и В", цель безопасности для ОО: "О12: ОО должен обеспечить сохранение конфиденциальности всей информации, передаваемой между А и В" и демонстрация: "Угрозе Т17 напрямую противостоит цель 012".

А.7.3.3 Предотвращаемые угрозы

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

Примеры устранения угрозы:

- устранение возможностей со стороны источника угрозы осуществлять нежелательное действие;

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

- устранение источника угрозы (например, отключение от сети ПК, которые часто "рушат" эту сеть).

Примеры уменьшения угрозы:

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

- ограничение возможности выполнить нежелательное действие источником угрозы;

- уменьшение вероятности успешного результата, выполненного нежелательного действия;

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

- требование от источника угрозы большей компетентности или больших ресурсов.

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

- частое создание резервных копий актива;

- приобретение дополнительных копий актива;

- страхование актива;

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

А.7.4 Цели безопасности: заключение

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

А.8 Определение расширенных компонентов (ASE_ECD)

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

Данный раздел ЗБ предназначен для изложения только расширенных компонентов, а не расширенных требований (требований, основанных на расширенных компонентах). Расширенные требования следует включать в раздел ЗБ "Требования безопасности" (см. А.9), и их предназначение то же, что и у требований, основанных на компонентах из ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3.

А.9 Требования безопасности (ASE_REQ)

Требования безопасности включают две группы требований:

a) функциональные требования безопасности (ФТБ): перевод целей безопасности для ОО на некоторый стандартизированный язык;

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

Эти две группы требований безопасности рассматриваются в 9.1 и 9.2.

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

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

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

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

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

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

А.9.1.1 Способы преобразования целей безопасности в требования безопасности, поддерживаемые ИСО/МЭК 15408

ИСО/МЭК 15408 поддерживает преобразование целей безопасности в требования безопасности тремя способами:

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

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

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

А.9.1.2 Взаимосвязь между ФТБ и целями безопасности

ЗБ также содержит "Обоснование требований безопасности", включающее два пункта, касающихся ФТБ:

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

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

А.9.1.2.1 Прослеживание ФТБ к целям безопасности для ОО

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

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

b) Полнота по отношению к целям безопасности для ОО: для каждой цели безопасности для ОО имеется, по крайней мере, одно ФТБ, сопоставленное с ней.

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

А.9.1.2.2 Предоставление логического обоснования для сопоставления

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

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

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

А.9.2 Требования доверия к безопасности (ТДБ)

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

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

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

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

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

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

А.9.3 ТДБ и обоснование требований безопасности

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

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

А.9.4 Требования безопасности: заключение

В ЗБ в "Определении проблемы безопасности" определяется проблема безопасности, которая включает угрозы, ПБОр и предположения. В разделе ЗБ "Цели безопасности" решение проблемы безопасности подразделяется на две части:

- цели безопасности для ОО;

- цели безопасности для среды функционирования.

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

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

Кроме того, здесь приводится совокупность ТДБ, чтобы показать, каким образом оценивается ОО, а также - пояснение выбора этих ТДБ.

Все вышеупомянутое может быть объединено в рамках следующего утверждения. Если все ФТБ и ТДБ удовлетворены и все цели безопасности для среды функционирования достигнуты, то имеется доверие к тому, что проблема безопасности, определенная в соответствии с ASE_SPD, решена: всем угрозам обеспечено противостояние, все ПБОр осуществлены и все предположения реализованы. Данное утверждение проиллюстрировано на рисунке A.3.

"Рисунок А.3 - Взаимосвязь между определением проблемы безопасности, целями безопасности и требованиями безопасности"

Объем приобретенного доверия определяется ТДБ, а достаточность этого объема доверия определяется пояснением выбора ТДБ.

А.10 Краткая спецификация ОО (ASE_TSS)

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

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

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

А.11 Вопросы, на которые можно ответить с помощью ЗБ

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

a) Как найти необходимые ЗБ/ОО из множества существующих ЗБ/ОО? Этот вопрос обращен к "Аннотации ОО", в которой дается краткое (несколько параграфов) описание ОО;

b) Согласован ли ОО с существующей инфраструктурой ИТ? Этот вопрос обращен к "Аннотации ОО", в которой идентифицируются основные элементы аппаратных средств/программно-аппаратных средств/программного обеспечения, под управлением которых должен функционировать ОО;

c) Согласован ли ОО с существующей средой функционирования? Этот вопрос обращен к "Целям безопасности для среды функционирования", где определяются все ограничения на размещение ОО в среде функционирования;

d) Что делает (возможности) ОО (заинтересованный пользователь)? Этот вопрос обращен к "Аннотации ОО", в которой дается краткое (несколько параграфов) описание ОО;

e) Что делает ОО (потенциальный потребитель)? Этот вопрос обращен к "Описанию ОО", в котором дается более подробное, чем в "Аннотации ОО", описание ОО (на несколько страниц);

f) Что делает ОО (технический специалист)? Этот вопрос обращен к "Краткой спецификации ОО", в которой приводится высокоуровневое описание механизмов, использованных в ОО;

g) Что делает ОО (эксперт)? Этот вопрос обращен к ФТБ, которые обеспечивают достаточно абстрактное техническое описание, и к "Краткой спецификации ОО", в которой приводятся дополнительные подробности;

h) Решает ли ОО проблему с учетом требований государства/организации? Если государство/организация определили пакеты и/или ПЗ, чтобы определить решение, то ответ на указанный вопрос может быть найден в разделе ЗБ "Утверждения о соответствии", в котором перечисляются все пакеты и ПЗ, которым соответствует ЗБ;

i) Отвечает ли ОО конкретной проблеме безопасности (эксперт)? Каким угрозам противостоит ОО? Какую политику безопасности организации реализует ОО? Какие предположения сделаны относительно среды функционирования? На эти вопросы отвечает "Определение проблемы безопасности";

j) Каков объем доверия к ОО? Ответ на этот вопрос может быть найден в ТДБ в разделе ЗБ "Требования безопасности", в котором определен уровень доверия, использованный при оценке ОО, а следовательно - объем доверия к корректности ОО, обеспечиваемый в результате оценки.

А.12 Задания по безопасности для низкого уровня доверия

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

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

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

- не требуется приводить определение проблемы безопасности;

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

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

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

Все, что остается в таком ЗБ, включает:

a) ссылки на ОО и ЗБ;

b) утверждение о соответствии;

c) различные описательные материалы:

1) аннотация ОО;

2) описание ОО;

3) краткая спецификация ОО;

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

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

Сокращенное содержание ЗБ для низкого уровня доверия приведено на рисунке 4.

А.13 Ссылка в ЗБ на другие стандарты

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

а) В качестве политики безопасности организации (или ее части).

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

"Рисунок А.4 - Содержание задания по безопасности для низкого уровня доверия"

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

c) В качестве упоминания стандарта (например, стандарта по криптографии) в краткой спецификации ОО.

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