Предисловие
Перечень сокращений
1.Представление и общая модель
2.Требования к функциям безопасности
3.Требования гарантии безопасности
4.Предопределенные профили защиты
Заключение
Литература
Приложение

Предисловие

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

В России единственными нормативными документами по критериям оценки защищенности средств вычислительной техники и автоматизированных систем являются Руководящие документы Гостехкомиссии РФ [1-5], разработанные с учетом предшествующих основополагающих документов [10,13].

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

Общие критерии обобщили содержание и опыт использования Оранжевой книги [10], развили уровни гарантии оценки Европейских критериев [13], воплотили в реальные структуры концепцию типовых профилей защиты Федеральных критериев США [15].

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

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

Настоящий обзор подготовлен с целью обобщения имеющихся материалов по Общим критериям оценки безопасности ИТ и разработки предложений по их использованию при:

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

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

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

Обзор подготовил ктн М.Т.Кобзарь. Автор выражает глубокую благодарность В.А.Евстигнееву, М.Ю.Долинину, В.В.Бердинских за помощь в техническом переводе исходных текстов и участие в их редактировании, а также кандидатам технических наук А.П.Трубачеву, Ю.М.Гончарову, И.А.Калайде за внимательное прочтение материалов обзора и ценные замечания. Особая благодарность доктору технических наук Ю.А.Бородину, который обеспечил получение исходных текстов по сети Интернет и провел их предварительный анализ.

 

Перечень сокращений

ВКФБ - возможности контроля функции безопасности

ЗБ - задание по безопасности

ИТ - информационная технология

ИФБ - интерфейс функции безопасности

КЗ - коммерческая защита

МЭ - межсетевой экран

ОК - общие критерии

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

ПБ - политика безопасности

ПЗ - профиль защиты

ПФБ - политика функции безопасности

ТЗ - техническое задание

УГО - уровень гарантии оценки

УК - управление конфигурацией

ФБ - функция безопасности

 

1. Представление и общая модель

  1.1. Введение

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

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

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

Общие критерии разработаны с учетом совместимости с этими существующими критериями, чтобы таким образом сохранить преемственность оценок безопасности.

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

  1.2. Подготовка общих критериев

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

В Европе Критерии оценки безопасности информационной технологии (ITSEC) версия 1.2 были изданы в 1991 году Европейской комиссией в результате совместных усилий Франции, Германии, Голландии и Англии.

В Канаде Критерии оценки компьютерных систем (CTCPEC) версия 3.1 [14] были изданы в 1993 году как комбинация подходов TCSEC и ITSEC.

В США проект Федеральных критериев для оценки безопасности информационной технологии (FC) версия 1 [15] был также издан в 1993 году как второй шаг к объединению Американской и Европейской концепций для критериев оценки.

В 1990 году Международная организация по стандартизации (ИСО) начала работу по разработке международных стандартов по критериям оценки безопасности ИТ для общего использования. Новые критерии должны были быть адаптированы к потребностям взаимного признания результатов оценки безопасности ИТ в глобальном масштабе. Эта задача была возложена на рабочую группу 3 (WG 3) из подкомиссии 27 (SC 27) ИСО.

В июне 1993 года авторы ITSEC, TCSEC, FC, CTCPEC объединили свои усилия и начали разработку проекта Общих критериев оценки безопасности информационной технологии (CCEB). Цель проекта состояла в том, чтобы исключить концептуальные и технические различия, имеющиеся в исходных критериях, и представить результаты в ИСО как проект международного стандарта.

В разработке Общих критериев участвовали: Национальный институт стандартов и технологии и Агентство национальной безопасности (США), Учреждение безопасности коммуникаций (Канада), Агентство информационной безопасности (Германия), Агентство национальной безопасности коммуникаций (Голландия), Органы исполнения Программы безопасности и сертификации ИТ (Англия), Центр обеспечения безопасности систем (Франция).

В январе 1996 года была выпущена версия 1.0 Общих критериев [16], которая и положена в основу настоящего обзора. В 1997 году были выпущены дополнительные материалы, выпуск версии 2.0 планируется в мае 1998 года.

  1.3. Целевая направленность общих критериев

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

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

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

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

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

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

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

 

  1.4. Организация общих критериев

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

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

Часть 2 "Требования к функциям безопасности" - устанавливает набор функциональных компонентов как стандартный путь выражения функциональных требований к объектам оценки. Каталоги части 2 содержат наборы функциональных компонентов, сгруппированные в семейства и классы.

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

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

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

  1.5. Возможности и применимость

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

К таким объектам относятся, например, операционные системы, сети компьютеров, распределенные системы, прикладные программы.

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

ОК могут быть также применимы и к другим аспектам безопасности ИТ.

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

Некоторые аспекты безопасности ИТ находятся вне рамок ОК. К ним относятся следующие:

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

б) в ОК не рассматривается оценка технических аспектов безопасности ИТ типа электромагнитного излучения;

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

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

д) в ОК не входят критерии для оценки специфических качеств криптографических методов и алгоритмов защиты информации.

 

  1.6. Концепция общих критериев

В соответствии с концепцией ОК требования безопасности объекта оценки подразделяются на две категории: функциональные требования и требования гарантированности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Профиль Защиты определен как набор требований, который состоит только из компонентов или пакетов функциональных требований, приведенных в Части 2, и одного из уровней гарантии, при необходимости усиленного дополнительными компонентами гарантии из Части 3 ОК.

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

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

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

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

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

Концептуальная схема оценки безопасности ИТ на основе ОК представлена на рисунке Концептуальная схема оценки безопасности ИТ на основе Общих критериев

Концептуальная схема оценки
безопасности ИТ на основе Общих критериев  

2. Требования к функциям безопасности

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

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

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

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

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

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

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

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

 

  2.2. Общие положения

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

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

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

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

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

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

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

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

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

б) Удаленный ОО не был оценен, поэтому его ПБ неизвестна. Обмен информацией в этой ситуации называется передачей вне контроля ФБ.

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

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

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

В ОК используется термин Уполномоченный пользователь для обозначения пользователя, обладающего правами и/или привилегиями, необходимыми для исполнения действия. Этот термин указывает, что пользователь допущен к исполнению действий в соответствии с ПБ.

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

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

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

Активные объекты названы Субъектами. В пределах ОО могут существовать несколько типов субъектов:

a) действующий от имени уполномоченного пользователя и выполняющий все правила ПБ (например, UNIX процессы);

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

в) действующий от имени уполномоченных администраторов;

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

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

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

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

Могут быть два специфических типа данных ФБ. Это - опознавательные данные и тайны.

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

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

 

  2.3. Структура функциональных требований

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

   2.3.1. Класс

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

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

   2.3.2. Семейство

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

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

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

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

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

   2.3.3. Компонент

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

а) Уникальное название, которое отражает цель компонента.

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

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

   2.3.4. Элемент

Набор элементов предусмотрен в каждом компоненте. Каждый элемент определяется и выделяется индивидуально.

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

При использовании ПЗ/ЗБ не разрешается выбирать только один или большее количество элементов из компонента. Для включения в ПЗ\ЗБ должен быть отобран полный набор элементов компонента.

В ОК принята уникальная короткая форма названия(имени) функционального элемента. Например, требование FDP_IFF. 4.2 читается следующим образом: F - функциональное требование, DP - класс "Защита Данных Пользователя", IFF - семейство "Функции Управления Информационным Потоком", 4 - 4-ый компонент, названный "Частичное Устранение Незаконных Информационных Потоков", 2 - 2-ой элемент компонента.

  2.4. Краткий обзор классов и семейств

Классы и семейства функциональных требований сгруппированы на основе определенной функции или цели и представлены в ОК в алфавитном порядке. Всего в разделе "Требования к функциям безопасности" ОК девять классов, 76 семейств, 184 компонента и 380 элементов.

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

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

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

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

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

КлассFPT (Защита Функций Безопасности) включает 22 семейства функциональных требований, которые касаются целостности и контроля механизмов, обеспечивающих ФБ, и целостности и контроля данных ФБ. Может показаться, что семейства в этом классе дублируют компоненты в классе FDP (Защита Данных Пользователя); они могут даже быть реализованы, используя те же самые механизмы. Однако, класс FDP сосредотачивается на защите данных пользователя, в то время как класс FPT - на защите данных ФБ. Фактически, компоненты от класса FPT необходимы даже при отсутствии любой защиты данных пользователя, обеспечивая доверие осуществлению политики, определенной в ПЗ/ЗБ.

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

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

КлассFTP (Надежный Маршрут/Канал) включает два семейства, которые содержат требования по обеспечению надежного маршрута связи между пользователями и ФБ и надежного канала связи между ФБ, имеющих следующие общие характеристики:

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

- использование маршрута коммуникаций может быть инициализировано пользователем и/или ФБ;

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

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

3. Требования гарантии безопасности

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

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

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

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

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

Методы оценки могут включать:

a) анализ и проверку процесса (ов) и процедуры ();

б) проверку процесса (ов) и процедуры (), который является прикладным;

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

г) анализ соответствия представленного проекта ОО требованиям;

д) проверку математических доказательств;

е) анализ руководящих документов;

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

з) независимое функциональное испытание;

и) анализ уязвимости (включая гипотезу недостатка);

к) испытание проникновения.

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

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

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

и деталей выполнения;

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

 

  3.2. Структура требований гарантии

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

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

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

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

б) Элементы представления и содержания свидетельства (требуемое свидетельство, что свидетельство должно демонстрировать, какую информацию свидетельство должно передать). Требования по содержанию и представлению свидетельств идентифицированы путем добавления к номеру элемента в конце буквы "C".

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

 

  3.3. Критерии оценки профиля защиты и задания по безопасности

Эти критерии - первые требования, представленные в Части 3 ОК, так как оценка ПЗ и ЗБ обычно выполняется перед оценкой ОО.

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

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

Все семейства классов оценки ПЗ и ЗБ включают только по одному компоненту.

   3.3.1. Класс APE (оценка профиля защиты)

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

Класс APE состоит из трех семейств, отражающих структуру и основное содержание ПЗ:

• Семейство APE_ENV (Профиль Защиты, Безопасность Окружающей среды);
• Семейство APE_OBJ (Профиль Защиты, Цели Безопасности);
• Семейство APE_REQ (Профиль Защиты, Требования Безопасности ОО).

   3.3.2. Класс ASE (оценка задания по безопасности)

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

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

• Семейство ASE_ENV (Задание по Безопасности, Безопасность Окружающей Среды);
• Семейство ASE_OBJ (Задание по Безопасности, Цели Безопасности);
• Семейство ASE_PPC (Задание по Безопасности, Требования ПЗ); Семейство ASE_REQ (Задание по Безопасности, Требования Безопасности ОО);
• Семейство ASE_TSS (Задание по Безопасности, Общая Спецификация ОО).

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

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

 

  3.4. Краткий обзор классов и семейств гарантии

Всего в разделе "Требования гарантии оценки ОО" семь классов, 25семейств, 72 компонента.

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

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

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

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

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

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

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

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

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

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

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

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

Каталог требований гарантии оценки с детализацией до уровня компонентов приведен в таблице 2 Приложения.

 

  3.5. Уровни гарантии

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

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

Таблица 3.1. Сводка уровней гарантии оценки

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

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

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

   3.5.1. Краткий обзор уровней гарантии оценки

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

Уровень Гарантии Оценки 1 (УГО1) - функционально проверенный проект.

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

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

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

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

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

Уровень Гарантии Оценки 3 (УГО3) - методически проверенный и оттестированный проект.

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

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

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

Уровень Гарантии Оценки 4 (УГО4) - методически разработанный и проверенный проект.

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

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

Этот УГО представляет значимое увеличение гарантии по сравнению с УГО3, требуя более детального описания проекта, поднабора выполнения и улучшенных механизмов и/или процедур, которые обеспечивают уверенность в том, что ОО не был подделан в процессе разработки.

Уровень Гарантии Оценки 5 (УГО5) - полуформально разработанный и проверенный проект.

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

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

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

Уровень Гарантии Оценки 6 (УГО6) - полуформально верифицированный и проверенный проект.

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

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

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

Уровень Гарантии Оценки 7 (УГО7) - формально верифицированный и проверенный проект.

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

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

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

 

4. Предопределенные профили защиты

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

Часть 4 ОК содержит три Профиля Защиты. Два из них были созданы на основе исходных критериев, а еще один разработан для изделия ИТ, которое является относительно новым для процесса оценки безопасности.

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

Профили "Коммерческая Защита 1" (КЗ1) и "Коммерческая Защита 3" (КЗ3) представляют дальнейшее развитие профилей Федеральных критериев [15], выполненное с использованием терминологии и конструкций ОК. Профиль КЗ1 ОК предназначен для замены профиля Федеральных критериев CS1 (и, следовательно, класса C2 TCSEC), но не идентичен этим наборам требований. Профиль КЗ3 ОК предназначен для выполнения тех же самых потребностей потребителя, что и профиль Федеральных критериев CS3.

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

Примечание.Подобное семейство профилей защищенности межсетевых экранов представлено в Руководящем документе Гостехкомиссии России [6].

 

  4.2. Краткий обзор профилей защиты

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

Каждый ПЗ состоит из следующих основных частей:

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

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

в) Функциональные требования - компоненты из Части 2 ОК, конкретизированные, при необходимости, применением разрешенных действий.

г) Требования гарантии, состоящие из уровня гарантии оценки и усиленные, при необходимости, дополнением компонентов гарантии из Части 3 ОК.

   4.2.1. Профиль защиты - коммерческая защита 1 (КЗ1)

4.2.1.1. Представление

Коммерческая защита 1 (КЗ1) - базовая управляемая защита доступа, основанная на дискреционном (избирательном) принципе контроля доступа.

КЗ1 определяет набор основополагающих функций безопасности и гарантий для изделий и систем ИТ.

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

4.2.1.2. Описание объекта оценки

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

КЗ1 применим к ОО, которые обеспечивают средства для интерактивного взаимодействия с пользователями.

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

КЗ1 предполагает, что ответственность за сохранение данных, защищенных ОО, может быть делегирована пользователям ОО. Все данные находятся под управлением ОО. Данные сохранены в именованных объектах, и ОО может присоединять к каждому управляемому объекту описание прав доступа к этому объекту.

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

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

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

КЗ1 рассматривается как подходящий для защиты информации только одного уровня конфиденциальности (секретности).

4.2.1.3. Безопасность окружающей среды

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

4.2.1.3.1. Угрозы безопасности

  а) Угрозы, адресованные объекту оценки:

  УГРОЗА ДОСТУПА (T.ACCESS). Неуполномоченный человек может получить логический доступ к ОО.

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

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

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

  УГРОЗА АВТОРА (T.AUTHOR). Пользователь может получить доступ к ресурсам, право доступа к которым ему не предоставлено.

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

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

  УГРОЗА ДЕФЕКТА (T.FLAW). Нарушения безопасности могут происходить из-за дефектов в ОО.

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

  УГРОЗА СЛЕДУ (T.TRACE). Относящиеся к безопасности события не могут быть зарегистрированы или не могут быть различимы пользователем.

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

  б) Угрозы, адресованные операционной окружающей среде:

  УГРОЗА ФУНКЦИОНИРОВАНИЯ (T.OPERATE). Нарушения безопасности могут происходить из-за некомпетентной администрации при применении ОО.

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

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

  УГРОЗА ФИЗИЧЕСКАЯ (T.PHYSICAL). Критические к безопасности части ОО могут быть подвергнуты физической атаке, которая может поставить под угрозу безопасность ОО.

4.2.1.3.2. Организационная политика безопасности

  ПОЛИТИКА ИЗВЕСТНОГО (P.KNOWN). Законные пользователи ОО должны быть идентифицированы до того, как им предоставлен доступ к ОО.

  ПОЛИТИКА ДОВЕРИЯ (P.TRUST). Законным пользователям системы с однажды предоставленным доступом к информации предоставляется возможность последующего контроля над этой информацией.

  ПОЛИТИКА ДОСТУПА (P.ACCESS). Права доступа к специфическим объектам данных определены атрибутами, приписанными этому объекту, идентичностью пользователя и атрибутами, связанными с этим пользователем.

  ПОЛИТИКА ОТЧЕТА (P.ACCOUNT). Пользователи должны быть ответственны в своих действиях, касающихся безопасности.

4.2.1.3.3. Условия безопасного использования

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

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

  а) Физические условия

  УСЛОВИЯ РАЗМЕЩЕНИЯ (A.LOCATE). Ресурсы изделия, включая терминалы, будут размещены в пределах управляемых средств доступа, которые предотвратят несанкционированный физический доступ.

  УСЛОВИЯ ЗАЩИТЫ (A.PROTECT). Аппаратные средства и программное обеспечение ОО, критические к нарушению политики безопасности, будут физически защищены от несанкционированного изменения потенциально враждебными посторонними.

  б) Условия для персонала

  УСЛОВИЯ УПРАВЛЕНИЯ (A.MANAGE). Будут иметься одна или более компетентных личностей, которым предписано управлять ОО и безопасностью содержащейся в нем информации.

  УСЛОВИЯ ДОСТУПА (A.ACCESS). Пользователи обладают необходимыми привилегиями, чтобы обратиться к информации, управляемой ОО.

  УСЛОВИЯ СОТРУДНИЧЕСТВА (A.COOP). Пользователи должны выполнять некоторую задачу или группу задач, которые требуют безопасной окружающей среды ИТ.

  в) Условия соединений

КЗ1 не содержит в явном виде требований для сетей или распределенных систем. Однако принимается, что существуют следующие условия соединений:

  УСЛОВИЯ РАВЕНСТВА ПОЛОЖЕНИЯ (A.PEER). Любые другие системы, с которыми ОО связывается, находятся под тем же самым управлением и эксплуатируются с теми же самыми ограничениями политики безопасности.

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

  УСЛОВИЯ ПОДКЛЮЧЕНИЯ (A.CONNECT). Все связи с периферийными устройствами находятся в пределах действия средств управления доступом.

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

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

  а) Цели безопасности ИТ:

  ЦЕЛЬ ЛОГИЧЕСКАЯ (O.LOGICAL). ОО должен предотвратить логический вход в ОО людям без полномочий доступа к ОО.

  ЦЕЛЬ ДОСТУПА (O.ACCESS). ОО должен ограничить пользователям доступ к ресурсам ОО и допускать только к тем, к которым им предоставлен доступ.

  ЦЕЛЬ ЗАПИСИ (O.RECORD). ОО должен фиксировать необходимые события, чтобы гарантировать, что существует информация для поддержания эффективного управления безопасности.

  ЦЕЛЬ ОТЧЕТА (O.ACCOUNT). ОО должен гарантировать, что все пользователи ОО могут впоследствии быть подотчетными в своих действиях, связанных с безопасностью.

  ЦЕЛЬ ПРЕДОТВРАЩЕНИЯ ОБХОДА (O.BYPASS). ОО должен предотвратить незаконное или неправильное функционирование программного обеспечения и пользователей в обход ограничений политики безопасности ОО.

  ЦЕЛЬ ОТСУТСТВИЯ ДЕФЕКТОВ (O.FLAW). ОО не должен содержать очевидные дефекты в проекте, реализации или применении.

  ЦЕЛЬ УПРАВЛЕНИЯ (O.CONTROL). ОО должен обеспечить все функции и средства, необходимые для поддержки ответственного за управление безопасностью ОО.

  б) Цели безопасности не-ИТ:

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

  ЦЕЛЬ УСТАНОВКИ (O.INSTALL). Ответственный за ОО должен гарантировать, что ОО поставлен, установлен, управляется и эксплуатируется способами, которые поддерживают безопасность ИТ.

  ЦЕЛЬ ФИЗИЧЕСКАЯ (O.PHYSICAL). Ответственный за ОО должен гарантировать, что части ОО, критические к политике безопасности, защищены от физических воздействий, которые могли бы ставить под угрозу безопасность ИТ.

  ЦЕЛЬ ДОВЕРИЯ (O.CREDEN). Ответственный за ОО должен гарантировать, что все мандаты доступа защищены пользователями способом, который поддерживает безопасность ИТ.

  ЦЕЛЬ СОЕДИНЕНИЙ (O.CONNECT). Ответственный за ОО должен гарантировать, что никакие соединения с наружными системами или пользователями не могут ставить под угрозу цели безопасности ИТ.

4.2.1.5. Требования безопасности ОО ИТ

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

4.2.1.5.1. Функциональные требования

В таблице 4.1 приведена сводка функциональных требований КЗ1, выраженных в компонентах Части 2 ОК.

Таблица 4.1 - Функциональные компоненты КЗ1

Требования идентификации и аутентификации

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

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

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

FIA_ATA.1.1 - ФБ должна обеспечить способность инициализации признаков пользователя с обеспеченными стандартными значениями.

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

Требования аудита

FAU_GEN.1.1 - ФБ должна быть способна произвести запись аудита следующих контролируемых событий:

a) Запуск и завершение контролируемых процессов;

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

[FIA_UID] - Все попытки использовать механизм идентификации пользователя, в том числе, при условии идентичности пользователя. Начало запроса должно быть включено в контрольную запись.

[FIA_UAU] - Любое использование опознавательного механизма. Начало запроса должно быть включено в контрольную запись.

[FIA_ATA] - Все запросы на использование функции администрирования признака пользователя, включая идентификацию признаков пользователя, которые были изменены.

[FIA_ADP] - Все запросы к данным аутентификации пользователя.

[FAU_PRO] - Любая попытка читать, модифицировать или уничтожить трассу контроля.

[FAU_MGT] - Любая попытка выполнять операции с трассой контроля.

[FAU_SEL] - Все модификации конфигурации аудита, которые происходят во время работы набора контрольных функций.

[FDP_ACF] - Все запросы для выполнения операции на объекте, охваченном ПФБ, включая введение объектов в адресное пространство пользователя и стирание объектов.

[FDP_ACI] - Любые изменения или отмена стандартных признаков объекта, включая идентификацию стандартных признаков объекта, которые были изменены или отменены.

[FDP_SAM] - Все попытки модифицировать признаки безопасности, включая идентификацию объекта попытки изменения и новые значения модифицированных признаков безопасности.

[FPT_AMT] - Выполнение тестирования основной машины и результаты проверок.

[FPT_TSA] - Использование относящейся к безопасности административной функции.

в) [назначение: другие контролируемые события]

FAU_GEN.1.2 - ФБ должна в пределах каждой записи аудита фиксировать по крайней мере следующую информацию:

a) Дата и время события, тип события, идентичность субъекта и результат (успех, неудача) события.

б) Для каждого типа контролируемых событий [назначение: другая, относящаяся к аудиту, информация].

FAU_GEN.2.1 - ФБ должна быть способна связать любое контролируемое событие с идентичностью пользователя, который явился причиной события.

FAU_STG.1.1 - ФБ должна обеспечить хранение полученных записей аудита в постоянной трассе контроля.

FAU_PRO.1.1 - ФБ должна разрешать доступ к трассе контроля только уполномоченному администратору.

FAU_MGT.1.1 - ФБ должна обеспечивать уполномоченному администратору возможность создавать, удалять и освобождать трассу контроля.

FAU_SEL.1.1 - ФБ должна быть способна включать или исключать контролируемые события из набора ревизуемых событий на основе следующих признаков:

a) идентичность пользователя;

б) признаки объекта.

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

Требования администрирования

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

FPT_TSA.1.2 - Набор относящихся к безопасности административных функций ФБ должен включать все функции, необходимые чтобы инсталлировать, конфигурировать и управлять ФБ; как минимум, этот набор должен включать [назначение: список административных услуг, которые должны быть минимально обеспечены].

FPT_TSA.1.3 - ФБ должна ограничить возможность выполнять относящиеся к безопасности административные функции специально уполномоченными пользователями.

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

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

Требования управления доступом

FDP_ACC.1.1 - ФБ должна предписать политику дискреционного контроля доступа для:

а) пользователей;

б) субъектов, действующих в защиту пользователей;

в) других именованных субъектов;

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

д) [назначение: операции между субъектами и объектами, охваченными управлением доступа].

FDP_ACF.1.1 - ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках субъекта:

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

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

в) [назначение: тип субъекта: характер (природа) субъекта].

ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках объекта:

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

б) [назначение: тип объекта: характер управляемого объекта].

FDP_ACF.1.2 - ФБ должна предписать следующие правила, чтобы определить, разрешается ли действие между контролируемыми субъектами и объектами:

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

б) если ни идентичность субъекта пользователя, ни любой элемент списка группы субъектов не упомянуты в списке контроля доступа к объекту, то доступ будет предоставляться применением [назначение: правила доступа по умолчанию].

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

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

FDP_ACI.1.1 - ФБ должна предписать политику стандартных (заданных по умолчанию) признаков, чтобы обеспечить разрешающие или стандартные значения для признаков безопасности объекта, которые используются, чтобы предписать ПФБ.

FDP_ACI.1.2 - ФБ должна предоставить возможность спецификации альтернативных начальных значений для отмены стандартных значений после создания объекта.

FDP_SAM.2.1 - ФБ должна предписать следующие правила доступа, чтобы обеспечить уполномоченным пользователям возможность модифицировать признаки объекта:

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

б) [Назначение: дополнительные правила для изменения признаков объекта].

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

Защита ФБ и посредничество ссылок

FPT_SEP.1.1 - ФБ должна для собственного выполнения поддерживать область безопасности , которая защищает ее от вмешательства и подделки недоверенными субъектами:

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

б) Значения ссылок пользовательских или прикладных параметров, относящихся ФБ, должны быть согласованы с адресным пространством и значениями, ожидаемыми ФБ.

в) Разрешения ссылок к объектам (и/или к данным не-ФБ) в качестве параметров ФБ должны быть согласованы с разрешениями, требуемыми ФБ.

г) Ссылки на объекты ФБ, используемые функциями изоляции ФБ, должны быть установлены ФБ.

д) Область ФБ должна иметь все признаки пользователя и объекта.

FPT_SEP.1.2 - ФБ должна предписать разделение между областями безопасности субъектов в ОКФБ.

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

a) ФБ должна обеспечить все ссылки на субъекты, объекты, ресурсы и функции ФБ.

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

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

г) Ссылки, исходящие от привилегированных субъектов, должны быть установлены в соответствии с атрибутами, определенными для этих субъектов.

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

4.2.1.5.2. Требования гарантированности

ОО должен выполнить требования уровня гарантии оценки УГО3.

4.2.1.6. Прикладные замечания

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

  4.2.2. Профиль защиты - коммерческая защита 3 (КЗ3)

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

4.2.2.1. Представление

Коммерческая защита 3 (КЗ3) - защита доступа, основанная на функциях(ролях), аналоге мандатного принципа доступа.

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

КЗ3 обеспечивает мощные механизмы аутентификации и средства администрирования.

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

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

4.2.2.2. Описание объекта оценки

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

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

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

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

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

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

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

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

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

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

4.2.2.3. Безопасность окружающей среды

По сравнению с КЗ1 в КЗ3 специализированы вопросы организационной политики безопасности, расширен список потенциальных угроз. Дополнительно включены:

   УГРОЗА НЕДОСТУПНОСТИ (T.DENY). Пользователям может быть заблокирована возможность доступа к ресурсам ОО.

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

   УГРОЗА РАЗРУШЕНИЯ (T.CRASH). Безопасное состояние ОО может быть поставлено под угрозу в случае аварийного отказа системы.

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

   УГРОЗА ВМЕШАТЕЛЬСТВА (T.TAMPER). Возможно вмешательство в механизмы защиты ОО.

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

   УГРОЗА НЕ ЗАМЕТИТЬ (T.OBSERVE). Могут происходить события в действии ОО, которые ставят под угрозу безопасность ИТ, но которые не могут быть легко отмечены.

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

   УГРОЗА РАЗРАБОТКИ РОЛИ (T.ROLEDEV). Разработка и назначение функций (ролей) пользователя могут быть выполнены способом, который подрывает безопасность.

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

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

В целях безопасности, по сравнению с КЗ1, добавлены:

• ЦЕЛЬ ПРЕДОТВРАЩЕНИЯ ВМЕШАТЕЛЬСТВА (O.TAMPER). ОО должен предотвратить физическое вмешательство в критические к безопасности части.
• ЦЕЛЬ ЭКСПЛУАТАЦИИ (O.OPERATE). ОО должен гарантировать непрерывное правильное действие функций безопасности.
• ЦЕЛЬ ДОСТУПА (O.ACCESS). ОО должен гарантировать непрерывную доступность ресурсов ОО уполномоченным пользователям.
• ЦЕЛЬ НАБЛЮДЕНИЙ (O.OBSERVE). ОО должен гарантировать, что состояние безопасности всегда легко наблюдаемо и управляемо администратором системы.
• ЦЕЛЬ СОХРАНЕНИЯ (O.PRESERV). ОО должен гарантировать, что безопасное состояние сохраняется в случае отказа (сбоя) системы или неоднородности обслуживания.
• ЦЕЛЬ РАЗРАБОТКИ РОЛИ (O.ROLEDEV). Ответственный за ОО должен гарантировать, что разработка и назначение функций выполнены способом, который поддерживает безопасность ИТ.

4.2.2.5. Требования безопасности ОО ИТ

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

4.2.2.5.1. Функциональные требования

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

Таблица 4.2 - Функциональные требования КЗ3

Как видно из таблицы 4.2, функциональные требования КЗ3 по сравнению с КЗ1 значительно расширены и усилены.

4.2.2.5.2. Требования гарантированности

Требования гарантированности для КЗ3 включают уровень гарантии оценки УГО4 и дополнительные компоненты гарантии из Части 3 ОК, а именно: ALC_FLR.2 (Процедуры сообщения о дефекте) и ADO_DEL.2 (Обнаружение модификации).

4.2.3. Профиль защиты межсетевого экрана с фильтром пакета на сетевом/транспортном уровне

4.2.3.1. Представление

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

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

4.2.3.2. Описание объекта оценки

Типичное расположение, включающее межсетевой экран, показано на рис. Типичное расположение МЭ в сети .

Типичное расположение МЭ в сети

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

Маршрутизаторы могут управлять движением на сетевом/транспортном уровне, избирательно разрешая или отвергая движение, основанное на адресе источника/адресата или порта. Главные компьютеры могут управлять движением на прикладном уровне. Данный профиль защиты адресован понятию фильтрующего пакета на сетевом/транспортном уровне. Примером может быть МЭ, который выполняет функции безопасности, основанные на информации, имеющейся в IP и TCP заголовках (например, исходного адреса и порта).

4.2.3.3. Безопасность окружающей среды

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

4.2.3.3.1. Угрозы безопасности

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

а) Угрозы, адресованные ОО

  УГРОЗА ЛОГИЧЕСКОГО ДОСТУПА (T.LACCESS). Неуполномоченный человек может получить логический доступ к МЭ.

  УГРОЗА ОБМАНА (T.SPOOF). Неуполномоченный человек может использовать сетевой адрес для обманного нападения. Общая используемая модель- МЭ обеспечивает управление доступом между одной или более "внешней" (ненадежной) сетью, и одной или более "внутренней" (или "частной", заслуживающей доверия) сетью. Специфическая угроза противостояния - субъект внешней сети, пытающийся подменить субъект внутренней сети.

  УГРОЗА СЕРВИСНОГО ДОСТУПА (T.SACCESS). Неуполномоченный человек может осуществить нападение через услуги. Определенные угрозы зависят от протоколов, позволяющих пройти через МЭ. Обслуживание, которое не может получить доступ снаружи к внутренней сети, не представляет угрозы.

  УГРОЗА ЗАГОЛОВКА (T.SOURCE). Неуполномоченный человек может осуществить нападение направленного типа через заголовок на сетевом уровне. Различные протоколы сетевого уровня предоставляют возможность создателю пакета определять путь, который пакет проходит от источника до адресата. В некоторых реализациях маршрутизации, если маршрутизация источника обозначена в заголовке протокола, функция обработки протокола обойдет любые правила проверки, таким образом предлагая непреднамеренный путь к "туннелю" через МЭ, выполняющий функцию маршрутизации.

  УГРОЗА ПОПЫТКИ (T.PENET). Неуполномоченный человек может быть способен неоднократно пробовать различные варианты нападения против сети, которая будет защищена без персонала, осведомленного, что такие попытки происходят.

  УГРОЗА НЕДОСТАТОЧНОСТИ ОБЗОРА (T.AUDITREV). Может иметь место недостаток обзора контрольного следа (трассы контроля). Даже если данные контроля собраны, но не рассмотрены из-за большого количества или недостатка адекватных инструментальных средств обзора, нападавший может быть способен уйти от обнаружения при выполнении повторных попыток проникновения.

  УГРОЗА РАЗРУШЕНИЯ АУДИТА (T.ACORR). Нападающий может разрушить трассу контроля. Это - двойная угроза. Во-первых, нападавший мог бы непосредственно разрушить трассу контроля, манипулируя через интерфейс в МЭ. Во-вторых, нападавший мог бы разрушить МЭ после выполнения проникновения или попытки проникновения, и если трасса контроля достаточно не защищена, она может быть потеряна, таким образом маскируя действия нападавшего.

  УГРОЗА РАЗРУШЕНИЯ ДАННЫХ (T.DCORR). Нападающий может изменить конфигурацию МЭ и другие относящиеся к безопасности данные. Эта угроза подобна предыдущей, за исключением того, что данные, которые являются целью нападающего - конфигурация МЭ и другие критические данные.

  УГРОЗА ДЕФЕКТА (T.FLAW). Отказы безопасности могут происходить из-за дефектов в МЭ.

б) Угрозы, адресованные операционной окружающей среде

Возможные угрозы, приведенные ниже, не адресованы МЭ.

Им нужно противостоять процедурным способом или принять как потенциальные риски системы.

  УГРОЗА АДМИНИСТРАЦИИ (T.EVIL_ADM). Имеется в виду небрежный, преднамеренно небрежный или враждебный персонал администрации системы. Так как администраторы ответственны за установку правил управления доступом и текущий контроль трассы контроля, они будут способны к простому обходу механизмов безопасности МЭ.

  УГРОЗА СООБЩНИКА (T.INSHARE). Враждебные пользователи защищенной сети ("позади" МЭ) желают совместно использовать информацию с пользователями внешней сети. Эта угроза возникает в случае, когда пользователь внутренних (защищенных) сетей хочет незаконнно послать информацию пользователю внешней сети. Поскольку этот ПЗ МЭ специально разработан, чтобы защитить внутренние сети от внешних сетей и не предназначен для проверки содержания пакета, он будет неэффективен против этих видов нападений.

  УГРОЗА ВНУТРЕННЯЯ (T.INALL). Враждебные пользователи защищенных сетей атакуют механизмы, которые являются частью защищенной сети. Так как МЭ по определению должен защитить пользователей внутренней сети от пользователей, внешних к сети, он не может защищать от нападений, не нацеленных на МЭ.

  УГРОЗА УСЛУГИ (T.SERVICES). Враждебные пользователи на защищенной сети пытаются выполнить сложные нападения через протоколы с более высоким уровнем и услуги. Эти типы нападений нацелены на дефекты в протоколах выше транспортного уровня. МЭ может быть способен полностью отвергнуть сервисные пакеты с определенными услугами. Но если только пакетам позволено проходить, тогда нападения через услуги могут быть возможны, так как МЭ не требует проверки содержания пакета.

4.2.3.3.2. Условия безопасного использования

а) Физические условия

  УСЛОВИЕ БЕЗОПАСНОСТИ (A.SECURE). МЭ и связанные с ним непосредственно пульты физически безопасны, то есть доступ ограничен только разрешенным персоналом.

  УСЛОВИЕ ПРЯМОЙ КОНСОЛИ (A.DIRCON). Уполномоченный персонал (администраторы) взаимодействуют с МЭ только через непосредственно подключенные пульты, то есть никакой сетевой "вход" не разрешается для администраторов.

  УСЛОВИЕ ИЗМЕНЕНИЙ (A.TRANSP). МЭ не требует для функционирования изменения операционного реквизита (например, прикладных программ, аппаратных средств) как на внутренней сети, так и на внешней сети.

б) Условия для персонала

  УСЛОВИЕ НЕИСПОЛЬЗОВАНИЯ (A.NO_USER). МЭ разработан исключительно, чтобы действовать как межсетевой экран и не обеспечивает дополнительные услуги пользователям (например, вход в систему); только администраторы имеют прямой доступ.

  УСЛОВИЕ НЕВРАЖДЕБНОСТИ АДМИНИСТРАЦИИ (A.NO_EVIL). Администраторы приняты невраждебными и выполняют режимы работы правильно.

в) Условия соединений

  УСЛОВИЕ ЕДИНСТВЕННОСТИ (A.SINGL_PT). МЭ - единственное устройство соединения между сетями.

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

а) Цели безопасности ИТ

  ЦЕЛЬ ПОЛУЧЕНИЯ ДОСТУПА (O.ACCESS). МЭ должен обеспечить управляемый доступ между сетями, связанными с ним, разрешая или отвергая поток пакетов.

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

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

Зато понятие механический пользователь применяется. Механический пользователь (идентифицированный как TCP/IP порт на другой машине) представляется в ФБ как субъект или объект. Субъекты и объекты идентифицированы информацией об источнике и адресате, которую содержит пакет. Исключая уполномоченных администраторов, каждая ссылка на пользователя относится к механическому пользователю на TCP/IP порте, как идентифицировано в пакете.

  ЦЕЛЬ АДМИНИСТРИРОВАНИЯ (O.ADMIN). МЭ должен ограничить прямой доступ к нему непосредственно приложенным пультом.

Эта цель ограничивает доступ к МЭ уполномоченным административным персоналом и дает только им способность конфигурировать МЭ посредством приложенного пульта. Эта цель близко связана и поддерживает ЦЕЛЬ АУДИТА.

  ЦЕЛЬ ЗАЩИТЫ (O.PROTECT). МЭ должен быть способен отделить данные, которые требуются для функционирования (данные ФБ), от данных, которые обрабатываются (пакеты).

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

  ЦЕЛЬ АУДИТА (O.AUDIT). МЭ должен гарантировать, что все пользователи могут быть впоследствии подотчетными в своих действиях, относящихся к безопасности.

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

  ЦЕЛЬ ОТСУТСТВИЯ ДЕФЕКТА (O.FLAW). МЭ должен быть разработан так, чтобы не содержать дефекты в проекте или реализации.

Эта цель специально адресована части требований гарантированности данного ПЗ.

б) Цели безопасности не-ИТ

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

  ЦЕЛЬ УСТАНОВКИ (O.INSTALL). Ответственный за МЭ должен гарантировать, что МЭ поставлен, установлен, управляется и эксплуатируется способом, который поддерживает безопасность системы.

Необходимо убедиться, что поставленный МЭ - идентичная копия оцененного. В течение установки все службы безопасности, необходимые для действий поддержания безопасности, должны быть задействованы. Управление и операции должны также поддержать безопасность, например, обучением пользователя и мотивацией. Это близко связано с угрозой враждебного персонала администрации (см. УГРОЗА АДМИНИСТРАЦИИ).

  ЦЕЛЬ ФИЗИЧЕСКОГО ДОСТУПА (O.PACCESS). Ответственный за МЭ должен гарантировать, что физический доступ к нему контролируется.

  ЦЕЛЬ ОБУЧЕНИЯ (O.TRAIN). Ответственный за МЭ должен гарантировать, что администраторы обладают необходимым умением в определении и сопровождении обоснованной политики безопасности и действий.

4.2.3.5. Требования безопасности ОО ИТ

4.2.3.5.1. Функциональные требования

В таблице 4.3 приведена сводка функциональных требований ПЗ МЭ, выраженная в функциональных компонентах ОК.

Таблица 4.3 - Функциональные требования ПЗ МЭ

Требования аудита

FAU_GEN.1.1 - ФБ должна быть способна произвести запись аудита следующих контролируемых событий:

a) запуск и завершение контролируемых процессов;

б) все контролируемые события для минимального уровня аудита, определенные во всех функциональных компонентах, включенных в ПЗ (см. таблицу 4.4);

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

FAU_GEN.1.2 - ФБ должна в пределах каждой записи аудита фиксировать по крайней мере следующую информацию:

a) Дата и время события, тип события, идентичность субъекта и результат (успех, неудача) события.

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

Таблица 4.4 - Контролируемые события

FAU_MGT.1.1 - ФБ должна обеспечить уполномоченному администратору возможность создавать, удалять и освобождать трассу контроля.

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

FAU_PRO.1.1 - ФБ должна ограничить доступ к трассе контроля уполномоченным администратором.

FAU_SAR.1.1 - ФБ должна обеспечивать инструментальные средства обзора аудита, способные просмотреть данные контроля.

FAU_SAR.1.2 - ФБ должна ограничить использование инструментальных средств просмотра аудита уполномоченным администратором.

FAU_SAR.3.1 - ФБ должна обеспечить инструментальные средства просмотра аудита, способные выполнить поиск и сортировку данных контроля, основанные на [назначение: множество критериев с логическими связями, определенное разработчиком ЗБ].

FAU_STG.3.1 - ФБ должна хранить полученные записи аудита в постоянной трассе контроля.

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

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

Требования идентификации и аутентификации

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

FIA_ADA.1.2 - ФБ должна ограничить использование этих функций уполномоченным администратором.

FIA_ADP.1.1 - ФБ должна защитить от несанкционированного наблюдения, модификации и разрушения данные аутентификации, которые хранятся в ОО.

FIA_ATA.1.1 - ФБ должна обеспечить способность инициализации признаков пользователя с обеспеченными стандартными значениями (по умолчанию).

FIA_ATD.1.1 - ФБ должна обеспечить каждому пользователя набор признаков безопасности, необходимых, чтобы предписать ПФБ.

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

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

FIA_USB.1.1 - ФБ должна сопоставить соответствующие признаки безопасности пользователя с субъектами, действующими от имени этого пользователя.

Защита ФБ

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

FPT_SEP.1.1 - ФБ должна поддержать область безопасности для собственного выполнения, которая защищает ее от вмешательства и подделки недоверенными субъектами.

FPT_SEP.1.2 - ФБ должна предписать разделение между областями безопасности в области контроля ФБ.

Требования администрирования

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

FPT_TSA.1.2 - Набор относящихся к безопасности административных функций ФБ должен включать все функции, необходимые, чтобы инсталлировать, конфигурировать и управлять ФБ; как минимум, этот набор должен включать следующие услуги:

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

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

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

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

д) инициализация данных аутентификации пользователя;

е) изменение и отображение параметров управления потоком данных МЭ (параметров управления доступом).

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

FPT_TSA.1.4 - ФБ должна быть способна выделить набор пользователей, уполномоченных для административных функций, из набора всех пользователей МЭ.

FPT_TSM.1.1 - ФБ должна обеспечить уполномоченным администраторам возможность устанавливать и модифицировать следующие параметры конфигурации ФБ:

a) параметры управления доступом;

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

в) правила аудита;

г) [назначение: другие, определенные разработчиком ЗБ].

FPT_TSM.1.2 - ФБ должна обеспечить уполномоченным администраторам возможность:

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

б) управления функцией аудита, включая запуск, завершение;

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

г) просмотра данных аудита;

д) инициализации данных аутентификации пользователя;

е) управления признаками пользователя, субъекта и объекта;

ж) изменения и отображения параметров управления потоком данных МЭ (параметров управления доступом);

з) управления интерфейсами;

и) [назначение: предоставление возможности подключения и отключения набора периферийных устройств, определенных разработчиком ЗБ].

Управление доступом

FDP_ACC.2.1 - ФБ должна предписать политику потока МЭ по субъектам и объектам и всем действиям среди субъектов и объектов, охваченных политикой потока МЭ (например, операция записи).

FDP_ACC.2.2 - ФБ должна гарантировать, что все действия между любым субъектом и любым объектом в пределах области контроля ФБ охвачены политикой потока МЭ.

FDP_ACF.2.1 - ФБ должна предписать политику потока МЭ к объектам, основанную на следующем:

a) сетевая идентификация субъекта и объекта;

б) идентичность субъекта;

в) идентичность объекта;

г) время.

FDP_ACF.2.2 - ФБ должна предписать следующие правила, чтобы определить, разрешается ли действие между управляемыми субъектами и управляемыми объектами:

а) если время находится между периодом, определенным уполномоченным администратором; и

б) субъект или объект имеет внутреннюю сетевую идентификацию, а второй имеет внешнюю сетевую идентификацию; и

в) субъект связан с внутренней сетью и порт, с которым субъект связан, находится во внутренней сети; и

г) доступ субъекта к идентифицированному объекту разрешен; и

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

FDP_ACF.4.1 - ФБ должна предписать политику потока МЭ, чтобы обеспечить способность явно предоставить доступ на основе значений признаков безопасности субъектов и объектов.

FDP_ACF.4.2 - ФБ должна предписать политику потока МЭ, чтобы обеспечить способность явно запретить доступ на основе значений признаков безопасности субъектов и объектов.

FDP_ACI.1.1 - ФБ должна предписать политику потока МЭ, обеспечивающую ограничительные стандартные значения для признаков безопасности объекта, которые используются, чтобы предписать политику потока МЭ.

FDP_ACI.1.2 - ФБ должна позволить спецификацию альтернативных начальных значений для стандартных значений после того, как объект создан.

FDP_ETC.1.1 - ФБ должна предписать политику потока МЭ для информации, выводимой из области контроля ФБ через функцию, которая не обеспечивает признаки безопасности при передаче информации.

FDP_ITC.1.1 - ФБ должна предписать политику потока МЭ для информации, вводимой из-за области контроля ФБ через функцию, которая не обеспечивает надежные признаки безопасности.

FDP_ITC.1.2 - ФБ должна позволить уполномоченному пользователю присваивать признаки безопасности полученной информации.

FDP_ITC.1.3 - ФБ должна обеспечить следующие правила, когда информация, управляемая политикой потока МЭ, вводится снаружи области контроля ФБ:

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

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

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

г) сеть объекта устанавливается по порту, с которым адресат связан.

FDP_SAM.1.1 - ФБ должна предписать политику потока МЭ, чтобы обеспечить уполномоченных администраторов способностью изменить [назначение: параметры управления потоком данных МЭ, определяемые разработчиком ЗБ].

FDP_SAQ.1.1 - ФБ должна предписать политику потока МЭ, чтобы обеспечить уполномоченного администратора способностью запросить значения [назначение: параметры управления потоком данных МЭ, определяемые разработчиком ЗБ].

4.2.3.5.2. Требования гарантированности

Требования гарантированности включают уровень гарантии УГО1.

Профиль Защиты ОК по сути является аналогом классов безопасности "Оранжевой книги", классов защищенности РД ГТК РФ, но базируется на значительно более полной и систематизированной совокупности компонентов требований безопасности. Для сравнения: в ОК - 256 компонентов функциональных требований и требований гарантированности, в TCSEC - 59 компонентов, в РД ГТК для СВТ - 51 компонент, для АС - 67 компонентов.

Примечание: Каждый компонент содержит новые или усиленные требования.

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

 

Заключение

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

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

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

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

ГОСТ Р ... Информационная технология. БЕЗОПАСНОСТЬ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ. Термины и определения.

ГОСТ Р ... Информационная технология. БЕЗОПАСНОСТЬ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ. Концепция оценки безопасности информационной технологии.

ГОСТ Р ... Информационная технология. ОБЩИЕ КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННОЙ ТЕХНОЛОГИИ. Функциональные требования и требования гарантии оценки.

ГОСТ Р ... Информационная технология. ТИПОВОЙ ПРОФИЛЬ ЗАЩИТЫ. Руководство по разработке и регистрации.

ГОСТ Р ... Информационная технология. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ ИЗДЕЛИЙ И СИСТЕМ ИТ. Руководство по разработке и оформлению.

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

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

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

 

Литература

1. Гостехкомиссия России. Руководящий документ. Защита от несанкционированного доступа к информации. Термины и определения. - Москва, 1992.

2. Гостехкомиссия России. Руководящий документ. Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации.- Москва, 1992.

3. Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации.- Москва, 1992.

4. Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации.- Москва, 1992.

5. Гостехкомиссия России. Руководящий документ. Временное положение по организации разработки, изготовления и эксплуатации программных и технических средств защиты информации от НСД в автоматизированных системах и средствах вычислительной техники.- Москва, 1992.

6. Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации.- Москва, 1997.

7. И.Моисеенков. Американская классификация и принципы оценивания безопасности компьютерных систем. КомпьютерПресс N2 1992.

8. В.А.Галатенко. Информационная безопасность - обзор основных положений. Информационный бюллетень JET INFO. 1'-3', Москва, 1996.

9. Д.П.Зегжда, А.М.Ивашко. Как построить защищенную информационную систему. НПО "Мир и семья - 95", Санкт-Петербург, 1997, 286c.

10. Trusted Computer System Evaluation Criteria (TCSEC), US DoD 5200.28-STD, 1983.

11. National Computer Security Center. Trusted Network Interpretation. - NCSC-TG-005,1987.

12. Security Architecture for Open Systems Interconnection for CCITT Applications. Recommendation X.800. - CCITT, Geneva, 1991.

13. Information Technology Security Evaluation Criteria (ITSEC). Harmonised Criteria of France - Germany - the Netherlands - the United Kingdom.- Department of Trade and Industry, London, 1991.

14. Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), Version 3.0, Canadian System Security Centre, Communications Security Establishment, Government of Canada, 1993.

15. Federal Criteria for Information Technology Security (FC), Draft Version 1.0, (Volumes I and II), jointly published by the National Institute of Standards and Technology and the National Security Agency, US Government, 1993.

16. Common Criteria for Information Technology Security Evaluation (CCEB). Version 1.0. 96.01.31.