Национальный стандарт РФ ГОСТ Р 57628-2017 "Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности" (утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 25 августа 2017 г. N 967-ст)

Национальный стандарт РФ ГОСТ Р 57628-2017
"Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности"
(утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 25 августа 2017 г. N 967-ст)

Information technology. Security techniques. Guide for the production of Protection Profiles and Security Targets

ОКС 35.240
П80

Дата введения - 1 января 2018 г.
Взамен ГОСТ P ИСО/МЭК TO 15446-2008

Предисловие

1 Разработан Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ")

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

3 Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 25 августа 2017 г. N 967-ст

4 Настоящий стандарт разработан с учетом основных положений международного стандарта ISO/IEC TR 15446:2009 "Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности" (ISO/IEC TR 15446:2004 "lnformation technology - Security techniques - Guide for the production of Protection Profiles and Security Targets", NEQ)

5 Взамен ГОСТ P ИСО/МЭК TO 15446-2008

Введение

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

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

а) формулировку потребности в безопасности, соответствующую проблеме безопасности и выраженную в терминах, ориентированных на пользователей ИТ;

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

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

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

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

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

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

б) утверждение о соответствии ЗБ одному или более ПЗ (если применимо);

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

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

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

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

Настоящий стандарт представляет собой руководство по разработке профилей защиты (ПЗ) и заданий по безопасности (ЗБ) в соответствии с комплексом стандартов ГОСТ Р ИСО/МЭК 15408.

Настоящий стандарт не предназначен для использования в качестве вводного материала по оценке безопасности продуктов ИТ в соответствии с ГОСТ Р ИСО/МЭК 15408. Для получения такой информации следует использовать ГОСТ Р ИСО/МЭК 15408-1.

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

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

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

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

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

ГОСТ Р ИСО/МЭК 18045-2013 Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий

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

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ Р ИСО/МЭК 15408-1.

4 Сокращения

В настоящем стандарте применены следующие обозначения:

БИТ - безопасность информационных технологий;

ЗБ - задание по безопасности;

ЗИ - защита информации;

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

ИФБО - интерфейс ФБО;

НДВ - недекларированные возможности;

ОО - объект оценки;

ОПБ - определение проблемы безопасности;

ОУД - оценочный уровень доверия;

ПБОр - политика безопасности организации;

ПЗ - профиль защиты;

ПО - программное обеспечение;

РД - руководящий документ;

САВЗ - средство антивирусной защиты;

СВТ - средство вычислительной техники;

СКН - средство контроля съемных машинных носителей информации;

СОВ - система обнаружения вторжений;

СУБД - система управления базами данных;

ТДБ - требование доверия к безопасности;

ФБО - функциональные возможности безопасности ОО;

ФТБ - функциональное требование безопасности.

5 Назначение и структура стандарта

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

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

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

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

Разделы 1-4 содержат вводные и ссылочные материалы.

В разделе 5 приведен обзор структуры и назначения настоящего стандарта.

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

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

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

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

В приложении А приведен пример определения расширенного (по отношению к ГОСТ Р ИСО/МЭК 15408-2) компонента.

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

6 Краткий обзор профилей защиты и заданий по безопасности

6.1 Введение

В данном разделе приведен краткий обзор роли ПЗ и ЗБ в процессе оценки безопасности продуктов ИТ в соответствии с комплексом стандартов ГОСТ Р ИСО/МЭК 15408.

6.2 Целевая аудитория

Настоящий стандарт предназначен для использования следующими категориями пользователей:

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

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

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

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

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

6.3 Использование профилей защиты и заданий по безопасности

6.3.1 Введение

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

В качестве примера системы ИТ можно, например, привести средства контроля отчуждения (переноса) информации со съемных машинных носителей информации, в состав которых входят следующие компоненты, распределенные по компонентам информационной системы или сами являющиеся законченными изделиями:

- специализированные съемные машинные носители информации;

- программное обеспечение инициализации;

- программное обеспечение управления;

- программное обеспечение взаимодействия со съемными машинными носителями информации.

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

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

В ГОСТ Р ИСО/МЭК 15408 приведены стандартизированные спецификации безопасности для (помимо прочего):

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

- создания условий для сравнения спецификаций безопасности различных продуктов ИТ.

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

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

Когда заказчику необходимо приобрести продукт ИТ, у него фактически имеются две возможности:

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

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

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

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

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

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

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

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

6.3.2 Процесс приобретения на основе спецификации

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

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

а) заказчик должен определить требования безопасности в неформализованном виде;

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

в) разработчик должен создать (разработать) продукт ИТ на основе данной спецификации.

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

6.3.2.2 Неформализованные требования безопасности

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

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

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

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

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

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

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

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

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

ж) несогласованными: требования могут быть внутренне противоречивыми.

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

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

6.3.2.3 Использование профилей защиты в качестве спецификаций

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

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

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

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

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

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

6.3.2.4 Разработка продукта по профилю защиты

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

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

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

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

- задание по безопасности может быть более детализированным, чем ПЗ: если в ПЗ объясняется, "что" должно быть защищено, то в ЗБ указывается и "каким образом": разработчик обобщенно излагает, каким образом он реализует требования заказчика.

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

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

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

6.3.2.5 Роль оценки в процессе приобретения на основе спецификации

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

а) ЗБ соответствует ПЗ;

б) продукт ИТ соответствует ЗБ;

в) следовательно, продукт ИТ соответствует ПЗ и отвечает требованиям заказчика.

Если заказчик принимает эти утверждения, процесс завершается.

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

а) ЗБ соответствует ПЗ;

б) продукт ИТ соответствует ЗБ.

Следует отметить, что несмотря на проведение оценки, два вопроса по-прежнему останутся открытыми:

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

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

6.3.3 Процесс приобретения на основе выбора

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

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

В процессе приобретения продукта ИТ на основе выбора:

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

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

6.3.3.2 Использование предоставленной разработчиком спецификации

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

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

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

Разработчик создает (разрабатывает) свой продукт в соответствии с ЗБ: этот процесс аналогичен процессу приобретения на основе спецификации.

6.3.3.3 Сравнение заданий по безопасности разных разработчиков

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

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

6.3.3.4 Роль оценки в процессе приобретения на основе выбора

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

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

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

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

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

6.3.4 Другие возможности использования профилей защиты

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

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

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

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

6.4 Процесс разработки профилей защиты и заданий по безопасности

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

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

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

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

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

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

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

а) идентификацию новых угроз;

б) изменение ПБОр;

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

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

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

6.5 Вопросы восприятия и понимания профилей защиты и заданий по безопасности

6.5.1 Введение

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

Для детального понимания содержания ПЗ и ЗБ следует изучить ГОСТ Р ИСО/МЭК 15408-1, в частности приложения А и В, в которых представлена детальная информация относительно заданий по безопасности и профилей защиты соответственно. Также необходимо изучить опубликованные ПЗ и ЗБ, находящиеся в открытом доступе. Профили защиты, выпущенные ФСТЭК России для целого ряда видов и типов средств защиты информации (например, средств антивирусной защиты, систем обнаружения вторжений, средств доверенной загрузки, средств контроля использования съемных машинных носителей информации, межсетевых экранов), представлены на официальном сайте ФСТЭК России (www.fstec.ru). Существует целый ряд международных реестров, из которых можно получить ПЗ и ЗБ. Самым известным является портал Common Criteria ("Общие критерии") [1]. Этот реестр признан ИСО и МЭК в качестве официального реестра JTC 1 для профилей защиты и пакетов, сформированных в соответствии с ГОСТ Р ИСО/МЭК 15408. Он функционирует в соответствии с [2].

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

К таким подразделам относятся:

а) "Аннотация ОО";

б) "Описание ОО";

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

г) "Утверждения о соответствии".

6.5.2 Подраздел "Аннотация ОО"

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

а) использование и основные характеристики безопасности ОО;

б) тип ОО;

в) требуемые аппаратные средства/программное обеспечение/программно-аппаратные средства, не входящие в ОО.

Простые примеры изложения этих пунктов приведены в ГОСТ Р ИСО/МЭК 15408-1, пункт А.4.2.

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

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

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

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

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

В состав средства контроля подключения съемных машинных носителей информации (СКН) входят следующие компоненты:

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

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

В СКН должны быть реализованы следующие функции безопасности:

- разграничение доступа к управлению СКН;

- управление работой СКН;

- управление параметрами СКН;

- контроль подключения съемных машинных носителей информации;

- аудит безопасности СКН;

- сигнализация СКН.

В среде, в которой СКН функционирует, должны быть реализованы следующие функции безопасности среды:

- физическая защита средств вычислительной техники, на которых используются компоненты СКН;

- обеспечение условий безопасного функционирования СКН;

- управление атрибутами безопасности компонентов СКН.

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

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

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

- требования доверия к безопасности.

Функциональные требования безопасности СКН, изложенные в ПЗ, включают:

- требования к разграничению доступа к управлению СКН;

- требования к управлению работой (режимами выполнения функций безопасности) СКН;

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

- требования к контролю подключения съемных машинных носителей информации;

- требования по предупреждению о событиях, связанных с нарушением безопасности;

- требования к аудиту безопасности СКН.

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

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

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

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

- поддержка определенных ролей для средства контроля подключения съемных машинных носителей информации и их ассоциации с конкретными администраторами СКН и пользователями информационной системы;

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

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

- возможность чтения информации из записей аудита уполномоченным администраторам СКН;

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

- возможность выборочного просмотра данных аудита.

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

В целях обеспечения условий для безопасного функционирования СКН в настоящем ПЗ определены цели и требования для среды функционирования СКН".

В пункте "Тип ОО" приводится описание общей категории продуктов ИТ, к которым относится ОО (например, операционная система, межсетевой экран, средство антивирусной защиты, средство обнаружения вторжений, средство доверенной загрузки и т.д.).

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

- средства контроля подключения съемных машинных носителей информации;

- средства контроля отчуждения (переноса) информации со съемных машинных носителей информации.

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

"Объектом оценки в настоящем ПЗ является средство контроля подключения съемных машинных носителей информации.

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

- проверка наличия разрешения или запрета на использование интерфейса ввода (вывода) средства вычислительной техники при попытке подключения съемного машинного носителя информации;

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

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

- разрешение или запрет использования подключаемого съемного машинного носителя информации по результатам выполненных проверок;

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

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

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

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

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

Если эти предупреждения предоставлены и могут влиять на предполагаемое использование продукта ИТ, то следует внимательно рассмотреть возможность использования данного ОО с этими ограничениями.

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

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

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

6.5.3 Подраздел "Описание ОО"

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

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

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

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

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

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

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

6.5.4 Цели безопасности для среды функционирования

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

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

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

6.5.5 Подраздел "Утверждение о соответствии"

"Утверждение о соответствии" обычно находится в начале ПЗ или ЗБ. В раздел обычно включается одно предложение следующего вида:

Настоящий ПЗ (настоящее ЗБ):

- соответствует ГОСТ Р ИСО/МЭК 15408;

- соответствует ГОСТ Р ИСО/МЭК 15408-2 или является расширенным по отношению к ГОСТ Р ИСО/МЭК 15408-2;

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

- соответствует ГОСТ Р ИСО/МЭК 15408-3 или является расширенным по отношению к ГОСТ Р ИСО/МЭК 15408-3;

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

- соответствует перечню пакетов, о соответствии которым утверждается для ОО;

Наиболее распространенным является использование пакета ОУД1, ОУД2, ..., ОУД6 или ОУД7, часто с пометкой "усиленный" и (или) "расширенный". Более подробно ОУД рассмотрены в 6.5.7.

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

Более подробно это соответствие рассмотрено в 6.5.6.

6.5.6 Соответствие профилям защиты

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

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

В ПЗ может содержаться утверждение о "строгом" или "демонстрируемом" соответствии ПЗ или ЗБ.

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

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

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

- "строгое" соответствие - если рассматриваемый ПЗ является единственным ПЗ, утверждение о соответствии которому включено в ЗБ;

- "демонстрируемое" соответствие - если ОО является комплексным продуктом (изделием), и в ЗБ включено утверждение о соответствии (помимо настоящему ПЗ) другому (другим) ПЗ.

6.5.7 Оценочные уровни доверия и другие вопросы доверия

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

- билет на некоторое число поездок в транспорте;

- кредитная карта с кредитным лимитом в 500 000 рублей;

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

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

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

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

ГОСТ Р ИСО/МЭК 15408 систематизирует доверие по двадцати семи категориям (так называемым "семействам доверия"). В каждой такой категории ГОСТ Р ИСО/МЭК 15408 определяет различные уровни соответствия.

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

- "0": неизвестно, выполнял ли разработчик тестирование продукта;

- "1": разработчик выполнил некоторое число тестов по отношению к отдельным интерфейсам продукта ИТ;

- "2": разработчик выполнил некоторое число тестов по отношению ко всем интерфейсам продукта ИТ;

- "3": разработчик выполнил очень большое число тестов по отношению ко всем интерфейсам продукта ИТ.

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

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

Каждый ОУД можно рассматривать как набор из двадцати семи чисел, по одному числу на каждую подкатегорию. Например, ОУД1 присваивает "1" тринадцати подкатегориям и "0" - остальным четырнадцати, в то время как ОУД2 присваивает "2" семи подкатегориям, "1" - одиннадцати подкатегориям, а оставшимся девяти - "0".

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

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

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

- усиливаются компонентами не использовавшейся в данном ОУД категории (семейства);

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

- расширяются с использованием компонентов, не входящих в ГОСТ Р ИСО/МЭК 15408-3, то есть расширенных (специальных) компонентов.

При этом итоговые наборы требований доверия (усиленные и расширенные ОУД) применяются для соответствующих классов защиты, устанавливаемых в нормативных правовых актах ФСТЭК России. Типовой состав компонентов доверия в зависимости от класса защиты средств защиты информации представлен в 12.4.1.

13 Краткая спецификация объекта оценки

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

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

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

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

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

14 Спецификация ПЗ и ЗБ для составных OO и ОО-компонентов

14.1 Составные объекты оценки

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

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

В приведенных выше примерах имеются следующие зависимости:

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

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

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

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

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

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

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

При анализе зависимостей можно легко идентифицировать:

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

- зависимость операционной системы от аппаратных средств;

- зависимость операционной системы от LDAP-сервера;

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

- зависимость операционной системы от смарт-карты;

- зависимость смарт-карты от операционной системы основного компьютера.

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

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

Предположение-1:

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

Предположение-2:

"Среда функционирования будет защищать файлы, используемые СУБД для хранения данных пользователей и данных ФБО от несанкционированного доступа";

Предположение-3:

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

Эти предположения могут быть использованы для определения вполне конкретных целей для операционной системы как части среды функционирования. Уровень детализации этих целей во многом зависит от конкретных требований, предъявляемых к СУБД. Например, если к СУБД предъявляются требования по аудиту, то может быть полезным потребовать также определенного уровня аудита от операционной системы с тем, чтобы обнаруживать попытки обхода или вмешательства в функциональные возможности безопасности операционной системы, от которой зависит СУБД. Примеры целей безопасности, полученных на основе приведенных ранее предположений:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14.2 ОО-компоненты

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

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

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

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

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

15 Отдельные вопросы

15.1 Профили защиты и задания по безопасности низкого уровня доверия

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

- определение проблемы безопасности;

- цели безопасности;

- обоснование целей безопасности;

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

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

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

15.2 Соответствие национальным интерпретациям ГОСТ Р ИСО/МЭК 15408

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

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

15.3 Функциональные пакеты и пакеты доверия

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

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

В существующих профилях защиты ФСТЭК России встречается также следующая ситуация. В ПЗ для СКН для 4 класса защиты (ИТ.СКН.П4.ПЗ) в качестве пакета доверия определен ОУДЗ усиленный и расширенный. В частности, ОУДЗ усилен компонентом ADV_IMP.2 "Полное отображение представления реализации ФБО". Компонент ADV_IMP.2 "Полное отображение представления реализации ФБО" имеет зависимость от компонента ALC_CMC.5 "Расширенная поддержка". По общему правилу компонент ALC_CMC.5 "Расширенная поддержка" либо следовало включить в ПЗ для СКН, либо обосновать неудовлетворение зависимости, либо предоставить рекомендации по удовлетворению этой зависимости в задании по безопасности. В ПЗ для СКН для 4 класса защиты (ИТ.СКН.П4.ПЗ) зависимость не была удовлетворена, так как уровень требований ALC_CMC.5 "Расширенная поддержка" (этот компонент является штатным для ОУД6) является необоснованно высоким для ОУДЗ и 4 класса защиты СКН; вместе с тем в пакет доверия и в ПЗ ИТ.СКН.П4.ПЗ был включен компонент ALC_CMC.4 "Поддержка генерации, процедуры приемки и автоматизация" как достаточное усиление, соответствующее общему уровню требований пакета доверия и классу защиты СКН.

16 Использование автоматизированных инструментальных средств

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

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

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

[1]	Перечень профилей защиты на портале Common Criteria, commoncriteriaportal.org
[2]	ISO/IEC 15292, Information technology - Security techniques - Protection Profile registration procedures
[3]	Методический документ ФСТЭК России "Профиль защиты средств контроля подключения съемных машинных носителей информации четвертого класса защиты" (ИТ.СКН.П4.ПЗ), 2014
[4]	Методический документ ФСТЭК России "Профиль защиты средств контроля подключения съемных машинных носителей информации пятого класса защиты" (ИТ.СКН.П5.ПЗ), 2014
[5]	Руководящий документ ФСТЭК (Гостехкомиссии) России "Безопасность информационных технологий. Критерии оценки безопасности информационных технологий" (РД БИТ), 2002
[6]	Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах (утв. Приказом ФСТЭК России 11.02.2013 N 17)
[7]	Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных (утв. Приказом ФСТЭК России 18.02.2013 N 21)
[8]	Требования к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды (утв. Приказом ФСТЭК России от 14.03.2014 N 31)
[9]	Руководящий документ ФСТЭК (Гостехкомиссии) России "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля недекларированных возможностей" (РД НДВ), 1999