Методический документ "Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций" (разработан Банком России)

Перечень сокращений

АСБиФО	- автоматизированная система банковских и финансовых операций
АС	- автоматизированная система
БС	- банковская система
ЗБ	- задание по безопасности
ЗИ	- защита информации
ИБ	- информационная безопасность
ИС	- информационная система
ИТ	- информационная технология
ИФБО	- интерфейс функциональной возможности безопасности объекта оценки
НСД	- несанкционированный доступ
ОО	- объект оценки
ОС	- операционная система
ОУД	- оценочный уровень доверия
ПЗ	- профиль защиты
ПФБ	- политика функции безопасности
ПО	- программное обеспечение
ППО	- прикладное программное обеспечение
СЗИ	- средство защиты информации
СВТ	- средство вычислительной техники
СПО	- системное программное обеспечение
ТДБ	- требования доверия к безопасности объекта оценки
УК	- управление конфигурацией
ФБО	- функциональные возможности безопасности объекта оценки
ФТБ	- функциональные требования безопасности к объекту оценки

1. Общие положения

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

Профиль защиты учитывает положения национальных стандартов Российской Федерации ГОСТ Р ИСО/МЭК 15408 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий", ГОСТ Р 57580.1-2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер", межгосударственного стандарта ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем", а также Рекомендации в области стандартизации Банка России РС БР ИББС-2.6-2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем", требования Положения Банка России от 09.06.2012 N 382-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств", Положения Банка России от 17.04.2019 N 683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента", Положения Банка России от 17.04.2019 N 684-П "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций", иных нормативных актов Банка России, устанавливающих требования к обеспечению защиты информации для кредитных организаций и некредитных финансовых организаций.

2. Введение профиля защиты

Данный раздел содержит информацию общего характера. Подраздел "Справка профиля защиты" содержит идентификационные сведения о профиле защиты (далее - ПЗ), которые включают обозначение и описательную информацию, необходимую для идентификации ПЗ и объекта оценки (далее - ОО), к которому он относится. Подраздел "Аннотация объекта оценки" содержит краткое описание использования ОО и его основные характеристики безопасности.

2.1. Справка профиля защиты

Наименование ПЗ:	Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций.
Тип ПО:	Прикладное программное обеспечение автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций.
Версия ПЗ:	Версия 1.0.
Обозначение ПЗ:	ИТ. ПО АС ФО.ПЗ.
Идентификация ОО:	Прикладное программное обеспечение автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций.
Уровень доверия:	Оценочный уровень доверия 4 (ОУД4), усиленный компонентами ADV_IMP.2 "Полное отображение представления реализации ФБО", ALC_FLR.2 "Процедуры сообщений о недостатках", AVA_VAN.5 "Усиленный методический анализ", расширенный компонентами ADV_IMP_EXT.3 "Реализация ОО", ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения", ALC_LCD_EXT.3 "Определенные разработчиком сроки поддержки", AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность" и AVA_CCA_EXT.1 "Анализ скрытых каналов".
Идентификация:	Нормативные акты Банка России, устанавливающие требования к обеспечению защиты информации для кредитных организаций и некредитных финансовых организаций: Положение Банка России от 09.06.2012 N 382-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств", Положение Банка России от 17.04.2019 N 683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента", Положение Банка России от 17.04.2019 N 684-П "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций", Положение Банка России от 09.01.2019 N 672-П "О требованиях к защите информации в платежной системе Банка России"; Рекомендации в области стандартизации Банка России РС БР ИББС-2.6-2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем", ГОСТ Р 57580.1-2017. "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер", ГОСТ Р ИСО/МЭК 15408 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий", ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем".
Ключевые слова:	Программное обеспечение, автоматизированные системы и приложения кредитных организаций и некредитных финансовых организаций, ОУД4.

2.2. Термины и определения

Администратор ППО	Субъект доступа из состава эксплуатационного персонала, уполномоченный выполнять некоторые действия по администрированию ППО (имеющий административные полномочия) в соответствии с установленной ролью и требуемыми привилегиями в прикладном программном обеспечении финансовой организации и обеспечивающих компонентах АС на выполнение этих действий.
Администратор безопасности	Субъект доступа, ответственный за защиту автоматизированной системы от несанкционированного доступа к информации, на которого возложены обязанности по мониторингу ИБ и контролю защитных мер, аудиту прав и контролю действий пользователей и эксплуатирующего персонала.
Доверенный продукт ИТ	Продукт ИТ, отличный от ОО, для которого имеются свои функциональные требования, организационно скоординированные с ОО, и который, как предполагается, реализует свои функциональные требования корректно.
Задание по безопасности (ЗБ)	Зависимое от реализации изложение потребностей в безопасности для прикладного программного обеспечения и приложений финансовых организаций.
Защищаемая информация	Информация, являющаяся предметом собственности и подлежащая защите в соответствии с требованиями действующего законодательства Российской Федерации или требованиями, устанавливаемыми собственником информации. При этом несанкционированное раскрытие, модификация или сокрытие такой информации может повлечь убытки собственника информации.
Краткая спецификация ОО (КСО)	Описание в ЗБ того, как ОО удовлетворяет ФТБ.
Обеспечивающие компоненты АС	Компоненты обеспечивающей среды функционирования прикладного программного обеспечения автоматизированных систем и приложений финансовых организаций, а также всего аппаратного, программного и программно-аппаратного обеспечения, в том числе системное программное обеспечение, средства вычислительной техники, средства защиты информации.
Объект доступа	В настоящем документе под объектом доступа понимается ресурс доступа - объект, представляющий собой совокупность информации прикладного программного обеспечения автоматизированных систем и приложений финансовых организаций.
Объект оценки (ОО)	ППО автоматизированных систем и приложений финансовых организаций, предназначенных для осуществления финансовых операций, и поддерживающая его документация, выступающие продуктом для оценки. Совокупность программного, программно-аппаратного и/или аппаратного обеспечения, возможно, сопровождаемая руководствами.
Пользователь ППО	Субъект доступа, в том числе клиент финансовой организации, осуществляющий доступ к объекту доступа с целью использования финансовых услуг, предоставляемых информационной инфраструктурой финансовой организации. Пользователь ППО не имеет административных полномочий.
Пользователь	Субъект доступа, которому в соответствии с ФТБ разрешено выполнять некоторые действия (операции) по администрированию ППО или обработке информации в ППО.
Права логического доступа	Набор действий, разрешенных для выполнения субъектом доступа над объектом доступа с использованием соответствующей учетной записи.
Профиль защиты (ПЗ)	Независимое от реализации изложение потребностей в безопасности для прикладного программного обеспечения и приложений финансовых организаций.
Роль	Заранее определенная совокупность функций и задач субъекта доступа, для выполнения которых необходим определенный набор прав логического доступа.
Субъект доступа	Работник финансовой организации или иное лицо (клиент, потребитель услуг), осуществляющий физический и (или) логический доступ, или программный сервис, осуществляющий логический доступ.
Требования доверия к безопасности (ТДБ)	Требования к обеспечению безопасности ОО: требования, обеспечивающие уверенность в том, что прикладное программное обеспечение автоматизированной системы и приложений финансовых организаций соответствует функциональным требованиям безопасности.
Финансовая организация	Кредитная организация и некредитная финансовая организация.
Функция обеспечения ИБ	Реализованная функциональная возможность одного или нескольких компонентов прикладного программного обеспечения автоматизированной системы и приложений финансовых организаций, связанная с обеспечением ИБ.
Функциональное требование безопасности (ФТБ)	Требование к осуществлению безопасности ОО: требования к функциям обеспечения информационной безопасности прикладного программного обеспечения автоматизированной системы и приложений финансовых организаций.
Функциональные возможности безопасности ОО (ФБО)	Совокупность функциональных возможностей всего аппаратного, программного и программно-аппаратного обеспечения ОО, которые необходимо использовать для корректной реализации ФТБ.
Эксплуатационный персонал	Субъект доступа, в том числе представитель подрядной организации, который решает задачи обеспечения эксплуатации и (или) администрирования объекта доступа, для которого необходимо осуществление логического доступа, включая задачи, связанные с эксплуатацией и администрированием технических мер защиты информации.

2.3. Аннотация объекта оценки

2.3.1. Использование и основные функциональные возможности безопасности ОО

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

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

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

При этом ОО:

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

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

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

Состав ФТБ, включенных в настоящий ПЗ, обеспечивает следующие функциональные возможности ОО:

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

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

- защиту персональной идентификационной информации;

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

- использование доверенного пути/канала передачи данных.

Функциональные требования безопасности для ОО выражены на основе компонентов требований из национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности" и специальных (расширенных) компонентов.

Требования доверия к безопасности ОО включают оценочный уровень доверия 4 (ОУД4) согласно ГОСТ Р ИСО/МЭК 15408-3-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", усиленный дополнительными компонентами из ГОСТ Р ИСО/МЭК 15408-3-2013, а также расширенный компонентами, определенными в явном виде. Компоненты требований доверия учитывают положения Рекомендаций в области стандартизации Банка России РС БР ИББС-2.6-2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем".

2.3.2. Тип объекта оценки

Прикладное программное обеспечение автоматизированных систем и приложений финансовых организаций (ППО АС ФО).

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

2.3.3. Доступные аппаратные средства, программное обеспечение, программно-аппаратные средства, не входящие в ОО

В рамках настоящего ПЗ аппаратные средства, программное обеспечение, программно-аппаратные средства, не входящие в ОО, не рассматриваются.

2.4. Соглашения

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

Для удобства восприятия операции "уточнение", "выбор", "назначение" и "итерация" в тексте настоящего ПЗ выделены полужирным шрифтом.

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

Операция "выбор" используется для выбора одного или нескольких элементов из перечня в формулировке компонента требований. Результат операции "выбор" в настоящем ПЗ обозначается подчеркнутым курсивным текстом.

Операция "назначение" используется для присвоения конкретного значения ранее не конкретизированному параметру в компоненте требований. Операция "назначение" обозначается заключением присвоенного значения параметра в квадратные скобки, [назначаемое (присвоенное) значение параметра].

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

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

В ПЗ включен ряд требований безопасности, сформулированных в явном виде (расширенные требования безопасности). Краткая форма имен компонентов требований, сформулированных в явном виде, содержит текст (EXT).

ПЗ содержит ряд компонентов функциональных требований безопасности с незавершенными операциями. Эти операции должны быть завершены в задании по безопасности для конкретной реализации ОО.

3. Утверждение о соответствии

3.1. Утверждение о соответствии ГОСТ Р ИСО/МЭК 15408

Настоящий ПЗ разработан с учетом положений национальных стандартов Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности" и ГОСТ Р ИСО/МЭК 15408-3-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности".

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

3.2. Утверждение о соответствии профилям защиты

Соответствие другим профилям защиты не требуется.

3.3. Утверждение о соответствии пакетам

Настоящий ПЗ соответствует пакету требований доверия: оценочный уровень доверия 4 (ОУД4), усиленный компонентами ADV_IMP.2 "Полное отображение представления реализации ФБО", ALC_FLR.2 "Процедуры сообщений о недостатках", AVA_VAN.5 "Усиленный методический анализ", расширенный компонентами ADV_IMP_EXT.3 "Реализация ОО", ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения", ALC_LCD_EXT.3 "Определенные разработчиком сроки поддержки", AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность" и AVA_CCA_EXT.1 "Анализ скрытых каналов".

3.4. Обоснование соответствия

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

3.5. Изложение соответствия

При разработке ЗБ и (или) других ПЗ на основе настоящего ПЗ устанавливаются следующие типы соответствия: "строгое соответствие" - все требования настоящего ПЗ должны быть полностью удовлетворены в ЗБ, хотя при этом ЗБ может быть более широким, чем ПЗ.

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

4. Определение проблемы безопасности

Данный раздел содержит описание следующих аспектов решаемой с использованием ОО проблемы безопасности:

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

- политик безопасности, которые должен выполнять ОО;

- предположений безопасности (обязательных условий безопасного использования ОО).

4.1. Угрозы

В настоящем ПЗ определены следующие угрозы, которым необходимо противостоять средствами ОО.

Угроза-1

1. Аннотация угрозы - несанкционированный доступ к информации при наличии недостатков и уязвимостей на стороне финансовых организаций.

2. Источники угрозы - внешний или внутренний нарушитель.

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

4. Используемые уязвимости - недостатки реализации механизмов защиты, недостатки механизмов разграничения доступа к ОО по каналам связи, наличие уязвимостей в ОО, использование устаревшего ПО, использование ненадежных механизмов аутентификации и авторизации, нарушение логики работы ОО.

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

6. Нарушаемые свойства безопасности информационных ресурсов - конфиденциальность, целостность.

7. Возможные последствия реализации угрозы - повышение привилегий процессов, команд, пользователей, используемых в ОО, выполнение произвольного кода на удаленной системе, внедрение несанкционированных данных в систему, выполнение несанкционированных действий от имени законного пользователя, внедрение вредоносного ПО в скомпрометированную систему, нарушение целостности и конфиденциальности электронных сообщений.

Угроза-2

1. Аннотация угрозы - возможность перехвата информации, передаваемой между ОО и другими конечными точками.

2. Источники угрозы - внешний нарушитель.

3. Способ реализации угрозы - нарушитель имеет доступ к каналу связи или к узлу сетевой инфраструктуры. Нарушитель может перехватывать и получать доступ к данным, передаваемым между ПО и другими конечными точками, с последующей модификацией передаваемых данных или без таковой.

4. Используемые уязвимости - недостатки и уязвимости в платформе и механизмах обеспечения конфиденциальности и целостности информации, передаваемой между ОО и другими конечными точками.

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

6. Нарушаемые свойства безопасности информационных ресурсов - конфиденциальность, целостность.

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

Угроза-3

1. Аннотация угрозы - воздействие на ПО на стороне клиента.

2. Источники угрозы - внутренний и внешний нарушитель.

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

4. Используемые уязвимости - недостатки в проектировании и в реализации ОО, заражение программного кода, недостатки в программном коде, связанные с ненадлежащим контролем вводимых данных, несовместимость ОО с другим ПО, несовместимость ОО с компонентами среды исполнения, небезопасное хранение данных.

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

6. Нарушаемые свойства безопасности информационных ресурсов - конфиденциальность, целостность.

7. Возможные последствия реализации угрозы - несанкционированное ознакомление с информацией, обрабатываемой в ПО, повышение привилегий скомпрометированного ОО, выполнение произвольного кода в локальной системе, внедрение несанкционированных данных в систему, выполнение несанкционированных действий от имени законного пользователя, внедрение вредоносного ПО в скомпрометированную систему, нарушение конфиденциальности и целостности электронных сообщений и информации, обрабатываемых ПО.

4.2. Политика безопасности

Политика безопасности-1

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

Политика безопасности-2

ОО должен осуществлять:

- проверку корректности входных данных на соответствие синтактической и семантической норме при импорте данных пользователя из-за пределов ОО;

- проверку корректности на соответствие синтактической и семантической норме выходных данных при экспорте данных пользователя из ОО;

- контроль отсутствия защищаемой информации в сообщениях от ППО.

Политика безопасности-3

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

Политика безопасности-4

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

Политика безопасности-5

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

Политика безопасности-6

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

Политика безопасности-7

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

Политика безопасности-8

ОО должен, при необходимости, осуществлять идентификацию, аутентификацию и авторизацию субъектов доступа.

4.3. Предположения безопасности

Предположение-1

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

Предположение-2

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

Предположение-3

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

Предположение-4

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

Предположение-5

В АСБиФО осуществляется защита от выполнения произвольного машинного кода.

Предположение-6

Осуществляется управление физическим доступом к элементам инфраструктуры АСБиФО.

Предположение-7

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

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

Предположение-8

Права на восстановление или смену необратимо утраченных аутентификационных данных предоставлены:

- администраторам безопасности АСБиФО;

- администраторам АСБиФО с обязательным контролем со стороны администратора безопасности АСБиФО;

- иным ответственным ролям эксплуатационного персонала по согласованию с администратором безопасности АСБиФО.

Предположение-9

В АСБиФО присутствуют и используются средства синхронизации времени.

Предположение-10

В АСБиФО имеются средства регистрации событий и просмотра журналов регистрации событий безопасности. При этом, при наличии такой возможности и целесообразности, обеспечивается:

- регистрация отдельных типов событий, существенных для расследования инцидентов, в том числе:

- создание новых учетных записей и изменение прав доступа учетных записей,

- неуспешные операции (например, ошибки аутентификации, недостаточные права доступа при выполнении операций, недоступность интерфейсов составных частей АСБиФО),

- срабатывание функций безопасности, направленных на противодействие компьютерным атакам (например, автоматическое блокирование учетных записей, автоматическое завершение сессий, поступление некорректных исходных данных на внешние интерфейсы АСБиФО),

- выполнение операций, предусмотренных моделью угроз в качестве составной части реализации угрозы;

- регистрация информации о проблемах и инцидентах ИБ, возникших при использовании клиентом компонентов АСБиФО и приложений;

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

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

- регистрация событий безопасности недоступными нарушителю составными частями АСБиФО и приложений;

- хранимые журналы регистрации событий защищены от несанкционированного доступа;

- невозможность изменения пользователями параметров регистрации событий;

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

- наличие механизмов оперативного уведомления администраторов ИБ АСБиФО о событиях, имеющих признаки инцидента безопасности. В финансовой организации определены признаки инцидентов безопасности, способы уведомления о них администраторов ИБ АСБиФО и порядок реагирования на них.

Предположение-11

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

Предположение-12

При использовании в составе АСБиФО СУБД обеспечивается:

- недоступность протоколов взаимодействия с СУБД, использование которых не предусмотрено проектной документацией;

- невозможность доступа составных частей АСБиФО и приложений к функциям СУБД без аутентификации;

- отсутствие у администраторов СУБД учетных записей ОС с правами, не являющимися безусловно необходимыми для обслуживания СУБД;

- отсутствие у технологических учетных записей, используемых составными частями АСБиФО и приложений для доступа к СУБД, прав, не являющихся безусловно необходимыми для выполнения предусмотренных документацией операций;

- обособление СУБД от других составных частей АСБиФО и приложений;

- при наличии такой возможности, использование ограничения доступа к СУБД, в том числе на сетевом уровне;

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

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

Предположение-13

В операционной системе АСБиФО обеспечивается:

- запрет использования незащищенных и слабозащищенных протоколов удаленного доступа к ОС (например, TELNET, PPTP) или с применением дополнительных мер защиты;

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

- отсутствие индивидуальных прав доступа к объектам ОС у отдельных пользователей (права пользователей задаются только в составе соответствующих групп) либо проведение процедур регулярного контроля прав пользователей в ОС, где группы пользователей не предусмотрены;

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

- отсутствие у пользователей, не являющихся администраторами ОС, прав на чтение и (или) модификацию файлов в домашних каталогах других пользователей;

- наличие минимально необходимого количества свободного места на дисках АСБиФО контролируется с использованием автоматизированных средств постоянно либо вручную администраторами АСБиФО с заданной периодичностью;

- соответствие настроек ОС рекомендациям разработчика по ее безопасной настройке;

- отсутствие в ОС серверных компонентов АСБиФО программного обеспечения, не предусмотренного эксплуатационной документацией, или наличие утвержденного разрешенного списка компонентов;

- отсутствие возможности доступа к ОС без аутентификации через вспомогательные и (или) редко используемые интерфейсы;

- аутентификация пользователя при доступе к параметрам BIOS, параметрам загрузчика ядра ОС, входе в режим восстановления системы;

- активация в настройках ядра ОС механизмовнастройки ядра, предотвращающих выполнение кода в области данных и стека;

- активация в настройках ядра ОС функции очистки файла/раздела подкачки виртуальной памяти;

- осуществление контроля и обеспечение конфиденциальности хранения защищаемой информации в оперативной памяти;

- отключение в настройках ОС возможности выгрузки образов областей памяти (дампов) на диск пользователями вручную либо автоматически при возникновении ошибок;

- отключение в настройках ОС возможности гибернации (перехода в ждущий режим);

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

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

Предположение-14

При использовании в АСБиФО технологий виртуализации обеспечивается:

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

- запрет доступа виртуальным машинам к разделяемым ресурсам ОС сервера виртуализации в случаях, когда такой доступ не предусмотрен явно эксплуатационной документацией АСБиФО;

- наличие средств мониторинга объема свободных ресурсов сервера виртуализации;

- ограничение удаленного доступа администраторов сервера виртуализации путем ограничения IP-адресов, с которых разрешен доступ, и сетевого интерфейса для доступа администраторов;

- отсутствие использования для удаленного администрирования сервера виртуализации сетевых интерфейсов, используемых виртуальными машинами;

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

- непосредственный доступ к виртуальным машинам, к физическим дискам и логическим томам памяти сервера виртуализации должен контролироваться СЗИ;

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

- отсутствие использования расширенных механизмов обмена данными между виртуальными машинами, если иное не предусмотрено эксплуатационной документацией;

- невозможность изменения пользователем режима загрузки виртуальной машины.

Предположение-15

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

Предположение-16

В АСБиФО присутствуют и используются:

- механизмы защиты от несанкционированного доступа к настройкам приложения;

- средства контроля целостности программного кода и корректности настроек составных частей АСБиФО;

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

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

- Используются механизмы установления защищенного соединения и/или взаимной аутентификации серверной и клиентской стороны.

Предположение-17

Предполагается, что на стадиях приемки и ввода в действие в части обеспечения ИБ ставятся задачи:

- контроля развертывания компонентов АСБиФО в информационной инфраструктуре организации БС;

- проведения опытной эксплуатации;

- устранения недостатков в реализации требований частного технического задания на подсистему ИБ АСБиФО;

- проведения приемочных испытаний.

Предполагается, что для контроля развертывания компонентов АСБиФО в промышленной среде:

- обеспечивается контроль корректности версий и целостности компонентов АСБиФО при передаче из среды разработки и тестирования в промышленную среду;

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

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

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

Предположение-18

Шифрование применяется с использованием стойких криптографических алгоритмов. Все учетные данные для проверки подлинности хранятся и передаются только в защищенном виде с использованием стойких криптографических алгоритмов или по зашифрованному каналу передачи данных.

5. Цели безопасности

5.1.  Цели безопасности для объекта оценки

В данном разделе дается описание целей безопасности для ОО.

Цель безопасности ОО-1

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

Цель безопасности ОО-2

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

Цель безопасности ОО-3

ОО должен предоставлять пользователю возможность управлять уровнем раскрытия любой персональной идентификационной информации.

Цель безопасности ОО-4

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

Цель безопасности ОО-5

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

Цель безопасности ОО-6

ОО должен при необходимости обеспечивать идентификацию, аутентификацию и авторизацию пользователей ППО.

5.2. Цели безопасности для среды функционирования

В данном разделе дается описание целей безопасности для среды функционирования ОО.

Цель безопасности среды-1

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

Цель безопасности среды-2

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

Цель безопасности среды-3

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

Цель безопасности среды-4

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

Цель безопасности среды-5

Права на восстановление или смену необратимо утраченных аутентификационных данных должны быть предоставлены:

- администраторам безопасности ППО АС;

- администраторам ППО АС;

- иным лицам по согласованию с администратором безопасности ППО АС;

- пользователям АС только при реализации безопасных механизмов автоматизированного восстановления (например, с использованием альтернативного канала связи);

- использовать безопасные механизмы автоматизированного восстановления.

Цель безопасности среды-6

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

Цель безопасности среды-7

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

Цель безопасности среды-8

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

Цель безопасности среды-9

Условия безопасного использования сторонних программных продуктов (например, СУБД) должны быть описаны в документации на ППО и обеспечиваться при его эксплуатации.

Цель безопасности среды-10

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

Цель безопасности среды-11

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

Цель безопасности среды-12

Должен обеспечиваться доверенный маршрут/канал передачи данных между ПО и другими компонентами ППО.

5.3.  Обоснование целей безопасности

В таблице 5.1 приведено отображение целей безопасности для ОО на угрозы и политику безопасности.

Таблица 5.1 - Отображение целей безопасности для ОО на угрозы и политику безопасности

	Цель безопасности ОО-1	Цель безопасности ОО-2	Цель безопасности ОО-3	Цель безопасности ОО-4	Цель безопасности ОО-5	Цель безопасности ОО-6
Угроза - 1		+	+	+
Угроза - 2				+
Угроза - 3	+	+
Политика безопасности-1					+
Политика безопасности-2			+	+
Политика безопасности-3	+
Политика безопасности-4		+
Политика безопасности-5	+
Политика безопасности-6	+
Политика безопасности-7	+
Политика безопасности-8						+

Цель безопасности-1

Достижение этой цели безопасности необходимо для противостояния угрозе Угроза-3 и реализации политик безопасности Политика безопасности-3, Политика безопасности-5, Политика безопасности-6, Политика безопасности-7, так как обеспечивает использование разрешенных механизмов безопасности среды функционирования.

Цель безопасности-2

Достижение этой цели безопасности необходимо для противостояния угрозам Угроза-1, Угроза-3 и реализации политики безопасности Политика безопасности-4, так как обеспечивает использование корректных интерфейсов управления и конфигурирования ОО.

Цель безопасности-3

Достижение этой цели безопасности необходимо для противостояния угрозе Угроза-1 и реализации политики безопасности Политика безопасности-2, так как обеспечивает защиту персональной идентификационной информации.

Цель безопасности-4

Достижение этой цели безопасности необходимо для противостояния угрозам Угроза-1, Угроза-2 и реализации политики безопасности Политика безопасности-2, так как обеспечивает использование надежных каналов передачи данных.

Цель безопасности-5

Достижение этой цели безопасности необходимо для реализации политики безопасности Политика безопасности-1, так как обеспечивает регистрацию событий безопасности.

Цель безопасности-6

Достижение этой цели безопасности необходимо для реализации политики безопасности Политика безопасности-8, так как обеспечивает управление учетными записями пользователя.

6. Определение расширенных компонентов

В данном разделе представлены расширенные компоненты ПЗ.

6.1. Определение расширенных компонентов функциональных требований безопасности объекта оценки

Для ОО определены следующие компоненты функциональных требований безопасности, сформулированные в явном виде: FDP_DAR_EXT.1 "Шифрование защищаемой информации приложения", FIA_IWS_EXT.1 "Идентификация сессий веб-приложений", FMT_CFG_EXT.1 "Конфигурация безопасности по умолчанию", FMT_MEC_EXT.1 "Поддерживаемый механизм конфигурации", FPR_ANO_EXT.1 "Согласие пользователей на обработку персональных данных (идентификационной информации)", FPT_AEX_EXT.1 "Противодействие использованию уязвимостей безопасности", FPT_API_EXT.1 "Использование поддерживаемых сервисов и прикладных программных интерфейсов", FPT_LIB_EXT.1 "Использование сторонних библиотек", FPT_TUD_EXT.1 "Целостность при установке и обновлении", FTP_DIT_EXT.1 "Защита данных при передаче" - в стиле компонентов из национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности" (расширенные (специальные) компоненты).

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

6.2.  Определение расширенных компонентов требований доверия к безопасности объекта оценки

Для ОО определены следующие расширенные (специальные) компоненты требований доверия к безопасности: ADV_IMP_EXT.3 "Реализация ОО", ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения ОО", ALC_LCD_EXT.3 "Определенные разработчиком сроки поддержки", AVA_CCA_EXT.1 "Анализ скрытых каналов" и AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность", сформулированные в явном виде в стиле компонентов из национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности".

Компоненты требований доверия к безопасности, сформулированные в явном виде, представлены в приложении Б к настоящему ПЗ.

7. Требования безопасности

В данном разделе ПЗ представлены функциональные требования и требования доверия, которым должен удовлетворять ОО. Функциональные требования, представленные в настоящем ПЗ, основаны на функциональных компонентах из ГОСТ Р ИСО/МЭК 15408-2. Кроме того, в настоящий ПЗ включен ряд требований безопасности, сформулированных в явном виде (расширение ГОСТ Р ИСО/МЭК 15408-2). Требования доверия основаны на компонентах требований доверия из ГОСТ Р ИСО/МЭК 15408-3 и представлены в настоящем ПЗ в виде оценочного уровня доверия ОУД4, усиленного компонентами ADV_IMP.2 "Полное отображение представления реализации ФБО", ALC_FLR.2 "Процедуры сообщений о недостатках", AVA_VAN.5 "Усиленный методический анализ", расширенный компонентами ADV_IMP_EXT.3 "Реализация ОО", ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения", ALC_LCD_EXT.3 "Определенные разработчиком сроки поддержки", AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность" и AVA_CCA_EXT.1 "Анализ скрытых каналов". Ряд требований безопасности, сформулированных в явном виде и в виде усиления ОУД4, определен в разделе 6 настоящего документа.

7.1.  Функциональные требования безопасности

Функциональные компоненты из национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", на которых основаны ФТБ ОО, а также компоненты сформулированных в явном виде расширенных (специальных) требований приведены в таблице 7.1.

Таблица 7.1 - Функциональные компоненты, на которых основаны
ФТБ ОО

Идентификатор компонента требований	Название компонента требований
FAU_GEN.1	Генерация данных аудита
FAU_GEN.2	Ассоциация идентификатора пользователя
FAU_SAR.1	Просмотр аудита
FAU_SAR.2	Ограниченный просмотр аудита
FAU_STG.1	Защищенное хранение журнала аудита
FAU_STG.3	Действия в случае возможной потери данных аудита
FAU_STG.4	Предотвращение потери данных аудита
FDP_ACC.1	Ограниченное управление доступом
FDP_ACF.1	Управление доступом, основанное на атрибутах безопасности
FDP_DAR_EXT.1	Шифрование защищаемой информации приложения
FDP_ETC.1	Экспорт данных пользователя без атрибутов безопасности
FDP_IFC.1	Ограниченное управление информационными потоками
FDP_IFF.1	Простые атрибуты безопасности
FDP_ITC.2	Импорт данных пользователя с атрибутами безопасности
FDP_RIP.2	Полная защита остаточной информации
FDP_ROL.1	Базовый откат
FIA_AFL.1	Обработка отказов аутентификации
FIA_ATD.1	Определение атрибутов пользователя
FIA_IWS_EXT.1	Идентификация сессий веб-приложений
FIA_SOS.1	Верификация секретов
FIA_SOS.2	Генерация секретов ФБО
FIA_UAU.2	Аутентификация до любых действий пользователя
FIA_UAU.4	Механизмы одноразовой аутентификации
FIA_UAU.5	Сочетание механизмов аутентификации
FIA_UAU.7	Аутентификация с защищенной обратной связью
FIA_UID.1	Выбор момента идентификации
FMT_CFG_EXT.1	Конфигурация безопасности по умолчанию
FMT_MEC_EXT.1	Поддерживаемый механизм конфигурации
FMT_MSA.1	Управление атрибутами безопасности
FMT_MSA.3	Инициализация статических атрибутов
FMT_MTD.1	Управление данными ФБО
FMT_SMF.1	Спецификация функций управления
FMT_SMR.1	Роли безопасности
FPR_ANO_EXT.1	Согласие пользователей на обработку персональных данных (идентификационной информации)
FPT_AEX_EXT.1	Противодействие использованию уязвимостей безопасности
FPT_API_EXT.1	Использование поддерживаемых сервисов и прикладных программных интерфейсов
FPT_LIB_EXT.1	Использование сторонних библиотек
FPT_STM.1	Надежные метки времени
FPT_TDC.1	Базовая согласованность данных ФБО между ФБО
FPT_TST.1	Тестирование функциональных возможностей безопасности
FPT_TUD_EXT.1	Целостность при установке и обновлении
FTA_MCS.1	Базовое ограничение на параллельные сеансы
FTP_DIT_EXT.1	Защита данных при передаче
FTP_ITC.1	Доверенный канал передачи между ФБО

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

FAU_GEN.1 Генерация данных аудита
FAU_GEN.1.1	ФБО должны быть способны генерировать запись аудита для следующих событий, потенциально подвергаемых аудиту: а) запуск и завершение выполнения функций аудита; б) создание новых учетных записей и изменение прав доступа учетных записей; в) неуспешные операции (например, ошибки аутентификации, недостаточные права доступа при выполнении операций, недоступность интерфейсов ОО); г) срабатывание функций безопасности, направленных на противодействие компьютерным атакам (например, автоматическое блокирование учетных записей, автоматическое завершение сессий, поступление некорректных исходных данных на внешние интерфейсы ОО); д) выполнение операций, предусмотренных моделью угроз в качестве составной части реализации угрозы; е) все события, потенциально подвергаемые аудиту, на детализированном уровне аудита; ж) события, приведенные в таблице 7.2; з) [назначение: другие специально определенные события, потенциально подвергаемые аудиту]. и) все сеансы персонального доступа пользователей к данным платежных карт; к) все действия, совершенные любым лицом с привилегиями суперпользователя (root) или администратора;
FAU_GEN.1.2	ФБО должны регистрировать в каждой записи аудита по меньшей мере следующую информацию: а) дата и время события, тип события, идентификатор субъекта (если применимо) и результат события (успешный или неуспешный); б) для каждого типа событий, потенциально подвергаемых аудиту, из числа определенных в функциональных компонентах, которые включены в ПЗ/ЗБ, [назначение: другая относящаяся к аудиту информация].
FAU_GEN_EXT.1 ФБО не должны регистрировать в записях аудита защищаемую информацию, если иное не предусмотрено целями функционирования и техническими особенностями, а также ограничениями реализации АСБиФО: [выбор:
	пароли пользователей; полные номера платежных карт и критичные авторизационные данные; закрытые криптографические ключи; [назначение: другая защищаемая информация] ].

Таблица 7.2 - События, подлежащие аудиту

Компонент	Событие	Детализация
FAU_GEN.1	Запуск и завершение выполнения функций аудита
FIA_AFL.1 FIA_ATD.1 FIA_IWS_EXT.1 FIA_SOS.1 FIA_SOS.2 FIA_UAU.2 FIA_UAU.4 FIA_UAU.5 FIA_UAU.7 FIA_UID.1	Запись аудита для событий, связанных с идентификацией и аутентификацией	Регистрируются успешные и неуспешные события, связанные с процессом идентификации и аутентификации
FDP_ACC.1 FDP_ACF.1 FDP_ETC.1 FDP_ITC.2 FDP_RIP.2 FDP_ROL.1 FDP_DAR_EXT.1 FTP_DIT_EXT.1	Запись аудита для событий, связанных с управлением доступом.	Регистрируются успешные и неуспешные события, связанные с процессами авторизации, правами доступа, управления потоками информации при импорте/ экспорте, защиты данных
FMT_MSA.1 FMT_MSA.3 FMT_MEC_EXT.1 FMT_CFG_EXT.1	Запись аудита для событий, связанных c управлением безопасности	Регистрируются успешные и неуспешные события, связанные c администрированием функций безопасности, настройкой параметров и конфигураций безопасности
FPT_AEX_EXT.1	Запись аудита для событий, связанных с противодействием компьютерным атакам	Например, автоматическое блокирование учетных записей, автоматическое завершение сессий, поступление некорректных исходных данных на внешние интерфейсы ППО
FPT_TST.1	Запись аудита для событий, связанных с выполнением и результатами самотестирования ФБО
FPT_TUD_EXT.1	Запись аудита для событий, связанных с контролем целостности при установке и обновлении
FTA_MCS.1	Запись аудита для событий, связанных с фиксацией числа параллельных сеансов пользователя, а также атрибутов безопасности этого пользователя
FTP_DIT_EXT.1	Запись аудита для событий, связанных с нарушением конфиденциальности данных при передаче

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

Замечания по применению:

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

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

Производитель должен установить следующие требования к пользователю по эксплуатации:

FAU_GEN.2 Ассоциация идентификатора пользователя
FAU_GEN.2.1	Для аудита событий, являющихся результатом действий идентифицированных пользователей, ФБО должны быть способны ассоциировать каждое событие, потенциально подвергаемое аудиту, с идентификатором пользователя, который был инициатором этого события.
Зависимости:	FAU_GEN. 1 Генерация данных аудита FIA_UID.1 Выбор момента идентификации
FAU_SAR.1 Просмотр аудита
FAU_SAR.1.1	ФБО должны предоставлять [назначение: уполномоченные пользователи] возможность читать [назначение: список информации аудита] из записей аудита.
FAU_SAR.1.2	ФБО должны предоставлять записи аудита в виде, позволяющем пользователю воспринимать содержащуюся в них информацию.
Зависимости:	FAU_GEN. 1 Генерация данных аудита.
FAU_SAR.2 Ограниченный просмотр аудита
FAU_SAR.2.1	ФБО должны запретить всем пользователям доступ к чтению записей аудита, за исключением пользователей, которым явно предоставлен доступ для чтения.
Зависимости:	FAU_SAR.1 "Просмотр аудита".
FAU_STG.1 Защищенное хранение журнала аудита
FAU_STG.1.1	ФБО должны защищать хранимые записи аудита в журнале аудита от несанкционированного удаления.
FAU_STG.1.2	ФБО должны быть способны [выбор, (выбрать одно из): предотвращать; выявлять ] несанкционированную модификацию хранимых записей аудита в журнале аудита.
Зависимости:	FAU_GEN. 1 Генерация данных аудита.
FAU_STG.3 Действия в случае возможной потери данных аудита
FAU_STG.3.1	ФБО должны выполнить [назначение: действия, которые нужно предпринять в случае возможного сбоя хранения журнала аудита], если журнал аудита превышает [ назначение: принятое ограничение].
Зависимости:	FAU_STG. 1 Защищенное хранение журнала аудита.
FAU_STG.4 Предотвращение потери данных аудита
FAU_STG.4.1	ФБО должны [выбор (выбрать одно из): игнорировать события, подвергающиеся аудиту; записывать поверх самых старых хранимых записей аудита ] и [назначение: другие действия, которые нужно предпринять в случае возможного сбоя хранения журнала аудита] при переполнении журнала аудита.
Зависимости:	FAU_STG. 1 Защищенное хранение журнала аудита.

.

7.1.2. Защита данных пользователя (FDP)

FDP_ACC.1 Ограниченное управление доступом
FDP_ACC.1.1	ФБО должны осуществлять ПФБ [выбор: управление доступом отсутствует; дискреционное управление доступом; ролевое управление доступом; мандатное управление доступом ] для [назначение: список субъектов, объектов и операций субъектов на объектах, на которые распространяется ПФБ].
Зависимости:	FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности.
FDP_ACF.1	Управление доступом, основанное на атрибутах безопасности
FDP_ACF.1.1	ФБО должны осуществлять [политику управления доступом, определенную в FDP_ACC.1.1] к объектам, основываясь на [назначение: список субъектов и объектов, находящихся под управлением указанной ПФБ, и для каждого из них - относящиеся к данной ПФБ атрибуты безопасности или именованные группы атрибутов безопасности].
FDP_ACF.1.2	ФБО должны осуществлять следующие правила определения того, разрешена ли операция управляемого субъекта на управляемом объекте: [назначение: правила управления доступом управляемых субъектов к управляемым объектам с использованием управляемых операций на них].
FDP_ACF.1.3	ФБО должны явно разрешать доступ субъектов к объектам, основываясь на следующих дополнительных правилах: [назначение: правила, основанные на атрибутах безопасности, которые явно разрешают доступ субъектов к объектам].
FDP_ACF.1.4	ФБО должны явно отказывать в доступе субъектов к объектам, основываясь на следующих дополнительных правилах: [назначение: правила, основанные на атрибутах безопасности, которые явно запрещают доступ субъектов к объектам].
Зависимости:	FDP_ACC.1 Ограниченное управление доступом FMT_MSA.3 Инициализация статических атрибутов

Замечания по применению:

В качестве объектов доступа ПФБ следует в том числе рассматривать:

- сетевые соединения;

- устройства ввода-вывода информации;

- съемные носители информации;

- службы определения местоположения;

- хранилища защищаемой информации;

- другие аппаратные и программные ресурсы.

FDP_DAR_EXT.1 Шифрование защищаемой информации ОО
FDP_DAR_EXT.1.1	ФБО должны [выбор: не хранить любую защищаемую информацию; усилить предоставленную платформой функциональность для шифрования защищаемой информации; реализовать функциональность для шифрования защищаемой информации; определить необходимость шифрования защищаемой информации в высокопроизводительных системах с высокой критичностью по времени передачи данных; использовать альтернативные методы зашиты защищаемой информации; ] в энергонезависимой памяти.
Зависимости:	отсутствуют.
FDP_ETC.1 Экспорт данных пользователя без атрибутов безопасности
FDP_ETC.1.1	ФБО должны осуществлять [ проверку корректности выходных данных, в том числе: - отсутствие возможности формирования серверными компонентами ППО исполняемых файлов и сценариев на основе задаваемых пользователями исходных данных; - отсутствие возможности включения в выходные данные, передаваемые между составными частями ППО, фрагментов, не соответствующих спецификациям протоколов взаимодействия и (или) используемых для эксплуатации типовых уязвимостей; контроль отсутствия в видимых пользователями сообщениях об ошибках защищаемой информации (например, аутентификационных данных, сведений, идентифицирующих программное обеспечение составных частей ППО, диагностической информации, содержащей подобные данные); контроль отсутствия защищаемой и аутентификационной информации в сообщениях HTTP любого типа ], при экспорте данных пользователя, контролируемом ПФБ, за пределы ОО.
FDP_ETC.1.2	ФБО должны экспортировать данные пользователя без атрибутов безопасности, ассоциированных с данными пользователя.
Зависимости:	[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками].
FDP_IFC.1	Ограниченное управление информационными потоками
FDP_IFC.1.1	ФБО должны осуществлять [назначение: ПФБ управления информационными потоками] для [назначение: список субъектов, информации и операций перемещения управляемой информации к управляемым субъектам и от них, на которые распространяется ПФБ].
Зависимости:	FDP_IFF.1 Простые атрибуты безопасности.
FDP_IFF.1 Простые атрибуты безопасности
FDP_IFF.1.1	ФБО должны осуществлять [назначение: ПФБ управления информационными потоками], основанную на следующих типах атрибутов безопасности субъекта и информации: [назначение: список субъектов и типов информации, находящихся под управлением указанной ПФБ, и для каждого из них - атрибуты безопасности].
FDP_IFF.1.2	ФБО должны разрешать информационный поток между управляемым субъектом и управляемой информацией посредством управляемой операции, если выполняются следующие правила: [назначение: основанные на атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации (для каждой операции)].
FDP_IFF.1.3	ФБО должны осуществлять [назначение: дополнительные правила ПФБ управления информационными потоками].
FDP_IFF.1.4	ФБО должны явно разрешать информационный поток, основываясь на следующих правилах: [назначение: основанные на атрибутах безопасности правила, которые явно разрешают информационные потоки].
FDP_IFF.1.5	ФБО должны явно запрещать информационный поток, основываясь на следующих правилах: [назначение: основанные на атрибутах безопасности правила, которые явно запрещают информационные потоки].
Зависимости:	FDP_IFC.1 Ограниченное управление информационными потоками FMT_MSA.3 Инициализация статических атрибутов
FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности
FDP_ITC.2.1	ФБО должны осуществлять [ предварительную проверку корректности входных данных (в том числе проверку ограничений на длину текстовых строк, отсутствие в них недопустимых символов и комбинаций символов, соответствие числовых значений граничным условиям); контроль наличия в параметрах веб-формы, предназначенных для ввода защищаемой информации, директив, запрещающих кеширование данных; контроль наличия атрибута HTTPOnly у параметров cookie, значения которых не должны быть доступны сценариям, выполняемым веб-браузером; контроль наличия атрибута secure у параметров cookie, содержащих защищаемую информацию; контроль наличия директивы, определяющей используемую кодировку в заголовках сообщений HTTP, а также отсутствия использования разных кодировок для разных источников входных данных; контроль корректности входных данных, предназначенных для последующей обработки программными модулями, допускающими интерпретацию команд (SQL, XPath, LINQ, LDAP, командная оболочка ОС и т.п.); контроль наличия атрибута secure у параметров cookie, содержащих защищаемую информацию; преобразование специальных символов, предусмотренное спецификациями языка HTML (например, замена символов '<' и '>' специальными символами языка HTML); [назначение: другую ПФБ управления доступом и/или ПФБ управления информационными потоками] ] при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОО.
FDP_ITC.2.2	ФБО должны использовать атрибуты безопасности, ассоциированные с импортируемыми данными пользователя.
FDP_ITC.2.3	ФБО должны обеспечить, чтобы используемый протокол предусматривал однозначную ассоциацию между атрибутами безопасности и полученными данными пользователя.
FDP_ITC.2.4	ФБО должны обеспечить, чтобы интерпретация атрибутов безопасности импортируемых данных пользователя была такой, как предусмотрено источником данных пользователя.
FDP_ITC.2.5	ФБО должны осуществлять следующие правила при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОО: [назначение: дополнительные правила управления импортом].
FDP_ITC.2.6	ФБО должны использовать встроенные средства проверки корректности входных параметров, реализованные в стандартных программных библиотеках.
Зависимости:	[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками]. [FTP_ITC. 1 Доверенный канал передачи между ФБО или FTP_TRP.1 Доверенный маршрут] FPT_TDC.1 Базовая согласованность данных ФБО между ФБО.
FDP_RIP.2 Полная защита остаточной информации
FDP_RIP.2.1	ФБО должны обеспечить недоступность любого предыдущего информационного содержания ресурсов при [выбор: распределение ресурса, освобождение ресурса ] для всех объектов.
Зависимости:	отсутствуют.

Замечания по применению:

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

Работы оценки

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

FDP_ROL.1 Базовый откат
FDP_ROL.1.1	ФБО должны осуществлять, при наличии технической возможности, [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы разрешать откат [назначение: список операций] на [назначение: список объектов].
Зависимости:	[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками].

7.1.3. Идентификация и аутентификация (FIA)

FIA_AFL.1 Обработка отказов аутентификации
FIA_AFL.1.1	ФБО должны обнаруживать, когда произойдет [выбор: [назначение: положительное целое число]; устанавливаемое администратором положительное целое число в пределах [назначение: диапазон допустимых значений] ] неуспешных попыток аутентификации, относящихся к [назначение: список событий аутентификации].
FIA_AFL.1.2	При [выбор: достижении; превышении ] установленного числа неуспешных попыток аутентификации ФБО должны выполнить [выбор: блокирование доступа пользователя в ОО; требование ввода пользователем дополнительной информации при невозможности ввода этой информации в автоматическом режиме ]
FIA_AFL.1.3	При истечении [назначение: интервал времени] от момента блокирования доступа пользователя в ОО по неуспешным попыткам аутентификации ФБО должны выполнить автоматическое разблокирование доступа пользователя в ОО.
Зависимости:	FIA_UAU.2 Аутентификация до любых действий пользователя.
FIA_ATD.1 Определение атрибутов пользователя
FIA_ATD.1.1	ФБО должны поддерживать для каждого пользователя следующий список атрибутов безопасности [назначение: список атрибутов безопасности]. Зависимости: отсутствуют.
FIA_IWS_EXT.1 Идентификация сессий веб-приложений
FIA_IWS_EXT.1.1	ФБО должны [уточнение: определить минимальную длину идентификатора в размере 8 символов] [выбор: нет идентификации сессий веб-приложений; исключать использование предсказуемых идентификаторов сессий; исключать возможность повторного использования идентификатора сессии (в том числе использование одинаковых идентификаторов в нескольких сессиях одного пользователя, неизменность идентификатора сессии после повторной аутентификации пользователя); исключать возможность использования идентификатора сессии после ее завершения; исключать возможность раскрытия идентификаторов сессий, в том числе передачу идентификаторов в незашифровонном виде, а также включение идентификаторов в запись журналов регистрации событий, в сообщения об ошибках ].
Зависимости:	отсутствуют.
FIA_SOS.1 Верификация секретов
FIA_SOS.1.1	ФБО должны предоставить механизм для верификации того, что секреты отвечают [назначение: определенная метрика качества].
Зависимости:	отсутствуют.

Замечание по применению:

Под метрикой качества в том числе следует понимать:

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

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

FIA_SOS.2 Генерация секретов ФБО
FIA_SOS.2.1	ФБО должны предоставить механизм генерации секретов, отвечающих [выбор: нет генерации секретов [назначение: определенная метрика качества]
FIA_SOS.2.2	ФБО должны ограничивать использование при генерации паролей единого первоначального пароля или формирование таких паролей по единому алгоритму, смену пароля пользователем без предварительной аутентификации, а также содержать механизм принудительной смены первоначального пароля при первом входе пользователя в OO.
FIA_UAU.2 Аутентификация до любых действий пользователя
FIA_UAU.2.1	ФБО должны [выбор: не требовать; требовать ], чтобы каждый пользователь был успешно аутентифицирован до разрешения любого действия, выполняемого при посредничестве ФБО от имени этого пользователя.
Зависимости:	FIA_UID.1 Выбор момента идентификации.
FIA_UAU.4 Механизмы одноразовой аутентификации
FIA_UAU.4.1	ФБО должны предотвращать повторное применение аутентификационных данных, связанных с [назначение: идентифицированный механизм (механизмы) аутентификации ].
Зависимости:	отсутствуют.
FIAUAU.5 Сочетание механизмов аутентификации
FIA_UAU.5.1	ФБО должны предоставлять [назначение: список сочетаемых механизмов аутентификации] для поддержки аутентификации пользователя.
FIA_UAU.5.2	ФБО должны аутентифицировать представленный идентификатор пользователя согласно [назначение: правила, описывающие, как сочетание механизмов аутентификации обеспечивает аутентификацию].
Зависимости:	отсутствуют.

Замечания по применению:

1. Компонент предназначен для задания требований к функциональным возможностям ОО по поддержке многофакторной (двухфакторной) аутентификации.

2. В FIA_UAU.5.1 разработчик ЗБ указывает механизмы аутентификации, поддерживаемые ОО при многофакторной (двухфакторной) аутентификации.

3. В FIA_UAU.5.2 разработчик ЗБ указывает поддерживаемые правила сочетания механизмов аутентификации при многофакторной (двухфакторной) аутентификации.

FIA_UAU.6 Повторная аутентификация
FIA_UAU.6.1	ФБО должны повторно аутентифицировать пользователя при [назначение: список условий, при которых требуется повторная аутентификация] во время выполнения аутентификации.
FIA_UAU.7 Аутентификация с защищенной обратной связью
FIA_UAU.7.1	ФБО должны предоставлять пользователю только [назначение: список допустимой информации обратной связи] во время выполнения аутентификации.
Зависимости:	FIA_UAU.2 Аутентификация до любых действий пользователя.

Замечания по применению:

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

FIA_UID.1 Выбор момента идентификации
FIA_UID.1.1	ФБО должны допускать [назначение: список действий, выполняемых при посредничестве ФБО] от имени пользователя прежде, чем он идентифицирован.
FIA_UID.1.2	ФБО должны требовать, чтобы каждый пользователь был успешно идентифицирован до разрешения любого другого действия, выполняемого при посредничестве ФБО от имени этого пользователя.
Зависимости:	отсутствуют.

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

FMT_CFG_EXT.1 Конфигурация безопасности по умолчанию
FMT_CFG_EXT.1.1	ФБО должны при установке новых учетных данных, когда конфигурируются с учетными данными по умолчанию или без учетных данных, предоставить [назначение: уполномоченные пользователи] только ограниченную функциональность.
FMT_CFG_EXT.1.2	ФБО должны запрещать создание технологических учетных записей со стандартными паролями и иными механизмами аутентификации, использующими стандартный секрет для аутентификации, задаваемыми автоматически при установке программного обеспечения.
Зависимости:	FMT_SMF.1 Спецификация функций управления.
FMT_MEC_EXT.1 Поддерживаемый механизм конфигурации
FMT_MEC_EXT.1.1	ФБО должны защищать хранилища параметров конфигурации (настроек) ОО от несанкционированного доступа.
FMT_MEC_EXT.1.2	ФБО должны обеспечить возможность экспорта параметров конфигурации ОО в формат, пригодный для анализа пользователем.
FMT_MEC_EXT.1.3	ФБО должны использовать для хранения и установки параметров конфигурации ОО механизмы, предусмотренные платформой.
Зависимости:	FMT_SMF.1 Спецификация функций управления.
FMT_MSA.1 Управление атрибутами безопасности
FMT_MSA.1.1	ФБО должны осуществлять [назначение: ПФБ управления доступом, ПФБ управления информационными потоками], предоставляющую возможность [выбор: изменять значения по умолчанию; запрашивать; модифицировать; удалять; [назначение: другие операции] ] атрибуты безопасности [назначение: список атрибутов безопасности] только [назначение: уполномоченные идентифицированные роли].
Зависимости:	[FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками]. FMT_SMR.1 Роли безопасности. FMT_SMF.1 Спецификация функций управления.
FMT_MSA.3 Инициализация статических атрибутов
FMT_MSA.3.1	ФБО должны осуществлять [назначение: ПФБ управления доступом, ПФБ управления информационными потоками], предусматривающую [выбор: ограничительные; разрешающие; другие свойства] ] значения по умолчанию для атрибутов безопасности, которые используются для осуществления ПФБ.
FMT_MSA.3.2	ФБО должны позволять [назначение: уполномоченные идентифицированные роли] определять альтернативные начальные значения для отмены значений по умолчанию при создании объекта или информации.
Зависимости:	FMT_MSA.1 Управление атрибутами безопасности FMT_SMR.1 Роли безопасности
FMT_MTD.1 Управление данными ФБО
FMT_MTD.1.1	ФБО должны предоставлять возможность [выбор: изменение значений по умолчанию; запрос; модификация; удаление; очистка; формирование отчетов; [назначение: другие операции] ] следующих данных [назначение: данные о пользователях и их привилегиях, список других данных ФБО] только [ назначение: уполномоченные идентифицированные роли].
Зависимости:	FMT_SMR.1 Роли безопасности FMT_SMF.1 Спецификация функций управления
FMT_SMF.1 Спецификация функций управления
FMT_SMF.1.1	ФБО должны быть способны к выполнению следующих функций управления: [назначение: список функций управления, предоставляемых ФБО].
Зависимости:	отсутствуют.
FMT_SMR.1 Роли безопасности
FMT_SMR.1.1	ФБО должны поддерживать следующие роли [назначение: уполномоченные идентифицированные роли].
FMT_SMR.1.2	ФБО должны быть способны ассоциировать пользователей с ролями.
Зависимости:	отсутствуют.

7.1.5. Приватность (FPR)

FPR_ANO_EXT.1	Согласие пользователей на обработку персональных данных (идентификационной информации)
FPR_ANO_EXT.1.1	ФБО должны: [выбор: не обрабатывать персональную идентификационную информацию; запрашивать согласие пользователя на обработку его персональной идентификационной информации ], защита которой требуется в соответствии с законодательством.
Зависимости:	отсутствуют.

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

FPT_AEX_EXT.1	Противодействие использованию уязвимостей безопасности
FPT_AEX_EXT.1.1	ФБО не должны требовать отображения памяти с явными адресами, за исключением [назначение: список явных исключений].
FPT_AEX_EXT.1.2	ФБО должны [выбор: не выделять никакую область памяти с разрешениями писать и выполнять; выделять области памяти с разрешениями писать и выполнять только для [назначение: список функций, выполняющих компиляцию just-in-time] ].
FPT_AEX_EXT.1.3	ФБО должны [выбор: запрещать запись пользовательской информации в системные директории; разрешать запись пользовательской информации [назначение: список системных директорий] ].
FPT_AEX_EXT.1.4	В ФБО не должны использоваться элементы управления в графическом интерфейсе пользователя ППО, предназначенные для выполнения операций, права на выполнение которых у пользователя отсутствуют. Проверка прав на выполнение любых операций пользователя должна осуществляться таким образом, чтобы пользователь не мог повлиять на результаты такой проверки.
FPT_AEX_EXT.1.5	ФБО должны быть совместимы со средствами защиты, предоставляемыми поставщиком/разработчиком платформы.
FPT_AEX_EXT.1.6	ФБО не должны записывать модифицируемые пользователем файлы в директории, которые содержат исполняемые файлы, [выбор: если делать так явно не предписано разработчиком; если модифицирование проходит не пользователем ].
FPT_AEX_EXT.1.7	ФБО должны позволять смену пользователем пароля или иного используемого параметра аутентификации только после предварительной аутентификации.
FPT_AEX_EXT.1.8	ФБО должны обеспечивать предварительную инициализацию переменных и структур данных при выделении оперативной памяти.
FPT_AEX_EXT.1.9	ФБО должны исключать возможность просмотра содержимого каталогов веб-сайта в случаях, когда такой просмотр не является необходимым. Если такой просмотр и изменение необходимы, ФБО должны исключать возможность просмотра и изменения произвольного каталога веб-сайта и возможность изменения каталога вебсайта, в котором может быть расположен исполняемый код.
FPT_AEX_EXT.1.10	ФБО [выбор: не должны использовать при обработке данных в формате XML внешние сущности (External Entity), внешние параметры сущностей (External Parameter Entity) и внешние описания типа документа (External Doctype); контролировать невозможность включения пользователем таких внешних сущностей, параметров и описаний типа документа, которые могут вызвать атаку типа XXE;
FPT_AEX_EXT.1.11	ОО не должен требовать для своего выполнения прав администратора операционной системы, за исключением случаев, когда такие права технически необходимы для корректного функционирования ОО.
FPT_AEX_EXT.1.12	ФБО должны предусматривать меры защиты от обратной разработки и меры по противодействию отладке ППО.
FPT_AEX_EXT.1.13	ФБО должны выполнять все значимые проверки первичных электронных документов таким образом, чтобы пользователь ППО не мог повлиять на результат проверки (например, проводить проверки реквизитов отправителя на стороне банка).
FPT_AEX_EXT.1.14	ФБО не должна использовать полученную от пользователя информацию для определения типа сущности ФБО, которая будет создана на основе полученной информации, без дополнительной проверки на допустимость создания такой сущности (противодействие атакам небезопасной десериализации).
FPT_AEX_EXT.1.15	В случае использования многопоточности в ФБО ФБО должна корректно обрабатывать конкурентный доступ к информации для предотвращения модификации информации в обход проверок доступа (противодействие уязвимостям типа "состояние гонки").
Зависимости:	отсутствуют.
FPT_API_EXT.1	Использование поддерживаемых сервисов и прикладных программных интерфейсов
FPT_API_EXT.1.1	ФБО должны использовать в программном продукте только задокументированные производителем сервисы и прикладные программные интерфейсы платформы. Выбор: [назначение: использовать в программном продукте задокументированные производителем сервисы.] [назначение: использовать доверенные самописные(сторонние) библиотеки функций противодействия использованию уязвимостей.]
FPT_API_EXT.1.2	ФБО должны использовать механизмы, предоставляемые архитектурой процессора, операционной системой и средствами компиляции кода (например, защиты от переполнения буфера, защиты от нарушения обработки исключений, защиты от исполнения кода в сегментах стека и данных, случайного размещения сегментов в адресном пространстве).
FPT_API_EXT.1.3	ФБО не должны использовать функции стандартных библиотек, уязвимых к атакам переполнения буфера, при наличии аналогичных функций со встроенной защитой.
Зависимости:	отсутствуют.
FPT_LIB_EXT.1	Использование сторонних библиотек
FPT_LIB_EXT.1.1	ФБО должны использовать только [назначение: список разрешенных сторонних библиотек].
Зависимости:	отсутствуют.
FPT_STM.1	Надежные метки времени
FPT_STM.1.1	ФБО должны быть способны [выбор: предоставлять; не предоставлять ] надежные метки времени
Зависимости:	отсутствуют.
FPT_TDC.1 Базовая согласованность данных ФБО между ФБО
FPT_TDC.1.1	ФБО должны обеспечить способность согласованно интерпретировать [назначение: список типов данных ФБО], совместно используемые ФБО и другим доверенным продуктом ИТ.
FPT_TDC.1.2	ФБО должны использовать [назначение: список правил интерпретации, применяемых ФБО] при интерпретации данных ФБО, полученных от другого доверенного продукта ИТ.
Зависимости:	отсутствуют.
FPT_TST.1 Тестирование ФБО
FPT_TST.1.1	ФБО должны выполнять пакет программ самотестирования [выбор: при запуске; периодически в процессе нормального функционирования; по запросу уполномоченного пользователя; при условиях [назначение: условия, при которых следует предусмотреть самотестирование] ] для демонстрации правильного выполнения [выбор: [назначение: части ФБО], ФБО
FPT_TST.1.2	ФБО должны предоставить уполномоченным пользователям возможность верифицировать целостность, корректность параметров конфигурации [выбор: [назначение: данных частей ФБО]; данных ФБО
FPT_TST.1.3	ФБО должны предоставить уполномоченным пользователям возможность верифицировать целостность хранимого выполняемого кода ФБО.
FPT_TST.1.4	ФБО при выявлении нарушения целостности или некорректности параметров конфигурации должны: [выбор: - перевести ОО в режим аварийного функционирования; - предоставить уполномоченным пользователям возможность перевести ОО в режим аварийного функционирования], отключить [назначение: список функций безопасности ОО], сгенерировать диагностическую информацию.
Зависимости:	отсутствуют.
FPT_TUD_EXT.1 Целостность при установке и обновлении
FPT_TUD_EXT.1.1	ФБО должны [выбор: предоставлять возможность; эффективно использовать платформу ], чтобы проверить обновление и установку патчей для ОО.
FPT_TUD_EXT.1.2	Программное обеспечение ОО должно распространяться с использованием формата, поддерживаемого платформой диспетчера пакетов. [выбор: использовать средства по установке/удалению/обновлению программного обеспечения собственного производства; использовать средства по установке/удалению/обновлению программного обеспечения стороннего производства.]
FPT_TUD_EXT.1.3	Программное обеспечение ОО должно быть упаковано таким образом, чтобы его удаление приводило к удалению всех его следов, за исключением параметров конфигурации, выходных файлов и контрольных/ регистрационных событий. [выбор: использовать средства по установке/удалению/обновлению программного обеспечения собственного производства; использовать средства по установке/удалению/обновлению программного обеспечения стороннего производства.]
FPT_TUD_EXT.1.4	Программное обеспечение ОО не должно загружать, изменять, заменять или обновлять [выбор: при отсутствии автообновления ] его собственный двоичный код.
FPT_TUD_EXT.1.5	Программное обеспечение ОО должно [выбор: предоставлять возможность; эффективно использовать платформу ], чтобы выяснить текущую версию прикладного программного обеспечения.
Зависимости:	отсутствуют.

7.1.7. Доступ к ОО (FTA)

FTA_MCS.1 Базовое ограничение на параллельные сеансы
FTA_MCS.1.1	ФБО должны ограничить максимальное число параллельных сеансов, предоставляемых одному и тому же пользователю.
FTA_MCS.1.2	ФБО должны задать по умолчанию ограничение [назначение: задаваемое по умолчанию число] сеансов пользователя.
Зависимости:	FIA_UID.1 Выбор момента идентификации.

7.1.8. Доверенный маршрут/канал (FTP)

FTP_DIT_EXT.1 Защита данных при передаче
FTP_DIT_EXT.1.1	ФБО должны [выбор: не передавать любые данные; не передавать любую защищаемую информацию; шифровать всю передаваемую защищаемую информацию; реализовать функциональность для шифрования защищаемой информации ] между ОО и другими доверенными продуктами ИТ. Зависимости: отсутствуют.
FTP_ITC.1 Доверенный канал передачи между ФБО
FTP_ITC.1.1	ФБО должны предоставлять канал связи между собой и другим доверенным продуктом ИТ, который логически отличим от других каналов связи и обеспечивает уверенную идентификацию его конечных сторон, а также защиту данных канала от модификации или раскрытия.
FTP_ITC.1.2	ФБО должны позволить [выбор: ФБО, другой доверенный продукт ИТ ] инициировать связь через доверенный канал.
FTP_ITC.1.3	ФБО должны инициировать связь через доверенный канал для выполнения [назначение: список функций, для которых требуется доверенный канал].
Зависимости:	отсутствуют.

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

Требования доверия к безопасности ОО взяты из национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности" и образуют ОУД4, усиленный компонентами ADV_IMP.2 "Полное отображение представления реализации ФБО", ALC_FLR.2 "Процедуры сообщений о недостатках", AVA_VAN.5 "Усиленный методический анализ", расширенный компонентами ADV_IMP_EXT.3 "Реализация ОО", ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения", ALC_LCD_EXT.3 "Определенные разработчиком сроки поддержки", AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность" и AVA_CCA_EXT.1 "Анализ скрытых каналов" (см. таблицу 7.3).

Таблица 7.3 - Требования доверия к безопасности ОО

Классы доверия	Идентификаторы компонентов доверия	Названия компонентов доверия
Разработка	ADV_ARC.1	Описание архитектуры безопасности
	ADV_FSP.4	Полная функциональная спецификация
	ADV_IMP.2*	Полное отображение представления реализации ФБО
	ADV_IMP_EXT.3*	Реализация ОО
	ADV_TDS.3	Базовый модульный проект
Руководства	AGD_OPE.1	Руководство пользователя по эксплуатации
	AGD_PRE.1	Подготовительные процедуры
Поддержка жизненного цикла	ALC_CMC.4**	Поддержка генерации, процедуры приемки и автоматизация
	ALC_CMS.4	Охват УК отслеживания проблем
	ALC_DEL.1	Процедуры поставки
	ALC_DVS.1	Идентификация мер безопасности
	ALC_FLR.2	Процедуры сообщений о недостатках
	ALC_FPU_EXT.1	Процедуры обновления программного обеспечения
	ALC_LCD.1	Определенная заявителем модель жизненного цикла
	ALC_LCD_EXT.3	Определенные разработчиком сроки поддержки
	ALC_TAT.1	Полностью определенные инструментальные средства разработки
Оценка задания по безопасности	ASE_CCL.1	Утверждения о соответствии
	ASE_ECD.1	Определение расширенных компонентов
	ASE_INT.1	Введение ЗБ
	ASE_OBJ.2	Цели безопасности
	ASE_REQ.2	Производные требования безопасности
	ASE_SPD.1	Определение проблемы безопасности
	ASE_TSS.1	Краткая спецификация ОО
Тестирование	ATE_COV.2	Анализ покрытия
	ATE_DPT.2	Тестирование: модули обеспечения безопасности
	ATE_FUN.1	Функциональное тестирование
	ATE_IND.2	Выборочное независимое тестирование
Оценка уязвимостей	AVA_VAN.5	Усиленный методический анализ
	AVA_CCA_EXT.1	Анализ скрытых каналов
Обновление ОО	AMA_SIA_EXT.3	Анализ влияния обновлений на безопасность ОО
Примечания: * - Отмечены компоненты, конкретизированные в настоящем ПЗ для обеспечения унификации с действующими ПЗ ФСТЭК России и преемственности требований по контролю отсутствия недекларированных возможностей руководящего документа "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации: Классификация по уровню контроля отсутствия недекларированных возможностей" (Гостехкомиссия России, 1999). ** - Требования доверия настоящего ПЗ основаны на ОУД4, усиленном, с учетом предыдущего примечания, компонентом ADV_IMP.2, для которого по зависимости требуется компонент ALC_CMC.5. Однако для исключения чрезмерного завышения требований в настоящем ПЗ сохранен компонент ALC_CMC.4, который входит в состав ОУД4.

7.2.1. Оценка задания по безопасности (ASE)

ASE_INT.1  Введение Задания по безопасности
Зависимости:	отсутствуют.
Элементы действий разработчика
ASE_INT.1.1D	Разработчик ЗБ должен представить "Введение ЗБ".
Элементы содержания и представления документированных материалов
ASE_INT.1.1C	"Введение ЗБ" должно содержать "Ссылку ЗБ", "Ссылку ОО", "Аннотацию ОО" и "Описание ОО".
ASE_INT.1.2C	"Ссылка ЗБ" должна однозначно идентифицировать ЗБ.
ASE_INT.1.3C	"Ссылка ОО" должна однозначно идентифицировать ОО.
ASE_INT.1.4C	В "Аннотации ОО" должна быть представлена краткая информация об использовании и основных функциональных возможностях безопасности ОО.
ASE_INT.1.5C	В "Аннотации ОО" должен быть идентифицирован тип ОО.
ASE_INT.1.6C	В "Аннотации ОО" должны быть идентифицированы любые не входящие в ОО аппаратные, программные, а также программно-аппаратные средства, требуемые ОО.
ASE_INT.1.7C	"Описание ОО" должно включать описание физических границ ОО.
ASE_INT.1.8C	"Описание ОО" должно включать описание логических границ ОО.
Элементы действий оценщика
ASE_INT.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ASE_INT.1.1C - ASE_INT.1.8C.
ASE_INT.1.2E	Оценщик должен подтвердить, что "Справка ОО", "Аннотация ОО" и "Описание ОО" не противоречат друг другу.

Работы оценки

Оценщик должен выполнять указанные действия в соответствии с пунктом 9.3.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ASE_CCL.1 Утверждения о соответствии
Зависимости:	ASE_INT.1 Введение ЗБ; ASE_ECD.1 Определение расширенных компонентов; ASE_REQ.1 Установленные требования безопасности.
Элементы действий разработчика
ASE_CCL.1.1D	Разработчик должен представить "Утверждения о соответствии".
ASE_CCL.1.2D	Разработчик должен представить "Обоснование утверждений о соответствии".
Элементы содержания и представления документированных материалов
ASE_CCL.1.1C	В "Утверждения о соответствии" должно быть включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ГОСТ Р ИСО/МЭК 15408 утверждается соответствие ЗБ и ОО.
ASE_CCL.1.2C	В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ЗБ ГОСТ Р ИСО/МЭК 15408-2; ЗБ описывается либо как соответствующее требованиям ГОСТ Р ИСО/МЭК 15408-2, либо как содержащее расширенные по отношению к ГОСТ Р ИСО/МЭК 15408-2 требования.
ASE_CCL.1.3C	В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ГОСТ Р ИСО/МЭК 15408-3; ЗБ описывается либо как соответствующее требованиям ГОСТ Р ИСО/МЭК 15408-3, либо как содержащее расширенные по отношению к ГОСТ Р ИСО/МЭК 15408-3 требования.
ASE_CCL.1.4C	"Утверждение о соответствии ИСО/МЭК 15408" должно согласовываться с "Определением расширенных компонентов".
ASE_CCL.1.5C	В "Утверждении о соответствии" должны быть идентифицированы все ПЗ и пакеты требований безопасности, о соответствии которым утверждается в ЗБ.
ASE_CCL.1.6C	В "Утверждении о соответствии ЗБ пакету требований" должно приводиться описание любого соответствия ЗБ некоторому пакету требований; ЗБ описывается либо как соответствующее пакету требований, либо как содержащее расширенные по отношению к пакету требования.
ASE_CCL.1.7C	В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что тип ОО согласуется с типом ОО в тех ПЗ, о соответствии которым утверждается в ЗБ.
ASE_CCL.1.8C	В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Определения проблемы безопасности" согласуется с изложением "Определения проблемы безопасности" в тех ПЗ, о соответствии которым утверждается в ЗБ.
ASE_CCL.1.9C	В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Целей безопасности" согласуется с изложением "Целей безопасности" в тех ПЗ, о соответствии которым утверждается в ЗБ.
ASE_CCL.1.10C	В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Требований безопасности" согласуется с изложением "Требований безопасности" в тех ПЗ, о соответствии которым утверждается в ЗБ.
Элементы действий оценщика
ASE_CCL.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ASE_CCL.1.1C - ASE_CCL.1.10C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 9.4.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ASE_SPD.1 Определение проблемы безопасности
Зависимости:	отсутствуют.
Элементы действий разработчика
ASE_SPD.1.1D	Разработчик должен представить "Определение проблемы безопасности".
Элементы содержания и представления документированных материалов
ASE_SPD.1.1C	"Определение проблемы безопасности" должно включать в себя описание угроз.
ASE_SPD.1.2C	Описание всех угроз должно проводиться в терминах источника угрозы, активов и негативного действия.
ASE_SPD.1.4C	"Определение проблемы безопасности" должно содержать описание предположений относительно среды функционирования ОО.
Элементы действий оценщика
ASE_SPD.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ASE_SPD.1.1C - ASE_SPD.1.4C.

Работы оценки

Оценщик должен выполнять указанные действия в соответствии с пунктом 9.5.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ASE_OBJ.2  Цели безопасности
Зависимости:	ASE_SPD.1 Определение проблемы безопасности.
Элементы действий разработчика
ASE_OBJ.2.1D	Разработчик должен предоставить "Определение целей безопасности".
ASE_OBJ.2.2D	Разработчик должен предоставить "Обоснование целей безопасности".
Элементы содержания и представления документированных материалов
ASE_OBJ.2.1C	Изложение "Целей безопасности" должно включать в себя описание целей безопасности для ОО и для среды функционирования ОО.
ASE_OBJ.2.2C	В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, и к политикам безопасности, на осуществление которых направлена эта цель безопасности.
ASE_OBJ.2.3C	В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, к политикам безопасности, на осуществление которых направлена эта цель безопасности, а также к предположениям, поддерживаемым данной целью безопасности.
ASE_OBJ.2.4C	В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на противостояние всем идентифицированным угрозам.
ASE_OBJ.2.5C	В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на осуществление всех политик безопасности.
ASE_OBJ.2.6C	В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности для среды функционирования поддерживают все предположения.
Элементы действий оценщика
ASE_OBJ.2.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ASE_OBJ.2.1C - ASE_OBJ.2.6C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 9.6.2 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ASE_ECD.1 Определение расширенных компонентов
Зависимости:	отсутствуют.
Элементы действий разработчика
ASE_ECD.1.1D	Разработчик должен представить изложение "Требований безопасности".
ASE_ECD.1.2D	Разработчик должен представить "Определение расширенных компонентов".
Элементы содержания и представления документированных материалов
ASE_ECD.1.1C	В изложении "Требований безопасности" должны быть идентифицированы все расширенные требования безопасности.
ASE_ECD.1.2C	В "Определении расширенных компонентов" должен определяться расширенный компонент для каждого расширенного требования безопасности.
ASE_ECD.1.3C	В "Определении расширенных компонентов" должно указываться, как каждый расширенный компонент связан с существующими компонентами, семействами и классами ГОСТ Р ИСО/МЭК 15408.
ASE_ECD.1.4C	В "Определении расширенных компонентов" должны использоваться в качестве модели представления компоненты, семейства, классы и методология ГОСТ Р ИСО/МЭК 15408.
ASE_ECD.1.5C	Расширенные компоненты должны состоять из измеримых объективных элементов, чтобы была возможность продемонстрировать соответствие или несоответствие этим элементам.
Элементы действий оценщика
ASE_ECD.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ASE_ECD.1.1C - ASE_ECD.1.5C.
ASE_ECD.1.2E	Оценщик должен подтвердить, что ни один из расширенных компонентов не может быть четко выражен с использованием существующих компонентов.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 9.7.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ASE_REQ.2  Производные требования безопасности
Зависимости:	ASE_OBJ.2 Цели безопасности; ASE_ECD.1 Определение расширенных компонентов.
Элементы действий разработчика
ASE_REQ.2.1D	Разработчик должен представить изложение "Требований безопасности".
ASE_REQ.2.2D	Разработчик должен представить обоснование "Требований безопасности".
Элементы содержания и представления документированных материалов
ASE_REQ.2.1C	Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.
ASE_REQ.2.2C	Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, использующиеся в ФТБ и ТБД, должны быть определены.
ASE_REQ.2.3C	В изложении "Требований безопасности" должны быть идентифицированы все выполненные над требованиями безопасности операции.
ASE_REQ.2.4C	Все операции должны быть выполнены правильно.
ASE_REQ.2.5C	Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения зависимости.
ASE_REQ.2.6C	В "Обосновании требований безопасности" должно быть представлено прослеживание каждого ФТБ к целям безопасности для ОО.
ASE_REQ.2.7C	В "Обосновании требований безопасности" должно быть продемонстрировано, что ФТБ обеспечивают выполнение всех целей безопасности для ОО.
ASE_REQ.2.8C	В "Обосновании требований безопасности" должно приводиться пояснение того, почему выбраны определенные ТДБ.
ASE_REQ.2.9C	Изложение "Требований безопасности" должно быть внутренне непротиворечивым.
Элементы действий оценщика
ASE_REQ.2.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ASE_REQ.2.1C - ASE_REQ.2.9C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 9.8.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ASE_TSS.1  Краткая спецификация ОО
Зависимости:	ASE_INT.1 Введение ЗБ.
ASE_REQ.1	Установленные требования безопасности
ADV_FSP.1	Базовая функциональная спецификация
Элементы действий разработчика
ASE_TSS.1.1D	Разработчик должен представить "Краткую спецификацию ОО".
Элементы содержания и представления документированных материалов
ASE_TSS.1.1C	"Краткая спецификация ОО" должна описывать, каким образом ОО выполняет каждое ФТБ.
Элементы действий оценщика
ASE_TSS.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ASE_TSS.1.1C.
ASE_TSS.1.2E	Оценщик должен подтвердить, что "Краткая спецификация ОО" не противоречит "Аннотации ОО" и "Описанию ОО".

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 9.9.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий". Дополнительно должно быть проанализировано покрытие ТДБ мерами доверия.

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

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

Оформление и содержание свидетельств должно соответствовать требованиям национальных стандартов Российской Федерации.

ADV_ARC.1 Описание архитектуры безопасности

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

Зависимости:	ADV_FSP.1 Базовая функциональная спецификация; ADV_TDS.1 Базовый проект.
Элементы действий разработчика
ADV_ARC.1.1D	Разработчик должен спроектировать ОО и обеспечить реализацию проекта таким образом, чтобы свойства безопасности ФБО невозможно было обойти.
ADV_ARC.1.2D	Разработчик должен спроектировать ФБО и обеспечить их реализацию таким образом, чтобы ФБО обеспечивали собственную защиту от вмешательства недоверенных сущностей.
ADV_ARC.1.3D	Разработчик должен предоставить "Описание архитектуры безопасности" ФБО.
Элементы содержания и представления документированных материалов
ADV_ARC.1.1C	Уровень детализации "Описания архитектуры безопасности" должен соответствовать представленному в проектной документации по ОО описанию абстракций (элементов представления ОО), осуществляющих выполнение ФТБ.
ADV_ARC.1.2C	В "Описание архитектуры безопасности" должно быть включено описание доменов безопасности, обеспеченных согласованностью ФБО с ФТБ.
ADV_ARC.1.3C	"Описание архитектуры безопасности" должно предоставлять информацию о том, насколько процесс инициализации ФБО является защищенным.
ADV_ARC.1.4C	В "Описании архитектуры безопасности" должно быть продемонстрировано, что ФБО обеспечивают собственную защиту от вмешательства.
ADV_ARC.1.5C	В "Описании архитектуры безопасности" должно быть продемонстрировано, что ФБО не допускают возможности обхода функциональных возможностей, осуществляющих выполнение ФТБ.
Элементы действий оценщика
ADV_ARC.1.1E	Оценщик должен подтвердить, что информация, представленная разработчиком в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированных материалов, изложенным в ADV_ARC.1.1C - ADV_ARC.1.5C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 10.3.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

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

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

ADV_FSP.4 Полная функциональная спецификация

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

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

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

интерфейсы сервисов, от которых никак не зависят функциональные возможности, осуществляющие выполнение ФТБ, относятся к не влияющим на выполнение ФТБ.

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

Зависимости:	ADV_TDS.1 Базовый проект.
Элементы действий разработчика
ADV_FSP.4.1D	Разработчик должен представить функциональную спецификацию.
ADV_FSP.4.2D	Разработчик должен представить прослеживание функциональной спецификации к функциональным требованиям безопасности.
Элементы содержания и представления документированных материалов
ADV_FSP.4.1C	В функциональной спецификации должны быть полностью представлены ФБО.
ADV_FSP.4.2C	В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.
	Замечания по применению: Назначение ИФБО - это общее утверждение, кратко описывающее функциональные возможности, предоставляемые интерфейсом. Если действие, доступное через интерфейс, играет роль в осуществлении какой-либо политики безопасности ОО (то есть, если одно из действий интерфейса может быть прослежено к одному из ФТБ, предъявляемых к ФБО), то этот интерфейс - осуществляющий ФТБ. Это относится не только к политикам управления доступом, но также и к любым функциям, определенным одним из ФТБ, содержащихся в ЗБ. Следует отметить, что у интерфейса могут быть различные действия и результаты его вызова, некоторые из которых могут быть осуществляющими ФТБ, а некоторые - нет. Интерфейсы (или действия, доступные через связанный с ними интерфейс), от которых зависят функции, осуществляющие выполнение ФТБ, от которых требуется только правильное функционирование для поддержания выполнения политик безопасности ОО, являются интерфейсами, поддерживающими выполнение ФТБ. Интерфейсы, от которых никак не зависят функции, осуществляющие выполнение ФТБ, относятся к не влияющим на выполнение ФТБ. Следует отметить, что для того, чтобы интерфейс был отнесен к поддерживающим или не влияющим на выполнение ФТБ, он не должен включать в себя действия и результаты, осуществляющие выполнение ФТБ. Напротив, осуществляющий выполнение ФТБ интерфейс может включать поддерживающие выполнение ФТБ действия.
ADV_FSP.4.3C	В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.
ADV_FSP.4.4C	В функциональной спецификации должны быть описаны все действия, связанные с каждым ИФБО.
ADV_FSP.4.5C	Функциональная спецификация должна содержать описание сообщений обо всех непосредственных ошибках, которые могут возникнуть при вызове каждого ИФБО.
ADV_FSP.4.6C	В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.
Элементы действий оценщика
ADV_FSP.4.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ADV_FSP.4.1С - ADV_FSP.4.6С.
ADV_FSP.4.2E	Оценщик должен сделать независимое заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 10.4.4 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ADV_IMP.2 Полное отображение представления реализации ФБО
Зависимости:	ADV_TDS.3 Базовый модульный проект; ALC_TAT.1 Полностью определенные инструментальные средства разработки; ALC_CMC.4 Поддержка генерации, процедуры приемки и автоматизация.
Элементы действий разработчика
ADV_IMP.2.1D	Разработчик должен обеспечить доступ к представлению реализации для всех ФБО. Замечания по применению: Доступ к представлению реализации должен быть предоставлен на уровне исходных текстов всего программного обеспечения, входящего в состав ОО. Доступ ко всему представлению реализации должен быть предоставлен для того, чтобы обеспечить уверенность в том, что действия по анализу не будут сокращены вследствие недостаточности информации. Разработчик должен сделать доступным представление реализации ОО в форме, которая может быть проанализирована оценщиком.
ADV_IMP.2.2D	Разработчик должен обеспечить прослеживание всего представления реализации к описанию проекта ОО.
ADV_IMP.2.3D	Разработчик должен провести контроль представления реализации ОО.
	Замечания по применению: Контроль представления реализации - мероприятия, осуществляемые в отношении определенных частей исходного текста (исходного кода) ПО, созданного одним или несколькими разработчиками, другим (не создававшим эту часть кода) разработчиком или назначенным в установленном порядке иным имеющим требуемую подготовку специалистом и состоящие в детальной проверке (изучении, анализе, исследовании) соответствующих исходных кодов с целью выявления неизвестных уязвимостей, в том числе связанных с ошибками программирования, нарушений установленных требований, а также иных существенных дефектов. Контроль исходного кода может осуществляться лицом, проверяющим код, как вручную, в том числе с использованием приемов эффективного чтения программного кода, так и с применением методов и средств автоматизированного анализа исходного кода, в том числе обеспечивающих статический анализ кода. Контроль (проверка) исходного кода вручную обеспечивается просмотром, изучением и оценкой кода лицом, отличным от его разработчика. Является альтернативным методом оценки. Оценка кода может включать в себя: а) оценку соответствия кода требованиям, предъявляемым к структурированию и оформлению кода, именованию объектов, разделению на модули, использованию специальных средств обеспечения качества кода, предусмотренных используемыми языками программирования и средствами разработки; б) оценку полноты и качества документирования кода, включая документирование заголовков программных модулей, прототипов функций и структур данных, комментарии к выполнению существенных операций; в) оценку соответствия алгоритмов, реализованных в исходном коде, программной документации, в том числе выявление явных недекларированных возможностей (программных закладок), ошибок программного кода, попыток запутывания (обфускации) программного кода и использования иных приемов, затрудняющих проведение контроля. Примечание: недекларированные возможности - функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации. Статический анализ кода проводится с использованием автоматизированных средств (программных инструментов) и направлен на идентификацию потенциально опасных фрагментов кода, в том числе: а) вызовов функциональных объектов (функций, методов, процедур) с передачей им в качестве аргументов данных, вводимых пользователем или принимаемых из внешних источников; Примечание: функциональный объект - элемент программы, осуществляющий выполнение действий по реализации законченного фрагмента алгоритма программы. Функциональные объекты, в частности, могут быть представлены в виде функций (процедур, подпрограмм), используемых в процедурно-ориентированных языках программирования, методов, используемых в объектно-ориентированных языках программирования, отдельных фрагментов в программном коде, процессов в языках описания аппаратных средств и т.п.; б) текстов функциональных объектов преобразования форматов данных; в) вызовов системных функциональных объектов и функциональных объектов обеспечения ИБ разделяемых обеспечивающих компонентов ППО, в том числе функциональных объектов обеспечения ИБ операционной системы, функциональных объектов ввода/вывода, управления памятью и системными ресурсами; г) текстов функциональных объектов, осуществляющих проверку прав доступа и принятие решений, основанных на значениях атрибутов безопасности; д) текстов функциональных объектов, самостоятельно реализующих функциональность обеспечения ИБ, в том числе криптографические функции, аутентификацию пользователей и проверку прав доступа, генерацию данных мониторинга ИБ; е) текстов функциональных объектов, предусматривающих установление соединения с внешними компонентами с передачей им аутентификационных данных; ж) текстов функциональных объектов обработчиков ошибок и исключений. В ходе статического анализа кода необходимо проводить поиск типовых ошибок программирования (недостаточная проверка входных параметров функций, включение аутентификационных данных непосредственно в текст программ, некорректное преобразование типов, недостаточная обработка ошибок и исключений), а также определять статические пути исполнения программы. В программном коде ОО должны отсутствовать аутентификационные данные, необходимые для доступа компонентов ППО к прочим ППО организации БС Российской Федерации.
Элементы содержания и представления документированных материалов
ADV_IMP.2.1C	Представление реализации должно определить ФБО на таком уровне детализации, чтобы ФБО могли быть созданы без дополнительных проектных решений.
ADV_IMP.2.2C	Представление реализации должно быть изложено в том виде, который используется персоналом, занимающимся разработкой. Замечания по применению: Представление реализации должно быть выполненным разработчиком таким образом, чтобы потом была возможность фактической реализации этого представления. Например, разработчик может работать с файлами, содержащими исходный текст программ, который потом будет скомпилирован и станет частью ФБО. Разработчик также может использовать в представлении реализации элементы, для которых исходные тексты недоступны, или элементы, не предполагающие проведения компиляции из исходных текстов для генерации ФБО. Однако разработчик обязательно должен сделать доступным представление реализации в той форме, в какой он его использует. Это также увеличивает уверенность в том, что оцениваемое представление реализации является именно тем, которое используется при производстве ФБО (в отличие от того случая, когда оно сопровождается альтернативным форматом представления, например, документом текстового процессора). Разработчик может использовать различные формы представления реализации, которые также должны прилагаться. Основная цель - снабдить оценщика такой информацией, которая позволила бы максимизировать эффективность его усилий по анализу. Разработчик ОО может применять в представлении реализации некие программы по сокрытию или запутыванию кода, например, обфускация, шифрование и т.п. Несмотря на то, что представление со скрытыми участками кода является именно тем, которое будет в дальнейшем подвергнуто компиляции, а потому может быть даже ближе к реализации (по структуре), чем оригинальная версия, предоставление оценщику запутанного программного кода может привести к значительному увеличению времени проведения анализа представления реализации и (или) невозможности получения положительного заключения. При подобных формах представления реализации разработчиком дополнительно должны быть представлены материалы по представлению реализации до применения сокрытия участков кода, а также применяемые средства/алгоритмы сокрытия для получения оценщиком уверенности в том, что процесс сокрытия участков кода не нарушил выполнения каких-либо функциональных возможностей безопасности. Для всех файлов с исходными текстами ПО в документации должны быть приведены значения контрольных сумм файлов.
ADV_IMP.2.3C	В прослеживании между всем представлением реализации и описанием проекта ОО должно быть продемонстрировано их соответствие. Замечания по применению: Соответствие между всем представлением реализации и описанием проекта ОО должно быть продемонстрировано для всех модулей, отнесенных к осуществляющим или поддерживающим выполнение ФТБ. Для модулей ОО, определенных как "не влияющие на выполнение ФТБ", должно быть предоставлено соответствующее обоснование.
ADV_IMP.2.4C	Результаты контроля представления реализации разработчиком должны быть оформлены в виде протоколов контроля представления реализации. Замечания по применению: Результаты контроля должны быть подписаны разработчиками - непосредственными исполнителями разработки проверенного исходного кода и лицами, участвовавшими в его проверке (контролерами кода), с отражением в протоколе сведений о дате мероприятия, проверенной части исходных кодов, выявленных недостатках (при наличии), повторном контроле кодов с подтверждением устранения выявленных недостатков. Протокол необходимо оформлять в виде информации в электронной форме, созданной, переданной и надежно сохраненной в предусмотренной для данного вида информации системе электронного документооборота с реквизитами, позволяющими при аудите предъявлять ее в качестве электронного документа, подписанного простыми электронными подписями, а также при необходимости изготавливать и заверять ее копии на бумажном носителе.
Элементы действий оценщика
ADV_IMP.2.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ADV_IMP.2.1С - ADV_IMP.2.4С.
ADV_IMP.2.2E	Оценщик должен провести контроль соответствия всего представления реализации описанию проекта ОО, включая: а) контроль исходного состояния ОО; б) контроль полноты представления реализации на уровне исходных модулей программ; в) контроль отсутствия избыточности представления реализации на уровне исходных модулей программ; г) контроль полноты представления реализации на уровне функциональных объектов; д) контроль отсутствия избыточности представления реализации на уровне функциональных объектов; е) контроль связей функциональных объектов представления реализации по управлению; ж) контроль связей функциональных объектов представления реализации по информации.

Работы оценки:

1. Оценщик должен выполнить действия в соответствии с пунктом 10.5.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий" для всего представления реализации.

2. Исследование представления реализации должно выполняться с использованием методов статического и динамического анализа исходных модулей программ.

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

Статический анализ исходных текстов программ - совокупность методов контроля (не)соответствия реализованных и декларированных в документации функциональных возможностей ПО, основанных на структурном анализе и декомпозиции исходных модулей программ.

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

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

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

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

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

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

Если в результате исследования установлено, что для ФТБ отсутствует представление реализации или оно представлено только частично, то такому этапу исследования не может быть дана положительная оценка.

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

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

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

Оценщик при контроле отсутствия избыточности исходных модулей должен:

- в части исходных модулей, осуществляющих и поддерживающих выполнение ФТБ, - исследовать (основываясь на структурном анализе и декомпозиции) эти модули, чтобы сделать заключение об отсутствии в исходных модулях функциональных возможностей безопасности, не предусмотренных проектом и ФТБ;

- в части исходных модулей, заявленных как "не влияющие на выполнение ФТБ", - проанализировать эти модули с глубиной, достаточной для подтверждения их невлияния на выполнение ФТБ.

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

6. Оценщик должен выполнить контроль полноты представления реализации на уровне функциональных объектов.

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

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

7. Оценщик должен выполнить контроль отсутствия избыточности представления реализации на уровне функциональных объектов.

Оценщик должен исследовать представление реализации, чтобы сделать заключение в отношении каждого функционального объекта как обеспечивающего выполнение ФТБ, поддерживающего выполнение ФТБ или не влияющего на выполнение ФТБ.

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

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

8. Оценщик должен выполнить контроль связей функциональных объектов представления реализации по управлению.

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

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

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

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

9. Оценщик должен выполнить контроль связей функциональных объектов (модулей, процедур, функций) по информации.

Связи функциональных объектов по информации осуществляются путем использования функциональными объектами общих информационных объектов.

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

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

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

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

ADV_IMP_EXT.3 Реализация ОО
Зависимости:	ADV_IMP.2 Полное отображение представления реализации ФБО.
Элементы действий разработчика
ADV_IMP_EXT.3.1D	Разработчик должен предоставить реализацию ОО.
ADV_IMP_EXT.3.2D	Разработчик должен обеспечить прослеживание реализации ОО к представлению реализации ФБО.
Элементы содержания и представления документированных материалов
ADV_IMP_EXT.3.1C	В документации должны быть указаны состав и значения контрольных сумм элементов реализации ПО [выбор: загрузочные модули ПО; [назначение: иные типы элементов реализации ПО] ].
ADV_IMP_EXT.3.2C	В прослеживании между реализацией ОО и представлением реализации должно быть продемонстрировано соответствие между реализацией ПО [выбор: загрузочные модули ПО, [назначение: иные типы элементов реализации ПО] ] и их представлением реализации [выбор: исходные тексты ПО, [назначение: иные формы представления реализации] ].
Элементы действий оценщика
ADV_IMP_EXT.3.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ADV_IMP_EXT.3.1С и ADV_IMP_EXT.3.2C.

Работы оценки

1. Оценщик должен верифицировать представленное разработчиком прослеживание между элементами представления реализации и элементами фактической реализации ОО.

2. Оценщик должен выполнить контроль соответствия представления реализации ОО фактической реализации ОО.

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

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

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

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

ADV_TDS.3	Базовый модульный проект
Зависимости:	ADV_FSP.4 Полная полуформальная функциональная спецификация.
Элементы действий разработчика
ADV_TDS.3.1D	Разработчик должен представить проект ОО.
	Замечания по применению: Проектная документация должна предоставлять возможность проведения контроля полноты и корректности реализации функций обеспечения ИБ в реализованных проектных решениях. При разработке проекта ОО должны учитываться положения руководящего документа РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов", а также ГОСТ 34.201-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем".
ADV_TDS.3.2D	Разработчик должен обеспечить прослеживание ИФБО в функциональной спецификации к более низкому уровню декомпозиции, представленному в проекте ОО.
Элементы содержания и представления документированных материалов
ADV_TDS.3.1C	В проекте должно приводиться описание структуры ОО на уровне подсистем.
ADV_TDS.3.2C	В проекте должно приводиться описание структуры ОО на уровне модулей.
ADV_TDS.3.3C	В проекте должны быть идентифицированы все подсистемы ФБО.
ADV_TDS.3.4C	В проекте должно приводиться описание каждой из подсистем ФБО.
ADV_TDS.3.5C	В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.
ADV_TDS.3.6C	В проекте должно быть осуществлено прослеживание подсистем ФБО с модулями ФБО.
ADV_TDS.3.7C	В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.
ADV_TDS.3.8C	В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его относящихся к ФТБ интерфейсов, значений, предоставляемых этими интерфейсами в ответ на запросы, взаимодействий с другими модулями и вызываемыми интерфейсами этих модулей.
ADV_TDS.3.9C	В проекте должен быть описан каждый поддерживающий и не влияющий на выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.
ADV_TDS.3.10C	В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.
Элементы действий оценщика
ADV_TDS.3.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ADV_TDS.3.1C - ADV_TDS.3.10C.
ADV_TDS.3.2E	Оценщик должен сделать независимое заключение, что проект является точным и полным отображением всех функциональных требований безопасности.

Работы оценки

Оценщик должен выполнить действия по оценке в соответствии с пунктом 10.8.3 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

7.2.3. Руководства (AGD)

AGD_OPE.1	Руководство пользователя по эксплуатации
Зависимости:	ADV_FSP.1 Базовая функциональная спецификация.
Элементы действий разработчика
AGD_OPE.1.1D	Разработчик должен представить руководство пользователя по эксплуатации.
Элементы содержания и представления документированных материалов
AGD_OPE.1.1C	В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть представлено описание доступных пользователям функций, возможных прав и обязанностей, которыми следует управлять в защищенной среде функционирования, а также уместных предупреждений.
AGD_OPE.1.2C	В руководстве пользователя по эксплуатации в рамках каждой пользовательской роли должно быть представлено описание принципов безопасной работы с предоставленными в ОО интерфейсами.
AGD_OPE.1.3C	В руководстве пользователя по эксплуатации должно быть представлено описание доступных для каждой пользовательской роли функций и интерфейсов, особенно всех параметров безопасности под управлением пользователя, с указанием безопасных значений, если это уместно.
AGD_OPE.1.4C	В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть четкое представление каждого типа имеющих значение для безопасности событий, связанных с доступными пользователю обязательными для выполнения функциями, включая изменение характеристик безопасности сущностей, находящихся под управлением ФБО.
AGD_OPE.1.5C	В руководстве пользователя по эксплуатации должны быть идентифицированы все возможные режимы работы ОО (включая операции после сбоев и ошибок эксплуатации), их последствия и участие в обеспечении безопасного функционирования.
AGD_OPE.1.6C	В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть приведено описание всех мер безопасности, предназначенных для выполнения целей безопасности для среды функционирования согласно описанию в ЗБ, имеющих отношение к пользователю.
AGD_OPE.1.7C	Руководство пользователя по эксплуатации должно быть четким и обоснованным.
AGD_OPE.1.8C	Руководство пользователя по эксплуатации должно содержать описание состава функций безопасности в привязке к компонентам ОО.
AGD_OPE.1.9C	Руководство пользователя по эксплуатации должно содержать типовые параметры настройки ОО (стандарты конфигурации), обеспечивающие безопасное функционирование ОО в установленных средах и режимах функционирования.
AGD_OPE.1.10C	Руководство пользователя по эксплуатации должно содержать параметры настройки ОО, устанавливаемые по умолчанию, при которых пользователю будет предоставляться только ограниченная функциональность ОО. Параметры, определяющие защиту ОО от несанкционированного доступа, должны по умолчанию устанавливаться такими, которые будут обеспечивать требуемый уровень защиты от НСД.
AGD_OPE.1.11C	Руководство пользователя по эксплуатации должно содержать описание правил использования функций безопасности ОО, включая правила обновления, управления и контроля их применения, в том числе параметров их настройки.
AGD_OPE.1.12C	Руководство пользователя по эксплуатации должно содержать перечень и эталонные значения конфигурационных параметров, а также описание процедур контроля соответствия фактических значений параметров конфигурации их эталонным значениям.
AGD_OPE.1.13C	В руководстве пользователя по эксплуатации должны быть определены требования к кадровому обеспечению подсистемы ИБ.
AGD_OPE.1.14C	В руководстве пользователя по эксплуатации должны быть определены требования по назначению ролей эксплуатационного персонала и его обучению, информированию и повышению осведомленности эксплуатационного персонала и пользователей, необходимых к проведению для обеспечения развертывания и эксплуатации подсистемы ИБ.
AGD_OPE.1.15C	В руководстве пользователя по эксплуатации должно быть регламентировано использование компонентов ОО на стороне клиента: - порядок реализации мер, принимаемых для обеспечения целостности ППО и компонентов ОО, передаваемых на стороне клиента; - требования к составу, версиям, обновлению и настройкам технических защитных мер, применяемых на стороне клиента.
AGD_OPE.1.16C	В руководстве пользователя по эксплуатации должны быть определены требования к использованию функции расширенного аудита, указанию порядка переключения режима аудита, контролю переключения режима аудита.
	Замечания по применению: 1. В руководстве пользователя по эксплуатации должны быть определены требования к кадровому обеспечению подсистемы ИБ. 2. В руководстве пользователя по эксплуатации должны быть определены требования по назначению ролей эксплуатационного персонала и их обучению, информированию и повышению осведомленности эксплуатационного персонала и пользователей, необходимых к проведению для обеспечения развертывания и эксплуатации подсистемы ИБ. 3. В руководстве пользователя по эксплуатации должно быть регламентировано использование компонентов ОО на стороне клиента: - порядок реализации мер, принимаемых для обеспечения целостности ППО и компонентов ОО, передаваемых на стороне клиента; - требования к составу, версиям, обновлению и настройкам технических защитных мер, применяемых на стороне клиента.
Элементы действий оценщика
AGD_OPE1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в AGD_OPE.1.1C - AGD_OPE.1.16C.

Работы оценки

Оценщик должен выполнить действия по оценке в соответствии с пунктом 11.3.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

AGD_PRE.1 Подготовительные процедуры
Зависимости:	отсутствуют.
Элементы действий разработчика
AGD_PRE.1.1D	Разработчик должен предоставить ОО вместе с подготовительными процедурами.
Элементы содержания и представления документированных материалов
AGD_PRE1.1C	В подготовительных процедурах должны описываться все шаги, необходимые для безопасной приемки поставленного ОО в соответствии с процедурами поставки заявителя (разработчика, производителя).
AGD_PRE1.2C	В подготовительных процедурах должны описываться все необходимые шаги для безопасной установки и настройки ОО и безопасной подготовки среды функционирования в соответствии с целями безопасности для среды функционирования, описанными в ЗБ.
AGD_PRE1.3C	В подготовительных процедурах должны описываться все необходимые шаги для контроля корректности версий и целостности ОО.
Элементы действий оценщика
AGD_PRE.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в AGD_PRE1.1C и AGD_PRE1.3C.
AGD_PRE.1.2E	Оценщик должен использовать подготовительные процедуры для подтверждения того, что ОО может быть безопасно подготовлен к работе.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 11.4.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

7.2.4. Поддержка жизненного цикла (ALC)

ALC_CMC.4

Поддержка генерации, процедуры приемки и автоматизация

Управление конфигурацией - один из способов увеличения доверия к тому, что ОО соответствует ФТБ. УК устанавливает это посредством предъявления требований к организационному порядку и управлению процессами усовершенствования и модификации ОО и связанной с ним информации. Системы УК реализуются для того, чтобы удостовериться в целостности частей ОО, подвергающихся контролю со стороны этих систем, путем отслеживания любых изменений, а также обеспечения санкционированности всех изменений.

Зависимости:	ALC_CMS.1 Охват УК ОО; ALC_DVS.1 Идентификация мер безопасности;
ALC_LCD.1	Определенная разработчиком модель жизненного цикла.
Элементы действий разработчика
ALC_CMC.4.1D	Разработчик должен предоставить ОО и маркировку для ОО.
ALC_CMC.4.2D	Разработчик должен предоставить документацию УК.
ALC_CMC.4.3D	Разработчик должен использовать систему УК.
Элементы содержания и представления документированных материалов
ALC_CMC.4.1C	ОО должен быть помечен уникальной маркировкой.
ALC_CMC.4.2C	В документации УК должно содержаться описание метода, используемого для уникальной идентификации элементов конфигурации (в том числе файлов исходного кода, ресурсных файлов, файлов документации).
ALC_CMC.4.3C	В системе УК должны быть уникальным образом идентифицированы все элементы конфигурации.
ALC_CMC.4.4C	В системе УК должны быть предусмотрены такие автоматизированные меры, при применении которых в элементы конфигурации могут быть внесены только санкционированные изменения.
ALC_CMC.4.5С	Система УК должна поддерживать производство ОО автоматизированными средствами.
ALC_CMC.4.6С	Документация УК должна включать в себя план УК.
ALC_CMC.4.7C	В плане УК должно быть описание того, каким образом система УК используется для разработки ОО.
ALC_CMC.4.8C	План УК должен содержать описание процедур, используемых для приемки модифицированных или вновь созданных элементов конфигурации.
ALC_CMC.4.9C	В свидетельствах должно быть продемонстрировано, что все элементы конфигурации сопровождаются системой УК.
ALC_CMC.4.10С	В свидетельствах должно быть продемонстрировано, что система УК функционирует в соответствии с планом УК.
Элементы действий оценщика
ALC_CMC.4.1Е	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_CMC.4.1C - ALC_CMC.4.10C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 12.2.4 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ALC_CMS.4 Охват УК отслеживания проблем

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

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

Зависимости:	отсутствуют
Элементы действий разработчика
ALC_CMS.4.1D	Разработчик должен представить список элементов конфигурации для ОО.
Элементы содержания и представления документированных материалов
ALC_CMS.4.1С	Список элементов конфигурации должен включать следующее: сам ОО; свидетельства оценки, необходимые по требованиям доверия к безопасности; представление реализации; сведения о недостатках безопасности и стадии их устранения.
ALC_CMS.4.2C	Элементы конфигурации должны быть уникально идентифицированы в списке элементов конфигурации.
ALC_CMS.4.3C	Для каждого значимого для ФБО элемента конфигурации в списке элементов конфигурации должен быть указан разработчик.
Элементы действий оценщика
ALC_CMS.4.1Е	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_CMS.4.1С - ALC_CMS.4.3С.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 12.3.4 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

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

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

Зависимости:	отсутствуют.
Элементы действий разработчика
ALC_DEL.1.1D	Разработчик должен задокументировать процедуры поставки ОО или его частей потребителю.
ALC_DEL.1.2D	Разработчик должен использовать процедуры поставки.
Элементы содержания и представления документированных материалов
ALC_DEL.1.1C	Документация поставки должна содержать описание всех процедур, необходимых для поддержания безопасности при распространении версий ОО потребителю.
	Замечания по применению: В процедурах поставки должны затрагиваться следующие вопросы: а) обеспечение точного соответствия между ОО, полученным потребителем, и прошедшим оценку ОО; б) избежание/обнаружение какой-либо подделки актуальной версии ОО; в) предотвращение поставки фальсифицированной версии ОО; г) избежание нежелательной утечки информации о распространении ОО потребителю; возможны случаи, при которых потенциальным нарушителям не следует знать о том, когда и каким образом поставляется ОО; д) избежание/обнаружение перехвата ОО во время поставки; е) избежание задержки поставки или невыполнения поставки ОО.
Элементы действий оценщика
ALC_DEL.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_DEL.1.1C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 12.4.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ALC_DVS.1 Идентификация мер безопасности

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

Зависимости:	отсутствуют.
Элементы действий разработчика
ALC_DVS.1.1D	Разработчик должен представить документацию по безопасности разработки.
Элементы содержания и представления документированных материалов
ALC_DVS.1.1C	Документация по безопасности разработки должна содержать описание всех физических, процедурных, организационных и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки.
ALC_DVS.1.2C	Для противодействия угрозам разработчик должен принять и задокументировать меры защиты, включающие: а) обеспечение контроля физического доступа к средствам вычислительной техники, используемым на стадии разработки и тестирования ОО; б) выделение сегментов вычислительных сетей, в которых располагаются средства вычислительной техники, используемые на стадии разработки ОО специализированных банковских приложений (специализированного ПО) финансовых организаций; в) выделение сегментов вычислительных сетей, в которых располагаются средства вычислительной техники, используемые на стадии тестирования ОО специализированных банковских приложений (специализированного ПО) финансовых организаций; г) организацию и контроль изоляции и информационного взаимодействия сегмента разработки, сегмента тестирования и сегментов вычислительных сетей, в которых располагаются средства вычислительной техники, используемые для реализации банковских технологических процессов, технологических процессов финансовой организации; д) управление доступом к ресурсам, средствам разработки и тестирования ОО специализированных банковских приложений (специализированного ПО) финансовых организаций, в том числе исходным файлам; е) регистрацию и контроль действий с исходными файлами ОО специализированных банковских приложений (специализированного ПО) финансовых организаций; ж) организацию антивирусной защиты; з) контроль использования коммуникационных портов средств вычислительной техники.
Элементы действий оценщика
ALC_DVS.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_DVS.1.1C.
ALC_DVS.1.2E	Оценщик должен подтвердить, что меры безопасности применяются и направлены на снижение вероятности возникновения в ОО уязвимостей и других недостатков.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 12.5.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ALC_FLR.2

Процедуры сообщений о недостатках

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

Зависимости:	отсутствуют.
Элементы действий разработчика
ALC_FLR.2.1D	Разработчик должен предоставить процедуры устранения недостатков, предназначенные для заявителей (разработчиков, производителей) ОО.
ALC_FLR.2.2D	Разработчик должен установить процедуру получения и отработки всех сообщений пользователей о недостатках безопасности и запросов на исправление этих недостатков.
ALC_FLR.2.3D	Разработчик должен предоставить руководство по устранению недостатков, предназначенное для пользователей ОО.
Элементы содержания и представления документированных материалов
ALC_FLR.2.1C	Документация процедур устранения недостатков должна содержать описание процедур по отслеживанию всех ставших известными недостатков безопасности в каждом релизе ОО.
ALC_FLR.2.2C	Процедуры устранения недостатков должны содержать требование представления описания сути и последствий каждого недостатка безопасности, а также состояния процесса исправления этого недостатка.
ALC_FLR.2.3C	Процедуры устранения недостатков должны содержать требование к тому, что для каждого недостатка безопасности должны быть идентифицированы корректирующие действия.
ALC_FLR.2.4C	Документация процедур устранения недостатков должна содержать описание методов, используемых для предоставления пользователям ОО информации о недостатках, материалов исправлений и руководства по внесению исправлений.
ALC_FLR.2.5C	Процедуры устранения недостатков должны описывать средства, посредством которых разработчик получает от пользователей ОО сообщения и запросы о предполагаемых недостатках безопасности в ОО.
ALC_FLR.2.6C	Процедуры обработки ставших известными недостатков безопасности должны обеспечить, чтобы любые ставшие известными недостатки были исправлены, а для пользователей ОО выпущены процедуры по исправлению.
ALC_FLR.2.7C	Процедуры обработки ставших известными недостатков безопасности должны обеспечить такие защитные меры, чтобы любые исправления этих недостатков не приводили к появлению новых недостатков.
ALC_FLR.2.8C	Руководство по устранению недостатков должно описывать средства, посредством которых пользователи ОО могут сообщать разработчикам о любых предполагаемых недостатках безопасности в ОО.
Элементы действий оценщика
ALC_FLR.2.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_FLR.2.1C - ALC_FLR.2.8C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 12.6.2 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ALC_FPU_EXT.1 Процедуры обновления программного обеспечения
Элементы действий разработчика
ALC_FPU_EXT.1.1D	Разработчик должен разработать и реализовать технологию обновления ОО для [выбор: обновление, направленное на устранение уязвимостей ОО; иное обновление, оказывающее влияние на безопасность ОО; обновление, не оказывающее влияния на безопасность ОО ].
ALC_FPU_EXT.1.2D	Разработчик должен разработать и поддерживать регламент обновления программного обеспечения.
ALC_FPU_EXT.1.3D	Разработчик должен разработать и реализовать процедуру уведомления потребителей о выпуске обновлений ОО, основанную на [назначение: способы уведомления].
ALC_FPU_EXT.1.4D	Разработчик должен разработать и реализовать процедуру предоставления обновлений потребителям ОО, основанную на [назначение: способы предоставления обновлений].
ALC_FPU_EXT.1.5D	Разработчик должен разработать и реализовать процедуру предоставления обновлений оценщику для проведения внешнего контроля, основанную на [назначение: способы предоставления обновлений для контроля].
Элементы содержания и представления документированных материалов
ALC_FPU_EXT.1.1C	Документация ОО должна содержать описание технологии выпуска обновлений ОО.
ALC_FPU_EXT.1.2C	Документация ОО должна содержать регламент обновления ОО, включающий: а) идентификацию типов выпускаемых обновлений; б) описание процедуры уведомления потребителей о выпуске обновлений; в) описание процедуры предоставления обновлений потребителям; г) описание содержания эксплуатационной документации на выпускаемые обновления; д) [назначение: иная информация].
ALC_FPU_EXT.1.3C	Регламент обновления ОО должен предусматривать включение в эксплуатационную документацию на выпускаемые обновления описания следующих процедур: а) процедуры получения обновления; б) процедуры контроля целостности обновления; в) типовой процедуры тестирования обновления; г) процедуры установки и применения обновления; д) процедуры контроля установки обновления; е) процедуры верификации (проверки) применения обновления.
ALC_FPU_EXT.1.4C	Документация процедуры предоставления обновлений для проведения внешнего контроля должна содержать: а) описание процедуры предоставления обновлений для внешнего контроля; б) требования к предоставлению и содержанию методики тестирования обновления разработчиком; в) требования к оформлению и предоставлению результатов тестирования обновления разработчиком; г) [назначение: иная информация].
Элементы действий оценщика
ALC_FPU_EXT.1.1E	Оценщик должен подтвердить, что информация, предоставленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированных материалов, изложенным в ALC_FPU_EXT.1.1C - ALC_FPU_EXT.1.4C.
ALC_FPU_EXT.1.2E	Оценщик должен проверить, что процедура предоставления обновлений для проведения внешнего контроля позволяет организовать и проводить их внешний контроль. Замечания по применению: В качестве типов обновлений рассматриваются: обновления, направленные на устранение уязвимостей ОО; иные обновления, оказывающие влияние на безопасность ОО; обновления, не оказывающие влияния на безопасность ОО.
ALC_LCD.1	Определенная разработчиком модель жизненного цикла

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

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

Зависимости:	отсутствуют.
Элементы действий разработчика
ALC_LCD.1.1D	Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.
ALC_LCD.1.2D	Разработчик должен представить документацию по определению жизненного цикла.
Элементы содержания и представления документированных материалов
ALC_LCD.1.1C	Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО. Замечания по применению: Модель жизненного цикла ОО должна содержать следующие стадии: 1) проектирование; 2) создание и тестирование; 3) приемка и ввод в действие; 4) сопровождение и модернизация.
ALC_LCD.1.2C	Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО. Замечания по применению: На каждой стадии жизненного цикла формируется собственный набор свидетельств доверия, по результатам оценки которых может быть принято решение о полноте и корректности реализации требований к обеспечению ИБ, предъявляемых к ОО. В качестве документированных материалов рекомендуется рассматривать: а) регламенты, используемые для организации деятельности по обеспечению ИБ на этапах жизненного цикла ОО; б) документированные результаты выполнения деятельности по обеспечению ИБ на этапах жизненного цикла ОО.
Элементы действий оценщика
ALC_LCD.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_LCD.1.1C и ALC_LCD.1.2C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 12.7.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ALC_LCD_EXT.3	Определенные разработчиком сроки поддержки
Зависимости:	отсутствуют.
Элементы действий разработчика
ALC_LCD_EXT.3.1D	Заявитель, разработчик, производитель должны установить в совместной декларации срок [назначение: срок], в течение которого они обязуются выполнять все необходимые действия по поддержке ОО, направленные на обеспечение поддержания сертификата соответствия ОО требованиям безопасности информации.
ALC_LCD_EXT.3.2D	Заявитель, разработчик, производитель должны обеспечить представление совместной декларации о сроке поддержки ОО вместе с заявкой на сертификацию ОО.
Элементы содержания и представления документированных материалов
ALC_LCD_EXT.3.1C	Декларация о сроке поддержки ОО должна содержать план поддержки ОО на весь задекларированный срок, включающий описание всех предпринимаемых действий по обеспечению поддержания сертификата соответствия ОО требованиям безопасности информации.
ALC_LCD_EXT.3.2C	Декларация о сроке поддержки ОО должна содержать сведения о поддерживаемой версии ОО.
Элементы действий оценщика
ALC_LCD_EXT.3.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_LCD_EXT.3.1C и ALC_LCD_EXT.3.2С.
ALC_TAT.1	Полностью определенные инструментальные средства разработки

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

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

Зависимости:	ADV_IMP.1 Подмножество реализации ФБО.
Элементы действий разработчика
ALC_TAT.1.1D	Разработчик должен идентифицировать каждое инструментальное средство, используемое для разработки (производства) ОО.
ALC_TAT.1.2D	Разработчик должен задокументировать выбранные опции инструментальных средств разработки (производства), обусловленные реализацией.
Элементы содержания и представления документированных материалов
ALC_TAT.1.1C	Все инструментальные средства разработки (производства), используемые для реализации, должны быть полностью определены.
ALC_TAT.1.2C	В документации по инструментальным средствам разработки (производства) должны быть однозначно определены значения всех языковых конструкций, используемых в реализации.
ALC_TAT.1.3C	В документации по инструментальным средствам разработки (производства) должны быть однозначно определены значения всех опций, обусловленных реализацией, методы, приемы и правила эксплуатации средств разработки (производства) при создании (производстве) ОО.
ALC_TAT.1.3C	Должны иметься и поддерживаться лицензии (права) на все инструментальные средства разработки.
Элементы действий оценщика
ALC_TAT.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_TAT.1.1C - ALC_TAT.1.4C.

Работы оценки

1. Оценщик должен выполнить действия в соответствии с пунктом 12.8.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

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

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

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

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

7.2.5. Тестирование (ATE)

ATE_COV.2	Анализ покрытия
Зависимости:	ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации; ATE_FUN.1 Функциональное тестирование.
Элементы действий разработчика
ATE_COV.2.1D	Разработчик должен представить анализ покрытия тестами.
Элементы содержания и представления документированных материалов
ATE_COV.2.1C	Анализ покрытия тестами должен демонстрировать соответствие между тестами из тестовой документации и ИФБО из функциональной спецификации.
ATE_COV.2.2C	Анализ покрытия тестами должен демонстрировать, что все ИФБО из функциональной спецификации были подвергнуты тестированию.
Элементы действий оценщика
ATE_COV.2.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ATE_COV.2.1C и ATE_COV.2.2C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 13.3.2 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ATE_DPT.2	Тестирование: модули, осуществляющие безопасность
Зависимости:	ADV_ARC.1 Описание архитектуры безопасности ADV_TDS.3 Базовый модульный проект ATE_FUN.1 Функциональное тестирование
Элементы действий разработчика
ATE_DPT.2.1D	Разработчик должен представить анализ глубины тестирования.
Элементы содержания и представления документированных материалов
ATE_DPT.2.1C	Анализ глубины тестирования должен демонстрировать соответствие между тестами в тестовой документации и подсистемами ФБО, а также осуществляющими выполнение ФТБ модулями из проекта ОО.
	Замечания по применению: Для каждого интерфейса каждой функции обеспечения ИБ должны быть предусмотрены процедуры тестирования, соответствующие этому интерфейсу.
ATE_DPT.2.2C	Анализ глубины тестирования должен демонстрировать, что все подсистемы ФБО из проекта ОО были подвергнуты тестированию.
ATE_DPT.2.3C	Анализ глубины тестирования должен демонстрировать, что осуществляющие выполнение ФТБ модули из проекта ОО были подвергнуты тестированию.
Элементы действий оценщика
ATE_DPT.2.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ATE_DPT.2.1C - ATE_DPT.2.3C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 13.4.2 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ATE_FUN.1	Функциональное тестирование
Зависимости:	ATE_COV.1 Свидетельство покрытия.
Элементы действий разработчика
ATE_FUN.1.1D	Разработчик должен протестировать ФБО и задокументировать результаты.
ATE_FUN.1.2D	Разработчик должен представить тестовую документацию.
Элементы содержания и представления документированных материалов
ATE_FUN.1.1C	Тестовая документация должна состоять из планов тестирования, а также ожидаемых и фактических результатов тестирования.
ATE_FUN.1.2C	В планах тестирования должны быть идентифицированы тесты, которые необходимо выполнить, а также должны содержаться описания сценариев проведения каждого теста. В эти сценарии должны быть включены также любые зависимости последовательности выполнения тестов от результатов других тестов.
	Замечания по применению: В среде разработки и тестирования не рекомендуется использование реальных данных, полученных в результате реализации банковских технологических процессов, технологических процессов финансовой организации. В случае если для тестирования необходимы данные, максимально приближенные к реальным, рекомендуется формирование тестовых массивов данных путем необратимого обезличивания, маскирования и (или) искажения сведений, полученных в результате реализации банковских технологических процессов, технологических процессов финансовой организации. Запрещается использование в тестировании каких-либо данных, на которые на основании законодательства Российской Федерации, в том числе нормативных актов Банка России, внутренних документов организации БС Российской Федерации и (или) договоров с клиентами и контрагентами, распространяется требование к обеспечению ИБ.
ATE_FUN.1.3C	Ожидаемые результаты тестирования должны продемонстрировать прогнозируемые данные на выходе успешного выполнения тестов.
ATE_FUN.1.4C	Фактические результаты тестирования должны соответствовать ожидаемым.
	Замечания по применению: Факт выполнения теста должен подтверждаться протоколом тестирования, содержащим дату тестирования, указание на методику тестирования, использованные при выполнении теста исходные данные, полученный результат и решение об успешном или неуспешном выполнении теста.
Элементы действий оценщика
ATE_FUN.1.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ATE_FUN.1.1C - ATE_FUN.1.4C.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 13.5.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

ATE_IND.2 Выборочное независимое тестирование
Зависимости:	ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации; AGD_OPE.1 Руководство пользователя по эксплуатации; AGD_PRE.1 Подготовительные процедуры; ATE_COV.1 Свидетельство покрытия; ATE_FUN.1 Функциональное тестирование.
Элементы действий разработчика
ATE_IND.2.1D	Разработчик должен представить ОО для тестирования.
Элементы содержания и представления документированных материалов
ATE_IND.2.1C	ОО должен быть пригоден для тестирования.
ATE_IND.2.2C	Разработчик должен представить набор ресурсов, эквивалентных использованным им при функциональном тестировании ФБО.
Элементы действий оценщика
ATE_IND.2.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ATE_IND.2.1C и ATE_IND.2.2C.
ATE_IND.2.2E	Оценщик должен выполнить выборку тестов из тестовой документации, чтобы верифицировать результаты тестирования, полученные заявителем (разработчиком, производителем).
ATE_IND.2.3E	Оценщик должен протестировать ФБО так, чтобы подтвердить, что все ФБО функционируют в соответствии со спецификациями.

Работы оценки

Оценщик должен выполнить действия в соответствии с пунктом 13.6.2 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".

7.2.6. Оценка уязвимостей (AVA)

AVA_CCA_EXT.1	Анализ скрытых каналов
Зависимости:	AVA_VAN.4 Методический анализ уязвимостей; ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации; ADV_IMP.2 Полное отображение представления реализации функций безопасности объекта оценки; AGD_OPE.1 Руководство пользователя по эксплуатации; AGD_PRE.1 Подготовительные процедуры; [FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками].
Элементы действий разработчика
AVA_CCA_EXT.1.1D	Разработчик должен провести поиск скрытых каналов для реализуемых ОО [выбор: политики управления информационными потоками; политики управления доступом; [назначение: иные политики] ].
AVA_CCA_EXT.1.2D	Разработчик должен представить документацию по анализу скрытых каналов.
Элементы содержания и представления документированных материалов
AVA_CCA_EXT.1.1C	В документации по анализу скрытых каналов должны быть идентифицированы скрытые каналы и должна содержаться оценка их пропускной способности.
AVA_CCA_EXT.1.2C	Документация по анализу скрытых каналов должна содержать описание процедур, использованных для вынесения заключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытых каналов.
AVA_CCA_EXT.1.3C	Документация по анализу скрытых каналов должна содержать описание всех предположений (быстродействие процессора, системная конфигурация, объем памяти и (или) иных), сделанных при анализе скрытых каналов.
AVA_CCA_EXT.1.4C	Документация по анализу скрытых каналов должна содержать описание метода, использованного для оценки пропускной способности канала для наиболее опасного сценария.
AVA_CCA_EXT.1.5C	Документация по анализу скрытых каналов должна содержать описание наиболее опасного сценария использования каждого идентифицированного скрытого канала.
Элементы действий оценщика
AVA_CCA_EXT.1.1E	Оценщик должен подтвердить, что информация, представленная разработчиком в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированных материалов, изложенным в AVA_CCA_EXT.1.1C - AVA_CCA_EXT.1.5C.
AVA_CCA_EXT.1.2E	Оценщик должен подтвердить, что результаты анализа скрытых каналов, выполненного разработчиком, свидетельствуют об удовлетворении ОО соответствующих функциональных требований (по управлению информационными потоками, управлению доступом и (или) иных).
AVA_CCA_EXT.1.3E	Оценщик должен подтвердить правильность результатов анализа скрытых каналов, выполненного заявителем (разработчиком, производителем).
AVA_VAN.5	Усиленный методический анализ
Зависимости:	ADV_ARC.1 Описание архитектуры безопасности; ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации; ADV_TDS.3 Базовый модульный проект; ADV_IMP.2 Полное отображение представления реализации ФБО; AGD_OPE.1 Руководство пользователя по эксплуатации; AGD_PRE.1 Подготовительные процедуры.
Элементы действий разработчика
AVA_VAN.5.1D	Оценщик должен представить ОО для тестирования.
AVA_VAN.5.2D	Оценщик должен выполнить анализ уязвимостей.
	Замечания по применению: Оценщик проводит анализ уязвимостей с целью выявления типовых ошибок программирования и иных дефектов, приводящих к возникновению уязвимостей. Проведение анализа уязвимостей Оценщиком включает выполнение следующих работ. 1. Оценщик должен выполнить выявление известных и типовых уязвимостей в ОО. Оценщик должен выполнить поиск информации в общедоступных источниках, чтобы идентифицировать потенциальные уязвимости в ОО. Выявление уязвимостей включает в себя: - выявление известных уязвимостей в сетевых службах; - выявление типовых уязвимостей в веб-приложениях; - выявление известных уязвимостей в программном обеспечении; - выявление учетных записей с паролями, содержащимися в словарях, используемых при проведении исследования. Известные уязвимости могут быть выявлены следующими способами: - идентификацией наименований и версий программного обеспечения ОО, сред его разработки и функционирования с последующим поиском в базах данных известных для них уязвимостей; - запуском тест-программ (эксплойтов), воспроизводящих в полном объеме или частично выполнение компьютерных атак с использованием известных уязвимостей. Сообщения об уязвимостях программного обеспечения рекомендуется получать из различных источников, таких как: - база данных уязвимостей в составе банка данных угроз безопасности информации ФСТЭК России (www.bdu.fstec.ru); - уведомления Центра мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Банка России (ФинЦЕРТ Банка России); - уведомления, публикуемые центрами реагирования на компьютерные инциденты (например, уведомления CERT), платежными системами (например, уведомления платежной системы VISA), производителями технических и программных средств (например, уведомления компании ORACLE); - уведомления, публикуемые в общедоступных базах данных уязвимостей, а также распространяемые по подписке (например, www.cve.mitre.org); - сообщения об уязвимостях в ППО, направляемые сторонними специалистами в адрес организации БС Российской Федерации или публикуемые ими в общедоступных источниках, для чего рекомендуется предусматривать способы оперативной связи с соответствующими специалистами организации БС Российской Федерации. Для веб-приложений должен быть выполнен поиск следующих типов известных уязвимостей: - инъекции, в особенности SQL-инъекции, команды операционной системы, LDAP, SSI и XPath-инъекции; - подбор аутентификационных данных; - небезопасная передача данных, в том числе в процессе аутентификации; - ошибки в контроле доступа (например, небезопасные прямые ссылки на объекты, невозможность ограничения доступа по URL и обход директорий); - межсайтовый скриптинг (XSS); - подделка межсайтовых запросов (CSRF); - расщепление запроса HTTP, сокрытие ответа HTTP; - открытое перенаправление; - раскрытие информации о директориях/сценариях; - предсказуемое расположение ресурсов; - идентификация приложений; - чтение произвольных файлов; - раскрытие защищаемой информации; - обратный путь в директориях; - переполнение буфера; - небезопасная конфигурация сервера; - внедрение внешних сущностей (XML, IMAP/SMTP); - загрузка и выполнение произвольного кода; - подмена контента; - недостатки защиты от атак типа Clickjacking; - недостатки защиты от атак на функции форматирования строк; - уязвимости клиентских плагинов. Исследование производится путем анализа данных веб-форм, отправки веб-серверу тестовых запросов с варьируемыми значениями параметров запроса и анализа ответов. Идентификация известных уязвимостей программного обеспечения включает в себя: - инвентаризацию программного обеспечения, установленного на исследуемом техническом средстве, с идентификацией наименований и версий программ, а также установленных обновлений безопасности; - выборку из базы данных уязвимостей, относящихся к идентифицированным версиям программ; - исключение из полученной выборки уязвимостей, устранение которых обеспечено установленными обновлениями безопасности. 2. Оценщик должен выполнить динамический анализ кода ОО с целью выявления уязвимостей. Динамический анализ кода осуществляется путем выполнения или эмуляции выполнения программы на определенной совокупности наборов тестовых исходных данных. Перед выполнением или в процессе выполнения программа иногда инструментируется путем дополнения ее функциями трассировки выполнения для задания и контроля инвариантов, предусловий, постусловий и др. Динамический контроль проводится с использованием специализированных автоматизированных средств и может включать в себя, в частности: а) исследование особенностей исполнения потенциально опасных функций при задании заведомо некорректных аргументов; б) построение динамических путей исполнения программы и идентификацию точек принятия решений, существенных для выполнения функций обеспечения ИБ; в) поиск защищаемой информации в оперативной памяти и в аргументах функций; г) исследование особенностей исполнения программы при типовых атаках (переполнение буфера, внедрение операторов SQL в данные, используемые для формирования запросов к СУБД). Вне зависимости от применяемых способов и методов анализа кода при его осуществлении рекомендуется использование классификаторов типовых ошибок программирования, например, Общего перечня недостатков (Common Weakness Enumeration, CWE), а также способов выявления различных типов ошибок. Выявленным в рамках контроля кода уязвимостям в коде разрабатываемых компонентов ОО целесообразно присваивать оценку степени их критичности (например, высокая, средняя, низкая). Для каждой выявленной уязвимости с учетом ее критичности принимается решение о доработке программного компонента ОО (и о приоритетности доработки) или о принятии рисков, связанных с наличием уязвимости.
AVA_VAN.5.3D	Оценщик должен выполнить тестирование на проникновение.
	Замечания по применению: При тестировании на проникновение исследователь выполняет поиск уязвимостей ОО, воспроизводя действия злоумышленника. Перед началом работ для исследователя создаются условия, эквивалентные тем, в которых действует потенциальный злоумышленник. Перед проведением тестирования на проникновение рекомендуется определить начальные условия его проведения. Рекомендуется учитывать, что максимальная полнота оценки достигается при внутреннем тестировании на проникновение с использованием предоставленного доступа к среде функционирования ОО. Тестирование на проникновение подразделяется на исследования с предоставлением доступа к ОО и без предоставления такого доступа. При исследовании с предоставлением доступа Оценщику предоставляются учетные записи для доступа к ОО. При исследовании без предоставления доступа к ОО задача самостоятельного получения учетных записей пользователей ОО является составной частью тестирования на проникновение. При необходимости тестирование проводится с разными правами доступа в ОО. При тестировании на проникновение могут использоваться две стратегии предоставления исследователю информации об ОО. При стратегии "черного ящика" исследователь оперирует только теми сведениями об ОО, которые получены им самостоятельно в ходе тестирования на проникновение. При стратегии "белого ящика" исследователю заблаговременно предоставляется вся доступная информация об ОО, включая (при наличии) проектную и эксплуатационную документацию, исходные коды программных компонентов ОО и возможность просмотра параметров настройки компонентов ОО. По расположению разработчика относительно сетевого периметра ОО тестирование на проникновение разделяется на внешнее и внутреннее. Тестирование на проникновение, в зависимости от типа ОО, может включать в себя следующие направления исследований, применимые к ОО и среде его функционирования: а) оценка защищенности веб-приложений; б) оценка защищенности специализированных банковских приложений (специализированного ПО) финансовых организаций; в) оценка защищенности мобильных устройств. При проведении оценки защищенности веб-приложений рекомендуются следующие мероприятия: а) выявление уязвимостей, связанных с раскрытием защищаемой информации о приложении, в том числе путем отправки некорректных сообщений, анализа стандартных системных сообщений об ошибках, поиска защищаемой информации в коде и комментариях веб-страниц; б) получение сведений о структуре файловой системы перебором путей и имен файлов (полный перебор, перебор по словарю, проверка наличия стандартных файлов используемых платформ и средств разработки, поиск резервных копий файлов); в) проверка корректности обработки специальных символов в параметрах запроса (символы форматирования вывода, перевода строки и возврата каретки, перехода в вышестоящий каталог, двойное URL-кодирование); г) проверка корректности обработки параметров различной длины; д) проверка корректности обработки числовых параметров, в том числе не предусмотренных технологией обработки больших величин, отрицательных и нулевых значений; е) проверка корректности приведения и преобразования типов параметров; ж) проверка корректности обработки различного представления пользовательских данных, в том числе дублирование заголовков запроса, дублирование параметров сценария; з) проверка корректности обработки параметров универсального идентификатора ресурса (URI - uniform resource identifier), в том числе возможности подключения произвольного внешнего источника данных или перенаправления на внешний или внутренний веб-сайт, возможности обращения к сетевым протоколам, возможности замены полного пути к ресурсу на относительный; и) проверка наличия ошибок, связанных с обработкой загружаемых файлов, в том числе с обработкой имен файлов без расширения, несоответствием расширения типу файла, альтернативными расширениями для файлов одного типа, специальными символами (включая нулевой символ) в имени файла; к) проверка корректности исполнения сценариев при манипулировании входными параметрами, в том числе атрибутами безопасности, используемыми при управлении доступом; л) проверка возможности подбора аутентификационных данных (паролей, включая словарные, идентификаторов сессий, атрибутов, используемых для восстановления паролей); м) проверка корректности обработки идентификаторов сессий пользователей, в том числе обработки событий завершения сессии, интервалов неактивности, сопоставление идентификатора сессии с дополнительными атрибутами, прямо или косвенно идентифицирующими пользователя или его рабочее место, предотвращение повторного и множественного использования идентификаторов сессий; н) проверка корректности реализации механизмов авторизации; о) проверка корректности противодействия атакам на клиентские приложения, в том числе с использованием межсайтового выполнения сценариев и подделки межсайтовых запросов; п) проверка корректности обработки входных параметров сценариев при внедрении в них команд операционных систем, синтаксических конструкций языков программирования и разметки; р) проверка невозможности обхода средств межсетевого экранирования прикладного уровня путем фрагментации данных, смешивания параметров, замены алгоритма кодирования и формата представления данных, замены специальных символов их альтернативными представлениями. При проведении оценки защищенности специализированных банковских приложений (специализированного ПО) финансовых организаций рекомендуются следующие мероприятия: а) прослушивание сетевого трафика и поиск в нем защищаемой информации, включая пароли и хеш-значения паролей пользователей, идентификаторы сессий, авторизационные маркеры, криптографические ключи; б) запуск программ с различными параметрами, в том числе нестандартными, в том числе с использованием значений различной длины, дублирование отдельных параметров с присвоением им разных значений, включение в значения параметров специальных символов, команд операционной системы, операторов интерпретируемых языков программирования; в) мониторинг характера взаимодействия приложения с операционной системой в процессе функционирования, включая идентификацию файлов данных, содержащих защищаемую информацию, трассировку системных вызовов; г) проверка прав доступа к файлам данных, содержащим защищаемую информацию, а также контроль целостности исполняемых файлов приложения. При проведении оценки защищенности мобильных устройств рекомендуются следующие мероприятия: а) проверка наличия защищаемой информации в файлах данных, журналах регистрации событий, в оперативной памяти устройства, а также передачи защищаемой информации в незашифрованном виде; б) проверка возможности чтения ключей шифрования и электронной подписи, а также записи и замены сертификатов ключей; в) идентификация протоколов взаимодействия и проверка возможности принудительного навязывания устройству использования незащищенных версий протоколов (HTTP вместо HTTPS, TELNET вместо SSH, SSH1 вместо SSH2); г) проверка корректности обработки мобильным приложением входящих параметров, в том числе с использованием значений различной длины, дублирование отдельных параметров с присвоением им разных значений, включение в значения параметров специальных символов, команд операционной системы, операторов интерпретируемых языков программирования; д) проверка наличия в мобильном приложении средств защиты от исследования и возможность неавторизованного доступа к интерфейсу программирования приложений.
Элементы содержания и представления документированных материалов
AVA_VAN.5.1C	ОО должен быть пригоден для тестирования.
AVA_VAN.5.2C	Документация анализа уязвимостей Оценщиком должна содержать: а) перечень исследованных компонентов ОО и среды его функционирования с указанием наименований и версий программ, а также установленных обновлений безопасности; б) перечень баз данных уязвимостей, по которым проводился поиск; в) результаты анализа, выполненного для поиска способов, которыми потенциально может быть нарушена реализация ФТБ; г) идентификацию проанализированных предполагаемых уязвимостей; д) перечень выявленных уязвимостей, оценку степени их критичности. Оценку критичности уязвимостей рекомендуется определять в соответствии с методикой Common Vulnerability Scoring System (CVSS); е) рекомендации по устранению выявленных уязвимостей; ж) сведения об устранении обнаруженных уязвимостей; з) демонстрацию для всех выявленных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде функционирования ОО.
AVA_VAN.5.3C	Результаты анализа уязвимостей Оценщиком должны оформляться протоколами анализа уязвимостей, подписываемыми Оценщиками - непосредственными исполнителями разработки ОО и лицами, участвовавшими в его проверке, с отражением в протоколе сведений о дате мероприятия, проверенной части ОО, выявленных уязвимостях и иных дефектах (при наличии), повторном контроле ОО с подтверждением устранения выявленных уязвимостей, дефектов.
AVA_VAN.5.4C	1. Отчет о тестировании на проникновение должен содержать: а) описание начальных условий исследования и постановку задачи; б) описание последовательности действий, которые приводили к выявлению уязвимостей или изменению возможностей исследователя, а также решения об отказе от выполнения запрашиваемых действий; в) описание выявленных уязвимостей, оценку степени их критичности; г) рекомендации по устранению выявленных уязвимостей; д) сведения об устранении уязвимостей.
Элементы действий оценщика
AVA_VAN.5.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в AVA_VAN.5.1C.
AVA_VAN.5.2E	Оценщик должен выполнить поиск информации в общедоступных источниках, чтобы идентифицировать потенциальные уязвимости в ОО.
	Замечания по применению: Поиск и проверка устранения в ОО и средах его функционирования известных (подтвержденных) уязвимостей (в том числе уязвимостей "нулевого дня") проводится по результатам анализа общедоступных источников информации об уязвимостях. Сообщения об уязвимостях программного обеспечения рекомендуется получать из различных источников, таких как: а) база данных уязвимостей в составе банка данных угроз безопасности информации ФСТЭК России (www.bdu.fstec.ru); б) уведомления Центра мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Банка России (ФинЦЕРТ Банка России); в) уведомления, публикуемые центрами реагирования на компьютерные инциденты (например, уведомления CERT), платежными системами (например, уведомления платежной системы VISA), производителями технических и программных средств (например, уведомления компании Oracle); г) уведомления, публикуемые в общедоступных базах данных уязвимостей, а также распространяемые по подписке (например, www.cve.mitre.org); д) сообщения об уязвимостях в ППО, направляемые сторонними специалистами в адрес организации БС Российской Федерации или публикуемые ими в общедоступных источниках, для чего рекомендуется предусматривать способы оперативной связи с соответствующими специалистами организации БС Российской Федерации; е) информация об инцидентах защиты информации направляется посредством технической инфраструктуры Банка России - автоматизированной системы обработки инцидентов Центра мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Департамента информационной безопасности Банка России (АСОИ ФинЦЕРТ). В качестве потенциальных должны быть также рассмотрены известные (подтвержденные) уязвимости, выявленные в отличных от сертифицируемых версиях ОО, а также однотипных ОО. Поиск информации о потенциальных уязвимостях необходимо сосредоточить на источниках, в которых содержится информация об однотипном с ОО прикладном программном обеспечении, а также на источниках, содержащих информацию о типовых уязвимостях, ошибках, недостатках языков программирования, используемых при разработке ОО. Результатом такого поиска является выявление всех возможных способов, которыми может быть нарушена реализация функциональных возможностей безопасности ОО. В качестве источников информации о потенциальных уязвимостях наряду с документацией заявителя должны рассматриваться базы данных уязвимостей и угроз безопасности информации, включая Общий перечень недостатков (CWE), Общий перечень шаблонов атак (САРЕС), рассылки и форумы по безопасности, "хакерские" форумы в сети Интернет, в которых сообщается об уязвимостях в конкретных технологиях и атаках на эти технологии. Оценщику не следует ограничиваться рассмотрением общедоступной информации вышеупомянутых источников, ему следует рассмотреть любую другую доступную информацию, имеющую отношение к уязвимостям ОО или среды функционирования ОО при их использовании в представлении реализации ОО. Процесс идентификации проблемных конструкций может быть итерационным (повторяющимся), т.е. идентификация одной проблемной конструкции может привести к идентификации другой проблемной конструкции, которая требует дальнейшего исследования. В случае обнаружения в ОО пригодных для использования известных уязвимостей сертификационные испытания могут быть продолжены только после их устранения разработчиком.
AVA_VAN.5.3E	Оценщик должен провести независимый методический анализ уязвимостей ОО с использованием документации руководств, функциональной спецификации, проекта ОО, описания архитектуры безопасности и представления реализации, чтобы идентифицировать потенциальные уязвимости в ОО.
	Замечания по применению: Независимый методический анализ уязвимостей должен включать выявление типовых ошибок программирования и иных дефектов, приводящих к возникновению уязвимостей. При этом выявлению подлежат уязвимости кода и уязвимости конфигурации ОО. Идентификация потенциальных уязвимостей предусматривает формирование перечня предполагаемых, но не подтвержденных уязвимостей в ОО по результатам исследований доступных документированных материалов и источников информации об уязвимостях. Предположения основываются на допустимых сценариях реализации угроз безопасности информации в заданных средах функционирования ОО. Оценщик должен выполнить контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.). С этой целью оценщик должен исследовать представленную документацию инструментальных средств разработки, чтобы сделать заключение о том, имеются ли в определении языка программирования проблемные конструкции, которые могут быть применены к информационным объектам. В качестве источников информации о проблемных конструкциях языка программирования, которые могут быть применены к информационным объектам, наряду с документацией заявителя должны также рассматриваться базы данных уязвимостей и угроз безопасности информации, включая Общий перечень недостатков (CWE), Общий перечень шаблонов атак (САРЕС), рассылки и форумы по безопасности, "хакерские" форумы в сети Интернет, в которых сообщается об уязвимостях в конкретных технологиях и атаках на эти технологии. В качестве таких проблемных конструкций, которые могут быть применены к информационным объектам, могут выступать, например, преобразование информационного объекта из одного типа данных в другой, использование псевдонимов (альтернативных имен, которые позволяют ссылаться на одну и ту же часть памяти различными способами), указателей (ссылок) на произвольные области памяти, использование стека для передачи фактических параметров между функциональными объектами, динамическое выделение памяти информационным объектам и т.п. Оценщик должен исследовать представление реализации, с тем чтобы сделать заключение о том, что любое использование проблемных конструкций языка программирования применительно к информационным объектам не вносит уязвимостей. Оценщику следует также удостовериться, что конструкции, не предусмотренные соответствующим стандартом языка программирования, не используются в представлении реализации. Оценщик должен также сделать заключение о том, что ввод данных пользователем обрабатывается ФБО таким способом, при котором ФБО защищены от внесения в них искажений вводимыми данными. Следует отметить, что части ОО, которые не относятся к ФБО, могут не исследоваться, если оценщиком проведено обоснование отсутствия их влияния на ФБО. Результатом идентификации потенциальных уязвимостей должен быть перечень потенциальных уязвимостей, которые являются предметом тестирования проникновения и применимы к ОО. Из рассмотрения могут быть исключены потенциальные уязвимости, для которых обосновано, что используемые в среде функционирования меры защиты информации исключают возможность эксплуатации (использования) этих уязвимостей.
AVA_VAN.5.4E	Оценщик должен провести тестирование проникновения, основанное на идентифицированных уязвимостях, чтобы сделать заключение о том, что ОО является стойким к нападениям, выполняемым нарушителем, обладающим высоким потенциалом нападения.
	Замечания по применению: Тестирование проникновения должно проводиться относительно всех идентифицированных потенциальных уязвимостей в ОО из составленного перечня. Для тестирования проникновения разрабатываются тесты, которые должны охватывать все возможные допустимые сценарии реализации угроз безопасности информации в заданных средах функционирования ОО (шаблоны атак). Тесты проникновения должны позволять оценить все возможности нарушителя по эксплуатации (использованию) идентифицированных потенциальных уязвимостей в ОО. Наиболее тщательно должны быть подготовлены и проведены тесты проникновения, связанные с тестированием уязвимостей, которые потенциально могут быть использованы нарушителем для обхода, отключения или преодоления функций безопасности, реализующих основные функциональные возможности ОО, определяемые видом и типом ОО. Для каждой идентифицированной потенциальной уязвимости из составленного списка должны быть разработаны способы тестирования, учитывающие интерфейсы ОО, используемые для выполнения функций безопасности, определены исходные данные и условия, которые необходимы для тестирования, средства тестирования, необходимые для инициирования интерфейсов, а также возможность использования при анализе уязвимостей тестов, которые выполнялись ранее. Результаты тестирования проникновения должны подтверждать стойкость ОО к действиям нарушителя с высоким потенциалом нападения. Если результаты показывают, что ОО, находящийся в заданных средах функционирования, имеет уязвимости, пригодные для использования нарушителем, по компоненту доверия в целом не может быть вынесена положительная оценка. Результаты анализа уязвимостей отражаются в отдельном протоколе, в котором, как минимум, указываются: а) перечень проанализированных источников информации; б) перечень идентифицированных потенциальных уязвимостей (с указанием источника информации, описанием, указанием последствий от использования нарушителем, минимального уровня компетентности нарушителя для подготовки и реализации уязвимости, времени, возможности по доступу, оборудования, требуемого ему для использования уязвимости); в) описание тестов и методик тестирования проникновения; г) результаты тестирования.

Работы оценки

1. Проверяющая организация должна выполнить действия в соответствии с пунктом 14.2.5 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045-2013
"Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий" для нарушителя с высоким потенциалом нападения.

2. Результаты анализа уязвимостей отражаются в отдельном протоколе, в котором, как минимум, указываются:

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

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

в) описание тестов и методик тестирования проникновения;

г) результаты тестирования.

7.2.7. Поддержка доверия (AMA)

AMA_SIA_EXT.3	Анализ влияния обновлений на безопасность ОО
Зависимости:	отсутствуют.
Элементы действий разработчика
AMA_SIA_EXT.3.1D	Разработчик должен представить материалы анализа влияния обновлений на безопасность ОО.
Элементы содержания и представления документированных материалов
AMA_SIA_EXT.3.1C	Материалы анализа влияния обновлений на безопасность ОО должны содержать краткое описание влияния обновлений на ЗБ, реализацию ОО функциональных возможностей или логическое обоснование отсутствия такого влияния, подтверждение устранения уязвимости (уязвимостей), на устранение которой (которых) направлен выпуск данных обновлений, и невнесения иных уязвимостей в ОО.
AMA_SIA_EXT.3.2C	Материалы анализа влияния обновлений на безопасность ОО для обновлений, влияющих на безопасность, должны идентифицировать функции безопасности, компоненты ОО, на которые влияет данное обновление.
Элементы действий оценщика
AMA_SIA_EXT.3.1E	Оценщик должен подтвердить, что информация, представленная в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированных материалов, изложенным в AMA_SIA_EXT.3.1C, AMA_SIA_EXT.3.2C.
AMA_SIA_EXT.3.2E	Оценщик должен подтвердить влияние (отсутствие влияния) обновлений на безопасность ОО.

7.3. Обоснование требований безопасности

7.3.1. Обоснование требований безопасности для объекта оценки

7.3.1.1. Обоснование функциональных требований безопасности объекта оценки

Таблица 7.4 - Отображение функциональных требований безопасности на цели безопасности

	Цель безопасности-1	Цель безопасности-2	Цель безопасности-3	Цель безопасности-4	Цель безопасности-5	Цель безопасности-6
FAU_GEN.1					Х
FAU_GEN.2					Х
FAU_SAR.1					Х
FAU_SAR.2					Х
FAU_STG.1					Х
FAU_STG.3					Х
FAU_STG.4					Х
FDP_ACC.1	Х
FDP_ACF.1	Х
FDP_DAR_EXT.1			Х
FDP_ETC.1				Х
FDP_RIP.2			Х
FDP_ROL.1	Х
FIA_AFL.1						Х
FIA_ATD.1						Х
FIA_SOS.1						Х
FIA_UAU.2						Х
FIA_UAU.4						Х
FIA_UAU.5						Х
FIA_UAU.7						Х
FIA_UID.1						Х
FMT_CFG_EXT.1		Х
FMT_MEC_EXT.1		Х		Х
FMT_MSA.1	Х
FMT_MSA.3	Х
FMT_MTD.1	Х
FMT_SMF.1	Х
FMT_SMR.1	Х
FPR_ANO_EXT.1			Х			Х
FPT_AEX_EXT.1	Х	Х
FPT_API_EXT.1	Х
FPT_LIB_EXT.1	Х
FPT_TST.1	Х
FPT_TUD_EXT.1	Х
FTA_MCS.1	Х
FTP_DIT_EXT.1			Х	Х
FDP_ITC_1				Х

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

Выполнение требований данного компонента обеспечивает возможность регистрации возникновения всех событий, связанных с выполнением функций безопасности ОО. Рассматриваемый компонент сопоставлен с целью Цель безопасности-5 и способствует ее достижению.

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

Выполнение требований данного компонента обеспечивает возможность регистрации возникновения всех событий, связанных с идентификатором пользователя, который был инициатором этого события. Рассматриваемый компонент сопоставлен с целью Цель безопасности-5 и способствует ее достижению.

FAU_SAR.1 Просмотр аудита

Выполнение требований данного компонента обеспечивает возможность предоставления администратору ППО всей информации аудита в понятном для него виде. Рассматриваемый компонент сопоставлен с целью Цель безопасности-5 и способствует ее достижению.

FAU_SAR.2 Ограниченный просмотр аудита

Выполнение требований данного компонента обеспечивает возможность ограничения доступа пользователям к чтению записей аудита, за исключением пользователей, которым явно предоставлен доступ на чтение. Рассматриваемый компонент сопоставлен с целью Цель безопасности-5 и способствует ее достижению.

FAU_STG.1 Защищенное хранение журнала аудита

Выполнение требований данного компонента обеспечивает возможность защиты хранимых записей аудита от несанкционированного удаления и предотвращения модификации записей аудита. Рассматриваемый компонент сопоставлен с целью Цель безопасности-5 и способствует ее достижению.

FAU_STG.3 Действия в случае возможной потери данных аудита

Выполнение требований данного компонента обеспечивает возможность защиты журнала аудита от переполнения. Рассматриваемый компонент сопоставлен с целью Цель безопасности-5 и способствует ее достижению.

FAU_STG.4 Предотвращение потери данных аудита

Выполнение требований данного компонента обеспечивает возможность выполнения действий, направленных на предотвращение потери данных аудита при переполнении журнала аудита. Рассматриваемый компонент сопоставлен с целью Цель безопасности-5 и способствует ее достижению.

FDP_ACC.1 Ограниченное управление доступом

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

FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности

Выполнение требований данного компонента обеспечивает возможность осуществления управления доступом к объектам доступа ОО на основе списков управления доступом. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

FDP_DAR_EXT.1 Шифрование защищаемой информации приложения

Выполнение требований данного компонента обеспечивает защиту защищаемой информации при хранении и обработке. Рассматриваемый компонент сопоставлен с целью Цель безопасности-3 и способствует ее достижению.

FDP_ETC.1 Экспорт данных пользователя без атрибутов безопасности

Выполнение требований данного компонента обеспечивает возможность осуществления контроля данных при экспорте компонентам ППО. Рассматриваемый компонент сопоставлен с целью Цель безопасности-4 и способствует ее достижению.

FDP_ITC_1 Импорт данных пользователя без атрибутов безопасности

Выполнение требований данного компонента обеспечивает возможность осуществления контроля данных при импорте из компонентов ППО. Рассматриваемый компонент сопоставлен с целью Цель безопасности-4 и способствует ее достижению.

FDP_RIP.2 Полная защита остаточной информации

Выполнение требований данного компонента обеспечивает недоступность содержания всей остаточной информации любых ресурсов, контролируемых ОО, при распределении или освобождении ресурса. Рассматриваемый компонент сопоставлен с целью Цель безопасности-3 и способствует ее достижению.

FDP_ROL.1 Базовый откат

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

FIA_AFL.1 Обработка отказов аутентификации

Выполнение требований данного компонента обеспечивает ограничение попыток пройти процедуру аутентификации для лиц, не являющихся уполномоченными пользователями. При достижении определенного числа неуспешных попыток аутентификации некоторого лица ОО предпринимаются действия, направленные на дальнейшее предотвращение попыток доступа со стороны данного лица, ограниченные временным интервалом. Рассматриваемый компонент сопоставлен с целью Цель безопасности-6 и способствует ее достижению.

FIA_ATD.1 Определение атрибутов пользователя

Выполнение требований данного компонента обеспечивает поддержание для каждого пользователя (или других уполномоченных идентифицированных ролей) список атрибутов безопасности. Рассматриваемый компонент сопоставлен с целью Цель безопасности-6 и способствует ее достижению.

FIA_SOS.1 Верификация секретов

Выполнение требований данного компонента обеспечивает предоставление механизма для верификации соответствия паролей определенным требованиям. Рассматриваемый компонент сопоставлен с целью Цель безопасности-6 и способствует ее достижению.

FIA_UAU.2 Аутентификация до любых действий пользователя

Выполнение требований данного компонента обеспечивает аутентификацию субъекта доступа до выполнения любых действий по доступу в информационную систему или привилегированного субъекта доступа до выполнения действий по управлению ОО. Рассматриваемый компонент сопоставлен с целью Цель безопасности-6 и способствует ее достижению.

FIA_UAU.4 Механизмы одноразовой аутентификации

Выполнение требований данного компонента предотвращает повторное применение аутентификационных данных. Рассматриваемый компонент сопоставлен с целью Цель безопасности-6 и способствует ее достижению.

FIA_UAU.5 Сочетание механизмов аутентификации

Выполнение требований данного компонента обеспечивает возможность выполнения аутентификации с использованием сочетания различных механизмов аутентификации. Рассматриваемый компонент сопоставлен с целью Цель безопасности-6 и способствует ее достижению.

FIA_UAU.7 Аутентификация с защищенной обратной связью

Выполнение требований данного компонента обеспечивает исключение отображения действительного значения аутентификационной информации при ее вводе пользователем в диалоговом интерфейсе. Рассматриваемый компонент сопоставлен с целью Цель безопасности-6 и способствует ее достижению.

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

Выполнение требований данного компонента обеспечивает выполнение определенных действий до идентификации пользователя. Рассматриваемый компонент сопоставлен с целью Цель безопасности-6 и способствует ее достижению.

FMT_CFG_EXT.1 Конфигурация безопасности по умолчанию

Выполнение требований данного компонента обеспечивает предоставление уполномоченным пользователям только ограниченной функциональности ОО при его конфигурировании по умолчанию. Рассматриваемый компонент сопоставлен с целью Цель безопасности-2 и способствует ее достижению.

FMT _MEC_EXT.1 Поддерживаемый механизм конфигурации

Выполнение требований данного компонента обеспечивает защиту конфигурационных данных, находящихся под управлением ОО. Рассматриваемый компонент сопоставлен с целью Цель безопасности-2 и способствует ее достижению.

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

Выполнение требований данного компонента обеспечивает возможность модифицировать атрибуты безопасности в правилах политики управления доступом только уполномоченным идентифицированным ролям. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

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

Выполнение требований данного компонента обеспечивает возможность определения правил политики управления доступом, которую должен наследовать атрибут безопасности. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

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

Выполнение требований данного компонента предоставляет возможность запроса и добавления данных компонентов ОО и данных аудита, запроса и модификации всех прочих данных ОО, а также внесения новых правил контроля только администратору. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

FMT_SMF.1 Спецификация функций управления

Выполнение требований данного компонента обеспечивает наличие у ОО, как минимум, функций управления режимом выполнения функций безопасности и функций управления данными ФБО. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

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

Выполнение требований данного компонента обеспечивает поддержание ролей безопасности и их ассоциации. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

FPR_ANO_EXT.1 Согласие пользователей на обработку персональных данных (идентификационной информации)

Выполнение требований данного компонента обязывает ОО запрашивать согласие пользователя на использование его персональной идентификационной информации. Рассматриваемый компонент сопоставлен с целями Цель безопасности-3, Цель безопасности-6 и способствуют их достижению.

FPT_AEX_EXT.1 Противодействие использованию уязвимостей безопасности

Выполнение требований данного компонента обеспечивает возможность контролировать использование уязвимых программных ресурсов. Рассматриваемый компонент сопоставлен с целями Цель безопасности-1, Цель безопасности-2 и способствуют их достижению.

FPT_API_EXT.1 Использование поддерживаемых сервисов и прикладных программных интерфейсов

Выполнение требований данного компонента обеспечивает возможность контролировать использование в программном продукте только легитимных программных ресурсов. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

FPT_LIB_EXT.1 Использование сторонних библиотек

Выполнение требований данного компонента обеспечивает возможность контроля использования сторонних библиотек. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

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

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

FPT_TUD_EXT.1 Целостность при установке и обновлении

Выполнение требований данного компонента обеспечивает возможность контроля целостности устанавливаемых обновлений ПО. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

FTA_MCS.1 Базовое ограничение на параллельные сеансы

Выполнение требований данного компонента ограничивает максимальное число параллельных сеансов, предоставляемых одному и тому же пользователю. Рассматриваемый компонент сопоставлен с целью Цель безопасности-1 и способствует ее достижению.

FTP_DIT_EXT.1 Защита данных при передаче

Выполнение требований данного компонента обеспечивает контроль за передачей данных между ОО и другими доверенными продуктами ППО. Рассматриваемый компонент сопоставлен с целями Цель безопасности-3, Цель безопасности-4 и способствуют их достижению.

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

В таблице 7.5 представлены результаты удовлетворения зависимостей функциональных требований безопасности. Все зависимости компонентов требований удовлетворены в настоящем ПЗ либо включением компонентов, определенных в национальном стандарте Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности" под рубрикой "Зависимости", либо включением компонентов, иерархичных по отношению к компонентам, определенным в национальном стандарте Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности" под рубрикой "Зависимости".

Cтолбец 1 таблицы 7.5 является справочным и содержит компоненты, определенные в национальном стандарте Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", в описании компонентов требований, приведенных в столбце 2 таблицы 7.5 под рубрикой "Зависимости".

Столбец 3 таблицы 7.5 показывает, какие компоненты требований были включены в настоящий ПЗ для удовлетворения зависимостей компонентов, приведенных в столбце 2 таблицы 7.5. Компоненты требований в столбце 3 таблицы 7.5 либо совпадают с компонентами в столбце 2 таблицы 7.5, либо иерархичны по отношению к ним.

Таблица 7.5 - Зависимости функциональных требований безопасности

Функциональные компоненты	Зависимости в соответствии с ГОСТ Р ИСО/МЭК 15408 и подразделом 7.1 настоящего ПЗ	Удовлетворение зависимостей
FAU_GEN.1	FPT_STM.1	Цель безопасности сред-4
FAU_GEN.2	FAU_GEN.1 FIA_UID.1	FAU_GEN.1 FIA_UID.2
FAU_SAR.1	FAU_GEN.1	FAU_GEN.1
FAU_SAR.2	FAU_SAR.1	FAU_SAR.1
FAU_STG.1	FAU_GEN.1	FAU_GEN.1
FAU_STG.3	FAU_STG.1	FAU_STG.1
FAU_STG.4	FAU_STG.1	FAU_STG.1
FDP_ACC.1	FDP_ACF.1	FDP_ACF.1
FDP_ACF.1	FDP_ACC.1 FMT_MSA.3	FDP_ACC.1 FMT_MSA.3
FDP_ETC.1	[FDP_ACC.1 или FDP_IFC.1]	FDP_ACC.1
FDP_ITC_1	[FDP_ACC.1 или FDP_IFC.1] FMT_MSA.3	FDP_ACC.1 FMT_MSA.3
FDP_ROL.1	[FDP_ACC.1 или FDP_IFC.1]	FDP_ACC.1
FIA_AFL.1	FIA_UAU.1	FIA_UAU.1
FIA_UAU.1	FIA_UID.1	FIA_UID.1
FMT_MSA.1	[FDP_ACC.1 или FDP_IFC.1] FMT_SMF.1 FMT_SMR.1	FDP_ACC.1 FMT_SMR.1 FMT_SMF.1
FMT_MSA.3	FMT_MSA.1 FMT_SMR.1	FMT_MSA.1 FMT_SMR.1
FMT_MTD.1	FMT_SMF.1 FMT_SMR.1	FMT_SMF.1 FMT_SMR.1
FMT _MEC_EXT.1	FMT_SMF.1	FMT_SMF.1
FMT_CFG_EXT.1	FMT_SMF.1	FMT_SMF.1
FMT_SMR.1	FIA_UID.1	FIA_UID.1
FTA_MCS.1	FIA_UID.1	FIA_UID.1

7.3.1.3. Обоснование требований доверия к безопасности объекта оценки

Требования доверия настоящего ПЗ соответствуют ОУД4, усиленному компонентами ADV_IMP.2 "Полное отображение представления реализации ФБО", ALC_FLR.2 "Процедуры сообщений о недостатках", AVA_VAN.5 "Усиленный методический анализ", расширенный компонентами ADV_IMP_EXT.3 "Реализация ОО", ALC_FPU_EXT.1 "Процедуры обновления программного обеспечения", AMA_SIA_EXT.3 "Анализ влияния обновлений на безопасность" и AVA_CCA_EXT.1 "Анализ скрытых каналов".