ГОСТ Р ИСО МЭК 15408-2 2007 (1027764), страница 25
Текст из файла (страница 25)
Примером списка таких действий является: "информировать уполномоченного пользователя, блокировать субъекта, действия которого могут привести к нарушению безопасности". Можно также указать, что предпринимаемые действия могут определяться уполномоченным пользователем.C.3 Генерация данных аудита безопасности (FAU_GEN)C.3.1 Замечания по применениюСемейство FAU_GEN «Генерация данных аудита безопасности» содержит требования поспецификации событий аудита, которые следует генерировать с использованием ФБО для событий, относящихся к безопасности.Это семейство организовано так, чтобы избежать зависимостей от всех компонентов, требующих поддержки аудита. В каждом компоненте имеется подготовленная секция "Аудит", в которой перечислены события, предлагаемые для аудита в его функциональной области. Содержаниеуказанной области аудита используется автором ПЗ/ЗБ при составлении ПЗ/ЗБ для завершенияопераций этого компонента.
Таким образом, спецификация того, что может подвергаться аудиту вфункциональной области, содержится в указанной области.Список событий, потенциально подвергаемых аудиту, полностью зависит от других функциональных семейств в ПЗ/ЗБ. Поэтому в описание каждого семейства следует включать списоксобытий, относящихся к семейству и потенциально подвергаемых аудиту, для каждого компонентасемейства.
Каждое событие в списке потенциально подвергаемых аудиту событий, специфицированное в функциональном семействе, следует там же отнести к одному из принятых уровней генерации событий аудита (т.е. минимальному, базовому, детализированному). Это предоставляет автору ПЗ/ЗБ информацию, позволяющую обеспечить, чтобы все события, потенциально подвергаемые аудиту, были специфицированы в ПЗ/ЗБ. Следующий пример показывает, как необходимоспецифицировать события, потенциально подвергаемые аудиту, в соответствующих функциональных семействах."Если в ПЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», тоследует предусмотреть возможность аудита следующих действий/событий/параметров.a) Минимальный: успешное использование функций административного управления атрибутами безопасности пользователя.b) Базовый: все попытки использования функций административного управления атрибутамибезопасности пользователя.c) Базовый: идентификация модифицированных атрибутов безопасности пользователя.d) Детализированный: новые значения атрибутов, за исключением чувствительных атрибутов (например, паролей, ключей шифрования)."Для каждого выбранного функционального компонента в общую совокупность событий, потенциально подвергаемых аудиту, следует включить те указанные в нем события, которые соот-135ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)ветствуют уровню, установленному в 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 «Ассоциация идентификатора пользователя».C.3.2.2 Замечания по применению для оценщикаИмеется зависимость от FPT_STM «Метки времени». Если точное значение времени событий для данного ОО несущественно, то может быть логически обоснован отказ от этой зависимости.136ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)C.3.2.3 ОперацииC.3.2.3.1 ВыборВ FAU_GEN.l.l в разделе аудита функциональных требований, входящих в ПЗ/ЗБ, следуетвыбрать уровень событий, потенциально подвергаемых аудиту, указанный в разделе аудита других функциональных компонентов, включенных в ПЗ/ЗБ.
Этот уровень может быть "минимальным","базовым", "детализированным" или "неопределенным".C.3.2.3.2 НазначениеВ FAU_GEN.l.l автору ПЗ/ЗБ следует составить список иных событий, потенциально подвергаемых аудиту, для включения в список событий, потенциально подвергаемых аудиту. Назначениеможет не включать ни одного события ("нет") или включать события из функциональных требований, потенциально подвергаемые аудиту более высокого уровня, чем требуется в 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 «Автоматическая реакция аудита безопасности».Для анализа в режиме реального времени данные аудита могут преобразовываться не только в формат, используемый для автоматической обработки, но также и в формат, удобный дляпросмотра уполномоченными пользователями.137ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)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 автору ПЗ/ЗБ следует определить любые другие правила, которые ФБО следует использовать для анализа журнала аудита.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
