ГОСТ Р ИСО МЭК 15408-2 2007 (1027764), страница 6
Текст из файла (страница 6)
Функциональные требования объединены в классы, семейства и компоненты.6.1.1 Структура классаСтруктура функционального класса приведена на рисунке 5. Каждый функциональный класссодержит имя класса, представление класса и одно или несколько функциональных семейств.Функциональный классИмя классаПредставление классаФункциональные семействаРисунок 5 – Структура функционального класса6.1.1.1 Имя классаИмя класса содержит информацию, необходимую для идентификации функциональногокласса и отнесения его к определенной категории.
Каждый функциональный класс имеет уникальное имя. Информация о категории предоставлена кратким именем, состоящим из трех букв латинского алфавита. Краткое имя класса используют при задании кратких имен семейств этого класса.6.1.1.2 Представление классаПредставление класса обобщает участие семейств класса в достижении целей безопасности. Определение функциональных классов не отражает никакую формальную таксономию в спецификации требований.Представление класса содержит рисунок, показывающий все семейства этого класса и иерархию компонентов в каждом семействе, как указано в подразделе 6.2.6.1.2 Структура семействаСтруктура функционального семейства приведена на рисунке 6.9ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)Функциональное семействоИмя семействаХарактеристика семействаРанжирование компонентовУправлениеАудитКомпонентыРисунок 6 – Структура функционального семейства6.1.2.1 Имя семействаИмя семейства содержит описательную информацию, необходимую, чтобы идентифицировать и категорировать функциональное семейство.
Каждое функциональное семейство имеет уникальное имя. Информация о категории состоит из краткого имени, включающего в себя семь символов. Первые три символа идентичны краткому имени класса, далее следуют символ подчеркивания и краткое имя семейства в виде XXX_YYY. Уникальная краткая форма имени семействапредоставляет основное имя ссылки для компонентов.6.1.2.2 Характеристика семействаХарактеристика семейства – это описание функционального семейства, в котором излагаются его цели безопасности и общее описание функциональных требований. Более детально ониописаны ниже:a) цели безопасности семейства характеризуют задачу безопасности, которая может быть решена с помощью компонентов этого семейства;b) описание функциональных требований обобщает все требования, которые включены в компонент (ты).
Описание ориентировано на разработчиков ПЗ, ЗБ и функциональных пакетов, которыехотели бы определить, соответствует ли семейство их конкретным требованиям.6.1.2.3 Ранжирование компонентовФункциональные семейства содержат один или несколько компонентов, каждый из которыхможет быть выбран для включения в ПЗ, ЗБ и функциональные пакеты. Цель ранжирования компонентов – предоставить пользователям информацию для выбора подходящего функциональногокомпонента, если семейство идентифицировано пользователем как необходимая или полезнаячасть требований безопасности.Далее перечисляются имеющиеся компоненты и приводится их обоснование. Детализациякомпонентов производится в описании каждого компонента.10ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)Связи между компонентами в пределах функционального семейства могут быть иерархическими и неиерархическими.
Компонент иерархичен (т.е. расположен выше по иерархии) по отношению к другому компоненту, если предлагает большую безопасность.Описания семейств содержат графическое представление иерархии компонентов, рассмотренное в 6.2.6.1.2.4 УправлениеТребования управления содержат информацию для разработчиков ПЗ/ЗБ, учитываемую приопределении действий по управлению для данного компонента. Требования управления детализированы в компонентах класса «Управление безопасностью» (FMT).Разработчик ПЗ/ЗБ может выбрать какие-либо из имеющихся требований управления иливключить новые, не указанные в настоящем стандарте.
В последнем случае следует представитьнеобходимую информацию.6.1.2.5 АудитТребования аудита содержат события, потенциально подвергаемые аудиту, для их отбораразработчиками ПЗ/ЗБ при условии включения в ПЗ/ЗБ требований из класса FAU «Аудит безопасности». Эти требования включают в себя события, относящиеся к безопасности, применительно к различным уровням детализации, поддерживаемым компонентами семейства FAU_GEN «Генерация данных аудита безопасности». Например, запись аудита какого-либо механизма безопасности может включать в себя на разных уровнях детализации действия, которые раскрываются вследующих терминах:-Минимальный – успешное использование механизма безопасности.-Базовый – любое использование механизма безопасности, а также информация о текущихзначениях атрибутов безопасности.-Детализированный – любые изменения конфигурации механизма безопасности, включая параметры конфигурации до и после изменения.Следует учесть, что категорирование событий, потенциально подвергаемых аудиту, всегдаиерархично.
Например, если выбрана базовая генерация данных аудита, то все события, идентифицированные как потенциально подвергаемые аудиту и поэтому входящие как в "минимальную",так и в "базовую" запись, следует включить в ПЗ/ЗБ с помощью соответствующей операции назначения, за исключением случая, когда событие более высокого уровня имеет более высокий уровень детализации, чем событие более низкого уровня, и может просто заменить его. Когда желательна детализированная генерация данных аудита, все идентифицированные события, потенциально подвергаемые аудиту (для минимального, базового и детализированного уровней), следуетвключить в ПЗ/ЗБ.Правила управления аудитом более подробно объяснены в классе FAU «Аудит безопасности».6.1.3 Структура компонентаСтруктура функционального компонента показана на рисунке 7.11ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)КомпонентИдентификация компонентаФункциональные элементыЗависимостиРисунок 7 – Структура функционального компонента6.1.3.1 Идентификация компонентаИдентификация компонента включает в себя описательную информацию, необходимую дляидентификации, категорирования, записи и реализации перекрестных ссылок компонента.
Для каждого функционального компонента представляется следующее:– уникальное имя, отражающее предназначение компонента;– краткое имя, применяемое как основное имя ссылки для категорирования, записи и реализации перекрестных ссылок компонента и уникально отражающее класс и семейство, которым компонент принадлежит, а также номер компонента в семействе;– список иерархических связей, содержащий имена других компонентов, для которых этоткомпонент иерархичен и вместо которых может использоваться при удовлетворении зависимостей от перечисленных компонентов.6.1.3.2 Функциональные элементыКаждый компонент включает в себя набор элементов. Каждый элемент определяется отдельно и является самодостаточным.Функциональный элемент – это функциональное требование безопасности, дальнейшееразделение которого не меняет значимо результат оценки.
Является наименьшим функциональным требованием безопасности, идентифицируемым и признаваемым в ИСО/МЭК 15408.При формировании ПЗ, ЗБ и/или пакетов не разрешается выбирать только часть элементовкомпонента. Для включения в ПЗ, ЗБ или пакет необходимо выбирать всю совокупность элементовкомпонента.Вводится уникальная краткая форма имени функционального элемента. Например, имяFDP_IFF.4.2 читается следующим образом: F – функциональное требование, DP – класс «Защитаданных пользователя», _IFF – семейство «Функции управления информационными потоками», .4 –четвертый компонент «Частичное устранение неразрешенных информационных потоков», .2 –второй элемент компонента.6.1.3.3 ЗависимостиЗависимости среди функциональных компонентов возникают, когда компонент не самодостаточен и нуждается либо в функциональных возможностях другого компонента, либо во взаимодействии с ним для поддержки собственного выполнения.Каждый функциональный компонент содержит полный список зависимостей от других функциональных компонентов и компонентов доверия.
Для некоторых компонентов указано, что зависимостиотсутствуют. Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов.Список, приведенный в компоненте, показывает прямые зависимости, т.е. содержит ссылки только на12ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)функциональные компоненты, заведомо необходимые для обеспечения выполнения рассматриваемого компонента. Косвенные зависимости, определяемые собственными зависимостями компонентов изсписка, показаны в приложении А.
В некоторых случаях зависимость выбирают из нескольких предлагаемых функциональных компонентов, причем каждый из них достаточен для удовлетворения зависимости (см., например, FDP_UIT.1 «Целостность передаваемых данных»).Список зависимостей идентифицирует минимум функциональных компонентов или компонентов доверия, необходимых для удовлетворения требований безопасности, ассоциированных сданным компонентом.
Компоненты, которые иерархичны по отношению к компоненту из списка,также могут быть использованы для удовлетворения зависимости.Зависимости между компонентами, указанные в настоящем стандарте, обязательны. Их необходимо удовлетворить в ПЗ/ЗБ. В некоторых, особых случаях эти зависимости удовлетворитьневозможно. Разработчик ПЗ/ЗБ, обязательно обосновав, почему данная зависимость неприменима, может не включать соответствующий компонент в пакет, ПЗ или ЗБ.6.2 Каталог компонентовРасположение компонентов в настоящем стандарте не отражает какую-либо формальнуютаксономию.Настоящий стандарт содержит классы, состоящие из семейств и компонентов, которые приблизительно сгруппированы на основе общей функции и предназначения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
