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

       

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


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

  • 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 (открытость для уполномоченного пользователя), согласно которому уполномоченные пользователи должны иметь возможность наблюдать за тем, как употребляются заданные ресурсы и/или услуги. (Как сказал один пессимист: "Я так и знал, что этим все кончится!")

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


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