Руководство по критериям безопасности

Введен в действие
Приказом
Гостехкомиссии России
от 19 июня 2002 г. N 187

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 Глоссарий

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

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 иллюстрирует высокоуровневые понятия безопасности и их взаимосвязь.

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

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

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

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

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

Рисунок 4.2 Понятия, используемые при оценке, и их взаимосвязь

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

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

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

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

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

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

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

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

4.2.1 Разработка

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

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

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

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

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

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

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

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

4.2.2 Оценка ОО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 4.5 — Последовательное формирование требований и спецификаций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 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 показывает взаимосвязь между различными конструкциями.

Рисунок 4.7 — Использование требований безопасности

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 показаны различные пути использования результатов оценки. Продукты можно оценивать и каталогизировать последовательно на все более высоких уровнях агрегирования вплоть до достижения уровня эксплуатируемых систем, когда продукты могут подлежать оценке в связи с аттестацией системы.

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

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

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

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

Приложение А
(справочное)

ПРОЕКТ ОБЩИХ КРИТЕРИЕВ

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

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

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

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

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

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

Версия 1.0 ОК была завершена CCEB в январе 1996г. и одобрена ISO в апреле 1996г. для распространения в качестве Проекта комитета. Был проведен ряд экспериментальных оценок на основе версии 1.0 ОК, а также организовано широкое публичное обсуждение документа. Затем в рамках Проекта ОК была предпринята значительная переработка ОК на основе замечаний, полученных при его экспериментальном использовании, публичном обсуждении и взаимодействии с ISO. Переработка документа была выполнена преемником CCEB, который в настоящее время называется Советом по реализации ОК (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 Краткий обзор

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

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

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

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

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

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

Рисунок Б.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 Corpora-tion MTR-2997, Bedford MA, March1976.

[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, Ca-nadian System Security Centre, Communications Security Establishment, Government of Canada, January 1993.

[FC] Federal Criteria for Information Technology Security, Draft Version 1.0, (Vo-lumes 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 Interconnec-tion — 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 ОК, в этом подразделе не изменяются и не переопределяются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 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.

Рисунок 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.

Рисунок 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.

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

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

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

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

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

В 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 определяет требования по регистрации возникновения событий, относящихся к безопасности, которые подконтрольны ФБО. Это семейство идентифицирует уровень аудита, перечисляет типы событий, которые потенциально должны подвергаться аудиту с использованием ФБО, и определяет минимальный объем связанной с аудитом информации, которую следует представлять в записях аудита различного типа.

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

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.

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

В 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 определяет требования к средствам аудита, к которым следует предоставить доступ уполномоченным пользователям для использования при просмотре данных аудита.

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

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

Для функций управления из класса 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 определяет требования, при выполнении которых ФБО способны создавать и сопровождать журнал аудита безопасности.

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

В 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.

Рисунок 4.1. Декомпозиция класса «Связь»

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

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

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

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

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 «Избирательное доказательство получения» содержит требование, чтобы ФБО предоставили субъектам возможность запросить свидетельство получения информации.

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.

Рисунок 5.1. Декомпозиция класса «Криптографическая поддержка»

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

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

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

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

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

Если в ПЗ/ЗБ включено семейство 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.

Рисунок 6.1. Декомпозиция класса «Защита данных пользователя»

Рисунок 6.2. Декомпозиция класса «Защита данных пользователя» (продолжение)

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

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

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

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

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_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 «Базовая аутентификация данных» содержит требование, чтобы ФБО были способны предоставить гарантию подлинности информации, содержащейся в объектах (например, документах).

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 определяет функции для экспорта данных пользователя из ОО таким образом, что их атрибуты безопасности и защита могут или полностью сохраняться, или игнорироваться при экспорте этих данных. В семействе также рассматриваются ограничения на экспорт и ассоциация атрибутов безопасности с экспортируемыми данными пользователя.

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

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 «Ограниченное управление информационными потоками» содержит требование, чтобы каждая идентифицированная ПФБ управления информационными потоками выполнялась для подмножества возможных операций на подмножестве информационных потоков в ОО.

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, где также определена область действия соответствующей политики. Семейство содержит два типа требований: один связан с обычными информационными потоками, а второй — с неразрешенными информационными потоками (скрытыми каналами). Это разделение возникает, потому что проблема неразрешенных информационных потоков в некотором смысле противоречит остальным аспектам ПФБ управления информационными потоками. По существу, скрытые каналы дают возможность обходить ПФБ управления информационными потоками в нарушение политики. Таким образом, возникает потребность в специальных функциях, которые либо ограничивают, либо предотвращают их возникновение.

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

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 определяет механизмы для передачи данных пользователя в ОО таким образом, чтобы эти данные имели требуемые атрибуты безопасности и защиту. В семействе также рассматриваются ограничения на импорт и определение требуемых атрибутов безопасности, а также интерпретация атрибутов безопасности, ассоциированных с данными пользователя.

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

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

Компонент 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, которые связаны с передачей данных за пределы или из-за пределов действия ФБО.

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

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 «Ограниченная защита остаточной информации» содержит требование, чтобы ФБО обеспечили недоступность содержания всей остаточной информации любых ресурсов для определенного подмножества объектов в ОДФ при распределении или освобождении ресурса.

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 «Базовый откат» связан с необходимостью вернуть обратно или отменить ограниченное число операций в определенных пределах.

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 «Мониторинг целостности хранимых данных» содержит требование, чтобы ФБ контролировала данные пользователя, хранимые в пределах ОДФ, на наличие идентифицированных ошибок целостности.

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 определяет требования по обеспечению конфиденциальности данных пользователя при их передаче по внешнему каналу между ОО и доверенными внешними объектами ИТ или между пользователями ОО и различных доверенных внешних объектов ИТ.

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

Цель компонента 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 определяет требования по обеспечению целостности данных пользователя при их передаче между ФБО и другим доверенным продуктом ИТ, а также для их восстановления при обнаружении ошибок. Как минимум, это семейство контролирует целостность данных пользователя на предмет модификации. Кроме того, семейство поддерживает различные способы исправления обнаруженных ошибок целостности.

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

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.

Рисунок 7.1. Декомпозиция класса «Идентификация и аутентификация»

7.1. Отказы аутентификации (FIA_AFL)

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

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

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

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

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

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

Аудит: FIA_ATD.1

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

FIA_ATD.1. Определение атрибутов пользователя

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

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

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

7.3. Спецификация секретов (FIA_SOS)

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

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

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

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 определяет типы механизмов аутентификации пользователя, предоставляемые ФБО. Оно также определяет те атрибуты, на которых необходимо базировать механизмы аутентификации пользователя.

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

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 «Выбор момента идентификации» позволяет пользователю выполнить некоторые действия перед своей идентификацией с использованием ФБО.

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

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

а) переопределение уполномоченным администратором заданных по умолчанию атрибутов безопасности субъекта.

Аудит: FIA_USB.1

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

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

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

FIA_USB.1. Связывание пользователь-субъект

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

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

Зависимости: FIA_ATD.1 Определение атрибутов пользователя.

8. Класс FMT. Управление безопасностью

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

Класс позволяет решать следующие задачи:

а) управление данными ФБО, которые включают в себя, например, предупреждающие сообщения;

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

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

г) определение ролей безопасности.

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

Рисунок 8.1. Декомпозиция класса «Управление безопасностью»

8.1. Управление отдельными функциями ФБО (FMT_MOF)

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

Семейство FMT_MOF позволяет уполномоченным пользователям управлять функциями из числа ФБО. К ним относятся, например, функции аудита и аутентификации.

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

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 допускает уполномоченных пользователей к управлению атрибутами безопасности. Такое управление может включать в себя возможности просмотра и модификации атрибутов безопасности.

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

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 допускает уполномоченных пользователей (роли) к управлению данными ФБО. Примеры данных ФБО: информация аудита, текущее значение времени, конфигурация системы, другие параметры конфигурации ФБО.

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

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 могут рассматриваться следующие действия:

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

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

в) управление правилами отмены.

Аудит: 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 могут рассматриваться следующие действия:

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

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

Аудит: 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 предназначено для управления назначением различных ролей пользователям. Возможности этих ролей по управлению безопасностью описаны в других семействах этого класса.

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

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.

Рисунок 9.1. Декомпозиция класса «Приватность»

9.1. Анонимность (FPR_ANO)

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

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

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

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 обеспечивает, чтобы пользователь мог использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время ответственным за это использование.

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

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

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

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

Аудит: FPR_UNL.1

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

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

FPR_UNL.1. Невозможность ассоциации

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

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

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

9.4. Скрытность (FPR_UNO)

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

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

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

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.

Рисунок 10.1. Декомпозиция класса «Защита ФБО»

Рисунок 10.2. Декомпозиция класса «Защита ФБО» (продолжение)

10.1. Тестирование базовой абстрактной машины (FPT_AMT)

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

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

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

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

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

а) базовый: сбой ФБО.

FPT_FLS.1. Сбой с сохранением безопасного состояния

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

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

Зависимости: ADV_SPM.1 Неформальная модель политики безопасности ОО.

10.3. Доступность экспортируемых данных ФБО (FPT_ITA)

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

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

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

Это семейство состоит из одного компонента 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.1 ФБО должны защитить все данные ФБО, передаваемые от ФБО к удаленному доверенному продукту ИТ, от несанкционированного раскрытия при передаче.

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

10.5. Целостность экспортируемых данных ФБО (FPT_ITI)

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

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

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

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 предоставляет требования защиты данных ФБО при их передаче между разделенными частями ОО по внутреннему каналу.

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

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 дают возможность ограничивать физический доступ к ФБО, а также реагировать на несанкционированную физическую модификацию или подмену реализации ФБО и противодействовать им.

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

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

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 обеспечивают, чтобы ФБО могли определить, не нарушена ли защита ФБО при запуске, и восстанавливаться без нарушения защиты после прерывания операций. Это семейство важно, потому что начальное состояние ФБО при запуске или восстановлении определяет защищенность ОО в последующем.

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

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

Для функций управления из класса 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.1 ФБО должны обеспечить, чтобы функции, осуществляющие ПБО, вызывались и успешно выполнялись прежде, чем разрешается выполнение любой другой функции в пределах ОДФ.

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

10.11. Разделение домена (FPT_SEP)

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

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

Это семейство содержит следующие требования:

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

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

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

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

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

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 «Одностороннее надежное подтверждение» содержит требование подтверждения одним лишь получателем данных.

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

Для функций управления из класса 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

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

а) минимальный: успешное использование механизмов согласования данных ФБО;

б) базовый: использование механизмов согласования данных ФБО;

в) базовый: идентификация ФБО, данные которых интерпретируются;

г) базовый: обнаружение модифицированных данных ФБО.

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

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

FPT_TDC.1.1 ФБО должны обеспечить способность согласованно интерпретировать [назначение: список типов данных ФБО%], совместно используемые ФБО и другим доверенным продуктом ИТ.

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

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

10.15. Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)

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

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

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

Это семейство состоит из одного компонента 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

Для функций управления из класса 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.

Рисунок 11.1. Декомпозиция класса «Использование ресурсов»

11.1. Отказоустойчивость (FRU_FLT)

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

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

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

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 «Ограниченный приоритет обслуживания» предоставляет приоритеты для использования субъектами подмножества ресурсов в пределах ОДФ.

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 «Максимальные квоты» содержит требования к механизмам квотирования, которые обеспечивают, чтобы пользователи и субъекты не монополизировали управляемый ресурс.

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.

Рисунок 12.1. Декомпозиция класса «Доступ к ОО»

12.1. Ограничение области выбираемых атрибутов (FTA_LSA)

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

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

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

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 «Базовое ограничение на параллельные сеансы» предоставляет ограничения, которые применяются ко всем пользователям ФБО.

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 определяет требования к ФБО по предоставлению возможности как ФБО, так и пользователю блокировать и разблокировать интерактивный сеанс.

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

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 определяет требования к отображению для пользователей предупреждающего сообщения с перестраиваемой конфигурацией относительно характера использования ОО.

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

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.1 При успешном открытии сеанса ФБО должны отобразить [выбор: дата, время, метод, расположение] последнего успешного открытия сеанса от имени пользователя.

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

FTA_TAH.1.3 ФБО не должны удалять информацию об истории доступа из интерфейса пользователя без предоставления пользователю возможности просмотреть ее.

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

12.6. Открытие сеанса с ОО (FTA_TSE)

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

Семейство FTA_TSE определяет требования по запрещению пользователям открытия сеанса с ОО.

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

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.

Рисунок 13.1. Декомпозиция класса «Доверенный маршрут/канал»

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

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

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

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

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

Для функций управления из класса 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.

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

А.1.1.1. Имя класса

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

А.1.1.2. Представление класса

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

А.1.2. Структура семейства

Структура функционального семейства в замечаниях по применению приведена на рисунке А.2.

Рисунок А.2. Структура функционального семейства в замечаниях по применению

А.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

ЗАВИСИМОСТИ ФУНКЦИОНАЛЬНЫХ КОМПОНЕНТОВ

Приложение Б
(справочное)

ФУНКЦИОНАЛЬНЫЕ КЛАССЫ, СЕМЕЙСТВА И КОМПОНЕНТЫ

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

Приложение В
(справочное)

АУДИТ БЕЗОПАСНОСТИ (FAU)

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

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

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

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

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

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

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

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

Рисунок В.1. Декомпозиция класса «Аудит безопасности»

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

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

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

Событие аудита определяется как «возможное нарушение безопасности», если так указано в компонентах семейства FAU_SAA.

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

Замечания по применению для пользователя

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

Операции

Назначение

В элементе FAU_ARP.1.1 автору ПЗ/ЗБ следует определить действия, предпринимаемые в случае возможного нарушения безопасности. Примером списка таких действий является: «информировать уполномоченного пользователя, блокировать субъекта, действия которого могут привести к нарушению безопасности». Можно также указать, что предпринимаемые действия могут определяться уполномоченным пользователем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже приведены примеры типов событий, которые следует определить как потенциально подвергаемые аудиту в каждом функциональном компоненте ПЗ/ЗБ:

а) введение объектов из ОДФ в адресное пространство субъекта;

б) удаление объектов;

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

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

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

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

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

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

к) ввод/вывод данных с/на заменяемых носителей (таких, как печатные материалы, ленты, дискеты).

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

Замечания по применению для пользователя

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

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

Замечания по применению для оценщика

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

Операции

Выбор

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

Назначение

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

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

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

Замечания по применению для пользователя

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

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

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

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

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

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

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

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

Замечания по применению для пользователя

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

Операции

Назначение

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

Назначение

В FAU_SAA.1.2.б автору ПЗ/ЗБ следует определить любые другие правила, которые ФБО следует использовать для анализа журнала аудита. Эти правила могут включать в себя конкретные требования, согласно которым необходимо, чтобы в течение указанного периода времени (например, установленного времени суток, заданного интервала времени) произошли определенные события.

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

Замечания по применению для пользователя

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

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

а) учетные данные единственного пользователя — один профиль на пользователя;

б) единый идентификатор или общие учетные данные группы — один профиль на всех пользователей с единым групповым идентификатором или общими учетными данными группы;

в) операционная роль — один профиль на всех пользователей, выполняющих данную операционную роль;

г) система в целом — один профиль на всех пользователей системы.

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

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

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

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

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

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

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

Операции

Выбор

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

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

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

Замечания по применению для пользователя

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

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

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

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

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

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

Операции

Назначение

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

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

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

Замечания по применению для пользователя

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

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

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

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

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

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

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

Операции

Назначение

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

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

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

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

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

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

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

— действия, выполненные над определенным объектом или ресурсом ОО;

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

действия, связанные с определенным атрибутом ПБО.

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

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

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

Замечания по применению для пользователя

Компонент FAU_SAR.1 используется для определения возможности читать записи аудита для пользователей и/или уполномоченных пользователей. Эти записи аудита будут представляться в удобном для пользователя виде. У пользователей различных типов могут быть разные требования к представлению данных аудита.

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

Операции

Назначение

В FAU_SAR.1.1 автору ПЗ/ЗБ следует указать уполномоченных пользователей, которые могут просматривать данные аудита. Если это необходимо, автор ПЗ/ЗБ может указать роли безопасности (см. FMT_SMR.1 «Роли безопасности»).

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

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

Замечания по применению для пользователя

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

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

Замечания по применению для пользователя

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

Операции

Выбор

Для FAU_SAR.3.1 автору ПЗ/ЗБ следует выбрать, какие действия: поиск, сортировку или упорядочение могут выполнять ФБО.

Назначение

Для FAU_SAR.3.1 автору ПЗ/ЗБ следует назначить критерии, возможно логически связанные, на основании которых производят выбор данных аудита для просмотра. Логические связи используют при определении, производится ли операция над отдельными атрибутами или над совокупностью атрибутов. Примерами такого назначения может быть: «прикладная задача, учетные данные и/или место нахождения пользователя». В этом случае операцию можно было бы специфицировать с помощью любой комбинации этих трех атрибутов: прикладной задачи, учетных данных пользователя и места его нахождения.

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

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

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

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

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

Замечания по применению для пользователя

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

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

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

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

Операции

Выбор

Для FAU_SEL.1.1а автору ПЗ/ЗБ следует выбрать, на каких атрибутах безопасности основана избирательность аудита: идентификатор объекта, идентификатор пользователя, идентификатор субъекта, идентификатор узла сети или тип события.

Назначение

Для FAU_SEL.1.1б автору ПЗ/ЗБ следует определить список дополнительных атрибутов, на которых основана избирательность аудита.

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

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

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

Замечания по применению для пользователя

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

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

Операции

Выбор

В FAU_STG.1.2 автору ПЗ/ЗБ следует специфицировать, должны ли ФБО предотвращать или только выявлять модификацию журнала аудита.

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

Замечания по применению для пользователя

Компонент FAU_STG.2 позволяет автору ПЗ/ЗБ определить метрику для журнала аудита.

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

Операции

Выбор

В FAU_STG.2.2 автору ПЗ/ЗБ следует специфицировать, должны ли ФБО предотвращать или только выявлять модификацию журнала аудита.

В FAU_STG.2.3 автору ПЗ/ЗБ следует специфицировать условие, при котором ФБО должны быть все еще способны сопровождать определенный объем данных аудита. Это может быть одно из следующих условий: переполнение журнала аудита, сбой, атака.

Назначение

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

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

Замечания по применению для пользователя

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

Операции

Назначение

В FAU_STG.3.1 автору ПЗ/ЗБ следует указать значение заранее определяемого предела. Если функции управления допускают, что уполномоченный пользователь может его изменить, то оно является значением по умолчанию. Автор ПЗ/ЗБ может позволить уполномоченному пользователю всегда определять это ограничение. В этом случае назначение может иметь вид: «ограничение устанавливает уполномоченный пользователь».

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

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

Замечания по применению для пользователя

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

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

Операции

Выбор

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

Назначение

В FAU_STG.4.1 автору ПЗ/ЗБ следует определить другие действия, предпринимаемые при недостатке памяти для данных аудита, такие как информирование уполномоченного пользователя.

Приложение Г
(справочное)

СВЯЗЬ (FCO)

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

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

Рисунок Г.1. Декомпозиция класса «Связь»

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

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

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

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

Замечания для пользователя

Если информация или ассоциированные с ней атрибуты каким-либо образом изменяются, подтверждение правильности свидетельства отправления может дать отрицательный результат. Поэтому автору ПЗ/ЗБ следует предусмотреть включение в ПЗ/ЗБ требований целостности из компонента FDP_UIT.1 «Целостность передаваемых данных».

Неотказуемость связана с несколькими различными ролями, выполняемыми одним или несколькими субъектами. Во-первых, это субъект, который запрашивает свидетельство отправления (только в FCO_NRO.1 «Избирательное доказательство отправления»). Во-вторых, — получатель и/или другие субъекты, которым предоставляется свидетельство (например, нотариус). И, в-третьих, — субъект, который запрашивает верификацию свидетельства отправления, например получатель или третье лицо, например арбитр.

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

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

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

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

Операции

Назначение

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

Выбор

В FCO_NRO.1.1 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может запросить свидетельство отправления.

Назначение

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

В FCO_NRO.1.2 автору ПЗ/ЗБ следует внести в список те атрибуты, которые должны быть связаны с информацией, например идентификатор отправителя, время и место отправления.

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

Выбор

В FCO_NRO.1.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство отправления.

Назначение

В FCO_NRO.1.3 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третьих лиц, которые могут верифицировать свидетельство отправления.

В FCO_NRO.1.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение «немедленно» или «неограниченно».

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

Операции

Назначение

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

В FCO_NRO.2.2 автору ПЗ/ЗБ следует внести в список те атрибуты, которые должны быть связаны с информацией, например идентификатор отправителя, время и место отправления.

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

Выбор

В FCO_NRO.2.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство отправления.

Назначение

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

В FCO_NRO.2.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение «немедленно» или «неограниченно».

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

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

Замечания для пользователя

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

Если информация или ассоциированные с ней атрибуты каким-либо образом изменяются, проверка правильности свидетельства получения может дать отрицательный результат. Поэтому автору ПЗ/ЗБ следует предусмотреть включение в ПЗ/ЗБ требований целостности из компонента FDP_UIT.1 «Целостность передаваемых данных».

Неотказуемость связана с несколькими различными ролями, выполняемыми одним или несколькими субъектами. Во-первых, это субъект, который запрашивает свидетельство получения (только в FCO_NRR.1 «Избирательное доказательство получения»). Во-вторых, — получатель и/или другие субъекты, которым предоставляется свидетельство (например, нотариус). И, в-третьих, — субъект, который запрашивает верификацию свидетельства получения, например отправитель или третья сторона, например арбитр.

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

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

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

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

Операции

Назначение

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

Выбор

В FCO_NRR.1.1 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может запросить свидетельство получения.

Назначение

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

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

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

Выбор

В FCO_NRR.1.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство получения.

Назначение

В FCO_NRR.1.3 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третьих лиц, которые могут верифицировать свидетельство получения.

В FCO_NRR.1.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение «немедленно» или «неограниченно».

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

Операции

Назначение

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

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

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

Выбор

В FCO_NRR.2.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство получения.

Назначение

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

В FCO_NRR.2.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение «немедленно» или «неограниченно».

Приложение Д
(справочное)

КРИПТОГРАФИЧЕСКАЯ ПОДДЕРЖКА (FCS)

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

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

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

Рисунок Д.1. Декомпозиция класса «Криптографическая поддержка»

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

Для каждого метода распределения криптографических ключей, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.2.

Для каждого метода доступа к криптографическим ключам, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.3.

Для каждого метода уничтожения криптографических ключей, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.4.

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

Криптографические функциональные возможности применимы для достижения целей безопасности, специфицированных в классе FCO, а также в семействах FDP_DAU, FDP_SDI, FDP_UCT, FDP_UIT, FIA_SOS, FIA_UAU. В случае, когда криптографические функциональные возможности используют для достижения целей безопасности из других классов, цели, требующие применения криптографических средств, специфицируют в отдельных компонентах. Цели класса FSC следует учитывать, когда потребители нуждаются в криптографических функциональных возможностях ОО.

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

Замечания для пользователя

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

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

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

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

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

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

Для генерации криптографических ключей обычно используют случайные числа. Тогда вместо FIA_SOS.2 «Генерация секретов ФБО» следует использовать компонент FCS_CKM.1. Компонент FIA_SOS.2 следует применять, когда генерация случайных чисел требуется для иных целей.

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

Замечания по применению для пользователя

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

Операции

Назначение

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

В FCS_CKM.1.1 автору ПЗ/ЗБ следует определить, какой длины криптографические ключи будут использоваться. Следует, чтобы длина ключа соответствовала выбранному алгоритму и предполагаемому применению ключа.

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

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

Замечания по применению для пользователя

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

Операции

Назначение

В FCS_CKM.2.1 автору ПЗ/ЗБ следует определить, какой метод используется для распределения криптографических ключей.

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

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

Замечания по применению для пользователя

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

Операции

Назначение

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

В FCS_CKM.3.1 автору ПЗ/ЗБ следует определить, какой метод будет использоваться для доступа к криптографическим ключам.

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

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

Замечания по применению для пользователя

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

Операции

Назначение

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

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

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

Замечания для пользователя

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

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

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

б) применения различных криптографических алгоритмов и/или длины криптографических ключей;

в) типа или чувствительности обрабатываемых данных.

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

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

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

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

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

Замечания по применению для пользователя

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

Операции

Назначение

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

В FCS_COP.1.1 автору ПЗ/ЗБ следует определить, какой криптографический алгоритм будет использован. Обычно применяют алгоритмы типа DES, RSA, IDEA, но могут использоваться и другие.

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

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

Приложение Е
(справочное)

ЗАЩИТА ДАННЫХ ПОЛЬЗОВАТЕЛЯ (FDP)

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

Этот класс не содержит явного требования «мандатного управления доступом» (Mandatory Access Controls — MAC) или традиционного «дискреционного управления доступом» (Discretionary Access Controls — DAC); тем не менее, такие требования могут быть выражены с использованием компонентов этого класса.

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

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

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

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

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

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

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

Декомпозиция класса FDP на составляющие его компоненты приведена на рисунках Е.1 и Е.2.

Рисунок Е.1. Декомпозиция класса «Защита данных пользователя»

Рисунок Е.2. Декомпозиция класса «Защита данных пользователя» (продолжение)

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

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

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

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

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

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

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

в) все применяемые компоненты, относящиеся к функциям, из семейств FDP_ACF и FDP_IFF, связанные с именованными политиками из семейств FDP_ACC и FDP_IFC. Выполнить операции, чтобы получить компоненты, определяющие правила этих политик. Следует отразить в компонентах требования к выбранным функциям, как полностью сформулированные, так и предполагаемые (которые будут завершены в ЗБ);

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

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

е) все компоненты семейства FDP_ROL, применяемые для отката к предшествующему состоянию;

ж) все требования из семейства FDP_RIP, применяемые для защиты остаточной информации;

и) все компоненты из семейств FDP_ITC и FDP_ETC, используемые при импорте или экспорте данных, указав, как следует обращаться при этом с атрибутами безопасности;

к) все используемые компоненты, относящиеся к внутренним передачам ОО, из семейства FDP_ITT;

л) требования защиты целостности хранимой информации из FDP_SDI;

м) все применяемые компоненты, относящиеся к передаче данных между ФБО, из семейств FDP_UCT или FDP_UIT.

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

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

Замечания для пользователя

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

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

Важнейшим аспектом функции управления доступом, осуществляющей ПФБ управления доступом, является предоставление пользователям возможности модифицировать атрибуты управления доступом. Семейство FDP_ACC для этого не предназначено. Часть относящихся к этой проблеме требований не определена, но их можно ввести как уточнение; часть содержится в других семействах и классах, например в классе FMT «Управление безопасностью».

В семействе FDP_ACC нет требований аудита, поскольку он специфицирует только требования ПФБ управления доступом. Требования аудита присутствуют в семействах, специфицирующих функции для удовлетворения ПФБ управления доступом, идентифицированных в этом семействе.

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

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

Замечания по применению для пользователя

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

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

Операции

Назначение

В FDP_ACC.1.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления доступом, осуществляемую ФБО.

В FDP_ACC.1.1 автору ПЗ/ЗБ следует специфицировать список субъектов, объектов и операций субъектов на объектах, на которые распространяется данная ПФБ.

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

Замечания по применению для пользователя

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

Автору ПЗ/ЗБ необходимо продемонстрировать, что на любую комбинацию объектов и субъектов распространяется какая-либо ПФБ управления доступом.

Операции

Назначение

В FDP_ACC.2.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления доступом, осуществляемую ФБО.

В FDP_ACC.2.1 автору ПЗ/ЗБ следует специфицировать список субъектов и объектов, на которые распространяется данная ПФБ. ПФБ будет распространяться на все операции между этими субъектами и объектами.

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

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

Замечания для пользователя

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

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

В этом семействе можно определить ряд ФБ управления доступом, имеющих в основе:

— списки контроля доступа (матрица доступа);

— спецификации управления доступом на основе времени;

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

— атрибуты управления доступом, управляемые их владельцем.

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

Замечания по применению для пользователя

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

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

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

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

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

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

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

Операции

Назначение

В FDP_ACF.1.1 автору ПЗ/ЗБ следует специфицировать имя ПФБ управления доступом, осуществляемой ФБО. Имя и область действия ПФБ управления доступом определяются в компонентах семейства FDP_ACC.

В FDP_ACF.1.1 автору ПЗ/ЗБ следует специфицировать атрибуты безопасности и/или именованные группы атрибутов безопасности, которые функция будет использовать при спецификации правил. Такими атрибутами безопасности могут быть, например, идентификатор пользователя, идентификатор субъекта, роль, время суток, местоположение, списки контроля доступа, а также любые другие атрибуты, специфицированные автором ПЗ/ЗБ. Для удобства ссылок на атрибуты безопасности неоднократного применения можно ввести именованные группы атрибутов безопасности. Именованные группы могут оказаться полезными при ассоциации «ролей», определенных в семействе FMT_SMR «Роли управления безопасностью», и соответствующих им атрибутов с субъектами. Другими словами, каждую роль можно связать с именованной группой атрибутов.

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

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

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

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

Семейство FDP_DAU описывает специальные функции, используемые для аутентификации «статических» данных.

Замечания для пользователя

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

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

Замечания по применению для пользователя

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

Операции

Назначение

В FDP_DAU.1.1 автору ПЗ/ЗБ следует специфицировать список объектов или типов информации, для которых ФБО должны быть в состоянии генерировать свидетельство аутентификации данных.

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

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

Замечания по применению для пользователя

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

Операции

Назначение

В FDP_DAU.2.1 автору ПЗ/ЗБ следует специфицировать список объектов или типов информации, для которых ФБО должны быть в состоянии генерировать свидетельство аутентификации данных.

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

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

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

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

Замечания для пользователя

FDP_ETC и соответствующее семейство для импорта данных FDP_ITC определяют, как ОО поступает с данными пользователей, передаваемыми из ОДФ и поступающими в нее. Фактически семейство FDP_ETC обеспечивает экспорт данных пользователей и связанных с ними атрибутов безопасности.

В этом семействе могут рассматриваться следующие действия:

а) экспорт данных пользователей без каких-либо атрибутов безопасности;

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

Если применяются несколько ПФБ управления доступом и/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой политики (т.е. применить к нему операцию итерации).

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

Замечания по применению для пользователя

Компонент FDP_ETC.1 используется для спецификации экспорта информации без экспорта атрибутов безопасности.

Операции

Назначение

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

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

Замечания по применению для пользователя

Данные пользователя экспортируются вместе со своими атрибутами безопасности. Эти атрибуты безопасности однозначно ассоциированы с данными пользователя. Ассоциация может устанавливаться различными способами. К способам установления ассоциации относятся совместное физическое размещение данных пользователя и атрибутов безопасности (например, на одной дискете) или использование криптографических приемов, таких как цифровые подписи, для ассоциации этих атрибутов и данных пользователя. Для обеспечения получения правильных значений атрибутов другим доверенным продуктом ИТ можно использовать семейство FTP_ITC «Доверенный канал передачи между ФБО», в то время как семейство FPT_TDC «Согласованность данных ФБО между ФБО» может применяться для достижения уверенности в правильной интерпретации этих атрибутов. В свою очередь, семейство FTP_TRP «Доверенный маршрут» может применяться для достижения уверенности в инициации экспорта надлежащим пользователем.

Операции

Назначение

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

В FDP_ETC.2.4 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления экспортом или указать «Нет» при их отсутствии. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/или информационными потоками, выбранным в FDP_ETC.2.1.

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

В семействе FDP_IFC идентифицируются ПФБ управления информационными потоками и специфицируются области действия каждой такой политики.

Примерами политик безопасности, которые могут быть применены, являются:

— модель безопасности Белла и Ла Падулы (Bell and La Padula [BL]);

— модель целостности Биба (Biba [Biba]);

— невмешательство (Non-interference) [Gogul, Gogu2].

Замечания для пользователя

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

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

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

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

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

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

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

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

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

Замечания по применению для пользователя

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

Операции

Назначение

В FDP_IFC.1.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления информационными потоками, осуществляемую ФБО.

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

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

Замечания по применению для пользователя

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

Автору ПЗ/ЗБ необходимо продемонстрировать, что на любую комбинацию информационных потоков и субъектов распространяется какая-либо ПФБ управления информационным потоком.

Операции

Назначение

В FDP_IFC.2.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления информационными потоками, осуществляемую ФБО.

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

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

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

Замечания для пользователя

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

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

Гибкость этих компонентов позволяет специфицировать в FDP_IFF.1 и FDP_IFF.2 политику полномочий, дающую возможность контролируемого обхода ПФБ в целом или частично. Если необходимо заранее предопределить обход ПФБ, автору ПЗ/ЗБ следует предусмотреть применение политики полномочий.

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

Замечания по применению для пользователя

Компонент FDP_IFF.1 содержит требования наличия атрибутов безопасности у информации и субъектов, являющихся отправителями или получателями этой информации. Следует также учитывать атрибуты безопасности мест хранения информации, если требуется их участие в управлении информационными потоками, или если на эти атрибуты распространяется политика управления доступом. Этот компонент специфицирует ключевые осуществляемые правила и описывает, как вводятся атрибуты безопасности. Например, компонент следует применять, когда хотя бы одна из ПФБ управления информационными потоками основана на метках, как это определяет модель политики безопасности Белла и Ла Падулы [BL], но эти атрибуты безопасности не образуют иерархию.

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

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

Операции

Назначение

В FDP_IFF.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

В FDP_IFF.1.1 автору ПЗ/ЗБ следует специфицировать минимальное число и тип атрибутов безопасности, которые будут использоваться при спецификации правил. Такими атрибутами безопасности могут быть, например, идентификатор субъекта, уровень чувствительности субъекта, уровень допуска субъекта к информации, уровень чувствительности информации и т.д. Следует, чтобы минимальное число атрибутов безопасности каждого типа было достаточным для поддержки потребностей среды.

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

В FDP_IFF.1.3 автору ПЗ/ЗБ следует специфицировать все дополнительные правила ПФБ управления информационными потоками, которые от ФБО требуется реализовать. Если дополнительные правила не используются, то автору ПЗ/ЗБ следует указать «Нет» при выполнении рассматриваемой операции.

В FDP_IFF.1.4 автору ПЗ/ЗБ следует специфицировать все дополнительные возможности ПФБ, которые от ФБО требуется предоставить. Если дополнительные возможности не предоставляются, то автору ПЗ/ЗБ следует указать «Нет» при выполнении рассматриваемой операции.

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

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

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

Замечания по применению для пользователя

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

Например, этот компонент следует применять, когда хотя бы одна из ПФБ управления информационными потоками основана на метках, как это определяет модель политики безопасности Белла и Ла Падулы [BL], и эти атрибуты безопасности образуют иерархию.

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

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

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

Операции

Назначение

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

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

В FDP_IFF.2.3 автору ПЗ/ЗБ следует специфицировать все дополнительные правила ПФБ управления информационными потоками, которые от ФБО требуется реализовать. Если дополнительные правила не используются, то автору ПЗ/ЗБ следует указать «Нет» при выполнении рассматриваемой операции.

В FDP_IFF.2.4 автору ПЗ/ЗБ следует специфицировать все дополнительные возможности ПФБ, которые от ФБО требуется предоставить. Если дополнительные возможности не предоставляются, то автору ПЗ/ЗБ следует указать «Нет» при выполнении рассматриваемой операции.

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

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

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

Замечания по применению для пользователя

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

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

Операции

Назначение

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать типы неразрешенных информационных потоков, максимальная интенсивность которых ограничивается.

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать максимальную интенсивность, допустимую для каждого из идентифицированных неразрешенных информационных потоков.

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

Замечания по применению для пользователя

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

Операции

Назначение

В FDP_IFF.4.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

В FDP_IFF.4.1 автору ПЗ/ЗБ следует специфицировать типы неразрешенных информационных потоков, максимальная интенсивность которых ограничивается.

В FDP_IFF.4.1 автору ПЗ/ЗБ следует специфицировать максимальную интенсивность, допустимую для каждого из идентифицированных неразрешенных информационных потоков.

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

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

Замечания по применению для пользователя

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

Операции

Назначение

В FDP_IFF.5.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, для которой информационные потоки требуется устранить. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

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

Замечания по применению для пользователя

Компонент FDP_IFF.6 следует использовать, когда от ФБО требуется проведение мониторинга неразрешенных информационных потоков, интенсивность которых превышает специфицированное пороговое значение. Если такой поток требуется подвергнуть аудиту, то этот компонент может служить источником событий аудита для компонентов семейства FAU_GEN «Генерация данных аудита безопасности».

Операции

Назначение

В FDP_IFF.6.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

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

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

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

Семейство FDP_ITC определяет механизмы для импорта данных пользователя в ОО из-за пределов ОДФ таким образом, чтобы атрибуты безопасности данных пользователя при этом сохранялись. Согласованность этих атрибутов безопасности определяется семейством FPT_TDC «Согласованность данных ФБО между ФБО».

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

Замечания для пользователя

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

В семействе могут рассматриваться следующие действия:

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

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

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

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

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

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

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

Хорошо известны следующие требования импорта:

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

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

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

Если применяются несколько ПФБ управления доступом и/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой политики (т.е. применить к нему операцию итерации).

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

Замечания по применению для пользователя

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

Операции

Назначение

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

В FDP_ITC.1.3 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления импортом или указать «Нет» при отсутствии таковых. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/или информационными потоками, выбранным в FDP_ITC.1.1.

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

Замечания по применению для пользователя

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

Операции

Назначение

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

В FDP_ITC.2.5 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления импортом или указать «Нет» при их отсутствии. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/или информационными потоками, выбранным в FDP_ITC.2.1.

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

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

Замечания для пользователя

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

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

Если применяются несколько ПФБ управления доступом и/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой именованной политики (т.е. применить к нему операцию итерации).

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

Операции

Назначение

В FDP_ITT.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, распространяющиеся на передаваемую информацию.

Выбор

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

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

Замечания по применению для пользователя

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

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

Операции

Назначение

В FDP_ITT.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, распространяющиеся на передаваемую информацию.

Выбор

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

Назначение

В FDP_ITT.2.2 автору ПЗ/ЗБ следует специфицировать атрибуты безопасности, по значениям которых ФБО будут определять, когда данные, пересылаемые между физически разделенными частями ОО, требуют разделения. Например, данные пользователя, ассоциированные с идентификатором одного владельца, передаются отдельно от данных, ассоциированных с идентификаторами других владельцев. Тогда для определения необходимости разделения данных при передаче используется значение идентификатора их владельца.

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

Замечания по применению для пользователя

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

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

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

Операции

Назначение

В FDP_ITT.3.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками распространяются на передаваемую и проверяемую на ошибки целостности информацию.

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

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

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

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

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

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

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

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

Операции

Назначение

В FDP_ITT.4.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками распространяются на передаваемую и проверяемую на ошибки целостности информацию.

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

В FDP_ITT.4.1 автору ПЗ/ЗБ следует специфицировать список атрибутов безопасности, требующих разделения каналов передачи. Этот список используется для определения того, какие данные пользователя будут отслеживаться на ошибки целостности на основе атрибутов безопасности данных и каналов передачи данных. Этот элемент прямо зависит от компонента FDP_ITT.2 «Разделение передачи по атрибутам».

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

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

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

Замечания для пользователя

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

Семейство применимо также при попеременном использовании различными субъектами ресурсов в системе. Например, в большинстве операционных систем для поддержки системных процессов обычно используются аппаратные регистры (в качестве ресурсов). Поскольку процессы постоянно переходят из активного состояния в состояние ожидания и обратно, эти регистры попеременно используются различными субъектами. Хотя подобные действия «подкачки» можно не считать занятием или освобождением ресурса, к таким событиям и ресурсам может быть применено семейство FDP_RIP.

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

Важно иметь в виду, что FDP_RIP применяется только к объектам типа on-line, а не off-line (т.е. не к автономным объектам, таким как резервные копии объектов на магнитных лентах). Например, если в ОО удаляется файл, в FDP_RIP может быть отображено требование отсутствия любой остаточной информации при освобождении ресурса; тем не менее, ФБО не могут распространить осуществление этого требования на тот же самый файл, существующий в виде автономной резервной копии. Следовательно, этот файл по-прежнему доступен. Если важно обеспечить недоступность, то автору ПЗ/ЗБ следует удостовериться, что соответствующая цель безопасности для среды отражена в руководстве администратора применительно к автономным объектам.

Семейства FDP_RIP и FDP_ROL могут вступать в конфликт, когда в первом отображено требование уничтожения остаточной информации во время передачи объекта от приложения к функциям безопасности (т.е. при освобождении объекта). Поэтому результат выполнения операции выбора «недоступность при освобождении ресурса» в FDP_RIP нельзя совместить с использованием FDP_ROL из-за возможного отсутствия информации, необходимой для отката в предыдущее состояние. В этом случае в FDP_RIP следует выбрать «недоступность при распределении ресурса», что позволяет использовать FDP_ROL, хотя имеется риск, что ресурс, содержавший информацию, распределен новому объекту до выполнения отката. Если это произойдет, то откат будет невозможен.

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

Это семейство следует применять к объектам, специфицированным в ПФБ управления доступом или информационными потоками автором ПЗ/ЗБ.

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

Замечания по применению для пользователя

Компонент FDP_RIP.1 содержит требование, что ФБО будут обеспечивать для подмножества объектов ОО отсутствие в распределенном этим объектам или освобожденном ими ресурсе доступной остаточной информации.

Операции

Выбор

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

Назначение

В FDP_RIP.1.1 автору ПЗ/ЗБ следует привести список объектов, для которых выполняется защита остаточной информации.

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

Замечания по применению для пользователя

Компонент FDP_RTP.2 содержит требование, что ФБО будут обеспечивать для всех объектов ОО отсутствие в распределенном этим объектам или освобожденном ими ресурсе доступной остаточной информации.

Операции

Выбор

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

Е.10. Откат (FDP_ROL)

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

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

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

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

FDP_ROL.1. Базовый откат

Замечания по применению для пользователя

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

Операции

Назначение

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

В FDP_ROL.1.1 автору ПЗ/ЗБ следует специфицировать список операций, допускающих откат.

В FDP_ROL.1.1 автору ПЗ/ЗБ следует специфицировать список объектов, к которым применима политика отката.

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

FDP_ROL.2. Расширенный откат

Замечания по применению для пользователя

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

Операции

Назначение

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

В FDP_ROL.2.1 автору ПЗ/ЗБ следует специфицировать список объектов, к которым применима политика отката.

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

Е.11. Целостность хранимых данных (FDP_SDI)

Семейство FDP_SDI содержит требования, связанные с защитой данных пользователя во время их хранения в пределах ОДФ.

Замечания для пользователя

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

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

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

FDP_SDI.1. Мониторинг целостности хранимых данных

Замечания по применению для пользователя

Компонент FDP_SDI.1 контролирует появление ошибок целостности данных, хранимых на носителе. Автор ПЗ/ЗБ может специфицировать различные типы атрибутов данных пользователя, на которых будет основан мониторинг.

Операции

Назначение

В FDP_SDI.1.1 автору ПЗ/ЗБ следует специфицировать ошибки целостности, которые будут выявлять ФБО.

В FDP_SDI.1.1 автору ПЗ/ЗБ следует специфицировать атрибуты данных пользователя, которые будут использоваться как основа для мониторинга.

FDP_SDI.2. Мониторинг целостности хранимых данных и предпринимаемые действия.

Замечания по применению для пользователя

Компонент FDP_SDI.2 контролирует появление ошибок целостности данных, хранимых на носителе. Автор ПЗ/ЗБ может специфицировать, какие действия следует предпринять при обнаружении ошибок целостности.

Операции

Назначение

В FDP_SDI.2.1 автору ПЗ/ЗБ следует специфицировать ошибки целостности, которые будут выявлять ФБО.

В FDP_SDI.2.1 автору ПЗ/ЗБ следует специфицировать атрибуты данных пользователя, которые будут использоваться как основа для мониторинга.

В FDP_SDI.2.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении ошибки целостности.

Е.12. Защита конфиденциальности данных пользователя при передаче между ФБО (FDP_UCT)

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

Замечания для пользователя

Это семейство предоставляет требование защиты данных пользователя при передаче. Семейство FPT_ITC, напротив, имеет дело с данными ФБО.

FDP_UCT.1. Базовая конфиденциальность обмена данными

Замечания по применению для пользователя:

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

Операции

Назначение

В FDP_UCT.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, кто и какими данными может обмениваться.

Выбор

В FDP_UCT.1.1 автору ПЗ/ЗБ следует определить, применяется этот элемент к механизму отправления или получения данных пользователя.

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

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

Замечания для пользователя

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

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

FDP_UIT.1. Целостность передаваемых данных

Замечания по применению для пользователя

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

Операции

Назначение

В FDP_UIT.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, кто может отправлять или получать данные и какие именно данные могут быть отправлены или получены.

Выбор

В FDP_UIT.1.1 автору ПЗ/ЗБ следует определить, применять ли этот элемент к ФБО при отправлении или получении объектов.

В FDP_UIT.1.1 автору ПЗ/ЗБ следует определить, защищать ли данные от модификации, удаления, вставки или повторения.

В FDP_UIT.1.2 автору ПЗ/ЗБ следует определить, обнаруживать ли ошибки типа модификации, удаления, вставки или повторения.

FDP_UIT.2. Восстановление переданных данных источником

Замечания по применению для пользователя

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

Операции

Назначение

В FDP_UIT.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, какие данные и каким образом могут восстанавливаться.

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

FDP_UIT.3. Восстановление переданных данных получателем

Замечания по применению для пользователя

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

Операции

Назначение

В FDP_UIT.3.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, какие данные и каким образом могут восстанавливаться.

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

Приложение Ж
(справочное)

ИДЕНТИФИКАЦИЯ И АУТЕНТИФИКАЦИЯ (FIA)

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

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

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

Семейство FIA_UID предназначено для определения идентификатора пользователя.

Семейство FIA_UAU предназначено для верификации идентификатора пользователя.

Семейство FIA_AFL предназначено для определения ограничений на число повторных неуспешных попыток аутентификации.

Семейство FIA_ATD предназначено для определения атрибутов пользователей, применяемых при осуществлении ПБО.

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

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

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

Рисунок Ж.1. Декомпозиция класса «Идентификация и аутентификация»

Ж.1. Отказы аутентификации (FIA_AFL)

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

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

FIA_AFL.1. Обработка отказов аутентификации

Замечания по применению для пользователя

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

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

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

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

Операции

Назначение

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

В FIA_AFL.1.1 автору ПЗ/ЗБ следует специфицировать события аутентификации. Примерами являются: число неуспешных попыток аутентификации для данного идентификатора пользователя с момента последней успешной попытки; число неуспешных попыток аутентификации для данного терминала с момента последней успешной попытки; число неуспешных попыток аутентификации за последние 10 мин. Необходимо указать, по меньшей мере, одно событие аутентификации.

В FIA_AFL.1.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые в случае достижения или превышения предельного значения числа попыток. Такими действиями могут быть: блокирование учетных данных на 5 мин., блокирование терминала на увеличивающийся интервал времени (число n секунд, равное 2 , где n — число неуспешных попыток) или блокирование, с уведомлением администратора, учетных данных вплоть до его снятия администратором. В описании действий следует указать принимаемые меры и срок их действия (или условия прекращения действия этих мер).

Ж.2. Определение атрибутов пользователя (FIA_ATD)

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

Замечания для пользователя

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

FIA_ATD.1. Определение атрибутов пользователя

Замечания по применению для пользователя

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

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

Операции

Назначение

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

Ж.3. Спецификация секретов (FIA_SOS)

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

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

Секреты могут генерироваться самим ОО. В этом случае требование, чтобы сгенерированные ОО секреты соответствовали специфицированной метрике, обеспечивается компонентом FIA_SOS.2.

Замечания для пользователя

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

FIA_SOS.1. Верификация секретов

Замечания по применению для пользователя

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

Операции

Назначение

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

FIA_SOS.2. Генерация секретов ФБО

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

Замечания по применению для пользователя

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

Операции

Назначение

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

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

Ж.4. Аутентификация пользователя (FIA_UAU)

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

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

Замечания по применению для пользователя

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

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

Операции

Назначение

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

FIA_UAU.2. Аутентификация до любых действий пользователя

Замечания по применению для пользователя

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

FIA_UAU.3. Аутентификация, защищенная от подделок

Замечания по применению для пользователя

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

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

Операции

Выбор

В FIA_UAU.3.1 автору ПЗ/ЗБ следует специфицировать, будут ли ФБО обнаруживать и/или предотвращать подделку данных аутентификации.

В FIA_UAU.3.2 автору ПЗ/ЗБ следует специфицировать, будут ли ФБО обнаруживать и/или предотвращать копирование данных аутентификации.

FIA_UAU.4. Механизмы одноразовой аутентификации

Замечания по применению для пользователя

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

Автор ПЗ/ЗБ может определить, к какому механизму(ам) аутентификации применимы эти требования.

Операции

Назначение

В FIA_UAU.4.1 автору ПЗ/ЗБ следует привести список механизмов аутентификации, к которым применяется это требование. Назначением может быть: «все механизмы аутентификации». Примером назначения может быть: «механизмы аутентификации, используемые для аутентификации пользователей во внешней сети».

FIA_UAU.5. Сочетание механизмов аутентификации

Замечания по применению для пользователя

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

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

Для допуска в систему анонимных пользователей можно ввести механизм аутентификации типа «отсутствие аутентификации». Использование доступа такого типа следует четко разъяснить в правилах FIA_UAU.5.2.

Операции

Назначение

В FIA_UAU.5.1 автору ПЗ/ЗБ следует определить предоставляемые механизмы аутентификации. Примером списка механизмов может служить: «отсутствие аутентификации, механизм пароля, биометрия (сканирование сетчатки), механизм ключа шифрования».

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

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

FIA_UAU.6. Повторная аутентификация

Замечания по применению для пользователя

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

Операции

Назначение

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

Автор ПЗ/ЗБ может задать пределы, в которых следует допускать повторную аутентификацию, оставив их детализацию на усмотрение уполномоченного администратора. Пример подобного правила: «пользователь должен проходить повторную аутентификацию не реже одного раза в сутки; администратор может потребовать более частую повторную аутентификацию, но не чаще одного раза в 10 мин.».

FIA_UAU.7. Аутентификация с защищенной обратной связью

Замечания по применению для пользователя

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

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

Операции

Назначение

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

Ж.5. Идентификация пользователя (FIA_UID)

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

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

Замечания по применению для пользователя

Компонент FIA_UID.1 устанавливает требования по идентификации пользователей. Автор ПЗ/ЗБ может указать конкретные действия, которые могут быть выполнены до завершения идентификации.

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

Операции

Назначение

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

FIA_UID.2. Идентификация до любых действий пользователя

Замечания по применению для пользователя

Компонент FIA_UID.2 содержит требование идентификации пользователей. До идентификации пользователя ФБО не допускают выполнение им никаких действий.

Ж.6. Связывание пользователь — субъект (FIA_USB)

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

FIA_USB.1. Связывание пользователь — субъект

Замечания по применению для пользователя

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

Приложение И
(справочное)

УПРАВЛЕНИЕ БЕЗОПАСНОСТЬЮ (FMT)

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

Если ОО состоит из нескольких физически разделенных частей, образующих распределенную систему, то проблемы синхронизации, относящиеся к распространению атрибутов безопасности, данных ФБО и модификации функций становятся очень сложными, особенно когда требуется дублирование информации в различных частях ОО. Эти проблемы следует принять во внимание при выборе компонентов FMT_REV.1 «Отмена» и FMT_SAE.1 «Ограниченная по времени авторизация», поскольку при этом возможно нарушение нормального выполнения ФБО. В такой ситуации рекомендуется воспользоваться компонентами семейства FPT_TRC.

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

Рисунок И.1. Декомпозиция класса «Управление безопасностью»

И.1. Управление отдельными функциями ФБО (FMT_MOF)

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

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

б) функции управления, относящиеся к контролю доступности. Например, определение и модификация параметров доступности или квот ресурсов;

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

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

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

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

FMT_MOF.1. Управление режимом выполнения функций безопасности

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

Операции

Выбор

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

Назначение

В FMT_MOF.1.1 автору ПЗ/ЗБ следует специфицировать функции, которые могут быть модифицированы идентифицированными ролями. Примерами таких функций являются функции аудита или определения времени.

В FMT_MOF.1.1 автору ПЗ/ЗБ следует специфицировать роли, которые допускаются к модификации функций из числа ФБО. Все возможные роли специфицированы в FMT_SMR.1.

И.2. Управление атрибутами безопасности (FMT_MSA)

Семейство FMT_MSA определяет требования по управлению атрибутами безопасности.

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

Существенно, что право на назначение прав пользователям само по себе является атрибутом безопасности и/или потенциальным субъектом управления в компоненте FMT_MSA.1.

Компонент FMT_MSA.2 можно использовать для обеспечения, чтобы выбранное сочетание атрибутов безопасности находилось в рамках безопасного состояния. Определение, что понимать как «безопасное», возлагается на руководства ОО и модель ПБО. Если разработчик предоставил четкое определение безопасных значений и доводы, почему их следует считать безопасными, зависимостью FMT_MSA.2 от ADV_SPM.1 можно пренебречь.

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

FMT_MSA.1. Управление атрибутами безопасности

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

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

Операции

Назначение

В FMT_MSA.1.1 автору ПЗ/ЗБ следует указать ПФБ управления доступом или информационными потоками, для которой применимы атрибуты безопасности.

Выбор

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

Назначение

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

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

В FMT_MSA.1.1 автору ПЗ/ЗБ следует специфицировать роли, которые допущены к операциям с атрибутами безопасности. Все возможные роли специфицированы в FMT_SMR.1.

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

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

Определение, что является «безопасным», в этом компоненте не раскрывается, но оставлено для класса «Разработка» (конкретно, для компонента ADV_SPM.1 «Неформальная модель политики безопасности ОО») и руководств. Примером может служить нетривиальный пароль, назначаемый пользователю при регистрации.

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

Замечания по применению для пользователя

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

Операции

Назначение

В FMT_MSA.3.1 автору ПЗ/ЗБ следует указать ПФБ управления доступом или информационными потоками, для которой применимы атрибуты безопасности.

Выбор

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

Назначение

В FMT_MSA.3.2 автору ПЗ/ЗБ следует специфицировать роли, которые допущены к модификации значений атрибутов безопасности. Все возможные роли специфицированы в FMT_SMR.1.

И.3. Управление данными ФБО (FMT_MTD)

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

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

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

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

Операции

Выбор

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

Назначение

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

В FMT_MTD.1.1 автору ПЗ/ЗБ следует специфицировать, какими данными ФБО могут оперировать идентифицированные роли. Допускается, что автор ПЗ/ЗБ специфицирует возможность управления значениями, задаваемыми по умолчанию.

В FMT_MTD.1.1 автору ПЗ/ЗБ следует специфицировать роли, которые допущены к операциям с данными ФБО. Все возможные роли специфицированы в FMT_SMR.1.

FMT_MTD.2. Управление ограничениями данных ФБО

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

Операции

Назначение

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

В FMT_MTD.2.1 автору ПЗ/ЗБ следует специфицировать роли, которые допущены к модификации как ограничений данных ФБО, так и действий в случае нарушения ограничений. Все возможные роли специфицированы в FMT_SMR.1.

В FMT_MTD.2.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые в случае превышения предельных значений специфицированных данных ФБО. Примером таких действий, выполняемых ФБО, является информирование уполномоченного администратора и генерация записи аудита.

FMT_MTD.3. Безопасные данные ФБО

Компонент FMT_MTD.3 распространяется на требования к значениям, которые могут присваиваться данным ФБО. Следует присваивать такие значения, чтобы ОО оставался в безопасном состоянии.

Определение, что является «безопасным», в этом компоненте не раскрывается, а оставлено для класса «Разработка» (конкретно, для компонента ADV_SPM.1 «Неформальная модель политики безопасности ОО») и руководств. Если разработчик предоставил четкое определение безопасных значений и объяснение, почему их следует считать безопасными, зависимостью FMT_MSA.2 от ADV_SPM.1 можно пренебречь.

И.4. Отмена (FMT_REV)

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

Семейство FMT_REV связано с отменой атрибутов безопасности различных сущностей в пределах ОО.

FMT_REV.1. Отмена

В компоненте FMT_REV.1 специфицируются требования по отмене прав. Он содержит требование спецификации правил отмены, например:

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

б) отмена произойдет при следующей попытке открыть файл;

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

Операции

Выбор

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

Назначение

В FMT_REV.1.1 автору ПЗ/ЗБ следует указать роли, которые допущены к отмене атрибутов безопасности. Все возможные роли специфицированы в FMT_SMR.1.

В FMT_REV.1.2 автору ПЗ/ЗБ следует специфицировать правила отмены. К правилам, в частности, могут быть отнесены: «перед следующей операцией над ассоциированным ресурсом» или «при создании каждого нового субъекта».

И.5. Срок действия атрибутов безопасности (FMT_SAE)

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

FMT_SAE.1. Ограниченная по времени авторизация

Операции

Назначение

В FMT_SAE.1.1 автору ПЗ/ЗБ следует представить список атрибутов безопасности, для которых поддерживается ограничение срока действия. Примером такого атрибута является уровень допуска пользователя.

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

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

И.6. Роли управления безопасностью (FMT_SMR)

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

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

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

Все роли из этого семейства связаны с безопасностью. Каждая роль может предоставлять широкие возможности (например, доступ ко всей структуре UNIX) или незначительные права (например, право чтения объектов единственного типа, таких как файл помощи). Все роли определяются в этом семействе. Возможности ролей определяются в семействах FIA_MOF, FMT_MSA и FMT_MTD.

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

FMT_SMR.1. Роли безопасности

Компонент FMT_SMR.1 определяет различные роли, которые ФБО следует распознавать. В системах часто проводится различие между владельцем сущности, администратором и остальными пользователями.

Операции

Назначение

В FMT_SMR.1.1 автору ПЗ/ЗБ следует специфицировать роли, которые распознаются системой. Это роли, которые могут исполнять пользователи относительно безопасности. Примеры ролей: владелец, аудитор, администратор.

FMT_SMR.2. Ограничения на роли безопасности

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

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

Операции

Назначение

В FMT_SMR.2.1 автору ПЗ/ЗБ следует специфицировать роли, которые распознаются системой. Это роли, которые могут исполнять пользователи относительно безопасности. Примеры ролей: владелец, аудитор, администратор.

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

FMT_SMR.3. Принятие ролей

Компонент FMT_SMR.3 определяет, что для принятия некоторых ролей необходим точный запрос.

Операции

Назначение

В FMT_SMR.3.1 автору ПЗ/ЗБ следует специфицировать роли, для принятия которых требуется точный запрос. Примеры: аудитор и администратор.

Приложение К
(справочное)

ПРИВАТНОСТЬ (FPR)

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

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

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

Рисунок К.1. Декомпозиция класса «Приватность»

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

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

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

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

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

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

К.1. Анонимность (FPR_ANO)

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

Замечания для пользователя

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

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

Хотя идентификатор пользователя не разглашается другим субъектам или пользователям, ФБО прямо не запрещено узнавать идентификатор пользователя. Если не допускается, чтобы ФБО был известен идентификатор пользователя, то можно прибегнуть к компоненту FPR_ANO.2. В этом случае ФБО не разрешается запрашивать информацию о пользователе.

Термин «определить» («determine») следует понимать в самом широком смысле слова. Для конкретизации требований к строгости автор ПЗ/ЗБ может воспользоваться понятием стойкости функций.

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

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

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

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

FPR_ANO.1. Анонимность

Замечания по применению для пользователя

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

Операции

Назначение

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

В FPR_ANO.1.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/или операций, и/или объектов, для которых подлинное имя пользователя данного субъекта следует защитить, например «голосование».

FPR_ANO.2. Анонимность без запроса информации

Замечания по применению для пользователя

Компонент FPR_ANO.2 используется для обеспечения того, что ФБО не будет разрешено знать идентификатор пользователя.

Операции

Назначение

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

В FPR_ANO.2.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/или операций, и/или объектов, для которых подлинное имя пользователя данного субъекта следует защитить, например «голосование».

В FPR_ANO.2.2 автору ПЗ/ЗБ следует идентифицировать список услуг, на которые распространяется требование анонимности, например «доступ к описанию работ».

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

К.2. Псевдонимность (FPR_PSE)

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

Замечания для пользователя

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

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

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

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

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

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

Следует иметь в виду, что наиболее строгие компоненты этого семейства могут потенциально не сочетаться с другими возможными требованиями, такими как идентификация и аутентификация или аудит. Выражение «определить идентификатор» следует понимать в широком смысле: ФБО не предоставляют информацию при выполнении операции; нельзя определить создателя субъекта или владельца субъекта, вызвавшего операцию; ФБО не будут записывать такую информацию, доступную пользователям или субъектам, по которой в дальнейшем можно бы было узнать идентификатор пользователя.

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

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

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

FPR_PSE.1. Псевдонимность

Замечания по применению для пользователя

Компонент FPR_PSE.1 обеспечивает защиту пользователя от раскрытия его идентификатора другими пользователями. При этом пользователь останется ответственным за свои действия.

Операции

Назначение

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

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

В FPR_PSE.1.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

В FPR_PSE.1.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, которым ФБО способны предоставлять псевдонимы.

Выбор

В FPR_PSE.1.3 автору ПЗ/ЗБ следует специфицировать, создаются псевдонимы функциями безопасности ОО или выбираются самими пользователями.

Назначение

В FPR_PSE.1.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

FPR_PSE.2. Обратимая псевдонимность

Замечания по применению для пользователя

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

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

Операции

Назначение

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

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

В FPR_PSE.2.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

В FPR_PSE.2.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, которым ФБО способны предоставлять псевдонимы.

Выбор

В FPR_PSE.2.3 автору ПЗ/ЗБ следует специфицировать, создаются псевдонимы функциями безопасности ОО или выбираются самими пользователями.

Назначение

В FPR_PSE.2.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

Выбор

В FPR_PSE.2.4 автору ПЗ/ЗБ следует идентифицировать, могут ли уполномоченный пользователь и/или доверенные субъекты определить подлинное имя пользователя.

Назначение

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

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

FPR_PSE.3. Альтернативная псевдонимность

Замечания по применению для пользователя

В компоненте FPR_PSE.3 ФБО должны обеспечить, чтобы предоставленная ссылка отвечала определенным правилам ее создания и вследствие этого могла использоваться потенциально опасными субъектами без нарушения безопасности.

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

Операции

Назначение

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

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

В FPR_PSE.3.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

В FPR_PSE.3.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, которым ФБО способны предоставлять псевдонимы.

Выбор

В FPR_PSE.3.3 автору ПЗ/ЗБ следует специфицировать, создаются псевдонимы функциями безопасности ОО или выбираются самими пользователями.

Назначение

В FPR_PSE.3.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

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

К.3. Невозможность ассоциации (FPR_UNL)

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

Замечания для пользователя

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

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

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

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

Примерами потенциально враждебных субъектов или пользователей являются провайдеры, системные операторы, абоненты связи и пользователи, скрытно вводящие в систему опасные элементы (например, «троянских коней»). Сами они не выполняют операции в системе, но стремятся получить информацию об операциях. Все они могут изучать образ действий пользователей (например, какие пользователи какие услуги заказывают) и злоупотреблять этой информацией. Невозможность ассоциации защищает пользователей от сопоставления, которое может быть произведено между различными действиями потребителя. Например, серия телефонных вызовов, сделанных анонимным потребителем по различным номерам, может дать информацию для раскрытия его идентификатора по сочетанию номеров.

FPR_UNL.1. Невозможность ассоциации

Замечания по применению для пользователя

Компонент FPR_UNL.1 обеспечивает, чтобы пользователи не могли связывать между собой различные операции в системе и таким образом получать информацию.

Операции

Назначение

В FPR_UNL.1.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

В FPR_UNL.1.1 автору ПЗ/ЗБ следует идентифицировать список операций, на которые следует распространить требование невозможности ассоциации, например «отправка электронной почты».

Выбор

В FPR_UNL.1.1 автору ПЗ/ЗБ следует выбрать взаимосвязи, которые следует скрыть. Этот выбор позволяет специфицировать либо идентификатор пользователя, либо операцию назначения списка соотношений.

Назначение

В FPR_UNL.1.1 автору ПЗ/ЗБ следует идентифицировать список соотношений, которые следует защищать, например «посланные с одного и того же терминала».

К.4. Скрытность (FPR_UNO)

Семейство FPR_UNO обеспечивает, чтобы пользователь мог использовать ресурс или услугу без предоставления кому-либо, в особенности третьей стороне, возможности знать об использовании ресурса или услуги.

Замечания для пользователя

Подход к защите идентификатора пользователя в этом семействе отличает его от остальных семейств данного класса. Скрывается факт использования ресурса или услуги, а не идентификатор пользователя.

Для реализации скрытности могут быть применены различные методы. Примеры некоторых из них приведены ниже:

а) размещение информации, повышающее скрытность. Информацию, которую необходимо скрыть (например, указывающую на выполнение операции), можно разместить в ОО различными способами. Место ее размещения в ОО можно выбирать случайно, так, чтобы нарушитель не знал, какую именно часть ОО следует атаковать. Данную информацию можно распределить таким образом, чтобы ни в одной части ОО ее не было достаточно для нарушения приватности пользователя. Этот способ рассматривается в компоненте FPR_UNO.2;

б) массовое распространение информации (по локальной сети, по радио). Пользователи не могут определить, кому конкретно послана данная информация, и кто в действительности станет ее использовать. Этот метод особенно полезен, когда информацию следует довести до того, кто опасается показывать свою заинтересованность в данной информации (например, чувствительной медицинской информации);

в) криптографическая защита и дополнение сообщений незначащей информацией. Путем наблюдения за потоком сообщений можно извлечь информацию из самого факта передачи сообщения и его атрибутов. Защиту передаваемых сообщений и их атрибутов можно обеспечить посредством дополнения трафика и самих сообщений незначащей информацией или шифрования.

Иногда пользователей не следует допускать к наблюдению за использованием ресурсов, а уполномоченным пользователям такое наблюдение необходимо для исполнения своих обязанностей. В таком случае может применяться компонент FPR_UNO.4, который предоставляет эту возможность одному или нескольким уполномоченным пользователям.

В этом семействе используется понятие «часть ОО». Под ней подразумевается какая-либо часть ОО, отделенная физически или логически от других частей ОО. В случае логического отделения может быть уместно применение семейства FPT_SEP.

Скрытность связей может быть важным фактором во многих областях, таких как осуществление конституционных прав, политика организации или приложения, связанные с оборонными вопросами.

FPR_UNO.1. Скрытность

Замечания по применению для пользователя

Компонент FPR_UNO.1 содержит требования недопустимости наблюдения неуполномоченными пользователями за использованием услуги или ресурса. Дополнительно к этому компоненту автору ПЗ/ЗБ может потребоваться «Анализ скрытых каналов».

Операции

Назначение

В FPR_UNO.1.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

Для FPR_UNO.1.1 автору ПЗ/ЗБ следует идентифицировать список операций, на которые распространяется требование скрытности. Тогда другие пользователи/субъекты не смогут наблюдать за указанными в списке операциями над специфицированными ниже объектами (например, за чтением и записью на объекте).

Для FPR_UNO.1.1 автору ПЗ/ЗБ следует идентифицировать список объектов, на которые распространяется требование скрытности. Примером может быть конкретный сервер электронной почты или FTP-сайт.

В FPR_UNO.1.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, скрытность информации которых будет обеспечиваться. Примером может быть: «пользователи, получившие доступ к системе через Интернет».

FPR_UNO.2. Распределение информации, влияющее на скрытность

Замечания по применению для пользователя

Компонент FPR_UNO.2 содержит требования недопустимости наблюдения определенными пользователями за использованием услуги или ресурса. Кроме этого, в нем определяется, какая информация, связанная с приватностью пользователя, распределяется в ОО таким образом, чтобы нарушитель не мог установить, в какой именно части ОО она содержится, или был вынужден атаковать несколько частей ОО.

Примером использования этого компонента является случайный выбор узла для предоставления услуги. В этом случае в компоненте может быть установлено требование, что информация, связанная с приватностью пользователя, должна быть доступна только в одной идентифицированной части ОО, не распространяясь за ее пределы.

Более сложный пример связан с некоторыми «алгоритмами голосования». В предоставлении услуги принимают участие несколько частей ОО, но никакая отдельная часть не сможет нарушить принятую политику. Какое-либо лицо может принять (или не принять) участие в голосовании; при этом невозможно определить результат голосования и его участие в голосовании (если голосование было анонимным).

Дополнительно к этому компоненту автору ПЗ/ЗБ может потребоваться «Анализ скрытых каналов».

Операции

Назначение

В FPR_UNO.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

Для FPR_UNO.2.1 автору ПЗ/ЗБ следует идентифицировать список операций, на которые распространяется требование скрытности. Тогда другие пользователи/субъекты не смогут наблюдать за указанными в списке операциями над специфицированными ниже объектами (например, за чтением и записью на объекте).

Для FPR_UNO.2.1 автору ПЗ/ЗБ следует идентифицировать список объектов, на которые распространяется требование скрытности. Примером может быть конкретный сервер электронной почты или FTP-сайт.

В FPR_UNO.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, скрытность информации которых будет обеспечиваться, например «пользователи, получившие доступ к системе через Интернет».

Для FPR_UNO.2.2 автору ПЗ/ЗБ следует идентифицировать, распределение какой информации, связанной с приватностью, следует контролировать. Примером такой информации являются IP-адрес субъекта, IP-адрес объекта, время, используемые криптографические ключи.

Для FPR_UNO.2.2 автору ПЗ/ЗБ следует специфицировать, каким условиям следует соответствовать распределению указанной информации. Эти условия следует поддерживать все время существования приватной информации пользователя в каждом случае. Примерами таких условий могут быть: «информация должна быть представлена только в одной из разделенных частей ОО и не должна передаваться за ее пределы»; «информация должна пребывать только в одной из разделенных частей ОО, но должна передаваться в другие его части периодически»; «информация должна распределяться между различными частями ОО таким образом, чтобы нарушение защиты любых пяти отдельных частей ОО не приводило к нарушению политики безопасности в целом».

FPR_UNO.3. Скрытность без запроса информации

Замечания по применению для пользователя

Компонент FPR_UNO.3 применяется для требования, чтобы ФБО не стремились получить информацию, которая может нарушить скрытность при предоставлении определенных услуг. Поэтому ФБО не будут запрашивать (т.е. стремиться получить из других источников) информацию, которая может быть использована для нарушения скрытности.

Операции

Назначение

В FPR_UNO.3.1 автору ПЗ/ЗБ следует идентифицировать список услуг, на которые распространяется требование скрытности, например «доступ к описанию работ».

В FPR_UNO.3.1 автору ПЗ/ЗБ следует идентифицировать список субъектов, от которых при получении специфицированных услуг следует защищать информацию, связанную с приватностью.

В FPR_UNO.3.1 автору ПЗ/ЗБ следует специфицировать информацию, связанную с приватностью, которая будет защищена от специфицированных субъектов. Это может быть идентификатор субъекта, получающего услугу, или характеристики полученной услуги, например использованный ресурс памяти.

FPR_UNO.4. Открытость для уполномоченного пользователя

Замечания по применению для пользователя

Компонент FPR_UNO.4 применяется для предоставления права наблюдения за использованием ресурсов одному или нескольким уполномоченным пользователям. Без этого компонента возможность наблюдения допускается, но не является обязательной.

Операции

Назначение

В FPR_UNO.4.1 автору ПЗ/ЗБ следует специфицировать совокупность уполномоченных пользователей, которым ФБО необходимо предоставить возможность наблюдения за использованием ресурсов. Это может быть, например, группа уполномоченных пользователей, исполняющих одну и ту же роль или использующих один и тот же процесс.

В FPR_UNO.4.1 автору ПЗ/ЗБ следует специфицировать список ресурсов и/или услуг, возможность наблюдения за которыми необходима уполномоченному пользователю.

Приложение Л
(справочное)

ЗАЩИТА ФБО (FPT)

Класс FPT содержит семейства функциональных требований, которые связаны с целостностью и управлением механизмами, реализованными в ФБО, не завися при этом от особенностей ПБО, а также с целостностью данных ФБО, не завися от специфического содержания данных ПБО. В некотором смысле компоненты семейств этого класса дублируют компоненты из класса FDP и могут даже использовать одни и те же механизмы. Однако класс FDP специализирован на защите данных пользователя, в то время как класс FPT нацелен на защиту данных ФБО. Фактически компоненты из класса FPT необходимы для реализации требований невозможности нарушения и обхода политик ФБ данного ОО.

В рамках этого класса выделяются три существенные составные части ФБО:

а) абстрактная машина ФБО, т.е. виртуальная или физическая машина, на которой выполняется оцениваемая реализация ФБО;

б) реализация ФБО, которая выполняется на абстрактной машине и реализует механизмы, осуществляющие ПБО;

в) данные ФБО, которые являются административными базами данных, управляющими осуществлением ПБО.

Все семейства в классе FPT можно связать с этими тремя частями и сгруппировать следующим образом:

г) FPT_PHP «Физическая защита ФБО» предоставляет уполномоченному пользователю возможность обнаружения внешних атак на те части ОО, которые реализуют ФБО;

д) FPT_AMT «Тестирование базовой абстрактной машины» и FPT_TST «Самотестирование ФБО» предоставляют уполномоченному пользователю возможность верифицировать правильность операций базовой абстрактной машины и ФБО, а также целостность данных и выполняемого кода ФБО;

е) FPT_SEP «Разделение домена» и FPT_RVM «Посредничество при обращениях» защищают ФБО во время их выполнения и обеспечивают невозможность обхода ФБО. Когда соответствующие компоненты этих семейств сочетаются с соответствующими компонентами семейства ADV_INT «Внутренняя структура ФБО», можно говорить о наличии в ОО традиционного «монитора обращений»;

ж) FPT_RCV «Надежное восстановление», FPT_FLS «Безопасность при сбое» и FPT_TRC «Согласованность данных ФБО при дублировании в пределах ОО» определяют режим выполнения ФБО при возникновении сбоя и непосредственно после него;

и) FPT_ITA «Доступность экспортируемых данных ФБО», FPT_ITC «Конфиденциальность экспортируемых данных ФБО» и FPT_ITI «Целостность экспортируемых данных ФБО» определяют защиту и доступность данных ФБО при их обмене между ФБО и удаленным доверенным продуктом ИТ;

к) FPT_ITT «Передача данных ФБО в пределах ОО» предназначено для защиты данных ФБО при их передаче между физически разделенными частями ОО;

л) FPT_RPL «Обнаружение повторного использования» содержит требование защиты от повторного использования различных типов информации и/или операций;

м) FPT_SSP «Протокол синхронизации состояний» определяет синхронизацию состояний между различными частями распределенных ФБО на основе данных ФБО;

н) FPT_STM «Метки времени» предоставляет надежные метки времени;

п) FPT_TDC «Согласованность данных ФБО между ФБО» предназначено для согласования данных между ФБО и удаленным доверенным продуктом ИТ.

Декомпозиция класса FPT на составляющие его компоненты приведена на рисунках Л.1 и Л.2.

Рисунок Л.1. Декомпозиция класса «Защита ФБО»

Рисунок Л.2. Декомпозиция класса «Защита ФБО» (продолжение)

Л.1. Тестирование базовой абстрактной машины (FPT_AMT)

Семейство FPT_AMT определяет требования к выполнению тестирования ФБО, демонстрирующего предположения безопасности относительно базовой абстрактной машины, лежащей в основе построения ФБО. «Абстрактная» машина может быть как платформой аппаратных/программно-аппаратных средств, так и некоторым известным и прошедшим оценку сочетанием аппаратных/программных средств, действующим как виртуальная машина. В качестве примеров такого тестирования можно указать проверку аппаратной защиты, посылку типовых пакетов по сети для проверки получения, верификацию режима функционирования виртуального машинного интерфейса и т.д. Эти тесты могут выполняться при некотором поддерживаемом состоянии, при запуске, по запросу или постоянно. Действия, предпринимаемые с использованием ОО по результатам тестирования, определены в FPT_RCV.

Замечания для пользователя

Термин «базовая абстрактная машина» относится главным образом к аппаратуре, реализующей ФБО. Однако его можно отнести и к предварительно оцененной базовой комбинации аппаратных средств и программного обеспечения, ведущей себя как виртуальная машина, на которой реализованы ФБО.

Тесты абстрактной машины могут иметь различные формы:

а) тесты при включении, которые проверяют правильность работы платформы. Для аппаратных и программно-аппаратных средств они могут включать в себя тесты таких элементов, как платы памяти, маршруты передачи данных, шины, управляющие элементы, регистры процессора, порты сообщений, интерфейсы консолей, звуковоспроизводящие и периферийные устройства. Для программных элементов (виртуальной машины) они включают в себя верификацию корректности инициализации и режима функционирования;

б) загружаемые тесты, которые могут загружаться и выполняться уполномоченным пользователем или активизироваться при определенных условиях. Они могут включать в себя тесты нагрузки элементов процессора (логических элементов, вычислительных элементов и т.д.) и управляемой памяти.

Замечания для оценщика

Следует, чтобы тесты базовой абстрактной машины были достаточны для проверки всех характеристик базовой абстрактной машины, на которой выполняются ФБО.

FPT_AMT.1. Тестирование абстрактной машины

Замечания по применению для пользователя

Компонент FPT_AMT.1 поддерживает периодическое тестирование предположений безопасности базовой абстрактной машины, от которых зависит выполнение ФБО, требуя обеспечения возможности периодического запуска тестирования функций.

При желании автор ПЗ/ЗБ может уточнить требование, указав, в каком режиме следует проводить тестирование: автономно, при обычном функционировании системы или в режиме аварийной поддержки.

Замечания по применению для оценщика

Допускается, чтобы функции периодического тестирования были доступны только в автономном режиме или режиме аварийной поддержки. Следует иметь средства управления для предоставления доступа в режиме аварийной поддержки только уполномоченным пользователям.

Операции

Выбор

В FPT_AMT.1.1 автору ПЗ/ЗБ следует специфицировать, когда ФБО будут выполнять тестирование абстрактной машины: при запуске, периодически во время нормального функционирования, по запросу уполномоченного пользователя, при других условиях. В последнем случае следует уточнить, какие это условия. С помощью этой операции выбора автор ПЗ/ЗБ имеет возможность указать также периодичность выполнения самотестирования. Более частое тестирование даст пользователю большую уверенность в правильном функционировании ОО. Однако необходимо выбрать правильное соотношение между предоставлением уверенности и потенциальным уменьшением доступности ОО, поскольку слишком частое тестирование может замедлить нормальное функционирование ОО.

Л.2. Безопасность при сбое (FPT_FLS)

Требования семейства FPT_FLS обеспечивают, чтобы ОО не нарушал свою политику безопасности при сбоях ФБО идентифицированных типов.

FPT_FLS.1. Сбой с сохранением безопасного состояния

Замечания по применению для пользователя

Термин «безопасное состояние» относится к состоянию, при котором данные ФБО непротиворечивы и ФБО продолжают корректное осуществление ПБО. «Безопасное состояние» определяется в модели ПБО. Если разработчик предоставил четкое определение безопасного состояния и разъяснение, когда его следует считать таковым, зависимость FPT_FLS.1 от ADV_SPM.1 можно не учитывать.

Хотя при сбоях с сохранением безопасного состояния желательно проведение аудита, это возможно не во всех ситуациях. Автору ПЗ/ЗБ следует специфицировать те ситуации, при которых проведение аудита желательно и выполнимо.

Сбои ФБО могут включать в себя аппаратные отказы, которые указывают на нарушение режима работы оборудования и требуют аварийной поддержки или восстановления ФБО. Сбои ФБО могут включать в себя также устранимые программные отказы, после которых требуется только инициализация или повторный запуск ФБО.

Операции

Назначение

Для FPT_FLS.1.1 автору ПЗ/ЗБ следует привести список типов сбоев ФБО, при которых следует, чтобы ФБО «сбились безопасно», т.е. сохранили безопасное состояние и продолжали корректно осуществлять ПБО.

Л.3. Доступность экспортируемых данных ФБО (FPT_ITA)

Семейство FPT_ITA определяет правила предотвращения потери доступности данных ФБО, передаваемых между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

Замечания по применению для пользователя

Это семейство используется в распределенных системах, когда ФБО представляют свои данные удаленному доверенному продукту ИТ. ФБО могут предпринять меры безопасности лишь со своей стороны и не могут нести ответственность за ФБО другого доверенного продукта ИТ.

Если имеется несколько различных метрик доступности для разных типов данных ФБО, этот компонент следует повторить для каждой отдельной пары «метрика — тип данных ФБО».

FPT_ITA.1. Доступность экспортируемых данных ФБО в пределах заданной метрики

Операции

Назначение

Для FPT_ITA.1. автору ПЗ/ЗБ следует специфицировать типы данных ФБО, на которые распространяется метрика доступности.

Для FPT_ITA.1.1 автору ПЗ/ЗБ следует специфицировать метрику доступности для соответствующих данных ФБО.

Для FPT_ITA.1.1 автору ПЗ/ЗБ следует специфицировать условия, при которых необходимо обеспечить доступность. Это, например, может быть наличие связи между ОО и удаленным доверенным продуктом ИТ.

Л.4. Конфиденциальность экспортируемых данных ФБО (FPT_ITC)

Семейство FPT_ITC определяет правила защиты данных ФБО от несанкционированного раскрытия при передаче между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

Замечания по применению для пользователя

Это семейство используется в распределенных системах, когда ФБО представляют свои данные удаленному доверенному продукту ИТ. ФБО могут предпринять меры безопасности лишь в своей области действия и не могут нести ответственность за ФБО другого доверенного продукта ИТ.

FPT_ITC.1. Конфиденциальность экспортируемых данных ФБО при передаче

Замечания по применению для оценщика

Конфиденциальность данных ФБО во время передачи необходима для их защиты от раскрытия. Возможные способы обеспечения конфиденциальности включают в себя применение криптографии, а также других методов, выбор которых постоянно расширяется.

Л.5. Целостность экспортируемых данных ФБО (FPT_ITI)

Семейство FPT_ITI определяет правила защиты данных ФБО от несанкционированной модификации при передаче между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

Замечания для пользователя

Это семейство используется в распределенных системах, когда ФБО представляют свои данные удаленному доверенному продукту ИТ. Отметим, что требования, связанные с модификацией, обнаружением или восстановлением и относящиеся к удаленному доверенному продукту ИТ, невозможно специфицировать, поскольку заранее не известны механизмы, которые будут использованы в удаленном доверенном продукте ИТ. Поэтому эти требования выражены в терминах «предоставления ФБО возможности», которую может использовать удаленный доверенный продукт ИТ.

FPT_ITI.1. Обнаружение модификации экспортируемых данных ФБО

Замечания по применению для пользователя

Компонент FPT_ITI.1 следует использовать в ситуациях, когда достаточно обнаружить, что данные модифицированы. Примером является ситуация, когда у удаленного доверенного продукта ИТ имеется возможность запросить ФБО о повторении передачи данных при обнаружении их модификации или удовлетворить аналогичный запрос.

Желательная стойкость функции обнаружения модификации основана на определенной метрике модификации, которая зависит от используемого алгоритма и может находиться в диапазоне от простых контрольных сумм и проверки на четность, которые не обнаруживают простые комбинации изменений в нескольких разрядах, до более сложных криптографических контрольных сумм.

Операции

Назначение

Для FPT_ITI.1.1 автору ПЗ/ЗБ следует специфицировать метрику модификации, удовлетворение которой необходимо для механизма обнаружения. Эта метрика должна определить желательную стойкость функции обнаружения модификации.

Для FPT_ITI.1.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении модификации данных ФБО. Примером таких действий может служить: «игнорировать полученные данные ФБО и запросить у доверенного продукта, являющегося отправителем, повторную передачу данных ФБО».

FPT_ITI.2. Обнаружение и исправление модификации экспортируемых данных ФБО

Замечания по применению для пользователя

Компонент FPT_ITI.2 следует использовать в ситуациях, когда требуется обнаружить или исправить модификации критичных данных ФБО.

Желательная стойкость функции обнаружения модификации основана на определенной метрике модификаций, которая зависит от используемого алгоритма и может находиться в диапазоне от контрольных сумм и проверки на четность, которые могут не обнаружить простые комбинации изменений в нескольких разрядах, до более сложных криптографических контрольных сумм. Метрику, которую требуется определить, можно связать либо с отражением атак (например, будет пропускаться только одно из тысячи случайных сообщений), либо с приведенным в открытой литературе механизмом (например, необходимо, чтобы требуемая стойкость соответствовала стойкости алгоритма безопасного хэширования).

Подход к исправлению модификаций может быть основан на использовании некоторых видов контрольных сумм, позволяющих корректировать ошибки.

Замечания по применению для оценщика

Возможные способы удовлетворения этих требований состоят в использовании криптографических функций или некоторых видов контрольных сумм.

Операции

Назначение

Для FPT_ITI.2.1 автору ПЗ/ЗБ следует специфицировать метрику модификации, удовлетворение которой необходимо для механизма обнаружения. Эта метрика должна определить желательную стойкость функции обнаружения модификации.

Для FPT_ITI.1.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении модификации данных ФБО. Примером таких действий может служить: «игнорировать полученные данные ФБО и запросить у доверенного продукта, являющегося отправителем, повторную передачу данных ФБО».

Для FPT_ITI.2.3 автору ПЗ/ЗБ следует определить типы модификаций, после которых ФБО следует предоставить возможность восстановления.

Л.6. Передача данных ФБО в пределах ОО (FPT_ITT)

Семейство FPT_ITT предоставляет требования защиты данных ФБО при их передаче между разделенными частями ОО по внутреннему каналу.

Замечания для пользователя

Принятие решения о степени физического или логического разделения, в условиях которого могло бы применяться это семейство, зависит от предполагаемой среды эксплуатации. В неблагоприятной среде могут возникать риски, связанные с передачей между частями ОО, разделенными всего лишь системной шиной. В более благоприятной среде для передачи можно использовать обычные сетевые средства.

Замечания для пользователя

Один из механизмов, практически применяемых для реализации функциями безопасности ОО этого вида защиты, основан на применении криптографических методов.

FPT_ITT.1. Базовая защита внутренней передачи данных ФБО

Операции

Выбор

В FPT_ITT.1.1 автору ПЗ/ЗБ следует специфицировать требуемый тип защиты, предоставляя ее от раскрытия или модификации.

FPT_ITT.2. Разделение данных ФБО при передаче

Замечания по применению для пользователя

Одним из путей выполнения разделения каналов, основанного на атрибутах, относящихся к ПФБ, является использование разделенных логических или физических каналов.

Операции

Выбор

В FPT_ITT.2.1 автору ПЗ/ЗБ следует специфицировать требуемый тип защиты, предоставляя ее от раскрытия или модификации.

FPT_ITT.3. Мониторинг целостности данных ФБО

Операции

Выбор

В FPT_ITT.3.1 автору ПЗ/ЗБ следует специфицировать, какой тип модификации должны быть способны обнаруживать ФБО, выбирая из следующих типов: модификация данных, подмена данных, перестановка данных, удаление данных или какие-либо иные ошибки целостности.

Назначение

В FPT_ITT.3.1 в случае выбора автором ПЗ/ЗБ последнего варианта нз предыдущего абзаца, ему следует также специфицировать, какие иные ошибки целостности ФБО следует обнаруживать.

В FPT_ITT.3.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении ошибки целостности.

Л.7. Физическая защита ФБО (FPT_PHP)

Компоненты семейства FPT_PHP дают возможность ограничивать физический доступ к ФБО, а также реагировать на несанкционированную физическую модификацию или подмену реализации ФБО и противодействовать им.

Требования компонентов в этом семействе обеспечивают, чтобы ФБО были защищены от физического воздействия и вмешательства. Удовлетворение требований этих компонентов позволяет получить реализацию ФБО, компонуемую и используемую способом, предусматривающим обнаружение физического воздействия или противодействие ему. Без этих компонентов защита ФБО теряет свою эффективность в среде, где не может быть предотвращено физическое повреждение. Это семейство также содержит требования к реакции ФБО на попытки физического воздействия на их реализацию.

Примерами сценариев физического воздействия являются нападения с использованием механических средств, радиоактивного излучения, изменения температуры.

Замечания для пользователя

Допускается, чтобы функции обнаружения физических нападений были доступны уполномоченному пользователю только в автономном режиме или режиме аварийной поддержки. Следует предусмотреть средства ограничения доступа в этих режимах, предоставляя его только уполномоченным пользователям. Поскольку в этих режимах ФБО могут оказаться «невыполнимыми», это может помешать нормальному осуществлению доступа уполномоченных пользователей. Физически ОО может состоять из устройств различного типа, например из экранирующего корпуса, плат и микросхем. Необходимо, чтобы эта совокупность «элементов» защищала ФБО от физического вмешательства (а также оповещала о нем и противодействовала ему). Это не означает, что эти качества необходимы всем устройствам по отдельности, но следует, чтобы их имело физическое воплощение ОО в целом.

Хотя с этими компонентами ассоциирован только минимальный аудит, это сделано исключительно потому, что потенциально механизмы обнаружения и оповещения могут быть реализованы полностью аппаратно, на уровне взаимодействий, более низком, чем управление подсистемой аудита (например, это может быть система обнаружения на аппаратном уровне, реагирующая на разрыв цепи и подающая световой сигнал, если цепь разорвана в момент нажатия кнопки уполномоченным пользователем). Тем не менее, автор ПЗ/ЗБ может определить, что для некоторых угроз, исходящих от среды, требуется аудит физических нападений. В этом случае автору ПЗ/ЗБ следует включить в список событий аудита соответствующие требования. Необходимо иметь в виду, что наличие этих требований может повлиять на конструкцию аппаратуры и ее взаимодействие с программным обеспечением.

FPT_PHP.1. Пассивное обнаружение физического нападения

Замечания по применению для пользователя

Компонент FPT_PHP.1 следует применять, когда угрозам несанкционированного физического воздействия на части ОО не противопоставлены процедурные методы. В этом компоненте рассматривается угроза, что физическое воздействие на ФБО может и не быть выявлено. Обычно задача верификации того, что нападение имело место, возлагается на уполномоченного пользователя. Как уже сказано, этот компонент всего лишь представляет способность ФБО обнаруживать физическое воздействие, поэтому требуется зависимость от FMT_MOF.1, чтобы специфицировать, кто и каким образом может воспользоваться этой способностью. Если эта функция реализована с помощью механизма, не связанного с ИТ (например, путем физической проверки), то может быть указано, что зависимость от FMT_MOF.1 не удовлетворяется.

FPT_PHP.2. Оповещение о физическом нападении

Замечания по применению для пользователя

Компонент FPT_PHP.2 следует применять, когда угрозам несанкционированного физического воздействия на части ОО не противопоставлены процедурные методы, и при этом требуется оповещение определенных лиц о физическом нападении. В этом компоненте рассматривается угроза, что физическое воздействие на элементы ФБО может быть хотя и выявлено, но не замечено (т.е. о нем никто не оповещен).

Операции

Назначение

Для FPT_PHP.2.3 автору ПЗ/ЗБ следует предоставить список устройств/элементов, реализующих ФБО, для которых требуется активное обнаружение физического воздействия.

Для FPT_PHP.2.3 автору ПЗ/ЗБ следует указать пользователя или роль, уведомляемую об обнаружении физического воздействия. Тип пользователя или роли могут меняться на итерациях компонента управления безопасностью FMT_MOF.1, включенного в ПЗ/ЗБ.

FPT_PHP.3. Противодействие физическому нападению

Для некоторых типов воздействия требуется, чтобы ФБО не только обнаруживали воздействие, но и фактически противодействовали ему или задерживали напавшего.

Замечания по применению для пользователя

Компонент FPT_PHP.3 следует использовать, когда устройства и элементы, реализующие ФБО, предназначены для эксплуатации в среде, где физическое воздействие (например, с целью наблюдения, анализа или модификации) на составляющие устройств, реализующих ФБО, или же на элементы, реализующие ФБО, само по себе признано угрозой.

Операции

Назначение

Для FPT_PHP.3.1 автору ПЗ/ЗБ следует специфицировать для списка устройств/элементов, реализующих ФБО, сценарии физического проникновения; ФБО следует противодействовать физическому проникновению, выполняемому по этим сценариям. Этот список может относиться к определенному подмножеству физических устройств и элементов, реализующих ФБО, выделенному на основе учета технологических ограничений и физической незащищенности прибора. Выделение такого подмножества следует четко определить и строго обосновать. Кроме того, ФБО следует реагировать на попытки физического проникновения автоматически. При автоматической реакции на физическое проникновение следует сохранять политику устройства, например, если проводится политика конфиденциальности, то прибор был бы физически отключен для того, чтобы защищаемая информация не могла быть считана.

Для FPT_PHP.3.1 автору ПЗ/ЗБ следует специфицировать список устройств/элементов, реализующих ФБО, для которых ФБО следует противодействовать физическому проникновению согласно идентифицированным сценариям.

Л.8. Надежное восстановление (FPT_RCV)

Требования семейства FPT_RCV обеспечивают, чтобы ФБО могли определить, не нарушена ли защита ФБО при запуске, и восстанавливаться без нарушения защиты после прерывания операций. Это семейство важно, потому что начальное состояние ФБО при запуске или восстановлении определяет защищенность ОО в последующем.

Компоненты данного семейства позволяют устанавливать безопасное состояние ФБО или предотвращать их переход в опасное состояние после сбоев, прерывания функционирования или перезапуска. В число возможных сбоев обычно включают:

а) сбои, которые всегда приводят к аварийным отказам системы (например, устойчивая несогласованность критичных системных таблиц; неуправляемые переходы в коде ФБО, вызванные сбоями аппаратных или программно-аппаратных средств; сбои питания, процессора, связи);

б) сбои носителей, приводящие к тому, что часть носителя или весь носитель, представляющий объекты ФБО, становится недоступным или неисправным (например, ошибки четности, неисправность головок дисков, устойчивый сбой чтения/записи, неточная юстировка головок дисков, износ магнитного покрытия, запыленность поверхности диска);

в) прерывание функционирования вследствие ошибочных действий администратора или отсутствия его своевременных действий (например, неожиданное прекращение работы из-за неподготовленности к отключению питания, игнорирование перерасхода критичных ресурсов, неадекватная инсталлированная конфигурация).

Важно отметить, что восстановление может быть предусмотрено для сценария как частичного, так и полного отказа. Полный отказ может возникнуть в неразделенной операционной системе, в распределенной среде его вероятность меньше. В такой среде некоторые подсистемы могут отказать, в то время как другие части останутся работающими. Более того, критичные элементы могут иметь избыточность (дублирование дисков, альтернативные маршруты) и точки проверки. Под восстановлением имеется в виду восстановление безопасного состояния.

Семейство FPT_RCV идентифицирует режим аварийной поддержки. В этом режиме нормальное функционирование может оказаться невозможным или сильно ограниченным из-за возможности перехода в опасное состояние. В таких случаях обычно доступ разрешается только уполномоченным пользователям, а более конкретно, кто может получить доступ в режиме аварийной поддержки, определяется в классе FMT «Управление безопасностью». Если в классе FMT нет никаких указаний о том, кто имеет право доступа в этом режиме, теоретически допускается, что восстановить систему может любой пользователь. Однако на практике это нежелательно, поскольку пользователь, восстанавливающий систему, может установить конфигурацию ОО, нарушающую ПБО.

Механизмы, предназначенные для обнаружения исключительных состояний при эксплуатации, определяются в FPT_TST «Самотестирование ФБО», FPT_FLS «Безопасность при сбое» и в других разделах, относящихся к проблеме «Сохранность программного обеспечения».

Замечания для пользователя

В этом семействе применяется выражение «безопасное состояние». Оно относится к состоянию, при котором данные ФБО непротиворечивы и продолжают корректное осуществление ПБО. Это состояние может быть состоянием после загрузки системы или состоянием в некоторой контрольной точке. Термин «безопасное состояние» определяется в модели ПФБ. Если разработчик предоставил четкое определение безопасного состояния и разъяснение, когда его следует считать таковым, зависимость FPT_RCV.1 — FPT_RCV.4 от ADV_SPM.1 можно не учитывать.

FPT_RCV.1. Ручное восстановление

Среди видов надежного восстановления тот из них, который основан только на ручном вмешательстве, наименее желателен, так как при этом исключается восстановление системы без участия человека.

Замечания по применению для пользователя

Компонент FPT_RCV.1 предназначен для применения в ОО, которые не требуют автоматического восстановления безопасного состояния. Требования этого компонента направлены против угрозы нарушения защиты в результате приведения ОО с участием человека в опасное состояние при восстановлении после сбоя или другого прерывания.

Замечания по применению для оценщика

Допускается, чтобы функции уполномоченного администратора по надежному восстановлению были доступны ему только в режиме аварийной поддержки. Следует предусмотреть средства ограничения доступа в режиме аварийной поддержки, предоставляя его только уполномоченным пользователям.

FPT_RCV.2. Автоматическое восстановление

Автоматическое восстановление считается более предпочтительным, чем ручное, так как оно позволяет машине продолжать функционирование без участия человека.

Замечания по применению для пользователя

Компонент FPT_RCV.2 расширяет FPT_RCV.1, требуя возможность автоматического восстановления хотя бы после одного типа сбоя/прерывания обслуживания. Требования этого компонента направлены против угрозы нарушения защиты в результате приведения ОО без участия человека в опасное состояние при восстановлении после сбоя или другого прерывания.

Замечания по применению для оценщика

Допускается, чтобы функции уполномоченного администратора по надежному восстановлению были доступны ему только в режиме аварийной поддержки. Следует предусмотреть средства ограничения доступа в режиме аварийной поддержки, предоставляя его только уполномоченным пользователям.

В соответствии с FPT_RCV.2.1 разработчик ФБО отвечает за определение совокупности сбоев и прерываний обслуживания, после которых возможно восстановление.

Предполагается, что робастность механизмов автоматического восстановления будет верифицирована.

Операции

Назначение

Для FPT_RCV.2.2 автору ПЗ/ЗБ следует специфицировать список сбоев или других прерываний обслуживания, для которых необходима возможность автоматического восстановления.

FPT_RCV.3. Автоматическое восстановление без недопустимой потери

Автоматическое восстановление считается более предпочтительным, чем ручное, но оно связано с риском потери большого числа объектов. Предотвращение недопустимых потерь объектов обеспечивается дополнительными средствами восстановления.

Замечания по применению для пользователя

Компонент FPT_RCV.3 расширяет FPT_RCV.2, требуя, чтобы не было чрезмерных потерь данных или объектов ФБО в ОДФ. В соответствии с FPT_RCV.2 механизм автоматического восстановления мог бы, в предельном случае, произвести восстановление путем уничтожения всех объектов и возвращения ФБО в известное безопасное состояние. Такой тип автоматического восстановления в FPT_RCV.3 запрещается.

Требования этого компонента направлены против угрозы нарушения защиты в результате непредусмотренного перехода ОО в опасное состояние при восстановлении после сбоя или перерывов в функционировании с большой потерей данных или объектов ФБО в ОДФ.

Замечания по применению для оценщика

Допускается, чтобы функции уполномоченного администратора по надежному восстановлению были доступны ему только в режиме аварийной поддержки. Следует предусмотреть средства ограничения доступа в режиме аварийной поддержки, предоставляя его только уполномоченным пользователям.

Предполагается, что робастность механизмов автоматического восстановления будет верифицирована оценщиком.

Операции

Назначение

Для FPT_RCV.3.2 автору ПЗ/ЗБ следует специфицировать список сбоев или других прерываний обслуживания, для которых необходима возможность автоматического восстановления.

Для FPT_RCV.3.3 автору ПЗ/ЗБ следует предоставить количественную меру приемлемых потерь данных или объектов ФБО.

FPT_RCV.4. Восстановление функции

Компонент FPT_RCV.4 содержит требование, чтобы в случае сбоя ФБО некоторые функции из числа ФБО либо нормально заканчивали работу, либо возвращались к безопасному состоянию.

Операции

Назначение

В FPT_RCV.4.1 автору ПЗ/ЗБ следует специфицировать список функций безопасности и сценариев сбоев, для которых нормально заканчивается работа ФБ, указанных в списке, или восстанавливается их устойчивое и безопасное состояние.

Л.9. Обнаружение повторного использования (FPT_RPL)

Семейство FPT_RPL связано с обнаружением повторного использования различных типов сущностей (таких, как сообщения, запросы на обслуживание, ответы на запросы обслуживания) и последующими действиями по его устранению.

FPT_RPL.1. Обнаружение повторного использования

Замечания по применению для пользователя

Рассматриваемыми здесь сущностями могут быть, например, сообщения, запросы на обслуживание, ответы на запросы обслуживания или сеансы пользователей.

Операции

Назначение

В FPT_RPL.1.1 автору ПЗ/ЗБ следует представить список сущностей, для которых следует предусмотреть возможность обнаружения повторного использования. Их примерами могут быть: сообщения, запросы на обслуживание, ответы на запросы обслуживания, сеансы пользователей.

В FPT_RPL.1.2 автору ПЗ/ЗБ следует специфицировать список действий, предпринимаемых ФБО при обнаружении повторного использования. Совокупность предпринимаемых действий может включать в себя игнорирование повторно используемой сущности, запрос подтверждения сущности из идентифицированного источника и отключение субъекта, пытавшегося инициировать повторное использование.

Л.10. Посредничество при обращениях (FPT_RVM)

Требования семейства FPT_RVM связаны с аспектом «постоянная готовность» традиционного монитора обращений. Цель этого семейства состоит в обеспечении для заданной ПФБ, чтобы в ОДФ все действия, требующие осуществления политики и инициируемые субъектами, недоверенными относительно одной или всех ПФБ, над объектами, управляемыми этой ПФБ, проверялись ФБО на соответствие ПФБ. Если помимо этого часть ФБО, осуществляющая ПФБ, выполняет требования соответствующих компонентов из семейств FPT_SEP «Разделение домена» и ADV_INT «Внутренняя структура ФБО», то эта часть ФБО обеспечивает «монитор обращений» для этой ПФБ.

Монитор обращений является частью ФБО, ответственной за осуществление ПБО, и обладает следующими тремя свойствами:

а) недоверенные субъекты не могут вмешиваться в работу монитора, т.е. он устойчив к проникновению. Это свойство обеспечивается требованиями компонентов семейства FPT_SEP;

б) недоверенные субъекты не могут обойти проверки монитора, т.е. он постоянно готов к работе. Это свойство обеспечивается требованиями компонентов семейства FPT_RVM;

в) монитор достаточно прост, его устройство поддается анализу, его действия понятны (т.е. его построение концептуально несложно). Это свойство обеспечивается требованиями компонентов семейства ADV_INT.

В единственном компоненте семейства FPT_RVM содержится требование: «ФБО должны обеспечить, чтобы функции, осуществляющие ПБО, вызывались и успешно выполнялись прежде, чем разрешается выполнение любой другой функции в пределах ОДФ». В любой системе (распределенной или нет) имеется конечное число функций, ответственных за осуществление ПБО. В этом требовании не утверждается, что для управления безопасностью применяется одна функция. Наоборот, утверждается, что роль механизма проверки правомочности обращений выполняют несколько функций, и именно их совокупность, осуществляющая ПБО, объединена под именем монитора обращений. При этом необходимо принимать во внимание задачу сохранения простоты «монитора обращений».

ФБО при реализации ПФБ предоставляют эффективную защиту от несанкционированных операций тогда и только тогда, когда правомочность всех действий, предполагаемых для осуществления (например, доступ к объектам) и запрошенных субъектами, недоверенными относительно всех или именно этой ПФБ, проверяется ФБО до выполнения действий. Если действия по проверке будут выполнены неправильно или проигнорированы (обойдены), то осуществление ПФБ в целом может быть поставлено под угрозу (ее можно обойти). Тогда «недоверенные» субъекты смогут обходить ПФБ различными способами (такими, как обход проверки доступа для некоторых субъектов и объектов, обход проверки для объектов, чья защита управляется прикладными программами, сохранение права доступа после истечения установленного срока действия, обход аудита событий, подлежащих аудиту, обход аутентификации). Важно отметить, что термин «недоверенный субъект» относится к субъектам, недоверенным относительно какой-либо или всех осуществляемых ПФБ; субъект может быть доверенным относительно одной ПФБ и недоверенным относительно другой.

FPT_RVM.1. Невозможность обхода ПБО

Замечания по применению для пользователя

Для получения эквивалента монитора обращений необходимо применить данный компонент совместно либо с FPT_SEP.2 «Отделение домена ПФБ», либо с FPT_SEP.3 «Полный монитор обращений», а также с ADV_INT.3 «Минимизация сложности». Кроме того, если требуется полное посредничество при обращениях, требования компонентов из класса FDP «Защита данных пользователя» необходимо распространить на все объекты в составе ОО.

Л.11. Разделение домена (FPT_SEP)

Компоненты семейства FPT_SEP обеспечивают, чтобы, по меньшей мере, один домен безопасности был доступен только для собственного выполнения ФБО, и этим они были защищены от внешнего вмешательства и искажения (например, модификации кода или структур данных ФБО) со стороны недоверенных субъектов. Выполнение требований этого семейства устанавливает такую самозащиту ФБО, что недоверенный субъект не сможет модифицировать или повредить ФБО.

Это семейство содержит следующие требования:

а) ресурсы домена безопасности ФБО («защищенного домена») и ресурсы субъектов и активных сущностей, внешних по отношению к этому домену, разделяются так, что сущности, внешние по отношению к защищенному домену, не смогут получить или модифицировать данные или код ФБО в пределах защищенного домена;

б) обмен между доменами управляется так, что невозможен произвольный вход в защищенный домен или произвольный выход из него;

в) параметры пользователя или прикладной программы, переданные в защищенный домен по адресу, проверяются относительно адресного пространства защищенного домена, а переданные по значению — относительно значений, ожидаемых этим доменом;

г) защищенные домены субъектов разделены, за исключением случаев, когда совместное использование одного домена управляется ФБО.

Замечания для пользователя

Это семейство применяется, когда требуется уверенность в том, что ФБО не подвержены внешнему воздействию.

Для получения эквивалента монитора обращений необходимо применить компонент FPT_SEP.2 (Отделение домена ПФБ) или FPT_SEP.3 «Полный монитор обращений» совместно с FPT_RVM.1 «Невозможность обхода ПБО» и ADV_INT.3 «Минимизация сложности». Кроме того, если требуется полное посредничество при обращениях, требования компонентов из класса FDP «Защита данных пользователя» необходимо распространить на все объекты в составе ОО.

FPT_SEP.1. Отделение домена ФБО

Без отдельного защищенного домена для ФБО не может быть доверия тому, что ФБО не подвергались каким-либо воздействиям со стороны недоверенных субъектов. Такие воздействия могут привести к модификации кода и/или структур данных ФБО.

FPT_SEP.2. Отделение домена ПФБ

Наиболее важной функцией ФБО является поддержка осуществляемых ими ПФБ. Чтобы упростить разработку ПФБ и приблизить их свойства к свойствам монитора обращений, в частности, к стойкости к воздействиям, функции, проводящие ПФБ, необходимо сосредоточить в домене, отличном от остальной части ФБО.

Замечания по применению для оценщика

Возможно, что монитор обращений в многоуровневом проекте предоставляет больше функций, чем требуется в ПФБ. Это проистекает из практической реализации многоуровневого проекта программного обеспечения. При этом функции, не относящиеся к ПФБ, следует свести к минимуму.

Допустимо, чтобы мониторы обращений для всех осуществляемых ПФБ находились как в одном домене монитора обращений, так и в нескольких доменах (каждый используется для осуществления одной или нескольких ПФБ). Если имеется несколько доменов монитора обращений для нескольких ПФБ, они могут или быть равноправными или образовывать иерархию.

Для FPT_SEP.2.1 фраза «неизолированная часть ФБО» относится к той части ФБО, которая не охвачена в FPT_SEP.2.3.

Операции

Назначение

Для FPT_SEP.2.3 автору ПЗ/ЗБ следует специфицировать те ПФБ управления доступом и/или информационными потоками, которым следует занимать отдельный домен.

FPT_SEP.3. Полный монитор обращений

Наиболее важной функцией из числа ФБО является поддержка осуществляемых ими ПФБ. Компонент FPT_SEP.3 завершает требования предыдущих компонентов семейства, устанавливая, что все функции безопасности, проводящие ПФБ управления доступом и/или информационными потоками, будут выполняться в домене, отличном от домена выполнения остальных ФБО. Это упрощает разработку ФБО и приближает их свойства к свойствам монитора обращений, в частности, к стойкости к воздействиям.

Замечания по применению для оценщика

Возможно, что монитор обращений в многоуровневом проекте предоставляет больше функций, чем требуется в ПФБ. Это проистекает из практической реализации многоуровневого проекта программного обеспечения. При этом функции, не относящиеся к ПФБ, следует свести к минимуму.

Допустимо, чтобы мониторы обращений для всех осуществляемых ПФБ находились как в одном домене монитора обращений, так и в нескольких доменах (каждый используется для осуществления одной или нескольких ПФБ). Если имеется несколько доменов монитора обращений для нескольких ПФБ, они могут или быть равноправными или образовывать иерархию.

Л.12. Протокол синхронизации состояний (FPT_SSP)

Распределенные системы могут иметь большую сложность, чем нераспределенные, из-за многообразия состояний частей системы, а также из-за задержек связи. В большинстве случаев синхронизация состояния между распределенными функциями включает в себя, вместо обычных действий, применение протокола обмена. Когда в среде распределенных систем существуют угрозы безопасности, потребуются более сложные защищенные протоколы.

Семейство FPT_SSP устанавливает требование использования надежных протоколов некоторыми критичными по безопасности функциями из числа ФБО. Оно обеспечивает, чтобы две распределенные части ОО (например, главные ЭВМ) синхронизировали свои состояния после действий, связанных с безопасностью.

Замечания для пользователя

Некоторые состояния невозможно синхронизировать, или затраты на транзакцию будут слишком велики для практического применения; отмена ключа шифрования является примером, когда после выполнения действия состояние может стать неопределенным. Либо действие предпринято, а подтверждение не может быть отправлено, либо сообщение проигнорировано получателем, и поэтому отмена не произойдет. Неопределенность присуща распределенным системам. Проблема неопределенности связана с необходимостью синхронизации состояний и может решаться соответствующими методами. Планировать неопределенные состояния бесполезно; при них автору ПЗ/ЗБ следует прибегнуть к другим требованиям (например, подача сигнала тревоги, проведение аудита).

FPT_SSP.1. Одностороннее надежное подтверждение

Замечания по применению для пользователя

В компоненте FPT_SSP.1 необходимо, чтобы по запросу ФБО предоставляли подтверждение для другой части ФБО. Это подтверждение требуется для указания, что в одной части распределенного ОО успешно получено немодифицированное сообщение из другой части ОО.

FPT_SSP.2. Взаимное надежное подтверждение

Замечания по применению для пользователя

Компонент FPT_SSP.2 содержит требование, что в дополнение к предоставлению подтверждения получения передаваемых данных принимающей части ФБО необходимо обратиться к передающей за уведомлением о получении подтверждения.

Например, локальная часть ФБО передает данные удаленной части ФБО. Последняя подтверждает успешный прием сообщения и запрашивает у передавшей сообщение части ФБО уведомление, что она получила подтверждение. Этот механизм дает дополнительную уверенность, что обе части ФБО, участвующие в передаче данных, извещены об успешном завершении передачи.

Л.13. Метки времени (FPT_STM)

Семейство FPT_STM содержит требования по предоставлению надежных меток времени в пределах ОО.

Замечания для пользователя

На автора ПЗ/ЗБ возлагается разъяснение смысла выражения «надежные метки времени» и указание, где принимается решение о надежности.

FPT_STM.1. Надежные метки времени

Замечания по применению для пользователя

Применение компонента FPT_STM.1 возможно для предоставления надежных меток времени при проведении аудита, а также для ограничения срока действия атрибутов безопасности.

Л.14. Согласованность данных ФБО между ФБО (FPT_TDC)

В среде распределенной или сложной системы от ОО может потребоваться произвести обмен данными ФБО (такими, как атрибуты ПФБ, ассоциированные с данными, информация аудита или идентификации) с другим доверенным продуктом ИТ. Семейство FPT_TDC определяет требования для совместного использования и непротиворечивой интерпретации этих атрибутов между ФБО и другим доверенным продуктом ИТ.

Замечания для пользователя

Это семейство предназначено для представления требований к автоматической поддержке согласованности данных ФБО при их передаче между ФБО рассматриваемого ОО и ФБО другого доверенного продукта. Возможна и такая ситуация, когда для согласования атрибутов безопасности применяются только процедурные меры, однако они здесь не рассматриваются.

Семейство FPT_TDC отличается от FDP_ETC и FDP_ITC, так как последние направлены лишь на соотнесение атрибутов безопасности между ФБО и носителями импортируемой или экспортируемой ими информации.

В случае, когда важна целостность данных ФБО, следует выбрать требования из семейства FPT_ITI. Его компоненты определяют требования, чтобы ФБО были способны обнаружить и/или исправить модификации данных ФБО во время передачи.

FPT_TDC.1. Базовая согласованность данных ФБО между ФБО

Замечания по применению для пользователя

ФБО отвечают за поддержку согласованности данных ФБО, используемых ими или ассоциированных с ними, которые являются общими у двух или более доверенных систем. Например, данные ФБО для ФБО двух различных систем могут толковаться внутри них по-разному. Для правильного применения данных ФБО принимающим доверенным продуктом ИТ (например, для обеспечения такой же защиты данных пользователя, как и в ОО) необходимо, чтобы ОО и другой доверенный продукт ИТ применяли заранее установленный протокол обмена данными ФБО.

Операции

Назначение

В FPT_TDC.1.1 автору ПЗ/ЗБ следует определить список типов данных ФБО, которые должны согласованно интерпретироваться при совместном использовании ФБО и другим доверенным продуктом ИТ.

В FPT_TDC.1.2 автору ПЗ/ЗБ следует привести список правил интерпретации, применяемых ФБО.

Л.15. Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)

Требования семейства FPT_TRC необходимы, чтобы обеспечить согласованность данных ФБО, когда они дублируются в пределах ОО. Такие данные могут стать несогласованными при нарушении работоспособности внутреннего канала между частями ОО. Если ОО внутренне структурирован как сеть, то это может произойти из-за отключения отдельных частей сети при разрыве сетевых соединений.

Замечания для пользователя

Метод обеспечения согласованности в данном семействе не указывается. Согласованность может достигаться с помощью некоторой формы обработки транзакций (где соответствующие транзакции «возвращаются назад» к месту отправления через повторное соединение) или путем обновления дублируемых данных через протокол синхронизации. Если для ПЗ/ЗБ необходим конкретный протокол, то он может быть специфицирован с использованием операции уточнения.

Может оказаться, что синхронизировать некоторые состояния невозможно или затраты на такую синхронизацию слишком высоки. Примером подобной ситуации служит отмена каналов связи и ключей шифрования. Могут также возникать неопределенные состояния. Если желателен конкретный режим функционирования, его следует специфицировать с использованием операции уточнения.

FPT_TRC.1. Согласованность дублируемых данных ФБО

Операции

Назначение

В FPT_TRC.1.2 автору ПЗ/ЗБ следует специфицировать список ФБ, которые зависят от согласованности дублирования данных ФБО.

Л.16. Самотестирование ФБО (FPT_TST)

Семейство FPT_TST определяет требования для самотестирования ФБО в части некоторых типичных операций с известным результатом. Примерами могут служить обращения к интерфейсам осуществляемых функций, а также некоторые арифметические операции, выполняемые критичными частями ОО. Эти тесты могут выполняться при запуске, периодически, по запросу уполномоченного пользователя или при удовлетворении других условий. Действия ОО, предпринимаемые по результатам самотестирования, определены в других семействах.

Требования этого семейства также необходимы для обнаружения искажения выполняемого кода ФБО (т.е. программной реализации ФБО) и данных ФБО различными сбоями, которые не всегда приводят к приостановке функционирования ОО (рассмотренной в других семействах). Такие проверки необходимо выполнять, т.к. подобные сбои не всегда можно предотвратить. Они могут происходить либо из-за непредусмотренных типов сбоев или имеющихся неточностей в проекте аппаратных, программно-аппаратных и программных средств, либо вследствие злонамеренного искажения ФБО, допущенного из-за неадекватной логической и/или физической защиты.

Дополнительно этот компонент может, при соответствующих условиях, помочь предотвратить неприемлемые или наносящие ущерб изменения ФБО, которые могут быть произведены в эксплуатируемом ОО при выполнении действий по сопровождению.

Замечания для пользователя

Термин «правильное выполнение ФБО» относится главным образом к функционированию программного обеспечения ФБО и целостности его данных. Абстрактная машина, на которой реализуется программное обеспечение ФБО, проверяется через зависимость от FPT_AMT.

FPT_TST.1. Тестирование ФБО

Замечания по применению для пользователя

Компонент FPT_TST.1 поддерживает как тестирование критичных функций из числа ФБО через требование возможности запускать тестирование функций, так и проверку целостности данных и выполняемого кода ФБО.

Замечания по применению для оценщика

Допускается, чтобы функции, предоставляемые уполномоченному пользователю для периодического тестирования, были доступны только в автономном режиме и режиме аварийной поддержки. В этих режимах следует предусмотреть средства ограничения доступа, предоставляя его только уполномоченным пользователям.

Операции

Выбор

В FPT_TST.1 автору ПЗ/ЗБ следует специфицировать, когда самими ФБО будет выполняться тестирование ФБО: при запуске, периодически в процессе нормального функционирования, по запросу уполномоченного пользователя, при других условиях. В последнем случае автору ПЗ/ЗБ следует также указать конкретные условия, используя операцию назначения.

Назначение

В FPT_TST.1.1 автору ПЗ/ЗБ следует, если сделан соответствующий выбор, специфицировать условия, при которых следует выполнять самотестирование.

Приложение М
(справочное)

ИСПОЛЬЗОВАНИЕ РЕСУРСОВ (FRU)

Класс FRU содержит три семейства, которые поддерживают доступность требуемых ресурсов, таких как вычислительные возможности и/или объем памяти. Семейство FRU_FLT «Отказоустойчивость» предоставляет защиту от недоступности ресурсов, вызванной сбоем ОО. Семейство FRU_PRS «Приоритет обслуживания» обеспечивает, чтобы ресурсы выделялись наиболее важным или критичным по времени задачам и не могли быть монополизированы задачами с более низким приоритетом. Семейство FRU_RSA «Распределение ресурсов» устанавливает ограничения использования доступных ресурсов, предотвращая монополизацию ресурсов пользователями.

Декомпозиция класса FRU на составляющие его компоненты приведена на рисунке М.1.

Рисунок М.1. Декомпозиция класса «Использование ресурсов»

М.1. Отказоустойчивость (FRU_FLT)

Семейство FRU_FLT содержит требования к доступности функциональных возможностей даже в случае сбоев. Примеры таких сбоев: отключение питания, отказ аппаратуры, сбой программного обеспечения. В случае таких ошибок, если это специфицировано, ОО будет поддерживать определенные возможности. Автор ПЗ/ЗБ может специфицировать, например, что ОО, используемый на атомной станции, продолжит работу по выполнению процедуры остановки реактора при сбое в энергоснабжении или средствах связи.

Замечания для пользователя

Поскольку ОО может продолжать правильное функционирование только при продолжении осуществления ПБО, то имеется требование, что после сбоя системе необходимо оставаться в безопасном состоянии. Эта способность обеспечивается привлечением компонента FPT_FLS.1.

Механизмы обеспечения отказоустойчивости могут быть активными или пассивными. Активный механизм имеет специальные функции, которые активизируются при возникновении ошибки. Например, пожарная сигнализация является активным механизмом: ФБО обнаружат пожар и смогут предпринять действия по включению операции резервирования. Пассивная схема применяется, если в архитектуре ОО заложена способность обработки ошибки. Например, применение мажоритарной схемы голосования с несколькими процессорами является пассивным решением; отказ одного процессора не прервет функционирование ОО (хотя отказ требуется обнаружить для исправления).

Для этого семейства не имеет значения, был ли сбой инициирован случайно (например, переполнение или ошибочное отключение устройства) или преднамеренно (например, из-за монополизации ресурса).

FRU_FLT.1. Пониженная отказоустойчивость

Замечания по применению для пользователя

Компонент FRU_FLT.1 предназначен для спецификации того, какие возможности ОО продолжит предоставлять после сбоя системы. Так как сложно было бы описать все возможные отказы, можно специфицировать их категории. Примерами типичных сбоев являются: затопление помещения с аппаратурой, короткое замыкание, сбой центрального процессора или главной ЭВМ, сбой программного обеспечения, переполнение буфера.

Операции

Назначение

В FRU_FLT.1.1 автору ПЗ/ЗБ следует специфицировать список возможностей ОО, которые ОО будет поддерживать во время и после специфицированного сбоя.

В FRU_FLT.1.1 автору ПЗ/ЗБ следует специфицировать список типов сбоев, от которых ОО должен быть обязательно защищен. Если случится сбой из этого списка, ОО будет способен продолжить функционирование.

FRU_FLT.2. Ограниченная отказоустойчивость

Замечания по применению для пользователя

Компонент FRU_FLT.2 позволяет специфицировать, каким типам сбоев ОО необходимо противодействовать. Так как сложно было бы описать все возможные отказы, можно специфицировать их категории. Примерами типичных сбоев являются: затопление помещения с аппаратурой, кратковременное отключение энергоснабжения, сбой центрального процессора или главной ЭВМ, сбой программного обеспечения, переполнение буфера.

Операции

Назначение

В FRU_FLT.2.1 автору ПЗ/ЗБ следует специфицировать список типов сбоев, от которых ОО должен быть обязательно защищен. Если случится сбой из этого списка, ОО будет способен продолжить функционирование.

М.2. Приоритет обслуживания (FRU_PRS)

Требования семейства FRU_PRS позволяют ФБО управлять использованием ресурсов пользователями и субъектами в пределах своей области действия так, что высокоприоритетные операции в пределах ОДФ всегда будут выполняться без препятствий или задержек со стороны операций с более низким приоритетом. Другими словами, задачи, критичные по времени выполнения, не будут задерживаться задачами, менее критичными по времени выполнения.

Это семейство может применяться к различным типам ресурсов, например вычислительным возможностям, пропускной способности каналов связи.

Механизм приоритетов обслуживания может быть пассивным или активным. В системе с пассивным приоритетом обслуживания выбирается задача с наивысшим приоритетом, если предлагается сделать выбор между двумя ожидающими приложениями. При использовании пассивных механизмов приоритетов обслуживания выполняемая задача с более низким приоритетом не может быть прервана задачей с более высоким приоритетом. При использовании активных механизмов приоритетов обслуживания задачи с более низким приоритетом могут прерываться новыми задачами с более высоким приоритетом.

Замечания для пользователя

Требования аудита устанавливают, что все причины отклонения операций следует подвергать аудиту. На усмотрение разработчика оставлена ситуация, когда операция не отклоняется, а задерживается.

FRU_PRS.1. Ограниченный приоритет обслуживания

Замечания по применению для пользователя

Компонент FRU_PRS.1 определяет приоритеты для субъектов и ресурсы, к которым будет применяться механизм приоритетов обслуживания. Если субъект пытается предпринять действие для получения ресурса, контролируемого требованиями приоритета обслуживания, доступ и/или время доступа будут поставлены в зависимость от приоритета субъекта, приоритета субъекта, действующего в настоящий момент, и приоритета субъектов в очереди.

Операции

Назначение

Для FRU_PRS.1.2 автору ПЗ/ЗБ следует специфицировать список управляемых ресурсов, для которых ФБО осуществляют приоритетное обслуживание (примеры ресурсов: процессы, дисковое пространство, память, полоса пропускания).

FRU_PRS.2. Полный приоритет обслуживания

Замечания по применению для пользователя

Компонент FRU_PRS.2 определяет приоритеты для субъектов. Все ресурсы в ОДФ, которые предполагается использовать совместно, будут управляться механизмом приоритетного обслуживания. Если субъект пытается предпринять действия на ресурсе в ОДФ, который предполагается использовать совместно, доступ и/или время доступа будет поставлено в зависимость от приоритета субъекта, приоритета субъекта, действующего в настоящий момент, и приоритета субъектов в очереди.

М.3. Распределение ресурсов (FRU_RSA)

Требования семейства FRU_RSA позволяют ФБО в пределах ОДФ управлять использованием ресурсов пользователями и субъектами таким образом, чтобы не допустить несанкционированные отказы в обслуживании из-за монополизации ресурсов другими пользователями или субъектами.

Замечания для пользователя

Правила распределения ресурсов позволяют назначать квоты или создавать другие средства определения ограничений на количество ресурса или время его использования, которые могут быть распределены конкретным пользователям или субъектам. Этими правилами, например, могут быть:

— введение квот объектов, ограничивающих число объектов и/или их размер, которые могут быть назначены конкретному пользователю;

— управление распределением/освобождением выделенных ранее единиц ресурсов в случае, когда они находятся под управлением ФБО.

В общем случае эти функции будут реализованы с применением атрибутов, назначенных пользователям и ресурсам.

Целью этих компонентов является обеспечение определенной степени «справедливости» по отношению к пользователям (например, всю доступную память не следует распределять одному пользователю) и субъектам. Так как продолжительность распределения ресурсов часто превышает время существования субъекта (так, файлы часто существуют дольше, чем приложения, создавшие их), то не следует, чтобы неоднократное воплощение субъектов одним и тем же пользователем оказывало бы слишком сильное отрицательное воздействие на других пользователей. Компоненты семейства позволяют связать ограничения на распределение ресурсов с пользователями. В некоторых же ситуациях ресурсы распределяются для субъектов (например, оперативная память или циклы центрального процессора). В таком случае компоненты семейства позволяют распределять ресурсы на уровне субъектов.

Данное семейство налагает требования на распределение ресурсов, но не на их использование. Поэтому установлено, что требования аудита также распространяются на распределение ресурсов, но не на их использование.

FRU_RSA.1. Максимальные квоты

Замечания по применению для пользователя

Компонент FRU_RSA.1 содержит требования для механизмов квотирования, которые применимы только к специфицированной совокупности разделяемых ресурсов в ОО. Эти требования позволяют ассоциировать квоты с пользователем или, возможно, связывать их с группами пользователей или субъектов, если это предусмотрено в ОО.

Операции

Назначение

В FRU_RSA.1.1 автору ПЗ/ЗБ следует специфицировать список управляемых ресурсов, для которых требуются ограничения максимального выделения ресурса (например, процессы, дисковое пространство, память, полоса пропускания). Если это требование необходимо распространить на все ресурсы в ОДФ, разрешается специфицировать «все ресурсы в ОДФ».

Выбор

В FRU_RSA.1.1 автору ПЗ/ЗБ следует выбрать, относятся ли максимальные квоты к отдельным пользователям, определенным группам пользователей, субъектам или любому их сочетанию.

В FRU_RSA.1.1 автору ПЗ/ЗБ следует выбрать, применимы ли максимальные квоты в любое заданное время (одновременно) или в течение определенного периода времени.

FRU_RSA.2. Минимальные и максимальные квоты

Замечания по применению для пользователя

Компонент FRU_RSA.2 содержит требования для механизмов квотирования, которые применимы только к специфицированной совокупности разделяемых ресурсов в ОО. Эти требования позволяют ассоциировать квоты с пользователем или, возможно, связывать их с группами пользователей или субъектов, если это предусмотрено в ОО.

Операции

Назначение

В FRU_RSA.2.1 автору ПЗ/ЗБ следует специфицировать управляемые ресурсы, для которых требуются ограничения максимального выделения ресурса (например, процессы, дисковое пространство, память, полоса пропускания). Если это требование необходимо распространить на все ресурсы в ОДФ, разрешается специфицировать «все ресурсы в ОДФ».

Выбор

В FRU_RSA.2.1 автору ПЗ/ЗБ следует выбрать, относятся ли максимальные квоты к отдельным пользователям, определенным группам пользователей, субъектам или любому их сочетанию.

В FRU_RSA.2.1 автору ПЗ/ЗБ следует выбрать, применимы ли максимальные квоты в любое заданное время (одновременно) или в течение определенного периода времени.

Назначение

В FRU_RSA.2.2 автору ПЗ/ЗБ следует специфицировать управляемые ресурсы, для которых необходимо установить предел минимального выделения ресурса (например, процессы, дисковое пространство, память, полоса пропускания). Если это требование необходимо распространить на все ресурсы в ОДФ, разрешается специфицировать «все ресурсы в ОДФ».

Выбор

В FRU_RSA.2.2 автору ПЗ/ЗБ следует выбрать, относятся ли минимальные квоты к отдельным пользователям, определенным группам пользователей, субъектам или любому их сочетанию.

В FRU_RSA.2.2 автору ПЗ/ЗБ следует выбрать, применимы ли минимальные квоты в любое заданное время (одновременно) или в течение определенного периода времени.

Приложение Н
(справочное)

ДОСТУП К ОО (FTA)

Открытие сеанса пользователя обычно состоит из создания одного или нескольких субъектов, выполняющих операции в ОО от имени пользователя. В конце процедуры открытия сеанса, если удовлетворены требования доступа к ОО, созданные субъекты имеют атрибуты, определенные функциями идентификации и аутентификации. Класс FTA определяет требования к управлению открытием сеанса пользователя.

Сеанс пользователя определен как период времени, начинающийся от момента идентификации/аутентификации (или, точнее, с начала взаимодействия между пользователем и системой) вплоть до момента, когда освобождены все субъекты, ресурсы и атрибуты, относящиеся к данному сеансу.

Декомпозиция класса FTA на составляющие его компоненты приведена на рисунке Н.1.

Рисунок Н.1. Декомпозиция класса «Доступ к ОО»

Н.1. Ограничение области выбираемых атрибутов (FTA_LSA)

Семейство FTA_LSA определяет требования по ограничению как атрибутов безопасности сеанса, которые может выбирать пользователь, так и субъектов, с которыми пользователь может быть связан, на основе метода или места доступа, порта, с которого осуществляется доступ, и/или времени (например, времени суток, дня недели).

Замечания для пользователя

Это семейство предоставляет авторам ПЗ/ЗБ возможность специфицировать требования для ФБО по установлению ограничений на область выбираемых атрибутов безопасности уполномоченных пользователей, которые следуют из условий среды. Например, пользователю может быть разрешено открыть «секретный сеанс» в рабочее время, но вне рабочего времени он может открыть только «неклассифицированный сеанс». Для идентификации соответствующих ограничений на область выбираемых атрибутов предусмотрена операция выбора. Эти ограничения могут следовать из значений других атрибутов. Если необходимо специфицировать ограничения для нескольких атрибутов, то этот компонент придется повторить несколько раз по числу атрибутов. Примерами атрибутов, которые можно использовать для ограничения атрибутов безопасности сеанса, являются следующие:

а) метод доступа, по которому можно определить среду, в которой будет работать пользователь (например, протокол передачи файлов, терминал, виртуальный телекоммуникационный метод доступа);

б) место, с которого осуществляется доступ. Может использоваться для ограничения области выбираемых атрибутов пользователя на основе места расположения пользователя или порта доступа. Эта возможность особенно важна при использовании телефонных линий или сетевых средств;

в) время доступа, которое можно использовать для ограничения области выбираемых атрибутов пользователя. Например, ограничения могут быть основаны на времени суток, дне недели, календарных датах. Это ограничение предоставляет определенную защиту от действий пользователя в то время, когда могут не применяться необходимые процедурные меры или мониторинг.

FTA_LSA.1. Ограничение области выбираемых атрибутов

Операции

Назначение

В FTA_LSA.1.1 автору ПЗ/ЗБ следует специфицировать совокупность атрибутов безопасности сеанса, которые нужно ограничить. Примеры таких атрибутов: уровень допуска пользователя, уровень целостности, роли.

В FTA_LSA.1.1 автору ПЗ/ЗБ следует специфицировать совокупность атрибутов, которые можно использовать для определения области атрибутов безопасности сеанса. Примеры таких атрибутов: идентификатор пользователя, расположение источника, время доступа и метод доступа.

Н.2. Ограничение на параллельные сеансы (FTA_MCS)

Семейство FTA_MCS определяет, сколько сеансов пользователь может иметь одновременно (параллельные сеансы). Допустимое число параллельных сеансов может указываться либо для группы пользователей, либо для каждого отдельного пользователя.

FTA_MCS.1. Базовое ограничение на параллельные сеансы

Замечания по применению для пользователя

Компонент FTA_MCS.1 предоставляет системе возможность ограничения числа сеансов в целях эффективного использования ресурсов ОО.

Операции

Назначение

В FTA_MCS.1.2 автору ПЗ/ЗБ следует специфицировать, какое ограничение числа параллельных сеансов будет использоваться по умолчанию.

FTA_MCS.2. Ограничение на параллельные сеансы по атрибутам пользователя

Замечания по применению для пользователя

Компонент FTA_MCS.2 предоставляет дополнительные возможности по сравнению с FTA_MCS.1, позволяя установить дополнительные ограничения на число параллельных сеансов, которые пользователи в состоянии открыть. Эти ограничения основаны на атрибутах безопасности пользователя, таких как идентификатор пользователя или принадлежность к роли.

Операции

Назначение

Для FTA_MCS.2.1 автору ПЗ/ЗБ следует специфицировать правила, определяющие максимально предоставляемое число параллельных сеансов. Примером такого правила является «максимальное число параллельных сеансов равно одному, если пользователь имеет уровень допуска «секретно» и пяти в остальных случаях».

В FTA_MCS.2.2 автору ПЗ/ЗБ следует специфицировать, какое ограничение числа параллельных сеансов будет использоваться по умолчанию.

Н.3. Блокирование сеанса (FTA_SSL)

Семейство FTA_SSL определяет требования к ФБО по предоставлению возможности блокировать и разблокировать интерактивные сеансы (например, блокировать клавиатуру).

Когда пользователь непосредственно взаимодействует с субъектами в ОО (интерактивный сеанс), терминал пользователя уязвим, если он оставлен без надзора. Это семейство предоставляет требования к ФБО по отключению (блокированию) терминала или завершению сеанса после установленного времени бездеятельности, а к пользователю — по возможности инициировать отключение (блокирование) терминала. Для возвращения терминала в активное состояние необходимо, чтобы произошло событие, специфицированное автором ПЗ/ЗБ, например повторная аутентификация пользователя.

Пользователь считается бездействующим, если он никак не воздействовал на ОО в течение некоторого периода времени.

Автору ПЗ/ЗБ следует учесть, требуется ли привлекать компонент FTP_TPR.1 «Доверенный маршрут». В этом случае следует через операцию компонента FTP_TPR.1 подключить функцию «блокирование сеанса».

FTA_SSL.1. Блокирование сеанса, инициированное ФБО

Замечания по применению для пользователя

Компонент FTA_SSL.1 предоставляет ФБО возможность блокировать сеанс пользователя по истечении заданного периода времени. Блокирование терминала прекратило бы все дальнейшие действия в данном сеансе с использованием заблокированного терминала.

Если на устройстве отображения перезаписывается информация, содержание замещающей информации не обязательно статично (например, разрешается использовать «хранитель экрана»).

Этот компонент позволяет автору ПЗ/ЗБ специфицировать события, деблокирующие сеанс. Эти события могут быть связаны с терминалом (например, набор установленной последовательности символов для разблокирования сеанса), с пользователем (например, его повторная аутентификация) или со временем.

Операции

Назначение

В FTA_SSL.1.1 автору ПЗ/ЗБ следует специфицировать интервал бездействия пользователя, по истечении которого произойдет блокирование сеанса. При желании автор ПЗ/ЗБ может использовать данную операцию, чтобы возложить определение интервала времени на уполномоченного администратора или пользователя. Функции управления в классе FMT могут специфицировать возможность модификации этого интервала, задавая его значение по умолчанию.

В FTA_SSL.1.2 автору ПЗ/ЗБ следует специфицировать событие или события, которые происходили бы до разблокирования сеанса. Примеры таких событий: «повторная аутентификация пользователя» или «ввод пользователем с клавиатуры деблокирующей последовательности символов».

FTA_SSL.2. Блокирование, инициированное пользователем

Замечания по применению для пользователя

Компонент FTA_SSL.2 предоставляет уполномоченному пользователю возможность блокировать и деблокировать свой собственный терминал. Это предоставило бы уполномоченным пользователям возможность эффективно блокировать свои сеансы без необходимости их завершения.

Если на устройстве отображения перезаписывается информация, содержание замещающей информации не обязательно статично (например, разрешается использовать «хранитель экрана»).

Операции

Назначение

В FTA_SSL.2.2 автору ПЗ/ЗБ следует специфицировать событие или события, которые происходили бы до разблокирования сеанса. Примеры таких событий: «повторная аутентификация пользователя» или «ввод пользователем с клавиатуры деблокирующей последовательности символов».

FTA_SSL.3. Завершение, инициированное ФБО

Замечания по применению для пользователя

Компонент FTA_SSL.3 содержит требование, чтобы ФБО завершали интерактивный сеанс пользователя после установленного периода его бездействия.

Автору ПЗ/ЗБ следует учесть, что сеанс может продолжаться и после того, как пользователь окончил активные действия, например в виде фонового выполнения. Данное требование направлено на завершение этого фонового субъекта после периода бездействия пользователя, независимо от статуса субъекта.

Операции

Назначение

В FTA_SSL.3.1 автору ПЗ/ЗБ следует специфицировать интервал бездействия пользователя, по истечении которого произойдет блокирование сеанса. При желании автор ПЗ/ЗБ может использовать операцию назначения, чтобы возложить определение интервала времени на уполномоченного администратора или пользователя. Функции управления в классе FMT могут специфицировать возможность модификации этого интервала, задавая его значение по умолчанию.

Н.4. Предупреждения перед предоставлением доступа к ОО (FTA_TAB)

Требования доступа к ОО предусматривают для ОО возможность еще до идентификации и аутентификации отобразить для потенциальных пользователей предупреждающее сообщение относительно характера использования ОО.

FTA_TAB.1. Предупреждения по умолчанию перед предоставлением доступа к ОО

Компонент FTA_TAB.1 содержит требование наличия предупреждающего сообщения о несанкционированном использовании ОО. Автор ПЗ/ЗБ может уточнить это требование с целью задания предупреждения по умолчанию.

Н.5. История доступа к ОО (FTA_TAH)

Семейство FTA_TAH определяет требования к ФБО по отображению для пользователя, при успешном открытии сеанса, истории неуспешных попыток получить доступ от имени этого пользователя. Эта история может содержать дату, время, средства доступа и порт последнего успешного доступа к ОО, а также число неуспешных попыток доступа к ОО после последнего успешного доступа идентифицированного пользователя.

FTA_TAH.1. История доступа к ОО

Компонент FTA_TAH.1 может предоставить уполномоченным пользователям информацию о возможном злоупотреблении их учетными данными.

Этот компонент содержит требование предоставления информации пользователю. Следует предоставить пользователю возможность просмотреть информацию, но не заставлять его делать это. При желании пользователь может, например, создать командный файл для игнорирования этой информации и перехода к последующим действиям.

Операции

Выбор

В FTA_TAH.1.1 автору ПЗ/ЗБ следует выбрать атрибуты безопасности последнего успешного открытия сеанса, которые будут показаны через пользовательский интерфейс. К этим атрибутам относятся: дата, время, метод доступа (например, протокол пересылки файлов) и/или место доступа (например, терминал 50).

В FTA_TAH.1.2 автору ПЗ/ЗБ следует выбрать атрибуты безопасности последней неуспешной попытки открытия сеанса, которые будут показаны через пользовательский интерфейс. К этим атрибутам относятся: дата, время, метод доступа (например, протокол пересылки файлов) и/или место доступа (например, терминал 50).

Н.6. Открытие сеанса с ОО (FTA_TSE)

Семейство FTA_TSE определяет требования по запрещению пользователям открытия сеанса с ОО на основе таких атрибутов, как место или порт доступа, атрибуты безопасности пользователя (например, идентификатора, уровня допуска, уровня целостности, принадлежности к роли), интервалы времени (например, время суток, день недели, календарные даты) или сочетания параметров.

Замечания для пользователя

Это семейство предоставляет автору ПЗ/ЗБ возможность специфицировать требования к ФБО с целью установить ограничения на способность уполномоченного пользователя открывать сеанс с ОО. Идентификация соответствующих ограничений может быть выполнена с применением операции выбора. Примерами атрибутов, которые можно использовать для установки ограничений на открытие сеанса, являются следующие:

а) место доступа, которое может использоваться для ограничения способности пользователя открывать активный сеанс с ОО на основе места расположения пользователя или порта доступа. Эта возможность особенно рекомендуется при использовании телефонных линий или сетевых средств;

б) атрибуты безопасности пользователя. Например, запретить открытие сеанса можно на основе любого из следующих атрибутов пользователя:

— идентификатор;

— уровень допуска;

— уровень прав на модификацию данных (уровень целостности);

— принадлежность к роли.

Эта возможность особенно применима в случае, когда авторизация или вход может происходить не в том месте, где выполняется проверка доступа к ОО:

в) время доступа может использоваться для ограничения возможности пользователя открыть активный сеанс с ОО на основе интервалов времени. Например, ограничения могут быть основаны на времени суток, дне недели, календарных датах. Это ограничение предоставляет определенную защиту от действий пользователя в то время, когда могут не применяться необходимые процедурные меры или мониторинг.

FTA_TSE.1. Открытие сеанса с ОО

Операции

Назначение

В FTA_TSE.1.1 автору ПЗ/ЗБ следует специфицировать атрибуты, которые могут быть использованы для ограничения открытия сеанса. Примеры возможных атрибутов: идентификатор пользователя, место доступа (например, не с удаленного терминала), время доступа (например, неурочное), метод доступа (например, X-windows).

Приложение П
(справочное)

ДОВЕРЕННЫЙ МАРШРУТ/КАНАЛ (FTP)

Пользователям часто необходимо выполнять свои функции, непосредственно взаимодействуя с ФБО. Доверенный маршрут обеспечивает уверенность в том, что пользователь взаимодействует непосредственно с ФБО независимо от места своего расположения. Ответ пользователя через доверенный маршрут гарантирует, что недоверенные приложения не смогут перехватить или модифицировать сообщение пользователя. Со своей стороны, доверенные каналы являются одним из способов безопасной связи между ФБО и удаленными продуктами ИТ.

На рисунке 1.2 показаны взаимоотношения между различными типами передачи сообщений, которые могут иметь место в ОО или в сети из ОО и внешних объектов ИТ (то есть внутренние передачи ОО, передачи между ФБО, импорт/экспорт из/в ОДФ), и различные формы доверенных маршрутов и каналов.

Отсутствие доверенного маршрута может привести к нарушениям учета или управления доступом в средах с недоверенными приложениями. Эти приложения могут перехватить приватную информацию пользователя, такую как пароли, и выдавать себя за других пользователей, используя эту информацию. Как следствие, ответственность за любые действия в системе не может быть надежно связана с учитываемыми сущностями. Кроме того, эти приложения могут выводить ошибочную информацию на дисплеи не подозревающих об этом пользователей, что может привести к ошибочным действиям пользователей и, как следствие, к нарушению безопасности.

Декомпозиция класса FTP на составляющие его компоненты приведена на рисунке П.1.

Рисунок П.1. Декомпозиция класса «Доверенный маршрут/канал»

П.1. Доверенный канал передачи между ФБО (FTP_ITC)

Семейство FTP_ITC определяет правила создания соединения через доверенный канал между ФБО и другими доверенными продуктами ИТ для выполнения операций, критичных для безопасности, между продуктами. Примером такой критичной для безопасности операции является обновление базы данных аутентификации ФБО посредством передачи данных от доверенного продукта, функцией которого является накопление данных аудита.

FTP_ITC.1. Доверенный канал передачи между ФБО

Замечания по применению пользователю

Компонент FTP_ITC.1 следует использовать, когда требуется доверенный канал передачи между ФБО и удаленным доверенным продуктом ИТ.

Операции

Выбор

В FTP_ITC.1.2 автору ПЗ/ЗБ следует специфицировать, должны ли локальные ФБО, удаленный доверенный продукт ИТ или они иметь возможность инициировать доверенный канал.

Назначение

В FTP_ITC.1.3 автору ПЗ/ЗБ следует специфицировать функции, для которых требуется доверенный канал. К таким функциям могут относиться передача атрибутов безопасности пользователя, субъекта и/или объекта и обеспечение согласованности данных ФБО.

П.2. Доверенный маршрут (FTP_TRP)

Семейство FTP_TRP определяет требования установки и поддержания доверенной связи между пользователями и ФБО. Доверенный маршрут может потребоваться для любого связанного с безопасностью взаимодействия. Обмен по доверенному маршруту может быть инициирован пользователем при взаимодействии с ФБО, или же сами ФБО могут установить связь с пользователем по доверенному маршруту.

FTP_TRP.1. Доверенный маршрут

Замечания по применению пользователю

Компонент FTP_TRP.1 следует использовать, когда требуется доверенная связь между пользователем и ФБО как для целей начальной аутентификации, так и для дополнительно специфицированных действий пользователя.

Операции

Выбор

В FPT_TRP.1.1 автору ПЗ/ЗБ следует специфицировать, необходимо ли предоставлять доверенный маршрут удаленным и/или локальным пользователям.

В FTP_TRP.1.2 автору ПЗ/ЗБ следует специфицировать, кому предоставлять возможность инициировать доверенный маршрут: ФБО, локальным пользователям и/или удаленным пользователям.

В FTP_TRP.1.3 автору ПЗ/ЗБ следует специфицировать, использовать ли доверенный маршрут для начальной аутентификации пользователя и/или для других специфицированных услуг.

Назначение

В FTP_TRP.1.3 автору ПЗ/ЗБ следует идентифицировать другие услуги, для которых требуется доверенный маршрут, если такие предполагаются.

Часть 3. Требования доверия к безопасности

1. Область применения

Эта часть ОК определяет требования доверия к безопасности и включает в себя оценочные уровни доверия (ОУД), определяющие шкалу для измерения доверия, собственно компоненты доверия, из которых составлены уровни доверия, и критерии для оценки ПЗ и ЗБ.

1.1 Структура

Часть 3 ОК состоит из следующих разделов:

1 — введение и парадигма;

2 — структура представления классов, семейств и компонентов доверия, оценочных уровней доверия и их взаимосвязь, а также краткая характеристика классов и семейств доверия, представленных в разделах 8-14;

3-5 — краткое введение в критерии оценки ПЗ и ЗБ, сопровождаемое детализированными объяснениями семейств и компонентов, которые применяют для этих оценок;

6 — детализированные определения оценочных уровней доверия;

7 — краткое введение в классы доверия;

8-14 — детализированные определения классов доверия;

15-16 — краткое введение в критерии оценки поддержки доверия с детализированными определениями применяемых семейств и компонентов.

Приложение A содержит сводку зависимостей между компонентами доверия.

Приложение Б содержит перекрестные ссылки между ОУД и компонентами доверия.

1.2 Парадигма доверия

Цель данного подраздела состоит в изложении основных принципов и подходов к установлению доверия к безопасности. Данный подраздел позволит читателю понять логику построения требований доверия в ОК.

1.2.1 Основные принципы ОК

Основные принципы ОК состоят в том, что следует четко сформулировать угрозы безопасности и положения политики безопасности организации, а достаточность предложенных мер безопасности должна быть продемонстрирована.

Более того, следует предпринять меры по уменьшению вероятности наличия уязвимостей, возможности их проявления (т.е. преднамеренного использования или непреднамеренной активизации), а также степени ущерба, который может явиться следствием проявления уязвимостей. Дополнительно следует предпринять меры для облегчения последующей идентификации уязвимостей, а также по их устранению, ослаблению и/или оповещению об их использовании или активизации.

1.2.2 Подход к доверию

Основная концепция ОК — обеспечение доверия, основанное на оценке (активном исследовании) продукта или системы ИТ, которым предполагается доверять. Оценка была традиционным способом обеспечения доверия и являлась основой предшествующих критериев оценки. Для согласования с существующими подходами в ОК принят тот же самый основной принцип. ОК предполагают, что проверку правильности документации и разработанного продукта или системы ИТ будут проводить опытные оценщики, уделяя особое внимание области, глубине и строгости оценки.

ОК не отрицают и при этом не комментируют относительные достоинства других способов получения доверия. Продолжаются исследования альтернативных путей достижения доверия. Если в результате этих исследований будут выявлены другие отработанные альтернативные подходы, то они могут в дальнейшем быть включены в ОК, которые структурно организованы так, что предусматривают такую возможность.

1.2.2.1 Значимость уязвимостей

Предполагается, что имеются нарушители, которые будут пытаться активно использовать возможности нарушения политики безопасности как для получения незаконной выгоды, так и для незлонамеренных, но, тем не менее, опасных действий. Нарушители могут также случайно активизировать уязвимости безопасности, нанося вред организации. При необходимости обрабатывать чувствительную информацию и отсутствии в достаточной степени доверенных продуктов или систем имеется значительный риск из-за отказов ИТ. Поэтому нарушения безопасности ИТ могут вызвать значительные потери.

Нарушения безопасности ИТ возникают вследствие преднамеренного использования или случайной активизации уязвимостей при применении ИТ по назначению.

Следует предпринять ряд шагов для предотвращения уязвимостей, возникающих в продуктах и системах ИТ. По возможности уязвимости должны быть:

а)устранены, т.е. следует предпринять активные действия для выявления, а затем удаления или нейтрализации всех уязвимостей, которые могут проявиться;

б)минимизированы, т.е. следует предпринять активные действия для уменьшения до допустимого остаточного уровня возможного ущерба от любого проявления уязвимостей;

в)отслежены, т.е. следует предпринять активные действия для обнаружения любой попытки использовать оставшиеся уязвимости с тем, чтобы ограничить ущерб.

1.2.2.2 Причины уязвимостей

Уязвимости могут возникать из-за недостатков:

а) требований, т.е. продукт или система ИТ могут обладать требуемыми от них функциями и свойствами, но все же содержать уязвимости, которые делают их непригодными или неэффективными в части безопасности;

б) проектирования, т.е. продукт или система ИТ не отвечают спецификации, и/или уязвимости являются следствием некачественных стандартов проектирования или неправильных проектных решений;

в) эксплуатации, т.е. продукт или система ИТ разработаны в полном соответствии с корректными спецификациями, но уязвимости возникают как результат неадекватного управления при эксплуатации.

1.2.2.3 Доверие в ОК

Доверие — основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие могло бы быть получено путем обращения к таким источникам, как бездоказательное утверждение, предшествующий аналогичный опыт или специфический опыт. Однако ОК обеспечивают доверие с использованием активного исследования. Активное исследование — это оценка продукта или системы ИТ для определения его свойств безопасности.

1.2.2.4 Доверие через оценку

Оценка является традиционным способом достижения доверия, и она положена в основу ОК. Методы оценки могут, в частности, включать в себя:

а) анализ и проверку процессов и процедур;

б) проверку, что процессы и процедуры действительно применяются;

в) анализ соответствия между представлениями проекта ОО;

г) анализ соответствия каждого представления проекта ОО требованиям;

д) верификацию доказательств;

е) анализ руководств;

ж) анализ разработанных функциональных тестов и полученных результатов;

и) независимое функциональное тестирование;

к) анализ уязвимостей, включающий предположения о недостатках;

л) тестирование проникновения.

1.2.3 Шкала оценки доверия в ОК

Основные принципы ОК содержат утверждение, что большее доверие является результатом приложения больших усилий при оценке, и что цель состоит в применении минимальных усилий, требуемых для обеспечения необходимого уровня доверия. Повышение уровня усилий может быть основано на:

а) области охвата, т.е. увеличении рассматриваемой части продукта или системы ИТ;

б) глубине, т.е. детализации рассматриваемых проектных материалов и реализации;

в) строгости, т.е. применении более структурированного и формального подхода.

2. Требования доверия к безопасности

2.1 Структуры

Следующие подразделы описывают конструкции, используемые в представлении классов, семейств и компонентов доверия, оценочных уровней доверия (ОУД), и их взаимосвязь.

На рисунке 2.1 показаны требования доверия, определенные в части 3 ОК. Наиболее общую совокупность требований доверия называют классом. Каждый класс содержит семейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия. Классы и семейства используют для обеспечения таксономии классифицируемых требований доверия, в то время как компоненты применяют непосредственно для спецификации требований доверия в ПЗ/ЗБ.

Рисунок 2.1. Иерархическая структура представления требований доверия: класс-семейство-компонент-элемент

2.1.1 Структура класса

Рисунок 2.1 иллюстрирует структуру класса доверия.

2.1.1.1 Имя класса

Каждому классу доверия присвоено уникальное имя. Имя указывает на тематические разделы, на которые распространяется данный класс доверия.

Представлена также уникальная краткая форма имени класса доверия. Она является основным средством для ссылки на класс доверия. Принятое условное обозначение включает в себя букву «A», за которой следуют еще две буквы латинского алфавита, относящиеся к имени класса.

2.1.1.2 Представление класса

Каждый класс доверия имеет вводный подраздел, в котором описаны состав и назначение класса.

2.1.1.3 Семейства доверия

Каждый класс доверия содержит, по меньшей мере, одно семейство доверия. Структура семейств доверия описана в следующем пункте.

2.1.2 Структура семейства доверия

Рисунок 2.1 иллюстрирует структуру семейства доверия.

2.1.2.1 Имя семейства

Каждому семейству доверия присвоено уникальное имя. Имя содержит описательную информацию по тематическим разделам, на которые распространяется данное семейство доверия. Каждое семейство доверия размещено в пределах класса доверия, который содержит другие семейства той же направленности.

Представлена также уникальная краткая форма имени семейства доверия. Она является основным средством для ссылки на семейство доверия. Принятое условное обозначение включает в себя краткую форму имени класса и символ подчеркивания, за которым следуют три буквы латинского алфавита, относящиеся к имени семейства.

2.1.2.2 Цели

Подраздел целей семейства доверия представляет назначение семейства доверия.

В нем описаны цели, для достижения которых предназначено семейство, особенно связанные с парадигмой доверия ОК. Описание целей для семейства доверия представлено в общем виде. Любые конкретные подробности, требуемые для достижения целей, включены в конкретный компонент доверия.

2.1.2.3 Ранжирование компонентов

Каждое семейство доверия содержит один или несколько компонентов доверия. Этот подраздел семейства доверия содержит описание имеющихся компонентов и объяснение их разграничения. Его основная цель состоит в указании различий между компонентами при принятии решения о том, что семейство является необходимой или полезной частью требований доверия для ПЗ/ЗБ.

В семействах доверия, содержащих более одного компонента, выполнено ранжирование компонентов и приведено его обоснование. Это обоснование сформулировано в терминах области применения, глубины и/или строгости.

2.1.2.4 Замечания по применению

Необязательный подраздел замечаний по применению семейства доверия содержит дополнительную информацию о семействе. Эта информация предназначена непосредственно для пользователей семейства доверия (например, разработчиков ПЗ и ЗБ, проектировщиков ОО, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.

2.1.2.5 Компоненты доверия

Каждое семейство содержит хотя бы один компонент доверия. Структура компонентов доверия представлена в следующем пункте.

2.1.3 Структура компонента доверия

Рисунок 2.2 иллюстрирует структуру компонента доверия.

Рисунок 2.2. Структура компонента доверия

Связь между компонентами внутри семейства показана с использованием соглашения о шрифтовом выделении. Для частей требований, которые являются новыми, расширенными или модифицированными по сравнению с требованиями предыдущего по иерархии компонента, применен полужирный шрифт. Такое же соглашение о шрифтовом выделении использовано и для зависимостей.

2.1.3.1 Идентификация компонента

Подраздел идентификации компонента содержит описательную информацию, необходимую для идентификации, категорирования, регистрации и ссылок на компонент.

Каждому компоненту доверия присвоено уникальное имя. Имя содержит информацию о тематических разделах, на которые распространяется компонент доверия. Каждый компонент входит в состав конкретного семейства доверия, с которым имеет общую цель безопасности.

Представлена также уникальная краткая форма имени компонента доверия как основной способ ссылки на компонент. Принято, что за краткой формой имени семейства ставится точка, а затем цифра. Цифры для компонентов внутри каждого семейства назначены последовательно, начиная с единицы.

2.1.3.2 Цели

Необязательный подраздел целей компонента доверия содержит конкретные цели этого компонента. Для компонентов доверия, которые имеют этот подраздел, он включает в себя конкретное назначение данного компонента и подробное разъяснение целей.

2.1.3.3 Замечания по применению

Необязательный подраздел замечаний по применению компонента доверия содержит дополнительную информацию для облегчения использования компонента.

2.1.3.4 Зависимости

Зависимости среди компонентов доверия возникают, когда компонент не самодостаточен, а предполагает присутствие другого компонента.

Для каждого компонента доверия приведен полный список зависимостей от других компонентов доверия. При отсутствии у компонента идентифицированных зависимостей вместо списка указано: «Зависимости отсутствуют». Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов.

Список зависимостей определяет минимальный набор компонентов доверия, на которые следует полагаться. Компоненты, которые иерархичны по отношению к компоненту из списка зависимостей, также могут использоваться для удовлетворения зависимости.

В отдельных ситуациях обозначенные зависимости могут быть неприменимы. Разработчик ПЗ/ЗБ может отказаться от удовлетворения зависимости, представив обоснование, почему данная зависимость неприменима.

2.1.3.5 Элементы доверия

Каждый компонент доверия содержит набор элементов доверия. Элемент доверия — требование безопасности, при дальнейшем разделении которого не изменяется значимый результат оценки. Он является наименьшим требованием безопасности, распознаваемым в ОК.

Каждый элемент доверия принадлежит к одному из трех типов.

а) Элементы действий разработчика, определяющие действия, которые должны выполняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в следующем наборе элементов. Требования к действиям разработчика обозначены буквой «D» после номера элемента.

б) Элементы содержания и представления свидетельств, определяющие требуемые свидетельства и отражаемую в них информацию. Требования к содержанию и представлению свидетельств обозначены буквой «C» после номера элемента.

в) Элементы действий оценщика, определяющие действия, которые должны выполняться оценщиком. Этот набор действий непосредственно включает в себя подтверждение того, что требования, предписанные элементами содержания и представления свидетельств, выполнены, а также конкретные действия и анализ, выполняемые в дополнение к уже проведенным разработчиком. Должны также выполняться не указанные явно действия оценщика, необходимые вследствие элементов действий разработчика, но не охваченные в требованиях к содержанию и представлению свидетельств. Требования к действиям оценщика обозначены буквой «E» после номера элемента.

Действия разработчика, содержание и представление свидетельств определяют требования, предъявляемые к разработчику по демонстрации доверия к ФБО. Выполняя эти требования, разработчик может повысить уверенность в том, что ОО удовлетворяет функциональным требованиям и требованиям доверия из ПЗ или ЗБ.

Действия оценщика определяют его ответственность по двум аспектам. Первый аспект — проверка правильности ПЗ/ЗБ в соответствии с требованиями классов APE/ASE из разделов 4 и 5. Второй аспект — верификация соответствия ОО его функциональным требованиям и требованиям доверия. Демонстрируя, что ПЗ/ЗБ правильны, и их требования выполняются ОО, оценщик может предоставить основание для уверенности в том, что ОО будет отвечать поставленным целям безопасности.

Элементы действий разработчика, элементы содержания и представления свидетельств и элементы установленных действий оценщика определяют уровень его усилий, которые должны быть приложены при верификации утверждений о безопасности, сформулированных в ЗБ конкретного ОО.

2.1.4 Элементы доверия

Каждый элемент представляет собой требование для выполнения. Формулировки этих требований должны быть четкими, краткими и однозначными. Поэтому в требованиях отсутствуют составные предложения. Каждое требование изложено как отдельный элемент.

В тексте элементов использованы, как правило, термины, имеющие обычное словарное значение, которые не могут привести к неоднозначному толкованию требований.

В отличие от функциональных элементов из части 2 ОК к элементам доверия из части 3 ОК не применимы операции назначения и выбора; однако, при необходимости, допустимо применение операции уточнения.

2.1.5 Структура ОУД

Рисунок 2.3 иллюстрирует ОУД и их структуру, определенную в части 3 ОК. Компоненты доверия, содержание которых показано на рисунке, включены в ОУД посредством ссылок на компоненты, приведенные в части 3 ОК.

Рисунок 2.3. Структура ОУД

2.1.5.1 Имя ОУД

Каждому ОУД присвоено уникальное имя. Имя представляет описательную информацию о предназначении ОУД.

Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД.

2.1.5.2 Цели

В подразделе целей ОУД приведено назначение ОУД.

2.1.5.3 Замечания по применению

Необязательный подраздел замечаний по применению ОУД содержит информацию, представляющую интерес для пользователей ОУД (например, для разработчиков ПЗ и ЗБ, проектировщиков ОО, планирующих использование этого ОУД, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.

Рисунок 2.4. Связь требований и уровня доверия

2.1.5.4 Компоненты доверия

Для каждого ОУД выбран набор компонентов доверия.

Более высокий уровень доверия, чем предоставляемый данным ОУД, может быть достигнут:

а) включением дополнительных компонентов доверия из других семейств доверия;

б) заменой компонента доверия иерархичным компонентом из этого же семейства доверия.

2.1.6 Связь между требованиями и уровнями доверия

Рисунок 2.4 иллюстрирует связь между требованиями и уровнями доверия, определенными в части 3 ОК. Компоненты доверия состоят из элементов, но последние не могут по отдельности быть включены в уровни доверия. Стрелка на рисунке отображает ссылку в ОУД на компонент доверия внутри класса, где он определен.

2.2 Классификация компонентов

Часть 3 ОК содержит классы семейств и компонентов, которые сгруппированы на основе, связанной с доверием. В начале каждого класса представлена диаграмма, которая указывает семейства в классе и компоненты в каждом семействе.

На рисунке 2.5 показан класс, содержащий одно семейство. Семейство содержит три компонента, которые являются линейно иерархичными (т.е. компонент 2 содержит более высокие требования, чем компонент 1, к конкретным действиям, приводимым свидетельствам или строгости действий и/или свидетельств). Все семейства доверия в части 3 ОК — линейно иерархичные, хотя линейность не обязательна для семейств доверия, которые могут быть добавлены в дальнейшем.

Рисунок 2.5 — Образец декомпозиции класса

2.3 Структура класса критериев оценки профиля защиты и задания по безопасности

Требования для оценки профиля защиты и задания по безопасности трактуют как классы доверия, структура которых подобна структуре других классов доверия, описанных ниже. Отличие заключается в отсутствии подраздела ранжирования компонентов в описаниях семейств и вызвано тем, что каждое семейство имеет только один компонент.

В таблицах 3.1-3.4 приведены названия каждого из классов APE и ASE, составляющих их семейств и их краткие имена. Содержание разделов ПЗ, рассматриваемых в семействах класса APE, представлено в части 1 ОК, приложение Б, подразделы Б.2.2-Б.2.6, а разделов ЗБ, рассматриваемых в семействах класса ASE, — в части 1 ОК, приложение В, подразделы В.2.2-В.2.8.

2.4 Использование терминов в части 3 ОК

В части 3 ОК определенным образом используются термины, список которых приведен ниже. Они не включены в глоссарий ОК (раздел 2 части 1 ОК), потому что являются общеупотребительными терминами, и их использование, хотя и ограничено приведенными разъяснениями, согласуется со словарными определениями. Однако именно такое толкование терминов применялось при разработке части 3 ОК, и поэтому оно полезно для понимания. В скобках приведены эквиваленты терминов на английском языке.

верифицировать(verify): Аналогичен термину «подтверждать» («confirm»), но имеет более глубокий смысл. При использовании в контексте действий оценщика указывает, что требуются независимые усилия оценщика.

взаимно поддерживающие (mutually supportive): Описывает взаимосвязь в группе сущностей, указывая, что последние обладают некоторыми свойствами, которые не находятся в противоречии со свойствами других сущностей и могут способствовать выполнению другими сущностями их задач. Нет необходимости определять, что каждая из рассматриваемых отдельных сущностей непосредственно поддерживает другие сущности в этой группе; достаточно, если сделано обобщенное заключение.

внутренне непротиворечивый (internally consistent): Отсутствуют очевидные противоречия между любыми аспектами сущности. Применительно к документации это означает, что в ней не может быть изложено что-либо, что может быть воспринято как противоречащее чему-то другому.

делать (независимое) заключение (determine): Требуется независимый анализ для достижения конкретного заключения. Термин отличается от «подтверждать»(«confirm») или «верифицировать»(«verify»), так как последние подразумевают, что требует проверки анализ, проведенный ранее, в то время как «делать (независимое) заключение» подразумевает совершенно независимый анализ, обычно при отсутствии любого предшествующего анализа.

демонстрировать (demonstrate): Относится к анализу, который приводит к заключению, но является менее строгим, чем «доказательство» («proof»).

доказывать (prove): Относится к формальному анализу в математическом смысле, полностью строгий во всех отношениях. Обычно используется, когда желательно показать соответствие между двумя представлениями ФБО на высоком уровне строгости.

исчерпывающий (exhaustive): Используется применительно к проведению анализа или другой деятельности. Аналогичен термину «систематический» («systematic»), но более точен, так как указывает не только на то, что в соответствии с некоторым конкретным планом проведения анализа или другой деятельности был применен методический подход, но также и на то, что этот план достаточен для обеспечения проведения исследования по всем возможным направлениям.

логически упорядоченный (coherent): Сущность логически упорядочена и имеет очевидный смысл. Применительно к документации этот термин относится как к тексту, так и к структуре, указывая, что они понятны потенциальной аудитории.

непротиворечивый (consistent): Описывает связь между двумя или более сущностями, указывая, что между ними нет никаких явных противоречий.

обеспечивать (ensure): Подразумевает сильную причинно-следственную связь между некоторым действием и его последствиями. Часто ему предшествует термин «способствует» («helps»), указывающий, что одно данное действие не полностью определяет последствия.

объяснять (explain): Отличается от терминов «описывать» («describe») и «демонстрировать» («demonstrate»). Предназначен для ответа на вопрос «Почему?» без попытки аргументировать, что ход предпринимаемых действий обязательно оптимален.

описывать (describe): Требует, чтобы некоторые конкретные подробности сущности были представлены.

подтверждать (confirm): Используется для указания необходимости подробного рассмотрения чего-либо; при этом требуется независимое заключение о его достаточности. Требуемый уровень строгости зависит от характера предмета. Применим только к действиям оценщика.

полный (complete): Представлены все необходимые составляющие сущности. Применительно к документации это означает, что приведена вся необходимая информация, причем настолько детально, что на данном уровне абстракции дальнейшие пояснения не требуются.

проверять (check): Аналогичен, но менее строг, чем «подтверждать»(«confirm») или «верифицировать»(«verify»). Требует, чтобы оценщиком было сделано оперативное заключение, возможно лишь с поверхностным анализом или вообще без него.

прослеживать или сопоставлять (trace): Используется для указания, что между двумя сущностями требуется только минимальный уровень строгости неформального соответствия.

противостоять (counter): Используется в том смысле, что некоторая цель безопасности заключается в противостоянии конкретной угрозе, но не обязательно указывает в итоге на полную ее ликвидацию.

специфицировать или определять (specify): Используется в том же контексте, что и «описывать» («describe»), но является более строгим и точным. Аналогичен термину «определять» («define»).

строгое обоснование (justification): Относится к анализу, ведущему к заключению, но является более строгим, чем термин «демонстрация» («demonstration»), в смысле точных и подробных объяснений каждого шага логических суждений.

2.5 Классификация доверия

Классы и семейства доверия, а также их краткие имена приведены в таблице 2.1.

Таблица 2.1

СЕМЕЙСТВА ДОВЕРИЯ

2.6 Краткий обзор классов и семейств доверия

Ниже приведены краткие характеристики классов и семейств доверия из разделов 8-14.

2.6.1 Класс ACM: Управление конфигурацией

Управление конфигурацией (УК) помогает обеспечить сохранение целостности ОО, устанавливая и контролируя определенный порядок процессов уточнения и модификации ОО и предоставления связанной с ними информации. УК предотвращает несанкционированную модификацию, добавление или уничтожение составляющих ОО, обеспечивая тем самым доверие, что оцениваются именно те ОО и документация, которые подготовлены к распространению.

2.6.1.1 Автоматизация УК (ACM_AUT)

Семейство «Автоматизация управления конфигурацией» устанавливает уровень автоматизации, используемый для управления элементами конфигурации.

2.6.1.2 Возможности УК (ACM_CAP)

Семейство «Возможности управления конфигурацией» определяет характеристики системы управления конфигурацией.

2.6.1.3 Область УК (ACM_SCP)

Семейство «Область управления конфигурацией» указывает на те элементы ОО, для которых необходим контроль со стороны системы управления конфигурацией.

2.6.2 Класс ADO. Поставка и эксплуатация

Класс доверия ADO определяет требования к мерам, процедурам и стандартам, применяемым для безопасной поставки, установки и эксплуатации ОО, обеспечивая, чтобы безопасность ОО не нарушалась во время его распространения, установки и эксплуатации.

2.6.2.1 Поставка (ADO_DEL)

Семейство «Поставка» распространяется на процедуры, используемые для поддержки безопасности во время передачи ОО пользователю при первоначальной поставке и последующих модификациях. Оно включает в себя специальные процедуры или действия, необходимые для демонстрации подлинности поставленного ОО. Такие процедуры и меры — основа обеспечения безопасности ОО во время передачи. Несмотря на то, что при оценке ОО не всегда может быть определено его соответствие требованиям поставки, можно оценить процедуры, предусмотренные разработчиком для распространения ОО пользователям.

2.6.2.2 Установка, генерация и запуск (ADO_IGS)

Семейство «Установка, генерация и запуск» предусматривает, чтобы копия ОО была конфигурирована и активизирована администратором так, чтобы показать те же самые свойства защиты, что и у оригинала ОО. Процедуры установки, генерации и запуска предоставляют уверенность в том, что администратор будет осведомлен о параметрах конфигурации ОО и о том, как они способны повлиять на ФБО.

2.6.3 Класс ADV. Разработка

Класс доверия ADV определяет требования для пошагового уточнения ФБО, начиная с краткой спецификации ОО в ЗБ и вплоть до фактической реализации. Каждое из получаемых представлений ФБО содержит информацию, помогающую оценщику решить, были ли выполнены функциональные требования к ОО.

2.6.3.1 Функциональная спецификация (ADV_FSP)

Функциональная спецификация описывает ФБО, и необходимо, чтобы она была полным и точным отображением функциональных требований безопасности ОО. Функциональная спецификация также детализирует внешний интерфейс ОО. Предполагают, что пользователи ОО взаимодействуют с ФБО через этот интерфейс.

2.6.3.2 Проект верхнего уровня (ADV_HLD)

Проект верхнего уровня — проектная спецификация самого высокого уровня, которая уточняет функциональную спецификацию ФБО в основных составляющих частях ФБО. Проект верхнего уровня идентифицирует базовую структуру ФБО, а также основные элементы аппаратных, программных и программно-аппаратных средств.

2.6.3.3 Представление реализации (ADV_IMP)

Представление реализации — наименее абстрактное представление ФБО. Оно фиксирует детализированное внутреннее содержание ФБО на уровне исходного текста, аппаратных схем и т.д.

2.6.3.4 Внутренняя структура ФБО (ADV_INT)

Требования к внутренней структуре ФБО определяют необходимое внутреннее структурирование ФБО.

2.6.3.5 Проект нижнего уровня (ADV_LLD)

Проект нижнего уровня — детализированная проектная спецификация, уточняющая проект верхнего уровня до уровня детализации, который может быть использован как основа для программирования и/или проектирования аппаратуры.

2.6.3.6 Соответствие представлений (ADV_RCR)

Соответствие представлений — демонстрация отображения между всеми смежными парами имеющихся представлений ФБО, от краткой спецификации ОО до наименее абстрактного из имеющихся представлений ФБО.

2.6.3.7 Моделирование политики безопасности (ADV_SPM)

Модели политики безопасности — структурные представления политик безопасности ПБО, используемые для обеспечения повышенного доверия, что функциональная спецификация соответствует политикам безопасности из ПБО и, в конечном счете, функциональным требованиям безопасности ОО. Это достигается посредством определения соответствия между функциональной спецификацией, моделью политики безопасности и моделируемыми политиками безопасности.

2.6.4 Класс AGD. Руководства

Класс доверия AGD определяет требования, направленные на обеспечение понятности, достаточности и законченности эксплуатационной документации, представляемой разработчиком. Эта документация, которая содержит две категории информации (для пользователей и администраторов), является важным фактором безопасной эксплуатации ОО.

2.6.4.1 Руководство администратора (AGD_ADM)

Требования к руководству администратора способствуют обеспечению, что ограничения среды будут поняты администраторами и операторами ОО. Руководство администратора — основное средство, имеющееся в распоряжении разработчика, для предоставления администраторам ОО детальной и точной информации о том, как осуществлять администрирование ОО безопасным способом и эффективно использовать привилегии ФБО и функции защиты.

2.6.4.2 Руководство пользователя (AGD_USR)

Требования к руководству пользователя способствуют обеспечению, что пользователи могут эксплуатировать ОО безопасным способом (например, ограничения использования, предусмотренные ПЗ или ЗБ, необходимо четко объяснить и проиллюстрировать). Руководство — основное средство, имеющееся в распоряжении разработчика, для предоставления пользователям ОО необходимой общей и специфической информации о том, как правильно использовать функции защиты ОО. В руководстве необходимо осветить два аспекта. Во-первых, требуется объяснить, что делают доступные пользователю функции безопасности, и как они будут использоваться, чтобы пользователи имели возможность последовательно и действенно защищать свою информацию. Во-вторых, требуется разъяснить роль пользователя в поддержании безопасности ОО.

2.6.5 Класс ALC. Поддержка жизненного цикла

Класс доверия ALC определяет требования доверия посредством принятия для всех этапов разработки ОО четко определенной модели жизненного цикла, включая политики и процедуры устранения недостатков, правильное использование инструментальных средств и методов, а также меры безопасности для защиты среды разработки.

2.6.5.1 Безопасность разработки (ALC_DVS)

Семейство «Безопасность разработки» охватывает физические, процедурные, относящиеся к персоналу и другие меры безопасности, используемые применительно к среде разработки. Оно также содержит требования к физической безопасности местоположения разработки и к контролю за отбором и наймом персонала разработчиков.

2.6.5.2 Устранение недостатков (ALC_FLR)

Семейство «Устранение недостатков» обеспечивает, чтобы недостатки, обнаруженные потребителями ОО, отслеживались и исправлялись, пока ОО сопровождается разработчиком. Несмотря на то, что при оценке ОО не может быть принято решение о потенциальном соответствии требованиям устранения недостатков, можно оценить политики и процедуры, которые разработчик предусмотрел для выявления и устранения недостатков и распространения исправлений потребителям.

2.6.5.3 Определение жизненного цикла (ALC_LCD)

Семейство «Определение жизненного цикла» устанавливает, что технология разработки, используемая разработчиком для создания ОО, включает в себя положения и действия, указанные в требованиях к процессу разработки и поддержке эксплуатации. Уверенность в соответствии ОО требованиям больше, когда анализ безопасности и подготовка свидетельств осуществляются на регулярной основе как неотъемлемая часть процесса разработки и поддержки эксплуатации. В задачи этого семейства не входит предопределение какого-либо конкретного процесса разработки.

2.6.5.4 Инструментальные средства и методы (ALC_TAT)

Семейство «Инструментальные средства и методы» связано с необходимостью определения инструментальных средств разработки, используемых для анализа и создания ОО. Сюда включены требования, относящиеся к инструментальным средствам разработки и опциям этих инструментальных средств, зависящим от реализации.

2.6.6 Класс ATE. Тестирование

Класс доверия ATE устанавливает требования к тестированию, которое демонстрирует, что ФБО удовлетворяют функциональным требованиям безопасности ОО.

2.6.6.1 Покрытие (ATE_COV)

Семейство «Покрытие» имеет дело с полнотой функциональных тестов, выполненных разработчиком для ОО. Оно связано со степенью тестирования функций безопасности ОО.

2.6.6.2 Глубина (ATE_DPT)

Семейство «Глубина» имеет дело с уровнем детализации, на котором разработчик проверяет ОО. Тестирование функций безопасности основано на увеличивающейся глубине информации, получаемой из анализа представлений ФБО.

2.6.6.3 Функциональное тестирование (ATE_FUN)

Семейство «Функциональное тестирование» устанавливает, что ФБО действительно демонстрируют свойства, необходимые для удовлетворения требований своего ЗБ. Функциональное тестирование обеспечивает доверие, что ФБО удовлетворяют, по меньшей мере, требованиям выбранных функциональных компонентов. Однако функциональные тесты не устанавливают, что ФБО не выполняют больше, чем от них ожидается. Это семейство сосредоточено на функциональном тестировании, выполняемом разработчиком.

2.6.6.4 Независимое тестирование (ATE_IND)

Семейство «Независимое тестирование» определяет степень выполнения функционального тестирования ОО кем-либо, кроме разработчика (например, третьей стороной). Это семейство повышает ценность тестирования добавлением тестов, которые дополняют тесты разработчика.

2.6.7 Класс AVA. Оценка уязвимостей

Класс доверия AVA определяет требования, направленные на идентификацию уязвимостей, которые могут быть активизированы. Особое внимание уделено уязвимостям, которые вносятся при проектировании, эксплуатации, неправильном применении или неверной конфигурации ОО.

2.6.7.1 Анализ скрытых каналов (AVA_CCA)

Семейство «Анализ скрытых каналов» направлено на выявление и анализ непредусмотренных коммуникационных каналов, которые могут применяться для нарушения предписанной ПБО.

2.6.7.2 Неправильное применение (AVA_MSU)

Семейство «Анализ неправильного применения» позволяет выяснить, способен ли администратор или пользователь, используя руководства, определить, что ОО конфигурирован или эксплуатируется небезопасным способом.

2.6.7.3 Стойкость функций безопасности ОО (AVA_SOF)

Анализ стойкости направлен на функции безопасности ОО, которые реализованы с помощью вероятностного или перестановочного механизма (например, пароля или хэш-функции). Даже если такие функции нельзя обойти, отключить или исказить, не исключено, что их все же можно преодолеть прямой атакой. Может быть заявлен уровень или специальная метрика стойкости для каждой из этих функций. Анализ стойкости функций выполняют для принятия решения, отвечают ли такие функции сделанным заявлениям. Например, анализ стойкости механизма пароля может, показав достаточность области задания пароля, продемонстрировать, что функция, использующая этот механизм, отвечает заявленной стойкости.

2.6.7.4 Анализ уязвимостей (AVA_VLA)

Анализ уязвимостей заключается в идентификации недостатков, которые могли быть внесены на различных этапах разработки. В результате определяются тесты проникновения, позволяющие получить всю совокупность необходимой информации относительно:

1) полноты ФБО (противостоят ли ФБО всем ожидаемым угрозам?);

2) зависимостей между всеми функциями безопасности.

Эти потенциальные уязвимости оценивают посредством тестирования проникновения, позволяющим сделать заключение, могут ли они в действительности быть использованы для нарушения безопасности ОО.

2.7 Классификация поддержки

Требования по поддержке доверия, трактуемые как класс доверия, представлены с использованием структуры класса, определенной выше.

Семейства поддержки доверия и их краткие имена приведены в таблице 2.2.

Таблица 2.2

ДЕКОМПОЗИЦИЯ КЛАССА AMA «ПОДДЕРЖКА ДОВЕРИЯ»

2.8 Краткий обзор класса и семейств поддержки доверия

Ниже приведены краткие характеристики класса и семейств поддержки доверия из раздела 16.

2.8.1 Класс AMA. Поддержка доверия

Класс AMA предназначен для поддержки уровня доверия, что ОО продолжит отвечать своему ЗБ при изменениях в ОО или его среде. Каждое из семейств этого класса определяет действия разработчика и оценщика, выполняемые после того, как ОО был успешно оценен, хотя некоторые требования применимы и при оценке.

2.8.1.1 План поддержки доверия (AMA_AMP)

Семейство «План поддержки доверия» идентифицирует планы и процедуры, которые выполняет разработчик для обеспечения поддержки доверия, установленного к оцененному ОО, после изменений в ОО или его среде.

2.8.1.2 Отчет о категорировании компонентов ОО (AMA_CAT)

Семейство «Отчет о категорировании компонентов ОО» представляет категорирование компонентов ОО (например, подсистем ФБО) по их отношению к безопасности. Это категорирование занимает центральное место в анализе разработчиком влияния на безопасность.

2.8.1.3 Свидетельство поддержки доверия (AMA_EVD)

Семейство «Свидетельство поддержки доверия» направлено на то, чтобы убедиться в поддержке разработчиком доверия к ОО в соответствии с планом поддержки доверия.

2.8.1.4 Анализ влияния на безопасность (AMA_SIA)

Семейство «Анализ влияния на безопасность» направлено на то, чтобы убедиться в поддержке доверия к ОО посредством проводимого разработчиком анализа влияния на безопасность ОО всех изменений после его оценки.

3. Критерии оценки профиля защиты и задания по безопасности

3.1 Краткий обзор

Настоящий раздел знакомит с критериями оценки для ПЗ и ЗБ, полностью представленными в классах APE «Оценка профиля защиты» и ASE «Оценка задания по безопасности» (разделы 4 и 5 соответственно).

Эти критерии — первые требования оценки, представленные в части 3 ОК, потому что, как правило, оценку ПЗ и ЗБ выполняют до оценки ОО. Они играют особую роль в оценке информации об ОО и оценке функциональных требований и требований доверия для выяснения, являются ли ПЗ и ЗБ содержательной основой для оценки ОО.

Хотя данные критерии оценки несколько отличаются от требований в разделах 8-14, они представлены аналогичным образом, потому что действия разработчика и оценщика при оценке сопоставимы для ПЗ, ЗБ и ОО.

Классы для ПЗ и ЗБ отличаются от классов для ОО тем, что при оценке ПЗ или ЗБ необходимо учесть все требования классов для ПЗ или ЗБ соответственно, в то время как далеко не все требования, представленные в классах для ОО, придется учитывать при оценке конкретного ОО.

Критерии оценки для ПЗ и ЗБ основаны на информации, приведенной в приложениях Б и В к части 1 ОК. Там можно найти полезную информацию о происхождении требований классов APE и ASE.

3.2 Краткий обзор критериев профиля защиты

3.2.1 Оценка профиля защиты

Цель оценки ПЗ — показать, что он является полным, непротиворечивым, технически правильным и поэтому пригоден для изложения требований к одному или нескольким оцениваемым ОО. Такой ПЗ может быть приемлем для включения в реестр ПЗ.

3.2.2 Соотношение с критериями оценки задания по безопасности

Как показано в приложениях Б и В к части 1 ОК, имеется много совпадений в структуре и содержании ПЗ, ориентированного на определенный тип ОО, и ЗБ, разработанного для конкретного ОО. Поэтому многие критерии для оценки ПЗ содержат требования, которые подобны аналогичным для ЗБ и представлены таким же образом.

3.2.3 Задачи оценщика

Оценщики ПЗ, который содержит требования только из ОК, должны применять требования класса APE, приведенные в таблице 3.1.

Таблица 3.1

СЕМЕЙСТВА ОЦЕНКИ ПРОФИЛЯ ЗАЩИТЫ, СОДЕРЖАЩЕГО ТРЕБОВАНИЯ ТОЛЬКО ИЗ ОК

Оценщики ПЗ, который содержит требования не из ОК, должны применять требования класса APE, приведенные в таблице 3.2.

Таблица 3.2

СЕМЕЙСТВА ОЦЕНКИ ПРОФИЛЯ ЗАЩИТЫ С ТРЕБОВАНИЯМИ, РАСШИРЯЮЩИМИ ОК

3.3 Краткий обзор критериев задания по безопасности

3.3.1 Оценка задания по безопасности

Цель оценки ЗБ — показать, что оно является полным, непротиворечивым, технически правильным и поэтому пригодно для использования в качестве основы при оценке соответствующего ОО.

3.3.2 Соотношение с другими критериями оценки из ОК

При оценке ОО различают две стадии: оценка ЗБ и непосредственно оценка ОО, к которому относится данное ЗБ. Требования для оценки ЗБ полностью представлены в разделе 5, а требования для оценки ОО содержатся в разделах 8-14.

Оценка ЗБ включает в себя оценку утверждений о соответствии ПЗ. Если в ЗБ не утверждается соответствие ПЗ, то в части ЗБ «Утверждения о соответствии ПЗ» должно быть указано, что соответствие какому-либо ПЗ для ОО не утверждается.

3.3.3 Задачи оценщика

Оценщики ЗБ, которое содержит требования только из ОК, должны применять требования класса ASE, приведенные в таблице 3.3.

Таблица 3.3

СЕМЕЙСТВА ОЦЕНКИ ЗАДАНИЯ ПО БЕЗОПАСНОСТИ, СОДЕРЖАЩЕГО ТРЕБОВАНИЯ ТОЛЬКО ИЗ ОК

Оценщики ЗБ, которое содержит требования не из ОК, должны применять требования класса ASE, приведенные в таблице 3.4.

Таблица 3.4

СЕМЕЙСТВА ОЦЕНКИ ЗАДАНИЯ ПО БЕЗОПАСНОСТИ С ТРЕБОВАНИЯМИ, РАСШИРЯЮЩИМИ ОК

4 Класс APE. Оценка профиля защиты

Цель оценки ПЗ состоит в демонстрации, что ПЗ является полным, непротиворечивым и технически правильным. Оцененный ПЗ пригоден в качестве основы для разработки заданий по безопасности. Такой ПЗ приемлем для включения в реестр ПЗ.

На рисунке 4.1 показаны семейства этого класса.

Рисунок 4.1 — Декомпозиция класса «Оценка профиля защиты»

4.1 Описание ОО (APE_DES)

Цели

Описание ОО способствует пониманию требований безопасности ОО. Оценка описания ОО требуется, чтобы показать, что оно является логически последовательным, внутренне непротиворечивым и согласованным со всеми другими частями ПЗ.

APE_DES.1Профиль защиты, описание ОО, требования оценки

Зависимости

APE_ENV.1 Профиль защиты, среда безопасности, требования оценки

APE_INT.1 Профиль защиты, введение ПЗ, требования оценки

APE_OBJ.1 Профиль защиты, цели безопасности, требования оценки

APE_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки

Элементы действий разработчика

APE_DES.1.1DРазработчик ПЗ должен представить описание ОО как часть ПЗ.

Элементы содержания и представления свидетельств

APE_DES.1.1CОписание ОО, как минимум, должно включать в себя тип продукта и общие свойства ИТ, присущие ОО.

Элементы действий оценщика

APE_DES.1.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

APE_DES.1.2EОценщик должен подтвердить, что описание ОО является логически последовательным и внутренне непротиворечивым.

APE_DES.1.3EОценщик должен подтвердить, что описание ОО согласуется с другими частями ПЗ.

4.2 Среда безопасности (APE_ENV)

Цели

Для принятия решения о достаточности требований безопасности ИТ в ПЗ важно, чтобы решаемая задача безопасности ясно понималась всеми участниками оценки.

APE_ENV.1Профиль защиты, среда безопасности, требования оценки

Зависимости отсутствуют

Элементы действий разработчика

APE_ENV.1.1D Разработчик ПЗ должен представить изложение среды безопасности ОО как часть ПЗ.

Элементы содержания и представления свидетельств

APE_ENV.1.1C Изложение среды безопасности ОО должно идентифицировать и объяснить любые предположения о предполагаемом применении ОО и среде использования ОО.

APE_ENV.1.2C Изложение среды безопасности ОО должно идентифицировать и объяснить любые известные или допускаемые угрозы активам, от которых будет требоваться защита посредством ОО или его среды.

APE_ENV.1.3C Изложение среды безопасности ОО должно идентифицировать и объяснить каждую политику безопасности организации, соответствие которой для ОО необходимо.

Элементы действий оценщика

APE_ENV.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

APE_ENV.1.2E Оценщик должен подтвердить, что описание среды безопасности ОО является логически последовательным и внутренне непротиворечивым.

4.3 Введение ПЗ (APE_INT)

Цели

Введение ПЗ содержит информацию для управления документооборотом и обзорную информацию о документе, необходимую для сопровождения реестра ПЗ. Оценка введения ПЗ требуется для демонстрации, что ПЗ правильно идентифицирован, и введение согласуется со всеми другими частями ЗБ.

APE_INT.1Профиль защиты, введение ПЗ, требования оценки

Зависимости

APE_DES.1 Профиль защиты, описание ОО, требования оценки

APE_ENV.1 Профиль защиты, среда безопасности, требования оценки

APE_ODJ.1 Профиль защиты, цели безопасности, требования оценки

APE_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки

Элементы действий разработчика

APE_INT.1.1D Разработчик ПЗ должен представить введение ПЗ как часть ПЗ.

Элементы содержания и представления свидетельств

APE_INT.1.1C Введение ПЗ должно содержать данные идентификации ПЗ, которые предоставляют маркировку и описательную информацию, необходимые, для идентификации, каталогизации, регистрации ПЗ и ссылок на него.

APE_INT.1.2C Введение ПЗ должно содержать аннотацию ПЗ с общей характеристикой ПЗ в описательной форме.

Элементы действий оценщика

APE_INT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

APE_INT.1.2E Оценщик должен подтвердить, что введение ПЗ является логически последовательным и внутренне непротиворечивым.

APE_INT.1.3E Оценщик должен подтвердить, что введение ПЗ согласуется с другими частями ПЗ.

4.4 Цели безопасности (APE_OBJ)

Цели

Цели безопасности — краткое изложение предполагаемой реакции на задачу безопасности. Оценка целей безопасности требуется для демонстрации, что установленные цели адекватны проблеме безопасности. Существуют цели безопасности для ОО и цели безопасности для среды. Необходимо сопоставить цели безопасности для ОО и среды с идентифицированными угрозами, которым они противостоят, и/или с политикой и предположениями, которым они соответствуют

APE_OBJ.1 Профиль защиты, цели безопасности, требования оценки

Зависимости

APE_ENV.1 Профиль защиты, среда безопасности, требования оценки

Элементы действий разработчика

APE_OBJ.1.1D Разработчик ПЗ должен представить изложение целей безопасности как часть ПЗ.

APE_OBJ.1.2D Разработчик ПЗ должен представить логическое обоснование целей безопасности.

Элементы содержания и представления свидетельств

APE_OBJ.1.1C Изложение целей безопасности должно определить цели безопасности для ОО и его среды.

APE_OBJ.1.2C Цели безопасности для ОО должны быть четко изложены и сопоставлены с идентифицированными угрозами, которым будет противостоять ОО, и/или с политикой безопасности организации, которая будет выполняться ОО.

APE_OBJ.1.3C Цели безопасности для среды должны быть четко изложены и сопоставлены с теми аспектами идентифицированных угроз, которым ОО противостоит не полностью, и/или с политикой безопасности организации или предположениями, не полностью выполняемыми ОО.

APE_OBJ.1.4C Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для противостояния всем идентифицированным угрозам безопасности.

APE_OBJ.1.5C Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для охвата всех установленных положений политики безопасности организации и предположений.

Элементы действий оценщика

APE_OBJ.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

APE_OBJ.1.2E Оценщик должен подтвердить, что описание целей безопасности является полным, логически последовательным и внутренне непротиворечивым.

4.5 Требования безопасности ИТ (APE_REQ)

Цели

Требования безопасности ИТ, выбранные для ОО и представленные или указанные в ПЗ, необходимо оценить для подтверждения их внутренней непротиворечивости и пригодности для разработки ОО, отвечающего его целям безопасности.

Не все цели безопасности, выраженные в ПЗ, могут быть выполнены соответствующим ОО, так как некоторые ОО могут зависеть от требований безопасности ИТ, выполняемых средой ИТ. В этом случае требования безопасности ИТ, относящиеся к среде, необходимо ясно изложить и оценить в контексте требований к ОО.

Это семейство представляет требования оценки, которые позволяют оценщику принять решение, что ПЗ пригоден для использования в качестве изложения требований к оцениваемому ОО. Дополнительные критерии, необходимые для оценки требований, сформулированных в явном виде, приведены в семействе APE_SRE.

Замечания по применению

Термин «требования безопасности ИТ» подразумевает «требования безопасности ОО» с возможным включением «требований безопасности для среды ИТ».

Термин «требования безопасности ОО» подразумевает «функциональные требования безопасности ОО» и/или «требования доверия к ОО».

В компоненте APE_REQ.1 использованы несколько значений термина «appropriate» («соответствующий», «необходимый», «приемлемый», «целесообразный») для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ПЗ. Подробная информация по этим аспектам содержится в приложении Б к части 1 ОК.

APE_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки

Зависимости

APE_OBJ.1 Профиль защиты, цели безопасности, требования оценки

Элементы действий разработчика

APE_REQ.1.1D Разработчик ПЗ должен представить изложение требований безопасности ИТ как часть ПЗ.

APE_REQ.1.2D Разработчик ПЗ должен представить логическое обоснование требований безопасности.

Элементы содержания и представления свидетельств

APE_REQ.1.1C Изложение функциональных требований безопасности ОО должно идентифицировать функциональные требования безопасности ОО, составленные из компонентов функциональных требований из части 2 ОК.

APE_REQ.1.2C Изложение требований доверия к ОО должно идентифицировать требования доверия к ОО, составленные из компонентов требований доверия из части 3 ОК.

APE_REQ.1.3C В изложение требований доверия к ОО следует включить оценочный уровень доверия (ОУД), как определено в части 3 ОК.

APE_REQ.1.4C Свидетельство должно содержать строгое обоснование, что изложение требований доверия к ОО является соответствующим.

APE_REQ.1.5C ПЗ должен, при необходимости, идентифицировать каждое требование безопасности для среды ИТ.

APE_REQ.1.6C Все завершенные операции над требованиями безопасности ИТ, включенными в ПЗ, должны быть идентифицированы.

APE_REQ.1.7C Любые незавершенные операции над требованиями безопасности ИТ, включенными в ПЗ, должны быть идентифицированы.

APE_REQ.1.8C Зависимости между требованиями безопасности ИТ, включенными в ПЗ, следует удовлетворить.

APE_REQ.1.9C Свидетельство должно содержать строгое обоснование каждого неудовлетворения зависимостей.

APE_REQ.1.10C ПЗ должен включать в себя изложение приемлемого минимального уровня стойкости функций безопасности (СФБ) для функциональных требований безопасности ОО: базовой, средней или высокой СФБ.

APE_REQ.1.11C ПЗ должен идентифицировать все конкретные функциональные требования безопасности ОО, для которых целесообразно явное указание стойкости функции, так же как и конкретной метрики.

APE_REQ.1.12C Логическое обоснование требований безопасности должно демонстрировать, что минимальный уровень стойкости функции в ПЗ, как и каждое явное указание стойкости функции согласуются с целями безопасности ОО.

APE_REQ.1.13C Логическое обоснование требований безопасности должно демонстрировать, что требования безопасности ИТ пригодны для достижения целей безопасности.

APE_REQ.1.14C Логическое обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутренне непротиворечивое целое.

Элементы действий оценщика

APE_REQ.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

APE_REQ.1.2Е Оценщик должен подтвердить, что описание требований безопасности ИТ является полным, логически последовательным и внутренне непротиворечивым.

4.6 Требования безопасности ИТ, сформулированные в явном виде (APE_SRE)

Цели

Если после тщательного рассмотрения окажется, что ни один из компонентов требований частей 2 или 3 ОК не применим непосредственно ко всем или к части требований безопасности ИТ, разработчик ПЗ может сформулировать другие требования, которые не ссылаются на ОК. Использование таких требований должно быть строго обосновано.

Это семейство содержит требования оценки, которые позволяют оценщику сделать заключение, что сформулированные в явном виде требования четко и однозначно выражены. Оценка требований, выбранных из ОК и используемых наряду со сформулированными в явном виде допустимыми требованиями безопасности, определяется семейством APE_REQ.

Сформулированные в явном виде требования безопасности ИТ для ОО, представленные или указанные в ПЗ, требуется оценить для демонстрации четкости и однозначности их выражения.

Замечания по применению

Формулировка в явном виде требований по структуре, сопоставимой со структурой существующих компонентов и элементов из ОК, включает в себя выбор аналогичного маркирования, способа выражения и уровня детализации.

Использование требований ОК как образца означает, что требования могут быть четко идентифицированы, что они автономны, и применение каждого требования возможно и даст значимый результат оценки, основанный на анализе соответствия ОО этому конкретному требованию.

Термин «требования безопасности ИТ» подразумевает «требования безопасности ОО» с возможным включением «требований безопасности для среды ИТ».

Термин «требования безопасности ОО» подразумевает «функциональные требования безопасности ОО» и/или «требования доверия к ОО».

APE_SRE.1 Профиль защиты, требования безопасности ИТ, сформулированные в явном виде, требования оценки

Зависимости

APE_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки

Элементы действий разработчика

APE_SRE.1.1D Разработчик ПЗ должен представить изложение требований безопасности ИТ как часть ПЗ.

APE_SRE.1.2D Разработчик ПЗ должен представить логическое обоснование требований безопасности.

Элементы содержания и представления свидетельств

APE_SRE.1.1C Все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ОК, должны быть идентифицированы.

APE_SRE.1.2C Все требования безопасности для среды ИТ, которые сформулированы в явном виде без ссылки на ОК, должны быть идентифицированы.

APE_SRE.1.3C Свидетельство должно содержать строгое обоснование, почему требования безопасности должны быть сформулированы в явном виде.

APE_SRE.1.4C Сформулированные в явном виде требования безопасности ИТ должны использовать компоненты, семейства и классы требований ОК как образец для представления.

APE_SRE.1.5C Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, что соответствие или несоответствие им ОО может быть определено и последовательно продемонстрировано.

APE_SRE.1.6C Сформулированные в явном виде требования безопасности ИТ должны быть четко и недвусмысленно выражены.

APE_SRE.1.7C Логическое обоснование требований безопасности должно демонстрировать, что требования доверия применимы и пригодны для поддержки каждого из сформулированных в явном виде функциональных требований безопасности ОО.

Элементы действий оценщика

APE_SRE.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

APE_SRE.1.2E Оценщик должен определить, что все зависимости сформулированных в явном виде требований безопасности ИТ были идентифицированы.

5. Класс ASE. Оценка задания по безопасности

Цель оценки ЗБ состоит в демонстрации, что ЗБ является полным, непротиворечивым, технически правильным и поэтому пригодно в качестве основы для оценки соответствующего ОО.

На рисунке 5.1 показаны семейства этого класса.

Рисунок 5.1 — Декомпозиция класса «Оценка задания по безопасности»

5.1 Описание ОО (ASE_DES)

Цели

Описание ОО способствует пониманию требований безопасности ОО. Оценка описания ОО требуется, чтобы показать, что оно является логически последовательным, внутренне непротиворечивым и согласованным со всеми другими частями ЗБ.

ASE_DES.1. Задание по безопасности, описание ОО, требования оценки

Зависимости

ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки

ASE_INT.1 Задание по безопасности, введение ЗБ, требования оценки

ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки

ASE_PPC.1 Задание по безопасности, утверждения о соответствии ПЗ, требования оценки

ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки

ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования оценки

Элементы действий разработчика

ASE_DES.1.1D Разработчик должен представить описание ОО как часть ЗБ.

Элементы содержания и представления свидетельств

ASE_DES.1.1C Описание ОО, как минимум, должно включать в себя тип продукта или системы, а также область и ограничения применения ОО в общеупотребительных терминах, как в физическом, так и в логическом смысле.

Элементы действий оценщика

ASE_DES.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ASE_DES.1.2E Оценщик должен подтвердить, что описание ОО является логически последовательным и внутренне непротиворечивым.

ASE_DES.1.3E Оценщик должен подтвердить, что описание ОО согласуется с другими частями ЗБ.

5.2 Среда безопасности (ASE_ENV)

Цели

Для принятия решения о достаточности требований безопасности ИТ в ЗБ важно, чтобы решаемая задача безопасности ясно понималась всеми участниками оценки.

ASE_ENV.1Задание по безопасности, среда безопасности, требования оценки

Зависимости отсутствуют.

Элементы действий разработчика

ASE_ENV.1.1D Разработчик должен представить изложение среды безопасности ОО как часть ЗБ.

Элементы содержания и представления свидетельств

ASE_ENV.1.1C Изложение среды безопасности ОО должно идентифицировать и объяснить любые предположения о предполагаемом применении ОО и среде использования ОО.

ASE_ENV.1.2C Изложение среды безопасности ОО должно идентифицировать и объяснить любые известные или допускаемые угрозы активам, от которых будет требоваться защита посредством ОО или его среды.

ASE_ENV.1.3C Изложение среды безопасности ОО должно идентифицировать и объяснить каждую политику безопасности организации, соответствие которой для ОО необходимо.

Элементы действий оценщика

ASE_ENV.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ASE_ENV.1.2E Оценщик должен подтвердить, что описание среды безопасности ОО является логически последовательным и внутренне непротиворечивым.

5.3 Введение ЗБ (ASE_INT)

Цели

Введение ЗБ содержит материалы по идентификации и индексации материалов. Оценка введения ЗБ требуется для демонстрации, что ЗБ правильно идентифицировано, и введение согласуется со всеми другими частями ЗБ.

ASE_INT.1 Задание по безопасности, введение ЗБ, требования оценки

Зависимости

ASE_DES.1 Задание по безопасности, описание ОО, требования оценки

ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки

ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки

ASE_PPC.1 Задание по безопасности, утверждения о соответствии ПЗ, требования оценки

ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки

ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования оценки

Элементы действий разработчика

ASE_INT.1.1D Разработчик должен представить введение ЗБ как часть ЗБ.

Элементы содержания и представления свидетельств

ASE_INT.1.1C Введение ЗБ должно содержать данные идентификации ЗБ, которые предоставляют маркировку и описательную информацию, необходимые для идентификации и применения ЗБ и ОО, к которому оно относится.

ASE_INT.1.2C Введение ЗБ должно содержать аннотацию ЗБ с общей характеристикой ЗБ в описательной форме.

ASE_INT.1.3C Введение ЗБ должно содержать утверждение о соответствии ОК, излагающее все оцениваемые утверждения для ОО о соответствии ОК.

Элементы действия оценщика:

ASE_INT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ASE_INT.1.2E Оценщик должен подтвердить, что введение ЗБ является логически последовательным и внутренне непротиворечивым.

ASE_INT.1.3E Оценщик должен подтвердить, что введение ЗБ согласуется с другими частями ЗБ.

5.4 Цели безопасности (ASE_OBJ)

Цели

Цели безопасности — краткое изложение предполагаемой реакции на задачу безопасности. Оценка целей безопасности требуется для демонстрации, что установленные цели адекватны проблеме безопасности. Существуют цели безопасности для ОО и цели безопасности для среды. Необходимо сопоставить цели безопасности для ОО и среды с идентифицированными угрозами, которым они противостоят, и/или с политикой и предположениями, которым они соответствуют.

ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки

Зависимости

ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки

Элементы действий разработчика

ASE_OBJ.1.1D Разработчик должен представить изложение целей безопасности как часть ЗБ.

ASE_OBJ.1.2D Разработчик должен представить логическое обоснование целей безопасности.

Элементы содержания и представления свидетельств

ASE_OBJ.1.1C Изложение целей безопасности должно определить цели безопасности для ОО и его среды.

ASE_OBJ.1.2C Цели безопасности для ОО должны быть четко изложены и сопоставлены с идентифицированными угрозами, которым будет противостоять ОО, и/или с политикой безопасности организации, которая будет выполняться ОО.

ASE_OBJ.1.3C Цели безопасности для среды должны быть четко изложены и сопоставлены с теми аспектами идентифицированных угроз, которым ОО противостоит не полностью, и/или с политикой безопасности организации или предположениями, не полностью выполняемыми ОО.

ASE_OBJ.1.4C Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для противостояния всем идентифицированным угрозам безопасности.

ASE_OBJ.1.5C Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для охвата всех установленных положений политики безопасности организации и предположений.

Элементы действий оценщика

ASE_OBJ.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ASE_OBJ.1.2E Оценщик должен подтвердить, что описание целей безопасности является полным, логически последовательным и внутренне непротиворечивым.

5.5 Утверждения о соответствии ПЗ (ASE_PPC)

Цели

Цель оценки утверждений о соответствии ПЗ состоит в том, чтобы решить, является ли ЗБ корректным отображением ПЗ.

Замечания по применению

Семейство применяют только при наличии утверждений о соответствии ПЗ. В противном случае не требуется никаких действий разработчика и оценщика.

Хотя при наличии утверждений о соответствии ПЗ необходимы дополнительные действия по оценке, затраты на оценку ЗБ обычно все-таки меньше, чем в случае, когда никакой ПЗ не применяется, потому что при оценке ЗБ можно использовать результаты оценки этого ПЗ.

ASE_PPC.1 Задание по безопасности, утверждения о соответствии ПЗ, требования оценки

Зависимости

ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки

ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки

Элементы действий разработчика

ASE_PPC.1.1D Разработчик должен представить каждое утверждение о соответствии ПЗ как часть ЗБ.

ASE_PPC.1.2D Разработчик должен представить логическое обоснование утверждений о соответствии ПЗ для каждого представленного утверждения о соответствии ПЗ.

Элементы содержания и представления свидетельств

ASE_PPC.1.1C Каждое утверждение о соответствии ПЗ должно идентифицировать ПЗ, соответствие которому утверждается, включая необходимые уточнения, связанные с этим утверждением.

ASE_PPC.1.2C Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки требований безопасности ИТ, в которых завершены разрешенные операции или иначе выполнено дальнейшее уточнение требований ПЗ.

ASE_PPC.1.3C Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки содержащихся в ЗБ целей безопасности и требований безопасности ИТ, которые дополняют имеющиеся в ПЗ.

Элементы действий оценщика

ASE_PPC.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ASE_PPC.1.2E Оценщик должен подтвердить, что утверждения о соответствии профилям защиты являются корректным отображением соответствующих ПЗ.

5.6 Требования безопасности ИТ (ASE_REQ)

Цели

Требования безопасности ИТ, выбранные для ОО и представленные или указанные в ЗБ, необходимо оценить для подтверждения их внутренней непротиворечивости и пригодности для разработки ОО, отвечающего его целям безопасности.

Это семейство представляет требования оценки, которые позволяют оценщику принять решение, что ЗБ пригодно для использования в качестве изложения требований к соответствующему ОО. Дополнительные критерии, необходимые для оценки требований, сформулированных в явном виде, приведены в семействе ASE_SRE.

Замечания по применению

Термин «требования безопасности ИТ» подразумевает «требования безопасности ОО» с возможным включением «требований безопасности для среды ИТ».

Термин «требования безопасности ОО» подразумевает «функциональные требования безопасности ОО» и/или «требования доверия к ОО».

В компоненте ASE_REQ.1 использованы несколько значений термина «appropriate» («соответствующий», «необходимый», «приемлемый», «целесообразный») для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ЗБ. Подробная информация по этим аспектам содержится в приложении В к части 1 ОК.

ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки

Зависимости

ASE_OBJ. 1 Задание по безопасности, цели безопасности, требования оценки

Элементы действий разработчика

ASE_REQ.1.1D Разработчик должен представить изложение требований безопасности ИТ как часть ЗБ.

ASE_REQ.1.2D Разработчик должен представить логическое обоснование требований безопасности.

Элементы содержания и представления свидетельств

ASE_REQ.1.1C Изложение функциональных требований безопасности ОО должно идентифицировать функциональные требования безопасности ОО, составленные из компонентов функциональных требований из части 2 ОК.

ASE_REQ.1.2C Изложение требований доверия к ОО должно идентифицировать требования доверия к ОО, составленные из компонентов требований доверия из части 3 ОК.

ASE_REQ.1.3C В изложение требований доверия к ОО следует включить оценочный уровень доверия (ОУД), как определено в части 3 ОК.

ASE_REQ.1.4C Свидетельство должно содержать строгое обоснование, что изложение требований доверия к ОО является соответствующим.

ASE_REQ.1.5C ЗБ должно, при необходимости, идентифицировать каждое требование безопасности для среды ИТ.

ASE_REQ.1.6C Операции, предусмотренные в требованиях безопасности ИТ, включенных в ЗБ, должны быть идентифицированы и выполнены.

ASE_REQ.1.7C Зависимости между требованиями безопасности ИТ, включенными в ЗБ, следует удовлетворить.

ASE_REQ.1.8C Свидетельство должно содержать строгое обоснование каждого неудовлетворения зависимостей.

ASE_REQ.1.9C ЗБ должно включать в себя изложение приемлемого минимального уровня стойкости функций безопасности (СФБ) для функциональных требований безопасности ОО: базовой, средней или высокой СФБ.

ASE_REQ.1.10C ЗБ должно идентифицировать все конкретные функциональные требования безопасности ОО, для которых целесообразно явное указание стойкости функции, так же как и конкретной метрики.

ASE_REQ.1.11C Логическое обоснование требований безопасности должно демонстрировать, что минимальный уровень стойкости функции в ЗБ, как и каждое явное указание стойкости функции согласуются с целями безопасности ОО.

ASE_REQ.1.12C Логическое обоснование требований безопасности должно демонстрировать, что требования безопасности ИТ пригодны для достижения целей безопасности.

ASE_REQ.1.13C Логическое обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутренне непротиворечивое целое.

Элементы действий оценщика

ASE_REQ.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ASE_REQ.1.2E Оценщик должен подтвердить, что описание требований безопасности ИТ является полным, логически последовательным и внутренне непротиворечивым.

5.7 Требования безопасности ИТ, сформулированные в явном виде (ASE_SRE)

Цели

Если, после тщательного рассмотрения, окажется, что ни один из компонентов требований частей 2 или 3 ОК не применим непосредственно ко всем или к части требований безопасности ИТ, разработчик ЗБ может сформулировать другие требования, которые не ссылаются на ОК. Использование таких требований должно быть строго обосновано.

Это семейство содержит требования оценки, которые позволяют оценщику сделать заключение, что сформулированные в явном виде требования четко и однозначно выражены. Оценка требований, выбранных из ОК и используемых наряду со сформулированными в явном виде допустимыми требованиями безопасности, определяется семейством ASE_REQ.

Сформулированные в явном виде требования безопасности ИТ для ОО, представленные или указанные в ЗБ, требуется оценить для демонстрации четкости и однозначности их выражения.

Замечания по применению

Формулировка в явном виде требований по структуре, сопоставимой со структурой существующих компонентов и элементов из ОК, включает в себя выбор аналогичного маркирования, способа выражения и уровня детализации.

Использование требований ОК как образца означает, что требования могут быть четко идентифицированы, что они автономны, и применение каждого требования возможно и даст значимый результат оценки, основанный на изложении соответствия ОО этому конкретному требованию.

Термин «требования безопасности ИТ» подразумевает «требования безопасности ОО» с возможным включением «требований безопасности для среды ИТ».

Термин «требования безопасности ОО» подразумевает «функциональные требования безопасности ОО» и/или «требования доверия к ОО».

ASE_SRE.1 Задание по безопасности, требования безопасности ИТ, сформулированные в явном виде, требования оценки

Зависимости

ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки

Элементы действий разработчика

ASE_SRE.1.1D Разработчик должен представить изложение требований безопасности ИТ как часть ЗБ.

ASE_SRE.1.2D Разработчик должен представить логическое обоснование требований безопасности.

Элементы содержания и представления свидетельств

ASE_SRE.1.1C Все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ОК, должны быть идентифицированы.

ASE_SRE.1.2C Все требования безопасности для среды ИТ, которые сформулированы в явном виде без ссылки на ОК, должны быть идентифицированы.

ASE_SRE.1.3C Свидетельство должно содержать строгое обоснование, почему требования безопасности должны быть сформулированы в явном виде.

ASE_SRE.1.4C Сформулированные в явном виде требования безопасности ИТ должны использовать компоненты, семейства и классы требований ОК как образец для представления.

ASE_SRE.1.5C Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, что соответствие или несоответствие им ОО может быть определено и последовательно продемонстрировано.

ASE_SRE.1.6C Сформулированные в явном виде требования безопасности ИТ должны быть четко и недвусмысленно выражены.

ASE_SRE.1.7C Логическое обоснование требований безопасности должно демонстрировать, что требования доверия применимы и пригодны для поддержки каждого из сформулированных в явном виде функциональных требований безопасности ОО.

Элементы действий оценщика

ASE_SRE.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ASE_SRE.1.2E Оценщик должен определить, что все зависимости сформулированных в явном виде требований безопасности ИТ были идентифицированы.

5.8 Краткая спецификация ОО (ASE_TSS)

Цели

Краткая спецификация ОО предоставляет определение в самом общем виде функций безопасности, заявленных для удовлетворения функциональных требований, и мер доверия, выбранных для удовлетворения требований доверия.

Замечания по применению

Отношение между функциями безопасности ИТ и функциональными требованиями безопасности ОО может быть отношением типа «многие ко многим». Тем не менее, каждая функция безопасности должна способствовать удовлетворению, по меньшей мере, одного требования безопасности, чтобы можно было четко определить ФБО. Функции безопасности, которые не соответствуют этому требованию, обычно необязательны. Заметим, однако, что требование, чтобы функция безопасности способствовала удовлетворению, по меньшей мере, одного требования безопасности, сформулировано в наиболее общем виде, с тем, чтобы для всех функций безопасности, которые полезны для ОО, существовала бы возможность обоснования.

Изложение мер доверия уместно во всех случаях, когда в ЗБ включены требования доверия, не входящие в ОК. Если требования доверия к ОО в ЗБ основаны исключительно на оценочных уровнях доверия или других компонентах доверия из ОК, то меры доверия могут быть представлены в форме ссылки на документы, которые указывают на удовлетворение требований доверия.

В компоненте ASE_TSS.1 использованы несколько значений термина «appropriate» («соответствующий», «необходимый») для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ЗБ. Подробная информация по этим аспектам содержится в приложении В к части 1 ОК.

ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования оценки

Зависимости

ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки

Элементы действий разработчика

ASE_TSS.1.1D Разработчик должен представить краткую спецификацию ОО как часть ЗБ.

ASE_TSS.1.2D Разработчик должен представить логическое обоснование краткой спецификации ОО.

Элементы содержания и представления свидетельств

ASE_TSS.1.1C Краткая спецификация ОО должна содержать описание функций безопасности ИТ и мер доверия к ОО.

ASE_TSS.1.2C Краткая спецификация ОО должна сопоставить функции безопасности ИТ и функциональные требования безопасности ОО таким образом, чтобы можно было отметить, какие функции безопасности ИТ каким функциональным требованиям безопасности ОО удовлетворяют, и что каждая функция безопасности ИТ способствует удовлетворению, по меньшей мере, одного функционального требования безопасности ОО.

ASE_TSS.1.3C Функции безопасности ИТ должны быть определены в неформальном стиле на уровне детализации, необходимом для понимания их назначения.

ASE_TSS.1.4C Все ссылки на механизмы безопасности, включенные в ЗБ, должны быть сопоставлены с соответствующими функциями безопасности так, чтобы можно было отметить, какие механизмы безопасности использованы при реализации каждой функции.

ASE_TSS.1.5C Логическое обоснование краткой спецификации ОО должно демонстрировать, что функции безопасности ИТ пригодны для удовлетворения функциональных требований безопасности ОО.

ASE_TSS.1.6C Логическое обоснование краткой спецификации ОО должно демонстрировать, что сочетание специфицированных функций безопасности ИТ в совокупности способно удовлетворить функциональные требования безопасности ОО.

ASE_TSS.1.7C Краткая спецификация ОО должна сопоставить меры и требования доверия так, чтобы можно было отметить, какие меры способствуют удовлетворению каких требований.

ASE_TSS.1.8C Логическое обоснование краткой спецификации ОО должно демонстрировать, что меры доверия удовлетворяют все требования доверия к ОО.

ASE_TSS.1.9C Краткая спецификация ОО должна идентифицировать все функции безопасности ИТ, которые реализованы вероятностным или перестановочным механизмом соответственно.

ASE_TSS.1.10C Краткая спецификация ОО должна установить для каждой функции безопасности ИТ, для которой это необходимо, требование стойкости функции либо по специальной метрике, либо как базовую, среднюю или высокую СФБ.

Элементы действий оценщика

ASE_TSS.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ASE_TSS.1.2E Оценщик должен подтвердить, что краткая спецификация ОО является полной, логически последовательной и внутренне непротиворечивой.

6. Оценочные уровни доверия

Оценочные уровни доверия (ОУД) образуют возрастающую шкалу, которая позволяет соотнести получаемый уровень доверия со стоимостью и возможностью достижения этой степени доверия. В части 3 ОК идентифицированы разделенные понятия доверия к ОО по завершению оценки и поддержки этого доверия в процессе эксплуатации ОО.

Важно обратить внимание, что не все семейства и компоненты из части 3 ОК включены в оценочные уровни доверия. Это не означает, что они не обеспечивают значимое и полезное доверие. Напротив, ожидается, что эти семейства и их компоненты будут рассматриваться для усиления ОУД в тех ПЗ и ЗБ, для которых они полезны.

6.1 Краткий обзор оценочных уровней доверия (ОУД)

В таблице 6.1 представлено сводное описание ОУД. Графы таблицы представляют иерархически упорядоченный набор ОУД, а строки — семейства доверия. Каждый номер в образованной ими матрице идентифицирует конкретный компонент доверия, применяемый в данном случае.

Таблица 6.1

ОБЗОР ОЦЕНОЧНЫХ УРОВНЕЙ ДОВЕРИЯ

Как показано в следующем подразделе, в части 3 ОК определены семь иерархически упорядоченных оценочных уровней доверия для ранжирования доверия к ОО. Каждый последующий ОУД представляет более высокое доверие, чем любой из предыдущих. Увеличение доверия от предыдущего ОУД к последующему достигается заменой какого-либо компонента доверия иерархичным компонентом из того же семейства доверия (т.е. увеличением строгости, области и/или глубины оценки) и добавлением компонентов из других семейств доверия (т.е. добавлением новых требований).

ОУД состоят из определенной комбинации компонентов доверия, как описано в разделе 2. Точнее, каждый ОУД включает в себя не более одного компонента каждого семейства доверия, а все зависимости каждого компонента доверия учтены.

Хотя в части 3 ОК определены именно ОУД, можно представлять другие комбинации компонентов доверия. Специально введенное понятие «усиление» («augmentation») допускает добавление (из семейств доверия, до этого не включенных в ОУД) или замену компонентов доверия в ОУД (другими, иерархичными компонентами из того же самого семейства доверия). Из конструкций установления доверия, определенных в ОК, только ОУД могут быть усилены. Понятие «ОУД за исключением какого-либо составляющего его компонента доверия» не признано в ОК как допустимое утверждение. Вводящий усиление обязан строго обосновать полезность и дополнительную ценность добавленного к ОУД компонента доверия. ОУД может быть также расширен требованиями доверия, сформулированными в явном виде.

6.2 Детализация оценочных уровней доверия

Следующие подразделы содержат определения ОУД с использованием полужирного шрифта для выделения новых требований и их описания.

6.2.1 Оценочный уровень доверия 1 (ОУД1) — предусматривающий функ-циональное тестирование

Цели

ОУД1 применим, когда требуется некоторая уверенность в правильном функционировании, а угрозы безопасности не рассматривают как серьезные. Он будет полезен там, где требуется независимо полученное доверие утверждению, что было уделено должное внимание защите персональных данных или подобной информации.

ОУД1 обеспечивает оценку ОО в том виде, в каком он доступен потребителю, путем независимого тестирования на соответствие спецификации и экспертизы представленной документации. Предполагается, что оценка может успешно проводиться без помощи разработчика ОО и с минимальными затратами.

При оценке на этом уровне следует предоставить свидетельство, что ОО функционирует в соответствии с документацией и предоставляет приемлемую защиту против идентифицированных угроз.

Компоненты доверия

ОУД1 (см. таблицу 6.2) предоставляет базовый уровень доверия посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, спецификации интерфейсов и руководств.

Таблица 6.2

ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 1

Анализ поддержан независимым тестированием ФБО.

Этот ОУД обеспечивает значимое увеличение доверия по сравнению с неоцененным продуктом или системой ИТ.

6.2.2 Оценочный уровень доверия 2 (ОУД2) — предусматривающий структур-ное тестирование

Цели

ОУД2 содержит требование сотрудничества с разработчиком для получения информации о проекте и результатах тестирования, но при этом не следует требовать от разработчика усилий, превышающих обычную коммерческую практику. Следовательно, не требуется существенного увеличения стоимости или затрат времени.

Поэтому ОУД2 применим в случаях, когда разработчикам или пользователям требуется независимо подтверждаемый уровень доверия от невысокого до умеренного при отсутствии доступа к полной документации по разработке. Такая ситуация может возникать при обеспечении безопасности разработанных ранее (наследуемых) систем или при ограниченной доступности разработчика.

Компоненты доверия

ОУД2 (см. таблицу 6.3) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, спецификации интерфейсов, руководств и проекта ОО верхнего уровня.

Таблица 6.3

ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 2

Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций и свидетельством поиска разработчиком явных уязвимостей (например, из общедоступных источников).

ОУД2 также обеспечивает доверие посредством списка конфигурации ОО и свидетельства безопасных процедур поставки.

Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД1, требуя тестирование и анализ уязвимостей разработчиком, а также независимое тестирование, основанное на более детализированных спецификациях ОО.

6.2.3 Оценочный уровень доверия 3 (ОУД3) — предусматривающий методическое тестирование и проверку

Цели

ОУД3 позволяет добросовестному разработчику достичь максимального доверия путем применения надлежащего проектирования безопасности без значительного изменения существующей практики качественной разработки.

ОУД3 применим в тех случаях, когда разработчикам или пользователям требуется независимо подтверждаемый умеренный уровень доверия на основе всестороннего исследования ОО и процесса его разработки без существенных затрат на изменение технологии проектирования.

Компоненты доверия

ОУД3 (см. таблицу 6.4) обеспечивает доверие путем анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, спецификации интерфейсов, руководств и проекта ОО верхнего уровня.

Таблица 6.4

ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 3

Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации и проекте верхнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций и свидетельством поиска разработчиком явных уязвимостей (например, из общедоступных источников).

ОУД3 также обеспечивает доверие посредством использования контроля среды разработки, управления конфигурацией ОО и свидетельства безопасных процедур поставки.

Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД2, требуя более полного покрытия тестированием функций и механизмов безопасности и/или процедур безопасности, что дает некоторую уверенность в том, что в ОО не будут внесены искажения во время разработки.

6.2.4 Оценочный уровень доверия 4 (ОУД4) — предусматривающий методи-ческое проектирование, тестирование и углубленную проверку

Цели

ОУД4 позволяет разработчику достичь максимального доверия путем применения надлежащего проектирования безопасности, основанного на обычной коммерческой практике разработки, которая, даже будучи строгой, не требует глубоких специальных знаний, навыков и других ресурсов. ОУД4 — самый высокий уровень, на который, вероятно, экономически целесообразно ориентироваться при оценке уже существующих продуктов.

Поэтому ОУД4 применим, когда разработчикам или пользователям требуется независимо подтверждаемый уровень доверия от умеренного до высокого в ОО общего назначения и имеется готовность нести дополнительные, связанные с обеспечением безопасности, производственные затраты.

Компоненты доверия

ОУД4 (см. таблицу 6.5) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также подмножества реализации. Доверие дополнительно достигается применением неформальной модели политики безопасности ОО.

Таблица 6.5

ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 4

Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации и проекте верхнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с низким потенциалом нападения.

ОУД4 также обеспечивает доверие посредством использования контроля среды разработки и дополнительного управления конфигурацией ОО, включая автоматизацию, и свидетельства безопасных процедур поставки.

Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД3, требуя более детальное описание проекта, подмножество реализации и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки или поставки.

6.2.5 Оценочный уровень доверия 5 (ОУД5) — предусматривающий полуформальное проектирование и тестирование

Цели

ОУД5 позволяет разработчику достичь максимального доверия путем проектирования безопасности, основанного на строгой коммерческой практике разработки, поддержанного умеренным применением узко специализированных методов проектирования безопасности. Такие ОО будут, вероятно, проектироваться и разрабатываться с намерением достичь ОУД5. Скорее всего, дополнительные затраты, сопутствующие требованиям ОУД5 в части строгости разработки, не будут большими без учета применения специализированных методов.

Поэтому ОУД5 применим, когда разработчикам или пользователям требуется независимо получаемый высокий уровень доверия для запланированной разработки со строгим подходом к разработке, не влекущим излишних затрат на применение узко специализированных методов проектирования безопасности.

Компоненты доверия

ОУД5 (см. таблицу 6.6) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также всей реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО и полуформального представления функциональной спецификации и проекта верхнего уровня, а также полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное проектирование ОО.

Таблица 6.6

ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 5

Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня и проекте нижнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с умеренным потенциалом нападения. Анализ также включает в себя проверку правильности анализа разработчиком скрытых каналов.

ОУД5 также обеспечивает доверие посредством использования контроля среды разработки и всестороннего управления конфигурацией ОО, включая автоматизацию, и свидетельства безопасных процедур поставки.

Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД4, требуя полуформальное описание проекта, полную реализацию, более структурированную (и, следовательно, лучше анализируемую) архитектуру, анализ скрытых каналов и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки.

6.2.6 Оценочный уровень доверия 6 (ОУД6) — предусматривающий полуформальную верификацию проекта и тестирование

Цели

ОУД6 позволяет разработчикам достичь высокого доверия путем применения специальных методов проектирования безопасности в строго контролируемой среде разработки с целью получения высококачественного ОО для защиты высоко оцениваемых активов от значительных рисков.

Поэтому ОУД6 применим для разработки безопасных ОО с целью применения в ситуациях высокого риска, где ценность защищаемых активов оправдывает дополнительные затраты.

Компоненты доверия

ОУД6 (см. таблицу 6.7) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также структурированного представления реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО и полуформального представления функциональной спецификации, проекта верхнего уровня и проекта нижнего уровня, а также полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное и иерархическое (по уровням) проектирование ОО.

Таблица 6.7

ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 6

Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня и проекте нижнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с высоким потенциалом нападения. Анализ также включает в себя проверку правильности систематического анализа разработчиком скрытых каналов.

ОУД6 также обеспечивает доверие посредством использования структурированного процесса разработки, контроля среды разработки и всестороннего управления конфигурацией ОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки.

Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД5, требуя всесторонний анализ, структурированное представление реализации, более стройную структуру (например, с разбиением на уровни), всесторонний независимый анализ уязвимостей, систематическую идентификацию скрытых каналов, улучшенное управление конфигурацией и улучшенный контроль среды разработки.

6.2.7 Оценочный уровень доверия 7 (ОУД7) — предусматривающий формальную верификацию проекта и тестирование

Цели

ОУД7 применим при разработке безопасных ОО для использования в ситуациях чрезвычайно высокого риска и/или там, где высокая ценность активов оправдывает максимальные затраты. Практическое применение ОУД7 в настоящее время ограничено ОО, которые строго ориентированы на реализацию функциональных возможностей безопасности и для которых возможен подробный формальный анализ.

Компоненты доверия

ОУД7 (см. таблицу 6.8) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также структурированного представления реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО, формального представления функциональной спецификации и проекта верхнего уровня, полуформального представления проекта нижнего уровня, а также формальной (где это требуется) и полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное, иерархическое (по уровням) и простое проектирование ОО.

Таблица 6.8

ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 7

Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня, проекте нижнего уровня и представлении реализации, полным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с высоким потенциалом нападения. Анализ также включает в себя проверку правильности систематического анализа разработчиком скрытых каналов.

ОУД7 также обеспечивает доверие посредством использования структурированного процесса разработки, средств контроля среды разработки и всестороннего управления конфигурацией ОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки.

Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД6, требуя всесторонний анализ, использующий формальные представления и формальное соответствие, а также всестороннее тестирование.

7. Классы, семейства и компоненты доверия

Разделы 8-14 содержат детализированные требования, представленные во всех компонентах доверия, сгруппированных в классы и семейства в алфавитном (по-латински) порядке.

8. Класс ACM. Управление конфигурацией

Управление конфигурацией (УК) — один из методов или способов установить, что в созданном ОО реализованы функциональные требования и спецификации. УК отвечает этим целям, предъявляя требования дисциплины и контроля в процессе уточнения и модификации ОО и связанной с ним информации. Системы УК используют для обеспечения целостности частей ОО, которые они контролируют, предоставляя метод отслеживания любых изменений, и для того, чтобы все изменения были санкционированы.

На рисунке 8.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 8.1 — Декомпозиция класса «Управление конфигурацией»

8.1 Автоматизация УК (ACM_AUT)

Цели

Цель привлечения инструментальных средств автоматизации УК — повышение эффективности системы УК. Несмотря на то, что как автоматизированные, так и ручные системы УК могут быть обойдены, игнорироваться или оказываться недостаточными для предотвращения несанкционированной модификации, автоматизированные системы все же менее восприимчивы к человеческому фактору — ошибке или небрежности.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе набора элементов конфигурации, которые управляются с применением автоматизированных средств.

Замечания по применению

ACM_AUT.1.1C содержит требование, которое связано с представлением реализации ОО. Представление реализации ОО включает в себя все аппаратные, программные и программно-аппаратные средства, которые составляют ОО по существу. В случае, когда ОО состоит только из программных средств, представление реализации может состоять исключительно из исходного и объектного кода.

ACM_AUT.1.2C содержит требование, чтобы система УК предоставила автоматизированные средства для поддержки генерации ОО. При этом требуется, чтобы система УК предоставила автоматизированные средства, содействующие принятию заключения, что при генерации ОО использованы правильные элементы конфигурации.

ACM_AUT.2.5C содержит требование, чтобы система УК предоставила автоматизированные средства, позволяющие установить различия между ОО и его предыдущей версией. Если предыдущей версии ОО не существует, разработчик все равно нуждается в предоставлении автоматизированных средств, чтобы установить различия между ОО и последующей версией ОО.

ACM_AUT.1 Частичная автоматизация УК

Цели

В средах разработки, где представление реализации является сложным или создается многими разработчиками, трудно контролировать изменения без использования автоматизированных инструментальных средств. В частности, от этих автоматизированных инструментальных средств требуется способность поддерживать многочисленные изменения, которые возникают в процессе разработки, и обеспечить санкционированность этих изменений. Целью данного компонента является обеспечение контроля представления реализации с использованием автоматизированных средств.

Зависимости

ACM_CAP.3 Средства контроля авторизации

Элементы действий разработчика

ACM_AUT.1.1D Разработчик должен использовать систему УК.

ACM_AUT.1.2D Разработчик должен представить план УК.

Элементы содержания и представления свидетельств

ACM_AUT.1.1C Система УК должна предоставить автоматизированные средства, с использованием которых в представлении реализации ОО производятся только санкционированные изменения.

ACM_AUT.1.2C Система УК должна предоставить автоматизированные средства для поддержки генерации ОО.

ACM_AUT.1.3C План УК должен содержать описание автоматизированных инструментальных средств, используемых в системе УК.

ACM_AUT.1.4C План УК должен содержать описание, как автоматизированные инструментальные средства используются в системе УК.

Элементы действий оценщика

ACM_AUT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ACM_AUT.2 Полная автоматизация УК

Цели

В тех средах разработки, где элементы конфигурации являются сложными или создаются многими разработчиками, трудно контролировать изменения без использования автоматизированных инструментальных средств. В частности, требуется, чтобы эти автоматизированные инструментальные средства были способны поддерживать многочисленные изменения, которые возникают в процессе разработки, и обеспечить санкционированность этих изменений. Цель данного компонента — обеспечить, чтобы все элементы конфигурации контролировались с использованием автоматизированных средств.

Применение автоматизированных средств для выявления различий между версиями ОО и определение, на какие элементы конфигурации воздействует модификация других элементов конфигурации, содействуют определению воздействия изменений на последовательные версии ОО. Это, в свою очередь, может предоставить ценную информацию, позволяющую определить, реализованы ли изменения ОО во всех элементах конфигурации, требующих согласования между собой.

Зависимости

ACM_CAP.3 Средства контроля авторизации

Элементы действий разработчика

ACM_AUT.2.1D Разработчик должен использовать систему УК.

ACM_AUT.2.2D Разработчик должен представить план УК.

Элементы содержания и представления свидетельств

ACM_AUT.2.1C Система УК должна предоставить автоматизированные средства, с использованием которых в представлении реализации ОО и во всех остальных элементах конфигурации производятся только санкционированные изменения.

ACM_AUT.2.2C Система УК должна предоставить автоматизированные средства для поддержки генерации ОО.

ACM_AUT.2.3C План УК должен содержать описание автоматизированных инструментальных средств, используемых в системе УК.

ACM_AUT.2.4C План УК должен содержать описание, как автоматизированные инструментальные средства используются в системе УК.

ACM_AUT.2.5C Система УК должна предоставить автоматизированные средства для выявления различий между ОО и предшествующей версией.

ACM_AUT.2.6C Система УК должна предоставить автоматизированные средства для определения всех других элементов конфигурации, на которые воздействует модификация данного элемента конфигурации.

Элементы действий оценщика

ACM_AUT.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

8.2 Возможности УК (ACM_CAP)

Цели

Возможности системы УК связаны с вероятностью того, что могут произойти случайные или несанкционированные модификации элементов конфигурации. Следует, чтобы система УК обеспечила целостность ОО, начиная с ранних этапов проектирования и на протяжении всей последующей деятельности по сопровождению.

Цели этого семейства состоят в следующем:

а) обеспечение корректности и полноты ОО к моменту представления его потребителю;

б) обеспечение, чтобы никакие элементы конфигурации не были пропущены в процессе оценки;

в) предотвращение несанкционированной модификации, добавления или удаления элементов конфигурации ОО.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе возможностей системы УК, объема документации УК, представленной разработчиком, и того, представлено ли разработчиком строгое обоснование соответствия системы УК требованиям безопасности.

Замечания по применению

ACM_CAP.2 содержит отдельные требования, которые относятся к элементам конфигурации. Семейство ACM_SCP содержит требования по составу элементов конфигурации, отслеживаемых системой УК.

ACM_CAP.2.3C содержит требование, чтобы был представлен список конфигурации. Список конфигурации содержит все элементы конфигурации, которые сопровождаются системой УК.

ACM_CAP.2.6C содержит требование, чтобы система УК уникально идентифицировала все элементы конфигурации. Также требуется, чтобы модификация элемента конфигурации приводила к назначению нового уникального идентификатора.

ACM_CAP.3.8С содержит требование, что свидетельство должно демонстрировать функционирование системы УК в соответствии с планом УК. Примерами такого свидетельства являются как документация типа образов экрана или журнала аудита для системы УК, так и подробная демонстрация системы УК разработчиком. Оценщик является ответственным за заключение, что это свидетельство является достаточным для показа, что система УК функционирует в соответствии с планом УК.

ACM_CAP.3.9С содержит требование, чтобы было представлено свидетельство, показывающее, что все элементы конфигурации поддерживаются системой УК. Так как элементом конфигурации считается элемент, включенный в список конфигурации, это требование устанавливает, что все элементы списка конфигурации поддерживаются системой УК.

ACM_CAP.4.11C содержит требование, чтобы система УК поддерживала генерацию ОО. Для этого требуется, чтобы система УК предоставила информационные и/или электронные средства, содействующие принятию заключения, что при генерации ОО использованы правильные элементы конфигурации.

ACM_CAP.1 Номера версий

Цели

Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.

Зависимости отсутствуют.

Элементы действий разработчика

ACM_CAP.1.1D Разработчик должен предоставить маркировку для ОО.

Элементы содержания и представления свидетельств

ACM_CAP.1.1C Маркировка ОО должна быть уникальна для каждой версии ОО.

ACM_CAP.1.2C ОО должен быть помечен маркировкой.

Элементы действий оценщика

ACM_CAP.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ACM_CAP.2 Элементы конфигурации

Цели

Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.

Уникальная идентификация элементов конфигурации ведет к лучшему пониманию состава ОО, что, в свою очередь, способствует определению тех элементов, на которые направлены требования оценки для ОО.

Зависимости отсутствуют.

Элементы действий разработчика

ACM_CAP.2.1D Разработчик должен предоставить маркировку для ОО.

ACM_CAP.2.2D Разработчик должен использовать систему УК.

ACM_CAP.2.3D Разработчик должен представить документацию УК.

Элементы содержания и представления свидетельств

ACM_CAP.2.1C Маркировка ОО должна быть уникальна для каждой версии ОО.

ACM_CAP.2.2C ОО должен быть помечен маркировкой.

ACM_CAP.2.3C Документация УК должна включать в себя список конфигурации.

ACM_CAP.2.4C Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.

ACM_CAP.2.5C Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации.

ACM_CAP.2.6C Система УК должна уникально идентифицировать все элементы конфигурации.

Элементы действий оценщика

ACM_CAP.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ACM_CAP.3 Средства контроля авторизации

Цели

Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.

Уникальная идентификация элементов конфигурации ведет к лучшему пониманию состава ОО, что, в свою очередь, способствует определению тех элементов, на которые направлены требования оценки для ОО.

Поддержанию целостности ОО способствуют применение средств контроля, предупреждающих выполнение несанкционированных модификаций ОО, а также обеспечение надлежащих функциональных возможностей и использование системы УК.

Зависимости

ACM_SCP.1 Охват УК объекта оценки

ALC_DVS.1 Идентификация мер безопасности

Элементы действий разработчика

ACM_CAP.3.1D Разработчик должен предоставить маркировку для ОО.

ACM_CAP.3.2D Разработчик должен использовать систему УК.

ACM_CAP.3.3D Разработчик должен представить документацию УК.

Элементы содержания и представления свидетельств

ACM_CAP.3.1C Маркировка ОО должна быть уникальна для каждой версии ОО.

ACM_CAP.3.2C ОО должен быть помечен маркировкой.

ACM_CAP.3.3C Документация УК должна включать в себя список конфигурации и план УК.

ACM_CAP.3.4C Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.

ACM_CAP.3.5C Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации.

ACM_CAP.3.6C Система УК должна уникально идентифицировать все элементы конфигурации.

ACM_CAP.3.7С План УК должен содержать описание, как используется система УК.

ACM_CAP.3.8С Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК.

ACM_CAP.3.9С Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации.

ACM_CAP.3.10С Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения.

Элементы действий оценщика

ACM_CAP.3.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ACM_CAP.4 Поддержка генерации, процедуры приемки

Цели

Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.

Уникальная идентификация элементов конфигурации ведет к лучшему пониманию состава ОО, что, в свою очередь, способствует определению тех элементов, на которые направлены требования оценки для ОО.

Поддержанию целостности ОО способствуют применение средств контроля, предупреждающих выполнение несанкционированных модификаций ОО, а также обеспечение надлежащих функциональных возможностей и использование системы УК.

Предназначение процедур приемки — подтвердить, что любое создание или модификация элементов конфигурации санкционировано.

Зависимости

ACM_SCP.1 Охват УК объекта оценки

ALC_DVS.1 Идентификация мер безопасности

Элементы действий разработчика

ACM_CAP.4.1D Разработчик должен предоставить маркировку для ОО.

ACM_CAP.4.2D Разработчик должен использовать систему УК.

ACM_CAP.4.3D Разработчик должен представить документацию УК.

Элементы содержания и представления свидетельств

ACM_CAP.4.1C Маркировка ОО должна быть уникальна для каждой версии ОО.

ACM_CAP.4.2C ОО должен быть помечен маркировкой.

ACM_CAP.4.3C Документация УК должна включать в себя список конфигурации, план УК и план приемки.

ACM_CAP.4.4C Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.

ACM_CAP.4.5C Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации.

ACM_CAP.4.6C Система УК должна уникально идентифицировать все элементы конфигурации.

ACM_CAP.4.7С План УК должен содержать описание, как используется система УК.

ACM_CAP.4.8С Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК.

ACM_CAP.4.9С Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации.

ACM_CAP.4.10С Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения.

ACM_CAP.4.11C Система УК должна поддерживать генерацию ОО.

ACM_CAP.4.12C План приемки должен содержать описание процедур, используемых для приемки модифицированного или вновь созданного элемента конфигурации как части ОО.

Элементы действий оценщика

ACM_CAP.4.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ACM_CAP.5 Расширенная поддержка

Цели

Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.

Уникальная идентификация элементов конфигурации ведет к лучшему пониманию состава ОО, что, в свою очередь, способствует определению тех элементов, на которые направлены требования оценки для ОО.

Поддержанию целостности ОО способствуют применение средств контроля, предупреждающих выполнение несанкционированных модификаций ОО, а также обеспечение надлежащих функциональных возможностей и использование системы УК.

Предназначение процедур приемки — подтвердить, что любое создание или модификация элементов конфигурации санкционировано.

Процедуры компоновки способствуют правильному выполнению генерации ОО из управляемого набора элементов конфигурации санкционированным способом.

Требование, чтобы система УК была способна идентифицировать оригинал материала, используемый для генерации ОО, способствует сохранению целостности этого материала путем применением приемлемых технических, физических и процедурных мер защиты.

Зависимости

ACM_SCP.1 Охват УК объекта оценки

ALC_DVS.2 Достаточность мер безопасности

Элементы действий разработчика

ACM_CAP.5.1D Разработчик должен предоставить маркировку для ОО.

ACM_CAP.5.2D Разработчик должен использовать систему УК.

ACM_CAP.5.3D Разработчик должен представить документацию УК.

Элементы содержания и представления свидетельств

ACM_CAP.5.1C Маркировка ОО должна быть уникальна для каждой версии ОО.

ACM_CAP.5.2C ОО должен быть помечен маркировкой.

ACM_CAP.5.3C Документация УК должна включать в себя список конфигурации, план УК, план приемки и процедуры компоновки.

ACM_CAP.5.4C Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.

ACM_CAP.5.5C Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации.

ACM_CAP.5.6C Система УК должна уникально идентифицировать все элементы конфигурации.

ACM_CAP.5.7С План УК должен содержать описание, как используется система УК.

ACM_CAP.5.8С Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК.

ACM_CAP.5.9С Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации.

ACM_CAP.5.10С Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения.

ACM_CAP.5.11C Система УК должна поддерживать генерацию ОО.

ACM_CAP.5.12C План приемки должен содержать описание процедур, используемых для приемки модифицированного или вновь созданного элемента конфигурации как части ОО.

ACM_CAP.5.13С Процедуры компоновки должны описать, как систему УК применяют в процессе изготовления ОО.

ACM_CAP.5.14С Система УК должна содержать требование, чтобы лицо, ответственное за включение элемента конфигурации под УК, не являлось его разработчиком.

ACM_CAP.5.15С Система УК должна четко идентифицировать элементы конфигурации, которые составляют ФБО.

ACM_CAP.5.16С Система УК должна поддерживать аудит всех модификаций ОО с регистрацией, как минимум, инициатора, даты и времени модификации в журнале аудита.

ACM_CAP.5.17С Система УК должна быть способна идентифицировать оригиналы всех материалов, используемые для генерации ОО.

ACM_CAP.5.18С Документация УК должна демонстрировать, что использование системы УК совместно с мерами безопасности разработки сделает возможными только санкционированные изменения в ОО.

ACM_CAP.5.19С Документация УК должна демонстрировать, что использование процедур компоновки обеспечивает выполнение генерации ОО правильно и санкционированным способом.

ACM_CAP.5.20С Документация УК должна демонстрировать, что система УК достаточна для обеспечения того , чтобы лицо, ответственное за включение элемента конфигурации под УК, не было его разработчиком.

ACM_CAP.5.21С Документация УК должна содержать строгое обоснование, что процедуры приемки обеспечивают адекватный и удобный просмотр изменений всех элементов конфигурации.

Элементы действий оценщика

ACM_CAP.5.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

8.3 Область УК (ACM_SCP)

Цели

Цель этого семейства — обеспечить, чтобы все необходимые элементы конфигурации ОО отслеживались системой УК. Это способствует обеспечению защиты целостности элементов конфигурации с использованием возможностей системы УК.

Компонентами семейства может обеспечиваться отслеживание:

а) представления реализации ОО;

б) всей необходимой документации, включая сообщения о проблемах, возникающих во время разработки и эксплуатации;

в) опций конфигурации (например, ключей компилятора);

г) инструментальных средств разработки.

Ранжирование компонентов

Компоненты семейства ранжированы на основе того, что из перечисленного ниже отслеживается системой УК: представление реализации ОО, проектная документация, тестовая документация, документация пользователя, документация администратора, документация УК, недостатки безопасности, инструментальные средства разработки.

Замечания по применению

ACM_SCP.1.1C содержит требование, чтобы системой УК отслеживалось представление реализации ОО. Представление реализации ОО включает в себя все аппаратные, программные и программно-аппаратные средства, которые составляют ОО по существу. В случае, когда ОО состоит только из программных средств, представление реализации может состоять исключительно из исходного и объектного кода.

ACM_SCP.1.1C содержит также требование, чтобы системой УК отслеживалась документация УК. Документация включает в себя план УК, а также информацию относительно актуальных версий любых инструментальных средств, которые входят в состав системы УК.

ACM_SCP.2.1C содержит требование, чтобы системой УК отслеживались недостатки безопасности, т.е. сопровождалась информация об имевших место недостатках безопасности и их устранении, а также сведения о существующих недостатках безопасности.

ACM_SCP.3.1С содержит требование, чтобы системой УК отслеживались инструментальные средства разработки и информация, относящаяся к ним. Примеры инструментальных средств разработки — языки программирования и компиляторы. Информация, имеющая отношение к элементам генерации ОО (типа опций компилятора, опций инсталляции/генерации и опций компоновки) — пример информации, относящейся к инструментальным средствам разработки.

ACM_SCP.1 Охват УК объекта оценки

Цели

Система УК может контролировать изменения только тех элементов, которые были включены под УК. Включение под УК представления реализации ОО, проектной и тестовой документации, документации администратора и пользователя и документации УК обеспечивает доверие, что они могут быть модифицированы только под контролем в соответствии с полномочиями.

Зависимости

ACM_CAP.3 Средства контроля авторизации

Элементы действий разработчика

ACM_SCP.1.1D Разработчик должен представить документацию УК.

Элементы содержания и представления свидетельств

ACM_SCP.1.1C Документация УК должна показать, что система УК, как минимум, отслеживает: представление реализации ОО, проектную документацию, тестовую документацию, документацию пользователя, документацию администратора и документацию УК.

ACM_SCP.1.2C Документация УК должна содержать описание, как элементы конфигурации отслеживаются системой УК.

Элементы действий оценщика

ACM_SCP.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ACM_SCP.2 Охват УК отслеживания проблем

Цели

Система УК может контролировать изменения только тех элементов, которые были включены под УК. Включение под УК представления реализации ОО, проектной и тестовой документации, документации администратора и пользователя и документации УК обеспечивает доверие, что они могут быть модифицированы только под контролем в соответствии с полномочиями.

Отслеживание недостатков безопасности под УК не позволяет утратить или игнорировать сообщения о недостатках безопасности, давая возможность разработчику контролировать недостатки безопасности вплоть до их устранения.

Зависимости

ACM_CAP.3 Средства контроля авторизации

Элементы действий разработчика

ACM_SCP.2.1D Разработчик должен представить документацию УК.

Элементы содержания и представления свидетельств

ACM_SCP.2.1C Документация УК должна показать, что система УК, как минимум, отслеживает: представление реализации ОО, проектную документацию, тестовую документацию, документацию пользователя, документацию администратора, документацию УК и недостатки безопасности.

ACM_SCP.2.2C Документация УК должна содержать описание, как элементы конфигурации отслеживаются системой УК.

Элементы действий оценщика

ACM_SCP.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ACM_SCP.3 Охват УК инструментальных средств разработки

Цели

Система УК может контролировать изменения только тех элементов, которые были включены под УК. Включение под УК представления реализации ОО, проектной и тестовой документации, документации администратора и пользователя и документации УК обеспечивает доверие к тому, что они могут быть модифицированы только под контролем в соответствии с полномочиями.

Отслеживание недостатков безопасности под УК не позволяет утратить или игнорировать сообщения о недостатках безопасности, давая возможность разработчику контролировать недостатки безопасности вплоть до их устранения.

Инструментальные средства разработки играют важную роль в обеспечении изготовления качественной версии ОО. Следовательно, важно контролировать модификацию этих средств.

Зависимости

ACM_CAP.3 Средства контроля авторизации

Элементы действий разработчика

ACM_SCP.3.1D Разработчик должен представить документацию УК.

Элементы содержания и представления свидетельств

ACM_SCP.3.1С Документация УК должна показать, что система УК, как минимум, отслеживает: представление реализации ОО, проектную документацию, тестовую документацию, документацию пользователя, документацию администратора, документацию УК, недостатки безопасности и инструментальные средства разработки и связанную с ними информацию.

ACM_SCP.3.2С Документация УК должна содержать описание, как элементы конфигурации отслеживаются системой УК.

Элементы действий оценщика

ACM_SCP.3.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

9. Класс ADO. Поставка и эксплуатация

Класс «Поставка и эксплуатация» содержит требования правильной поставки, установки, генерации и запуска ОО.

На рисунке 9.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 9.1 — Декомпозиция класса » Поставка и эксплуатация «

9.1 Поставка (ADO_DEL)

Цели

Требования для поставки предусматривают такие средства и процедуры контроля и распространения системы, которые обеспечивают доверие к тому, что потребитель получит именно тот ОО, который отправитель намеревался отослать, без каких-либо модификаций. Правильно выполненная поставка предполагает необходимость точного соответствия полученной версии оригиналу ОО, исключая, таким образом, как любое вмешательство в актуальную версию, так и подмену ее фальсифицированной версией.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе повышения требований к разработчику, позволяющих обнаружить и предотвратить модификации ОО во время его поставки.

ADO_DEL.1 Процедуры поставки

Зависимости отсутствуют.

Элементы действий разработчика

ADO_DEL.1.1D Разработчик должен задокументировать процедуры поставки ОО или его частей пользователю.

ADO_DEL.1.2.D Разработчик должен использовать процедуры поставки.

Элементы содержания и представления свидетельств

ADO_DEL.1.1C Документация поставки должна содержать описание всех процедур, необходимых для поддержки безопасности при распространении версий ОО к местам использования.

Элементы действий оценщика

ADO_DEL.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADO_DEL.2 Обнаружение модификации

Зависимости

ACM_CAP.3 Средства контроля авторизации

Элементы действий разработчика

ADO_DEL.2.1D Разработчик должен задокументировать процедуры поставки ОО или его частей пользователю.

ADO_DEL.2.2 Разработчик должен использовать процедуры поставки.

Элементы содержания и представления свидетельств

ADO_DEL.2.1C Документация поставки должна содержать описание всех процедур, необходимых для поддержки безопасности при распространении версий к местам использования.

ADO_DEL.2.2C Документация поставки должна содержать описание, как различные процедуры и технические меры обеспечивают обнаружение модификаций или любого расхождения между оригиналом разработчика и версией, полученной в месте использования.

ADO_DEL.2.3C Документация поставки должна содержать описание, как различные процедуры позволяют обнаружить попытку подмены от имени разработчика, даже в тех случаях, когда разработчик ничего не отсылал к месту использования.

Элементы действий оценщика

ADO_DEL.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADO_DEL.3 Предотвращение модификации

Зависимости

ACM_CAP.3 Средства контроля авторизации

Элементы действий разработчика

ADO_DEL.3.1D Разработчик должен задокументировать процедуры поставки ОО или его частей пользователю.

ADO_DEL.3.2D Разработчик должен использовать процедуры поставки.

Элементы содержания и представления свидетельств

ADO_DEL.3.1C Документация поставки должна содержать описание всех процедур, необходимых для поддержки безопасности при распространении версий ОО к местам использования.

ADO_DEL.3.2C Документация поставки должна содержать описание, как различные процедуры и технические меры обеспечивают предотвращение модификаций или любого расхождения между оригиналом разработчика и версией, полученной в месте использования.

ADO_DEL.3.3C Документация поставки должна содержать описание, как различные процедуры позволяют обнаружить попытку подмены от имени разработчика, даже в тех случаях, когда разработчик ничего не отсылал к месту использования.

Элементы действий оценщика

ADO_DEL.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

9.2 Установка, генерация и запуск (ADO_IGS)

Цели

Процедуры установки, генерации и запуска полезны для обеспечения, чтобы ОО был установлен, сгенерирован и запущен безопасным способом так, как это предписано разработчиком. Требования, предъявляемые к установке, генерации и запуску, предусматривают безопасный переход от нахождения представления реализации ОО под управлением конфигурации к началу его эксплуатации в среде использования.

Ранжирование компонентов

Компоненты в этом семействе ранжированы с учетом того, регистрируются ли опции генерации ОО.

Замечания по применению

Установлено, что применение этих требований будет меняться в зависимости от различных аспектов, например, является ли ОО продуктом или системой ИТ, поставлен ли ОО в готовом к эксплуатации состоянии или он должен устанавливаться владельцем на месте эксплуатации и т.д. Для конкретного ОО обычно будет иметь место разделение ответственности по установке, генерации и запуску между разработчиком и владельцем ОО, но имеются примеры, где все действия выполняются одной стороной. Например, для смарт-карты все аспекты установки, генерации и запуска могут выполняться по месту разработки ОО. С другой стороны, ОО может быть поставлен как система ИТ в форме программного обеспечения, где все аспекты установки, генерации и запуска выполняются по месту использования ОО.

Также возможен случай, когда ОО уже установлен до начала оценки. В этом случае может быть неуместным требовать и анализировать процедуры установки.

Более того, требования генерации применимы только к тем ОО, которые дают возможность генерировать составляющие вводимого в эксплуатацию ОО из их представления реализации.

Процедуры установки, генерация и запуска могут быть либо приведены в отдельном документе, либо включены в другое административное руководство. Требования в этом семействе доверия представлены отдельно от требований семейства AGD_ADM из-за нечастого, возможно, одноразового использования процедур установки, генерации и запуска.

ADO_IGS.1 Процедуры установки, генерации и запуска

Зависимости

AGD_ADM.1 Руководство администратора

Элементы действий разработчика

ADO_IGS.1.1D Разработчик должен задокументировать процедуры, необходимые для безопасной установки, генерации и запуска ОО.

Элементы содержания и представления свидетельств

ADO_IGS.1.1C Документация должна содержать описание последовательности действий, необходимых для безопасной установки, генерации и запуска ОО.

Элементы действий оценщика

ADO_IGS.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADO_IGS.1.2E Оценщик должен сделать независимое заключение, что процедуры установки, генерации и запуска приводят к безопасной конфигурации.

ADO_IGS.2 Журнал регистрации генерации

Зависимости

AGD_ADM.1 Руководство администратора

Элементы действий разработчика

ADO_IGS.2.1D Разработчик должен задокументировать процедуры, необходимые для безопасной установки, генерации и запуска ОО.

Элементы содержания и представления свидетельств

ADO_IGS.2.1CДокументация должна содержать описание последовательности действий, необходимых для безопасной установки, генерации и запуска ОО.

ADO_IGS.2.2C Документация должна содержать описание процедур, позволяющих таким образом создать журнал регистрации, содержащий применявшиеся опции генерации ОО, чтобы можно было точно определить, как и когда ОО был сгенерирован.

Элементы действий оценщика

ADO_IGS.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADO_IGS.2.2E Оценщик должен сделать независимое заключение, что процедуры установки, генерации и запуска приводят к безопасной конфигурации.

10. Класс ADV. Разработка

Класс «Разработка» содержит четыре семейства требований для представления ФБО на различных уровнях абстракции — от функционального интерфейса до представления реализации. Класс «Разработка» включает в себя также семейство требований для отображения соответствия между различными представлениями ФБО, требуя, в конечном счете, демонстрацию соответствия от наименее абстрактного представления через все промежуточные представления до краткой спецификации ОО, содержащейся в ЗБ. Кроме того, имеется семейство требований для модели ПБО и для отображения соответствия между ПБО, моделью ПБО и функциональной спецификацией. И, наконец, имеется семейство требований к внутренней структуре ФБО, которое распространяется на такие аспекты, как модульность, разбиение на уровни и минимизация сложности.

На рисунке 10.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 10.1 — Декомпозиция класса «Разработка»

Парадигма, очевидная для этих семейств, — функциональная спецификация ФБО, разбиение ФБО на подсистемы, разбиение подсистем на модули, показ реализации модулей и демонстрация соответствия между всеми декомпозициями, которая представляется как свидетельство. Требования для различных представлений ФБО разнесены по разным семействам, однако разработчику ПЗ/ЗБ дается возможность определить, какое именно подмножество представлений ФБО требуется.

Рисунок 10.2 — Связи между представлениями ОО и требованиями

На рисунке 10.2 показаны связи между различными представлениями ФБО, целями и требованиями, с которыми они связаны. Классы APE и ASE определяют требования соответствия между функциональными требованиями и целями безопасности, а также между целями безопасности и ожидаемой средой ОО. Класс ASE также определяет требования к соответствию между целями безопасности, функциональными требованиями и краткой спецификацией ОО.

Требования для всех других соответствий, показанных на рисунке 10.2, определены в классе ADV. Семейство ADV_SPM определяет требования соответствия между ПБО и моделью ПБО, а также между моделью ПБО и функциональной спецификацией. Семейство ADV_RCR определяет требования соответствия между всеми имеющимися представлениями ФБО — от краткой спецификации ОО до представления реализации. Наконец, каждое семейство доверия, относящееся к конкретному представлению ФБО (т.е. ADV_FSP, ADV_HLD, ADV_LLD и ADV_IMP), определяет требования, устанавливающие связь между представлением ФБО и функциональными требованиями, сочетание которых помогает убедиться в том, что функциональные требования безопасности ОО были учтены. Анализ прослеживания будет выполняться всегда, начиная с самого высокого уровня представления ФБО, включая каждое из имеющихся представлений ФБО. ОК реализуют это требование прослеживания, используя зависимости от семейства ADV_RCR. Семейство ADV_INT не представлено на рисунке 10.2, поскольку оно связано с внутренней структурой ФБО и имеет лишь косвенное отношение к процессу уточнения представлений ФБО.

Замечания по применению

Политика безопасности ОО (ПБО) — совокупность правил, регулирующих управление активами, их защиту и распределение в пределах ОО и выражаемых посредством функциональных требований безопасности ОО. От разработчика в явном виде не требуется представление ПБО, поскольку ПБО выражается посредством функциональных требований безопасности ОО, через сочетание политик функций безопасности (ПФБ) и других отдельных элементов требований.

Функции безопасности ОО (ФБО) — совокупность всех функциональных возможностей различных частей ОО, направленных на осуществление ПБО. ФБО включают в себя как функции, которые непосредственно осуществляют ПБО, так и функции, которые, не реализуя ПБО непосредственно, косвенно содействуют осуществлению ПБО.

Хотя требования семейства ASE_TSS и некоторых других семейств класса ASE предусматривают несколько различных представлений ФБО, совсем необязателен отдельный документ для каждого представления ФБО. Действительно, возможен случай, когда один документ выполняет требования по документированию нескольких представлений ФБО, а объединение в нем требуемой информации по каждому из этих представлений ФБО предпочтительнее, несмотря на усложнение структуры данного документа. В случае, когда несколько представлений ФБО объединены в одном документе, разработчику следует указать конкретно, в каких документах какие представления содержатся.

Этим классом узаконены три типа стиля изложения спецификаций: неформальный, полуформальный и формальный. Функциональная спецификация, проект верхнего уровня, проект нижнего уровня и модель ПБО будут изложены с применением одного или нескольких из этих стилей спецификации. Неоднозначность в этих спецификациях уменьшается с повышением уровня формализации стиля изложения.

Неформальную спецификацию излагают как текст на естественном языке. Под естественным языком здесь подразумевается применение выразительных средств общения любого разговорного языка (например, английского, немецкого, русского, французского). Неформальная спецификация не подчинена никаким нотационным или специальным ограничениям, отличным от общепринятых соглашений для этого языка (таких, как грамматика и синтаксис). Хотя не применяются никакие нотационные ограничения, в неформальной спецификации все же требуется привести определения значений терминов, использование которых в контексте отличается от общепринятого.

Полуформальную спецификацию излагают на языке с ограниченным синтаксисом и обычно сопровождают вспомогательным пояснительным (неформальным) текстом. Язык с ограниченным синтаксисом может быть естественным языком с ограниченной структурой предложения и ключевыми словами со специальными значениями или же он может быть языком схем (таких, как схемы потоков данных, переходов, взаимосвязей сущностей, структур данных и процессов или структур программ). В обоих случаях обязателен набор соглашений, позволяющих определить ограничения, накладываемые на синтаксис.

Формальную спецификацию излагают с использованием нотации, основанной на известных математических понятиях, и обычно сопровождают вспомогательным пояснительным (неформальным) текстом. Эти математические понятия используют, чтобы определить синтаксис и семантику нотации и правила доказательства, поддерживающие логическую аргументацию. Следует, чтобы синтаксические и семантические правила, регламентирующие формальную нотацию, определяли, как однозначно распознавать конструкции и определять их значение. Требуется свидетельство невозможности вывода противоречий, а все правила, регламентирующие нотацию, необходимо определить или сослаться на них.

Существенное доверие может быть достигнуто через обеспечение прослеживания ФБО до каждого из его представлений и соответствия модели ПБО функциональной спецификации. Семейство ADV_RCR содержит требования к отображению соответствия между различными представлениями ФБО, а семейство ADV_SPM — между моделью ПБО и функциональной спецификацией. Соответствие может принять форму либо неформальной или полуформальной демонстрации, либо формального доказательства.

Когда требуется неформальная демонстрация соответствия, это означает, что требуется только соответствие по сути. Методы демонстрации включают, например, использование двумерной таблицы с входами, обозначающими соответствие, или использование подходящей для этого нотации схем проекта. Могут быть также использованы указатели и ссылки на другие документы.

Полуформальная демонстрация соответствия требует структурного подхода при анализе соответствия. Следует, чтобы при этом подходе уменьшалась неоднозначность, которая может существовать при неформальном соответствии, ограничивая интерпретацию применяемых терминов. Могут быть также использованы указатели и ссылки на другие документы.

Формальное доказательство соответствия требует, чтобы были использованы известные математические понятия для определения синтаксиса и семантики формальной нотации и правил доказательства, которые поддерживают логическую аргументацию. Необходимо, чтобы свойства безопасности могли быть выражены на языке формальной спецификации, и было показано, что эти свойства удовлетворяются формальной спецификацией. Могут быть также использованы указатели и ссылки на другие документы.

Элементы ADV_RCR.*.1C содержат требование, чтобы разработчик представил свидетельство для каждой смежной пары представлений ФБО, что все относящиеся к безопасности функциональные возможности более абстрактного представления ФБО уточнены в менее абстрактном представлении ФБО. Каждый из элементов ADV_FSP.*.2E, ADV_HLD.*.2E, ADV_LLD.*.2E и ADV_IMP.*.2E содержит требование, чтобы оценщик сделал заключение о том, что ФБО, представляемые этим семейством требований — точное и полное отображение функциональных требований безопасности ОО. Чтобы сделать заключение, что представление ФБО является точным и полным отображением функциональных требований безопасности ОО, предполагается, что оценщик использует свидетельство, предоставленное разработчиком в ADV_RCR.*.1C, как основание для этого заключения. Устанавливая соответствие между функциональными требованиями безопасности ОО и каждым из цепочки последовательных представлений ФБО, этот пошаговый процесс предоставит, в конечном счете, более высокое доверие соответствию наименее абстрактного представления ФБО функциональным требованиям безопасности ОО, что и является конечной целью этого класса. Если оценщик не устанавливает соответствие функциональным требованиям безопасности ОО для промежуточных представлений ФБО, то попытка сделать заключение о соответствии наименее абстрактного представления ФБО функциональным требованиям безопасности ОО может представлять собой слишком большой шаг для точного выполнения. И, наконец, в зависимости от требуемой совокупности представлений ФБО, вполне возможно, что проект нижнего уровня, проект верхнего уровня или даже функциональная спецификация может являться наименее абстрактным имеющимся представлением ФБО.

10.1 Функциональная спецификация (ADV_FSP)

Цели

Функциональная спецификация — это описание на верхнем уровне видимого пользователем интерфейса и режима выполнения ФБО. Она представляет собой отображение функциональных требований безопасности ОО. Функциональная спецификация должна показать, что все функциональные требования безопасности ОО учтены.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе степени формализации, требуемой для функциональной спецификации, и степени детализации, предусмотренной для внешних интерфейсов ФБО.

Замечания по применению

Элементы ADV_FSP.*.2E этого семейства определяют требование, чтобы оценщик сделал заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и функциональной спецификацией в дополнение к попарным соответствиям, требуемым семейством ADV_RCR. Ожидается, что оценщик использует свидетельство, включенное в ADV_RCR, как основание для этого заключения, а требование полноты предполагает соотнесение с уровнем абстракции функциональной спецификации.

Для ADV_FSP.1.3C предполагается, чтобы в функциональной спецификации предоставлялась информация, достаточная для понимания того, как были учтены функциональные требования безопасности ОО, и давалась возможность спецификации тестов, которые отражают функциональные требования безопасности ОО в ЗБ. Необязательно, чтобы такое тестирование охватило все возможные ответы на запросы и сообщения об ошибках, которые могут быть сформированы интерфейсом, но следует, чтобы приведенная информация сделала ясными результаты использования интерфейса в случае нормального завершения и наиболее общих примеров отказа.

ADV_FSP.2.3C содержит требование полного представления функционального интерфейса. Этим будет обеспечена необходимая детализация для поддержки как полного тестирования ОО, так и оценки уязвимостей.

Применительно к уровню формализации функциональной спецификации неформальная, полуформальная и формальная спецификации рассматриваются как иерархичные по сути. Так, элементы требований ADV_FSP.1.1C и ADV_FSP.2.1C могут быть удовлетворены использованием полуформальной или формальной функциональной спецификации, поддержанной, где это необходимо, неформальным пояснительным текстом. Аналогично, ADV_FSP.3.1C может быть удовлетворен использованием формальной функциональной спецификации.

ADV_FSP.1 Неформальная функциональная спецификация

Зависимости

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_FSP.1.1D Разработчик должен представить функциональную спецификацию.

Элементы содержания и представления свидетельств

ADV_FSP.1.1C Функциональная спецификация должна содержать неформальное описание ФБО и их внешних интерфейсов.

ADV_FSP.1.2C Функциональная спецификация должна быть внутренне непротиворечивой.

ADV_FSP.1.3C Функциональная спецификация должна содержать описание назначения и методов использования всех внешних интерфейсов ФБО, обеспечивая, где это необходимо, детализацию результатов, нештатных ситуаций и сообщений об ошибках.

ADV_FSP.1.4C Функциональная спецификация должна полностью представить ФБО.

Элементы действий оценщика

ADV_FSP.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_FSP.1.2E Оценщик должен сделать независимое заключение, что функциональная спецификация — точное и полное отображение функциональных требований безопасности ОО.

ADV_FSP.2 Полностью определенные внешние интерфейсы

Зависимости

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_FSP.2.1D Разработчик должен представить функциональную спецификацию.

Элементы содержания и представления свидетельств

ADV_FSP.2.1C Функциональная спецификация должна содержать неформальное описание ФБО и их внешних интерфейсов.

ADV_FSP.2.2C Функциональная спецификация должна быть внутренне непротиворечивой.

ADV_FSP.2.3C Функциональная спецификация должна содержать описание назначения и методов использования всех внешних интерфейсов ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_FSP.2.4C Функциональная спецификация должна полностью представить ФБО.

ADV_FSP.2.5C Функциональная спецификация должна включать в себя логическое обоснование, что ФБО полностью представлены.

Элементы действий оценщика

ADV_FSP.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_FSP.2.2E Оценщик должен сделать независимое заключение, что функциональная спецификация — точное и полное отображение функциональных требований безопасности ОО.

ADV_FSP.3 Полуформальная функциональная спецификация

Зависимости

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_FSP.3.1D Разработчик должен представить функциональную спецификацию.

Элементы содержания и представления свидетельств

ADV_FSP.3.1C Функциональная спецификация должна содержать полуформальное описание ФБО и их внешних интерфейсов, поддержанное, где это необходимо, неформальным пояснительным текстом.

ADV_FSP.3.2C Функциональная спецификация должна быть внутренне непротиворечивой.

ADV_FSP.3.3C Функциональная спецификация должна содержать описание назначения и методов использования всех внешних интерфейсов ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_FSP.3.4C Функциональная спецификация должна полностью представить ФБО.

ADV_FSP.3.5C Функциональная спецификация должна включать в себя логическое обоснование, что ФБО полностью представлены.

Элементы действий оценщика

ADV_FSP.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_FSP.3.2E Оценщик должен сделать независимое заключение, что функциональная спецификация — точное и полное отображение функциональных требований безопасности ОО.

ADV_FSP.4 Формальная функциональная спецификация

Зависимости

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_FSP.4.1D Разработчик должен представить функциональную спецификацию.

Элементы содержания и представления свидетельств

ADV_FSP.4.1C Функциональная спецификация должна содержать формальное описание ФБО и их внешних интерфейсов, поддержанное, где это необходимо, неформальным пояснительным текстом.

ADV_FSP.4.2C Функциональная спецификация должна быть внутренне непротиворечивой.

ADV_FSP.4.3C Функциональная спецификация должна содержать описание назначения и методов использования всех внешних интерфейсов ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_FSP.4.4C Функциональная спецификация должна полностью представить ФБО.

ADV_FSP.4.5C Функциональная спецификация должна включать в себя логическое обоснование, что ФБО полностью представлены.

Элементы действий оценщика

ADV_FSP.4.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_FSP.4.2E Оценщик должен сделать независимое заключение, что функциональная спецификация — точное и полное отображение функциональных требований безопасности ОО.

10.2 Проект верхнего уровня (ADV_HLD)

Цели

Проект верхнего уровня ОО представляет описание ФБО в терминах основных структурных частей (т.е. подсистем) и связывает эти части с функциями, которые они выполняют. Требования к проекту верхнего уровня предназначены для обеспечения доверия, что ОО имеет архитектуру, приемлемую для реализации функциональных требований безопасности ОО.

Проект верхнего уровня уточняет функциональную спецификацию, преобразуя ее в подсистемы. Для каждой подсистемы ФБО проект верхнего уровня описывает ее назначение, а также идентифицирует функции безопасности, включаемые в подсистему. В проекте верхнего уровня также определяются взаимосвязи всех подсистем. Эти взаимосвязи будут представлены как внешние интерфейсы соответственно по данным, управлению и т.д.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе степени формализации, требуемой для проекта верхнего уровня, и на степени детализации, требуемой для спецификаций интерфейса.

Замечания по применению

Разработчик, как ожидается, опишет проект ФБО в терминах подсистем. Термин «подсистема» используют здесь для выражения идеи декомпозиции ФБО на относительно небольшое число частей. Даже если разработчику фактически не требуется иметь «подсистемы», ожидается, что он представит подобный уровень декомпозиции. Например, проект может быть декомпозирован путем использования «уровней», «доменов» или «серверов».

Выражение «функциональные возможности безопасности» используют, чтобы представить совокупность выполняемых подсистемой действий, которые участвуют в осуществлении функций безопасности, реализуемых ОО. Это разграничение сделано потому, что составные части проекта, такие как подсистемы или модули, не обязательно однозначно отождествляются с конкретными функциями безопасности. В то время как данная подсистема может прямо соответствовать как одной, так и нескольким функциям безопасности, возможно также, что несколько подсистем необходимо объединить для реализации единственной функции безопасности.

Выражение «подсистема, осуществляющая ПБО» относится к подсистеме, которая прямо или косвенно содействует осуществлению ПБО.

Элементы ADV_HLD.*.2E этого семейства определяют требование вынесения оценщиком заключения, что проект верхнего уровня является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и проектом верхнего уровня в дополнение к попарным соответствиям, требуемым семейством ADV_RCR. Ожидается, что оценщик использует свидетельство, включенное в ADV_RCR, как основание для этого заключения, а требование полноты предполагает соотнесение с уровнем абстракции проекта верхнего уровня.

ADV_HLD.3.8 C содержит требование полного представления интерфейсов подсистем. Этим будет обеспечена необходимая детализация для поддержки как полного тестирования ОО (с использованием компонентов из ATE_DPT), так и оценки уязвимостей.

Применительно к уровню формализации проекта верхнего уровня неформальный, полуформальный и формальный проекты рассматривают как иерархичные по сути. Так, элементы требований ADV_HLD.1.1C и ADV_HLD.2.1C могут быть удовлетворены использованием полуформального или формального проекта верхнего уровня, а элементы требований ADV_HLD.3.1С и ADV_HLD.4.1C — использованием формального проекта верхнего уровня.

ADV_HLD.1 Описательный проект верхнего уровня

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.1.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.1.1C Представление проекта верхнего уровня должно быть неформальным.

ADV_HLD.1.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.1.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.1.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.1.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.1.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.1.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

Элементы действий оценщика

ADV_HLD.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.1.2E Оценщик должен сделать независимое заключение, что проект верхнего уровня — точное и полное отображение функциональных требований безопасности ОО.

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.2.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.2.1C Представление проекта верхнего уровня должно быть неформальным.

ADV_HLD.2.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.2.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.2.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.2.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.2.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.2.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

ADV_HLD.2.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая, где это необходимо, детализацию результатов, нештатных ситуаций и сообщений об ошибках.

ADV_HLD.2.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

Элементы действий оценщика

ADV_HLD.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.2.2E Оценщик должен сделать независимое заключение, что проект верхнего уровня — точное и полное отображение функциональных требований безопасности ОО.

ADV_HLD.3 Полуформальный проект верхнего уровня

Зависимости

ADV_FSP.3 Полуформальная функциональная спецификация

ADV_RCR.2 Полуформальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.3.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.3.1C Представление проекта верхнего уровня должно быть полуформальным.

ADV_HLD.3.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.3.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.3.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.3.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.3.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.3.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

ADV_HLD.3.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_HLD.3.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

Элементы действий оценщика

ADV_HLD.3.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.3.2Е Оценщик должен сделать независимое заключение, что проект верхнего уровня — точное и полное отображение функциональных требований безопасности ОО.

ADV_HLD.4 Пояснения в полуформальном проекте верхнего уровня

Зависимости

ADV_FSP.3 Полуформальная функциональная спецификация

ADV_RCR.2 Полуформальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.4.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.4.1C Представление проекта верхнего уровня должно быть полуформальным.

ADV_HLD.4.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.4.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.4.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.4.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.4.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.4.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

ADV_HLD.4.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_HLD.4.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

ADV_HLD.4.10C Проект верхнего уровня должен содержать строгое обоснование, что идентифицированный способ выполнения разделения, в том числе любых механизмов защиты, достаточен для обеспечения четкого и эффективного отделения функций, осуществляющих ПБО, от функций, не участвующих в осуществлении ПБО.

ADV_HLD.4.11C Проект верхнего уровня должен содержать строгое обоснование, что механизмы ФБО достаточны для реализации функций безопасности, идентифицированных в проекте верхнего уровня.

Элементы действий оценщика

ADV_HLD.4.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.4.2Е Оценщик должен сделать независимое заключение, что проект верхнего уровня — точное и полное отображение функциональных требований безопасности ОО.

ADV_HLD.5Формальный проект верхнего уровня

Зависимости

ADV_FSP.4 Формальная функциональная спецификация

ADV_RCR.3 Формальная демонстрация соответствия

Элементы действий разработчика

ADV_HLD.5.1D Разработчик должен представить проект верхнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_HLD.5.1C Представление проекта верхнего уровня должно быть формальным.

ADV_HLD.5.2C Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.5.3C Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

ADV_HLD.5.4C Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

ADV_HLD.5.5C Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.5.6C Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.5.7C Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

ADV_HLD.5.8C Проект верхнего уровня должен содержать описание назначения и методов использования всех интерфейсов подсистем ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_HLD.5.9C Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

ADV_HLD.5.10C Проект верхнего уровня должен содержать строгое обоснование, что идентифицированный способ выполнения разделения, в том числе любых механизмов защиты, достаточен для обеспечения четкого и эффективного отделения функций, осуществляющих ПБО, от функций, не участвующих в осуществлении ПБО.

ADV_HLD.5.11C Проект верхнего уровня должен содержать строгое обоснование, что механизмы ФБО достаточны для реализации функций безопасности, идентифицированных в проекте верхнего уровня.

Элементы действий оценщика

ADV_HLD.5.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_HLD.5.2Е Оценщик должен сделать независимое заключение, что проект верхнего уровня — точное и полное отображение функциональных требований безопасности ОО.

10.3 Представление реализации (ADV_IMP)

Цели

Описание представления реализации в форме исходного текста программ, микропрограмм, схем аппаратных средств и т.д. фиксирует детализацию выполнения ФБО для поддержки анализа.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе полноты и структуры приведенного представления реализации.

Замечания по применению

Представление реализации применяют, чтобы выразить наименее абстрактное представление ФБО, а именно используемое для создания собственно реализации ФБО без дальнейшего уточнения проекта. Исходный текст, который затем компилируют, или чертеж аппаратуры, который используют для построения действующего оборудования, — примеры частей представления реализации.

Возможно, что оценщики смогут использовать представление реализации, чтобы непосредственно поддерживать другие виды действий при оценке (например, анализ уязвимостей, анализ полноты тестирования или идентификацию дополнительных тестов оценщика). Ожидается, что авторы ПЗ/ЗБ выберут компонент, требующий достаточно полной и всесторонней реализации, для удовлетворения всех других требований, включенных в ПЗ/ЗБ.

ADV_IMP.1 Подмножество реализации ФБО

Замечания по применению

ADV_IMP.1.1D содержит требование, чтобы разработчик обеспечил представление реализации для подмножества ФБО. Целью является доступ, по меньшей мере, к той части ФБО, которая обеспечит оценщику возможность провести экспертизу представления реализации тех частей ОО, для которых подобная экспертиза может значительно увеличить понимание применяемых механизмов и доверие им. Подготовка выборки представления реализации позволит оценщику выборочно проверить свидетельство прослеживания требований безопасности в представлениях проекта ОО, чтобы получить доверие к подходу, принятому для уточнения, и непосредственно оценить предъявленное представление реализации.

Элемент ADV_IMP.1.2E определяет требование вынесения оценщиком независимого заключения, что наименее абстрактное представление ФБО является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и наименее абстрактным представлением ФБО в дополнение к попарным соответствиям, требуемым семейством ADV_RCR. Ожидается, что оценщик использует свидетельство, предоставляемое в ADV_RCR, как основание для заключения об этом. Наименее абстрактное представление ФБО для этого компонента — совокупность имеющегося представления реализации и той части проекта нижнего уровня, для которой не имеется представления реализации.

Зависимости

ADV_LLD.1 Описательный проект нижнего уровня

ADV_RCR.1 Неформальная демонстрация соответствия

ALC_TAT.1 Полностью определенные инструментальные средства разработки

Элементы действий разработчика

ADV_IMP.1.1D Разработчик должен обеспечить представление реализации для выбранного подмножества ФБО.

Элементы содержания и представления свидетельств

ADV_IMP.1.1C Представление реализации должно однозначно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дальнейших проектных решений.

ADV_IMP.1.2C Представление реализации должно быть внутренне непротиворечивым.

Элементы действий оценщика

ADV_IMP.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_IMP.1.2E Оценщик должен сделать независимое заключение, что наименее абстрактное представление ФБО — точное и полное отображение функциональных требований безопасности ОО.

ADV_IMP.2 Реализация ФБО

Замечания по применению

Элемент ADV_IMP.2.2E определяет требование вынесения оценщиком независимого заключения о том, что представление ФБО является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и представлением реализации в дополнение к попарным соответствиям, требуемым семейством ADV_RCR. Ожидается, что оценщик использует свидетельство, предоставляемое в ADV_RCR, как основание при вынесении этого заключения.

Зависимости

ADV_LLD.1 Описательный проект нижнего уровня

ADV_RCR.1 Неформальная демонстрация соответствия

ALC_TAT.1 Полностью определенные инструментальные средства разработки

Элементы действий разработчика

ADV_IMP.2.1D Разработчик должен обеспечить представление реализации для всех ФБО.

Элементы содержания и представления свидетельств

ADV_IMP.2.1C Представление реализации должно однозначно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дальнейших проектных решений.

ADV_IMP.2.2C Представление реализации должно быть внутренне непротиворечивым.

ADV_IMP.2.3C Представление реализации должно включать в себя описание взаимосвязей между всеми частями реализации.

Элементы действий оценщика

ADV_IMP.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_IMP.2.2E Оценщик должен сделать независимое заключение, что представление реализации — точное и полное отображение функциональных требований безопасности ОО.

ADV_IMP.3 Структурированная реализация ФБО

Замечания по применению

Элемент ADV_IMP.3.2E определяет требование вынесения оценщиком независимого заключения о том, что представление ФБО является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и представлением реализации в дополнение к попарным соответствиям, требуемым семейством ADV_RCR. Ожидается, что оценщик использует свидетельство, предоставляемое в ADV_RCR, как основание при вынесении этого заключения.

Зависимости

ADV_INT.1 Модульность

ADV_LLD.1 Описательный проект нижнего уровня

ADV_RCR.1 Неформальная демонстрация соответствия

ALC_TAT.1 Полностью определенные инструментальные средства разработки

Элементы действий разработчика

ADV_IMP.3.1D Разработчик должен обеспечить представление реализации для всех ФБО.

Элементы содержания и представления свидетельств

ADV_IMP.3.1C Представление реализации должно однозначно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дальнейших проектных решений.

ADV_IMP.3.2C Представление реализации должно быть внутренне непротиворечивым.

ADV_IMP.3.3C Представление реализации должно включать в себя описание взаимосвязей между всеми частями реализации.

ADV_IMP.3.4C Представление реализации должно быть структурировано в малые и понятные разделы.

Элементы действий оценщика

ADV_IMP.3.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_IMP.3.2Е Оценщик должен сделать независимое заключение, что представление реализации — точное и полное отображение функциональных требований безопасности ОО.

10.4 Внутренняя структура ФБО (ADV_INT)

Цели

Это семейство связано с внутренней структурой ФБО. Установлены требования для модульности, разбиения на уровни (чтобы разделить уровни абстракции и минимизировать циклические зависимости), минимизации как сложности механизмов осуществления политик, так и функциональных возможностей ФБО, не участвующих в осуществлении ПБО, для получения ФБО, которые являются достаточно простыми для анализа.

Модульное проектирование уменьшает взаимозависимость между элементами ФБО и, таким образом, уменьшает риск, что изменение или ошибка в одном модуле повлияет на весь ОО. Таким образом, модульное проектирование предоставляет основу для определения области взаимодействия с другими элементами ФБО, обеспечивает повышение доверия к отсутствию непредвиденных последствий, а также предоставляет основу для проектирования и оценки комплектов тестов.

Использование разбиения на уровни и простой конструкции для функциональных возможностей, осуществляющих ПБО, уменьшает сложность ФБО. Это, в свою очередь, способствует лучшему пониманию ФБО, предоставляя большее доверие, что функциональные требования безопасности ОО точно и полностью отражены в реализации.

Минимизация тех функциональных возможностей в ФБО, которые не участвуют в осуществлении ПБО, уменьшает возможность появления дефектов в ФБО. В сочетании с модульностью и разбиением на уровни, она позволяет оценщику сосредоточиться только на тех функциональных возможностях, которые действительно необходимы для осуществления ПБО.

Минимизация сложности проекта содействует повышению доверия, что код понятен: чем меньше сложность кода ФБО, тем больше вероятность, что проект ФБО постижим. Минимизация сложности проекта является ключевой характеристикой механизма проверки правомочности обращений.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе требуемых структурированности и минимизации.

Замечания по применению

Выражение «части ФБО» использовано для представления частей ФБО различной степени детализации, основанной на доступных представлениях ФБО. Функциональная спецификация допускает идентификацию в терминах интерфейсов, проект верхнего уровня — в терминах подсистем, проект нижнего уровня — в терминах модулей и представление реализации — в терминах блоков реализации.

Элементы ADV_INT.2.5C и ADV_INT.3.5C связаны с минимизацией взаимодействий между уровнями иерархии. Взаимодействие между уровнями допустимо, но при этом от разработчика требуется показать, что эти взаимодействия необходимы, и их невозможно избежать.

ADV_INT.2.6C обращается к концепции монитора обращений, требуя минимизацию сложности тех частей ФБО, которые осуществляют политики управления доступом и/или управления информационными потоками, идентифицированные в ПБО. ADV_INT.3.6С развивает далее концепцию монитора обращений, требуя минимизацию сложности всех ФБО.

Некоторые элементы в компонентах этого семейства ссылаются на описание архитектуры. Описание архитектуры выполняется на том же уровне абстракции, что и проект нижнего уровня в отношении модулей ФБО. Принимая во внимание, что проект нижнего уровня описывает модульную конструкцию ФБО, назначение описания архитектуры — предоставить при необходимости свидетельство модульности, разбиения на уровни и минимизации сложности ФБО. Требуется согласованность как проекта нижнего уровня, так и представления реализации с описанием архитектуры для обеспечения доверия, что эти представления ФБО обладают требуемой модульностью, разбиением на уровни и минимизацией сложности.

ADV_INT.1 Модульность

Зависимости

ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

Элементы действий разработчика

ADV_INT.1.1D Разработчик должен проектировать и структурировать ФБО в модульном виде, избегая необязательных связей между модулями проекта.

ADV_INT.1.2D Разработчик должен представить описание архитектуры.

Элементы содержания и представления свидетельств

ADV_INT.1.1C Описание архитектуры должно идентифицировать модули ФБО.

ADV_INT.1.2C Описание архитектуры должно содержать изложение назначения, интерфейсов, параметров и результатов применения каждого модуля ФБО.

ADV_INT.1.3C Описание архитектуры должно содержать изложение, каким образом проект ФБО обеспечивает большую независимость модулей, чтобы избежать ненужного взаимодействия.

Элементы действий оценщика

ADV_INT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_INT.1.2E Оценщик должен сделать независимое заключение, что и проект нижнего уровня, и представление реализации согласуются с описанием архитектуры.

ADV_INT.2 Уменьшение сложности

Замечания по применению

Этот компонент обращается к концепции монитора обращений, требуя минимизации сложности тех частей ФБО, которые осуществляют политики управления доступом и/или информационными потоками, идентифицированные в ПБО.

Зависимости

ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

Элементы действий разработчика

ADV_INT.2.1D Разработчик должен проектировать и структурировать ФБО в модульном виде, избегая необязательных связей между модулями проекта.

ADV_INT.2.2D Разработчик должен представить описание архитектуры.

ADV_INT.2.3D Разработчик должен проектировать и структурировать ФБО по уровням с минимизацией взаимных связей между уровнями проекта.

ADV_INT.2.4D Разработчик должен проектировать и структурировать ФБО способом, минимизирующим сложность тех частей ФБО, которые осуществляют какие-либо политики управления доступом и/или информационными потоками.

Элементы содержания и представления свидетельств

ADV_INT.2.1C Описание архитектуры должно идентифицировать модули ФБО и специфицировать, какие части ФБО осуществляют политики управления доступом и/или информационными потоками.

ADV_INT.2.2C Описание архитектуры должно содержать изложение назначения, интерфейсов, параметров и результатов применения каждого модуля ФБО.

ADV_INT.2.3C Описание архитектуры должно содержать изложение, каким образом проект ФБО обеспечивает большую независимость модулей, чтобы избежать ненужного взаимодействия.

ADV_INT.2.4C Описание архитектуры должно показать ее разбиение на уровни.

ADV_INT.2.5C Описание архитектуры должно показать, что взаимные связи были минимизированы, и содержать строгое обоснование оставшихся связей.

ADV_INT.2.6C Описание архитектуры должно содержать изложение, каким образом части ФБО, которые осуществляют любые политики управления доступом и/или информационными потоками, структурированы для минимизации сложности.

Элементы действий оценщика

ADV_INT.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_INT.2.2E Оценщик должен сделать независимое заключение, что и проект нижнего уровня, и представление реализации согласуются с описанием архитектуры.

ADV_INT.3Минимизация сложности

Замечания по применению

Этот компонент содержит требование, чтобы свойство монитора обращений «достаточно простой для анализа» полностью выполнялось. Если этот компонент сочетается с функциональными требованиями FPT_RVM.1 и FPT_SEP.3, то концепция монитора обращений будет полностью реализована.

Зависимости

ADV_IMP.2 Реализация ФБО

ADV_LLD.1 Описательный проект нижнего уровня

Элементы действий разработчика

ADV_INT.3.1D Разработчик должен проектировать и структурировать ФБО в модульном виде, избегая необязательных связей между модулями проекта.

ADV_INT.3.2D Разработчик должен представить описание архитектуры.

ADV_INT.3.3D Разработчик должен проектировать и структурировать ФБО по уровням с минимизацией взаимных связей между уровнями проекта.

ADV_INT.3.4D Разработчик должен проектировать и структурировать ФБО способом, минимизирующим сложность ФБО в целом.

ADV_INT.3.5D Разработчик должен проектировать и структурировать части ФБО, которые осуществляют какие-либо политики управления доступом и/или информационными потоками так, чтобы они были достаточно простыми для анализа.

ADV_INT.3.6D Разработчик должен обеспечить, чтобы функции, цели которых не имеют отношения к безопасности, были устранены из модулей ФБО.

Элементы содержания и представления свидетельств

ADV_INT.3.1C Описание архитектуры должно идентифицировать модули ФБО и специфицировать, какие части ФБО осуществляют политики управления доступом и/или управления информационными потоками.

ADV_INT.3.2C Описание архитектуры должно содержать изложение назначения, интерфейса, параметров и результатов применения каждого модуля ФБО.

ADV_INT.3.3C Описание архитектуры должно содержать изложение, каким образом проект ФБО обеспечивает большую независимость модулей, чтобы избежать ненужного взаимодействия.

ADV_INT.3.4C Описание архитектуры должно показать ее разбиение на уровни.

ADV_INT.3.5C Описание архитектуры должно показать, что взаимные связи были минимизированы, и содержать строгое обоснование оставшихся связей.

ADV_INT.3.6C Описание архитектуры должно содержать изложение, каким образом все ФБО структурированы для минимизации сложности.

ADV_INT.3.7C Описание архитектуры должно содержать строгое обоснование включения в ФБО каждого модуля, не участвующего в осуществлении ПБО.

Элементы действий оценщика

ADV_INT.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_INT.3.2E Оценщик должен сделать независимое заключение, что и проект нижнего уровня, и представление реализации согласуются с описанием архитектуры.

ADV_INT.3.3Е Оценщик должен подтвердить, что части ФБО, которые осуществляют какие-либо политики управления доступом и/или информационными потоками, достаточно просты для анализа.

10.5 Проект нижнего уровня (ADV_LLD)

Цели

Проект нижнего уровня ОО содержит описание внутреннего содержания ФБО в терминах модулей, их взаимосвязей и зависимостей. Проект нижнего уровня обеспечивает доверие к тому, что подсистемы ФБО были правильно и эффективно уточнены.

Для каждого модуля ФБО проект нижнего уровня описывает назначение, функции, интерфейсы, зависимости и реализацию всех функций, участвующих в осуществлении ПБО.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе степени формализации, требуемой для проекта нижнего уровня, и степени детализации, требуемой для спецификаций интерфейсов.

Замечания по применению

Выражение «модуль, осуществляющий ПБО» относится к любому модулю, направленному на осуществление ПБО.

Выражение «функциональные возможности безопасности» используют, чтобы представить совокупность выполняемых модулем действий, которые участвуют в осуществлении функций безопасности, реализуемых ОО. Это разграничение сделано потому, что модули не обязательно однозначно отождествляются с конкретными функциями безопасности. В то время как данный модуль может прямо соответствовать как одной, так и нескольким функциям безопасности, возможно также, что несколько модулей необходимо объединить для реализации единственной функции безопасности.

Элементы ADV_LLD.*.6C содержат требование, чтобы проект нижнего уровня описал, как обеспечивается каждая из функций, осуществляющих ПБО. Смысл этого требования состоит в том, чтобы проект нижнего уровня содержал описание того, как планируется реализовать каждый модуль, исходя из перспективы проекта.

Элементы ADV_LLD.*.2E этого семейства определяют требование вынесения оценщиком независимого заключения, что проект нижнего уровня является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и проектом нижнего уровня в дополнение к попарным соответствиям, требуемым семейством ADV_RCR. Ожидается, что оценщик использует свидетельство, включенное в ADV_RCR, как основание для этого заключения, а требование полноты предполагает соотнесение с уровнем абстракции проекта нижнего уровня.

ADV_LLD.2.9C содержит требование полного представления интерфейсов модулей. Этим будет обеспечена необходимая детализация для поддержки как полного тестирования ОО (с использованием компонентов из ATE_DPT), так и оценки уязвимостей.

Применительно к уровню формализации проекта нижнего уровня неформальный, полуформальный и формальный проекты рассматривают как иерархичные по сути. Так, элемент ADV_LLD.1.1C может быть удовлетворен использованием полуформального или формального проекта нижнего уровня, а элемент ADV_LLD.2.1C — формального проекта нижнего уровня.

ADV_LLD.1 Описательный проект нижнего уровня

Зависимости

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_RCR.1 Неформальная демонстрация соответствия

Элементы действий разработчика

ADV_LLD.1.1D Разработчик должен представить проект нижнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_LLD.1.1C Представление проекта нижнего уровня должно быть неформальным.

ADV_LLD.1.2C Проект нижнего уровня должен быть внутренне непротиворечивым.

ADV_LLD.1.3C Проект нижнего уровня должен содержать описание ФБО в терминах модулей.

ADV_LLD.1.4C Проект нижнего уровня должен содержать описание назначения каждого модуля.

ADV_LLD.1.5C Проект нижнего уровня должен определить взаимосвязи между модулями в терминах предоставляемых функциональных возможностей безопасности и зависимостей от других модулей.

ADV_LLD.1.6C Проект нижнего уровня должен содержать описание, как предоставляется каждая из функций, осуществляющих ПБО.

ADV_LLD.1.7C Проект нижнего уровня должен идентифицировать все интерфейсы модулей ФБО.

ADV_LLD.1.8C Проект нижнего уровня должен идентифицировать, какие из интерфейсов модулей ФБО являются видимыми извне.

ADV_LLD.1.9C Проект нижнего уровня должен содержать описание назначения и методов использования всех интерфейсов модулей ФБО, предоставляя, при необходимости, детализацию результатов, нештатных ситуаций и сообщений об ошибках.

ADV_LLD.1.10C Проект нижнего уровня должен содержать описание разделения ОО на модули, осуществляющие ПБО, и прочие.

Элементы действий оценщика

ADV_LLD.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_LLD.1.2E Оценщик должен сделать независимое заключение, что проект нижнего уровня — точное и полное отображение функциональных требований безопасности ОО.

ADV_LLD.2 Полуформальный проект нижнего уровня

Зависимости

ADV_HLD.3 Полуформальный проект верхнего уровня

ADV_RCR.2 Полуформальная демонстрация соответствия

Элементы действий разработчика

ADV_LLD.2.1D Разработчик должен представить проект нижнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_LLD.2.1C Представление проекта нижнего уровня должно быть полуформальным.

ADV_LLD.2.2C Проект нижнего уровня должен быть внутренне непротиворечивым.

ADV_LLD.2.3C Проект нижнего уровня должен содержать описание ФБО в терминах модулей.

ADV_LLD.2.4C Проект нижнего уровня должен содержать описание назначения каждого модуля.

ADV_LLD.2.5C Проект нижнего уровня должен определить взаимосвязи между модулями в терминах предоставляемых функциональных возможностей безопасности и зависимостей от других модулей.

ADV_LLD.2.6C Проект нижнего уровня должен содержать описание, как предоставляется каждая из функций, осуществляющих ПБО.

ADV_LLD.2.7C Проект нижнего уровня должен идентифицировать все интерфейсы модулей ФБО.

ADV_LLD.2.8C Проект нижнего уровня должен идентифицировать, какие из интерфейсов модулей ФБО являются видимыми извне.

ADV_LLD.2.9CПроект нижнего уровня должен содержать описание назначения и методов использования всех интерфейсов модулей ФБО, предоставляя полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_LLD.2.10CПроект нижнего уровня должен содержать описание разделения ОО на модули, осуществляющие ПБО, и прочие.

Элементы действий оценщика

ADV_LLD.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_LLD.2.2E Оценщик должен сделать независимое заключение, что проект нижнего уровня — точное и полное отображение функциональных требований безопасности ОО.

ADV_LLD.3 Формальный проект нижнего уровня

Зависимости

ADV_HLD.5 Формальный проект верхнего уровня

ADV_RCR.3 Формальная демонстрация соответствия

Элементы действий разработчика

ADV_LLD.3.1D Разработчик должен представить проект нижнего уровня ФБО.

Элементы содержания и представления свидетельств

ADV_LLD.3.1C Представление проекта нижнего уровня должно быть формальным.

ADV_LLD.3.2C Проект нижнего уровня должен быть внутренне непротиворечивым.

ADV_LLD.3.3C Проект нижнего уровня должен содержать описание ФБО в терминах модулей.

ADV_LLD.3.4C Проект нижнего уровня должен содержать описание назначения каждого модуля.

ADV_LLD.3.5C Проект нижнего уровня должен определить взаимосвязи между модулями в терминах предоставляемых функциональных возможностей безопасности и зависимостей от других модулей.

ADV_LLD.3.6C Проект нижнего уровня должен содержать описание, как предоставляется каждая из функций, осуществляющих ПБО.

ADV_LLD.3.7C Проект нижнего уровня должен идентифицировать все интерфейсы модулей ФБО.

ADV_LLD.3.8C Проект нижнего уровня должен идентифицировать, какие из интерфейсов модулей ФБО являются видимыми извне.

ADV_LLD.3.9C Проект нижнего уровня должен содержать описание назначения и методов использования всех интерфейсов модулей ФБО, предоставляя полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

ADV_LLD.3.10C Проект нижнего уровня должен содержать описание разделения ОО на модули, осуществляющие ПБО, и прочие.

Элементы действий оценщика

ADV_LLD.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_LLD.3.2E Оценщик должен сделать независимое заключение, что проект нижнего уровня — точное и полное отображение функциональных требований безопасности ОО.

10.6 Соответствие представлений (ADV_RCR)

Цели

Соответствие между различными представлениями ФБО (т.е. краткой спецификацией ОО, функциональной спецификацией, проектом верхнего уровня, проектом нижнего уровня, представлением реализации) связано с правильным и полным отображением требований вплоть до наименее абстрактного из имеющихся представлений ФБО. Этот результат достигается пошаговым уточнением и совокупным результатом определения соответствия между всеми смежными абстракциями представления.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе требуемого уровня формализации соответствия между различными представлениями ФБО.

Замечания по применению

Необходимо, чтобы разработчик продемонстрировал оценщику, что наиболее детализированное или наименее абстрактное имеющееся представление ФБО — точное, непротиворечивое и полное отображение функций, выраженных как функциональные требования в ЗБ. Это выполняют путем показа соответствия между смежными представлениями на соразмерном уровне строгости.

Семейство ADV_RCR не связано с требованиями соответствия ПБО или модели ПБО. В этом семействе, как показано на рисунке 10.2, рассмотрено соответствие между различными представлениями ФБО (т.е. краткой спецификацией ОО, функциональной спецификацией, проектом верхнего уровня, проектом нижнего уровня и представлением реализации).

Элементы ADV_RCR.*.1C ссылаются на «все функциональные возможности, относящиеся к безопасности» в определении области уточнения для смежной пары представлений ФБО. При переходе от краткой спецификации ОО к функциональной спецификации этот элемент предусматривает только, чтобы функции безопасности ОО из краткой спецификации ОО были уточнены в функциональной спецификации, и не требует, чтобы функциональная спецификация содержала какие-либо подробности относительно мер доверия (которые представлены в краткой спецификации ОО). Там, где рассматривается представление реализации только для подмножества ФБО (как в ADV_IMP.1), требуемые уточнения при переходе от проекта нижнего уровня к представлению реализации ограничены функциональными возможностями безопасности, которые имеются в представлении реализации. Во всех остальных случаях этот элемент предусматривает, чтобы все части более абстрактного представления ФБО были уточнены в менее абстрактном представлении ФБО.

Применительно к уровню формализации соответствия между смежными представлениями ФБО неформальный, полуформальный и формальный уровни рассматривают как иерархичные по сути. Так, ADV_RCR.2.2C и ADV_RCR.3.2C могут быть удовлетворены формальным доказательством соответствия, а при отсутствии каких-либо требований к уровню формализации демонстрация соответствия может быть неформальной, полуформальной или формальной.

ADV_RCR.1 Неформальная демонстрация соответствия

Зависимости отсутствуют.

Элементы действий разработчика

ADV_RCR.1.1D Разработчик должен представить анализ соответствия между всеми смежными парами имеющихся представлений ФБО.

Элементы содержания и представления свидетельств

ADV_RCR.1.1C Для каждой смежной пары имеющихся представлений ФБО анализ должен демонстрировать, что все функциональные возможности более абстрактного представления ФБО, относящиеся к безопасности, правильно и полностью уточнены в менее абстрактном представлении ФБО.

Элементы действий оценщика

ADV_RCR.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_RCR.2 Полуформальная демонстрация соответствия

Зависимости отсутствуют.

Элементы действий разработчика

ADV_RCR.2.1D Разработчик должен представить анализ соответствия между всеми смежными парами имеющихся представлений ФБО.

Элементы содержания и представления свидетельств

ADV_RCR.2.1C Для каждой смежной пары имеющихся представлений ФБО анализ должен демонстрировать, что все функциональные возможности более абстрактного представления ФБО, относящиеся к безопасности, правильно и полностью уточнены в менее абстрактном представлении ФБО.

ADV_RCR.2.2C Для каждой смежной пары имеющихся представлений ФБО, где части обоих представлений специфицированы, по меньшей мере, полуформально, демонстрация соответствия между этими частями представлений должна быть полуформальной.

Элементы действий оценщика

ADV_RCR.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_RCR.3 Формальная демонстрация соответствия

Замечания по применению

Необходимо, чтобы разработчик либо демонстрировал, либо доказал соответствие, как описано ниже в требованиях, соразмерно с уровнем строгости стиля представления. Например, соответствие необходимо доказать, если используемые представления специфицированы формально.

Зависимости отсутствуют.

Элементы действий разработчика

ADV_RCR.3.1D Разработчик должен представить анализ соответствия между всеми смежными парами имеющихся представлений ФБО.

ADV_RCR.3.2D Для тех из соответствующих частей представлений, которые специфицированы формально, разработчик должен доказать это соответствие.

Элементы содержания и представления свидетельств

ADV_RCR.3.1C Для каждой смежной пары имеющихся представлений ФБО анализ должен доказать или демонстрировать, что все функциональные возможности более абстрактного представления ФБО, относящиеся к безопасности, правильно и полностью уточнены в менее абстрактном представлении ФБО.

ADV_RCR.3.2C Для каждой смежной пары имеющихся представлений ФБО, где части одного представления специфицированы полуформально, а другого — по меньшей мере, полуформально, демонстрация соответствия между этими частями представлений должна быть полуформальной.

ADV_RCR.3.3C Для каждой смежной пары имеющихся представлений ФБО, где части обоих представлений специфицированы формально, доказательство соответствия между этими частями представлений должно быть формальным.

Элементы действий оценщика

ADV_RCR.3.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_RCR.3.2Е Оценщик должен сделать независимое заключение о правильности доказательств соответствия, избирательно верифицируя формальный анализ.

10.7 Моделирование политики безопасности (ADV_SPM)

Цели

Цель этого семейства — повысить доверие, что функции безопасности в функциональной спецификации осуществляют политики ПБО. Это выполняется посредством разработки модели политики безопасности, которая основана на подмножестве политик ПБО, и установления соответствия между функциональной спецификацией, моделью политики безопасности и этим подмножеством политик ПБО.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе степени формализации, требуемой от модели ПБО, и степени формализации, требуемой при установлении соответствия между моделью ПБО и функциональной спецификацией.

Замечания по применению

В то время как ПБО может включать в себя любые политики, модели ПБО традиционно представляют только подмножества этих политик, потому что моделирование некоторых политик в настоящее время не представляется выполнимым. Современное состояние вопроса определяет политики, которые могут быть смоделированы, и автору ПЗ/ЗБ следует идентифицировать конкретные функции и связанные с ними политики, которые можно, и поэтому требуется, смоделировать. Как минимум, требуется моделировать политики управления доступом и информационными потоками (если они являются частью ПБО), так как в настоящее время это признается возможным.

В каждом из компонентов этого семейства присутствует требование описания в модели ПБО правил и характеристик применяемых политик ПБО и обеспечения, чтобы модель ПБО была адекватна соответствующим политикам ПБО. «Правила» и «характеристики» модели ПБО предназначены для обеспечения гибкости в выборе типа модели (например, переход из одного состояния в другое, невмешательство), которая может быть разработана. Например, правила могут быть представлены как «свойства» (например, простое свойство безопасности, при которой уровень доступа субъекта выше уровня доступа к объекту или равен ему), а характеристики могут быть представлены такими определениями, как «начальное состояние», «безопасное состояние», «субъекты» и «объекты».

Применительно к уровню формализации модели ПБО и соответствия между моделью ПБО и функциональной спецификацией неформальный, полуформальный и формальный уровни рассматривают как иерархичные по сути. Так, ADV_SPM.1.1C может быть удовлетворен полуформальной или формальной моделью ПБО, а ADV_SPM.2.1C — также формальной моделью ПБО. Помимо этого, ADV_SPM.2.5C и ADV_SPM.3.5C могут быть удовлетворены формальным доказательством соответствия. И, наконец, при отсутствии каких-либо требований к уровню формализации демонстрация соответствия может быть неформальной, полуформальной или формальной.

ADV_SPM.1 Неформальная модель политики безопасности ОО

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

Элементы действий разработчика

ADV_SPM.1.1D Разработчик должен представить модель ПБО.

ADV_SPM.1.2D Разработчик должен демонстрировать соответствие между функциональной спецификацией и моделью ПБО.

Элементы содержания и представления свидетельств

ADV_SPM.1.1C Модель ПБО должна быть неформальной.

ADV_SPM.1.2C Модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы.

ADV_SPM.1.3C Модель ПБО должна включать в себя логическое обоснование, которое демонстрирует, что она согласована и полна относительно всех политик ПБО, которые могут быть смоделированы.

ADV_SPM.1.4C Демонстрация соответствия между моделью ПБО и функциональной спецификацией должна показать, что все функции безопасности в функциональной спецификации являются непротиворечивыми и полными относительно модели ПБО.

Элементы действий оценщика

ADV_SPM.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_SPM.2 Полуформальная модель политики безопасности ОО

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

Элементы действий разработчика

ADV_SPM.2.1D Разработчик должен представить модель ПБО.

ADV_SPM.2.2D Разработчик должен демонстрировать соответствие между функциональной спецификацией и моделью ПБО.

Элементы содержания и представления свидетельств

ADV_SPM.2.1C Модель ПБО должна быть полуформальной.

ADV_SPM.2.2C Модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы.

ADV_SPM.2.3CМодель ПБО должна включать в себя логическое обоснование, которое демонстрирует, что она согласована и полна относительно всех политик ПБО, которые могут быть смоделированы.

ADV_SPM.2.4C Демонстрация соответствия между моделью ПБО и функциональной спецификацией должна показать, что все функции безопасности в функциональной спецификации являются непротиворечивыми и полными относительно модели ПБО.

ADV_SPM.2.5C Там, где функциональная спецификация, по меньшей мере, полуформальна, демонстрация соответствия между моделью ПБО и функциональной спецификацией должна быть полуформальной.

Элементы действий оценщика

ADV_SPM.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_SPM.3 Формальная модель политики безопасности ОО

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

Элементы действий разработчика

ADV_SPM.3.1D Разработчик должен представить модель ПБО.

ADV_SPM.3.2D Разработчик должен демонстрировать или доказать, где это требуется, соответствие между функциональной спецификацией и моделью ПБО.

Элементы содержания и представления свидетельств

ADV_SPM.3.1C Модель ПБО должна быть формальной.

ADV_SPM.3.2C Модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы.

ADV_SPM.3.3C Модель ПБО должна включать в себя логическое обоснование, которое демонстрирует, что она согласована и полна относительно всех политик ПБО, которые могут быть смоделированы.

ADV_SPM.3.4C Демонстрация соответствия между моделью ПБО и функциональной спецификацией должна показать, что все функции безопасности в функциональной спецификации являются непротиворечивыми и полными относительно модели ПБО.

ADV_SPM.3.5C Там, где функциональная спецификация полуформальна, демонстрация соответствия между моделью ПБО и функциональной спецификацией должна быть полуформальной.

ADV_SPM.3.6C Там, где функциональная спецификация формальна, доказательство соответствия между моделью ПБО и функциональной спецификацией должно быть формальным.

Элементы действий оценщика

ADV_SPM.3.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

11. Класс AGD. Руководства

Класс «Руководства» предоставляет требования к содержанию «Руководства администратора» и «Руководства пользователя». Для безопасного администрирования и использования ОО необходимо описать все аспекты, относящиеся к безопасному применению ОО.

На рисунке 11.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 11.1 — Декомпозиция класса «Руководства»

11.1 Руководство администратора (AGD_ADM)

Цели

Руководство администратора относится к печатным документам, которые предназначены для использования лицами, ответственными за правильное конфигурирование, сопровождение и администрирование ОО правильным способом в целях максимальной безопасности. Так как безопасность эксплуатации ОО зависит от правильного выполнения ФБО, лица, ответственные за выполнение указанных выше функций, являются доверенными для ФБО. Руководство предназначено способствовать пониманию администраторами функций безопасности, предоставляемых ОО, включая как функции, требующие выполнения администратором действий, критичных для безопасности, так и функции, предоставляющие информацию, критичную для безопасности.

Ранжирование компонентов

Это семейство содержит только один компонент.

Замечания по применению

Требования AGD_ADM.1.3C и AGD_ADM.1.7C касаются того аспекта, что в руководстве администратора приемлемо отражены все упомянутые в ПЗ/ЗБ предупреждения пользователям ОО, относящиеся к среде безопасности и целям безопасности ОО.

Понятие безопасных значений, как оно используется в AGD_ADM.1.5C, уместно при управлении администратором параметрами безопасности. В руководстве необходимо представить безопасные и опасные устанавливаемые значения для таких параметров. Это понятие связано с применением компонента FMT_MSA.2 из части 2 ОК.

AGD_ADM.1 Руководство администратора

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

Элементы действий разработчика

AGD_ADM.1.1D Разработчик должен представить руководство администратора, предназначенное для персонала системного администрирования.

Элементы содержания и представления свидетельств

AGD_ADM.1.1C Руководство администратора должно содержать описание функций администрирования и интерфейсов, доступных администратору ОО.

AGD_ADM.1.2C Руководство администратора должно содержать описание того, как управлять ОО безопасным способом.

AGD_ADM.1.3C Руководство администратора должно содержать предупреждения относительно функций и привилегий, которые следует контролировать в безопасной среде обработки информации.

AGD_ADM.1.4C Руководство администратора должно содержать описание всех предположений о поведении пользователя, которые связаны с безопасной эксплуатацией ОО.

AGD_ADM.1.5C Руководство администратора должно содержать описание всех параметров безопасности, контролируемых администратором, указывая, при необходимости, безопасные значения.

AGD_ADM.1.6C Руководство администратора должно содержать описание каждого типа относящихся к безопасности событий, связанных с выполнением обязательных функций администрирования, включая изменение характеристик безопасности сущностей, контролируемых ФБО.

AGD_ADM.1.7C Руководство администратора должно быть согласовано со всей другой документацией, представленной для оценки.

AGD_ADM.1.8C Руководство администратора должно содержать описание всех требований безопасности к среде ИТ, которые относятся к администратору.

Элементы действий оценщика

AGD_ADM.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

11.2 Руководство пользователя (AGD_USR)

Цели

Руководство пользователя относится к материалам, предназначенным для применения пользователями ОО, не связанными с администрированием, и другими лицами (например, программистами), использующими внешние интерфейсы ОО. Руководство описывает доступные пользователям функции безопасности, входящие в состав ФБО, и содержит инструкции и предписания, включая предупреждения, по их безопасному использованию.

Руководство пользователя предоставляет основание для предположений об использовании ОО и обеспечивает уверенность в том, что лояльные пользователи, поставщики приложений и прочие лица, использующие внешние интерфейсы ОО, поймут, как безопасно эксплуатировать ОО, и будут использовать его в соответствии с предназначением.

Ранжирование компонентов

Это семейство содержит только один компонент.

Замечания по применению

Требования AGD_USR.1.3C и AGD_USR.1.5C касаются того аспекта, что в руководстве пользователя приемлемо отражены все упомянутые в ПЗ/ЗБ предупреждения пользователям ОО, относящиеся к среде безопасности и целям безопасности ОО.

Во многих случаях может оказаться целесообразным, чтобы руководство было представлено раздельными документами: один для пользователей, а другой для прикладных программистов и/или проектировщиков аппаратных средств, использующих программные или аппаратные интерфейсы.

AGD_USR.1 Руководство пользователя

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

Элементы действий разработчика

AGD_USR.1.1D Разработчик должен представить руководство пользователя.

Элементы содержания и представления свидетельств

AGD_USR.1.1C Руководство пользователя должно содержать описание функций и интерфейсов, которые доступны пользователям ОО, не связанным с администрированием.

AGD_USR.1.2C Руководство пользователя должно содержать описание применения доступных пользователям функций безопасности, предоставляемых ОО.

AGD_USR.1.3C Руководство пользователя должно содержать предупреждения относительно доступных для пользователей функций и привилегий, которые следует контролировать в безопасной среде обработки информации.

AGD_USR.1.4C Руководство пользователя должно четко представить все обязанности пользователя, необходимые для безопасной эксплуатации ОО, включая обязанности, связанные с предположениями относительно действий пользователя, содержащимися в изложении среды безопасности ОО.

AGD_USR.1.5C Руководство пользователя должно быть согласовано со всей другой документацией, представленной для оценки.

AGD_USR.1.6C Руководство пользователя должно содержать описание всех требований безопасности к среде ИТ, которые имеют отношение к пользователю.

Элементы действий оценщика

AGD_USR.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

12. Класс ALC. Поддержка жизненного цикла

Поддержка жизненного цикла является аспектом установления дисциплины и контроля в процессе уточнения ОО во время его разработки и сопровождения. Уверенность в соответствии ОО требованиям безопасности к ОО больше, если анализ безопасности и формирование свидетельств выполняют на регулярной основе как неотъемлемую часть деятельности при разработке и сопровождении.

На рисунке 12.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 12.1 — Декомпозиция класса «Поддержка жизненного цикла»

12.1 Безопасность разработки (ALC_DVS)

Цели

Безопасность разработки связана с физическими, процедурными, относящимися к персоналу и другими мерами безопасности, которые могут применяться в среде разработки для защиты ОО. Она включает в себя физическую безопасность места разработки и любые процедуры, связанные с отбором персонала разработчиков.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе того, требуется ли строгое обоснование достаточности мер безопасности.

Замечания по применению

Семейство ALC_DVS связано с мерами по устранению или уменьшению угроз, существующих в месте разработки. Напротив, угрозы, противостоять которым предполагается по месту эксплуатации ОО, обычно учитывают в разделе «Среда безопасности» ПЗ или ЗБ.

Оценщику следует сделать заключение, необходимо ли ему посетить место разработки для подтверждения выполнения требований этого семейства.

Известно, что конфиденциальность не всегда может включаться в задачи защиты ОО в среде его разработки. Использование слова «необходимый» («necessary») предусматривает возможность выбора соответствующих мер защиты.

ALC_DVS.1 Идентификация мер безопасности

Зависимости отсутствуют.

Элементы действий разработчика

ALC_DVS.1.1D Разработчик должен иметь документацию по безопасности разработки.

Элементы содержания и представления свидетельств

ALC_DVS.1.1C Документация по безопасности разработки должна содержать описание всех физических, процедурных, относящихся к персоналу и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки.

ALC_DVS.1.2C Документация по безопасности разработки должна предоставить свидетельство, что необходимые меры безопасности соблюдаются во время разработки и сопровождения ОО.

Элементы действий оценщика

ALC_DVS.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_DVS.1.2E Оценщик должен подтвердить применение мер безопасности.

ALC_DVS.2 Достаточность мер безопасности

Зависимости отсутствуют.

Элементы действий разработчика

ALC_DVS.2.1D Разработчик должен иметь документацию по безопасности разработки.

Элементы содержания и представления свидетельств

ALC_DVS.2.1C Документация по безопасности разработки должна содержать описание всех физических, процедурных, относящихся к персоналу и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки.

ALC_DVS.2.2C Документация по безопасности разработки должна предоставить свидетельство, что необходимые меры безопасности соблюдаются во время разработки и сопровождения ОО.

ALC_DVS.2.3C Свидетельство должно содержать строгое обоснование, что меры безопасности обеспечивают необходимый уровень защиты конфиденциальности и целостности ОО.

Элементы действий оценщика

ALC_DVS.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_DVS.2.2E Оценщик должен подтвердить применение мер безопасности.

12.2 Устранение недостатков (ALC_FLR)

Цели

Семейство ALC_FLR содержит требование, чтобы обнаруженные недостатки безопасности были отслежены и исправлены разработчиком. Хотя при оценке ОО не может быть сделано заключение о его соответствии процедурам устранения недостатков в будущем, можно оценить политики и процедуры, которые предусмотрены разработчиком для отслеживания и исправления недостатков, а также распространения информации о недостатках и их исправлении.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе расширения области применения процедур устранения недостатков и повышения строгости политик устранения недостатков.

Замечания по применению

Это семейство обеспечивает доверие к сопровождению и поддержке ОО в будущем, требуя от разработчика ОО отслеживать и исправлять недостатки в ОО. Кроме того, имеются требования по распространению сведений об исправлениях недостатков. Однако это семейство не налагает требований, выходящих за рамки текущей оценки.

В процедурах устранения недостатков следует описать методы реагирования на недостатки всех типов, которым необходимо противостоять. Некоторые недостатки не могут быть исправлены немедленно. Не исключено, что недостаток вообще не может быть исправлен, и необходимо применить другие (например, процедурные) меры. Представленную документацию следует распространить на процедуры по обеспечению исправлений в местах эксплуатации, а также для предоставления информации о недостатках, для которых исправление отложено (и что делать в этой ситуации) или невозможно.

ALC_FLR.1 Базовое устранение недостатков

Зависимости отсутствуют.

Элементы действий разработчика

ALC_FLR.1.1D Разработчик должен задокументировать процедуры устранения недостатков.

Элементы содержания и представления свидетельств

ALC_FLR.1.1C Документация процедур устранения недостатков должна содержать описание процедур по отслеживанию всех ставших известными недостатков безопасности в каждой редакции ОО.

ALC_FLR.1.2C Процедуры устранения недостатков должны содержать требование представления описания природы и проявлений каждого недостатка безопасности, а также статуса завершения исправления этого недостатка.

ALC_FLR.1.3C Процедуры устранения недостатков должны содержать требование, чтобы действия по исправлению были идентифицированы для каждого недостатка безопасности.

ALC_FLR.1.4C Документация процедур устранения недостатков должна содержать описание методов, используемых для предоставления пользователям ОО информации о недостатках, материалов исправлений и руководства по внесению исправлений.

Элементы действий оценщика

ALC_FLR.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_FLR.2 Процедуры сообщений о недостатках

Зависимости отсутствуют.

Элементы действий разработчика

ALC_FLR.2.1D Разработчик должен задокументировать процедуры устранения недостатков.

ALC_FLR.2.2D Разработчик должен установить процедуру приема и отработки сообщений пользователей о недостатках безопасности и запросов на их исправление.

Элементы содержания и представления свидетельств

ALC_FLR.2.1C Документация процедур устранения недостатков должна содержать описание процедур по отслеживанию всех ставших известными недостатков безопасности в каждой редакции ОО.

ALC_FLR.2.2C Процедуры устранения недостатков должны содержать требование представления описания природы и проявлений каждого недостатка безопасности, а также статуса завершения исправления этого недостатка.

ALC_FLR.2.3C Процедуры устранения недостатков должны содержать требование, чтобы действия по исправлению были идентифицированы для каждого недостатка безопасности.

ALC_FLR.2.4C Документация процедур устранения недостатков должна содержать описание методов, используемых для предоставления пользователям ОО информации о недостатках, материалов исправлений и руководства по внесению исправлений.

ALC_FLR.2.5C Процедуры обработки недостатков безопасности, ставших известными, должны обеспечить, чтобы любые ставшие известными недостатки были исправлены, а исправления изданы.

ALC_FLR.2.6C Процедуры обработки недостатков безопасности, ставших известными, должны предоставить такие меры безопасности, чтобы любые исправления этих недостатков не приводили к появлению новых.

Элементы действий оценщика

ALC_FLR.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_FLR.3 Систематическое устранение недостатков

Зависимости отсутствуют.

Элементы действий разработчика

ALC_FLR.3.1D Разработчик должен задокументировать процедуры устранения недостатков.

ALC_FLR.3.2D Разработчик должен установить процедуру приема и отработки сообщений пользователей о недостатках безопасности и запросов на исправление этих недостатков.

ALC_FLR.3.3D Разработчик должен указать один или несколько адресов для сообщений и запросов пользователей о проблемах безопасности, касающихся ОО.

Элементы содержания и представления свидетельств

ALC_FLR.3.1C Документация процедур устранения недостатков должна содержать описание процедур по отслеживанию всех ставших известными недостатков безопасности в каждом выпуске ОО.

ALC_FLR.3.2C Процедуры устранения недостатков должны содержать требование представления описания природы и проявлений каждого недостатка безопасности, а также статуса завершения исправления этого недостатка.

ALC_FLR.3.3C Процедуры устранения недостатков должны содержать требование, чтобы действия по исправлению были идентифицированы для каждого недостатка безопасности.

ALC_FLR.3.4C Документация процедур устранения недостатков должна содержать описание методов, используемых для предоставления пользователям ОО информации о недостатках, материалов исправлений и руководства по внесению исправлений.

ALC_FLR.3.5C Процедуры обработки недостатков безопасности, ставших известными, должны обеспечить, чтобы любые ставшие известными недостатки были исправлены, а исправления изданы.

ALC_FLR.3.6C Процедуры обработки недостатков безопасности, ставших известными, должны предоставить такие меры безопасности, чтобы любые исправления этих недостатков не приводили к появлению новых.

ALC_FLR.3.7C Процедуры устранения недостатков должны включать процедуру автоматического распространения сообщений о недостатках безопасности и их исправлении зарегистрированным пользователям, которым эти недостатки могут причинить ущерб.

Элементы действий оценщика

ALC_FLR.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

12.3 Определение жизненного цикла (ALC_LCD)

Цели

Плохо управляемые разработка и сопровождение ОО могут приводить к неправильной реализации ОО (или к ОО, который отвечает не всем требованиям безопасности). Это, в свою очередь, приводит к нарушениям безопасности. Поэтому важно, чтобы в жизненном цикле ОО была как можно раньше установлена модель разработки и сопровождения ОО.

Использование модели разработки и сопровождения ОО не гарантирует, что ОО не будет содержать недостатки и будет отвечать всем функциональным требованиям безопасности. Может оказаться, что выбранная модель будет недостаточной или неадекватной, и поэтому выигрыш в качестве ОО не будет заметен. Использование модели жизненного цикла, которая одобрена некоторой группой экспертов (например, специалистами-теоретиками, органами стандартизации), повышает вероятность, что модель разработки и сопровождения будет содействовать достижению требуемого качества ОО.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе повышения требований к стандартизации и измеримости модели жизненного цикла, а также к согласованности с этой моделью.

Замечания по применению

Модель жизненного цикла объединяет процедуры, инструментальные средства и методы, используемые для разработки и сопровождения ОО. Аспекты процесса, которые могут быть охвачены такой моделью, включают в себя методы проектирования, процедуры просмотра, средства управления проектом, процедуры контроля изменений, методы тестирования и процедуры приемки. Эффективная модель жизненного цикла позволит включить аспекты процесса разработки и сопровождения в общую структуру управления, которая устанавливает обязанности и контролирует развитие.

Оценка аспектов сопровождения ОО повышает доверие к ОО за счет анализа информации о жизненном цикле ОО, представленной во время оценки до начала сопровождения.

Стандартизованная модель жизненного цикла — модель, которая была одобрена некоторой группой экспертов (например, специалистами-теоретиками, органами стандартизации).

Измеримая модель жизненного цикла — модель с количественными параметрами и/или метриками, используемыми для измерения характеристик разработки ОО (например, метрикой сложности исходного текста).

Модель жизненного цикла обеспечивает необходимый контроль за разработкой и сопровождением ОО, если разработчик может предоставить информацию, которая показала бы, что модель приемлемым образом минимизирует риск нарушений безопасности в ОО. При определении модели для части жизненного цикла после поставки ОО может быть полезна информация о предполагаемой среде ОО и целях безопасности ОО, приведенная в ЗБ.

ALC_LCD.1 Определение модели жизненного цикла разработчиком

Зависимости отсутствуют.

Элементы действий разработчика

ALC_LCD.1.1D Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.

ALC_LCD.1.2D Разработчик должен представить документацию по определению жизненного цикла.

Элементы содержания и представления свидетельств

ALC_LCD.1.1C Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО.

ALC_LCD.1.2C Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.

Элементы действий оценщика

ALC_LCD.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_LCD.2 Стандартизованная модель жизненного цикла

Зависимости отсутствуют.

Элементы действий разработчика

ALC_LCD.2.1D Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.

ALC_LCD.2.2D Разработчик должен представить документацию по определению жизненного цикла.

ALC_LCD.2.3D Разработчик должен использовать стандартизованную модель жизненного цикла для разработки и сопровождения ОО.

Элементы содержания и представления свидетельств

ALC_LCD.2.1C Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО.

ALC_LCD.2.2C Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.

ALC_LCD.2.3C Документация по определению жизненного цикла должна объяснить выбор модели.

ALC_LCD.2.4C Документация по определению жизненного цикла должна объяснить, как модель используется при разработке и сопровождении ОО.

ALC_LCD.2.5C Документация по определению жизненного цикла должна демонстрировать согласованность со стандартизованной моделью жизненного цикла.

Элементы действий оценщика

ALC_LCD.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_LCD.3 Измеримая модель жизненного цикла

Зависимости отсутствуют.

Элементы действий разработчика

ALC_LCD.3.1D Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.

ALC_LCD.3.2D Разработчик должен представить документацию по определению жизненного цикла.

ALC_LCD.3.3D Разработчик должен использовать стандартизованную и измеримую модель жизненного цикла для разработки и сопровождения ОО.

ALC_LCD.3.4D Разработчик должен количественно оценить процесс разработки ОО, используя стандартизованную и измеримую модель жизненного цикла.

Элементы содержания и представления свидетельств

ALC_LCD.3.1C Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО, включая детализацию ее количественных параметров и/или метрик, используемых для оценки соответствия процесса разработки ОО принятой модели.

ALC_LCD.3.2C Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.

ALC_LCD.3.3C Документация по определению жизненного цикла должна объяснить выбор модели.

ALC_LCD.3.4C Документация по определению жизненного цикла должна объяснить, как модель используется при разработке и сопровождении ОО.

ALC_LCD.3.5C Документация по определению жизненного цикла должна демонстрировать согласованность со стандартизованной и измеримой моделью жизненного цикла.

ALC_LCD.3.6C Документация по жизненному циклу должна представить результаты количественной оценки процесса разработки ОО с использованием стандартизованной и измеримой модели жизненного цикла.

Элементы действий оценщика

ALC_LCD.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

12.4 Инструментальные средства и методы (ALC_TAT)

Семейство ALC_TAT связано с выбором инструментальных средств, используемых для разработки, анализа и реализации ОО. Семейство содержит требования по предотвращению использования плохо определенных, несогласованных или неподходящих инструментальных средств разработки ОО. Это относится, в частности, к языкам программирования, документации, стандартам реализации и некоторым частям ОО, например вспомогательным динамическим библиотекам.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе повышения требований к описанию и области применения стандартов реализации и документации по опциям, зависимым от реализации.

Замечания по применению

Полностью определенными называют инструментальные средства разработки, которые применимы без необходимости подробных дополнительных пояснений. Например, принято считать полностью определенными языки программирования и системы автоматизации проектирования (САПР), которые основаны на стандартах, изданных органами стандартизации.

В данном семействе различают стандарты реализации, которые применялись разработчиком (ALC_TAT.2.3D), и стандарты реализации для «всех частей ОО» (ALC_TAT.3.3D), куда дополнительно включены программные, аппаратные или программно-аппаратные средства сторонних разработчиков.

Требование в ALC_TAT.1.2C применяют, главным образом, к языкам программирования для обеспечения однозначности всех операторов исходного текста.

ALC_TAT.1 Полностью определенные инструментальные средства разработки

Зависимости

ADV_IMP.1 Подмножество реализации ФБО

Элементы действий разработчика

ALC_TAT.1.1D Разработчик должен идентифицировать инструментальные средства разработки ОО.

ALC_TAT.1.2D Разработчик должен задокументировать выбранные опции инструментальных средств разработки, зависящие от реализации.

Элементы содержания и представления свидетельств

ALC_TAT.1.1C Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены.

ALC_TAT.1.2C Документация инструментальных средств разработки должна однозначно определить значения всех конструкций языка, используемых в реализации.

ALC_TAT.1.3C Документация инструментальных средств разработки должна однозначно определить значения всех опций, зависящих от реализации.

Элементы действий оценщика

ALC_TAT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_TAT.2 Соответствие стандартам реализации

Зависимости

ADV_IMP.1 Подмножество реализации ФБО

Элементы действий разработчика

ALC_TAT.2.1D Разработчик должен идентифицировать инструментальные средства разработки ОО.

ALC_TAT.2.2D Разработчик должен задокументировать выбранные опции инструментальных средств разработки, зависящие от реализации.

ALC_TAT.2.3D Разработчик должен привести описание применявшихся стандартов реализации.

Элементы содержания и представления свидетельств

ALC_TAT.2.1C Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены.

ALC_TAT.2.2C Документация инструментальных средств разработки должна однозначно определить значения всех конструкций языка, используемых в реализации.

ALC_TAT.2.3C Документация инструментальных средств разработки должна однозначно определить значения всех опций, зависящих от реализации.

Элементы действий оценщика

ALC_TAT.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_TAT.2.2E Оценщик должен подтвердить, что стандарты реализации применялись.

ALC_TAT.3 Соответствие всех частей ОО стандартам реализации

Зависимости

ADV_IMP.1 Подмножество реализации ФБО

Элементы действий разработчика

ALC_TAT.3.1D Разработчик должен идентифицировать инструментальные средства разработки ОО.

ALC_TAT.3.2D Разработчик должен задокументировать выбранные опции инструментальных средств разработки, зависящие от реализации.

ALC_TAT.3.3D Разработчик должен привести описание стандартов реализации для всех частей ОО.

Элементы содержания и представления свидетельств

ALC_TAT.3.1C Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены.

ALC_TAT.3.2C Документация инструментальных средств разработки должна однозначно определить значения всех конструкций языка, используемых в реализации.

ALC_TAT.3.3C Документация инструментальных средств разработки должна однозначно определить значения всех опций, зависящих от реализации.

Элементы действий оценщика

ALC_TAT.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ALC_TAT.3.2E Оценщик должен подтвердить, что стандарты реализации применялись.

13. Класс ATE. Тестирование

Класс «Тестирование» включает в себя четыре семейства: «Покрытие» (ATE_COV), «Глубина» (ATE_DPT), «Функциональное тестирование» (ATE_FUN) и «Независимое тестирование» (например, функциональное тестирование, выполняемое оценщиками, ATE_IND). Тестирование помогает установить, что функциональные требования безопасности ОО выполнены. Тестирование обеспечивает доверие к тому, что ОО удовлетворяет, по меньшей мере, функциональным требованиям безопасности ОО, хотя оно и не может установить, что ОО не обладает большими возможностями, чем определено спецификациями. Тестирование также может быть направлено на внутреннюю структуру ФБО, например тестирование подсистем и модулей на соответствие их спецификациям.

Аспекты покрытия и глубины отделены от функционального тестирования для повышения гибкости при применении компонентов семейств. Тем не менее, требования этих трех семейств предназначены для совместного применения.

Компоненты семейства «Независимое тестирование» имеют зависимости от компонентов других семейств, позволяющие получить необходимую информацию для поддержки требований, но при этом относятся в первую очередь к независимым действиям оценщика.

Основное внимание в этом классе уделено подтверждению того, что ФБО выполняются согласно их спецификациям. Для этого применяют и позитивное тестирование, основанное на функциональных требованиях, и негативное тестирование, чтобы проверить отсутствие нежелательных режимов выполнения. Этот класс не распространяется на тестирование проникновения, которое направлено на поиск уязвимостей, дающих пользователю возможность нарушить политику безопасности. Тестирование проникновения базируется на анализе ОО, направленном специально на идентификацию уязвимостей в проекте и реализации ФБО, и рассматривается отдельно как аспект оценки уязвимостей в классе AVA.

На рисунке 13.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 13.1 — Декомпозиция класса «Тестирование»

13.1 Покрытие (ATE_COV)

Цели

Семейство ATE_COV направлено на аспекты тестирования, которые имеют отношение к полноте охвата (покрытия) тестами. Таким образом, семейство связано с объемом тестирования ФБО, а также с выяснением, является ли тестирование достаточно всесторонним, чтобы демонстрировать выполнение ФБО в соответствии со спецификациями.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе повышения строгости тестирования интерфейсов и анализа достаточности тестов для демонстрации, что ФБО выполняются в соответствии с их функциональной спецификацией.

ATE_COV.1 Свидетельство покрытия

Цели

Цель этого компонента состоит в том, чтобы установить, что ФБО были проверены на соответствие их функциональной спецификации. Это предполагается достичь путем экспертизы свидетельства о соответствии, представленного разработчиком.

Замечания по применению

Несмотря на то, что цель тестирования состоит в полном покрытии ФБО, для верификации этого утверждения не требуется обеспечить ничего, помимо неформального сопоставления тестов с функциональной спецификацией и собственно данных тестирования.

В этом компоненте от разработчика требуется показать, насколько идентифицированные тесты соответствуют описанию ФБО в функциональной спецификации. Это может быть достигнуто представлением соответствия (возможно, с использованием таблицы). Эта информация требуется для содействия оценщику в планировании программы тестирования при оценке. На этом уровне нет требований полного покрытия разработчиком каждого аспекта ФБО, поэтому необходимо, чтобы оценщик принял во внимание возможные пробелы в этой области.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ATE_FUN.1 Функциональное тестирование

Элементы действий разработчика

ATE_COV.1.1D Разработчик должен представить свидетельство покрытия тестами.

Элементы содержания и представления свидетельств

ATE_COV.1.1C Свидетельство покрытия тестами должно показать соответствие между тестами, идентифицированными в тестовой документации, и описанием ФБО в функциональной спецификации.

Элементы действий оценщика

ATE_COV.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_COV.2 Анализ покрытия

Цели

Цель этого компонента состоит в том, чтобы установить, что ФБО были проверены на соответствие их функциональной спецификации систематическим методом. Это предполагается достичь путем экспертизы анализа соответствия, представленного разработчиком.

Замечания по применению

От разработчика требуется демонстрировать, что идентифицированные тесты включают в себя проверку всех функций безопасности, представленных в функциональной спецификации. При анализе следует не только показать соответствие между тестами и функциями безопасности, но также предоставить оценщику достаточную информацию для вынесения независимого заключения о том, насколько функции были проверены. Эта информация может быть использована при планировании дополнительных тестов оценщика. Хотя на этом уровне разработчик должен продемонстрировать, что каждая из функций в функциональной спецификации была проверена, исчерпывающее тестирование каждой функции не обязательно.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ATE_FUN.1 Функциональное тестирование

Элементы действий разработчика

ATE_COV.2.1D Разработчик должен представить анализ покрытия тестами.

Элементы содержания и представления свидетельств

ATE_COV.2.1C Анализ покрытия тестами должен демонстрировать соответствие между тестами, идентифицированными в тестовой документации, и описанием ФБО в функциональной спецификации.

ATE_COV.2.2C Анализ покрытия тестами должен демонстрировать полное соответствие между описанием ФБО в функциональной спецификации и тестами, идентифицированными в тестовой документации.

Элементы действий оценщика

ATE_COV.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_COV.3 Строгий анализ покрытия

Цели

Цель этого компонента состоит в том, чтобы установить, что ФБО были проверены систематическим и исчерпывающим образом на соответствие их функциональной спецификации. Это предполагается достичь путем экспертизы анализа соответствия, представленного разработчиком.

Замечания по применению

От разработчика требуется предоставить убедительные аргументы, что идентифицированные тесты покрывают все функции безопасности, а тестирование каждой функции безопасности является полным. Оценщику останется мало возможностей для разработки дополнительных функциональных тестов интерфейсов ФБО, основанных на функциональной спецификации, поскольку они будут исчерпывающе проверены. Тем не менее, оценщику следует стремиться разработать такие тесты.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ATE_FUN.1 Функциональное тестирование

Элементы действий разработчика

ATE_COV.3.1D Разработчик должен представить анализ покрытия тестами.

Элементы содержания и представления свидетельств

ATE_COV.3.1C Анализ покрытия тестами должен демонстрировать соответствие между тестами, идентифицированными в тестовой документации, и описанием ФБО в функциональной спецификации.

ATE_COV.3.2C Анализ покрытия тестами должен демонстрировать полное соответствие между описанием ФБО в функциональной спецификации и тестами, идентифицированными в тестовой документации.

ATE_COV.3.3C Анализ покрытия тестами должен убедительно демонстрировать, что все внешние интерфейсы ФБО, идентифицированные в функциональной спецификации, полностью проверены.

Элементы действий оценщика

ATE_COV.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

13.2 Глубина (ATE_DPT)

Цели

Компоненты семейства ATE_DPT имеют отношение к уровню детализации тестирования ФБО. Тестирование функций безопасности основано на детализации информации, полученной из анализа представлений.

Целью является противостоять риску пропуска ошибки при разработке ОО. Дополнительно компоненты этого семейства позволяют с большей вероятностью обнаружить любой внесенный злонамеренный код, особенно потому, что тестирование в большей степени касается внутренней структуры ФБО.

Тестирование конкретных внутренних интерфейсов может обеспечивать доверие не только к тому, что ФБО внешне соответствуют желательному режиму безопасности, но также к тому, что этот режим является следствием корректного функционирования внутренних механизмов.

Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе увеличения степени детализации, обеспеченной в представлениях ФБО, от проекта верхнего уровня до представления реализации. Это ранжирование отражает представления ФБО, рассмотренные в классе ADV.

Замечания по применению

Конкретный объем, а также типы документации и свидетельств будут определяться, в основном, выбранным компонентом из ATE_FUN.

Тестирование на уровне функциональной спецификации рассмотрено в ATE_COV.

В данном семействе принят принцип, чтобы уровень тестирования соответствовал искомому уровню доверия. Там, где применяют более высокие по иерархии компоненты, от результатов тестирования потребуется демонстрация того, что реализация ФБО не противоречит проекту ФБО. Например, в проекте верхнего уровня следует описать каждую из подсистем, а также интерфейсы для взаимодействия этих подсистем с достаточной детализацией. В свидетельстве тестирования необходимо показать, что были проверены внутренние интерфейсы для взаимодействия подсистем. Это может быть достигнуто либо тестированием через внешние интерфейсы ФБО, либо автономной проверкой интерфейсов подсистем, возможно с использованием средств и среды автономного тестирования. В случаях, когда некоторые аспекты внутреннего интерфейса не могут быть проверены через внешние интерфейсы, следует либо иметь строгое обоснование, что эти аспекты проверять необязательно, либо проверить этот внутренний интерфейс непосредственно. В последнем случае необходимо, чтобы проект верхнего уровня был достаточно детализирован для облегчения прямого тестирования. Иерархичные компоненты в этом семействе нацелены на проверку правильности использования внутренних интерфейсов, которые становятся видимыми, поскольку проект становится менее абстрактным. Когда применяют эти компоненты, сложнее предоставить адекватное свидетельство глубины тестирования, используя только внешние интерфейсы ФБО, поэтому, как правило, необходимо тестирование на уровне модулей.

ATE_DPT.1 Тестирование: проект верхнего уровня

Цели

Подсистемы ФБО обеспечивают высокоуровневое описание внутренних действий ФБО. Тестирование на уровне подсистем для демонстрации наличия любых недостатков обеспечивает доверие, что подсистемы ФБО были правильно реализованы.

Замечания по применению

Разработчик, как ожидается, опишет тестирование проекта верхнего уровня ФБО в терминах «подсистем». Термин «подсистема» используют, чтобы отразить декомпозицию ФБО на относительно малое число частей.

Зависимости

ADV_HLD.1 Описательный проект верхнего уровня

ATE_FUN.1 Функциональное тестирование

Элементы действий разработчика

ATE_DPT.1.1D Разработчик должен представить анализ глубины тестирования.

Элементы содержания и представления свидетельств

ATE_DPT.1.1C Анализ глубины должен показать достаточность тестов, идентифицированных в тестовой документации, для демонстрации, что ФБО выполняются в соответствии с проектом верхнего уровня.

Элементы действий оценщика

ATE_DPT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_DPT.2 Тестирование: проект нижнего уровня

Цели

Подсистемы ФБО обеспечивают высокоуровневое описание внутренних действий ФБО. Тестирование на уровне подсистем для демонстрации наличия любых недостатков обеспечивает доверие, что подсистемы ФБО были правильно реализованы.

Модули ФБО обеспечивают описание внутренних действий ФБО. Тестирование на уровне модулей для демонстрации наличия любых недостатков обеспечивает доверие, что модули ФБО были правильно реализованы.

Замечания по применению

Разработчик, как ожидается, опишет тестирование проекта верхнего уровня ФБО в терминах «подсистем». Термин «подсистема» используют, чтобы отразить декомпозицию ФБО на относительно малое число частей.

Разработчик, как ожидается, опишет тестирование проекта нижнего уровня ФБО в терминах «модулей». Термин «модуль» используют, чтобы отразить декомпозицию каждой из «подсистем» ФБО на относительно малое число частей.

Зависимости

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_LLD.1 Описательный проект нижнего уровня

ATE_FUN.1 Функциональное тестирование

Элементы действий разработчика

ATE_DPT.2.1D Разработчик должен представить анализ глубины тестирования.

Элементы содержания и представления свидетельств

ATE_DPT.2.1C Анализ глубины должен показать достаточность тестов, идентифицированных в тестовой документации, для демонстрации, что ФБО выполняются в соответствии с проектом верхнего уровня и проектом нижнего уровня.

Элементы действий оценщика

ATE_DPT.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_DPT.3 Тестирование на уровне реализации

Цели

Подсистемы ФБО обеспечивают высокоуровневое описание внутренних действий ФБО. Тестирование на уровне подсистем для демонстрации наличия любых недостатков обеспечивает доверие, что подсистемы ФБО были правильно реализованы.

Модули ФБО обеспечивают описание внутренних действий ФБО. Тестирование на уровне модулей для демонстрации наличия любых недостатков обеспечивает доверие, что модули ФБО были правильно реализованы.

Представление реализации ФБО обеспечивает детализированное описание внутренних действий ФБО. Тестирование на уровне реализации для демонстрации наличия любых недостатков обеспечивает доверие, что реализация ФБО была выполнена правильно.

Замечания по применению

Разработчик, как ожидается, опишет тестирование проекта верхнего уровня ФБО в терминах «подсистем». Термин «подсистема» используют, чтобы отразить декомпозицию ФБО на относительно малое число частей.

Разработчик, как ожидается, опишет тестирование проекта нижнего уровня ФБО в терминах «модулей». Термин «модули» используют, чтобы отразить декомпозицию каждой из «подсистем» ФБО на относительно малое число частей.

Представление реализации используют непосредственно для генерации реализации ФБО (например, исходный текст, который затем компилируют).

Зависимости

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_IMP.2 Реализация ФБО

ADV_LLD.1 Описательный проект нижнего уровня

ATE_FUN.1 Функциональное тестирование

Элементы действий разработчика

ATE_DPT.3.1D Разработчик должен представить анализ глубины тестирования.

Элементы содержания и представления свидетельств

ATE_DPT.3.1C Анализ глубины должен показать достаточность тестов, идентифицированных в тестовой документации, для демонстрации, что ФБО выполняются в соответствии с проектом верхнего уровня, проектом нижнего уровня и представлением реализации.

Элементы действий оценщика

ATE_DPT.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

13.3 Функциональное тестирование (ATE_FUN)

Цели

Функциональное тестирование, выполняемое разработчиком, устанавливает, что ФБО проявляют свойства, необходимые для удовлетворения функциональных требований ПЗ/ЗБ. Такое функциональное тестирование обеспечивает доверие к тому, что ОО, по меньшей мере, удовлетворяет функциональным требованиям безопасности ОО, хотя и не может установить, что ОО не обладает большими возможностями, чем определено спецификациями. Семейство ATE_FUN сосредоточено на типе и объеме необходимой документации или требуемых инструментальных средств поддержки, а также на том, что будет демонстрировать тестирование, проведенное разработчиком. Функциональное тестирование не ограничено позитивным подтверждением предоставления требуемых функций безопасности, но может также включать в себя негативное тестирование (часто основанное на инверсии функциональных требований) для проверки отсутствия нежелательных режимов функционирования.

Это семейство способствует обеспечению доверия, что вероятность наличия незамеченных недостатков относительно мала.

Семейства ATE_COV, ATE_DPT и ATE_FUN используют совместно для определения свидетельства тестирования, представляемого разработчиком. Независимое функциональное тестирование, выполняемое оценщиком, рассмотрено в ATE_IND.

Ранжирование компонентов

Это семейство содержит два компонента. Иерархичный компонент содержит требование, чтобы была проанализирована зависимость от порядка выполнения процедур тестирования.

Замечания по применению

Как ожидается, процедуры выполнения тестов будут обеспечены инструкциями по использованию тестовых программ и комплектов тестов, включая среду и условия тестирования, параметры и значения тестовых данных. Следует также, чтобы процедуры тестирования показывали, как результаты тестирования получаются из входных данных тестирования.

Это семейство определяет требования для представления всех планов, процедур и результатов тестирования. В соответствии с этим объем информации, которую необходимо представить, будет меняться в зависимости от использования ATE_COV и ATE_DPT.

Зависимость от порядка выполнения актуальна, когда успешное выполнение конкретного теста зависит от существования конкретного состояния. Например, можно потребовать, чтобы тест А выполнялся непосредственно перед тестом Б, так как состояние, следующее из успешного выполнения теста А, — предпосылка для успешного выполнения теста Б. Таким образом, неудача теста Б может быть связана с проблемой зависимости от порядка выполнения. В приведенном примере тест Б может закончиться неудачно, потому что тест В (а не A) был выполнен непосредственно перед ним, или же неудача теста Б связана с неудачей теста A.

ATE_FUN.1 Функциональное тестирование

Цели

Цель разработчика — демонстрировать, что все функции безопасности выполняются в соответствии со спецификациями. От разработчика требуется выполнить тестирование и представить тестовую документацию.

Зависимости отсутствуют.

Элементы действий разработчика

ATE_FUN.1.1D Разработчик должен протестировать ФБО и задокументировать результаты.

ATE_FUN.1.2D Разработчик должен представить тестовую документацию.

Элементы содержания и представления свидетельств

ATE_FUN.1.1C Тестовая документация должна состоять из планов и описаний процедур тестирования, а также ожидаемых и фактических результатов тестирования.

ATE_FUN.1.2C Планы тестирования должны идентифицировать проверяемые функции безопасности и содержать изложение целей тестирования.

ATE_FUN.1.3C Описания процедур тестирования должны идентифицировать тесты, которые необходимо выполнить, и включать в себя сценарии для тестирования каждой функции безопасности. Эти сценарии должны учитывать любое влияние последовательности выполнения тестов на результаты других тестов.

ATE_FUN.1.4C Ожидаемые результаты тестирования должны показать прогнозируемые выходные данные успешного выполнения тестов.

ATE_FUN.1.5C Результаты выполнения тестов разработчиком должны демонстрировать, что каждая проверенная функция безопасности выполнялась в соответствии со спецификациями.

Элементы действий оценщика

ATE_FUN.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_FUN.2 Упорядоченное функциональное тестирование

Цели

Цель разработчика — демонстрировать, что все функции безопасности выполняются в соответствии со спецификациями. От разработчика требуется выполнить тестирование и представить тестовую документацию.

Дополнительная цель данного компонента — обеспечение структурирования тестирования таким образом, чтобы избежать циклической зависимости при подтверждении правильности проверяемых частей ФБО.

Замечания по применению

Хотя процедуры тестирования могут устанавливать предопределенные начальные условия тестирования на основе упорядочения тестов, они могут не иметь логического обоснования упорядочения. Анализ упорядочения тестов — важный фактор в определении адекватности тестирования, так как имеется возможность наличия ошибок, скрытых порядком выполнения тестов.

Зависимости отсутствуют.

Элементы действий разработчика

ATE_FUN.2.1D Разработчик должен протестировать ФБО и задокументировать результаты.

ATE_FUN.2.2D Разработчик должен представить тестовую документацию.

Элементы содержания и представления свидетельств

ATE_FUN.2.1C Тестовая документация должна состоять из планов и описаний процедур тестирования, а также ожидаемых и фактических результатов тестирования.

ATE_FUN.2.2C Планы тестирования должны идентифицировать проверяемые функции безопасности и содержать изложение целей тестирования.

ATE_FUN.2.3C Описания процедур тестирования должны идентифицировать тесты, которые необходимо выполнить, и включать в себя сценарии для тестирования каждой функции безопасности. Эти сценарии должны учитывать любое влияние последовательности выполнения тестов на результаты других тестов.

ATE_FUN.2.4C Ожидаемые результаты тестирования должны показать прогнозируемые выходные данные успешного выполнения тестов.

ATE_FUN.2.5C Результаты выполнения тестов разработчиком должны демонстрировать, что каждая проверенная функция безопасности выполнялась в соответствии со спецификациями.

ATE_FUN.2.6C Тестовая документация должна включать в себя анализ зависимостей от порядка выполнения процедуры тестирования.

Элементы действий оценщика

ATE_FUN.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

13.4 Независимое тестирование (ATE_IND)

Цели

Главная цель — демонстрировать, что функции безопасности выполняются в соответствии со спецификациями.

Дополнительная цель — противостоять риску неправильной оценки разработчиком выходных данных тестов в результате неправильной реализации спецификаций или пропуска кода, который не согласуется со спецификациями.

Ранжирование компонентов

Ранжирование основано на объеме тестовой документации и поддержки тестирования, а также на объеме тестирования оценщиком.

Замечания по применению

Тестирование, рассматриваемое в этом семействе, может проводиться с привлечением, помимо оценщика, других квалифицированных исполнителей (например, независимой лаборатории, организации конечных потребителей). При этом тестирование требует понимания ОО с учетом выполнения других действий по установлению доверия к ОО, а оценщик по-прежнему отвечает за обеспечение удовлетворения требований данного семейства.

Это семейство имеет отношение к степени выполнения независимого функционального тестирования ФБО. Независимое функциональное тестирование может приобретать форму полного или частичного повторения функциональных тестов, выполненных разработчиком. Оно может также проводиться в дополнение к функциональным тестам, выполненным разработчиком, как для увеличения области покрытия или глубины тестов, так и для проверки очевидных, известных из общедоступных источников слабых мест безопасности, которые могут иметься в ОО. Эти действия дополняют друг друга, и для каждого ОО необходимо планировать приемлемое их сочетание с учетом применимости и области покрытия результатов тестов, а также функциональной сложности ФБО. Следует разработать план тестирования, согласующийся с уровнем других действий по установлению доверия к ОО, который, когда требуется более высокое доверие, включает в себя повторение большей выборки тестов и большего объема независимых позитивных и негативных функциональных тестов, выполняемых оценщиком.

Повторение выборки тестов, выполненных разработчиком, предназначено для обеспечения подтверждения, что разработчик выполнил свою запланированную программу тестирования ФБО и правильно зафиксировал результаты. На объем установленной выборки будут влиять детализация и качество результатов функционального тестирования разработчиком. Необходимо также, чтобы оценщик рассмотрел возможность разработки дополнительных тестов и соотношение результатов, которые могут быть получены по этим двум направлениям. Повторение всех тестов, выполненных разработчиком, может быть возможно и желательно в некоторых случаях, но весьма затруднено и менее продуктивно в других. Поэтому самый высокий по иерархии компонент этого семейства следует использовать осторожно. При формировании выборки рассматривается весь диапазон применения результатов тестирования, включая обеспечение выполнения требований семейств ATE_COV и ATE_DPT.

Необходимо также принять во внимание, что при оценке могут использоваться разные конфигурации ОО. Оценщику придется проанализировать применимость предоставленных результатов и в соответствии с этим планировать свое собственное тестирование.

Независимое функциональное тестирование отличается от тестирования проникновения, основанного на целенаправленном и систематическом поиске уязвимостей в проекте и/или реализации. Тестирование проникновения рассмотрено в семействе AVA_VLA.

Пригодность ОО для тестирования основана на доступности ОО и поддержке документацией и информацией, необходимой для выполнения тестов (включая любое тестовое программное обеспечение или инструментальные средства тестирования). Необходимость в такой поддержке отражена в зависимостях от других семейств доверия.

Кроме того, пригодность ОО для тестирования может основываться на других соображениях. Например, версия ОО, представленная разработчиком, может быть не окончательной.

Ссылки на подмножество ФБО предназначены для того, чтобы позволить оценщику проектировать приемлемую совокупность тестов, которая согласована с целями проводимой оценки.

ATE_IND.1Независимое тестирование на соответствие

Цели

Целью является демонстрация выполнения функций безопасности в соответствии со спецификациями.

Замечания по применению

Этот компонент не ориентирован на использование результатов тестирования разработчиком. Он применим, когда такие результаты недоступны, а также в случае, когда тестирование, выполненное разработчиком, принимается без проверки. От оценщика требуется разработать и выполнить тесты с целью подтверждения, что функциональные требования безопасности ОО удовлетворены. При этом подходе предполагается убедиться в правильном функционировании через репрезентативное тестирование, а не через выполнение всех возможных тестов. Объем тестирования, планируемый для этой цели, является методологической проблемой, и его необходимо рассматривать в контексте конкретного ОО и в сопоставлении с другими действиями оценки.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

ATE_IND.1.1D Разработчик должен представить ОО для тестирования.

Элементы содержания и представления свидетельств

ATE_IND.1.1C ОО должен быть пригоден для тестирования.

Элементы действий оценщика

ATE_IND.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_IND.1.2E Оценщик должен протестировать необходимое подмножество ФБО, чтобы подтвердить, что ОО функционирует в соответствии со спецификациями.

ATE_IND.2 Выборочное независимое тестирование

Цели

Целью является демонстрация выполнения функций безопасности в соответствии со спецификациями. Тестирование, проводимое оценщиком, включает в себя отбор и повторение тестов, выполненных разработчиком.

Замечания по применению

Разработчику следует обеспечить оценщика материалами, необходимыми для эффективного воспроизведения тестов, выполненных разработчиком. Сюда могут быть включены такие материалы, как машиночитаемая тестовая документация, тест-программы и т.д.

Этот компонент содержит требование, чтобы оценщику были доступны результаты тестирования разработчиком для дополнения программы тестирования. Оценщик повторит выборку из тестов, выполненных разработчиком, чтобы получить уверенность в полученных результатах. Получив такую уверенность, оценщик расширит тестирование, выполненное разработчиком, проводя дополнительные испытания ОО способом, отличающимся от примененного разработчиком. Основываясь на подтверждении достоверности результатов тестов, выполненных разработчиком, оценщик способен убедиться, что ОО функционирует правильно в более широком диапазоне условий, чем это было бы возможно для разработчика, ограниченного уровнем его ресурсов. Убедившись в том, что разработчик протестировал ОО, оценщик будет также иметь больше свободы для концентрации тестирования в тех направлениях, где экспертиза документации или специальные знания вызвали определенную настороженность.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

ATE_FUN.1 Функциональное тестирование

Элементы действий разработчика

ATE_IND.2.1D Разработчик должен представить ОО для тестирования.

Элементы содержания и представления свидетельств

ATE_IND.2.1C ОО должен быть пригоден для тестирования.

ATE_IND.2.2C Разработчик должен представить набор ресурсов, эквивалентных использованным им при функциональном тестировании ФБО.

Элементы действий оценщика

ATE_IND.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_IND.2.2E Оценщик должен протестировать необходимое подмножество ФБО, чтобы подтвердить, что ОО функционирует в соответствии со спецификациями.

ATE_IND.2.3E Оценщик должен выполнить выборку тестов из тестовой документации, чтобы верифицировать результаты тестирования, полученные разработчиком.

ATE_IND.3 Полное независимое тестирование

Цели

Целью является демонстрация выполнения функций безопасности в соответствии со спецификациями. Тестирование, проводимое оценщиком, включает в себя повторное выполнение всех тестов, выполненных разработчиком.

Замечания по применению

Разработчику следует обеспечить оценщика материалами, необходимыми для эффективного воспроизведения тестов, выполненных разработчиком. Сюда могут быть включены такие материалы, как машиночитаемая тестовая документация, тест-программы и т.д.

В этом компоненте требуется, чтобы оценщик повторил все тесты, выполненные разработчиком, как часть программы тестирования. Как и в предыдущем компоненте, оценщик проведет дополнительные испытания, стремясь проверить ОО способом, отличным от использованного разработчиком. В случае, когда тестирование разработчиком было исчерпывающим, для этого могут оставаться небольшие возможности.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

ATE_FUN.1 Функциональное тестирование

Элементы действий разработчика

ATE_IND.3.1D Разработчик должен представить ОО для тестирования.

Элементы содержания и представления свидетельств

ATE_IND.3.1C ОО должен быть пригоден для тестирования.

ATE_IND.3.2C Разработчик должен представить набор ресурсов, эквивалентных использованным им при функциональном тестировании ФБО.

Элементы действий оценщика

ATE_IND.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ATE_IND.3.2E Оценщик должен протестировать необходимое подмножество ФБО, чтобы подтвердить, что ОО функционирует в соответствии со спецификациями.

ATE_IND.3.3E Оценщик должен выполнить все тесты из тестовой документации, чтобы верифицировать результаты тестирования разработчиком.

14. Класс AVA. Оценка уязвимостей

Класс AVA связан с наличием пригодных для использования скрытых каналов и с возможностью неправильного применения или конфигурирования ОО, а также с возможностью преодоления вероятностных или перестановочных механизмов безопасности и использованием уязвимостей, вносимых при разработке или эксплуатации ОО.

На рисунке 14.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 14.1 — Декомпозиция класса «Оценка уязвимостей»

14.1 Анализ скрытых каналов (AVA_CCA)

Цели

Анализ скрытых каналов выполняют с целью сделать заключение о существовании и потенциальной пропускной способности непредусмотренных каналов передачи сигналов (т.е. неразрешенных информационных потоков), которые могут быть использованы.

Требования доверия связаны с угрозой существования непредусмотренных и пригодных для использования путей передачи сигналов, которые могут быть применены для нарушения ПФБ.

Ранжирование компонентов

Компоненты ранжированы по повышению строгости анализа скрытых каналов.

Замечания по применению

Оценка пропускной способности канала основана на технических расчетах, а также на фактических результатах выполнения тестов.

Примеры предположений, на которых основан анализ скрытых каналов, могут включать в себя быстродействие процессора, системную или сетевую конфигурацию, размер памяти, размер кэш-памяти.

Выборочное подтверждение правильности анализа скрытых каналов путем тестирования дает оценщику возможность верифицировать любые аспекты анализа (такие, как идентификация, оценка пропускной способности, удаление, мониторинг, сценарии применения). Это не требует демонстрации всех результатов анализа скрытых каналов.

Если в ЗБ не содержатся никакие ПФБ управления информационными потоками, это семейство требований доверия не применяют, поскольку оно относится только к ПФБ управления информационными потоками.

AVA_CCA.1 Анализ скрытых каналов

Цели

Целью является идентифицировать скрытые каналы, которые можно найти путем неформального поиска скрытых каналов.

Зависимости

ADV_FSP.2 Полностью определенные внешние интерфейсы

ADV_IMP.2 Реализация ФБО

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_CCA.1.1D Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.

AVA_CCA.1.2D Разработчик должен представить документацию анализа скрытых каналов.

Элементы содержания и представления свидетельств

AVA_CCA.1.1C Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.

AVA_CCA.1.2C Документация анализа должна содержать описание процедур, используемых для вынесения заключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытых каналов.

AVA_CCA.1.3C Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.

AVA_CCA.1.4C Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.

AVA_CCA.1.5C Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.

Элементы действий оценщика

AVA_CCA.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_CCA.1.2E Оценщик должен подтвердить, что результаты анализа скрытых каналов показывают, что ОО удовлетворяет функциональным требованиям.

AVA_CCA.1.3E Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.

AVA_CCA.2 Систематический анализ скрытых каналов

Цели

Целью является идентифицировать скрытые каналы, которые можно найти путем систематического поиска скрытых каналов.

Замечания по применению

Для систематического анализа скрытых каналов требуется, чтобы разработчик идентифицировал скрытые каналы структурированным и повторяемым образом, в противоположность идентификации скрытых каналов частным методом, применимым для конкретной ситуации.

Зависимости

ADV_FSP.2 Полностью определенные внешние интерфейсы

ADV_IMP.2 Реализация ФБО

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_CCA.2.1D Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.

AVA_CCA.2.2D Разработчик должен представить документацию анализа скрытых каналов.

Элементы содержания и представления свидетельств

AVA_CCA.2.1C Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.

AVA_CCA.2.2C Документация анализа должна содержать описание процедур, используемых для вынесения заключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытых каналов.

AVA_CCA.2.3C Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.

AVA_CCA.2.4C Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.

AVA_CCA.2.5C Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.

AVA_CCA.2.6C Документация анализа должна содержать свидетельство, что метод, использованный для идентификации скрытых каналов, является систематическим.

Элементы действий оценщика

AVA_CCA.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_CCA.2.2E Оценщик должен подтвердить, что результаты анализа скрытых каналов показывают, что ОО удовлетворяет функциональным требованиям.

AVA_CCA.2.3E Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.

AVA_CCA.3 Исчерпывающий анализ скрытых каналов

Цели

Целью является идентифицировать скрытые каналы, которые можно найти путем исчерпывающего поиска скрытых каналов.

Замечания по применению

Для исчерпывающего анализа скрытых каналов требуется представление дополнительного свидетельства, что план идентификации скрытых каналов достаточен для утверждения, что были испробованы все возможные пути исследования скрытых каналов.

Зависимости

ADV_FSP.2 Полностью определенные внешние интерфейсы

ADV_IMP.2 Реализация ФБО

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_CCA.3.1D Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.

AVA_CCA.3.2D Разработчик должен представить документацию анализа скрытых каналов.

Элементы содержания и представления свидетельств

AVA_CCA.3.1C Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.

AVA_CCA.3.2C Документация анализа должна содержать описание процедур, используемых для вынесения заключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытых каналов.

AVA_CCA.3.3C Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.

AVA_CCA.3.4C Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.

AVA_CCA.3.5C Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.

AVA_CCA.3.6C Документация анализа должна содержать свидетельство, что метод, использованный для идентификации скрытых каналов, является исчерпывающим.

Элементы действий оценщика

AVA_CCA.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_CCA.3.2E Оценщик должен подтвердить, что результаты анализа скрытых каналов показывают, что ОО удовлетворяет функциональным требованиям.

AVA_CCA.3.3E Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.

14.2 Неправильное применение (AVA_MSU)

Цели

Семейство AVA_MSU позволяет установить, может ли ОО быть конфигурирован или использован опасным образом так, чтобы администратор или пользователь ОО считал бы его безопасным.

Целями являются:

а) минимизация вероятности конфигурирования или установки ОО опасным образом, исключающим возможность обнаружения пользователем или администратором;

б) минимизация риска ошибок, обусловленных человеческим фактором или иными причинами, в операциях, которые могут блокировать, отключить или помешать активизировать функции безопасности, приводя к необнаруженному опасному состоянию.

Ранжирование компонентов

Компоненты ранжированы по возрастанию числа свидетельств, представляемых разработчиком, и повышению строгости анализа.

Замечания по применению

Противоречивое, вводящее в заблуждение, неполное или необоснованное руководство может убедить пользователя в безопасности ОО при ее отсутствии, что может привести к уязвимостям.

Примером противоречия является наличие двух инструкций руководства, которые подразумевают различные выходные результаты при одних и тех же входных данных.

Примером введения в заблуждение является такая формулировка инструкции руководства, которую можно трактовать неоднозначно, причем одна из трактовок может привести к опасному состоянию.

Примером неполноты является список существенных физических требований безопасности, в котором опущен важный пункт, что приведет к игнорированию соответствующего требования администратором, считающим список полным.

Примером необоснованности является рекомендация следовать процедуре, приводящей к чрезмерной административной нагрузке.

Требуется руководящая документация по выявлению опасных состояний. Она может быть включена в руководства пользователя и администратора или же представляться отдельно. При отдельном представлении оценщику следует подтвердить, что данная документация поставлена вместе с ОО.

AVA_MSU.1 Экспертиза руководств

Цели

Целью является обеспечить отсутствие в руководствах вводящих в заблуждение, необоснованных и противоречивых указаний и предусмотреть безопасные процедуры для всех режимов функционирования. Опасные состояния должны легко выявляться.

Зависимости

ADO_IGS.1 Процедуры установки, генерации и запуска

ADV_FSP.1 Неформальная функциональная спецификация

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_MSU.1.1D Разработчик должен представить руководства по применению ОО.

Элементы содержания и представления свидетельств

AVA_MSU.1.1C Руководства должны идентифицировать все возможные режимы эксплуатации ОО (включая действия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.

AVA_MSU.1.2C Руководства должны быть полны, понятны, непротиворечивы и обоснованы.

AVA_MSU.1.3C Руководства должны содержать список всех предположений относительно среды эксплуатации.

AVA_MSU.1.4C Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль над процедурами, физическими мерами и персоналом).

Элементы действий оценщика

AVA_MSU.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_MSU.1.2E Оценщик должен повторить все процедуры конфигурирования и установки для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства.

AVA_MSU.1.3E Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.

AVA_MSU.2 Подтверждение правильности анализа

Цели

Целью является обеспечить отсутствие в руководствах вводящих в заблуждение, необоснованных и противоречивых указаний и предусмотреть безопасные процедуры для всех режимов функционирования. Опасные состояния должны легко выявляться. В этом компоненте требуется анализ разработчиком руководств для повышения доверия, что цель достигнута.

Зависимости

ADO_IGS.1 Процедуры установки, генерации и запуска

ADV_FSP.1 Неформальная функциональная спецификация

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_MSU.2.1D Разработчик должен представить руководства по применению ОО.

AVA_MSU.2.2D Разработчик должен задокументировать анализ руководств.

Элементы содержания и представления свидетельств

AVA_MSU.2.1C Руководства должны идентифицировать все возможные режимы эксплуатации ОО (включая действия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.

AVA_MSU.2.2C Руководства должны быть полны, понятны, непротиворечивы и обоснованы.

AVA_MSU.2.3CРуководства должны содержать список всех предположений относительно среды эксплуатации.

AVA_MSU.2.4C Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль за процедурами, физическими мерами и персоналом).

AVA_MSU.2.5C Документация анализа должна демонстрировать, что руководства полны.

Элементы действий оценщика

AVA_MSU.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_MSU.2.2E Оценщик должен повторить все процедуры конфигурирования и установки и выборочно другие процедуры для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства.

AVA_MSU.2.3E Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.

AVA_MSU.2.4E Оценщик должен подтвердить, что документация анализа показывает обеспечение руководствами безопасного функционирования во всех режимах эксплуатации ОО.

AVA_MSU.3 Анализ и тестирование опасных состояний

Цели

Целью является обеспечить отсутствие в руководствах вводящих в заблуждение, необоснованных и противоречивых указаний и предусмотреть безопасные процедуры для всех режимов функционирования. Опасные состояния должны легко выявляться. В этом компоненте требуется анализ разработчиком руководств для повышения доверия, что цель достигнута, и этот анализ проверяется и подтверждается оценщиком путем тестирования.

Замечания по применению

В этом компоненте от оценщика требуется выполнить тестирование, что при переходе ОО в опасное состояние оно может быть легко выявлено. Это тестирование может рассматриваться как специфический аспект тестирования проникновения.

Зависимости

ADO_IGS.1 Процедуры установки, генерации и запуска

ADV_FSP.1 Неформальная функциональная спецификация

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_MSU.3.1D Разработчик должен представить руководства по применению ОО.

AVA_MSU.3.2D Разработчик должен задокументировать анализ руководств.

Элементы содержания и представления свидетельств

AVA_MSU.3.1C Руководства должны идентифицировать все возможные режимы эксплуатации ОО (включая действия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.

AVA_MSU.3.2C Руководства должны быть полны, понятны, непротиворечивы и обоснованы.

AVA_MSU.3.3C Руководства должны содержать список всех предположений относительно среды эксплуатации.

AVA_MSU.3.4C Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль за процедурами, физическими мерами и персоналом).

AVA_MSU.3.5C Документация анализа должна демонстрировать, что руководства полны.

Элементы действий оценщика

AVA_MSU.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_MSU.3.2E Оценщик должен повторить все процедуры конфигурирования и установки и выборочно другие процедуры для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства.

AVA_MSU.3.3E Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.

AVA_MSU.3.4E Оценщик должен подтвердить, что документация анализа показывает обеспечение руководствами безопасного функционирования во всех режимах эксплуатации ОО.

AVA_MSU.3.5E Оценщик должен выполнить независимое тестирование, чтобы сделать заключение, будут ли администратор или пользователь способны установить, руководствуясь документацией, что ОО конфигурирован или используется опасным образом.

14.3 Стойкость функций безопасности ОО (AVA_SOF)

Цели

Даже если функцию безопасности ОО нельзя обойти, отключить или исказить, в некоторых случаях все же существует возможность ее преодоления из-за уязвимости в концепции реализующих ее базовых механизмов безопасности. Для этих функций квалификация режима безопасности может быть проведена с использованием результатов количественного или статистического анализа режима безопасности указанных механизмов, а также усилий, требуемых для их преодоления. Квалификацию осуществляют в виде утверждения о стойкости функции безопасности ОО.

Ранжирование компонентов

В этом семействе имеется только один компонент.

Замечания по применению

Функции безопасности реализуются механизмами безопасности. Например, механизм пароля может использоваться при реализации функций идентификации и аутентификации.

Оценку стойкости функции безопасности ОО выполняют на уровне механизма безопасности, но ее результаты позволяют определить способность соответствующей функции безопасности противостоять идентифицированным угрозам.

При анализе стойкости функции безопасности ОО следует рассматривать, по меньшей мере, содержание всех поставляемых материалов ОО, включая ЗБ, с учетом намеченного оценочного уровня доверия.

AVA_SOF.1 Оценка стойкости функции безопасности ОО

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.1 Описательный проект верхнего уровня

Элементы действий разработчика

AVA_SOF.1.1D Разработчик должен выполнить анализ стойкости функции безопасности ОО для каждого механизма, идентифицированного в ЗБ как имеющего утверждение относительно стойкости функции безопасности ОО.

Элементы содержания и представления свидетельств

AVA_SOF.1.1C Для каждого механизма, имеющего утверждение относительно стойкости функции безопасности ОО, анализ должен показать, что ее стойкость достигает или превышает минимальный уровень стойкости, определенный в ПЗ/ЗБ.

AVA_SOF.1.2C Для каждого механизма, имеющего утверждение относительно конкретной стойкости функции безопасности ОО, анализ должен показать, что ее стойкость достигает или превышает конкретный показатель, определенный в ПЗ/ЗБ.

Элементы действий оценщика

AVA_SOF.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_SOF.1.2E Оценщик должен подтвердить, что утверждения относительно стойкости корректны.

14.4 Анализ уязвимостей (AVA_VLA)

Цели

Анализ уязвимостей позволяет сделать заключение, могут ли уязвимости, идентифицированные в процессе оценки ОО и его ожидаемого применения или другими методами (например, из гипотезы о недостатках), быть использованы пользователями для нарушения ПБО.

При анализе уязвимостей рассматривают угрозы, что пользователь будет в состоянии обнаружить недостатки, позволяющие получить несанкционированный доступ к ресурсам (например, данным), препятствовать выполнению ФБО и искажать их или же ограничивать санкционированные возможности других пользователей.

Ранжирование компонентов

Ранжирование основано на повышении строгости анализа уязвимостей разработчиком и оценщиком.

Замечания по применению

Разработчик выполняет анализ уязвимостей, чтобы установить присутствие уязвимостей безопасности; при этом следует рассматривать, по меньшей мере, содержание всех поставляемых материалов ОО, включая ЗБ, с учетом намеченного оценочного уровня доверия. От разработчика требуется задокументировать местоположение идентифицированных уязвимостей, чтобы позволить оценщику использовать эту информацию, если ее признают полезной, для поддержки независимого анализа уязвимостей оценщиком.

Анализ, проводимый разработчиком, предназначен для подтверждения невозможности использования идентифицированных уязвимостей безопасности в предполагаемой среде ОО и стойкости ОО к явным нападениям проникновения.

Под явными уязвимостями понимают те, которые открыты для использования, требующего минимума понимания ОО, умений, технического опыта и ресурсов. Они могут быть подсказаны описанием интерфейса ФБО. К явным уязвимостям относятся известные из общедоступных источников (и разработчику следует детально знать их) или полученные от органа оценки.

Систематический поиск уязвимостей предусматривает, чтобы разработчик идентифицировал эти уязвимости структурированным и повторяемым образом, в противоположность идентификации их частными методами. Следует, чтобы свидетельство того, что поиск уязвимостей был систематическим, включало в себя идентификацию всей документации ОО, на которой был основан поиск недостатков.

Независимый анализ уязвимостей не ограничивается уязвимостями, идентифицированными разработчиком. Основная цель анализа, проводимого оценщиком, — сделать заключение, что ОО является стойким к нападениям проникновения со стороны нарушителя, обладающего низким (для AVA_VLA.2), умеренным (для AVA_VLA.3) или высоким (для AVA_VLA.4) потенциалом нападения. Для выполнения этой цели оценщик сначала проверяет возможности использования всех идентифицированных уязвимостей. Это осуществляется посредством тестирования проникновения. Оценщику следует принять на себя роль нарушителя с одним из указанным выше потенциалов нападения при попытке проникновения в ОО. Любое использование уязвимостей таким нарушителем оценщику следует рассматривать как «явное нападение проникновения» (в отношении элементов AVA_VLA.*.2C) в контексте компонентов AVA_VLA.2-4.

AVA_VLA.1 Анализ уязвимостей разработчиком

Цели

Разработчик выполняет анализ уязвимостей, чтобы установить присутствие явных уязвимостей безопасности и подтвердить, что они не могут быть использованы в предполагаемой среде ОО.

Замечания по применению

Оценщику следует предусмотреть дополнительные тесты для уязвимостей, выявленных при выполнении других частей оценки и потенциально пригодных для использования.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.1 Описательный проект верхнего уровня

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_VLA.1.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску явных путей, которыми пользователь может нарушить ПБО.

AVA_VLA.1.2D Разработчик должен задокументировать местоположение явных уязвимостей.

Элементы содержания и представления свидетельств

AVA_VLA.1.1C Документация должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.

Элементы действий оценщика

AVA_VLA.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_VLA.1.2E Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета явных уязвимостей.

AVA_VLA.2 Независимый анализ уязвимостей

Цели

Разработчик выполняет анализ уязвимостей, чтобы установить присутствие уязвимостей безопасности и подтвердить, что они не могут быть использованы в предполагаемой среде ОО.

Оценщик выполняет независимое тестирование проникновения, поддержанное собственным независимым анализом уязвимостей, чтобы сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителями, обладающими низким потенциалом нападения.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_VLA.2.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску путей, которыми пользователь может нарушить ПБО.

AVA_VLA.2.2D Разработчик должен задокументировать местоположение идентифицированных уязвимостей.

Элементы содержания и представления свидетельств

AVA_VLA.2.1C Документация должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.

AVA_VLA.2.2C Документация должна содержать строгое обоснование, что ОО с идентифицированными уязвимостями является стойким к явным нападениям проникновения.

Элементы действий оценщика

AVA_VLA.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_VLA.2.2E Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета идентифицированных уязвимостей.

AVA_VLA.2.3E Оценщик должен выполнить независимый анализ уязвимостей.

AVA_VLA.2.4E Оценщик должен выполнить независимое тестирование проникновения, основанное на независимом анализе уязвимостей, и сделать независимое заключение о возможности использования дополнительно идентифицированных уязвимостей в предполагаемой среде.

AVA_VLA.2.5EОценщик должен сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителем, обладающим низким потенциалом нападения.

AVA_VLA.3 Умеренно стойкий

Цели

Разработчик выполняет анализ уязвимостей, чтобы установить присутствие уязвимостей безопасности и подтвердить, что они не могут быть использованы в предполагаемой среде ОО.

Оценщик выполняет независимое тестирование проникновения, поддержанное собственным независимым анализом уязвимостей, чтобы сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителями, обладающими умеренным потенциалом нападения.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_VLA.3.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску путей, которыми пользователь может нарушить ПБО.

AVA_VLA.3.2D Разработчик должен задокументировать местоположение идентифицированных уязвимостей.

Элементы содержания и представления свидетельств

AVA_VLA.3.1C Документация должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.

AVA_VLA.3.2C Документация должна содержать строгое обоснование, что ОО с идентифицированными уязвимостями является стойким к явным нападениям проникновения.

AVA_VLA.3.3C Свидетельство должно показать, что поиск уязвимостей является систематическим.

Элементы действий оценщика

AVA_VLA.3.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_VLA.3.2E Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета идентифицированных уязвимостей.

AVA_VLA.3.3E Оценщик должен выполнить независимый анализ уязвимостей.

AVA_VLA.3.4E Оценщик должен выполнить независимое тестирование проникновения, основанное на независимом анализе уязвимостей, и сделать независимое заключение о возможности использования дополнительно идентифицированных уязвимостей в предполагаемой среде.

AVA_VLA.3.5E Оценщик должен сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителем, обладающим умеренным потенциалом нападения.

AVA_VLA.4 Высокостойкий

Цели

Разработчик выполняет анализ уязвимостей, чтобы установить присутствие уязвимостей безопасности и подтвердить, что они не могут быть использованы в предполагаемой среде ОО.

Оценщик выполняет независимое тестирование проникновения, поддержанное собственным независимым анализом уязвимостей, чтобы сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителями, обладающими высоким потенциалом нападения.

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

AGD_ADM.1 Руководство администратора

AGD_USR.1 Руководство пользователя

Элементы действий разработчика

AVA_VLA.4.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску путей, которыми пользователь может нарушить ПБО.

AVA_VLA.4.2D Разработчик должен задокументировать местоположение идентифицированных уязвимостей.

Элементы содержания и представления свидетельств

AVA_VLA.4.1C Документация должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.

AVA_VLA.4.2C Документация должна содержать строгое обоснование, что ОО с идентифицированными уязвимостями является стойким к явным нападениям проникновения.

AVA_VLA.4.3C Свидетельство должно показать, что поиск уязвимостей является систематическим.

AVA_VLA.4.4C Документация анализа должна содержать строгое обоснование, что анализ полностью учитывает все поставляемые материалы ОО.

Элементы действий оценщика

AVA_VLA.4.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AVA_VLA.4.2E Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета идентифицированных уязвимостей.

AVA_VLA.4.3E Оценщик должен выполнить независимый анализ уязвимостей.

AVA_VLA.4.4E Оценщик должен выполнить независимое тестирование проникновения, основанное на независимом анализе уязвимостей, и сделать независимое заключение о возможности использования дополнительно идентифицированных уязвимостей в предполагаемой среде.

AVA_VLA.4.5E Оценщик должен сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителем, обладающим высоким потенциалом нападения.

15. Парадигма поддержки доверия

15.1 Введение

В этом разделе представлена парадигма поддержки доверия, которой посвящен класс «Поддержка доверия» (AMA). Здесь также приведена полезная информация, помогающая понять один из возможных подходов к применению требований класса AMA.

Поддержка доверия — понятие, применение которого предполагается после того, как ОО уже оценен и сертифицирован по критериям из разделов 4-5 и 8-14. Поддержка требований доверия направлена на получение уверенности в том, что ОО будет по-прежнему отвечать своему заданию по безопасности после изменений в ОО или его среде. К таким изменениям относятся: обнаружение новых угроз или уязвимостей, изменения в требованиях пользователя, исправление ошибок, обнаруженных в сертифицированном ОО, а также другие обновления функциональных возможностей ОО.

Одним из способов вынесения заключения о поддержке доверие является переоценка ОО. Термин «переоценка» здесь означает оценку новой версии ОО, учитывающую все относящиеся к безопасности изменения, произведенные в сертифицированной ранее версии ОО, при которой повторно используют результаты предыдущей оценки, оставшиеся актуальными. Однако во многих случаях вряд ли будет практично выполнять переоценку каждой новой версии ОО для дальнейшей поддержки доверия.

Поэтому главная цель класса AMA — определить совокупность требований, которые могут применяться, чтобы убедиться в поддержке установленного доверия к ОО, не требуя во всех случаях формальной переоценки новых версий ОО. Класс AMA не исключает полностью необходимость переоценки. В некоторых случаях изменения могут быть настолько значительными, что для дальнейшей поддержки доверия переоценка обязательна. Таким образом, требования этого класса имеют дополнительную цель по обеспечению, при необходимости, экономически оправданной переоценки ОО.

Следует отметить, что вполне возможна переоценка каждой новой версии ОО по критериям из разделов 4-5 и 8-14 вообще без учета требований класса AMA. Однако класс AMA включает в себя требования, которые могут быть использованы для поддержки любой такой переоценки.

Действия разработчика и оценщика по поддержке предполагается выполнять после того, как ОО был оценен и сертифицирован, хотя, как описано ниже, некоторые требования могут применяться и на стадии оценки. Примеры использования терминов в описании парадигмы:

а) сертифицированная версия ОО — версия, которая была оценена и сертифицирована;

б) текущая версия ОО — версия, которая в некотором смысле отличается от сертифицированной версии; это может быть, например:

— новый выпуск ОО,

— сертифицированная версия с обновлениями, внесенными для исправления вновь обнаруженных ошибок,

— та же самая базовая версия ОО, но на другой аппаратной или программной платформе.

Роли разработчика и оценщика в этом классе такие же, как и описанные в части 1 ОК. Однако совершенно необязательно, чтобы оценщик, упоминаемый в требованиях этого класса, ранее принимал участие в оценке сертифицированной версии ОО.

Чтобы сделать возможным продолжение поддержки доверия к ОО без обязательной формальной переоценки, требования этого класса накладывают на разработчика обязанность представить свидетельство, показывающее, что ОО по-прежнему удовлетворяет своему заданию по безопасности (например, свидетельство тестирования разработчиком).

15.2 Цикл поддержки доверия

Этот подраздел описывает один из возможных подходов к использованию семейств и компонентов поддержки доверия с целью проиллюстрировать использование рассматриваемых понятий. В качестве примера приведен «цикл поддержки доверия», разделенный на три следующие фазы:

а) приемка ОО для поддержки — начало цикла, когда планы и процедуры разработчика по поддержке доверия в течение цикла устанавливает разработчик, и затем их правильность независимо подтверждает оценщик;

б) мониторинг — разработчик предоставляет в одной или нескольких контрольных точках цикла свидетельство, что доверие к ОО поддерживается в соответствии с установленными планами и процедурами; это свидетельство поддержки доверия затем независимо проверяет оценщик;

в)переоценка — окончание цикла, когда обновленная версия ОО представляется на рассмотрение для переоценки, основанной на изменениях, которым подверглась сертифицированная версия ОО.

Семейства класса AMA связаны, прежде всего, с двумя первыми фазами, обеспечивая поддержку для третьей. Эти фазы введены здесь только для того, чтобы понятнее описать применение требований поддержки доверия. Не ставится цель сделать строго обязательной схему поддержки доверия, которая формально включает в себя эти три фазы.

Цикл поддержки доверия проиллюстрирован на рисунке 15.1.

Рисунок 15.1 — Пример цикла поддержки доверия

Рисунок 15.2. Пример подхода к приемке ОО

В рассматриваемом примере можно переходить к фазе мониторинга ОО только после успешного завершения фазы приемки (т.е. когда планы и процедуры разработчика по поддержке доверия уже приняты). Если разработчик вносит изменения в эти планы или процедуры в фазе мониторинга, необходимо вернуться к фазе приемки ОО, чтобы учесть произведенные изменения.

В фазе мониторинга разработчик выполняет планы и процедуры поддержки доверия, проводя анализ влияния на безопасность изменений, которым подвергается ОО (анализ влияния на безопасность). В определенных контрольных точках этой фазы оценщик независимо проверяет (посредством аудита) деятельность разработчика. От разработчика требуется четкое выполнение планов и процедур поддержки и анализа влияния на безопасность.

Поэтому при нахождении ОО в фазе мониторинга появляется возможность убедиться, что доверие к ОО поддерживается для новых версий ОО, выпущенных разработчиком.

ОО, который подвергается изменениям, не может пребывать в фазе мониторинга постоянно: в какой-то момент времени переоценка ОО становится необходимой. Время принятия решения о необходимости переоценки зависит от накопления изменений в ОО, а также от особо значительных изменений. Например, большое количество малых изменений может повлиять на доверие к ОО как одно значительное изменение. План разработчика по поддержке доверия определяет предел для изменений в ОО, которые могут быть внесены в фазе мониторинга (см. 15.3.1).

Подобным образом невозможно «повысить рейтинг» ОО (т.е. повысить его уровень доверия) в фазе мониторинга. Это может быть достигнуто только посредством новой оценки ОО (использующей, по возможности, результаты предыдущего оценивания).

Статус поддержки доверия к ОО должен быть пересмотрен, если будет обнаружено, что процедуры поддержки доверия не выполняются, в результате чего утрачивается доверие к ОО. В некоторых случаях от разработчика может потребоваться представление ОО для переоценки, после которой начнется новый цикл поддержки доверия.

15.2.1 Приемка ОО

В рассматриваемом примере фаза приемки ОО в цикле поддержки доверия может быть далее уточнена путем использования семейств «План поддержки доверия» и «Отчет о категорировании компонентов ОО» из класса AMA.

15.2.2 Мониторинг ОО

Фаза мониторинга ОО в цикле поддержки доверия будет уточнена ниже с использованием семейств «Свидетельство поддержки доверия» и «Анализ влияния на безопасность» класса AMA.

15.2.3 Переоценка

Третья фаза рассматриваемого примера цикла поддержки — переоценка, когда оценщик использует анализ влияния изменений и свидетельство поддержки доверия, чтобы заново выполнить экспертизу частей ОО, применяя компоненты доверия, соответствующие намеченному уровню доверия.

Переход к переоценке предусмотрен в плане поддержки доверия; он же может выполняться вследствие непредвиденных значительных изменений в ОО или его среде, после которых дальнейшая поддержка доверия окажется неприемлемой.

15.3 Класс и семейства поддержки доверия

Для осуществления концепции поддержки доверия был разработан класс AMA, включающий в себя четыре семейства, приведенные в таблице 15.1.

Таблица 15.1

ПРЕДСТАВЛЕНИЕ СЕМЕЙСТВ ПОДДЕРЖКИ ДОВЕРИЯ

Рисунок 15.3. Пример подхода к мониторингу ОО

15.3.1 План поддержки доверия

План поддержки доверия (ПД) определяет основную линию поведения при поддержке доверия в зависимости от результатов оценки и проведения категорирования компонентов ОО.

План ПД определяет процедуры, выполняемые разработчиком по мере изменений в ОО или его среде для обеспечения поддержки доверия, которое было установлено в сертифицированном ОО. План ПД распространяется на один цикл поддержки доверия.

План ПД определяет пределы изменений, которые могут быть сделаны в ОО без необходимости переоценки. Конкретный применяемый подход зависим от схемы, но следующие типы изменений, вероятно, обязательно приведут к переоценке, находясь, тем не менее, за пределами плана ПД:

а) значительное изменение задания по безопасности (т.е. значительные изменения среды безопасности, целей безопасности, функциональных требований безопасности или любое повышение требований доверия);

б) значительное изменение внешних интерфейсов ФБО, отнесенных к категории обеспечивающих осуществление ПБО;

в) значительное изменение подсистем ФБО, отнесенных к категории обеспечивающих осуществление ПБО (для случаев, когда требования доверия включают в себя ADV_HLD.1 или иерархичные компоненты).

Следует отметить, что на подход к изменениям, вносимым во время поддержки, могут повлиять любые функции, предусмотренные в ОО для поддержки автоматизированной проверки безопасности оцененной конфигурации. Такие функции могут предотвращать неприемлемые или наносящие ущерб изменения при внесении их в эксплуатируемый ОО.

Более подробная спецификация правил находится вне рамок ОК, в частности, из-за того, что смысл выражения значительное изменение будет зависеть от типа оцененного ОО и содержания задания по безопасности.

В плане ПД требуется определить или сослаться на процедуры, которые будут использоваться для обеспечения поддержки доверия к ОО на протяжении данного цикла поддержки. Идентифицированы четыре типа процедур, которые рекомендуется применять:

г) по управлению конфигурацией, которые контролируют и регистрируют изменения в ОО для поддержки анализа влияния на безопасность, проводимого разработчиком, а также в сопроводительной документации (включая собственно план ПД);

д) по поддержке «свидетельства доверия» (т.е. поддержке задокументированного свидетельства, предписанного соответствующими требованиями доверия), ключевой аспект которых — функциональное тестирование ФБО и, в частности, политика регрессивного тестирования разработчиком;

е) регламентирующие анализ влияния на безопасность изменений, воздействующих на ОО (включая изменения в среде ОО типа новых угроз или методов нападения, которые могут нуждаться в идентификации и отслеживании), а также поддержку отчета о категорировании компонентов ОО по мере внесения изменений;

ж) по устранению недостатков, включая отслеживание и исправление выявленных недостатков безопасности (как предусматривает ALC_FLR.1).

План ПД, как ожидается, останется действующим до завершения цикла поддержки доверия (т.е. завершения запланированной переоценки), после которого потребуется новый план. План ПД, как ожидается, будет признан недействительным, если разработчик не придерживается этого плана или вносит изменения в ОО, находящиеся вне рамок этого плана, или вынужден внести подобные изменения в ОО, чтобы он оставался эффективным в пределах своей среды. Обновленный план ПД следует заново представить на рассмотрение и принять прежде, чем ОО войдет в новую фазу мониторинга.

План ПД предусматривает, чтобы разработчик определил аналитика безопасности от разработчика, ответственного за постоянный контроль процесса поддержки доверия. Эту роль могут выполнять и несколько человек. Требуется, чтобы аналитик хорошо знал ОО, результаты оценки и примененные требования доверия, что является необходимым условием для успешной работы. Требования не определяют, как достигается этот уровень знаний и опыта; однако, вероятно, предполагаемый аналитик должен пройти обучение в какой-либо форме, чтобы устранить все пробелы в своих знаниях и навыках. Необходимо, чтобы аналитик имел достаточные полномочия внутри организации разработчика для выполнения требований плана ПД и связанных с ним процедур.

15.3.2 Отчет о категорировании компонентов ОО

Назначение отчета о категорировании компонентов ОО состоит в том, чтобы дополнить план ПД категорированием компонентов ОО (например, подсистем ФБО) по их отношению к безопасности. Это категорирование занимает центральное место как в анализе влияния на безопасность, проводимом разработчиком, так и при последующей переоценке ОО.

Проверка отчета о категорировании компонентов ОО происходит в фазе приемки, причем оценщик проверяет только версию отчета для сертифицированной версии ОО. Хотя процедуры поддержки доверия, идентифицированные в плане ПД, требуют от разработчика обновления отчета о категорировании компонентов ОО по мере внесения изменений в ОО, от оценщика не требуется делать заново обзор документа; в то же время, любые такие обновления, вероятно, будут внимательно проверяться в фазе мониторинга.

Отчет о категорировании компонентов ОО распространяется на все представления ФБО на поддерживаемом уровне доверия. Отчет о категорировании компонентов ОО также идентифицирует:

а) любые аппаратные, программно-аппаратные и программные компоненты, которые являются внешними по отношению к ОО (например, аппаратные или программные платформы) и удовлетворяют требованиям безопасности ИТ, определенным в ЗБ;

б) любые инструментальные средства разработки, модификация которых будет влиять на требуемое доверие к тому, что ОО удовлетворяет своему ЗБ.

Отчет о категорировании компонентов ОО также содержит описание подхода, используемого для категорирования компонентов ОО. Как минимум, компоненты ОО требуется разделить на осуществляющие и не осуществляющие ПБО. Описание схемы категорирования предназначено, чтобы дать возможность аналитику безопасности от разработчика выбрать категорию, к которой следует отнести каждый новый компонент ОО, а также, когда потребуется, изменить категорию существующего компонента ОО после изменений в ОО или его ЗБ.

Начальное категорирование компонентов ОО будет основано на свидетельстве, представленном разработчиком для поддержки оценки ОО и независимо подтвержденном оценщиком. Хотя за поддержку документа отвечает аналитик безопасности от разработчика, начальное его содержание может быть основано на результатах оценки ОО.

Представляется полезным включать в ЗБ компонент AMA_CAT.1, где имеется требование поддержки доверия в последующих версиях ОО. Оно применяется независимо от того, достигается ли поддержка доверия использованием требований этого класса или же периодической переоценкой ОО.

15.3.3 Свидетельство поддержки доверия

Необходимо убедиться в том, что доверие к ОО поддерживается разработчиком в соответствии с планом ПД. Это достигается путем подготовки свидетельства, которое демонстрирует поддержку доверия к ОО и независимо проверяется оценщиком. Эта проверка, называемая «аудит поддержки доверия» (аудит ПД), будет, как правило, применяться периодически в фазе мониторинга цикла поддержки доверия к ОО.

Аудит ПД проводят в соответствии с графиком, определенным в плане ПД. Действия разработчика и оценщика, требуемые в AMA_EVD.1, будут выполняться один или несколько раз в фазе мониторинга цикла поддержки доверия. Оценщику, возможно, необходимо непосредственно ознакомиться с условиями разработки ОО, чтобы выполнить экспертизу требуемого свидетельства, но не исключаются и другие способы проверки.

От разработчика требуется представить свидетельство следования процедурам поддержки доверия, указанным в плане ПД. Оно будет включать в себя:

а) записи управления конфигурацией;

б) документацию, используемую при анализе влияния на безопасность, включая текущую версию отчета о категорировании компонентов ОО и свидетельства для всех примененных требований доверия, такие как улучшения проекта, тестовая документация, новые версии руководств и т.д.;

в) свидетельство отслеживания недостатков безопасности.

Проверка оценщиком анализа влияния на безопасность, проведенного разработчиком, (требуемая AMA_SIA.1, от которого зависит AMA_EVD.1) займет центральное место в аудите ПД. Аудит ПД будет, в свою очередь, способствовать подтверждению анализа, проведенного разработчиком (и, следовательно, уверенности в качестве анализа), обеспечивая подтверждение правильности утверждения разработчика, что доверие к ОО поддерживается для его текущей версии.

При аудите ПД требуется, чтобы оценщик подтвердил выполнение функционального тестирования текущей версии ОО. Это выделяют в отдельную проверку, потому что тестовая документация обеспечивает убедительное доказательство продолжения выполнения ФБО в соответствии со спецификациями. Оценщик выборочно проверяет тестовую документацию для подтверждения, что тестирование разработчиком показывает правильность выполнения ФБО, а покрытие тестами и глубина тестирования соразмерны поддерживаемому уровню доверия.

15.3.4 Анализ влияния на безопасность

Назначение анализа влияния на безопасность состоит в том, чтобы убедиться в поддержке доверия к ОО посредством проводимого разработчиком анализа влияния на безопасность всех изменений, воздействующих на ОО после его сертификации. Эти требования могут применяться в фазе мониторинга или переоценки.

Анализ влияния на безопасность, проводимый разработчиком, основывается на отчете о категорировании компонентов ОО: изменения в осуществляющих ПБО компонентах ОО могут повлиять на доверие к тому, что ОО продолжает отвечать своему ЗБ после изменений. Поэтому все такие изменения требуют анализа их влияния на безопасность, чтобы показать, что они не нарушают доверия к ОО.

Компоненты этого семейства могут использоваться для поддержки последующего аудита ПД или для переоценки ОО.

Следует, чтобы для аудита ПД краткий обзор оценщиком анализа влияния на безопасность служил бы основой последующих действий аудита, которые, в свою очередь, предоставили бы подтверждение результатов анализа, проведенного разработчиком.

Анализ влияния на безопасность идентифицирует изменения в сертифицированной версии ОО на уровне компонентов ОО, которые или являются новыми, или были модифицированы. Оценщик проверяет точность этой информации либо во время связанного с ними аудита ПД, либо при вызванной ими переоценке ОО.

Следует, чтобы подготовка анализа влияния на безопасность для поддержки переоценки уменьшила трудозатраты оценщика, необходимые для установления требуемого уровня доверия к ОО. Применение AMA_SIA.2, который содержит требование полной экспертизы анализа влияния на безопасность, предоставит, как ожидается, максимальный выигрыш при переоценке. Детализация условий, при которых орган оценки мог бы на практике потребовать использование при переоценке анализа влияния на безопасность, находится за рамками ОК.

16. Класс AMA. Поддержка доверия

Класс AMA содержит требования, предназначенные для применения после того, как ОО был сертифицирован на основе ОК. Эти требования имеют целью сохранить уверенность в том, что ОО продолжит отвечать своему заданию по безопасности после изменений в ОО или его среде. К таким изменениям относятся обнаружение новых угроз или уязвимостей, изменения в требованиях пользователя, а также исправление ошибок, найденных в сертифицированном ОО.

Класс включает в себя четыре семейства с иерархией компонентов в семействах, показанной на рисунке 16.1:

Рисунок 16.1 — Декомпозиция класса «Поддержка доверия»

16.1 План поддержки доверия (AMA_AMP)

Цели

План поддержки доверия (ПД) идентифицирует процедуры, которые необходимо выполнять разработчику по мере изменений в ОО или его среде для обеспечения поддержки доверия, которое было установлено к сертифицированному ОО. План ПД специфичен для конкретного ОО и зависит от личного опыта и навыков разработчика.

Ранжирование компонентов

Это семейство содержит только один компонент.

Замечания по применению

План ПД распространяется на один цикл поддержки доверия, который представляет собой период от завершения последней выполненной оценки ОО до завершения следующей запланированной переоценки.

Требования AMA_AMP.1.2C и AMA_AMP.1.3C помогают обеспечить четкую идентификацию основания для поддержки доверия в терминах результатов оценки и определения категорирования компонентов ОО. Отчет о категорировании компонентов ОО формируют в соответствии с требованиями семейства AMA_CAT, и он предоставляет основу для анализа влияния на безопасность, выполняемого аналитиком безопасности от разработчика.

Пределы изменений, предусмотренные планом в соответствии с AMA_AMP.1.4C, следует определять в терминах категории компонентов ОО, которые могут подвергнуться изменениям, и уровня представления, на котором могут происходить изменения (со ссылкой, где это необходимо, на отчет о категорировании компонентов ОО).

AMA_AMP.1.5 C содержит требование описания текущих планов разработчика для любых новых выпусков ОО. Эти планы, естественно, могут изменяться и, следовательно, вызывать обновления в плане ПД. Однако следует отметить, что в данном контексте термин новый выпуск не включает в себя, например, второстепенные («внеплановые») выпуски ОО, обусловленные исправлением незначительных ошибок.

AMA_AMP.1.6 C содержит требование определить плановый график аудита ПД (см. семейство AMA_EVD) и намеченную переоценку ОО вместе со строгим обоснованием предложенных графиков. В основу планирования может быть положен определенный период времени (например, ежегодный аудит ПД), или же планирование может быть связано с ожидаемыми новыми выпусками ОО. В графике следует учесть ожидаемые изменения ОО в течение указанного, а также прошедшего между оценкой ОО и составлением плана ПД периодов. В частности, любые изменения, выходящие за рамки плана ПД, могут привести к переоценке.

AMA_AMP.1 План поддержки доверия

Зависимости

ACM_CAP.2 Элементы конфигурации

ALC_FLR.1 Базовое устранение недостатков

AMA_CAT.1 Отчет о категорировании компонентов ОО

Элементы действий разработчика

AMA_AMP.1.1D Разработчик должен представить план ПД.

Элементы содержания и представления свидетельств

AMA_AMP.1.1C План ПД должен содержать или ссылаться на краткое описание ОО, включающее в себя предоставляемые им функциональные возможности безопасности.

AMA_AMP.1.2C План ПД должен идентифицировать сертифицированную версию ОО и ссылаться на результаты оценки.

AMA_AMP.1.3C План ПД должен опираться на отчет о категорировании компонентов ОО для сертифицированной версии ОО.

AMA_AMP.1.4C План ПД должен определить пределы изменений ОО, предусматриваемых планом.

AMA_AMP.1.5C План ПД должен содержать описание жизненного цикла ОО и идентифицировать текущие планы любых новых выпусков ОО, а также включать в себя краткое описание любых запланированных изменений, которые, как ожидается, будут иметь значительное влияние на безопасность.

AMA_AMP.1.6C План ПД должен содержать описание цикла поддержки доверия, устанавливая и строго обосновывая плановый график аудита ПД и намеченную дату следующей переоценки ОО.

AMA_AMP.1.7C План ПД должен идентифицировать лицо (а), которое (ые) будет (ут) исполнять роль аналитика безопасности от разработчика для ОО.

AMA_AMP.1.8C План ПД должен содержать описание, как роль аналитика безопасности от разработчика обеспечит следование процедурам, которые задокументированы в плане ПД или на которые там имеются ссылки.

AMA_AMP.1.9C План ПД должен содержать описание, как роль аналитика безопасности от разработчика обеспечит правильное выполнение всех действий разработчика, связанных с анализом влияния на безопасность изменений, воздействующих на ОО.

AMA_AMP.1.10C План ПД должен содержать строгое обоснование, что идентифицированный аналитик безопасности от разработчика хорошо знает задание по безопасности, функциональную спецификацию и (где это необходимо) проект верхнего уровня ОО, а также результаты оценки и все примененные требования доверия для сертифицированной версии ОО.

AMA_AMP.1.11C План ПД должен содержать описание или иметь ссылки на процедуры, которые предполагается применять для поддержки доверия к ОО и которые, как минимум, должны включать в себя процедуры управления конфигурацией, поддержки свидетельства доверия, выполнения анализа влияния на безопасность изменений, воздействующих на ОО, и устранения недостатков.

Элементы действий оценщика

AMA_AMP.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AMA_AMP.1.2E Оценщик должен подтвердить, что предложенные графики аудита ПД и переоценки ОО приемлемы и согласуются с предполагаемыми изменениями ОО.

16.2 Отчет о категорировании компонентов ОО (AMA_CAT)

Цели

Назначение отчета о категорировании компонентов ОО состоит в том, чтобы дополнить план ПД обеспечением категорирования компонентов ОО (например, подсистем ФБО) согласно их отношению к безопасности. Категорирование занимает центральное место в анализе влияния на безопасность, проводимом разработчиком, а также в последующей переоценке ОО.

Ранжирование компонентов

Семейство AMA_CAT содержит только один компонент.

Замечания по применению

Термин «наименее абстрактное из представлений ФБО» в AMA_CAT.1 относится к наименее абстрактному представлению ФБО, которое предоставлено для поддерживаемого уровня доверия. Например, если для ОО поддерживается уровень доверия ОУД3, то наименее абстрактное из представлений ФБО — проект верхнего уровня. Следовательно, в этом случае необходимо категорировать следующие компоненты ОО:

а) все внешние интерфейсы ФБО, которые могут быть идентифицированы в функциональной спецификации;

б) все подсистемы ФБО, которые могут быть идентифицированы в проекте верхнего уровня.

В то время как данное семейство содержит требование разделения, по меньшей мере, на две категории, может быть приемлемо (в зависимости от типа ОО) подразделить далее категорию, осуществляющую ПБО, чтобы облегчить анализ влияния на безопасность, проводимый разработчиком. Например, компоненты, осуществляющие ПБО, могли бы быть категорированы на критичные для безопасности и на поддерживающие безопасность, где:

а) критичные для безопасности компоненты ОО — это те, которые несут непосредственную ответственность за осуществление хотя бы одной функции безопасности ИТ, определенной в задании по безопасности;

б) поддерживающие безопасность компоненты ОО — это те, которые не несут непосредственную ответственность за осуществление какой-либо функции безопасности ИТ (и поэтому некритичны для безопасности), но на которые, тем не менее, полагаются при поддержке функций безопасности ИТ; эта категория может, в свою очередь, включать в себя компоненты ОО двух различных типов:

— способствующие выполнению критичных для безопасности компонентов ОО (поэтому для них обязательно правильное функционирование),

— не способствующие выполнению критичных для безопасности компонентов ОО, но, тем не менее, требующие доверия к тому, что их режим функционирования не является опасным (т.е. не ведет к активизации уязвимостей).

AMA_CAT.1.3C содержит требование идентификации любых инструментальных средств разработки, модификация которых повлияет на доверие к тому, что ОО удовлетворяет своему заданию по безопасности (например, компилятора, используемого для получения объектного кода).

AMA_CAT.1Отчет о категорировании компонентов ОО

Зависимости

ACM_CAP.2 Элементы конфигурации

Элементы действий разработчика

AMA_CAT.1.1D Разработчик должен представить отчет о категорировании компонентов ОО для сертифицированной версии ОО.

Элементы содержания и представления свидетельств

AMA_CAT.1.1C Отчет о категорировании компонентов ОО должен распределить по категориям каждый компонент ОО, который может быть идентифицирован в каждом представлении ФБО от наиболее до наименее абстрактного, согласно его отношению к безопасности; как минимум, компоненты ОО необходимо разделить на осуществляющие и не осуществляющие ПБО.

AMA_CAT.1.2C Отчет о категорировании компонентов ОО должен содержать такое описание используемой схемы категорирования, чтобы можно было определить, как распределять по категориям новые компоненты, включаемые в ОО, а также в каких случаях требуется заново распределять по категориям существующие компоненты ОО вследствие изменений в ОО или в его задании по безопасности.

AMA_CAT.1.3C Отчет о категорировании компонентов ОО должен идентифицировать любые инструментальные средства, используемые в среде разработки, модификация которых повлияет на доверие к тому, что ОО удовлетворяет своему заданию по безопасности.

Элементы действий оценщика

AMA_CAT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AMA_CAT.1.2E Оценщик должен подтвердить, что категорирование компонентов и инструментальных средств ОО и используемая схема категорирования приемлемы и согласованы с результатами оценки для сертифицированной версии.

16.3 Свидетельство поддержки доверия (AMA_EVD)

Цели

Назначение семейства AMA_EVD состоит в том, чтобы убедиться в поддержке разработчиком доверия к ОО в соответствии с планом ПД. Это достигается подготовкой свидетельства, независимо проверяемого оценщиком, которое демонстрирует поддержку доверия к ОО. Указанную проверку, называемую «Аудит ПД», периодически проводят во время действия плана ПД.

Ранжирование компонентов

Семейство содержит только один компонент.

Замечания по применению

Семейство включает в себя некоторые требования к свидетельству, подобные требованиям доверия, определенным в классах ACM, ATE и AVA. В то же время, аудит ПД не требует проведения оценщиком экспертизы свидетельства в том же самом объеме, как это установлено компонентами перечисленных классов; скорее, здесь достаточно требования, чтобы частичная выборка позволила убедиться в правильности следования процедурам поддержки доверия.

В порядке аудита ПД оценщик проверяет (выборочно) согласованность списка конфигурации и анализа влияния на безопасность с текущей версией ОО для компонентов ОО, которые изменились по сравнению с сертифицированной версией ОО.

AMA_EVD.1.3C содержит требование подготовки свидетельства следования процедурам поддержки доверия из плана ПД. Требование распространяется на все процедуры, упоминаемые в AMA_AMP.1.11C, т.е. необходимо свидетельство применения процедур, относящихся к управлению конфигурацией, поддержке свидетельства доверия, выполнению анализа влияния на безопасность и устранению недостатков.

Свидетельство, требуемое в AMA_EVD.1.4C, содержит список идентифицированных уязвимостей в текущей версии ОО. Это выделено как отдельное требование ввиду важности отсутствия в текущей версии каких-либо недостатков безопасности, которые могли бы быть использованы в среде ОО, с уровнем доверия, полученным при первоначальной оценке. В список в AMA_EVD.1.4C следует включить уязвимости, выявленные в результате:

а)анализа разработчиком, требуемого AVA_VLA.1 или иерархичным компонентом (если он применялся для сертифицированной версии ОО);

б)обнаружения любых других недостатков безопасности, обработанных с использованием процедур их устранения, требуемых ALC_FLR.1 (или ALC_FLR.2) для сертифицированной версии ОО.

AMA_EVD.1.5E содержит требования, чтобы оценщик подтвердил выполнение разработчиком функционального тестирования текущей версии ОО, а также соразмерность покрытия тестами и глубины тестирования с поддерживаемым уровнем доверия. Эту проверку выполняют посредством выборки из тестовой документации для текущей версии ОО.

AMA_EVD.1 Свидетельство процесса поддержки

Зависимости

AMA_AMP.1 План поддержки доверия

AMA_SIA.1 Выборочная проверка анализа влияния на безопасность

Элементы действий разработчика

AMA_EVD.1.1D Аналитик безопасности от разработчика должен представить документацию ПД для текущей версии ОО.

Элементы содержания и представления свидетельств

AMA_EVD.1.1C Документация ПД должна включать в себя список конфигурации и список идентифицированных уязвимостей в ОО.

AMA_EVD.1.2C Список конфигурации должен содержать описание элементов конфигурации, которые составляют текущую версию ОО.

AMA_EVD.1.3C Документация ПД должна представить свидетельство следования процедурам, которые имеются или на которые есть ссылки в плане ПД.

AMA_EVD.1.4C Список идентифицированных уязвимостей в текущей версии ОО должен показать для каждой уязвимости, что она не может быть использована в предполагаемой среде ОО.

Элементы действий оценщика

AMA_EVD.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AMA_EVD.1.2E Оценщик должен подтвердить следование процедурам, которые задокументированы или на которые есть ссылки в плане ПД.

AMA_EVD.1.3E Оценщик должен подтвердить, что анализ влияния на безопасность для текущей версии ОО согласован со списком конфигурации.

AMA_EVD.1.4E Оценщик должен подтвердить, что все изменения, задокументированные при анализе влияния на безопасность для текущей версии ОО, находятся в пределах, установленных планом ПД.

AMA_EVD.1.5E Оценщик должен подтвердить, что функциональное тестирование выполнялось на текущей версии ОО соразмерно поддерживаемому уровню доверия.

16.4 Анализ влияния на безопасность (AMA_SIA)

Цели

Назначение семейства AMA_SIA состоит в том, чтобы убедиться в поддержке доверия к ОО посредством анализа, проводимого разработчиком, по определению влияния на безопасность всех изменений, воздействующих на ОО после его сертификации.

Ранжирование компонентов

Семейство состоит из двух компонентов, ранжированных согласно степени проверки оценщиком правильности анализа влияния на безопасность, проведенного разработчиком.

Замечания по применению

AMA_SIA.1 содержит требование применения выборочного подхода при проверке правильности анализа влияния на безопасность, проведенного разработчиком. AMA_SIA.2 предпочтителен в случаях, когда выборочный подход не рассматривают как достаточный, чтобы убедиться в поддержке доверия к ОО для его текущей версии, но при этом формальную переоценку не считают необходимой.

Оба компонента в этом семействе содержат требование, чтобы анализ влияния на безопасность идентифицировал все новые и модифицированные (по сравнению с сертифицированной версией) компоненты в текущей версии ОО. Точность этой информации проверяют во время связанного с этим аудита ПД (выборочно) или при связанной с этим переоценке ОО, когда список конфигурации проверяют в рамках ACM_CAP.

AMA_SIA.1 Выборочная проверка анализа влияния на безопасность

Зависимости

AMA_CAT.1 Отчет о категорировании компонентов ОО

Элементы действий разработчика

AMA_SIA.1.1D Аналитик безопасности от разработчика должен представить для текущей версии ОО анализ влияния на безопасность, который учитывает все изменения, воздействующие на ОО, по сравнению с сертифицированной версией.

Элементы содержания и представления свидетельств

AMA_SIA.1.1C Анализ влияния на безопасность должен идентифицировать сертифицированный ОО, из которого была получена текущая версия ОО.

AMA_SIA.1.2C Анализ влияния на безопасность должен идентифицировать все новые и модифицированные компоненты ОО, которые категорированы как осуществляющие ПБО.

AMA_SIA.1.3C Анализ влияния на безопасность должен для каждого изменения, воздействующего на задание по безопасности или представления ФБО, содержать краткое описание изменения и всех последствий, к которым оно приводит на более низких уровнях представления.

AMA_SIA.1.4C Анализ влияния на безопасность должен для каждого изменения, воздействующего на задание по безопасности или представления ФБО, идентифицировать все функции безопасности ИТ и компоненты ОО, категорированные как осуществляющие ПБО, на которые влияет данное изменение.

AMA_SIA.1.5C Анализ влияния на безопасность должен для каждого изменения, которое приводит к модификации представления реализации ФБО или среды ИТ, идентифицировать свидетельство тестирования, показывающее для требуемого уровня доверия, что ФБО остаются правильно реализованными и после изменения.

AMA_SIA.1.6C Анализ влияния на безопасность должен для каждого применяемого требования из классов доверия «Управление конфигурацией» (ACM), «Поддержка жизненного цикла» (ALC), «Поставка и эксплуатация» (ADO) и «Руководства» (AGD) идентифицировать все поставляемые материалы оценки, которые изменились, и содержать краткое описание каждого изменения и его воздействие на доверие к ОО.

AMA_SIA.1.7C Анализ влияния на безопасность должен для каждого применяемого требования в классе доверия «Оценка уязвимости» (AVA) идентифицировать, какие поставляемые материалы оценки изменились, а какие нет, и привести доводы для принятого решения, обновлять или нет данный поставляемый материал.

Элементы действий оценщика

AMA_SIA.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AMA_SIA.1.2E Оценщик должен выборочно проверить, что при анализе влияния на безопасность изменения задокументированы на приемлемом уровне детализации вместе с соответствующим строгим обоснованием поддержки доверия в текущей версии ОО.

AMA_SIA.2 Экспертиза анализа влияния на безопасность

Зависимости

AMA_CAT.1 Отчет о категорировании компонентов ОО

Элементы действий разработчика

AMA_SIA.2.1D Аналитик безопасности от разработчика должен представить для текущей версии ОО анализ влияния на безопасность, который учитывает все изменения, воздействующие на ОО, по сравнению с сертифицированной версией.

Элементы содержания и представления свидетельств

AMA_SIA.2.1C Анализ влияния на безопасность должен идентифицировать сертифицированный ОО, из которого была получена текущая версия ОО.

AMA_SIA.2.2C Анализ влияния на безопасность должен идентифицировать все новые и модифицированные компоненты ОО, которые категорированы как осуществляющие ПБО.

AMA_SIA.2.3C Анализ влияния на безопасность должен для каждого изменения, влияющего на задание по безопасности или представления ФБО, содержать краткое описание изменения и всех последствий, к которым оно приводит на более низких уровнях представления.

AMA_SIA.2.4C Анализ влияния на безопасность должен для каждого изменения, влияющего на задание по безопасности или представления ФБО, идентифицировать все функции безопасности ИТ и компоненты ОО, категорированные как осуществляющие ПБО, на которые воздействует данное изменение.

AMA_SIA.2.5C Анализ влияния на безопасность должен для каждого изменения, которое приводит к модификации представления реализации ФБО или среды ИТ, идентифицировать свидетельство тестирования, показывающее для требуемого уровня доверия, что ФБО остаются правильно реализованными и после изменения.

AMA_SIA.2.6C Анализ влияния на безопасность должен для каждого применяемого требования из классов доверия «Управление конфигурацией» (ACM), «Поддержка жизненного цикла» (ALC), «Поставка и эксплуатация» (ADO) и «Руководства» (AGD) идентифицировать все поставляемые материалы оценки, которые изменились, и содержать краткое описание каждого изменения и его воздействие на доверие к ОО.

AMA_SIA.2.7C Анализ влияния на безопасность должен для каждого применяемого требования в классе доверия «Оценка уязвимости» (AVA) идентифицировать, какие поставляемые материалы оценки изменились, а какие нет, и привести доводы для принятого решения, обновлять или нет данный поставляемый материал.

Элементы действий оценщика

AMA_SIA.2.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

AMA_SIA.2.2E Оценщик должен проверить, что при анализе влияния на безопасность все изменения задокументированы на приемлемом уровне детализации вместе с соответствующим строгим обоснованием поддержки доверия в текущей версии ОО.

Приложение А
(справочное)

ПЕРЕКРЕСТНЫЕ ССЫЛКИ МЕЖДУ КОМПОНЕНТАМИ ДОВЕРИЯ

Зависимости между компонентами, приведенные в разделах 8-14 и 16, являются прямыми зависимостями между компонентами доверия. В таблице А.1 объединены как прямые, так и косвенные зависимости. Косвенные зависимости являются, в конечном счете, результатом последовательного учета всех зависимостей каждого компонента, приведенного в списке зависимостей.

Таблица А.1

ЗАВИСИМОСТИ МЕЖДУ КОМПОНЕНТАМИ ДОВЕРИЯ

Примечание. В таблице А.1 в боковике содержатся сокращенные обозначения компонентов (приведены только первые три буквы имени семейства и номер компонента или диапазон номеров компонентов). Каждая заполненная ячейка в таблице указывает на компонент, идентифицированный первыми тремя буквами имени семейства в наименовании графы и номером компонента в ячейке, для которого компонент, указанный в боковике, является зависимым. Полужирным шрифтом выделены прямые зависимости, курсивом — косвенные зависимости. Серый фон выделяет пересечение компонента с самим собой. Зависимости компонентов класса AMA от компонентов доверия включены в таблицу А.1, в то время как внутренние зависимости класса AMA приведены в таблице А.2. От компонентов класса AMA не зависят никакие компоненты других классов, поэтому в таблице А.1 нет граф, представляющих семейства класса AMA.

Таблица А.2

ВНУТРЕННИЕ ЗАВИСИМОСТИ КЛАССА AMA

Приложение Б
(справочное)

ПЕРЕКРЕСТНЫЕ ССЫЛКИ ОУД И КОМПОНЕНТОВ ДОВЕРИЯ

Взаимосвязь между оценочными уровнями доверия и классами, семействами и компонентами доверия приведена в таблице Б.1.

Таблица Б.1

ОБЗОР ОЦЕНОЧНЫХ УРОВНЕЙ ДОВЕРИЯ