Безопасность

Предисловие

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

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.
Сводка уровней гарантии оценки

Все права защищены ® 2005-2011       Карта сайта: 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23