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 Генерация данных аудита

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

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

...".

Если операция остается невыполненной, то целесообразно пояснить, что выполнение операции возлагается на разработчика ЗБ. Например, требование на основе элемента 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

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

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

Рекомендации по определению расширенных (специальных) компонентов представлены в разделе 11.

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

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

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

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

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

Далее приведен пример выполнения операции "уточнение" над элементом FMT_MSA.3.1 функционального компонента FMT_MSA.3 "Инициализация статических атрибутов".

Элемент FMT_MSA.3.1 в ГОСТ Р ИСО/МЭК 15408-2 имеет следующий вид:

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

После выполнения операций "назначение", "выбор" и "уточнение", соответствующих элементу FMT_MSA.3.1, ФТБ принимает следующий вид:

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

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

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

Реализация описанного подхода к представлению ФТБ проиллюстрирована на примере формирования ПЗ, приведенном в приложении Б настоящего стандарта.

12.3.10 Разработка подраздела "Обоснование требований безопасности"

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

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

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

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

- каким образом осуществляется аутентификация пользователей;

- реакцию в случае неудачной аутентификации;

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

- каким образом осуществляется связь "пользователь - субъект".

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

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

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

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

12.4 Спецификация в ПЗ или ЗБ требований доверия к безопасности

12.4.1 Выбор требований доверия к безопасности

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

а) ценности активов, подлежащих защите, и риска их компрометации;

б) технической реализуемости;

в) стоимости разработки и оценки;

г) требуемого времени для разработки и оценки ОО;

д) требований рынка (для продуктов ИТ);

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

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

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

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

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

б) цели безопасности могут требовать рассмотрения вопросов собственной защиты, разделения доменов или невозможности обхода, и в этом случае необходимо включить в ПЗ или ЗБ компонент ADV_ARC.1. В классе ADV имеется только один компонент, но требуемый уровень архитектурного описания зависит от компонента, выбираемого из класса ADV_TDS;

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

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

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

Если в ПЗ включены расширенные требования доверия к безопасности, то необходимо удовлетворить все зависимости компонентов доверия к безопасности, содержащих эти дополнительные требования. Например, если в ПЗ пакет ОУДЗ усилен путем использования компонента AVA_VAN.3 "Сосредоточенный анализ уязвимостей", то в ПЗ также необходимо включить компоненты ADV_TDS.3 "Базовый модульный проект" и ADV_IMP.1 "Представление реализации ФБО". Кроме того, должен быть включен компонент ADV_FSP.4 "Полная функциональная спецификация", так как ADV_TDS.3 имеет зависимость от ADV_FSP 4.

Если ПЗ или ЗБ разрабатываются для конкретного класса защиты средств защиты информации, установленных соответствующим нормативным правовым актом ФСТЭК России для данного вида средств защиты информации, состав требований доверия определяется на основе этого документа. Типовой состав компонентов доверия в зависимости от класса защиты средств защиты информации приведен в таблице 8.

Таблица 8 - Типовой состав компонентов доверия в зависимости от класса защиты средств защиты информации

Класс защиты средства защиты информации	Требования доверия к безопасности средств защиты информации		Уровень контроля отсутствия недеклариро ванных возможностей
Класс защиты средства защиты информации	Оценочный уровень доверия по ГОСТ Р ИСО/МЭК 15408-3	Дополнительные требования доверия к безопасности, определенные на основе ГОСТ Р ИСО/МЭК 15408-3	Уровень контроля отсутствия недеклариро ванных возможностей
4	ОУДЗ	ADV_FSP.4 "Полная функциональная спецификация" ADV_IMP.2 "Полное отображение представления реализации функциональных возможностей безопасности" ADV_TDS.3 "Базовый модульный проект" ALC_CMC.4 "Поддержка генерации, процедуры приемки и автоматизация" ALC_FLR.1 "Базовое устранение недостатков" АLС_ТАТ.1 "Полностью определенные инструментальные средства разработки" AVA_VAN.5 "Усиленный методический анализ" ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения средства защиты информации" AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность средства защиты информации"	4
5	ОУД2	ADV_IMP.2 "Полное отображение представления реализации функциональных возможностей безопасности" ADV_TDS.3 "Базовый модульный проект" ALC_FLR.1 "Базовое устранение недостатков" AVA_VAN.4 "Методический анализ уязвимостей" ALC_TAT_EXT.0 "Определение инструментальных средств разработки" ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения средства защиты информации" AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность средства защиты информации"	4
6	ОУД1	ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения средства защиты информации" AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность средства защиты информации"	-

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

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

Возможны следующие операции:

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

б) "уточнение", позволяющее детализировать ТДБ;

в) "назначение", позволяющее устанавливать в элементе ТДБ значения указанного параметра.

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

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

б) в целях предписания действий оценщика, например:

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

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

Таким образом (с помощью применения операции "уточнение"), в ПЗ, утвержденные ФСТЭК России, интегрированы требования руководящего документа ФСТЭК России по контролю отсутствия недекларированных возможностей (РД НДВ [9]).

Фрагмент требований РД НДВ:

"Контроль исходного состояния ПО

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

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

Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.

Статический анализ исходных текстов программ

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

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

- контроля соответствия исходных текстов ПО его объектному (загрузочному) коду".

Исходный компонент доверия:

"ADV_IMP.2 Полное отображение представления реализации ФБО

Зависимости: ADV_TDS.3 Базовый модульный проект;

АLС_ТАТ.1 Полностью определенные инструментальные средства разработки;

ALC_CMC.5 Расширенная поддержка.

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

ADV_IMP.2.1D Заявитель (разработчик, производитель) должен обеспечить доступ к представлению реализации для всех ФБО:

для аппаратных средств - на уровне схем аппаратных средств и (или) представления (кода) на языке описания аппаратных средств (в соответствии с национальным стандартом ГОСТ Р 50754 "Язык описания аппаратуры цифровых систем - VHDL" или ином языке описания аппаратных средств);

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

ADV_IMP.2.2D Заявитель (разработчик, производитель) должен обеспечить прослеживание всего представления реализации к описанию проекта ОО.

Элементы содержания и представления документированных материалов

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

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

ADV_IMP.2.3C В прослеживании между всем представлением реализации и описанием проекта ОО (для всех модулей, отнесенных к осуществляющим или поддерживающим выполнение ФТБ) должно быть продемонстрировано их соответствие, а для модулей изделия, определенных как "не влияющие на выполнение ФТБ", должно быть предоставлено соответствующее обоснование.

Элементы действий испытательной лаборатории

ADV_IMP.2.1Е Испытательная лаборатория должна подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ADV_IMP.2.1C-ADV_IMP.2.3C, в том числе на основе результатов:

а) контроля исходного состояния ПО;

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

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

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

"AGD_OPE.1 Руководство пользователя по эксплуатации

...

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

...

AGD_PRE.1 Подготовительные процедуры

...

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

..."

Фрагменты уточненных компонентов доверия:

"AGD_OPE.1 Руководство пользователя по эксплуатации

...

Элементы содержания и представления свидетельств (документированных материалов)

...

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

...

AGD_PRE.1 Подготовительные процедуры

...

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

..."

Действующая редакция ГОСТ Р ИСО/МЭК 15408 не предъявляет требований к разработчику (заявителю) по проведению анализа уязвимостей.

"AVA_VAN.4 Методический анализ уязвимостей

...

Элементы действий разработчика

AVA_VAN.4.1D Разработчик должен представить OO для тестирования.

Элементы содержания и представления свидетельств

AVA_VAN.4.1C OO должен быть пригоден для тестирования.

..."

Предыдущая редакция ГОСТ Р ИСО/МЭК 15408 предъявляла следующие требования:

"AVA_VLA.3 Умеренно стойкий

...

Элементы действий разработчика

AVA_VLA.3.1D Разработчик должен выполнить анализ уязвимостей.

AVA_VLA.3.2D Разработчик должен предоставить документацию анализа уязвимостей.

Элементы содержания и представления свидетельств

AVA_VLA.3.1C Документация анализа уязвимостей должна содержать описание анализа поставляемых материалов OO, выполненного для поиска способов, которыми пользователь может нарушить ПБО.

AVA_VLA.3.2C Документация анализа уязвимостей должна содержать описание решения в отношении идентифицированных уязвимостей.

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

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

AVA_VLA.3.5C Документация анализа уязвимостей должна показывать, что поиск уязвимостей является систематическим.

..."

Для обеспечения преемственности требований и сохранения принятой технологии сертификации в ПЗ, утвержденных ФСТЭК России, требования по проведению анализа уязвимостей сохранены путем выполнения уточнения над соответствующими компонентами ТДБ из семейства AVA_VAN:

"AVA_VAN.4 Методический анализ уязвимостей

...

Элементы действий заявителя

AVA_VAN.4.1D Заявитель должен выполнить анализ уязвимостей ОО.

Элементы содержания и представления свидетельств (документированных материалов)

AVA_VAN.4.1C Документация анализа уязвимостей должна:

содержать результаты анализа, выполненного для поиска способов, которыми потенциально может быть нарушена реализация ФТБ;

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

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

..."

Что касается выполнения операции "назначение" над компонентами ТДБ, то в ГОСТ Р ИСО/МЭК 15408-3 имеются два примера, где допускается выполнение операции "назначение": элементы ADV_INT.1.1D и ADV_SPM.1.1D.

В первом случае разработчику ПЗ или ЗБ нужно определить при помощи операции "назначение" подмножество ФБО, к которому применяется элемент.

Исходный элемент:

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

Элемент с примером выполнения операции "назначение":

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

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

Исходный элемент:

"ADV_SPM.1.1D Разработчик должен представить формальную модель ПБО для [назначение: список формально моделируемых политик]".

Элемент с примером выполнения операции "назначение":

"ADV_SPM.1.1D Разработчик должен представить формальную модель ПБО для [политики управления доступом]".

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

12.4.3 Спецификация в профиле защиты или задании по безопасности требований доверия к безопасности, не включенных в ГОСТ Р ИСО/МЭК 15408-3

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

Рекомендации по определению расширенных (специальных) компонентов ТДБ представлены в разделе 11.

12.4.4 Определение документированных материалов (свидетельств), необходимых для проведения оценки

Для проведения работ по оценке соответствия продукта ИТ требованиям безопасности заявитель должен предоставить испытательной лаборатории документированные материалы (свидетельства), предусмотренные компонентами доверия к безопасности (в частности, элементами АХХ_ХХХ.#.#С). Согласно требованиям ФСТЭК России для сертификации средств защиты информации 4-6 классов защиты должны быть представлены документированные материалы (свидетельства) согласно таблице 9.

Таблица 9 - Документированные материалы (свидетельства), предоставляемые заявителем для проведения сертификационных испытаний средств защиты информации

Документированные материалы (свидетельства), предоставляемые заявителем для проведения сертификационных испытаний средств защиты информации (в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2013 и ГОСТ Р ИСО/МЭК 18045-2013)	Класс защиты средства защиты информации
	6	5	4
1. Задание по безопасности	+	+	+
2. Функциональная спецификация	+	+	+
3. Проект на уровне подсистем (эскизный проект)		+	+
4. Проект на уровне модулей (технический проект)		+	+
5. Описание архитектуры безопасности		+	+
6. Представление реализации		+	+
7. Руководство пользователя по эксплуатации	+	+	+
8. Руководство по подготовительным процедурам	+	+	+
9. Описание процедур поставки		+	+
10. Документация по управлению конфигурацией:
список управления конфигурацией (список конфигурации)	+	+	+
план управления конфигурацией			+
документация по применению управления конфигурацией			+
протоколы (записи) системы управления конфигурацией			+
описание технологии обновления средства защиты информации	+	+	+
регламент обновления программного обеспечения средства защиты информации	+	+	+
11. Документация по безопасности разработки			+
12. Документация процедур устранения недостатков		+	+
13. Документация определения жизненного цикла (модель жизненного цикла, используемая при разработке и сопровождении объекта оценки)			+
14. Документация инструментальных средств разработки		+	+
15. Тестовая документация (заявителя, разработчика)		+	+
16. Свидетельство о покрытии тестами		+	+
17. Материалы анализа глубины тестирования			+
18. Документация анализа уязвимостей		+	+
19. Описание технологии выпуска обновлений межсетевого экрана	+	+	+
20. Регламент обновления средства защиты информации	+	+	+
21. Документация процедуры представления обновлений для проведения внешнего контроля	+	+	+

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

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

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

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

В зависимости от вида и (или) типа OO это, например, могут быть:

- базы данных признаков компьютерных вирусов (для САВЗ);

- базы компьютерных атак (для СОВ);

- базы уязвимостей (для САЗ).

12.4.5 Обоснование требований доверия к безопасности

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

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

Если ПЗ или ЗБ разрабатываются для конкретного класса защиты средств защиты информации, то включение конкретных требований доверия к безопасности ОО в ПЗ или ЗБ обосновывается требованиями соответствующего нормативного правового акта ФСТЭК России для данного вида средств защиты информации. Например, для средств контроля съемных носителей информации - требованиями документа ФСТЭК России "Требования к средствам контроля съемных машинных носителей информации".

<< 11. Спецификация раздела "Определение расширенных компонентов"		Приложение >> А (справочное). Пример определения расширенного компонента
	Содержание Национальный стандарт РФ ГОСТ Р 57628-2017 "Информационная технология. Методы и средства обеспечения безопасности. Руководство...

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

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