Куда я попал?
SECURITM это SGRC система, ? автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014

Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения

Р. 7 п. 8 п.п. 6

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

Список требований

Похожие требования

ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВРВ.17.2
ВРВ.17.2 Применение риск-ориентированной модели для установления лимитов по параметрам финансовых (банковских) операций, в том числе переводов денежных средств, при использовании каналов дистанционного обслуживания;
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 2.2.6
2.2.6
Defined Approach Requirements: 
System security parameters are configured to prevent misuse. 

Customized Approach Objective:
System components cannot be compromised because of incorrect security parameter configuration. 

Defined Approach Testing Procedures:
  •  2.2.6.a Examine system configuration standards to verify they include configuring system security parameters to prevent misuse.
  •  2.2.6.b Interview system administrators and/or security managers to verify they have knowledge of common security parameter settings for system components.
  •  2.2.6.c Examine system configurations to verify that common security parameters are set appropriately and in accordance with the system configuration standards. 
Purpose:
Correctly configuring security parameters provided in system components takes advantage of the capabilities of the system component to defeat malicious attacks. 

Good Practice:
System configuration standards and related processes should specifically address security settings and parameters that have known security implications for each type of system in use. 
For systems to be configured securely, personnel responsible for configuration and/or administering systems should be knowledgeable in the specific security parameters and settings that apply to the system. Considerations should also include secure settings for parameters used to access cloud portals. 

Further Information: 
Refer to vendor documentation and industry references noted in Requirement 2.2.1 for information about applicable security parameters for each type of system. 
Requirement 6.4.3
6.4.3
Defined Approach Requirements: 
All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
  • A method is implemented to confirm that each script is authorized.
  • A method is implemented to assure the integrity of each script.
  • An inventory of all scripts is maintained with written justification as to why each is necessary 
Customized Approach Objective:
Unauthorized code cannot be present in the payment page as it is rendered in the consumer’s browser. 

Applicability Notes:
This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:
  • 6.4.3.a Examine policies and procedures to verify that processes are defined for managing all payment page scripts that are loaded and executed in the consumer’s browser, in accordance with all elements specified in this requirement. 
  • 6.4.3.b Interview responsible personnel and examine inventory records and system configurations to verify that all payment page scripts that are loaded and executed in the consumer’s browser are managed in accordance with all elements specified in this requirement. 
Purpose:
Scripts loaded and executed in the payment page can have their functionality altered without the entity’s knowledge and can also have the functionality to load additional external scripts (for example, advertising and tracking, tag management systems). 
Such seemingly harmless scripts can be used by potential attackers to upload malicious scripts that can read and exfiltrate cardholder data from the consumer browser. 
Ensuring that the functionality of all such scripts is understood to be necessary for the operation of the payment page minimizes the number of scripts that could be tampered with. 
Ensuring that scripts have been explicitly authorized reduces the probability of unnecessary scripts being added to the payment page without appropriate management approval. 
Using techniques to prevent tampering with the script will minimize the probability of the script being modified to carry out unauthorized behavior, such as skimming the cardholder data from the payment page. 

Good Practice:
Scripts may be authorized by manual or automated (e.g., workflow) processes. 
Where the payment page will be loaded into an inline frame (IFRAME), restricting the location that the payment page can be loaded from, using the parent page’s Content Security Policy (CSP) can help prevent unauthorized content being substituted for the payment page. 

Definitions:
“Necessary” for this requirement means that the entity’s review of each script justifies and confirms why it is needed for the functionality of the payment page to accept a payment transaction 

Examples:
The integrity of scripts can be enforced by several different mechanisms including, but not limited to:
  • Sub-resource integrity (SRI), which allows the consumer browser to validate that a script has not been tampered with.
  • A CSP, which limits the locations the consumer browser can load a script from and transmit account data to.
  • Proprietary script or tag-management systems, which can prevent malicious script execution. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.1.3
A.14.1.3 Защита транзакций прикладных сервисов 
Мера обеспечения информационной безопасности: Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений 
A.14.1.2
A.14.1.2 Обеспечение безопасности прикладных сервисов, предоставляемых с использованием сетей общего пользования 
Мера обеспечения информационной безопасности: Информация, используемая в прикладных сервисах и передаваемая по сетям общего пользования, должна быть защищена от мошеннической деятельности, оспаривания договоров, а также несанкционированного раскрытия и модификации 
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 7 п.п. 3
7.3. Участники СБП, ОПКЦ СБП и ОУИО СБП должны определить во внутренних документах состав и правила применения технологических мер защиты информации, используемых для контроля целостности и подтверждения подлинности электронных сообщений и информационных сообщений (при их наличии), при осуществлении перевода денежных средств с использованием сервиса быстрых платежей на этапах формирования (подготовки), обработки, передачи и хранения электронных сообщений и информационных сообщений (при их наличии).
Участники СБП, ОПКЦ СБП и ОУИО СБП должны применять технологические меры защиты информации, используемые для контроля целостности и подтверждения подлинности электронных сообщений и информационных сообщений на этапах их формирования (подготовки), обработки, передачи и хранения (при их наличии).
П. 16.1
16.1. Участник СБП - банк плательщика должен осуществлять:
  • выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, установленным Банком России в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - признаки осуществления переводов денежных средств без согласия клиента), в рамках реализуемой им системы управления рисками при осуществлении переводов денежных средств с использованием сервиса быстрых платежей;
  • приостановление в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ исполнения распоряжения в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, с учетом информации об уровне риска операции без согласия клиента (далее - индикатор уровня риска операции), включенной в электронное сообщение, полученной от ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, содержащей в том числе информацию об индикаторе уровня риска операции, сформированном участником СБП - банком получателя;
  • формирование индикатора уровня риска операции на основе оценки рисков операций в рамках реализуемой участником СБП - банком плательщика системы управления рисками и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, - в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.4.3
6.4.3
Определенные Требования к Подходу:
Все скрипты страницы оплаты, которые загружаются и выполняются в браузере пользователя, управляются следующим образом:
  • Реализован метод для подтверждения того, что каждый сценарий авторизован.
  • Реализован метод для обеспечения целостности каждого скрипта.
  • Ведется инвентаризация всех сценариев с письменным обоснованием того, почему каждый из них необходим
Цель Индивидуального подхода:
Несанкционированный код не может присутствовать на странице оплаты, поскольку он отображается в браузере потребителя.

Примечания по применению:
Это требование применяется ко всем скриптам, загруженным из среды объекта, а также к скриптам, загруженным от третьих и четвертых сторон.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:
  • 6.4.3.a Изучить политики и процедуры, чтобы убедиться, что определены процессы для управления всеми скриптами платежных страниц, которые загружаются и выполняются в браузере потребителя, в соответствии со всеми элементами, указанными в этом требовании.
  • 6.4.3.b Опросите ответственный персонал и изучите инвентарные записи и системные конфигурации, чтобы убедиться, что все скрипты страницы оплаты, которые загружаются и выполняются в браузере потребителя, управляются в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Скрипты, загружаемые и выполняемые на странице оплаты, могут изменять свою функциональность без ведома субъекта, а также могут иметь функциональность для загрузки дополнительных внешних скриптов (например, реклама и отслеживание, системы управления тегами).
Такие, казалось бы, безобидные скрипты могут быть использованы потенциальными злоумышленниками для загрузки вредоносных скриптов, которые могут считывать и извлекать данные о держателях карт из браузера пользователя.
Обеспечение того, чтобы функциональность всех таких скриптов понималась как необходимая для работы платежной страницы, сводит к минимуму количество скриптов, которые могут быть подделаны.
Обеспечение того, чтобы скрипты были явно авторизованы, снижает вероятность добавления ненужных скриптов на страницу оплаты без соответствующего одобрения руководства.
Использование методов предотвращения несанкционированного доступа к скрипту сведет к минимуму вероятность изменения скрипта для выполнения несанкционированного поведения, такого как удаление данных о владельце карты со страницы оплаты.

Надлежащая практика:
Сценарии могут быть авторизованы с помощью ручных или автоматизированных (например, workflow) процессов.
Если страница оплаты будет загружена во встроенный фрейм (IFRAME), ограничение местоположения, из которого может быть загружена страница оплаты, с помощью Политики безопасности содержимого родительской страницы (CSP) может помочь предотвратить замену страницы оплаты несанкционированным контентом.

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

Примеры:
Целостность скриптов может быть обеспечена несколькими различными механизмами, включая, но не ограничиваясь ими:
Целостность субресурсов (SRI), которая позволяет браузеру пользователя проверять, что сценарий не был изменен.
CSP, который ограничивает местоположения, из которых браузер пользователя может загружать скрипт и передавать данные учетной записи.
Проприетарные системы управления скриптами или тегами, которые могут предотвратить выполнение вредоносных скриптов.
Requirement 2.2.6
2.2.6
Определенные Требования к Подходу:
Параметры безопасности системы настроены для предотвращения неправильного использования.

Цель Индивидуального подхода:
Системные компоненты не могут быть скомпрометированы из-за неправильной настройки параметров безопасности.

Определенные Процедуры Тестирования Подхода:
  • 2.2.6.a Изучите стандарты конфигурации системы, чтобы убедиться, что они включают настройку параметров безопасности системы для предотвращения неправильного использования.
  • 2.2.6.b Опросите системных администраторов и/или менеджеров по безопасности, чтобы убедиться, что они знают общие настройки параметров безопасности для системных компонентов.
  • 2.2.6.c Изучите конфигурации системы, чтобы убедиться, что общие параметры безопасности установлены надлежащим образом и в соответствии со стандартами конфигурации системы.
Цель:
Правильная настройка параметров безопасности, предоставляемых в системных компонентах, использует возможности системного компонента для предотвращения вредоносных атак.

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

Дополнительная информация:
Обратитесь к документации поставщика и отраслевым справочникам, указанным в Требовании 2.2.1, для получения информации о применимых параметрах безопасности для каждого типа системы.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 4 п.1
4.1. Операторы услуг информационного обмена должны обеспечивать защиту информации при оказании операторам по переводу денежных средств услуг информационного обмена на основании договоров в отношении следующих операций:
  • осуществление переводов денежных средств с использованием электронных средств платежа на основании электронных сообщений клиентов операторов по переводу денежных средств;
  • осуществление переводов денежных средств с использованием электронных средств платежа на основании электронных сообщений иностранных поставщиков платежных услуг.
Глава 2 п. 9
2.9. Технологические меры, указанные в пункте 2.8 настоящего Положения, должны обеспечивать реализацию:
  • механизмов идентификации и аутентификации клиента оператора по переводу денежных средств при формировании (подготовке) и при подтверждении им электронных сообщений в соответствии с требованиями законодательства Российской Федерации;
  • механизмов двухфакторной аутентификации клиента оператора по переводу денежных средств при совершении им действий в целях осуществления переводов денежных средств;
  • механизмов и (или) протоколов формирования и обмена электронными сообщениями, обеспечивающих защиту электронных сообщений от искажения, фальсификации, переадресации, несанкционированного ознакомления и (или) уничтожения, ложной авторизации, в том числе аутентификацию входных электронных сообщений;
  • взаимной (двухсторонней) аутентификации участников обмена средствами вычислительной техники операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов услуг информационного обмена, операторов услуг платежной инфраструктуры, клиентов операторов по переводу денежных средств;
  • возможности использования клиентом оператора по переводу денежных средств независимых программных сред для формирования (подготовки) и подтверждения электронных сообщений;
  • возможности контроля клиентом оператора по переводу денежных средств реквизитов распоряжений о переводе денежных средств при формировании (подготовке) электронных сообщений (пакета электронных сообщений) и их подтверждении;
  • возможности установления временных ограничений на выполнение клиентом оператора по переводу денежных средств подтверждения электронных сообщений;
  • функций передаваемого клиенту оператора по переводу денежных средств программного обеспечения, используемого при осуществлении переводов денежных средств и предназначенного для установки на мобильные устройства клиента оператора по переводу денежных средств, связанных с выявлением модификации мобильного устройства клиента оператора по переводу денежных средств с использованием недекларируемых возможностей, в том числе деактивации (отключения) механизма разграничения доступа (далее - недекларируемая модификация мобильного устройства клиента), а также уведомлением клиента оператора по переводу денежных средств о случаях недекларируемой модификации мобильного устройства клиента с указанием рисков использования такого устройства (при наличии технической возможности).
Глава 6 п. 2
6.2. ПКЦ при предоставлении услуг платежного клиринга должен обеспечивать защиту информации при осуществлении следующих операций:
  • выполнение процедур приема к исполнению электронных сообщений операторов по переводу денежных средств, включая проверку соответствия электронных сообщений операторов по переводу денежных средств установленным требованиям, определение достаточности денежных средств для исполнения электронных сообщений операторов по переводу денежных средств и определение платежных клиринговых позиций;
  • передача РЦ для исполнения электронных сообщений ПКЦ, принятых электронных сообщений операторов по переводу денежных средств;
  • направление операторам по переводу денежных средств извещений (подтверждений), касающихся приема к исполнению электронных сообщений операторов по переводу денежных средств, а также передача извещений (подтверждений), касающихся исполнения электронных сообщений операторов по переводу денежных средств.
Глава 6 п. 1
6.1. Операторы услуг платежной инфраструктуры, осуществляющие деятельность операционных центров (далее - ОЦ), при предоставлении операционных услуг должны обеспечивать защиту информации при осуществлении обмена электронными сообщениями между операторами по переводу денежных средств, между операторами по переводу денежных средств и их клиентами, операторами услуг платежной инфраструктуры, осуществляющими деятельность платежных клиринговых центров (далее - ПКЦ), операторами услуг платежной инфраструктуры, осуществляющими деятельность расчетных центров (далее - РЦ), между ПКЦ и РЦ.
Глава 3 п.2
3.2. Банковские платежные агенты, осуществляющие операции платежного агрегатора, должны обеспечивать защиту информации в процессе формирования (подготовки) электронных сообщений при обеспечении приема электронных средств платежа юридическими лицами, индивидуальными предпринимателями и иными лицами, указанными в части 13 статьи 141 Федерального закона № 161-ФЗ (Собрание законодательства Российской Федерации, 2011, № 27, ст. 3872; 2019, № 27, ст. 3538), при участии в переводе денежных средств в пользу юридических лиц, индивидуальных предпринимателей и иных лиц, указанных в части 13 статьи 141 Федерального закона № 161-ФЗ, по операциям с использованием электронных средств платежа.
Глава 1 п. 4
1.4. Операторы по переводу денежных средств, банковские платежные агенты (субагенты), операторы услуг информационного обмена, операторы услуг платежной инфраструктуры должны обеспечивать регистрацию результатов совершения следующих действий, связанных с осуществлением доступа к защищаемой информации:
  • идентификация, аутентификация и авторизация клиентов операторов по переводу денежных средств при совершении действий в целях осуществления переводов денежных средств;
  • прием электронных сообщений от клиентов операторов по переводу денежных средств;
  • прием (передача) электронных сообщений при взаимодействии операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов услуг информационного обмена, операторов услуг платежной инфраструктуры при осуществлении переводов денежных средств, в том числе для удостоверения права клиентов операторов по переводу денежных средств распоряжаться денежными средствами и для учета результатов переводов денежных средств;
  • реализация мер, направленных на проверку правильности формирования (подготовки) электронных сообщений (двойной контроль), применяемых в соответствии с подпунктом 1.9 пункта 1 приложения 1 к настоящему Положению;
  • осуществление доступа работников к защищаемой информации и осуществление действий клиентами операторов по переводу денежных средств с защищаемой информацией, выполняемых с использованием автоматизированных систем, программного обеспечения.
Регистрации подлежат следующие данные о действиях, выполняемых работниками с использованием автоматизированных систем, программного обеспечения:
  • дата (день, месяц, год) и время (часы, минуты, секунды) совершения работником действий с защищаемой информацией;
  • присвоенный работнику идентификатор, позволяющий установить работника в автоматизированной системе, программном обеспечении;
  • код, соответствующий технологическому участку;
  • результат совершения работником действия с защищаемой информацией (успешно или неуспешно);
  • информация, используемая для идентификации устройств, при помощи которых либо в отношении которых осуществлен доступ к автоматизированной системе, программному обеспечению в целях совершения работником действий с защищаемой информацией.
Регистрации подлежат следующие данные о действиях, выполняемых клиентами операторов по переводу денежных средств с использованием автоматизированных систем, программного обеспечения:
  • дата (день, месяц, год) и время (часы, минуты, секунды) совершения клиентом оператора по переводу денежных средств действий с защищаемой информацией;
  • присвоенный клиенту оператора по переводу денежных средств идентификатор, позволяющий установить клиента оператора по переводу денежных средств в автоматизированной системе, программном обеспечении; код, соответствующий технологическому участку;
  • результат совершения клиентом оператора по переводу денежных средств действия с защищаемой информацией (успешно или неуспешно);
  • информация, используемая для идентификации устройств, при помощи которых либо в отношении которых осуществлен доступ к автоматизированной системе, программному обеспечению в целях совершения клиентом оператора по переводу денежных средств действий с защищаемой информацией.
Положение Банка России № 757-П от 20.04.2021 "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций":
1.10.5.
1.10.5. Технология обработки защищаемой информации, применяемая при осуществлении финансовой операции, учете результатов ее осуществления (при наличии учета), должна обеспечивать выполнение следующих мероприятий:
  • проверку соответствия (сверку) выходных электронных сообщений соответствующим входным электронным сообщениям;
  • проверку соответствия (сверку) результатов осуществления финансовых операций информации, содержащейся в электронных сообщениях;
  • направление клиентам некредитных финансовых организаций уведомлений об осуществлении финансовых операций в случае, когда такое уведомление предусмотрено законодательством Российской Федерации, регулирующим деятельность некредитных финансовых организаций, или договором.
  • Некредитные финансовые организации должны реализовывать механизмы подтверждения принадлежности клиенту адреса электронной почты, на который некредитной финансовой организацией направляются уведомления о совершаемых финансовых операциях, в том числе при предоставлении клиентам справок (выписок) по финансовым операциям.
1.10.3.
1.10.3. Технология обработки защищаемой информации, применяемая при формировании (подготовке), передаче и приеме электронных сообщений, должна обеспечивать выполнение следующих мероприятий:
  • проверку правильности формирования (подготовки) электронных сообщений (двойной контроль);
  • проверку правильности заполнения полей электронного сообщения и прав владельца электронной подписи (входной контроль);
  • контроль дублирования электронного сообщения;
  • структурный контроль электронных сообщений;
  • защиту, в том числе криптографическую, защищаемой информации при ее передаче по каналам связи.

Связанные защитные меры

Ничего не найдено

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