Стандарты информационной безопасности

1. Введение;
2. Функциональные требования безопасности;
3. Требования доверия безопасности.

В данном стандарте приведены общие  понятия:

1. Объекта оценки – произвольный продукт ИТ или системы с руководствами администратора и пользователя;
2. Продукт – совокупность программных, ПА и аппаратных средств ИТ, обладающий функциональными возможностями и предназначенное для непосредственного использования или включения в состав рабочих систем.
3. Система рассматривается в качестве специфического упрощения ИТ с конкретными значениями и условиями эксплуатации.

  В данном документе также определены категории пользователей:

1. Потребители;
2. Разработчики;
3. Эксперты.

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

При подготовке к оценке анализу подлежат:

1. Предположения безопасности;
2. Угрозы безопасности;
3. Политики безопасности.

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

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

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

 
 

Недостатки:

1. Отсутствие критериев оценки качающееся вопроса администрирования механизмов безопасности, непосредственно не относящиеся к мерам безопасности ИТ (управление персоналом, вопросы физической безопасности и ряд других);
2. В общих критериях не затрагиваются вопросы контроля ПЭМИН;
3. Не рассматривается методология оценки и административно правовая структура;
4. Не рассматриваются процедуры использования результатов оценки при аттестации продуктов (систем);
5. Не входят критерии оценки специфических свойств крипто алгоритмов.

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

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

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

Среда безопасности – содержит описание основных аспектов безопасности среды в которых предусматривается использовать объект оценки. Здесь же описывается способ применения. Состав изложения среды безопасности:

Описание предложений:

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

Относительно среды применения.

Описание угроз;

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

При изложении требований безопасности должны быть определены:

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

итерация;

назначение;

выбор;

уточнение.

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

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

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

Выбор требований безопасности должен быть строго обоснован

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

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

Соответствие  ОО – должен содержать все поддающиеся оценки утверждения о соответствии объекта оценки общим критериям.

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

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

01.11.11 (лекция)

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

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

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

1. 11 классов;
2. 66 семей;
3. 135 компонентов.

 

 

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

Представление класса содержит рисунок,  показывающий все семейства данного класса и иерархию компонентов в каждом семействе. 

Функциональное  семейство:

1. Имя семейства – каждое функциональное семейство имеет уникальное имя. XXX_YYY-Первые 3 символа идентичны краткому имени класса, подчеркивание, краткое имя семейства.
2. Характеристика семейства – описание функционального семейства, в котором излагаются цели безопасности, и общее описание функциональных требований. Цели безопасности характеризуют задачи безопасности, которая может быть решена с помощью объекта оценки включающего компонент из этого семейства. Описание функциональных требований обобщает все компоненты включенные в компоненты
3. Ранжирование компонентов – заключается в том, чтобы предоставить пользователям информацию для выбора наиболее подходящего функционального компонента из семейства. Связи между компонентами в пределах одного семейства могут быть как иерархическими так и не иерархическими. Иерархичность – характеризует уровень безопасности.
4. Управление – содержит информацию для разработчиков профиля защиты, либо задания по безопасности, которая должна учитываться при определении действий по управлению для данного компонента.
5. Аудит – содержат события, потенциально подвергаемые этому аудиту. Отбор этих событий, осуществляется при условии включения в эти документы требований из класса FAU-аудит безопасности. Запись аудита, какого либо механизма безопасности может происходить на разных уровнях детализации, эти уровни детализации характеризуются показателями:
1. Минимальный;
2. Базовый;
3. Детализированный.
6. Компоненты – их множество.

 

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

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

Уникальное имя.

Краткое имя.

Список иерархических связей.

Каждый  из этих компонентов включает в себя набор элементов, а каждый элемент  является самодостаточным.

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

Уникальная  краткая форма имени функционального  элемента выглядит вот так: FDP_IFF A.2

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

F – Функциональное требование.

DP – класс «Защита данных пользователя».

После подчёркивания 3 символа – это семейство «Функции управления информационными потоками».

A – Компонент «Частичное устранение неразрешённых информационных потоков».

2 – это второй элемент компонента.

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

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

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

 

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

Приведены в 3 части ОК:

1. 10 классов
2. 44 семейства
3. 93 компонента

 

Доверие – это основа для уверенности в том, что продукт или система IT отвечает целям безопасности.

Общие критерии обеспечивают доверие с использованием активного исследования.

Активным  исследованием является оценка продукта или система IT для определения его свойств безопасности.

Методы  оценки могут включать:

1. Анализ и проверка процессов и процедур.
2. Проверка действительной применимости процессов и процедур.
3. Анализ соответствия между представлениями проекта ОО.
4. Анализ соответствия каждого представления проекта ОО требованиям.
5. Верификация доказательств.
6. Анализ руководств.
7. Анализ разработанных функциональных тестов и полученных результатов.
8. Независимое функциональное тестирование.
9. Анализ уязвимостей с включением предложений о недостатках.
10. Тестирование проникновением.

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

 

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

Каждый  класс доверия имеет вводный  подраздел: блок представление класса. В нём осуществляется описание состава и назначения класса.

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

Каждое  семейство размещено в пределах класса доверия.

Ранжирование  компонентов. Этот подраздел содержит описание имеющихся компонентов и объявление их разграничений. Цель данного раздела состоит в указании различий между компонентами при принятии решения о том, что семейство является полезной частью.

 

Первый  раздел – идентификация, категорирование и регистрация ссылок на компоненты.