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

FAU_GEN.1.1

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

а) запуск и завершение выполнения функций аудита;

б) создание новых учетных записей и изменение прав доступа учетных записей;

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

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

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

е) все события, потенциально подвергаемые аудиту, на детализированном уровне аудита;

ж) события, приведенные в таблице 7.2;

з) [назначение: другие специально определенные события, потенциально подвергаемые аудиту].

и) все сеансы персонального доступа пользователей к данным платежных карт;

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

FAU_GEN.1.2

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

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

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

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

пароли пользователей;

полные номера платежных карт и критичные авторизационные данные;

закрытые криптографические ключи;

[ назначение: другая защищаемая информация]

].

Компонент

Событие

Детализация

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

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

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 Защищенное хранение журнала аудита.

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_ROL.1 Базовый откат

FDP_ROL.1.1

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

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

FDP_IFC.1 Ограниченное управление информационными потоками].

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

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

Зависимости:

отсутствуют.

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

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

Зависимости:

отсутствуют.

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

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

Зависимости:

отсутствуют.

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

FPR_ANO_EXT.1.1

ФБО должны: [выбор:

не обрабатывать персональную идентификационную информацию;

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

], защита которой требуется в соответствии с законодательством.

Зависимости:

отсутствуют.

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

Программное обеспечение ОО должно [выбор:

предоставлять возможность;

эффективно использовать платформу

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

Зависимости:

отсутствуют.

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

FTA_MCS.1.1

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

FTA_MCS.1.2

ФБО должны задать по умолчанию ограничение [назначение:

задаваемое по умолчанию число] сеансов пользователя.

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

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

FTP_DIT_EXT.1.1

ФБО должны [выбор:

не передавать любые данные;

не передавать любую защищаемую информацию;

шифровать всю передаваемую защищаемую информацию;

реализовать функциональность для шифрования защищаемой информации

] между ОО и другими доверенными продуктами ИТ.

Зависимости:

отсутствуют.

FTP_ITC.1 Доверенный канал передачи между ФБО

FTP_ITC.1.1

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

FTP_ITC.1.2

ФБО должны позволить [выбор:

ФБО,

другой доверенный продукт ИТ

] инициировать связь через доверенный канал.

FTP_ITC.1.3

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

Зависимости:

отсутствуют.

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

Оценщик должен подтвердить, что "Справка ОО", "Аннотация ОО" и "Описание ОО" не противоречат друг другу.

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.

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.

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.

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

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

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.

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

Оценщик должен подтвердить, что "Краткая спецификация ОО" не противоречит "Аннотации ОО" и "Описанию ОО".

Зависимости:

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.

Зависимости:

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

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

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

Оценщик должен провести контроль соответствия всего представления реализации описанию проекта ОО, включая:

а) контроль исходного состояния ОО;

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

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

г) контроль полноты представления реализации на уровне функциональных объектов;

д) контроль отсутствия избыточности представления реализации на уровне функциональных объектов;

е) контроль связей функциональных объектов представления реализации по управлению;

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.

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

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

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

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

AGD_OPE1.1E

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

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

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

Зависимости:

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.

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

Элементы действий разработчика

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

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

Элементы действий разработчика

ALC_DEL.1.1D

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

ALC_DEL.1.2D

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

Элементы содержания и представления документированных материалов

ALC_DEL.1.1C

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

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

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

а) обеспечение точного соответствия между ОО, полученным потребителем, и прошедшим оценку ОО;

б) избежание/обнаружение какой-либо подделки актуальной версии ОО;

в) предотвращение поставки фальсифицированной версии ОО;

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

д) избежание/обнаружение перехвата ОО во время поставки;

е) избежание задержки поставки или невыполнения поставки ОО.

Элементы действий оценщика

ALC_DEL.1.1E

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

ALC_DVS.1.1D

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

Элементы содержания и представления документированных материалов

ALC_DVS.1.1C

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

ALC_DVS.1.2C

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

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

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

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

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

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

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

ж) организацию антивирусной защиты;

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

Элементы действий оценщика

ALC_DVS.1.1E

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

ALC_DVS.1.2E

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

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.

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.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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оценщик должен подтвердить влияние (отсутствие влияния) обновлений на безопасность ОО.