Куда я попал?
Framework № PCI DSS 4.0 от 01.03.2022
Payment Card Industry Data Security Standard
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 (RU)":
Requirement 6.4.3
6.4.3
Определенные Требования к Подходу:
Все скрипты страницы оплаты, которые загружаются и выполняются в браузере пользователя, управляются следующим образом:
Определенные Требования к Подходу:
Все скрипты страницы оплаты, которые загружаются и выполняются в браузере пользователя, управляются следующим образом:
- Реализован метод для подтверждения того, что каждый сценарий авторизован.
- Реализован метод для обеспечения целостности каждого скрипта.
- Ведется инвентаризация всех сценариев с письменным обоснованием того, почему каждый из них необходим
Цель Индивидуального подхода:
Несанкционированный код не может присутствовать на странице оплаты, поскольку он отображается в браузере потребителя.
Примечания по применению:
Это требование применяется ко всем скриптам, загруженным из среды объекта, а также к скриптам, загруженным от третьих и четвертых сторон.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Несанкционированный код не может присутствовать на странице оплаты, поскольку он отображается в браузере потребителя.
Примечания по применению:
Это требование применяется ко всем скриптам, загруженным из среды объекта, а также к скриптам, загруженным от третьих и четвертых сторон.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 6.4.3.a Изучить политики и процедуры, чтобы убедиться, что определены процессы для управления всеми скриптами платежных страниц, которые загружаются и выполняются в браузере потребителя, в соответствии со всеми элементами, указанными в этом требовании.
- 6.4.3.b Опросите ответственный персонал и изучите инвентарные записи и системные конфигурации, чтобы убедиться, что все скрипты страницы оплаты, которые загружаются и выполняются в браузере потребителя, управляются в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Скрипты, загружаемые и выполняемые на странице оплаты, могут изменять свою функциональность без ведома субъекта, а также могут иметь функциональность для загрузки дополнительных внешних скриптов (например, реклама и отслеживание, системы управления тегами).
Такие, казалось бы, безобидные скрипты могут быть использованы потенциальными злоумышленниками для загрузки вредоносных скриптов, которые могут считывать и извлекать данные о держателях карт из браузера пользователя.
Обеспечение того, чтобы функциональность всех таких скриптов понималась как необходимая для работы платежной страницы, сводит к минимуму количество скриптов, которые могут быть подделаны.
Обеспечение того, чтобы скрипты были явно авторизованы, снижает вероятность добавления ненужных скриптов на страницу оплаты без соответствующего одобрения руководства.
Использование методов предотвращения несанкционированного доступа к скрипту сведет к минимуму вероятность изменения скрипта для выполнения несанкционированного поведения, такого как удаление данных о владельце карты со страницы оплаты.
Надлежащая практика:
Сценарии могут быть авторизованы с помощью ручных или автоматизированных (например, workflow) процессов.
Если страница оплаты будет загружена во встроенный фрейм (IFRAME), ограничение местоположения, из которого может быть загружена страница оплаты, с помощью Политики безопасности содержимого родительской страницы (CSP) может помочь предотвратить замену страницы оплаты несанкционированным контентом.
Определения:
“Необходимо” для этого требования означает, что проверка субъектом каждого сценария обосновывает и подтверждает, почему это необходимо для функциональности платежной страницы для принятия платежной транзакции
Примеры:
Целостность скриптов может быть обеспечена несколькими различными механизмами, включая, но не ограничиваясь ими:
Целостность субресурсов (SRI), которая позволяет браузеру пользователя проверять, что сценарий не был изменен.
CSP, который ограничивает местоположения, из которых браузер пользователя может загружать скрипт и передавать данные учетной записи.
Проприетарные системы управления скриптами или тегами, которые могут предотвратить выполнение вредоносных скриптов.
Скрипты, загружаемые и выполняемые на странице оплаты, могут изменять свою функциональность без ведома субъекта, а также могут иметь функциональность для загрузки дополнительных внешних скриптов (например, реклама и отслеживание, системы управления тегами).
Такие, казалось бы, безобидные скрипты могут быть использованы потенциальными злоумышленниками для загрузки вредоносных скриптов, которые могут считывать и извлекать данные о держателях карт из браузера пользователя.
Обеспечение того, чтобы функциональность всех таких скриптов понималась как необходимая для работы платежной страницы, сводит к минимуму количество скриптов, которые могут быть подделаны.
Обеспечение того, чтобы скрипты были явно авторизованы, снижает вероятность добавления ненужных скриптов на страницу оплаты без соответствующего одобрения руководства.
Использование методов предотвращения несанкционированного доступа к скрипту сведет к минимуму вероятность изменения скрипта для выполнения несанкционированного поведения, такого как удаление данных о владельце карты со страницы оплаты.
Надлежащая практика:
Сценарии могут быть авторизованы с помощью ручных или автоматизированных (например, workflow) процессов.
Если страница оплаты будет загружена во встроенный фрейм (IFRAME), ограничение местоположения, из которого может быть загружена страница оплаты, с помощью Политики безопасности содержимого родительской страницы (CSP) может помочь предотвратить замену страницы оплаты несанкционированным контентом.
Определения:
“Необходимо” для этого требования означает, что проверка субъектом каждого сценария обосновывает и подтверждает, почему это необходимо для функциональности платежной страницы для принятия платежной транзакции
Примеры:
Целостность скриптов может быть обеспечена несколькими различными механизмами, включая, но не ограничиваясь ими:
Целостность субресурсов (SRI), которая позволяет браузеру пользователя проверять, что сценарий не был изменен.
CSP, который ограничивает местоположения, из которых браузер пользователя может загружать скрипт и передавать данные учетной записи.
Проприетарные системы управления скриптами или тегами, которые могут предотвратить выполнение вредоносных скриптов.
NIST Cybersecurity Framework (EN):
DE.CM-7
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.