11.6.1
Определенные требования подхода:
Механизм обнаружения изменений и вмешательства развернут следующим образом:
- Для оповещения персонала о несанкционированных изменениях (включая индикаторы компрометации, изменения, добавления и удаления) в заголовках HTTP и содержимом скриптов платежных страниц, как они получаются браузером потребителя.
- Механизм настроен для оценки получаемых заголовков HTTP и платежных страниц.
- Функции механизма выполняются следующим образом:
- Не реже одного раза в неделю,
- Либо периодически (с частотой, определенной в целевом анализе рисков организации, который проводится в соответствии со всеми элементами, указанными в Требовании 12.3.1).
Цель Индивидуального подхода:
Код для скимминга в электронной коммерции или методы не могут быть добавлены на платежные страницы, как они получаются браузером потребителя, без своевременного оповещения. Меры против скимминга не могут быть удалены с платежных страниц без немедленного оповещения.
Примечания по применимости:
Это требование также применяется к организациям, у которых есть веб-страницы, включающие встроенную страницу/форму платежного процессора (например, одна или несколько встроенных рамок или iframe).
Это требование не применяется к организации для скриптов на встроенной странице/форме платежного процессора, где организация включает страницу/форму платежного процессора на своем веб-сайте.
Скрипты на странице/форме платежного процессора являются ответственностью поставщика платежных услуг (TPSP)/платежного процессора в соответствии с этим требованием.
Цель этого требования не заключается в том, чтобы организация устанавливала программное обеспечение на устройствах или браузерах своих потребителей, а в том, чтобы организация использовала такие методы, как описано в разделе "Примеры" в Руководстве, для предотвращения и обнаружения непредвиденной активности скриптов.
Это требование является лучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью учтено при оценке PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 11.6.1.a Изучите настройки системы, мониторируемые платежные страницы и результаты мониторинговых действий, чтобы проверить использование механизма обнаружения изменений и вмешательства.
- 11.6.1.b Изучите настройки конфигурации, чтобы убедиться, что механизм настроен в соответствии со всеми элементами, указанными в этом требовании.
- 11.6.1.c Если функции механизма выполняются с частотой, определенной организацией, изучите целевой анализ рисков организации для определения частоты, чтобы убедиться, что анализ рисков был выполнен в соответствии со всеми элементами, указанными в Требовании 12.3.1.
- 11.6.1.d Изучите настройки конфигурации и проведите интервью с персоналом, чтобы проверить, что функции механизма выполняются либо:
- Не реже одного раза в семь дней,
- Либо с частотой, определенной в целевом анализе рисков организации, выполненном для этого требования.
Цель:
Многие веб-страницы сейчас полагаются на сбор объектов, включая активный контент (преимущественно JavaScript), с нескольких интернет-ресурсов. Кроме того, содержимое многих веб-страниц определяется с помощью систем управления контентом и систем управления тегами, которые могут быть трудны для мониторинга с использованием традиционных механизмов обнаружения изменений.
Таким образом, единственное место для обнаружения изменений или индикаторов злонамеренной активности — это браузер потребителя, когда страница строится, и все скрипты интерпретируются.
Сравнив текущую версию заголовка HTTP и активный контент платежных страниц, получаемых браузером потребителя, с предыдущими или известными версиями, можно обнаружить несанкционированные изменения, которые могут свидетельствовать о скимминговой атаке или попытке отключить механизм, предназначенный для защиты от скимминга или для его обнаружения.
Кроме того, анализируя известные индикаторы компрометации и элементы или поведение скриптов, типичных для скиммеров, можно генерировать подозрительные оповещения.
Надлежащая практика:
Если организация включает встроенную страницу/форму платежного процессора на своем веб-сайте, она должна ожидать, что платежный процессор предоставит доказательства того, что он соблюдает это требование в соответствии с оценкой PCI DSS платежного процессора и Требованием 12.9.
Примеры:
Механизмы, которые могут обнаруживать и сообщать о изменениях в заголовках и содержимом платежных страниц, могут включать, но не ограничиваться, следующими методами:
- Нарушения Политики безопасности контента (CSP) могут быть сообщены организации с использованием директив report-to или report-uri CSP.
- Изменения самой CSP могут свидетельствовать о вмешательстве.
- Внешний мониторинг систем, которые запрашивают и анализируют полученные веб-страницы (так называемый синтетический пользовательский мониторинг), может обнаружить изменения в JavaScript на платежных страницах и оповестить персонал.
- Встраивание устойчивых к вмешательствам, обнаруживающих вмешательство скриптов в платежную страницу, может оповестить и заблокировать при обнаружении злонамеренного поведения скрипта.
- Обратные прокси-серверы и сети доставки контента могут обнаружить изменения в скриптах и оповестить персонал.
Вышеупомянутый список механизмов не является исчерпывающим, и использование любого из этих механизмов не обязательно является полным механизмом обнаружения и отчетности.
Часто эти механизмы являются подписными или облачными, но также могут быть основаны на индивидуальных и специализированных решениях.
