12. Спецификация раздела "Требования безопасности"

12 Спецификация раздела "Требования безопасности"

12.1 Введение

Данный раздел содержит рекомендации по формированию в ПЗ и ЗБ требований безопасности ИТ для ОО.

В ПЗ и ЗБ формулируются следующие типы требований безопасности ИТ:

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

б) требования доверия к безопасности ОО (ТДБ). Требования доверия к безопасности определяют требуемый уровень доверия к реализации ФТБ.

Рисунок 3 - Формирование требований безопасности ИТ

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

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

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

В 12.3.7 и 12.4.3 даны рекомендации по спецификации соответственно ФТБ и ТДБ в тех случаях, когда в ГОСТ Р ИСО/МЭК 15408-2 и ГОСТ Р ИСО/МЭК 15408-3 нет подходящих компонентов требований для формулирования рассматриваемых ФТБ и ТДБ.

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

Рекомендации по выполнению операций над функциональными компонентами, определенными в ГОСТ Р ИСО/МЭК 15408, приведены в 12.3.2; над компонентами доверия к безопасности - в 12.4.2.

При этом следует отметить, что в ГОСТ Р ИСО/МЭК 15408 каждому компоненту требований безопасности назначается основанное на определенной таксономии уникальное краткое имя.

Например, для FAU_GEN.1.2 из ГОСТ Р ИСО/МЭК 15408-2 краткое имя имеет следующий вид:

а) указывает на то, что это функциональное требование;

б) указывает на то, что ФТБ принадлежит классу ФТБ "Аудит безопасности";

в) указывает на то, что ФТБ принадлежит семейству "Генерация данных аудита безопасности" класса FAU;

г) указывает на то, что это ФТБ "генерации данных аудита" в рамках семейства FAU_GEN;

д) указывает на то, что ФТБ является вторым элементом компонента FAU_GEN.1.

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

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

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

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

Например, для ADV_TDS.1.2C из ГОСТ Р ИСО/МЭК 15408-3 краткое имя имеет следующий вид:

а) указывает на то, что это требование доверия;

б) указывает на то, что ТДБ принадлежит классу "Разработка";

в) указывает на то, что ТДБ принадлежит семейству "Проект ОО" класса ADV "Разработка";

г) указывает на то, что это ТДБ "Базовый проект" в рамках семейства ADV_TDS;

д) указывает на то, что ФТБ является вторым элементом в наборе элементов доверия;

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

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

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

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

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

12.2 Парадигмы безопасности ГОСТ Р ИСО/МЭК 15408

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

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

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

12.2.2 Управление доступом к ресурсам и объектам и управление их использованием

12.2.2.1 Пояснение

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

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

- память (как оперативная память, так и дисковое пространство);

- процессорное время;

- периферийные устройства или сетевые соединения;

- функции.

Пользователи определены в ГОСТ Р ИСО/МЭК 15408-1 как "сущность, взаимодействующая с ОО из-за пределов границ ОО". Субъекты определены в ГОСТ Р ИСО/МЭК 15408-1 как "активная сущность в ОО, выполняющая операции над объектами". Пользователи и субъекты являются активными сущностями, которые запрашивают сервисы ОО и тем самым взаимодействуют с объектами и ресурсами.

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

Перечень параметров (далеко неполный), которые могут подвергаться оценке в рамках этих правил, включает:

- тип и идентификатор сущности, которая инициировала запрос;

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

- тип и идентификатор ресурса, на который направлен запрос;

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

- тип запроса;

- время и дата;

- внутреннее состояние ОО.

Для реализации правил на основе вышеуказанных параметров от ОО требуются поддержка и управление этими параметрами:

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

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

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

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

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

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

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

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

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

- атрибуты безопасности пользователей: идентификаторы пользователей, роли пользователей;

- атрибуты безопасности процессов: идентификатор процесса, уровень доверия к процессу.

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

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

12.2.2.2 Использование

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

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

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

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

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

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

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

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

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

Следует определить правила управления атрибутами безопасности пользователей. Это делается по аналогии с определением атрибутов безопасности субъектов и объектов.

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

- условия, которые должны быть выполнены для разрешения связывания;

- установку атрибутов безопасности субъекта после связывания.

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

12.2.3 Управление пользователями

12.2.3.1 Пояснение

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

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

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

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

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

12.2.3.2 Использование

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

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

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

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

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

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

- определить правила управления процессом аутентификации (включая управление учетными данными, используемыми для аутентификации);

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

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

12.2.4 Собственная защита ОО

12.2.4.1 Пояснение

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

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

- цель безопасности может быть не достигнута из-за сбоя элемента среды функционирования ОО;

- цель безопасности может быть не выполнена из-за сбоя элемента ФБО.

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

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

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

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

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

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

12.2.4.2 Использование

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

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

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

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

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

Ответное реагирование может состоять:

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

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

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

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

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

12.2.5 Защита каналов связи

12.2.5.1 Пояснение

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

- аутентификацию участников обмена данными;

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

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

- защиту от потери данных;

- обеспечение неотказуемости при отправке и (или) получении сообщений.

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

12.2.5.2 Использование

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

- идентификация каналов (соединений);

- определение необходимых характеристик безопасности для каждого канала связи. Примерами таких характеристик безопасности являются:

- аутентификация узлов;

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

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

- обеспечение неотказуемости (факта отправки, получения или и того и другого);

- обеспечение защиты от потери передаваемых данных.

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

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

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

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

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

- обеспечение конфиденциальности;

- обеспечение неотказуемости (при экспорте, импорте или и том и другом).

12.2.6 Аудит безопасности

12.2.6.1 Пояснение

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

Примерами таких критических событий безопасности являются:

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

- неожиданное возникновение сбоя;

- неожиданное или некорректное поведение (режим функционирования) удаленного доверенного продукта ИТ;

- сбой, обнаруженный функцией собственного тестирования;

- изменение заданных критических порогов безопасности для критичных данных ФБО;

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

12.2.6.2 Использование

Для построения модели аудита безопасности требуется:

- сформировать список событий, подлежащих аудиту;

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

- определить данные, которые должны быть указаны при регистрации каждого события;

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

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

12.2.7 Требования к архитектуре объекта оценки

12.2.7.1 Пояснение

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

- отказоустойчивость;

- управление потоками информации;

- характеристики обеспечения конфиденциальности;

- характеристики функционирования в режиме реального времени.

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

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

12.2.7.2 Использование

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

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

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

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

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

12.3 Спецификация функциональных требований безопасности в профиле защиты или задании по безопасности

12.3.1 Выбор функциональных требований безопасности

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

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

В процессе формирования ФТБ для включения в ПЗ или ЗБ выделяются несколько стадий.

В целях рассмотрения в процессе выбора целесообразно различать следующие два типа ФТБ:

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

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

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

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

Рисунок 4 - Взаимосвязь основных и дополнительных ФТБ

Формирование полной совокупности поддерживающих ФТБ включает следующие стадии:

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

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

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

Идентификация поддерживающих ФТБ согласно ГОСТ Р ИСО/МЭК 15408-2 представляет собой итерационный процесс, например:

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

б) согласно ГОСТ Р ИСО/МЭК 15408-2 компонент FAU_ARP.1 имеет зависимость от компонента FAU_SAA.1 "Анализ потенциальных нарушений", который также должен быть включен в ПЗ или ЗБ в качестве поддерживающего ФТБ;

в) компонент FAU_SAA.1 имеет зависимость от FAU_GEN.1 "Генерация данных аудита";

г) компонент FAU_GEN.1 имеет зависимость от FPT_STM.1 "Надежные метки времени";

д) компонент FPT_STM.1 не требует ввода дополнительных функциональных компонентов.

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

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

Для других компонентов добиться согласованности может быть проблематично. Например, при включении в ПЗ компонента FDP_ACC.1 одновременно идентифицируется конкретная ПФБ управления доступом. При удовлетворении зависимости FDP_ACC.1 от компонента FDP_ACF.1 необходимо обеспечить применение FDP_ACF.1 к той же политике управления доступом, которая идентифицировалась при включении в ПЗ компонента FDP_ACC.1. Если к компоненту FDP_ACC.1 применяется операция "итерация" для различных политик управления доступом, то зависимость от компонента FDP_ACF.1 должна быть удовлетворена несколько раз, принимая во внимание каждую политику управления доступом.

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

а) ФТБ, основанные на соответствующих компонентах из того же класса, что и основные ФТБ. Например, если компонент FAU_GEN.1 "Генерация данных аудита" включен в ПЗ, то может возникнуть потребность в создании и ведении журнала аудита безопасности для хранения сгенерированных данных (для формулирования подобных требований необходим один или более функциональных компонентов из семейства FAU_STG), а также в наличии средств просмотра сгенерированных данных аудита (для формулирования подобных требований необходим один или более функциональных компонентов из семейства FAU_SAR). В качестве альтернативы включению поддерживающих ФТБ сгенерированные данные аудита безопасности могут быть экспортированы для просмотра в другую систему.

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

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

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

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

б) увеличение числа ФТБ увеличивает стоимость оценки.

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

12.3.2 Выбор функциональных требований безопасности из ГОСТ Р ИСО/МЭК 15408-2

В приведенных ниже таблицах 2-7 представлено прослеживание между рассмотренными парадигмами и компонентами ФТБ, определенными в ГОСТ Р ИСО/МЭК 15408-2. Некоторые компоненты охватывают более одного аспекта парадигмы и поэтому приводятся в таблицах несколько раз.

Таблица 2 - Управление доступом

Требование	Применимые компоненты
Определение субъектов, объектов, операций	FDP_ACC.1, FDP_ACC.2, FDP_IFC.1, FDP_IFC.2, FMT_SMF.1
Определение атрибутов безопасности	FDP_DAU.1, FDP_DAU.2, FDP_IFF.1, FDP_IFF.2, FRU_PRS.1, FRU_PRS.2, FRU_RSA.1, FRU_RSA.2
Создание субъектов, объектов	FDP_ITC.1, FD_ITC.2, FMT_SMF.1
Экспортирование объектов	FDP_ETC.1, FDP_ETC.2
Управление атрибутами безопасности	FDP_ITC.2, FIA_USB.1, FMT_MSA.1, FMT_MSA.2, FMT_MSA.3, FMT_MTD.1, FMT_MTD.2, FMT_MTD.3, FMT_REV.1, FMT_REV.2, FMT_SAE.1, FTA_LSA.1
Определение правил доступа	FDP_ACF.1, FDP_IFF.1, FDP_IFF.2, FDP_ROL.1, FDP_ROL.2, FRU_PRS.1, FRU_PRS.2, FRU_RSA.1, FRU_RSA.2
Управление правилами управления доступом	FMT_MOF.1, FMT_SMF.1

Таблица 3 - Управление пользователями

Требование	Применимые компоненты
Определение типов пользователей	FMT_SMF.1
Определение атрибутов безопасности	FIA_ATD.1
Правила идентификации пользователей	FIA_UID.1, FIA_UID.2
Правила аутентификации пользователей	FIA_AFL.1, FIA_SOS.1, FIA_SOS.2, FIA_UAU.1, FIA_UAU.2, FIA_UAU.3, FIA_UAU.4, FIA_UAU.5, FIA_UAU.6, FIA_UAU.7
Управление учетными данными и атрибутами безопасности пользователей	FMT_MSA.1, FMT_MSA.2, FMT_MSA.3, FMT_MSA.4, FMT_MTD.1, FMT_MTD.2, FMT_MTD.3, FMT_REV.1, FMT_REV.2, FMT_SAE.1, FMT_SMR.1, FMT_SMR.2, FMT_SMR.3, FTA_LSA.1, FTA_MCS.1, FTA_MCS.2
Управление правилами идентификации и аутентификации	FMT_MOF.1, FMT_MTD.1, FMT_MTD.2, FMT_MTD.3, FMT_SMF.1
Управление связями пользователь - субъект	FIA_USB.1

Таблица 4 - Собственная защита ОО

Требование	Применимые компоненты
Обнаружение неисправности	FPT_TEE.1, FPT_ITI.2, FPT_ITT.3, FPT_PHP.1, FPT_PHP.2, FPT_PHP.3, FPT_RPL.1, FPT_TST.1, FRU_FLT.1, FRU_FLT.2
Реагирование на неисправность	FPT_ITT 3, FPT_PHP 2, FPT_PHP.3, FPT_RCV.1, FPT_RCV.2, FPT_RCV.3, FPT_RCV.4, FPT_RPL.1, FRU _FLT.1, FRU_FLT.2
Управление правилами обнаружения и реагирования	FMT_MOF.1, FMT_MTD.1, FMT_MTD.2, FMT_MTD.3, FMT_SMF.1

Таблица 5 - Защита каналов связи

Требование	Применимые компоненты
Установление канала связи	FMT_SMF.1, FTP_ITC.1, FTP_TRP.1
Определение свойств канала связи (атрибутов безопасности)	FCO_NRO.1, FCO_NRO.2, FCO_NRR.1, FCO_NRR.2, FDP_UTC.1, FDP_UIT.1, FDP_UIT.2, FDP_UIT.3, FPT_ITC.1, FPT_ITI.1, FPT_ITI.2, FPT_RPL.1, FTP_ITC 1, FTP_TRP.1
Управление свойствами канала связи	FMT_MSA.1, FMT_MSA.2, FMT_MSA.3, FMT_MTD.1, FMT_MTD.2, FMT_MTD.3, FMT_REV.1, FMT_REV.2, FMT_SAE.1
Управление правилами установления связи	FMT_MOF.1, FMT_MTD.1, FMT_MTD.2, FMT_MTD.3, FMT_SMF.1, FTA_SSL.1, FTA_SSL.2, FTA_SSL.3, FTA_SSL.4, FTA_TAB.1, FTA_TAH.1, FTA_TSE.1

Таблица 6 - Аудит

Требование	Применимые компоненты
Определение событий, подлежащих аудиту	FAU_GEN.1, FAU_GEN.2, FAU_SEL.1
Определение реагирования на события	FAU_ARP.1, FAU_SAA.1, FAU_SAA.2, FAU_SAA.3, FAU_SAA.4
Определение управления событиями	FAU_SAR.1, FAU_SAR.2, FAU_SAR.3
Определение управления журналом аудита	FAU_STG.1
Управление правилами аудита	FMT_MOF.1, FMT_MTD.1, FMT_MTD.2, FMT_MTD.3

Таблица 7 - Требования к архитектуре

Требование	Применимые компоненты
Защита журнала аудита	FAU_STG.2, FAU_STG.3, FAU_STG.4
Управление информационными потоками	FDP_IFF.3, FDP_IFF.4, FDP_IFF.5, FDP_IFF.6
Передача данных внутри ОО	FDP_ITT.1, FDP_ITT.2, FDP_ITT.3, FDP_ITT.4
Защита остаточной информации	FDP_RIP.1, FDP_RIP.2
Целостность хранимых данных	FDP_SDI.1, FDP_SDI.2
Управление	FMT_MTD.1
Защита конфиденциальности	FPR_ANO.1, FPR_ANO.2, FPR_PSE.1, FPR_PSE.2, FPR_PSE.3, FPR_UNL.1, FPR_UNO.1, FPR_UNO.2, FPR_UNO.3, FPR_UNO.4
Сбой безопасности	FPT_FLS.1
Доступность	FPT_ITA.1, FPT_ITT.1, FPT_ITT.2
Синхронизация состояния	FPT_SSP.1, FPT_SSP.2
Надежные метки времени	FPT_STM.1
Непротиворечивость данных	FPT_TDC.1, FPT_TRC.1

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

Для архитектурных требований предоставляется перечень возможных архитектурных вопросов, прослеженный к компонентам ФТБ из ГОСТ Р ИСО/МЭК 15408-2, связанным с этими вопросами.

12.3.3 Выполнение операций над функциональными требованиями безопасности

12.3.3.1 Разрешенные операции

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

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

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

в) выбор - позволяет специфицировать один или несколько элементов из списка;

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

12.3.3.2 Операция "итерация"

Операция "итерация" часто используется для определения ФТБ на основе компонентов класса FMT ("Управление безопасности"), которые включаются в ПЗ для удовлетворения зависимостей многих других функциональных компонентов. Для того чтобы удовлетворить такие зависимости, обычно необходимо использовать компоненты класса FMT, над которыми операции "назначение" и "выбор" выполняют по-разному. Например, компонент FMT_MSA.1 может быть использован многократно для определения отдельных ФТБ, соответствующих управлению различными типами атрибутов безопасности. Аналогично может потребоваться неоднократное использование компонентов семейств FDP_ACC и FDP_ACF в тех случаях, когда требуется, чтобы ОО реализовывал различные политики управления доступом, например, дискреционную и ролевую.

Целесообразно использовать операцию "итерация" для улучшения читабельности ПЗ, например, для того чтобы разбить сложное и громоздкое ФТБ на отдельные понятные ФТБ. Использование операции "итерация" тем не менее может породить другие потенциальные проблемы при представлении ФТБ в ПЗ или ЗБ.

12.3.3.3 Операции "назначение" и "выбор"

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

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

Баланс выполнения (завершения) операций основывается на том, что ПЗ должен:

а) представлять собой полный набор требований;

б) быть независимым от реализации;

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

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

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

Например, в нижеследующем ФТБ (основанном на FAU_STG.4.1) операция "выбор" выполнена частично путем предотвращения выбора варианта "игнорирование подвергаемых аудиту событий", который разработчик считает несовместимым с целями безопасности для ОО. Таким образом, ФТБ предоставляет разработчику ЗБ два (а не три) варианта выбора:

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

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

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

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

Например, требование на основе элемента FMT_SAE.1.1 могло быть представлено следующим образом:

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

Ниже приведен пример выполнения операции "выбор" в утвержденном ФСТЭК России профиле защиты.

Фрагмент исходного компонента:

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

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

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

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

Фрагмент компонента с выполненной операцией "выбор":

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

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

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

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

...".

Если операция остается невыполненной, то целесообразно пояснить, что выполнение операции возлагается на разработчика ЗБ. Например, требование на основе элемента FDP_RIP.1.1 могло бы быть специфицировано в ПЗ следующим образом:

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

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

Ниже приведен пример замечаний по применению из утвержденного ФСТЭК России профиля защиты:

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

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

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

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

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

12.3.3.4 Операция "уточнение"

Для каждого ФТБ, включаемого в ПЗ или ЗБ, необходимо принять решение о том, нуждается ли оно в каком-либо уточнении.

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

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

Использование операции "уточнение" может быть подходящим в следующих случаях:

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

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

в) когда может быть улучшен стиль изложения ФТБ.

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

Далее приводится пример выполнения операции "уточнение" применительно к требованию на основе элемента FMT_MTD.3.1:

"ФБО должны обеспечить присвоение данным ФБО только безопасных значений.

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

12.3.3.5 Выделение результатов выполнения операций

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

Ниже представлен фрагмент такого подраздела на примере подраздела "Соглашения" профилей защиты, утвержденных ФСТЭК России.

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

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

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

Операция "назначение" используется для присвоения конкретного значения ранее неконкретизированному параметру. Операция "назначение" обозначается заключением значения параметра в квадратные скобки - [назначаемое значение].

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

Настоящий профиль защиты содержит ряд незавершенных операций над компонентами функциональных требований безопасности. Эти операции должны быть завершены в задании по безопасности для конкретной реализации СКН".

12.3.4 Спецификация требований аудита

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

Выбор подлежащих аудиту событий и подлежащей аудиту информации зависит от следующих основных факторов:

а) определенные в ПБОр требования к аудиту безопасности;

б) значимость аудита безопасности для достижения целей безопасности;

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

г) анализ "стоимость - эффективность".

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

При проведении анализа "стоимость - эффективность" должны быть рассмотрены следующие вопросы:

а) является ли регистрируемая информация полезной для ее последующего анализа;

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

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

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

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

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

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

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

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

Если ни один из перечисленных уровней аудита не является подходящим для конкретного случая, то целесообразно выбрать неопределенный уровень аудита и в явном виде перечислить все подлежащие аудиту события в элементе FAU_GEN.1.1. Например, можно принять за основу минимальный уровень аудита, но в ряде случаев отклоняться от минимальных требований вследствие того, что какое-либо подмножество действий или событий является более значимым для достижения целей безопасности. Например, если в ПЗ включен компонент FDP_ACF.1, то может потребоваться более детальный аудит неуспешных попыток доступа по сравнению с успешными.

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

12.3.5 Спецификация требований управления

В подразделе "Управление" для каждого семейства (см. ГОСТ Р ИСО/МЭК 15408-2) определен список действий управления применительно к компонентам данного семейства. Наличие списка действий управления может предполагать включение в ПЗ отдельных компонентов из класса FMT "Управление безопасностью". Подраздел "Управление" определен в ГОСТ Р ИСО/МЭК 15408 в качестве информативного, и поэтому обосновывать отсутствие в ПЗ тех или иных компонентов управления нет необходимости (если, конечно, данные компоненты управления не идентифицированы в подразделе "Зависимости").

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

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

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

- создание объектов;

- изменение атрибутов безопасности пользователей, объектов, сеансов и т.д.

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

- изменение параметров аудита;

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

При выборе компонентов из класса FMT следует применять рекомендации, приведенные в ГОСТ Р ИСО/МЭК 15408-2 (приложение Н).

12.3.6 Спецификация функциональных требований, приведенных в профиле защиты

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

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

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

12.3.7 Спецификация функциональных требований, отсутствующих в профиле защиты

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

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

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

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

12.3.8 Спецификация в профиле защиты функциональных требований, не изложенных в ГОСТ Р ИСО/МЭК 15408-2

Если при разработке ПЗ требуется включить в документ функциональное требование, для которого в Г