Cartelta

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

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

Change-detection

Browser-view

Weekly+

Alerts

SOC/SIEM

Получить консультацию 11.6.1

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

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

Мониторинг «как у клиента»: сравнение контента и заголовков с эталоном, алерты и реакция.

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

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

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

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

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

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

Атаки на клиентской стороне (веб-скимминг, formjacking, magecart-атаки) происходят уже после выдачи страницы. Перехваты на уровне CDN/3rd-party/браузерных расширений не видны WAF и FIM. Требование 11.6.1 закрывает этот разрыв: обнаружение изменений именно в том виде, как их видит пользователь.

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

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

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

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

Подход	Плюсы	Минусы
Browser-sensor	Видит реальный DOM и заголовки в пользовательских сессиях, обрабатывает действия от 3rd-party/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) выше — увеличивайте частоту (например, до почасовой/поминутной).

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