Домашнее задание 2, страница 3

Зависимости: FIA_UID.1.2 Выбор момента идентификации.

1. Защита ФБО (FPT)

FPT_TRC.1.1 – ФБО должны обеспечить согласованность данных ФБО при дублировании их в различных частях ОО.

Зависимости: FPT_ITT.1 Базовая защита внутренней передачи данных ФБО.

FPT_TST.1 – Тестирование ФБО

FPT_TST.1.2 – ФБО должны предоставлять уполномоченным пользователям возможность верифицировать целостность данных ФБО.

Зависимость: FPT_AMT.1 Тестирование абстрактной машины.

FPT_FLS.1 – Сбой с сохранением безопасного состояния

FPT_FLS.1.1 - ФБО должны обеспечивать невозможность несанкционированного доступа к ресурсам внутреннего информационного пространства при следующих типах сбоев:

• сбой в системе электропитания ОО;

• обнаружение нарушения безопасности;

Зависимости: ADV_SPM.1 Неформальная модель ПБО.

FPT_RCV.1 – Ручное восстановление

FPT_RCV.1 - После сбоя или прерывания обслуживания ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию.

Зависимости: FPT_TST.1 Тестирование ФБО

AGD_ADM.1 Руководство администратора

FPT_PHP.1.2 – ФБО должны предоставить возможность определить, произошло ли физическое воздействие на устройства или элементы, реализующие ФБО.

Зависимости: FMT_MOF.1 Управление режимом выполнения функции безопасности.

FPT_STM.1 – Надежные метки времени

FPT_STM.1.1

ФБО должны быть способны предоставить надежные метки времени для собственного использования.

Зависимости: отсутствуют.

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

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

Зависимости: FAU_SAA.1 Анализ потенциального нарушения.

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

FAU_GEN.1.2 - ФБО должны регистрировать в каждой записи аудита, по меньшей мере, следующую информацию:

1. дата и время события, тип события, идентификатор субъекта и результат события (успешный или неуспешный);

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

Зависимости: FPT_STM.1 Надёжные метки времени

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

Зависимости: FAU_GEN.1 Генерация данных аудита

FIA_UID.1 Выбор момента времени идентификации

FAU_SEL.1 - ФБО должны быть способны включать потенциально подвергаемые аудиту события или исключать события из числа событий, подвергающихся аудиту, основываясь на следующих атрибутах: идентификатор субъекта, тип события; время события, дата события.

Зависимости: FAU_GEN.1 Генерация данных аудита

FMT_MTD.1 Управление данными ФБО

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

FAU_SAA.1.2

ФБО должны реализовать следующие правила при мониторинге событий, подвергающихся аудиту:

1. накопление или объединение известных событий:

   • все попытки получения сервисов прикладного уровня;

   • блокированные ФБО;

   • все запросы, адресованные непосредственно к ОО, в том числе для получения информации об архитектуре и конфигурации ФБО;

   • все попытки изменения атрибутов безопасности;

   • все запросы на получение доступа к аутентификационным данным;

   • все запросы на использование механизмов аутентификации;

   • завершение обработки запроса, вызванное рядом неудачных попыток аутентификации;

   • использование функций, относящихся к администрированию ФБО;

   • все попытки изменения параметров конфигурации ФБО.

Зависимости: FAU_GEN.1 Генерация данных аудита

1. Доступ в ОО (FTA)

FTA_SSL.2.1 – ФБО должно допускать инициированное пользователем блокирование своего собственного интерактивного сеанса, для чего предусматривается очистка или перезапись устройств отображения, придание их текущему содержанию нечитаемого вида.

Зависимости: Отсутствуют.

FTA_TAB.1 - Перед открытием сеанса пользователя ФБО должны отобразить предупреждающее сообщение относительно несанкционированного использования ОО.

Зависимости: Отсутствуют.

1. Использование ресурсов (FRU)

FRU_FLT.1 - ФБО должны обеспечить выполнение возврата ОО к безопасному состоянию, генерации записи журнала аудита, осуществления сигнализации о нарушении безопасности, когда происходят нарушения безопасности.

Зависимости: FPT_FLS.1 Сбой с сохранением безопасного состояния.

1. Управление безопасностью (FMT)

FMT_MOF.1.1 - ФБО должны ограничить возможность определения режима функционирования, отключение, подключение, модификацию режима функционирования определенных функций: идентификация и аутентификация субъектов доступа; управление правами доступа субъектов; аудит (регистрация и учет) событий; сигнализация при обнаружении возможного нарушения безопасности только Администратору АСР.

Зависимости: FMT_SMR.1 Роли безопасности

FMT_MSA.3 – Инициализация статических атрибутов

FMT_MSA.3.1 - ФБО должны осуществлять ПФБ управления доступом и информационными потоками, чтобы обеспечить ограничительные значения по умолчанию для атрибутов безопасности, которые используются для осуществления ПФБ.

Зависимости: FMT_MSA.1 Управление атрибутами безопасности

FMT_SMR.1 Роли безопасности

FMT_SMR.1 – Роли безопасности

FMT_SMR.1.2

ФБО должны быть способны ассоциировать пользователей с ролями.

Зависимости: IA_UID.1 Выбор момента времени идентификации

1. Требования доверия к безопасности

Комбинация выбранных компонентов доверия к безопасности соответствует 3-му оценочному уровню доверия к безопасности (ОУД3), предусматривающему методическое тестирование и проверку.

1. Управление конфигурацией (ACM)

   1. Средства контроля авторизации (ACM_CAP.3)

ACM_CAP.3.1D – Разработчик должен обеспечить маркировку для ОО.

ACM_CAP.3.2D – Разработчик должен использовать систему УК.

ACM_CAP.3.3D – Разработчик должен представить документацию УК.

ACM_CAP.3.1C – Маркировка ОО должна быть уникальна для каждой версии ОО.

ACM_CAP.3.2C – ОО должен быть помечен маркировкой.

ACM_CAP.3.3C – Документация УК должна включать список конфигурации и план УК.

ACM_CAP.3.4C – Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.

ACM_CAP.3.5C – Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации.

ACM_CAP.3.6C – Система УК должна уникально идентифицировать все элементы конфигурации.

ACM_CAP.3.7C – План УК должен содержать описание, как используется система УК.

ACM_CAP.3.8C – Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК.

ACM_CAP.3.9C – Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации.

ACM_CAP.3.10C – Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения.

ACM_CAP.3.1Е – Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

1. Охват УК объекта оценки (ACM_SCP.1)

ACM_SCP.1.1D – Разработчик должен представить документацию УК.

ACM_SCP.1.1C – Документация УК должна показать, что система УК, как минимум, отслеживает: представление реализации ОО, проектную документацию, тестовую документацию, документацию пользователя, документацию администратора и документацию УК.

ACM_SCP.1.2C – Документация УК должна содержать описание, как элементы конфигурации отслеживаются системой УК.

ACM_SCP.1.1E – Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

1. Поставка и эксплуатация (ADO)

   1. Процедуры поставки (ADO_DEL.1)

ADO_DEL.1.1D – Разработчик должен задокументировать процедуры поставки ОО или его частей пользователю.

ADO_DEL.1.2.D – Разработчик должен использовать процедуры поставки.

ADO_DEL.1.1C – Документация поставки должна содержать описание всех процедур, необходимых для поддержки безопасности при распределении версий ОО по местам использования.

ADO_DEL.1.1E – Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

1. Процедуры установки, генерации и запуска (ADO_IGS.1)

ADO_IGS.1.1D – Разработчик должен задокументировать процедуры, необходимые для безопасной установки, генерации и запуска ОО.

ADO_IGS.1.1C – Документация должна содержать описание последовательности действий, необходимых для безопасной установки, генерации и запуска ОО.

ADO_IGS.1.1E – Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADO_IGS.1.2E – Оценщик должен сделать независимое заключение, что процедуры установки, генерации и запуска приводят к безопасной конфигурации.

1. Разработка (ADV)

   1. Неформальная функциональная спецификация (ADV_FSP.1)

ADV_FSP.1.1D – Разработчик должен представить функциональную спецификацию.

ADV_FSP.1.1C – Функциональная спецификация должна содержать неформальное описание ФБО и их внешних интерфейсов.

ADV_FSP.1.2C – Функциональная спецификация должна быть внутренне непротиворечивой.

ADV_FSP.1.3C – Функциональная спецификация должна содержать описание назначения и методов использования всех внешних интерфейсов ФБО, обеспечивая, где необходимо, детализацию результатов, нештатных ситуаций и сообщений об ошибках.

ADV_FSP.1.4C – Функциональная спецификация должна полностью представить ФБО.

ADV_FSP.1.1E – Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.

ADV_FSP.1.2E – Оценщик должен сделать независимое заключение, что функциональная спецификация – точное и полное отображение функциональных требований безопасности ОО.

1. Детализация вопросов безопасности в проекте верхнего уровня (ADV_HLD.2)

ADV_HLD.2.1D – Разработчик должен представить проект верхнего уровня ФБО.

ADV_HLD.2.1C – Представление проекта верхнего уровня должно быть неформальным.

ADV_HLD.2.2C – Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.2.3C – Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

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

ADV_HLD.2.5C – Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.2.6C – Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.