Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

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

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

C.2.2.2 Операции

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

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

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

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

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

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

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

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

Семейство 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 Генерация данных аудита

<== предыдущая лекция | следующая лекция ==>
А.1.3.3 Разрешенные операции | C.3.2.3.2 Назначение
Поделиться с друзьями:


Дата добавления: 2014-01-15; Просмотров: 694; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.015 сек.