Опубликован: 03.09.2003 | Уровень: специалист | Доступ: платный
Лекция 3:

"Общие критерии", часть 2. Функциональные требования безопасности

< Лекция 2 || Лекция 3: 123456 || Лекция 4 >
Аннотация: Детально рассматриваются семейства функциональных требований безопасности, представленные в "Общих критериях". Анализируются достоинства и недостатки принятого в них подхода.
Ключевые слова: библиотека требований, класс, семейство, компонент, цели безопасности, аналогия, профиль защиты, ПО, функциональный пакет, параметризация, политика безопасности, список, операции, итерация, уточнение, функциональные требования, производные, аудит безопасности, FIA, идентификация, аутентификация, FRU, использование ресурсов, неотказуемость, FPR, приватность, защита данных пользователя, криптографическая поддержка, управление криптографическими ключами, криптографические операции, FMT, управление безопасностью, FTA, управление сеансами работы пользователей, доверенный маршрут, доверенный канал, сервис безопасности, управление доступом, архитектурные требования, обход защитных средств, разделение доменов, механизмы, ядро безопасности, безопасность, генерация данных аудита безопасности, минимум, идентификатор, ассоциация, выбор событий аудита безопасности, тип события, хранение событий аудита безопасности, запись, просмотр аудита безопасности, право на чтение, доступ, анализ аудита безопасности, анализ, подозрительная активность, эвристика, сигнатура атаки, автоматическая реакция аудита безопасности, вывод, сетевые угрозы, механизм одноразовой аутентификации, сочетание механизмов аутентификации, пароль, определение атрибутов пользователя, связывание пользователь-субъект, отказ аутентификации, пользователь, генератор паролей, криптография, отказоустойчивость, приоритет обслуживания, распределение ресурсов, квота, надежность, многопроцессорная конфигурация, анонимность, функции безопасности, псевдонимность, ресурс, псевдоним, доверенный субъект, связь, невозможность ассоциации, скрытность, распределение информации, многоаспектность информационной безопасности, конфликт интересов, субъект информационных отношений, импорт данных пользователя, экспорт данных пользователя, изделие ИТ, управление информационными потоками, множества, группа, иерархические атрибуты безопасности, скрытый канал, пропускная способность, аутентификация данных, целостность, внутренний канал, базовая, мониторинг, защита остаточной информации, оранжевая книга, откат, интерпретация, объект, внешний канал, аутентичность, статическая целостность, криптографическая хэш-функция, архитектурная безопасность, невозможность обхода защитных средств, посредничество при обращениях, домен безопасности, монитор обращений, безопасность при сбое, надежное восстановление, функция, безопасное состояние, физическая защита, физический доступ, информация, контроль, самотестирование функций безопасности, самотестирование, объединение, защита данных, конфиденциальность, передача данных, перестановка, согласованность данных функций безопасности, базовая абстрактная машина, обнаружение повторного использования, синхронизация состояний, метки времени, надежные метки времени, FCS, генерация ключей, распределение ключей, доступ к ключам, уничтожение ключей, управление данными, срок действия атрибутов безопасности, роли управления безопасностью, ограничение параллельных сеансов, блокирование сеанса, предупреждающее сообщение, история доступа, общие критерии, FTP

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

Часть 2 "Общих критериев", представляющая собой весьма обширную библиотеку функциональных требований безопасности, описывает 11 классов, 66 семейств, 135 компонентов и содержит сведения о том, какие цели безопасности могут быть достигнуты при современном уровне информационных технологий и каким образом.

Аналогия между библиотекой функциональных требований безопасности и библиотекой программных модулей является в данном случае довольно полной. Функциональные компоненты могут быть не до конца конкретизированы, поэтому фактические параметры подставляются не в самих "Общих критериях", а в определенных профилях защиты, заданиях по безопасности и функциональных пакетах. (Правда, в ГОСТ Р ИСО/МЭК 15408-2002 параметризация не очень удачно названа "назначением".) В качестве параметров могут выступать весьма сложные сущности, такие, например, как политика безопасности (ПБ).

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

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

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

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

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

  • FAU - аудит безопасности (описывает требования к сервису протоколирования/аудита);
  • FIA - идентификация / аутентификация ;
  • FRU - использование ресурсов (прежде всего - обеспечение отказоустойчивости).

Классы второй группы:

  • FCO - связь (обслуживает неотказуемость отправителя/получателя);
  • FPR - приватность ;

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

  • FDP - защита данных пользователя;
  • FPT - защита функций безопасности объекта оценки.

Наиболее многочисленны классы, играющие инфраструктурную роль:

  • FCS - криптографическая поддержка (обслуживает управление криптографическими ключами и криптографические операции );
  • FMT - управление безопасностью ;
  • FTA - доступ к объекту оценки (управление сеансами работы пользователей);
  • FTP - доверенный маршрут / канал.

Приведенная классификация содержит несколько примечательных моментов. Во-первых, функциональные требования ОК довольно разнородны. Трудно объяснить, например, почему протоколированию/аудиту соответствует собственный класс, а такой важнейший, без преувеличения, классический сервис безопасности, как управление доступом, "спрятан" среди других требований защиты данных пользователя.

Во-вторых, в ОК не выделены архитектурные требования. Правда, некоторые весьма важные архитектурные компоненты, в числе которых - посредничество при обращениях (частный случай невозможности обхода защитных средств) и разделение доменов, вошли в класс FPT (защита функций безопасности).

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

Далее мы кратко рассмотрим все 11 классов     функциональных требований безопасности "Общих критериев".

< Лекция 2 || Лекция 3: 123456 || Лекция 4 >
Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?

Мария Архипова
Мария Архипова
Роман Ижванов
Роман Ижванов
Россия, Университет природы, общества и человека «Дубна»
Анастасия Шмакова
Анастасия Шмакова
Россия, Тольятти, ПВГУС, 2013