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

 

В этом разделе рассматриваются три класса функциональных требований безопасности:

· FAU - аудит безопасности;

· FIA - идентификация/аутентификация;

· FRU - использование ресурсов.

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

Семейство FAU_GEN (генерация данных аудита безопасности) включает два компонента. Первый, FAU_GEN.1 (генерация данных аудита), специфицирует потенциально подвергаемые протоколированию и аудиту события, вводит понятие уровня протоколирования (минимальный, базовый, детализированный, неопределенный), определяет минимум регистрационных данных о событии (дата, время, тип, результат события, а также идентификатор субъекта). Второй, FAU_GEN.2 (ассоциация идентификатора пользователя), предписывает ассоциировать каждое потенциально регистрируемое событие с идентификатором пользователя, его инициирующего.

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

Семейство FAU_STG (хранение событий аудита безопасности) содержит две пары компонентов. Первая, FAU_STG.1 (защищенное хранение журнала аудита) и FAU_STG.2 (гарантии доступности данных аудита), специфицирует защиту регистрационного журнала от несанкционированного удаления, модификации, а также от повреждения регистрационных данных при его переполнении, сбое или атаке. Вторая пара, FAU_STG.3 (действия в случае возможной потери данных аудита) и FAU_STG.4 (предотвращение потери данных аудита), определяет последовательность действий, если объем информации в регистрационном журнале превышает заранее заданный порог. В их число входят игнорирование и своевременное запрещение протоколируемых событий, запись поверх самых старых регистрационных данных и т.д.

Семейство FAU_SAR (просмотр аудита безопасности) предоставляет право на чтение (полное или выборочное, на основе критериев с логическими отношениями) регистрационного журнала уполномоченным пользователям и запрет на доступ к журналу для прочих пользователей.

Семейство FAU_SAA (анализ аудита безопасности) устанавливает требования к средствам автоматического анализа функционирования объекта оценки, позволяющим выявлять возможные нарушения безопасности. Базовым компонентом семейства является FAU_SAA.1 (анализ потенциального нарушения), регламентирующий применение набора правил, основанных на накоплении или объединении событий, сигнализирующих о вероятном нарушении безопасности. В рамках семейства этот компонент усилен по двум направлениям. В FAU_SAA.2 (выявление аномалий, опирающееся на профиль) вводится понятия профиля поведения, рейтинга подозрительной активности для каждого пользователя, чьи действия отражены в профиле, а также порога, превышение которого указывает на ожидаемое нарушение политики безопасности. FAU_SAA.3 (простая эвристика атаки) и FAU_SAA.4 (сложная эвристика атаки) содержит понятие сигнатуры атаки (разной степени сложности) и специфические функции выявления сигнатур в реальном масштабе времени.

Шестое семейство класса FAU - FAU_ARP (автоматическая реакция аудита безопасности) - определяет действия, которые необходимо предпринять при выявлении возможных нарушений безопасности. Действия эти характеризуются как "наименее разрушительные".

Можно сделать вывод, что в "Общих критериях" нашли отражение такие важные достижения относительно недавнего прошлого, как разработка и применение методов активного аудита.

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

Семейство FIA_UID (идентификация пользователя) включает два компонента и определяет набор действий (например, получение справочной информации), которые разрешается выполнять до идентификации. Обычно применяют более сильный компонент FIA_UID.2 - идентификация до любых действий, выполняемых пользователем при посредничестве функций безопасности.

Семейство FIA_UAU (аутентификация пользователя) устроено сложнее. Оно специфицирует типы механизмов аутентификации и используемые при этом атрибуты. Два первых компонента, FIA_UAU.1 (выбор момента аутентификации) и FIA_UAU.2 (аутентификация до любых действий пользователя), играют (применительно к аутентификации) ту же роль, что и компоненты семейства FIA_UID. На реализацию надежной аутентификации, устойчивой к сетевым угрозам, направлены компоненты FIA_UAU.3 (аутентификация, защищенная от подделок), FIA_UAU.4 (механизмы одноразовой аутентификации) и FIA_UAU.5 (сочетание механизмов аутентификации). После периода неактивности пользователя и в ряде других ситуаций уместно применение компонента FIA_UAU.6 (повторная аутентификация). Наконец, FIA_UAU.7 (аутентификация с защищенной обратной связью) указывает, как отображать пароль при вводе.

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

Обычно после успешной идентификации и аутентификации от имени пользователя начинает действовать некий процесс (субъект). Семейство FIA_USB (связывание пользователь-субъект) содержит требования по ассоциированию атрибутов безопасности пользователя с этим субъектом.

Выявлением и реагированием на неудачи аутентификации ведает семейство FIA_AFL (отказы аутентификации). Разумеется, и число допустимых неудачных попыток, и действия, выполняемые при превышении порога неудач, - все это параметры единственного компонента семейства.

Обычно пользователь доказывает свою подлинность, сообщая нечто, что знает только он ("секрет" в терминологии ОК). Семейство FIA_SOS (спецификация секретов) вводит понятие метрики качества секретов и содержит требования к средствам проверки качества и генерации секретов заданного качества. Примеры подобных средств - проверка выполнения технических ограничений на пользовательские пароли в ОС Unix и программные генераторы паролей.

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

Класс FRU (использование ресурсов) включает три семейства, призванные разными способами поддерживать высокую доступность.

Выполнение требований семейства FRU_FLT (отказоустойчивость) должно обеспечить корректную работу всех или хотя бы некоторых функций объекта оценки даже в случае сбоев.

FRU_PRS (приоритет обслуживания) регламентирует действия по защите высокоприоритетных операций от препятствий или задержек со стороны операций с более низким приоритетом.

Семейство FRU_RSA (распределение ресурсов) для достижения высокой доступности ресурсов привлекает механизм квот.

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

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

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

Отметим также, что включение в класс FRU конкретных механизмов еще резче обозначает излишнюю обобщенность требований класса FIA.