Cartelta

PCI DSS 11.6.1: обнаружение изменений платёжной страницы

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

Обнаружение изменений

На стороне конечного пользователя

Регулярные проверки

Уведомления

SOC/SIEM

Запросить консультацию по требованию 11.6.1

Скачать чек-лист (PDF)

Схема мониторинга изменений платёжной страницы

Мониторинг на стороне конечного пользователя: сравнение контента и заголовков с эталоном, уведомления и регламент реагирования.

Что именно требует 11.6.1

Обнаруживать неавторизованные изменения платёжной страницы в том виде, как её получает браузер клиента (HTML, JS, ресурсы, HTTP-заголовки).

Частота: не реже 1 раза в неделю; при повышенном риске — чаще, согласно TAR.

Генерировать уведомление уполномоченному персоналу и обеспечивать своевременную реакцию.

Документировать инциденты и принятые меры; хранить артефакты для аудита.

Почему это важно

Клиентские атаки (client-side attacks) — веб-скимминг (web skimming), внедрение в формы (formjacking), атаки типа Magecart — происходят после выдачи страницы. Перехваты на уровне CDN, сторонних скриптов и браузерных расширений не обнаруживаются средствами WAF и FIM. Требование 11.6.1 устраняет этот разрыв: обнаружение изменений именно в том виде, в каком их получает конечный пользователь.

Как внедрить мониторинг изменений

Идентификация платёжных и предчекаутных шагов, на которых вводятся реквизиты или персональные данные.
Определение эталонной модели страницы (контент/заголовки) и источников разрешённых скриптов.
Развёртывание механизма обнаружения изменений через браузерный сенсор.
Интеграция оповещений в рабочие каналы (SIEM/SOC, e-mail); определение SLO на реакцию.

Формализация процедуры: классификация события, расследование, фиксация причин, откат/исправление.

Подходы реализации: плюсы и минусы

Подход	Плюсы	Минусы
Браузерный сенсор (browser-sensor)	Анализ реального DOM и заголовков в пользовательских сессиях, фиксация влияния сторонних скриптов, ISP и браузерных расширений.	Необходимость размещения лёгкого клиентского скрипта и контроля производительности.
Внешний сканер (external crawler)	Отсутствие необходимости размещения кода на стороне клиента, быстрое развёртывание; гибкое планирование частоты проверок.	Не обнаруживает сценарии, проявляющиеся только у реальных пользователей в определённых сегментах или регионах.
Гибридный подход	Максимальное покрытие сценариев при приемлемой стоимости.	Необходимость координации двух каналов сигналов и ведения единой отчётности.

Что будет проверять аудитор

Артефакты

Журнал срабатываний/оповещений, выгрузки сравнения «эталон ↔ текущая страница».
Регламент реакции и доказательства выполнения: кто, когда, что сделал.
План/лог частоты запусков (≥ еженедельно) и правило усиления по TAR.

Интервью/наблюдение

Как формируется эталон и кто его утверждает?
Какие каналы уведомлений и SLO на реакцию?
Как учитываются регион/UserAgent (AB-тесты, CDN, 3rd-party)?

Делайте / не делайте

Делайте

Сверка HTML/JS/заголовков на стороне конечного пользователя, а не только файлов на сервере.

Проверка не реже одного раза в неделю и чаще по TAR; фиксация событий и мер реагирования.

Интеграция уведомлений в SOC/SIEM, ведение регламента реагирования (runbook) и соблюдение SLO.

Покрытие платёжных и околочекаутных шагов (итоговая страница, доставка, промокоды, скидки и т. п.).

Не делайте

Использование только FIM: контролируются билд-артефакты, а не то, что фактически загружается в браузер.
Ограничение ежеквартальным аудитом — требование 11.6.1 предусматривает регулярный мониторинг.
Использование исключительно CSP-отчётов или WAF — данных инструментов недостаточно для обнаружения изменений (change detection).
Мониторинг исключительно staging-среды или единственной локации/user-agent.

FAQ по 11.6.1

Самостоятельно — нет. Требование 11.6.1 предусматривает обнаружение изменений в том виде, в каком страницу получает браузер конечного пользователя. FIM может выступать дополнительным уровнем контроля, однако не заменяет проверку на стороне клиента.

Не реже одного раза в неделю. При повышенной оценке рисков (TAR) рекомендуется увеличение частоты проверок (до почасовой или поминутной).

Логи срабатываний и оповещений, регламенты (кто реагирует и как), доказательства устранения, выгрузки сравнения «эталон ↔ текущая страница», а также периодичность запусков.