Security Evaluation

For Information Technology

Common Criteria

Окончательная версия

Версия 3.1 Пакет изменений 3

Июль 2009

Часть 1 Введение и общая модель

ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

ОБЩИЕ КРИТЕРИИ

 

 

 

 

 

Part 1: Introduction and general model

 

July 2009

Version 3.1 Revision 3

Final

 

 

1.1 Контекст оценки

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

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

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

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

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

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

1.2 Объект оценки

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

Таким образом, в контексте оценке в ОК используется термин ”ОО“ (объект оценки).

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

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

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

 

Примерами ОО являются:

· прикладная программа;

· операционная система;

· прикладная программа в сочетании с операционной системой;

· прикладная программа в сочетании с операционной системой и рабочей станцией;

· операционная система в сочетании с рабочей станцией;

· интегральная схема смарт-карты;

· локальная вычислительная сеть, включая все терминалы, серверы, сетевое оборудование и программные средства;

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

 

 

1.2.1 Различные представления ОО

В ОК ОО может встречаться в нескольких представлениях, таких как (для программного ОО):

· список файлов в системе управления конфигурацией;

· отдельная мастер-копия, которая была только что скомпилирована;

· коробка, содержащая компакт-диск и руководства, готовая для поставки потребителю;

· установленная и функционирующая версия.

Все из перечисленного считается ОО: где в дальнейшем в ОК используется термин ”ОО“, его конкретное представление определяется из контекста.

1.2.2 Различные конфигурации ОО

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

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

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

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

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

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

 

1.3 Активы и контрмеры

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

· содержание файла или сервера;

· подлинность голосов, поданных на выборах;

· доступность процесса электронной коммерции;

· возможность использовать дорогостоящий принтер;

· доступ к средствам ограниченного доступа.

Но так как ценность – это весьма субъективное понятие, то почти все, что угодно, может рассматриваться в качестве активов.

 

Среда, в которой размещаются эти активы, называется средой функционирования. Примерами (аспектами) среды функционирования являются:

· компьютерное помещение в банке;

· компьютерная сеть, подключенная к Интернету;

· локальная вычислительная сеть (ЛВС);

· обычная офисная среда.

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

Рисунок 2 – Понятия безопасности и их взаимосвязь

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

При отстаивании этого решения должна иметься возможность продемонстрировать два важных момента, что:

· контрмеры являются достаточными: если контрмеры выполняют то, что заявлено, то угрозам, направленным на активы, обеспечивается противостояние;

· контрмеры являются корректными: контрмеры выполняют то, что заявлено.

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

 

1.3.1 Достаточность контрмер

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

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

Далее в Задании по безопасности контрмеры делятся на две группы:

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

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

Причинами данного разделения являются:

· ОК применим только для оценивания корректности контрмер ИТ. Следовательно, не-ИТ контрмеры (например, сотрудники службы безопасности, процедуры) всегда относят к среде функционирования;

· оценивание корректности контрмер требует затрат времени и денег, возможно делая неосуществимой оценку корректности всех контрмер ИТ;

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

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

Таким образом, Задание по безопасности демонстрирует, что:

· ФТБ удовлетворяют целям безопасности для ОО;

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

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

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

1.3.2 Корректность ОО

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

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

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

· тестирование ОО;

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

· исследование физической безопасности среды разработки ОО.

Задание по безопасности обеспечивает структурированное описание этих видов деятельности для определения корректности в форме требований доверия к безопасности (ТДБ). Эти ТДБ формулируются на стандартном языке (описанном в ОК-3), чтобы обеспечить точность и облегчить сопоставимость.

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

1.3.3 Корректность среды функционирования

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

Однако в ОК доверие не приобретается при рассмотрении корректности среды функционирования. Или, другими словами, среда функционирования не оценивается (см. 6.3).

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

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

 

· если установлены цели безопасности для среды функционирования ОО типа ”ОС: ”Среда функционирования должна обеспечить, что сущности из недоверенной сети (например, Интернета) могут осуществлять доступ к ОО по ftp“, то потребитель мог бы выбрать оцененный межсетевой экран и настроить его так, чтобы к ОО был разрешен доступ только по ftp;

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

1.4 Оценка

По ОК признают два типа оценки: оценка ЗБ/ОО, которая описывается ниже, и оценка ПЗ, которая определяется в ОК-3. Во многих местах ОК использован термин ”оценка“ (без уточнений) для ссылки на оценку ЗБ/ОО.

По ОК оценка ЗБ/ОО проходит в два этапа:

a) оценка ЗБ: на этом этапе определяют полноту описания ОО и среды функционирования;

b) оценка ОО: на этом этапе определяют корректность ОО; оценка ОО как отмечалось ранее, не включает оценку корректности среды функционирования.

Оценку ЗБ выполняют путем применения критериев оценки заданий по безопасности (которые определены в разделе ASE ОК-3). Конкретный способ применения критериев ASE определяется используемой методологией оценки.

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

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

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

Результатом процесса оценки ОО будет:

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

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

Оценка ОО может быть выполнена после завершения разработки ОО или параллельно с разработкой ОО.

Способ изложения результатов оценки ЗБ/ОО описан в разделе 9. В этих результатах также указывают ПЗ и пакет(ы), по отношению к которым заявлено соответствие ОО; эти конструкции описаны в разделе 8.


2 Доработка требований безопасности для конкретного применения

2.1 Операции

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

a) итерация (iteration): позволяет неоднократно использовать компонент при различном выполнении в нем операций;

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

c) выбор(selection): позволяет выбирать один или более пунктов из перечня;

d) уточнение (refinement): позволяет осуществлять детализацию.

Операции ”назначение“ и ”выбор“ разрешены только в тех местах компонента, где они специально обозначены.

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

a) ”Нет“ допускается как вариант выполнения выбора только, если он явным образом предусмотрен.

Списки, предусмотренные для выполнения операций выбора, не должны быть пустыми. Если выбран вариант ”Нет“, никакие другие дополнительные варианты выбора не могут быть выбраны. Если ”Нет“ не предусмотрено в качестве варианта выбора, допускается сочетание вариантов в операции выбора с союзами "и" и "или", если в операции выбора в явном виде не определено "выбрать одно из".

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

b) По отношению к выполнению операций назначения необходимо обратиться к Приложениям ОК-2, чтобы определить, когда ”Нет“ является допустимым выполнением.

2.1.1 Операция ”итерация”

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

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

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

2.1.2 Операция ”назначение”

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

Каждый раз, когда элемент в ПЗ предусматривает операцию ”назначение“, разработчик ПЗ должен выполнить одно из четырех действий:

a) оставить операцию ”назначение“ полностью невыполненной. Разработчик ПЗ, например, мог бы включить в ПЗ FIA_AFL.1.2 ”При достижении или превышении определенного числа неуспешных попыток аутентификации ФБО должны выполнить [назначение: список действий]”.

b) полностью выполнить операцию ”назначение“. Например, разработчик ПЗ мог бы включить в ПЗ FIA_AFL.1.2 ”При достижении или превышении определенного числа неуспешных попыток аутентификации ФБО должны предотвращать в дальнейшем привязку соответствующей внешней сущности к какому-либо субъекту”.

c) ограничить операцию ”назначение“, чтобы в дальнейшем ограничить диапазон допустимых значений. Например, разработчик ПЗ мог бы включить в ПЗ FIA_AFL.1.1 ”ФБО должны обнаружить, когда произойдет [назначение: положительное целое от 4 до 9] неуспешных попыток аутентификации …”.

d) преобразовать ”назначение“ в ”выбор“, ограничивая таким образом ”назначение“. Например, разработчик ПЗ мог бы включить в ПЗ FIA_AFL.1.2 ”При достижении или превышении определенного числа неуспешных попыток аутентификации ФБО должны [выбор: предотвращать в дальнейшем привязку соответствующего пользователя к какому-либо субъекту, уведомлять администратора”].

Каждый раз, когда элемент в ЗБ предусматривает операцию ”назначение“, разработчик ЗБ должен завершить выполнение этой операции ”назначение“, как указано выше в варианте b). Варианты a), c) и d) для ЗБ не допускаются.

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

Когда ”назначение“ должно быть завершено определением некоторой совокупности, например, субъектов, в ”назначении“ можно перечислить совокупность этих субъектов, но также можно привести некоторое описание этой совокупности, на основе которого могут быть определены элементы совокупности, такое как:

· все субъекты;

· все субъекты типа X;

· все субъекты, кроме субъекта А,

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

2.1.3 Операция ”выбор”

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

Каждый раз, когда элемент в ПЗ предусматривает операцию ”выбор“, разработчик ПЗ может выполнить одно из трех действий:

a) оставить операцию ”выбор“ полностью невыполненной;

b) полностью выполнить операцию ”выбор“ путем выбора одного или более пунктов;

c) ограничить операцию ”выбор“, удалив некоторые из вариантов, но оставив два или более.

Каждый раз, когда элемент в ЗБ предусматривает операцию ”выбор“, разработчик ЗБ должен завершить выполнение этой операции ”выбор“, как указано выше в варианте b). Варианты a) и c) для ЗБ не допускаются.

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

2.1.4 Операция ”уточнение”

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

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

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

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

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

2.2 Зависимости между компонентами

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

Другими словами, если компонент А имеет зависимость от компонента Б, это означает, что когда ПЗ/ЗБ содержит компонент А, ПЗ/ЗБ должен также содержать одно из:

a) компонент Б;

b) компонент, более высокого уровня по иерархии по отношению к Б;

c) обоснование, почему ПЗ/ЗБ не содержит компонент Б.

2.3 Расширенные компоненты

Согласно ОК необходимо, чтобы требования основывались на компонентах из ОК-2 или ОК-3 с двумя исключениями:

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

b) цели безопасности могут быть выражены на основе компонентов из ОК-2 и/или ОК-3, но только с большими трудностями и/или сложностями.

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

После корректного определения новых компонентов разработчик ПЗ/ЗБ может затем включить одно или более ФТБ или ТДБ в эти вновь определенные расширенные компоненты и использовать их таким же образом, как и другие ФТБ и ТДБ. С этого момента не существует каких-либо различий между ФТБ и ТДБ, изложенными в ОК, и ФТБ и ТДБ, включенными в расширенные компоненты. Дополнительные требования к расширенным компонентам изложены в семействах ”Определение расширенных компонентов“ (APE_ECD) и ”Определение расширенных компонентов“ (ASE_ECD) ОК-3.

 

3 Профили защиты и пакеты

3.1 Пакеты

Пакет – это именованный набор требований безопасности. Пакеты делятся на:

· функциональные пакеты, включающие только ФТБ;

· пакеты доверия, включающие только ТДБ.

Смешанные пакеты, включающие как ФТБ, так и ТДБ, не допустимы.

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

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

Примерами пакетов доверия являются оценочные уровни доверия (ОУД), определенные в ОК-3.

3.2 Профили защиты

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

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

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

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

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

ПЗ определяет допустимый тип соответствия ЗБ профилю защиты. То есть, в ПЗ устанавливают (в разделе ПЗ ”Утверждение о соответствии“, см. B.5), какие типы соответствия являются допустимыми для ЗБ, а именно:

· если в ПЗ установлено, что требуется ”строгое соответствие“, то ЗБ должно в строгой форме соответствовать ПЗ;

· если в ПЗ установлено, что требуется ”демонстрируемое соответствие“, то ЗБ должно либо строго соответствовать ПЗ, либо его соответствие ПЗ может быть продемонстрировано.

Иными словами, для ЗБ допускается ”демонстрируемое соответствие“ ПЗ только, если ПЗ в явном виде это разрешает.

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

Следует отметить, что ЗБ либо соответствует рассматриваемому ПЗ, либо не соответствует. ОК не признает ”частичное“ соответствие. Поэтому обязанность разработчика ПЗ – обеспечить, чтобы ПЗ не был чрезмерно перегруженным и не создавал бы, таким образом, препятствий разработчикам ПЗ/ЗБ при заявлении о соответствии ПЗ.

ЗБ эквивалентно ПЗ либо является более ограничительным, если:

· ОО, который удовлетворяет ЗБ, также удовлетворяет ПЗ;

· все среды функционирования, которые удовлетворяют ПЗ, также удовлетворяют ЗБ.

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

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

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

· ОО, который бы отвечал определению проблемы безопасности в ЗБ, также отвечал бы определению проблемы безопасности в ПЗ;;

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

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

· ОО, который бы отвечал целям безопасности для ОО в ЗБ, также отвечал бы целям безопасности для ОО в ПЗ;;

· все среды функционирования, которые отвечали бы целям безопасности для среды функционирования в ПЗ, также отвечали бы целям безопасности для среды функционирования в ЗБ. ;

Если определено строгое соответствие профилям защиты, то применяют следующие требования:

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

b) Цели безопасности: ЗБ:

· должно включать все цели безопасности для ОО из ПЗ, но может определять дополнительные цели безопасности для ОО;

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

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

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

Если определено ”демонстрируемое соответствие“ профилям защиты, то применяют следующие требования:

· ЗБ должно включать обоснование того, почему ЗБ рассматривается как ”эквивалентное или более ограничительное“ по отношению к ПЗ;

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

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

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

 

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

· при оценке новых ПЗ/ЗБ часто могут быть повторно использованы результаты оценки оцененного ПЗ, что облегчит оценку новых ПЗ/ЗБ.

 

Рисунок 4 – Взаимосвязь между содержанием ПЗ, ЗБ и ОО

3.3 Использование ПЗ и пакетов

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

Это делает возможным следующий процесс:

a) организация, заинтересованная в приобретении конкретного типа продукта безопасности ИТ, излагает свои потребности в безопасности в ПЗ, затем обеспечивает его оценку и выпуск;

b) разработчик получает этот ПЗ, разрабатывает ЗБ, которое содержит утверждение о соответствии данному ПЗ, и обеспечивает оценку этого ЗБ;

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

3.4 Многократное использование профилей защиты

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

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


4 Результаты оценки

4.1 Введение

В этом разделе представлены ожидаемые результаты оценки ПЗ и ЗБ/ОО, выполненной в соответствии с ОМО:

· оценки профилей защиты позволяют создавать каталоги (реестры) оцененных ПЗ;

· оценка ЗБ дает промежуточные результаты, которые затем используются при оценке ОО;

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

 

Рисунок 5 – Результаты оценки

ЗБ могут базироваться на пакетах, оцененных ПЗ, неоцененных ПЗ; тем не менее, совсем не обязательно, чтобы ЗБ на чем-то базировались.

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

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

4.2 Результаты оценки ПЗ

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

Результаты оценки должны также включать ”Утверждение о соответствии“ (см. 9.4).

4.3 Результаты оценки ЗБ/ОО

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

Результат оценки ОО должен формулироваться как "соответствие/несоответствие" по отношению к ЗБ. Если и для ЗБ, и для ОО результат оценки – ”соответствует“, то соответствующий продукт получает право включения в реестр. Результаты оценки должны также включать ”Утверждение о соответствии“, как определено в 9.4.

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

4.4 Утверждение о соответствии

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

a) описывает ту версию ОК, о соответствии которой заявлено в ПЗ или ЗБ;

b) описывает соответствие ОК-2 (функциональные требования безопасности), включающее одно из следующего:

· ”соответствие ОК-2“ – ПЗ или ЗБ соответствует ОК-2, если все ФТБ в данном ПЗ или ЗБ основаны только на функциональных компонентах из ОК-2;

· ”расширение ОК-2“ – ПЗ или ЗБ является расширенным по отношению к ОК-2, если, как минимум, одно ФТБ в данном ПЗ или ЗБ не основано на функциональных компонентах из ОК-2;

c) описывает соответствие ОК-3 (требования доверия к безопасности), включающее одно из следующего:

· ”соответствие ОК-3“ – ПЗ или ЗБ соответствует ОК-3, если все ТДБ в данном ПЗ или ЗБ основаны только на компонентах доверия из ОК-3;

· ”расширение ОК-3“ – ПЗ или ЗБ является расширенным по отношению к ОК-3, если, как минимум, одно ТДБ в данном ПЗ или ЗБ не основано на компонентах доверия из ОК-3.

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

· ”соответствие именованному пакету“ – ПЗ или ЗБ соответствует предопределенному именованному пакету (например, ОУД), если:

· ФТБ в ПЗ или ЗБ идентичны ФТБ в пакете или

· ТДБ в ПЗ или ЗБ идентичны ТДБ в пакете.

· ”усиление именованного пакета“ – ПЗ или ЗБ является усилением предопределенного именованного пакета, если:

· ФТБ в ПЗ или ЗБ включают все ФТБ из пакета, а также содержат, как минимум, одно дополнительное ФТБ или ФТБ, которое является иерархичным по отношению к некоторому ФТБ из пакета;

· ТДБ в ПЗ или ЗБ включают все ТДБ из пакета, а также содержат, как минимум, одно дополнительное ТДБ или ТДБ, которое является иерархичным по отношению к некоторому ТДБ из пакета.

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

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

a) ”соответствие ПЗ – ПЗ или ОО удовлетворяет конкретному(ым) профилю (ям) защиты, который(ые) перечислен(ы) как часть утверждения о соответствии;

b) ”изложение соответствия“ (только для профилей защиты) – В данном изложении описывается способ, которым должно быть обеспечено соответствие профилей защиты или заданий по безопасности рассматриваемому ПЗ: строгое или демонстрируемое. Более подробная информация по вопросу ”изложения соответствия“ приведена в Приложении В.

 

4.5 Использование результатов оценки ЗБ/ОО

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

При этом владелец активов должен тщательно проверить следующее:

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

e) раздел ”Определение расширенных компонентов“ (опционально), в котором могут быть определены новые компоненты (то есть, компоненты, не содержащиеся в ОК-2 или ОК-3). Для этих новых компонентов необходимо сформулировать расширенные функциональные требования и расширенные требования доверия;

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

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

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

 

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