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

(введен в действие Приказом Гостехкомиссии России от 19.06.2002 № 187)

РУКОВОДЯЩИЙ ДОКУМЕНТ

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

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

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

Руководящий документ разработан в развитие РД Гостехкомиссии России по защите информации от несанкционированного доступа и соответствует ГОСТ Р ИСО/МЭК 15408-2002 «Информационная технология. Методы обеспечения безопасности. Критерии оценки безопасности информационных технологий», далее по тексту РД — Общие критерии (ОК).

Разработка настоящего Руководящего документа направлена на обеспечение практического использования ГОСТ Р ИСО/МЭК 15408-2002 в деятельности заказчиков, разработчиков и пользователей продуктов и систем ИТ при формировании ими требований, разработке, приобретении и применении продуктов и систем информационных технологий, предназначенных для обработки, хранения или передачи информации, подлежащей защите в соответствии с требованиями нормативных правовых документов или требованиями, устанавливаемыми собственником информации. Руководящий документ предназначен также для органов сертификации и испытательных лабораторий, аккредитованных в системе сертификации средств защиты информации по требованиям безопасности информации № РОСС RU.0001.01БИ00 (Гостехкомиссии России), для использования при проведении оценки и сертификации безопасности ИТ.

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

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

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

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

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

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

Руководящий документ состоит из трех частей.

Часть 1 РД определяет виды требований безопасности (функциональные и требования доверия), основные конструкции представления требований безопасности (профиль защиты, задание по безопасности) и содержит основные методические положения по оценке безопасности ИТ.

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

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

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

Часть 1. ВВЕДЕНИЕ И ОБЩАЯ МОДЕЛЬ

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

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

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

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

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

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

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

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

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

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

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

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

2. Определения

2.1. Общие сокращения

Следующие сокращения являются общими для всех частей ОК.

    ЗБ (ST)      Задание по безопасности
    ИТ (IT)      Информационная технология
    ИФБО (TSFI)  Интерфейс ФБО
    ОДФ (TSC)    Область действия ФБО
    ОК (CC)      Общие критерии, исторически сложившееся название,

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

    ОО (TOE)     Объект оценки
    ОУД (EAL)    Оценочный уровень доверия
    ПБО (TSP)    Политика безопасности ОО
    ПЗ (PP)      Профиль защиты
    ПФБ (SFP)    Политика функции безопасности
    СФБ (SOF)    Стойкость функции безопасности
    ФБ (SF)      Функция безопасности
    ФБО (TSF)    Функции безопасности ОО

2.2. Область применения глоссария

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

2.3. Глоссарий

В ОК применяются следующие термины:

#активы#: информация или ресурсы, подлежащие защите #assets# контрмерами ОО;

#атрибут безопасности#: информация, связанная с субъектами, #security пользователями и/или объектами, которая используется для attribute# осуществления ПБО;

#аутентификационные данные#: информация, используемая для   #authentication
верификации предъявленного идентификатора пользователя;     data#
#базовая СФБ#: уровень стойкости функции безопасности ОО,   #SOF-basic#

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

#внешний объект ИТ#: любые продукт или система ИТ,          #external IT
доверенные или нет, находящиеся вне ОО и взаимодействующие  entity#

с ним;

#внутренний канал связи#: канал связи между разделенными    #internal
частями ОО;                                                 communication

                                                        channel#

#выбор#: выделение одного или нескольких элементов #selection# из перечня в компоненте;

#высокая СФБ#: уровень стойкости функции безопасности ОО, #SOF-high# на котором, как показывает анализ, функция предоставляет адекватную защиту от тщательно спланированного и организованного нарушения безопасности ОО нарушителями с высоким потенциалом нападения;

#данные ФБО#: данные, созданные ФБО или для ФБО, которые #TSF data# могут повлиять на выполнение ФБО;

#данные пользователя#: данные, созданные пользователем #user data# и для пользователя, которые не влияют на выполнение ФБО;

#доверенный канал#: средство взаимодействия между ФБО       #trusted
и удаленным доверенным продуктом ИТ, обеспечивающее         channel#

необходимую степень уверенности в поддержании ПБО;

#доверенный маршрут#: средство взаимодействия между #trusted path# пользователем и ФБО, обеспечивающее необходимую степень уверенности в поддержании ПБО;

#доверие#: основание для уверенности в том, что сущность #assurance# отвечает своим целям безопасности;

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

#задание по безопасности#: совокупность требований          #security
безопасности и спецификаций, предназначенная для            target#

использования в качестве основы для оценки конкретного ОО;

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

#интерфейс функций безопасности ОО#: совокупность           #TOE security
интерфейсов, как интерактивных (человеко-машинные           functions
интерфейсы), так и программных (интерфейсы прикладных       interface#

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

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

#класс#: группа семейств, объединенных общим назначением;   #class#
#компонент#: наименьшая выбираемая совокупность элементов,  #component#

которая может быть включена в ПЗ, ЗБ или пакет;

#механизм проверки правомочности обращений#: реализация     #reference
концепции монитора обращений, обладающая следующими         validation
свойствами: защищенностью от проникновения; постоянной      mechanism#

готовностью; простотой, достаточной для проведения исчерпывающего анализа и тестирования;

#модель политики безопасности ОО#: структурированное        #TOE security
представление политики безопасности, которая должна быть    policy model#

осуществлена ОО;

#монитор обращений#: концепция абстрактной машины,          #reference
осуществляющей политики управления доступом ОО;             monitor#
#назначение#: спецификация определенного параметра          #assignment#

в компоненте;

#неформальный#: выраженный на естественном языке;           #informal#
#область действия ФБО#: совокупность возможных              #TSF scope
взаимодействий с ОО или в его пределах, которые             of control#

подчинены правилам ПБО;

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

#объект оценки#: подлежащие оценке продукт ИТ или система   #target of
с руководствами администратора и пользователя;              evaluation#
#орган оценки#: организация, которая посредством системы    #evaluation
оценки обеспечивает реализацию ОК для определенного         authority#

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

#оценка#: оценка ПЗ, ЗБ или ОО по определенным критериям;   #evaluation#
#оценочный уровень доверия#: пакет компонентов доверия      #evaluation

из части 3 ОК, представляющий некоторое положение assurance

на предопределенной в ОК шкале доверия;                     level#
#пакет#: предназначенная для многократного использования    #package#

совокупность функциональных компонентов или компонентов доверия (например, ОУД), объединенных для удовлетворения совокупности определенных целей безопасности;

#передача в пределах ОО#: передача данных между             #internal TOE
разделенными частями ОО;                                    transfer#
#передача за пределы области действия ФБО#: передача        #transfers
данных сущностям, не контролируемым ФБО;                    outside TSF

                                                        control#

#передача между ФБО#: передача данных между ФБО и           #inter-TSF
функциями безопасности других доверенных продуктов ИТ;      transfers#
#политика безопасности организации#: одно или несколько     #organisational
правил, процедур, практических приемов или руководящих      security
принципов в области безопасности, которыми руководствуется  policies#

организация в своей деятельности;

#политика безопасности ОО#: совокупность правил,            #TOE security
регулирующих управление активами, их защиту и               policy#

распределение в пределах ОО;

#политика функции безопасности#: политика безопасности,     #security
осуществляемая ФБ;                                          function

                                                        policy#

#полуформальный#: выраженный на языке с ограниченным #semiformal# синтаксисом и определенной семантикой;

#пользователь#: любая сущность (человек-пользователь #user# или внешний объект ИТ) вне ОО, которая взаимодействует с ОО;

#потенциал нападения#: прогнозируемый потенциал для         #attack
успешного (в случае реализации) нападения, выраженный в     potential#

показателях компетентности, ресурсов и мотивации нарушителя;

#продукт#: совокупность программных, программно-аппаратных #product# и/или аппаратных средств ИТ, предоставляющая определенные функциональные возможности и предназначенная для непосредственного использования или включения в различные системы;

#профиль защиты#: не зависимая от реализации совокупность   #protection
требований безопасности для некоторой категории ОО,         profile#

отвечающая специфическим запросам потребителя;

#расширение#: добавление в ЗБ или ПЗ функциональных #extension# требований, не содержащихся в части 2 ОК, и/или требований доверия, не содержащихся в части 3 ОК;

#ресурс ОО#: все, что может использоваться или потребляться #TOE resource# в ОО;

#роль#: заранее определенная совокупность правил, #role# устанавливающих допустимое взаимодействие между пользователем и ОО;

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

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

#семейство#: группа компонентов, которые объединены #family# одинаковыми целями безопасности, но могут отличаться акцентами или строгостью;

#система#: специфическое воплощение ИТ с конкретным #system# назначением и условиями эксплуатации;

#система оценки#: административно-правовая структура,       #evaluation
в рамках которой в определенном сообществе органы оценки    scheme#

применяют ОК;

#средняя СФБ#: уровень стойкости функции безопасности ОО, #SOF-medium# на котором, как показывает анализ, функция предоставляет адекватную защиту от прямого или умышленного нарушения безопасности ОО нарушителями с умеренным потенциалом нападения;

#стойкость функции безопасности#: характеристика функции    #strength of
безопасности ОО, выражающая минимальные усилия,             function#

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

#субъект#: сущность в пределах ОДФ, которая инициирует #subject# выполнение операций;

#уполномоченный пользователь#: пользователь, которому       #authorised
в соответствии с ПБО разрешено выполнять какую-либо         user#

операцию;

#усиление#: добавление одного или нескольких компонентов #augmentation# доверия из части 3 ОК в ОУД или пакет требований доверия;

#уточнение#: добавление деталей в компонент;                #refinement#
#функции безопасности ОО#: совокупность всех функций        #TOE security
безопасности ОО, направленных на осуществление ПБО;         functions#
#функция безопасности#: функциональные возможности части    #security
или частей ОО, обеспечивающие выполнение подмножества       function#

взаимосвязанных правил ПБО;

#формальный#: выраженный на языке с ограниченным #formal# синтаксисом и определенной семантикой, основанной на установившихся математических понятиях;

#человек-пользователь#: любое лицо, взаимодействующее #human user# с ОО;

#цель безопасности#: изложенное намерение противостоять     #security
установленным угрозам и/или удовлетворять установленной     objective#

политике безопасности организации и предположениям;

#элемент#: неделимое требование безопасности. #element#

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

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

3.1. Введение

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

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

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

3.2. Пользователи ОК

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

3.2.1 Потребители

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

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

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

3.2.2 Разработчики

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

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

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

3.2.3 Оценщики

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

3.2.4 Прочие

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

а) лица, ответственные за техническое состояние оборудования, и сотрудники служб безопасности, ответственные за определение и выполнение политики и требований безопасности организации в области ИТ;

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

в) проектировщики систем безопасности, ответственные за спецификацию основного содержания безопасности систем и продуктов ИТ;

г) аттестующие, ответственные за приемку системы ИТ в эксплуатацию в конкретной среде;

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

е) органы оценки, ответственные за руководство и надзор за программами проведения оценок безопасности ИТ.

3.3. Контекст оценки

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

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

Рисунок 3.1. Контекст оценки

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

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

3.4. Структура ОК

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

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

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

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

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

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

Таблица 3.1

ПУТЕВОДИТЕЛЬ ПО ОБЩИМ КРИТЕРИЯМ

4. Общая модель

В этом разделе представлены общие понятия, используемые во всех частях ОК, включая контекст использования этих понятий, и подход ОК к их применению. Части 2 и 3 ОК развивают эти понятия в рамках описанного подхода. Этот раздел предполагает наличие определенных знаний по безопасности ИТ и не предназначен для использования в качестве учебного пособия в этой области.

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

4.1. Контекст безопасности

4.1.1 Общий контекст безопасности

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

   ┌───────────┐                    оценивают
   │ ВЛАДЕЛЬЦЫ ├─────────────────────────────────────────────────┐
<pre class="legal-pre">   │           ├─────────────────────────────────────────┐       │
   └┬─────┬────┘ хотят минимизировать                    │       │
    │     │                                              │       │
    │     │ предпринимают  ┌───────────┐ чтобы уменьшить │       │
    │     └───────────────>│ КОНТРМЕРЫ ├─────────────────┤       │
    │                      │           ├──────────┐      │       │
    │                      └───────────┘          │      │       │
    │                       /\ которые направлены \/     │       │
    │    которые могут быть │  на      ┌────────────┐    │       │
    │         уменьшены     └──────────┤ УЯЗВИМОСТИ │    │       │
    └─────────────────────────────────>│            │    │       │
              могут знать        ┌────>└─────┬──────┘    \/      │
                                 │           │    ┌────────┐     │
                        которые  │           └───>│  РИСК  │     │
                      используют │ ведущие к ┌───>│        │     │
   ┌───────────────────┐         │           │    └──────┬─┘     \/
   │  ИСТОЧНИКИ УГРОЗ  │         │           │       для │ ┌──────────┐
   │   (НАРУШИТЕЛИ)    │         │           │           └>│  АКТИВЫ  │
   └────────┬────────┬─┘         │           │ которые     └──────────┘
            │        │ порождают │           │ повышают       /\   /\
            │        │        ┌──┴───────────┴────┐    для    │    │
            │        └───────>│      УГРОЗЫ       ├───────────┘    │
            │                 └───────────────────┘                │
            │    хотят злоупотребить и/или могут нанести ущерб     │</pre>
            └──────────────────────────────────────────────────────┘

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

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

<pre class="legal-pre">           ┌──────────────┐           ┌──────┐
           │МЕТОДЫ ДОВЕРИЯ│           │ОЦЕНКА│
           └──────┬───────┘           └───┬──┘
             дают │  ┌───────────┐        │ предоставляет
                  └─>│  ДОВЕРИЕ  │<───────┘ свидетельство</pre>
                     └─────┬─────┘
<pre class="legal-pre">           ┌─────────┐     │ дающее
           │ВЛАДЕЛЬЦЫ│     │
           └──┬──────┘     \/
              │      ┌───────────┐</pre>
      требуют └─────>│УВЕРЕННОСТЬ│
                     └─────┬─────┘
                       что │       ┌─────────┐
                           └──────>│КОНТРМЕРЫ│
                                   └───┬─────┘
                          минимизируют │         ┌────┐
                                       └────────>│РИСК│
                                                 └──┬─┘
                                                для │        ┌───────┐
                                                    └───────>│АКТИВОВ│
                                                             └───────┘

и их взаимосвязь

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

4.1.2 Контекст безопасности информационных технологий

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

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

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

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

4.2. Подход Общих критериев

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

4.2.1 Разработка

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

   ┌────────────┐ ┌────┐
<pre class="legal-pre">   │ Требования ├>│    │
   │безопасности│ │    │</pre>
   └────────────┘ └─┬──┘
     /\             \/
   ┌─┴──┐ ┌──────────────┐ ┌────┐
<pre class="legal-pre">   │    │<┤Функциональная├>│    │
   │    │ │ спецификация │ │    │</pre>
   └────┘ └──────────────┘ └─┬──┘
<pre class="legal-pre">                /\           \/                      \ Уточнение в процессе
              ┌─┴──┐ ┌───────────────┐ ┌────┐         \  проектирования и
              │    │<┤Проект верхнего├>│    │          \    реализации
              │    │ │    уровня     │ │    │           \
              └────┘ └───────────────┘ └─┬──┘            \
                            /\           \/               \
                          ┌─┴──┐ ┌ ─ ─ ─ ─ ─ ─ ─┐         \/
                   /\     │    │<┤              ├ ┐ ┌────┐
                    \     │    │                  ├>│    │
 Анализ соответствия \    └────┘ └┬ ─ ─ ─ ─ ─ ─ ┘   │    │
     и совместная     \           └ ─ ─ ─ ─ ─ ─ ─ ┘ └─┬──┘
       проверка        \                 /\           \/
                        \              ┌─┴──┐ ┌────────────────┐ ┌────┐
                         \             │    │<┤ Исходный код/  ├>│    │
                                       │    │ │схемы аппаратуры│ │    │</pre>
                                       └────┘ └────────────────┘ └─┬──┘
                                                      /\           \/
                                                    ┌────┐ ┌──────────┐
                                                    │    │<┤Реализация│
                                                    └────┘ └──────────┘

Рисунок 4.3. Модель разработки ОО

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

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

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

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

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

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

4.2.2 Оценка ОО

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

а) совокупность свидетельств, характеризующих ОО, включая прошедшее оценку ЗБ в качестве основы оценки ОО;

б) ОО, безопасность которого требуется оценить;

в) критерии, методология и система оценки.

                                                          ┌───────────┐
<pre class="legal-pre">       ┌──────────────────────────────────────────────────┤ Критерии  │
       │                               ┌──────────────────┤  оценки   │
       \/                              │                  └───────────┘
     ┌────────────┐  ┌───────────┐     │                  ┌───────────┐
     │ Требования │  │Разработать│     │  ┌───────────────┤Методология│
     │безопасности├─>│    ОО     │     │  │               │  оценки   │
     │ (ПЗ и ЗБ)  │  └─────┬─────┘     │  │               └───────────┘
     └────────────┘  /\    │           │  │               ┌───────────┐
       /\            /     \/          \/ \/              │  Система  │
                    /┌─────────────┐  ┌─────────┐<────────┤  оценки   │
       │           / │    ОО и     │  │ Оценить │         └───────────┘
                  /  │свидетельства├─>│   ОО    │
       │         /   │ для оценки  │  └────┬────┘
                /    └─────────────┘ /\    \/
       │       /           /\        /┌──────────┐       ┌────────────┐
              /            │        / │Результаты├──────>│   Начать   │
       │     /                     /  │  оценки  │       │эксплуатацию│
            /              │      /   └──────────┘       │     ОО     │
       │   /                     /         /\            └──────┬─────┘
          /                │    /          │
       │ /                     /                                │
        /                  │  /            │
       │                     /                                  │</pre>
                           │/Обратная связь│
       └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┴ ─ ─ ─ ─ ─ ─ ─ ┴ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┘

Рисунок 4.4. Процесс оценки ОО

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

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

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

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

4.2.3 Эксплуатация ОО

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

4.3. Понятия безопасности

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

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

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

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

┌──────────────┐┌───────────────────┐┌───────────────────┐<─┐
<pre class="legal-pre">│  Физическая  ││Активы, нуждающиеся││ Предназначение ОО │  │  Материалы
│  среда ООО   ││     в защите      ││                   │  │   по среде
└────┬─────────┘└─────────┬─────────┘└──────────┬────────┘  │ безопасности
     │                    \/                    │           │    (ПЗ/ЗБ)
     │          ┌───────────────────┐           │           │
     └─────────>│ Установить среду  │<──────────┘           │
     ┌──────────┤   безопасности    ├───────────┐           │
     │          └─────────┬─────────┘           │           │
     \/                   \/                    \/          │
┌──────────────┐┌───────────────────┐┌───────────────────┐  │
│Предположения ││      Угрозы       ││     Политика      │  │
│              ││                   ││   безопасности    │  │
│              ││                   ││    организации    │  │</pre>
└────┬─────────┘└─────────┬─────────┘└──────────┬────────┘<─┘
<pre class="legal-pre">     │                    \/                    │
     │          ┌───────────────────┐           │
     └─────────>│  Установить цели  │<──────────┘
                │   безопасности    │</pre>
                └─────────┬─────────┘
                          \/
<pre class="legal-pre">┌──────────────┐┌───────────────────┐                     <─┐  Материалы
│   Каталог    ││ Цели безопасности │                       │   по целям
│требований ОК ││                   │                       │ безопасности
└────┬─────────┘└─────────┬─────────┘                     <─┘
     │                    \/
     │          ┌───────────────────┐
     └─────────>│    Установить     │
                │    требования     │
     ┌──────────┤   безопасности    ├───────────┐
     │          └─────────┬─────────┘           │
     \/                   \/                    \/</pre>
┌──────────────┐┌───────────────────┐┌───────────────────┐<─┐ Материалы по
<pre class="legal-pre">│Функциональные││Требования доверия ││Требования к среде │  │ требованиям
│  требования  ││                   ││                   │  │ безопасности
└────┬─────────┘└─────────┬─────────┘└───────────────────┘<─┘    (ПЗ/ЗБ)
     │                    \/
     │          ┌───────────────────┐</pre>
     └─────────>│Установить краткую │
                │  спецификацию ОО  │
                └─────────┬─────────┘

                      \/

требований и спецификаций

4.3.1 Среда безопасности

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

При установлении среды безопасности автор ПЗ или ЗБ должен принять во внимание:

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

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

в) предназначение ОО, включая тип продукта и предполагаемую сферу его применения.

На основании исследования политики безопасности, угроз и рисков следует сформировать материалы, относящиеся к безопасности ОО:

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

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

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

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

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

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

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

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

4.3.3 Требования безопасности ИТ

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

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

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

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

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

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

а) уверенности в корректности реализации функций безопасности, т.е. оценки того, правильно ли они реализованы;

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

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

4.3.4 Краткая спецификация ОО

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

4.3.5 Реализация ОО

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

4.4. Описательные возможности ОК

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

4.4.1 Представление требований безопасности

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

┌──────────────────────────────────────────────────────────────────────────┐
<pre class="legal-pre">│  ┌──────────────────────────────────────────┐ ┌─────────────────────────┐│
│  │Класс B          ┌───────────┐ ┌─────────┐│ │         Пакеты          ││
│  │                 │Семейство K├┬┤Компонент││ │  Наборы функциональных  ││
│  │                 └───────────┘│└─────────┘│ │требований или требований││
│  │                              │┌─────────┐│ │доверия для многократного││
│  │                              ├┤Компонент├┼─┤     использования.      ││
│  │                              │└─────────┘│┌┤ Дополнительный источник ││
│  │                              │...        │││ требований для ПЗ и ЗБ  ││
│  │                              │┌─────────┐││└─────────────┬─────────┬─┘│┌───────────────────────┐
│  │                              └┤Компонент├┼┘                        │  ││     Профиль защиты    │
│  │                               └─────────┘│               │         └──┼┤  Возможные источники  │
│┌─┴─────────────────────────────────────┐    │                     ┌──────┼┤требований безопасности│
││Класс A       ┌───────────┐ ┌─────────┐│    │               │     │    ┌─┼┤для ПЗ                 │
││              │Семейство J├┬┤Компонент││    │                     │    │ │└───────────┬───────────┘
││              └───────────┘│└─────────┘├────┘               │     │    │ │            │
││┌───────────┐ ┌─────────┐  │┌─────────┐│                          │    │ │            │
│││Семейство I├┬┤Компонент│  ├┤Компонент│├────────────────────┼─────┼────┘ │┌───────────┴───────────┐
││└───────────┘│└─────────┘  │└─────────┘│                          │      ││Задание по безопасности│
││             │┌─────────┐  │...        │                    └ ─ ─ ┼ ─ ─ ─┼┤  Возможные источники  │
││             ├┤Компонент│  │┌─────────┐│                          │    ┌ ┼┤требований безопасности│
││             │└─────────┘  └┤Компонент│├──────────────────────────┼────┼─┼┤для ЗБ                 │
││             │...           └─────────┘│                          │      │└───────────────────────┘
││             │┌─────────┐ Каталоги     │      ┌───────────────────┴────┴┐│
││             └┤Компонент│ требований   │      │Дополнительные требования││
││              └─────────┘ безопасности │      │безопасности, не входящие││
│└───────────────────────────────────────┘      │           в ОК          ││
│                                               └─────────────────────────┘│</pre>
└──────────────────────────────────────────────────────────────────────────┘

Рисунок 4.6. Организация и структура требований

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

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

4.4.1.1 Класс

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

Составляющие класса называются семействами.

4.4.1.2 Семейство

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

Составляющие семейства называются компонентами.

4.4.1.3 Компонент

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

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

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

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

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

4.4.1.5 Разрешенные операции на компонентах

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

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

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

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

г) #уточнение# (refinement), позволяющее осуществлять дополнительную детализацию при использовании компонента.

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

4.4.2 Использование требований безопасности

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

            ┌────────────┐       ┌───────────┐        ┌───────┐
            │ Требования ├──────>│Разработать├───────>│Каталог│
<pre class="legal-pre">            │безопасности│       │   пакет   │        │пакетов│
            └─────┬──────┘       └───────────┘        └───┬──┬┘
                  │                    ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─┘
                  │                    \/                    │
                  │              ┌───────────┐     ┌───────┐
                  │              │Разработать│     │Каталог│ │
                  ├─────────────>│    ПЗ     ├────>│  ПЗ   │
                  │              └───────────┘     └───┬───┘ │
                  │                    ┌ ─ ─ ─ ─ ─ ─ ─ ┘
                  │                    \/                    │
                  │              ┌───────────┐
                  │              │Разработать│               │
                  └─────────────>│    ЗБ     │<─ ─ ─ ─ ─ ─ ─ ┘</pre>
                                 └───────────┘

4.4.2.1 Пакет

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

Оценочные уровни доверия (ОУД) — это предопределенные пакеты требований доверия, содержащиеся в части 3 ОК. ОУД является базовым набором требований доверия для оценки. Каждый ОУД определяет непротиворечивый набор требований доверия. Совместно ОУД формируют упорядоченное множество, которое является предопределенной в ОК шкалой доверия.

4.4.2.2 Профиль защиты

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

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

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

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

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

4.4.3 Источники требований безопасности

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

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

Существующие ПЗ можно использовать как основу для создания нового ПЗ;

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

Совокупностью предопределенных пакетов являются ОУД, определенные в части 3 ОК. В требования доверия к ОО, входящие в ПЗ или ЗБ, следует включить какой-либо ОУД из этой части;

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

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

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

4.5. Виды оценок

4.5.1 Оценка ПЗ

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

4.5.2 Оценка ЗБ

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

4.5.3 Оценка ОО

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

4.6. Поддержка доверия

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

5. Требования общих критериев и результаты оценки

5.1. Введение

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

┌──────────┐ ┌─────────────────┐ ┌─────────┐ ┌─────────────┐
│Оценить ПЗ├>│Результаты оценки├>│Внести ПЗ├>│ПЗ, прошедший│
└──────────┘ │       ПЗ        │ │в каталог│ │   оценку    │
             └─────────────────┘ └─────────┘ └────────┬────┘
    ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
    \/
┌──────────┐ ┌──────────┐
│Оценить ЗБ├>│Результаты│
└──────────┘ │оценки ЗБ │
             └────┬─────┘
                  \/
             ┌──────────┐ ┌──────────┐ ┌──────────────────┐ ┌─────────────┐
             │Оценить ОО├>│Результаты├>│Внести сертификаты├>│ОО, прошедший│
             └──────────┘ │оценки ОО │ │    в каталог     │ │   оценку    │
                          └──────────┘ └──────────────────┘ └─────────────┘

Рисунок 5.1. Результаты оценки

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

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

5.2. Требования, включаемые в ПЗ и ЗБ

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

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

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

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

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

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

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

Результат оценки ПЗ должен формулироваться как «соответствие/несоответствие». ПЗ, для которого оценка заканчивается положительно, должен получить право включения в реестр.

5.3. Требования к ОО

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

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

б) правильно ли реализованы специфицированные функции безопасности ОО.

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

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

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

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

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

Результат оценки ОО должен формулироваться как «соответствие/несоответствие». ОО, для которого оценка заканчивается положительно, должен получить право включения в реестр.

5.4. Пояснение результатов оценки

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

а) соответствие части 2 - ПЗ или ОО соответствует части 2, если функциональные требования основаны только на функциональных компонентах из части 2;

б) расширение части 2 - ПЗ или ОО соответствует расширению части 2, если функциональные требования включают функциональные компоненты, не содержащиеся в части 2;

в) соответствие части 3 - ПЗ или ОО соответствует части 3, если требования доверия представлены в виде #ОУД# из части 3 или #пакета требований доверия#, включающего только компоненты доверия из части 3;

г) усиление части 3 - ПЗ или ОО соответствует усилению части 3, если требования доверия представлены в виде #ОУД# или #пакета требований доверия# и включают другие компоненты доверия из части 3;

д) расширение части 3 - ПЗ или ОО соответствует расширению части 3, если требования доверия представлены в виде #ОУД#, дополненного требованиями доверия не из части 3, или #пакета требований доверия#, который включает требования доверия, не содержащиеся в части 3, или полностью состоит из них;

е) соответствие ПЗ — ОО соответствует ПЗ только в том случае, если он соответствует всем частям этого ПЗ.

5.5. Использование результатов оценки ОО

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

               ┌────────┐┌─────────┐
               │Каталог ││ Каталог │<───────────────┼────────┐
<pre class="legal-pre">               │профилей││оцененных│                         │
               │ защиты ││продуктов│                │        │
               └───┬────┘└─────┬───┘ (необязательно)   ┌─────┴─────┐ ┌─────────────┐
(необязательно)    └─────┬─────┘     ┌──────────────┼─>│  Внести   ├>│  Оцененный  │
                         \/          │              │  │  продукт  │ │   продукт   │
┌────────────┐ ┌─────────────┐ ┌─────┴────┐            │ в каталог │ └─────────────┘
│ Требования ├>│Разработать и├>│Результаты│         │  └───────────┘
│безопасности│ │ оценить ОО  │ │  оценки  │             (альтернативные варианты)
└────────────┘ └─────────────┘ └─────┬────┘         ├─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
                                     │                 ┌───────────┐ ┌─────────────┐</pre>
                                     └──────────────┼─>│Аттестовать├>│Аттестованная│
<pre class="legal-pre">                                                       │  систему  │ │   система   │
                                                    │  └───────────┘ └─────────────┘</pre>

                                                        /\

Рисунок 5.2. Использование результатов оценки ОО

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

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

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

А.1. Предыстория

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

В Европе в 1991 г. Европейской Комиссией были опубликованы «Критерии оценки безопасности информационных технологий» (ITSEC) версии 1.2, разработанные совместно Францией, Германией, Нидерландами и Великобританией. В Канаде на основе сочетания подходов TCSEC и ITSEC в начале 1993 г. были созданы «Канадские критерии оценки доверенных компьютерных продуктов» (СТСРЕС) версии 3.0. В США в это же время был издан проект стандарта «Федеральные критерии безопасности информационных технологий» (FC) версии 1.0, использовавший другой подход к объединению североамериканской и европейской концепций критериев оценки.

В 1990 г. Международной организацией по стандартизации (ISO) была начата разработка международного стандарта критериев оценки для общего использования. Новые критерии были призваны удовлетворить потребность взаимного признания результатов стандартизованной оценки безопасности на мировом рынке ИТ. Эта задача была поставлена перед Рабочей группой 3 (WG3) подкомитета 27 (SC27) Совместного технического комитета 1 (JTC1). Вначале работа WG3 шла медленно из-за большого объема и необходимости интенсивных многосторонних переговоров.

А.2. Разработка Общих критериев

В июне 1993 г. организации-спонсоры СТСРЕС, FC, TCSEC и ITSEC из шести стран (Великобритания, Германия, Канада, Нидерланды, США, Франция) объединили свои усилия и начали действовать совместно, чтобы согласовать различающиеся между собой критерии и создать единую совокупность критериев безопасности ИТ, которые могли бы широко использоваться. Эта деятельность получила название «Проект ОК». Его целью являлось устранение концептуальных и технических различий между исходными критериями и представление в ISO полученных результатов для содействия разработке международного стандарта. Представители организаций-спонсоров сформировали Редакционный совет ОК (ССЕВ) для разработки ОК. Затем было установлено взаимодействие между ССЕВ и WG3, после чего ССЕВ представил в WG3 несколько ранних версий ОК. Начиная с 1994 г., в результате взаимодействия между WG3 и ССЕВ эти версии оформлялись как последовательные рабочие проекты различных частей критериев ISO.

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

CCIB завершил бета-версию 2.0 ОК в октябре 1997 г. и представил ее в WG3, которая одобрила ее как Второй проект комитета. Последующие промежуточные версии проекта предоставлялись неофициально экспертам WG3 по мере их подготовки в CCIB. CCIB учел ряд замечаний, которые были получены как непосредственно от экспертов WG3, так и от национальных органов ISO при обсуждении промежуточных версий проекта. В мае 1998 г. была опубликована версия 2.0 ОК, и на ее основе в июне 1999 г. был принят международный стандарт ISO/IEC 15408. Официальный текст стандарта издан 1 декабря 1999 г. Изменения, внесенные в стандарт на завершающей фазе его принятия, учтены в версии 2.1 ОК, идентичной стандарту по содержанию.

По историческим причинам и с целью обеспечения преемственности ISO/IEC/JTC1/SC27/WG3 приняла для дальнейшего использования термин «Общие критерии» (ОК) внутри документа, признавая, что его официальным названием, принятым в ISO, является «Критерии оценки безопасности информационных технологий».

Б.1. Краткий обзор

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

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

Б.2. Содержание профиля защиты

Б.2.1. Содержание и представление

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

Содержание ПЗ представлено на рисунке Б.1, который следует использовать при создании структурной схемы разрабатываемого ПЗ.

┌──────────────┐
│ПРОФИЛЬ ЗАЩИТЫ│
└┬─────────────┘
 │┌─────────────────────┐
 ├┤     Введение ПЗ     ├─┬──── Идентификация ПЗ
 │└─────────────────────┘ └──── Аннотация ПЗ
 │┌─────────────────────┐
 ├┤     Описание ОО     │
 │└─────────────────────┘
 │┌─────────────────────┐
 ├┤Среда безопасности ОО├─┬──── Предположения безопасности
 │└─────────────────────┘ ├──── Угрозы
 │                        └──── Политика безопасности организации
 │┌─────────────────────┐
 ├┤  Цели безопасности  ├─┬──── Цели безопасности для ОО
 │└─────────────────────┘ └──── Цели безопасности для среды
 │┌─────────────────────┐ ┌───────────────────┐
<pre class="legal-pre"> ├┤     Требования      ├┬┤    Требования     ├────┬─── Функциональные
 ││   безопасности ИТ   │││безопасности для ОО│    │    требования
 │└─────────────────────┘│└───────────────────┘    │    безопасности ОО
 │                       └───── Требования         └─── Требования доверия
 │                              безопасности            к безопасности ОО
 │                              для среды ИТ</pre>
 ├ Замечания по применению
 │┌─────────────────────┐
 └┤     Обоснование     ├─┬──── Логическое обоснование целей безопасности
  └─────────────────────┘ └──── Логическое обоснование требований

                            безопасности

Рисунок Б.1. Содержание профиля защиты

Б.2.2. Введение ПЗ

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

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

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

Б.2.3. Описание ОО

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

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

Б.2.4. Среда безопасности ОО

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

а) описание #предположений#, содержащее аспекты безопасности среды, в которой ОО будет использоваться или предполагается к использованию. Оно должно также содержать:

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

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

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

Если цели безопасности ОО следуют только из политики безопасности организации и предположений, то описание угроз может быть опущено;

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

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

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

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

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

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

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

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

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

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

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

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

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

Если требования доверия к ОО включают компонент AVA_SOF.1 (например, ОУД2 и выше), то при изложении функциональных требований безопасности ОО должен устанавливаться минимальный уровень стойкости для функций безопасности, реализуемых с помощью вероятностного или перестановочного механизма (например, пароля или хэш-функции). Все подобные функции должны удовлетворять этому минимальному уровню. Уровень должен быть одним из следующих: базовая СФБ, средняя СФБ и высокая СФБ. Уровень должен выбираться в соответствии с установленными целями безопасности ОО. Для достижения некоторых целей безопасности ОО могут быть определены специальные метрики стойкости функций для выбранных функциональных требований.

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

2. при изложении #требований доверия к безопасности ОО# следует определить их как один из ОУД, возможно, усиленный другими компонентами доверия из части 3 ОК. Расширение ОУД в ПЗ может осуществляться за счет явного включения дополнительных компонентов доверия, не содержащихся в этой части;

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

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

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

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

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

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

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

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

Б.2.7. Замечания по применению

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

Б.2.8. Обоснование

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

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

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

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

2. данный набор требований безопасности образует единое и внутренне непротиворечивое целое;

3. выбор требований безопасности строго обоснован. Каждое из перечисленных ниже условий должно быть строго обосновано:

• выбор требований, не содержащихся в частях 2 или 3 ОК;
• выбор требований доверия, не включенных в какой-либо ОУД;
• случаи неудовлетворения зависимостей;

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

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

В.1. Краткий обзор

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

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

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

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

В.2. Содержание задания по безопасности

В.2.1. Содержание и представление ЗБ

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

Содержание ЗБ представлено на рисунке В.1, который рекомендуется использовать при создании структурной схемы ЗБ.

                            соответствии ПЗ

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

В.2.2. Введение ЗБ

Введение ЗБ должно содержать информацию для управления документооборотом и обзорную информацию:

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

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

в) #утверждение о соответствии ОК# должно изложить каждое поддающееся оценке утверждение о соответствии ОО общим критериям, как указано в подразделе 5.4.

В.2.3. Описание ОО

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

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

В.2.4. Среда безопасности ОО

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

а) описание #предположений#, содержащее аспекты безопасности среды, в которой ОО будет использоваться или предполагается к использованию. Оно должно также содержать:

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

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

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

Если цели безопасности ОО следуют только из политики безопасности организации и предположений, то описание угроз может быть опущено;

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

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

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

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

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

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

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

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

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

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

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

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

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

Если требования доверия к ОО включают компонент AVA_SOF.1 (например, ОУД2 и выше), то при изложении функциональных требований безопасности ОО должен устанавливаться минимальный уровень стойкости для функций безопасности, реализуемых с помощью вероятностного или перестановочного механизма (например, пароля или хэш-функции). Все подобные функции должны удовлетворять этому минимальному уровню. Уровень должен быть одним из следующих: базовая СФБ, средняя СФБ и высокая СФБ. Уровень должен выбираться в соответствии с установленными целями безопасности ОО. Для достижения некоторых целей безопасности ОО могут быть определены специальные метрики стойкости функций для выбранных функциональных требований.

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

2. при изложении #требований доверия к безопасности ОО# следует определить их как один из ОУД, возможно, усиленный другими компонентами доверия из части 3 ОК. Расширение ОУД в ЗБ может осуществляться за счет явного включения дополнительных компонентов доверия, не содержащихся в этой части;

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

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

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

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

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

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

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

В.2.7. Краткая спецификация ОО

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

Краткая спецификация ОО включает в себя следующее:

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

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

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

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

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

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

В.2.8. Утверждения о соответствии ПЗ

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

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

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

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

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

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

д) случай, когда в ЗБ утверждается о частичном соответствии ПЗ, не приемлем для оценки в рамках ОК.

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

Если сделано утверждение о соответствии какому-либо ПЗ, то изложение утверждений о соответствии должно содержать следующий материал для каждого ПЗ:

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

ж) #конкретизацию ПЗ#, идентифицирующую те требования безопасности ИТ, в которых выполняются операции, разрешенные в ПЗ, или дополнительно уточняются требования ПЗ;

з) #дополнение ПЗ#, идентифицирующее цели и требования безопасности ОО, которые дополняют цели и требования ПЗ.

В.2.9. Обоснование

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

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

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

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

2. данный набор требований безопасности образует единое и внутренне непротиворечивое целое;

3. выбор требований безопасности строго обоснован. При этом должны быть строго обоснованы:

• выбор требований, не содержащихся в частях 2 или 3 ОК;
• выбор требований доверия, не включенных в какой-либо ОУД;
• случаи неудовлетворения зависимостей;

4. выбранный для ЗБ уровень стойкости функций и заявленная в явном виде стойкость функций согласуются с целями безопасности для ОО;

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

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

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

3. строго обосновано утверждение, что изложенные меры доверия соответствуют требованиям доверия.

Уровень детализации логического обоснования должен соответствовать уровню детализации определения функций безопасности;

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

Этот потенциально объемный материал разрешается распространять отдельно, поскольку он необходим или полезен не для всех пользователей ЗБ.

[B&L] Bell, D.E. and LaPadula, L.J., Secure Computer Systems: Unified Exposition and MULTICS Interpretation, Revision 1, US Air Force ESD-TR-75-306, MITRE Corporation MTR-2997, Bedford MA., March, 1976.

[Biba] Biba, K.J., Integrity Considerations for Secure Computer Systems, ESD-TR-372, ESD/AFSC, Hanscom AFB, Bedford MA., April, 1977.

[CTCPEC] Canadian Trusted Computer Product Evaluation Criteria, Version 3.0, Canadian System Security Centre, Communications Security Establishment, Government of Canada, January, 1993.

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

[Gogu1] Goguen, J.A. and Meseguer, J., «Security Policies and Security Models», 1982 Symposium on Security and Privacy, pp. 11 — 20, IEEE, April, 1982.

[Gogu2] Goguen, J.A. and Meseguer, J., «Unwinding and Inference Control», 1984 Symposium on Security and Privacy, pp. 75 — 85, IEEE, May, 1984.

[ITSEC] Information Technology Security Evaluation Criteria, Version 1.2, Office for Official Publications of the European Communities, June, 1991.

[ISO/IEC 7498-2:1989] Information processing systems — Open Systems Interconnection — Basic Reference Model, Part 2: Security Architecture.

[TCSEC] Trusted Computer Systems Evaluation Criteria, US DoD 5200.28-STD, December, 1985.

Часть 2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ БЕЗОПАСНОСТИ

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

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

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

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

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

1.1. Расширение и сопровождение функциональных требований

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

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

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

1.2. Структура

Раздел 1 содержит введение.

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

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

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

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

Часть 1 ОК содержит следующую информацию, необходимую разработчикам ПЗ или ЗБ:

• термины, используемые в ОК, определены в разделе 2 части 1 ОК;
• структура ПЗ приведена в Приложении Б к части 1 ОК;
• структура ЗБ приведена в Приложении В к части 1 ОК.

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

На рисунках 1.1 и 1.2 показаны некоторые ключевые понятия парадигмы. Описаны и другие, не показанные на рисунках, ключевые понятия. Рассматриваемые ключевые понятия выделены полужирным курсивом. Определения терминов, приведенные в словаре в разделе 2 части 1 ОК, в этом подразделе не изменяются и не переопределяются.

<pre class="legal-pre">          /\           ┌─────────────────────────────────────────────────────────────────────┐
         /  \          │Объект оценки (ОО)                    Интерфейс ФБО (ИФБО)           │
        /    \         │                                     /          │         \          │
       /      \        │┌───────────────────────────────────────────────────────────────────┐│
      /        \       ││Субъект                                                            ││
     /          \      ││┌──────────────┐     ┌────────────────────────────────────┐        ││
    /            \     │││┌────────────┐│     │   Функции безопасности ОО (ФБО),   │        ││
   /              \────┼┼┤│  Атрибуты  │├────>│осуществляющие политику безопасности│        ││
  / Пользователь/  \   ││││безопасности││   ┌>│              ОО (ПБО)              │        ││
 /удаленный продукт \  │││└────────────┘│   │ └───────────────────────────────┬────┘        ││
/         ИТ         \ ││└──────────────┘   │       /\                    /\  │             ││
────────────────────── ││Субъект            │       │                     │   │             ││
          /\           ││┌──────────────┐   │       │                     │   │             ││
         /  \──────────┼┼┤┌────────────┐├───┘       │                     │   │             ││
        /    \         ││││  Атрибуты  ││           │                     │   │             ││
       /      \        ││││безопасности││           │                     │   │             ││
      /        \       │││└────────────┘│           │                     │   │             ││
     /          \      ││└──────────────┘           │       Объект/       │   │             ││
    /            \     ││                   Субъект │       информация    │   \/     Субъект││
   /              \    ││                   ┌───────┴──────┐┌─────────────┴┐┌──────────────┐││
  /  Пользователь  \───┼┼───────────────────┤┌────────────┐││┌────────────┐││┌────────────┐│││
  ──────────────────   ││                   ││  Атрибуты  ││││  Атрибуты  ││││  Атрибуты  ││││
                       ││ Область действия  ││безопасности││││безопасности││││безопасности││││
                       ││     ФБО (ОДФ)     │└────────────┘││└────────────┘││└────────────┘│││
                       ││                   └──────────────┘│ /  Ресурс  \ ││┌────────────┐│││
                       ││                                   │ \          / │││  Процесс   ││││
                       ││                                   │  ──────────  ││└────────────┘│││
                       ││                                   └──────────────┘└──────────────┘││</pre>
                       │└───────────────────────────────────────────────────────────────────┘│
                       └─────────────────────────────────────────────────────────────────────┘

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

<pre class="legal-pre">Локальный пользователь <─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─    Локальный (внутренний
        ┌────┐                                   для ОО) доверенный маршрут</pre>
        └────┘
<pre class="legal-pre">          /\       ┌─────────────────────────────────┐ Передача в пределах
          │        │Локальный ОО              ┌ ─ ─ ─┼ ─       ОО
          │        │         ┌──┐       ┌──┐  \/     │
          │        │ ┌───────┤ФБ├───────┤ФБ├───────┐ │
          │        │┌┴─┐     └──┘       └──┘     ┌─┴┐│
          └────────>│ФБ│                         │ФБ││
                   │└┬─┘     ┌──┐       ┌──┐     └─┬┘│</pre>
                   │ └───────┤ФБ├───────┤ФБ├───────┘ │
                 ┌>│         └──┘       └──┘         │<┐
Передача вне ОДФ │ └─────────────────────/\──────────┘ │ Передача между ФБО
<pre class="legal-pre">     │           │                       │             │         │
     └ ─ ─ ─ ─ ─>│                   ┌──>о             │<─ ─ ─ ─ ┘
                 \/                      │             \/
┌───────────────────────┐            │   о┌───────────────────────────────┐
│Недоверенный продукт ИТ│ Доверенный     ││Удаленный доверенный продукт ИТ│
└───────────┬───────────┘  маршрут  ─┘   о│┌─────────────────────────────┐│
            о             между ФБО      └>│   ФБ удаленного продукта    ││
            │                             │└──────────────┬──────────────┘│
            о                             └───────────────о───────────────┘
            │                                             │
            о           Удаленный пользователь            о
            │                   ┌────┐                    │</pre>
            └о─о─о─о─о─о─о─о─о─>└────┘<о─о─о─о─о─о─о─о─о─о┘

Рисунок 1.2. Функции безопасности в распределенном ОО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«аутентификационные данные» и «секреты»

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

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

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

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

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

           ┌────────────────────┐
           │Функциональный класс├──┐┌────────────────────┐
           └────────────────────┘  ├┤     Имя класса     │
                                   │└────────────────────┘
                                   │┌────────────────────┐
                                   ├┤Представление класса│
                                   │└────────────────────┘
                                   │  ┌────────────────────────┐
                                   │ ┌┴───────────────────────┐│
                                   │┌┴───────────────────────┐├┘
                                   └┤Функциональные семейства├┘
                                    └────────────────────────┘

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

2.1.1.1 Имя класса

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

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

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

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

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

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

         ┌────────────────────────┐
         │Функциональное семейство├─┐┌────────────────────────┐
         └────────────────────────┘ ├┤     Имя семейства      │
                                    │└────────────────────────┘
                                    │┌────────────────────────┐
                                    ├┤Характеристика семейства│
                                    │└────────────────────────┘
                                    │┌────────────────────────┐
                                    ├┤Ранжирование компонентов│
                                    │└────────────────────────┘
                                    │┌────────────────────────┐
                                    ├┤       Управление       │
                                    │└────────────────────────┘
                                    │┌────────────────────────┐
                                    ├┤         Аудит          │
                                    │└────────────────────────┘
                                    │  ┌────────────────────────┐
                                    │ ┌┴───────────────────────┐│
                                    │┌┴───────────────────────┐├┘
                                    └┤       Компоненты       ├┘
                                     └────────────────────────┘

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

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

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

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

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

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

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

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

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

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

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

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

2.1.2.4 Управление

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

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

2.1.2.5 Аудит

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

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

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

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

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

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

                ┌─────────┐
                │Компонент├──┐ ┌────────────────────────┐
                └─────────┘  ├─┤Идентификация компонента│
                             │ └────────────────────────┘
<pre class="legal-pre">                             │   ┌────────────────────────┐
                             │  ┌┴───────────────────────┐│</pre>
                             │ ┌┴───────────────────────┐├┘
                             ├─┤Функциональные элементы ├┘
                             │ └────────────────────────┘
                             │ ┌────────────────────────┐
                             └─┤      Зависимости       │
                               └────────────────────────┘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.4 Разрешенные операции с функциональными компонентами

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

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

К разрешенным операциям относятся:

• итерация — позволяет несколько раз использовать компонент с различным выполнением операций;
• назначение — позволяет специфицировать заданный параметр;
• выбор — позволяет специфицировать один или несколько элементов из списка;
• уточнение — позволяет добавить детали.

2.1.4.1 Итерация

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

2.1.4.2 Назначение

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

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

2.1.4.3 Выбор

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

2.1.4.4 Уточнение

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

Например, если для конкретного ОО требуется объяснение смысла терминов «субъект» и «объект» в рамках ЗБ, то эти термины подвергают операции уточнения.

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

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

Расположение компонентов в части 2 ОК не отражает какую-либо формальную таксономию.

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

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

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

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

Рисунок 2.4. Пример декомпозиции класса

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

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

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

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

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

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

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

Декомпозиция класса на составляющие его компоненты показана на рисунке 3.1.

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

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

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

         ┌──────────────────────────────────────────────────┐ ┌─┐
         │FAU_ARP Автоматическая реакция аудита безопасности├─┤1│
         └──────────────────────────────────────────────────┘ └─┘

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

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

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

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

Аудит: FAU_ARP.1

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

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

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

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

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

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

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

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

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

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

                                                              ┌─┐
         ┌──────────────────────────────────────────────────┐┌┤1│
         │   FAU_GEN Генерация данных аудита безопасности   ├┤└─┘
         └──────────────────────────────────────────────────┘│┌─┐
                                                             └┤2│
                                                              └─┘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости: #FAU_GEN.1 Генерация данных аудита FIA_UID.1 Выбор момента идентификации#.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иерархический для: FAU_SAA.1

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

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

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

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

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

Иерархический для: FAU_SAA.1

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

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

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

Зависимости: отсутствуют.

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

Иерархический для: FAU_SAA.3

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

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

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

Зависимости: отсутствуют.

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

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

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

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

                                                             ┌─┐
                                                            ┌┤1│
        ┌──────────────────────────────────────────────────┐│└─┘┌─┐
        │       FAU_SAR Просмотр аудита безопасности       ├┼───┤2│
        └──────────────────────────────────────────────────┘│┌─┐└─┘
                                                            └┤3│
                                                             └─┘

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

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

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

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

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

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

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

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

Аудит: FAU_SAR.1

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

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

Аудит: FAU_SAR.2

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

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

Аудит: FAU_SAR.3

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

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

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

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

него виде. Для внешнего объекта ИТ информацию требуется представлять только в электронном виде.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

         ┌──────────────────────────────────────────────────┐ ┌─┐
         │    FAU_SEL Выбор событий аудита безопасности     ├─┤1│
         └──────────────────────────────────────────────────┘ └─┘

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

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

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

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

Аудит: FAU_SEL.1

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

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

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

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

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

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

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

Зависимости: #FAU_GEN.1 Генерация данных аудита FMT_MTD.1 Управление данными ФБО#.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аудит: FAU_STG.3

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

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

Аудит: FAU_STG.4

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

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

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

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

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

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

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

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

Иерархический для: FAU_STG.1

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

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

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

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

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

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

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

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

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

Иерархический для: FAU_STG.3

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

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

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

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

Декомпозиция класса на составляющие его компоненты показана на рисунке 4.1.

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

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

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

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

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

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

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

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

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

Аудит: FCO_NRO.1

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

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

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

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

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

Аудит: FCO_NRO.2

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

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

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

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

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

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

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

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

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

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

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

Иерархический для: FCO_NRO.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аудит: FCO_NRR.1

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

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

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

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

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

Аудит: FCO_NRR.2

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

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

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

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

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

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

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

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

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

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

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

Иерархический для: FCO_NRR.1

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

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

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

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

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

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

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

Декомпозиция класса FCS на составляющие его компоненты показана на рисунке 5.1.

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

«Криптографическая поддержка»

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

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

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

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

                                                            ┌─┐
                                                           ┌┤1│
                                                           │└─┘┌─┐
            ┌─────────────────────────────────────────────┐├───┤2│
            │FCS_CKM Управление криптографическими ключами├┤┌─┐└─┘
            └─────────────────────────────────────────────┘├┤3│
                                                           │└─┘┌─┐
                                                           └───┤4│
                                                               └─┘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости: #[FCS_CKM.2 Распределение криптографических ключей или FCS_COP.1 Криптографические операции] FCS_CKM.4 Уничтожение криптографических ключей FMT_MSA.2 Безопасные значения атрибутов безопасности#.

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

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

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

Зависимости: #[FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности или FCS_CKM.1 Генерация криптографических ключей] FCS_CKM.4 Уничтожение криптографических ключей FMT_MSA.2 Безопасные значения атрибутов безопасности#.

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

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

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

Зависимости: #[FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности или FCS_CKM.1 Генерация криптографических ключей] FCS_CKM.4 Уничтожение криптографических ключей FMT_MSA.2 Безопасные значения атрибутов безопасности#.

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

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

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

Зависимости: #[FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности или FCS_CKM.1 Генерация криптографических ключей] FMT_MSA.2 Безопасные значения атрибутов безопасности#

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

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

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

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

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

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

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

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

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

Аудит: FCS_COP.1

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

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

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

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

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

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

Зависимости: #[FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности или FCS_CKM.1 Генерация криптографических ключей] FCS_CKM.4 Уничтожение криптографических ключей FMT_MSA.2 Безопасные значения атрибутов безопасности#.

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

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

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

• FDP_ACC «Политика управления доступом»;
• FDP_IFC «Политика управления информационными потоками».

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

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

• FDP_ACF «Функции управления доступом»;
• FDP_IFF «Функции управления информационными потоками»;
• FDP_ITT «Передача в пределах ОО»;
• FDP_RIP «Защита остаточной информации»;
• FDP_ROL «Откат»;
• FDP_SDI «Целостность хранимых данных»;

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

• FDP_DAU «Аутентификация данных»;
• FDP_ETC «Экспорт данных за пределы действия ФБО»;
• FDP_ITC «Импорт данных из-за пределов действия ФБО».

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

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

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

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

Декомпозиция класса FDP на составляющие его компоненты приведена на рисунках 6.1 и 6.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иерархический для: FDP_ACC.1

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

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

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

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

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

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

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

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

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

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

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

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

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

Аудит: FDP_ACF.1

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

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

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

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

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

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

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

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

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

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

Зависимости: #FDP_ACC.1 Ограниченное управление доступом FMT_MSA.3 Инициализация статических атрибутов#.

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

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

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

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

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

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

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

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

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

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

Аудит: FDP_DAU.1

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

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

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

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

Аудит: FDP_DAU.2

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

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

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

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

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

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

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

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

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

Зависимости: отсутствуют.

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

Иерархический для: FDP_DAU.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иерархический для: FDP_IFC.1

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

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

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

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

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

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

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

                                                          ┌─┐ ┌─┐
                                                         ┌┤1├─┤2│
                                                         │└─┘ └─┘
   ┌────────────────────────────────────────────────────┐│  ┌─┐  ┌─┐┌─┐
   │FDP_IFF Функции управления информационными потоками ├┼──┤3├──┤4├┤5│
   └────────────────────────────────────────────────────┘│  └─┘  └─┘└─┘
                                                         │┌─┐
                                                         └┤6│
                                                          └─┘

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

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

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

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

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

FDP_IFF.6 «Мониторинг неразрешенных информационных потоков» содержит требование, чтобы ПФБ отслеживала неразрешенные информационные потоки, максимальная интенсивность которых превышает заданное пороговое значение.

Управление: FDP_IFF.1, FDP_IFF.2

Дня функций управления из класса FMT может рассматриваться следующее действие:

а) управление атрибутами, используемыми для явного разрешения и запрещения доступа.

Управление: FDP_IFF.3, FDP_IFF.4, FDP_IFF.5

Действия по управлению для этих компонентов не предусмотрены.

Управление: FDP_IFF.6

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) включение или отключение функции мониторинга;

б) модификация максимальной интенсивности, которая отслеживается при мониторинге.

Аудит: FDP_IFF.1, FDP_IFF.2, FDP_IFF.5

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: разрешения на запрашиваемые информационные потоки;

б) базовый: все решения по запросам на информационные потоки;

в) детализированный: специальные атрибуты безопасности, используемые при принятии решений по осуществлению информационных потоков;

г) детализированный: некоторые специфические подмножества информации, передача которой обусловлена целями политики (например, аудит материалов, для которых гриф секретности был понижен).

Аудит: FDP_IFF.3, FDP_IFF.4, FDP_IFF.6

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: разрешения на запрашиваемые информационные потоки;

б) базовый: все решения по запросам на информационные потоки;

в) базовый: использование выявленных скрытых каналов;

г) детализированный: специфические атрибуты безопасности, используемые при принятии решений по осуществлению информационных потоков;

д) детализированный: некоторые специфические подмножества информации, передача которой обусловлена целями политики (например, аудит материалов, для которых гриф секретности был понижен);

е) детализированный: использование идентифицированных скрытых каналов, для которых оценка максимальной интенсивности превышает заданное пороговое значение.

FDP_IFF.1. Простые атрибуты безопасности

Иерархический для: Нет подчиненных компонентов.

#FDP_IFF.1.1 ФБО должны осуществлять [назначение: &ПФБ управления информационными потоками&], основанную на следующих типах атрибутов безопасности субъектов и информации: [назначение: &минимальное число и тип атрибутов безопасности&].

FDP_IFF.1.2 ФБО должны разрешать информационный поток между управляемыми субъектом и информацией посредством управляемой операции, если выполняются следующие правила: [назначение: &основанные на атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации (для каждой операции)&].

FDP_IFF.1.3 ФБО должны реализовать [назначение: &дополнительные правила ПФБ управления информационными потоками&].

FDP_IFF.1.4 ФБО должны предоставить следующее [назначение: &список дополнительных возможностей ПФБ&].

FDP_IFF.1.5 ФБО должны явно разрешать информационный поток, основываясь на следующих правилах: [назначение: &основанные на атрибутах безопасности правила, которые явно разрешают информационные потоки&].

FDP_IFF.1.6 ФБО должны явно запрещать информационный поток, основываясь на следующих правилах: [назначение: &основанные на атрибутах безопасности правила, которые явно запрещают информационные потоки&]#.

Зависимости: #FDP_IFC.1 Ограниченное управление информационными потоками FMT_MSA.3 Инициализация статических атрибутов#.

FDP_IFF.2. Иерархические атрибуты безопасности

Иерархический для: FDP_IFF.1

#FDP_IFF.2.1# ФБО должны осуществлять [назначение: ПФБ управления информационными потоками], основанную на следующих типах атрибутов безопасности субъектов и информации: [назначение: минимальное число и тип атрибутов безопасности].

#FDP_IFF.2.2# ФБО должны разрешать информационный поток между управляемыми субъектом и информацией посредством управляемой операции, если выполняются следующие правила, #основанные на упорядоченных связях между атрибутами безопасности#: [назначение: основанные на атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации (для каждой операции)].

#FDP_IFF.2.3# ФБО должны реализовать [назначение: дополнительные правила ПФБ управления информационными потоками].

#FDP_IFF.2.4# ФБО должны предоставить следующее [назначение: список дополнительных возможностей ПФБ].

#FDP_IFF.2.5# ФБО должны явно разрешать информационный поток, основываясь на следующих правилах: [назначение: основанные на атрибутах безопасности правила, которые явно разрешают информационные потоки].

#FDP_IFF.2.6# ФБО должны явно запрещать информационный поток, основываясь на следующих правилах: [назначение: основанные на атрибутах безопасности правила, которые явно запрещают информационные потоки].

#FDP_IFF.2.7 ФБО должны реализовать следующие отношения для любых двух допустимых атрибутов безопасности управления информационными потоками:

а) существует функция упорядочения, которая определяет для двух допустимых атрибутов безопасности, являются ли они равными, или же один из них больше другого, или же они несравнимы;

б) существует «наименьшая верхняя грань» в совокупности атрибутов безопасности такая, что для любых двух допустимых атрибутов безопасности найдется такой допустимый атрибут безопасности, который больше или равен двум допустимым атрибутам безопасности;

в) существует «наибольшая нижняя грань» в совокупности атрибутов безопасности такая, что для любых двух допустимых атрибутов безопасности найдется такой допустимый атрибут безопасности, который не больше двух допустимых атрибутов безопасности#.

Зависимости: FDP_IFC.1 Ограниченное управление информационными потоками FMT_MSA.3 Инициализация статических атрибутов.

FDP_IFF.3. Ограничение неразрешенных информационных потоков

Иерархический для: Нет подчиненных компонентов.

#FDP_IFF.3.1 ФБО должны осуществлять [назначение: &ПФБ управления информационными потоками&], чтобы ограничить интенсивность [назначение: &типы неразрешенных информационных потоков&] до [назначение: &максимальная интенсивность&]#.

Зависимости: #AVA_CCA.1 Анализ скрытых каналов FDP_IFC.1 Ограниченное управление информационными потоками#.

FDP_IFF.4. Частичное устранение неразрешенных информационных потоков

Иерархический для: FDP_IFF.3

#FDP_IFF.4.1# ФБО должны осуществлять [назначение: ПФБ управления информационными потоками], чтобы ограничить интенсивность [назначение: типы неразрешенных информационных потоков] до [назначение: максимальная интенсивность].

#FDP_IFF.4.2 ФБО должны предотвращать [назначение: &типы неразрешенных информационных потоков&]#.

Зависимости: AVA_CCA.1 Анализ скрытых каналов FDP_IFC.1 Ограниченное управление информационными потоками.

FDP_IFF.5. Отсутствие неразрешенных информационных потоков

Иерархический для: FDP_IFF.4

#FDP_IFF.5.1 ФБО должны обеспечить, чтобы не существовало никаких неразрешенных информационных потоков, способных нарушить [назначение: &имя ПФБ управления информационными потоками&]#.

Зависимости: #AVA_CCA.3 Исчерпывающий анализ скрытых каналов# FDP_IFC.1 Ограниченное управление информационными потоками.

FDP_IFF.6. Мониторинг неразрешенных информационных потоков

Иерархический для: Нет подчиненных компонентов.

#FDP_IFF.6.1 ФБО должны осуществлять [назначение: &ПФБ управления информационными потоками&], чтобы отследить [назначение: &типы неразрешенных информационных потоков&], когда они превышают [назначение: &максимальная интенсивность&]#.

Зависимости: #AVA_CCA.1 Анализ скрытых каналов FDP_IFC.1 Ограниченное управление информационными потоками#.

6.7. Импорт данных из-за пределов действия ФБО (FDP_ITC)

Характеристика семейства

Семейство FDP_ITC определяет механизмы для передачи данных пользователя в ОО таким образом, чтобы эти данные имели требуемые атрибуты безопасности и защиту. В семействе также рассматриваются ограничения на импорт и определение требуемых атрибутов безопасности, а также интерпретация атрибутов безопасности, ассоциированных с данными пользователя.

Ранжирование компонентов

                                                              ┌─┐
          ┌─────────────────────────────────────────────────┐┌┤1│
          │FDP_ITC Импорт данных из-за пределов действия ФБО├┤└─┘
          └─────────────────────────────────────────────────┘│┌─┐
                                                             └┤2│
                                                              └─┘

Это семейство содержит два компонента, связанные с сохранением атрибутов безопасности импортируемых данных пользователя для политик управления доступом и информационными потоками.

Компонент FDP_ITC.1 «Импорт данных пользователя без атрибутов безопасности» содержит требования, чтобы атрибуты безопасности правильно представляли данные пользователя и поставлялись независимо от объекта.

Компонент FDP_ITC.2 «Импорт данных пользователя с атрибутами безопасности» содержит требования, чтобы атрибуты безопасности правильно представляли данные пользователя, а также точно и однозначно ассоциировались с данными пользователя, импортируемыми из-за пределов ОДФ.

Управление: FDP_ITC.1, FDP_ITC.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) модификация дополнительных правил управления, используемых для импорта.

Аудит: FDP_ITC.1, FDP_ITC.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: успешный импорт данных пользователя, включая любые атрибуты безопасности;

б) базовый: все попытки импортировать данные пользователя, включая любые атрибуты безопасности;

в) детализированный: спецификация атрибутов безопасности для импортируемых данных пользователя, выполненная уполномоченным пользователем.

FDP_ITC.1. Импорт данных пользователя без атрибутов безопасности

Иерархический для: Нет подчиненных компонентов.

#FDP_ITC.1.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&] при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ.

FDP_ITC.1.2 ФБО должны игнорировать любые атрибуты безопасности, ассоциированные с данными пользователя, при импорте из-за пределов ОДФ.

FDP_ITC.1.3 ФБО должны реализовать следующие правила при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ: [назначение: &дополнительные правила управления импортом&]#.

Зависимости: #[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] FMT_MSA.3 Инициализация статических атрибутов#.

FDP_ITC.2. Импорт данных пользователя с атрибутами безопасности

Иерархический для: Нет подчиненных компонентов.

#FDP_ITC.2.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&] при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ.

FDP_ITC.2.2 ФБО должны использовать атрибуты безопасности, ассоциированные с импортируемыми данными пользователя.

FDP_ITC.2.3 ФБО должны обеспечить, чтобы используемый протокол предусматривал однозначную ассоциацию между атрибутами безопасности и полученными данными пользователя.

FDP_ITC.2.4 ФБО должны обеспечить, чтобы интерпретация атрибутов безопасности импортируемых данных пользователя была такой, как предусмотрено источником данных пользователя.

FDP_ITC.2.5 ФБО должны реализовать следующие правила при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ: [назначение: &дополнительные правила управления импортом&]#.

Зависимости: #[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] [FTP_ITC.1 Доверенный канал передачи между ФБО или FTP_TRP.1 Доверенный маршрут] FPT_TDC.1 Базовая согласованность данных ФБО между ФБО#.

6.8. Передача в пределах ОО (FDP_ITT)

Характеристика семейства

Семейство FDP_ITT содержит требования, связанные с защитой данных пользователя при их передаче между различными частями ОО по внутреннему каналу. Этим оно отличается от семейств FDP_UCT и FDP_UIT, которые обеспечивают защиту данных пользователя при их передаче между различными ФБО по внешнему каналу, а также от семейств FDP_ETC и FDP_ITC, которые связаны с передачей данных за пределы или из-за пределов действия ФБО.

Ранжирование компонентов

                                                             ┌─┐┌─┐
         ┌─────────────────────────────────────────────────┐┌┤1├┤2│
         │         FDP_ITT Передача в пределах ОО          ├┤└─┘└─┘
         └─────────────────────────────────────────────────┘│┌─┐┌─┐
                                                            └┤3├┤4│
                                                             └─┘└─┘

FDP_ITT.1 «Базовая защита внутренней передачи» содержит требование, чтобы данные пользователя были защищены при передаче между частями ОО.

FDP_ITT.2 «Разделение передачи по атрибутам» содержит в дополнение к первому компоненту требование разделения данных, основанного на значениях присущих ПФБ атрибутов.

FDP_ITT.3 «Мониторинг целостности» содержит требование, чтобы ФБ контролировала данные пользователя, передаваемые между частями ОО, на наличие идентифицированных ошибок целостности.

FDP_ITT.4 «Мониторинг целостности по атрибутам» расширяет третий компонент, разрешая дополнительную форму мониторинга целостности с разделением, использующим присущие ПФБ атрибуты.

Управление: FDP_ITT.1, FDP_ITT.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) если ФБО предоставляют несколько методов защиты данных пользователя во время передачи между физически разделенными частями ОО, то ФБО могут предусмотреть предопределенную роль с выбором метода, который будет использован.

Управление: FDP_ITT.3, FDP_ITT.4

Для функций управления из класса FMT может рассматриваться следующее действие:

а) возможность настройки спецификации действий, предпринимаемых после обнаружения ошибки целостности.

Аудит: FDP_ITT.1, FDP_ITT.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: успешные передачи данных пользователя с идентификацией используемого метода защиты;

б) базовый: все попытки передать данные пользователя с идентификацией используемого метода защиты и любых произошедших ошибок.

Аудит: FDP_ITT.3, FDP_ITT.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: успешные передачи данных пользователя с идентификацией используемого метода защиты целостности;

б) базовый: все попытки передать данные пользователя с идентификацией используемого метода защиты целостности и любых произошедших ошибок;

в) базовый: несанкционированные попытки изменить метод защиты целостности;

г) детализированный: действия, предпринимаемые после обнаружения ошибки целостности.

FDP_ITT.1. Базовая защита внутренней передачи

Иерархический для: Нет подчиненных компонентов.

#FDP_ITT.1.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], чтобы предотвратить [выбор: &раскрытие, модификация, недоступность&] данных пользователя при их передаче между физически разделенными частями ОО#.

Зависимости: #[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками]#.

FDP_ITT.2. Разделение передачи по атрибутам

Иерархический для: FDP_ITT.1

#FDP_ITT.2.1# ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы предотвратить [выбор: раскрытие, модификация, недоступность] данных пользователя при их передаче между физически разделенными частями ОО.

#FDP_ITT.2.2 ФБО должны разделять данные, контролируемые ПФБ, при их передаче между физически разделенными частями ОО, основываясь на значениях следующих атрибутов: [назначение: &атрибуты безопасности, которые требуют разделения данных&]#.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками].

FDP_ITT.3. Мониторинг целостности

Иерархический для: Нет подчиненных компонентов.

#FDP_ITT.3.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], чтобы контролировать данные пользователя, передаваемые между физически разделенными частями ОО, на наличие следующих ошибок: [назначение: &ошибки целостности&].

FDP_ITT.3.2 При обнаружении ошибки целостности данных ФБО должны предпринять [назначение: &действия при ошибке целостности&]#.

Зависимости: #[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] FDP_ITT.1 Базовая защита внутренней передачи#.

FDP_ITT.4. Мониторинг целостности по атрибутам

Иерархический для: FDP_ITT.3

#FDP_ITT.4.1# ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы контролировать данные пользователя, передаваемые между физически разделенными частями ОО, на наличие следующих ошибок: [назначение: ошибки целостности], #основываясь на следующих атрибутах: [назначение: &атрибуты безопасности, которые требуют разделения каналов передачи&]#.

#FDP_ITT.4.2# При обнаружении ошибки целостности данных ФБО должны предпринять [назначение: действия при ошибке целостности].

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] #FDP_ITT.2 Разделение передачи по атрибутам#.

6.9. Защита остаточной информации (FDP_RIP)

Характеристика семейства

Семейство FDP_RIP связано с необходимостью обеспечения последующей недоступности удаленной информации и отсутствия во вновь созданных объектах информации, которую не следует оставлять доступной. Это семейство содержит требования защиты информации, которая уже логически удалена или исключена из рассмотрения, но физически все еще может присутствовать в пределах ОО.

Ранжирование компонентов

         ┌─────────────────────────────────────────────────┐┌─┐┌─┐
         │       FDP_RIP Защита остаточной информации      ├┤1├┤2│
         └─────────────────────────────────────────────────┘└─┘└─┘

FDP_RIP.1 «Ограниченная защита остаточной информации» содержит требование, чтобы ФБО обеспечили недоступность содержания всей остаточной информации любых ресурсов для определенного подмножества объектов в ОДФ при распределении или освобождении ресурса.

FDP_RIP.2 «Полная защита остаточной информации» содержит требование, чтобы ФБО обеспечили недоступность содержания всей остаточной информации любых ресурсов для всех объектов при распределении или освобождении ресурса.

Управление: FDP_RIP.1, FDP_RIP.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) возможность настройки, когда выполнять защиту остаточной информации (т.е. при распределении или освобождении) в пределах ОО.

Аудит: FDP_RIP.1, FDP_RIP.2

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FDP_RIP.1. Ограниченная защита остаточной информации

Иерархический для: Нет подчиненных компонентов.

#FDP_RIP.1.1 ФБО должны обеспечить недоступность любого предыдущего информационного содержания ресурсов при [выбор: &распределение ресурса, освобождение ресурса&] для следующих объектов: [назначение: &список объектов&]#.

Зависимости: отсутствуют.

FDP_RIP.2. Полная защита остаточной информации

Иерархический для: FDP_RIP.1

#FDP_RIP.2.1# ФБО должны обеспечить недоступность любого предыдущего информационного содержания ресурсов при [выбор: распределение ресурса, освобождение ресурса] для #всех объектов#.

Зависимости: отсутствуют.

6.10. Откат (FDP_ROL)

Характеристика семейства

Операция отката включает в себя отмену последней операции или ряда операций, ограниченных некоторым пределом (например, периодом времени), и возврат к предшествующему известному состоянию. Откат предоставляет возможность отменить результаты операции или ряда операций, чтобы сохранить целостность данных пользователя.

Ранжирование компонентов

         ┌─────────────────────────────────────────────────┐┌─┐┌─┐
         │                   FDP_ROL Откат                 ├┤1├┤2│
         └─────────────────────────────────────────────────┘└─┘└─┘

FDP_ROL.1 «Базовый откат» связан с необходимостью вернуть обратно или отменить ограниченное число операций в определенных пределах.

FDP_ROL.2 «Расширенный откат» связан с необходимостью вернуть обратно или отменить все операции в определенных пределах.

Управление: FDP_ROL.1, FDP_ROL.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) возможность настройки предела ограничений, до которого возможен откат в пределах ОО;

б) разрешение выполнять операцию отката только вполне определенным ролям.

Аудит: FDP_ROL.1, FDP_ROL.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: все успешные операции отката;

б) базовый: все попытки выполнить операции отката;

в) детализированный: все попытки выполнить операции отката с идентификацией типов операций, отмененных при откате.

FDP_ROL.1. Базовый откат

Иерархический для: Нет подчиненных компонентов.

#FDP_ROL.1.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], чтобы разрешать откат [назначение: &список операций&] на [назначение: &список объектов&].

FDP_ROL.1.2 ФБО должны разрешать откат в пределах [назначение: &ограничение выполнения отката&]#.

Зависимости: #[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками]#.

FDP_ROL.2. Расширенный откат

Иерархический для: FDP_ROL.1

#FDP_ROL.2.1# ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы разрешать откат #всех операций# на [назначение: список объектов].

#FDP_ROL.2.2# ФБО должны разрешать откат в пределах [назначение: ограничение выполнения отката].

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками].

6.11. Целостность хранимых данных (FDP_SDI)

Характеристика семейства

Семейство FDP_SDI содержит требования, связанные с защитой данных пользователя во время их хранения в пределах ОДФ. Ошибки целостности могут воздействовать на данные пользователя, хранимые как в оперативной памяти, так и на запоминающих устройствах. Это семейство отличается от семейства FDP_ITT «Передача в пределах ОО», которое защищает данные пользователя от ошибок целостности во время их передачи в пределах ОО.

Ранжирование компонентов

         ┌─────────────────────────────────────────────────┐┌─┐┌─┐
         │       FDP_SDI Целостность хранимых данных       ├┤1├┤2│
         └─────────────────────────────────────────────────┘└─┘└─┘

FDP_SDI.1 «Мониторинг целостности хранимых данных» содержит требование, чтобы ФБ контролировала данные пользователя, хранимые в пределах ОДФ, на наличие идентифицированных ошибок целостности.

FDP_SDI.2 «Мониторинг целостности хранимых данных и предпринимаемые действия» дополняет предыдущий компонент действиями, предпринимаемыми после обнаружения ошибок.

Управление: FDP_SDI.1

Действия по управлению не предусмотрены.

Управление: FDP_SDI.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) возможность настройки действий, предпринимаемых после обнаружения ошибки целостности.

Аудит: FDP_SDI.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: успешные попытки проверки целостности данных пользователя с индикацией результатов проверки;

б) базовый: все попытки проверки целостности данных пользователя с индикацией результатов проверки, если она была выполнена;

в) детализированный: тип обнаруженной ошибки целостности.

Аудит: FDP_SDI.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: успешные попытки проверки целостности данных пользователя с индикацией результатов проверки;

б) базовый: все попытки проверки целостности данных пользователя с индикацией результатов проверки, если она была выполнена;

в) детализированный: тип обнаруженной ошибки целостности;

г) детализированный: действия, предпринимаемые при обнаружении ошибки целостности.

FDP_SDI.1. Мониторинг целостности хранимых данных

Иерархический для: Нет подчиненных компонентов.

#FDP_SDI.1.1 ФБО должны контролировать данные пользователи, хранимые в пределах ОДФ, на наличие [назначение: &ошибки целостности&] для всех объектов, основываясь на следующих атрибутах: [назначение: &атрибуты данных пользователя&]#.

Зависимости: отсутствуют.

FDP_SDI.2. Мониторинг целостности хранимых данных и предпринимаемые действия

Иерархический для: FDP_SDI.1

#FDP.SDI.2.1# ФБО должны контролировать данные пользователя, хранимые в пределах ОДФ, на наличие [назначение: ошибки целостности] для всех объектов, основываясь на следующих атрибутах: [назначение: атрибуты данных пользователя].

#FDP_SDI.2.2 При обнаружении ошибки целостности данных ФБО должны обеспечить [назначение: &предпринимаемые действия&]#.

Зависимости: отсутствуют.

6.12. Защита конфиденциальности данных пользователя при передаче между ФБО (FDP_UCT)

Характеристика семейства

Семейство FDP_UCT определяет требования по обеспечению конфиденциальности данных пользователя при их передаче по внешнему каналу между ОО и доверенными внешними объектами ИТ или между пользователями ОО и различных доверенных внешних объектов ИТ.

Ранжирование компонентов

          ┌─────────────────────────────────────────────────┐┌─┐
<pre class="legal-pre">          │    FDP_UCT Защита конфиденциальности данных     ├┤1│
          │       пользователя при передаче между ФБО       ││ │</pre>
          └─────────────────────────────────────────────────┘└─┘

Цель компонента FDP_UCT.1 «Базовая конфиденциальность обмена данными» состоит в предоставлении защиты от раскрытия данных пользователя во время их передачи.

Управление: FDP_UCT.1

Действия по управлению не предусмотрены.

Аудит: FDP_UCT.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров.

а) Минимальный: идентификатор любого пользователя или субъекта, использующего механизмы обмена данными.

б) Базовый: идентификатор неуполномоченного пользователя или субъекта, предпринимающего попытку использовать механизмы обмена данными.

в) Базовый: ссылка на имена или другую информацию индексации, полезную при идентификации данных пользователя, которые были переданы или получены. Может включать в себя атрибуты безопасности, ассоциированные с информацией.

#FDP_UCT.1 Базовая конфиденциальность обмена данными#

Иерархический для: Нет подчиненных компонентов.

#FDP_UCT.1.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], предоставляющую возможность [выбор: &отправление, получение&] данных пользователя способом, защищенным от несанкционированного раскрытия#.

Зависимости: #[FTP_ITC.1 Доверенный канал передачи между ФБО или FTP_TRP.1 Доверенный маршрут] [FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками]#

6.13 Защита целостности данных пользователя при передаче между ФБО (FDP_UIT)

Характеристика семейства

Семейство FDU_UIT определяет требования по обеспечению целостности данных пользователя при их передаче между ФБО и другим доверенным продуктом ИТ, а также для их восстановления при обнаружении ошибок. Как минимум, это семейство контролирует целостность данных пользователя на предмет модификации. Кроме того, семейство поддерживает различные способы исправления обнаруженных ошибок целостности.

Ранжирование компонентов

                                                  ┌─┐
                                                ┌─┤1│
          ┌───────────────────────────────────┐ │ └─┘
          │ FDP_UIT Защита целостности данных ├─┤
          │пользователя при передаче между ФБО│ │
          └───────────────────────────────────┘ │ ┌─┐ ┌─┐
                                                └─┤2├─┤3│
                                                  └─┘ └─┘

FDP_UIT.1 «Целостность передаваемых данных» связан с обнаружением модификации, удалений, вставок и повторения передаваемых данных пользователя.

FDP_UIT.2 «Восстановление переданных данных источником» связан с восстановлением исходных данных пользователя, полученных ФБО, с помощью источника — доверенного продукта ИТ.

FDP_UIT.3 «Восстановление переданных данных получателем» связан с самостоятельным восстановлением исходных данных пользователя, полученных ФБО, без какой-либо помощи источника — доверенного продукта ИТ.

Управление: FDP_UIT.1, FDP_UIT.2, FDP_UIT.3

Действия по управлению не предусмотрены.

Аудит: FDP_UIT.1

Если в ПЗ/ЗБ включено семейство FAU/GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров.

а) Минимальный: идентификатор любого пользователя или субъекта, использующего механизмы обмена данными.

б) Базовый: идентификатор любого пользователя или субъекта, пытающегося использовать механизмы обмена данными пользователя, но не уполномоченного делать это таким образом.

в) Базовый: ссылка на имена или другую информацию индексации, полезную при идентификации данных пользователя, которые были переданы или получены. Может включать атрибуты безопасности, ассоциированные с данными пользователя.

г) Базовый: любые идентифицированные попытки блокировать передачу данных пользователя.

д) Детализированный: типы и/или результаты любых обнаруженных модификаций переданных данных пользователя.

Аудит: FDP_UIT.2, FDP_UIT.3

Если в ПЗ/ЗБ включено семейство FAU/GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров.

а) Минимальный: идентификатор любого пользователя или субъекта, использующего механизмы обмена данными.

б) Минимальный: успешное восстановление после ошибок, включая тип обнаруженной ошибки.

в) Базовый: идентификатор любого пользователя или субъекта, пытающегося использовать механизмы обмена данными пользователя, но не уполномоченного делать это таким образом.

г) Базовый: ссылка на имена или другую информацию индексации, полезную при идентификации данных пользователя, которые были переданы или получены. Может включать в себя атрибуты безопасности, ассоциированные с данными пользователя.

д) Базовый: любые идентифицированные попытки блокировать передачу данных пользователя.

е) Детализированный: типы и/или результаты любых обнаруженных модификаций переданных данных пользователя.

FDP_UIT.1. Целостность передаваемых данных

Иерархический для: Нет подчиненных компонентов.

#FDP_UIT.1.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&] предоставляющую возможность [выбор: &отправление, получение&] данных пользователя способом, защищенным от следующих ошибок: [выбор: &модификация, удаление, вставка, повторение&].

FDP_UIT.1.2 ФБО должны быть способны определить после получения данных пользователя, произошли ли следующие ошибки: [выбор: &модификация, удаление, вставка, повторение&]#.

Зависимости: #[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] [FTP_ITC.1 Доверенный канал передачи между ФБО или FTP_TRP.1 Доверенный маршрут]#.

FDP_UIT.2. Восстановление переданных данных источником

Иерархический для: Нет подчиненных компонентов.

#FDP_UIT.2.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом и/или ПФБ управления информационными потоками&], предоставляющую возможность восстановления после [назначение: &список потенциально исправляемых ошибок&] с помощью источника — доверенного продукта ИТ#.

Зависимости: #[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] FDP_UIT.1 Целостность передаваемых данных FTP_ITC.1 Доверенный канал передачи между ФБО#.

FDP_UIT.3. Восстановление переданных данных получателем

Иерархический для: FDP_UIT.2

#FDP.UIT.3.1# ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], предоставляющую возможность восстановления после [назначение: список потенциально исправляемых ошибок] #без какой-либо помощи источника — доверенного продукта ИТ#.

Зависимости: [FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] FDP_UIT.1 Целостность передаваемых данных FTP_ITC.1 Доверенный канал передачи между ФБО.

7. Класс FIA. Идентификация и аутентификация

Семейства класса FIA содержат требования к функциям установления и верификации заявленного идентификатора пользователя.

Идентификация и аутентификация требуются для обеспечения ассоциации пользователей с соответствующими атрибутами безопасности (такими, как идентификатор, группы, роли, уровни безопасности или целостности).

Однозначная идентификация уполномоченных пользователей и правильная ассоциация атрибутов безопасности с пользователями и субъектами критичны для осуществления принятых политик безопасности. Семейства этого класса связаны с определением и верификацией идентификаторов пользователей, определением их полномочий на взаимодействие с ОО, а также с правильной ассоциацией атрибутов безопасности с каждым уполномоченным пользователем. Эффективность требований других классов (таких, как «Защита данных пользователя», «Аудит безопасности») во многом зависит от правильно проведенных идентификации и аутентификации пользователей.

Декомпозиция класса FDP на составляющие его компоненты приведена на рисунке 7.1.

         ┌──────────────────────────────┐
         │Идентификация и аутентификация│
         └┬─────────────────────────────┘
          │┌──────────────────────────────────────────┐ ┌─┐
          ├┤      FIA_AFL Отказы аутентификации       ├─┤1│
          │└──────────────────────────────────────────┘ └─┘
          │┌──────────────────────────────────────────┐ ┌─┐
          ├┤FIA_ATD Определение атрибутов пользователя├─┤1│
          │└──────────────────────────────────────────┘ └─┘
          │                                             ┌─┐
          │┌──────────────────────────────────────────┐┌┤1│
 ├┤ FIA_SOS Спецификация секретов ├┤└─┘
          │└──────────────────────────────────────────┘│┌─┐
<pre class="legal-pre">          │                                            └┤2│
          │                                             └─┘
          │                                                ┌─┐┌─┐
          │                                            ┌───┤1├┤2│
          │                                            │   └─┘└─┘
          │                                            │┌─┐
          │                                            ├┤3│
          │                                            │└─┘
          │┌──────────────────────────────────────────┐│   ┌─┐
          ├┤   FIA_UAU Аутентификация пользователя    ├┼───┤4│
          │└──────────────────────────────────────────┘│   └─┘
          │                                            │┌─┐
          │                                            ├┤5│
          │                                            │└─┘
          │                                            │   ┌─┐
          │                                            ├───┤6│
          │                                            │   └─┘
          │                                            │┌─┐
          │                                            └┤7│
          │                                             └─┘</pre>
          │┌──────────────────────────────────────────┐ ┌─┐┌─┐
          ├┤    FIA_UID Идентификация пользователя    ├─┤1├┤2│
          │└──────────────────────────────────────────┘ └─┘└─┘
          │┌──────────────────────────────────────────┐ ┌─┐
          └┤ FIA_USB Связывание пользователь-субъект  ├─┤1│
           └──────────────────────────────────────────┘ └─┘

7.1. Отказы аутентификации (FIA_AFL)

Характеристика семейства

Семейство FIA_AFL содержит требования к определению числа неуспешных попыток аутентификации и к действиям ФБО при превышении ограничений на неуспешные попытки аутентификации. Параметрами, определяющими возможное число попыток аутентификации, среди прочих могут быть количество попыток и допустимый интервал времени.

Ранжирование компонентов

             ┌──────────────────────────────────────────┐┌─┐
             │      FIA_AFL Отказы аутентификации       ├┤1│
             └──────────────────────────────────────────┘└─┘

FIA_AFL.1 «Обработка отказов аутентификации» содержит требование, чтобы ФБО были способны прервать процесс открытия сеанса после определенного числа неуспешных попыток аутентификации пользователя. Также требуется, чтобы после прерывания процесса открытия сеанса ФБО были бы способны блокировать учетные данные пользователя или место входа (например, рабочую станцию), с которого выполнялись попытки, до наступления определенного администратором условия.

Управление: FIA_AFL.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление ограничениями для неуспешных попыток аутентификации;

б) управление действиями, предпринимаемыми при неуспешной аутентификации.

Аудит: FIA_AFL.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: достижение ограничения неуспешных попыток аутентификации и предпринятые действия (например, блокирование терминала), а также, при необходимости, последующее восстановление нормального состояния (например, деблокирование терминала).

FIA_AFL.1. Обработка отказов аутентификации

Иерархический для: Нет подчиненных компонентов.

#FIA_AFL.1.1 ФБО должны обнаруживать, когда произойдет [назначение: &число&] неуспешных попыток аутентификации, относящихся к [назначение: &список событий аутентификации&].

FIA_AFL.1.2 При достижении или превышении определенного числа неуспешных попыток аутентификации ФБО должны выполнить [назначение: &список действий&]#.

Зависимости: #FIA_UAU.1 Выбор момента аутентификации#.

7.2. Определение атрибутов пользователя (FIA_ATD)

Характеристика семейства

Все уполномоченные пользователи могут, помимо идентификатора пользователя, иметь другие атрибуты безопасности, применяемые при осуществлении ПБО. Семейство FIA_ATD определяет требования для ассоциации атрибутов безопасности с пользователями в соответствии с необходимостью поддержки ПБО.

Ранжирование компонентов

             ┌──────────────────────────────────────────┐┌─┐
             │FIA_ATD Определение атрибутов пользователя├┤1│
             └──────────────────────────────────────────┘└─┘

FIA_ATD.1 «Определение атрибутов пользователя» позволяет поддерживать атрибуты безопасности пользователя для каждого пользователя индивидуально.

Управление: FIA_ATD.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) уполномоченный администратор может быть способен определять дополнительные атрибуты безопасности для пользователей, если это указано в операции назначения.

Аудит: FIA_ATD.1

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FIA_ATD.1. Определение атрибутов пользователя

Иерархический для: Нет подчиненных компонентов.

#FIA_ATD.1.1 ФБО должны поддерживать для каждого пользователя следующий список атрибутов безопасности: [назначение: &список атрибутов безопасности&]#.

Зависимости: отсутствуют.

7.3. Спецификация секретов (FIA_SOS)

Характеристика семейства

Семейство FIA_SOS определяет требования к механизмам, которые реализуют определенную метрику качества для предоставляемых секретов и генерируют секреты, удовлетворяющие определенной метрике.

Ранжирование компонентов

                                                          ┌─┐
             ┌──────────────────────────────────────────┐┌┤1│
             │      FIA_SOS Спецификация секретов       ├┤└─┘
             └──────────────────────────────────────────┘│┌─┐
                                                         └┤2│
                                                          └─┘

FIA_SOS.1 «Верификация секретов» содержит требование, чтобы ФБО верифицировали, отвечают ли секреты определенной метрике качества.

FIA_SOS.2 «Генерация секретов ФБО» содержит требование, чтобы ФБО были способны генерировать секреты, отвечающие определенной метрике качества.

Управление: FIA_SOS.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление метрикой, используемой для верификации секретов.

Управление: FIA_SOS.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление метрикой, используемой при генерации секретов.

Аудит: FIA_SOS.1, FIA_SOS.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: отклонение ФБО любого проверенного секрета;

б) базовый: отклонение или принятие ФБО любого проверенного секрета;

в) детализированный: идентификация любых изменений заданных метрик качества.

FIA_SOS.1. Верификация секретов

Иерархический для: Нет подчиненных компонентов.

#FIA_SOS.1.1 ФБО должны предоставить механизм для верификации того, что секреты отвечают [назначение: &определенная метрика качества&]#.

Зависимости: отсутствуют.

FIA_SOS.2. Генерация секретов ФБО

Иерархический для: Нет подчиненных компонентов.

#FIA.SOS.2.1 ФБО должны предоставить механизм генерации секретов, отвечающих [назначение: &определенная метрика качества&].

FIA_SOS.2.2 ФБО должны быть способны использовать генерируемые ими секреты для [назначение: &список функций ФБО&]#.

Зависимости: отсутствуют.

7.4. Аутентификация пользователя (FIA_UAU)

Характеристика семейства

Семейство FIA_UAU определяет типы механизмов аутентификации пользователя, предоставляемые ФБО. Оно также определяет те атрибуты, на которых необходимо базировать механизмы аутентификации пользователя.

Ранжирование компонентов

                                                         ┌─┐┌─┐
                                                     ┌───┤1├┤2│
                                                     │   └─┘└─┘
                                                     │┌─┐
                                                     ├┤3│
                                                     │└─┘
<pre class="legal-pre">         ┌──────────────────────────────────────────┐│   ┌─┐
         │   FIA_UAU Аутентификация пользователя    ├┼───┤4│
         └──────────────────────────────────────────┘│   └─┘</pre>
                                                     │┌─┐
                                                     ├┤5│
                                                     │└─┘
                                                     │   ┌─┐
                                                     ├───┤6│
                                                     │   └─┘
                                                     │┌─┐
                                                     └┤7│
                                                      └─┘

FIA_UAU.1 «Выбор момента аутентификации» позволяет пользователю выполнить некоторые действия до аутентификации пользователя.

FIA_UAU.2 «Аутентификация до любых действий пользователя» содержит требование, чтобы пользователи прошли аутентификацию прежде, чем ФБО даст им возможность предпринимать какие-либо действия.

FIA_UAU.3 «Аутентификация, защищенная от подделок» содержит требование, чтобы механизм аутентификации был способен выявить аутентификационные данные, которые были фальсифицированы или скопированы, и предотвратить их использование.

FIA_UAU.4 «Механизмы одноразовой аутентификации» содержит требование наличия механизма аутентификации, который оперирует аутентификационными данными одноразового использования.

FIA_UAU.5 «Сочетание механизмов аутентификации» содержит требование предоставления и применения различных механизмов аутентификации пользователей в особых случаях.

FIA_UAU.6 «Повторная аутентификация» содержит требование возможности определения событий, при которых необходима повторная аутентификация пользователя.

FIA_UAU.7 «Аутентификация с защищенной обратной связью» содержит требование, чтобы во время аутентификации пользователю предоставлялась строго ограниченная информация о ней.

Управление: FIA_UAU.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление аутентификационными данными администратором;

б) управление аутентификационными данными пользователем, ассоциированным с этими данными;

в) управление списком действий, которые могут быть предприняты до того, как пользователь аутентифицирован.

Управление: FIA_UAU.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление аутентификационными данными администратором;

б) управление аутентификационными данными пользователем, ассоциированным с этими данными.

Управление: FIA_UAU.3, FIA_UAU.4, FIA_UAU.7

Действия по управлению не предусмотрены.

Управление: FIA_UAU.5

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление механизмами аутентификации;

б) управление правилами аутентификации.

Управление: FIA_UAU.6

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление запросом на повторную аутентификацию, если для уполномоченного администратора предусмотрена возможность такого запроса.

Аудит: FIA_UAU.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: неуспешное использование механизма аутентификации;

б) базовый: все случаи использования механизма аутентификации;

в) детализированный: все действия при посредничестве ФБО до аутентификации пользователя.

Аудит: FIA_UAU.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: неуспешное использование механизма аутентификации;

б) базовый: все случаи использования механизма аутентификации.

Аудит: FIA_UAU.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обнаружение фальсифицированных аутентификационных данных;

б) базовый: все безотлагательно предпринимаемые меры и результаты проверок на фальсифицированные данные.

Аудит: FIA_UAU.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: попытки повторного использования аутентификационных данных.

Аудит: FIA_UAU.5

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: итоговое решение по аутентификации;

б) базовый: результат действия каждого активизированного механизма вместе с итоговым решением.

Аудит: FIA_UAU.6

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: неуспешная повторная аутентификации;

б) базовый: все попытки повторной аутентификации.

Аудит: FIA_UAU.7

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FIA_UAU.1. Выбор момента аутентификации

Иерархический для: Нет подчиненных компонентов.

#FIA_UAU.1.1 ФБО должны допускать выполнение [назначение: &список действий, выполняемых при посредничестве ФБО&] от имени пользователя прежде, чем пользователь аутентифицирован.

FIA_UAU.1.2 ФБО должны требовать, чтобы каждый пользователь был успешно аутентифицирован до разрешения любого другого действия, выполняемого при посредничестве ФБО от имени этого пользователя#.

Зависимости: #FIA_UID.1 Выбор момента идентификации#.

FIA_UAU.2. Аутентификация до любых действий пользователя

Иерархический для: FIA_UAU.1

#FIA.UAU.2.1# ФБО должны требовать, чтобы каждый пользователь был успешно аутентифицирован до разрешения #любого действия#, выполняемого при посредничестве ФБО от имени этого пользователя.

Зависимости: FIA_UID.1 Выбор момента идентификации.

FIA_UAU.3. Аутентификация, защищенная от подделок

Иерархический для: Нет подчиненных компонентов.

#FIA_UAU.3.1 ФБО должны [выбор: &обнаруживать, предотвращать&] применение любым пользователем ФБО аутентификационных данных, которые были подделаны.

FIA_UAU.3.2 ФБО должны [выбор: &обнаруживать, предотвращать&] применение любым пользователем ФБО аутентификационных данных, которые были скопированы у какого-либо другого пользователя ФБО#.

Зависимости: отсутствуют.

FIA_UAU.4. Механизмы одноразовой аутентификации

Иерархический для: Нет подчиненных компонентов.

#FIA_UAU.4.1 ФБО должны предотвращать повторное применение аутентификационных данных, связанных с [назначение: &идентифицированный механизм (механизмы) аутентификации&]#.

Зависимости: отсутствуют.

FIA_UAU.5. Сочетание механизмов аутентификации

Иерархический для: Нет подчиненных компонентов.

#FIA_UAU.5.1 ФБО должны предоставлять [назначение: &список сочетаемых механизмов аутентификации&] для поддержки аутентификации пользователя.

FIA_UAU.5.2 ФБО должны аутентифицировать любой представленный идентификатор пользователя согласно [назначение: &правила, описывающие как сочетание механизмов аутентификации обеспечивает аутентификацию&]#.

Зависимости: отсутствуют.

FIA_UAU.6. Повторная аутентификация

Иерархический для: Нет подчиненных компонентов.

#FIA_UAU.6.1 ФБО должны повторно аутентифицировать пользователя при [назначение: &список условий, при которых требуется повторная аутентификация&]#.

Зависимости: отсутствуют.

FIA_UAU.7. Аутентификация с защищенной обратной связью

Иерархический для: Нет подчиненных компонентов.

#FIA_UAU.7.1 ФБО должны предоставлять пользователю только [назначение: &список допустимой информации обратной связи&] во время выполнения аутентификации#.

Зависимости: #FIA_UAU.1 Выбор момента аутентификации#.

7.5. Идентификация пользователя (FIA_UID)

Характеристика семейства

Семейство FIA_UID определяет условия, при которых от пользователей должна требоваться собственная идентификация до выполнения при посредничестве ФБО каких-либо других действий, требующих идентификации пользователя.

Ранжирование компонентов

            ┌──────────────────────────────────────────┐┌─┐┌─┐
            │    FIA_UID Идентификация пользователя    ├┤1├┤2│
            └──────────────────────────────────────────┘└─┘└─┘

FIA_UID.1 «Выбор момента идентификации» позволяет пользователю выполнить некоторые действия перед своей идентификацией с использованием ФБО.

FIA_UID.2 «Идентификация до любых действий пользователя» содержит требование, чтобы пользователи идентифицировали себя прежде, чем ФБО позволят им предпринимать какие-либо действия.

Управление: FIA_UID.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление идентификаторами пользователей;

б) управление списком действий, если уполномоченный администратор может изменять действия, разрешенные до идентификации.

Управление: FIA_UID.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление идентификаторами пользователей.

Аудит: FIA_UID.1, FIA_UID.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: неуспешное использование механизма идентификации пользователя, включая представленный идентификатор пользователя;

б) базовый: все случаи использования механизма идентификации пользователя, включая представленный идентификатор пользователя.

FIA_UID.1. Выбор момента идентификации

Иерархический для: Нет подчиненных компонентов.

#FIA_UID.1.1 ФБО должны допускать [назначение: &перечень действий, выполняемых при посредничестве ФБО&] от имени пользователя прежде, чем он идентифицирован.

FIA_UID.1.2 ФБО должны требовать, чтобы каждый пользователь был успешно идентифицирован до разрешения любого другого действия, выполняемого при посредничестве ФБО от имени этого пользователя#.

Зависимости: отсутствуют.

FIA_UID.2. Идентификация до любых действий пользователя

Иерархический для: FIA_UID.1

#FIA_UID.2.1# ФБО должны требовать, чтобы каждый пользователь был успешно идентифицирован до разрешения #любого действия#, выполняемого при посредничестве ФБО от имени этого пользователя.

Зависимости: отсутствуют.

7.6. Связывание пользователь-субъект (FIA_USB)

Характеристика семейства

Для работы с ОО аутентифицированный пользователь обычно активизирует какой-либо субъект. Атрибуты безопасности этого пользователя ассоциируются (полностью или частично) с этим субъектом. Семейство FIA_USB определяет требования по созданию и сопровождению ассоциации атрибутов безопасности пользователя с субъектом, действующим от имени пользователя.

Ранжирование компонентов

            ┌──────────────────────────────────────────┐┌─┐
            │ FIA_USB Связывание пользователь-субъект  ├┤1│
            └──────────────────────────────────────────┘└─┘

FIA_USB.1 «Связывание пользователь-субъект» содержит требование сопровождения ассоциации между атрибутами безопасности пользователя и субъектом, действующим от имени пользователя.

Управление: FIA_USB.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) переопределение уполномоченным администратором заданных по умолчанию атрибутов безопасности субъекта.

Аудит: FIA_USB.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: неуспешное связывание атрибутов безопасности пользователя с субъектом (например, при создании субъекта);

б) базовый: успешное или неуспешное связывание атрибутов безопасности пользователя с субъектом (например, успешное или неуспешное создание субъекта).

FIA_USB.1. Связывание пользователь-субъект

Иерархический для: Нет подчиненных компонентов.

#FIA_USB.1.1 ФБО должны ассоциировать соответствующие атрибуты безопасности пользователя с субъектами, действующими от имени этого пользователя#.

Зависимости: #FIA_ATD.1 Определение атрибутов пользователя#.

8. Класс FMT. Управление безопасностью

Класс FMT предназначен для спецификации управления некоторыми аспектами ФБО: атрибутами безопасности, данными и отдельными функциями. Могут быть установлены различные роли управления, а также определено их взаимодействие, например распределение обязанностей.

Класс позволяет решать следующие задачи:

а) управление данными ФБО, которые включают в себя, например, предупреждающие сообщения;

б) управление атрибутами безопасности, которые включают в себя, например, списки управления доступом и перечни возможностей;

в) управление функциями из числа ФБО, которое включает в себя, например, выбор функций, а также правил или условий, влияющих на режим выполнения ФБО;

г) определение ролей безопасности.

Декомпозиция класса FMT на составляющие его компоненты приведена на рисунке 8.1.

          ┌────────────────────────┐
          │Управление безопасностью│
          └┬───────────────────────┘
           │┌───────────────────────────────────────────┐ ┌─┐
           ├┤FMT_MOF Управление отдельными функциями ФБО├─┤1│
           │└───────────────────────────────────────────┘ └─┘
<pre class="legal-pre">           │                                              ┌─┐
           │                                             ┌┤1│
           │                                             │└─┘
           │┌───────────────────────────────────────────┐│   ┌─┐</pre>
           ├┤FMT_MSA Управление атрибутами безопасности ├┼───┤2│
<pre class="legal-pre">           │└───────────────────────────────────────────┘│   └─┘
           │                                             │┌─┐
           │                                             └┤3│
           │                                              └─┘
           │                                              ┌─┐
           │                                             ┌┤1│
           │                                             │└─┘
           │┌───────────────────────────────────────────┐│   ┌─┐
           ├┤      FMT_MTD Управление данными ФБО       ├┼───┤2│
           │└───────────────────────────────────────────┘│   └─┘
           │                                             │┌─┐
           │                                             └┤3│
           │                                              └─┘</pre>
           │┌───────────────────────────────────────────┐ ┌─┐
           ├┤              FMT_REV Отмена               ├─┤1│
           │└───────────────────────────────────────────┘ └─┘
           │┌───────────────────────────────────────────┐ ┌─┐
           ├┤FMT_SAE Срок действия атрибута безопасности├─┤1│
           │└───────────────────────────────────────────┘ └─┘
           │                                              ┌─┐┌─┐
           │┌───────────────────────────────────────────┐┌┤1├┤2│
 └┤ FMT_SMR Роли управления безопасностью ├┤└─┘└─┘
            └───────────────────────────────────────────┘│┌─┐
                                                         └┤3│
                                                          └─┘

8.1. Управление отдельными функциями ФБО (FMT_MOF)

Характеристика семейства

Семейство FMT_MOF позволяет уполномоченным пользователям управлять функциями из числа ФБО. К ним относятся, например, функции аудита и аутентификации.

Ранжирование компонентов

             ┌───────────────────────────────────────────┐┌─┐
             │FMT_MOF Управление отдельными функциями ФБО├┤1│
             └───────────────────────────────────────────┘└─┘

FMT_MOF.1 «Управление режимом выполнения функций безопасности» позволяет уполномоченным пользователям (ролям) управлять режимом выполнения функций из числа ФБО, использующих правила или предусматривающих определенные условия, которыми можно управлять.

Управление: FMT_MOF.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление группой ролей, которые могут взаимодействовать с функциями из числа ФБО.

Аудит: FMT_MOF.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров;

а) базовый: все модификации режима выполнения функций из числа ФБО.

FMT_MOF.1. Управление режимом выполнения функций безопасности

Иерархический для: Нет подчиненных компонентов.

#FMT_MOF.1.1 ФБО должны ограничить возможность [выбор: &определение режима выполнения, отключение, подключение, модификация режима выполнения&] определенных функций [назначение: &список функций&] только [назначение: &уполномоченные идентифицированные роли&]#.

Зависимости: #FMT_SMR.1 Роли безопасности#.

8.2. Управление атрибутами безопасности (FMT_MSA)

Характеристика семейства

Семейство FMT_MSA допускает уполномоченных пользователей к управлению атрибутами безопасности. Такое управление может включать в себя возможности просмотра и модификации атрибутов безопасности.

Ранжирование компонентов

                                                          ┌─┐
                                                         ┌┤1│
                                                         │└─┘
            ┌───────────────────────────────────────────┐│   ┌─┐
            │FMT_MSA Управление атрибутами безопасности ├┼───┤2│
            └───────────────────────────────────────────┘│   └─┘
                                                         │┌─┐
                                                         └┤3│
                                                          └─┘

FMT_MSA.1 «Управление атрибутами безопасности» позволяет уполномоченным пользователям (ролям) управлять определенными атрибутами безопасности.

FMT_MSA.2 «Безопасные значения атрибутов безопасности» обеспечивает, чтобы значения, присвоенные атрибутам безопасности, были допустимы по безопасности.

FMT_MSA.3 «Инициализация статических атрибутов» обеспечивает, чтобы значения атрибутов безопасности по умолчанию являлись по своей сути либо разрешающими, либо ограничительными.

Управление: FMT_MSA.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление группой ролей, которые могут оперировать атрибутами безопасности.

Управление: FMT_MSA.2

Действия по управлению не предусмотрены.

Управление: FMT_MSA.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление группой ролей, которые могут определять начальные значения;

б) управление установкой разрешающих или ограничительных значений по умолчанию для данной ПФБ управления доступом.

Аудит: FMT_MSA.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) базовый: все модификации значений атрибутов безопасности.

Аудит: FMT_MSA.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: все предлагаемые и отклоненные значения атрибутов безопасности;

б) детализированный: все предлагаемые и принятые безопасные значения атрибутов безопасности.

Аудит: FMT_MSA.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) базовый: модификации настройки по умолчанию разрешающих или ограничительных правил;

б) базовый: все модификации начальных значений атрибутов безопасности.

FMT_MSA.1. Управление атрибутами безопасности

Иерархический для: Нет подчиненных компонентов.

#FMT_MSA.1.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом, ПФБ управления информационными потоками&], чтобы ограничить возможность [выбор: &изменение значений по умолчанию, запрос, модификация, удаление [назначение: другие операции&]] атрибутов безопасности [назначение: &список атрибутов безопасности&] только [назначение: &уполномоченные идентифицированные роли&]#.

Зависимости: #[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] FMT_SMR.1 Роли безопасности#.

FMT_MSA.2. Безопасные значения атрибутов безопасности

Иерархический для: Нет подчиненных компонентов.

#FMT_MSA.2.1 ФБО должны обеспечить присвоение атрибутам безопасности только безопасных значений#.

Зависимости: #ADV_SPM.1 Неформальная модель политики безопасности ОО [FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками] FMT_MSA.1 Управление атрибутами безопасности FMT_SMR.1 Роли безопасности#.

FMT_MSA.3 Инициализация статических атрибутов

Иерархический для: Нет подчиненных компонентов.

#FMT_MSA.3.1 ФБО должны осуществлять [назначение: &ПФБ управления доступом, ПФБ управления информационными потоками&], чтобы обеспечить [выбор: &ограничительные, разрешающие, с другими свойствами&] значения по умолчанию для атрибутов безопасности, которые используются для осуществления ПФБ.

FMT_MSA.3.2 ФБО должны предоставить возможность [назначение: &уполномоченные идентифицированные роли&] определять альтернативные начальные значения для отмены значений по умолчанию при создании объекта или информации#.

Зависимости: #FMT_MSA.1 Управление атрибутами безопасности FMT_SMR.1 Роли безопасности#.

8.3. Управление данными ФБО (FMT_MTD)

Характеристика семейства

Семейство FMT_MTD допускает уполномоченных пользователей (роли) к управлению данными ФБО. Примеры данных ФБО: информация аудита, текущее значение времени, конфигурация системы, другие параметры конфигурации ФБО.

Ранжирование компонентов

                                                          ┌─┐
                                                         ┌┤1│
                                                         │└─┘
<pre class="legal-pre">            ┌───────────────────────────────────────────┐│   ┌─┐
            │      FMT_MTD Управление данными ФБО       ├┼───┤2│
            └───────────────────────────────────────────┘│   └─┘</pre>
                                                         │┌─┐
                                                         └┤3│
                                                          └─┘

FMT_MTD.1 «Управление данными ФБО» позволяет уполномоченным пользователям управлять данными ФБО.

FMT_MTD.2 «Управление ограничениями данных ФБО» определяет действия, предпринимаемые при достижении или превышении ограничений данных ФБО.

FMT_MTD.3 «Безопасные данные ФБО» обеспечивает, чтобы значения, присвоенные данным ФБО, были допустимы по безопасности.

Управление: FMT_MTD.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление группой ролей, которые могут оперировать данными ФБО.

Управление: FMT_MTD.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление группой ролей, которые могут оперировать ограничениями данных ФБО.

Управление: FMT_MTD.3

Действия по управлению не предусмотрены.

Аудит: FMT_MTD.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) базовый: все модификации значений данных ФБО.

Аудит: FMT_MTD.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) базовый: все модификации ограничений данных ФБО;

б) базовый: все модификации действий, предпринимаемых при нарушениях ограничений.

Аудит: FMT_MTD.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: все отклоненные значения данных ФБО.

FMT_MTD.1. Управление данными ФБО

Иерархический для: Нет подчиненных компонентов.

#FMT_MTD.1.1 ФБО должны ограничить возможность [выбор: &изменение значений по умолчанию, запрос, модификация, удаление, очистка& [назначение: &другие операции&]] следующих данных [назначение: &список данных ФБО&] только [назначение: &уполномоченные идентифицированные роли&]#.

Зависимости: #FMT_SMR.1 Роли безопасности#.

FMT_MTD.2. Управление ограничениями данных ФБО

Иерархический для: Нет подчиненных компонентов.

#FMT_MTD.2.1 ФБО должны предоставить возможность определения ограничений следующих данных [назначение: &список данных ФБО&] только [назначение: &уполномоченные идентифицированные роли&].

FMT_MTD.2.2 ФБО должны предпринять следующие действия при достижении или превышении данными ФБО установленных выше ограничений: [назначение: &предпринимаемые действия&]#.

Зависимости: #FMT_MTD.1 Управление данными ФБО FMT_SMR.1 Роли безопасности#.

FMT_MTD.3. Безопасные данные ФБО

Иерархический для: Нет подчиненных компонентов.

#FMT_MTD.3.1 ФБО должны обеспечить присвоение данным ФБО только безопасных значений#.

Зависимости: #ADV_SPM.1 Неформальная модель политики безопасности ОО FMT_MTD.1 Управление данными ФБО#.

8.4. Отмена (FMT_REV)

Характеристика семейства

Семейство FMT_REV связано с отменой атрибутов безопасности различных сущностей в пределах ОО.

Ранжирование компонентов

             ┌───────────────────────────────────────────┐┌─┐
             │              FMT_REV Отмена               ├┤1│
             └───────────────────────────────────────────┘└─┘

FMT_REV.1 «Отмена» предусматривает отмену атрибутов безопасности, осуществляемую в некоторый момент времени.

Управление: FMT_REV.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление группой ролей, которые могут вызывать отмену атрибутов безопасности;

б) управление списками пользователей, субъектов, объектов и других ресурсов, для которых возможна отмена;

в) управление правилами отмены.

Аудит: FMT_REV.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: неуспешная отмена атрибутов безопасности;

б) базовый: все попытки отменить атрибуты безопасности.

FMT_REV.1. Отмена

Иерархический для: Нет подчиненных компонентов.

#FMT_REV.1.1 ФБО должны ограничить возможность отмены атрибутов безопасности, ассоциированных с [выбор: &пользователи, субъекты, объекты, другие дополнительные ресурсы&], в пределах ОДФ только [назначение: &уполномоченные идентифицированные роли&].

FMT_REV.1.2 ФБО должны реализовать правила [назначение: &правила отмены&]#.

Зависимости: #FMT_SMR.1 Роли безопасности#.

8.5. Срок действия атрибута безопасности (FMT_SAE)

Характеристика семейства

Семейство FMT_SАЕ связано с возможностью установления срока действия атрибутов безопасности.

Ранжирование компонентов

             ┌───────────────────────────────────────────┐┌─┐
             │FMT_SAE Срок действия атрибута безопасности├┤1│
             └───────────────────────────────────────────┘└─┘

FMT_SAE.1 «Ограниченная по времени авторизация» предоставляет возможность уполномоченному пользователю устанавливать срок действия определенных атрибутов безопасности.

Управление: FMT_SAE.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление списком атрибутов безопасности с назначенным сроком действия;

б) предпринимаемые по истечении назначенного срока действия.

Аудит: FMT_SAE.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) базовый: назначение срока действия для атрибута;

б) базовый: действия, предпринятые по истечении назначенного срока.

FMT_SAE.1. Ограниченная по времени авторизация

Иерархический для: Нет подчиненных компонентов.

#FMT_SAE.1.1 ФБО должны ограничить возможность назначать срок действия для [назначение: &список атрибутов безопасности, для которых предусмотрено установление срока действия&] только [назначение: &идентифицированные уполномоченные роли&].

FMT_SAE.1.2 Для каждого из этих атрибутов безопасности ФБО должны быть способны к [назначение: &список действий, предпринимаемых для каждого атрибута безопасности&] по истечении его срока действия#.

Зависимости: #FMT_SMR.1 Роли безопасности FPT_STM.1 Надежные метки времени#.

8.6. Роли управления безопасностью (FMT_SMR)

Характеристика семейства

Семейство FMT_SMR предназначено для управления назначением различных ролей пользователям. Возможности этих ролей по управлению безопасностью описаны в других семействах этого класса.

Ранжирование компонентов

                                                          ┌─┐┌─┐
            ┌───────────────────────────────────────────┐┌┤1├┤2│
            │   FMT_SMR Роли управления безопасностью   ├┤└─┘└─┘
            └───────────────────────────────────────────┘│┌─┐
                                                         └┤3│
                                                          └─┘

FMT_SMR.1 «Роли безопасности» определяет роли, относящиеся к безопасности и распознаваемые ФБО.

FMT_SMR.2 «Ограничения на роли безопасности» определяет, что в дополнение к определению ролей имеются правила, которые управляют отношениями между ролями.

FMT_SMR.3 «Принятие ролей» содержит требование, чтобы принятие роли производилось только через точный запрос к ФБО.

Управление: FMT_SMR.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление группой пользователей — исполнителей роли.

Управление: FMT_SMR.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление группой пользователей — исполнителей роли;

б) управление условиями, которым должны удовлетворять роли.

Управление: FMT_SMR.3

Действия по управлению не предусмотрены.

Аудит: FMT_SMR.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: модификация группы пользователей — исполнителей роли;

б) детализированный: каждое использование прав, предоставленных ролью.

Аудит: FMT_SMR.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: модификация в группе пользователей — исполнителей роли;

б) минимальный: неуспешные попытки использовать роль вследствие ограничений, накладываемых на роли;

в) детализированный: каждое использование прав, предоставленных ролью.

Аудит: FMT_SMR.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: конкретные запросы на принятие роли.

FMT_SMR.1. Роли безопасности

Иерархический для: Нет подчиненных компонентов.

#FMT_SMR.1.1 ФБО должны поддерживать следующие роли [назначение: &уполномоченные идентифицированные роли&].

FMT_SMR.1.2 ФБО должны быть способны ассоциировать пользователей с ролями#.

Зависимости: #FIA_UID.1 Выбор момента идентификации#.

FMT_SMR.2. Ограничения на роли безопасности

Иерархический для: FMT_SMR.1

#FMT_SMR.2.1# ФБО должны поддерживать следующие роли [назначение: уполномоченные идентифицированные роли].

#FMT_SMR.2.2# ФБО должны быть способны ассоциировать пользователей с ролями.

#FMT_SMR.2.3 ФБО должны обеспечить выполнение [назначение: &условия для различных ролей&]#.

Зависимости: FIA_UID.1 Выбор момента идентификации.

FMT_SMR.3. Принятие ролей

Иерархический для: Нет подчиненных компонентов.

#FMT_SMR.3.1 ФБО должны требовать точный запрос для принятия следующих ролей [назначение: &список ролей&]#.

Зависимости: #FMT_SMR.1 Роли безопасности#.

9. Класс FPR. Приватность

Класс FPR содержит требования приватности. Эта требования предоставляют пользователю защиту от раскрытия его идентификатора и злоупотребления этим другими пользователями.

Декомпозиция класса FPR на составляющие его компоненты приведена на рисунке 9.1.

             ┌───────────┐
             │Приватность│
             └┬──────────┘
              │┌────────────────────────────────┐ ┌─┐┌─┐
              ├┤      FPR_ANO Анонимность       ├─┤1├┤2│
              │└────────────────────────────────┘ └─┘└─┘
<pre class="legal-pre">              │                                       ┌─┐
              │                                      ┌┤2│</pre>
              │┌────────────────────────────────┐ ┌─┐│└─┘
 ├┤ FPR_PSE Псевдонимность ├─┤1├┤
              │└────────────────────────────────┘ └─┘│┌─┐
<pre class="legal-pre">              │                                      └┤3│
              │                                       └─┘</pre>
              │┌────────────────────────────────┐ ┌─┐
              ├┤FPR_UNL Невозможность ассоциации├─┤1│
              │└────────────────────────────────┘ └─┘
<pre class="legal-pre">              │                                       ┌─┐┌─┐
              │                                  ┌────┤1├┤2│</pre>
              │┌────────────────────────────────┐│┌─┐ └─┘└─┘
              └┤       FPR_UNO Скрытность       ├┼┤3│
               └────────────────────────────────┘│└─┘ ┌─┐
                                                 └────┤4│
                                                      └─┘

Рисунок 9.1. Декомпозиция класса "Приватность"

9.1. Анонимность (FPR_ANO)
Характеристика семейства
Семейство FPR_ANO обеспечивает, чтобы пользователь мог использовать ресурс или услугу ОО без раскрытия своего идентификатора. Требования семейства предоставляют защиту идентификатора пользователя. Семейство не предназначено для защиты идентификаторов субъектов.
Ранжирование компонентов

                ┌────────────────────────────────┐┌─┐┌─┐
                │      FPR_ANO Анонимность       ├┤1├┤2│
                └────────────────────────────────┘└─┘└─┘

FPR_ANO.1 «Анонимность» содержит требование, чтобы другие пользователи или субъекты не могли определить идентификатор пользователя, связанного с субъектом или операцией.

FPR_ANO.2 «Анонимность без запроса информации» расширяет требования FPR_ANO.1, обеспечивая, чтобы ФБО не запрашивали идентификатор пользователя.

Управление: FPR_ANO.1, FPR_ANO.2

Действия по управлению для этих компонентов не предусмотрены.

Аудит: FPR_ANO.1, FPR_ANO.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обращение к механизму анонимности.

FPR_ANO.1. Анонимность

Иерархический для: Нет подчиненных компонентов.

#FPR_ANO.1.1 ФБО должны обеспечить, чтобы [назначение: &совокупность пользователей и/или субъектов&] была не способна определить подлинное имя пользователя, связанного с [назначение: &список субъектов и/или операций, и/или объектов&]#.

Зависимости: отсутствуют.

FPR_ANO.2. Анонимность без запроса информации

Иерархический для: FPR_ANO.1

#FPR_ANO.2.1# ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить подлинное имя пользователя, связанного с [назначение: список субъектов и/или операций, и/или объектов].

#FPR_ANO.2.2 ФБО должны предоставить [назначение: &список услуг&] для [назначение: &список субъектов&] без запроса какой-либо ссылки на подлинное имя пользователя#.

Зависимости: отсутствуют.

9.2. Псевдонимность (FPR_PSE)

Характеристика семейства

Семейство FPR_PSE обеспечивает, чтобы пользователь мог использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время ответственным за это использование.

Ранжирование компонентов

                                                       ┌─┐
                                                      ┌┤2│
                 ┌────────────────────────────────┐┌─┐│└─┘
                 │     FPR_PSE Псевдонимность     ├┤1├┤
                 └────────────────────────────────┘└─┘│┌─┐
                                                      └┤3│
                                                       └─┘

FPR_PSE.1 «Псевдонимность» содержит требование, чтобы некоторая совокупность пользователей и/или субъектов была не способна определить идентификатор пользователя, связанного с субъектом или операцией, но в то же время этот пользователь оставался ответственным за свои действия.

FPR_PSE.2 «Обратимая псевдонимность» содержит требование, чтобы ФБО предоставили возможность определить первоначальный идентификатор пользователя, основываясь на представленном псевдониме.

FPR_PSE.3 «Альтернативная псевдонимность» содержит требование, чтобы при создании псевдонима для идентификатора пользователя ФБО следовали определенным правилам.

Управление: FPR_PSE.1, FPR_PSE.2, FPR_PSE.3

Действия по управлению для этих компонентов не предусмотрены.

Аудит: FPR_PSE.1, FPR_PSE.2, FPR_PSE.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: идентификатор субъекта/пользователя, который потребовал раскрытия идентификатора пользователя.

FPR_PSE.1. Псевдонимность

Иерархический для: Нет подчиненных компонентов.

#FPR_PSE.1.1 ФБО должны обеспечить, чтобы [назначение: &совокупность пользователей и/или субъектов&] была не способна определить подлинное имя пользователя, связанного с [назначение: &список субъектов и/или операций, и/или объектов&].

FPR_PSE.1.2 ФБО должны быть способны предоставить [назначение: &количество псевдонимов&] псевдонимов подлинного имени пользователя для [назначение: &список субъектов&].

FPR_PSE.1.3 ФБО должны быть способны [выбор: &определить псевдоним пользователя, принять псевдоним от пользователя&] и верифицировать его соответствие [назначение: &метрика псевдонимов&]#.

Зависимости: отсутствуют.

FPR_PSE.2. Обратимая псевдонимность

Иерархический для: FPR_PSE.1

#FPR_PSE.2.1# ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить подлинное имя пользователя, связанное с [назначение: список субъектов и/или операций, и/или объектов].

#FPR_PSE.2.2# ФБО должны быть способны предоставить [назначение: количество псевдонимов] псевдонимов подлинного имени пользователя для [назначение: список субъектов].

#FPR_PSE.2.3# ФБО должны быть способны [выбор: определить псевдоним пользователя, принять псевдоним от пользователя], и верифицировать его соответствие [назначение: метрика псевдонимов].

#FPR_PSE.2.4 ФБО должны предоставить [выбор: &уполномоченный пользователь&, [назначение: &список доверенных субъектов&]] возможность определять идентификатор пользователя по представленному псевдониму только при выполнении [назначение: &список условий&]#.

Зависимости: #FIA_UID.1 Выбор момента идентификации#.

FPR_PSE.3. Альтернативная псевдонимность

Иерархический для: FPR_PSE.1

#FPR_PSR.3.1# ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить подлинное имя пользователя, связанное с [назначение: список субъектов и/или операций, и/или объектов].

#FPR_PSE.3.2# ФБО должны быть способны предоставить [назначение: количество псевдонимов] псевдонимов подлинного имени пользователя для [назначение: список субъектов].

#FPR_PSE.3.3# ФБО должны быть способны [выбор: определить псевдоним пользователя, принять псевдоним от пользователя], и верифицировать его соответствие [назначение: метрика псевдонимов].

#FPR_PSR.3.4 ФБО должны предоставить псевдоним для подлинного имени пользователя, который должен быть идентичен псевдониму, предоставленному ранее, при следующих условиях [назначение: &список условий&]; в противном случае предоставляемый псевдоним должен быть не связан с предоставленными ранее псевдонимами#.

Зависимости: отсутствуют.

9.3. Невозможность ассоциации (FPR_UNL)

Характеристика семейства

Семейство FPR_UNL обеспечивает, чтобы пользователь мог неоднократно использовать ресурсы или услуги, не давая в то же время никому возможности связать вместе их использование.

Ранжирование компонентов

                  ┌────────────────────────────────┐┌─┐
                  │FPR_UNL Невозможность ассоциации├┤1│
                  └────────────────────────────────┘└─┘

FPR_UNL.1 «Невозможность ассоциации» содержит требование, чтобы пользователи и/или субъекты были не способны определить, были ли определенные операции в системе инициированы одним и тем же пользователем.

Управление: FPR_UNL.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление функцией предотвращения ассоциации.

Аудит: FPR_UNL.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обращение к механизму предотвращения ассоциации.

FPR_UNL.1. Невозможность ассоциации

Иерархический для: Нет подчиненных компонентов.

#FPR_UNL.1.1 ФБО должны обеспечить, чтобы [назначение: &совокупность пользователей и/или субъектов&] была не способна определить, что [назначение: &список операций&] [выбор: &были инициированы одним и тем же пользователем, связаны следующим образом& [назначение: &список соотношений&]]#.

Зависимости: отсутствуют.

9.4. Скрытность (FPR_UNO)

Характеристика семейства

Семейство FPR_UNO обеспечивает, чтобы пользователь мог использовать ресурс или услугу без предоставления кому-либо, в особенности третьей стороне, информации об использовании ресурса или услуги.

Ранжирование компонентов

                                                     ┌─┐┌─┐
                                                 ┌───┤1├┤2│
               ┌────────────────────────────────┐│┌─┐└─┘└─┘
               │       FPR_UNO Скрытность       ├┼┤3│
               └────────────────────────────────┘│└─┘┌─┐
                                                 └───┤4│
                                                     └─┘

FPR_UNO.1 «Скрытность» содержит требование, чтобы пользователи и/или субъекты не могли определить, выполняется ли операция.

FPR_UNO.2 «Распределение информации, влияющее на скрытность» содержит требование, чтобы ФБО предоставили специальные механизмы для предотвращения концентрации информации, связанной с приватностью, в пределах ОО. Такая концентрация могла бы повлиять на обеспечение скрытности при нарушениях безопасности.

FPR_UNO.3 «Скрытность без запроса информации» содержит требование, чтобы ФБО не пытались получить информацию, связанную с приватностью, что может использоваться для нарушения скрытности.

FPR_UNO.4 «Открытость для уполномоченного пользователя» содержит требование, чтобы ФБО предоставили одному или нескольким уполномоченным пользователям возможность наблюдать за использованием ресурсов и/или услуг.

Управление: FPR_UNO.1, FPR_UNO.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление режимом выполнения функции скрытности.

Управление: FPR_UNO.3

Действия по управлению для этого компонента не предусмотрены.

Управление: FPR_UNO.4

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление совокупностью уполномоченных пользователей, которые способны определить, выполнялись ли операции.

Аудит: FPR_UNO.1, FPR_UNO.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обращение к механизму скрытности.

Аудит: FPR_UNO.3

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

Аудит: FPR_UNO.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: наблюдение за использованием ресурса или услуги пользователем или субъектом.

FPR_UNO.1. Скрытность

Иерархический для: Нет подчиненных компонентов.

#FPR_UNO.1.1 ФБО должны обеспечить, чтобы [назначение: &совокупность пользователей и/или субъектов&] была не способна наблюдать следующие операции [назначение: &список операций&] на [назначение: &список объектов&], выполняемые [назначение: &совокупность защищаемых пользователей и/или субъектов&]#.

Зависимости: отсутствуют.

FPR_UNO.2. Распределение информации, влияющее на скрытность

Иерархический для: FPR_UNO.1

#FPR_UNO.2.1# ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна наблюдать следующие операции [назначение: список операций] на [назначение: список объектов], выполняемые [назначение: совокупность защищаемых пользователей и/или субъектов].

#FPR_UNO.2.2 ФБО должны распределить (назначение: &информация, связанная со скрытностью&] среди различных частей ОО так, чтобы во время существования информации выполнялись следующие условия: [назначение: &список условий&]#.

Зависимости: отсутствуют.

FPR_UNO.3. Скрытность без запроса информации

Иерархический для: Нет подчиненных компонентов.

#FPR_UNO.3.1 ФБО должны предоставить [назначение: &список услуг&] для [назначение: &список субъектов&] без запроса каких-либо ссылок на [назначение: &информация, связанная с приватностью&]#.

Зависимости: #FPR_UNO.1 Скрытность#.

FPR_UNO.4. Открытость для уполномоченного пользователя

Иерархический для: Нет подчиненных компонентов.

#FPR_UNO.4.1 ФБО должны предоставить [назначение: &совокупность уполномоченных пользователей&] возможность наблюдать за использованием [назначение: &список ресурсов и/или услуг&]#.

Зависимости: отсутствуют.

10. Класс FPT. Защита ФБО

Класс FPT содержит семейства функциональных требований, которые связаны с целостностью и управлением механизмами, реализованными в ФБО, не завися при этом от особенностей ПБО, а также с целостностью данных ФБО, не завися от специфического содержания данных ПБО. В некотором смысле компоненты семейств этого класса дублируют компоненты из класса FDP и могут даже использовать одни и те же механизмы. Однако класс FDP специализирован на защите данных пользователя, в то время как класс FPT нацелен на защиту данных ФБО. Фактически, компоненты из класса FPT необходимы для обеспечения требований невозможности нарушения и обхода политик ФБ данного ОО.

В рамках этого класса выделяются три существенные составные части ФБО:

а) абстрактная машина ФБО, т.е. виртуальная или физическая машина, на которой выполняется оцениваемая реализация ФБО;

б) реализация ФБО, которая выполняется на абстрактной машине и реализует механизмы, осуществляющие ПБО;

в) данные ФБО, которые являются административными базами данных, управляющими осуществлением ПБО.

Декомпозиция класса FPT на составляющие его компоненты приведена на рисунках 10.1 и 10.2.

    ┌──────────┐
    │Защита ФБО│
    └┬─────────┘
     │┌────────────────────────────────────────────────────┐ ┌─┐
     ├┤  FPT_AMT Тестирование базовой абстрактной машины   ├─┤1│
     │└────────────────────────────────────────────────────┘ └─┘
     │┌────────────────────────────────────────────────────┐ ┌─┐
     ├┤           FPT_FLS Безопасность при сбое            ├─┤1│
     │└────────────────────────────────────────────────────┘ └─┘
     │┌────────────────────────────────────────────────────┐ ┌─┐
     ├┤   FPT_ITA Доступность экспортируемых данных ФБО    ├─┤1│
     │└────────────────────────────────────────────────────┘ └─┘
     │┌────────────────────────────────────────────────────┐ ┌─┐
     ├┤FPT_ITC Конфиденциальность экспортируемых данных ФБО├─┤1│
     │└────────────────────────────────────────────────────┘ └─┘
     │┌────────────────────────────────────────────────────┐ ┌─┐┌─┐
     ├┤   FPT_ITI Целостность экспортируемых данных ФБО    ├─┤1├┤2│
     │└────────────────────────────────────────────────────┘ └─┘└─┘
     │                                                       ┌─┐┌─┐
     │┌────────────────────────────────────────────────────┐┌┤1├┤2│
 ├┤ FPT_ITT Передача данных ФБО в пределах ОО ├┤└─┘└─┘
     │└────────────────────────────────────────────────────┘│┌─┐
<pre class="legal-pre">     │                                                      └┤3│
     │                                                       └─┘
     │                                                       ┌─┐┌─┐</pre>
     │┌────────────────────────────────────────────────────┐┌┤1├┤2│
 ├┤ FPT_PHP Физическая защита ФБО ├┤└─┘└─┘
     │└────────────────────────────────────────────────────┘│┌─┐
<pre class="legal-pre">     │                                                      └┤3│
     │                                                       └─┘
     │                                                       ┌─┐┌─┐┌─┐</pre>
     │┌────────────────────────────────────────────────────┐┌┤1├┤2├┤3│
 └┤ FPT_RCV Надежное восстановление ├┤└─┘└─┘└─┘
      └────────────────────────────────────────────────────┘│┌─┐
                                                            └┤4│
                                                             └─┘

Рисунок 10.1. Декомпозиция класса "Защита ФБО"

      ┌──────────┐
      │Защита ФБО│
      └┬─────────┘
       │┌────────────────────────────────────────────┐ ┌─┐
       ├┤FPT_RPL Обнаружение повторного использования├─┤1│
       │└────────────────────────────────────────────┘ └─┘
       │┌────────────────────────────────────────────┐ ┌─┐
       ├┤   FPT_RVM Посредничество при обращениях    ├─┤1│
       │└────────────────────────────────────────────┘ └─┘
       │┌────────────────────────────────────────────┐ ┌─┐┌─┐┌─┐
       ├┤         FPT_SEP Разделение домена          ├─┤1├┤2├┤3│
       │└────────────────────────────────────────────┘ └─┘└─┘└─┘
       │┌────────────────────────────────────────────┐ ┌─┐┌─┐
       ├┤  FPT_SSP Протокол синхронизации состояний  ├─┤1├┤2│
       │└────────────────────────────────────────────┘ └─┘└─┘
       │┌────────────────────────────────────────────┐ ┌─┐
       ├┤           FPT_STM Метки времени            ├─┤1│
       │└────────────────────────────────────────────┘ └─┘
       │┌────────────────────────────────────────────┐ ┌─┐
       ├┤FPT_TDC Согласованность данных ФБО между ФБО├─┤1│
       │└────────────────────────────────────────────┘ └─┘
       │┌────────────────────────────────────────────┐ ┌─┐
<pre class="legal-pre">       ││   FPT_TRC Согласованность данных ФБО при   ├─┤1│
       ├┤         дублировании в пределах ОО         │ │ │</pre>
       │└────────────────────────────────────────────┘ └─┘
       │┌────────────────────────────────────────────┐ ┌─┐
       └┤        FPT_TST Самотестирование ФБО        ├─┤1│
        └────────────────────────────────────────────┘ └─┘

(продолжение)

10.1. Тестирование базовой абстрактной машины (FPT_AMT)

Характеристика семейства

Семейство FPT_AMT определяет требования к выполнению тестирования ФБО, демонстрирующего предположения безопасности относительно базовой абстрактной машины, лежащей в основе построения ФБО. «Абстрактная» машина может быть как платформой аппаратных/программно-аппаратных средств, так и некоторым известным и прошедшим оценку сочетанием аппаратных/программных средств, действующим как виртуальная машина.

Ранжирование компонентов

        ┌────────────────────────────────────────────────────┐┌─┐
        │  FPT_AMT Тестирование базовой абстрактной машины   ├┤1│
        └────────────────────────────────────────────────────┘└─┘

FPT_AMT.1 «Тестирование абстрактной машины» предоставляет возможность проверки базовой абстрактной машины.

Управление: FPT_AMT.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление условиями, при которых происходит тестирование абстрактной машины, например при первоначальном запуске, с постоянным интервалом, при заданных условиях;

б) управление временным интервалом (если такое управление предусмотрено).

Аудит: FPT_AMT.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) базовый: выполнение тестирования базовой машины и результаты тестирования.

FPT_AMT.1. Тестирование абстрактной машины

Иерархический для: Нет подчиненных компонентов.

#FPT_AMT.1.1 ФБО должны выполнять пакет тестовых программ [выбор: &при первоначальном запуске, периодически во время нормального функционирования, по запросу уполномоченного пользователя, при других условиях&] для демонстрации правильности выполнения предположений безопасности, обеспечиваемых абстрактной машиной, которая положена в основу ФБО#.

Зависимости: отсутствуют.

10.2. Безопасность при сбое (FPT_FLS)

Характеристика семейства

Требования семейства FPT_FLS обеспечивают, чтобы ОО не нарушал свою политику безопасности при сбоях ФБО идентифицированных типов.

Ранжирование компонентов

        ┌────────────────────────────────────────────────────┐┌─┐
        │           FPT_FLS Безопасность при сбое            ├┤1│
        └────────────────────────────────────────────────────┘└─┘

Это семейство состоит из одного компонента FPT_FLS.1 «Сбой с сохранением безопасного состояния», содержащего требование, чтобы ФБО сохранили безопасное состояние при идентифицированных сбоях.

Управление: FPT_FLS.1

Действия по управлению не предусмотрены.

Аудит: FPT_FLS.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) базовый: сбой ФБО.

FPT_FLS.1. Сбой с сохранением безопасного состояния

Иерархический для: Нет подчиненных компонентов.

#FPT_FLS.1.1 ФБО должны сохранить безопасное состояние при следующих типах сбоев [назначение: &список типов сбоев ФБО&]#. Зависимости: #ADV_SPM.1 Неформальная модель политики безопасности ОО#.

10.3. Доступность экспортируемых данных ФБО (FPT_ITA)

Характеристика семейства

Семейство FPT_ITA определяет правила предотвращения потери доступности данных ФБО, передаваемых между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

Ранжирование компонентов

        ┌────────────────────────────────────────────────────┐┌─┐
        │   FPT_ITA Доступность экспортируемых данных ФБО    ├┤1│
        └────────────────────────────────────────────────────┘└─┘

Это семейство состоит из одного компонента FPT_ITA.1 «Доступность экспортируемых данных ФБО в пределах заданной метрики», содержащего требование, чтобы ФБО обеспечили с заданной вероятностью доступность данных ФБО, предоставляемых удаленному доверенному продукту ИТ.

Управление: FPT_ITA.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление списком типов данных ФБО, для которых необходимо, чтобы они были доступны удаленному доверенному продукту ИТ.

Аудит: FPT_ITA.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: отсутствие данных ФБО, когда они запрошены ОО.

FPT_ITA.1. Доступность экспортируемых данных ФБО в пределах заданной метрики

Иерархический для: Нет подчиненных компонентов.

#FPT_ITA.1.1 ФБО должны обеспечить доступность [назначение: &список типов данных ФБО&] для удаленного доверенного продукта ИТ в пределах [назначение: &заданная метрика доступности&] при выполнении следующих условий [назначение: &условия обеспечения доступности&].

Зависимости: отсутствуют.

10.4. Конфиденциальность экспортируемых данных ФБО (FPT_ITC)

Характеристика семейства

Семейство FPT_ITC определяет правила защиты данных ФБО от несанкционированного раскрытия при передаче между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

Ранжирование компонентов

        ┌────────────────────────────────────────────────────┐┌─┐
        │FPT_ITC Конфиденциальность экспортируемых данных ФБО├┤1│
        └────────────────────────────────────────────────────┘└─┘

Это семейство состоит из одного компонента FPT_ITC.1 «Конфиденциальность экспортируемых данных ФБО при передаче», содержащего требование, чтобы ФБО обеспечили защиту данных, передаваемых между ФБО и удаленным доверенным продуктом ИТ, от раскрытия при передаче.

Управление: FPT_ITC.1

Действия по управлению не предусмотрены.

Аудит: FPT_ITC.1

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FPT_ITC.1. Конфиденциальность экспортируемых данных ФБО при передаче

Иерархический для: Нет подчиненных компонентов.

#FPT_ITC.1.1 ФБО должны защитить все данные ФБО, передаваемые от ФБО к удаленному доверенному продукту ИТ, от несанкционированного раскрытия при передаче#.

Зависимости: отсутствуют.

10.5. Целостность экспортируемых данных ФБО (FPT_ITI)

Характеристика семейства

Семейство FPT_ITI определяет правила защиты данных ФБО от несанкционированной модификации при передаче между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

Ранжирование компонентов

       ┌────────────────────────────────────────────────────┐┌─┐┌─┐
       │   FPT_ITI Целостность экспортируемых данных ФБО    ├┤1├┤2│
       └────────────────────────────────────────────────────┘└─┘└─┘

FPT_ITI.1 «Обнаружение модификации экспортируемых данных ФБО» позволяет обнаружить модификацию данных ФБО при передаче между ФБО и удаленным доверенным продуктом ИТ при допущении, что последнему известен используемый механизм передачи.

FPT_ITI.2 «Обнаружение и исправление модификации экспортируемых данных ФБО» позволяет удаленному доверенному продукту ИТ не только обнаружить модификацию, но и восстановить данные ФБО, модифицированные при передаче от ФБО, при допущении, что последнему известен используемый механизм передачи.

Управление: FPT_ITI.1

Действия по управлению не предусмотрены.

Управление: FPT_ITI.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление типами данных ФБО, которые ФБО следует пытаться исправить, если они модифицированы при передаче;

б) управление типами действий, которые ФБО могут предпринять, если данные ФБО модифицированы при передаче.

Аудит: FPT_ITI.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обнаружение модификации передаваемых данных ФБО;

б) базовый: действия, предпринятые при обнаружении модификации передаваемых данных ФБО.

Аудит: FPT_ITI.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обнаружение модификации передаваемых данных ФБО;

б) базовый: действия, предпринятые при обнаружении модификации передаваемых данных ФБО;

в) базовый: использование механизма восстановления.

FPT_ITI.1. Обнаружение модификации экспортируемых данных ФБО

Иерархический для: Нет подчиненных компонентов.

#FPT_ITI.1.1 ФБО должны предоставить возможность обнаружить модификацию любых данных ФБО при передаче между ФБО и удаленным доверенным продуктом ИТ в пределах следующей метрики: [назначение: &метрика модификации&].

FPT_ITI.1.2 ФБО должны предоставить возможность верифицировать целостность всех данных ФБО при их передаче между ФБО и удаленным доверенным продуктом ИТ и выполнить [назначение: &предпринимаемые действия&], если модификация обнаружена#.

Зависимости: отсутствуют.

FPT_ITI.2. Обнаружение и исправление модификации экспортируемых данных ФБО

Иерархический для: FPT_ITI.1

#FPT_ITI.2.1# ФБО должны предоставить возможность обнаружить модификацию любых данных ФБО при передаче между ФБО и удаленным доверенным продуктом ИТ в пределах следующей метрики: [назначение: метрика модификации].

#FPT_ITI.2.2# ФБО должны предоставить возможность верифицировать целостность всех данных ФБО при их передаче между ФБО и удаленным доверенным продуктом ИТ и выполнить [назначение: предпринимаемые действия], если модификация обнаружена.

#FPT_ITI.2.3 ФБО должны предоставить возможность исправить [назначение: &тип модификации&] все данные ФБО, передаваемые между ФБО и удаленным доверенным продуктом ИТ#.

Зависимости: отсутствуют.

10.6. Передача данных ФБО в пределах ОО (FPT_ITT)

Характеристика семейства

Семейство FPT_ITT предоставляет требования защиты данных ФБО при их передаче между разделенными частями ОО по внутреннему каналу.

Ранжирование компонентов

                                                             ┌─┐┌─┐
      ┌────────────────────────────────────────────────────┐┌┤1├┤2│
      │     FPT_ITT Передача данных ФБО в пределах ОО      ├┤└─┘└─┘
      └────────────────────────────────────────────────────┘│┌─┐
                                                            └┤3│
                                                             └─┘

FPT_ITT.1 «Базовая защита внутренней передачи данных ФБО» содержит требование, чтобы данные ФБО были защищены при их передаче между разделенными частями ОО.

FPT_ITT.2 «Разделение данных ФБО при передаче» содержит требование, чтобы при передаче ФБО отделяли данные пользователей от данных ФБО.

FPT_ITT.3 «Мониторинг целостности данных ФБО» содержит требование, чтобы данные ФБО, передаваемые между разделенными частями ОО, контролировались на идентифицированные ошибки целостности.

Управление: FPT_ITT.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление типами модификации, от которых ФБО следует защищать передаваемые данные;

б) управление механизмом, используемым для обеспечения защиты данных при передаче между различными частями ФБО.

Управление: FPT_ITT.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление типами модификации, от которых ФБО следует защищать передаваемые данные;

б) управление механизмом, используемым для обеспечения защиты данных при передаче между различными частями ФБО;

в) управление механизмом разделения данных.

Управление: FPT_ITT.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление типами модификации, от которых ФБО следует защищать передаваемые данные;

б) управление механизмом, используемым для обеспечения защиты данных при передаче между различными частями ФБО;

в) управление типами модификации данных ФБО, которые ФБО следует пытаться обнаружить;

г) управление действиями, предпринимаемыми после обнаружения модификации.

Аудит: FPT_ITT.1, FPT_ITT.2

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

Аудит: FPT_ITT.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обнаружение модификации данных ФБО;

б) базовый: действия, предпринятые после обнаружения ошибок целостности.

FPT_ITT.1. Базовая защита внутренней передачи данных ФБО

Иерархический для: Нет подчиненных компонентов.

#FPT_ITT.1.1 ФБО должны защитить свои данные от [выбор: &раскрытие, модификация&] при их передаче между разделенными частями ОО#.

Зависимости: отсутствуют.

FPT_ITT.2. Разделение данных ФБО при передаче

Иерархический для: FPT_ITT.1

#FРТ_IТТ.2.1# ФБО должны защитить свои данные от [выбор: раскрытие, модификация] при их передаче между разделенными частями ОО.

#FPT_ITT.2.2 ФБО должны отделить данные пользователя от данных ФБО при их передаче между разделенными частями ОО#.

Зависимости: отсутствуют.

FPT_ITT.3. Мониторинг целостности данных ФБО

Иерархический для: Нет подчиненных компонентов.

#FPT_ITT.3.1 ФБО должны быть способны обнаружить [выбор: &модификация данных, подмена данных, перестановка данных, удаление данных&, [назначение: &другие ошибки целостности&]] в данных ФБО, передаваемых между разделенными частями ОО.

FPT_ITT.3.2 При обнаружении ошибки целостности данных ФБО должны предпринять следующие действия: [назначение: &выполняемые действия&]#.

Зависимости: #FPT_ITT.1 Базовая защита внутренней передачи данных ФБО#.

10.7. Физическая защита ФБО (FPT_PHP)

Характеристика семейства

Компоненты семейства FPT_PHP дают возможность ограничивать физический доступ к ФБО, а также реагировать на несанкционированную физическую модификацию или подмену реализации ФБО и противодействовать им.

Требования компонентов в этом семействе обеспечивают, чтобы ФБО были защищены от физического воздействия и вмешательства. Удовлетворение требований этих компонентов позволяет получить реализацию ФБО, компонуемую и используемую способом, предусматривающим обнаружение физического воздействия или противодействие ему. Без этих компонентов защита ФБО теряет свою эффективность в среде, где не может быть предотвращено физическое повреждение. Это семейство также содержит требования к реакции ФБО на попытки физического воздействия на их реализацию.

Ранжирование компонентов

                                                             ┌─┐┌─┐
      ┌────────────────────────────────────────────────────┐┌┤1├┤2│
      │           FPT_PHP Физическая защита ФБО            ├┤└─┘└─┘
      └────────────────────────────────────────────────────┘│┌─┐
                                                            └┤3│
                                                             └─┘

FPT_PHP.1 «Пассивное обнаружение физического нападения» предоставляет возможность известить о нападении на устройства или элементы, реализующие ФБО. Однако оповещение о нападении не действует автоматически; уполномоченному пользователю необходимо вызвать административную функцию безопасности или проверить вручную, произошло ли нападение.

FPT_PHP.2 «Оповещение о физическом нападении» обеспечивает автоматическое оповещение о нападении для установленного подмножества физических проникновений.

FPT_PHP.3 «Противодействие физическому нападению» предоставляет возможности предотвращения или противодействия физическому нападению на устройства и элементы, реализующие ФБО.

Управление: FPT_PHP.1, FPT_PHP.3

Действия по управлению не предусмотрены.

Управление: FPT_PHP.2

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление пользователем или ролью, которые получают информацию о вторжениях;

б) управление списком устройств, о вторжении в которые следует оповестить указанного пользователя или роль.

Управление: FPT_PHP.3

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление автоматической реакцией на физическое воздействие.

Аудит: FPT_PHP.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обнаружение вторжения средствами ИТ.

Аудит: FPT_PHP.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: обнаружение вторжения.

Аудит: FPT_PHP.3

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FPT_PHP.1. Пассивное обнаружение физического нападения

Иерархический для: Нет подчиненных компонентов.

#FPT_PHP.1.1 ФБО должны обеспечить однозначное обнаружение физического воздействия, которое может угрожать выполнению ФБО.

FPT_PHP.1.2 ФБО должны предоставить возможность определить, произошло ли физическое воздействие на устройства или элементы, реализующие ФБО#.

Зависимости: #FMT_MOF.1 Управление режимом выполнения функций безопасности#.

FPT_PHP.2. Оповещение о физическом нападении

Иерархический для: FPT_PHP.1

#FPT_PHP.2.1# ФБО должны обеспечить однозначное обнаружение физического воздействия, которое может угрожать выполнению ФБО.

#FPT_PHP.2.2# ФБО должны предоставить возможность определить, произошло ли физическое воздействие на устройства или элементы, реализующие ФБО.

#FPT_PHP.2.3 Для [назначение: &список устройств/элементов, реализующих ФБО, для которых требуется активное обнаружение&] ФБО должны постоянно контролировать устройства, элементы и оповещать [назначение: &назначенный пользователь или роль&], что произошло физическое воздействие на устройства или элементы, реализующие ФБО#.

Зависимости: FMT_MOF.1 Управление режимом выполнения функций безопасности.

FPT_PHP.3. Противодействие физическому нападению

Иерархический для: Нет подчиненных компонентов.

#FPT_PHP.3.1 ФБО должны противодействовать [назначение: &сценарии физического воздействия&] на [назначение: &список устройств/ элементов, реализующих ФБО&], реагируя автоматически таким образом, чтобы предотвратить нарушение ПБО#.

Зависимости: отсутствуют.

10.8. Надежное восстановление (FPT_RCV)

Характеристика семейства

Требования семейства FPT_RCV обеспечивают, чтобы ФБО могли определить, не нарушена ли защита ФБО при запуске, и восстанавливаться без нарушения защиты после прерывания операций. Это семейство важно, потому что начальное состояние ФБО при запуске или восстановлении определяет защищенность ОО в последующем.

Ранжирование компонентов

                                                           ┌─┐┌─┐┌─┐
    ┌────────────────────────────────────────────────────┐┌┤1├┤2├┤3│
    │          FPT_RCV Надежное восстановление           ├┤└─┘└─┘└─┘
    └────────────────────────────────────────────────────┘│┌─┐
                                                          └┤4│
                                                           └─┘

FPT_RCV.1 «Ручное восстановление» позволяет ОО предоставить только такие механизмы возврата к безопасному состоянию, которые предполагают вмешательство человека.

FPT_RCV.2 «Автоматическое восстановление» предоставляет хотя бы для одного типа прерывания обслуживания восстановление безопасного состояния без вмешательства человека; восстановление после прерываний других типов может потребовать вмешательства человека.

FPT_RCV.3 «Автоматическое восстановление без недопустимой потери» также предусматривает автоматическое восстановление, но повышает уровень требований, препятствуя недопустимой потере защищенных объектов.

FPT_RCV.4 «Восстановление функции» предусматривает восстановление на уровне отдельных ФБ, обеспечивая либо их нормальное завершение после сбоя, либо возврат к безопасному состоянию данных ФБО.

Управление: FPT_RCV.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление списком доступа к средствам восстановления в режиме аварийной поддержки.

Управление: FPT_RCV.2, FPT_RCV.3

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление списком доступа к средствам восстановления в режиме аварийной поддержки;

б) управление списком сбоев/прерываний обслуживания, которые будут обрабатываться автоматическими процедурами.

Управление: FPT_RCV.4

Действия по управлению не предусмотрены.

Аудит: FPT_RCV.1, FPT_RCV.2, FPT_RCV.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: факт возникновения сбоя или прерывания обслуживания;

б) минимальный: возобновление нормальной работы;

в) базовый: тип сбоя или прерывания обслуживания.

Аудит: FPT_RCV.4

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: невозможность возврата к безопасному состоянию после сбоя функции безопасности, если аудит возможен;

б) базовый: обнаружение сбоя функции безопасности, если аудит возможен.

FPT_RCV.1. Ручное восстановление

Иерархический для: Нет подчиненных компонентов.

#FPT_RCV.1.1 После сбоя или прерывания обслуживания ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию#.

Зависимости: #FPT_TST.1 Тестирование ФБО AGD_ADM.1 Руководство администратора ADV_SPM.1 Неформальная модель политики безопасности ОО#.

FPT_RCV.2. Автоматическое восстановление

Иерархический для: FPT_RCV.1

#FPT_RCV.2.1 Когда автоматическое восстановление# после сбоя или прерывания обслуживания #невозможно#, ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию.

#FPT_RCV.2.2 Для [назначение: &список сбоев/прерываний обслуживания&] ФБО должны обеспечить возврат ОО к безопасному состоянию с использованием автоматических процедур#.

Зависимости: FPT_TST.1 Тестирование ФБО AGD_ADM.1 Руководство администратора ADV_SPM.1 Неформальная модель политики безопасности ОО.

FPT_RCV.3. Автоматическое восстановление без недопустимой потери

Иерархический для: FPT_RCV.2

#FPT_RCV.3.1# Когда автоматическое восстановление после сбоя или прерывания обслуживания невозможно, ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию.

#FPT_RCV.3.2# Для [назначение: список сбоев/прерываний обслуживания] ФБО должны обеспечить возврат ОО к безопасному состоянию с использованием автоматических процедур.

#FPT_RCV.3.3 Функции из числа ФБО, предназначенные для преодоления последствий сбоя или прерывания обслуживания, должны обеспечить восстановление безопасного начального состояния без превышения [назначение: &количественная мера&] потери данных ФБО или объектов в пределах ОДФ.

FPT_RCV.3.4 ФБО должны обеспечить способность определения, какие объекты могут, а какие не могут быть восстановлены#.

Зависимости: FPT_TST.1 Тестирование ФБО AGD_ADM.1 Руководство администратора ADV_SPM.1 Неформальная модель политики безопасности ОО.

FPT_RCV.4. Восстановление функции

Иерархический для: Нет подчиненных компонентов.

#FPT_RCV.4.1 ФБО должны обеспечить следующее свойство для [назначение: &список ФБ и сценариев сбоев&]: ФБ нормально заканчивает работу или, для предусмотренных сценариев сбоев, восстанавливается ее устойчивое и безопасное состояние#.

Зависимости: #ADV_SPM.1 Неформальная модель политики безопасности ОО#.

10.9. Обнаружение повторного использования (FPT_RPL)

Характеристика семейства

Семейство FPT_RPL связано с обнаружением повторного использования различных типов сущностей (таких, как сообщения, запросы на обслуживание, ответы на запросы обслуживания) и последующими действиями по его устранению. При обнаружении повторного использования выполнение требований семейства эффективно предотвращает его.

Ранжирование компонентов

             ┌────────────────────────────────────────────┐┌─┐
             │FPT_RPL Обнаружение повторного использования├┤1│
             └────────────────────────────────────────────┘└─┘

Семейство состоит из одного компонента FPT_RPL.1 «Обнаружение повторного использования», который содержит требование, чтобы ФБО были способны обнаружить повторное использование идентифицированных сущностей.

Управление: FPT_RPL.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление списком идентифицированных сущностей, для которых повторное использование должно быть обнаружено;

б) управление списком действий, которые необходимо предпринять при повторном использовании.

Аудит: FPT_RPL.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров;

а) базовый: обнаруженные нападения посредством повторного использования;

б) детализированный: предпринятые специальные действия.

FPT_RPL.1. Обнаружение повторного использования

Иерархический для: Нет подчиненных компонентов.

#FPT_RPL.1.1 ФБО должны обнаруживать повторное использование для следующих сущностей: [назначение: &список идентифицированных сущностей&].

FPT_RPL.1.2 ФБО должны выполнить [назначение: &список специальных действий&] при обнаружении повторного использования#.

Зависимости: отсутствуют.

10.10. Посредничество при обращениях (FPT_RVM)

Характеристика семейства

Требования семейства FPT_RVM связаны с аспектом «постоянная готовность» традиционного монитора обращений. Цель этого семейства состоит в обеспечении для заданной ПФБ, чтобы все действия, требующие осуществления политики, проверялись ФБО на соответствие ПФБ. Если помимо этого часть ФБО, осуществляющая ПФБ, выполняет требования соответствующих компонентов из семейств FPT_SEP «Разделение домена» и ADV_INT «Внутренняя структура ФБО», то эта часть ФБО обеспечивает «монитор обращений» для этой ПФБ.

ФБО при реализации ПФБ предоставляют эффективную защиту от несанкционированных операций тогда и только тогда, когда правомочность всех действий, предполагаемых для осуществления (например, доступ к объектам) и запрошенных субъектами, недоверенными относительно всех или именно этой ПФБ, проверяется ФБО до выполнения действий. Если действия по проверке, которые должны выполняться ФБО, исполнены неправильно или проигнорированы (обойдены), то осуществление ПФБ в целом может быть поставлено под угрозу (ее можно обойти). Тогда субъекты смогут обходить ПФБ различными способами (такими, как обход проверки доступа для некоторых субъектов и объектов, обход проверки для объектов, чья защита управляется прикладными программами, сохранение права доступа после истечения установленного срока действия, обход аудита действий, подлежащих аудиту, обход аутентификации). Важно отметить, что некоторым субъектам, так называемым «доверенным субъектам» относительно одной из ПФБ, может быть непосредственно доверено осуществление этой ПФБ, предоставляя тем самым возможность обойтись без ее посредничества.

Ранжирование компонентов

            ┌────────────────────────────────────────────┐┌─┐
            │   FPT_RVM Посредничество при обращениях    ├┤1│
            └────────────────────────────────────────────┘└─┘

Это семейство состоит из только компонента FPT_RVM.1 «Невозможность обхода ПБО», который содержит требование предотвращения обхода для всех ПФБ из ПБО.

Управление: FPT_RVM.1

Действия по управлению не предусмотрены.

Аудит: FPT_RVM.1

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FPT_RVM.1. Невозможность обхода ПБО

Иерархический для: Нет подчиненных компонентов.

#FPT_RVM.1.1 ФБО должны обеспечить, чтобы функции, осуществляющие ПБО, вызывались и успешно выполнялись прежде, чем разрешается выполнение любой другой функции в пределах ОДФ#.

Зависимости: отсутствуют.

10.11. Разделение домена (FPT_SEP)

Характеристика семейства

Компоненты семейства FPT_SEP обеспечивают, чтобы, по меньшей мере, один домен безопасности был доступен только для собственного выполнения ФБО, и этим они были защищены от внешнего вмешательства и искажения (например, модификации кода или структур данных ФБО) со стороны недоверенных субъектов. Выполнение требований этого семейства устанавливает такую самозащиту ФБО, что недоверенный субъект не сможет модифицировать или повредить ФБО.

Это семейство содержит следующие требования:

а) ресурсы домена безопасности ФБО («защищенного домена») и ресурсы субъектов и активных сущностей, внешних по отношению к этому домену, разделяются так, что сущности, внешние по отношению к защищенному домену, не смогут получить или модифицировать данные или код ФБО в пределах защищенного домена;

б) обмен между доменами управляется так, что произвольный вход в защищенный домен или произвольный выход из него невозможны;

в) параметры пользователя или прикладной программы, переданные в защищенный домен по адресу, проверяются относительно адресного пространства защищенного домена, а переданные по значению — относительно значений, ожидаемых этим доменом;

г) защищенные домены субъектов разделены, за исключением случаев, когда совместное использование одного домена управляется ФБО.

Ранжирование компонентов

          ┌────────────────────────────────────────────┐┌─┐┌─┐┌─┐
          │         FPT_SEP Разделение домена          ├┤1├┤2├┤3│
          └────────────────────────────────────────────┘└─┘└─┘└─┘

FPT_SEP.1 «Отделение домена ФБО» предоставляет отдельный защищенный домен для ФБО и обеспечивает разделение между субъектами в ОДФ.

FPT_SEP.2 «Отделение домена ПФБ» содержит требования дальнейшего разбиения защищенного домена ФБО с выделением отдельного(ных) домена(ов) для идентифицированной совокупности ПФБ, которые действуют как мониторы обращений для них, и домена для остальной части ФБО, а также доменов для частей ОО, не связанных с ФБО.

FPT_SEP.3 «Полный монитор обращений» содержит требования, чтобы имелся отдельный(ные) домен(ны) для осуществления ПБО, домен для остальной части ФБО, а также домены для частей ОО, не связанных с ФБО.

Управление: FPT_SEP.1, FPT_SEP.2, FPT_SEP.3

Действия по управлению не предусмотрены.

Аудит: FPT_SEP.1, FPT_SEP.2, FPT_SEP.3

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FPT_SEP.1. Отделение домена ФБО

Иерархический для: Нет подчиненных компонентов.

#FPT_SEP.1.1 ФБО должны поддерживать домен безопасности для собственного выполнения, защищающий их от вмешательства и искажения недоверенными субъектами.

FPT_SEP.1.2 ФБО должны реализовать разделение между доменами безопасности субъектов в ОДФ#.

Зависимости: отсутствуют.

FPT_SEP.2. Отделение домена ПФБ

Иерархический для: FPT_SEP.1

#FPT_SEP.2.1 Неизолированная часть ФБО должна# поддерживать домен безопасности для собственного выполнения, защищающий их от вмешательства и искажения недоверенными субъектами.

#FPT_SEP.2.2# ФБО должны реализовать разделение между доменами безопасности субъектов в ОДФ.

#FPT_SEP.2.3 ФБО должны поддерживать часть ФБО, связанных с [назначение: &список ПФБ управления доступом и/или управления информационными потоками&] в домене безопасности для их собственного выполнения, защищающем их от вмешательства и искажения остальной частью ФБО и субъектами, недоверенными относительно этих ПФБ#.

Зависимости: отсутствуют.

FPT_SEP.3. Полный монитор обращений

Иерархический для: FPT_SEP.2

#FPT_SEP.3.1# Неизолированная часть ФБО должна поддерживать домен безопасности для собственного выполнения, защищающий их от вмешательства и искажения недоверенными субъектами.

#FPT_SEP.3.2# ФБО должны реализовать разделение между доменами безопасности субъектов в ОДФ.

#FPT.SEP.3.3 ФБО должны поддерживать ту часть ФБО, которая осуществляет ПФБ управления доступом и/или управления информационными потоками#, в домене безопасности для #ее# собственного выполнения, защищающем #их# от вмешательства и искажения остальной частью ФБО и субъектами, недоверенными относительно #ПБО#.

Зависимости: отсутствуют.

10.12. Протокол синхронизации состояний (FPT_SSP)

Характеристика семейства

Распределенные системы могут иметь большую сложность, чем нераспределенные, из-за многообразия состояний частей системы, а также из-за задержек связи. В большинстве случаев синхронизация состояния между распределенными функциями включает в себя, помимо обычных действий, применение протокола обмена. Когда в среде распределенных систем существуют угрозы безопасности, потребуются более сложные защищенные протоколы.

Семейство FPT_SSP устанавливает требование использования надежных протоколов некоторыми критичными по безопасности функциями из числа ФБО. Оно обеспечивает, чтобы две распределенные части ОО (например, главные ЭВМ) синхронизировали свои состояния после действий, связанных с безопасностью.

Ранжирование компонентов

           ┌────────────────────────────────────────────┐┌─┐┌─┐
           │  FPT_SSP Протокол синхронизации состояний  ├┤1├┤2│
           └────────────────────────────────────────────┘└─┘└─┘

FPT_SSP.1 «Одностороннее надежное подтверждение» содержит требование подтверждения одним лишь получателем данных.

FPT_SSP.2 «Взаимное надежное подтверждение» содержит требование взаимного подтверждения обмена данными.

Управление: FPT_SSP.1, FPT_SSP.2

Действия по управлению не предусмотрены.

Аудит: FPT_SSP.1, FPT_SSP.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: неполучение ожидаемого подтверждения.

FPT_SSP.1. Одностороннее надежное подтверждение

Иерархический для: Нет подчиненных компонентов.

#FPT_SSP.1.1 ФБО должны подтвердить после запроса другой части ФБО получение немодифицированных данных ФБО при передаче#.

Зависимости: #FPT_ITT.1 Базовая защита внутренней передачи данных ФБО#.

FPT_SSP.2. Взаимное надежное подтверждение

Иерархический для: FPT_SSP.1

#FPT_SSP.2.1# ФБО должны подтвердить после запроса другой части ФБО получение немодифицированных данных ФБО при передаче.

#FPT_SSP.2.2 ФБО должны обеспечить, чтобы соответствующие части ФБО извещались, используя подтверждения, о правильном состоянии данных, передаваемых между различными частями ФБО#.

Зависимости: FPT_ITT.1 Базовая защита внутренней передачи данных ФБО.

10.13. Метки времени (FPT_STM)

Характеристика семейства

Семейство FPT_STM содержит требования по предоставлению надежных меток времени в пределах ОО.

Ранжирование компонентов

             ┌────────────────────────────────────────────┐┌─┐
             │           FPT_STM Метки времени            ├┤1│
             └────────────────────────────────────────────┘└─┘

Это семейство состоит из одного компонента FPT_STM.1 «Надежные метки времени», который содержит требование, чтобы ФБО предоставили надежные метки времени для функций из числа ФБО.

Управление: FPT_STM.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление внутренним представлением времени.

Аудит: FPT_STM.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: изменения внутреннего представления времени;

б) детализированный: предоставление меток времени.

FPT_STM.1. Надежные метки времени

Иерархический для: Нет подчиненных компонентов.

#FPT_STM.1.1 ФБО должны быть способны предоставить надежные метки времени для собственного использования#.

Зависимости: отсутствуют.

10.14. Согласованность данных ФБО между ФБО (FPT_TDC)

Характеристика семейства

В среде распределенной или сложной системы от ОО может потребоваться произвести обмен данными ФБО (такими, как атрибуты ПФБ, ассоциированные с данными, информация аудита или идентификации) с другим доверенным продуктом ИТ. Семейство FPT_TDC определяет требования для совместного использования и согласованной интерпретации этих атрибутов между ФБО и другим доверенным продуктом ИТ.

Ранжирование компонентов

            ┌────────────────────────────────────────────┐┌─┐
            │FPT_TDC Согласованность данных ФБО между ФБО├┤1│
            └────────────────────────────────────────────┘└─┘

FPT_TDC.1 «Базовая согласованность данных ФБО между ФБО» содержит требование, чтобы ФБО предоставили возможность обеспечить согласованность атрибутов между ФБО.

Управление: FPT_TDC.1

Действия по управлению не предусмотрены.

Аудит: FPT_TDC.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: успешное использование механизмов согласования данных ФБО;

б) базовый: использование механизмов согласования данных ФБО;

в) базовый: идентификация ФБО, данные которых интерпретируются;

г) базовый: обнаружение модифицированных данных ФБО.

FPT_TDC.1. Базовая согласованность данных ФБО между ФБО

Иерархический для: Нет подчиненных компонентов.

#FPT_TDC.1.1 ФБО должны обеспечить способность согласованно интерпретировать [назначение: &список типов данных ФБО%], совместно используемые ФБО и другим доверенным продуктом ИТ.

FPT_TDC.1.2 ФБО должны использовать [назначение: &список правил интерпретации, применяемых ФБО&] при интерпретации данных ФБО, полученных от другого доверенного продукта ИТ#.

Зависимости: отсутствуют.

10.15. Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)

Характеристика семейства

Требования семейства FPT_TRC необходимы, чтобы обеспечить согласованность данных ФБО, когда они дублируются в пределах ОО. Такие данные могут стать несогласованными при нарушении работоспособности внутреннего канала между частями ОО. Если ОО внутренне структурирован как сеть, то это может произойти из-за отключения отдельных частей сети при разрыве сетевых соединений.

Ранжирование компонентов

            ┌────────────────────────────────────────────┐┌─┐
<pre class="legal-pre">            │   FPT_TRC Согласованность данных ФБО при   ├┤1│
            │         дублировании в пределах ОО         ││ │</pre>
            └────────────────────────────────────────────┘└─┘

Это семейство состоит из одного компонента FPT_TRC.1 «Согласованность дублируемых данных ФБО», содержащего требование, чтобы ФБО обеспечили непротиворечивость данных ФБО, дублируемых в нескольких частях ОО.

Управление: для FPT_TRC.1

Действия по управлению не предусмотрены.

Аудит: для FPT_TRC.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: восстановление согласованности после восстановления соединения;

б) базовый: выявление несогласованности между данными ФБО.

FPT_TRC.1. Согласованность дублируемых данных ФБО

Иерархический для: Нет подчиненных компонентов.

#FPT_TRC.1.1 ФБО должны обеспечить согласованность данных ФБО при дублировании их в различных частях ОО.

FPT_TRC.1.2 Когда части ОО, содержащие дублируемые данные ФБО, разъединены, ФБО должны обеспечить согласованность дублируемых данных ФБО после восстановления соединения перед обработкой любых запросов к [назначение: &список ФБ, зависящих от согласованности дублируемых данных ФБО&]#.

Зависимости: #FPT_ITT.1 Базовая защита внутренней передачи данных ФБО#.

10.16. Самотестирование ФБО (FPT_TST)

Характеристика семейства

Семейство FPT_TST определяет требования для самотестирования ФБО в части некоторых типичных операций с известным результатом. Примерами могут служить обращения к интерфейсам реализуемых функций, а также некоторые арифметические операции, выполняемые критичными частями ОО. Эти тесты могут выполняться при запуске, периодически, по запросу уполномоченного пользователя или при удовлетворении других условий. Действия ОО, предпринимаемые по результатам самотестирования, определены в других семействах.

Требования этого семейства также необходимы для обнаружения искажения выполняемого кода ФБО (т.е. программной реализации ФБО) и данных ФБО различными сбоями, которые не всегда приводят к приостановке функционирования ОО (рассмотренной в других семействах). Такие проверки необходимо выполнять, т.к. подобные сбои не всегда можно предотвратить. Они могут происходить либо из-за непредусмотренных типов сбоев или имеющихся неточностей в проекте аппаратных, программно-аппаратных и программных средств, либо вследствие злонамеренного искажения ФБО, допущенного из-за неадекватной логической и/или физической защиты.

Ранжирование компонентов

             ┌────────────────────────────────────────────┐┌─┐
             │        FPT_TST Самотестирование ФБО        ├┤1│
             └────────────────────────────────────────────┘└─┘

FPT_TST.1 «Тестирование ФБО» позволяет проверить правильность выполнения ФБО. Эти тесты могут выполняться при запуске, периодически, по запросу уполномоченного пользователя или при выполнении других заранее оговоренных условий. Этот компонент также предоставляет возможность верифицировать целостность данных и выполняемого кода ФБО.

Управление: для FPT_TST.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) управление условиями, при которых происходит самотестирование ФБО (при запуске, с постоянным интервалом или при определенных условиях);

б) управление периодичностью выполнения (при необходимости).

Аудит: для FPT_TST.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) базовый: выполнение и результаты самотестирования ФБО.

FPT_TST.1. Тестирование ФБО

Иерархический для: Нет подчиненных компонентов.

#FPT_TST.1.1 ФБО должны выполнять пакет программ самотестирования [выбор: &при запуске, периодически в процессе нормального функционирования, по запросу уполномоченного пользователя, при условиях& [назначение: &условия, при которых следует предусмотреть самотестирование&]] для демонстрации правильного выполнения ФБО.

FPT_TST.1.2 ФБО должны предоставить уполномоченным пользователям возможность верифицировать целостность данных ФБО.

FPT_TST.1.3 ФБО должны предоставить уполномоченным пользователям возможность верифицировать целостность хранимого выполняемого кода ФБО#.

Зависимости: #FPT_AMT.1 Тестирование абстрактной машины#.

11. Класс FRU. Использование ресурсов

Класс FRU содержит три семейства, которые поддерживают доступность требуемых ресурсов, таких как вычислительные возможности и/или объем памяти. Семейство FRU_FLT «Отказоустойчивость» предоставляет защиту от недоступности ресурсов, вызванной сбоем ОО. Семейство FRU_PRS «Приоритет обслуживания» обеспечивает, чтобы ресурсы выделялись наиболее важным или критичным по времени задачам и не могли быть монополизированы задачами с более низким приоритетом. Семейство FRU_RSA «Распределение ресурсов» устанавливает ограничения использования доступных ресурсов, предотвращая монополизацию ресурсов пользователями.

Декомпозиция класса FRU на составляющие его компоненты приведена на рисунке 11.1.

              ┌──────────────────────┐
              │Использование ресурсов│
              └──┬───────────────────┘
<pre class="legal-pre">                 │  ┌──────────────────────────────┐┌─┐┌─┐
                 ├──┤  FRU_FLT Отказоустойчивость  ├┤1├┤2│
                 │  └──────────────────────────────┘└─┘└─┘
                 │  ┌──────────────────────────────┐┌─┐┌─┐</pre>
                 ├──┤FRU_PRS Приоритет обслуживания├┤1├┤2│
<pre class="legal-pre">                 │  └──────────────────────────────┘└─┘└─┘
                 │  ┌──────────────────────────────┐┌─┐┌─┐</pre>
                 └──┤FRU_RSA Распределение ресурсов├┤1├┤2│
                    └──────────────────────────────┘└─┘└─┘

Рисунок 11.1. Декомпозиция класса "Использование ресурсов"

11.1. Отказоустойчивость (FRU_FLT)
Характеристика семейства
Требования семейства FRU_FLT обеспечивают, чтобы ОО продолжил поддерживать правильное функционирование даже в случае сбоев.
Ранжирование компонентов

                    ┌──────────────────────────┐┌─┐┌─┐
                    │FRU_FLT Отказоустойчивость├┤1├┤2│
                    └──────────────────────────┘└─┘└─┘

FRU_FLT.1 «Пониженная отказоустойчивость» содержит требование, чтобы ОО продолжил правильное выполнение указанных возможностей в случае идентифицированных сбоев.

FRU_FLT.2 «Ограниченная отказоустойчивость» содержит требование, чтобы ОО продолжил правильное выполнение всех своих возможностей в случае идентифицированных сбоев.

Управление: FRU_FLT.1, FRU_FLT.2

Действия по управлению не предусмотрены.

Аудит: FRU_FLT.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: любой сбой, обнаруженный ФБО;

б) базовый: все операции ОО, прерванные из-за сбоя.

Аудит: FRU_FLT.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: любой сбой, обнаруженный ФБО.

FRU_FLT.1. Пониженная отказоустойчивость

Иерархический для: Нет подчиненных компонентов.

#FRU_FLT.1.1 ФБО должны обеспечить выполнение [назначение: &список возможностей ОО&], когда происходят следующие сбои: [назначение: &список типов сбоев&]#.

Зависимости: #FPT_FLS.1 Сбой с сохранением безопасного состояния#.

#FRU_FLT.2. Ограниченная отказоустойчивость#

Иерархический для: FRU_FLT.1

#FRU_FLT.2.1# ФБО должны обеспечить выполнение #всех возможностей ОО#, когда происходят следующие сбои: [назначение: &список типов сбоев&].

Зависимости: FPT_FLS.1 Сбой с сохранением безопасного состояния.

11.2. Приоритет обслуживания (FRU_PRS)

Характеристика семейства

Требования семейства FRU_PRS позволяют ФБО управлять использованием ресурсов пользователями и субъектами в пределах своей области действия так, что высокоприоритетные операции в пределах ОДФ всегда будут выполняться без препятствий или задержек со стороны операций с более низким приоритетом.

Ранжирование компонентов

                  ┌──────────────────────────────┐┌─┐┌─┐
                  │FRU_PRS Приоритет обслуживания├┤1├┤2│
                  └──────────────────────────────┘└─┘└─┘

FRU_PRS.1 «Ограниченный приоритет обслуживания» предоставляет приоритеты для использования субъектами подмножества ресурсов в пределах ОДФ.

FRU_PRS.2 «Полный приоритет обслуживания» предоставляет приоритеты для использования субъектами всех ресурсов в пределах ОДФ.

Управление: FRU_PRS.1, FRU_PRS.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) назначение приоритетов каждому субъекту в ФБО.

Аудит: FRU_PRS.1, FRU_PRS.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: отклонение операции на основании использования приоритета при распределении ресурса;

б) базовый: все попытки использования функции распределения ресурсов с учетом приоритетности обслуживания.

FRU_PRS.1. Ограниченный приоритет обслуживания

Иерархический для: Нет подчиненных компонентов.

#FRU_PRS.1.1  ФБО должны установить приоритет к каждому субъекту в ФБО.
 FRU_PRS.1.2  ФБО должны обеспечить доступ к [назначение: &управляемые

          ресурсы&] на основе приоритетов, назначенных субъектам#.

Зависимости: отсутствуют.

#FRU_PRS.2. Полный приоритет обслуживания#

Иерархический для: FRU_PRS.1

#FRU_PRS.2.1# ФБО должны установить приоритет каждому субъекту в ФБО.

#FRU_PRS.2.2# ФБО должны обеспечить доступ #ко всем совместно используемым ресурсам# на основе приоритетов, назначенных субъектам.

Зависимости: отсутствуют.

11.3. Распределение ресурсов (FRU_RSA)

Характеристика семейства

Требования семейства FRU_RSA позволяют ФБО управлять использованием ресурсов пользователями и субъектами таким образом, чтобы не происходило отказов в обслуживании из-за несанкционированной монополизации ресурсов.

Ранжирование компонентов

                  ┌──────────────────────────────┐┌─┐┌─┐
                  │FRU_RSA Распределение ресурсов├┤1├┤2│
                  └──────────────────────────────┘└─┘└─┘

FRU_RSA.1 «Максимальные квоты» содержит требования к механизмам квотирования, которые обеспечивают, чтобы пользователи и субъекты не монополизировали управляемый ресурс.

FRU_RSA.2 «Минимальные и максимальные квоты» содержит требования к механизмам квотирования, которые обеспечивают, чтобы пользователи и субъекты всегда имели хотя бы минимум специфицированного ресурса, но при этом не могли бы монополизировать этот ресурс.

Управление: FRU_RSA.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) определение администратором максимальных квот ресурса для групп и/или отдельных пользователей и/или субъектов.

Управление: FRU_RSA.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) определение администратором минимальных и максимальных квот ресурса для групп и/или отдельных пользователей и/или субъектов.

Аудит: FRU_RSA.1, FRU_RSA.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: отклонение операции распределения ресурса из-за его ограниченности;

б) базовый: все обращения к функциям распределения ресурсов, управляемых ФБО.

FRU_RSA.1. Максимальные квоты

Иерархический для: Нет подчиненных компонентов.

#FRU_RSA.1.1 ФБО должны реализовать максимальные квоты следующих ресурсов: [назначение: &управляемые ресурсы&], которые [выбор: &отдельные пользователи, определенные группы пользователей, субъекты&] могут использовать [выбор: &одновременно, в течение определенного периода времени&]#.

Зависимости: отсутствуют.

FRU_RSA.2. Минимальные и максимальные квоты

Иерархический для: FRU_RSA.1

#FRU_RSA.2.1# ФБО должны реализовать максимальные квоты следующих ресурсов: [назначение: управляемые ресурсы], которые [выбор: отдельные пользователи, определенные группы пользователей, субъекты] могут использовать [выбор: одновременно, в течение определенного периода времени].

#FRU_RSA.2.2 ФБО должны обеспечить выделение минимального количества каждого из [назначение: &управляемые ресурсы&], которые являются доступными для [выбор: &отдельный пользователь, определенная группа пользователей, субъекты&], чтобы использовать [выбор: &одновременно, в течение определенного периода времени&]#.

Зависимости: отсутствуют.

12. Класс FTA. Доступ к ОО

Класс FTA определяет функциональные требования к управлению открытием сеанса пользователя.

Декомпозиция класса на составляющие его компоненты приведена на рисунке 12.1.

            ┌───────────┐
            │Доступ к ОО│
            └────┬──────┘
                 │    ┌─────────────────────────────┐ ┌─┐
                 ├────┤ FTA_LSA Ограничение области ├─┤1│
<pre class="legal-pre">                 │    │    выбираемых атрибутов     │ │ │
                 │    └─────────────────────────────┘ └─┘
                 │    ┌─────────────────────────────┐ ┌─┐  ┌─┐
                 ├────┤    FTA_MCS Ограничение на   ├─┤1├──┤2│
                 │    │     параллельные сеансы     │ │ │  │ │
                 │    └─────────────────────────────┘ └─┘  └─┘
                 │                                     ┌─┐
                 │                                   ┌─┤1│
                 │                                   │ └─┘
                 │    ┌─────────────────────────────┐│ ┌─┐</pre>
                 ├────┤ FTA_SSL Блокирование сеанса ├┼─┤2│
<pre class="legal-pre">                 │    └─────────────────────────────┘│ └─┘
                 │                                   │ ┌─┐
                 │                                   └─┤3│
                 │                                     └─┘
                 │    ┌─────────────────────────────┐ ┌─┐</pre>
                 ├────┤FTA_TAB Предупреждения перед ├─┤1│
<pre class="legal-pre">                 │    │предоставлением доступа к ОО │ │ │
                 │    └─────────────────────────────┘ └─┘
                 │    ┌─────────────────────────────┐ ┌─┐</pre>
                 ├────┤FTA_TAH История доступа к ОО ├─┤1│
<pre class="legal-pre">                 │    └─────────────────────────────┘ └─┘
                 │    ┌─────────────────────────────┐ ┌─┐</pre>
                 └────┤FTA_TSE Открытие сеанса с ОО ├─┤1│
                      └─────────────────────────────┘ └─┘

Рисунок 12.1. Декомпозиция класса "Доступ к ОО"

12.1. Ограничение области выбираемых атрибутов (FTA_LSA)
Характеристика семейства
Семейство FTA_LSA определяет требования по ограничению области атрибутов безопасности сеанса, которые может выбирать для него пользователь.
Ранжирование компонентов

                     ┌───────────────────────────┐ ┌─┐
                     │FTA_LSA Ограничение области├─┤1│
                     │   выбираемых атрибутов    │ │ │
                     └───────────────────────────┘ └─┘

FTA_LSA.1 «Ограничение области выбираемых атрибутов» предоставляет требование к ОО по ограничению области атрибутов безопасности сеанса во время его открытия.

Управление: FTA_LSA.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление администратором областью атрибутов безопасности сеанса.

Аудит: FTA_LSA.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: все неуспешные попытки выбора атрибутов безопасности сеанса;

б) базовый: все попытки выбора атрибутов безопасности сеанса;

в) детализированный: фиксация значений атрибутов безопасности каждого сеанса.

FTA_LSA.1. Ограничение области выбираемых атрибутов

Иерархический для: Нет подчиненных компонентов.

#FTA_LSA.1.1 ФБО должны ограничить область атрибутов безопасности сеанса [назначение: &атрибуты безопасности сеанса&], основываясь на [назначение: &атрибуты&]#.

Зависимости: отсутствуют.

12.2. Ограничение на параллельные сеансы (FTA_MCS)

Характеристика семейства

Семейство FTA_MCS определяет требования по ограничению числа параллельных сеансов, предоставляемых одному и тому же пользователю.

Ранжирование компонентов

           ┌──────────────────────────────────────────┐ ┌─┐ ┌─┐
           │FTA_MCS Ограничение на параллельные сеансы├─┤1├─┤2│
           └──────────────────────────────────────────┘ └─┘ └─┘

FTA_MCS.1 «Базовое ограничение на параллельные сеансы» предоставляет ограничения, которые применяются ко всем пользователям ФБО.

FTA_MCS.2 «Ограничение на параллельные сеансы по атрибутам пользователя» расширяет FTA_MCS.1 требованием возможности определить ограничения на число параллельных сеансов, основываясь на атрибутах безопасности, связанных с пользователем.

Управление: FTA_MCS.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление администратором максимально допустимым числом параллельных сеансов, предоставляемых пользователю.

Управление: FTA_MCS.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление администратором правилами, которые определяют максимально допустимое число параллельных сеансов, предоставляемых пользователю.

Аудит: FTA_MCS.1, FTA_MCS.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: отклонение нового сеанса, основанное на ограничении числа параллельных сеансов;

б) детализированный: фиксация числа параллельных сеансов пользователя, а также атрибутов безопасности этого пользователя.

FTA_MCS.1. Базовое ограничение на параллельные сеансы

Иерархический для: Нет подчиненных компонентов.

#FTA_MCS.1.1 ФБО должны ограничить максимальное число параллельных сеансов, предоставляемых одному и тому же пользователю.

FTA_MCS.1.2 ФБО должны задать по умолчанию ограничение [назначение: &задаваемое по умолчанию число&] сеансов пользователя.#

Зависимости: FIA_UID.1 Выбор момента идентификации.

FTA_MCS.2. Ограничение на параллельные сеансы по атрибутам пользователя

Иерархический для: FTA_MCS.1

#FTA_MCS.2.1# ФБО должны ограничить максимальное число параллельных сеансов, предоставляемых одному и тому же пользователю, #согласно правилам [назначение: &правила определения максимального числа параллельных сеансов&].

FTA_MCS.2.2# ФБО должны задать по умолчанию ограничение [назначение: задаваемое по умолчанию число] сеансов пользователя.

Зависимости: FIA_UID.1 Выбор момента идентификации.

12.3. Блокирование сеанса (FTA_SSL)

Характеристика семейства

Семейство FTA_SSL определяет требования к ФБО по предоставлению возможности как ФБО, так и пользователю блокировать и разблокировать интерактивный сеанс.

Ранжирование компонентов

                                                    ┌─┐
                                                  ┌─┤1│
                                                  │ └─┘
                    ┌───────────────────────────┐ │ ┌─┐
                    │FTA_SSL Блокирование сеанса├─┼─┤2│
                    └───────────────────────────┘ │ └─┘
                                                  │ ┌─┐
                                                  └─┤3│
                                                    └─┘

FTA_SSL.1 «Блокирование сеанса, инициированное ФБО» включает инициированное системой блокирование интерактивного сеанса после определенного периода бездействия пользователя.

FTA_SSL.2 «Блокирование, инициированное пользователем» предоставляет пользователю возможность блокировать и разблокировать свои собственные интерактивные сеансы.

FTA_SSL.3 «Завершение, инициированное ФБО» предоставляет требования к ФБО по завершению сеанса после определенного периода бездействия пользователя.

Управление: FTA_SSL.1

Для функций управления из класса FMT могут рассматриваться следующие действия:

а) задание времени бездействия пользователя, после которого происходит блокировка сеанса;

б) задание по умолчанию времени бездействия пользователя, после которого происходит блокировка;

в) управление событиями, которые предусматриваются до разблокирования сеанса.

Управление: FTA_SSL.2

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление событиями, которые предусматриваются до разблокирования сеанса.

Управление: FTA_SSL.3

Дня функций управления из класса FMT могут рассматриваться следующие действия:

а) задание времени бездействия пользователя, после которого происходит завершение интерактивного сеанса;

б) задание по умолчанию времени бездействия пользователя, после которого происходит завершение интерактивного сеанса.

Аудит: FTA_SSL.1, FTA_SSL.2

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: блокирование интерактивного сеанса механизмом блокирования сеанса;

б) минимальный: успешное разблокирование интерактивного сеанса;

в) базовый: все попытки разблокирования интерактивного сеанса.

Аудит: FTA_SSL.3

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: завершение интерактивного сеанса механизмом блокирования сеанса.

FTA_SSL.1. Блокирование сеанса, инициированное ФБО

Иерархический для: Нет подчиненных компонентов.

#FTA_SSL.1.1 ФБО должны блокировать интерактивный сеанс после [назначение: &интервал времени бездействия пользователя&], для чего предпринимаются следующие действия:

а) очистка или перезапись устройств отображения, придание их текущему содержанию нечитаемого вида;

б) блокирование любых действий по доступу к данным пользователя/устройствам отображения, кроме необходимых для разблокирования сеанса.

FTA_SSL.1.2 ФБО должны требовать, чтобы до разблокирования сеанса произошли следующие события: [назначение: &события, которые будут происходить&]#.

Зависимости: #FIA_UAU.1 Выбор момента аутентификации.

FTA_SSL.2. Блокирование, инициированное пользователем

Иерархический для: Нет подчиненных компонентов.

#FTA_SSL.2.1 ФБО должны допускать инициированное пользователем блокирование своего собственного интерактивного сеанса, для чего предпринимаются следующие действия:

а) очистка или перезапись устройств отображения, придание их текущему содержанию нечитаемого вида;

б) блокирование любых действий по доступу к данным пользователя/устройствам отображения, кроме необходимых для разблокирования сеанса.

FTA_SSL.2.2 ФБО должны требовать, чтобы до разблокирования сеанса произошли следующие события: [назначение: &события, которые будут происходить&]#.

Зависимости: #FIA_UAU.1 Выбор момента аутентификации.

FTA_SSL.3. Завершение, инициированное ФБО

Иерархический для: Нет подчиненных компонентов.

#FTA_SSL.3.1 ФБО должны завершить интерактивный сеанс после [назначение: &интервал времени бездействия пользователя&]#.

Зависимости: отсутствуют.

12.4. Предупреждения перед предоставлением доступа к ОО (FTA_TAB)

Характеристика семейства

Семейство FTA_TAB определяет требования к отображению для пользователей предупреждающего сообщения с перестраиваемой конфигурацией относительно характера использования ОО.

Ранжирование компонентов

                ┌────────────────────────────────────┐ ┌─┐
<pre class="legal-pre">                │    FTA_TAB Предупреждения перед    ├─┤1│
                │    предоставлением доступа к ОО    │ │ │</pre>
                └────────────────────────────────────┘ └─┘

FTA_TAB.1 «Предупреждения по умолчанию перед предоставлением доступа к ОО» предоставляет требования к предупреждающим сообщениям, которые отображаются перед началом диалога в сеансе.

Управление: FTA_TAB.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) сопровождение уполномоченным администратором предупреждающих сообщений.

Аудит: FTA_TAB.1

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FTA_TAB.1 Предупреждения по умолчанию перед предоставлением доступа к ОО

Иерархический для: Нет подчиненных компонентов.

#FTA_TAB.1.1 Перед открытием сеанса пользователя ФБО должны отобразить предупреждающее сообщение относительно несанкционированного использования ОО#.

Зависимости: отсутствуют.

12.5. История доступа к ОО (FTA_TAH)

Характеристика семейства

Семейство FTA_TAH определяет требования к ФБО по отображению для пользователя, при успешном открытии сеанса, истории успешных и неуспешных попыток получить доступ от имени этого пользователя.

Ранжирование компонентов

                    ┌────────────────────────────┐ ┌─┐
                    │FTA_TAH История доступа к ОО├─┤1│
                    └────────────────────────────┘ └─┘

FTA_TAH.1 «История доступа к ОО» предоставляет требования к ОО по отображению информации, связанной с предыдущими попытками открыть сеанс.

Управление: FTA_TAH.1

Действия по управлению не предусмотрены.

Аудит: FTA_TAH.1

Нет идентифицированных действий/событий/параметров, для которых следует предусмотреть возможность аудита.

FTA_TAH.1. История доступа к ОО

Иерархический для: Нет подчиненных компонентов.

#FTA_TAH.1.1 При успешном открытии сеанса ФБО должны отобразить [выбор: &дата, время, метод, расположение&] последнего успешного открытия сеанса от имени пользователя.

FTA_TAH.1.2 При успешном открытии сеанса ФБО должны отобразить [выбор: &дата, время, метод, расположение&] последней неуспешной попытки открытия сеанса и число неуспешных попыток со времени последнего успешного открытия сеанса.

FTA_TAH.1.3 ФБО не должны удалять информацию об истории доступа из интерфейса пользователя без предоставления пользователю возможности просмотреть ее#.

Зависимости: отсутствуют.

12.6. Открытие сеанса с ОО (FTA_TSE)

Характеристика семейства

Семейство FTA_TSE определяет требования по запрещению пользователям открытия сеанса с ОО.

Ранжирование компонентов

                    ┌────────────────────────────┐ ┌─┐
                    │FTA_TSE Открытие сеанса с ОО├─┤1│
                    └────────────────────────────┘ └─┘

FTA_TSE.1 «Открытие сеанса с ОО» предоставляет условия запрещения пользователям доступа к ОО, основанного на атрибутах.

Управление: FTA_TSE.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) управление уполномоченным администратором условиями открытия сеанса.

Аудит: FTA_TSE.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: запрещение открытия сеанса механизмом открытия сеанса;

б) базовый: все попытки открытия сеанса пользователя;

в) детализированный: фиксация значений выбранных параметров доступа (таких, как место доступа или время доступа).

FTA_TSE.1. Открытие сеанса с ОО

Иерархический для: Нет подчиненных компонентов.

#FTA_TSE.1.1 ФБО должны быть способны отказать в открытии сеанса, основываясь на [назначение: &атрибуты&]#.

Зависимости: отсутствуют.

13. Класс FTP. Доверенный маршрут/канал

Семейства класса FTP содержат требования как к доверенному маршруту связи между пользователями и ФБО, так и к доверенному каналу связи между ФБО и другими доверенными продуктами ИТ. Доверенные маршруты и каналы имеют следующие общие свойства:

• маршрут связи создается с использованием внутренних и внешних каналов коммуникаций (в соответствии с компонентом), которые изолируют идентифицированное подмножество данных и команд ФБО от остальной части данных пользователей и ФБО;
• использование маршрута связи может быть инициировано пользователем и/или ФБО (в соответствии с компонентом);
• маршрут связи способен обеспечить доверие тому, что пользователь взаимодействует с требуемыми ФБО или ФБО — с требуемым пользователем (в соответствии с компонентом).

Здесь &доверенный канал& — это канал связи, который может быть инициирован любой из связывающихся сторон и обеспечивает свойство неотказуемости по отношению к идентичности сторон канала.

&Доверенный маршрут& предоставляет пользователям средства для выполнения функций путем обеспечения прямого взаимодействия с ФБО. Доверенный маршрут обычно желателен при начальной идентификации и/или аутентификации пользователя, но может быть также применен на протяжении всего сеанса пользователя. Обмены по доверенному маршруту могут быть инициированы пользователем или ФБО. Гарантируется, что ответы пользователя с применением доверенного маршрута будут защищены от модификации или раскрытия недоверенными приложениями.

Декомпозиция класса FTP на составляющие его компоненты приведена на рисунке 13.1.

               ┌─────────────────────────┐
<pre class="legal-pre">               │  Класс FTP: Доверенный  │
               │      маршрут/канал      │</pre>
               └────────┬────────────────┘
                        │  ┌──────────────────────────┐ ┌─┐
                        ├──┤ FTP_ITC Доверенный канал ├─┤1│
<pre class="legal-pre">                        │  │    передачи между ФБО    │ │ │
                        │  └──────────────────────────┘ └─┘
                        │  ┌──────────────────────────┐ ┌─┐</pre>
                        └──┤FTP_TRP Доверенный маршрут├─┤1│
                           └──────────────────────────┘ └─┘

Рисунок 13.1. Декомпозиция класса "Доверенный маршрут/канал"

13.1. Доверенный канал передачи между ФБО (FTP_ITC)
Характеристика семейства
Семейство FTP_ITC определяет правила создания доверенного канала между ФБО и другими доверенными продуктами ИТ для выполнения операций, критичных для безопасности. Это семейство следует использовать всякий раз, когда имеются требования безопасной передачи данных пользователя или ФБО между ОО и другими доверенными продуктами ИТ.
Ранжирование компонентов

             ┌───────────────────────────────────────────┐ ┌─┐
             │FTP_ITC Доверенный канал передачи между ФБО├─┤1│
             └───────────────────────────────────────────┘ └─┘

FTP_ITC.1 «Доверенный канал передачи между ФБО» содержит требование, чтобы ФБО предоставили доверенный канал связи между ними самими и другим доверенным продуктом ИТ.

Управление: FTP_ITC.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) изменение набора операций, которые требуют доверенного канала (если таковой имеется).

Аудит: FTP_ITC.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: сбой функций доверенного канала;

б) минимальный: идентификация инициатора и адресата отказавших функций доверенного канала;

в) базовый: все попытки использования функций доверенного канала;

г) базовый: идентификация инициатора и адресата всех функций доверенного канала.

FTP_ITC.1. Доверенный канал передачи между ФБО

Иерархический для: Нет подчиненных компонентов.

#FTP_ITC.1.1 ФБО должны предоставлять канал связи между собой и удаленным доверенным продуктом ИТ, который логически отличим от других каналов связи и обеспечивает уверенную идентификацию его конечных сторон, а также защиту данных канала от модификации или раскрытия.

FTP_ITC.1.2 ФБО должны позволить [выбор: &ФБО, удаленный доверенный продукт ИТ&] инициировать связь через доверенный канал.

FTP_ITC.1.3 ФБО должны инициировать связь через доверенный канал для выполнения [назначение: &список функций, для которых требуется доверенный канал&]#.

Зависимости: отсутствуют.

13.2. Доверенный маршрут (FTP_TRP)

Характеристика семейства

Семейство FTP_TRP определяет требования установки и поддержания доверенной связи между пользователями и ФБО. Доверенный маршрут может потребоваться для любого связанного с безопасностью взаимодействия. Обмен по доверенному маршруту может быть инициирован пользователем при взаимодействии с ФБО, или же сами ФБО могут установить связь с пользователем по доверенному маршруту.

Ранжирование компонентов

                     ┌──────────────────────────┐ ┌─┐
                     │FTP_TRP Доверенный маршрут├─┤1│
                     └──────────────────────────┘ └─┘

FTP_TRP.1 «Доверенный маршрут» содержит требование, чтобы доверенный маршрут между ФБО и пользователем предоставлялся для совокупности событий, определенных разработчиком ПЗ/ЗБ. Возможность инициировать доверенный маршрут могут иметь пользователь и/или ФБО.

Управление: FTP_TRP.1

Для функций управления из класса FMT может рассматриваться следующее действие:

а) изменение набора операций, которые требуют доверенного маршрута, если он имеется.

Аудит: FTP_TRP.1

Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих действий/событий/параметров:

а) минимальный: сбой функций доверенного маршрута;

б) минимальный: идентификация пользователей, ассоциированных со всеми отказами доверенного маршрута (если это возможно);

в) базовый: все попытки использования функций доверенного маршрута;

г) базовый: идентификация пользователей, ассоциированных со всеми вызовами доверенного маршрута (если это возможно).

FTP_TRP.1. Доверенный маршрут

Иерархический для: Нет подчиненных компонентов.

#FTP_TRP.1.1 ФБО должны предоставлять маршрут связи между собой и [выбор: &удаленный, локальный&] пользователем, который логически отличим от других маршрутов связи и обеспечивает уверенную идентификацию его конечных сторон, а также защиту передаваемых данных от модификации или раскрытия.

FTP_TRP.1.2 ФБО должны позволить [выбор: &ФБО, локальные пользователи, удаленные пользователи&] инициировать связь через доверенный маршрут.

FTP_TRP.1.3 ФБО должны требовать использования доверенного маршрута для [выбор: &начальная аутентификация пользователя& [назначение: &другие услуги, для которых требуется доверенный маршрут&]]#.

ТРЕБОВАНИЙ БЕЗОПАСНОСТИ

Приложения А — П содержат дополнительную справочную информацию по использованию семейств и компонентов, определенных в нормативных элементах данной части ОК, которая может понадобиться потребителям, разработчикам или оценщикам при использовании компонентов. Для упрощения поиска требуемой информации порядок следования классов, семейств и компонентов в Приложениях тот же, что и в нормативных элементах данной части ОК. Структура представления классов, семейств и компонентов в Приложениях отличается от их предшествующего описания, так как Приложения содержат только вспомогательную информацию.

А.1. Структура замечаний

Раздел определяет содержание и форму замечаний, относящихся к функциональным требованиям ОК.

А.1.1. Структура класса

Структура функционального класса в Приложениях В - П приведена на рисунке А.1.

          ┌────────────────────┐
          │Функциональный класс├─┐
          └────────────────────┘ │
                                 │ ┌────────────────────────┐
                                 ├─┤      Имя класса        │
                                 │ └────────────────────────┘
                                 │ ┌────────────────────────┐
                                 ├─┤  Представление класса  │
                                 │ └────────────────────────┘
<pre class="legal-pre">                                 │    ┌─────────────────────────┐
                                 │  ┌─┴───────────────────────┐ │</pre>
                                 │ ┌┴───────────────────────┐ ├─┘
                                 └─┤Функциональные семейства├─┘
                                   └────────────────────────┘

Рисунок А.1. Структура функционального класса

А.1.1.1. Имя класса

Уникальное имя класса, определенное в нормативных элементах данной части ОК.

А.1.1.2. Представление класса

В представлении класса в Приложениях В - П приводится информация об использовании семейств и компонентов класса. Эта информация дополняется рисунком, показывающим организацию каждого класса и семейств в каждом классе, а также иерархические связи между компонентами в каждом семействе.

А.1.2. Структура семейства

Структура функционального семейства в замечаниях по применению приведена на рисунке А.2.

       ┌────────────────────────┐
       │Функциональное семейство├─┐
       └────────────────────────┘ │
                                  │ ┌──────────────────────────┐
                                  ├─┤      Имя семейства       │
                                  │ └──────────────────────────┘
                                  │ ┌──────────────────────────┐
                                  ├─┤Замечания для пользователя│
                                  │ └──────────────────────────┘
                                  │ ┌──────────────────────────┐
                                  ├─┤  Замечания для оценщика  │
                                  │ └──────────────────────────┘
<pre class="legal-pre">                                  │   ┌────────────────────────────┐
                                  │  ┌┴──────────────────────────┐ │</pre>
                                  │ ┌┴─────────────────────────┐ ├─┘
                                  └─┤       Компоненты         ├─┘
                                    └──────────────────────────┘

в замечаниях по применению

А.1.2.1. Имя семейства

Уникальное имя семейства, определенное в нормативных элементах данной части ОК.

А.1.2.2. Замечания для пользователя

Замечания для пользователя содержат дополнительную информацию, которая представляет интерес для потенциальных пользователей семейства, таких как разработчики ПЗ, ЗБ, функциональных пакетов, а также ОО. Эти замечания имеют информативный характер и могут охватывать предупреждения об ограничениях применения и тех аспектах, которые требуют особого внимания при использовании компонентов.

А.1.2.3. Замечания для оценщика

Замечания для оценщика содержат любую информацию, которая представляет интерес для разработчиков и оценщиков ОО при проверке его на соответствие компонентам семейства. Замечания носят информативный характер и могут относиться к различным областям, которые требуют особого внимания при оценке. Они могут включать в себя разъяснение назначения и определение возможных путей интерпретации требований, а также предостережения и предупреждения, представляющие особый интерес для оценщиков.

Замечания для пользователя и оценщика не обязательны и приводятся только при необходимости.

А.1.3. Структура компонента

Структура функциональных компонентов в замечаниях по применению показана на рисунке А.3.

Рисунок А.3. Структура функционального компонента

А.1.3.1. Идентификация компонента

Уникальное имя компонента, определенное в нормативных элементах данной части ОК.

А.1.3.2. Обоснование компонента и замечания по применению

В этом пункте может содержаться любая относящаяся к компоненту информация.

Обоснование содержит такие детали, которые уточняют общие формулировки применительно к определенному уровню; его следует использовать только в том случае, если на этом уровне требуется расширенное описание.

Замечания по применению содержат дополнительное уточнение в виде описания, относящегося к определенному компоненту. Это уточнение может касаться замечаний для пользователя и/или оценщика, как указано в А.1.2. Это уточнение может использоваться при объяснении природы зависимостей (например, совместно применяемая информация или операция).

Этот раздел не обязателен и вводится при необходимости.

А.1.3.3. Разрешенные операции

В этой части каждого компонента содержатся рекомендации по выполнению разрешенных в этом компоненте операций.

Этот пункт не обязателен и вводится только при необходимости.

А.2. Таблица зависимостей

В таблице А.1 показаны прямые, косвенные и выбираемые зависимости функциональных компонентов. Каждому компоненту, от которого зависят какие-либо функциональные компоненты, отведена графа. Каждому функциональному компоненту отведена строка. Знаки на пересечении строк и граф таблицы указывают характер зависимости соответствующих компонентов. «Х» — прямая зависимость; «-» — косвенная, а «О» — выбираемая.

Выбираемую зависимость рассмотрим на примере компонента FDP_ETC.1, требующего присутствия либо компонента FDP_ACC.1, либо компонента FDP_IFC.1. Так, если выбран компонент FDP_ACC.1, то присутствие FDP_IFC.1 необязательно, и наоборот. Если пересечение строки и графы таблицы пусто, компонент из строки не зависит от компонента из графы.

Таблица А.1