You are on page 1of 56

Проект национального российского стандарта,

сделанный на основе перевода


международного стандарта ISO / IEC 15408-1:2009

Информационные технологии —
Техника безопасности —
Критерии оценки безопасности
информационных технологий

Часть 1:
Введение и общая модель
НАПРАВЛЕНИЯ
ДЕЯТЕЛЬНОСТИ

КОНГРЕССЫ CIO-КЛУБОВ

РЕКОМЕНДАЦИИ

КАТАЛОГ ИТ-РЕШЕНИЙ CIO

ЭКСПЕРТИЗЫ ПРОЕКТОВ

ПОРТАЛ GLOBALCIO

ПЕРЕВОД СТАНДАРТОВ ISO


ISO / IEC 15408-1:2009

Уважаемые друзья и коллеги!


Мы рады, что нам выпала честь написать аннотацию к уже второму, пере-
веденному Российским Союзом ИТ-директоров стандарту. И вдвойне приятно,
что это стандарт по безопасности.
Сегодня мы представляем Вам Международный стандарт ISO / IEC 15408.
«Информационные технологии. Техника безопасности. Критерии оценки безо-
пасности ИТ».
Несколько слов о том, что такое стандарт и зачем нам нужны стандарты. В на-
шей повседневной работе стандарты являются не просто сводом придуманных
кем-то правил, для нас это формализованная методология, которая позволяет
быстро выстраивать работу в том или ином функциональном блоке компании. C
другой стороны, каким образом мы можем подтвердить, что мы умеем управлять
автомашиной? — Показать права на вождение. Каким образом компания — про-
изводитель может подтвердить, что ее продукт высокого качества? — Показать
соответствующий сертификат. Так же и в случае с нашим стандартом, чтобы
подтвердить, что программно-аппаратный комплекс безопасен с точки зрения
противостояния угрозам безопасности, необходимо выполнить требования стан-
дарта и предъявить соответствующий сертификат.
Вообще, в своей практике мы используем много стандартов из самых раз-
ных областей, но при этом до получения сертификата доходит далеко не всег-
да. Дело в том, что стандарты есть, требования их выполняются, но для внут-
реннего подтверждения нет необходимости получать сертификат. Чем удобен
стандарт? — Если мы не знаем, что и как делать, то обращаемся к соответс-
твующему стандарту. Чего и Вам желаем.
В конце прошлого века в нашу повседневную жизнь вошли современные ин-
формационные технологии, уровень доступности которых впечатляет. Скорость
развития информационных технологий несравнима ни с одной из существую-
щих отраслей Вместе с тем, новые технологии создают новые риски. В эпоху
построения информационного общества доля услуг в области информационных
технологий (включая внутренние услуги на самих предприятиях) возрастает и
начинает играть существенную роль не только в определении стратегических
целей, но и в благополучии самих компаний. Ценность информации, хранящейся
и передаваемой в электронном виде, становится сопоставимой со стоимостью
самих услуг, оказываемых организациями своим клиентам. В этой связи задачи,
стоящие в области информационной безопасности, все более и более становят-
ся задачами безопасности всей деятельности как коммерческих, так и государс-

1
ISO / IEC 15408-1:2009

твенных организаций. Наверное, именно этот факт послужил толчком к тому, что
мы выбрали стандарт именно из области безопасности информационных техно-
логий. Мы надеемся, что Вам этот стандарт поможет оценить уровень безопас-
ности своих информационных систем и производить и приобретать программно-
аппаратные комплексы с необходимым бизнесу уровнем безопасности.
Несколько слов, о чем этот стандарт. Стандарт ISO/IEC 15408 дает уникаль-
ную возможность самостоятельно выполнить процедуру оценки ИТ-продукта на
уровень безопасности примененных информационных технологий. Он предо-
ставляет Вам общий набор требований к безопасному функционированию про-
дуктов ИТ и к обеспечению гарантирующих мер, принятых к этим продуктам. Ре-
зультаты оценки уровня безопасности могут помочь потребителям определить,
удовлетворяют ли эти продукты ИТ их потребности. ISO/IEC 15408 полезен и как
руководство по разработке, развитию, оценке и/или поставке продуктов ИТ с
требуемым уровнем функциональной безопасности. Сам стандарт намеренно
сделан гибким, что дает возможность применять целый ряд методов оценки к
большому спектру параметров безопасности продуктов ИТ.
Для кого этот стандарт? Как указано в самом стандарте, заинтересован-
ными в оценке характеристик безопасности являются три основные группы:
потребители (пользователи), разработчики (производители) и те, кто проводит
непосредственно оценку (эксперты).
Настоящий стандарт состоит из трех основных разделов, объединенных об-
щим названием «Информационные Технологии. Техника безопасности. Крите-
рии оценки безопасности ИТ»:
• Часть 1: «Введение и общая модель».
• Часть 2: «Функциональные компоненты безопасности».
• Часть 3: «Компоненты гарантии безопасности».
Что получают владельцы ресурсов? После того, как оценка безопасности
информационных технологий была проведена, владельцы активов могу иметь
гарантии в том, что оцениваемый объект и его операционная среда противо-
стоят угрозам. Владелец активов может использовать эти результаты оценки
для того, чтобы решить, можно ли пойти на риск воздействия угрожающих
факторов на свои ресурсы или нет.
В заключение хочется отметить, что весь коллектив СоДИТ, работающий
в проекте Стандартов, делает эту работу для Вас и надеется, что Вам будет
полезен данный стандарт. Стандарты не панацея, но они могут во многом по-
мочь. Мы уверены, что данный стандарт послужит хорошей основой для приме-
нения и использования безопасных информационных технологий.

Юрий Шойдин – Член правления СоДИТ,


со-председатель комитета по ИБ СоДИТ

Виктор Минин – Член правления СоДИТ,


со-председатель комитета по ИБ СоДИТ

2
ISO / IEC 15408-1:2009

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


Если вы работаете в сфере информационной безопасности, то, скорее все-
го, вам приходилось сталкиваться с определенными ИБ-стандартами. Под ни-
ми обычно подразумеваются документы организаций ISO (Международная
организация по стандартизации) и IEC (Международная электротехническая
комиссия). Многие страны адаптируют данные стандарты под требования на-
ционального законодательства, нормотворчества и другие государственные и
социальные аспекты.
Инициированный российским Союзом ИТ-директоров (СоДИТ) проект ло-
кализации международных стандартов потенциально может стать отличным
стимулом для развития в России конкурентоспособных технологий, положив
начало применению единых стандартов всеми отечественными компаниями.
Понимая чрезвычайную важность этой задачи, «Лаборатория Касперского»
с энтузиазмом подключилась к процессу локализации, инвестировав проект
перевода международного стандарта ISO / IEC 15408: 2008 «Информационные
технологии. Методы обеспечения безопасности. Критерии оценки ИТ-безопас-
ности». Этот стандарт был выбран ради получения вполне конкретных, прак-
тических преимуществ, которые смогут получить компании от его внедрения.
Положения ISO / IEC 15408 предлагают рекомендации по безопасному функци-
онированию информационных систем, а также по объективной оценке уровня
текущей безопасности.
Не секрет, что актуальность проблемы защиты информации растет с каж-
дым днем — именно поэтому мы надеемся на повсеместное внедрение стан-
дарта ISO / IEC 15408. Как яркий представитель IT-индустрии и один из членов
СоДИТ, «Лаборатория Касперского» своим авторитетом готова продвигать
идею важности применения международных стандартов отечественными ком-
паниями.
Также хотелось бы напомнить, что информационная безопасность предпри-
ятий определяется не только соблюдением международных стандартов, но и
использованием надежного, сертифицированного государством программного
обеспечения. «Лаборатория Касперского», как один из ключевых, признанных
во всем мире производителей комплексных антивирусных продуктов, готова
предоставить заказчикам гарантии сохранности информации и надежную за-
щиту корпоративных сетей.
Резюмируя, могу сказать, что проект локализации стандартов — дело хло-
потное, но необходимое. И помогать этому процессу нужно, по возможности,
всем IT-миром.
Сергей Земков,
управляющий директор «Лаборатории Касперского»
в России и странах Закавказья

3
ISO / IEC 15408-1:2009

Результат более чем 20-летнего развития


Представляемый вашему вниманию стандарт имеет длинную историю раз-
вития. Еще начиная с 70-х годов службами безопасности США делались ис-
следования в области формальных методов оценки безопасности, связанной
с использованием ИТ. Позднее, в 90-х, эта деятельность привела к разработке
набора критериев TCSEC (Trusted Computer System Evaluation Criteria), более из-
вестного как «Оранжевая книга», а также «Федеральных критериев безопаснос-
ти информационных технологий». Аналогичные критерии были разработаны и в
других странах: «Гармонизированные критерии европейских стран» (Information
Technology Security Evaluation Criteria), «Канадские критерии оценки безопасности
компьютерных продуктов» и т. д.
Понимая, что национальные критерии будут препятствовать широкому рас-
пространению продуктов в области ИТ-безопасности, в 1990 году под эгидой ISO
были начаты работы по унификации национальных стандартов. В 1993 году ор-
ганизации США, Канады, Великобритании, Франции, Германии и Нидерландов
[Национальный институт стандартов и технологии, Агентство национальной бе-
зопасности (США), Учреждение безопасности коммуникаций (Канада), Агентство
информационной безопасности (Германия), Агентство национальной безопаснос-
ти коммуникаций (Нидерланды), Органы исполнения Программы безопасности
и сертификации ИТ (Великобритания), Центр обеспечения безопасности систем
(Франция) ], объединили свои усилия в рамках проекта, получившего название
«Общие критерии оценки безопасности информационных технологий» (Common
Criteria for Information Technology Security Evaluation).
Разработка версии 1.0 «Общих критериев…» была завершена в январе
1996 года и одобрена международной организацией по стандартизации (ISO) уже
в апреле 1996 года. Появление международного стандарта явилось новым эта-
пом в развитии нормативной базы оценки информационной безопасности. Но-
вые критерии обеспечили взаимное признание результатов стандартизованной
оценки безопасности на мировом рынке ИТ. «Общие критерии…» обобщили со-
держание и опыт использования «Оранжевой книги», развили оценочные уровни
доверия «Европейских критериев…», воплотили в реальные структуры концеп-
цию типовых профилей защиты «Федеральных критериев…». В «Общих критери-
ях…» проведена классификация широкого набора функциональных требований
и требований доверия к безопасности, определены способы их группирования и
принципы использования.
В мае 1998 года была опубликована версия 2.0 «Общих критериев…» и на ее
основе в июне 1999 года был принят международный стандарт ISO/IEC 15408:1999
(Information technology — Security techniques — Evaluation criteria for IT security).
Практически одновременно с «Общими критериями…» разрабатывались вер-
сии «Общей методологии оценки безопасности информационных технологий».
В августе 1999 года опубликована версия 1.0 «Общей методологии оценки..»
(часть 2) для оценочных уровней доверия (ОУД) 1-4. В январе 2004 году опубли-
кованы версии 2.2, а в августе 2005 г. версии 2.3 «Общих критериев…» и «Общей
методологии оценки..». Именно они легли в основу стандартов ISO/IEC 15408:2005
и ISO/IEC 18045:2005 (Information technology — Security techniques — Methodology
for IT security evaluation) соответственно.
В июле 2005 года опубликованы новые версии 3.0 «Общих критериев…» и «Об-
щей методологии оценки..», в которых предыдущие версии подверглись сущест-
венной ревизии. Однако, как показало обсуждение этих версий в международном
сообществе, далеко не все предложенные авторами изменения были целесооб-

4
ISO / IEC 15408-1:2009

разны и корректны. В результате, в сентябре 2006 года появились версии 3.1 «Об-
щих критериев…» и «Общей методологии оценки..», которые и были признаны
официальными версиями. Именно эти версии, с определенными доработками,
легли в основу уже третьей и на данный момент последней, версии стандарта
ISO/IEC 15408, части которого вышли в 2008 и 2009 годах.
Надо сказать, что Россия достаточно сильно отставала от этого движения.
Только в 2002 постановлением Госстандарта России году был принят ГОСТ Р
15408:2002, содержащий полный аутентичный текст международного стандарта
ISO/IEC 15408:1999 (введен в действие с 1 января 2004 года). Вскоре была приня-
та вторая редакция стандарта — ГОСТ Р 15408:2008, содержащая полный текст
международного стандарта ISO/IEC 15408:2005. Однако, как уже было сказано, с
2005 по 2008 годы международный стандарт подвергся серьезным переработкам,
и поэтому возникла настоятельная необходимость в переводе его новой версии.
Именно эту работу и выполнила группа экспертов СОДИТ.
Главная тенденция, которая прослеживается на протяжении целого ряда стан-
дартов в области информационной безопасности — отказ от жесткой универ-
сальной шкалы классов безопасности и обеспечение гибкости в подходе к оценке
безопасности различных типов ИТ-продуктов. Именно это стремление объясняет
столь сложную на первый взгляд логическую структуру стандарта ISO/IEC 15408.
Если говорить кратко, то принципиальные черты стандарта следующие:
1. Четкое разделение требований безопасности на функциональные требо-
вания и требования доверия к безопасности. Функциональные требования
относятся к функциям безопасности (идентификация, аутентификация, уп-
равление доступом, аудит и т. д.), а требования доверия — к технологии раз-
работки, тестированию, анализу уязвимостей, поставке, сопровождению,
эксплуатационной документации, то есть ко всем этапам жизненного цикла
изделий информационных технологий.
2. Систематизация и классификация требований к безопасности в рамках ие-
рархии «класс» — «семейство» — «компонент» — «элемент».
3. Ранжирование компонентов требований в семействах и классах по степени
полноты и жесткости, а также их группирование в пакеты функциональных
требований и Уровни Оценки Доверия.
4. Гибкость и динамизм в подходе к заданию требований безопасности для
различных типов изделий информационных технологий и условий их приме-
нения, обеспечиваемые путем целенаправленного формирования необходи-
мых наборов требований в виде определенных структур (Профилей Защиты
и Целевых Уровней Безопасности).
В предлагаемом вашему вниманию переводе ISO/IEC 15408-1:2009 мы поста-
рались в полной мере учесть нововведения стандарта, что привело к необходи-
мости введения новых терминов и понятий, а также изменению трактовки ста-
рых терминов. Из наиболее значительных, по сравнению с действующим ГОСТ Р
15408:2008, изменений следует отметить:
Security Target — в настоящем проекте перевода называется «Целевой уро-
вень безопасности» (в ГОСТ Р 15408:2008 — «Задание по безопасности»);
Evaluation Assurance Level — в настоящем проекте перевода называется
«Уровень оценки доверия» (в ГОСТ Р 15408:2008 — «Оценочный уровень
доверия»).
Понимание методологии является залогом эффективного использования того
огромного фактического материала по требованиям безопасности ИТ, порядку их
задания и оценке, который содержится в данном стандарте.
От редактора

5
ISO / IEC 15408-1:2009

Содержание
Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1 Область применения . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Нормативные документы. . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Термины и определения . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Термины и определения, принятые в ISO / IEC 15408 . . . . . . . . . .11
3.2 Термины и определения, относящиеся к классу ADV . . . . . . . . .17
3.3 Термины и определения, относящиеся к классу AGD . . . . . . . . .21
3.4 Термины и определения, относящиеся к классу ALC. . . . . . . . . .21
3.5 Термины и определения, относящиеся к классу AVA . . . . . . . . . .26
3.6 Термины и определения, относящиеся к классу ACO . . . . . . . . .26
4 Сокращения терминов . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Общий обзор . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Общие положения. . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
5.2 Объект Оценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
5.3 Целевая аудитория ISO / IEC 15408 . . . . . . . . . . . . . . . . . . . .29
5.4 Различные части ISO / IEC 15408 . . . . . . . . . . . . . . . . . . . . .31
5.5 Контекст оценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
6 Общая модель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1 Введение к общей модели . . . . . . . . . . . . . . . . . . . . . . . .32
6.2 Активы и меры противодействия . . . . . . . . . . . . . . . . . . . .33
6.3 Оценка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
7 Составление требований безопасности . . . . . . . . . . . . . . . . . 38
7.1 Операции . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
7.2 Зависимости между компонентами . . . . . . . . . . . . . . . . . . .41
7.3 Расширенные компоненты . . . . . . . . . . . . . . . . . . . . . . . .41
8 Профили защиты и пакеты. . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1 Введение. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
8.2 Пакеты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
8.3 Профили защиты . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
8.4 Использование профилей защиты и пакетов . . . . . . . . . . . . . .46
8.5 Использование составных профилей защиты . . . . . . . . . . . . .46
9 Результаты оценки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.1 Введение. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
9.2 Результаты оценки профилей защиты. . . . . . . . . . . . . . . . . .48
9.3 Результаты оценки целевых уровней безопасности
и объектов оценки. . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
9.4 Декларация о соответствии . . . . . . . . . . . . . . . . . . . . . . .48
9.5 Использование результатов оценки целевых
уровней безопасности и объектов оценки. . . . . . . . . . . . . . . .50
Список литературы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6
ISO / IEC 15408-1:2009

Предисловие
Международная организация по стандартизации (International Organization
for Standardization, ISO) и Международная электротехническая комиссия
(International Electrotechnical Commission, IEC)) формируют специализирован-
ную систему международных стандартов. Национальные организации члены
ISO или IEC, участвуют в разработке международных стандартов, используя
технические комитеты, созданные для работы в определенных областях тех-
нической деятельности. Технические комитеты ISO и IEC сотрудничают в тех
областях, где их интересы пересекаются. Также участие в работе принимают
другие международные организации, как государственные, так и негосударс-
твенные. Для работы в области информационных технологий ISO и IEC основа-
ли объединенный технический комитет ISO / IEC JTC 1.
Международные стандарты создаются в соответствии с правилами, изложен-
ными в части 2 Директив ISO / IEC. Основная задача объединенного техническо-
го комитета состоит в подготовке Международных стандартов. Для голосования
проекты Международных стандартов, принятых объединенным техническим ко-
митетом, передаются в национальные организации. Документ будет принят как
Международный стандарт, если он одобрен не менее чем 75 % национальных
организаций, участвующих в голосовании. Следует обратить внимание на то,
что некоторые части стандарта ISO / IEC 15408 могут быть предметом патент-
ных прав. ISO и IEC не несут ответственности при установлении каких-либо или
всех таких патентных прав. ISO / IEC 15408-1 подготовлен подкомитетом SC 27
«Методы и средства безопасности ИТ» (IT Security techniques) объединенного
технического комитета ISO / IEC JTC 1 «Информационные технологии». Текст
ISO / IEC 15408 публикуется спонсорскими организациями проекта как «Общие
критерии оценки безопасности информационных технологий» (Common Criteria
for Information Тechnology Security Evaluation). Общий источник для этих пуб-
ликаций можно найти по адресу http://www.oc.ccn.cni.es / xml (в формате xml).
Это третье издание отменяет и заменяет второе издание стандарта — ISO / IEC
15408-1:2005, которое подверглось технической переработке.
ISO / IEC 15408 состоит из трех частей, объединенных общим названием «Ин-
формационные Технологии — Техника безопасности — Критерии оценки безо-
пасности информационных технологий»:
• Часть 1: Введение и общая модель.
• Часть 2: Функциональные компоненты безопасности.
• Часть 3: Компоненты доверия к безопасности.

7
ISO / IEC 15408-1:2009

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

8
ISO / IEC 15408-1:2009

а) Стандарт ISO / IEC 15408 не содержит критерии оценки безопасности,


относящиеся к административным мерам безопасности, не связанным
непосредственно с ИТ-безопасностью. Тем не менее, признано, что зна-
чительной степени требуемого уровня безопасности можно достичь ад-
министративными мерами, например, организационными, кадровыми,
физическими и процедурными.
b) Оценка физических аспектов безопасности ИТ, таких, например, как
контроль электромагнитных излучений, в стандарте целенаправленно не
затрагивается, хотя многие приводимые концепции вполне применимы к
этой области.
c) Стандарт ISO / IEC 15408 не рассматривает методологию оценки, в рамках
которой следует применять упомянутые критерии. Эта методология изло-
жена в стандарте ISO / IEC 18045.
d) Положения стандарта ISO / IEC 15408 не предназначены для администра-
тивных и правовых структур. Однако предполагается, что ISO / IEC 15408
будет применяться для проведения оценок в контексте таких структур.
e) Процедуры использования результатов оценки при аттестации, лежат вне
рамок ISO / IEC 15408. Аттестация ИТ-продукта — это административный
процесс, в соответствии с которым оценивающий орган получает опреде-
ленный уровень доверия к безопасности во время эксплуатации ИТ-про-
дукта (либо нескольких) в полностью операционной среде, включающей
также все части, не относящиеся к ИТ. Результаты процесса оценки бе-
зопасности — это один из элементов процесса аттестации. Тем не менее,
поскольку для оценки не относящихся к ИТ характеристик безопасности
продукта, а также их связи с аспектами ИТ-безопасности больше подхо-
дят другие технологии, органы занимающиеся аттестацией должны пре-
дусмотреть для них отдельные подходы.
f) Критерии оценки специфических качеств криптографических алгоритмов
стандартом ISO / IEC 15408 не охвачены. В том случае, когда потребуется
провести оценку математических свойств криптографии, необходима от-
дельная процедура. Схема проведения оценки ИТ-безопасности, в рамках
которой применяется ISO / IEC 15408, должна обеспечивать такую оценку.

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


как: «мочь», «информативный», «можно» «нормативный», «будет» и «следу-
ет», даны в Директивах ISO / IEC, Часть 2. Нужно отметить, что при использова-
нии данного международного стандарта, термину «следует» придается допол-
нительное значение.
Примечание: При использовании термина «следует» в стандарте ISO / IEC
15408 предполагается, что он указывает на то, что из ряда возможностей
одна рекомендуется как особенно подходящая, при этом другие не упо-
минаются, но и не исключаются, либо что определенный образ действий
предпочтителен, но не требуется в обязательном порядке (см. ISO / IEC Ди-
рективы, Часть 2 / Directives, Part 2). При этом ISO / IEC 15408 интерпретирует
выражение «не требуется в обязательном порядке» в том смысле, что выбор
иной возможности требует обоснования, почему предпочтительный вариант
всё же не был выбран.

9
ISO / IEC 15408-1:2009

Информационные технологии — Технологии


безопасности — Критерии оценки
безопасности информационных технологий
Часть 1: ВВЕДЕНИЕ И ОБЩАЯ МОДЕЛЬ
1 Область применения
В целом стандарт ISO / IEC 15408 задуман как основа для оценки показателей
безопасности ИТ_систем и продуктов. В данной части стандарта ISO / IEC 15408
устанавливаются общие концепции и принципы оценки безопасности ИТ и оп-
ределяется общая модель оценки, используемая различными частями стан-
дарта. Часть 1 дает обзор всех остальных частей стандарта ISO / IEC 15408.
Она описывает различные части стандарта, дает определения терминов и со-
кращений, используемых во всех документах стандарта, определяет основную
концепцию объекта оценки (ОО), а также контекст оценки и приводит описание
аудитории, которой адресованы критерии оценки. Также дается введение в ос-
новные концепции безопасности необходимые для оценки ИТ_систем.
В части 1 также определяются различные операции, посредством которых
компоненты функций безопасности и доверия к безопасности, приведенные в
частях стандарта ISO / IEC 15408_2 и ISO / IEC 15408_3, могут быть привязаны
к конкретным потребностям. В этом документе определяются ключевые кон-
цепции профилей защиты (ПЗ), пакетов требований по безопасности и вопрос
соответствия заданным требованиям, а также описываются следствия резуль-
татов оценки. Эта часть ISO / IEC 15408 содержит указания по спецификации
Целевых Уровней Безопасности (ЦУБ) и описание организации компонент (бе-
зопасности) в рамках всей модели. Общая информация по методологии оцен-
ки, а также обзор схем оценки даны в стандарте ISO / IEC 18405.

2 Нормативные документы
Для практического применения части 1 ISO / IEC 15408 обязательно использо-
вание следующих документов:
• ISO / IEC 15408-2, Информационная технология — Техника безопасности —
Критерии оценки безопасности ИТ — Часть 2: Функциональные компонен-
ты безопасности
• ISO / IEC 15408-3, Информационная технология — Техника безопаснос-
ти — Критерии оценки безопасности ИТ — Часть 3: Компоненты доверия
к безопасности
• ISO / IEC 18045, Информационная технология — Техника безопасности —
Методика оценки безопасности ИТ.

3 Термины и определения
Для достижения цели и решения задач данного документа используются сле-
дующие термины и определения.
Примечание: Этот раздел содержит только специфические термины, исполь-
зуемые в тексте ISO / IEC 15408. Некоторые комбинации общих терминов не
столь существенны для включения в этот список и для большей ясности объ-
ясняются непосредственно в тексте стандарта по мере их использования.

10
ISO / IEC 15408-1:2009

3.1 Термины и определения, принятые в ISO / IEC 15408


3.1.1 Негативные действия (adverse actions) — враждебные / вредоносные
действия производимые носителем угрозы по отношению к каким_либо
активам, либо их полезным свойствам.
3.1.2 Активы (assets) — сущности (целостные элементы предметной области),
предположительно представляющие ценность для владельца объекта
оценки.
3.1.3 Назначение (assignment) — спецификация определенного параметра в
компоненте (ISO / IEC 15408) или требовании.
3.1.4 Доверие (assurance) — основание для уверенности в том, что объект
оценки отвечает требованиям к функциям безопасности.
3.1.5 Потенциал нападения (attack potential) — мера усилий которые должны
быть приложены для нападения на объект оценки, выраженная в показа-
телях компетентности, ресурсов и мотивации нападающего.
3.1.6 Усиление (augmentation) — добавление одного или нескольких требова-
ний к пакету.
3.1.7 Данные аутентификации (authentication data) — информация, исполь-
зуемая для проверки достоверности предъявленного идентификатора
пользователя.
3.1.8 Авторизованный пользователь (authorized user) — пользователь объ-
екта оценки, которому, в соответствии с требованиям к функциям безо-
пасности, разрешено выполнять определенные операции.
3.1.9 Класс (class) — группа семейств компонентов ISO / IEC 15408 общей на-
правленности.
3.1.10 Ясный (coherent) — логически упорядоченный и имеющий ясное значе-
ние или чёткую формулировку.
Примечание: В случаях, связанных с документацией, это относится как к рас-
сматриваемому тексту, так и к структуре самого документа, в том смысле,
что он должен быть правильно понят целевой аудиторией.
3.1.11 Полный (complete) — свойство, заключающееся в том, что все необхо-
димые части предмета имеются в наличии.
Примечание: В случае документации это означает, что вся относящаяся к
предмету информация представлена, причем на таком уровне детализации,
что для избранного уровня абстрактности изложения никакие дальнейшие
объяснения не требуются.
3.1.12 Компонент (component) — наименьшая совокупность элементов, на ко-
торой могут основываться требования.
3.1.13 Составной пакет доверия (composed assurance package) — пакет требо-
ваний доверия к безопасности, состоящий из требований, извлеченных
из ISO / IEC 15408_3 (преимущественно из класса АСО) и представляю-
щий точку на шкале ранжирования доверия к безопасности, определен-
ной в ISO / IEC 15408.
3.1.14 Подтвердить (confirm) — объявить о том, что нечто подвергнуто деталь-
ной экспертизе, проанализировано и от независимой стороны получено
подтверждение достаточности этого.
Примечание: Уровень жесткости требований зависит от природы рассматри-
ваемого предмета. Этот термин употребляется только по отношению к дейс-
твиям лица, занимающегося оценкой.

11
ISO / IEC 15408-1:2009

3.1.15 Связность (connectivity) — свойство объекта оценки, позволяющее ему


взаимодействовать с внешними по отношению к нему ИТ_сущностями.
Примечание: Это взаимодействие включает обмен данными по проводным
или беспроводным средствам на любом расстоянии, в любой среде или при
любой конфигурации.
3.1.16 Совместимый (consistent) — связь между двумя или более сущностями
(объектами), при которой между ними отсутствуют противоречия.
3.1.17 Противодействие (to counter) — такое отражение нападения, при кото-
ром негативный эффект угрожающего воздействия смягчается, но не
обязательно устраняется полностью.
3.1.18 Очевидное соответствие (demonstrable conformance) — отношение
между целевым уровнем безопасности и профилем защиты, при кото-
ром показатели целевого уровня безопасности решают проблемы безо-
пасности, определенные в данном профиле защиты.
Примечание: Профиль защиты и целевой уровень безопасности могут со-
держать абсолютно разные положения, касающиеся обсуждения разных,
несхожих, предметов, использовать разные концепции и т. д. Очевидное
соответствие также подходит для таких документов как объект оценки, для
которого уже существуют несколько сходных профилей защиты, поскольку
позволяет автору целевого уровня безопасности заявить о его соответствии
всем этим профилям, и таким образом экономить трудозатраты.
3.1.19 Продемонстрировать (demonstrate) — представить заключение, полу-
ченное путем анализа, менее строгий метод чем «доказательство».
3.1.20 Зависимость (dependency) — взаимосвязь между компонентами, при
которой, если какое_либо требование, основанное на зависящем компо-
ненте, включено в профиль защиты, целевой уровень безопасности или
в пакет требований, то требование, основанное на том компоненте, от
которого он зависит, в общем случае, также должно входить в профиль
защиты, целевой уровень безопасности или пакет требований.
3.1.21 Описать (describe) — представить специфические детали (предмета
рассмотрения).
3.1.22 Определить (determine) — подтвердить некоторое заключение. осно-
ванное на независимом анализе, предварительно проведенном с целью
формирования этого вывода.
Примечание: использование этого термина подразумевает проведение дейс-
твительно независимого анализа, как правило, выполненного при полном от-
сутствии какого_либо предыдущего. Сравните с терминами «подтвердить»
или «верифицировать». подразумевающими, что анализ уже был проведен
и / но его (результаты) нуждаются в проверке.
3.1.23 Среда разработки (development environment) — среда, в которой разра-
ботан объект оценки.
3.1.24 Элемент (element) — неделимое (элементарное) требование безопас-
ности.
3.1.25 Гарантировать (ensure) — обязательство сильной причинно_следст-
венной связи между действием и его последствиями.
Примечание: если перед этим термином стоит слово «помогать», то оно ука-
зывает, что на основании лишь одного указанного действия полной уверен-
ности в наступлении данного следствия быть не может.

12
ISO / IEC 15408-1:2009

3.1.26 Оценка (evaluation) — установление соответствия профиля защиты, це-


левого уровня безопасности или пакета требований назначенным кри-
териям.
3.1.27 Уровень оценки доверия (evaluation assurance level) — пакет требова-
ний доверия к безопасности, вытекающих из ISO / IEC 15408_3, который
представляет точку на определенной в ISO / IEC 15408 шкале ранжирова-
ния доверия и формирует пакет доверия к объекту оценки.
3.1.28 Полномочный орган оценки (evaluation authority) — учреждение, уста-
навливающее стандарты и контролирующее качество оценок, проводи-
мых соответствующими организациями определенного сообщества и
обеспечивающее выполнение ISO / IEC 15408 на практике через схемы
проведения оценки.
3.1.29 Схема оценки (evaluation scheme) — административно_нормативная
структура, в рамках которой полномочные органы оценки применяют
ISO / IEC 15408 в конкретном сообществе.
3.1.30 Исчерпывающий (exhaustive) — характеристика методического подхо-
да, предпринятого для выполнения некоторого анализа или другой де-
ятельности, согласно ясному однозначному плану.
Примечание: Этот термин используется в ISO / IEC 15408 в отношении анали-
за или другой деятельности. Он родственен термину «систематический», но
значительно сильнее. Он указывает не только то, что для выполнения неко-
торого анализа или другой деятельности был принят методический подход,
но также, что сам план, по которому выполнялся анализ, достаточен и гаран-
тирует, что все возможные средства были использованы.
3.1.31 Объяснить (explain) — представить довод, обосновывающий причину
выполнения каких_либо действий.
Примечание: Этот термин отличается как от «описать» так и от «продемонс-
трировать». Он предназначен для ответа на вопрос «Почему?», однако при
этом, не утверждает, что избранный способ действий непременно был опти-
мальным.
3.1.32 Расширение (extension) — дополнение целевого уровня безопасности
или профиля защиты функциональными требованиями, не содержащи-
мися в ISO / IEC 15408_2, и / или требованиями доверия к безопасности, не
содержащимися в ISO / IEC 15408-3.
3.1.33 Внешний объект (external entity) — любые объекты: человек или
ИТ_система, находящиеся вне границ объекта оценки и, возможно, вза-
имодействующие с ним.
Примечание: Внешний объект может быть определен как пользователь объ-
екта оценки.
3.1.34 Семейство (family) — набор компонентов, имеющих общую цель, но раз-
личающихся по акцентированию деталей, либо строгости требований.
3.1.35 Формальный (formal) — выражаемый языком с ограниченным синтак-
сисом и четко определенной семантикой, основанной на установивших-
ся математических понятиях.
3.1.36 Инструкция (guidance documentation) — документация, описывающая
доставку, подготовку, действие, эксплуатацию, управление и / или ис-
пользование объекта оценки.

13
ISO / IEC 15408-1:2009

3.1.37 Идентификатор (identity) — представление уникальных сущностей


(например, пользователя, процесса или диска) в контексте объекта
оценки.
Примечание: Примером такого представления может быть строка символов.
Представлять пользователя может его полное, либо сокращённое имя или
его (равно уникальный) псевдоним.
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 Операция (с компонентом ISO / IEC 15408 operation) модификация или
повторение компонента.
Примечание: Разрешенные операции с компонентом — это назначение, ите-
рация, уточнение и выбор.
3.1.47 Операция (с объектом) (operation) специфический тип действий над объ-
ектом, выполняемый субъектом.
3.1.48 Операционная среда (operational environment) — среда в которой экс-
плуатируется объект оценки.
3.1.49 Политика безопасности организации (organizational security policy) —
набор правил, процедур или руководящих принципов в области безопас-
ности, предназначенных для использования в организации.
Примечание: Политика безопасности может также относиться к какой_либо
специфической операционной среде.
3.1.50 Пакет (package) — именованный набор требований, предъявляемых
либо к функциям безопасности, либо к уровню доверия к безопасности.
Примечание: Примером пакета требований может служить ЕAL 3.
3.1.51 Оценка профиля защиты (Protection Profile evaluation) — оценка профи-
ля защиты согласно определенным критериям.

14
ISO / IEC 15408-1:2009

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) — характеристики субъектов,
пользователей объектов (включая внешние ИТ_продукты), объектов, ин-
формации, рабочих сеансов и / или ресурсов, то есть всего, что использу-
ется при определении требований к функциям безопасности и чьи вели-
чины используются в реализации этих требований.
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, ST) — зависимая от
применения совокупность требований по безопасности, предназначен-
ная для использования при оценке конкретного объекта оценки.
3.1.64 Выбор (selection) — выделение одного или нескольких элементов из пе-
речисленных в компоненте.

15
ISO / IEC 15408-1:2009

3.1.65 Полуформальный (semiformal) — выраженный на языке с ограничен-


ным синтаксисом и определенной семантикой.
3.1.66 Специфицировать (specify) — предусмотреть характерные детали
какого_либо объекта в точной и строгой манере.
3.1.67 Cтрогое соответствие (strict conformance) — иерархическая связь меж-
ду профилем защиты и целевым уровнем безопасности, в которой все
требования, содержащиеся в профиле защиты, также существуют и в
целевом уровне безопасности.
3.1.68 Оценка целевого уровня безопасности (ST evaluation) — оценка целе-
вого уровня безопасности согласно установленным критериям.
3.1.69 Субъект (subject) — активная сущность в объекте оценки, выполняющая
операции над объектами.
3.1.70 Объект оценки (target of evaluation, TOE) — комплект, состоящий из
программного обеспечения, программно-аппаратных и / или аппаратных
средств, возможно, снабженный инструкциями.
3.1.71 Носитель угрозы (threa tagent) — носитель потенциального негативного
воздействия на имеющие ценность активы.
3.1.72 Оценка объекта оценки (TOE evaluation) — оценка объекта оценки со-
гласно установленным критериям.
3.1.73 Ресурс объекта оценки (TOE resource) — всё, что пригодно к использо-
ванию или потреблению в объекте оценки.
3.1.74 Функции безопасности объекта оценки (TOE security functionality,
TSF) — объединенная функциональность всего оборудования, програм-
много обеспечения и программно-аппаратных средств, на которую необ-
ходимо полагаться для правильного соблюдения требований к функци-
ям безопасности.
3.1.75 Прослеживать (trace) — выполнять неформальный анализ общения
двух объектов, с минимальным уровнем строгости.
3.1.76 Передача за пределы объекта оценки (transfers outside of the TOE) —
передача данных функциями безопасности объекта оценки объектам, не
контролируемым этими функциями безопасности.
3.1.77 Трансляция (translation) — описание стандартизованным языком про-
цесса составления требований по безопасности.
Примечание: Использование термина «трансляция» в этом контексте не бук-
вально и не подразумевает, что каждое требование к функциям безопаснос-
ти, выраженное стандартизованным языком, может быть также транслирова-
но обратным порядком к целям безопасности.
3.1.78 Доверенный канал (trusted channel) — средство взаимодействия меж-
ду функциями безопасности объекта и другим удаленным доверенным
ИТ-продуктом, обеспечивающее необходимую для этого степень уве-
ренности.
3.1.79 Доверенный ИТ-продукт (trusted IT product) — ИТ-продукт, отличный от
объекта оценки, требования к функциям безопасности которого адми-
нистративно скоординированы с объектом оценки и который считается
правильно реализующим свои требования к функциям безопасности.
Примечание: Пример доверенного ИТ-продукта — продукт, прошедший не-
зависимую оценку.

16
ISO / IEC 15408-1:2009

3.1.80 Доверенный маршрут (trusted path) — средство, с помощью которого


пользователь и функции безопасности объекта оценки могут общаться
с необходимой степенью уверенности.
3.1.81 Данные функций безопасности объекта оценки (TSF data) — дан-
ные, необходимые для функционирования объекта оценки, на которые
опирается принудительное исполнение требований к функциям безопас-
ности.
3.1.82 Интерфейс функций безопасности объекта оценки (TSF interface) —
средства, через которые внешние объекты (или элементы объекта оцен-
ки, но вне его функций безопасности) пересылают данные в функции
безопасности объекта оценки, получают данные от этих функций и при-
влекают их услуги.
3.1.83 Данные пользователя (user data) — данные, предназначенные для
пользователя, не влияющие на выполнение функции безопасности объ-
екта оценки.
3.1.84 Верификация (verify) — строгий детальный анализ, сопровождаемый
независимой оценкой его достаточности.
Примечание: См. также термин «подтвердить» (3.1.14). Термин «верифика-
ция» имеет более строгие оттенки. Он используется в контексте действий
оценивающего, где от него требуется независимый взгляд.

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


Примечание: Приведенные ниже термины используются для потребностей
внутреннего структурирования програмного обеспечения. Некоторые из них
взяты из глоссария терминологии разработки программных средств (IEEE
Std 610.12-1990 Standard glossary of software engineering terminology), разра-
ботанного Институтом Инженеров Электротехники и Электроники (Institute of
Electrical and Electronics Engineers).
3.2.1 Администратор (administrator) — объект, уровень доверия которого со-
ответствует всем видам политик, реализуемых функциями безопасности
объекта оценки.
Примечание: Не все профили защиты или целевые уровни безопасности
предполагают одинаковый уровень доверия для администраторов. Обычно
считается, что администраторы должны придерживаться политик, заложен-
ных в целевые уровни безопасности объекта оценки. Некоторые из этих по-
литик могут относиться к функциональности объекта оценки, другие могут
быть связаны с операционной средой.
3.2.2 Дерево вызовов (call tree) — идентифицирует модули в системе, пред-
ставляя их в форме диаграммы, показывающей какие модули вызывают
другие.
Примечание: адаптировано из глоссария IEEEStd 610.12-1990.
3.2.3 Связность (cohesion) — сила модуля, его способ работы и степень, до ко-
торой задания, выполненные отдельным программным модулем, связаны
с другим модулем.
[IEEEStd 610.12-1990]
Примечание: Различные виды связности включают: синхронную, коммуни-
кационную, функциональную, логическую, последовательную и временную.
Эти разновидности связности описываются при введении соответствующих
терминов.

17
ISO / IEC 15408-1:2009

3.2.4 Синхронная связность (coincidental cohesion) — модуль, характеризуе-


мый выполнением несвязанных, либо слабо связанных действий.
[IEEE Std 610.12-1990]
3.2.5 Коммуникационная связность (communicational cohesion) — модуль,
содержащий функции, осуществляющие вывод для других функций это-
го же модуля, или использующий выведенный из них материал.
[IEEEStd 610.12-1990]
Примечание: Пример коммуникационно-связанного модуля — это модуль
проверки доступа, содержащий мандатную и дискреционную проверки.
3.2.6 Сложность (complexity) — мера того, насколько программное обеспече-
ние трудно для понимания, анализа, проверки и обслуживания
[IEEEStd 610.12-1990]
Примечание: Снижение сложности — это конечная цель декомпозиции, раз-
деления на слои и минимизации модулей. Контроль соединения и связности
значительно способствует достижению этой цели. Много усилий в сфере раз-
работки программного обеспечения были затрачены в попытках разработ-
ки метрики для количественного измерения сложности исходных программ.
Большинство этих метрик используют легко вычисляемые свойства исход-
ных программ, такие как количество операторов и операндов, сложность
управляющей логики (сложность организации циклов в программе), число
строк в исходном коде программы, пропорция содержания комментариев в
исполняемой программе и прочие аналогичные количественные показатели.
Общепринято, что стандарты программирования — это полезный инстру-
мент разработки более легких для понимания программ.
Семейство внутренних функций безопасности объекта оценки (ADV_INT) вы-
зывает анализ сложности во всех компонентах. Ожидается, что разработчик
сможет подтвердить утверждения, что произошло существенное снижение
сложности. Это подтверждение может включать в себя стандарты програм-
мирования разработчика и указание на то, что все модули соответствуют
стандарту (либо имеются исключения, появление которых обосновано каки-
ми-либо соображениями разработки). Оно также может включать результаты
применения инструментов для измерения свойств исходной программы или
содержать другие формы поддержки, которые разработчик сочтет подобаю-
щими случаю.
3.2.7 Соединение (coupling) — способ и степень взаимозависимости между
модулями программ.
[IEEEStd 610.12-1990]
Примечание: Виды соединения включают соединения «по вызову», «общее»
и «информационное».
3.2.8 Соединение по вызову (call coupling) — связь между двумя модулями,
сообщающимися строго через документированные функций вызова.
Примечание: Примеры соединения по вызову — это данные, отметка и уп-
равление.
3.2.9 Соединение по вызову (данные) (call coupling) — связь между двумя
модулями, коммуницирующими строго через параметры вызова, пред-
ставляющие отдельные элементы данных.
3.2.10 Соединение по вызову (отметка) (call coupling) — связь между двумя
модулями, коммуницирующими через параметры вызова, охватыва-
ющие множество областей или имеющие значащие внутренние струк-
туры.

18
ISO / IEC 15408-1:2009

3.2.11 Соединение по вызову (управление) (call coupling) — связь между дву-


мя модулями, при которой один передает информацию, предназначен-
ную для влияния на внутреннюю логику другого.
3.2.12 Общее соединение (common coupling) — связь между двумя модулями,
разделяющими общую область данных или другой общий системный ре-
сурс.
Примечание: Глобальные переменные указывают, что модули, использу-
ющие их, имеют общее соединение. Общее соединение через глобальные
переменные обычно допускается, но в ограниченной степени. Например,
переменные, размещенные как глобальные, но используемые лишь одним
модулем, размещены неподобающим образом и их следует удалить. Другие
факторы, которые нужно принимать во внимание при оценке приемлемости
глобальных переменных, следующие.
1. Количество модулей модифицирующих глобальную переменную. В общем
случае только отдельному модулю может быть предоставлена ответствен-
ность контроля и управления содержанием глобальной переменной. Од-
нако могут сложиться ситуации, в которых второй модуль может разделить
эту ответственность, хотя в подобном случае должны быть представлены
веские обоснования. Недопустимо, чтобы эту ответственность разделя-
ли совместно более двух модулей. (При оценке и определении того, ка-
кой именно модуль действительно несет ответственность за содержание
переменной, нужно проявлять большую осторожность. Например, если
для модификации переменной используется отдельная процедура, и она
просто выполняет модификацию, запрошенную вызывающим модулем, то
именно этот модуль и является ответственным. Тем не менее, могут так-
же существовать и другие подобные модули). В качестве ещё одной со-
ставляющей определения сложности можно сказать, что если два модуля
несут ответственность за содержание глобальной переменной, то долж-
ны иметься ясные указания на то, как эти модификации координируются
между ними.
2. Количество модулей обращающихся к глобальной переменной. Хотя обыч-
но никаких ограничений на количество таких модулей, обращающихся к
одной глобальной переменной, не накладывается, все же случаи, когда
множество модулей делают такие ссылки, следует проверять на необхо-
димость и обоснованность.
3.2.13 Контентная связь (content coupling) — связь между двумя модулями,
при которой один напрямую обращается к внутреннему содержанию
другого.
Примечание: Примеры такой связи — модификация кодов и программ или
обращение к внутренним меткам другого модуля. В результате, часть, либо
все содержание одного модуля успешно инкорпорируется в другой. Контен-
тную связь можно также трактовать, как использование необъявленных ин-
терфейсов модулей. Эта связь противоположна «соединению по вызову»,
при котором используются только объявленные интерфейсы модулей.
3.2.14 Разделение доменов (domain separation) — свойство архитектуры бе-
зопасности, на основе которого функций безопасности объекта оценки
определяют отдельные домены безопасности для каждого пользователя
и для самих функций безопасности объекта, и отслеживают чтобы ника-
кой пользовательский процесс не затронул домен безопасности другого
пользователя или функций безопасности объекта оценки.

19
ISO / IEC 15408-1:2009

3.2.15 Функциональная связность (functional cohesion) — функциональное


свойство модуля, выполняющего действия относящиеся к какой-либо
единственной цели.
[IEEEStd 610.12-1990]
Примечание: Модуль с функциональной связностью трансформирует одно-
типный сигнал на входе в однотипный сигнал на выходе, например, как моду-
ли управления стэком или очередями.
3.2.16 Взаимодействие (interaction) — общая деятельность, основанная на
коммуникации между объектами.
3.2.17 Интерфейс (interface) — средства взаимодействия с компонентом или
модулем.
3.2.18 Разделение на слои (layering) — технология разработки, при которой
отдельные группы модулей (слои) иерархически организованы так, что-
бы каждый имел свою сферу ответственности, причем каждый слой в
иерархии сервисов зависит только от слоев лежащих ниже него, а свои
сервисы предоставляет лишь слоям расположенным выше.
Примечание: Строгое разделение по слоям накладывает дополнительное ог-
раничение, состоящее в том, что каждый слой обслуживает лишь один слой,
расположенный непосредственно над ним.
3.2.19 Логическая связность (logical cohesion), процедурная связность
(procedural cohesion) — характеристики модуля, выполняющего сходные
действия над разными структурами данных.
Примечание: Модуль демонстрирует логическую связность, если его функ-
ции выполняют родственные, но разные, операции над разными входными
сигналами.
3.2.20 Декомпозиция на модули (modular decomposition) — процесс разбие-
ния системы на компоненты, чтобы обеспечить проектирование, разра-
ботку и оценку.
[IEEEStd 610.12-1990].
3.2.21 Невозможность обхода (в функциях безопасности объекта оценки)
(non-bypassability) — свойство архитектуры безопасности, на основании
которого все действия, связанные с функциональными требованиями,
производятся посредством функций безопасности объекта оценки.
3.2.22 Домен безопасности (security domain) — подборка ресурсов, к которой
активный объект имеет преимущественный доступ.
3.2.23 Последовательная связность (sequential cohesion) — модуль, содер-
жащий функции, выходной сигнал каждой из которых служит входным
сигналом для следующей функции этого модуля.
[IEEEStd 610.12-1990]
Примечание: Примером модуля с последовательной связностью служит мо-
дуль, содержащий функции записи данных аудита и подсчитывающий накап-
ливаемые данные по числу проверенных нарушений определенного типа.
3.2.24 Программная инженерия (software engineering) — применение систе-
матизированного, упорядоченного, количественно измеряемого подхода
к разработке и обслуживанию программного обеспечения, то есть при-
менение инженерных методов к программному обеспечению.
[IEEEStd 610.12-1990]
Примечание: Как и вообще в инженерной практике, при применении инже-
нерных принципов должны использоваться экспертные решения. На выбор

20
ISO / IEC 15408-1:2009

влияет множество факторов, а не только лишь применение методов деком-


позиции на модули, создание иерархического, многоуровневого, разбиения
на слои и минимизация. Например, разработчик может проектировать систе-
му, имея в виду её будущие применения, которые не будут реализованы на
начальной стадии. Разработчик может заложить в систему логику, которая
будет управлять этими будущими применениями, при этом, не реализуя ее
полностью. В дальнейшем разработчик может добавить какие_либо команды
вызова не используемых до тех пор модулей. Решение разработчика ввес-
ти подобные отклонения от программ с рациональной структурой придется
оценить, используя экспертные решения, равно как и применение должной
дисциплины разработки программ.
3.2.25 Временная связность (temporal cohesion) — характеристика модуля,
содержащего функции, которые нужно выполнить почти одновременно.
Примечание 1: адаптировано из [IEEEStd 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 Tермины и определения, относящиеся к классу ALC
3.4.1 Критерии приемки (acceptance criteria) — критерии, применяемые во
время выполнения процедур приемки (например, успешный просмотр до-
кументации или тестирование).
3.4.2 Процедуры приемки (acceptance procedures) — процедуры, которым
следуют с целью приемки новых объектов или модифицированных кон-

21
ISO / IEC 15408-1:2009

фигурационных единиц, которые являются частью объекта оценки, а так-


же для продвижения их на новую ступень жизненного цикла.
Примечание: Эти процедуры определяют роли лиц, ответственных за при-
емку и критерии, применяемые с целью вынесения решения о приемке. Су-
ществуют несколько типов ситуаций приемки, некоторые из которых могут
накладываться друг на друга:
a) приемка конфигурационной единицы в систему управления конфигу-
рациями в первый раз, в частности, включение компонентов программ,
программно_аппаратных систем или оборудования от других производите-
лей в объект оценки («интеграция»);
b) развитие конфигурационной единицы до фазы следующего жизненного
цикла на каждой стадии построения объекта оценки (например, модуль,
подсистема, контроль качества законченого объекта);
c) последующее перемещение конфигурационной единицы (например, час-
тей объекта оценки или первичных продуктов) между разными площадка-
ми разработки;
d) последующая доставка объекта оценки потребителю.
3.4.3 Управление конфигурациями (УК) (configuration management, CM) — дис-
циплина, привлекающая технические и административные управление и
контроль, чтобы идентифицировать и документировать функциональные
и физические характеристики конфигурационной единицы, контролиро-
вать изменения в этих характеристиках, регистрировать и информиро-
вать о процессе изменения и статусе внедрения, а также проверять на
соответствие определенным требованиям.
Примечание: адаптировано из IEEEStd 610.12.
3.4.4 Документация управления конфигурациями (CM documentation) — вся
документация управления конфигурациями, включая выходные данные,
реестр конфигураций, записи системы управления конфигурациями, план
и документация по управлению конфигурациями.
3.4.5 Свидетельство управления конфигурацией (configuration management
evidence) — всё, что можно использовать, чтобы удостовериться в пра-
вильном функционировании системы управления конфигурациями.
Примечание: Например, это могут быть выходные сигналы системы управле-
ния конфигурациями, аргументы разработчика, наблюдения, эксперименты
или интервью, проведенные оценивающим лицом во время посещения ра-
бочих мест.
3.4.6 Конфигурационная единица (configuration item) — элемент, управляе-
мый системой управления конфигурациями в ходе разработки объекта
оценки.
Примечание: Это могут быть либо части объекта оценки, либо объекты, от-
носящиеся к его разработке, такие как документы об оценке или инструмен-
ты для разработки. Конфигурационные единицы могут храниться прямо в
системе управления конфигурациями (например, файлы) или посредством
ссылки (например, детали оборудования) вместе с их основной версией.
3.4.7 Реестр конфигурации (configuration list) — выходной документ управ-
ления конфигурациями, содержащий перечень всех конфигурационных
единиц конкретного продукта, вместе с точной версией каждой единицы,
относящейся к конкретной версии продукта в целом.
Примечание: Этот реестр дает возможность отличать конфигурационные
единицы, принадлежащие оцениваемой версии продукта, от других версий

22
ISO / IEC 15408-1:2009

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


реестр конфигураций — это специальный документ, относящийся к конкрет-
ной версии конкретного продукта. (Разумеется, перечень может быть внут-
ренним электронным документом инструмента управления конфигурациями.
В этом случае его можно рассматривать скорее как особый ракурс системы,
либо как часть системы, а не выходные данные системы. Тем не менее, для
практического использования при оценке, реестр конфигураций, вероятно,
будет частью оценочной документации.) Реестр конфигураций определяет
те элементы, которые соответствуют требованиям управления конфигураци-
ями 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) — выходной продукт, созданный во время
функционирования системы управления конфигурациями, фиксирую-
щий важные действия по управлению конфигурациями.
Примечание: Примеры записей системы управления конфигурациями — это
формы контроля изменений конфигурационных единиц или разрешения до-
ступа к конфигурационной единице.

23
24
®ÅÎÏÂɽ°§ £ÅÄÊÂÊÊØÆÓÅÇÈÌÍËÁÐÇϽ
®ÅÎÏÂɽ ÐÌͽ¿ÈÜÂÏ «Ï¿ÂÏÎÏ¿ÂÊÊËÎÏÙ
°§ «Ï¿ÂÏÎÏ¿ÂÊÊËÎÏÙͽÄͽ¾ËÏÔÅǽ
¥ÊÎÏÍÐÉÂÊÏØ°§ ÌËÈÙÄË¿½ÏÂÈÜ
ÇËÊÇÍÂÏÊËÀË
ÌÍËÁÐÇϽ «ÌÂͽÓÅËÊʽÜ
®ÍÂÁ½ͽÄͽ¾ËÏÇÅ ÎÍÂÁ½
¡ËÇÐÉÂÊϽÓÅÜ

ÅÎÌËÈÙÄÐÂÏ
ÌËÅÊÎÏÍÐÉÂÊϽÉ
¡ËÇÐÉÂÊϽÓÅÜ ¡ËÇÐÉÂÊϽÓÅÜ ¯ÂÎÏÅÍË¿½ÊÅÂ
ÌËÅÎÌËÈÙÄË¿½ÊÅÛ°§ ÌËÌÍËÓÂÁÐͽÉ
¬ÍËÓÂÁÐÍØ°§
­½Äͽ¾ËÏǽ
¥ÊÎϽÈÈÜÓÅÜ
ÌÍËÅÄ¿ËÁÅÏ ËÌÍÂÁÂÈÜÂÏ ¬ÍËÅÄ¿ËÁÎÏ¿Ë
ʽÌÍÅÄÀËÏË¿ÈÂÊÅÂ

ÌÍËÅÄ¿ËÁÅÏ
¿ØÌËÈÊÂÊÅÂ
ÅÊÏÂÀͽÓÅÜ ÒͽÊÂÊÅÂ

˾ÂÎÌÂÔÅ¿½ÂÏ
«ÌÂͽÓÅÜ
ɽÍÇÅÍ˿ǽ

¬ÍËÁÐÇÏØ°§
¡ÂÆÎÏ¿ÅÜ
ŸØÒËÁʽÜ
ÁËÇÐÉÂÊϽÓÅÜ°§ ­ÂÂÎÏÍ  Í½ÊÅÓØ
ÇËÊÑÅÀÐ ÍÐÔÊËÀË ¬ÍËÓÂÎÎÁËÎϽ¿ÇÅ
¬È½Ê ¤½ÌÅΊͽÓÅÆ °§
°§ ÎÅÎÏÂÉØ ÎËÁÂÍÃÅÏ ÌÂÍÂÎØÈǽ
°§ §¢
¬ËÁÀËÏ˿ǽ ¬ÍÅÂÉǽ
ÅÎÌËÈÙÄÐÂÏ

Примечание. Документация УК = Документация по использованию УК + Выходная документация УК

Рисунок 1. Терминология, используемая в управлении конфигурациями и жизненном цикле продукта.


ISO / IEC 15408-1:2009
ISO / IEC 15408-1:2009

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) — фаза изготовления в жизненном цикле
продукта, которая следует за фазой разработки и состоит в превраще-
нии задания на реализацию в непосредственную реализацию объекта

25
ISO / IEC 15408-1:2009

оценки, то есть, доведение изделия до состояния приемлемого для пе-


редачи покупателю.
Примечание 1: Эта фаза может охватывать производство, интеграцию, внут-
реннюю транспортировку, хранение и маркировку объекта оценки.
Примечание 2: См. также Рис 1.

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 Термины и определения, относящиеся к классу ACO
3.6.1 Базовый компонент (base component) — элемент в составном объекте
оценки, который сам был предметом оценки, предоставляющий сервисы
и ресурсы для зависимого от него компонента.
3.6.2 Совместимые (компоненты) (compatible) — свойство компонентов через
соответствующие интерфейсы предоставлять сервисные функции, требу-
емые другими компонентами, в согласующихся операционных средах.
3.6.3 Компонент объекта оценки (component TOE) — успешно проверенный
объект оценки, являющийся частью другого составного объекта.
3.6.4 Составной объект оценки (composed TOE) — объект оценки, состоящий
из двух или более компонентов успешно прошедших оценку.
3.6.5 Зависимый компонент (dependent component) — элемент в составном
объекте оценки, который сам является предметом оценки и зависит от
сервисных функций, предоставляемых базовым компонентом.

26
ISO / IEC 15408-1:2009

3.6.6 Функциональный интерфейс (functional interface) — внешний интер-


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

4 Сокращения терминов
Следующие сокращения используются в одной или нескольких частях
ISO / IEC 15408:
• API (Applied Programming Interface) — интерфейс прикладного программи-
ровния.
• CAP (Composed Assurance Package) — составной пакет доверия к безопас-
ности
• CM (Сonfiguration management) — управление конфигурациями (УК)
• DAC (Discretionary Access Control) — дискреционный контроль доступа
• EAL (Evaluation Assurance Level) — уровень оценки доверия (УОД)
• GHz (Gigahertz) — гигагерц (ГГц)
• GUI (Graphical User Interface) — графический интерфейс пользователя.
• IC (Integrated Circuit) — интегральная схема
• IOCTL (Input Output Control) — управление вводом / выводом
• IP (Internet Protocol) — протокол IP
• IT (Information Technology) — информационные технологии (ИТ)
• MB (Mega Byte) — Мегабайт (Мб)
• OS (Operating System) — операционная система ОС ()
• OSP (Organizational Security Policy) — политика безопасности организации
(ПБО)
• PC (Personal Computer) — персональный компьютер (ПК)
• PCI (Peripheral Component Interconnect) — шина PCI
• PKI (Public Key Infrastructure) — инфраструктура открытых ключей
• PP (Protection Profile) — профиль защиты (ПЗ)
• RAM (Random Access Memory) — оперативная память
• RPC (Remote Procedure Call) — вызов удаленной процедуры
• SAR (Security Assurance Requirement) — требование доверия к безопаснос-
ти (ТДБ)
• SFR (Security Functional Requirement) — требование к функциям безопас-
ности (ТФБ)
• SFP (Security Function Policy) — политика функции безопасности.
• SPD (Security Problem Definition) — определение проблем безопасности.
• ST (Security Target) — целевой уровень безопасности (ЦУБ)
• TCP (Transmission Control Protocol) — протокол ТСР
• TOE (Target of Evaluation) — объект оценки (ОО)
• TSF (TOE Security Functionality) — функции безопасности объекта оценки
(ФБОО)
• TSFI (TSF Interface) — интерфейс функции безопасности объекта оценки.
• VPN (Virtual Private Network) — виртуальная частная сеть

27
ISO / IEC 15408-1:2009

5. Общий обзор
5.1 Общие положения
В настоящем разделе изложены основные концепции ISO / IEC 15408. Он оп-
ределяет понятие «Объект Оценки» (ОО), целевую аудиторию пользователей
ISO / IEC 15408, а также подход, принятый к представлению материала в следу-
ющих частях cтандарта ISO / IEC 15408.
5.2 Объект оценки
В отношении оцениваемого предмета стандарт ISO / IEC15408 весьма гибок
и, следовательно, не привязан жестко к границам ИТ_продуктов, как обычно
считается. Вследствие этого, в контексте оценки, ISO / IEC 15408 использует
термин «объект оценки» (ОО). ОО определяется как комплекс программных
средств, программно_аппаратных средств и / или аппаратных средств, возмож-
но снабженных инструкциями.
Ситуации, когда объект оценки представляет собой ИТ_продукт — не единст-
венны. Объект оценки может быть ИТ_продуктом, частью ИТ_продукта, набором
ИТ_продуктов, уникальной технологией, которая, возможно, никогда не будет го-
товым продуктом, или комбинацией перечисленных вариантов. В рамках ISO/IEC
15408, точное соотношение между ОО и любыми ИТ_продуктами важно лишь в
одном аспекте: оценка ОО, содержащего только часть ИТ_продукта, не должна
быть ошибочно представлена как оценка всего продукта в целом.
Примеры объектов оценки включают следующее:
• прикладная программа;
• операционная система;
• прикладная программа в сочетании с операционной системой;
• прикладная программа в сочетании с операционной системой и рабочей
станцией;
• операционная система в сочетании с рабочей станцией;
• интегральная схема смарт_карты;
• криптографический сопроцессор интегральной схемы смарт_карты;
• локальная сеть, включающая все терминалы, серверы, сетевое оборудова-
ние и программное обеспечение;
• приложение базы данных, включая программное обеспечение удаленного
пользователя, обычно относящееся к этому приложению.
5.2.1 Различные формы представления объекта оценки
В ISO/IEC 15408 объект оценки может быть представлен в нескольких вариан-
тах, таких как (для ОО, относящегося к категории программного обеспечения):
• список файлов в системе управления конфигурациями;
• отдельная мастер_копия, компилированная непосредственно перед оценкой;
• упаковка, содержащая CD-ROM и руководство пользователя, готовая к от-
правке заказчику;
• инсталлированная рабочая версия.
Все перечисленное может считаться объектом оценки: и где бы, в ISO / IEC
15408, в дальнейшем не использовался термин «объект оценки» конкретная
форма представления будет определяться, исходя из контекста.

28
ISO / IEC 15408-1:2009

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


Вообще говоря, ИТ_продукты могут иметь множество конфигураций: они мо-
гут быть инсталлированы разными способами и обладать различными набора-
ми включенных или отключенных опций. Когда, во время проведения оценки
безопасности по стандарту ISO / IEC 15408, будет установлено, насколько ОО
удовлетворяет определенным требованиям, эта гибкость конфигураций может
создать специфические проблемы, поскольку, в этом случае все возможные
варианты конфигураций ОО должны будут отвечать этим требованиям.
Именно поэтому на управляющие модули объекта оценки часто накладыва-
ются строгие ограничения в отношении возможных вариантов конфигурации
этого ОО. Иначе говоря: характер управления функционированием ОО может
существенно отличаться от общего характера функционирования данного
ИТ_продукта в целом.
Наглядный пример — такой ИТ_продукт как операционная система. Этот про-
дукт может иметь многочисленные конфигурации (например, по типам поль-
зователей, по типам разрешенных/неразрешенных внешних связей, включен-
ных/отключенных опций и т. д.). Если этот же ИТ_продукт должен стать ОО, и по
нему проводится оценка на соответствие обоснованному набору требований, то
его конфигурация должна контролироваться намного жестче, поскольку многие
опции (например, разрешение всех типов внешних связей или отсутствие тре-
бования аутентификации системного администратора) приведут к появлению
объекта оценки, не удовлетворяющему предъявляемым требованиям.
В связи с этим обычно и появляется различие между управлением функцио-
нированием ИТ_продукта (разрешены многочисленные конфигурации) и управ-
лением функционированием ОО (разрешены лишь одна или несколько конфи-
гураций, не отличающихся по способам и уровню обеспечения безопасности).
Следует отметить, что в случае допущения в ОО наличия более чем одной
конфигурации, все эти конфигурации будут объединены под общим названием
«объект оценки», и каждая такая комплексная конфигурация должна будет со-
ответствовать требованиям, налагаемым на этот ОО.
5.3 Целевая аудитория ISO / IEC 15408
В оценке характеристик безопасности объектов оценки заинтересованы три груп-
пы: потребители и разработчики объекта оценки, а также эксперты по оценке. Кри-
терии, представленные в данной части ISO/IEC 15408, структурированы так, чтобы
удовлетворить потребности всех трех групп, поскольку все они считаются основны-
ми потребителями стандарта ISO/IEC 15408. В последующих разделах показано,
как именно эти три группы могут извлечь пользу из описанных критериев.
5.3.1 Потребители
ISO / IEC15408 разработан для того, чтобы процесс оценки безопасности гаран-
тировал удовлетворение нужд потребителей, поскольку это является основной
целью и логическим обоснованием процесса оценки. Результаты оценки помо-
гают потребителям решить, удовлетворяет ли ОО их требованиям в области
безопасности. Эти потребности в области безопасности обычно определяются
как следствие анализа рисков и направленности политики безопасности. Пот-
ребители могут также использовать результаты оценки и для сравнения раз-
личных объектов оценки.

29
ISO / IEC 15408-1:2009

Стандарт ISO / IEC 15408 предоставляет потребителям, особенно входящим


в группы и сообщества с едиными интересами, независимое от реализации
положение, называемое «Профиль Защиты» (ПЗ), в котором они могут одно-
значным образом выразить свои требования в области безопасности.
5.3.2 Разработчики
Стандарт ISO / IEC 15408 предназначен для поддержки разработчиков при под-
готовке и проведении процесса оценки их ОО, а также в определении требо-
ваний безопасности, которым должны удовлетворять эти ОО. Эти требования
содержатся в зависимом от реализации положении, называемом «Целевой
уровень Безопасности» (ЦУБ). Эти ЦУБ могут основываться на одном или не-
скольких профилях защиты, чтобы показать, что они соответствуют требова-
ниям безопасности, предъявляемым потребителями, изложенными в соответ-
ствующих ПЗ.
Стандарт ISO / IEC 15408 можно использовать для определения ответствен-
ности и действий по предоставлению доказательств, необходимых в процессе
оценки ОО по этим требованиям. Он также определяет содержание и способ
представления этих свидетельств.
5.3.3 Эксперты по оценке
Стандарт ISO / IEC15408 содержит критерии, предназначенные для использо-
вания организациями / специалистами по оценке при составлении экспертных
заключений о соответствии ОО предъявленным к ним требованиям безопас-
ности. В ISO / IEC15408 приведено описание комплекса основных действий. Об-
ратите внимание, что ISO / IEC 15408 не определяет процедуры, которых нужно
придерживаться при выполнении этих действий. Дополнительная информация
по эти процедурам приведена в 5.5.
5.3.4 Прочие
В то время как ISO / IEC15408 ориентирован на определение и оценку характе-
ристик ИТ_безопасности различных ОО, он может быть полезен и в качестве
справочного материала всем, кто интересуется вопросами безопасности ИТ
или несет ответственность за безопасность ИТ.
Содержащаяся в ISO / IEC15408 информация может оказаться весьма полез-
ной для следующих групп заинтересованных лиц:
a) лица, ответственные за техническое состояние оборудования и сотрудни-
ки служб безопасности, ответственные за формирование и выполнение
политики и требований безопасности организации в области ИТ;
b) аудиторы (внешние и внутренние), ответственные за оценку уровня адек-
ватности безопасности ИТ_решений (которые могут состоять из ОО или
содержать их);
c) архитекторы и проектировщики систем безопасности, отвечающие за
спецификацию свойств безопасности ИТ_продуктов;
d) уполномоченные лица и организации, ответственные за принятие ИТ-ре-
шения на эксплуатацию в конкретной среде;
e) спонсоры оценки, ответственные за запрос и поддержку проведения
оценки;
f) полномочные органы оценки, ответственные за управление и надзор за
программами проведения оценок безопасности ИТ.

30
ISO / IEC 15408-1:2009

5.4. Различные части ISO / IEC 15408


Стандарт ISO / IEC 15408 состоит из трех самостоятельных, но взаимосвязан-
ных частей, перечисленных ниже. Терминология, используемая в них, объяс-
няется в разделе 6.
a) Часть 1 «Введение и общая модель» — это введение в стандарт ISO / IEC
15408. В ней определены основные концепции и принципы оценки безопаснос-
ти ИТ, а также описана общая модель оценки.
b) Часть 2 «Функциональные компоненты безопасности» устанавливает
набор компонентов функций безопасности, служащих стандартными шабло-
нами, на которых должны основываться функциональные требования к раз-
личным ОО. Часть ISO / IEC 15408-2 также содержит каталог функциональных
компонентов и их семейств и классов.
c) Часть 3 «Компоненты доверия к безопасности» устанавливает набор
компонентов доверия к безопасности, служащих в качестве стандартных шаб-
лонов, на которых следует основывать требования доверия к безопасности раз-
ных ОО. Часть ISO/IEC 15408-3 также содержит каталог компонентов доверия к
безопасности их семейств и классов. Кроме того, в части ISO/IEC 15408_3 также
определены критерии оценки для различных профилей защиты и целевых уров-
ней безопасности, и представлены семь предопределенных пакетов доверия к
безопасности называемых «Уровень Оценки Доверия» (УОД).

Таблица 1. Путеводитель по стандарту «Критерии оценки безопасности ИТ»


Потребители Разработчики Эксперты по оценке

Часть 1 Используют как общую Используют как общую Обязаны использовать


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

Часть 2 Используют как руко- Обязаны использовать Обязаны использовать,


водство и справочник как справочник при ин- как справочник при ин-
при формулировке по- терпретации положений терпретации положений
ложений требований к требований к функциям требований к функциям
функциям безопаснос- безопасности и фор- безопасности.
ти для ОО. мулировании функцио-
нальных спецификаций
различных ОО.
Часть 3 Используют как руко- Используют как спра- Используют как спра-
водство при определе- вочник при интер- вочник при интер-
нии требуемых уровней претации положений претации положений
доверия к безопаснос- требований доверия к требований доверия к
ти. безопасности и опре- безопасности.
делении подходов к ус-
тановлению доверия к
различным ОО.
Для поддержки трех перечисленных выше частей стандарта ISO / IEC 15408
были опубликованы и другие документы. Например, ISO / IEC 18045 предлагает

31
ISO / IEC 15408-1:2009

методологию оценки безопасности ИТ на базе стандарта ISO / IEC 15408. Ожи-


дается, что будут опубликованы и другие документы, включая материалы по
техническому обоснованию и различные руководства и инструкции.
В таблице 1 показано, какой именно интерес могут представлять различные
части ISO / IEC 15408 для каждой из трех ключевых групп пользователей.
5.5 Контекст оценки
Для большей сопоставимости результатов оценки их следует проводить в рам-
ках определенной структуры и официальной схемы оценки, которая устанав-
ливает стандарты, контролирует качество проведения оценок и обеспечивает
правила, которым должны соответствовать как используемые средства оцен-
ки, так и оценщики.
Стандарт ISO / IEC15408 не содержит требований к нормативной базе. Тем не
менее, для взаимного признания результатов оценок необходима согласован-
ность между нормативно_правовыми базами различных органов оценки.
Другой путь повышения сопоставимости результатов оценки — это исполь-
зование общей методологии получения этих результатов. Для ISO / IEC 15408
эта методология дана в стандарте ISO / IEC 18045. Использование общей ме-
тодологии оценки содействует повторяемости и объективности результатов,
однако одного этого ещё недостаточно. Многие оценки требуют привлечения
экспертных заключений и базовых знаний, достичь совместимости которых
непросто. Чтобы повысить согласованность выводов, полученных при оценке,
окончательные результаты оценки должны пройти процесс сертификации.
Процесс сертификации — это независимая экспертиза результатов оценки,
которая завершается их утверждением или выдачей сертификата. Утвержде-
ние или выдача сертификата обычно становятся публичными. Процесс серти-
фикации — это средство повышения согласованности в применении критериев
безопасности ИТ. Схемы проведения оценки и процессы сертификации нахо-
дятся в компетенции полномочных органов оценки, реализующих эти схемы и
процессы, и выходят за рамки ISO / IEC 15408.

6 Общая модель
6.1 Введение к общей модели
В этом разделе представлены основные концепции, используемые во всех
частях стандарта ISO / IEC 15408, включая контекст их использования и подход
ISO / IEC 15408 к применению этих концепций. Части стандарта ISO / IEC 15408_2
и ISO / IEC 15408_3, к которым должны обращаться пользователи первой части
ISO / IEC 15408, развивают использование этих концепций в рамках описанного
подхода. Далее тем пользователям этой части ISO / IEC 15408, которые наме-
рены провести оценку, полезен также стандарт ISO / IEC 18045. Этот раздел
предполагает наличие определенных знаний в области безопасности ИТ и не
предназначен в качестве учебного пособия.
Безопасность рассматривается в ISO / IEC 15408 с использованием набора
концепций безопасности и терминологии. Понимание этих концепций и терми-
нологии — это необходимое предварительное условие эффективного исполь-
зования стандарта ISO / IEC 15408. Тем не менее, сами эти концепции имеют до-

32
ISO / IEC 15408-1:2009

статочно общий характер и не ограничивают класс проблем ИТ_безопасности,


к которым применим ISO / IEC 15408.
6.2 Активы и меры противодействия
Безопасность имеет дело с защитой активов. Активы — это объекты, пред-
ставляющие ценность для кого_либо. Примеры активов:
– содержание файла или сервера;
– аутентичность голосов поданных на выборах;
– доступность процесса электронной коммерции;
– возможность использовать дорогой принтер;
– доступ к закрытому (секретному) устройству.
Однако, поскольку эта ценность весьма субъективна, как актив может рас-
сматриваться очень много объектов и сущностей. Среда, в которой размещены
эти активы, называется «операционная среда».
Примеры операционных сред:
– помещение с компьютерами в банке;
– сеть компьютеров, подключенная к Интернету;
– локальная вычислительная сеть;
– стандартное офисное окружение.
Многие активы представлены в виде информации, которая хранится, обра-
батывается и передаётся ИТ_продуктами в соответствии с требованиями, оп-
ределенными владельцами этой информации. Владельцы информации вправе
потребовать, чтобы доступность, распространение и модификация такой ин-
формации строго контролировалась, и чтобы их активы были защищены от
угроз мерами противодействия.

ŸÈ½ÁÂÈÙÓØ ÓÂÊÊËÎÏÙ
ÒËÏÜÏ
οÂÎÏÅÇÉÅÊÅÉÐÉÐ
ÌÍÅÉÂÊÜÛÏ

©ÂÍØ
ÌÍËÏÅ¿ËÁÂÆÎÏ¿ÅÜ

ÌËÊÅÄÅÏÙ

­ÅÎÇ

ªËÎÅÏÂÈÅÐÀÍËÄØ ÇËÏËÍØÂ
ÌË¿ØÕ½ÛÏ ÁÈÜ
ÌËÍËÃÁ½ÛÏ

°ÀÍËÄØ ÁÈÜ ÇÏÅ¿Ø

ÒËÏÜÏÄÈËÐÌËÏ;ÅÏÙÅÅÈÅÉËÀÐÏÌË¿ÍÂÁÅÏÙ

Рисунок 2. Высокоуровневые концепции безопасности и их взаимосвязи

33
ISO / IEC 15408-1:2009

Защита активов, представляющих интерес, — это область ответственности


владельцев, для которых эти активы представляют ценность. Существующие,
либо предполагаемые, носители угрозы, также могут видеть в этих активах опре-
деленную ценность и стремиться злоупотребить ими, путями, противоречащими
интересам владельца. Примерами таких носителей угрозы могут быть хакеры,
злонамеренные пользователи, добросовестные пользователи (временами до-
пускающие ошибки), а также некоторые процессы и инциденты в компьютерах.
Владельцы активов будут воспринимать такие угрозы как потенциальную
возможность их повреждения, при котором ценность, представляемая этими
активами для своих владельцев, понизится. Владельцы активов будут анализи-
ровать угрозы, применимые к их активам и среде, определяя связанные с ними
риски. К специфическим нарушениям безопасности обычно относят: потерю
конфиденциальности актива, потерю целостности актива или потерю доступ-
ности к активу (но этим список не ограничивается). Таким образом, эти угрозы
повышают степень риска для актива, основанную на вероятности реализации
угрозы и ее воздействия на активы, а также последствий этого. Вследствие
этого, чтобы снизить риски для активов, принимаются меры защитного про-
тиводействия. Эти меры противодействия могут состоять из защитных мер в
области ИТ (таких как средства сетевой защиты и смарт_карт), а также различ-
ных не относящихся к области ИТ мер (таких как служба охраны и процедуры).
Более широкое обсуждение защитных мер безопасности (контроля), их внед-
рение, а также управление содержится в стандартах ISO / IEC 27001 и ISO / IEC
27002.

«ÓÂÊǽ

ŸÈ½ÁÂÈÙÓØ Ë¾ÂÎÌÂÔÅ¿½ÂÏ

Ï;ÐÛÏ

°¿ÂÍÂÊÊËÎÏÙ

¿ÏËÉ ÔÏË
©ÂÍØÌÍËÏÅ¿ËÁÂÆÎÏ¿ÅÜ ¡ËÎϽÏËÔÊØ
Å ÎÈÂÁË¿½ÏÂÈÙÊË
ÉÅÊÅÉÅÄÅÍÐÛÏ

§ËÍÍÂÇÏÊØ ­ÅÎÇ
Å ÎÈÂÁË¿½ÏÂÈÙÊË
ÉÅÊÅÉÅÄÅÍÐÛÏ

ÁÈÜ

ÇÏÅ¿Ë¿

Рисунок 3. Понятия, используемые при оценке и их взаимосвязи

34
ISO / IEC 15408-1:2009

На владельцев активов может быть возложена ответственность за эти ак-


тивы и, следовательно, они должны иметь возможность обосновать решение
по приемлемости рисков, связанных с возможными угрозами для актива. При
обосновании такого решения они должны иметь возможность продемонстри-
ровать два важных момента, состоящих в том, что:
• меры защитного противодействия достаточны — если применение этих
мер действительно приносит то, что заявлено, в этом случае угрозы акти-
вам блокированы;
• защитные меры корректны — эти меры действительно приносят то, что за-
явлено.
Многие владельцы ресурсов не имеют знаний, экспертизы или иных источ-
ников информации, необходимых для того чтобы вынести заключение о доста-
точности или корректности защитных мер, и, возможно, не желают всецело до-
верять заверениям разработчиков защитных мер. Тогда они могут предпочесть
повысить свою уверенность в достаточности и корректности некоторых, или
всех, принятых ими защитных мер, заказав проведение оценки этих мер.
6.2.1 Достаточность защитных мер
В процессе оценки достаточность защитных мер анализируется посредством
структурированного документа, называемого «Целевые уровни безопасности»
(ЦУБ). В данном подразделе приводится только упрощенный его вид, более
детальное и полное описание можно найти в Приложении А.
Структурированный документ «Целевые уровни безопасности» начинает-
ся с описания активов и угроз этим активам. Затем в нем описываются меры
противодействия (в форме целей безопасности) и показывается, что эти меры
достаточны, чтобы противостоять угрозам. То есть, если применение этих мер
действительно приносит то, что заявлено по отношению к ним, тогда угрозы
активам блокированы.
Меры противодействия делятся на две группы:
a) цели безопасности для объекта оценки — они описывают меры противо-
действия, корректность которых будет определена в процессе оценки;
b) цели безопасности для операционной среды — они описывают меры про-
тиводействия, корректность которых не может быть определена в процес-
се оценки.
Такое разделение продиктовано следующими причинами:
• ISO / IEC 15408 применим только для оценивания корректности мер проти-
водействия в области ИТ, тем не менее, в операционной среде всегда на-
ходятся меры противодействия, не относящиеся к области ИТ (например,
персонал службы безопасности, процедуры);
• оценка корректности мер противодействия стоит временных и финансо-
вых затрат, что, возможно, сделает аттестацию всех мер ИТ_безопасности
практически невыполнимой;
• корректность некоторых мер безопасности, возможно, уже была оценена
в каком_либо другом процессе оценки, и их повторная аттестация будет
экономически неэффективна.
Для объекта оценки (правильность мер противодействия в области ИТ ко-
торого будет проверена в процессе оценки), заданные целевые уровни бе-
зопасности нуждаются в дальнейшей детализации задач безопасности в

35
ISO / IEC 15408-1:2009

«Требованиях к Функциям Безопасности» (ТФБ). Эти ТФБ сформулированы


стандартным языком (который описан в ISO / IEC 15408_2) для обеспечения точ-
ности и сопоставимости.
Говоря кратко, документ «Целевые уровни безопасности» показывает, что:
• требования к функциям безопасности соответствуют целям безопасности,
которые ставятся для ОО;
• цели безопасности, которые ставятся для ОО и операционной среды про-
тивостоят угрозам;
• и, следовательно, ТФБ и цели безопасности для операционной среды про-
тивостоят угрозам.
Из этого следует, что корректный объект оценки (отвечающий ТФБ), в ком-
бинации с корректной операционной средой (соответствующей целям безопас-
ности операционной среды), будет противостоять угрозам. В следующих двух
подразделах корректность объекта оценки и операционной среды обсуждают-
ся раздельно.
6.2.2 Корректность объекта оценки
Вообще говоря, объект оценки может быть неправильно спроектирован и ре-
ализован и, таким образом, может содержать ошибки, ведущие к появлению
уязвимости. Используя эти уязвимые места, нарушители могут повреждать
активы и / или злоупотреблять ими. Уязвимость может возникнуть от случай-
ных ошибок, допущенных в процессе разработки, от просчетов при проекти-
ровке, преднамеренном введении зловредных кодов, плохого тестирования
и т. д. Для установления степени доброкачественности объекта оценки могут
применяться различные действия, например:
– тестирование ОО;
– контроль различных видов проектирования ОО;
– контроль физической безопасности среды разработки ОО.
«Целевые уровни безопасности» содержат структурированное описание этих
действий определения корректности объекта оценки в форме «Требований До-
верия к Безопасности» (ТДБ). Эти ТДБ сформулированы стандартным языком
(описанным в ISO/IEC 15408-3), что обеспечивает точность и сопоставимость.
Если эти требования доверия удовлетворяются, то есть и уверенность в коррект-
ности ОО и тогда вероятность наличия уязвимых мест в этом ОО, которыми мо-
гут воспользоваться злоумышленники, заметно уменьшается. Степень доверия,
заложенная в корректности ОО, определяется самими «Требованиями Доверия к
Безопасности»: несколько «слабых» ТДБ приведут к понижению доверия, тогда
как достаточно «сильные» ТДБ, соответственно повысят уровень доверия.
6.2.3 Корректность операционной среды
Операционная среда так же может быть неверно спроектирована и реализова-
на, следовательно, может содержать ошибки, ведущие к появлению уязвимых
мест. Пользуясь этой уязвимостью, злоумышленники могут повредить активы
и / или злоупотребить ими.
Тем не менее, в ISO / IEC 15408 не содержится никаких гарантий относитель-
но корректности операционной среды. Другими словами операционная среда
не оценивается (см. 6.3). Однако, поскольку процесс оценки связан с ней, то
предполагается, что данная операционная среда на 100 % корректная операци-
онная среда для данных целей безопасности.

36
ISO / IEC 15408-1:2009

Однако, это вовсе не мешает пользователям этого ОО применять другие


методы для установления корректности операционной среды:
• если, для ОО, являющегося операционной системой, задачи безопасности
для операционной среды гласят: «операционная среда гарантирует, что эле-
менты сетей не имеющих доверия (например, Интернет) могут иметь доступ
к ОО только посредством протокола ftp», то потребитель может выбрать
какой_либо прошедший оценку файрволл и конфигурировать его таким об-
разом, чтобы доступ к ОО осуществлялся только через протокол ftp;
• если цели безопасности для операционной среды гласят: «эта операционная
среда будет гарантировать, что никто из всего административного персонала
не будет вести себя злонамеренно», тогда потребитель мог бы так сформули-
ровать свой контракт с административным персоналом, чтобы в него вошли
положения о штрафных санкциях за намеренное причинение ущерба, но это
решение не является частью оценки в рамках стандарта ISO/IEC 15408.
6.3 Оценка
Стандарт ISO / IEC 15408 признаёт два типа оценки: оценку целевых уровней
безопасности (ЦУБ) или объекта оценки (ОО), описанную ниже, и оценку раз-
личных ПЗ, которая определена в ISO / IEC 15408_3. Во многих местах ISO / IEC
15408 использует термин «оценка» (без уточняющих определений), подразу-
мевая, что имеется в виду оценка ЦУБ / ОО.
В ISO / IEC 15408 оценка ЦУБ / ОО проходит в два этапа:
a) оценка ЦУБ: где устанавливается достаточность ОО и операционной среды;
b) оценка ОО: где определяется корректность ОО (как было отмечено ранее,
оценка ОО не является аттестацией всей операционной среды).
Оценка ЦУБ проводится через критерии оценки (которые определяются в
ISO / IEC 15408-3, класс ASE), которые применяются к ЦУБ. Точный метод при-
менения критериев класса ASE определяется в зависимости от используемой
методологии оценки.
Процесс оценки ОО более сложен. Основные входные материалы, данные
для оценки ОО — это основание для оценки, которое включает в себя сам ОО
и ЦУБ, а также, как правило, и данные среды разработки, такие как проектная
документация или результаты тестов проектировщика.
Оценка ОО состоит в применении требований доверия к безопасности
(ТДБ), содержащихся в ЦУБ, к основаниям для оценки. Точный метод, который
необходимо применять для конкретных ТДБ, определяется исходя из использу-
емой методологии оценки. Как документировать результаты применения этих
требований, какие отчеты нужно составить и до каких именно деталей — это
определяется как используемой методологией оценки, так и схемой оценки, по
которой она выполняется.
Результатом процесса оценки ОО будет:
• либо утверждение о том, что не все ТДБ удовлетворяются, и, таким обра-
зом определенный уровень доверия к тому, что ОО соответствует требова-
ниям к функциям безопасности, заявленным в ЦУБ, не достигнут;
• либо утверждение о том, что все ТДБ удовлетворяются и, следовательно,
определенный уровень доверия к тому, что ОО удовлетворяет требовани-
ям к функциям безопасности, указанным в ЦУБ, достигнут.

37
ISO / IEC 15408-1:2009

Оценка ОО может проводиться после окончания разработки этого объекта


или параллельно с его разработкой. Метод формулировки результатов оценки
ЦУБ / ОО описывается в главе 9. Эти результаты также определяют ПЗ и паке-
ты, соответствие ОО которым может заявляться (эти положения и концепции
описаны в главе 7).

7 Составление требований безопасности


7.1 Операции
Компоненты функциональности и доверия могут быть использованы в точнос-
ти как определено в частях ISO / IEC 15408_2 и в ISO / IEC 15408_3, либо сформи-
рованы посредством использования разрешенных операций. В случае исполь-
зования операций, автор ПЗ / ЦУБ должен быть уверен, что потребности других
требований, зависящих от этого требования, удовлетворяются. Дозволенные
операции выбираются из следующего набора:
• итерация (iteration) — позволяет неоднократно использовать компонент,
при различном выполнении в нем операций;
• назначение (assignment) — позволяет специфицировать параметры;
• выбор (selection) — позволяет специфицировать один или более пунктов
из списка;
• уточнение (refinement) — позволяет осуществлять детализацию.
Операции назначения и выбора разрешены только там, где они специально
отмечены в каком_либо компоненте. Операции итерации и уточнения разре-
шены для всех компонентов. Ниже эти операции описаны более детально. При-
ложение к ISO/IEC 15408_2 содержит руководство по правомерному проведению
выбора или присваивания. Это руководство содержит нормативные инструкции
по выполнению операций, и этим инструкциям необходимо следовать, кроме тех
случаев, когда автор ПЗ/ЦУБ обосновывает отступление от них:
a) Пункт «нет» допускается как вариант для выполнения операции выбора,
только в том случае, если он непосредственно предусмотрен. Списки,
предусмотренные для выполнения операций выбора, не должны быть пус-
тыми. Если выбран вариант «нет», то никакие дополнительные варианты
не могут быть выбраны. Если пункт «нет» не предусмотрен в качестве оп-
ции операции выбора, тогда допускается сочетание вариантов в операции
выбора, с помощью союзов «и» и «или», если только в операции выбора
в однозначном виде не определено «выбрать одно из».
Операции выбора, при необходимости, могут, сочетаться с итерацией.
В этом случае применимость варианта, выбранного для каждой итерации,
не должна относиться к предмету другой итерационной операции выбора,
поскольку они рассматриваются как исключающие.
b) Чтобы определить, когда вариант «нет» был бы правомерным для завер-
шения операции назначения, нужно обратиться к приложению в части
ISO / IEC 15408-2.
7.1.1 Операция итерации
Операция итерации может быть выполнена над любым компонентом. Автор
ПЗ / ЦУБ выполняет операцию итерации путём включения различных требова-
ний, основанных на том же самом компоненте. Каждая итерация компонента

38
ISO / IEC 15408-1:2009

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


зуются завершением операций назначения и выбора другим способом, либо
выполнением уточнения, также другим образом. Различные итерации должны
быть идентифицированы уникальным образом, чтобы обеспечить их четкие яс-
ные логические обоснования и прослеживание от или до этих требований.
Важно отметить, что иногда, вместо того чтобы проводить итерации компо-
нентов, операция итерации может быть использована с компонентами, в кото-
рых также можно выполнять операции назначения параметрам величин из об-
ласти или списка. В этом случае автор может выбрать наиболее подходящую
альтернативу, учитывая соображения о том, что больше соответствует реальной
необходимости: одно логическое обоснование для всего диапазона величин или
обоснование каждой в отдельности. Автор также всегда должен иметь в виду
следующий вопрос: «нужны ли индивидуальные прослеживания этих величин?»
7.1.2 Операция назначения
Операция назначения проводится там, где данный компонент содержит эле-
мент с параметром, который может задать автор ПЗ / ЦУБ. Этот параметр может
быть представлен неограниченной переменной, либо правилом, суживающим
область допустимых значений переменной до заданного диапазона. Какой бы
элемент любого ПЗ не содержал назначения, его автор может выполнить одно
из следующих четырех действий:
a) Оставить назначение невыполненным. Автор ПЗ может включить в него
функциональные требования отказа от аутентификации (FIA_AFL.1.2) сле-
дующим образом: «при достижении или превышении заданного числа
неудачных попыток аутентификации, функции безопасности ОО должны
прекратить попытки в связи с “исковой давностью”».
b) Выполнить назначение. Например, автор ПЗ может ввести в него функцио-
нальные требования отказа от аутентификации (FIA_AFL.1.2) следующим
образом: «при достижении или превышении заданного числа неудачных
попыток аутентификации, функции безопасности ОО в дальнейшем долж-
ны предотвращать привязку внешнего объекта к какому_либо элементу».
c) Сузить назначение, чтобы в дальнейшем ограничить диапазон разрешен-
ных значений. Например, автор ПЗ может ввести в него функциональные
требования отказа от аутентификации (FIA_AFL.1.1) следующим образом:
«Функции безопасности ОО будут фиксировать, когда произойдёт от 4 до
9 неудачных попыток аутентификации…»
d) Превратить назначение в выбор, сужая, таким образом, рамки этого на-
значения. Например, автор ПЗ может включить в него функциональные
требования отказа от аутентификации (FIA_AFL.1.2) следующим обра-
зом: «при достижении или превышении заданного числа неудачных попы-
ток аутентификации, функции безопасности ОО должны препятствовать
пользователю обращаться к субъекту в будущем, уведомив об этом адми-
нистратора».
Какой бы элемент целевых уровней безопасности не содержал операцию
назначения, автор этого ЦУБ должен выполнить эту операцию, как указано
выше в варианте b). Варианты a), c) и d), для ЦУБ не допускаются.
Величины, выбранные в вариантах a), c) и d) должны соответствовать ука-
занному типу, требуемому назначением. В случае, когда назначение должно

39
ISO / IEC 15408-1:2009

быть выполнено для целой группы (предметов), можно составить список груп-
пы предметов, но можно дать и описание группы, из которого его элементы
могут выводиться следующим образом (при условии, что ясно, какие именно
предметы имеются в виду):
• все предметы;
• все предметы типа Х;
• все предметы, кроме предмета А.
7.1.3 Операция выбора
Операция выбора осуществляется там, где данный компонент содержит эле-
мент, в котором выбор из нескольких отдельных предметов должен быть сде-
лан автором ПЗ / ЦУБ. В каком бы случае элемент ПЗ не содержал операцию
выбора, его автор может сделать одно из следующих трех действий:
a) оставить операцию выбора невыполненной;
b) выполнить операцию выбора путем отбора одного или нескольких пред-
метов;
c) ограничить выбор, удалив несколько вариантов, но оставив два или бо-
лее.
Какой бы ни был элемент целевых уровней безопасности, содержащий вы-
бор, автор ЦУБ должен выполнить операцию выбора как указано выше, в ва-
рианте b). Варианты a) и c) для ЦУБ не допускаются. Элемент или элементы,
выбранные в b) и c), должны быть взяты из элементов, предусмотренных в этой
операции выбора.
7.1.4 Операция уточнения
Операция уточнения может выполняться в любом требовании. Автор ПЗ / ЦУБ
выполняет операцию уточнения путём изменения этого требования. Первое
правило уточнения состоит в том, что объект оценки, соответствующий уточнен-
ным требованиям, также должен соответствовать неуточненным требованиям
в контексте ПЗ / ЦУБ (то есть, уточненные требования должны быть «жестче»,
чем первоначальные требования). Если операция уточнения не соответствует
этому правилу, тогда требование, полученное в результате этой операции, бу-
дет рассматриваться и обрабатываться как расширенное требование.
Единственное исключение из этого правила состоит в том, что автор ПЗ / ЦУБ
имеет право уточнять требования к функциям безопасности с целью приме-
нить их к некоторым, но не всем, предметам, объектам, операциям, атрибутам
безопасности и / или внешним сущностям. Однако, это исключение не распро-
страняется на уточнение ТФБ, взятых из тех ПЗ, соответствие которым заяв-
ляется. Эти ТФБ не могут быть уточнены с целью применить их к меньшему
числу предметов, объектов, операций, атрибутов безопасности и / или внешних
сущностей, чем ТФБ в ПЗ.
Второе правило уточнения состоит в том, что уточнение должно быть свя-
зано с исходным компонентом. Особым случаем уточнения данных будет ре-
дакционное уточнение, при котором в требования вносятся малые изменения,
такие как перефразирование предложения для надлежащего соответствия
грамматическим правилам, либо улучшение читабельности. Однако, эта моди-
фикация не разрешает какое_либо изменение смысла требования.

40
ISO / IEC 15408-1:2009

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


Между компонентами могут существовать зависимости. Зависимости возни-
кают, если какой_либо компонент не самодостаточен и для обеспечения фун-
кциональной безопасности или определенного уровня доверия к безопаснос-
ти, предполагает наличие другого компонента. Функциональные компоненты
в ISO / IEC 15408_2, как правило, связаны зависимостями с другими функци-
ональными компонентами, равно как и некоторые компоненты доверия к бе-
зопасности в ISO / IEC 15408_3, которые могут иметь зависимости от других
компонентов ISO / IEC 15408-3. Также можно определить зависимости компо-
нентов ISO / IEC 15408_2 от компонентов ISO / IEC 15408_3. Тем не менее, это не
исключает наличие расширенных функциональных компонентов, зависящих от
компонентов доверия к безопасности или наоборот.
Описание зависимости компонентов является частью определения компонен-
та в ISO/IEC 15408_2 и ISO/IEC 15408-3. Если в ПЗ и ЦУБ включаются требова-
ния, основанные на имеющих зависимости компонентах, для обеспечения пол-
ноты требований безопасности к объекту оценки эти зависимости должны быть
удовлетворены. Зависимости следует учитывать и при построении пакетов.
Иными словами, если компонент А зависим от компонента В, это значит, что в
любом случае, когда ПЗ/ЦУБ содержит требование безопасности, основанное на
компоненте А, ПЗ/ЦУБ должен также содержать один из следующих вариантов:
a) требование безопасности на основе компонента В;
b) требование безопасности, основанное на компоненте иерархически бо-
лее высоком, чем В;
c) обоснование, почему ПЗ / ЦУБ не содержит требования безопасности, ос-
нованного на компоненте В.
В случаях a) и b), когда требование безопасности включено по причине на-
личия зависимости, может быть необходимым выполнение операций (назначе-
ния, итерации, уточнения или выбора) над этим требованием, способом, позво-
ляющим убедиться, что операция удовлетворяет эту зависимость.
В случае с) обоснование отсутствия требования безопасности должно объ-
яснять:
• либо почему зависимость не полезна или в ней нет необходимости;
• либо, что зависимость обращена к операционной среде ОО и, в этом слу-
чае, обоснование должно описывать, как цели и задачи безопасности для
операционной среды приводятся в соответствие с этой зависимостью;
• либо, что эта зависимость адресуется другими требованиями к функциям
безопасности, каким либо иным образом (расширенные ТФБ, комбинация
ТФБ и т. п.).
7.3 Расширенные компоненты
В ISO / IEC 15408 требования обязательно должны основываться на компонен-
тах из ISO / IEC 15408_2 или ISO / IEC 15408-3 лишь с двумя допустимыми исклю-
чениями:
a) имеются цели безопасности для объекта оценки, которые не могут быть
переведены в ТФБ или имеются требования третьей стороны (например,
законы, стандарты), которые не могут быть переведены в ТДБ (например,
относящиеся к оценке криптографии);

41
ISO / IEC 15408-1:2009

b) цели безопасности могут быть выражены на основе компонентов ISO / IEC


15408_2 и / или ISO / IEC 15408-3, но лишь с большими трудностями и / или
сложностями.
В обоих случаях от автора ПЗ / ЦУБ требуется четко и недвусмысленно оп-
ределить его собственные компоненты. Эти вновь определенные компоненты
называются расширенными компонентами. Точно определенный расширенный
компонент нужен для того, чтобы обеспечить контекст и смысл для расширен-
ных ТФБ и ТДБ, основанных на этом компоненте. После того, как новые рас-
ширенные компоненты точно определены, автор ПЗ / ЦУБ может использовать
их как основу для новых ТФБ и ТДБ и использовать последние таким же об-
разом, как и стандартные ТФБ и ТДБ. Начиная с этого момента, не существу-
ет различий между ТФБ и ТДБ, основанными на стандарте ISO / IEC 15408, и
ТФБ и ТДБ, основанными на расширенных компонентах. Дальнейшие требо-
вания к расширенным компонентам содержатся в классах «Определение рас-
ширенных компонентов» (классы APE_ECD и ASE_ECD), описанных в части
ISО / IEC 15408_3.

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


8.1 Введение
Чтобы позволить группам и сообществам потребителей выражать свои потреб-
ности в области безопасности и способствовать написанию «Целевых уровней
безопасности», этот раздел ISO / IEC 15408 предоставляет два специальных
структурных компонента: пакеты и Профили Защиты (ПЗ). Эти структуры опи-
саны подробнее в разделах 8.2 и 8.3. Раздел 8.4 объясняет, как эти структуры
могут быть использованы.
8.2 Пакеты
Пакет — это поименованный набор требований безопасности. Существуют
либо:
• функциональные пакеты, содержащие только ТФБ;
• пакеты доверия к безопасности, содержащие только ТДБ.
Смешанные пакеты, содержащие как функциональные требования (ТФБ),
так и требования доверия (ТДБ), не допускаются.
Пакет может быть определен какой_либо стороной и предназначен для мно-
гократного использования и определяет требования, известные как полезные
и эффективные для достижения установленных целей. Допускается примене-
ние пакетов при создании более крупных пакетов профилей защиты и целевых
уровней безопасности. Поскольку в настоящее время критерии оценки пакетов
еще не существуют, пакетом может быть любой набор ТФБ или ТДБ.
Примерами пакетов требований доверия к безопасности могут служить «Уров-
ни оценки доверия» (УОД) определенные в ISO/IEC 15408_3. На момент написа-
ния этой версии ISO/IEC 15408 функциональные пакеты не были созданы.
8.3 Профили защиты
В то время как документ «Целевой уровень безопасности» всегда описывает
конкретный объект оценки (например, MinuteGapv18.5 Firewall), профиль защи-

42
ISO / IEC 15408-1:2009

ты предназначен для описания типа ОО (например, firewalls). Следовательно,


один и тот же ПЗ можно использовать как шаблон для составления разнооб-
разных ЦУБ, в различных оценках. Детальное описание ПЗ приведено в при-
ложении В.
В общем случае, «Целевой уровень безопасности» описывает требования к
объекту оценки и написан его разработчиком, в то время как профиль защиты
описывает общие требования к типу ОО и поэтому обычно написан:
• сообществом пользователей, стремящихся прийти к консенсусу относи-
тельно требований для данного типа ОО;
• разработчиком ОО, или группой разработчиков подобных ОО, желающих
сформулировать минимальный уровень для объектов этого типа;
• правительственной организацией или большой корпорацией, задающей
свои требования в качестве составляющей процесса приобретения.
Профиль защиты определяет допускаемый тип соответствия целевых уров-
ней безопасности этому ПЗ. Иными словами, профиль защиты формулирует
(в декларации соответствия, см. В.5), что разрешенные типы соответствия для
ЦУБ следующие:
• если профиль защиты заявляет, что требуется строгое соответствие, ЦУБ
должно соответствовать ПЗ в строгой форме;
• если профиль защиты заявляет, что требуется очевидное соответствие,
тогда ЦУБ должен соответствовать ПЗ либо в строгой, либо в очевидной
форме.
Иными словами, очевидное соответствие ЦУБ и ПЗ разрешено только в том
случае, если ПЗ даёт на это однозначное разрешение.
Если какой_либо Целевой уровень безопасности заявляет о соответствии
нескольким профилям защиты, то он должен соответствовать (как показано
выше) каждому из этих ПЗ, причем таким образом, как предписывает каждый
из этих ПЗ. Это может означать, что Целевой уровень безопасности соответ-
ствует некоторым ПЗ строго, а другим очевидным образом.
Следует отметить, что этот Целевой уровень безопасности либо полностью
соответствует конкретному профилю защиты, либо нет. Стандарт ISO/IEC 15408
не признает «частичного» соответствия. По этой причине, ответственность ав-
тора профиля защиты — убедиться в том, что этот ПЗ не создаёт чрезмерных
затруднений, лишая, таким образом, авторов ПЗ/ЦУБ возможности заявить об
их соответствии этому ПЗ. В общем случае Целевой уровень безопасности экви-
валентен или более ограничительный, чем ПЗ, если:
• все объекты оценки, отвечающие требованиям ЦУБ, также соответствуют
ПЗ;
• все операционные среды, соответствующие ПЗ, также соответствуют
ЦУБ.
Говоря простым языком, документ «Целевой уровень безопасности» должен
накладывать те же самые, или большие ограничения на объект оценки, и те же
самые, или менее жесткие, ограничения на операционную среду этого ОО.
Это общее положение может быть более конкретизировано для различных
подразделов документа «Целевой уровень безопасности»:
Определение проблем безопасности. Обоснование соответствия, приве-
денное в ЦУБ должно показать, что определение проблем безопасности в нем

43
ISO / IEC 15408-1:2009

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


ти в ПЗ. Это означает, что:
• все объекты оценки, которые будут соответствовать определению проблем
безопасности, содержащихся в ЦУБ, также соответствуют определению
проблем безопасности в ПЗ;
• все операционные среды, которые соответствуют определению проблем
безопасности в ПЗ, также будут соответствовать определению проблем
безопасности, содержащихся в ЦУБ.
Цели безопасности. Обоснование соответствия в ЦУБ должно показать,
что цели безопасности в нем эквивалентны (или более строги и сужены), чем
цели безопасности в ПЗ. Это означает, что:
• все объекты, которые будут отвечать целям и задачам безопасности для
ОО, содержащимся в ЦУБ, также соответствуют целям безопасности для
ОО в ПЗ;
• все операционные среды, соответствующие целям безопасности для опе-
рационной среды в ПЗ, также будут отвечать целям безопасности для опе-
рационной среды, содержащимся в ЦУБ.
Если специально указано строгое соответствие профилям защиты, тогда на-
кладываются следующие требования:
a) Определение проблемы безопасности — документ «Целевой уровень
безопасности» должен содержать определение задачи безопасности из
ПЗ, могут задаваться дополнительные угрозы и Политики Безопасности
Организации (ПБО), но дополнительные условия могут и не задаваться.
b) Цели безопасности — в документе «Целевой уровень безопасности» бу-
дут содержаться:
• все цели безопасности для объекта оценки, содержащиеся в ПЗ, но могут
задаваться и дополнительные цели безопасности для этого ОО;
• все цели безопасности для операционной среды (с одним лишь исключе-
нием, указанным в следующем абзаце), но дополнительные цели безопас-
ности могут и не задаваться;
• можно специально указать, что содержащиеся в ПЗ определенные цели бе-
зопасности для операционной среды — это цели безопасности для конкрет-
ного ОО из ЦУБ. Это называется переназначением цели безопасности. Если
цель безопасности ОО переназначена, то обоснование целей безопасности
должно ясно указать, какое допущение, или его часть, более не актуально.
c) Требования безопасности — документ «Целевой уровень безопаснос-
ти» должен содержать все ТФБ и ТДБ из профиля защиты, но может за-
являть наличие дополнительных или иерархически более сильных ТФБ и
ТДБ. Выполнение операций на компонентах из ЦУБ должно согласовы-
ваться с выполнением операций на компонентах из ПЗ: либо в ЦУБ будут
использованы операции аналогичные тем, что в ПЗ, либо такие, которые
сделают требования более строгими и ограничительными (применимы
правила уточнения).
Если для профилей защиты специально указано очевидное соответствие,
тогда должны применяться следующие требования:
• «Целевой уровень безопасности» должен содержать обоснование, почему
он считается «эквивалентным или более ограничительным» чем ПЗ;

44
ISO / IEC 15408-1:2009

¬ÍËÑÅÈÙĽÖÅÏØ
³ÂÈÅ
¾ÂÄË̽ÎÊËÎÏÅ ¯Í¾˿½ÊÅÜ
¾ÂÄË̽ÎÊËÎÏÅ
«ÌÍÂÁÂÈÂÊÅÂ
ÌÍ˾ÈÂÉ ¯Í¾˿½ÊÅÜ
¾ÂÄË̽ÎÊËÎÏÅ ÇÑÐÊÇÓÅÜÉ
ÐÀÍËÄØ ¾ÂÄË̽ÎÊËÎÏÅ
¬ËÈÅÏÅÇÅ
¾ÂÄË̽ÎÊËÎÏÅ ¯Í¾˿½ÊÅÜ
ËÍÀ½ÊÅĽÓÅÅ ÁË¿ÂÍÅÜ
ÓÂÈŠǾÂÄË̽ÎÊËÎÏÅ
¡ËÌÐÖÂÊÅÜÁÈÜ
ËÌÂͽÓÅËÊÊËÆ
ÎÍÂÁØ

«ÌÓÅËʽÈÙÊË ºÇ¿Å¿½ÈÂÊÏÊØ ¿ÎÂ


ÁËÌËÈÊÅÏÂÈÙÊØ ÅÈžËÈÂÂÎÏÍËÀÅÂ
Ë̽ÎÊËÎÏÅÅ ¯ËÈÙÇË
ÌËÈÅÏÅÇÅ ÎÏÍËÀË ³ÂÈ¿ØÂÐÍË¿ÊÅ «ÌÓÅËʽÈÙÊË
¾ÂÄË̽ÎÊËÎÏÅ ÎËËÏ¿ÂÏÎÏ¿Å ¾ÂÄË̽ÎÊËÎÏÅ ÁËÌËÈÊÅÏÂÈÙÊØÂ
ËÍÀ½ÊÅĽÓÅÅ ÅÈžËÈÂÂÎÏÍËÀÅÂ
«ÌÍÂÁÂÈÂÊÅ ¯Í¾˿½ÊÅÜ Ï;˿½ÊÅÜ
ÌÍ˾ÈÂÉ ¾ÂÄË̽ÎÊËÎÏÅ ÁË¿ÂÍÅÜ
¯ËÈÙÇË Ç¾ÂÄË̽ÎÊËÎÏÅÅ
¾ÂÄË̽ÎÊËÎÏÅ ÎÏÍËÀËÂ
ÐÀÍËÄØ ¯Í¾˿½ÊÅÜ ÎËËÏ¿ÂÏÎÏ¿Å Ï;˿½ÊÅÜ
¬ËÈÅÏÅÇÅ ÇÑÐÊÇÓÅÜÉ ÇÑÐÊÇÓÅÜÉ
¾ÂÄË̽ÎÊËÎÏÅ ¾ÂÄË̽ÎÊËÎÏÅ ¾ÂÄË̽ÎÊËÎÏÅ
ËÍÀ½ÊÅĽÓÅÅ
ÓÂÈÅ ¯Í¾˿½ÊÅÜ
ÁË¿ÂÍÅÜ
³ÂÈÅÅĽÁ½ÔŠǾÂÄË̽ÎÊËÎÏÅ
««ÎËËÏ¿ÂÏÎÏ¿ÐÂÏ ¾ÂÄË̽ÎÊËÎÏÅ
¡ËÌÐÖÂÊÅÜÁÈÜ
ËÌÂͽÓÅËÊÊËÆ
ÎÍÂÁØ

««
«ÌÂͽÓÅËÊʽÜ
ÎÍÂÁ½ ÎËËÏ¿ÂÏÎÏ¿ÐÂÏ
««

Рисунок 4. Взаимосвязи между содержанием ПЗ, ЦУБ и ОО

45
ISO / IEC 15408-1:2009

• очевидное соответствие позволяет автору профиля защиты описывать


общую задачу безопасности, которая должна быть решена, и обеспечить
общие ориентиры по требованиям необходимым для ее решения, зная, что
имеется более чем один способ задания решения.
Оценка профиля защиты является опциональной. Оценка выполняется пу-
тем применения к нему критериев класса APE в виде списка, приведенного в
ISO / IEC 15408_3. Цель такой оценки заключается в том, чтобы продемонстри-
ровать, что ПЗ полный, последовательный, единообразный и технически ис-
правный, а также что он подходит в качестве шаблона для построения нового
ПЗ или ЦУБ.
Формирование ПЗ / ЦУБ на основе уже оцененного профиля защиты имеет
два преимущества:
• риск существования ошибок, неясностей или пробелов в профиле защиты
намного уменьшается: если какие_либо проблемы с ПЗ (которые могли бы
быть обнаружены при проведении его оценки) найдены во время написа-
ния или оценки нового ЦУБ, то на исправление этого ПЗ может потребо-
ваться значительное время;
• часто при оценке новых ПЗ / ЦУБ результаты оценки уже проверенного про-
филя защиты могут использоваться повторно, что приводит к уменьшению
усилий требуемых для оценки новых ПЗ / ЦУБ.
8.4 Использование профилей защиты и пакетов
Если какой_либо Целевой уровень безопасности заявляет о совместимости
с одним или более пакетами и / или профилями защиты, то оценка этого ЦУБ
должна (среди других его характеристик) показать, что он действительно со-
ответствует этим пакетам и / или этим ПЗ, о соответствии которым заявляет.
Детали этого определения соответствия можно найти в Приложении А.
Это делает возможным следующий процесс:
a) организация, стремящаяся приобрести продукт ИТ_безопасности конк-
ретного типа разрабатывает свои потребности безопасности в виде профиля
защиты, а затем проводит его оценку и публикует её;
b) разработчик принимает этот профиль защиты, пишет Целевой уровень
безопасности, заявляющий о соответствии этому ПЗ, а потом проводит оценку
этого ЦУБ;
c) затем разработчик собирает ОО (либо использует существующий) и оце-
нивает его, ориентируясь на этот ЦУБ.
В результате, разработчик сможет доказать соответствие объекта оценки
нуждам безопасности этой организации — следовательно, организация может
приобретать этот ОО. Аналогичная цепь рассуждений относится и к пакетам.
8.5 Использование составных профилей защиты
ISO / IEC 15408 также позволяет профилю защиты соответствовать другим ПЗ,
позволяя, таким образом, создавать цепочки профилей защиты, в которых
каждый последующий основывается на предыдущем. Например, можно взять
профили защиты для интегральной схемы и для ОС смарт_карты и создать ПЗ
для всей смарт_карты (ИС и ОС), который заявляет о соответствии обоим. Пос-
ле этого, можно писать профиль защиты по смарт_картам для общественного

46
ISO / IEC 15408-1:2009

транспорта на основе ПЗ для смарт_карт и ПЗ для загружаемого на них прило-


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

9 Результаты оценки
9.1 Введение
В этом разделе представлены ожидаемые результаты оценок ПЗ и ЦУБ / ОО
выполненных согласно ISO / IEC 18045:
• оценка профиля защиты позволяет создавать каталоги оцененных ПЗ;
• оценка Целевого уровня безопасности дает промежуточные результаты,
которые используются в рамках оценки ОО;
• оценка ЦУБ / ОО также позволяет создавать каталоги оцененных объек-
тов оценки. Во многих случаях эти каталоги скорее будут относиться к
ИТ_продуктам, из которых получены эти ОО, чем к этим конкретным ОО.
Следовательно, существование ИТ_продукта в каталоге не должно воспри-
ниматься как признак того, что весь ИТ_продукт уже прошел оценку — ре-
альный объем оценки Целевого уровня безопасности или объекта оценки
определяется ЦУБ. Примеры таких каталогов можно найти в списке лите-
ратуры.
Целевые уровни безопасности могут быть сделаны либо на основе пакетов
или ПЗ, прошедших оценку, либо на ещё не оцененных ПЗ. Однако, это не
обязательно — ЦУБ, вообще говоря, не должны непременно основываться на
чем_либо.
Процесс оценки должен давать объективные и повторяемые результаты,
на которые можно будет ссылаться, как на свидетельство, даже при отсутс-
твии абсолютно объективной шкалы для представления результатов оценки
безопасности. Наличие совокупности критериев оценки — это необходимое

«ÓÂÊÅÏÙ ­ÂÄÐÈÙϽÏØ «ÓÂÊÂÊÊØ ­ÂÂÎÏͬ¤


¬¤ ËÓÂÊÇŬ¤ ¬¤

«ÓÂÊÅÏÙ ­ÂÄÐÈÙϽÏØ «ÓÂÊÂÊÊØÂ


³°ž ËÓÂÊÇų°ž ³°ž

«ÓÂÊÅÏÙ ­ÂÄÐÈÙϽÏØ «ÓÂÊÂÊÊØ ­ÂÂÎÏÍ««


«« ËÓÂÊÇÅ«« ««

Рисунок 5. Результаты оценки

47
ISO / IEC 15408-1:2009

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


результатам и создал техническую основу для общего признания результатов
оценки полномочными органами в этой области.
Результат оценки представляет собой итоговые данные специфического
типа исследований характеристик безопасности ОО. Однако, такой результат
оценки не гарантирует пригодность к использованию в какой_либо конкретной
среде применения. Решение о приемке ОО к использованию в некой конкрет-
ной среде применения основывается на учете множества аспектов безопаснос-
ти, включая и упомянутые выводы оценки.
9.2 Результаты оценки профилей защиты
ISO / IEC 15408_3 содержит критерии оценки, позволяющие оценщику устано-
вить, является ли ПЗ полным, непротиворечивым и технически обоснованным,
и, следовательно, подходящим для использования при разработке Целевого
уровня безопасности.
Результаты оценки также должны включать «Декларацию соответствия»
(см. 9.4).
9.3 Результаты оценки целевых уровней безопасности
и объектов оценки
ISO / IEC 15408_3 содержит критерии оценки, позволяющие эксперту по оцен-
ке установить, имеется ли достаточная уверенность в том, что объект оценки
удовлетворяет требованиям к функциям безопасности, выраженным в Целевом
уровне безопасности. Таким образом, результатом оценки ОО будет деклара-
ция «соответствия / несоответствия» сформулированному ЦУБ. Если результат
оценки, как ЦУБ, так и ОО, гласит «соответствует», то рассматриваемый про-
дукт может быть включен в реестр. Результаты оценки также должны включать
«Декларацию соответствия» как определено в 9.4.
Возможно, результаты оценки в дальнейшем будут использованы в процес-
се сертификации, но этот процесс находится за рамками ISO / IEC 15408.
9.4 Декларация соответствия
Декларация соответствия указывает на источник комплекса требований, ко-
торым соответствуют прошедшие оценку профили защиты и Целевые уровни
безопасности. Декларация соответствия содержит декларацию соответствия
стандарту ISO / IEC 15408, которая:
a) описывает ту версию стандарта ISO / IEC 15408, о соответствии которой
заявлено в профиле защиты или Целевом уровне безопасности;
b) описывает соответствие и стандарту ISO / IEC 15408_2 (функциональные
требования в области безопасности) одним из двух вариантов:
• «соответствие ISO / IEC 15408-2» — профиль защиты или Целевой
уровень безопасности соответствует ISO / IEC 15408-2, если все функ-
циональные требования к безопасности в этом ПЗ или ЦУБ основаны
только на функциональных компонентах из ISO / IEC 15408-2;
• «расширение ISO / IEC 15408-2» — профиль защиты или Целевой
уровень безопасности является расширенным, по отношению к
ISO / IEC 15408-2, если по крайней мере одно требование функцио-

48
ISO / IEC 15408-1:2009

нальной безопасности в этом ПЗ или ЦУБ, не основано на функцио-


нальных компонентах из ISO / IEC 15408-2.
c) описывает соответствие профиля защиты и Целевого уровня безопаснос-
ти стандарту ISO / IEC 15408_3 (требования доверия к безопасности) одним
из двух вариантов:
• «соответствие ISO / IEC 15408-3» — профиль защиты или Целевой
уровень безопасности соответствует ISO / IEC 15408-3, если все ТДБ,
содержащиеся в этом ПЗ или ЦУБ, основаны только на компонентах
доверия из ISO / IEC 15408-3;
• «расширение ISO / IEC 15408-3» — профиль защиты или Целе-
вой уровень безопасности является расширенным по отношению к
ISO / IEC 15408-3, если по крайней мере одно ТДБ, содержащиеся в
этом ПЗ или ЦУБ, не основано на компонентах доверия из ISO / IEC
15408-3.
Кроме того, декларация соответствия может включать утверждения, сде-
ланные относительно пакетов требований. В этом случае декларация будет
соответствовать одному из двух вариантов:
• «Соответствие именованному пакету» — профиль защиты или Целевой
уровень безопасности соответствует ранее определенному пакету (напри-
мер, конкретному УОД) если:
• либо ТФБ этого профиля защиты или Целевого уровня безопасности иден-
тичны ТФБ пакета;
• либо ТДБ этого профиля защиты или Целевого уровня безопасности иден-
тичны ТДБ этого пакета.
• «Усиление именованного пакета» — профиль защиты или Целевой уровень
безопасности будут являться усилением ранее определенного пакета если:
• ТФБ этого профиля защиты или Целевого уровня безопасности содержат
все ТФБ пакета, но имеют, по крайней мере, одно дополнительное ТФБ или
ТФБ, которое иерархически выше, чем ТФБ в этом пакете;
• ТДБ этого профиля защиты или Целевого уровня безопасности содержат
все ТДБ пакета, но также имеют, по крайней мере, одно дополнительное
ТДБ или ТДБ, которое иерархически выше, чем ТДБ этого пакета.
Заметим, что в случае успешного прохождения оценки ОО данному Целево-
му уровню безопасности, любые декларации о соответствии ЦУБ, также спра-
ведливы и для этого объекта оценки. Следовательно, ОО также может быть
соответствующим, например ISO / IEC 15408-2.
И, наконец, декларация соответствия, также, может включать два утвержде-
ния относительно профилей защиты:
a) «соответствие профилю защиты» — ПЗ или ОО соответствует
конкретному(ым) ПЗ, перечисленному(ым) как часть результатов соответ-
ствия.
b) «формулировка соответствия» (только для ПЗ) — описывает каким обра-
зом ПЗ и ЦУБ должны соответствовать этому ПЗ: строго или очевидно.
Дополнительную информацию по этой декларации соответствия смотри-
те в «Приложении В».

49
ISO / IEC 15408-1:2009

9.5 Использование результатов оценки целевых


уровней безопасности и объектов оценки
После того, как Целевой уровень безопасности и объект оценки были оценены,
владельцы активов могут иметь определенный уровень доверия (как опреде-
лено в ЦУБ) к тому, что этот ОО вместе с операционной средой, противостоят
угрозам. Владелец этих активов может использовать результаты оценки для
того, чтобы решить, можно ли принять риски, открывая свои активы воздей-
ствию угрожающих факторов. Тем не менее, владелец актива должен тща-
тельно проверить следующее:
• отвечает ли определение проблем безопасности, содержащееся в ЦУБ,
реальной задаче безопасности, стоящей перед владельцем этого актива;
• соответствует ли операционная среда владельца актива целям безопас-
ности для операционной среды, описанной в ЦУБ (или её можно привести
в соответствие).
Если не проходит ни тот, ни другой вариант, значит, этот объект оценки не
подходит целям владельца актива.
Кроме этого, когда оцененный ОО поступает в эксплуатацию, остаётся ве-
роятность, что содержащиеся в нем непроявившиеся дефекты, ошибки или
слабые места проявятся. В таком случае разработчик может внести поправки
в объект оценки (исправить уязвимые места), либо заменить Целевой уровень
безопасности, чтобы исключить уязвимые места из области оценки. В любом
случае, результаты предыдущей оценки более не будут действительны.
Если будет необходимо восстановить доверие, нужно обязательно провести
переоценку. Для этой повторной оценки можно использовать ISO / IEC 15408,
однако подробные процедуры для переоценки не содержатся в этой части
ISO / IEC 15408.

Примечание.
Полный текст первой части стандарта ISO / IEC 15408 содержит также несколько прило-
жений:
1. Приложение А: Спецификация целевых уровней безопасности.
2. Приложение В: Спецификация профилей защиты.
3. Приложение С: Руководство по операциям.
4. Приложение D: Cоответствие профилей защиты.
Однако, эти приложения не включены в настоящее печатное издание перевода стан-
дарта, в связи с ограничениями объема печатной версии. Эти приложения есть в элект-
ронной версии этого проекта стандарта, которую вы можете найти на официальном пор-
тале ИТ-директоров GlobalCIO (www.globalcio.ru).

50
ISO / IEC 15408-1:2009

Список литературы
Этот список литературы содержит ссылки на материалы и стандарты, которые
могут быть полезными читателям ISO / IEC 15408. Если документы не имеют
конкретной даты, то рекомендуется выбирать самое последнее издание этого
документа.
Cтандарты и руководства ISO / IEC
[1] ISO / IEC 15292, Information technology — Security techniques — Protection
Profile registration Procedures.
[2] ISO / IEC 15443 (все части), Information technology — Security techniques —
A framework for IT security assurance.
[3] ISO / IEC 15446, Information technology — Security techniques — Guide for the
production of Protection Profilesand Security Targets.
[4] ISO / IEC 19790, Information technology — Security techniques — Security
requirements for cryptographic modules.
[5] ISO / IEC 19791, Information technology — Security techniques — Security
assessment of operational Systems.
[6] ISO / IEC 27001, Information technology — Security techniques — Information
security management systems requirements.
[7] ISO / IEC 27002, Information technology — Security techniques — Code of
practice for information security management.
Другие стандарты и руководства
[8] IEEE Std 610.12-1990, Institute of Electrical and Electronics Engineers,
Standard Glossary of Software Engineering Terminology.
[9] Портал Common Criteria CCRA, www.commoncriteriaportal.org.

51
ISO / IEC 15408-1:2009

Союз ИТ-директоров России (СоДИТ) — межрегиональная общественная организа-


ция, объединяющая в своих рядах руководителей ИТ-служб коммерческих предприятий
и государственных ведомств. Миссия Союза — содействие модернизации экономики
России за счет эффективного внедрения ИТ через повышение профессионализма и ста-
туса руководителя ИТ службы. В задачи СоДИТ входят:
— разработка и пропаганда рекомендаций, стандартов, создание единых информа-
ционных ресурсов, справочников;
— поддержка региональных клубов ИТ-директоров;
— участие в экспертизах крупных ИТ проектов и разработка рекомендаций и предло-
жений правительству России;
— организация и участие в международных конференциях, деловых поездках по об-
мену опытом с коллегами из других стран;
— взаимодействие с бизнес ассоциациями и ВУЗами, некоммерческими организаци-
ями, представленными на ИТ рынке, прессой;
— разработка и внедрение систем сертификаций CIO и поставщиков в области ИТ,
организация конкурсов и премий».
Высшим руководящим органом Союза является его Съезд, который собирается
ежегодно и избирает Правление и Директора, которые управляют Союзом в период
между съездами. Директор Союза отвечает за техническую и организационную работу
организации. Правление реализует задачи, поставленные Съездом ИТ-директоров, при-
нимает новых членов, формирует комитеты по направлениям, в рамках которых реали-
зуются основные задачи Союза. В настоящее время в СоДИТ функционируют комитеты
по информационной безопасности, по науке и образованию, по стандартам, по законо-
дательству, по машиностроению.
В рамках Союза работают два Совета: Попечительский и Консультационный.
Попечительский Совет, который собирается раз в год, обсуждает деятельность ра-
боты Союза и участвует в наиболее значимых для общества инициативах. В настоящее
время Попечительский Совет СоДИТ возглавляет заместитель министра связи и мас-
совых коммуникаций РФ Д. Северов. Членами Совета являются А. Аганбегян, К. Ветров,
Е. Дьякова, В. Иноземцев, Е. Касперский, Б. Нуралиев, Т. Оби, Н. Прянишников, А. Чачава,
А.-В. Шеер, И. Юргенс и др.
Консультационный совет состоит из руководителей клубов ИТ-директоров. Задача
совета — координация деятельности клубного движения и СоДИТ.
Членом Союза ИТ-директоров может стать любой руководитель ИТ-службы, разделя-
ющий задачи организации, изложенные в ее уставных документах, и поддерживающий ее
работу взносами и участием. Иные представители отрасли или профессионалы в области
ИТ также могут стать членом Союза в случае, если они в рамках сотрудничества с СоДИТ
много делают для его развития. При СоДИТ организован Фонд поддержки ИКТ, в задачу
которого входит финансирование и организационная поддержка мероприятий, проводи-
мых Союзом. Учредителями Фонда выступили крупнейшие клубы ИТ-директоров.

Издание подготовили:
Издатель — Елена Максимова
Руководитель проекта — Марина Аншина
Экспертная группа:
Виктор Минин, Юрий Шойдин, Константин Зимин
Перевод — Александр Нетусов
Оригинал-макет и выпуск издания — ООО «Литера-Принт»
Москва, ул. Прянишникова, д. 19а, стр. 4, Тел. / факс: (495) 771-34-77
www.litera-print.ru, e-mail: litera-print@yandex.ru, litera-print@bk.ru
Тираж 500 экземпляров. Заказ № 477. Распространяется бесплатно.
© СоДИТ, 2010 г. www.rucio.ru
По вопросу перевода стандартов пишите по e-mail: standard@rucio.ru

52

You might also like