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

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

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

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

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

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

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. Термины и определения

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

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

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

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

Предположение-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

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

Цель безопасности среды-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	Надежные метки времени
FPTTDC.1	Базовая согласованность данных ФБО между ФБО
FPTTST.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	ФБО должны предотвращать повторное применение аутентификационных данных, связанных с [назначение: идентифицированный механизм (механизмы) аутентификации].
Зависимости:	отсутствуют.
FIA_UAU.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_EXT1.1	ФБО должны при установке новых учетных данных, когда конфигурируются с учетными данными по умолчанию или без учетных данных, предоставить [назначение: уполномоченные пользователи] только ограниченную функциональность.
FMT_CFG_EXT1.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.6C
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.1C - ADV_IMP.2.4C
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	В проекте должен быть описан каждый поддерживающий и не влияющий на выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.
ADVTDS.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.5G	Система УК должна поддерживать производство ОО автоматизированными средствами.
ALC_CMC.4.6G	Документация УК должна включать в себя план УК.
ALC_CMC.4.7C	В плане УК должно быть описание того, каким образом система УК используется для разработки ОО.
ALC_CMC.4.8C	План УК должен содержать описание процедур, используемых для приемки модифицированных или вновь созданных элементов конфигурации.
ALC_CMC.4.9C	В свидетельствах должно быть продемонстрировано, что все элементы конфигурации сопровождаются системой УК.
ALC_CMC.4.10С	В свидетельствах должно быть продемонстрировано, что система УК функционирует в соответствии с планом УК.
Элементы действий оценщика
ALC_CMC.4.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в 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.1C	Список элементов конфигурации должен включать следующее: сам ОО; свидетельства оценки, необходимые по требованиям доверия к безопасности; представление реализации; сведения о недостатках безопасности и стадии их устранения.
ALC_CMS.4.2C	Элементы конфигурации должны быть уникально идентифицированы в списке элементов конфигурации.
ALC_CMS.4.3C	Для каждого значимого для ФБО элемента конфигурации в списке элементов конфигурации должен быть указан разработчик.
Элементы действий оценщика
ALC_CMS.4.1E	Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_CMS.4.1C - ALC_CMS.4.3C

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

Оценщик должен выполнить действия в соответствии с пунктом 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.1С	Документация ОО должна содержать описание технологии выпуска обновлений ОО.
ALC_FPU_EXT.1.2С	Документация ОО должна содержать регламент обновления ОО, включающий: а) идентификацию типов выпускаемых обновлений; б) описание процедуры уведомления потребителей о выпуске обновлений; в) описание процедуры предоставления обновлений потребителям; г) описание содержания эксплуатационной документации на выпускаемые обновления; д) [назначение: иная информация].
ALC_FPU_EXT.1.3С	Регламент обновления ОО должен предусматривать включение в эксплуатационную документацию на выпускаемые обновления описания следующих процедур: а) процедуры получения обновления; б) процедуры контроля целостности обновления; в) типовой процедуры тестирования обновления; г) процедуры установки и применения обновления; д) процедуры контроля установки обновления; е) процедуры верификации (проверки) применения обновления.
ALC_FPU_EXT.1.4С	Документация процедуры предоставления обновлений для проведения внешнего контроля должна содержать: а) описание процедуры предоставления обновлений для внешнего контроля; б) требования к предоставлению и содержанию методики тестирования обновления разработчиком; в) требования к оформлению и предоставлению результатов тестирования обновления разработчиком; г) [назначение: иная информация].
Элементы действий оценщика
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.2C
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); д) сообщения об уязвимостях в ППО, направляемые сторонними специалистами в адрес организации БС Российской Федерации или публикуемые ими в общедоступных источниках, для чего рекомендуется предусматривать способы оперативной связи с соответствующими специалистами организации БС Российской Федерации; е) информация об инцидентах защиты информации направляется посредством технической инфраструктуры Банка России - автоматизированной системы обработки инцидентов Центра мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Департамента информационной безопасности Банка России (АСОИ ФинЦЕРТ). В качестве потенциальных должны быть также рассмотрены известные (подтвержденные) уязвимости, выявленные в отличных от сертифицируемых версиях ОО, а также однотипных ОО. Поиск информации о потенциальных уязвимостях необходимо сосредоточить на источниках, в которых содержится информация об однотипном с ОО прикладном программном обеспечении, а также на источниках, содержащих информацию о типовых уязвимостях, ошибках, недостатках языков программирования, используемых при разработке ОО. Результатом такого поиска является выявление всех возможных способов, которыми может быть нарушена реализация функциональных возможностей безопасности ОО.
AVA_VAN.5.3E	В качестве источников информации о потенциальных уязвимостях наряду с документацией заявителя должны рассматриваться базы данных уязвимостей и угроз безопасности информации, включая Общий перечень недостатков (CWE), Общий перечень шаблонов атак (САРЕС), рассылки и форумы по безопасности, "хакерские" форумы в сети Интернет, в которых сообщается об уязвимостях в конкретных технологиях и атаках на эти технологии. Оценщику не следует ограничиваться рассмотрением общедоступной информации вышеупомянутых источников, ему следует рассмотреть любую другую доступную информацию, имеющую отношение к уязвимостям ОО или среды функционирования ОО при их использовании в представлении реализации ОО. Процесс идентификации проблемных конструкций может быть итерационным (повторяющимся), т.е. идентификация одной проблемной конструкции может привести к идентификации другой проблемной конструкции, которая требует дальнейшего исследования. В случае обнаружения в ОО пригодных для использования известных уязвимостей сертификационные испытания могут быть продолжены только после их устранения разработчиком. Оценщик должен провести независимый методический анализ уязвимостей ОО с использованием документации руководств, функциональной спецификации, проекта ОО, описания архитектуры безопасности и представления реализации, чтобы идентифицировать потенциальные уязвимости в ОО. Замечания по применению: Независимый методический анализ уязвимостей должен включать выявление типовых ошибок программирования и иных дефектов, приводящих к возникновению уязвимостей. При этом выявлению подлежат уязвимости кода и уязвимости конфигурации ОО. Идентификация потенциальных уязвимостей предусматривает формирование перечня предполагаемых, но не подтвержденных уязвимостей в ОО по результатам исследований доступных документированных материалов и источников информации об уязвимостях. Предположения основываются на допустимых сценариях реализации угроз безопасности информации в заданных средах функционирования ОО. Оценщик должен выполнить контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.). С этой целью оценщик должен исследовать представленную документацию инструментальных средств разработки, чтобы сделать заключение о том, имеются ли в определении языка программирования проблемные конструкции, которые могут быть применены к информационным объектам. В качестве источников информации о проблемных конструкциях языка программирования, которые могут быть применены к информационным объектам, наряду с документацией заявителя должны также рассматриваться базы данных уязвимостей и угроз безопасности информации, включая Общий перечень недостатков (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 и способствует ее достижению.

FDPRIP.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. Функциональные компоненты безопасности" под рубрикой "Зависимости".

Столбец 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 "Анализ скрытых каналов".

7.4. Безопасный жизненный цикл ОО. Требования к гибкой безопасной разработке и тестированию ОО

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

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

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

В связи с этим требования настоящего раздела могут использоваться в целях реализации требования доверия к безопасности (ТДБ) ОО (п. 7.2. настоящего документа) в случаях, когда финансовая организация либо разработчик ОО (далее при совместном упоминании - Разработчик) реализует документированный безопасный жизненный цикл ОО, основанный на современных гибких практиках разработки, тестирования и внедрения ОО, в основе которых лежат различные методологии безопасного жизненного цикла программных продуктов (например, такие международные и общепринятые в рамках соответствующих сообществ методологии, как SDLC ¹, DevSecOps ², BSIMM ³, OWASP ⁴ и др.).

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

При этом переход от ТДБ, связанных с оценочным уровнем доверия, к настоящей методологии безопасного жизненного цикла возможен только при условии соответствия отдельных процессов Разработчика критериям и условиям, указанным в п. 7.4.2 настоящего раздела.

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

- результаты контрольных мероприятий по ИБ;

- результаты проведенных контролей безопасности (security controls);

- результаты работ по анализу уязвимостей и тестированию

защищенности ОО при подтвержденном общем соответствии документированному процессу безопасной разработки.

7.4.2. Критерии и условия для реализации безопасного жизненного цикла ОО

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

7.4.2.1. Условия для реализации безопасного жизненного цикла ОО

Условия для перехода к оценке соответствия требованиям безопасности процесса разработки ОО:

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

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

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

- инфраструктура Разработчика, на которой выполняются процессы разработки, тестирования и развертывания, а также среды постоянной эксплуатации финансовой организации, должна соответствовать требованиям ГОСТ Р 57580.1-2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер" с учетом определенного уровня защиты информации для финансовой организации ⁷ и иметь соответствующее подтверждение оценки соответствия по ГОСТ Р 57580.2-2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия". При этом инфраструктурные системы (платформы) и решения по обеспечению информационной безопасности и соответствующие требования к ним должны быть документированы в достаточном виде для подтверждения и формирования автотестов и контрольных процедур (например, в рамках интеграционного тестирования с компонентами СОИБ, СМИБ).

7.4.2.2. Критерии для реализации безопасного жизненного цикла ОО

Критерии, при выполнении которых возможен переход к оценке соответствия требованиям безопасности процесса разработки ОО:

- состав команды, участвующей в реализации безопасного жизненного цикла ОО, должен иметь необходимые компетенции ⁸, в том числе предусматривать наличие таких специализированных ролей, как ИТ-архитектор, аналитик ИБ (специалист по безопасности прикладного программного обеспечения и приложений; также встречаются наименования "Application Security", "AppSec"), DevOps-инженеры и тестировщики, а также Security Champion ⁹ - член команды с высокой осведомленностью в вопросах обеспечения информационной безопасности, имеющий определенные компетенции в области безопасности прикладного программного обеспечения и принципов безопасной разработки;

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

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

7.4.2.3. Определение условий для проведения мероприятий по оценке соответствия

Условиями для проведения мероприятий по оценке соответствия процесса разработки ОО требованиям безопасности являются:

- успешное прохождение этапов (задач) жизненного цикла ОО;

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

- получение документального подтверждения успешного переноса ОО в среду промышленной эксплуатации.

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

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

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

- изменения в подсистемах обеспечения ИБ, компонентах ИБ ОО;

- изменения ролевой модели ОО;

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

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

- изменение схем взаимодействия ОО со смежными системами;

- расширение или изменение структуры базы данных ОО;

- мажорный релиз ОО.

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

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

7.4.3. Процесс безопасного жизненного цикла ОО

7.4.3.1. Описание процесса безопасного жизненного цикла ОО. Определение методологии и практик процесса безопасного жизненного цикла ОО

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

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

В состав задач безопасного жизненного цикла ОО входят:

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

- Задача "Формирование требований к ОО" - в данной задаче формулируются функциональные и нефункциональные требования к разрабатываемому ОО, включая требования к обеспечению информационной безопасности ОО;

- Задача "Архитектура и проектирование ОО" - в данной задаче разрабатываются архитектурное решение и проектное описание ОО;

- Задача "Реализация (разработка) ОО" - в данной задаче осуществляются непосредственное кодирование и процесс реализации ОО;

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

- Задача "Подготовка и перенос ОО в промышленную эксплуатацию" - в данной задаче требуется проверить на готовность ОО к выполнению требований ИБ и переносу в промышленную эксплуатацию, корректно перенести версию ОО в среду эксплуатации;

- Задача "Эксплуатация и сопровождение ОО" - в данной задаче реализуются мониторинг, обновление, сопровождение и сопутствующая эксплуатация ОО;

- Задача "Вывод из эксплуатации ОО" - в данной задаче производится снятие с эксплуатации ОО.

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

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

Таблица 1. Связь задач безопасного жизненного цикла ОО и шагов процесса

Задача	Шаг процесса (Приложение В)
Задача "Организационная подготовка"	- Потребности, бизнес-требования - Старт спринта, планирование задачи
Задача "Формирование требований к ОО"	- Разработка требований - Разработка требований ИБ
Задача "Архитектура и проектирование ОО"	- Мониторинг выполнения требований ИБ
Задача "Реализация (разработка) ОО"	- Разработка кода, реиспользование кода - Тест-кейсы, требования к развертыванию и внедрению
Задача "Тестирование ОО"	- Code review - Статический анализ кода - Динамический анализ кода - Security Review - Фаззинг-тестирование - Тестирование на проникновение - Функциональное тестирование - Демо спринта, ретроспектива
Задача "Подготовка и перенос ОО в промышленную эксплуатацию"	- Развертывание, внедрение - Приемка - Эксплуатация и поддержка эксплуатации 10
Задача "Эксплуатация и сопровождение ОО"
Задача "Вывод из эксплуатации ОО"	- Архивирование информации, содержащейся в ОО 11 - Уничтожение (стирание) данных и остаточной информации с машинных носителей информации и (или) уничтожение машинных носителей информации 12

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

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

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

- несоответствий, выявленных в ходе внутренних проверок;

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

- изменения целей применения и объектов применения требований настоящего раздела.

7.4.3.2. Определение требований по подготовке и организации процесса безопасного жизненного цикла ОО

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

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

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

- требования ИБ для защиты инфраструктуры разработки (АРМ разработчиков, репозитории кода, инструменты сред разработки и переноса между средами).

7.4.3.3. Особенности обеспечения безопасности инфраструктур разработки и тестирования

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

- выбор сервисов СОИБ и отдельных функций ИБ;

- подключение и кастомизацию настроек сервисов СОИБ к платформе;

- разделение сред на изолированные сегменты (например, среда разработки, среда тестирования, среда промышленной эксплуатации).

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

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

- обеспечить доступность инструментов контроля целостности программного кода;

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

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

- обеспечить хранение всех файлов релизов в репозитории;

- обеспечить реализацию требований ИБ по защите репозитория от НСД, нарушений целостности и доступности;

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

- обеспечить резервное копирование хранилищ, репозиториев, баз знаний проекта/платформы.

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

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

Ниже приведено базовое определение ролей, связанных с обеспечением информационной безопасности:

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

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

Базовое определение ролей и компетенций, необходимых для выполнения контрольных мероприятий безопасности, представлено в таблице 2.

Таблица 2. Базовое определение ролей

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

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

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

7.4.3.5. Задача "Формирование требований к ОО"

Задачи ИБ, которые должны быть выполнены командой DevSecOps: определение требований ИБ, определение основных векторов атак, планирование первичного конфигурирования и настройки решений по обеспечению ИБ. На основе результатов вышеперечисленного формируется окончательный свод требований по информационной безопасности и проводится оценка соответствия на этапе проверки технического решения.

Состав контрольных мероприятий безопасности, выполняемых в рамках задачи "Формирование требований к ОО", приведен в таблице 3.

Таблица 3 - Контрольные мероприятия безопасности, выполняемые в рамках задачи "Формирование требований к ОО"

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

7.4.3.6. Задача "Архитектура и проектирование ОО"

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

Состав контрольных мероприятий безопасности, выполняемых в рамках задачи "Архитектура и проектирование ОО", приведен в таблице 4.

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

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

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

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

Наиболее важными являются следующие принципы построения архитектуры ОО:

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

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

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

Таблица 4 - Контрольные мероприятия безопасности, выполняемые в рамках задачи "Архитектура и проектирование ОО"

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

7.4.3.7. Задача "Реализация (разработка) ОО"

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

Состав контрольных мероприятий безопасности, выполняемых в рамках задачи "Реализация (разработка) ОО", приведен в таблице 5.

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

Для обеспечения управления версиями и контроля за изменениями ОО, а также в целях

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

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

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

Таблица 5 - Контрольные мероприятия безопасности, выполняемые в рамках задачи "Реализация (разработка) ОО"

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

7.4.3.8. Задача "Тестирование ОО"

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

Состав контрольных мероприятий безопасности, выполняемых в рамках задачи "Тестирование ОО", приведен в таблице 6.

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

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

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

Таблица 6 - Контрольные мероприятия безопасности, выполняемые в рамках задачи "Тестирование ОО"

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

7.4.3.9. Задача "Подготовка и перенос ОО в промышленную эксплуатацию"

Задачи ИБ, которые должны быть выполнены командой DevSecOps: контроль корректности версий и целостности ОО при передаче в среду промышленной эксплуатации, контроль выполнения ТДБ и ФТБ проектной и эксплуатационной документации.

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

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

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

Таблица 7 - Контрольные мероприятия безопасности, выполняемые в рамках задачи "Подготовка и перенос ОО в промышленную эксплуатацию"

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

7.4.3.10. Задача "Эксплуатация и сопровождение ОО"

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

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

На данном этапе используются инструментальные средства для резервного копирования, мониторинга событий и уязвимостей.

Таблица 8 - Контрольные мероприятия безопасности, выполняемые в рамках задачи "Эксплуатация и сопровождение ОО"

Контрольные мероприятия безопасности	Подзадача жизненного цикла	Описание	Входные данные	Результат	Необходимые инструменты	Комментарий
Тестирование безопасности системы управления конфигурация ми	Оценка защищенности ОО	Определение и верификация конфигураций ПО, влияющих на риски ИБ	Типовые конфигурации	Отчет о тестировании, отчет о сравнении конфигураций	Инструмент проверки соответствия требованиям безопасности	Тестирование происходит после развертывания
Тестирование на проникновение	Оценка защищенности ОО	Проведение периодического тестирования на проникновение охватывает все аспекты функционирования подсистем ОО	Развернутый ОО	Отчет о тестировании, найденные уязвимости	Инструментальные средства
Резервное копирование каждого выпуска ОО и всех его компонентов	Хранение всех файлов выпусков в репозитории	Контроль корректности резервного копирования хранилищ, репозиториев, баз знаний проекта/платформы	Доступ к системе резервных копий, компоненты ОО	Заархивированные копии компонентов ОО	Система управления резервным копированием
Мониторинг ОО на наличие уязвимостей	Сопровождение ОО	Осуществление ручного и автоматического анализа уязвимостей	Общеизвестные базы данных уязвимостей, списки рассылки безопасности, отчеты об уязвимостях	Отчет осуществления мониторинга	Инструментальные средства мониторинга
Периодический пересмотр, анализ и тестирование кода ОО для выявления ранее не обнаруженных уязвимостей	Оценка защищенности ОО	Проведение анализа и осуществление тестирования кода ОО	Развернутый ОО, исполняемый код, тестовые наборы входных данных, тестовые сценарии	Обновленные конфигурации настроек инструментов проведения контроля ИБ. Отчеты о выявленных уязвимостях. Скорректированна я оценка векторов и актуальных атак	Инструментальные средства оценки защищенности

7.4.3.11. Задача "Вывод из эксплуатации ОО"

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

Состав контрольных мероприятий безопасности, выполняемых в рамках задачи "Вывод из эксплуатации ОО", приведен в таблице 9.

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

Таблица 9 - Контрольные мероприятия безопасности, выполняемые в рамках задачи "Вывод из эксплуатации ОО"

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

------------------------------

¹ Software development lifecycle.

² Software development, security, IT operations.

³ Building Security in Maturity Model.

⁴ Open Web Application Security Project.

⁵Федеральный закон от 26 июля 2017 г. N 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации".

⁶ В случае если в качестве Разработчика выступает финансовая организация.

⁷ В случае если в качестве Разработчика выступает финансовая организация.

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

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

¹⁰ В приложении В не показан, так как выходит за пределы стандартного спринта разработки.

¹¹ В приложении В не показан, так как выходит за пределы стандартного спринта разработки.

¹² В приложении В не показан, так как выходит за пределы стандартного спринта разработки.