Классы функциональных требований, описывающие элементарные сервисы безопасности
В этом разделе рассматриваются три класса функциональных требований безопасности:
- 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 (предотвращение потери данных аудита), определяет последовательность действий, если объем информации в регистрационном журнале превышает заранее заданный порог.
Мы приступаем к рассмотрению двух следующих классов функциональных требований безопасности:
- FCO - связь;
- FPR - приватность.
Класс FCO состоит из двух семейств, FCO_NRO и FCO_NRR, ведающих неотказуемостью (невозможностью отказаться от факта отправки или получения данных), которая достигается путем избирательной или принудительной генерации допускающих верификацию свидетельств, позволяющих ассоциировать атрибуты отправителя (получателя) с элементами передаваемых данных.
Класс FPR (приватность) содержит четыре семейства функциональных требований, обеспечивающих защиту пользователя от раскрытия и несанкционированного использования его идентификационных данных.
Семейство FPR_ANO (анонимность) дает возможность выполнения действий без идентификатора пользователя. Анонимность может быть полной или выборочной. В первом случае функции безопасности обязаны предоставить заданный набор услуг без запроса идентификатора пользователя. Во втором предусмотрено более слабое требование, в соответствии с которым идентификатор может запрашиваться, но должен скрываться от заранее указанных пользователей и/или субъектов.
Семейство FPR_PSE (псевдонимность) обеспечивает условия, когда пользователь может использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время подотчетным за свои действия. Базовый компонент семейства, FPR_PSE.1, предписывает выборочную анонимность, а также наличие средств генерации заданного числа псевдонимов и определения или принятия псевдонима от пользователя с верификацией соответствия некоторой метрике псевдонимов. Эти требования дополняются в компоненте FPR_PSE.2 (обратимая псевдонимность) возможностью определения доверенными субъектами идентификатора пользователя по представленному псевдониму, а в компоненте FPR_PSE.3 (альтернативная псевдонимность) - возможностью оперативного перехода на новый псевдоним, связь которого со старым проявляется лишь в заранее оговоренных ситуациях.
Семейство FPR_UNL (невозможность ассоциации) содержит единственный компонент, предусматривающий неоднократное применение пользователем информационных сервисов, не позволяя заданным субъектам ассоциировать их между собой и приписывать одному лицу.
В их число входят игнорирование и своевременное запрещение протоколируемых событий, запись поверх самых старых регистрационных данных и т.д.
Семейство 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.
Невозможность ассоциации защищает от построения профилей поведения пользователей (см. выше компонент FAU_SAA.2).
Самым сложным в классе FPR является семейство FPR_UNO (скрытность). Его требования направлены на то, чтобы пользователь мог незаметно для кого бы то ни было работать с определенными информационными сервисами. Наиболее интересны два из четырех имеющихся компонентов семейства. FPR_UNO.2 (распределение информации, влияющее на скрытность) предписывает рассредоточить соответствующие данные по различным частям объекта оценки. Это одно из немногих архитектурных требований "Общих критериев" (правда, выраженное в очень общей форме). В некотором смысле противоположную роль играет компонент FPR_UNO.4 (открытость для уполномоченного пользователя), согласно которому уполномоченные пользователи должны иметь возможность наблюдать за тем, как употребляются заданные ресурсы и/или услуги. (Как сказал один пессимист: "Я так и знал, что этим все кончится!")
Требования приватности ставят очень серьезную проблему многоаспектности информационной безопасности, заставляют искать баланс конфликтующих интересов субъектов информационных отношений. Разработчики заданий по безопасности должны учесть и конкретизировать эти требования с учетом действующего законодательства и специфики систем ИТ.
