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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание компонента 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. Позволяет ли применение требований класса АМА избежать переоценки действующего сертифицированного ранее объекта оценки?