43. «Общие критерии». Структура и содержание профиля защиты.

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

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

// ОУД является базовым набором требований доверия для оценки. Каждый ОУД определяет непротиворечивый набор требований доверия.

Содержание ПЗ:

44. «Общие критерии». Структура и содержание задания по безопасности.

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

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

Содержание ЗБ:

45. «Общие критерии». Функциональные требования безопасности.

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

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

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

Систематизированный каталог функциональных требований безопасности сосредоточен во второй части ОК. Функциональные требования разбиты на 11 классов, 66 семейств и 135 компонентов.

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

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

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

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

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

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

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

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

–    уникальное имя, отражающее предназначение компонента;

–    краткое имя, уникально отражающее класс и семейство, которым компонент принадлежит, а также номер компонента в семействе;

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

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

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

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