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

Общие критерии оценки безопасности информационных технологий - это... Что такое Общие критерии оценки безопасности информационных технологий?

Общие критерии оценки безопасности информационных технологий — (англ. Common Criteria for Information TechnologySecurity Evaluation). Общеизвестным является более короткое название Общие критерии (Common Criteria, CC, или ОК). Международный стандарт (IEC 15408[1], ИСО/МЭК 15408-2002) по компьютерной безопасности. В отличие от стандарта FIPS 140[2] , Common Criteria не приводит списка требований по безопасности или списка особенностей, которые должен содержать продукт. Вместо этого он описывает инфраструктуру (framework) в которой потребители компьютерной системы могут описать требования, разработчики могут заявить о свойствах безопасности продуктов, а эксперты по безопасности определить, удовлетворяет ли продукт заявлениям. Таким образом Common Criteria позволяет быть обеспечить условия, в которых процесс описания, разработки и проверки продукта будет произведен с необходимой скурпулезностью.

Прообразом данного документа послужили «Критерии оценки безопасности информационных технологий» (англ. Evaluation Criteria for IT Security, ECITS), работа над которыми началась в 1990 году (см. историю разработки далее).

Основные понятия

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

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

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

Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности, всего 11 функциональных классов (в трёх группах), 66 семейств, 135 компонентов.

Первая группа определяет элементарные сервисы безопасности:
1. FAU — аудит, безопасность (требования к сервису, протоколирование и аудит);
2. FIA — идентификация и аутентификация;
3. FRU — использование ресурсов (для обеспечения отказоустойчивости).
Вторая группа описывает производные сервисы, реализованные на базе элементарных:
1. FCO — связь (безопасность коммуникаций отправитель-получатель);
2. FPR — приватность;
3. FDP — защита данных пользователя;
4. FPT — защита функций безопасности объекта оценки.
Третья группа классов связана с инфраструктурой объекта оценки:
1. FCS — криптографическая поддержка (обслуживает управление криптоключами и крипто-операциями);
2. FMT — управление безопасностью;
3. FTA — доступ к объекту оценки (управление сеансами работы пользователей);
4. FTP — доверенный маршрут/канал;

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

К элементарным сервисам безопасности относятся следующие классы FAU, FIA и FRU.

Класс FAU включает шесть семейств (FAU_GEN, FAU_SEL, FAU_STG, FAU_SAR, FAU_SAA и FAU_ARP), причем каждое семейство может содержать разное число компонентов.

Назначение компонент данного класса следующее.

FAU_GEN — генерация данных аудита безопасности. Содержит два компонента FAU_GEN.1 (генерация данных аудита) и FAU_GEN.2 (ассоциация идентификатора пользователя).

Требования доверия

Требования гарантии безопасности (доверия) — требования, предъявляемые к технологии и процессу разработки и эксплуатации объекта оценки. Разделены на 10 классов, 44 семейства, 93 компонента, которые охватывают различные этапы жизненного цикла.

Первая группа содержит классы требований, предшествующих разработке и оценки объекта:
1. APE — оценка профиля защиты;
2. ASE — оценка задания по безопасности.
Вторая группа связана с этапами жизненного цикла объекта аттестации:
1. ADV — разработка, проектирование объекта;
2. ALC — поддержка жизненного цикла;
3. ACM — управление конфигурацией;
4. AGD — руководство администратора и пользователя;
5. ATE — тестирование;
6. AVA — оценка уязвимостей;
7. ADO — требования к поставке и эксплуатации;
8. АMA — поддержка доверия-требования, применяется после сертификации объекта на соответствие общим критериям.

История разработки

Разработке «Общих критериев» предшествовала разработка докомента «Критерии оценки безопасности информационных технологий» (англ. Evaluation Criteria for IT Security, ECITS), начатая в 1990 году, и выполненная рабочей группой 3 подкомитета 27 первого совместного технического комитета (или JTC1/SC27/WG3) Международной организации по стандартизации (Общие критерии оценки безопасности информационных технологий (англ. Common Criteria for IT Security Evaluation), начатой в 1993 году. В этой работе принимали участие правительственные организации шести стран (США, Канада, Германия, Великобритания, Франция, Нидерланды). В работе над проектом принимали участие следующие институты:

Национальный институт стандартов и технологии и Агентство национальной безопасности (США);
Учреждение безопасности коммуникаций (Канада);
Агентство информационной безопасности (Германия);
Органы исполнения программы безопасности и сертификации ИТ (Англия);
Центр обеспечения безопасности систем (Франция);
Агентство национальной безопасности коммуникаций (Нидерланды).

Стандарт был принят в 2005 году комитетом ISO и имеет статус международного стандарта, идентификационный номер ISO/IEC 15408. В профессиональных кругах за этим документом впоследствии закрепилось короткое название — англ. Common Criteria, CC; русск. «Общие критерии», ОК.

Что это значит?

Итак, допустим некий продукт сертифицирован в соответствии со стандартом Common Criteria. О каком уровне защищённости это говорит?

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

Операционная система Windows XP (исходная версия, без SP1) была сертифицирована на уровень Common Criteria EAL4+, после чего для неё было выпущено два пакета обновлений (service pack) и регулярно выпускаются новые критические обновления безопасности. Тем не менее Windows XP в исходной версии по прежнему обладает сертификатом EAL4+, никаких дополнительных сертификаций не проводилось. Это факт говорит о том, что условия сертификации (окружение и модель злоумышленника) были подобраны весьма консервативно, в результате чего ни одна из обнаруженных уязвимостей не применима к протестированной конфигурации.

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

Ссылки

Примечания

↑ Evaluation criteria for IT security
↑ FIPS 140 (англ.)

Wikimedia Foundation. 2010.

Критерии оценки безопасности информационных технологий - это... Что такое Критерии оценки безопасности информационных технологий?

Основные понятия

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

Первая группа определяет элементарные сервисы безопасности:
1. FAU — аудит, безопасность (требования к сервису, протоколирование и аудит);
2. FIA — идентификация и аутентификация;
3. FRU — использование ресурсов (для обеспечения отказоустойчивости).
Вторая группа описывает производные сервисы, реализованные на базе элементарных:
1. FCO — связь (безопасность коммуникаций отправитель-получатель);
2. FPR — приватность;
3. FDP — защита данных пользователя;
4. FPT — защита функций безопасности объекта оценки.
Третья группа классов связана с инфраструктурой объекта оценки:
1. FCS — криптографическая поддержка (обслуживает управление криптоключами и крипто-операциями);
2. FMT — управление безопасностью;
3. FTA — доступ к объекту оценки (управление сеансами работы пользователей);
4. FTP — доверенный маршрут/канал;

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

К элементарным сервисам безопасности относятся следующие классы FAU, FIA и FRU.

Назначение компонент данного класса следующее.

Требования доверия

Первая группа содержит классы требований, предшествующих разработке и оценки объекта:
1. APE — оценка профиля защиты;
2. ASE — оценка задания по безопасности.
Вторая группа связана с этапами жизненного цикла объекта аттестации:
1. ADV — разработка, проектирование объекта;
2. ALC — поддержка жизненного цикла;
3. ACM — управление конфигурацией;
4. AGD — руководство администратора и пользователя;
5. ATE — тестирование;
6. AVA — оценка уязвимостей;
7. ADO — требования к поставке и эксплуатации;
8. АMA — поддержка доверия-требования, применяется после сертификации объекта на соответствие общим критериям.

История разработки

Национальный институт стандартов и технологии и Агентство национальной безопасности (США);
Учреждение безопасности коммуникаций (Канада);
Агентство информационной безопасности (Германия);
Органы исполнения программы безопасности и сертификации ИТ (Англия);
Центр обеспечения безопасности систем (Франция);
Агентство национальной безопасности коммуникаций (Нидерланды).

Что это значит?

Ссылки

Примечания

↑ Evaluation criteria for IT security
↑ FIPS 140 (англ.)

Wikimedia Foundation. 2010.

Общие критерии оценки безопасности информационных технологий

Основные понятия и идеи Общих Критериев

Общие Критерии содержат два основных вида требований безопасности:

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

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

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

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

– профиля защиты (ПЗ);

– задания по безопасности (ЗБ).

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

Задания по безопасностисодержат совокупность требований к конкретной разработке продукта или системы.

Системой ИТ называется специфичная реализация ИТ с конкретным назначением и условиями эксплуатации.

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

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

В среду безопасности ОО включаются:

– законодательная среда (нормативные акты, затрагивающие ОО);

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

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

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

Из анализа среды безопасности должны быть описаны следующие аспекты:

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

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

- источник;

- метод воздействия;

- опасные с точки зрения закономерности использования уязвимости;

- активы, потенциально подверженные повреждению.

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

3) положения политики безопасности, предназначенные для применения к ОО. Для системы ИТ такие положения могут быть описаны точно, для продукта ИТ — в общих чертах.

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

ОК, а именно их вторая и третья части, являются каталогами требований безопасности.

В основу методологии ОК положена модель безопасности, представленная на рисунке 2.

Рисунок 2 - Модель безопасности, положенная в основу методологии ОК

Для структуризации пространственных требований в ОК введена иерархия класс – семейство – компонент - элемент.

Классы определяют наиболее общую группировку требований.

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

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

Элемент— это неделимое требование безопасности.

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

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

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

ПЗ включает в себя следующие разделы:

– введение, состоящее из разделов идентификации ПЗ и аннотации ПЗ;

– описание ОО;

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

– цели безопасности, состоящие из подразделов целей безопасности для ОО и целей безопасности для среды;

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

– замечания по применению и обоснование, состоящее из подразделов логического обоснования требований безопасности и логического обоснования целей безопасности.

Состав ЗБ отличается наличием двух разделов и нескольких подразделов. Дополнительно в ЗБ имеются следующие разделы:

– краткая спецификация ОО, состоящая из функций безопасности ОО и спецификации мер доверия;

– утверждение соответствия ПЗ, в котором приводится ссылка на ПЗ, конкретизация ПЗ и дополнение ПЗ.

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

Краткая спецификация определяет отображение требований на функции безопасности.

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

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

При проведении оценки главными являются следующие вопросы:

1) отвечают ли функции безопасности ОО функциональным требованиям?

2) конкретна ли реализация функций безопасности?

Если оба ответа положительны, то говорят о достижении целей безопасности.

Контрольные вопросы

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

2. Можно ли при создании безопасных систем информационных технологий в соответствии с подходами Общих критериев использовать алгоритм создания автоматизированной системы, предписываемый ГОСТ 34.601 «Автоматизированные системы. Стадии создания»?

3. Каков состав задания по безопасности и чем он отличается от состава профиля защиты?

4. Какими параметрами характеризуется в Общих критериях угроза безопасности объекта оценки?

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

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

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

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

Некоторые компоненты в ОК задаются с «запросом». В них включается список возможностей, из которых потом осуществляется выбор той, что необходима в конкретной ситуации, например, обнаружение и/или предотвращение определенных нарушений политики безопасности.

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

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

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

К первой группе можно отнести следующие классы:

– FAU - аудит безопасности;

– FIA - идентификация и аутентификация;

– FRU - использование ресурсов.

Класс FAU состоит из 6 семейств, содержащих требования к отбору, регистрации, хранению и анализу данных о действиях и событиях, затрагивающих безопасность объекта оценки. Класс FIA состоит из 6 семейств, содержащих требования к идентификации пользователя, к аутентификации пользователей, определению атрибутов пользователя, к связыванию пользователя с субъектом, к отказам аутентификации и к спецификации секретов. Класс FRU включает 3 семейства, призванные разными способами поддерживать высокую доступность: отказоустойчивость, приоритет обслуживания и распределение ресурсов.

Ко второй группе можно отнести следующие классы:

– FCO – связь;

– FPR — приватность.

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

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

– FDP — защита данных пользователя;

– FPT — защита функций безопасности ОО.

Класс FDP включает 13 семейств, которые можно разбить на четыре группы:

– политики защиты данных пользователя;

– виды защиты данных пользователя;

– импорт и экспорт данных пользователя;

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

Класс FPT включает 16 семейств, которые можно условно разделить на четыре группы:

– архитектурная безопасность;

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

– защита данных функций безопасности;

– инфраструктурные требования.

Наибольшее число компонентов сосредоточено в классах инфраструктурной группы:

– FCS — криптографическая поддержка;

– FMT — управление безопасностью;

– FTA — доступ к ОО;

– FTP — доверенный маршрут/канал.

Класс FCS состоит из двух семейств, где в самом общем виде (в виде параметризованных шаблонов) рассматриваются генерация, распределение, доступ и уничтожение ключей, а также криптографические операции. Смысл требований состоит в том, что необходимо действовать в соответствии с некими алгоритмами, длинами ключей и стандартами. Какие-либо содержательные специфики отсутствуют. Класс FMT, включающий шесть семейств, регламентирует управление функциями безопасности и их данными, атрибутами и ролями безопасности. Класс FTA содержит шесть семейств, куда вошли требования управления сеансами работы пользователей (помимо идентификации и аутентификации). Класс FTP, состоящий из двух семейств: «доверенный маршрут» и «доверенный канал» – обеспечивает требования по созданию маршрутов/каналов передачи информации безопасным образом.

Контрольные вопросы

1. На базе каких элементарных сервисов безопасности первой группы классов функциональных требований могут быть реализованы требования второй группы функциональных требований класса FCO?

2. Чем отличается доверенный маршрут от доверенного канала?

3. Почему требования класса FTA отнесены условно к инфраструктурной группе?

4. Обеспечивает ли реализация требований класса FPR абсолютную неподотчетность действий пользователя в системе?

15 Пример описания функциональных требований

Рассмотрим описание класса, семейства, компонента и элементов требований на примере класса FCO «Связь».

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

Декомпозиция класса на составляющие его компоненты показана на рисунке 3

Рисунок 3 – Декомпозиция класса FCO «Связь»

Семейство FCO_NRO «Неотказуемость отправления» обеспечивает невозможность отрицания отправителем информации факта ее отправления. Семейство FCO_NRO содержит требование, чтобы функции безопасности объекта оценки обеспечили метод предоставления субъекту-получателю свидетельства отправления информации. Это свидетельство может быть затем верифицировано этим субъектом или другими субъектами.

Ранжирование компонентов показано на рисунке 4

Рисунок 4 - Ранжирование компонентов семейства FCO_NRO

FCO_NRO.1 «Избирательное доказательство отправления» содержит требование, чтобы функции безопасности объекта оценки предоставили субъектам возможность запросить свидетельство отправления информации.

FCO_NRO.2 «Принудительное доказательство отправления» содержит требование, чтобы функции безопасности объекта оценки всегда генерировали свидетельство отправления передаваемой информации.

Управление: FCO_NRO.1, FCO_NRO.2

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Аудит: FCO_NRO.1

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

а) Минимальный: идентификатор пользователя, который запросил генерацию свидетельства отправления.

б) Минимальный: обращение к функции неотказуемости.

в) Базовый: идентификатор информации, получателя и копии предоставляемого свидетельства.

г) Детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

Аудит: FCO_NRO.2

а) Минимальный: обращение к функции неотказуемости.

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

в) Детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

Описание компонента FCO_NRO.1 «Избирательное доказательство отправления» выглядит следующим образом.

Иерархический для FCO_NRO.1: нет подчиненных компонентов.

Элементы компонента FCO_NRO.1 описаны ниже.

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

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

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

Зависимости: FIA_UID.1 Выбор момента идентификации

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

Контрольные вопросы

1. Почему без компонента FIA_UID.1 «Выбор момента идентификации» компонент FCO_NRO.1 является несамодостаточным и не может обеспечить выполнение соответствующих целей безопасности?

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

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

13 Основные понятия и классификация требований доверия безопасности

Доверие в интерпретации ОК — это основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие обеспечивается через активные исследования (оценку) продукта или системы.

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

– оцениваются ЗБ и ПЗ, как источники требований безопасности;

– анализируются различные представления проекта ОО и соответствие между ними, а также соответствие каждого из них требованиям безопасности;

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

– анализируются тесты и их результаты, а также уязвимости ОО;

– проводится независимое тестирование, в том числе тестирование проникновением.

Каждое требование (элемент) доверия принадлежит одному из трех типов:

– элементы действия разработчика (помечаются буквой D после номера элемента). Эти действия должны подтверждаться доказательным материалом (свидетельством);

– элементы представления и содержания свидетельств (помечаются буквой S);

– элементы действия оценщика (помечаются буквой Е).

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

Требования доверия разделены на 10 классов, 44 семейства, 93 компонента. Классы можно сгруппировать в зависимости от охватываемых этапов жизненного цикла ОО.

К первой группе, логически предшествующей разработке и оценке ОО, принадлежат классы:

– APE — оценка ПЗ;

– ASE — оценка ЗБ.

Цель требований классов APE и ASE - проверить полноту, непротиворечивость и реализуемость профиля защиты или задания по безопасности.

Во вторую группу входят классы:

– ADV — разработка;

– ALC — поддержка жизненного цикла;

– ACM — управление конфигурацией.

Класс ADV (разработка) состоит из семи семейств и содержит требования для постепенного повышения уровня детализации проекта вплоть до представления реализаций с демонстрацией соответствия между уровнями. В этом классе предусмотрено три стиля изложения спецификации: неформальный, полуформальный и формальный – и три способа демонстрации соответствия. Технологические требования процедурного характера составляют содержание класса ALC (поддержка жизненного цикла), состоящего из четырех семейств. Прежде всего, определяется модель жизненного цикла (семейство ALC_LCD), затем следует обосновать выбор инструментальных средств и методов (семейство ALC_TAD). Безопасность разработки организуется в соответствии с требованиями семейства ALC_DVC. Важнейшим элементом этапа сопровождения является устранение недостатков (семейство ALC_FLR). Управление конфигурацией (класс ACM) - необходимый инструмент коллектива разработчиков. В этот класс входят три семейства, самое содержательное из которых ACM_CAB, специфицирующее возможности управления конфигурацией. Семейство ACM_SCP специфицирует область действия управления конфигурацией. Для уменьшения числа возможных ошибок управление конфигурацией следует максимально автоматизировать. В этом состоит смысл требований семейства ACM_AOT.

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

– AGD — руководство пользователя, администратора;

– ATE — тестирование;

– AVA — оценка уязвимостей.

Класс AGD состоит из двух семейств, где сформулированы требования к руководствам администратора (AGD_ADM) и пользователя (AGD_USR). Класс ATE состоит из четырех семейств, содержащих требования к полноте, глубине, способам и результатам тестирования функций безопасности на предмет их соответствия спецификациям. Один из ключевых моментов оценки безопасности продуктов информационных технологий – это оценка уязвимостей (класс AVA), отправным пунктом которой является анализ уязвимостей (семейство AVA_VLA), выполняемый разработчиком и оценщиком. Анализ стойкости функций безопасности объекта оценки (семейство AVA_SOF) проводится на уровне реализующих механизмов. Требования семейства AVA_MSV (неправильное применение) направлено на то, чтобы исключить возможность такого конфигурирования и (или) применения объекта оценки, которое администратор или пользователь считает безопасным, в то время как оно таковым не является. Анализ скрытых каналов, регламентируемый семейством AVA_CCA, требует, чтобы разработчик проводил исчерпывающий поиск скрытых каналов для каждой политики управления информационными потоками и предоставлял документацию анализа, а оценщик должен выборочно подтвердить правильность анализа скрытых каналов посредством тестирования.

Класс ADO (поставка и эксплуатация) содержит требования к процедурам поставки, установки, генерации и запуска объекта оценки.

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

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

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

– расширение границ ОО;

– увеличение уровня детализации рассматриваемых аспектов ОО;

– повышение строгости рассмотрения и применения более формальных методов верификации.

Контрольные вопросы

1. Реализация требований доверия увеличивает защищенность объекта оценки или повышает уверенность в его защищенности у оценщика и потребителя?

2. Раскройте смысл понятия «скрытый канал» и поясните, могут ли они оставаться в действующем объекте оценки, если разработчик осуществлял их поиск в процессе разработки объекта оценки?

3. Позволяет ли применение требований класса АМА избежать переоценки действующего сертифицированного ранее объекта оценки?

Общие критерии оценки безопасности информационных технологий | Защита информации

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

Критерии разрешают сравнивать результаты независимых оценок безопасности в информационной системе.

Подготовка общих критериев

Общие критерии — это продукт работы организаций по созданию критериев оценки безопасности ИТ. Критерии оценки безопасности компьютерных систем (tcsec) были созданы и развиты в США в 80-х годах. В Европе же критерии называются (ITSEC) была создана в 1991 году. В Канаде в 1993 году создали (CTCPEC) критерии как результат слияния предыдущих двух. Также всем известная международная организация по стандартизации (ISO) в 1990 году начала работу по созданию критериев оценки безопасности ИТ для общего использования.

Направление общих критериев

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

потребители объекта оценки
разработчики объекта оценки
оценщики объекта оценки

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

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

Организация общих критериев

Организация делится на следующие этапы:

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

Применимость и возможности

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

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

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

Концепции общих критериев

В соответствии с концепцией общих критериев требования безопасности объекта оценки делятся на:

функциональные требования
требования гарантировании

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

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

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

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

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

Выбор — действие на выбор нескольких пунктов из списка, что бы конкретизировать возможности элемента.

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

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

Уровни гарантии оценки — предопределенные пакеты требований гарантии.

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

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

Рисунок — 1, Концептуальная схема оценки безопасности ИТ на основе Общих критериев

Структура функциональных требований

Класс

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

Обзор классов и семейств

В разделе общих критериев имеется 9 классов, 76 семейств, 184 компонента и 380 элементов.

Класс FAU — (Аудит безопасности) — имеет 12 семейств имеющих требования пр регистрации, распознаванию, хранению и анализу данных связанных с безпасностью предприятия.

Класс FCO — (Связь) — имеет 2 семейства, указывающих на определение и идентификацию сторон при обмене информацией.

Класс FDP — (Защита данных пользователя) — имеет 15 семейств. Включает в себя требования к ведению политики безопасности предприятия связанной с защитой данных пользователя.

Класс FIA (Идентификация и авторизация) — имеет 9 семейств. Имеет требования для функций которые касаются проверки входа пользователей в информационную систему.

Класс FPR — (Секретность) — имеет 4 семейства и реализует правила относительно данных пользователя.

Класс FPT — (Защита функций безопасности) — имеет 22 семейства функциональных требований, которые направлены на контроль и целостность механизмов реализующих ФБ.

Класс FRU — (Реализация ресурса) — имеет 3 семейства которые направлены на правила готовности нужных ресурсов к храненнию или обработке информации.

Класс FTA — (Доступ к ОО(объект оценки) имеет 7 семейств имеющие требования к управлением сеансом работы пользователя.

Класс FTP — (надежный канал) — имеет 2 семейства имеющих требования к реализации надежного маршрута связи между пользователями.

Структура требований гарантии

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

Элементы действия разработчика (В конце буква D)
Элементы представление и содержания свидетельства (В конце буква С)
Элементы действия оценщика (В конце буква Е)

Классы и семейства гарантии

АСМ — управление настройками
ADO — Поставка и действие
ADV — разработка
AGD — документы руководства
ALC — поддержка жизненного цикла
ATE — тестирование
AVA — оценка уязвимости

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

Общие критерии оценки безопасности информационных технологий - это... Что такое Общие критерии оценки безопасности информационных технологий?

Основные понятия

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

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

Требования доверия

История разработки

Что это значит?

Ссылки

Примечания

Критерии оценки безопасности информационных технологий - это... Что такое Критерии оценки безопасности информационных технологий?

Основные понятия

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

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

Требования доверия

История разработки

Что это значит?

Ссылки

Примечания

Общие критерии оценки безопасности информационных технологий

Общие критерии оценки безопасности информационных технологий | Защита информации

Подготовка общих критериев

Направление общих критериев

Организация общих критериев

Применимость и возможности

Концепции общих критериев

Структура функциональных требований

Класс

Обзор классов и семейств

Структура требований гарантии

Классы и семейства гарантии

Смотрите также