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

3a548bfa

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


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

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

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

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

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


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

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

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


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

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


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

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


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

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


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

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

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

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


Содержание раздела