ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫМ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ.

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

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

ISO/IEC 15408-2:2008 Information technology — Security techniques —

Evaluation criteria for IT security — Part 2. Security functional components

(IDT)

Издание официальное

Москва

Стандартинформ

2014

Предисловие

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

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

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 г. №1339-ст

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

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

5    ВЗАМЕН ГОСТ Р ИСО/МЭК 15408-2—2008

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

© Стандартинформ, 2014

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

6.1.1.1    Имя класса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6

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

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

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

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

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

6.1.2.4    Управление

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

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

6.1.2.5    Аудит

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

-    Минимальный — успешное использование механизма безопасности.

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

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

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

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

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

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

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

7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9

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

7.1.4    Аудит: FAU_ARP.1

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

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

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

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

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

7.1.5.1    FAU_ARP.1.1

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

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

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

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

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

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

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

10

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

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

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

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

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

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

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

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

7.2.5.1    FAU_GEN.1.1

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

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

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

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

7.2.5.2    FAU_GEN.1.2

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

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

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

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

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

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

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

7.2.6.1    FAU_GEN.2.1

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

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

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

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

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

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

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

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

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

11

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.3.8.1    FAU_SAA.1.1

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

7.3.8.2    FAU_SAA.1.2

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

аудиту:

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

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

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

Иерархический для: Нет подчиненных компонентов Зависимости: FIA_UID.1 Выбор момента идентификации

7.3.9.1    FAU_SAA.2.1

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

7.3.9.2    FAU_SAA.2.2

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

7.3.9.3    FAU_SAA.2.3

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

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

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

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

7.3.10.1    FAU_SAA.3.1

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

7.3.10.2    FAU_SAA.3.2

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

7.3.10.3    FAU_SAA.3.3

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

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

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

7.3.11.1    FAU_SAA.4.1

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

7.3.11.2    FAU_SAA.4.2

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

7.3.11.3    FAU_SAA.4.3

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

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

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

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

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

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

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

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

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

7.4.4    Управление: FAU_SAR.2, FAU_SAR.3 Действия по управлению не предусмотрены.

7.4.5    Аудит: FAU_SAR.1

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

7.4.6    Аудит: FAU_SAR.2

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

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

7.4.7    Аудит: FAU_SAR.3

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

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

13

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

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

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

7.4.8.1    FAU_SAR.1.1

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

7.4.8.2    FAU_SAR.1.2

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

7.4.9    FAU_SAR.2 Ограниченный просмотр аудита Иерархический для: Нет подчиненных компонентов.

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

7.4.9.1    FAU_SAR.2.1

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

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

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

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

7.4.10.1    FAU_SAR.3.1

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

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

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

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

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

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

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

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

7.5.4    Аудит: FAU_SEL.1

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

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

7.5.5    FAU_SEL.1 Избирательный аудит Иерархический для: Нет подчиненных компонентов Зависимости: FAU_GEN.1 Генерация данных аудита

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

7.5.5.1    FAU_SEL.1.1

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

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

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

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

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

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

14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.6.8    Аудит: FAU_STG.3

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

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

7.6.9    Аудит: FAU_STG.4

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

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

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

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

7.6.10.1    FAU_STG.1.1

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

7.6.10.2    FAU_STG.1.2

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

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

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

7.6.11.1    FAU_STG.2.1

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

7.6.11.2    FAU_STG.2.2

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

7.6.11.3    FAU_STG.2.3

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

15

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

Введение

Международный стандарт ISO/IEC 15408:2008 был подготовлен Совместным техническим комитетом ISO/IEC JTC 1 «Информационные технологии», Подкомитетом SC 27 «Методы и средства обеспечения безопасности ИТ». Идентичный ISO/IEC 15408 текст опубликован организациями-спон-сорами проекта «Общие критерии» как «Общие критерии оценки безопасности информационных технологий».

Третья редакция стандарта отменяет и заменяет вторую редакцию (ISO/IEC 15408:2005), которая подверглась технической переработке.

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

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

-    Часть 2: Функциональные компоненты безопасности;

-    Часть 3: Компоненты доверия к безопасности.

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

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

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

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

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

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

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

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

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

7.6.12.1    FAU_STG.3.1

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

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

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

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

7.6.13.1    FAU_STG.4.1

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1.4    Аудит: FC0_NR0.1

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

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

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

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

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

16

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.4    Экспорт данных из ОО (FDP_ETC)...................................................................25

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

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

10.7    Импорт данных из-за пределов ОО (FDPJTC)..........................................................30

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

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

10.10    Откат (FDP ROL).................................................................................33

10.11    Целостность хранимых данных (FDP_SDI)............................................................34

10.12    Защита конфиденциальности данных пользователя при передаче

между ФБО (FDP UCT)...........................................................................35

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

11    Класс FIA: Идентификация и аутентификация..............................................................37

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

11.2    Определение атрибутов пользователя (FIA_ATD).......................................................38

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

11.4    Аутентификация пользователя (FIA_UAU).............................................................39

11.5    Идентификация пользователя (FIA_UID)..............................................................41

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

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

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

12.2    Управление атрибутами безопасности (FMT_MSA)......................................................44

12.3    Управление данными ФБО (FMT_MTD)...............................................................46

12.4    Отмена (FMT REV)................................................................................47

12.5    Срок действия атрибута безопасности (FMT_SAE)......................................................47

12.6    Спецификация функций управления (FMT_SMF)........................................................48

12.7    Роли управления безопасностью (FMT_SMR)..........................................................48

13    Класс FPR: Приватность................................................................................50

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

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

13.2    Псевдонимность (FPR_PSE)........................................................................

13.3    Невозможность ассоциации (FPRJJNL)...............................................................52

13.4    Скрытность (FPRJJNO)............................................................................52

14    Класс FPT: Защита ФБО................................................................................54

14.1    Безопасность при сбое (FPT_FLS)....................................................................55

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

14.3    Конфиденциальность экспортируемых данных ФБО (FPTJTC)............................................56

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

14.5    Передача данных ФБО в пределах 00 (FPTJTT).......................................................57

14.6    Физическая защита ФБО (FPT_PHP)..................................................................58

14.7    Надежное восстановление (FPT_RCV)................................................................60

14.8    Обнаружение повторного использования (FPT_RPL)....................................................61

14.9    Протокол синхронизации состояний (FPT_SSP).........................................................62

14.10 Метки времени (FPT_STM).........................................................................62

14.11    Согласованность данных ФБО между ФБО (FPT_TDC)..................................................63

14.12    Тестирование внешних сущностей (FPT_TEE).........................................................63

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

14.14    Самотестирование ФБО (FPT_TST).................................................................64

15    Класс FRU: Использование ресурсов.....................................................................65

15.1    Отказоустойчивость (FRILFLT)......................................................................65

15.2    Приоритет обслуживания (FRU_PRS).................................................................66

15.3    Распределение ресурсов (FRU_RSA).................................................................67

16    Класс FTA: Доступ к 00................................................................................67

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

16.2    Ограничение на параллельные сеансы (FTAJVICS).....................................................68

16.3    Блокирование и завершение сеанса (FTA_SSL).........................................................69

16.4    Предупреждения перед предоставлением доступа к 00 (FTA_TAB)........................................71

16.5    История доступа к 00 (FTA_TAH)....................................................................71

16.6    Открытие сеанса с 00 (FTA_TSE)....................................................................71

17    Класс FTP: Доверенный маршрут/канал...................................................................72

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

17.2    Доверенный маршрут (FTP_TRP)....................................................................73

Приложение А (обязательное) Замечания по применению функциональных требований

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

Приложение В (обязательное) Функциональные классы, семейства и компоненты..................................82

Приложение С (обязательное) Аудит безопасности (FAU).......................................................82

Приложение D (обязательное) Связь (FCO)..................................................................91

Приложение Е (обязательное) Криптографическая поддержка (FCS).............................................94

Приложение F (обязательное) Защита данных пользователя (FDP)..............................................97

Приложение G (обязательное) Идентификация и аутентификация (FIA)..........................................114

Приложение FI (обязательное) Управление безопасностью (FMT)...............................................120

Приложение I (обязательное) Приватность (FPR)...........................................................126

Приложение J (обязательное) Защита ФБО (FPT)............................................................134

Приложение К (обязательное) Использование ресурсов (FRU).................................................145

Приложение L (обязательное) Доступ к 00 (FTA).............................................................148

Приложение М (обязательное) Доверенный маршрут/канал (FTP)...............................................152

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам

Российской Федерации.................................................................154

Библиография..........................................................................................155

V

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

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ.

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

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

Information technology. Security techniques. Evaluation criteria for IT security.

Part 2. Security functional components

Дата введения — 2014—09—01

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

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

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

Указанные в данном разделе документы являются необходимыми для применения настоящего стандарта. Для датированных ссылок используют только указанное издание. Для недатированных ссылок — последнее издание со всеми изменениями и дополнениями.

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

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

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

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

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

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

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

Издание официальное

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

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

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

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

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

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

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

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

-    структура ЗБ приведена в приложении А к ИСО/МЭК 15408-1;

-    структура ПЗ приведена в приложении В к ИСО/МЭК 15408-1.

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

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

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

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

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

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

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

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

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

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

2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящем стандарте рассматривается реализация ФТБ для субъектов всехтипов, перечисленных выше.

3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5