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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Класс

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

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

Семейство

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

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

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

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

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

Компонент

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

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

Элемент

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Представление и общая модель Содержание Требования гарантии безопасности
Copyright ╘ 1993-2000, Jet Infosystems