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

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

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

• 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.