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

(утв. Банком России)

ЦЕНТРАЛЬНЫЙ БАНК РОССИЙСКОЙ ФЕДЕРАЦИИ

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

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

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

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

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

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

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

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

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

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

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

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

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

При этом ОО:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1. Угрозы

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

Угроза-1

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

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

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

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

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

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

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

Угроза-2

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

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

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

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

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

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

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

Угроза-3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• администраторам безопасности ППО АС;
• администраторам ППО АС;
• иным лицам по согласованию с администратором безопасности ППО АС;
• пользователям АС только при реализации безопасных механизмов автоматизированного восстановления (например, с использованием альтернативного канала связи);
• использовать безопасные механизмы автоматизированного восстановления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В связи с этим требования настоящего раздела могут использоваться в целях реализации требования доверия к безопасности (ТДБ) ОО (п. 7.2. настоящего документа) в случаях, когда финансовая организация либо разработчик ОО (далее при совместном упоминании — Разработчик) реализует документированный безопасный жизненный цикл ОО, основанный на современных гибких практиках разработки, тестирования и внедрения ОО, в основе которых лежат различные методологии безопасного жизненного цикла программных продуктов (например, такие международные и общепринятые в рамках соответствующих сообществ методологии, как SDLC <1>, DevSecOps <2>, BSIMM <3>, OWASP <4> и др.).

<1> Software development lifecycle.

<2> Software development, security, IT operations.

<3> Building Security in Maturity Model.

<4> Open Web Application Security Project.

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

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

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

• результаты контрольных мероприятий по ИБ;
• результаты проведенных контролей безопасности (security controls);
• результаты работ по анализу уязвимостей и тестированию защищенности ОО при подтвержденном общем соответствии документированному процессу безопасной разработки.

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

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

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

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

<5> Федеральный закон от 26 июля 2017 г. № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».

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

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

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

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

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

• состав команды, участвующей в реализации безопасного жизненного цикла ОО, должен иметь необходимые компетенции <8>, в том числе предусматривать наличие таких специализированных ролей, как ИТ-архитектор, аналитик ИБ (специалист по безопасности прикладного программного обеспечения и приложений; также встречаются наименования «Application Security», «AppSec»), DevOps-инженеры и тестировщики, а также Security Champion <9> — член команды с высокой осведомленностью в вопросах обеспечения информационной безопасности, имеющий определенные компетенции в области безопасности прикладного программного обеспечения и принципов безопасной разработки;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Задача «Организационная подготовка» — в данной задаче определяются требования по подготовке и организации процесса безопасного жизненного цикла ОО, а также требования к организационной модели команды, ролевому составу, ответственности, компетенции и обучению;
• Задача «Формирование требований к ОО» — в данной задаче формулируются функциональные и нефункциональные требования к разрабатываемому ОО, включая требования к обеспечению информационной безопасности ОО;
• Задача «Архитектура и проектирование ОО» — в данной задаче разрабатываются архитектурное решение и проектное описание ОО;
• Задача «Реализация (разработка) ОО» — в данной задаче осуществляются непосредственное кодирование и процесс реализации ОО;
• Задача «Тестирование ОО» — в данной задаче проводится проверка реализации ОО и качества его исполнения на соответствие функциональным и нефункциональным требованиям, включая требования к обеспечению информационной безопасности ОО;
• Задача «Подготовка и перенос ОО в промышленную эксплуатацию» — в данной задаче требуется проверить на готовность ОО к выполнению требований ИБ и переносу в промышленную эксплуатацию, корректно перенести версию ОО в среду эксплуатации;
• Задача «Эксплуатация и сопровождение ОО» — в данной задаче реализуются мониторинг, обновление, сопровождение и сопутствующая эксплуатация ОО;
• Задача «Вывод из эксплуатации ОО» — в данной задаче производится снятие с эксплуатации ОО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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