ГОСТ Р ИСО/МЭК 15408-2-2008. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности

(утв. Приказом Ростехрегулирования от 18.12.2008 № 520-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р ИСО/МЭК 15408-2-2002"]:::rst
  click n0 "https://bukva.ai/docs/gost-r-isomek-15408-2-2002" "ГОСТ Р ИСО/МЭК 15408-2-2002. Государственный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки... (принят и введ"
  n1["ГОСТ Р ИСО/МЭК 15408-2-2008"]:::rst
  click n1 "https://bukva.ai/docs/gost-r-isomek-15408-2-2008" "ГОСТ Р ИСО/МЭК 15408-2-2008. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные "
  n2["ГОСТ Р ИСО/МЭК 15408-2-2013"]:::doc
  click n2 "https://bukva.ai/docs/gost-r-isomek-15408-2-2013" "ГОСТ Р ИСО/МЭК 15408-2-2013. Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности... (утв"
  n1 --> n2
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

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

ЧАСТЬ 2

ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ БЕЗОПАСНОСТИ

Information technology. Security techniques. Evaluation criteria for IT security. Part 2. Security functional requirements

ISO/IEC 15408-2:2005

Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional requirements (IDT)

ГОСТ Р ИСО/МЭК 15408-2-2008

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения».

Сведения о стандарте

1. Подготовлен Обществом с ограниченной ответственностью «Центр безопасности информации» (ООО «ЦБИ»), Федеральным государственным учреждением «4 Центральный научно-исследовательский институт Министерства обороны России» (ФГУ «4 ЦНИИ Минобороны России»), Федеральным государственным унитарным предприятием «Научно-технический и сертификационный центр по комплексной защите информации» ФГУП Центр «Атомзащитаинформ», Федеральным государственным унитарным предприятием «Центральный научно-исследовательский институт управления, экономики и информации Росатома» (ФГУП «ЦНИИАТОМИНФОРМ») при участии экспертов Международной рабочей группы по Общим критериям на основе собственного аутентичного перевода стандарта, указанного в пункте 4.

2. Внесен Техническим комитетом по стандартизации ТК 362 «Защита информации».

3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2008 г. № 520-ст.

4. Настоящий стандарт идентичен международному стандарту ИСО/МЭК 15408-2:2005 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности» (ISO/IEC 15408-2:2005 «Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional requirements»).

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

5. Взамен ГОСТ Р ИСО/МЭК 15408-2-2002.

Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет.

Введение

Международный стандарт ИСО/МЭК 15408:2005 подготовлен Совместным техническим комитетом ИСО/МЭК СТК 1 «Информационные технологии», Подкомитет ПК 27 «Методы и средства обеспечения безопасности ИТ». Идентичный ИСО/МЭК 15408:2005 текст опубликован организациями — спонсорами проекта «Общие критерии» как «Общие критерии оценки безопасности информационных технологий», версия 2.3 (ОК, версия 2.3).

Второе издание ИСО/МЭК 15408:2005 отменяет и заменяет первое издание (ИСО/МЭК 15408:1999), которое подверглось технической переработке.

ИСО/МЭК 15408 под общим наименованием «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий» состоит из следующих частей:

• часть 1. Введение и общая модель;
• часть 2. Функциональные требования безопасности;
• часть 3. Требования доверия к безопасности.

Если имеют в виду все три части стандарта, используют обозначение ИСО/МЭК 15408.

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

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

Аудитория для данной части ИСО/МЭК 15408 включает в себя потребителей, разработчиков и оценщиков безопасных ИТ-систем и продуктов. Дополнительная информация о потенциальных пользователях ИСО/МЭК 15408 и использовании ИСО/МЭК 15408 группами, которые включают в себя потенциальных пользователей, представлена в ИСО/МЭК 15408-1, раздел 4. Эти группы могут использовать данную часть ИСО/МЭК 15408 следующим образом:

a) потребители используют данную часть ИСО/МЭК 15408, выбирая компоненты, чтобы сформулировать функциональные требования для удовлетворения целей безопасности, приведенных в ПЗ или ЗБ. Более подробная информация о взаимосвязях требований безопасности и целей безопасности приведена в ИСО/МЭК 15408-1, подраздел 5.3;

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

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

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

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

2. Нормативные ссылки

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

ИСО/МЭК 15408-1:2005. Информационная технология — Методы и средства обеспечения безопасности — Критерии оценки безопасности информационных технологий — Часть 1: Введение и общая модель.

3. Термины, определения, обозначения и сокращения

В настоящем стандарте применены термины, обозначения и сокращения по ИСО/МЭК 15408-1.

4. Краткий обзор

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

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

Так как знания и потребности пользователей могут меняться, функциональные требования, представленные в настоящем стандарте, нуждаются в дальнейшем сопровождении. Предполагается, что некоторые разработчики ПЗ/ЗБ могут иметь потребности в безопасности, не охваченные компонентами функциональных требований, представленными в настоящем стандарте. В данном случае разработчик ПЗ/ЗБ может предпочесть использование нестандартных функциональных требований (так называемую «расширяемость») в соответствии с ИСО/МЭК 15408-1, приложения A и B.

4.1 Структура данной части ИСО/МЭК 15408

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

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

В разделах 7 - 17 приведено описание функциональных классов.

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

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

ИСО/МЭК 15408-1 содержит следующую информацию, необходимую разработчикам ПЗ или ЗБ:

ИСО/МЭК 15408-1, раздел 2, определяет термины, используемые в ИСО/МЭК 15408;

ИСО/МЭК 15408-1, приложение A, определяет структуру профилей защиты;

ИСО/МЭК 15408-1, приложение B, определяет структуру заданий по безопасности;

библиография необходимых документов приведена в элементе «Библиография» ИСО/МЭК 15408-1.

5. Парадигма функциональных требований

В данном разделе приведена парадигма функциональных требований безопасности настоящего стандарта. Некоторые ключевые понятия парадигмы показаны на рисунках 1 и 2. Описаны и другие, не показанные на рисунках 1 и 2, ключевые понятия. Рассматриваемые ключевые понятия выделены полужирным курсивом. Определения терминов, приведенные в ИСО/МЭК 15408-1, раздел 2, в данном разделе не изменяются и не заменяются.

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

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

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

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

&Монитор обращений& — это концепция абстрактной машины, которая осуществляет политику управления доступом ОО. &Механизм проверки правомочности обращений& — реализация концепции монитора обращений, обладающая следующими свойствами: защищенностью от проникновения, постоянной готовностью, простотой, достаточной для проведения исчерпывающего анализа и тестирования. ФБО могут состоять из механизма проверки правомочности обращений и/или других функций безопасности, необходимых для эксплуатации ОО.

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

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

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

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

a) политика безопасности «удаленного доверенного продукта ИТ» и ПБО рассматриваемого ОО скоординированы и оценены в административном порядке. Обмен информацией в этом случае назван &передачей между ФБО&, поскольку он осуществляется между ФБО различных доверенных продуктов;

b) удаленный продукт ИТ, обозначенный на рисунке 2 как «недоверенный продукт ИТ», не был оценен, поэтому его политика безопасности неизвестна. Обмен информацией в этом случае назван &передачей за пределы области действия ФБО&, так как этот удаленный продукт ИТ не имеет ФБО (или характеристики его политики безопасности неизвестны).

Совокупность взаимодействий, которые могут происходить с ОО или в пределах ОО и подчинены правилам ПБО, относится к &области действия функций безопасности (ОДФ)&. ОДФ включает в себя определенную совокупность взаимодействий в пределах ОО с использованием понятий «субъекты», «объекты» и «операции», но не обязательно охватывает все ресурсы ОО.

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

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

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

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

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

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

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

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

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

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

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

В настоящем стандарте рассматривается осуществление ПБО для субъектов перечисленных выше типов.

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

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

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

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

Рисунок 3. Связь между данными пользователей и данными ФБО

Выделяются ПФБ, которые применяются при защите данных, такие как &ПФБ управления доступом& и &ПФБ управления информационными потоками&. Действия механизмов, реализующих ПФБ управления доступом, основаны на атрибутах субъектов, объектов и операций в пределах области действия. Эти атрибуты используются в совокупности правил, управляющих операциями, которые субъектам разрешено выполнять на объектах.

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

Два специфических типа данных ФБО, рассматриваемых в настоящем стандарте, могут (но необязательно) совпадать. Это &аутентификационные данные& и &секреты&.

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

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

Следовательно, некоторые (но не все) аутентификационные данные необходимо хранить в секрете, и некоторые (но не все) секреты используют как аутентификационные данные. Взаимосвязь секретов и аутентификационных данных представлена на рисунке 4. На рисунке 4 указаны типы данных, которые часто относят к аутентификационным данным и секретам.

6. Функциональные компоненты безопасности

6.1. Краткий обзор

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

6.1.1 Структура класса

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

Рисунок 5. Структура функционального класса

6.1.1.1 Имя класса

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

6.1.1.2 Представление класса

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

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

6.1.2 Структура семейства

Структура функционального семейства приведена на рисунке 6.

6.1.2.1 Имя семейства

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

6.1.2.2 Характеристика семейства

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

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

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

6.1.2.3 Ранжирование компонентов

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

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

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

Описания семейств содержат графическое представление иерархии компонентов, рассмотренное в 6.2.

6.1.2.4 Управление

Требования управления содержат информацию для разработчиков ПЗ/ЗБ, учитываемую при определении действий по управлению для данного компонента. Требования управления детализированы в компонентах класса «Управление безопасностью» (FMT).

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

6.1.2.5 Аудит

Требования аудита содержат события, потенциально подвергаемые аудиту, для их отбора разработчиками ПЗ/ЗБ при условии включения в ПЗ/ЗБ требований из класса FAU «Аудит безопасности». Эти требования включают в себя события, относящиеся к безопасности, применительно к различным уровням детализации, поддерживаемым компонентами семейства FAU_GEN «Генерация данных аудита безопасности». Например, запись аудита какого-либо механизма безопасности может включать в себя на разных уровнях детализации действия, которые раскрываются в следующих терминах:

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

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

Правила управления аудитом более подробно объяснены в классе FAU «Аудит безопасности».

6.1.3 Структура компонента

Рисунок 7. Структура функционального компонента

6.1.3.1 Идентификация компонента

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

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

6.1.3.2 Функциональные элементы

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

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

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

Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2 читается следующим образом: F — функциональное требование, DP — класс «Защита данных пользователя», _IFF — семейство «Функции управления информационными потоками», .4 — четвертый компонент «Частичное устранение неразрешенных информационных потоков», .2 — второй элемент компонента.

6.1.3.3 Зависимости

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

Каждый функциональный компонент содержит полный список зависимостей от других функциональных компонентов и компонентов доверия. Для некоторых компонентов указано, что зависимостей нет. Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов. Список, приведенный в компоненте, показывает прямые зависимости, то есть содержит ссылки только на функциональные компоненты, заведомо необходимые для обеспечения выполнения рассматриваемого компонента. Косвенные зависимости, определяемые собственными зависимостями компонентов из списка, показаны в Приложении A. В некоторых случаях зависимость выбирают из нескольких предлагаемых функциональных компонентов, причем каждый из них достаточен для удовлетворения зависимости (см., например, FDP_UIT.1 «Целостность передаваемых данных»).

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

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

6.2. Каталог компонентов

Расположение компонентов в настоящем стандарте не отражает какую-либо формальную таксономию.

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

В описании каждого функционального компонента приведены его зависимости от других компонентов.

Пример представления таксономии класса и иерархии компонентов в его семействах приведен на рисунке 8.

             ┌────────────────────────┐
             │       Имя класса       │
             └───────┬────────────────┘
                     │
<pre class="legal-pre">                     │  ┌─────────────────┐   ┌─┐ ┌─┐ ┌─┐
                     ├──┤   Семейство 1   ├───┤1├─┤2├─┤3│
                     │  └─────────────────┘   └─┘ └─┘ └─┘
                     │                        ┌─┐
                     │                      ┌─┤1│
                     │  ┌─────────────────┐ │ └─┘
                     ├──┤   Семейство 2   ├─┤
                     │  └─────────────────┘ │ ┌─┐ ┌─┐
                     │                      └─┤2├─┤3│
                     │                        └─┘ └─┘
                     │                              ┌─┐
                     │                            ┌─┤2├─┐
                     │  ┌─────────────────┐   ┌─┐ │ └─┘ │ ┌─┐
                     └──┤   Семейство 3   ├───┤1├─┤ ┌─┐ ├─┤4│
                        └─────────────────┘   └─┘ └─┤3├─┘ └─┘</pre>
                                                    └─┘

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

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

В семействе 3 компоненты 2, 3 и 4 иерархичны компоненту 1. Компоненты 2 и 3 иерархичны компоненту 1, но несопоставимы по иерархии между собой. Компонент 4 иерархичен компонентам 2 и 3.

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

6.2.1 Выделение изменений в компоненте

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

7. Класс FAU. Аудит безопасности

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

             ┌───────────────────────────────┐   ┌─┐
             │FAU_ARP Автоматическая реакция ├───┤1│
<pre class="legal-pre">             │      аудита безопасности      │   │ │
             └───────────────────────────────┘   └─┘</pre>
                                                 ┌─┐
                                               ┌─┤1│
             ┌───────────────────────────────┐ │ └─┘
             │FAU_GEN Генерация данных аудита├─┤
             │          безопасности         │ │ ┌─┐
             └───────────────────────────────┘ └─┤2│
                                                 └─┘
                                                       ┌─┐
<pre class="legal-pre">             ┌───────────────────────────────┐   ┌─┐ ┌─┤2│
             │      FAU_SAA Анализ аудита    ├───┤1├─┤ └─┘
             │          безопасности         │   └─┘ │ ┌─┐  ┌─┐
             └───────────────────────────────┘       └─┤3├──┤4│
                                                       └─┘  └─┘</pre>
                                                 ┌─┐
                                               ┌─┤1│
<pre class="legal-pre">             ┌───────────────────────────────┐ │ └─┘  ┌─┐
             │    FAU_SAR Просмотр аудита    ├─┼──────┤2│
             │        безопасности           │ │ ┌─┐  └─┘</pre>
             └───────────────────────────────┘ └─┤3│
                                                 └─┘
<pre class="legal-pre">             ┌───────────────────────────────┐   ┌─┐
             │ FAU_SEL Выбор событий аудита  ├───┤1│
             │         безопасности          │   └─┘</pre>
             └───────────────────────────────┘
                                                 ┌─┐  ┌─┐
                                               ┌─┤1├──┤2│
<pre class="legal-pre">             ┌───────────────────────────────┐ │ └─┘  └─┘
             │FAU_STG Хранение данных аудита ├─┤ ┌─┐  ┌─┐
             │         безопасности          │ └─┤3├──┤4│
             └───────────────────────────────┘   └─┘  └─┘</pre>

Рисунок 9. Декомпозиция класса FAU "Аудит безопасности"

7.1. Автоматическая реакция аудита безопасности (FAU_ARP)

7.1.1. Характеристика семейства
Семейство FAU_ARP определяет реакцию на обнаружение событий, указывающих на возможное нарушение безопасности.

7.1.2. Ранжирование компонентов

<pre class="legal-pre">                  ┌──────────────────────────────┐   ┌─┐
                  │    FAU_ARP Автоматическая    ├───┤1│
                  │ реакция аудита безопасности  │   │ │
                  └──────────────────────────────┘   └─┘</pre>

В FAU_ARP.1 «Сигналы нарушения безопасности» ФБО должны предпринимать действия в случае обнаружения возможного нарушения безопасности.

7.1.3 Управление: FAU_ARP.1

Для функций управления из класса FMT могут рассматриваться следующие действия.

a) Управление действиями (добавление, удаление или модификация).

7.1.4 Аудит: FAU_ARP.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: действия, предпринимаемые в ответ на ожидаемые нарушения безопасности.

7.1.5 FAU_ARP.1 Сигналы нарушения безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_SAA.1 Анализ потенциального нарушения

7.1.5.1 FAU_ARP.1.1

#ФБО должны предпринять [назначение: &список наименее разрушительных действий&] при обнаружении возможного нарушения безопасности#.

7.2. Генерация данных аудита безопасности (FAU_GEN)

7.2.1 Характеристика семейства

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

7.2.2 Ранжирование компонентов

FAU_GEN.1 «Генерация данных аудита» определяет уровень событий, потенциально подвергаемых аудиту, и состав данных, которые должны быть зарегистрированы в каждой записи.

В FAU_GEN.2 «Ассоциация идентификатора пользователя» ФБО должны ассоциировать события, потенциально подвергаемые аудиту, и личные идентификаторы пользователей.

7.2.3 Управление: FAU_GEN.1, FAU_GEN.2

Действия по управлению не предусмотрены.

7.2.4 Аудит: FAU_GEN.1, FAU_GEN.2

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

7.2.5 FAU_GEN.1 Генерация данных аудита

Иерархический для: нет подчиненных компонентов.

Зависимости: FPT_STM.1 Надежные метки времени

7.2.5.1 FAU_GEN.1.1

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

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

b) все события, потенциально подвергаемые аудиту, на [выбор (выбрать одно из): &минимальный, базовый, детализированный, неопределенный&] уровне аудита;

c) [назначение: &другие специально определенные события, потенциально подвергаемые аудиту&]#.

7.2.5.2 FAU_GEN.1.2

#ФБО должны регистрировать в каждой записи аудита, по меньшей мере, следующую информацию:

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

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

7.2.6 FAU_GEN.2 Ассоциация идентификатора пользователя

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_GEN.1 Генерация данных аудита

FIA_UID.1 Выбор момента идентификации

7.2.6.1 FAU_GEN.2.1

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

7.3. Анализ аудита безопасности (FAU_SAA)

7.3.1 Характеристика семейства

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

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

7.3.2 Ранжирование компонентов

                                                       ┌─┐
                                                     ┌─┤2│
            ┌──────────────────────────────────┐ ┌─┐ │ └─┘
            │FAU_SAA Анализ аудита безопасности├─┤1├─┤
            └──────────────────────────────────┘ └─┘ │ ┌─┐ ┌─┐
                                                     └─┤3├─┤4│
                                                       └─┘ └─┘

В FAU_SAA.1 «Анализ потенциального нарушения» требуется базовый порог обнаружения на основе установленного набора правил.

В FAU_SAA.2 «Выявление аномалии, основанное на профиле» ФБО поддерживают отдельные профили использования системы, где профиль представляет собой шаблоны предыстории использования, выполнявшиеся участниками целевой группы профиля. Целевая группа профиля может включать в себя одного или нескольких участников (например, отдельный пользователь; пользователи, совместно использующие общий идентификатор или общие учетные данные; пользователи, которым назначена одна роль; все пользователи системы или сетевого узла), которые взаимодействуют с ФБО. Каждому участнику целевой группы профиля назначается индивидуальный рейтинг подозрительной активности, который показывает, насколько текущие показатели действий участника соответствуют установленным шаблонам использования, представленным в профиле. Этот анализ может проводиться во время функционирования ОО или при анализе данных аудита в пакетном режиме.

В FAU_SAA.3 «Простая эвристика атаки» ФБО должны быть способны обнаружить возникновение характерных событий, которые свидетельствуют о значительной угрозе осуществлению ПБО. Этот поиск характерных событий может происходить в режиме реального времени или при анализе данных аудита в пакетном режиме.

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

7.3.3 Управление: FAU_SAA.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) сопровождение (добавление, модификация, удаление) правил из набора правил.

7.3.4 Управление: FAU_SAA.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

7.3.5 Управление: FAU_SAA.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

7.3.6 Управление: FAU_SAA.4

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

b) сопровождение (удаление, модификация, добавление) набора последовательностей событий системы.

7.3.7 Аудит: FAU_SAA.1, FAU_SAA.2, FAU_SAA.3, FAU_SAA.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: подключение и отключение любого из механизмов анализа;

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

7.3.8 FAU_SAA.1 Анализ потенциального нарушения

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_GEN.1 Генерация данных аудита

7.3.8.1 FAU_SAA.1.1

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

7.3.8.2 FAU_SAA.1.2

#ФБО должны осуществлять следующие правила при мониторинге событий, подвергающихся аудиту:

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

b) [назначение: &другие правила&]#.

7.3.9 FAU_SAA.2 Выявление аномалии, основанное на профиле

Иерархический для: FAU_SAA.1 Анализ потенциального нарушения

Зависимости: FIA_UID.1 Выбор момента идентификации

7.3.9.1 FAU_SAA.2.1

#ФБО должны быть способны сопровождать профили использования системы, где каждый отдельный профиль представляет известные шаблоны предыстории использования, выполнявшиеся участниками [назначение: &спецификация целевой группы профиля&]#.

7.3.9.2 FAU_SAA.2.2

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

7.3.9.3 FAU_SAA.2.3

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

7.3.10 FAU_SAA.3 Простая эвристика атаки

Иерархический для: FAU_SAA.1 Анализ потенциального нарушения

Зависимости: нет зависимостей.

7.3.10.1 FAU_SAA.3.1

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

7.3.10.2 FAU_SAA.3.2

#ФБО должны быть способны сравнивать характерные события с записью показателей функционирования системы, полученных при обработке [назначение: &информация, используемая для определения показателей функционирования системы&]#.

7.3.10.3 FAU_SAA.3.3

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

7.3.11 FAU_SAA.4 Сложная эвристика атаки

Иерархический для: FAU_SAA.3 Простая эвристика атаки

Зависимости: нет зависимостей.

7.3.11.1 FAU_SAA.4.1

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

7.3.11.2 FAU_SAA.4.2

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

7.3.11.3 FAU_SAA.4.3

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

7.4. Просмотр аудита безопасности (FAU_SAR)

7.4.1 Характеристика семейства

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

7.4.2 Ранжирование компонентов

                                                ┌─┐
                                              ┌─┤1│
                    ┌───────────────────────┐ │ └─┘
<pre class="legal-pre">                    │FAU_SAR Просмотр аудита│ │     ┌─┐
                    │      безопасности     ├─┼─────┤2│
                    │                       │ │     └─┘</pre>
                    └───────────────────────┘ │ ┌─┐
                                              └─┤3│
                                                └─┘

FAU_SAR.1 «Просмотр аудита» предоставляет возможность читать информацию из записей аудита.

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

FAU_SAR.3 «Выборочный просмотр аудита» содержит требование отбора данных аудита средствами просмотра аудита на основе критериев просмотра.

7.4.3 Управление: FAU_SAR.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

7.4.4 Управление: FAU_SAR.2, FAU_SAR.3

Действия по управлению не предусмотрены.

7.4.5 Аудит: FAU_SAR.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: чтение информации из записей аудита.

7.4.6 Аудит: FAU_SAR.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: неуспешные попытки читать информацию из записей аудита.

7.4.7 Аудит: FAU_SAR.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) детализированный: параметры, используемые при просмотре.

7.4.8 FAU_SAR.1 Просмотр аудита

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_GEN.1 Генерация данных аудита

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

7.4.8.1 FAU_SAR.1.1

#ФБО должны предоставлять [назначение: &уполномоченные пользователи&] возможность читать [назначение: &список информации аудита&] из записей аудита#.

7.4.8.2 FAU_SAR.1.2

#ФБО должны предоставлять записи аудита в виде, позволяющем пользователю воспринимать содержащуюся в них информацию#.

7.4.9 FAU_SAR.2 Ограниченный просмотр аудита

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_SAR.1 Просмотр аудита

7.4.9.1 FAU_SAR.2.1

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

7.4.10 FAU_SAR.3 Выборочный просмотр аудита

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_SAR.1 Просмотр аудита

7.4.10.1 FAU_SAR.3.1

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

7.5. Выбор событий аудита безопасности (FAU_SEL)

7.5.1 Характеристика семейства

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

7.5.2 Ранжирование компонентов

                   ┌───────────────────────────────┐ ┌─┐
<pre class="legal-pre">                   │    FAU_SEL Выбор событий      ├─┤1│
                   │      аудита безопасности      │ │ │</pre>
                   └───────────────────────────────┘ └─┘

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

7.5.3 Управление: FAU_SEL.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) сопровождение прав просмотра/модификации событий аудита.

7.5.4 Аудит: FAU_SEL.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

7.5.5 FAU_SEL.1 Избирательный аудит

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_GEN.1 Генерация данных аудита

FMT_MTD.1 Управление данными ФБО

7.5.5.1 FAU_SEL.1.1

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

a) [выбор: &идентификатор объекта, идентификатор пользователя, идентификатор субъекта, идентификатор узла сети, тип события&];

b) [назначение: &список дополнительных атрибутов, на которых основана избирательность аудита&]#.

7.6. Хранение данных аудита безопасности (FAU_STG)

7.6.1 Характеристика семейства

Семейство FAU_STG определяет требования, при выполнении которых ФБО способны создавать и сопровождать журнал аудита безопасности.

7.6.2 Ранжирование компонентов

                                                    ┌─┐ ┌─┐
                                                  ┌─┤1├─┤2│
                 ┌──────────────────────────────┐ │ └─┘ └─┘
                 │FAU_STG Хранение данных аудита├─┤
                 │         безопасности         │ │ ┌─┐ ┌─┐
                 └──────────────────────────────┘ └─┤3├─┤4│
                                                    └─┘ └─┘

В FAU_STG.1 «Защищенное хранение журнала аудита» содержатся требования защиты журнала аудита от несанкционированного удаления и/или модификации.

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

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

FAU_STG.4 «Предотвращение потери данных аудита» определяет действия при переполнении журнала аудита.

7.6.3 Управление: FAU_STG.1

Действия по управлению не предусмотрены.

7.6.4 Управление: FAU_STG.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

7.6.5 Управление: FAU_STG.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) отслеживание порога заполнения;

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

7.6.6 Управление: FAU_STG.4

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

7.6.7 Аудит: FAU_STG.1, FAU_STG.2

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

7.6.8 Аудит: FAU_STG.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: предпринимаемые действия после превышения порога заполнения.

7.6.9 Аудит: FAU_STG.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: предпринимаемые действия при сбое хранения журнала аудита.

7.6.10 FAU_STG.1 Защищенное хранение журнала аудита

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_GEN.1 Генерация данных аудита

7.6.10.1 FAU_STG.1.1

#ФБО должны защищать хранимые записи аудита от несанкционированного удаления#.

7.6.10.2 FAU_STG.1.2

#ФБО должны быть способны [выбор (выбрать одно из): &предотвращать, выявлять&] несанкционированную модификацию хранимых записей аудита в журнале аудита#.

7.6.11 FAU_STG.2 Гарантии доступности данных аудита

Иерархический для: FAU_STG.1 Защищенное хранение журнала аудита.

Зависимости: FAU_GEN.1 Генерация данных аудита

7.6.11.1 FAU_STG.2.1

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

7.6.11.2 FAU_STG.2.2

ФБО должны быть способны [выбор (выбрать одно из): предотвращать, выявлять] несанкционированную модификацию хранимых записей аудита в #журнале аудита#.

7.6.11.3 FAU_STG.2.3

#ФБО должны обеспечивать поддержку [назначение: &показатель сохранности записей аудита&] при наступлении следующих событий: [выбор: &переполнение журнала аудита, сбой, атака&]#.

7.6.12 FAU_STG.3 Действия в случае возможной потери данных аудита

Иерархический для: нет подчиненных компонентов.

Зависимости: FAU_STG.1 Защищенное хранение журнала аудита

7.6.12.1 FAU_STG.3.1

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

7.6.13 FAU_STG.4 Предотвращение потери данных аудита

Иерархический для: FAU_STG.3 Действия в случае возможной потери данных аудита

Зависимости: FAU_STG.1 Защищенное хранение журнала аудита

7.6.13.1 FAU_STG.4.1

#ФБО должны [выбор (выбрать одно из): &«игнорировать события, подвергающиеся аудиту», «предотвращать события, подвергающиеся аудиту, исключая предпринимаемые уполномоченным пользователем со специальными правами», «записывать поверх самых старых хранимых записей аудита»& и [назначение: &другие действия, которые нужно предпринимать в случае возможного сбоя хранения журнала аудита&] при переполнении журнала аудита#.

8. Класс FCO. Связь

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

               ┌───────────────────────────────────┐ ┌─┐ ┌─┐
               │FCO_NRO Неотказуемость отправления ├─┤1├─┤2│
               └───────────────────────────────────┘ └─┘ └─┘
               ┌───────────────────────────────────┐ ┌─┐ ┌─┐
               │  FCO_NRR Неотказуемость получения ├─┤1├─┤2│
               └───────────────────────────────────┘ └─┘ └─┘

Рисунок 16. Декомпозиция класса FCO "Связь"

8.1. Неотказуемость отправления (FCO_NRO)

8.1.1. Характеристика семейства
Семейство FCO_NRO обеспечивает невозможность отрицания отправителем информации факта ее отправления. Семейство FCO_NRO содержит требование, чтобы ФБО обеспечили метод предоставления субъекту-получателю свидетельства отправления информации. Это свидетельство может быть затем верифицировано этим субъектом или другими субъектами.

8.1.2. Ранжирование компонентов

                 ┌───────────────────────────────┐ ┌─┐ ┌─┐
<pre class="legal-pre">                 │     FCO_NRO Неотказуемость    ├─┤1├─┤2│
                 │           отправления         │ │ │ │ │</pre>
                 └───────────────────────────────┘ └─┘ └─┘

FCO_NRO.1 «Избирательное доказательство отправления» содержит требование, чтобы ФБО предоставили субъектам возможность запросить свидетельство отправления информации.

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

8.1.3 Управление: FCO_NRO.1, FCO_NRO.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление изменениями типов и полей информации, атрибутов отправителей информации и получателей свидетельств.

8.1.4 Аудит: FCO_NRO.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: идентификатор пользователя, который запросил генерацию свидетельства отправления;

b) минимальный: обращение к функции неотказуемости;

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

d) детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

8.1.5 Аудит: FCO_NRO.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обращение к функции неотказуемости;

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

c) детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

8.1.6 FCO_NRO.1 Избирательное доказательство отправления

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UID.1 Выбор момента идентификации

8.1.6.1 FCO_NRO.1.1

#ФБО должны быть способны генерировать свидетельство отправления передаваемой [назначение: &список типов информации&] при запросе [выбор: &отправитель, получатель [назначение: список третьих лиц]&]#.

8.1.6.2 FCO_NRO.1.2

#ФБО должны быть способны связывать [назначение: &список атрибутов&] отправителя информации и [назначение: &список информационных полей&] информации, к которой прилагается свидетельство#.

8.1.6.3 FCO_NRO.1.3

#ФБО должны предоставлять возможность верифицировать свидетельство отправления информации [выбор: &отправитель, получатель [назначение: список третьих лиц]&] при установленных [назначение: &ограничения на свидетельство отправления&]#.

8.1.7 FCO_NRO.2 Принудительное доказательство отправления

Иерархический для: FCO_NRO.1 Избирательное доказательство отправления

Зависимости: FIA_UID.1 Выбор момента идентификации

8.1.7.1 FCO_NRO.2.1

ФБО должны #всегда осуществлять генерацию# свидетельства отправления передаваемой [назначение: список типов информации].

8.1.7.2 FCO_NRO.2.2

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

8.1.7.3 FCO_NRO.2.3

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

8.2. Неотказуемость получения (FCO_NRR)

8.2.1 Характеристика семейства

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

8.2.2 Ранжирование компонентов

                ┌─────────────────────────────────┐ ┌─┐ ┌─┐
                │FCO_NRR Неотказуемость получения ├─┤1├─┤2│
                └─────────────────────────────────┘ └─┘ └─┘

FCO_NRR.1 «Избирательное доказательство получения» содержит требование, чтобы ФБО предоставили субъектам возможность запросить свидетельство получения информации.

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

8.2.3 Управление: FCO_NRR.1, FCO_NRR.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление изменениями типов и полей информации, атрибутов отправителей информации и других получателей свидетельств.

8.2.4 Аудит: FCO_NRR.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

b) минимальный: обращение к функции неотказуемости;

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

d) детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

8.2.5 Аудит: FCO_NRR.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обращение к функции неотказуемости;

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

c) детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

8.2.6 FCO_NRR.1 Избирательное доказательство получения

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UID.1 Выбор момента идентификации

8.2.6.1 FCO_NRR.1.1

#ФБО должны быть способны генерировать свидетельство получения принятой [назначение: &список типов информации&] при запросе [выбор: &отправитель, получатель [назначение: список третьих лиц]&]#.

8.2.6.2 FCO_NRR.1.2

#ФБО должны быть способны связывать [назначение: &список атрибутов&] получателя информации и [назначение: &список информационных полей&] информации, к которой прилагается свидетельство#.

8.2.6.3 FCO_NRR.1.3

#ФБО должны предоставлять возможность верифицировать свидетельство получения информации [выбор: &отправитель, получатель [назначение: список третьих лиц]&] при установленных [назначение: &ограничения на свидетельство отправления&]#.

8.2.7 FCO_NRR.2 Принудительное доказательство получения

Иерархический для: FCO_NRR.1 Избирательное доказательство получения

Зависимости: FIA_UID.1 Выбор момента идентификации

8.2.7.1 FCO_NRR.2.1

ФБО должны #осуществлять генерацию# свидетельства получения принятой [назначение: список типов информации].

8.2.7.2 FCO_NRR.2.2

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

8.2.7.3 FCO_NRR.2.3

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

9. Класс FCS. Криптографическая поддержка

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

Класс FCS «Криптографическая поддержка» состоит из двух семейств: FCS_CKM «Управление криптографическими ключами» и FCS_COP «Криптографические операции». В семействе FCS_CKM «Управление криптографическими ключами» рассмотрены аспекты управления криптографическими ключами, тогда как в семействе FCS_COP «Криптографические операции» рассмотрено практическое применение этих криптографических ключей.

                                                      ┌─┐
                                                    ┌─┤1│
                                                    │ └─┘
<pre class="legal-pre">               ┌──────────────────────────────────┐ │     ┌─┐
               │        FCS_CKM Управление        ├─┼─────┤2│
               │    криптографическими ключами    │ │ ┌─┐ └─┘</pre>
               └──────────────────────────────────┘ ├─┤3│
                                                    │ └─┘ ┌─┐
                                                    └─────┤4│
                                                          └─┘
               ┌──────────────────────────────────┐   ┌─┐
               │FCS_COP Криптографические операции├───┤1│
               └──────────────────────────────────┘   └─┘

9.1. Управление криптографическими ключами (FCS_CKM)

9.1.1 Характеристика семейства

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

9.1.2 Ранжирование компонентов

                                                    ┌─┐
                                                  ┌─┤1│
                                                  │ └─┘┌─┐
                                                  ├────┤2│
<pre class="legal-pre">                ┌───────────────────────────────┐ │    └─┘
                │       FCS_CKM Управление      ├─┤ ┌─┐
                │   криптографическими ключами  │ ├─┤3│</pre>
                └───────────────────────────────┘ │ └─┘┌─┐
                                                  └────┤4│
                                                       └─┘

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

FCS_CKM.2 «Распределение криптографических ключей» содержит требование их распределения определенным методом, который может основываться на соответствующем стандарте.

FCS_CKM.3 «Доступ к криптографическим ключам» содержит требование осуществления доступа к ним согласно определенному методу, который может основываться на соответствующем стандарте.

FCS_CKM.4 «Уничтожение криптографических ключей» содержит требование их уничтожения согласно определенному методу, который может основываться на соответствующем стандарте.

9.1.3 Управление: FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

9.1.4 Аудит: FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: успешный или неуспешный результат действия;

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

9.1.5 FCS_CKM.1 Генерация криптографических ключей

Иерархический для: нет подчиненных компонентов.

Зависимости: [FCS_CKM.2 Распределение криптографических ключей или

FCS_COP.1 Криптографические операции]

FCS_CKM.4 Уничтожение криптографических ключей

FMT_MSA.2 Безопасные значения атрибутов безопасности

9.1.5.1 FCS_CKM.1.1

#ФБО должны генерировать криптографические ключи в соответствии с определенным алгоритмом [назначение: &алгоритм генерации криптографических ключей&] и длиной [назначение: &длины криптографических ключей&], которые отвечают следующему: [назначение: &список стандартов&]#.

9.1.6 FCS_CKM.2 Распределение криптографических ключей

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности или

FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности, или

FCS_CKM.1 Генерация криптографических ключей]

FCS_CKM.4 Уничтожение криптографических ключей

FMT_MSA.2 Безопасные значения атрибутов безопасности

9.1.6.1 FCS_CKM.2.1

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

9.1.7 FCS_CKM.3 Доступ к криптографическим ключам

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности или

FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности, или

FCS_CKM.1 Генерация криптографических ключей]

FCS_CKM.4 Уничтожение криптографических ключей

FMT_MSA.2 Безопасные значения атрибутов безопасности

9.1.7.1 FCS_CKM.3.1

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

9.1.8 FCS_CKM.4 Уничтожение криптографических ключей

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности или

FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности, или

FCS_CKM.1 Генерация криптографических ключей]

FMT_MSA.2 Безопасные значения атрибутов безопасности

9.1.8.1 FCS_CKM.4.1

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

9.2. Криптографические операции (FCS_COP)

9.2.1 Характеристика семейства

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

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

9.2.2 Ранжирование компонентов

                  ┌──────────────────────────────────┐ ┌─┐
                  │FCS_COP Криптографические операции├─┤1│
                  └──────────────────────────────────┘ └─┘

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

9.2.3 Управление: FCS_COP.1

Действия по управлению не предусмотрены.

9.2.4 Аудит: FCS_COP.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

b) базовый: любые применяемые криптографические режимы операций, атрибуты субъектов и объектов.

9.2.5 FCS_COP.1 Криптографические операции

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности или

FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности, или

FCS_CKM.1 Генерация криптографических ключей]

FCS_CKM.4 Уничтожение криптографических ключей

FMT_MSA.2 Безопасные значения атрибутов безопасности

9.2.5.1 FCS_COP.1.1

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

10. Класс FDP. Защита данных пользователя

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

a) политики функций безопасности для защиты данных пользователя:

1. FDP_ACC «Политика управления доступом»,

2. FDP_IFC «Политика управления информационными потоками».

Компоненты этих семейств позволяют разработчику ПЗ/ЗБ именовать политики функций безопасности для защиты данных пользователя и определять область действия этих политик, которые необходимо соотнести с целями безопасности. Предполагается, что имена этих политик будут использоваться повсеместно в тех функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор «ПФБ управления доступом» и/или «ПФБ управления информационными потоками». Правила, которые определяют функциональные возможности именованных ПФБ управления доступом и управления информационными потоками, будут установлены в семействах FDP_ACF «Функции управления доступом» и FDP_IFF «Функции управления информационными потоками» соответственно;

b) виды защиты данных пользователя:

1. FDP_ACF «Функции управления доступом»,

2. FDP_IFF «Функции управления информационными потоками»,

3. FDP_ITT «Передача в пределах ОО»,

4. FDP_RIP «Защита остаточной информации»,

5. FDP_ROL «Откат»,

6. FDP_SDI «Целостность хранимых данных»;

c) автономное хранение, импорт и экспорт данных:

1. FDP_DAU «Аутентификация данных»,

2. FDP_ETC «Экспорт данных за пределы действия ФБО»,

3. FDP_ITC «Импорт данных из-за пределов действия ФБО».

Компоненты этих семейств связаны с доверенной передачей данных в ОДФ или из ОДФ;

d) связь между ФБО:

1. FDP_UCT «Защита конфиденциальности данных пользователя при передаче между ФБО»,

2. FDP_UIT «Защита целостности данных пользователя при передаче между ФБО».

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

         ┌─────────────────────────────────────┐   ┌─┐  ┌─┐
         │FDP_ACC Политика управления доступом ├───┤1├──┤2│
<pre class="legal-pre">         └─────────────────────────────────────┘   └─┘  └─┘
         ┌─────────────────────────────────────┐   ┌─┐</pre>
         │ FDP_ACF Функции управления доступом ├───┤1│
<pre class="legal-pre">         └─────────────────────────────────────┘   └─┘
         ┌─────────────────────────────────────┐   ┌─┐  ┌─┐
         │    FDP_DAU Аутентификация данных    ├───┤1├──┤2│
         └─────────────────────────────────────┘   └─┘  └─┘</pre>
                                                   ┌─┐
                                                 ┌─┤1│
         ┌─────────────────────────────────────┐ │ └─┘
<pre class="legal-pre">         │  FDP_ETC Экспорт данных за пределы  ├─┤
         │            действия ФБО             │ │ ┌─┐</pre>
         └─────────────────────────────────────┘ └─┤2│
                                                   └─┘
<pre class="legal-pre">         ┌─────────────────────────────────────┐   ┌─┐  ┌─┐
         │     FDP_IFC Политика управления     ├───┤1├──┤2│
         │       информационными потоками      │   │ │  │ │
         └─────────────────────────────────────┘   └─┘  └─┘
                                                   ┌─┐  ┌─┐</pre>
                                                 ┌─┤1├──┤2│
<pre class="legal-pre">                                                 │ └─┘  └─┘
         ┌─────────────────────────────────────┐ │    ┌─┐  ┌─┐  ┌─┐
         │      FDP_IFF Функции управления     ├─┼────┤3├──┤4├──┤5│
         │       информационными потоками      │ │ ┌─┐└─┘  └─┘  └─┘</pre>
         └─────────────────────────────────────┘ └─┤6│
                                                   └─┘

Рисунок 22. Декомпозиция класса FDP
"Защита данных пользователя", лист 1

                                                         ┌─┐
                                                       ┌─┤1│
            ┌────────────────────────────────────────┐ │ └─┘
<pre class="legal-pre">            │  FDP_ITC Импорт данных из-за пределов  ├─┤
            │               действия ФБО             │ │ ┌─┐</pre>
            └────────────────────────────────────────┘ └─┤2│
                                                         └─┘
                                                         ┌─┐ ┌─┐
                                                       ┌─┤1├─┤2│
            ┌────────────────────────────────────────┐ │ └─┘ └─┘
            │     FDP_ITT Передача в пределах ОО     ├─┤
            └────────────────────────────────────────┘ │ ┌─┐ ┌─┐
                                                       └─┤3├─┤4│
                                                         └─┘ └─┘
<pre class="legal-pre">            ┌────────────────────────────────────────┐   ┌─┐ ┌─┐
            │  FDP_RIP Защита остаточной информации  ├───┤1├─┤2│
            └────────────────────────────────────────┘   └─┘ └─┘
            ┌────────────────────────────────────────┐   ┌─┐ ┌─┐
            │             FDP_ROL Откат              ├───┤1├─┤2│
            └────────────────────────────────────────┘   └─┘ └─┘
            ┌────────────────────────────────────────┐   ┌─┐ ┌─┐
            │  FDP_SDI Целостность хранимых данных   ├───┤1├─┤2│
            └────────────────────────────────────────┘   └─┘ └─┘
            ┌────────────────────────────────────────┐     ┌─┐</pre>
            │FDP_UCT Защита конфиденциальности данных├─────┤1│
<pre class="legal-pre">            │  пользователя при передаче между ФБО   │     │ │
            └────────────────────────────────────────┘     └─┘</pre>
                                                         ┌─┐
                                                       ┌─┤1│
            ┌────────────────────────────────────────┐ │ └─┘
<pre class="legal-pre">            │   FDP_UIT Защита целостности данных    ├─┤
            │  пользователя при передаче между ФБО   │ │ ┌─┐ ┌─┐</pre>
            └────────────────────────────────────────┘ └─┤2├─┤3│
                                                         └─┘ └─┘

Рисунок 22, лист 2

10.1. Политика управления доступом (FDP_ACC)

10.1.1. Характеристика семейства
Семейство FDP_ACC идентифицирует ПФБ управления доступом, устанавливая им имена, и определяет области действия политик, образующих идентифицированную часть управления доступом ПБО. Области действия можно характеризовать тремя множествами: субъекты под управлением политики, объекты под управлением политики и операции управляемых субъектов на управляемых объектах, на которые распространяется политика. Общие критерии допускают существование нескольких политик, каждая из которых имеет уникальное имя. Это достигается посредством выполнения итераций компонентов рассматриваемого семейства по одному разу для каждой именованной политики управления доступом. Правила, определяющие функциональные возможности ПФБ управления доступом, будут установлены другими семействами, такими как FDP_ACF "Функции управления доступом" и FDP_SDI "Целостность хранимых данных". Предполагается, что имена ПФБ, идентифицированные в семействе FDP_ACC "Политика управления доступом", будут использоваться повсеместно в функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор "ПФБ управления доступом".

10.1.2. Ранжирование компонентов

                 ┌────────────────────────────────────┐ ┌─┐ ┌─┐
                 │FDP_ACC Политика управления доступом├─┤1├─┤2│
                 └────────────────────────────────────┘ └─┘ └─┘

FDP_ACC.1 «Ограниченное управление доступом» содержит требование, чтобы каждая идентифицированная ПФБ управления доступом существовала для подмножества возможных операций на подмножестве объектов в ОО.

FDP_ACC.2 «Полное управление доступом» содержит требование, чтобы каждая идентифицированная ПФБ управления доступом охватывала все операции субъектов на объектах, управляемых этой ПФБ. Кроме этого, требуется, чтобы все объекты и операции в ОДФ были охвачены, по меньшей мере, одной идентифицированной ПФБ управления доступом.

10.1.3 Управление: FDP_ACC.1, FDP_ACC.2

Действия по управлению не предусмотрены.

10.1.4 Аудит: FDP_ACC.1, FDP_ACC.2

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

10.1.5 FDP_ACC.1 Ограниченное управление доступом

Иерархический для: нет подчиненных компонентов.

Зависимости: FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности

10.1.5.1 FDP_ACC.1.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом&] для [назначение: &список субъектов, объектов и операций субъектов на объектах, на которые распространяется ПФБ&]#.

10.1.6 FDP_ACC.2 Полное управление доступом

Иерархический для: FDP_ACC.1 Ограниченное управление доступом

Зависимости: FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности

10.1.6.1 FDP_ACC.2.1

ФБО должны осуществлять [назначение: ПФБ управления доступом] для [назначение: список субъектов и объектов] #и всех операций субъектов на объектах, на которые распространяется ПФБ#.

10.1.6.2 FDP_ACC.2.2

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

10.2. Функции управления доступом (FDP_ACF)

10.2.1 Характеристика семейства

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

10.2.2 Ранжирование компонентов

                 ┌───────────────────────────────────┐ ┌─┐
                 │FDP_ACF Функции управления доступом├─┤1│
                 └───────────────────────────────────┘ └─┘

В этом семействе рассмотрены использование атрибутов безопасности и характеристики политик управления доступом. Предполагается, что компонент этого семейства будет использован, чтобы описать правила для функции, которая реализует ПФБ, ранее идентифицированную в FDP_ACC «Политика управления доступом». Разработчик ПЗ/ЗБ может также выполнять итерации этого компонента, если в ОО имеется несколько таких политик.

FDP_ACF.1 «Управление доступом, основанное на атрибутах безопасности» позволяет ФБО осуществить доступ, основанный на атрибутах и именованных группах атрибутов безопасности. Кроме того, ФБО могут иметь возможность явно разрешать или запрещать доступ к объекту, основываясь на атрибутах безопасности.

10.2.3 Управление: FDP_ACF.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

10.2.4 Аудит: FDP_ACF.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: успешные запросы на выполнение операций на объекте, на который распространяется ПФБ;

b) базовый: все запросы на выполнение операций на объекте, на который распространяется ПФБ;

c) детализированный: специальные атрибуты безопасности, используемые при проверке правомерности доступа.

10.2.5 FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: FDP_ACC.1 Ограниченное управление доступом

FMT_MSA.3 Инициализация статических атрибутов

10.2.5.1 FDP_ACF.1.1

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

10.2.5.2 FDP_ACF.1.2

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

10.2.5.3 FDP_ACF.1.3

#ФБО должны явно разрешать доступ субъектов к объектам, основываясь на следующих дополнительных правилах: [назначение: &правила, основанные на атрибутах безопасности, которые явно разрешают доступ субъектов к объектам&]#.

10.2.5.4 FDP_ACF.1.4

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

10.3. Аутентификация данных (FDP_DAU)

10.3.1 Характеристика семейства

Аутентификация данных позволяет сущности принять ответственность за подлинность информации (например, с использованием цифровой подписи). Семейство FDP_DAU содержит метод предоставления гарантии правильности специфического набора данных, который может быть впоследствии использован для верификации того, что содержание информации не было подделано или модифицировано мошенническим путем. В отличие от класса FAU «Аудит безопасности» данное семейство предназначено для применения скорее к статическим, чем к перемещаемым данным.

10.3.2 Ранжирование компонентов

                ┌────────────────────────────────┐ ┌─┐ ┌─┐
                │ FDP_DAU Аутентификация данных  ├─┤1├─┤2│
                └────────────────────────────────┘ └─┘ └─┘

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

FDP_DAU.2 «Аутентификация данных с идентификацией гаранта» содержит дополнительное требование, чтобы ФБО были способны установить идентификатор субъекта, который предоставил гарантию подлинности.

10.3.3 Управление: FDP_DAU.1, FDP_DAU.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

10.3.4 Аудит: FDP_DAU.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: успешная генерация свидетельства правильности;

b) базовый: неуспешная генерация свидетельства правильности;

c) детализированный: идентификатор субъекта, который запросил свидетельство.

10.3.5 Аудит: FDP_DAU.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: успешная генерация свидетельства правильности;

b) базовый: неуспешная генерация свидетельства правильности;

c) детализированный: идентификатор субъекта, который запросил свидетельство;

d) детализированный: идентификатор субъекта, который генерировал свидетельство.

10.3.6 FDP_DAU.1 Базовая аутентификация данных

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

10.3.6.1 FDP_DAU.1.1

#ФБО должны предоставлять возможность генерировать свидетельство, которое может быть использовано как гарантия правильности [назначение: &список объектов или типов информации&]#.

10.3.6.2 FDP_DAU.1.2

#ФБО должны предоставлять [назначение: список субъектов] возможность верифицировать свидетельство правильности указанной информации#.

10.3.7 FDP_DAU.2 Аутентификация данных с идентификацией гаранта

Иерархический для: FDP_DAU.1 Базовая аутентификация данных

Зависимости: FIA_UID.1 Выбор момента идентификации

10.3.7.1 FDP_DAU.2.1

ФБО должны предоставлять возможность генерировать свидетельство, которое может быть использовано как гарантия правильности [назначение: список объектов или типов информации].

10.3.7.2 FDP_DAU.2.2

ФБО должны предоставлять [назначение: список субъектов] возможность верифицировать свидетельство правильности указанной информации и #идентификатор пользователя, который создал свидетельство#.

10.4. Экспорт данных за пределы действия ФБО (FDP_ETC)

10.4.1 Характеристика семейства

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

10.4.2 Ранжирование компонентов

                                                       ┌─┐
                                                     ┌─┤1│
                 ┌─────────────────────────────────┐ │ └─┘
                 │FDP_ETC Экспорт данных за пределы├─┤
                 │           действия ФБО          │ │
                 └─────────────────────────────────┘ │ ┌─┐
                                                     └─┤2│
                                                       └─┘

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

FDP_ETC.2 «Экспорт данных пользователя с атрибутами безопасности» содержит требование, чтобы ФБО осуществляли соответствующие ПФБ, используя функцию, которая точно и однозначно ассоциирует атрибуты безопасности с экспортируемыми данными пользователя.

10.4.3 Управление: FDP_ETC.1

Действия по управлению не предусмотрены.

10.4.4 Управление: FDP_ETC.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) изменение дополнительных правил управления экспортом информации пользователем с определенной ролью.

10.4.5 Аудит: FDP_ETC.1, FDP_ETC.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: успешный экспорт информации;

b) базовый: все попытки экспортировать информацию.

10.4.6 FDP_ETC.1 Экспорт данных пользователя без атрибутов безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

10.4.6.1 FDP_ETC.1.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&] при экспорте данных пользователя, контролируемом ПФБ, за пределы ОДФ#.

10.4.6.2 FDP_ETC.1.2

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

10.4.7 FDP_ETC.2 Экспорт данных пользователя с атрибутами безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

10.4.7.1 FDP_ETC.2.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&] при экспорте данных пользователя, контролируемом ПФБ, за пределы ОДФ#.

10.4.7.2 FDP_ETC.2.2

#ФБО должны экспортировать данные пользователя с атрибутами безопасности, ассоциированными с данными пользователя#.

10.4.7.3 FDP_ETC.2.3

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

10.4.7.4 FDP_ETC.2.4

#ФБО должны осуществлять следующие правила при экспорте данных пользователя из ОДФ: [назначение: &дополнительные правила управления экспортом информации&]#.

10.5. Политика управления информационными потоками (FDP_IFC)

10.5.1 Характеристика семейства

Семейство FDP_IFC идентифицирует ПФБ управления информационными потоками, устанавливая им имена, и определяет области действия политик, образующих идентифицированную часть управления информационными потоками ПБО. Эти области действия можно характеризовать тремя множествами: субъекты под управлением политики, информация под управлением политики и операции перемещения управляемой информации к управляемым субъектам и от них, на которые распространяется политика. Общие критерии допускают существование нескольких политик, каждая из которых имеет уникальное имя. Это достигается посредством выполнения итераций компонентов рассматриваемого семейства по одному разу для каждой именованной политики управления информационными потоками. Правила, определяющие функциональные возможности ПФБ управления информационными потоками, будут установлены другими семействами, такими как FDP_IFF «Функции управления информационными потоками» и FDP_SDI «Целостность хранимых данных». Имена ПФБ управления информационными потоками, идентифицированные в семействе FDP_IFC, в дальнейшем будут использоваться повсеместно в тех функциональных компонентах, которые включают в себя операцию, запрашивающую назначение или выбор «ПФБ управления информационными потоками».

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

10.5.2 Ранжирование компонентов

                   ┌───────────────────────────┐ ┌─┐ ┌─┐
                   │FDP_IFC Политика управления├─┤1├─┤2│
                   │ информационными потоками  │ │ │ │ │
                   └───────────────────────────┘ └─┘ └─┘

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

FDP_IFC.2 «Полное управление информационными потоками» содержит требование, чтобы каждая идентифицированная ПФБ управления информационными потоками охватывала все операции для субъектов и информацию под управлением этой ПФБ. Также требуется, чтобы все информационные потоки и операции в пределах ОДФ были охвачены хотя бы одной идентифицированной ПФБ управления информационными потоками. Совместно с компонентом FPT_RVM.1 это обеспечивает аспект «постоянная готовность» монитора обращений.

10.5.3 Управление: FDP_IFC.1, FDP_IFC.2

Действия по управлению не предусмотрены.

10.5.4 Аудит: FDP_IFC.1, FDP_IFC.2

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

10.5.5 FDP_IFC.1 Ограниченное управление информационными потоками

Иерархический для: нет подчиненных компонентов.

Зависимости: FDP_IFF.1 Простые атрибуты безопасности

10.5.5.1 FDP_IFC.1.1

#ФБО должны осуществлять [назначение: &ПФБ управления информационными потоками&] для [назначение: &список субъектов, информации и операций перемещения управляемой информации к управляемым субъектам и от них, на которые распространяется ПФБ&]#.

10.5.6 FDP_IFC.2 Полное управление информационными потоками

Иерархический для: FDP_IFC.1 Ограниченное управление информационными потоками

Зависимости: FDP_IFF.1 Простые атрибуты безопасности

10.5.6.1 FDP_IFC.2.1

ФБО должны осуществлять [назначение: ПФБ управления информационными потоками] для [назначение: список субъектов и информации] и #всех операций перемещения управляемой информации к управляемым субъектам и от них, на которые распространяется ПФБ#.

10.5.6.2 FDP_IFC.2.2

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

10.6. Функции управления информационными потоками (FDP_IFF)

10.6.1 Характеристика семейства

Семейство FDP_IFF описывает правила для конкретных функций, которые могут реализовать ПФБ управления информационными потоками, именованные в FDP_IFC «Политика управления информационными потоками», где также определена область действия соответствующей политики. Семейство содержит два типа требований: первый связан с обычными информационными потоками, а второй — с неразрешенными информационными потоками (скрытыми каналами). Это разделение возникает, потому что проблема неразрешенных информационных потоков в некотором смысле противоречит остальным аспектам ПФБ управления информационными потоками. По существу, скрытые каналы дают возможность обходить ПФБ управления информационными потоками в нарушение политики. Таким образом, возникает потребность в специальных функциях, которые ограничивают либо предотвращают их возникновение.

10.6.2 Ранжирование компонентов

                                             ┌─┐  ┌─┐
                                          ┌──┤1├──┤2│
<pre class="legal-pre">                                          │  └─┘  └─┘
             ┌──────────────────────────┐ │     ┌─┐  ┌─┐  ┌─┐</pre>
             │FDP_IFF Функции управления├─┼─────┤3├──┤4├──┤5│
             │ информационными потоками │ │  ┌─┐└─┘  └─┘  └─┘
             └──────────────────────────┘ └──┤6│
                                             └─┘

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

FDP_IFF.2 «Иерархические атрибуты безопасности» расширяет требования предыдущего компонента, требуя, чтобы все ПФБ управления информационными потоками в ПБО использовали иерархические атрибуты безопасности, которые образуют некоторую структуру.

FDP_IFF.3 «Ограничение неразрешенных информационных потоков» содержит требование, чтобы ПФБ распространялась на неразрешенные информационные потоки, но не обязательно устраняла их.

FDP_IFF.4 «Частичное устранение неразрешенных информационных потоков» содержит требование, чтобы ПФБ обеспечила устранение некоторых, но не обязательно всех, неразрешенных информационных потоков.

FDP_IFF.5 «Полное устранение неразрешенных информационных потоков» содержит требование, чтобы ПФБ обеспечила устранение всех неразрешенных информационных потоков.

FDP_IFF.6 «Мониторинг неразрешенных информационных потоков» содержит требование, чтобы ПФБ отслеживала неразрешенные информационные потоки, максимальная интенсивность которых превышает заданное пороговое значение.

10.6.3 Управление: FDP_IFF.1, FDP_IFF.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

10.6.4 Управление: FDP_IFF.3, FDP_IFF.4, FDP_IFF.5

Действия по управлению не предусмотрены.

10.6.5 Управление: FDP_IFF.6

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) включение или отключение функции мониторинга;

b) модификация максимальной интенсивности, которая отслеживается при мониторинге.

10.6.6 Аудит: FDP_IFF.1, FDP_IFF.2, FDP_IFF.5

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: разрешения на запрашиваемые информационные потоки;

b) базовый: все решения по запросам на информационные потоки;

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

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

10.6.7 Аудит: FDP_IFF.3, FDP_IFF.4, FDP_IFF.6

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: разрешения на запрашиваемые информационные потоки;

b) базовый: все решения по запросам на информационные потоки;

c) базовый: использование выявленных скрытых каналов;

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

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

f) детализированный: использование идентифицированных скрытых каналов, для которых оценка максимальной интенсивности превышает заданное пороговое значение.

10.6.8 FDP_IFF.1 Простые атрибуты безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: FDP_IFC.1 Ограниченное управление информационными потоками

FMT_MSA.3 Инициализация статических атрибутов

10.6.8.1 FDP_IFF.1.1

#ФБО должны осуществлять [назначение: &ПФБ управления информационными потоками&], основанную на следующих типах атрибутов безопасности субъекта и информации: [назначение: &список субъектов и типов информации, находящихся под управлением указанной ПФБ, и для каждого из них — атрибуты безопасности&]#.

10.6.8.2 FDP_IFF.1.2

#ФБО должны разрешать информационный поток между управляемым субъектом и управляемой информацией посредством управляемой операции, если выполняются следующие правила: [назначение: &основанные на атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации (для каждой операции)&]#.

10.6.8.3 FDP_IFF.1.3

#ФБО должны осуществлять [назначение: &дополнительные правила ПФБ управления информационными потоками&]#.

10.6.8.4 FDP_IFF.1.4

#ФБО должны предоставлять следующее [назначение: &список дополнительных возможностей ПФБ&]#.

10.6.8.5 FDP_IFF.1.5

#ФБО должны явно разрешать информационный поток, основываясь на следующих правилах: [назначение: &основанные на атрибутах безопасности правила, которые явно разрешают информационные потоки&]#.

10.6.8.6 FDP_IFF.1.6

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

10.6.9 FDP_IFF.2 Иерархические атрибуты безопасности

Иерархический для: FDP_IFF.1 Простые атрибуты безопасности

Зависимости: FDP_IFC.1 Ограниченное управление информационными потоками

FMT_MSA.3 Инициализация статических атрибутов

10.6.9.1 FDP_IFF.2.1

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

10.6.9.2 FDP_IFF.2.2

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

10.6.9.3 FDP_IFF.2.3

ФБО должны осуществлять [назначение: дополнительные правила ПФБ управления информационными потоками].

10.6.9.4 FDP_IFF.2.4

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

10.6.9.5 FDP_IFF.2.5

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

10.6.9.6 FDP_IFF.2.6

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

10.6.9.7 FDP_IFF.2.7

#ФБО должны осуществлять следующие отношения для любых двух допустимых атрибутов безопасности управления информационными потоками:

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

b) существует такая «наименьшая верхняя грань» в совокупности атрибутов безопасности, что для любых двух допустимых атрибутов безопасности найдется такой допустимый атрибут безопасности, который больше или равен двум допустимым атрибутам безопасности;

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

10.6.10 FDP_IFF.3 Ограничение неразрешенных информационных потоков

Иерархический для: нет подчиненных компонентов.

Зависимости: AVA_CCA.1 Анализ скрытых каналов

FDP_IFC.1 Ограниченное управление информационными потоками

10.6.10.1 FDP_IFF.3.1

#ФБО должны осуществлять [назначение: ПФБ управления информационными потоками], чтобы ограничить интенсивность [назначение: &типы неразрешенных информационных потоков&] до [назначение: &максимальная интенсивность&]#.

10.6.11 FDP_IFF.4 Частичное устранение неразрешенных информационных потоков

Иерархический для: FDP_IFF.3 Ограничение неразрешенных информационных потоков

Зависимости: AVA_CCA.1 Анализ скрытых каналов

FDP_IFC.1 Ограниченное управление информационными потоками

10.6.11.1 FDP_IFF.4.1

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

10.6.11.2 FDP_IFF.4.2

#ФБО должны предотвращать [назначение: &типы неразрешенных информационных потоков&]#.

10.6.12 FDP_IFF.5 Отсутствие неразрешенных информационных потоков

Иерархический для: FDP_IFF.4 Частичное устранение неразрешенных информационных потоков

Зависимости: AVA_CCA.3 Исчерпывающий анализ скрытых каналов

FDP_IFC.1 Ограниченное управление информационными потоками

10.6.12.1 FDP_IFF.5.1

#ФБО должны обеспечивать, чтобы не существовало неразрешенных информационных потоков, способных нарушить [назначение: &имя ПФБ управления информационными потоками&]#.

10.6.13 FDP_IFF.6 Мониторинг неразрешенных информационных потоков

Иерархический для: нет подчиненных компонентов.

Зависимости: AVA_CCA.1 Анализ скрытых каналов

FDP_IFC.1 Ограниченное управление информационными потоками

10.6.13.1 FDP_IFF.6.1

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

10.7. Импорт данных из-за пределов действия ФБО (FDP_ITC)

10.7.1 Характеристика семейства

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

                                                        ┌─┐
               ┌────────────────────────────────────┐ ┌─┤1│
               │FDP_ITC Импорт данных из-за пределов├─┤ └─┘
               │            действия ФБО            │ │ ┌─┐
               └────────────────────────────────────┘ └─┤2│
                                                        └─┘

10.7.2 Ранжирование компонентов

Компонент FDP_ITC.1 «Импорт данных пользователя без атрибутов безопасности» содержит требования, чтобы атрибуты безопасности правильно представляли данные пользователя и поставлялись независимо от объекта.

Компонент FDP_ITC.2 «Импорт данных пользователя с атрибутами безопасности» содержит требования, чтобы атрибуты безопасности правильно представляли данные пользователя, а также точно и однозначно ассоциировались с данными пользователя, импортируемыми из-за пределов ОДФ.

10.7.3 Управление: FDP_ITC.1, FDP_ITC.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

10.7.4 Аудит: FDP_ITC.1, FDP_ITC.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

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

10.7.5 FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

FMT_MSA.3 Инициализация статических атрибутов

10.7.5.1 FDP_ITC.1.1

#ФБО должны осуществлять [назначение: &политики ФБ управления доступом и/или политики ФБ управления информационными потоками&] при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ#.

10.7.5.2 FDP_ITC.1.2

#ФБО должны игнорировать любые атрибуты безопасности, ассоциированные с данными пользователя, при импорте из-за пределов ОДФ#.

10.7.5.3 FDP_ITC.1.3

#ФБО должны осуществлять следующие правила при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ: [назначение: &дополнительные правила управления импортом&]#.

10.7.6 FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

[FTP_ITC.1 Доверенный канал передачи между ФБО или

FTP_TRP.1 Доверенный маршрут]

FPT_TDC.1 Базовая согласованность данных ФБО между ФБО

10.7.6.1 FDP_ITC.2.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&] при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ#.

10.7.6.2 FDP_ITC.2.2

#ФБО должны использовать атрибуты безопасности, ассоциированные с импортируемыми данными пользователя#.

10.7.6.3 FDP_ITC.2.3

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

10.7.6.4 FDP_ITC.2.4

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

10.7.6.5 FDP_ITC.2.5

#ФБО должны осуществлять следующие правила при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ: [назначение: &дополнительные правила управления импортом&]#.

10.8. Передача в пределах ОО (FDP_ITT)

10.8.1 Характеристика семейства

Семейство FDP_ITT содержит требования, связанные с защитой данных пользователя при их передаче между различными частями ОО по внутреннему каналу. Этим данное семейство отличается от семейств FDP_UCT «Защита конфиденциальности данных пользователя при передаче между ФБО» и FDP_UIT «Защита целостности данных пользователя при передаче между ФБО», которые обеспечивают защиту данных пользователя при их передаче между различными ФБО по внешнему каналу, а также от семейств FDP_ETC «Экспорт данных за пределы действия ФБО» и FDP_ITC «Импорт данных из-за пределов действия ФБО», которые связаны с передачей данных за пределы или из-за пределов действия ФБО.

10.8.2 Ранжирование компонентов

                                                   ┌─┐ ┌─┐
                                                 ┌─┤1├─┤2│
                ┌──────────────────────────────┐ │ └─┘ └─┘
                │FDP_ITT Передача в пределах ОО├─┤
                └──────────────────────────────┘ │ ┌─┐ ┌─┐
                                                 └─┤3├─┤4│
                                                   └─┘ └─┘

FDP_ITT.1 «Базовая защита внутренней передачи» содержит требование, чтобы данные пользователя были защищены при передаче между частями ОО.

FDP_ITT.2 «Разделение передачи по атрибутам» содержит в дополнение к первому компоненту требование разделения данных, основанного на значениях присущих ПФБ атрибутов.

FDP_ITT.3 «Мониторинг целостности» содержит требование, чтобы ФБ контролировала данные пользователя, передаваемые между частями ОО, на наличие идентифицированных ошибок целостности.

FDP_ITT.4 «Мониторинг целостности по атрибутам» расширяет третий компонент, разрешая дополнительную форму мониторинга целостности с разделением, использующим присущие ПФБ атрибуты.

10.8.3 Управление: FDP_ITT.1, FDP_ITT.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

10.8.4 Управление: FDP_ITT.3, FDP_ITT.4

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

10.8.5 Аудит: FDP_ITT.1, FDP_ITT.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

10.8.6 Аудит: FDP_ITT.3, FDP_ITT.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

c) базовый: несанкционированные попытки изменить метод защиты целостности;

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

10.8.7 FDP_ITT.1 Базовая защита внутренней передачи

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

10.8.7.1 FDP_ITT.1.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потопами&], чтобы предотвращать [выбор: &раскрытие, модификация, недоступность&] данных пользователя при их передаче между физически разделенными частями ОО#.

10.8.8 FDP_ITT.2 Разделение передачи по атрибутам

Иерархический для: FDP_ITT.1 Базовая защита внутренней передачи

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

10.8.8.1 FDP_ITT.2.1

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

10.8.8.2 FDP_ITT.2.2

#ФБО должны разделять данные, контролируемые ПФБ, при их передаче между физически разделенными частями ОО, основываясь на значениях следующих атрибутов: [назначение: &атрибуты безопасности, которые требуют разделения данных&]#.

10.8.9 FDP_ITT.3 Мониторинг целостности

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

FDP_ITT.1 Базовая защита внутренней передачи

10.8.9.1 FDP_ITT.3.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], чтобы контролировать данные пользователя, передаваемые между физически разделенными частями ОО, на наличие следующих ошибок: [назначение: &ошибки целостности&]#.

10.8.9.2 FDP_ITT.3.2

#При обнаружении ошибки целостности данных ФБО должны [назначение: &действия при ошибке целостности&]#.

10.8.10 FDP_ITT.4 Мониторинг целостности по атрибутам

Иерархический для: FDP_ITT.3 Мониторинг целостности

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

FDP_ITT.2 Разделение передачи по атрибутам

10.8.10.1 FDP_ITT.4.1

ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы контролировать данные пользователя, передаваемые между физически разделенными частями ОО, на наличие следующих ошибок: [назначение: ошибки целостности], #основываясь на следующих атрибутах: [назначение: &атрибуты безопасности, которые требуют разделения каналов передачи&]#.

10.8.10.2 FDP_ITT.4.2

При обнаружении ошибки целостности данных ФБО должны [назначение: действия при ошибке целостности].

10.9. Защита остаточной информации (FDP_RIP)

10.9.1 Характеристика семейства

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

10.9.2 Ранжирование компонентов

              ┌────────────────────────────────────┐ ┌─┐ ┌─┐
              │FDP_RIP Защита остаточной информации├─┤1├─┤2│
              └────────────────────────────────────┘ └─┘ └─┘

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

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

10.9.3 Управление: FDP_RIP.1, FDP_RIP.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

10.9.4 Аудит: FDP_RIP.1, FDP_RIP.2

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

10.9.5 FDP_RIP.1 Ограниченная защита остаточной информации

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

10.9.5.1 FDP_RIP.1.1

#ФБО должны обеспечивать недоступность любого предыдущего информационного содержания ресурсов при [выбор: &распределение ресурса, освобождение ресурса&] для следующих объектов: [назначение: &список объектов&]#.

10.9.6 FDP_RIP.2 Полная защита остаточной информации

Иерархический для: FDP_RIR.1 Ограниченная защита остаточной информации

Зависимости: нет зависимостей.

10.9.6.1 FDP_RIP.2.1

ФБО должны обеспечивать недоступность любого предыдущего информационного содержания ресурсов при [выбор: распределение ресурса, освобождение ресурса] для #всех объектов#.

10.10. Откат (FDP_ROL)

10.10.1 Характеристика семейства

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

10.10.2 Ранжирование компонентов

                 ┌───────────────────────────────┐ ┌─┐ ┌─┐
                 │         FDP_ROL Откат         ├─┤1├─┤2│
                 └───────────────────────────────┘ └─┘ └─┘

FDP_ROL.1 «Базовый откат» связан с необходимостью вернуть обратно или отменить ограниченное число операций в определенных пределах.

FDP_ROL.2 «Расширенный откат» связан с необходимостью вернуть обратно или отменить все операции в определенных пределах.

10.10.3 Управление: FDP_ROL.1, FDP_ROL.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) возможность настройки предела ограничений, до которого возможен откат в пределах ОО;

b) разрешение выполнять операцию отката только вполне определенным ролям.

10.10.4 Аудит: FDP_ROL.1, FDP_ROL.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

b) базовый: все попытки выполнить операции отката;

c) детализированный: все попытки выполнить операции отката с идентификацией типов операций, отмененных при откате.

10.10.5 FDP_ROL.1 Базовый откат

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

10.10.5.1 FDP_ROL.1.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], чтобы разрешать откат [назначение: &список операций&] на [назначение: &список объектов&]#.

10.10.5.2 FDP_ROL.1.2

#ФБО должны разрешать откат в пределах [назначение: &ограничение выполнения отката&]#.

10.10.6 FDP_ROL.2 Расширенный откат

Иерархический для: FDP_ROL.1 Базовый откат

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

10.10.6.1 FDP_ROL.2.1

ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы разрешать откат #всех операций# на [назначение: список объектов].

10.10.6.2 FDP_ROL.2.2

ФБО должны разрешать откат в пределах [назначение: ограничение выполнения отката].

10.11 Целостность хранимых данных (FDP_SDI)

10.11.1 Характеристика семейства

Семейство FDP_SDI содержит требования, связанные с защитой данных пользователя во время их хранения в пределах ОДФ. Ошибки целостности могут воздействовать на данные пользователя, хранимые как в оперативной памяти, так и на запоминающих устройствах. Это семейство отличается от семейства FDP_ITT «Передача в пределах ОО», которое защищает данные пользователя от ошибок целостности во время их передачи в пределах ОО.

10.11.2 Ранжирование компонентов

              ┌────────────────────────────────────┐ ┌─┐ ┌─┐
              │FDP_SDI Целостность хранимых данных ├─┤1├─┤2│
              └────────────────────────────────────┘ └─┘ └─┘

FDP_SDI.1 «Мониторинг целостности хранимых данных» содержит требование, чтобы ФБ контролировала данные пользователя, хранимые в пределах ОДФ, на наличие идентифицированных ошибок целостности.

FDP_SDI.2 «Мониторинг целостности хранимых данных и предпринимаемые действия» дополняет предыдущий компонент действиями, предпринимаемыми после обнаружения ошибок.

10.11.3 Управление: FDP_SDI.1

Действия по управлению не предусмотрены.

10.11.4 Управление: FDP_SDI.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

10.11.5 Аудит: FDP_SDI.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

c) детализированный: тип обнаруженной ошибки целостности.

10.11.6 Аудит: FDP_SDI.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

c) детализированный: тип обнаруженной ошибки целостности;

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

10.11.7 FDP_SDI.1 Мониторинг целостности хранимых данных

Иерархический для: нет подчиненных компонентов.

Зависимости: отсутствуют.

10.11.7.1 FDP_SDI.1.1

#ФБО должны контролировать данные пользователя, хранимые в пределах ОДФ, на наличие [назначение: &ошибки целостности&] для всех объектов, основываясь на следующих атрибутах: [назначение: &атрибуты данных пользователя&]#.

10.11.8 FDP_SDI.2 Мониторинг целостности хранимых данных и предпринимаемые действия

Иерархический для: FDP_SDI.1 Мониторинг целостности хранимых данных

Зависимости: нет зависимостей.

10.11.8.1 FDP_SDI.2.1

ФБО должны контролировать данные пользователя, хранимые в пределах ОДФ, на наличие [назначение: ошибки целостности] для всех объектов, основываясь на следующих атрибутах: [назначение: атрибуты данных пользователя].

10.11.8.2 FDP_SDI.2.2

#При обнаружении ошибки целостности данных ФБО должны [назначение: &предпринимаемые действия&]#.

10.12. Защита конфиденциальности данных пользователя при передаче между ФБО (FDP_UCT)

10.12.1 Характеристика семейства

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

10.12.2 Ранжирование компонентов

              ┌────────────────────────────────────────┐ ┌─┐
              │FDP_UCT Защита конфиденциальности данных├─┤1│
              │   пользователя при передаче между ФБО  │ │ │
              └────────────────────────────────────────┘ └─┘

Цель компонента FDP_UCT.1 «Базовая конфиденциальность обмена данными» состоит в предоставлении защиты от раскрытия данных пользователя во время их передачи.

10.12.3 Управление: FDP_UCT.1

Действия по управлению не предусмотрены.

10.12.4 Аудит: FDP_UCT.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

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

10.12.5 FDP_UCT.1 Базовая конфиденциальность обмена данными

Иерархический для: нет подчиненных компонентов.

Зависимости: [FTP_ITC.1 Доверенный канал передачи между ФБО или

FTP_TRP.1 Доверенный маршрут]

[FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

10.12.5.1 FDP_UCT.1.1

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

10.13. Защита целостности данных пользователя при передаче между ФБО (FDP_UIT)

10.13.1 Характеристика семейства

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

10.13.2 Ранжирование компонентов

                                                      ┌─┐
                                                    ┌─┤1│
              ┌───────────────────────────────────┐ │ └─┘
              │ FDP_UIT Защита целостности данных ├─┤
              │пользователя при передаче между ФБО│ │
              └───────────────────────────────────┘ │ ┌─┐ ┌─┐
                                                    └─┤2├─┤3│
                                                      └─┘ └─┘

FDP_UIT.1 «Целостность передаваемых данных» связан с обнаружением модификации, удалений, вставок и повторения передаваемых данных пользователя.

FDP_UIT.2 «Восстановление переданных данных источником» связан с восстановлением исходных данных пользователя, полученных ФБО, с помощью источника — доверенного продукта ИТ.

FDP_UIT.3 «Восстановление переданных данных получателем» связан с самостоятельным восстановлением исходных данных пользователя, полученных ФБО, без какой-либо помощи источника — доверенного продукта ИТ.

10.13.3 Управление: FDP_UIT.1, FDP_UIT.2, FDP_UIT.3

Действия по управлению не предусмотрены.

10.13.4 Аудит: FDP_UIT.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

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

d) базовый: любые идентифицированные попытки блокировать передачу данных пользователя;

e) детализированный: типы и/или результаты любых обнаруженных модификаций переданных данных пользователя.

10.13.5 Аудит: FDP_UIT.2, FDP_UIT.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

b) минимальный: успешное восстановление после ошибок, включая тип обнаруженной ошибки;

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

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

e) базовый: любые идентифицированные попытки блокировать передачу данных пользователя;

f) детализированный: типы и/или результаты любых обнаруженных модификаций переданных данных пользователя.

10.13.6 FDP_UIT.1 Целостность передаваемых данных

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

[FTP_ITC.1 Доверенный канал передачи между ФБО или

FTP_TRP.1 Доверенный маршрут]

10.13.6.1 FDP_UIT.1.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], предоставляющую возможность [выбор: &отправление, получение&] данных пользователя способом, защищенным от следующих ошибок: [выбор: &модификация, удаление, вставка, повторение&]#.

10.13.6.2 FDP_UIT.1.2

#ФБО должны быть способны определять после получения данных пользователя, произошли ли следующие ошибки: [выбор: &модификация, удаление, вставка, повторение&]#.

10.13.7 FDP_UIT.2 Восстановление переданных данных источником

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

FDP_UIT.1 Целостность передаваемых данных

FTP_ITC.1 Доверенный канал передачи между ФБО

10.13.7.1 FDP_UIT.2.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], предоставляющую возможность восстановления после [назначение: &список потенциально исправляемых ошибок&] с помощью источника — доверенного продукта ИТ#.

10.13.8 FDP_UIT.3 Восстановление переданных данных получателем

Иерархический для: FDP_UIT.2 Восстановление переданных данных источником

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

FDP_UIT.1 Целостность передаваемых данных

FTP_ITC.1 Доверенный канал передачи между ФБО

10.13.8.1 FDP_UIT.3.1

ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], предоставляющую возможность восстановления после [назначение: список потенциально исправляемых ошибок] #без какой-либо помощи источника — доверенного продукта ИТ#.

11. Класс FIA. Идентификация и аутентификация

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

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

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

<pre class="legal-pre">           ┌───────────────────────────────────┐   ┌─┐
           │   FIA_AFL Отказы аутентификации   ├───┤1│
           └───────────────────────────────────┘   └─┘
           ┌───────────────────────────────────┐   ┌─┐
           │    FIA_ATD Определение атрибутов  ├───┤1│
           │          пользователя             │   │ │
           └───────────────────────────────────┘   └─┘</pre>
                                                   ┌─┐
                                                 ┌─┤1│
           ┌───────────────────────────────────┐ │ └─┘
           │   FIA_SOS Спецификация секретов   ├─┤
           └───────────────────────────────────┘ │ ┌─┐
                                                 └─┤2│
                                                   └─┘
                                                        ┌─┐  ┌─┐
                                                  ┌─────┤1├──┤2│
                                                  │  ┌─┐└─┘  └─┘
                                                  ├──┤3│
                                                  │  └─┘┌─┐
                                                  ├─────┤4│
<pre class="legal-pre">           ┌───────────────────────────────────┐  │     └─┘
           │FIA_UAU Аутентификация пользователя├──┤  ┌─┐
           └───────────────────────────────────┘  ├──┤5│
                                                  │  └─┘┌─┐</pre>
                                                  ├─────┤6│
                                                  │  ┌─┐└─┘
                                                  └──┤7│
                                                     └─┘
           ┌───────────────────────────────────┐  ┌─┐   ┌─┐
           │FIA_UID Идентификация пользователя ├──┤1├───┤2│
<pre class="legal-pre">           └───────────────────────────────────┘  └─┘   └─┘
           ┌───────────────────────────────────┐  ┌─┐
           │        FIA_USB Связывание         ├──┤1│
           │       пользователь-субъект        │  │ │
           └───────────────────────────────────┘  └─┘</pre>

11.1. Отказы аутентификации (FIA_AFL)

11.1.1 Характеристика семейства

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

11.1.2 Ранжирование компонентов

                    ┌─────────────────────────────┐ ┌─┐
                    │FIA_AFL Отказы аутентификации├─┤1│
                    └─────────────────────────────┘ └─┘

FIA_AFL.1 «Обработка отказов аутентификации» содержит требование, чтобы ФБО были способны прервать процесс открытия сеанса после определенного числа неуспешных попыток аутентификации пользователя. Также требуется, чтобы после прерывания процесса открытия сеанса ФБО были способны блокировать учетные данные пользователя или место входа (например, рабочую станцию), с которого выполнялись попытки, до наступления определенного администратором условия.

11.1.3 Управление: FIA_AFL.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление ограничениями для неуспешных попыток аутентификации;

b) управление действиями, предпринимаемыми при неуспешной аутентификации.

11.1.4 Аудит: FIA_AFL.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

11.1.5 FIA_AFL.1 Обработка отказов аутентификации

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UAU.1 Выбор момента аутентификации

11.1.5.1 FIA_AFL.1.1

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

11.1.5.2 FIA_AFL.1.2

#При достижении или превышении определенного числа неуспешных попыток аутентификации ФБО должны выполнить [назначение: &список действий&]#.

11.2. Определение атрибутов пользователя (FIA_ATD)

11.2.1 Характеристика семейства

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

11.2.2 Ранжирование компонентов

                  ┌─────────────────────────────────┐ ┌─┐
<pre class="legal-pre">                  │  FIA_ATD Определение атрибутов  ├─┤1│
                  │            пользователя         │ │ │</pre>
                  └─────────────────────────────────┘ └─┘

FIA_ATD.1 «Определение атрибутов пользователя» позволяет поддерживать атрибуты безопасности пользователя для каждого пользователя индивидуально.

11.2.3 Управление: FIA_ATD.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

11.2.4 Аудит: FIA_ATD.1

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

11.2.5 FIA_ATD.1 Определение атрибутов пользователя

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

11.2.5.1 FIA_ATD.1.1

#ФБО должны поддерживать для каждого пользователя следующий список атрибутов безопасности: [назначение: &список атрибутов безопасности&]#.

11.3. Спецификация секретов (FIA_SOS)

11.3.1 Характеристика семейства

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

11.3.2 Ранжирование компонентов

                                                     ┌─┐
                                                   ┌─┤1│
                   ┌─────────────────────────────┐ │ └─┘
                   │FIA_SOS Спецификация секретов├─┤
                   └─────────────────────────────┘ │ ┌─┐
                                                   └─┤2│
                                                     └─┘

FIA_SOS.1 «Верификация секретов» содержит требование, чтобы ФБО верифицировали, отвечают ли секреты определенной метрике качества.

FIA_SOS.2 «Генерация секретов ФБО» содержит требование, чтобы ФБО были способны генерировать секреты, отвечающие определенной метрике качества.

11.3.3 Управление: FIA_SOS.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

11.3.4 Управление: FIA_SOS.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление метрикой, используемой при генерации секретов.

11.3.5 Аудит: FIA_SOS.1, FIA_SOS.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: отклонение ФБО любого проверенного секрета;

b) базовый: отклонение или принятие ФБО любого проверенного секрета;

c) детализированный: идентификация любых изменений заданных метрик качества.

11.3.6 FIA_SOS.1 Верификация секретов

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

11.3.6.1 FIA_SOS.1.1

#ФБО должны предоставлять механизм для верификации того, что секреты соответствуют [назначение: &определенная метрика качества&]#.

11.3.7 FIA_SOS.2 Генерация секретов ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

11.3.7.1 FIA_SOS.2.1

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

11.3.7.2 FIA_SOS.2.2

#ФБО должны быть способны использовать генерируемые ими секреты для [назначение: &список функций ФБО&]#.

11.4. Аутентификация пользователя (FIA_UAU)

11.4.1 Характеристика семейства

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

11.4.2 Ранжирование компонентов

                                                        ┌─┐ ┌─┐
                                                 ┌──────┤1├─┤2│
                                                 │  ┌─┐ └─┘ └─┘
                                                 ├──┤3│
                                                 │  └─┘ ┌─┐
                                                 ├──────┤4│
           ┌───────────────────────────────────┐ │      └─┘
           │FIA_UAU Аутентификация пользователя├─┤
           └───────────────────────────────────┘ │  ┌─┐
                                                 ├──┤5│
                                                 │  └─┘ ┌─┐
                                                 ├──────┤6│
                                                 │  ┌─┐ └─┘
                                                 └──┤7│
                                                    └─┘

FIA_UAU.1 «Выбор момента аутентификации» позволяет пользователю выполнить некоторые действия до аутентификации пользователя.

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

FIA_UAU.3 «Аутентификация, защищенная от подделок» содержит требование, чтобы механизм аутентификации был способен выявить аутентификационные данные, которые были фальсифицированы или скопированы, и предотвратить их использование.

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

FIA_UAU.5 «Сочетание механизмов аутентификации» содержит требование предоставления и применения различных механизмов аутентификации пользователей в особых случаях.

FIA_UAU.6 «Повторная аутентификация» содержит требование возможности определения событий, при которых необходима повторная аутентификация пользователя.

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

11.4.3 Управление: FIA_UAU.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

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

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

11.4.4 Управление: FIA_UAU.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

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

11.4.5 Управление: FIA_UAU.3, FIA_UAU.4, FIA_UAU.7

Действия по управлению не предусмотрены.

11.4.6 Управление: FIA_UAU.5

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление механизмами аутентификации;

b) управление правилами аутентификации.

11.4.7 Управление: FIA_UAU.6

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

11.4.8 Аудит: FIA_UAU.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

b) базовый: все случаи использования механизма аутентификации;

c) детализированный: все действия при посредничестве ФБО до аутентификации пользователя.

11.4.9 Аудит: FIA_UAU.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

11.4.10 Аудит: FIA_UAU.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обнаружение фальсифицированных аутентификационных данных;

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

11.4.11 Аудит: FIA_UAU.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: попытки повторного использования аутентификационных данных.

11.4.12 Аудит: FIA_UAU.5

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: итоговое решение по аутентификации;

b) базовый: результат действия каждого активизированного механизма вместе с итоговым решением.

11.4.13 Аудит: FIA_UAU.6

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: неуспешная повторная аутентификация;

b) базовый: все попытки повторной аутентификации.

11.4.14 Аудит: FIA_UAU.7

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

11.4.15 FIA_UAU.1 Выбор момента аутентификации

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UID.1 Выбор момента идентификации

11.4.15.1 FIA_UAU.1.1

#ФБО должны допускать выполнение [назначение: &список действий, выполняемых при посредничестве ФБО&] от имени пользователя, прежде чем пользователь аутентифицирован#.

11.4.15.2 FIA_UAU.1.2

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

11.4.16 FIA_UAU.2 Аутентификация до любых действий пользователя

Иерархический для: FIA_UAU.1 Выбор момента аутентификации

Зависимости: FIA_UID.1 Выбор момента идентификации

11.4.16.1 FIA_UAU.2.1

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

11.4.17 FIA_UAU.3 Аутентификация, защищенная от подделок

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

11.4.17.1 FIA_UAU.3.1

#ФБО должны [выбор: &обнаруживать, предотвращать&] применение любым пользователем ФБО аутентификационных данных, которые были подделаны#.

11.4.17.2 FIA_UAU.3.2

#ФБО должны [выбор: &обнаруживать, предотвращать&] применение любым пользователем ФБО аутентификационных данных, которые были скопированы у любого другого пользователя ФБО#.

11.4.18 FIA_UAU.4 Механизмы одноразовой аутентификации

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

11.4.18.1 FIA_UAU.4.1

#ФБО должны предотвращать повторное применение аутентификационных данных, связанных с [назначение: &идентифицированный механизм (механизмы) аутентификации&]#.

11.4.19 FIA_UAU.5 Сочетание механизмов аутентификации

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

11.4.19.1 FIA_UAU.5.1

#ФБО должны предоставлять [назначение: &список сочетаемых механизмов аутентификации&] для поддержки аутентификации пользователя#.

11.4.19.2 FIA_UAU.5.2

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

11.4.20 FIA_UAU.6 Повторная аутентификация

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

11.4.20.1 FIA_UAU.6.1

#ФБО должны повторно аутентифицировать пользователя при [назначение: &список условий, при которых требуется повторная аутентификация&]#.

11.4.21 FIA_UAU.7 Аутентификация с защищенной обратной связью

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UAU.1 Выбор момента аутентификации

11.4.21.1 FIA_UAU.7.1

#ФБО должны предоставлять пользователю только [назначение: &список допустимой информации обратной связи&] во время выполнения аутентификации#.

11.5. Идентификация пользователя (FIA_UID)

11.5.1 Характеристика семейства

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

11.5.2 Ранжирование компонентов

               ┌──────────────────────────────────┐ ┌─┐ ┌─┐
               │FIA_UID Идентификация пользователя├─┤1├─┤2│
               └──────────────────────────────────┘ └─┘ └─┘

FIA_UID.1 «Выбор момента идентификации» позволяет пользователю выполнить некоторые действия перед своей идентификацией с использованием ФБО.

FIA_UID.2 «Идентификация до любых действий пользователя» содержит требование, чтобы пользователи идентифицировали себя прежде, чем ФБО позволят им предпринимать какие-либо действия.

11.5.3 Управление: FIA_UID.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

b) управление списком действий, если уполномоченный администратор может изменять действия, разрешенные до идентификации.

11.5.4 Управление: FIA_UID.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление идентификаторами пользователей.

11.5.5 Аудит: FIA_UID.1, FIA_UID.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

11.5.6 FIA_UID.1 Выбор момента идентификации

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

11.5.6.1 FIA_UID.1.1

#ФБО должны допускать [назначение: &список действий, выполняемых при посредничестве ФБО&] от имени пользователя прежде, чем он идентифицирован#.

11.5.6.2 FIA_UID.1.2

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

11.5.7 FIA_UID.2 Идентификация до любых действий пользователя

Иерархический для: FIA_UID.1 Выбор момента идентификации

Зависимости: нет зависимостей.

11.5.7.1 FIA_UID.2.1

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

11.6. Связывание пользователь-субъект (FIA_USB)

11.6.1 Характеристика семейства

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

11.6.2 Ранжирование компонентов

               ┌───────────────────────────────────────┐ ┌─┐
               │FIA_USB Связывание пользователь-субъект├─┤1│
               └───────────────────────────────────────┘ └─┘

FIA_USB.1 «Связывание пользователь-субъект» требует спецификации каких-либо правил, определяющих ассоциацию между атрибутами пользователя и атрибутами субъекта, в которые они отображаются.

11.6.3 Управление: FIA_USB.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

b) изменение уполномоченным администратором атрибутов безопасности субъекта.

11.6.4 Аудит: FIA_USB.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

11.6.5 FIA_USB.1 Связывание пользователь-субъект

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_ATD.1 Определение атрибутов пользователя

11.6.5.1 FIA_USB.1.1

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

11.6.5.2 FIA_USB.1.2

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

11.6.5.3 FIA_USB.1.3

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

12. Класс FMT. Управление безопасностью

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

Класс FMT позволяет решать следующие задачи:

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

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

c) управление функциями из числа ФБО, которое включает в себя, например, выбор функций, а также правил или условий, влияющих на режим выполнения ФБО;

d) определение ролей безопасности.

               ┌──────────────────────────────┐   ┌─┐
               │FMT_MOF Управление отдельными ├───┤1│
<pre class="legal-pre">               │         функциями ФБО        │   │ │
               └──────────────────────────────┘   └─┘</pre>
                                                    ┌─┐
                                                ┌───┤1│
               ┌──────────────────────────────┐ │   └─┘  ┌─┐
               │FMT_MSA Управление атрибутами ├─┼────────┤2│
               │         безопасности         │ │   ┌─┐  └─┘
               └──────────────────────────────┘ └───┤3│
                                                    └─┘
                                                    ┌─┐
                                                ┌───┤1│
               ┌──────────────────────────────┐ │   └─┘  ┌─┐
               │FMT_MTD Управление данными ФБО├─┼────────┤2│
               └──────────────────────────────┘ │   ┌─┐  └─┘
                                                └───┤3│
                                                    └─┘
<pre class="legal-pre">               ┌──────────────────────────────┐   ┌─┐
               │         FMT_REV Отмена       ├───┤1│
               └──────────────────────────────┘   └─┘
               ┌──────────────────────────────┐   ┌─┐</pre>
               │FMT_SAE Срок действия атрибута├───┤1│
<pre class="legal-pre">               │         безопасности         │   │ │
               └──────────────────────────────┘   └─┘
               ┌──────────────────────────────┐   ┌─┐</pre>
               │ FMT_SMF Спецификация функций ├───┤1│
<pre class="legal-pre">               │         безопасности         │   │ │
               └──────────────────────────────┘   └─┘
                                                  ┌─┐    ┌─┐</pre>
                                                ┌─┤1├────┤2│
<pre class="legal-pre">               ┌──────────────────────────────┐ │ └─┘    └─┘
               │    FMT_SMR Роли управления   ├─┤ ┌─┐
               │         безопасностью        │ └─┤3│
               └──────────────────────────────┘   └─┘</pre>

12.1. Управление отдельными функциями ФБО (FMT_MOF)

12.1.1 Характеристика семейства

Семейство FMT_MOF позволяет уполномоченным пользователям управлять функциями из числа ФБО. К ним относятся, например, функции аудита и аутентификации.

12.1.2 Ранжирование компонентов

             ┌───────────────────────────────────────────┐ ┌─┐
             │FMT_MOF Управление отдельными функциями ФБО├─┤1│
             └───────────────────────────────────────────┘ └─┘

FMT_MOF.1 «Управление режимом выполнения функций безопасности» позволяет уполномоченным пользователям (ролям) управлять режимом выполнения функций из числа ФБО, использующих правила или предусматривающих определенные условия, которыми можно управлять.

12.1.3 Управление: FMT_MOF.1

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

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

12.1.4 Аудит: FMT_MOF.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

12.1.5 FMT_MOF.1 Управление режимом выполнения функций безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: FMT_SMR.1 Роли безопасности

FMT_SMF.1 Спецификация функций управления

12.1.5.1 FMT_MOF.1.1

#ФБО должны предоставлять возможность [выбор: &определять режим выполнения, отключать, подключать, модифицировать режим выполнения&] функций [назначение: &список функций&] только [назначение: &уполномоченные идентифицированные роли&]#.

12.2. Управление атрибутами безопасности (FMT_MSA)

12.2.1 Характеристика семейства

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

12.2.2 Ранжирование компонентов

                                                         ┌─┐
                                                        ┌┤1│
           ┌──────────────────────────────────────────┐ │└─┘ ┌─┐
           │FMT_MSA Управление атрибутами безопасности├─┼────┤2│
           └──────────────────────────────────────────┘ │┌─┐ └─┘
                                                        └┤3│
                                                         └─┘

FMT_MSA.1 «Управление атрибутами безопасности» позволяет уполномоченным пользователям (ролям) управлять определенными атрибутами безопасности.

FMT_MSA.2 «Безопасные значения атрибутов безопасности» обеспечивает, чтобы значения, присвоенные атрибутам безопасности, были допустимы по безопасности.

FMT_MSA.3 «Инициализация статических атрибутов» обеспечивает, чтобы значения атрибутов безопасности по умолчанию являлись по сути разрешающими либо ограничительными.

12.2.3 Управление: FMT_MSA.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

12.2.4 Управление: FMT_MSA.2

Действия по управлению не предусмотрены.

12.2.5 Управление: FMT_MSA.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

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

12.2.6 Аудит: FMT_MSA.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: все модификации значений атрибутов безопасности.

12.2.7 Аудит: FMT_MSA.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

b) детализированный: все предлагаемые и принятые безопасные значения атрибутов безопасности.

12.2.8 Аудит: FMT_MSA.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

12.2.9 FMT_MSA.1 Управление атрибутами безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

FMT_SMR.1 Роли безопасности

FMT_SMF.1 Спецификация функций управления

12.2.9.1 FMT_MSA.1.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом, ПФБ управления информационными потоками&], предоставляющую возможность [выбор: &изменять значения по умолчанию, запрашивать, модифицировать, удалять& [назначение: &другие операции&] атрибуты безопасности [назначение: &список атрибутов безопасности&] только [назначение: &уполномоченные идентифицированные роли&]#.

12.2.10 FMT_MSA.2 Безопасные значения атрибутов безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: ADV_SPM.1 Неформальная модель политики безопасности ОО

[FDP_ACC.1 Ограниченное управление доступом или

FDP_IFC.1 Ограниченное управление информационными потоками]

FMT_MSA.1 Управление атрибутами безопасности

FMT_SMR.1 Роли безопасности

12.2.10.1 FMT_MSA.2.1

#ФБО должны обеспечивать присвоение атрибутам безопасности только безопасных значений#.

12.2.11 FMT_MSA.3 Инициализация статических атрибутов

Иерархический для: нет подчиненных компонентов.

Зависимости: FMT_MSA.1 Управление атрибутами безопасности

FMT_SMR.1 Роли безопасности

12.2.11.1 FMT_MSA.3.1

#ФБО должны осуществлять [назначение: &ПФБ управления доступом, ПФБ управления информационными потоками&], предусматривающую [выбор (выбрать одно из): &ограничительные, разрешающие, другие свойства&] значений по умолчанию для атрибутов безопасности, которые используются для осуществления ПФБ#.

12.2.11.2 FMT_MSA.3.2

#ФБО должны позволять [назначение: &уполномоченные идентифицированные роли&] определять альтернативные начальные значения для отмены значений по умолчанию при создании объекта или информации#.

12.3. Управление данными ФБО (FMT_MTD)

12.3.1 Характеристика семейства

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

12.3.2 Ранжирование компонентов

                                                   ┌─┐
                                                  ┌┤1│
                 ┌──────────────────────────────┐ │└─┘ ┌─┐
                 │FMT_MTD Управление данными ФБО├─┼────┤2│
                 └──────────────────────────────┘ │┌─┐ └─┘
                                                  └┤3│
                                                   └─┘

FMT_MTD.1 «Управление данными ФБО» позволяет уполномоченным пользователям управлять данными ФБО.

FMT_MTD.2 «Управление ограничениями данных ФБО» определяет действия, предпринимаемые при достижении или превышении ограничений данных ФБО.

FMT_MTD.3 «Безопасные данные ФБО» обеспечивает, чтобы значения, присвоенные данным ФБО, были допустимы по безопасности.

12.3.3 Управление: FMT_MTD.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление группой ролей, которые могут оперировать данными ФБО.

12.3.4 Управление: FMT_MTD.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление группой ролей, которые могут оперировать ограничениями данных ФБО.

12.3.5 Управление: FMT_MTD.3

Действия по управлению не предусмотрены.

12.3.6 Аудит: FMT_MTD.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: все модификации значений данных ФБО.

12.3.7 Аудит: FMT_MTD.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: все модификации ограничений данных ФБО;

b) базовый: все модификации действий, предпринимаемых при нарушениях ограничений.

12.3.8 Аудит: FMT_MTD.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: все отклоненные значения данных ФБО.

12.3.9 FMT_MTD.1 Управление данными ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: FMT_SMR.1 Роли безопасности

FMT_SMF.1 Спецификация функций управления

12.3.9.1 FMT_MTD.1.1

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

12.3.10 FMT_MTD.2 Управление ограничениями данных ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: FMT_MTD.1 Управление данными ФБО

FMT_SMR.1 Роли безопасности

12.3.10.1 FMT_MTD.2.1

#ФБО должны предоставлять возможность определения ограничений для [назначение: &список данных ФБО&] только [назначение: &уполномоченные идентифицированные роли&]#.

12.3.10.2 FMT_MTD.2.2

#ФБО должны предпринимать следующие действия при достижении или превышении данными ФБО установленных выше ограничений: [назначение: &предпринимаемые действия&]#.

12.3.11 FMT_MTD.3 Безопасные данные ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: ADV_SPM.1 Неформальная модель политики безопасности ОО

FMT_MTD.1 Управление данными ФБО

12.3.11.1 FMT_MTD.3.1

#ФБО должны обеспечивать присвоение данным ФБО только безопасных значений#.

12.4. Отмена (FMT_REV)

12.4.1 Характеристика семейства

Семейство FMT_REV связано с отменой атрибутов безопасности различных сущностей в пределах ОО.

12.4.2 Ранжирование компонентов

                            ┌──────────────┐ ┌─┐
                            │FMT_REV Отмена├─┤1│
                            └──────────────┘ └─┘

FMT_REV.1 «Отмена» предусматривает отмену атрибутов безопасности, осуществляемую в некоторый момент времени.

12.4.3 Управление: FMT_REV.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление группой ролей, которые могут вызывать отмену атрибутов безопасности;

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

c) управление правилами отмены.

12.4.4 Аудит: FMT_REV.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: неуспешная отмена атрибутов безопасности;

b) базовый: все попытки отменить атрибуты безопасности.

12.4.5 FMT_REV.1 Отмена

Иерархический для: нет подчиненных компонентов.

Зависимости: FMT_SMR.1 Роли безопасности

12.4.5.1 FMT_REV.1.1

#ФБО должны предоставлять возможность отмены атрибутов безопасности, ассоциированных с [выбор: &пользователи, субъекты, объекты [назначение: другие дополнительные ресурсы]&], в пределах ОДФ только [назначение: &уполномоченные идентифицированные роли&]#.

12.4.5.2 FMT_REV.1.2

#ФБО должны осуществлять правила [назначение: &правила отмены&]#.

12.5. Срок действия атрибута безопасности (FMT_SAE)

12.5.1 Характеристика семейства

Семейство FMT_SAE связано с возможностью установления срока действия атрибутов безопасности.

12.5.2 Ранжирование компонентов

             ┌───────────────────────────────────────────┐ ┌─┐
             │FMT_SAE Срок действия атрибута безопасности├─┤1│
             └───────────────────────────────────────────┘ └─┘

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

12.5.3 Управление: FMT_SAE.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

b) предпринимаемые по истечении назначенного срока действия.

12.5.4 Аудит: FMT_SAE.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: назначение срока действия для атрибута;

b) базовый: действия, предпринятые по истечении назначенного срока.

12.5.5 FMT_SAE.1 Ограниченная по времени авторизация

Иерархический для: нет подчиненных компонентов.

Зависимости: FMT_SMR.1 Роли безопасности

FPT_STM.1 Надежные метки времени

12.5.5.1 FMT_SAE.1.1

#ФБО должны предоставлять возможность назначать срок действия для [назначение: &список атрибутов безопасности, для которых предусмотрено установление срока действия&] только [назначение: &идентифицированные уполномоченные роли&]#.

12.5.5.2 FMT_SAE.1.2

#Для каждого из этих атрибутов безопасности ФБО должны быть способны к [назначение: &список действий, предпринимаемых для каждого атрибута безопасности&] по истечении его срока действия#.

12.6. Спецификация функций управления (FMT_SMF)

12.6.1 Характеристика семейства

Семейство FMT_SMF позволяет специфицировать функции управления, предоставляемые ОО. Функции управления предоставляют ИФБО, который позволяет администраторам определять параметры управления функционированием ОО в части аспектов, относящихся к безопасности, например, атрибуты защиты данных, атрибуты защиты ОО, атрибуты аудита, атрибуты идентификации и аутентификации. Функции управления также включают в себя функции, выполняемые операторами для обеспечения непрерывной работы ОО, такие как резервирование и восстановление. Данное семейство используется совместно с другими компонентами из класса FMT «Управление безопасностью»: компонент из этого семейства предусматривает наличие функций управления, а другие семейства из класса FMT «Управление безопасностью» накладывают ограничения на возможность использования этих функций управления.

12.6.2 Ранжирование компонентов

               ┌───────────────────────────────────────┐ ┌─┐
               │FMT_SMF Спецификация функций управления├─┤1│
               └───────────────────────────────────────┘ └─┘

FMT_SMF.1 «Спецификация функций управления» требует, чтобы ФБО предоставляли конкретные функции управления.

12.6.3 Управление FMT_SMF.1

Действия по управлению не предусмотрены.

12.6.4 Аудит FMT_SMF.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: использование функций управления.

12.6.5 FMT_SMF.1 Спецификация функций управления

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

12.6.5.1 FMT_SMF.1.1

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

12.7. Роли управления безопасностью (FMT_SMR)

12.7.1 Характеристика семейства

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

12.7.2 Ранжирование компонентов

                                                       ┌─┐ ┌─┐
                                                     ┌─┤1├─┤2│
             ┌─────────────────────────────────────┐ │ └─┘ └─┘
             │FMT_SMR Роли управления безопасностью├─┤
             └─────────────────────────────────────┘ │ ┌─┐
                                                     └─┤3│
                                                       └─┘

FMT_SMR.1 «Роли безопасности» определяет роли, относящиеся к безопасности и распознаваемые ФБО.

FMT_SMR.2 «Ограничения на роли безопасности» определяет, что в дополнение к определению ролей имеются правила, управляющие отношениями между ролями.

FMT_SMR.3 «Принятие ролей» содержит требование, чтобы принятие роли производилось только через явный запрос к ФБО.

12.7.3 Управление: FMT_SMR.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление группой пользователей — исполнителей роли.

12.7.4 Управление: FMT_SMR.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление группой пользователей — исполнителей роли;

b) управление условиями, которым должны удовлетворять роли.

12.7.5 Управление: FMT_SMR.3

Действия по управлению не предусмотрены.

12.7.6 Аудит: FMT_SMR.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: модификация группы пользователей — исполнителей роли;

b) детализированный: каждое использование прав, предоставленных ролью.

12.7.7 Аудит: FMT_SMR.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: модификация в группе пользователей — исполнителей роли;

b) минимальный: неуспешные попытки использовать роль вследствие ограничений, накладываемых на роли;

c) детализированный: каждое использование прав, предоставленных ролью.

12.7.8 Аудит: FMT_SMR.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: конкретные запросы на принятие роли.

12.7.9 FMT_SMR.1 Роли безопасности

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UID.1 Выбор момента идентификации

12.7.9.1 FMT_SMR.1.1

#ФБО должны поддерживать следующие роли [назначение: &уполномоченные идентифицированные роли&]#.

12.7.9.2 FMT_SMR.1.2

#ФБО должны быть способны ассоциировать пользователей с ролями#.

12.7.10 FMT_SMR.2 Ограничения на роли безопасности

Иерархический для: FMT_SMR.1 Роли безопасности

Зависимости: FIA_UID.1 Выбор момента идентификации

12.7.10.1 FMT_SMR.2.1

ФБО должны поддерживать следующие роли [назначение: уполномоченные идентифицированные роли].

12.7.10.2 FMT_SMR.2.2

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

12.7.10.3 FMT_SMR.2.3

#ФБО должны обеспечивать, чтобы условия [назначение: &условия для различных ролей&] удовлетворялись#.

12.7.11 FMT_SMR.3 Принятие ролей

Иерархический для: нет подчиненных компонентов.

Зависимости: FMT_SMR.1 Роли безопасности

12.7.11.1 FMT_SMR.3.1

#ФБО должны требовать явный запрос для принятия следующих ролей [назначение: &список ролей&]#.

13. Класс FPR. Приватность

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

<pre class="legal-pre">                  ┌──────────────────────┐ ┌─┐   ┌─┐
                  │ FPR_ANO Анонимность  ├─┤1├───┤2│
                  └──────────────────────┘ └─┘   └─┘</pre>
                                                 ┌─┐
                                               ┌─┤2│
                  ┌──────────────────────┐ ┌─┐ │ └─┘
                  │FPR_PSE Псевдонимность├─┤1├─┤
                  └──────────────────────┘ └─┘ │ ┌─┐
                                               └─┤3│
                  ┌──────────────────────┐ ┌─┐   └─┘
                  │FPR_UNL Невозможность ├─┤1│
                  │     ассоциации       │ │ │
                  └──────────────────────┘ └─┘
                                                  ┌─┐  ┌─┐
                                           ┌──────┤1├──┤2│
                                           │      └─┘  └─┘
                  ┌──────────────────────┐ │ ┌─┐
                  │  FPR_UNO Скрытность  ├─┼─┤3│
                  └──────────────────────┘ │ └─┘
                                           │      ┌─┐
                                           └──────┤4│
                                                  └─┘

Рисунок 51. Декомпозиция класса FPR "Приватность"

13.1. Анонимность (FPR_ANO)

13.1.1. Характеристика семейства
Семейство FPR_ANO обеспечивает пользователю возможность использовать ресурс или услугу ОО без раскрытия своего идентификатора. Требования семейства предоставляют защиту идентификатора пользователя. Семейство не предназначено для защиты идентификаторов субъектов.

13.1.2. Ранжирование компонентов

                 ┌────────────────────────────────┐ ┌─┐ ┌─┐
                 │       FPR_ANO Анонимность      ├─┤1├─┤2│
                 └────────────────────────────────┘ └─┘ └─┘

FPR_ANO.1 «Анонимность» содержит требование, чтобы другие пользователи или субъекты не могли определить идентификатор пользователя, связанного с субъектом или операцией.

FPR_ANO.2 «Анонимность без запроса информации» расширяет требования FPR_ANO.1 «Анонимность», обеспечивая, чтобы ФБО не запрашивали идентификатор пользователя.

13.1.3 Управление: FPR_ANO.1, FPR_ANO.2

Действия по управлению не предусмотрены.

13.1.4 Аудит: FPR_ANO.1, FPR_ANO.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обращение к механизму анонимности.

13.1.5 FPR_ANO.1 Анонимность

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

13.1.5.1 FPR_ANO.1.1

#ФБО должны обеспечивать, чтобы [назначение: &совокупность пользователей и/или субъектов&] была не способна определить подлинное имя пользователя, связанного с [назначение: &список субъектов и/или операций, и/или объектов&]#.

13.1.6 FPR_ANO.2 Анонимность без запроса информации

Иерархический для: FPR_ANO.1 Анонимность

Зависимости: нет зависимостей.

13.1.6.1 FPR_ANO.2.1

ФБО должны обеспечивать, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить подлинное имя пользователя, связанного с [назначение: список субъектов и/или операций, и/или объектов].

13.1.6.2 FPR_ANO.2.2

#ФБО должны предоставлять [назначение: &список услуг&] для [назначение: &список субъектов&] без запроса какой-либо ссылки на подлинное имя пользователя#.

13.2. Псевдонимность (FPR_PSE)

13.2.1 Характеристика семейства

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

13.2.2 Ранжирование компонентов

                                                    ┌─┐
                                                  ┌─┤2│
                     ┌──────────────────────┐ ┌─┐ │ └─┘
                     │FPR_PSE Псевдонимность├─┤1├─┤
                     └──────────────────────┘ └─┘ │ ┌─┐
                                                  └─┤3│
                                                    └─┘

FPR_PSE.1 «Псевдонимность» содержит требование, чтобы некоторая совокупность пользователей и/или субъектов была не способна определить идентификатор пользователя, связанного с субъектом или операцией, но в то же время этот пользователь оставался ответственным за свои действия.

FPR_PSE.2 «Обратимая псевдонимность» содержит требование, чтобы ФБО предоставили возможность определить первоначальный идентификатор пользователя, основываясь на представленном псевдониме.

FPR_PSE.3 «Альтернативная псевдонимность» содержит требование, чтобы при создании псевдонима для идентификатора пользователя ФБО следовали определенным правилам.

13.2.3 Управление: FPR_PSE.1, FPR_PSE.2, FPR_PSE.3

Действия по управлению не предусмотрены.

13.2.4 Аудит: FPR_PSE.1, FPR_PSE.2, FPR_PSE.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

13.2.5 FPR_PSE.1 Псевдонимность

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

13.2.5.1 FPR_PSE.1.1

#ФБО должны обеспечивать, чтобы [назначение: &совокупность пользователей и/или субъектов&] была не способна определять подлинное имя пользователя, связанного с [назначение: &список субъектов и/или операций, и/или объектов&]#.

13.2.5.2 FPR_PSE.1.2

#ФБО должны быть способны предоставлять [назначение: &число псевдонимов&] псевдонимов подлинного имени пользователя для [назначение: &список субъектов&]#.

13.2.5.3 FPR_PSE.1.3

#ФБО должны быть способны [выбор (выбрать одно из): &определять псевдоним пользователя, принимать псевдоним от пользователя&] и верифицировать его соответствие [назначение: &метрика псевдонимов&]#.

13.2.6 FPR_PSE.2 Обратимая псевдонимность

Иерархический для: FPR_PSE.1 Псевдонимность

Зависимости: FIA_UID.1 Выбор момента идентификации

13.2.6.1 FPR_PSE.2.1

ФБО должны обеспечивать, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определять подлинное имя пользователя, связанное с [назначение: список субъектов и/или операций, и/или объектов].

13.2.6.2 FPR_PSE.2.2

ФБО должны быть способны предоставлять [назначение: число псевдонимов] псевдонимов подлинного имени пользователя для [назначение: список субъектов].

13.2.6.3 FPR_PSE.2.3

ФБО должны быть способны [выбор (выбрать одно из): определять псевдоним пользователя, принимать псевдоним от пользователя] и верифицировать его соответствие [назначение: метрика псевдонимов].

13.2.6.4 FPR_PSE.2.4

#ФБО должны предоставлять [выбор: &уполномоченный пользователь& [&назначение: список доверенных субъектов]&] возможность определять идентификатор пользователя по представленному псевдониму только при выполнении [назначение: &список условий&]#.

13.2.7 FPR_PSE.3 Альтернативная псевдонимность

Иерархический для: FPR_PSE.1 Псевдонимность

Зависимости: нет зависимостей.

13.2.7.1 FPR_PSE.3.1

ФБО должны обеспечивать, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определять подлинное имя пользователя, связанное с [назначение: список субъектов и/или операций, и/или объектов].

13.2.7.2 FPR_PSE.3.2

ФБО должны быть способны предоставлять [назначение: число псевдонимов] псевдонимов подлинного имени пользователя для [назначение: список субъектов].

13.2.7.3 FPR_PSE.3.3

ФБО должны быть способны [выбор (выбрать одно из): определять псевдоним пользователя, принимать псевдоним от пользователя] и верифицировать его соответствие [назначение: метрика псевдонимов].

13.2.7.4 FPR_PSE.3.4

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

13.3. Невозможность ассоциации (FPR_UNL)

13.3.1 Характеристика семейства

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

                  ┌────────────────────────────────┐ ┌─┐
                  │FPR_UNL Невозможность ассоциации├─┤1│
                  └────────────────────────────────┘ └─┘

13.3.2 Ранжирование компонентов

FPR_UNL.1 «Невозможность ассоциации» содержит требование, чтобы пользователи и/или субъекты были не способны определить, инициированы ли определенные операции в системе одним и тем же пользователем.

13.3.3 Управление: FPR_UNL.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление функцией предотвращения ассоциации.

13.3.4 Аудит: FPR_UNL.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обращение к механизму предотвращения ассоциации.

13.3.5 FPR_UNL.1 Невозможность ассоциации

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

13.3.5.1 FPR_UNL.1.1

#ФБО должны обеспечивать, чтобы [назначение: &совокупность пользователей и/или субъектов&] была не способна определять, что [назначение: &список операций&] [выбор: &были инициированы одним и тем же пользователем, связаны следующим образом [назначение: список соотношений]&]#.

13.4. Скрытность (FPR_UNO)

13.4.1 Характеристика семейства

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

13.4.2 Ранжирование компонентов

                                                ┌─┐ ┌─┐
                                          ┌─────┤1├─┤2│
                    ┌──────────────────┐  │ ┌─┐ └─┘ └─┘
                    │FPR_UNO Скрытность├──┼─┤3│
                    └──────────────────┘  │ └─┘ ┌─┐
                                          └─────┤4│
                                                └─┘

FPR_UNO.1 «Скрытность» содержит требование, чтобы пользователи и/или субъекты не могли определить, выполняется ли операция.

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

FPR_UNO.3 «Скрытность без запроса информации» содержит требование, чтобы ФБО не пытались получить информацию, связанную с приватностью, что может использоваться для нарушения скрытности.

FPR_UNO.4 «Открытость для уполномоченного пользователя» содержит требование, чтобы ФБО предоставили одному или нескольким уполномоченным пользователям возможность наблюдать за использованием ресурсов и/или услуг.

13.4.3 Управление: FPR_UNO.1, FPR_UNO.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление режимом выполнения функции скрытности.

13.4.4 Управление: FPR_UNO.3

Действия по управлению не предусмотрены.

13.4.5 Управление: FPR_UNO.4

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

13.4.6 Аудит: FPR_UNO.1, FPR_UNO.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обращение к механизму скрытности.

13.4.7 Аудит: FPR_UNO.3

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

13.4.8 Аудит: FPR_UNO.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: наблюдение за использованием ресурса или услуги пользователем или субъектом.

13.4.9 FPR_UNO.1 Скрытность

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

13.4.9.1 FPR_UNO.1.1

#ФБО должны обеспечивать, чтобы [назначение: &совокупность пользователей и/или субъектов&] была не способна наблюдать следующие операции [назначение: &список операций&] на [назначение: &список объектов&], выполняемые [назначение: &совокупность защищаемых пользователей и/или субъектов&]#.

13.4.10 FPR_UNO.2 Распределение информации, влияющее на скрытность

Иерархический для: FPR_UNO.1 Скрытность

Зависимости: нет зависимостей

13.4.10.1 FPR_UNO.2.1

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

13.4.10.2 FPR_UNO.2.2

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

13.4.11 FPR_UNO.3 Скрытность без запроса информации

Иерархический для: нет подчиненных компонентов.

Зависимости: FPR_UNO.1 Скрытность

13.4.11.1 FPR_UNO.3.1

#ФБО должны предоставлять [назначение: &список услуг&] для [назначение: &список субъектов&] без запроса каких-либо ссылок на [назначение: &информация, связанная с приватностью&]#.

13.4.12 FPR_UNO.4 Открытость для уполномоченного пользователя

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей

13.4.12.1 FPR_UNO.4.1

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

14. Класс FPT. Защита ФБО

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

В рамках данного класса выделяют три важные составные части ФБО:

1. абстрактная машина ФБО, то есть виртуальная или физическая машина, на которой выполняется оцениваемая реализация ФБО;

2. реализация ФБО, которая выполняется на абстрактной машине и реализует механизмы, осуществляющие ПБО;

3. данные ФБО, которые являются административными базами данных, управляющими осуществлением ПБО.

14.1. Тестирование базовой абстрактной машины (FPT_AMT)

14.1.1 Характеристика семейства

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

14.1.2 Ранжирование компонентов

               ┌───────────────────────────────────────┐ ┌─┐
<pre class="legal-pre">               │     FPT_AMT Тестирование базовой      ├─┤1│
               │          абстрактной машины           │ │ │</pre>
               └───────────────────────────────────────┘ └─┘

FPT_AMT.1 «Тестирование абстрактной машины» предоставляет возможность проверки базовой абстрактной машины.

14.1.3 Управление: FPT_AMT.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

b) управление временным интервалом (при необходимости).

14.1.4 Аудит: FPT_AMT.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: выполнение тестирования базовой машины и результаты тестирования.

14.1.5 FPT_AMT.1 Тестирование абстрактной машины

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.1.5.1 FPT_AMT.1.1

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

14.2. Безопасность при сбое (FPT_FLS)

14.2.1 Характеристика семейства

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

14.2.2 Ранжирование компонентов

                ┌──────────────────────────────────────┐ ┌─┐
                │     FPT_FLS Безопасность при сбое    ├─┤1│
                └──────────────────────────────────────┘ └─┘

Это семейство состоит из одного компонента FPT_FLS.1 «Сбой с сохранением безопасного состояния», содержащего требование, чтобы ФБО сохраняли безопасное состояние при идентифицированных сбоях.

14.2.3 Управление: FPT_FLS.1

Действия по управлению не предусмотрены.

14.2.4 Аудит: FPT_FLS.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: сбой ФБО.

14.2.5 FPT_FLS.1 Сбой с сохранением безопасного состояния

Иерархический для: нет подчиненных компонентов.

Зависимости: ADV_SPM.1 Неформальная модель политики безопасности ОО

14.2.5.1 FPT_FLS.1.1

#ФБО должны сохранять безопасное состояние при следующих типах сбоев: [назначение: &список типов сбоев ФБО&]#.

14.3. Доступность экспортируемых данных ФБО (FPT_ITA)

14.3.1 Характеристика семейства

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

14.3.2 Ранжирование компонентов

              ┌───────────────────────────────────────┐ ┌─┐
<pre class="legal-pre">              │   FPT_ITA Доступность экспортируемых  ├─┤1│
              │                 данных ФБО            │ │ │</pre>
              └───────────────────────────────────────┘ └─┘

Это семейство состоит из одного компонента FPT_ITA.1 «Доступность экспортируемых данных ФБО в пределах заданной метрики», содержащего требование, чтобы ФБО обеспечили с заданной вероятностью доступность данных ФБО, предоставляемых удаленному доверенному продукту ИТ.

14.3.3 Управление: FPT_ITA.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

14.3.4 Аудит: FPT_ITA.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: отсутствие данных ФБО, когда они запрошены ОО.

14.3.5 FPT_ITA.1 Доступность экспортируемых данных ФБО в пределах заданной метрики

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.3.5.1 FPT_ITA.1.1

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

14.4. Конфиденциальность экспортируемых данных ФБО (FPT_ITC)

14.4.1 Характеристика семейства

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

14.4.2 Ранжирование компонентов

              ┌─────────────────────────────────────────┐ ┌─┐
              │FPT_ITC Конфиденциальность экспортируемых├─┤1│
              │                данных ФБО               │ │ │
              └─────────────────────────────────────────┘ └─┘

Это семейство состоит из одного компонента FPT_ITC.1 «Конфиденциальность экспортируемых данных ФБО при передаче», содержащего требование, чтобы ФБО обеспечили защиту данных, передаваемых между ФБО и удаленным доверенным продуктом ИТ, от раскрытия при передаче.

14.4.3 Управление: FPT_ITC.1

Действия по управлению не предусмотрены.

14.4.4 Аудит: FPT_ITC.1

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

14.4.5 FPT_ITC.1 Конфиденциальность экспортируемых данных ФБО при передаче

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.4.5.1 FPT_ITC.1.1

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

14.5. Целостность экспортируемых данных ФБО (FPT_ITI)

14.5.1 Характеристика семейства

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

14.5.2 Ранжирование компонентов

                ┌──────────────────────────────────┐ ┌─┐ ┌─┐
                │FPT_ITI Целостность экспортируемых├─┤1├─┤2│
                │            данных ФБО            │ │ │ │ │
                └──────────────────────────────────┘ └─┘ └─┘

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

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

14.5.3 Управление: FPT_ITI.1

Действия по управлению не предусмотрены.

14.5.4 Управление: FPT_ITI.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление типами данных ФБО, которые ФБО следует пытаться исправить, если они модифицированы при передаче;

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

14.5.5 Аудит: FPT_ITI.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обнаружение модификации передаваемых данных ФБО;

b) базовый: действия, предпринятые при обнаружении модификации передаваемых данных ФБО.

14.5.6 Аудит: FPT_ITI.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обнаружение модификации передаваемых данных ФБО;

b) базовый: действия, предпринятые при обнаружении модификации передаваемых данных ФБО;

c) базовый: использование механизма восстановления.

14.5.7 FPT_ITI.1 Обнаружение модификации экспортируемых данных ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.5.7.1 FPT_ITI.1.1

#ФБО должны предоставлять возможность обнаруживать модификацию любых данных ФБО при передаче между ФБО и удаленным доверенным продуктом ИТ в пределах следующей метрики: [назначение: &метрика модификации&]#.

14.5.7.2 FPT_ITI.1.2

#ФБО должны предоставлять возможность верифицировать целостность всех данных ФБО при их передаче между ФБО и удаленным доверенным продуктом ИТ и выполнять [назначение: &предпринимаемые действия&], если модификация обнаружена#.

14.5.8 FPT_ITI.2 Обнаружение и исправление модификации экспортируемых данных ФБО

Иерархический для: FPT_ITI.1 Обнаружение модификации экспортируемых данных ФБО

Зависимости: нет зависимостей.

14.5.8.1 FPT_ITI.2.1

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

14.5.8.2 FPT_ITI.2.2

ФБО должны предоставлять возможность верифицировать целостность всех данных ФБО при их передаче между ФБО и удаленным доверенным продуктом ИТ и выполнять [назначение: предпринимаемые действия], если модификация обнаружена.

14.5.8.3 FPT_ITI.2.3

#ФБО должны предоставлять возможность исправлять [назначение: &тип модификации&] все данные ФБО, передаваемые между ФБО и удаленным доверенным продуктом ИТ#.

14.6. Передача данных ФБО в пределах ОО (FPT_ITT)

14.6.1 Характеристика семейства

Семейство FPT_ITT содержит требования защиты данных ФБО при их передаче между разделенными частями ОО по внутреннему каналу.

14.6.2 Ранжирование компонентов

                                                     ┌─┐ ┌─┐
                                                   ┌─┤1├─┤2│
               ┌─────────────────────────────────┐ │ └─┘ └─┘
<pre class="legal-pre">               │   FPT_ITT Передача данных ФБО   ├─┤
               │           в пределах ОО         │ │</pre>
               └─────────────────────────────────┘ │ ┌─┐
                                                   └─┤3│
                                                     └─┘

FPT_ITT. 1 «Базовая защита внутренней передачи данных ФБО» содержит требование, чтобы данные ФБО были защищены при их передаче между разделенными частями ОО.

FPT_ITT.2 «Разделение данных ФБО при передаче» содержит требование, чтобы при передаче ФБО отделяли данные пользователей от данных ФБО.

FPT_ITT.3 «Мониторинг целостности данных ФБО» содержит требование, чтобы данные ФБО, передаваемые между разделенными частями ОО, контролировались на идентифицированные ошибки целостности.

14.6.3 Управление: FPT_ITT.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление типами модификации, от которых ФБО следует защищать передаваемые данные;

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

14.6.4 Управление: FPT_ITT.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление типами модификации, от которых ФБО следует защищать передаваемые данные;

b) управление механизмом, используемым для обеспечения защиты данных при передаче между различными частями ФБО;

c) управление механизмом разделения данных.

14.6.5 Управление: FPT_ITT.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление типами модификации, от которых ФБО следует защищать передаваемые данные;

b) управление механизмом, используемым для обеспечения защиты данных при передаче между различными частями ФБО;

c) управление типами модификации данных ФБО, которые ФБО следует пытаться обнаружить;

d) управление действиями, предпринимаемыми после обнаружения модификации.

14.6.6 Аудит: FPT_ITT.1, FPT_ITT.2

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

14.6.7 Аудит: FPT_ITT.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обнаружение модификации данных ФБО;

b) базовый: действия, предпринятые после обнаружения ошибок целостности.

14.6.8 FPT_ITT.1 Базовая защита внутренней передачи данных ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.6.8.1 FPT_ITT.1.1

#ФБО должны защищать свои данные от [выбор: &раскрытие, модификация&] при их передаче между разделенными частями ОО#.

14.6.9 FPT_ITT.2 Разделение данных ФБО при передаче

Иерархический для: FPT_ITT.1 Базовая защита внутренней передачи данных ФБО.

Зависимости: нет зависимостей.

14.6.9.1 FPT_ITT.2.1

ФБО должны защищать свои данные от [выбор: раскрытие, модификация] при их передаче между разделенными частями ОО.

14.6.9.2 FPT_ITT.2.2

#ФБО должны отделять данные пользователя от данных ФБО при их передаче между разделенными частями ОО#.

14.6.10 FPT_ITT.3 Мониторинг целостности данных ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: FPT_ITT.1 Базовая защита внутренней передачи данных ФБО

14.6.10.1 FPT_ITT.3.1

#ФБО должны быть способны обнаруживать [выбор: &модификация данных, подмена данных, перестановка данных, удаление данных& [назначение: &другие ошибки целостности&] в данных ФБО, передаваемых между разделенными частями ОО#.

14.6.10.2 FPT_ITT.3.2

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

14.7. Физическая защита ФБО (FPT_PHP)

14.7.1 Характеристика семейства

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

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

14.7.2 Ранжирование компонентов

                                                   ┌─┐ ┌─┐
                                                 ┌─┤1├─┤2│
                 ┌─────────────────────────────┐ │ └─┘ └─┘
                 │FPT_PHP Физическая защита ФБО├─┤
                 └─────────────────────────────┘ │ ┌─┐
                                                 └─┤3│
                                                   └─┘

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

FPT_PHP.2 «Оповещение о физическом нападении» обеспечивает автоматическое оповещение о вмешательстве для установленного подмножества физических проникновений.

FPT_PHP.3 «Противодействие физическому нападению» предоставляет возможности предотвращения или противодействия физическому вмешательству в устройства и элементы, реализующие ФБО.

14.7.3 Управление: FPT_PHP.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

14.7.4 Управление: FPT_PHP.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление пользователем или ролью, которые получают информацию о вторжениях;

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

14.7.5 Управление: FPT_PHP.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

14.7.6 Аудит: FPT_PHP.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обнаружение вторжения средствами ИТ.

14.7.7 Аудит: FPT_PHP.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: обнаружение вторжения.

14.7.8 Аудит: FPT_PHP.3

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

14.7.9 FPT_PHP.1 Пассивное обнаружение физического нападения

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.7.9.1 FPT_PHP.1.1

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

14.7.9.2 FPT_PHP.1.2

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

14.7.10 FPT_PHP.2 Оповещение о физическом нападении

Иерархический для: FPT_PHP.1 Пассивное обнаружение физической атаки

Зависимости: FMT_MOF.1 Управление режимом выполнения функций безопасности

14.7.10.1 FPT_PHP.2.1

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

14.7.10.2 FPT_PHP.2.2

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

14.7.10.3 FPT_PHP.2.3

#Для [назначение: &список устройств/элементов, реализующих ФБО, для которых требуется активное обнаружение&] ФБО должны постоянно контролировать устройства, элементы и оповещать [назначение: &назначенный пользователь или роль&], что произошло физическое воздействие на устройства или элементы, реализующие ФБО#.

14.7.11 FPT_PHP.3 Противодействие физическому нападению

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.7.11.1 FPT_PHP.3.1

#ФБО должны противодействовать [назначение: &сценарии физического воздействия&] на [назначение: &список устройств/элементов, реализующих ФБО&], реагируя автоматически так, чтобы предотвращать нарушение ПБО#.

14.8. Надежное восстановление (FPT_RCV)

14.8.1 Характеристика семейства

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

14.8.2 Ранжирование компонентов

                                                  ┌─┐ ┌─┐ ┌─┐
                                                ┌─┤1├─┤2├─┤3│
              ┌───────────────────────────────┐ │ └─┘ └─┘ └─┘
              │FPT_RCV Надежное восстановление├─┤
              └───────────────────────────────┘ │ ┌─┐
                                                └─┤4│
                                                  └─┘

FPT_RCV.1 «Ручное восстановление» позволяет ОО предоставить только такие механизмы возврата к безопасному состоянию, которые предполагают вмешательство человека.

FPT_RCV.2 «Автоматическое восстановление» предоставляет хотя бы для одного типа прерывания обслуживания восстановление безопасного состояния без вмешательства человека; восстановление после прерываний других типов может потребовать вмешательства человека.

FPT_RCV.3 «Автоматическое восстановление без недопустимой потери» также предусматривает автоматическое восстановление, но повышает уровень требований, препятствуя недопустимой потере защищенных объектов.

FPT_RCV.4 «Восстановление функции» предусматривает восстановление на уровне отдельных ФБ, обеспечивая их нормальное завершение после сбоя либо возврат к безопасному состоянию данных ФБО.

14.8.3 Управление: FPT_RCV.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление списком доступа к средствам восстановления в режиме аварийной поддержки.

14.8.4 Управление: FPT_RCV.2, FPT_RCV.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

b) управление списком сбоев/прерываний обслуживания, которые будут обрабатываться автоматическими процедурами.

14.8.5 Управление: FPT_RCV.4

Действия по управлению не предусмотрены.

14.8.6 Аудит: FPT_RCV.1, FPT_RCV.2, FPT_RCV.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: факт возникновения сбоя или прерывания обслуживания;

b) минимальный: возобновление нормальной работы;

c) базовый: тип сбоя или прерывания обслуживания.

14.8.7 Аудит: FPT_RCV.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

14.8.8 FPT_RCV.1 Ручное восстановление

Иерархический для: нет подчиненных компонентов.

Зависимости: AGD_ADM.1 Руководство администратора

ADV_SPM.1 Неформальная модель политики безопасности ОО

14.8.8.1 FPT_RCV.1.1

#После [назначение: &список сбоев/прерываний обслуживания&] ФБО должны переходить в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию#.

14.8.9 FPT_RCV.2 Автоматическое восстановление

Иерархический для: FPT_RCV.1 Ручное восстановление

Зависимости: AGD_ADM.1 Руководство администратора

ADV_SPM.1 Неформальная модель политики безопасности ОО

14.8.9.1 FPT_RCV.2.1

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

14.8.9.2 FPT_RCV.2.2

#Для [назначение: &список сбоев/прерываний обслуживания&] ФБО должны обеспечивать возврат ОО к безопасному состоянию с использованием автоматических процедур#.

14.8.10 FPT_RCV.3 Автоматическое восстановление без недопустимой потери

Иерархический для: FPT_RCV.2 Автоматическое восстановление

Зависимости: AGD_ADM.1 Руководство администратора

ADV_SPM.1 Неформальная модель политики безопасности ОО

14.8.10.1 FPT_RCV.3.1

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

14.8.10.2 FPT_RCV.3.2

Для [назначение: список сбоев/прерываний обслуживания] ФБО должны обеспечивать возврат ОО к безопасному состоянию с использованием автоматических процедур.

14.8.10.3 FPT_RCV.3.3

#Функции из числа ФБО, предназначенные для преодоления последствий сбоя или прерывания обслуживания, должны обеспечивать восстановление безопасного начального состояния без превышения [назначение: &количественная мера&] потери данных ФБО или объектов в пределах ОДФ#.

14.8.10.4 FPT_RCV.3.4

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

14.8.11 FPT_RCV.4 Восстановление функции

Иерархический для: нет подчиненных компонентов.

Зависимости: ADV_SPM.1 Неформальная модель политики безопасности ОО

14.8.11.1 FPT_RCV.4.1

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

14.9. Обнаружение повторного использования (FPT_RPL)

14.9.1 Характеристика семейства

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

14.9.2 Ранжирование компонентов

            ┌────────────────────────────────────────────┐ ┌─┐
            │FPT_RPL Обнаружение повторного использования├─┤1│
            └────────────────────────────────────────────┘ └─┘

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

14.9.3 Управление: FPT_RPL.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

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

14.9.4 Аудит: FPT_RPL.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: обнаруженные нападения посредством повторного использования;

b) детализированный: предпринятые специальные действия.

14.9.5 FPT_RPL.1 Обнаружение повторного использования

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.9.5.1 FPT_RPL.1.1

#ФБО должны обнаруживать повторное использование для следующих сущностей: [назначение: &список идентифицированных сущностей&]#.

14.9.5.2 FPT_RPL.1.2

#ФБО должны выполнять [назначение: &список специальных действий&] при обнаружении повторного использования#.

14.10. Посредничество при обращениях (FPT_RVM)

14.10.1 Характеристика семейства

Требования семейства FPT_RVM связаны с аспектом «постоянная готовность» традиционного монитора обращений. Цель этого семейства состоит в обеспечении для заданной ПФБ, чтобы все действия, требующие осуществления политики, проверялись ФБО на соответствие ПФБ. Если, помимо этого, часть ФБО, осуществляющая ПФБ, выполняет требования соответствующих компонентов из семейств FPT_SEP «Разделение домена» и ADV_INT «Внутренняя структура ФБО», то эта часть ФБО обеспечивает «монитор обращений» для этой ПФБ.

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

14.10.2 Ранжирование компонентов

              ┌────────────────────────────────────────┐ ┌─┐
              │  FPT_RVM Посредничество при обращениях ├─┤1│
              └────────────────────────────────────────┘ └─┘

Это семейство состоит только из одного компонента FPT_RVM.1 «Невозможность обхода ПБО», который содержит требование предотвращения обхода для всех ПФБ из ПБО.

14.10.3 Управление: FPT_RVM.1

Действия по управлению не предусмотрены.

14.10.4 Аудит: FPT_RVM.1

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

14.10.5 FPT_RVM.1 Невозможность обхода ПБО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.10.5.1 FPT_RVM.1.1

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

14.11. Разделение домена (FPT_SEP)

14.11.1 Характеристика семейства

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

Это семейство содержит следующие требования:

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

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

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

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

14.11.2 Ранжирование компонентов

                  ┌─────────────────────────┐ ┌─┐ ┌─┐ ┌─┐
                  │FPT_SEP Разделение домена├─┤1├─┤2├─┤3│
                  └─────────────────────────┘ └─┘ └─┘ └─┘

FPT_SEP.1 «Отделение домена ФБО» обеспечивает отдельный защищенный домен для ФБО и разделение между субъектами в ОДФ.

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

FPT_SEP.3 «Полный монитор обращений» содержит требования, чтобы имелся отдельный(ые) домен(ы) для осуществления ПБО, домен для остальной части ФБО, а также домены для частей ОО, не связанных с ФБО.

14.11.3 Управление: FPT_SEP.1, FPT_SEP.2, FPT_SEP.3

Действия по управлению не предусмотрены.

14.11.4 Аудит: FPT_SEP.1, FPT_SEP.2, FPT_SEP.3

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

14.11.5 FPT_SEP.1 Отделение домена ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.11.5.1 FPT_SEP.1.1

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

14.11.5.2 FPT_SEP.1.2

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

14.11.6 FPT_SEP.2 Отделение домена ПФБ

Иерархический для: FPT_SEP.1 Отделение домена ФБО

Зависимости: нет зависимостей.

14.11.6.1 FPT_SEP.2.1

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

14.11.6.2 FPT_SEP.2.2

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

14.11.6.3 FPT_SEP.2.3

#ФБО должны поддерживать часть ФБО, связанных с [назначение: &список ПФБ управления доступом и/или управления информационными потоками&], в домене безопасности для их собственного выполнения, защищающем их от вмешательства и искажения остальной частью ФБО и субъектами, недоверенными относительно этих ПФБ#.

14.11.7 FPT_SEP.3 Полный монитор обращений

Иерархический для: FPT_SEP.2 Отделение домена ПФБ

Зависимости: отсутствуют.

14.11.7.1 FPT_SEP.3.1

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

14.11.7.2 FPT_SEP.3.2

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

14.11.7.3 FPT_SEP.3.3

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

14.12. Протокол синхронизации состояний (FPT_SSP)

14.12.1 Характеристика семейства

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

Семейство FPT_SSP «Протокол синхронизации состояний» устанавливает требование использования надежных протоколов некоторыми критичными по безопасности функциями из числа ФБО. Данное семейство обеспечивает, чтобы две распределенные части ОО (например, главные ЭВМ) синхронизировали свои состояния после действий, связанных с безопасностью.

14.12.2 Ранжирование компонентов

            ┌────────────────────────────────────────┐ ┌─┐ ┌─┐
            │FPT_SSP Протокол синхронизации состояний├─┤1├─┤2│
            └────────────────────────────────────────┘ └─┘ └─┘

FPT_SSP.1 «Одностороннее надежное подтверждение» содержит требование подтверждения одним лишь получателем данных.

FPT_SSP.2 «Взаимное надежное подтверждение» содержит требование взаимного подтверждения обмена данными.

14.12.3 Управление: FPT_SSP.1, FPT_SSP.2

Действия по управлению не предусмотрены.

14.12.4 Аудит: FPT_SSP.1, FPT_SSP.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: неполучение ожидаемого подтверждения.

14.12.5 FPT_SSP.1 Одностороннее надежное подтверждение

Иерархический для: нет подчиненных компонентов.

Зависимости: FPT_ITT.1 Базовая защита внутренней передачи данных ФБО

14.12.5.1 FPT_SSP.1.1

#ФБО должны подтверждать после запроса другой части ФБО получение немодифицированных данных ФБО при передаче#.

14.12.6 FPT_SSP.2 Взаимное надежное подтверждение

Иерархический для: FPT_SSP.1 Одностороннее надежное подтверждение

Зависимости: FPT_ITT.1 Базовая защита внутренней передачи данных ФБО

14.12.6.1 FPT_SSP.2.1

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

14.12.6.2 FPT_SSP.2.2

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

14.13. Метки времени (FPT_STM)

14.13.1 Характеристика семейства

Семейство FPT_STM содержит требования по предоставлению надежных меток времени в пределах ОО.

14.13.2 Ранжирование компонентов

                        ┌─────────────────────┐ ┌─┐
                        │FPT_STM Метки времени├─┤1│
                        └─────────────────────┘ └─┘

Это семейство состоит из одного компонента FPT_STM.1 «Надежные метки времени», который содержит требование, чтобы ФБО предоставляли надежные метки времени для функций из числа ФБО.

14.13.3 Управление: FPT_STM.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление внутренним представлением времени.

14.13.4 Аудит: FPT_STM.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: изменения внутреннего представления времени.

b) детализированный: предоставление меток времени.

14.13.5 FPT_STM.1 Надежные метки времени

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.13.5.1 FPT_STM.1.1

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

14.14. Согласованность данных ФБО между ФБО (FPT_TDC)

14.14.1 Характеристика семейства

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

14.14.2 Ранжирование компонентов

            ┌────────────────────────────────────────────┐ ┌─┐
            │FPT_TDC Согласованность данных ФБО между ФБО├─┤1│
            └────────────────────────────────────────────┘ └─┘

FPT_TDC.1 «Базовая согласованность данных ФБО между ФБО» содержит требование, чтобы ФБО предоставили возможность обеспечить согласованность атрибутов между ФБО.

14.14.3 Управление: FPT_TDC.1

Действия по управлению не предусмотрены.

14.14.4 Аудит: FPT_TDC.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: успешное использование механизмов согласования данных ФБО;

b) базовый: использование механизмов согласования данных ФБО;

c) базовый: идентификация ФБО, данные которых интерпретируются;

d) базовый: обнаружение модифицированных данных ФБО.

14.14.5 FPT_TDC.1 Базовая согласованность данных ФБО между ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

14.14.5.1 FPT_TDC.1.1

#ФБО должны обеспечивать способность согласованно интерпретировать [назначение: &список типов данных ФБО&], совместно используемые ФБО и другим доверенным продуктом ИТ#.

14.14.5.2 FPT_TDC.1.2

#ФБО должны использовать [назначение: &список правил интерпретации, применяемых ФБО&] при интерпретации данных ФБО, полученных от другого доверенного продукта ИТ#.

14.15. Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)

14.15.1 Характеристика семейства

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

14.15.2 Ранжирование компонентов

                  ┌──────────────────────────────────┐ ┌─┐
                  │  FPT_TRC Согласованность данных  ├─┤1│
                  │ФБО при дублировании в пределах ОО│ │ │
                  └──────────────────────────────────┘ └─┘

Это семейство состоит из одного компонента FPT_TRC.1 «Согласованность дублируемых данных ФБО», содержащего требование, чтобы ФБО обеспечили непротиворечивость данных ФБО, дублируемых в нескольких частях ОО.

14.15.3 Управление: для FPT_TRC.1

Действия по управлению не предусмотрены.

14.15.4 Аудит: для FPT_TRC.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: восстановление согласованности после восстановления соединения;

b) базовый: выявление несогласованности между данными ФБО.

14.15.5 FPT_TRC.1 Согласованность дублируемых данных ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: FPT_ITT.1 Базовая защита внутренней передачи данных ФБО

14.15.5.1 FPT_TRC.1.1

#ФБО должны обеспечивать согласованность данных ФБО при дублировании их в различных частях ОО#.

14.15.5.2 FPT_TRC.1.2

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

14.16. Самотестирование ФБО (FPT_TST)

14.16.1 Характеристика семейства

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

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

14.16.2 Ранжирование компонентов

                     ┌────────────────────────────┐ ┌─┐
                     │FPT_TST Самотестирование ФБО├─┤1│
                     └────────────────────────────┘ └─┘

FPT_TST.1 «Тестирование ФБО» позволяет проверять правильность выполнения ФБО. Тесты могут выполняться при запуске, периодически, по запросу уполномоченного пользователя или при выполнении других заранее оговоренных условий. Данный компонент также предоставляет возможность верифицировать целостность данных и выполняемого кода ФБО.

14.16.3 Управление: для FPT_TST.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление условиями, при которых происходит самотестирование ФБО (при запуске, с постоянным интервалом или при определенных условиях);

b) управление периодичностью выполнения (при необходимости).

14.16.4 Аудит: для FPT_TST.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) базовый: выполнение и результаты самотестирования ФБО.

14.16.5 FPT_TST.1 Тестирование ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: FPT_AMT.1 Тестирование абстрактной машины

14.16.5.1 FPT_TST.1.1

#ФБО должны выполнять пакет программ самотестирования [выбор: &при запуске, периодически в процессе нормального функционирования, по запросу уполномоченного пользователя, при &условиях& [назначение: &условия, при которых следует предусмотреть самотестирование]&] для демонстрации правильного выполнения [выбор: &[назначение: части ФБО]&, ФБО]#.

14.16.5.2 FPT_TST.1.2

#ФБО должны предоставлять уполномоченным пользователям возможность верифицировать целостность [выбор: &[назначение: данных частей ФБО], данных ФБО&]#.

14.16.5.3 FPT_TST.1.3

#ФБО должны предоставлять уполномоченным пользователям возможность верифицировать целостность хранимого выполняемого кода ФБО#.

15. Класс FRU. Использование ресурсов

Класс FRU содержит три семейства, которые поддерживают доступность требуемых ресурсов, таких как вычислительные возможности и/или объем памяти. Семейство FRU_FLT «Отказоустойчивость» предоставляет защиту от недоступности ресурсов, вызванной сбоем ОО. Семейство FRU_PRS «Приоритет обслуживания» обеспечивает, чтобы ресурсы выделялись наиболее важным или критичным по времени задачам и не могли быть монополизированы задачами с более низким приоритетом. Семейство FRU_RSA «Распределение ресурсов» устанавливает ограничения использования доступных ресурсов, предотвращая монополизацию ресурсов пользователями.

                 ┌──────────────────────────────┐ ┌─┐ ┌─┐
                 │  FRU_FLT Отказоустойчивость  ├─┤1├─┤2│
                 └──────────────────────────────┘ └─┘ └─┘
                 ┌──────────────────────────────┐ ┌─┐ ┌─┐
                 │FRU_PRS Приоритет обслуживания├─┤1├─┤2│
                 └──────────────────────────────┘ └─┘ └─┘
                 ┌──────────────────────────────┐ ┌─┐ ┌─┐
                 │FRU_RSA Распределение ресурсов├─┤1├─┤2│
                 └──────────────────────────────┘ └─┘ └─┘

Рисунок 73. Декомпозиция класса FRU "Использование ресурсов"

15.1. Отказоустойчивость (FRU_FLT)

15.1.1. Характеристика семейства
Требования семейства FRU_FLT обеспечивают, чтобы ОО продолжил поддерживать правильное функционирование даже в случае сбоев.

15.1.2. Ранжирование компонентов

                   ┌──────────────────────────┐ ┌─┐ ┌─┐
                   │FRU_FLT Отказоустойчивость├─┤1├─┤2│
                   └──────────────────────────┘ └─┘ └─┘

FRU_FLT.1 «Пониженная отказоустойчивость» содержит требование, чтобы ОО продолжил правильное выполнение указанных возможностей в случае идентифицированных сбоев.

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

15.1.3 Управление: FRU_FLT.1, FRU_FLT.2

Действия по управлению не предусмотрены.

15.1.4 Аудит: FRU_FLT.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: любой сбой, обнаруженный ФБО;

b) базовый: все операции ОО, прерванные из-за сбоя.

15.1.5 Аудит: FRU_FLT.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: любой сбой, обнаруженный ФБО.

15.1.6 FRU_FLT.1 Пониженная отказоустойчивость

Иерархический для: нет подчиненных компонентов.

Зависимости: FPT_FLS.1 Сбой с сохранением безопасного состояния

15.1.6.1 FRU_FLT.1.1

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

15.1.7 FRU_FLT.2 Ограниченная отказоустойчивость

Иерархический для: FRU_FLT.1 Пониженная отказоустойчивость

Зависимости: FPT_FLS.1 Сбой с сохранением безопасного состояния

15.1.7.1 FRU_FLT.2.1

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

15.2. Приоритет обслуживания (FRU_PRS)

15.2.1 Характеристика семейства

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

15.2.2 Ранжирование компонентов

                 ┌──────────────────────────────┐ ┌─┐ ┌─┐
                 │FRU_PRS Приоритет обслуживания├─┤1├─┤2│
                 └──────────────────────────────┘ └─┘ └─┘

FRU_PRS.1 «Ограниченный приоритет обслуживания» предоставляет приоритеты для использования субъектами подмножества ресурсов в пределах ОДФ.

FRU_PRS.2 «Полный приоритет обслуживания» предоставляет приоритеты для использования субъектами всех ресурсов в пределах ОДФ.

15.2.3 Управление: FRU_PRS.1, FRU_PRS.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) назначение приоритетов каждому субъекту в ФБО.

15.2.4 Аудит: FRU_PRS.1, FRU_PRS.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

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

15.2.5 FRU_PRS.1 Ограниченный приоритет обслуживания

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

15.2.5.1 FRU_PRS.1.1

#ФБО должны устанавливать приоритет каждому субъекту в ФБО#.

15.2.5.2 FRU_PRS.1.2

#ФБО должны обеспечивать доступ к [назначение: &управляемые ресурсы&] на основе приоритетов, назначенных субъектам#.

15.2.6 FRU_PRS.2 Полный приоритет обслуживания

Иерархический для: FRU_PRS.1 Ограниченный приоритет обслуживания

Зависимости: нет зависимостей.

15.2.6.1 FRU_PRS.2.1

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

15.2.6.2 FRU_PRS.2.2

ФБО должны обеспечивать доступ ко #всем совместно используемым ресурсам# на основе приоритетов, назначенных субъектам.

15.3. Распределение ресурсов (FRU_RSA)

15.3.1 Характеристика семейства

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

15.3.2 Ранжирование компонентов

                  ┌──────────────────────────────┐ ┌─┐ ┌─┐
                  │FRU_RSA Распределение ресурсов├─┤1├─┤2│
                  └──────────────────────────────┘ └─┘ └─┘

FRU_RSA.1 «Максимальные квоты» содержит требования к механизмам квотирования, которые обеспечивают, чтобы пользователи и субъекты не монополизировали управляемый ресурс.

FRU_RSA.2 «Минимальные и максимальные квоты» содержит требования к механизмам квотирования, которые обеспечивают, чтобы пользователи и субъекты всегда имели хотя бы минимум специфицированного ресурса, но при этом не могли бы монополизировать этот ресурс.

15.3.3 Управление: FRU_RSA.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

15.3.4 Управление: FRU_RSA.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

15.3.5 Аудит: FRU_RSA.1, FRU_RSA.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

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

b) базовый: все обращения к функциям распределения ресурсов, управляемых ФБО.

15.3.6 FRU_RSA.1 Максимальные квоты

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

15.3.6.1 FRU_RSA.1.1

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

15.3.7 FRU_RSA.2 Минимальные и максимальные квоты

Иерархический для: FRU_RSA.1 Максимальные квоты

Зависимости: нет зависимостей.

15.3.7.1 FRU_RSA.2.1

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

15.3.7.2 FRU_RSA.2.2

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

16. Класс FTA. Доступ к ОО

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

                  ┌─────────────────────────────┐ ┌─┐
                  │ FTA_LSA Ограничение области ├─┤1│
                  │    выбираемых атрибутов     │ │ │
                  └─────────────────────────────┘ └─┘
<pre class="legal-pre">                  ┌─────────────────────────────┐ ┌─┐  ┌─┐
                  │    FTA_MCS Ограничение на   ├─┤1├──┤2│
                  │     параллельные сеансы     │ │ │  │ │
                  └─────────────────────────────┘ └─┘  └─┘</pre>
                                                   ┌─┐
                                                 ┌─┤1│
                                                 │ └─┘
                  ┌─────────────────────────────┐│ ┌─┐
                  │ FTA_SSL Блокирование сеанса ├┼─┤2│
                  └─────────────────────────────┘│ └─┘
                                                 │ ┌─┐
                                                 └─┤3│
                                                   └─┘
                  ┌─────────────────────────────┐ ┌─┐
                  │FTA_TAB Предупреждения перед ├─┤1│
                  │предоставлением доступа к ОО │ │ │
                  └─────────────────────────────┘ └─┘
                  ┌─────────────────────────────┐ ┌─┐
                  │FTA_TAH История доступа к ОО ├─┤1│
                  └─────────────────────────────┘ └─┘
                  ┌─────────────────────────────┐ ┌─┐
                  │FTA_TSE Открытие сеанса с ОО ├─┤1│
                  └─────────────────────────────┘ └─┘

Рисунок 77. Декомпозиция класса FTA "Доступ к ОО"

16.1. Ограничение области выбираемых атрибутов (FTA_LSA)

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

16.1.2. Ранжирование компонентов

                     ┌───────────────────────────┐ ┌─┐
                     │FTA_LSA Ограничение области├─┤1│
                     │   выбираемых атрибутов    │ │ │
                     └───────────────────────────┘ └─┘

FTA.LSA.1 «Ограничение области выбираемых атрибутов» содержит требование к ОО по ограничению области атрибутов безопасности сеанса во время его открытия.

16.1.3 Управление: FTA_LSA.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) управление администратором областью атрибутов безопасности сеанса.

16.1.4 Аудит: FTA_LSA.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: все неуспешные попытки выбора атрибутов безопасности сеанса;

b) базовый: все попытки выбора атрибутов безопасности сеанса;

c) детализированный: фиксация значений атрибутов безопасности каждого сеанса.

16.1.5 FTA_LSA.1 Ограничение области выбираемых атрибутов

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

16.1.5.1 FTA_LSA.1.1

#ФБО должны ограничивать область атрибутов безопасности сеанса [назначение: &атрибуты безопасности сеанса&], основываясь на [назначение: &атрибуты&]#.

16.2. Ограничение на параллельные сеансы (FTA_MCS)

16.2.1 Характеристика семейства

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

16.2.2 Ранжирование компонентов

           ┌──────────────────────────────────────────┐ ┌─┐ ┌─┐
           │FTA_MCS Ограничение на параллельные сеансы├─┤1├─┤2│
           └──────────────────────────────────────────┘ └─┘ └─┘

FTA_MCS.1 «Базовое ограничение на параллельные сеансы» предоставляет ограничения, которые применяются ко всем пользователям ФБО.

FTA_MCS.2 «Ограничение на параллельные сеансы по атрибутам пользователя» расширяет FTA_MCS.1 «Базовое ограничение на параллельные сеансы» требованием возможности определить ограничения на число параллельных сеансов, основываясь на атрибутах безопасности, связанных с пользователем.

16.2.3 Управление: FTA_MCS.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

16.2.4 Управление: FTA_MCS.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

16.2.5 Аудит: FTA_MCS.1, FTA_MCS.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: отклонение нового сеанса, основанное на ограничении числа параллельных сеансов;

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

16.2.6 FTA_MCS.1 Базовое ограничение на параллельные сеансы

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UID.1 Выбор момента идентификации

16.2.6.1 FTA_MCS.1.1

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

16.2.6.2 FTA_MCS.1.2

#ФБО должны задавать по умолчанию ограничение [назначение: &задаваемое по умолчанию число&] сеансов пользователя#.

16.2.7 FTA_MCS.2 Ограничение на параллельные сеансы по атрибутам пользователя

Иерархический для: FTA_MCS.1 Базовое ограничение на параллельные сеансы

Зависимости: FIA_UID.1 Выбор момента идентификации

16.2.7.1 FTA_MCS.2.1

ФБО должны ограничивать максимальное число параллельных сеансов, предоставляемых одному и тому же пользователю, #согласно правилам [назначение: &правила определения максимального числа параллельных сеансов&]#.

16.2.7.2 FTA_MCS.2.2

ФБО должны задавать по умолчанию ограничение [назначение: задаваемое по умолчанию число] сеансов пользователя.

16.3. Блокирование сеанса (FTA_SSL)

16.3.1 Характеристика семейства

Семейство FTA_SSL определяет требования к ФБО по предоставлению возможности как ФБО, так и пользователю блокировать и разблокировать интерактивный сеанс.

16.3.2 Ранжирование компонентов

                                                    ┌─┐
                                                  ┌─┤1│
                                                  │ └─┘
                    ┌───────────────────────────┐ │ ┌─┐
                    │FTA_SSL Блокирование сеанса├─┼─┤2│
                    └───────────────────────────┘ │ └─┘
                                                  │ ┌─┐
                                                  └─┤3│
                                                    └─┘

FTA_SSL.1 «Блокирование сеанса, инициированное ФБО» включает в себя инициированное системой блокирование интерактивного сеанса после определенного периода бездействия пользователя.

FTA_SSL.2 «Блокирование, инициированное пользователем» предоставляет пользователю возможность блокировать и разблокировать свои собственные интерактивные сеансы.

FTA_SSL.3 «Завершение, инициированное ФБО» предоставляет требования к ФБО по завершению сеанса после определенного периода бездействия пользователя.

16.3.3 Управление: FTA_SSL.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) задание времени бездействия пользователя, после которого происходит блокировка сеанса;

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

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

16.3.4 Управление: FTA_SSL.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

16.3.5 Управление: FTA_SSL.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

a) задание времени бездействия пользователя, после которого происходит завершение интерактивного сеанса;

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

16.3.6 Аудит: FTA_SSL.1, FTA_SSL.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: блокирование интерактивного сеанса механизмом блокирования сеанса;

b) минимальный: успешное разблокирование интерактивного сеанса;

c) базовый: все попытки разблокирования интерактивного сеанса.

16.3.7 Аудит: FTA_SSL.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: завершение интерактивного сеанса механизмом блокирования сеанса.

16.3.8 FTA_SSL.1 Блокирование сеанса, инициированное ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UAU.1 Выбор момента аутентификации

16.3.8.1 FTA_SSL.1.1

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

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

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

16.3.8.2 FTA_SSL.1.2

#ФБО должны требовать, чтобы до разблокирования сеанса произошли следующие события: [назначение: &события, которые будут происходить&]#.

16.3.9 FTA_SSL.2 Блокирование, инициированное пользователем

Иерархический для: нет подчиненных компонентов.

Зависимости: FIA_UAU.1 Выбор момента аутентификации

16.3.9.1 FTA_SSL.2.1

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

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

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

16.3.9.2 FTA_SSL.2.2

#ФБО должны требовать, чтобы до разблокирования сеанса произошли следующие события: [назначение: &события, которые будут происходить&]#.

16.3.10 FTA_SSL.3 Завершение, инициированное ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

16.3.10.1 FTA_SSL.3.1

#ФБО должны завершать интерактивный сеанс после [назначение: &интервал времени бездействия пользователя&]#.

16.4. Предупреждения перед предоставлением доступа к ОО (FTA_TAB)

16.4.1 Характеристика семейства

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

16.4.2 Ранжирование компонентов

                 ┌────────────────────────────────────┐ ┌─┐
<pre class="legal-pre">                 │     FTA_TAB Предупреждения перед   ├─┤1│
                 │     предоставлением доступа к ОО   │ │ │</pre>
                 └────────────────────────────────────┘ └─┘

Рисунок 81. Ранжирование компонентов семейства FTA_TAB

FTA_TAB.1 «Предупреждения по умолчанию перед предоставлением доступа к ОО» содержит требования к предупреждающим сообщениям, которые отображаются перед началом диалога в сеансе.

16.4.3 Управление: FTA_TAB.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

16.4.4 Аудит: FTA_TAB.1

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

16.4.5 FTA_TAB.1 Предупреждения по умолчанию перед предоставлением доступа к ОО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

16.4.5.1 FTA_TAB.1.1

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

16.5. История доступа к ОО (FTA_TAH)

16.5.1 Характеристика семейства

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

16.5.2 Ранжирование компонентов

                    ┌────────────────────────────┐ ┌─┐
                    │FTA_TAH История доступа к ОО├─┤1│
                    └────────────────────────────┘ └─┘

Рисунок 82. Ранжирование компонентов семейства FTA_TAH

FTA_TAH.1 «История доступа к ОО» содержит требования к ОО по отображению информации, связанной с предыдущими попытками открыть сеанс.

16.5.3 Управление: FTA_TAH.1

Действия по управлению не предусмотрены.

16.5.4 Аудит: FTA_TAH.1

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

16.5.5 FTA_TAH.1 История доступа к ОО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

16.5.5.1 FTA_TAH.1.1

#При успешном открытии сеанса ФБО должны отображать [выбор: &дата, время, метод, расположение&] последнего успешного открытия сеанса от имени этого пользователя#.

16.5.5.2 FTA_TAH.1.2

#При успешном открытии сеанса ФБО должны отображать [выбор: &дата, время, метод, расположение&] последней неуспешной попытки открытия сеанса и число неуспешных попыток со времени последнего успешного открытия сеанса#.

16.5.5.3 FTA_TAH.1.3

#ФБО не должны удалять информацию об истории доступа из интерфейса пользователя без предоставления пользователю возможности просмотреть ее#.

16.6. Открытие сеанса с ОО (FTA_TSE)

16.6.1 Характеристика семейства

Семейство FTA_TSE определяет требования по запрещению пользователям открытия сеанса с ОО.

16.6.2 Ранжирование компонентов

                     ┌────────────────────────────┐ ┌─┐
                     │FTA_TSE Открытие сеанса с ОО├─┤1│
                     └────────────────────────────┘ └─┘

Рисунок 83. Ранжирование компонентов семейства FTA_TSE

FTA_TSE.1 «Открытие сеанса с ОО» содержит условия запрещения пользователям доступа к ОО, основанного на атрибутах.

16.6.3 Управление: FTA_TSE.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

16.6.4 Аудит: FTA_TSE.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: запрещение открытия сеанса механизмом открытия сеанса;

b) базовый: все попытки открытия сеанса пользователя;

c) детализированный: фиксация значений выбранных параметров доступа (таких как место доступа или время доступа).

16.6.5 FTA_TSE.1 Открытие сеанса с ОО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

16.6.5.1 FTA_TSE.1.1

#ФБО должны быть способны отказывать в открытии сеанса, основываясь на [назначение: &атрибуты&]#.

17. Класс FTP. Доверенный маршрут/канал

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

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

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

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

                      ┌──────────────────────────┐ ┌─┐
                      │ FTP_ITC Доверенный канал ├─┤1│
                      │    передачи между ФБО    │ │ │
                      └──────────────────────────┘ └─┘
                      ┌──────────────────────────┐ ┌─┐
                      │FTP_TRP Доверенный маршрут├─┤1│
                      └──────────────────────────┘ └─┘

Рисунок 84. Декомпозиция класса FPT «Доверенный маршрут/канал»

17.1. Доверенный канал передачи между ФБО (FTP_ITC)

17.1.1 Характеристика семейства

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

17.1.2 Ранжирование компонентов

             ┌───────────────────────────────────────────┐ ┌─┐
             │FTP_ITC Доверенный канал передачи между ФБО├─┤1│
             └───────────────────────────────────────────┘ └─┘

Рисунок 85. Ранжирование компонентов FTP_ITC

FTP_ITC.1 «Доверенный канал передачи между ФБО» содержит требование, чтобы ФБО предоставляли доверенный канал связи между ними и другим доверенным продуктом ИТ.

17.1.3 Управление: FTP_ITC.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

17.1.4 Аудит: FTP_ITC.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: сбой функций доверенного канала;

b) минимальный: идентификация инициатора и адресата отказавших функций доверенного канала;

c) базовый: все попытки использования функций доверенного канала;

d) базовый: идентификация инициатора и адресата всех функций доверенного канала.

17.1.5 FTP_ITC.1 Доверенный канал передачи между ФБО

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

17.1.5.1 FTP_ITC.1.1

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

17.1.5.2 FTP_ITC.1.2

#ФБО должны позволять [выбор: &ФБО, удаленный доверенный продукт ИТ&] инициировать связь через доверенный канал#.

17.1.5.3 FTP_ITC.1.3

#ФБО должны инициировать связь через доверенный канал для выполнения [назначение: &список функций, для которых требуется доверенный канал&]#.

17.2. Доверенный маршрут (FTP_TRP)

17.2.1 Характеристика семейства

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

17.2.2 Ранжирование компонентов

                      ┌──────────────────────────┐ ┌─┐
                      │FTP_TRP Доверенный маршрут├─┤1│
                      └──────────────────────────┘ └─┘

Рисунок 86. Ранжирование компонентов семейства FTP_TRP

FTP_TRP.1 «Доверенный маршрут» содержит требование, чтобы доверенный маршрут между ФБО и пользователем предоставлялся для совокупности событий, определенных разработчиком ПЗ/ЗБ. Возможность инициировать доверенный маршрут могут иметь пользователь и/или ФБО.

17.2.3 Управление: FTP_TRP.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

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

17.2.4 Аудит: FTP_TRP.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность аудита следующих действий:

a) минимальный: сбой функций доверенного маршрута;

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

c) базовый: все попытки использования функций доверенного маршрута;

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

17.2.5 FTP_TRP.1 Доверенный маршрут

Иерархический для: нет подчиненных компонентов.

Зависимости: нет зависимостей.

17.2.5.1 FTP_TRP.1.1

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

17.2.5.2 FTP_TRP.1.2

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

17.2.5.3 FTP_TRP.1.3

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

ЗАМЕЧАНИЯ ПО ПРИМЕНЕНИЮ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ БЕЗОПАСНОСТИ

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

A.1. Структура замечаний

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

Структура функционального класса в Приложениях C - M приведена на рисунке A.1.

Рисунок A.1. Структура функционального класса

A.1.1.1. Имя класса

Имя класса — это уникальное имя класса, определенное в соответствующих разделах настоящего стандарта.

A.1.1.2. Представление класса

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

Структура функционального семейства в замечаниях по применению приведена на рисунке A.2.

в замечаниях по применению

A.1.2.1. Имя семейства

Имя семейства — это уникальное имя семейства, определенное в соответствующих разделах настоящего стандарта.

A.1.2.2. Замечания для пользователя

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

A.1.2.3. Замечания для оценщика

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

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

A.1.3. Структура компонента

Структура функциональных компонентов в замечаниях по применению показана на рисунке A.3.

A.1.3.1. Идентификация компонента

Имя компонента — это уникальное имя компонента, определенное в соответствующих разделах настоящего стандарта.

A.1.3.2. Обоснование компонента и замечания по применению

В данном подпункте может содержаться любая относящаяся к компоненту «информация».

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

Замечания по применению содержат дополнительное уточнение в виде описания, относящегося к определенному компоненту. Уточнение может касаться замечаний для пользователя и/или оценщика, как указано в A.1.2. Данное уточнение может использоваться при объяснении природы зависимостей (например, совместно применяемая информация или действие).

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

A.1.3.3. Разрешенные операции

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

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

A.2. Таблицы зависимостей

В следующих таблицах зависимостей для функциональных компонентов представлены прямые, косвенные и выбираемые зависимости функциональных компонентов. Для каждого компонента, от которого зависят какие-либо функциональные компоненты, отведен столбец таблицы. Для каждого функционального компонента отведена строка таблицы. Знаки на пересечении строк и столбцов таблицы указывают характер зависимости соответствующих компонентов: «X» — прямая зависимость; «-» — косвенная, а «O» — выбираемая.

Выбираемую зависимость рассмотрим на примере компонента FDP_ETC.1 «Экспорт данных пользователя без атрибутов безопасности», требующего присутствия компонента FDP_ACC.1 «Ограниченное управление доступом» либо компонента FDP_IFC.1 «Ограниченное управление информационными потоками». Так, если выбран компонент FDP_ACC.1 «Ограниченное управление доступом», то присутствие FDP_IFC.1 «Ограниченное управление информационными потоками» необязательно и наоборот. Если пересечение строки и столбца таблицы пусто, компонент из строки не зависит от компонента из столбца.

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

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

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

C.1. Требования аудита в распределенной среде

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

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

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

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

Декомпозиция класса FAU "Аудит безопасности" на составляющие его компоненты показана на рисунке C.1.

     ┌─────────────────────────────────────┐   ┌─┐
     │FAU_ARP Автоматическая реакция аудита├───┤1│
<pre class="legal-pre">     │           безопасности              │   │ │
     └─────────────────────────────────────┘   └─┘</pre>
                                               ┌─┐
                                             ┌─┤1│
     ┌─────────────────────────────────────┐ │ └─┘
<pre class="legal-pre">     │    FAU_GEN Генерация данных аудита  ├─┤
     │             безопасности            │ │ ┌─┐</pre>
     └─────────────────────────────────────┘ └─┤2│
                                               └─┘
                                                     ┌─┐
                                                   ┌─┤2│
<pre class="legal-pre">     ┌─────────────────────────────────────┐   ┌─┐ │ └─┘
     │ FAU_SAA Анализ аудита безопасности  ├───┤1├─┤
     └─────────────────────────────────────┘   └─┘ │ ┌─┐ ┌─┐</pre>
                                                   └─┤3├─┤4│
                                                     └─┘ └─┘
                                               ┌─┐
                                             ┌─┤1│
     ┌─────────────────────────────────────┐ │ └─┘   ┌─┐
     │FAU_SAR Просмотр аудита безопасности ├─┼───────┤2│
     └─────────────────────────────────────┘ │ ┌─┐   └─┘
                                             └─┤3│
                                               └─┘
<pre class="legal-pre">     ┌─────────────────────────────────────┐   ┌─┐
     │    FAU_SEL Выбор событий аудита     ├───┤1│
     │            безопасности             │   │ │
     └─────────────────────────────────────┘   └─┘
                                               ┌─┐   ┌─┐</pre>
                                             ┌─┤1├───┤2│
<pre class="legal-pre">     ┌─────────────────────────────────────┐ │ └─┘   └─┘
     │    FAU_STG Хранение данных аудита   ├─┤
     │            безопасности             │ │ ┌─┐   ┌─┐</pre>
     └─────────────────────────────────────┘ └─┤3├───┤4│
                                               └─┘   └─┘

C.2. Автоматическая реакция аудита безопасности (FAU_ARP)

C.2.1. Замечания по применению

Семейство FAU_ARP «Автоматическая реакция аудита безопасности» содержит требования по обработке событий аудита. Конкретное требование может включать в себя требования сигнала тревоги или действий ФБО (автоматическая реакция). Например, ФБО могут обеспечивать подачу сигнала тревоги в реальном времени, прерывание процесса с выявленным нарушением, прекращение обслуживания, блокирование или закрытие учетных данных пользователя.

Событие аудита определяется как «возможное нарушение безопасности», если так указано в компонентах семейства FAU_SAA «Анализ аудита безопасности».

C.2.2. FAU_ARP.1 Сигналы нарушения безопасности

C.2.2.1. Замечания по применению для пользователя

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

C.2.2.2. Операции

C.2.2.2.1. Назначение

В элементе FAU_ARP.1.1 автору ПЗ/ЗБ следует определить действия, предпринимаемые в случае возможного нарушения безопасности. Примером списка таких действий является: «информировать уполномоченного пользователя, блокировать субъекта, действия которого могут привести к нарушению безопасности». Можно также указать, что предпринимаемые действия могут определяться уполномоченным пользователем.

C.3. Генерация данных аудита безопасности (FAU_GEN)

C.3.1. Замечания по применению

Семейство FAU_GEN «Генерация данных аудита безопасности» содержит требования по спецификации событий аудита, которые следует генерировать с использованием ФБО для событий, относящихся к безопасности.

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

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

«Если в ПЗ/ЗБ включено семейство FAU_GEN „Генерация данных аудита безопасности“, то следует предусмотреть возможность аудита следующих действий:»

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

b) базовый: все попытки использования функций административного управления атрибутами безопасности пользователя;

c) базовый: идентификация модифицированных атрибутов безопасности пользователя;

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

Для каждого выбранного функционального компонента в общую совокупность событий, потенциально подвергаемых аудиту, следует включить те указанные в нем события, которые соответствуют уровню, установленному в FAU_GEN «Генерация данных аудита безопасности». Если в приведенном выше примере в FAU_GEN «Генерация данных аудита безопасности» выбран уровень «базовый», события, указанные в перечислениях «a» - «c», следует отнести к потенциально подвергаемым аудиту.

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

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

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

Ниже приведены примеры типов событий, которые следует определить как потенциально подвергаемые аудиту в каждом функциональном компоненте ПЗ/ЗБ:

a) введение объектов из ОДФ в адресное пространство субъекта;

b) удаление объектов;

c) предоставление или отмена прав или возможностей доступа;

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

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

f) использование прав доступа для обхода проверок политики;

g) использование функций идентификации и аутентификации;

h) действия, предпринимаемые оператором и/или уполномоченным пользователем (например, подавление такого механизма защиты ФБО, как доступные человеку метки);

i) ввод/вывод данных с/на заменяемые носители (например, печатные материалы, ленты, дискеты).

C.3.2. FAU_GEN.1. Генерация данных аудита

C.3.2.1. Замечания по применению для пользователя

Компонент FAU_GEN.1 «Генерация данных аудита» определяет требования по идентификации событий, потенциально подвергаемых аудиту, для которых следует генерировать записи аудита, и состав информации в этих записях.

Если ПБО не предусматривает ассоциации событий аудита с идентификатором пользователя, то достаточно применения только компонента FAU_GEN.1 «Генерация данных аудита». То же приемлемо и в случае, когда ПЗ/ЗБ содержит требования приватности. Если необходимо подключение идентификатора пользователя, допускается дополнительно использовать компонент FAU_GEN.2 «Ассоциация идентификатора пользователя».

C.3.2.2. Замечания по применению для оценщика

Имеется зависимость от FPT_STM «Метки времени». Если точное значение времени событий для данного ОО несущественно, то допускается логически обоснованный отказ от этой зависимости.

C.3.2.3. Операции

C.3.2.3.1. Выбор

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

C.3.2.3.2. Назначение

В FAU_GEN.1.1 автору ПЗ/ЗБ следует составить список и других событий, потенциально подвергаемых аудиту, для включения в список событий, потенциально подвергаемых аудиту. Назначение в перечислении «c» может не включать в себя ни одного события («нет») или включать события из функциональных требований, потенциально подвергаемые аудиту более высокого уровня, чем требуется в перечислении «b», а также события, генерируемые при использовании специфицированного интерфейса прикладного программирования (API).

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

C.3.3. FAU_GEN.2 Ассоциация идентификатора пользователя

C.3.3.1. Замечания по применению для пользователя

Компонент FAU_GEN.2 связан с требованием использования идентификаторов пользователей при учете событий, потенциально подвергаемых аудиту. Этот компонент следует использовать в дополнение к FAU_GEN.1 «Генерация данных аудита».

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

C.4. Анализ аудита безопасности (FAU_SAA)

C.4.1. Замечания по применению

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

Действия для выполнения ФБО при обнаружении ожидаемого или потенциального нарушения определяются в компонентах семейства FAU_ARP «Автоматическая реакция аудита безопасности».

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

C.4.2. FAU_SAA.1 Анализ потенциального нарушения

C.4.2.1. Замечания по применению для пользователя

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

C.4.2.2. Операции

C.4.2.2.1. Назначение

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

В FAU_SAA.1.2 автору ПЗ/ЗБ следует определить любые другие правила, которые ФБО следует использовать для анализа журнала аудита. Эти правила могут включать в себя конкретные требования, согласно которым необходимо, чтобы в течение указанного периода времени (например, установленного времени суток, заданного интервала времени) произошли определенные события. Если нет никаких дополнительных правил, которые должны использовать ФБО при анализе журнала аудита, то данное назначение может быть выполнено как «нет».

C.4.3. FAU_SAA.2 Выявление аномалии, основанное на профиле

C.4.3.1. Замечания по применению для пользователя

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

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

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

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

c) операционная роль — один профиль на всех пользователей, выполняющих данную операционную роль;

d) система в целом — один профиль на всех пользователей системы.

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

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

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

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

FAU_SAA.2 «Выявление аномалии, основанное на профиле» содержит требование, чтобы ФБО сопровождали профили использования системы. Под сопровождением понимается активное участие детектора отклонений в обновлении профиля использования системы в соответствии с новыми действиями, выполняемыми членами целевой группы этого профиля. Важно, чтобы автором ПЗ/ЗБ была определена метрика представления деятельности пользователя. Индивид может выполнять тысячи различных действий, но детектор отклонений способен отобрать для контроля только некоторые из них. Результаты аномальной деятельности интегрируются в профиль так же, как и результаты нормальной деятельности (при условии выполнения мониторинга этих действий). То, что считалось отклонением четыре месяца назад, сегодня может стать нормой (и наоборот) из-за изменения условий работы пользователей. ФБО не будут способны учесть изменение ситуации, если в алгоритмах обновления профиля не отражена какая-либо аномальная деятельность пользователей.

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

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

C.4.3.2. Операции

C.4.3.2.1. Выбор

В FAU_SAA.2.1 автору ПЗ/ЗБ следует определить целевую группу профиля. Один ПЗ/ЗБ может включать в себя несколько целевых групп профиля.

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

C.4.4. FAU_SAA.3 Простая эвристика атаки

C.4.4.1. Замечания по применению для пользователя

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

Сложность средств анализа в значительной степени будет зависеть от назначений, сделанных автором ПЗ/ЗБ при определении базового множества «характерных» событий.

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

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

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

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

C.4.4.2. Операции

C.4.4.2.1. Назначение

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

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

C.4.5. FAU_SAA.4 Сложная эвристика атаки

C.4.5.1. Замечания по применению для пользователя

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

Сложность средств анализа в значительной степени будет зависеть от назначений, сделанных автором ПЗ/ЗБ при определении базового множества «характерных» событий и последовательностей событий.

Автору ПЗ/ЗБ следует определить базовое множество «характерных» событий и последовательностей событий, которые будут представлены в ФБО. Дополнительные «характерные» события и последовательности событий могут быть определены разработчиком системы.

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

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

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

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

C.4.5.2. Операции

C.4.5.2.1. Назначение

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

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

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

C.5. Просмотр аудита безопасности (FAU_SAR)

C.5.1. Замечания по применению

Семейство FAU_SAR определяет требования, относящиеся к просмотру информации аудита.

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

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

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

C.5.2. FAU_SAR.1 Просмотр аудита

C.5.2.1. Обоснование

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

C.5.2.2. Замечания по применению для пользователя

Компонент FAU_SAR.1 используется для определения возможности читать записи аудита для пользователей и/или уполномоченных пользователей. Эти записи аудита будут представляться в удобном для пользователя виде. У пользователей различных типов могут быть разные требования к представлению данных аудита.

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

C.5.2.3. Операции

C.5.2.3.1. Назначение

В FAU_SAR.1.1 автору ПЗ/ЗБ следует указать уполномоченных пользователей, которые могут просматривать данные аудита. Если это необходимо, автор ПЗ/ЗБ может указать роли безопасности (см. FMT_SMR.1 «Роли безопасности»).

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

C.5.3. FAU_SAR.2 Ограниченный просмотр аудита

C.5.3.1. Замечания по применению для пользователя

В компоненте FAU_SAR.2 определяется, что ни один пользователь, не указанный в FAU_SAR.1 «Просмотр аудита», не сможет читать записи аудита.

C.5.4. FAU_SAR.3 Выборочный просмотр аудита

C.5.4.1. Замечания по применению для пользователя

Компонент FAU_SAR.3 определяет возможность выборочного просмотра данных аудита. Если просмотр проводится на основе нескольких критериев, то необходимо, чтобы они были логически связаны (например, операциями «и», «или»), а инструментальные средства предоставили возможность обработки данных аудита (например, сортировки, фильтрации).

C.5.4.2. Операции

C.5.4.2.1. Выбор

В FAU_SAR.3.1 автору ПЗ/ЗБ следует выбрать, какие действия (поиск, сортировку и/или упорядочение) могут выполнять ФБО.

C.5.4.2.2. Назначение

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

C.6. Выбор событий аудита безопасности (FAU_SEL)

C.6.1. Замечания по применению

Семейство FAU_SEL «Выбор событий аудита безопасности» содержит требования, связанные с идентификацией того, какие события, потенциально подвергаемые аудиту, действительно подлежат аудиту. События, потенциально подвергаемые аудиту, определяются в семействе FAU_GEN «Генерация данных аудита безопасности», но для выполнения аудита этих событий их следует определить как выбираемые в компоненте FAU_SEL.1.

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

C.6.2. FAU_SEL.1 Избирательный аудит

C.6.2.1. Замечания по применению для пользователя

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

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

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

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

C.6.2.2. Операции

C.6.2.2.1. Выбор

В FAU_SEL.1.1 автору ПЗ/ЗБ следует выбрать, на каких атрибутах безопасности основана избирательность аудита: идентификатор объекта, идентификатор пользователя, идентификатор субъекта, идентификатор узла сети или тип события.

C.6.2.2.2. Назначение

В FAU_SEL.1.1 автору ПЗ/ЗБ следует определить дополнительные атрибуты, на которых основана избирательность аудита. Если нет дополнительных правил, на которых основана избирательность аудита, то данное назначение может быть выполнено как «нет».

C.7. Хранение данных аудита безопасности (FAU_STG)

C.7.1. Замечания по применению

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

C.7.2. FAU_STG.1 Защищенное хранение журнала аудита

C.7.2.1. Замечания по применению для пользователя

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

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

C.7.2.2. Операции

C.7.2.2.1. Выбор

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

C.7.3. FAU_STG.2 Гарантии доступности данных аудита

C.7.3.1. Замечания по применению для пользователя

Компонент FAU_STG.2 позволяет автору ПЗ/ЗБ определить метрику для журнала аудита.

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

C.7.3.2. Операции

C.7.3.2.1. Выбор

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

C.7.3.2.2. Назначение

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

C.7.3.2.3. Выбор

В FAU_STG.2.3 автору ПЗ/ЗБ следует специфицировать условие, при котором ФБО должны быть все еще способны сопровождать определенный объем данных аудита. Это может быть одно из следующих условий: переполнение журнала аудита, сбой, атака.

C.7.4. FAU_STG.3 Действия в случае возможной потери данных аудита

C.7.4.1. Замечания по применению для пользователя

Компонент FAU_STG.3 содержит требование выполнения определенных действий в случае превышения журналом аудита некоторого заранее определяемого предела.

C.7.4.2. Операции

C.7.4.2.1. Назначение

В FAU_STG.3.1 автору ПЗ/ЗБ следует указать значение заранее определяемого предела принятого ограничения. Если функции управления допускают, что уполномоченный пользователь может его изменить, то предел принятого ограничения является значением по умолчанию. Автор ПЗ/ЗБ может позволить уполномоченному пользователю всегда определять это ограничение. В этом случае назначение может быть, например, следующим: «ограничение устанавливает уполномоченный пользователь».

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

C.7.5. FAU_STG.4 Предотвращение потери данных аудита

C.7.5.1. Замечания по применению для пользователя

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

C.7.5.2. Операции

C.7.5.2.1. Выбор

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

C.7.5.2.2. Назначение

В FAU_STG.4.1 автору ПЗ/ЗБ следует определить другие действия, предпринимаемые в случае сбоя хранения данных аудита, такие как информирование уполномоченного пользователя. Если нет никаких других действий, которые нужно предпринять в случае сбоя хранения данных аудита, то данное назначение может быть выполнено как «нет».

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

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

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

Декомпозиция класса FCO «Связь» на составляющие его компоненты показана на рисунке D.1.

            ┌───────────────────────────────────┐ ┌─┐ ┌─┐
         ┌──┤ FCO_NRO Неотказуемость отправления├─┤1├─┤2│
<pre class="legal-pre">         │  └───────────────────────────────────┘ └─┘ └─┘
         │  ┌───────────────────────────────────┐ ┌─┐ ┌─┐
         └──┤ FCO_NRR Неотказуемость получения  ├─┤1├─┤2│</pre>
            └───────────────────────────────────┘ └─┘ └─┘

D.1. Неотказуемость отправления (FCO_NRO)

D.1.1. Замечания для пользователя

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

Если информация или ассоциированные с ней атрибуты каким-либо образом изменяются, подтверждение правильности свидетельства отправления может дать отрицательный результат. Поэтому автору ПЗ/ЗБ следует предусмотреть включение в ПЗ/ЗБ требований целостности из компонента FDP_UIT.1 «Целостность передаваемых данных».

Неотказуемость связана с несколькими различными ролями, выполняемыми одним или несколькими субъектами. Во-первых, это субъект, который запрашивает свидетельство отправления (только в FCO_NRO.1 «Избирательное доказательство отправления»). Во-вторых, получатель и/или другие субъекты, которым предоставляется свидетельство (например, нотариус). В-третьих, субъект, который запрашивает верификацию свидетельства отправления, например, получатель или третье лицо, например, арбитр.

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

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

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

D.1.2. FCO_NRO.1 Избирательное доказательство отправления

D.1.2.1. Операции

D.1.2.1.1. Назначение

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

D.1.2.1.2. Выбор

В FCO_NRO.1.1 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может запросить свидетельство отправления.

D.1.2.1.3. Назначение

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

В FCO_NRO.1.2 автору ПЗ/ЗБ следует внести в список те атрибуты, которые должны быть связаны с информацией, например, идентификатор отправителя, время и место отправления.

В FCO_NRO.1.2 автору ПЗ/ЗБ следует внести в список те информационные поля, атрибуты которых обеспечивают свидетельство отправления, например, текст сообщения.

D.1.2.1.4. Выбор

В FCO_NRO.1.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство отправления.

D.1.2.1.5. Назначение

В FCO_NRO.1.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение «немедленно» или «неограниченно».

В FCO_NRO.1.3 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третью сторону, которая может верифицировать свидетельство отправления.

D.1.3. FCO_NRO.2 Принудительное доказательство отправления

D.1.3.1. Операции

D.1.3.1.1. Назначение

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

В FCO_NRO.2.2 автору ПЗ/ЗБ следует внести в список те атрибуты, которые должны быть связаны с информацией, например, идентификатор отправителя, время и место отправления.

В FCO_NRO.2.2 автору ПЗ/ЗБ следует внести в список те информационные поля, атрибуты которых обеспечивают свидетельство отправления, например, текст сообщения.

D.1.3.1.2. Выбор

В FCO_NRO.2.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство отправления.

D.1.3.1.3. Назначение

В FCO_NRO.2.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение «немедленно» или «неограниченно».

В FCO_NRO.2.3 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третью сторону, которая может верифицировать свидетельство отправления. Третьей стороной может быть арбитр, судья или юридический орган.

D.2. Неотказуемость получения (FCO_NRR)

D.2.1. Замечания для пользователя

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

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

Если информация или ассоциированные с ней атрибуты каким-либо образом изменяются, проверка правильности свидетельства получения может дать отрицательный результат. Поэтому автору ПЗ/ЗБ следует предусмотреть включение в ПЗ/ЗБ требований целостности из компонента FDP_UIT.1 «Целостность передаваемых данных».

Неотказуемость связана с несколькими различными ролями, выполняемыми одним или несколькими субъектами. Во-первых, это субъект, который запрашивает свидетельство получения (только в FCO_NRR.1 «Избирательное доказательство получения»). Во-вторых, получатель и/или другие субъекты, которым предоставляется свидетельство (например, нотариус). В-третьих, субъект, который запрашивает верификацию свидетельства получения, например, отправитель или третья сторона, например, арбитр.

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

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

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

D.2.2. FCO_NRR.1 Избирательное доказательство получения

D.2.2.1. Операции

D.2.2.1.1. Назначение

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

D.2.2.1.2. Выбор

В FCO_NRR.1.1 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может запросить свидетельство получения.

D.2.2.1.3. Назначение

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

В FCO_NRR.1.2 автору ПЗ/ЗБ следует внести в список те атрибуты, которые должны быть связаны с информацией, например, идентификатор получателя, время и место получения.

В FCO_NRR.1.2 автору ПЗ/ЗБ следует внести в список те информационные поля, атрибуты которых обеспечивают свидетельство получения, например, текст сообщения.

D.2.2.1.4. Выбор

В FCO_NRR.1.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство получения.

D.2.2.1.5. Назначение

В FCO_NRR.1.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение «немедленно» или «неограниченно».

В FCO_NRR.1.3 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третью сторону, которая может верифицировать свидетельство получения.

D.2.3. FCO_NRR.2 Принудительное доказательство получения

D.2.3.1. Операции

D.2.3.1.1. Назначение

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

В FCO_NRR.2.2 автору ПЗ/ЗБ следует внести в список те атрибуты, которые должны быть связаны с информацией, например, идентификатор получателя, время и место получения.

В FCO_NRR.2.2 автору ПЗ/ЗБ следует внести в список те информационные поля, атрибуты которых обеспечивают свидетельство получения, например, текст сообщения.

D.2.3.1.2. Выбор

В FCO_NRR.2.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство получения.

D.2.3.1.3. Назначение

В FCO_NRR.2.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение «немедленно» или «неограниченно».

В FCO_NRR.2.3 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третьи стороны, которые могут верифицировать свидетельство получения. Третьей стороной может быть арбитр, судья или юридический орган.

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

Класс FCS «Криптографическая поддержка» состоит из двух семейств: FCS_CKM «Управление криптографическими ключами» и FCS_COP «Криптографические операции». В семействе FCS_CKM рассмотрены аспекты управления криптографическими ключами, тогда как в семействе FCS_COP рассмотрено практическое применение этих криптографических ключей.

Для каждого метода генерации криптографических ключей, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.1 «Генерация криптографических ключей».

Для каждого метода распределения криптографических ключей, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.2 «Распределение криптографических ключей».

Для каждого метода доступа к криптографическим ключам, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.3 «Доступ к криптографическим ключам».

Для каждого метода уничтожения криптографических ключей, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.4 «Уничтожение криптографических ключей».

Для каждой из криптографических операций, реализованных в ОО, таких как цифровая подпись, шифрование данных, согласование ключей, хэширование и т.д., автору ПЗ/ЗБ следует применить компонент FCS_COP.1 «Криптографические операции».

Криптографические функциональные возможности применимы для достижения целей безопасности, специфицированных в классе FCO «Связь», а также в семействах FDP_DAU «Аутентификация данных», FDP_SDI «Целостность хранимых данных», FDP_UCT «Защита конфиденциальности данных пользователя при передаче между ФБО», FDP_UIT «Защита целостности данных пользователя при передаче между ФБО», FIA_SOS «Спецификация секретов», FIA_UAU «Аутентификация пользователя». В случае, если криптографические функциональные возможности используют для достижения целей безопасности из других классов, цели, требующие применения криптографических средств, специфицируют в отдельных компонентах. Цели класса FSC «Криптографическая поддержка» должны использоваться, если потребители нуждаются в криптографических функциональных возможностях ОО.

Декомпозиция класса FCS «Криптографическая поддержка» на составляющие его компоненты показана на рисунке E.1.

                                                ┌─┐
                                              ┌─┤1│
                                              │ └─┘ ┌─┐
            ┌───────────────────────────────┐ ├─────┤2│
 ┌─┤ FCS_CKM Управление ├─┤ └─┘
          │ │  криптографическими ключами   │ │ ┌─┐
          │ └───────────────────────────────┘ ├─┤3│
<pre class="legal-pre">          │                                   │ └─┘ ┌─┐
          │                                   └─────┤4│
          │                                         └─┘
          │ ┌───────────────────────────────┐   ┌─┐
          └─┤   FCS_COP Криптографические   ├───┤1│
            │           операции            │   │ │
            └───────────────────────────────┘   └─┘</pre>

E.1. Управление криптографическими ключами (FCS_CKM)

E.1.1. Замечания для пользователя

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

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

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

Если в ПЗ/ЗБ включен компонент семейства FAU_GEN «Генерация данных аудита безопасности», то аудиту следует подвергать события, связанные с:

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

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

Для генерации криптографических ключей обычно используют случайные числа. Тогда вместо FIA_SOS.2 «Генерация секретов ФБО» следует использовать компонент FCS_CKM.1. Компонент FIA_SOS.2 следует применять, если генерация случайных чисел требуется для иных целей.

E.1.2. FCS_CKM.1 Генерация криптографических ключей

E.1.2.1. Замечания по применению для пользователя

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

E.1.2.2. Операции

E.1.2.2.1. Назначение

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

В FCS_CKM.1.1 автору ПЗ/ЗБ следует определить, какой длины криптографические ключи будут использоваться. Следует, чтобы длина ключа соответствовала выбранному алгоритму и предполагаемому применению ключа.

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

E.1.3. FCS_CKM.2 Распределение криптографических ключей

E.1.3.1. Замечания по применению для пользователя

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

E.1.3.2. Операции

E.1.3.2.1. Назначение

В FCS_CKM.2.1 автору ПЗ/ЗБ следует определить, какой метод используется для распределения криптографических ключей.

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

E.1.4. FCS_CKM.3 Доступ к криптографическим ключам

E.1.4.1. Замечания по применению для пользователя

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

E.1.4.2. Операции

E.1.4.2.1. Назначение

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

В FCS_CKM.3.1 автору ПЗ/ЗБ следует определить, какой метод будет использоваться для доступа к криптографическим ключам.

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

E.1.5. FCS_CKM.4 Уничтожение криптографических ключей

E.1.5.1. Замечания по применению для пользователя

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

E.1.5.2. Операции

E.1.5.2.1. Назначение

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

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

E.2. Криптографические операции (FCS_COP)

E.2.1. Замечания для пользователя

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

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

a) прикладной программы пользователя, для которой понадобилась данная функция;

b) применения различных криптографических алгоритмов и/или длины криптографических ключей;

c) типа или чувствительности обрабатываемых данных.

Если в ПЗ/ЗБ включен компонент семейства FAU_GEN «Генерация данных аудита безопасности», то аудиту следует подвергать события, связанные с:

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

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

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

E.2.2. FCS_COP.1 Криптографические операции

E.2.2.1. Замечания по применению для пользователя

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

E.2.2.2. Операции

E.2.2.2.1. Назначение

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

В FCS_COP.1.1 автору ПЗ/ЗБ следует определить, какой криптографический алгоритм будет использован.

В FCS_COP.1.1 автору ПЗ/ЗБ следует определить, какой длины криптографические ключи будут использоваться. Необходимо, чтобы длина ключа соответствовала выбранному алгоритму и предполагаемому применению ключа.

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

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

Данный класс не содержит явного требования мандатного управления доступом (Mandatory Access Controls — MAC) или традиционного дискреционного управления доступом (Discretionary Access Controls — DAC); тем не менее, такие требования могут быть выражены с использованием компонентов этого класса.

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

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

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

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

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

Наконец, при рассмотрении компонентов класса FDP «Защита данных пользователя» важно помнить, что эти компоненты содержат требования для функций, которые могут быть реализованы механизмами, которые служат или могли бы служить и для других целей. Например, возможно формирование политики управления доступом (FDP_ACC), которая использует метки (FDP_IFF.1 «Простые атрибуты безопасности») как основу для механизма управления доступом.

Политика безопасности ОО может содержать несколько политик функций безопасности (ПФБ), каждая из которых будет идентифицирована компонентами двух ориентированных на политики семейств «Политика управления безопасностью» FDP_ACC и «Политика управления информационными потоками» FDP_IFC. Эти политики будут, как правило, учитывать аспекты конфиденциальности, целостности и доступности так, как это потребуется для удовлетворения требований к ОО. Следует обеспечить, чтобы на каждый объект обязательно распространялась, по меньшей мере, одна ПФБ и при реализации различных ПФБ не возникали конфликты.

В процессе разработки ПЗ/ЗБ с использованием компонентов класса FDP «Защита данных пользователя» при их просмотре и выборе необходимо руководствоваться нижеследующими положениями.

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

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

Ключом к выбору компонентов этого семейства является наличие полностью определенной политики безопасности ОО, обеспечивающей правильный выбор компонентов из семейств «Политика управления доступом» FDP_ACC и «Политика управления информационными потоками» FDP_IFC. В FDP_ACC «Политика управления доступом» и FDP_IFC «Политика управления информационными потоками» присваивают имя соответственно каждой политике управления доступом или информационными потоками. Кроме того, эти компоненты определяют субъекты, объекты и операции, входящие в область действия соответствующей функции безопасности. Предполагается, что имена этих политик будут использоваться повсеместно в тех функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор «ПФБ управления доступом» и/или «ПФБ управления информационными потоками». Правила, которые определяют функциональные возможности именованных ПФБ управления доступом или информационными потоками, будут установлены в семействах FDP_ACF «Функции управления доступом» и FDP_IFF «Функции управления информационными потоками» соответственно.

Ниже приведена рекомендуемая последовательность применения этого класса при построении ПЗ/ЗБ, для чего необходимо идентифицировать:

a) осуществляемые политики, применив семейства FDP_ACC «Политика управления доступом» и FDP_IFC «Политика управления информационными потоками». Эти семейства определяют область действия каждой политики, уровень детализации управления и могут идентифицировать некоторые правила следования политике;

b) требуемые компоненты, после чего выполнить все применяемые операции в компонентах, относящихся к политикам. Операции назначения могут выполняться как в обобщенном виде (например, «все файлы»), так и конкретно («файлы „A“, „B“ и т.д.) в зависимости от уровня детализации;»

c) все потенциально применяемые компоненты, относящиеся к функциям, из семейств FDP_ACF «Функции управления доступом» и FDP_IFF «Функции управления информационными потоками», связанные с именованными политиками из семейств FDP_ACC «Политика управления доступом» и FDP_IFC «Политика управления информационными потоками». Далее выполнить операции, чтобы получить компоненты, определяющие правила этих политик. Это следует сделать так, чтобы компоненты отражали требования выбранной функции, которые уже можно себе представить или которые только подлежат разработке;

d) тех, кому будет предоставлена возможность управления атрибутами функций безопасности и их изменения, например, только администратору безопасности, только владельцу объекта и т.д., после чего выбрать соответствующие компоненты из класса FMT «Управление безопасностью» и выполнить в них операции. При этом могут быть полезны уточнения для идентификации недостающих свойств, например, некоторые или все изменения необходимо выполнять только с использованием доверенного маршрута;

e) все подходящие компоненты класса FMT «Управление безопасностью», необходимые для спецификации начальных значений новых объектов и субъектов;

f) все компоненты семейства FDP_ROL «Откат», применяемые для отката к предшествующему состоянию;

g) все требования из семейства FDP_RIP «Защита остаточной информации», применяемые для защиты остаточной информации;

h) все компоненты из семейств FDP_ITC «Импорт данных из-за пределов действия ФБО» и FDP_ETC «Экспорт данных за пределы действия ФБО», используемые при импорте или экспорте данных, указав, как следует обращаться при этом с атрибутами безопасности;

i) все используемые компоненты, относящиеся к внутренним передачам ОО, из семейства FDP_ITT «Передача в пределах ОО»;

j) требования защиты целостности хранимой информации из семейства FDP_SDI «Целостность хранимых данных»;

k) все применяемые компоненты, относящиеся к передаче данных между ФБО, из семейств FDP_UCT «Защита конфиденциальности данных пользователя при передаче между ФБО» или FDP_UIT «Защита целостности данных пользователя при передаче между ФБО».

Декомпозиция класса FDP на составляющие его компоненты показана на рисунке F.1.

     ┌────────────────────────────────────┐ ┌─┐  ┌─┐
     │FDP_ACC Политика управления доступом├─┤1├──┤2│
     └────────────────────────────────────┘ └─┘  └─┘
     ┌────────────────────────────────────┐ ┌─┐
     │FDP_ACF Функции управления доступом ├─┤1│
     └────────────────────────────────────┘ └─┘
<pre class="legal-pre">     ┌────────────────────────────────────┐ ┌─┐  ┌─┐
     │   FDP_DAU Аутентификация данных    ├─┤1├──┤2│
     └────────────────────────────────────┘ └─┘  └─┘</pre>
                                            ┌─┐
                                           ┌┤1│
     ┌────────────────────────────────────┐│└─┘
<pre class="legal-pre">     │ FDP_ETC Экспорт данных за пределы  ├┤
     │           действия ФБО             ││┌─┐</pre>
     └────────────────────────────────────┘└┤2│
                                            └─┘
<pre class="legal-pre">     ┌────────────────────────────────────┐ ┌─┐  ┌─┐
     │     FDP_IFC Политика управления    ├─┤1├──┤2│
     │      информационными потоками      │ │ │  │ │
     └────────────────────────────────────┘ └─┘  └─┘
                                            ┌─┐   ┌─┐</pre>
                                           ┌┤1├───┤2│
<pre class="legal-pre">                                           │└─┘   └─┘
     ┌────────────────────────────────────┐│   ┌─┐   ┌─┐ ┌─┐
     │     FDP_IFF Функции управления     ├┼───┤3├───┤4├─┤5│
     │      информационными потоками      ││   │ │   │ │ │ │
     └────────────────────────────────────┘│   └─┘   └─┘ └─┘</pre>
                                           │┌─┐
                                           └┤6│
                                            └─┘

                                                ┌─┐
                                              ┌─┤1│
        ┌───────────────────────────────────┐ │ └─┘
<pre class="legal-pre">        │    FDP_ITC Импорт данных из-за    ├─┤
        │      пределов действия ФБО        │ │ ┌─┐</pre>
        └───────────────────────────────────┘ └─┤2│
                                                └─┘
                                                ┌─┐   ┌─┐
                                              ┌─┤1├───┤2│
<pre class="legal-pre">        ┌───────────────────────────────────┐ │ └─┘   └─┘
        │  FDP_ITT Передача в пределах ОО   ├─┤
        └───────────────────────────────────┘ │ ┌─┐   ┌─┐</pre>
                                              └─┤3├───┤4│
<pre class="legal-pre">                                                └─┘   └─┘
        ┌────────────────────────────────────┐  ┌─┐   ┌─┐</pre>
        │FDP_RIP Защита остаточной информации├──┤1├───┤2│
<pre class="legal-pre">        └────────────────────────────────────┘  └─┘   └─┘
        ┌───────────────────────────────────┐   ┌─┐   ┌─┐
        │          FDP_ROL Откат            ├───┤1├───┤2│
        └───────────────────────────────────┘   └─┘   └─┘
        ┌───────────────────────────────────┐   ┌─┐   ┌─┐</pre>
        │FDP_SDI Целостность хранимых данных├───┤1├───┤2│
<pre class="legal-pre">        └───────────────────────────────────┘   └─┘   └─┘
        ┌────────────────────────────────────────┐  ┌─┐</pre>
        │FDP_UCT Защита конфиденциальности данных├──┤1│
<pre class="legal-pre">        │  пользователя при передаче между ФБО   │  │ │
        └────────────────────────────────────────┘  └─┘</pre>
                                                ┌─┐
                                              ┌─┤1│
        ┌────────────────────────────────────┐│ └─┘
        │ FDP_UIT Защита целостности данных  ├┤
        │ пользователя при передаче между ФБО││
        └────────────────────────────────────┘│ ┌─┐   ┌─┐
                                              └─┤2├───┤3│
                                                └─┘   └─┘

F.1. Политика управления доступом (FDP_ACC)

F.1.1. Замечания для пользователя

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

Компоненты этого семейства дают возможность идентификации (по имени) ПФБ управления доступом, в основе которых лежат традиционные механизмы дискреционного управления доступом (DAC). В семействе определяются субъекты, объекты и операции, которые входят в область действия идентифицированных политик управления доступом. Правила, определяющие функциональные возможности ПФБ управления доступом, будут установлены другими семействами, такими как FDP_ACF «Функции управления доступом» и FDP_RIP «Защита остаточной информации». Предполагается, что имена ПФБ, идентифицированные в семействе FDP_ACC «Политика управления доступом», будут использоваться повсеместно в тех функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор «ПФБ управления доступом».

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

Важнейшим аспектом функции управления доступом, осуществляющей ПФБ управления доступом, является предоставление пользователям возможности модифицировать атрибуты управления доступом. Семейство FDP_ACC «Политика управления доступом» для этого не предназначено. Часть относящихся к этой проблеме требований не определена, но их можно ввести как уточнение; часть содержится в других семействах и классах, например, в классе FMT «Управление безопасностью».

В семействе FDP_ACC «Политика управления доступом» нет требований аудита, поскольку оно специфицирует только требования ПФБ управления доступом. Требования аудита присутствуют в семействах, специфицирующих функции для удовлетворения ПФБ управления доступом, идентифицированных в этом семействе.

Это семейство предоставляет автору ПЗ/ЗБ возможность спецификации нескольких политик, например, жесткую ПФБ управления доступом в одной области действия и гибкую в другой. Для спецификации нескольких политик управления доступом компоненты этого семейства могут использоваться в ПЗ/ЗБ несколько раз для различных подмножеств операций и объектов. Это применимо к ОО, в которых предусмотрено несколько политик для различных подмножеств операций и объектов. Другими словами, автору ПЗ/ЗБ следует специфицировать, применяя компонент ACC, необходимую информацию о каждой из ПФБ, которые будут осуществляться ФБО. Например, ПЗ/ЗБ для ОО, включающего в себя три ПФБ, каждая из которых действует для своей части объектов, субъектов и операций в пределах ОО, будет содержать по одному компоненту FDP_ACC.1 «Ограниченное управление доступом» для каждой из трех ПФБ.

F.1.2. FDP_ACC.1 Ограниченное управление доступом

F.1.2.1. Замечания по применению для пользователя

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

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

F.1.2.2. Операции

F.1.2.2.1. Назначение

В FDP_ACC.1.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления доступом, осуществляемую ФБО.

В FDP_ACC.1.1 автору ПЗ/ЗБ следует специфицировать список субъектов, объектов и операций субъектов на объектах, на которые распространяется данная ПФБ.

F.1.3. FDP_ACC.2 Полное управление доступом

F.1.3.1. Замечания по применению для пользователя

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

Автору ПЗ/ЗБ необходимо продемонстрировать, что на любую комбинацию объектов и субъектов распространяется какая-либо ПФБ управления доступом.

F.1.3.2. Операции

F.1.3.2.1. Назначение

В FDP_ACC.2.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления доступом, осуществляемую ФБО.

В FDP_ACC.2.1 автору ПЗ/ЗБ следует специфицировать список субъектов и объектов, на которые распространяется данная ПФБ. ПФБ будет распространяться на все операции между этими субъектами и объектами.

F.2. Функции управления доступом (FDP_ACF)

F.2.1. Замечания для пользователя

Семейство FDP_ACF описывает правила для конкретных функций, которые могут реализовать политики управления доступом, именованные в FDP_ACC «Политика управления доступом». В FDP_ACC также определяется область действия этих политик.

Данное семейство позволяет автору ПЗ/ЗБ описать правила управления доступом. В результате правила доступа к объектам системы не будут изменяться. Примером такого объекта является рубрика «Новости дня», которую читать могут все, а изменять — только уполномоченный администратор. Данное семейство также позволяет автору ПЗ/ЗБ устанавливать исключения из общих правил управления доступом. Такие исключения будут явно разрешать или запрещать авторизацию доступа к объекту.

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

В этом семействе можно определить ряд ФБ управления доступом, имеющих в основе:

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

F.2.2. FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности

F.2.2.1. Замечания по применению для пользователя

Компонент FDP_ACF.1 обеспечивает требования к механизму, который поддерживает управление доступом, основанное на атрибутах безопасности, ассоциированных с субъектами и объектами. Каждый объект и субъект имеет совокупность ассоциированных с ним атрибутов, таких как расположение, время создания, права доступа (например, списки контроля доступа). Данный компонент позволяет автору ПЗ/ЗБ специфицировать атрибуты, которые будут использоваться для посредничества при управлении доступом, а также правила управления доступом на основе этих атрибутов.

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

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

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

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

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

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

F.2.2.2. Операции

F.2.2.2.1. Назначение

В FDP_ACF.1.1 автору ПЗ/ЗБ следует специфицировать имя ПФБ управления доступом, осуществляемой ФБО. Имя и область действия ПФБ управления доступом определяются в компонентах семейства FDP_ACC.

В FDP_ACF.1.1 автору ПЗ/ЗБ следует специфицировать атрибуты безопасности и/или именованные группы атрибутов безопасности, которые функция будет использовать при спецификации правил, для каждого управляемого субъекта или объекта. Такими атрибутами безопасности могут быть, например, идентификатор пользователя, идентификатор субъекта, роль, время суток, местоположение, списки контроля доступа, а также любые другие атрибуты, специфицированные автором ПЗ/ЗБ. Для удобства ссылок на атрибуты безопасности неоднократного применения можно ввести именованные группы атрибутов безопасности. Именованные группы могут оказаться полезными при ассоциации «ролей», определенных в семействе FMT_SMR «Роли управления безопасностью», и соответствующих им атрибутов с субъектами. Другими словами, каждую роль можно связать с именованной группой атрибутов.

В FDP_ACF.1.2 автору ПЗ/ЗБ следует специфицировать для данной ПФБ правила управления доступом контролируемых субъектов к контролируемым объектам и контролируемым операциям на контролируемых объектах. Эти правила определяют, когда доступ предоставляется, а когда в нем отказано. В них могут быть специфицированы функции управления доступом общего характера (использующие, например, обычные биты разрешения) или структурированные функции управления доступом (использующие, например, списки контроля доступа).

В FDP_ACF.1.3 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, которые будут использоваться для явного разрешения доступа субъектов к объектам и дополняют правила, установленные в FDP_ACF.1.1. Они вынесены в отдельный элемент FDP_ACF.1.3, поскольку описывают исключения из правил, установленных в FDP_ACF.1.1. Например, правила явного разрешения доступа могут быть основаны на векторе полномочий, ассоциированном с субъектом и всегда обеспечивающим ему доступ к объектам, на которые распространяется специфицируемая ПФБ управления доступом. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать «Нет» в данной операции.

В FDP_ACF.1.4 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, которые будут использоваться для явного отказа в доступе субъектов к объектам и дополняют правила, установленные в FDP_ACF.1.1. Они вынесены в отдельный элемент FDP_ACF.1.4, поскольку описывают исключения из правил, установленных в FDP_ACF.1.1. Например, правила явного отказа в доступе могут быть основаны на векторе полномочий, ассоциированном с субъектом и явно отказывающем ему в доступе к объектам, на которые распространяется специфицируемая ПФБ управления доступом. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать «Нет» в данной операции.

F.3. Аутентификация данных (FDP_DAU)

F.3.1. Замечания для пользователя

Семейство FDP_DAU описывает специальные функции, используемые для аутентификации «статических» данных.

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

F.3.2. FDP_DAU.1 Базовая аутентификация данных

F.3.2.1. Замечания по применению для пользователя

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

F.3.2.2. Операции

F.3.2.2.1. Назначение

В FDP_DAU.1.1 автору ПЗ/ЗБ следует специфицировать список объектов или типов информации, для которых ФБО должны быть в состоянии генерировать свидетельство аутентификации данных.

В FDP_DAU.1.2 автору ПЗ/ЗБ следует специфицировать список субъектов, которые будут в состоянии верифицировать свидетельства аутентификации данных для объектов, указанных в предыдущем элементе. Список может просто перечислить субъектов, если все они известны, или описание субъектов в списке может носить более общий характер и ссылаться на «тип» субъекта, например, на идентифицированную роль.

F.3.3. FDP_DAU.2 Аутентификация данных с идентификацией гаранта

F.3.3.1. Замечания по применению для пользователя

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

F.3.3.2. Операции

F.3.3.2.1. Назначение

В FDP_DAU.2.1 автору ПЗ/ЗБ следует специфицировать список объектов или типов информации, для которых ФБО должны быть в состоянии генерировать свидетельство аутентификации данных.

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

F.4. Экспорт данных за пределы действия ФБО (FDP_ETC)

F.4.1. Замечания для пользователя

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

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

FDP_ETC и соответствующее семейство для импорта данных FDP_ITC «Импорт данных из-за пределов действия ФБО» определяют, как ОО поступает с данными пользователей, передаваемыми из ОДФ и поступающими в нее. Фактически семейство FDP_ETC обеспечивает экспорт данных пользователей и связанных с ними атрибутов безопасности.

В данном семействе могут рассматриваться следующие действия:

a) экспорт данных пользователей без каких-либо атрибутов безопасности;

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

Если применяются несколько ПФБ управления доступом и/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой политики (то есть применить к нему операцию итерации).

F.4.2. FDP_ETC.1 Экспорт данных пользователя без атрибутов безопасности

F.4.2.1. Замечания по применению для пользователя

Компонент FDP_ETC.1 используется для спецификации экспорта информации без экспорта атрибутов безопасности.

F.4.2.2. Операции

F.4.2.2.1. Назначение

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

F.4.3. FDP_ETC.2 Экспорт данных пользователя с атрибутами безопасности

F.4.3.1. Замечания по применению для пользователя

Данные пользователя экспортируются вместе со своими атрибутами безопасности. Эти атрибуты безопасности однозначно ассоциированы с данными пользователя. Ассоциация может устанавливаться различными способами. К способам установления ассоциации относятся совместное физическое размещение данных пользователя и атрибутов безопасности (например, на одной дискете) или использование криптографических методов, например, цифровых подписей, для ассоциации этих атрибутов и данных пользователя. Для обеспечения получения правильных значений атрибутов другим доверенным продуктом ИТ можно использовать семейство FTP_ITC «Доверенный канал передачи между ФБО», в то время как семейство FPT_TDC «Согласованность данных ФБО между ФБО» может применяться для достижения уверенности в правильной интерпретации этих атрибутов. В свою очередь, семейство FTP_TRP «Доверенный маршрут» может применяться для достижения уверенности в инициации экспорта надлежащим пользователем.

F.4.3.2. Операции

F.4.3.2.1. Назначение

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

В FDP_ETC.2.4 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления экспортом или указать «Нет» при их отсутствии. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/или информационными потоками, выбранным в FDP_ETC.2.1.

F.5. Политика управления информационными потоками (FDP_IFC)

F.5.1. Замечания для пользователя

В семействе FDP_IFC идентифицируются ПФБ управления информационными потоками и специфицируются области действия каждой такой политики.

Примерами политик безопасности, которые могут быть применены, являются:

• модель безопасности Белла и Ла Падулы [1];
• модель целостности Биба [2];
• невмешательство [5], [6].

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

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

Каждая ПФБ распространяется на некоторое множество триад: «субъект, информация, операции перемещения информации к субъектам и от субъектов». Некоторые политики управления информационными потоками могут иметь очень подробную детализацию и описывать субъекты непосредственно в терминах процессов операционной системы. Другие политики могут определяться с меньшими подробностями и описывать субъекты в терминах пользователей или каналов ввода/вывода. Если политика управления информационными потоками задана недостаточно подробно, то четкое определение требуемых функций безопасности ИТ может оказаться невыполнимым. В этом случае целесообразнее описывать политики управления информационными потоками как цели безопасности. Тогда требуемые функции безопасности ИТ можно специфицировать, исходя из этих целей.

Во втором компоненте (FDP_IFC.2 «Полное управление информационными потоками») каждая ПФБ управления информационными потоками будет охватывать все возможные операции перемещения информации к субъектам и от субъектов под управлением этой ПФБ. Более того, требуется, чтобы все информационные потоки были охвачены какой-либо ПФБ, поэтому для каждого действия, вызвавшего перемещение информации, будет существовать совокупность правил, определяющих, является ли данное действие допустимым. Если данный информационный поток подчинен нескольким ПФБ, то необходимо его разрешение всеми этими политиками до его начала.