Приложение C (обязательное). Аудит безопасности (FAU)

Приложение C
(обязательное)

Аудит безопасности (FAU)

Семейства аудита ИСО/МЭК 15408 предоставляют авторам ПЗ/ЗБ возможность определить требования для мониторинга действий пользователя и в некоторых случаях обнаружить существующие, возможные или готовящиеся нарушения выполнения ФТБ. Функции аудита безопасности ОО определены, чтобы помочь осуществлять контроль за относящимися к безопасности событиями, и выступают как сдерживающий фактор нарушений безопасности. Требования семейств аудита используют функции, включающие в себя защиту данных аудита, формат записи, выбор событий, а также инструментальные средства анализа, сигналы оповещения при нарушении и анализ в реальном масштабе времени. Журнал аудита следует представить в формате, доступном человеку, либо явно (например, храня журнал аудита в таком формате), либо неявно (например, применяя инструментальные средства предварительной обработки данных аудита), или же с использованием обоих методов.

При составлении требований аудита безопасности автору ПЗ/ЗБ следует обращать внимание на взаимосвязь семейств и компонентов аудита. Возможность реализации совокупности требований аудита в соответствии со списками зависимостей компонентов может привести и к некоторым недостаткам функции аудита. Так, при проведении аудита всех событий, относящихся к безопасности, они не сгруппируются по определенному принципу, например по принадлежности к отдельному пользователю или объекту.

C.1. Требования аудита в распределенной среде

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

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

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

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

Декомпозиция класса FAU на составляющие его компоненты показана на рисунке C.1.

C.2. Автоматическая реакция аудита безопасности (FAU_ARP)

C.2.1. Замечания для пользователя

Семейство FAU_ARP "Автоматическая реакция аудита безопасности" содержит требования по обработке событий аудита. Конкретное требование может включать в себя требования сигнала тревоги или действий ФБО (автоматическая реакция). Например, ФБО могут обеспечивать подачу сигнала тревоги в реальном времени, прерывание процесса с выявленным нарушением, прекращение обслуживания, блокирование или закрытие учетных данных пользователя.

Событие аудита определяется как "возможное нарушение безопасности", если так указано в компонентах семейства FAU_SAA "Анализ аудита безопасности".

C.2.2. FAU_ARP.1 Сигналы нарушения безопасности

C.2.2.1. Замечания по применению для пользователя

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

C.2.2.2. Операции

C.2.2.2.1. Назначение

В элементе FAU_ARP.1.1 автору ПЗ/ЗБ следует определить действия, предпринимаемые в случае возможного нарушения безопасности. Примером списка таких действий является: "информировать уполномоченного пользователя, блокировать субъекта, действия которого могут привести к нарушению безопасности". Можно также указать, что предпринимаемые действия могут определяться уполномоченным пользователем.

Рисунок C.1. Декомпозиция класса FAU "Аудит безопасности"

C.3. Генерация данных аудита безопасности (FAU_GEN)

C.3.1. Замечания для пользователя

Семейство FAU_GEN "Генерация данных аудита безопасности" содержит требования по спецификации событий аудита, которые следует генерировать с использованием ФБО для событий, относящихся к безопасности.

Это семейство организовано так, чтобы избежать зависимостей от всех компонентов, требующих поддержки аудита. В каждом компоненте имеется подготовленная секция "Аудит", в которой перечислены события, предлагаемые для аудита в его функциональной области. Содержание указанной области аудита используется автором ПЗ/ЗБ при составлении ПЗ/ЗБ для завершения операций этого компонента. Таким образом, спецификация того, что может подвергаться аудиту в функциональной области, содержится в указанной области.

Список событий, потенциально подвергаемых аудиту, полностью зависит от других функциональных семейств в ПЗ/ЗБ. Поэтому в описание каждого семейства следует включать список событий, относящихся к семейству и потенциально подвергаемых аудиту, для каждого компонента семейства. Каждое событие в списке потенциально подвергаемых аудиту событий, специфицированное в функциональном семействе, следует там же отнести к одному из принятых уровней генерации событий аудита (т.е. минимальному, базовому, детализированному). Это предоставляет автору ПЗ/ЗБ информацию, позволяющую обеспечить, чтобы все события, потенциально подвергаемые аудиту, были специфицированы в ПЗ/ЗБ. Следующий пример показывает, как необходимо специфицировать события, потенциально подвергаемые аудиту, в соответствующих функциональных семействах.

"Если в ПЗ/ЗБ включено семейство FAU_GEN "Генерация данных аудита безопасности", то следует предусмотреть возможность аудита следующих действий/событий/параметров:

a) Минимальный: успешное использование функций административного управления атрибутами безопасности пользователя.

b) Базовый: все попытки использования функций административного управления атрибутами безопасности пользователя.

c) Базовый: идентификация модифицированных атрибутов безопасности пользователя.

d) Детализированный: новые значения атрибутов, за исключением чувствительных атрибутов (например, паролей, ключей шифрования)".

Для каждого выбранного функционального компонента в общую совокупность событий, потенциально подвергаемых аудиту, следует включить те указанные в нем события, которые соответствуют уровню, установленному в FAU_GEN "Генерация данных аудита безопасности". Если, допустим, в приведенном выше примере в FAU_GEN "Генерация данных аудита безопасности" выбран уровень "базовый", события, указанные в подпунктах a), b) и c), следует отнести к потенциально подвергаемым аудиту.

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

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

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

Ниже приведены примеры типов событий, которые следует определить как потенциально подвергаемые аудиту в каждом функциональном компоненте ПЗ/ЗБ:

a) введение объектов, находящихся под контролем ФБО, в адресное пространство субъекта;

b) удаление объектов;

c) предоставление или отмена прав или возможностей доступа;

d) изменение атрибутов безопасности субъекта или объекта;

e) проверки политики, выполняемые ФБО как результат запроса субъекта;

f) использование прав доступа для обхода проверок политики;

g) использование функций идентификации и аутентификации;

h) действия, предпринимаемые оператором и/или уполномоченным пользователем (например, подавление такого механизма защиты ФБО, как доступные человеку метки);

i) ввод/вывод данных с/на заменяемых носителей (таких, как печатные материалы, ленты, дискеты).

C.3.2. FAU_GEN.1 Генерация данных аудита

C.3.2.1. Замечания по применению для пользователя

Компонент FAU_GEN.1 "Генерация данных аудита" определяет требования по идентификации событий, потенциально подвергаемых аудиту, для которых следует генерировать записи аудита, и состав информации в этих записях.

Если ФТБ не предусматривают ассоциации событий аудита с идентификатором пользователя, то достаточно применения только компонента FAU_GEN.1 "Генерация данных аудита". Это же приемлемо и в случае, когда ПЗ/ЗБ содержит требования приватности. Если же необходимо подключение идентификатора пользователя, можно дополнительно использовать компонент FAU_GEN.2 "Ассоциация идентификатора пользователя".

Если субъектом является пользователь, идентификатор пользователя может быть зарегистрирован как идентификатор субъекта. При этом, если не применялись компоненты семейства "Аутентификация пользователя" (FIA_UAU), идентификатор пользователя может быть не верифицирован. Поэтому в случае недействительной авторизации в системе (логина) заявленный идентификатор пользователя следует зарегистрировать. Следует также рассмотреть возможность указывать, когда зарегистрированный идентификатор не прошел аутентификацию.

C.3.2.2. Замечания для оценщика

Имеется зависимость от FPT_STM "Метки времени". Если точное значение времени событий для данного ОО несущественно, то может быть логически обоснован отказ от этой зависимости.

C.3.2.3. Операции

C.3.2.3.1. Выбор

В FAU_GEN.1.1 в разделе аудита функциональных требований, входящих в ПЗ/ЗБ, следует выбрать уровень событий, потенциально подвергаемых аудиту, указанный в разделе аудита других функциональных компонентов, включенных в ПЗ/ЗБ. Этот уровень может быть "минимальным", "базовым", "детализированным" или "неопределенным".

C.3.2.3.2. Назначение

В FAU_GEN.1.1 автору ПЗ/ЗБ следует составить список иных событий, потенциально подвергаемых аудиту, для включения в список событий, потенциально подвергаемых аудиту. Назначение может не включать ни одного события ("нет") или включать события из функциональных требований, потенциально подвергаемые аудиту более высокого уровня, чем требуется в b), а также события, генерируемые при использовании специфицированного интерфейса прикладного программирования (API).

В FAU_GEN.1.2 автору ПЗ/ЗБ следует для всех событий, потенциально подвергаемых аудиту и включенных в ПЗ/ЗБ, составить список иной информации, имеющей отношение к аудиту, для включения в записи событий аудита.

C.3.3. FAU_GEN.2 Ассоциация идентификатора пользователя

C.3.3.1. Замечания по применению для пользователя

Компонент FAU_GEN.2 связан с требованием использования идентификаторов пользователей при учете событий, потенциально подвергаемых аудиту. Этот компонент следует использовать в дополнение к FAU_GEN.1 "Генерация данных аудита".

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

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

C.4. Анализ аудита безопасности (FAU_SAA)

C.4.1. Замечания для пользователя

Семейство FAU_SAA определяет требования для автоматизированных средств, которые анализируют показатели функционирования системы и данные аудита в целях поиска возможных или реальных нарушений безопасности. Этот анализ может использоваться для поддержки как обнаружения вторжения, так и автоматической реакции на возможное нарушение безопасности.

Действия для выполнения ФБО при обнаружении потенциального нарушения определяются в компонентах семейства FAU_ARP "Автоматическая реакция аудита безопасности".

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

C.4.2. FAU_SAA.1 Анализ потенциального нарушения

C.4.2.1. Замечания по применению для пользователя

Компонент FAU_SAA.1 используется для определения совокупности событий, потенциально подвергаемых аудиту, появление которых (каждого отдельно или в совокупности) указывает на потенциальные нарушения выполнения ФТБ, и правил, применяемых для анализа этих нарушений.

C.4.2.2. Операции

C.4.2.2.1. Назначение

В FAU_SAA.1.2 автору ПЗ/ЗБ следует определить совокупность событий, потенциально подвергаемых аудиту, проявление которых (каждого в отдельности или совместно) будет указывать на возможные нарушения выполнения ФТБ.

В FAU_SAA.1.2 автору ПЗ/ЗБ следует определить любые другие правила, которые ФБО следует использовать для анализа журнала аудита. Эти правила могут включать в себя конкретные требования, согласно которым необходимо, чтобы в течение указанного периода времени (например, установленного времени суток, заданного интервала времени) произошли определенные события. Если нет никаких дополнительных правил, которые должны использовать ФБО при анализе журнала аудита, то данное назначение может быть выполнено как "нет".

C.4.3. FAU_SAA.2 Выявление аномалии, основанное на профиле

C.4.3.1. Замечания по применению для пользователя

Профиль является структурой, характеризующей поведение пользователей и/или субъектов; он описывает различные способы взаимодействия пользователей/субъектов с ФБО. Шаблоны использования для пользователей/субъектов устанавливаются по отношению к различным видам результатов их деятельности, включая, например: шаблоны возникновения исключительных ситуаций; шаблоны использования ресурсов (когда, каких, как); шаблоны выполняемых действий. Метрики профиля ссылаются на способы, которыми различные виды деятельности отражаются в профиле (например, измерение использованных ресурсов, счетчики событий, таймеры).

Каждый профиль представляет собой ожидаемые шаблоны использования, выполняемые членами группы, на которую он ориентирован (целевая группа профиля). Этот шаблон может основываться на предшествующем использовании (шаблон предыстории) или на обычном использовании пользователями подобных целевых групп (ожидаемое поведение). Целевая группа профиля включает в себя одного или нескольких пользователей, взаимодействующих с ФБО. Деятельность каждого члена группы данного профиля анализируется инструментальными средствами, чтобы сравнить ее с шаблоном, представленным в профиле. Примерами целевых групп профиля являются:

a) учетная запись отдельного пользователя - один профиль для каждого пользователя;

b) идентификатор группы или учетная запись группы - один профиль для всех пользователей, которые имеют один и тот же идентификатор группы или работают, используя общую учетную запись;

c) операционная роль - один профиль на всех пользователей, выполняющих данную операционную роль;

d) система в целом - один профиль на всех пользователей системы.

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

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

При составлении ПЗ/ЗБ следует перечислить виды деятельности, которые следует отслеживать и анализировать с использованием ФБО. Автору ПЗ/ЗБ следует особо указать, какая информация о деятельности пользователей необходима при составлении профилей использования системы.

FAU_SAA.2 "Выявление аномалии, основанное на профиле" содержит требование, чтобы ФБО сопровождали профили использования системы. Под сопровождением понимается активное участие детектора отклонений в обновлении профиля использования системы в соответствии с новыми действиями, выполняемыми членами целевой группы этого профиля. Важно, чтобы автором ПЗ/ЗБ была определена метрика представления деятельности пользователя. Индивид может выполнять тысячи различных действий, но детектор отклонений способен отобрать для контроля только некоторые из них. Результаты аномальной деятельности интегрируются в профиль так же, как и результаты нормальной деятельности (при условии выполнения мониторинга этих действий). То, что считалось отклонением четыре месяца назад, сегодня может стать нормой (и наоборот) из-за изменения условий работы пользователей. ФБО не будут способны учесть изменение ситуации, если в алгоритмах обновления профиля не отражена какая-либо аномальная деятельность пользователей.

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

Автору ПЗ/ЗБ следует определить, как интерпретировать рейтинги подозрительной активности и условия, при которых в случае аномального поведения нужно обращаться к механизму компонента FAU_ARP.

C.4.3.2. Операции

C.4.3.2.1. Выбор

В FAU_SAA.2.1 автору ПЗ/ЗБ следует определить целевую группу профиля. Один ПЗ/ЗБ может включать в себя несколько целевых групп профиля.

В FAU_SAA.2.3 автору ПЗ/ЗБ следует определить условия, при которых ФБО сообщают об аномальном поведении. Условия могут включать в себя достижение рейтингом подозрительной активности некоторого значения или основываться на определенном виде аномального поведения.

C.4.4. FAU_SAA.3 Простая эвристика атаки

C.4.4.1. Замечания по применению для пользователя

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

Сложность средств анализа в значительной степени будет зависеть от назначений, сделанных автором ПЗ/ЗБ при определении базового множества характерных событий.

В ПЗ/ЗБ следует перечислить события, отслеживаемые ФБО в целях их анализа. Автору ПЗ/ЗБ следует указать, на основании какой информации о событии его следует отнести к характерным.

Административные уведомления следует доводить до уполномоченного пользователя таким образом, чтобы он понимал значение этих событий и приемлемую реакцию на них.

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

Элементы FAU_SAA.3 "Простая эвристика атаки" не требуют, чтобы реализация эвристик распознавания прямой атаки осуществлялась теми же самыми ФБО, выполнение которых подлежит мониторингу. Поэтому компоненты, применяемые для обнаружения вторжения, можно разрабатывать независимо от системы, показатели функционирования которой подлежит анализу.

C.4.4.2. Операции

C.4.4.2.1. Назначение

В FAU_SAA.3.1 автору ПЗ/ЗБ следует идентифицировать базовое подмножество системных событий, появление которых, в отличие от иных показателей функционирования системы, может указывать на нарушение выполнения ФТБ. К ним относятся как события, сами по себе указывающие на очевидные нарушения выполнения ФТБ, так и события, появление которых является достаточным основанием для принятия мер предосторожности.

В FAU_SAA.3.2 автору ПЗ/ЗБ следует специфицировать информацию, используемую при определении показателей функционирования системы. Информация является исходной для инструментальных средств анализа показателей функционирования системы, применяемых в ОО. В эту информацию могут входить данные аудита, комбинации данных аудита с другими системными данными и данные, отличные от данных аудита. При составлении ПЗ/ЗБ следует точно определить, какие системные события и атрибуты событий используются в качестве исходной информации.

C.4.5. FAU_SAA.4 Сложная эвристика атаки

C.4.5.1. Замечания по применению для пользователя

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

Сложность средств анализа в значительной степени будет зависеть от назначений, сделанных автором ПЗ/ЗБ при определении базового множества характерных событий и последовательностей событий.

В ПЗ/ЗБ следует перечислить события, которые следует отслеживать ФБО в целях их анализа. Автору ПЗ/ЗБ следует указать, на основании какой информации о событии его можно отнести к характерным.

Административные уведомления следует доводить до уполномоченного пользователя таким образом, чтобы он понимал значение этих событий и приемлемую реакцию на них.

При спецификации этих требований предусмотрена возможность привлечения иных источников данных о функционировании системы, кроме данных аудита. Это было сделано в целях расширения привлекаемых методов обнаружения вторжения, которые при анализе показателей функционирования системы используют не только данные аудита (примерами других типов источников данных являются параметры сетевых дейтаграмм, данные о ресурсах/учете или комбинации различных системных данных). Поэтому от автора ПЗ/ЗБ требуется специфицировать виды данных, используемых при контроле показателей функционирования системы.

Элементы FAU_SAA.4 "Сложная эвристика атаки" не требуют, чтобы реализация эвристик распознавания прямой атаки осуществлялась теми же самыми ФБО, выполнение которых подлежит мониторингу. Поэтому компоненты, применяемые для обнаружения вторжения, можно разрабатывать независимо от системы, показатели функционирования которой подлежат анализу.

C.4.5.2. Операции

C.4.5.2.1. Назначение

В FAU_SAA.4.1 автору ПЗ/ЗБ следует идентифицировать базовое множество перечня последовательностей системных событий, совпадение которых типично для известных сценариев проникновения. Эти последовательности событий представляют известные сценарии проникновения. Каждое событие в последовательности следует сопоставлять с контролируемыми системными событиями, и если в итоге все системные события произошли в действительности, это подтверждает (отображает) попытку проникновения.

В FAU_SAA.4.1 автору ПЗ/ЗБ следует специфицировать базовое подмножество системных событий, появление которых, в отличие от иных показателей функционирования системы, может указывать на нарушение выполнения ФТБ. К ним относятся как события, сами по себе указывающие на очевидные нарушения выполнения ФТБ, так и события, появление которых является достаточным основанием для принятия мер предосторожности.

В FAU_SAA.4.2 автору ПЗ/ЗБ следует специфицировать информацию, используемую при определении показателей функционирования системы. Информация является исходной для инструментальных средств анализа показателей функционирования системы, применяемых в ОО. В эту информацию могут входить данные аудита, комбинации данных аудита с другими системными данными и данные, отличные от данных аудита. При составлении ПЗ/ЗБ следует точно определить, какие системные события и атрибуты событий используются в качестве исходной информации.

C.5. Просмотр аудита безопасности (FAU_SAR)

C.5.1. Замечания по применению

Семейство FAU_SAR определяет требования, относящиеся к просмотру информации аудита.

Следует, чтобы функции предоставляли возможность отбирать данные аудита до или п