Обзор Профиля защиты прикладного программного обеспечения. Методический документ Банка России

Руслан Рахметов, Security Vision

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

В частности, данное требование сформулировано в следующих нормативных актах (в уже действующих и в тех, которые вступят в силу в ближайшее время) Банка России:

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

• Положение Банка России от 20 апреля 2021 г. № 757-П «Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций». В пункте 1.8 для некредитных финансовых организаций, реализующих усиленный и стандартный уровни защиты информации, указано аналогичное вышеуказанному требование по применению прикладного программного обеспечения, распространяемого клиентам или доступного к взаимодействию через сеть интернет, прошедшего сертификацию или оценку соответствия по ОУД 4. При этом, оценка соответствия прикладного ПО может проводиться как самостоятельно, так и с привлечением внешней проверяющей организации.

• Положение Банка России от 17 апреля 2019 г. № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента». В пункте 4.1 для кредитных организаций также указано аналогичное требование (но с некоторыми особенностями, которые будут, по всей вероятности, устранены через изменения), а в пункте 4.2 оговорено, что для проведения анализа кредитные организации должны привлекать организации, имеющие лицензию на осуществление деятельности по технической защите конфиденциальной информации.
  

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

Очевидно, что в текущих реалиях программное обеспечение (особенно в части взаимодействия с клиентами) очень часто изменяется. Проведение сертификации весьма проблематично, увеличит сроки выхода новых версий ПО и, по сути, приведет к потере конкурентоспособности как за счет долгих сроков вывода новых продуктов, так и за счет стоимости сертификации. С этой точки зрения (экономической эффективности) интересен опубликованный в июне 2021 года на Федеральном портале проектов нормативных правовых актов проект Указания Банка России «О внесении изменений в Положение Банка России от 17 апреля 2019 года № 683-П…», в котором одно из изменений касается возможности проведения оценки соответствия самостоятельно. Вероятно, аналогичные изменения и подходы будут «стандартизированы» по всем актам Банка России и позволят организациям выстраивать безопасную разработку целиком внутри себя.

В актах указана оценка соответствия в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности», но общий характер ГОСТ и потребность в определении требований, учитывающих специфику финансовой сферы, сподвигло Банк России к разработке  методического документа – профиля защиты (что и предусмотрено ГОСТ Р ИСО/МЭК 15408-3-2013, где в введении указано: «Компоненты доверия к безопасности, которые определены в ИСО/МЭК 15408-3, являются основой для требований доверия к безопасности, отражаемых в профиле защиты (ПЗ)»). Полное название методического документа – «ПРОФИЛЬ ЗАЩИТЫ прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций» (далее – Профиль защиты) и, по всей видимости, он будет одним из основных методических документов для подразделений организаций финансово-кредитной сферы, обеспечивающих безопасную разработку.

Профиль защиты - достаточно объемный документ (155 страниц). Рассмотрим его основные разделы. 

Из общих положений явно следует применение данного документа для сертификации и оценки соответствия как самими организациями кредитно-финансовой сферы, так и привлекаемыми внешними организациями. Указывается на то, что документ учитывает положения национальных стандартов Российской Федерации (хотелось бы отдельно отметить указанные в документе ГОСТ Р 57580.1-2017 и ГОСТ 34.603-92), отраслевых рекомендаций (РС БР ИББС-2.6-2014) и нормативных актов Банка России – в общем, разработчики документа постарались передать всю специфику требований мегарегулятора к своим поднадзорным.

Из введения следует, что документ разработан для оценочного уровня доверия 4 (ОУД4), усиленного рядом компонент. Хотелось бы отметить, что в 719-П и в проекте изменений 683-П для организаций поменьше (например, для не являющихся системно значимыми) предусмотрен ОУД5 – возможно, скоро данный документ получит обновление. Также в данном разделе указаны термины и определения, соглашения (операции «уточнение», «выбор», «назначение» и «итерация» над компонентами требований безопасности) и аннотация объекта оценки.

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

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

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

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

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

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

Следующий раздел Профиля защиты посвящен соответствую внешним документам (стандартам серии 15408, РС БР ИББС-2.6-2014) и так и называется - «Утверждение о соответствии». Особое внимание можно уделить подразделу 3.5, в котором идет речь о строгом соответствии документов организации (разработанных, в свою очередь, на базе Профиля защиты) всем требованиям Профиля защиты, но не ограничиваясь (т.е. документы организации могут и должны быть шире, повышая детализацию и учитывая специфику прикладного программного обеспечения, применяемого в организации). В случае, если строгое соответствие невозможно, должно быть обоснование, в соответствии с риск-ориентированным подходом, как обработан соответствующий риск нарушения информационной безопасности.

В следующем разделе «Определение проблемы безопасности» идет разбор угроз, которые обязательно нужно рассмотреть:

• угроза НСД к информации при наличии уязвимостей на стороне организации, за счет доступа к оборудованию;

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

• угроза воздействия на ПО на стороне клиента, в основном за счет применения вредоносного ПО.
  

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

Рис. 1. Матрица соответствия целей угрозам и политикам

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

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

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

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

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

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

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

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

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

Перечислим направления (классы), которым посвящены функциональные требования безопасности:

• Аудит безопасности

• Защита данных пользователя

• Идентификация и аутентификация

• Управление безопасностью

• Приватность

• Защита ФБО

• Доступ к ОО

• Доверенный маршрут/канал
  

Классы доверия к безопасности ОО (взяты из ГОСТ Р ИСО/МЭК 15408-3-2013):

• Оценка задания по безопасности

• Разработка

• Руководства

• Поддержка жизненного цикла

• Тестирование

• Оценка уязвимостей

• Поддержка доверия
  

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