Куда я попал?
Framework № PCI DSS 4.0 от 01.03.2022
Payment Card Industry Data Security Standard (RU)
Requirement 6.4.3
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 8 п.п. 6
7.8.6. Комплекс защитных мер банковского платежного технологического процесса должен предусматривать, в том числе:
- защиту платежной информации от искажения, фальсификации, переадресации, несанкционированного уничтожения, ложной авторизации электронных платежных сообщений;
- доступ работника организации БС РФ только к тем ресурсам банковского платежного технологического процесса, которые необходимы ему для исполнения должностных обязанностей или реализации прав, предусмотренных технологией обработки платежной информации;
- контроль (мониторинг) исполнения установленной технологии подготовки, обработки, передачи и хранения платежной информации;
- аутентификацию входящих электронных платежных сообщений;
- двустороннюю аутентификацию автоматизированных рабочих мест (рабочих станций и серверов), участников обмена электронными платежными сообщениями;
- возможность ввода платежной информации в АБС только для авторизованных пользователей;
- контроль, направленный на исключение возможности совершения злоумышленных действий, в частности двойной ввод, сверка, установление ограничений в зависимости от суммы совершаемых операций;
- восстановление платежной информации в случае ее умышленного (случайного) разрушения (искажения) или выхода из строя средств вычислительной техники;
- сверку выходных электронных платежных сообщений с соответствующими входными и обработанными электронными платежными сообщениями при осуществлении межбанковских расчетов;
- возможность блокирования приема к исполнению распоряжений клиентов;
- доставку электронных платежных сообщений участникам обмена.
Кроме того, в организации БС РФ рекомендуется организовать авторизованный ввод платежной информации в АБС двумя работниками с последующей программной сверкой результатов ввода на совпадение (принцип "двойного управления").
NIST Cybersecurity Framework (RU):
DE.CM-7
DE.CM-7: Выполняется мониторинг неавторизованных персонала, подключений, устройств и программного обеспечения
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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:
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:
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:
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.
NIST Cybersecurity Framework (EN):
DE.CM-7
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.