Товары в корзине: 0 шт Оформить заказ
Стр. 1 

56 страниц

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

 Скачать PDF

Идентичен ISO/IEC 15408-1:2009

Оглавление

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

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

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

     3.1 Термины и определения, общие для всех частей ИСО/МЭК 15408

     3.2 Термины и определения, относящиеся к классу ADV

     3.3 Термины и определения, относящиеся к классу AGD

     3.4 Термины и определения, относящиеся к классу ALC

     3.5 Термины и определения, относящиеся к классу AVA

     3.6 Термины и определения, относящиеся к классу ACO

4 Сокращения

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

     5.1 Общая информация

     5.2 Объект оценки

     5.3 Пользователи ИСО/МЭК 15408

     5.4 Части ИСО/МЭК 15408

     5.5 Контекст оценки

6 Общая модель

     6.1 Введение к общей модели

     6.2 Активы и контрмеры

     6.3 Оценка

7 Доработка требований безопасности для конкретного применения

     7.1 Операции

     7.2 Зависимости между компонентами

     7.3 Расширенные компоненты

8 Профили защиты и пакеты

     8.1 Введение

     8.2 Пакеты

     8.3 Профили защиты

     8.4 Использование ПЗ и пакетов

     8.5 Многократное использование профилей защиты

9 Результаты оценки

     9.1 Введение

     9.2 Результаты оценки ПЗ

     9.3 Результаты оценки ЗБ/ОО

     9.4 Утверждение о соответствии

     9.5 Использование результатов оценки ЗБ/ОО

Приложение А (справочное) Спецификация заданий по безопасности

Приложение В (справочное) Спецификация профилей защиты

Приложение С (справочное) Руководство по выполнению операций

Приложение D (справочное) Соответствие ПЗ

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

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

 

56 страниц

Дата введения01.12.2013
Добавлен в базу01.10.2014
Актуализация01.02.2020

Этот ГОСТ находится в:

Организации:

15.11.2012УтвержденФедеральное агентство по техническому регулированию и метрологии814-ст
ИзданСтандартинформ2014 г.
РазработанФГУП СКЦ Росатома
РазработанФАУ ГНИИИ ПТЗИ ФСТЭК России
РазработанООО ЦБИ

Information technology. Security techniques. Evaluation criteria for IT security. Part 1. Introduction and general model

Нормативные ссылки:
Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

ГОСТР

исо/мэк

15408-1 —

2012

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

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

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

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

Часть 1

Введение и общая модель

ISO/IEC 15408-1:2009 Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model

(IDT)

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

Москва

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

2014

ГОСТ Р ИСО/МЭК 15408-1—2012

Предисловие

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

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

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

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

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

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

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

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

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

3.1.81    данные ФБО (TSF data): Данные, необходимые для функционирования 00. на основе которых осуществляется реализация ФТБ.

3.1.82    интерфейс ФБО (TSF interface): Средства, через которые внешние сущности (или субъект в 00. но за пределами ФБО) передают данные к ФБО. получают данные от ФБО и обращаются к сервисам ФБО.

3.1.83    данные пользователя (user data): Данные для пользователя, не влияющие на выполнение ФБО.

3.1.84    верифицировать (verify): Провести строгую детальную проверку с независимым определением ее достаточности.

Примечание — См. также термин «подтверждать» (3.1.14). Термин «верифицировать» имеет более глубокий смысл. Он используется в контексте действий оценщика, когда требуются независимые усилия оценщика.

3.2 Термины и определения, относящиеся к классу ADV

Примечание — Приведенные ниже термины используются в формулировках требований для отражения внутренней структуризации программного обеспечения. Некоторые из них взяты из IEEE Std 610.12—1990 «Стандартный глоссарий терминологии по проектированию программного обеспечения». Институт инженеров по электротехнике и электронике.

3.2.1    администратор (administrator): Сущность, которая имеет некоторый уровень доверия в отношении всех политик, реализуемых ФБО.

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

3.2.2    дерево вызовов (call tree): Идентифицирует модули в системе в виде диаграммы, показывающей. какие модули вызывают другие модули.

Примечание — Адаптированный термин IEEE Std 610.12—1990.

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

(IEEE Std 610.12—1990)

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

3.2.4    случайная связность (coincidental cohesion): Связность модуля, характеризуемая выполнением несвязанных или слабо связанных действий.

(IEEE Std 610.12—1990]

Примечание — См. также «связность» (3.2.3).

3.2.5    коммуникационная связность (commuication cohesion): Характеристика модуля, включающего функции, которые осуществляют выдачу выходных результатов другим функциям или используют выходные результаты от других функций.

(IEEE Std 610.12—1990]

Примечание 1 — См. также «связность» (3.2.3).

Примечание 2 — Примером коммуникационно-связанного модуля является модуль контроля доступа, который включает мандатный, дискреционный контроль и контроль полномочий.

3.2.6    сложность (complexity): Мера того, насколько трудным для понимания и. соответственно, для анализа, тестирования и поддержки является программное обеспечение.

(IEEE Std 610.12—1990]

Примечание — Уменьшение сложности является основной целью декомпозиции, распределения по уровням и минимизации модулей. Контроль сопряжения и связности значительно способствуют достижению этой цели.

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

6

ГОСТ Р ИСО/МЭК 15408-1—2012

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

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

3.2.7    связанность (coupling): Способ и степень взаимозависимости программных модулей.

(IEEE Std 610.12—1990]

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

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

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

3.2.9    связанность по вызову (по данным) (call coupling <data>): Взаимосвязь между двумя модулями. взаимодействующими строго через вызовы параметров, которые представляют собой отдельные элементы данных.

Примечание — См. также «связанность по вызову» (3.2.8).

3.2.10    связанность по вызову (по образцу) (call coupling <stamp>): Взаимосвязь между двумя модулями, взаимодействующими через вызовы параметров, которые включают в себя составные поля или имеют значительную внутреннюю структуру.

Примечание — См. также «связанность по вызову» (3.2.8).

3.2.11    связанность по вызову (по управлению) (call coupling <control>): Взаимосвязь между двумя модулями, когда один передает информацию, предназначенную для воздействия на внутреннюю логику другого.

Примечание — См. также «связанность по вызову» (3.2.8).

3.2.12    связанность по общей области (common coupling): Взаимосвязь между двумя модулями, разделяющими общую область данных или другой общий ресурс системы.

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

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

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

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

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

3.2.13    связанность по содержимому (content coupling): Взаимосвязь между двумя модулями, когда один модуль напрямую обращается к внутреннему содержанию другого модуля.

7

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

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

3.2.15    функциональная связность (functional cohesion); Функциональная характеристика модуля. который выполняет действия, связанные с одной единственной задачей.

(IEEE Std 610.12—1990)

Примечание — Функционально связный модуль преобразует единственный тип входных данных в единственный тип выходных данных, например модуль управления стеком или модуль управления очередью. См. также «связность» (3.2.3).

3.2.16    взаимодействие (interaction): Общие, основанные на коммуникации действия между сущностями.

3.2.17    интерфейс (interface): Средства взаимодействия с компонентом или модулем.

3.2.18    разделение на уровни (layering): Метод проектирования, при котором отдельные группы модулей (уровни) иерархически организованы таким образом, чтобы один уровень зависел только от уровней, которые ниже его в иерархии сервисов, и предоставлял свои сервисы только уровням, которые выше его в иерархии.

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

3.2.19    логическая связность (logical cohesion), процедурная связность (procedural cohesion): Характеристики модуля, выполняющего сходные виды действий по отношению к различным структурам данных.

Примечание 1 — Модуль демонстрирует логическую связность, если его функции выполняют связанные. но разные операции по отношению к разным входным данным.

Примечание 2 — См. также «связность» (3.2.3).

3.2.20    модульная декомпозиция (modular decomposition): Процесс разбиения системы на компоненты для упрощения проектирования, разработки и оценки.

[IEEE Std 610.12—1990)

3.2.21    невозможность обхода (ФБО) (non-bypassability <of TSF>): Свойство архитектуры безопасности. при котором все действия, связанные с ФТБ. производятся через ФБО.

3.2.22    домен безопасности (security domain): Набор ресурсов, по отношению к которым некоторая активная сущность имеет права на доступ.

3.2.23    последовательная связность (sequential cohesion): Характеристика модуля, который включает функции, выходные данные каждой из которых являются входными данными для последующей функции в этом модуле.

[IEEE Std 610.12—1990]

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

3.2.24    разработка программного обеспечения (software engineering): Применение систематического. упорядоченного, измеримого подхода к разработке и сопровождению программного обеспечения, т.е. применение методов разработки по отношению к программному обеспечению.

[IEEE Std 610.12—1990]

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

8

ГОСТ Р ИСО/МЭК 15408-1—2012

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

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

Примечание 1 — Адаптированный термин IEEE Std 610.12—1990.

Примечание 2 — Примерами модулей с временной связностью являются модули инициализации, восстановления и завершения работы.

3.2.26    собственная защита ФБО (TSF self-protection): Свойство архитектуры безопасности, при которой ФБО не могут быть нарушены не относящимися к ФБО кодом или сущностями.

3.3 Термины и определения, относящиеся к классу AGD

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

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

3.3.2    функционирование (эксплуатация) (operation): Стадия использования ОО. включающая «обычное использование», администрирование и поддержку (сопровождение) ОО после поставки и подготовки.

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

3.4 Термины и определения, относящиеся к классу ALC

3.4.1    критерии приемки (acceptance criteria): Критерии, применяемые при выполнении процедур приемки (например, успешная проверка документации или успешное тестирование в случае с программным, программно-аппаратным или аппаратным обеспечением).

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

Примечание — Эти процедуры идентифицируют роли пиц. ответственных за приемку, и критерии, применяемые для принятия решения о приемке.

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

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

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

c)    приемка после перемещения элементов конфигурации (например, частей ОО или «заготовок» продуктов) между различными местами разработки:

d)    приемка после поставки ОО потребителю.

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

Примечен и е — Адаптированный термин IEEE Std 610.12—1990.

3.4.4    документация УК (CM documentation): Вся документация УК. включая входные данные УК. список УК (список конфигурации), записи системы УК. план УК и документацию по применению УК.

9

3.4.5    свидетельство управления конфигурацией (configuration management evidence): Все, что может быть использовано для приобретения уверенности в правильности функционирования системы УК.

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

3.4.6    элемент конфигурации (configuration item): Объект, находящийся под управлением системы УК в течение разработки 00.

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

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

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

3.4.8    выходные данные управления конфигурацией (configuration management output): Результаты. связанные с управлением конфигурацией, созданные или обеспеченные системой управления конфигурацией.

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

3.4.9    план управления конфигурацией (configuration management plan): Описание порядка использования системы управления конфигурацией для конкретного ОО.

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

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

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

3.4.11    записи системы управления конфигурацией (configuration management system records): Выходные данные, создаваемые в процессе функционирования системы управления конфигурацией и документирующие важные виды деятельности по управлению конфигурацией.

10

ГОСТ Р ИСО/МЭК 15408-1—2012

Примечание — Примерами записей системы управления конфигурацией являются формы контроля изменений элементов конфигурации или формы санкционирования доступа к элементам конфигурации.

3.4.12    инструментальные сродства управления конфигурацией (configuration management tools): Управляемые вручную или автоматизированные инструментальные средства, реализующие или поддерживающие систему управления конфигурацией.

Примечание — Например, инструментальные средства управления версиями частей ОО.

3.4.13    документация по применению управления конфигурацией (configuration management usage documentation): Часть системы управления конфигурацией, в которой описаны способы определения и применения системы управления конфигурацией путем использования, например руководств, инструкций и/или документации инструментальных средств и процедур.

3.4.14    поставка (delivery): Передача завершенного ОО из производственной среды потребителю.

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

3.4.15    разработчик (developer): Организация, ответственная за разработку ОО.

3.4.16    разработка (development): Стадия жизненного цикла продукта, связанная с созданием представления реализации ОО.

Примечание — В требованиях класса ALC термин «разработка» и связанные с ним термины (разработчик. разрабатывать) понимаются в более широком смысле и охватывают разработку и производство.

3.4.17    инструментальные сродства разработки (development tools): Инструментальные средства (включая программные средства тестирования, если применимы), поддерживающие разработку и производство ОО.

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

3.4.18    представление реализации (implementation representation): Наименее абстрактное представление ФБО. а именно то. которое используется для создания собственно ФБО без дальнейшего уточнения проекта.

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

3.4.19    жизненный цикл (life-cycle): Последовательность стадий существования объекта (например. некоторого продукта или системы) во времени.

3.4.20    определение жизненного цикла (life-cycle definition): Определение модели жизненного цикла.

3.4.21    модель жизненного цикла (life-cycle model): Описание стадий (этапов) и их связей друг с другом, которые используются при управлении жизненным циклом определенного объекта, а также описание последовательности этих стадий (этапов) и их высокоуровневых характеристик

Примечание — См. также рисунок 1.

3.4.22    производство (production): Стадия жизненного цикла «производство» следует после стадии «разработка» и заключается в преобразовании представления реализации в реализацию конкретного ОО. т. е. в состояние, приемлемое для поставки потребителю.

Примечание 1 — Эта стадия может включать изготовление, интеграцию, генерацию, внутреннюю транспортировку, хранение и маркировку ОО.

Примечание 2 — См. также рисунок 1.

11

Рисунок 1 — Терминология, связанная с УК и жизненным циклом продукта


ГОСТ Р ИСО/МЭК 15408-1—2012


ГОСТ Р ИСО/МЭК 15408-1—2012

3.5 Термины и определения, относящиеся к классу AVA

3.5.1    скрытый канал (covert channel): Специально созданный несанкционированный канал передачи сигналов, который позволяет пользователю скрытно нарушать многоуровневую политику разграничения доступа и требования подконтрольности использования ОО.

3.5.2    обнаруженные потенциальные уязвимости (encountered potential vulnerabilities): Потенциально слабые места ОО. идентифицированные оценщиком при выполнении видов деятельности по оценке, которые могли бы быть использованы для нарушения ФТБ.

3.5.3    пригодная для использования уязвимость (exploitable vulnerability): Слабое место ОО, которое может быть использовано для нарушения ФТБ в среде функционирования ОО.

3.5.4    мониторинговые атаки (monitoring attacks): Характерная категория методов нападения, которая включает пассивные методы и средства анализа, направленные на раскрытие чувствительных внутренних данных ОО в условиях его функционирования в соответствии с руководствами.

3.5.5    потенциальная уязвимость (potential vulnerability): Предполагаемая, но не подтвержденная слабость ОО.

Примечание — Предположение основывают на теоретически допустимой схеме нападения для нарушения ФТБ.

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

3.5.7    уязвимость (vulnerability): Слабое место ОО. которое может быть использовано для нарушения ФТБ в некоторой среде.

3.6 Термины и определения, относящиеся к классу АСО

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

3.6.2    совместимые (компоненты) (compatible <components>): Свойство компонента, способного предоставлять сервисы, требуемые другим компонентом, через соответствующий интерфейс каждого компонента в согласованной среде функционирования.

3.6.3    00-компонент (component TOE): Успешно оцененный ОО. который является частью другого составного ОО.

3.6.4    составной ОО (composed TOE): ОО. состоящий из двух или более компонентов, которые были успешно оценены.

3.6.5    зависимый компонент (dependent component): Сущность в составном ОО. которая сама является предметом оценки, зависящая от предоставления сервисов базовым компонентом.

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

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

4 Сокращения

ВЧС (VPN) ГГц (GHz) ГИП (GUI) ДУД (DAC) ЗБ (ST) ИОК (PKI)

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

—    виртуальная частная сеть;

—    гигагерц;

—    графический интерфейс пользователя;

—    дискреционное управление доступом;

—    задание по безопасности;

—    инфраструктура открытых ключей;

11 Данные сокращения используются в одной или нескольких частях ИСО/МЭК 15408.

13

ГОСТ Р ИСО/МЭК 15408-1—2012

ИС (1C)

ИТ (IT)

ИФБО (TSFI) — IP

Мб (МВ)

00 (ТОЕ)

ОП (RAM) — ОПБ (SPD) — ОС (OS)

ОУД (EAL) -ПБОр (OSP) — ПЗ (РР)

ПК (PC)

ППИ (API) — ПФБ (SFP) — PCI    —

СоПД(САР) — ТДБ (SAR) -TCP    —

УВВ (IOCTL) — УВП (RPC) — УК (СМ)

ФБО (TSF) — ФТБ (SFR) —

интегральная схема:

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

интерфейс ФБО:

протокол Интернета:

мегабайт:

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

оперативная память;

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

операционная система:

оценочный уровень доверия;

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

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

персональный компьютер;

прикладной программный интерфейс;

(интерфейс PCI);

политика функции безопасности;

шина взаимодействия с периферийными компонентами

составной пакет доверия;

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

протокол управления передачей (протокол TCP);

управление вводом-выводом;

удаленный вызов процедуры;

управление конфигурацией;

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

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

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

5.1    Общая информация

В этом разделе представлены основные концептуальные положения ИСО/МЭК 15408. В нем определены понятие «00». категории пользователей ИСО/МЭК 15408. контекст оценки и принятый подход к дальнейшему представлению материала в ИСО/МЭК 15408.

5.2    Объект оценки

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

Таким образом, в контексте оценки в ИСО/МЭК 15408 используется термин «ОО» (объект оценки).

00 определяется как набор программных, программно-аппаратных и/или аппаратных средств, возможно сопровождаемых руководствами.

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

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

Примерами ОО являются.

-    прикладная программа;

-    операционная система;

-    прикладная программа в сочетании с операционной системой;

-    прикладная программа в сочетании с операционной системой и рабочей станцией;

-    операционная система в сочетании с рабочей станцией;

-    интегральная схема смарт-карты:

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

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

14

ГОСТ Р ИСО/МЭК 15408-1—2012

5.2.1    Различные представления 00

В ИСО/МЭК 15408 ОО может встречаться в нескольких представлениях, таких как (для программного ОО):

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

-    отдельная мастер-копия, которая была только что скомпилирована;

-    коробка, содержащая компакт-диск и руководства, готовая для поставки потребителю:

-    установленная и функционирующая версия.

Все из перечисленного считается ОО: где в дальнейшем в ИСО/МЭК 15408 используется термин «ОО», его конкретное представление определяется из контекста.

5.2.2    Различные конфигурации ОО

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

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

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

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

Если руководства ОО допускают более одной конфигурации, то все эти конфигурации вместе именуются «ОО», и каждая такая конфигурация должна удовлетворять требованиям, предъявляемым кОО.

5.3 Пользователи ИСО/МЭК 15408

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

5.3.1    Потребители

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

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

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

5.3.2    Разработчики

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

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

15

ГОСТ Р ИСО/МЭК 15408-1—2012

Содержание

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

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

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

3.1    Термины и определения, общие для всех частей ИСО/МЭК 15408.........................2

3.2    Термины и определения,    относящиеся к классу ADV....................................6

3.3    Термины и определения,    относящиеся к классу AGD....................................9

3.4    Термины и определения,    относящиеся    к классу ALC....................................9

3.5    Термины и определения,    относящиеся    к классу AVA....................................13

3.6    Термины и определения,    относящиеся    к классу АСО...................................13

4    Сокращения........................................................................13

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

5.1    Общая информация..............................................................14

5.2    Объект оценки...................................................................14

5.3    Пользователи ИСО/МЭК 15408.....................................................15

5.4    Части ИСО/МЭК 15408.............................. ’.....................16

5.5    Контекст оценки.................................................................17

6    Общая модель......................................................................17

6.1    Введение к общей модели.........................................................17

6.2    Активы и контрмеры..............................................................18

6.3    Оценка.........................................................................21

7    Доработка требований безопасности для конкретного применения...........................21

7.1    Операции............................................,..........................21

7.2    Зависимости между компонентами..................................................23

7.3    Расширенные компоненты.........................................................24

8    Профили защиты и пакеты ................................. 24

8.1    Введение.......................................................................24

8.2    Пакеты.........................................................................24

8.3    Профили защиты........................ 25

8.4    Использование ПЗ и пакетов.......... 26

8.5    Многократное использование профилей защиты......................................26

9    Результаты оценки................. 27

9.1    Введение.......................................................................27

9.2    Результаты оценки ПЗ............................................................28

9.3    Результаты оценки ЗБ/ОО.........................................................28

9.4    Утверждение о соответствии.......................................................28

9.5    Использование результатов оценки ЗБ/ОО...........................................29

Приложение А (справочное) Спецификация заданий по безопасности..........................30

Приложение В (справочное) Спецификация профилей защиты...............................41

Приложение С (справочное) Руководство по выполнению операций...........................45

Приложение D (справочное) Соответствие ПЗ..............................................47

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

ссылочным национальным стандартам Российской Федерации.................48

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

5.3.3    Оценщики

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

5.3.4    Прочие

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

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

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

c)    проектировщики систем безопасности, ответственные за характеристики безопасности продуктов ИТ;

d)    аттестующие, ответственные за приемку ИТ-решения в эксплуатацию в конкретной среде;

e)    заявители, заказывающие оценку и обеспечивающие ее проведение;

f)    органы оценки, ответственные за руководство и надзор за программами проведения оценок безопасности ИТ.

5.4    Части ИСО/МЭК 15408

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

a)    Часть 1 «Введение и общая модель» является введением в ИСО/МЭК 15408. В ней определяются общие понятия и принципы оценки безопасности ИТ и приводится общая модель оценки.

b)    Часть 2 «Функциональные компоненты безопасности» устанавливает совокупность функциональных компонентов, предназначенных для использования в качестве стандартных шаблонов, на основе которых следует устанавливать функциональные требования к ОО. ИСО/МЭК 15408-2 содержит каталог функциональных компонентов, систематизированных по семействам и классам.

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

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

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

Таблица 1— Использование частей ИСО/МЭК 15408 основными группами пользователей

Часть

ИСО/МЭК

15408

Потребители

Разработчики

Оценщики

1

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

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

Должны использовать в качестве справочного руководства и руководства по структуре профилей защиты и заданий по безопасности

Введение

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

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

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

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

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

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

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

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

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

c)    В ИСО/МЭК 15408 не рассматривается методология оценки, в рамках которой могут применяться конкретные критерии. Данная методология приведена в ИСО/МЭК 18045.

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

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

ГОСТ Р ИСО/МЭК 15408-1—2012

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

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

Терминология ИСО. такая как «может» (сап), «справочный» (informative), «должен» (shall) и «следует» (should), используемая в настоящем стандарте, определена в Директивах ИСО/МЭК. часть 2. У термина «следует» (should) имеется дополнительное значение, применимое при использовании настоящего стандарта. См. примечание ниже. Для использования в ИСО/МЭК 15408 дано следующее определение термина «следует» (should).

«следует» (should): В пределах нормативного текста «следует» (should) указывает, что «среди нескольких возможностей одна рекомендована в качестве наиболее подходящей, без упоминания или исключения других, или что определенный способ действия является предпочтительным, но не обязательно требуемым» (Директивы ИСО/МЭК. часть 2).

Примечание — ИСО/МЭК 15408 интерпретирует «не обязательно требуемый» для отражения того, что выбор другой возможности требует логического обоснования, почему не была выбрана предпочтительная возможность.

V

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

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

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

Часть 1

Введение и общая модель

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

Part 1. Introduction and general model

Дата введения — 2013—12—01

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р ИСО/МЭК 15408-1—2012

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

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

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

3.1    Термины и определения, общие для всех частей ИСО/МЭК 15408

3.1.1    негативные действия (adverse actions): Действия, выполняемые источником угрозы по отношению к активам.

3.1.2    активы (assets): Сущности, предположительно представляющие ценность для владельца ОО.

3.1.3    назначение (assignment): Спецификация определенного параметра в компоненте или требовании.

3.1.4    доверие (assurance): Основание для уверенности в том, что ОО отвечает конкретным ФТБ.

3.1.5    потенциал нападения (attack potential): Мера усилий, затрачиваемых при атаке на ОО. выраженная в показателях компетентности, ресурсов и мотивации нарушителя.

3.1.6    усиление (augmentation): Добавление одного или нескольких требований к пакету.

3.1.7    аутентификационные данные (authentication data): Информация, используемая для верификации предъявленного идентификатора пользователя.

3.1.8    уполномоченный пользователь (authorised user): Пользователь ОО. которому в соответствии с ФТБ разрешено выполнять некоторую операцию.

3.1.9    класс (class): Совокупность семейств, объединенных общим назначением.

3.1.10    четкий (coherent): Логически упорядоченный и имеющий понятное значение.

Примечание — В случае с документацией это относится как к имеющемуся тексту, так и к структуре документа в том смысле, понятен ли он его целевой аудитории.

3.1.11    полный (complete): Свойство, обеспеченное наличием всех необходимых частей некоторой сущности.

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

3.1.12    компонент (component): Наименьшая выбираемая совокупность элементов, на которой могут основываться требования.

3.1.13    составной пакет доверия (composed assurance package): Пакет доверия, представляющий некоторое положение на предопределенной составной шкале доверия.

3.1.14    подтвердить (confirm): Декларировать, что что-то детально проверено с независимым определением достаточности.

Примечание — Требуемый уровень строгости зависит от типа рассматриваемого предмета. Данный термин применим только к действиям оценщика.

3.1.15    внешняя связность (connectivity): Свойство ОО. позволяющее ему взаимодействовать с сущностями ИТ. внешними по отношению к ОО.

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

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

3.1.17    противостоять (counter): Характеризует противостояние некоторому нападению, при котором негативные последствия реализации некоторой конкретной угрозы уменьшаются, но не обязательно полностью ликвидируются.

3.1.18    демонстрируемое соответствие (demonstrable conformance): Связь между ЗБ и ПЗ, при которой ЗБ обеспечивает решение общей проблемы безопасности, определенной в ПЗ.

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

2

ГОСТ Р ИСО/МЭК 15408-1—2012

3.1.19    демонстрировать (demonstrate): Предоставить заключение, полученное в процессе анализа. который является менее строгим, чем «доказательство» («proof»).

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

3.1.21    описывать (describe): Представить конкретные подробности о некоторой сущности.

3.1.22    делать заключение (determine): Подтвердить некоторое заключение, основанное на независимом анализе для достижения этого заключения.

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

3.1.23    среда разработки (development environment): Среда, в которой осуществляется разработка ОО.

3.1.24    элемент (element): Неделимое изложение некоторой потребности в безопасности.

3.1.25    обеспечивать (ensure): Гарантировать сильную причинно-следственную связь между некоторым действием и его последствиями.

Примечание — Когда этому термину предшествует термин «способствовать», то это указывает, что одно данное действие не полностью определяет последствия.

3.1.26    оценка (evaluation): Оценивание ПЗ. ЗБ или ОО по определенным критериям.

3.1.27    оценочный уровень доверия (evaluation assurance level): Набор требований доверия, представляющий некоторое положение на предопределенной шкале доверия и составляющий пакет доверия.

3.1.28    орган оценки (evaluation authority): Организация, устанавливающая стандарты и контролирующая качество оценок, проводимых организациями в пределах определенного сообщества, и обеспечивающая реализацию ИСО/МЭК 15408 для данного сообщества посредством системы оценки.

3.1.29    система оценки (evaluation scheme): Административно-правовая структура, в рамках которой в определенном сообществе органы оценки применяют ИСО/МЭК 15408.

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

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

3.1.31    объяснять (explain): Предоставить аргументы, содержащие основания для выбора хода предпринимаемых действий.

Примечание — Данный термин отличается от терминов «описывать» («describe») и «демонстрировать* («demonstrate»). Предназначен для ответа на вопрос «Почему?» без попытки аргументировать, что ход предпринимаемых действий обязательно оптимален.

3.1.32    расширение (extension): Добавление в ЗБ или ПЗ функциональных требований, не содержащихся в ИСО/МЭК 15408-2. и/или требований доверия, не содержащихся в ИСО/МЭК 15408-3.

3.1.33    внешняя сущность (external entity): Человек или ИТ-сущность. взаимодействующие с ОО из-за пределов границ ОО.

Примечание — В качестве внешней сущности может также рассматриваться пользователь ОО.

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

3.1.35    формальный (formal): Выраженный на языке с ограниченным синтаксисом и определенной семантикой, основанной на установившихся математических понятиях.

3.1.36    документация руководств (guidance documentation): Документация, описывающая поставку. установку, конфигурирование, эксплуатацию, управление и/или использование ОО.

3.1.37    идентификатор (identity): Представление, однозначно идентифицирующее сущность (например. пользователя, процесс или диск) в контексте конкретного ОО.

3

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

3.1.38    неформальный (informal): Выраженный на естественном языке.

3.1.39    передача между ФБО (inter TSF transfers): Передача данных между ОО и функциональными возможностями безопасности других доверенных продуктов ИТ.

3.1.40    внутренний канал связи (internal communication channel): Канал связи между разделенными частями ОО.

3.1.41    передача в пределах ОО (internal TOE transfer): Передача данных между разделенными частями ОО.

3.1.42    внутренне непротиворечивый (internally consistent): Характеризует отсутствие очевидных противоречий между любыми аспектами сущности.

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

3.1.43    иторация (iteration): Использование компонента для выражения двух или более отдельных требований.

3.1.44    логическое обоснование (justification): Анализ, приводящий к получению заключения.

Примечание — Термин «логическое обоснование» является более строгим, чем термин «демонстрация». Этот термин требует точных и подробных обьяснений каждого шага логических суждений.

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

3.1.46    операция (над компонентом) (operation): Модификация или повторное ислогъэоеание компонента.

Примечание — Разрешенными операциями над компонентами являются назначение, итерация, уточнение и выбор.

3.1.47    операция (над объектом) (operation): Определенный тип действия, выполняемого субъектом по отношению к объекту.

3.1.48    среда функционирования (operation environment): Среда, в которой функционирует ОО.

3.1.49    политика безопасности организации (organisational security policies): Совокупность правил. процедур или руководящих принципов в области безопасности для некоторой организации.

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

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

Примечание — Примером пакета может служить «ОУДЗ».

3.1.51    оценка профиля защиты (protection profile evaluation): Оценивание ПЗ по определенным критериям.

3.1.52    профиль защиты (protection profile): Независимое от реализации изложение потребностей в безопасности для некоторого типа ОО.

3.1.53    доказывать (prove): Демонстрировать соответствие посредством формального анализа в математическом смысле.

Примечание — Доказательство должно быть полностью строгим во всех отношениях. Обычно термин «доказывать» используют, когда необходимо показать соответствие между двумя представлениями ФБО на высоком уровне строгости.

3.1.54    уточнение (refinement): Добавление деталей в компонент.

3.1.55    роль (role): Предопределенная совокупность правил, устанавливающих допустимое взаимодействие между пользователем и ОО.

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

3.1.57    безопасное состояние (secure state): Состояние, при котором данные ФБО являются непротиворечивыми и ФБО продолжают корректно реализовывать ФТБ.

3.1.58    атрибут безопасности (security attribute): Характеристика субъектов, пользователей (включая внешние продукты ИТ), объектов, информации, сеансов и/или ресурсов, которые используются при определении ФТБ. и значения которых используются при осуществлении ФТБ.

4

ГОСТ Р ИСО/МЭК 15408-1—2012

3.1.59    политика функции безопасности (security function policy): Совокупность правил, описывающих конкретный режим безопасности, реализуемый ФБО. и выраженных в виде совокупности ФТБ.

3.1.60    цель безопасности (security objective): Изложенное намерение противостоять установленным угрозам и/или удовлетворять установленной политике безопасности организации и/или предположениям.

3.1.61    проблема безопасности (security problem): Изложение, которое в формализованном виде определяет характер и масштабы безопасности, которую должен обеспечивать ОО.

Примечание — Данное изложение содержит сочетание:

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

-    ПБОр. осуществляемых ОО. и

-    предположений, которые определены для ОО и его среды функционирования.

3.1.62    требование безопасности (security requirement): Требование, изложенное на стандартизованном языке и направленное на достижение целей безопасности для ОО.

3.1.63    задание по безопасности (security target): Зависимое от реализации изложение потребностей в безопасности для конкретного идентифицированного ОО.

3.1.64    выбор (selection): Выделение одного или нескольких пунктов из перечня в компоненте.

3.1.65    полуформальный (semiformal): Выраженный на языке с ограниченным синтаксисом и определенной семантикой.

3.1.66    специфицировать (specify): Предоставить конкретные подробности о некоторой сущности в строгой и точной форме.

3.1.67    строгое соответствие (strict conformance): Иерархическая связь между ПЗ и ЗБ. когда все требования из ПЗ также присутствуют в ЗБ.

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

3.1.68    оценка задания по безопасности (security target evaluation): Оценивание ЗБ по определенным критериям.

3.1.69    субъект (subject): Активная сущность в ОО. выполняющая операции над объектами.

3.1.70    объект оценки (target of evaluation): Совокупность программного, программно-аппаратного и/или аппаратного обеспечения, возможно сопровождаемая руководствами.

3.1.71    источник угрозы (threat agent): Сущность, которая негативно воздействует на активы.

3.1.72    оценка ОО (TOE evaluation): Оценивание ОО по определенным критериям.

3.1.73    ресурс ОО (TOE resource): Все. что может быть использовано или потреблено ОО.

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

3.1.75    прослеживать или сопоставлять (trace): Выполнять неформальный анализ соответствия между двумя сущностями с минимальным уровнем строгости.

3.1.76    передача за пределы ОО (transfers outside TOE): Опосредованная ФБО передача данных сущностям, не контролируемым ФБО.

3.1.77    трансляция (translation): Описание процесса изложения требований безопасности на стандартизованном языке.

Примечание — Использование термина «трансляция* не является буквальным и не подразумевает, что каждое ФТБ. выраженное на стандартизованном языке, может быть также обратно транслировано к целям безопасности.

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

3.1.79    доверенный продукт ИТ (trusted IT product): Продукт ИТ. отличный от ОО, для которого имеются свои функциональные требования, организационно скоординированные с ОО. и который, как предполагается, реализует свои функциональные требования корректно.

Примечание — Примером доверенного продукта ИТ является продукт, который был отдельно оценен.

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

5