- Законы
- Кодексы
- Форум
Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности. ГОСТ Р ИСО/МЭК 15408-2-2008
Утвержден
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 18 декабря 2008 г. N 520-ст
Дата введения -
1 октября 2009 года
Предисловие
Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения".
Сведения о стандарте
1. Подготовлен Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ"), Федеральным государственным учреждением "4 Центральный научно-исследовательский институт Министерства обороны России" (ФГУ "4 ЦНИИ Минобороны России"), Федеральным государственным унитарным предприятием "Научно-технический и сертификационный центр по комплексной защите информации" ФГУП Центр "Атомзащитаинформ", Федеральным государственным унитарным предприятием "Центральный научно-исследовательский институт управления, экономики и информации Росатома" (ФГУП "ЦНИИАТОМИНФОРМ") при участии экспертов Международной рабочей группы по Общим критериям на основе собственного аутентичного перевода стандарта, указанного в пункте 4.
2. Внесен Техническим комитетом по стандартизации ТК 362 "Защита информации".
3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 18 декабря 2008 г. N 520-ст.
4. Настоящий стандарт идентичен международному стандарту ИСО/МЭК 15408-2:2005 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности" (ISO/IEC 15408-2:2005 "Information technology - Security techniques - Evaluation criteria for IT security - Part 2: Security functional requirements").
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном Приложении N.
5. Взамен ГОСТ Р ИСО/МЭК 15408-2-2002.
Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе "Национальные стандарты", а текст изменений и поправок - в ежемесячно издаваемых информационных указателях "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет.
Введение
Международный стандарт ИСО/МЭК 15408:2005 подготовлен Совместным техническим комитетом ИСО/МЭК СТК 1 "Информационные технологии", Подкомитет ПК 27 "Методы и средства обеспечения безопасности ИТ". Идентичный ИСО/МЭК 15408:2005 текст опубликован организациями - спонсорами проекта "Общие критерии" как "Общие критерии оценки безопасности информационных технологий", версия 2.3 (ОК, версия 2.3).
Второе издание ИСО/МЭК 15408:2005 отменяет и заменяет первое издание (ИСО/МЭК 15408:1999), которое подверглось технической переработке.
ИСО/МЭК 15408 под общим наименованием "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий" состоит из следующих частей:
- часть 1. Введение и общая модель;
- часть 2. Функциональные требования безопасности;
- часть 3. Требования доверия к безопасности.
Если имеют в виду все три части стандарта, используют обозначение ИСО/МЭК 15408.
Функциональные компоненты безопасности, определенные в данной части ИСО/МЭК 15408, являются основой для выражения функциональных требований безопасности в профиле защиты (ПЗ) или задании по безопасности (ЗБ). Данные требования содержат описание желательного безопасного режима функционирования объекта оценки (ОО) или ИТ-среды ОО и предназначены для достижения целей безопасности, установленных в ПЗ или ЗБ. Данные требования содержат свойства безопасности, которые пользователи могут обнаружить при непосредственном взаимодействии с ИТ (то есть при входе и выходе) или при реакции ИТ на запросы.
Функциональные компоненты безопасности выражают требования безопасности, направленные на противостояние угрозам в предполагаемой среде эксплуатации ОО и/или охватывающие любую идентифицированную политику безопасности организации и предположения.
Аудитория для данной части ИСО/МЭК 15408 включает в себя потребителей, разработчиков и оценщиков безопасных ИТ-систем и продуктов. Дополнительная информация о потенциальных пользователях ИСО/МЭК 15408 и использовании ИСО/МЭК 15408 группами, которые включают в себя потенциальных пользователей, представлена в ИСО/МЭК 15408-1, раздел 4. Эти группы могут использовать данную часть ИСО/МЭК 15408 следующим образом:
a) потребители используют данную часть ИСО/МЭК 15408, выбирая компоненты, чтобы сформулировать функциональные требования для удовлетворения целей безопасности, приведенных в ПЗ или ЗБ. Более подробная информация о взаимосвязях требований безопасности и целей безопасности приведена в ИСО/МЭК 15408-1, подраздел 5.3;
b) разработчики, несущие ответственность за выполнение существующих или предполагаемых требований безопасности потребителя при разработке ОО, найдут в данной части ИСО/МЭК 15408 стандартизированный подход к пониманию указанных требований. Они используют содержание данной части ИСО/МЭК 15408 как основу для дальнейшего определения функций и механизмов безопасности ОО, которые соответствовали бы этим требованиям;
c) оценщики используют функциональные требования, определенные в данной части ИСО/МЭК 15408, для подтверждения того, что функциональные требования ОО, приведенные в ПЗ или ЗБ, соответствуют целям безопасности ИТ, а также для учета зависимостей данных требований и показа удовлетворения этих зависимостей. Оценщикам также следует использовать данную часть ИСО/МЭК 15408 при определении того, соответствует ли конкретный ОО предъявленным требованиям.
1. Область применения
Настоящий стандарт устанавливает структуру и содержание компонентов функциональных требований безопасности для оценки безопасности. Он также включает в себя каталог функциональных компонентов, отвечающих общим требованиям к функциональным возможностям безопасности многих продуктов и систем ИТ.
2. Нормативные ссылки
В настоящем стандарте использована ссылка на следующий международный стандарт: ИСО/МЭК 15408-1:2005. Информационная технология - Методы и средства обеспечения безопасности - Критерии оценки безопасности информационных технологий - Часть 1: Введение и общая модель.
3. Термины, определения, обозначения и сокращения
В настоящем стандарте применены термины, обозначения и сокращения по ИСО/МЭК 15408-1.
4. Краткий обзор
ИСО/МЭК 15408 и соответствующие функциональные требования безопасности, описанные ниже, не предназначены для окончательного решения всех задач безопасности ИТ. Скорее настоящий стандарт предлагает совокупность хорошо продуманных функциональных требований безопасности, которые могут применяться при создании доверенных продуктов или систем ИТ, отвечающих потребностям рынка. Эти функциональные требования безопасности представляют современный уровень спецификации требований и оценки.
В настоящий стандарт предполагалось включать только те функциональные требования безопасности, которые на момент издания стандарта были известны и одобрены его разработчиками.
Так как знания и потребности пользователей могут меняться, функциональные требования, представленные в настоящем стандарте, нуждаются в дальнейшем сопровождении. Предполагается, что некоторые разработчики ПЗ/ЗБ могут иметь потребности в безопасности, не охваченные компонентами функциональных требований, представленными в настоящем стандарте. В данном случае разработчик ПЗ/ЗБ может предпочесть использование нестандартных функциональных требований (так называемую "расширяемость") в соответствии с ИСО/МЭК 15408-1, приложения A и B.
4.1. Структура данной части ИСО/МЭК 15408
В разделе 5 приведено описание парадигмы, используемой в функциональных требованиях безопасности настоящего стандарта.
Раздел 6 представляет собой каталог функциональных компонентов.
В разделах 7 - 17 приведено описание функциональных классов.
Приложение A содержит информацию для потенциальных пользователей функциональных компонентов, включая таблицы перекрестных ссылок зависимостей функциональных компонентов.
Приложения B - M содержат информацию для функциональных классов. Этот материал должен рассматриваться в качестве нормативных инструкций по применению соответствующих операций и выбору необходимой информации для аудита и документирования; использование глагола "следует" означает, что конкретная инструкция является предпочтительной, но и другие могут быть обоснованы. В случае, если приводят различные варианты, выбор остается за автором ПЗ/ЗБ.
ИСО/МЭК 15408-1 содержит следующую информацию, необходимую разработчикам ПЗ или ЗБ:
ИСО/МЭК 15408-1, раздел 2, определяет термины, используемые в ИСО/МЭК 15408;
ИСО/МЭК 15408-1, приложение A, определяет структуру профилей защиты;
ИСО/МЭК 15408-1, приложение B, определяет структуру заданий по безопасности;
библиография необходимых документов приведена в элементе "Библиография" ИСО/МЭК 15408-1.
5. Парадигма функциональных требований
В данном разделе приведена парадигма функциональных требований безопасности настоящего стандарта. Некоторые ключевые понятия парадигмы показаны на рисунках 1 и 2. Описаны и другие, не показанные на рисунках 1 и 2, ключевые понятия. Рассматриваемые ключевые понятия выделены полужирным курсивом. Определения терминов, приведенные в ИСО/МЭК 15408-1, раздел 2, в данном разделе не изменяются и не заменяются.
-----------------------------------------------------------
¦Объект оценки (ОО) ¦
¦ Интерфейс ФБО (ИФБО)¦
¦ ----------------- ¦ ¦ ¦
¦ ----------------------+-----------------------+------ ¦ ¦
¦ ¦ Субъект ¦ ¦ ¦
¦ ¦ ---------------- ¦ ¦ ¦
--------------- ¦ ¦ ¦--------------¦ ¦ ¦ ¦
¦Пользователь/¦ ¦ ¦ ¦¦ Атрибуты ¦¦ ----------------------------- ¦ ¦ ¦
¦удаленный +-+-+--+¦безопасности¦+---+> Функции безопасности ОО ¦ ¦ ¦ ¦
¦продукт ИТ ¦ ¦ ¦ ¦--------------¦ ¦ (ФБО), осуществляющие ¦ ¦ ¦
--------------- ¦ ¦ ---------------- ¦ политику безопасности ¦ ¦ ¦
¦ ¦ ¦ ОО (ПБО) ¦ ¦ ¦
¦ ¦ Субъект ¦ ¦ ¦ ¦
¦ ¦ ---------------- ¦ /\ /\ /\ ¦ ¦ ¦ ¦
¦ ¦ ¦--------------¦ L-+---+---+-------+---------- ¦ ¦
--------------- ¦ ¦ ¦¦ Атрибуты ¦+------ ¦ ¦ ¦ ¦ ¦
¦Пользователь +-+-+--+¦безопасност覦 ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦--------------¦ --------- ¦ ¦ ¦ ¦
--------------+ ¦ ¦ ---------------- ¦ ¦ ¦ ¦ ¦
¦ ¦ ¦ ---- Объект/ ¦ ¦ ¦ ¦
¦ ¦ ¦ Субъект ¦ информация ¦ \/ Субъект ¦ ¦
¦ ¦ ¦ --------------+¬-------------+-¬---------------- ¦ ¦
¦ ¦ ¦ ¦--------------¦¦--------------¦¦--------------¦ ¦ ¦
¦ ¦ ¦ ¦¦ Атрибуты ¦¦¦¦ Атрибуты ¦¦¦¦ Атрибуты ¦¦ ¦ ¦
L-+-+--+¦безопасност覦¦¦безопасност覦¦¦безопасност覦 ¦ ¦
¦ ¦ ¦--------------¦¦LT----------T-¦¦LT----------T-¦ ¦ ¦
¦ ¦ ----------------¦ ¦ Ресурс ¦ ¦¦ ¦ Процесс ¦ ¦ ¦ ¦
¦ ¦ ¦ ------------ ¦¦ ------------ ¦ ¦ ¦
¦ ¦ Область действия -------------------------------- ¦ ¦
¦ ¦ ФБО (ОДФ) ¦ ¦
¦ ----------------------------------------------------- ¦
-----------------------------------------------------------
Рисунок 1. Ключевые понятия функциональных требований безопасности (единый ОО)
Локальный Локальный (внутренний для ОО) пользователь доверенный маршрут
------- ¦
¦ ¦
------- ¦
/\
¦<- - - - - - - - - - - - - - - - - - - - - - Передача в пределах ОО
¦ ¦
¦ -----------------------------
¦ ¦ Локальный ОО - - + - - --
¦ ¦ ---¬ ---¬ \/ ¦
¦ ¦ ----+ФБ+-------+ФБ+--¬ ¦
¦ ¦ ¦ ---- ---- ¦ ¦
¦ ¦ -+-¬ -+-¬ ¦
--------------------+>¦ФБ¦ ¦ФБ¦ ¦
¦ LT-- LT-- ¦
¦ ¦ ---¬ ---¬ ¦ ¦
¦ ----+ФБ+-------+ФБ+--- ¦
¦ ---- ---- ¦
¦ /\ ¦
-------------------+---------
/\ . /\
¦ ¦ ¦
Передача вне ОДФ - - - - >¦ - - >. ¦<- - -Передача между ФБО
\/ ¦ ¦ \/
------------------------- . -----------------------
¦Недоверенный продукт ИТ¦ ¦ ¦ ¦Удаленный доверенный ¦
¦ ¦ . ¦ продукт ИТ ¦
¦ ¦ ¦ ¦ ¦ --------------- ¦
¦ ¦ Доверенный L.-.-.+.->¦ФБ удаленного¦ ¦
¦ ¦ маршрут между ¦ ¦ продукта ¦ ¦
¦ ¦ ФБО ¦ L-T------------ ¦
-------------------+----- ------+----------------
. ------- .
L-.-.-.-.-.->¦ ¦<-.-.-.-.-.--
-------
Удаленный
пользователь
Рисунок 2. Функции безопасности в распределенном ОО
Настоящий стандарт содержит каталог функциональных требований безопасности, которые могут быть предъявлены к &объекту оценки (ОО)&. ОО - это продукт или система ИТ (вместе с руководствами администратора и пользователя), содержащие ресурсы типа электронных носителей данных (таких, как диски), периферийных устройств (таких, как принтеры) и вычислительных возможностей (таких, как процессорное время), которые могут использоваться для обработки и хранения информации и являются предметом оценки.
Оценка, прежде всего, подтверждает, что в отношении ресурсов ОО осуществляется определенная &политика безопасности ОО (ПБО)&. ПБО определяет правила, по которым ОО управляет доступом к своим ресурсам и, таким образом, ко всей информации и сервисам, контролируемым ОО.
ПБО в свою очередь состоит из различных &политик функций безопасности (ПФБ)&. Каждая ПФБ имеет свою область действия, определяющую субъекты, объекты и операции, на которые распространяется ПФБ. ПФБ реализуется &функцией безопасности (ФБ)&, чьи механизмы осуществляют политику и предоставляют необходимые возможности.
Совокупность всех функций безопасности ОО, которые направлены на осуществление ПБО, определяется как &функции безопасности объекта оценки (ФБО)&. ФБО объединяют функциональные возможности всех аппаратных, программных и программно-аппаратных средств ОО, на которые как непосредственно, так и косвенно возложено обеспечение безопасности.
&Монитор обращений& - это концепция абстрактной машины, которая осуществляет политику управления доступом ОО. &Механизм проверки правомочности обращений& - реализация концепции монитора обращений, обладающая следующими свойствами: защищенностью от проникновения, постоянной готовностью, простотой, достаточной для проведения исчерпывающего анализа и тестирования. ФБО могут состоять из механизма проверки правомочности обращений и/или других функций безопасности, необходимых для эксплуатации ОО.
ОО может быть единым продуктом, включающим в себя аппаратные, программно-аппаратные и программные средства.
В ином случае ОО может быть распределенным, состоящим из нескольких разделенных частей. Каждая часть ОО обеспечивает выполнение конкретного сервиса для ОО и взаимодействует с другими частями ОО через &внутренний канал связи&. Этот канал может быть всего лишь шиной процессора, а может являться внутренней сетью для ОО.
Если ОО состоит из нескольких частей, то каждая часть может иметь собственное подмножество ФБО, которое обменивается данными ФБО и пользователей через внутренние каналы связи с другими подмножествами ФБО. Это взаимодействие называется &внутренней передачей ОО&. В этом случае части ФБО формируют объединенные ФБО, которые осуществляют ПБО для этого ОО.
Интерфейсы ОО могут быть локализованы в конкретном ОО или допускать взаимодействие с другими продуктами ИТ по &внешним каналам связи&. Внешние взаимодействия с другими продуктами ИТ могут принимать две формы:
a) политика безопасности "удаленного доверенного продукта ИТ" и ПБО рассматриваемого ОО скоординированы и оценены в административном порядке. Обмен информацией в этом случае назван &передачей между ФБО&, поскольку он осуществляется между ФБО различных доверенных продуктов;
b) удаленный продукт ИТ, обозначенный на рисунке 2 как "недоверенный продукт ИТ", не был оценен, поэтому его политика безопасности неизвестна. Обмен информацией в этом случае назван &передачей за пределы области действия ФБО&, так как этот удаленный продукт ИТ не имеет ФБО (или характеристики его политики безопасности неизвестны).
Совокупность взаимодействий, которые могут происходить с ОО или в пределах ОО и подчинены правилам ПБО, относится к &области действия функций безопасности (ОДФ)&. ОДФ включает в себя определенную совокупность взаимодействий в пределах ОО с использованием понятий "субъекты", "объекты" и "операции", но не обязательно охватывает все ресурсы ОО.
Совокупность интерфейсов как интерактивных (человеко-машинный интерфейс), так и программных (интерфейс программных приложений), через которые могут быть получены доступ к ресурсам при посредничестве ФБО или информация от ФБО, называется &интерфейсом ФБО (ИФБО)&. ИФБО определяет границы возможностей функций ОО, которые предоставлены для осуществления ПБО.
Пользователей не включают в состав ОО, поэтому они находятся вне ОДФ. Однако пользователи взаимодействуют с ОО через ИФБО при запросе услуг, которые будут выполняться ОО. Существует два типа пользователей, учитываемых в функциональных требованиях безопасности настоящего стандарта: &человек-пользователь& и &внешняя сущность ИТ&. Для человека-пользователя различают &локального человека-пользователя&, взаимодействующего непосредственно с ОО через устройства ОО (такие как рабочие станции), и &удаленного человека-пользователя&, взаимодействующего с ОО через другой продукт ИТ.
Период взаимодействия между пользователем и ФБО называется &сеансом пользователя&. Открытие сеансов пользователей может контролироваться на основе ряда условий, таких как аутентификация пользователя, время суток, метод доступа к ОО, число параллельных сеансов, разрешенных пользователю, и т.д.
В настоящем стандарте используется термин &уполномоченный& для обозначения пользователя, который обладает правами и/или привилегиями, необходимыми для выполнения операций. Поэтому термин &уполномоченный пользователь& указывает на то, что пользователю разрешается выполнять данную операцию в соответствии с ПБО.
Для выражения требований разделения административных обязанностей соответствующие функциональные компоненты безопасности (из семейства FMT_SMR), приведенные в настоящем стандарте, явно устанавливают обязательность административных &ролей&. Роль - это заранее определенная совокупность правил, устанавливающих допустимые взаимодействия между пользователем и ОО. ОО может поддерживать определение произвольного числа ролей. Например, роли, связанные с операциями безопасности ОО, могут включать в себя роли "Администратор аудита" и "Администратор учета пользователей".
ОО содержит ресурсы, которые могут использоваться для обработки и хранения информации. Основной целью ФБО является полное и правильное осуществление ПБО для ресурсов и информации, которыми управляет ОО.
Ресурсы ОО могут иметь различную структуру и использоваться различными способами. Тем не менее, в настоящем стандарте проводится специальное разграничение, позволяющее специфицировать желательные свойства безопасности. Все сущности, которые могут быть созданы на основе ресурсов, характеризуются одним из двух способов. Сущности могут быть активными, то есть являться причиной действий, которые происходят в пределах ОО, и инициировать операции, выполняемые с информацией. Напротив, сущности могут быть пассивными, то есть являться источником или местом хранения информации.
Активные сущности названы &субъектами&. В пределах ОО могут существовать несколько типов субъектов:
a) действующие от имени уполномоченного пользователя и подчиненные всем правилам ПБО (например, процессы UNIX);
b) действующие как особый функциональный процесс, который может, в свою очередь, действовать от имени многих пользователей (например, функции, которые характерны для архитектуры клиент/сервер);
c) действующие как часть собственно ОО (например, доверенные процессы).
В настоящем стандарте рассматривается осуществление ПБО для субъектов перечисленных выше типов.
Пассивные сущности (то есть хранилища информации) названы &объектами& в функциональных требованиях безопасности настоящего стандарта. Объекты являются предметом операций, которые могут выполняться субъектами. В случае, если субъект (активная сущность) сам является предметом операции (например, при установлении связи между процессами), над субъектом могут производиться действия, как над объектом.
Объекты могут содержать &информацию&. Это понятие требуется, чтобы специфицировать политики управления информационными потоками в соответствии с классом FDP.
Пользователи, субъекты, информация и объекты обладают определенными &атрибутами&, которые содержат информацию, позволяющую ОО правильно функционировать. Некоторые атрибуты, такие как имена файлов, могут предназначаться только для информирования, в то время как другие, например, различные параметры управления доступом, - исключительно для осуществления ПБО. Эти последние обобщенно названы &"атрибутами безопасности"&. В дальнейшем слово "атрибут" используется в настоящем стандарте как сокращение для словосочетания "атрибут безопасности" (если не оговорено иное). Вместе с тем независимо от предназначения информации атрибута могут потребоваться средства управления этим атрибутом в соответствии с ПБО.
В ОО содержатся данные пользователей и данные ФБО. Их взаимосвязь показана на рисунке 3. &Данные пользователей& - это информация, содержащаяся в ресурсах ОО, которая может применяться пользователями в соответствии с ПБО и не предназначена специально для ФБО. Например, содержание сообщения электронной почты является данными пользователя. &Данные ФБО& - это информация, используемая ФБО при осуществлении ПБО. Допускается воздействие пользователей на данные ФБО, если это предусмотрено ПБО. Примерами данных ФБО являются атрибуты безопасности, аутентификационные данные, списки управления доступом.
-----------------------------------------------------------------
¦ ДАННЫЕ ОО ¦
¦ ¦
¦ ---------------- -------------------------------------------- ¦
¦ ¦ ¦ ¦ -------------------------- ¦ ¦
¦ ¦ ¦ ¦ ДАННЫЕ ФБО ¦ Атрибуты безопасности ¦ ¦ ¦
¦ ¦ ¦ ¦ ¦------------------------¦ ¦ ¦
¦ ¦ ¦ ¦-------------- ¦¦Атрибуты пользователе馦 ¦ ¦
¦ ¦ ¦ ¦¦Аутентифика-¦ ¦------------------------¦ ¦ ¦
¦ ¦ ¦ ¦¦ционные ¦ ¦------------------------¦ ¦ ¦
¦ ¦ ДАННЫЕ ¦ ¦¦данные ¦ ¦¦ Атрибуты объектов ¦¦ ¦ ¦
¦ ¦ПОЛЬЗОВАТЕЛЕЙ ¦ ¦¦ ¦ ¦------------------------¦ ¦ ¦
¦ ¦ ¦ ¦¦ ¦ ¦------------------------¦ ¦ ¦
¦ ¦ ¦ ¦¦ ¦ ¦¦ Атрибуты субъектов ¦¦ ¦ ¦
¦ ¦ ¦ ¦¦ ¦ ¦------------------------¦ ¦ ¦
¦ ¦ ¦ ¦¦ ¦ ¦------------------------¦ ¦ ¦
¦ ¦ ¦ ¦¦ ¦ ¦¦ Атрибуты информации ¦¦ ¦ ¦
¦ ¦ ¦ ¦¦ ¦ ¦------------------------¦ ¦ ¦
¦ ¦ ¦ ¦-------------- -------------------------- ¦ ¦
¦ ---------------- -------------------------------------------- ¦
-----------------------------------------------------------------
Рисунок 3. Связь между данными пользователей и данными ФБО
Выделяются ПФБ, которые применяются при защите данных, такие как &ПФБ управления доступом& и &ПФБ управления информационными потоками&. Действия механизмов, реализующих ПФБ управления доступом, основаны на атрибутах субъектов, объектов и операций в пределах области действия. Эти атрибуты используются в совокупности правил, управляющих операциями, которые субъектам разрешено выполнять на объектах.
Функционирование механизмов, реализующих ПФБ управления информационными потоками, основано на атрибутах субъектов и информации в пределах области действия и совокупности правил, по которым выполняются операции субъектов с информацией. Атрибуты информации, которые могут быть ассоциированы с атрибутами места хранения (или не ассоциированы с ними, например, в случае многоуровневой базы данных), остаются с информацией при ее перемещении.
Два специфических типа данных ФБО, рассматриваемых в настоящем стандарте, могут (но необязательно) совпадать. Это &аутентификационные данные& и &секреты&.
Аутентификационные данные используют, чтобы верифицировать заявленный идентификатор пользователя, обращающегося к ОО за услугами. Самая распространенная форма аутентификационных данных - пароль, который необходимо хранить в секрете, чтобы механизм безопасности был эффективен. Однако в секрете необходимо хранить не все формы аутентификационных данных. Биометрические опознавательные устройства (например, считыватели отпечатка пальца или сканеры сетчатки глаза) основываются не на предположении, что аутентификационные данные хранятся в секрете, а на том, что эти данные являются неотъемлемым свойством пользователя, которое невозможно подделать.
Термин "секрет", используемый в функциональных требованиях настоящего стандарта по отношению к аутентификационным данным, применим и к данным других типов, которые необходимо хранить в тайне при осуществлении определенной ПФБ. Например, стойкость механизма доверенного канала, в котором применена криптография для сохранения конфиденциальности передаваемой через канал информации, зависит от надежности способа сохранения в секрете криптографических ключей от несанкционированного раскрытия.
Следовательно, некоторые (но не все) аутентификационные данные необходимо хранить в секрете, и некоторые (но не все) секреты используют как аутентификационные данные. Взаимосвязь секретов и аутентификационных данных представлена на рисунке 4. На рисунке 4 указаны типы данных, которые часто относят к аутентификационным данным и секретам.
------------------------------
¦ &Аутентификационные данные&¦
¦ ¦
¦ Биометрия ¦
¦ Кредитные карточки ¦
¦ ¦
¦ -------+---------------------
¦ ¦Пароли¦ ¦
----------------------+------- ¦
¦ Криптографические ¦
¦ переменные ¦
¦ ¦
¦ ¦
¦ &Секреты& ¦
-----------------------------
Рисунок 4. Связь между понятиями "аутентификационные данные" и "секреты"
6. Функциональные компоненты безопасности
6.1. Краткий обзор
Данный раздел определяет содержание и форму представления функциональных требований настоящего стандарта и предоставляет руководство по организации требований для новых компонентов, включаемых в ЗБ. Функциональные требования объединены в классы, семейства и компоненты.
6.1.1. Структура класса
Структура функционального класса приведена на рисунке 5. Каждый функциональный класс содержит имя класса, представление класса и одно или несколько функциональных семейств.
----------------------
¦Функциональный класс+¬
----------------------¦
¦----------------------
++ Имя класса ¦
¦----------------------
¦----------------------
++Представление класса¦
¦----------------------
¦ ---------------------
¦ --+-------------------¦
¦-+--------------------+-
L+ Функциональные +-
¦ семейства ¦
----------------------
Рисунок 5. Структура функционального класса
6.1.1.1. Имя класса
Имя класса содержит информацию, необходимую для идентификации функционального класса и отнесения его к определенной категории. Каждый функциональный класс имеет уникальное имя. Информация о категории предоставлена кратким именем, состоящим из трех букв латинского алфавита. Краткое имя класса используют при задании кратких имен семейств этого класса.
6.1.1.2. Представление класса
Представление класса обобщает участие семейств класса в достижении целей безопасности. Определение функциональных классов не отражает формальную таксономию в спецификации требований.
Представление класса содержит рисунок, показывающий все семейства этого класса и иерархию компонентов в каждом семействе, как указано в 6.2.
6.1.2. Структура семейства
Структура функционального семейства приведена на рисунке 6.
--------------------------
¦Функциональное семейство+-¬
-------------------------- ¦
¦-------------------------
++ Имя семейства ¦
¦-------------------------
¦-------------------------
++ Характеристика ¦
¦¦ семейства ¦
¦-------------------------
¦-------------------------
++ Ранжирование ¦
¦¦ компонентов ¦
¦-------------------------
¦-------------------------
++ Управление ¦
¦-------------------------
¦-------------------------
++ Аудит ¦
¦-------------------------
¦ ------------------------
¦ --+----------------------¦
¦-+-----------------------+-
L+ Компоненты +-
-------------------------
Рисунок 6. Структура функционального семейства
6.1.2.1. Имя семейства
Имя семейства содержит описательную информацию, необходимую для идентификации и категорирования функционального семейства. Каждое функциональное семейство имеет уникальное имя. Информация о категории состоит из краткого имени, включающего в себя семь символов. Первые три символа идентичны краткому имени класса, далее следуют символ подчеркивания и краткое имя семейства в виде XXX_YYY. Уникальная краткая форма имени семейства предоставляет основное имя ссылки для компонентов.
6.1.2.2. Характеристика семейства
Характеристика семейства - это описание функционального семейства, в котором излагаются его цели безопасности и общее описание функциональных требований. Более детально они описаны ниже:
a) цели безопасности семейства характеризуют задачу безопасности, которая может быть решена с помощью компонентов этого семейства;
b) описание функциональных требований обобщает все требования, которые включены в компонент(ты). Описание ориентировано на разработчиков ПЗ, ЗБ и функциональных пакетов, которые хотели бы определить, соответствует ли семейство их конкретным требованиям.
6.1.2.3. Ранжирование компонентов
Функциональные семейства содержат один или несколько компонентов, каждый из которых может быть выбран для включения в ПЗ, ЗБ и функциональные пакеты. Цель ранжирования компонентов - предоставить пользователям информацию для выбора подходящего функционального компонента, если семейство идентифицировано пользователем как необходимая или полезная часть требований безопасности.
Далее перечисляются имеющиеся компоненты и приводится их обоснование. Детализация компонентов производится в описании каждого компонента.
Связи между компонентами в пределах функционального семейства могут быть иерархическими и неиерархическими. Компонент иерархичен (то есть расположен выше по иерархии) по отношению к другому компоненту, если предлагает большую безопасность.
Описания семейств содержат графическое представление иерархии компонентов, рассмотренное в 6.2.
6.1.2.4. Управление
Требования управления содержат информацию для разработчиков ПЗ/ЗБ, учитываемую при определении действий по управлению для данного компонента. Требования управления детализированы в компонентах класса "Управление безопасностью" (FMT).
Разработчик ПЗ/ЗБ может выбрать указанные требования управления или включить новые, не указанные в настоящем стандарте. В последнем случае следует представить необходимую информацию.
6.1.2.5. Аудит
Требования аудита содержат события, потенциально подвергаемые аудиту, для их отбора разработчиками ПЗ/ЗБ при условии включения в ПЗ/ЗБ требований из класса FAU "Аудит безопасности". Эти требования включают в себя события, относящиеся к безопасности, применительно к различным уровням детализации, поддерживаемым компонентами семейства FAU_GEN "Генерация данных аудита безопасности". Например, запись аудита какого-либо механизма безопасности может включать в себя на разных уровнях детализации действия, которые раскрываются в следующих терминах:
- минимальный - успешное использование механизма безопасности;
- базовый - любое использование механизма безопасности, а также информация о текущих значениях атрибутов безопасности;
- детализированный - любые изменения конфигурации механизма безопасности, включая параметры конфигурации до и после изменения.
Следует учесть, что категорирование событий, потенциально подвергаемых аудиту, всегда иерархично. Например, если выбрана базовая генерация данных аудита, то все события, идентифицированные как потенциально подвергаемые аудиту и поэтому входящие как в "минимальную", так и в "базовую" запись, следует включить в ПЗ/ЗБ с помощью соответствующей операции назначения, за исключением случая, когда событие более высокого уровня имеет более высокий уровень детализации, чем событие более низкого уровня, и может просто заменить его. Если необходима детализированная генерация данных аудита, то все идентифицированные события, потенциально подвергаемые аудиту (для минимального, базового и детализированного уровней), следует включить в ПЗ/ЗБ.
Правила управления аудитом более подробно объяснены в классе FAU "Аудит безопасности".
6.1.3. Структура компонента
Структура функционального компонента показана на рисунке 7.
----------------------
¦ Компонент +¬
----------------------¦
¦--------------------------
++Идентификация компонента¦
¦--------------------------
¦ ------------------------
¦ --+----------------------¦
¦-+-----------------------+-
++Функциональные элементы+-
¦-------------------------
¦-------------------------
L+ Зависимости ¦
-------------------------
Рисунок 7. Структура функционального компонента
6.1.3.1. Идентификация компонента
Идентификация компонента включает в себя описательную информацию, необходимую для идентификации, категорирования, записи и реализации перекрестных ссылок компонента. Для каждого функционального компонента представляются:
- уникальное имя, отражающее предназначение компонента;
- краткое имя, применяемое как основное имя ссылки для категорирования, записи и реализации перекрестных ссылок компонента и уникально отражающее класс и семейство, которым компонент принадлежит, а также номер компонента в семействе;
- список иерархических связей, содержащий имена других компонентов, для которых этот компонент иерархичен и вместо которых может использоваться при удовлетворении зависимостей от перечисленных компонентов.
6.1.3.2. Функциональные элементы
Каждый компонент включает в себя набор элементов. Каждый элемент определяется отдельно и является самодостаточным.
Функциональный элемент - это функциональное требование безопасности, дальнейшее разделение которого не меняет значимо результат оценки; является наименьшим функциональным требованием безопасности, идентифицируемым и признаваемым в ИСО/МЭК 15408.
При формировании ПЗ, ЗБ и/или пакетов не разрешается выбирать только часть элементов компонента. Для включения в ПЗ, ЗБ или пакет необходимо выбирать всю совокупность элементов компонента.
Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2 читается следующим образом: F - функциональное требование, DP - класс "Защита данных пользователя", _IFF - семейство "Функции управления информационными потоками", .4 - четвертый компонент "Частичное устранение неразрешенных информационных потоков", .2 - второй элемент компонента.
6.1.3.3. Зависимости
Зависимости среди функциональных компонентов возникают, если компонент не самодостаточен и нуждается в функциональных возможностях другого компонента либо во взаимодействии с ним для поддержки собственного выполнения.
Каждый функциональный компонент содержит полный список зависимостей от других функциональных компонентов и компонентов доверия. Для некоторых компонентов указано, что зависимостей нет. Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов. Список, приведенный в компоненте, показывает прямые зависимости, то есть содержит ссылки только на функциональные компоненты, заведомо необходимые для обеспечения выполнения рассматриваемого компонента. Косвенные зависимости, определяемые собственными зависимостями компонентов из списка, показаны в Приложении A. В некоторых случаях зависимость выбирают из нескольких предлагаемых функциональных компонентов, причем каждый из них достаточен для удовлетворения зависимости (см., например, FDP_UIT.1 "Целостность передаваемых данных").
Список зависимостей идентифицирует минимум функциональных компонентов или компонентов доверия, необходимых для удовлетворения требований безопасности, ассоциированных с данным компонентом. Компоненты, которые иерархичны по отношению к компоненту из списка, также могут быть использованы для удовлетворения зависимости.
Зависимости между компонентами, указанные в настоящем стандарте, обязательны. Их необходимо удовлетворить в ПЗ/ЗБ. В некоторых, особых случаях эти зависимости удовлетворить невозможно. Разработчик ПЗ/ЗБ, обязательно обосновав, почему данная зависимость неприменима, может не включать соответствующий компонент в пакет, ПЗ или ЗБ.
6.2. Каталог компонентов
Расположение компонентов в настоящем стандарте не отражает какую-либо формальную таксономию.
Настоящий стандарт содержит классы, состоящие из семейств и компонентов, которые сгруппированы на основе общей функции и предназначения. Классы и семейства упорядочены в соответствии с латинским алфавитом. В начале каждого класса представлен рисунок, показывающий таксономию каждого класса, перечисляя семейства в каждом классе и компоненты в каждом семействе. На рисунке также представлена иерархия компонентов внутри каждого семейства.
В описании каждого функционального компонента приведены его зависимости от других компонентов.
Пример представления таксономии класса и иерархии компонентов в его семействах приведен на рисунке 8.
--------------------------
¦ Имя класса ¦
--------+-----------------
¦
¦ ------------------- --¬ --¬ --¬
+--+ Семейство 1 +---+1+-+2+-+3¦
¦ ------------------- L-- L-- L--
¦ --¬
¦ --+1¦
¦ ------------------- ¦ L--
+--+ Семейство 2 +-+
¦ ------------------- ¦ --¬ --¬
¦ L-+2+-+3¦
¦ L-- L--
¦ --¬
¦ --+2+-¬
¦ ------------------- --¬ ¦ L-- ¦ --¬
L--+ Семейство 3 +---+1+-+ --¬ +-+4¦
------------------- L-- L-+3+-- L--
L--
Рисунок 8. Пример декомпозиции класса
В примере первое семейство содержит три иерархических компонента, где компоненты 2 и 3 могут быть применены для выполнения зависимостей вместо компонента 1. Компонент 3 иерархичен компоненту 2 и может применяться для выполнения зависимостей вместо компонента 2.
В семействе 2 имеются три компонента, не все из них иерархически связаны. Компоненты 1 и 2 не иерархичны другим компонентам. Компонент 3 иерархичен компоненту 2 и может применяться для удовлетворения зависимостей вместо компонента 2, но не вместо компонента 1.
В семействе 3 компоненты 2, 3 и 4 иерархичны компоненту 1. Компоненты 2 и 3 иерархичны компоненту 1, но несопоставимы по иерархии между собой. Компонент 4 иерархичен компонентам 2 и 3.
Такие рисунки дополняют текст описания семейств и упрощают идентификацию отношений их компонентов. Они не заменяют пункт "Иерархический для" в описании каждого компонента, который устанавливает обязательные утверждения иерархии для каждого компонента.
6.2.1. Выделение изменений в компоненте
Взаимосвязь компонентов в пределах семейства показана с использованием полужирного шрифта. Все новые требования в тексте компонентов выделены полужирным шрифтом. Для иерархически связанных компонентов требования выделены, если они расширены или модифицированы по сравнению с требованиями предыдущего компонента. Кроме того, любые новые или расширенные по сравнению с предыдущим компонентом разрешенные операции также выделены полужирным шрифтом.
7. Класс FAU. Аудит безопасности
Аудит безопасности включает в себя распознавание, запись, хранение и анализ информации, связанной с действиями, относящимися к безопасности (например, с действиями, контролируемыми ПБО). Записи аудита, получаемые в результате, могут быть проанализированы с тем, чтобы определить, какие действия, относящиеся к безопасности, происходили и кто из пользователей за них отвечает.
--------------------------------- --¬
¦FAU_ARP Автоматическая реакция +---+1¦
¦ аудита безопасности ¦ ¦ ¦
--------------------------------- L--
--¬
--+1¦
--------------------------------- ¦ L--
¦FAU_GEN Генерация данных аудита+-+
¦ безопасности ¦ ¦ --¬
--------------------------------- L-+2¦
L--
--¬
--------------------------------- --¬ --+2¦
¦ FAU_SAA Анализ аудита +---+1+-+ L--
¦ безопасности ¦ L-- ¦ --¬ --¬
--------------------------------- L-+3+--+4¦
L-- L--
--¬
--+1¦
--------------------------------- ¦ L-- --¬
¦ FAU_SAR Просмотр аудита +-+------+2¦
¦ безопасности ¦ ¦ --¬ L--
--------------------------------- L-+3¦
L--
--------------------------------- --¬
¦ FAU_SEL Выбор событий аудита +---+1¦
¦ безопасности ¦ L--
---------------------------------
--¬ --¬
--+1+--+2¦
--------------------------------- ¦ L-- L--
¦FAU_STG Хранение данных аудита +-+ --¬ --¬
¦ безопасности ¦ L-+3+--+4¦
--------------------------------- L-- L--
Рисунок 9. Декомпозиция класса FAU "Аудит безопасности"
7.1. Автоматическая реакция аудита безопасности (FAU_ARP)
7.1.1. Характеристика семейства
Семейство FAU_ARP определяет реакцию на обнаружение событий, указывающих на возможное нарушение безопасности.
7.1.2. Ранжирование компонентов
-------------------------------- --¬
¦ FAU_ARP Автоматическая +---+1¦
¦ реакция аудита безопасности ¦ ¦ ¦
-------------------------------- L--
Рисунок 10. Ранжирование компонентов семейства FAU_ARP
В FAU_ARP.1 "Сигналы нарушения безопасности" ФБО должны предпринимать действия в случае обнаружения возможного нарушения безопасности.
7.1.3. Управление: FAU_ARP.1
Для функций управления из класса FMT могут рассматриваться следующие действия.
a) Управление действиями (добавление, удаление или модификация).
7.1.4. Аудит: FAU_ARP.1
Если в ПЗ/ЗБ включено семейство FAU_GEN "Генерация данных аудита безопасности", то следует предусмотреть возможность аудита следующих действий:
a) минимальный: действия, предпринимаемые в ответ на ожидаемые нарушения безопасности.
7.1.5. FAU_ARP.1 Сигналы нарушения безопасности
Иерархический для: нет подчиненных компонентов.
Зависимости: FAU_SAA.1 Анализ потенциального нарушения
7.1.5.1. FAU_ARP.1.1
#ФБО должны предпринять [назначение: &список наименее разрушительных действий&] при обнаружении возможного нарушения безопасности#.
7.2. Генерация данных аудита безопасности (FAU_GEN)
7.2.1. Характеристика семейства
Семейство FAU_GEN определяет требования к регистрации возникновения событий, относящихся к безопасности, которые подконтрольны ФБО. Данное семейство идентифицирует уровень аудита, перечисляет типы событий, которые потенциально должны подвергаться аудиту с использованием ФБО, и определяет минимальный объем связанной с аудитом информации, которую следует представлять в записях аудита различного типа.
7.2.2. Ранжирование компонентов
--¬
---+1¦
¦ L--
--------------------------------- ¦
¦FAU_GEN Генерация данных аудита+--+
¦ безопасности ¦ ¦
--------------------------------- ¦ --¬
L--+2¦
L--
Рисунок 11. Ранжирование компонентов семейства FAU_GEN
FAU_GEN.1 "Генерация данных аудита" определяет уровень событий, потенциально подвергаемых аудиту, и состав данных, которые должны быть зарегистрированы в каждой записи.
В FAU_GEN.2 "Ассоциация идентификатора пользователя" ФБО должны ассоциировать события, потенциально подвергаемые аудиту, и личные идентификаторы пользователей.
7.2.3. Управление: FAU_GEN.1, FAU_GEN.2
Действия по управлению не предусмотрены.
7.2.4. Аудит: FAU_GEN.1, FAU_GEN.2
Нет событий, для которых следует предусмотреть возможность аудита.
7.2.5. FAU_GEN.1 Генерация данных аудита
Иерархический для: нет подчиненных компонентов.
Зависимости: FPT_STM.1 Надежные метки времени
7.2.5.1. FAU_GEN.1.1
#ФБО должны быть способны генерировать запись аудита для следующих событий, потенциально подвергаемых аудиту:
a) запуск и завершение выполнения функций аудита;
b) все события, потенциально подвергаемые аудиту, на [выбор (выбрать одно из): &минимальный, базовый, детализированный, неопределенный&] уровне аудита;
c) [назначение: &другие специально определенные события, потенциально подвергаемые аудиту&]#.
7.2.5.2. FAU_GEN.1.2
#ФБО должны регистрировать в каждой записи аудита, по меньшей мере, следующую информацию:
a) дата и время события, тип события, идентификатор субъекта и результат события (успешный или неуспешный);
b) для каждого типа событий, потенциально подвергаемых аудиту, из числа определенных в функциональных компонентах, которые включены в ПЗ/ЗБ [назначение: &другая относящаяся к аудиту информация&]#.
7.2.6. FAU_GEN.2 Ассоциация идентификатора пользователя
Иерархический для: нет подчиненных компонентов.
Зависимости: FAU_GEN.1 Генерация данных аудита
FIA_UID.1 Выбор момента идентификации
7.2.6.1. FAU_GEN.2.1
#ФБО должны быть способны ассоциировать каждое событие, потенциально подвергаемое аудиту, с идентификатором пользователя, который был инициатором этого события#.
7.3. Анализ аудита безопасности (FAU_SAA)
7.3.1. Характеристика семейства
Семейство FAU_SAA определяет требования для автоматизированных средств, которые анализируют показатели функционирования системы и данные аудита в целях поиска возможных или реальных нарушений безопасности. Этот анализ может использоваться для поддержки как обнаружения проникновения, так и автоматической реакции на ожидаемое нарушение безопасности.
Действия, предпринимаемые при обнаружении нарушений, могут быть при необходимости определены с использованием семейства FAU_ARP "Автоматическая реакция аудита безопасности".
7.3.2. Ранжирование компонентов
--¬
--+2¦
------------------------------------ --¬ ¦ L--
¦FAU_SAA Анализ аудита безопасности+-+1+-+
------------------------------------ L-- ¦ --¬ --¬
L-+3+-+4¦
L-- L--
Рисунок 12. Ранжирование компонентов семейства FAU_SAA
В FAU_SAA.1 "Анализ потенциального нарушения" требуется базовый порог обнаружения на основе установленного набора правил.
В FAU_SAA.2 "Выявление аномалии, основанное на профиле" ФБО поддерживают отдельные профили использования системы, где профиль представляет собой шаблоны предыстории использования, выполнявшиеся участниками целевой группы профиля. Целевая группа профиля может включать в себя одного или нескольких участников (например, отдельный пользователь; пользователи, совместно использующие общий идентификатор или общие учетные данные; пользователи, которым назначена одна роль; все пользователи системы или сетевого узла), которые взаимодействуют с ФБО. Каждому участнику целевой группы профиля назначается индивидуальный рейтинг подозрительной активности, который показывает, насколько текущие показатели действий участника соответствуют установленным шаблонам использования, представленным в профиле. Этот анализ может проводиться во время функционирования ОО или при анализе данных аудита в пакетном режиме.
В FAU_SAA.3 "Простая эвристика атаки" ФБО должны быть способны обнаружить возникновение характерных событий, которые свидетельствуют о значительной угрозе осуществлению ПБО. Этот поиск характерных событий может происходить в режиме реального времени или при анализе данных аудита в пакетном режиме.
В FAU_SAA.4 "Сложная эвристика атаки" ФБО должны быть способны задать и обнаружить многошаговые сценарии проникновения. Здесь ФБО способны сравнить события в системе (возможно, выполняемые несколькими участниками) с последовательностями событий, известными как полные сценарии проникновения. ФБО должны быть способны указать на обнаружение характерного события или последовательности событий, свидетельствующих о возможном нарушении ПБО.
7.3.3. Управление: FAU_SAA.1
Для функций управления из класса FMT могут рассматриваться следующие действия:
a) сопровождение (добавление, модификация, удаление) правил из набора правил.
7.3.4. Управление: FAU_SAA.2
Для функций управления из класса FMT могут рассматриваться следующие действия:
a) сопровождение (удаление, модификация, добавление) группы пользователей в целевой группе профиля.
7.3.5. Управление: FAU_SAA.3
Для функций управления из класса FMT могут рассматриваться следующие действия:
a) сопровождение (удаление, модификация, добавление) подмножества событий системы.
7.3.6. Управление: FAU_SAA.4
Для функций управления из класса FMT могут рассматриваться следующие действия:
a) сопровождение (удаление, модификация, добавление) подмножества событий системы;
b) сопровождение (удаление, модификация, добавление) набора последовательностей событий системы.
7.3.7. Аудит: FAU_SAA.1, FAU_SAA.2, FAU_SAA.3, FAU_SAA.4
Если в ПЗ/ЗБ включено семейство FAU_GEN "Генерация данных аудита безопасности", то следует предусмотреть возможность аудита следующих действий:
a) минимальный: подключение и отключение любого из механизмов анализа;
b) минимальный: автоматические реакции, выполняемые инструментальными средствами.
7.3.8. FAU_SAA.1 Анализ потенциального нарушения
Иерархический для: нет подчиненных компонентов.
Зависимости: FAU_GEN.1 Генерация данных аудита
7.3.8.1. FAU_SAA.1.1
#ФБО должны быть способны применять набор правил мониторинга событий, подвергающихся аудиту, и указывать на возможное нарушение ПБО, основываясь на этих правилах#.
7.3.8.2. FAU_SAA.1.2
#ФБО должны осуществлять следующие правила при мониторинге событий, подвергающихся аудиту:
a) накопление или объединение известных [назначение: &подмножество определенных событий, потенциально подвергаемых аудиту&], указывающих на возможное нарушение безопасности;
b) [назначение: &другие правила&]#.
7.3.9. FAU_SAA.2 Выявление аномалии, основанное на профиле
Иерархический для: FAU_SAA.1 Анализ потенциального нарушения
Зависимости: FIA_UID.1 Выбор момента идентификации
7.3.9.1. FAU_SAA.2.1
#ФБО должны быть способны сопровождать профили использования системы, где каждый отдельный профиль представляет известные шаблоны предыстории использования, выполнявшиеся участниками [назначение: &спецификация целевой группы профиля&]#.
7.3.9.2. FAU_SAA.2.2
#ФБО должны быть способны сопровождать рейтинг подозрительной активности для каждого пользователя, чьи действия отражены в профиле, где рейтинг подозрительной активности показывает степень несогласованности действий, выполняемых пользователем, с установленными шаблонами использования, представленными в профиле#.
7.3.9.3. FAU_SAA.2.3
#ФБО должны быть способны указывать на ожидаемое нарушение ПБО, когда рейтинг подозрительной активности пользователя превышает следующие пороговые условия [назначение: &условия, при которых ФБО сообщают об аномальных действиях&]#.
7.3.10. FAU_SAA.3 Простая эвристика атаки
Иерархический для: FAU_SAA.1 Анализ потенциального нарушения
Зависимости: нет зависимостей.
7.3.10.1. FAU_SAA.3.1
#ФБО должны быть способны сопровождать внутреннее представление следующих характерных событий [назначение: &подмножество событий системы&], которые могут указывать на нарушение ПБО#.
7.3.10.2. FAU_SAA.3.2
#ФБО должны быть способны сравнивать характерные события с записью показателей функционирования системы, полученных при обработке [назначение: &информация, используемая для определения показателей функционирования системы&]#.
7.3.10.3. FAU_SAA.3.3
#ФБО должны быть способны указывать на ожидаемое нарушение ПБО, когда событие системы соответствует характерному событию, указывающему на возможное нарушение ПБО#.
7.3.11. FAU_SAA.4 Сложная эвристика атаки
Иерархический для: FAU_SAA.3 Простая эвристика атаки
Зависимости: нет зависимостей.
7.3.11.1. FAU_SAA.4.1
ФБО должны быть способны сопровождать внутреннее представление #следующих последовательностей событий известных сценариев проникновения [назначение: &список последовательностей событий системы, совпадение которых характерно для известных сценариев проникновения&]# и следующих характерных событий [назначение: подмножество событий системы], которые могут указывать на возможное нарушение ПБО.
7.3.11.2. FAU_SAA.4.2
ФБО должны быть способны сравнивать характерные события и #последовательности событий# с записью показателей функционирования системы, полученных при обработке [назначение: информация, используемая для определения показателей функционирования системы].
7.3.11.3. FAU_SAA.4.3
ФБО должны быть способны указывать на ожидаемое нарушение ПБО, когда #показатели функционирования системы# соответствуют характерному событию #или последовательности событий#, указывающим на возможное нарушение ПБО.
7.4. Просмотр аудита безопасности (FAU_SAR)
7.4.1. Характеристика семейства
Семейство FAU_SAR определяет требования к средствам аудита, к которым следует предоставить доступ уполномоченным пользователям для использования при просмотре данных аудита.
7.4.2. Ранжирование компонентов
--¬
--+1¦
------------------------- ¦ L--
¦FAU_SAR Просмотр аудита¦ ¦ --¬
¦ безопасности +-+-----+2¦
¦ ¦ ¦ L--
------------------------- ¦ --¬
L-+3¦
L--
Рисунок 13. Ранжирование компонентов семейства FAU_SAR
FAU_SAR.1 "Просмотр аудита" предоставляет возможность читать информацию из записей аудита.
FAU_SAR.2 "Ограниченный просмотр аудита" содержит требование отсутствия доступа к информации кому-либо, кроме пользователей, указанных в FAU_SAR.1 "Просмотр аудита".
FAU_SAR.3 "Выборочный просмотр аудита" содержит требование отбора данных аудита средствами просмотра аудита на основе критериев просмотра.
Комментарии
Комментирование через социальные сервисы Facebook и Вконтакте:
Федеральное