Коротко
• 11.6.1 требует обнаруживать несанкционированные изменения платежной страницы.
• Важно контролировать DOM, заголовки, сторонние скрипты и процесс обработки алертов.
• File Integrity Monitoring на сервере полезен, но не заменяет проверку того, что получил браузер клиента.
Что именно нужно мониторить
Требование 11.6.1 фокусируется на обнаружении несанкционированных изменений платежных страниц и важных HTTP-заголовков. Ключевой момент: проверять нужно не только файлы на сервере, а фактическое состояние страницы, которое получает браузер клиента.
В e-commerce это означает контроль HTML, DOM, подключённых ресурсов, сторонних скриптов, security-заголовков и изменений, которые могут появиться через CDN, tag manager, CMS или внешний виджет.
Почему FIM не закрывает задачу полностью
File Integrity Monitoring видит изменения файлов, но не всегда видит итоговую страницу после доставки, модификации на CDN, динамические вставки и поведение сторонних скриптов в браузере.
Поэтому FIM может быть дополнительным слоем, но для 11.6.1 нужен контроль страницы как пользовательского артефакта: что реально загрузилось, какие заголовки пришли и чем это отличается от базового состояния.
Частота и реакция
Требование задаёт регулярность проверок и ожидание реакции. На практике частоту лучше привязывать к оценке риска, критичности страницы и темпу изменений.
Не менее важна процедура обработки события: кто получает оповещение, кто классифицирует изменение, где фиксируется причина и как подтверждается исправление.
Какие доказательства нужны аудитору
Аудитор будет смотреть не на сам факт наличия инструмента, а на доказуемость процесса. Нужны логи проверок, история изменений, базовые состояния страниц, правила уведомлений, регламент реакции и примеры обработанных событий.
- контролируемые URL и сценарии оплаты;
- снимки базового состояния DOM и заголовков;
- история срабатываний и решений по ним;
- каналы уведомления и ответственные роли;
- периодичность проверок и её обоснование.
Связь с 6.4.3
11.6.1 не заменяет 6.4.3. Мониторинг изменений отвечает на вопрос «что изменилось», а контроль скриптов — на вопрос «что разрешено и почему». В устойчивой программе оба слоя работают вместе.
Практический порядок действий
1
Определите платежные и околоплатежные страницы.
2
Зафиксируйте базовое состояние DOM, ресурсов и HTTP-заголовков.
3
Настройте регулярное обнаружение изменений и уведомления.
4
Опишите процедуру классификации, реакции и хранения доказательств.
Вопросы по теме
Подходит ли обычный FIM для PCI DSS 11.6.1?
Самостоятельно нет. FIM может помогать, но 11.6.1 требует видеть изменения платежной страницы в том виде, в котором её получает браузер конечного пользователя.
Что должен увидеть аудитор?
Логи проверок, базовое состояние страницы, события изменений, уведомления, регламент реакции, ответственных и подтверждение устранения или принятого решения.