Лекция 1: Обзор наиболее важных стандартов и спецификаций в области информационной безопасности
Классификация функциональных требований безопасности
жүктеу/скачать 0.51 Mb.
|
| Классификация функциональных требований безопасности
Часть 2 "Общих критериев", представляющая собой весьма обширную библиотеку функциональных требований безопасности, описывает 11 классов, 66 семейств, 135 компонентов и содержит сведения о том, какие цели безопасности могут быть достигнуты при современном уровне информационных технологий и каким образом. Аналогия между библиотекой функциональных требований безопасности и библиотекой программных модулей является в данном случае довольно полной. Функциональные компоненты могут быть не до конца конкретизированы, поэтому фактические параметры подставляются не в самих "Общих критериях", а в определенных профилях защиты, заданиях по безопасности и функциональных пакетах. (Правда, в ГОСТ Р ИСО/МЭК 15408-2002 параметризация не очень удачно названа "назначением".) В качестве параметров могут выступать весьма сложные сущности, такие, например, как политика безопасности (ПБ). Некоторые функциональные компоненты "Общих критериев" задаются "с запасом", в них включается список возможностей, из которых затем с помощью соответствующей операции выбирается только то, что нужно в конкретной ситуации. Пример - обнаружение и/или предотвращение определенных нарушений политики безопасности. На программистском языке подобный отбор называется частичным применением. Разумеется, любой функциональный компонент допускает многократное использование (например, чтобы охватить разные аспекты объекта оценки), называемое в ОК итерацией , а также уточнение и добавление дополнительных деталей (последнее можно считать еще одной формой частичного применения). Между компонентами функциональных требований, как и между привычными библиотечными функциями, могут существовать зависимости. Они возникают, когда компонент не является самодостаточным и для своей реализации нуждается в привлечении других компонентов. Очевидно, размещая в ПЗ, ЗБ или ФП подобный компонент, нужно включить туда и всю гроздь зависимостей (это похоже на разрешение внешних ссылок при формировании выполняемого модуля). Классы функциональных требований "Общих критериев" можно разделить в зависимости от того, описывают ли они элементарные сервисы безопасности или производные, реализуемые на основе элементарных, направлены ли они на достижение высокоуровневых целей безопасности или играют инфраструктурную роль. К первой группе относятся следующие классы: FAU - аудит безопасности (описывает требования к сервису протоколирования/аудита); FIA - идентификация / аутентификация ; FRU - использование ресурсов (прежде всего - обеспечение отказоустойчивости). Классы второй группы: FCO - связь (обслуживает неотказуемость отправителя/получателя); FPR - приватность ; Достичь высокоуровневых целей безопасности помогают два класса: FDP - защита данных пользователя; FPT - защита функций безопасности объекта оценки. Наиболее многочисленны классы, играющие инфраструктурную роль: FCS - криптографическая поддержка (обслуживает управление криптографическими ключами и криптографические операции ); FMT - управление безопасностью ; FTA - доступ к объекту оценки (управление сеансами работы пользователей); FTP - доверенный маршрут / канал. Приведенная классификация содержит несколько примечательных моментов. Во-первых, функциональные требования ОК довольно разнородны. Трудно объяснить, например, почему протоколированию/аудиту соответствует собственный класс, а такой важнейший, без преувеличения, классический сервис безопасности, как управление доступом, "спрятан" среди других требований защиты данных пользователя. Во-вторых, в ОК не выделены архитектурные требования. Правда, некоторые весьма важные архитектурные компоненты, в числе которых - посредничество при обращениях (частный случай невозможности обхода защитных средств) и жүктеу/скачать 0.51 Mb. Достарыңызбен бөлісу:
|