Коротко
• 11.6.1 требует обнаруживать несанкционированные изменения платежной страницы.
• Важно контролировать DOM, заголовки, сторонние скрипты и процесс обработки алертов.
• File Integrity Monitoring на сервере полезен, но не заменяет проверку того, что получил браузер клиента.
Что именно нужно мониторить
Требование 11.6.1 фокусируется на обнаружении несанкционированных изменений платежных страниц и важных HTTP-заголовков. Ключевой момент: проверять нужно не только файлы на сервере, а фактическое состояние страницы, которое получает браузер клиента.
Для электронной коммерции это означает контроль HTML, DOM, подключённых ресурсов, сторонних скриптов, HTTP-заголовков, влияющих на безопасность, и изменений, которые могут появиться через CDN, менеджер тегов, CMS или внешний виджет.
Почему FIM не закрывает задачу полностью
File Integrity Monitoring видит изменения файлов, но не всегда видит итоговую страницу после доставки, модификации на CDN, динамические вставки и поведение сторонних скриптов в браузере.
Поэтому FIM может быть дополнительным слоем, но для 11.6.1 нужен контроль страницы как пользовательского артефакта: что реально загрузилось, какие заголовки пришли и чем это отличается от базового состояния.
Частота и реакция
Требование задаёт регулярность проверок и ожидание реакции. На практике частоту лучше привязывать к оценке риска, критичности страницы и темпу изменений.
Не менее важна процедура обработки события: кто получает оповещение, кто классифицирует изменение, где фиксируется причина и как подтверждается исправление.
Какие доказательства нужны аудитору
Аудитор будет смотреть не на сам факт наличия инструмента, а на доказуемость процесса. Нужны логи проверок, история изменений, базовые состояния страниц, правила уведомлений, регламент реакции и примеры обработанных событий.
- контролируемые URL и сценарии оплаты;
- снимки базового состояния DOM и заголовков;
- история срабатываний и решений по ним;
- каналы уведомления и ответственные роли;
- периодичность проверок и её обоснование.
Связь с 6.4.3
11.6.1 не заменяет 6.4.3. Мониторинг изменений отвечает на вопрос «что изменилось», а контроль скриптов — на вопрос «что разрешено и почему». В устойчивой программе оба слоя работают вместе.
Как сравнивать страницу без слепого хэширования HTML
Полный HTML часто содержит идентификаторы сессий, локализованный текст, персонализацию и значения, меняющиеся при каждом открытии. Хэш всего документа даёт шум, а слишком широкие исключения способны скрыть важное изменение. Практичнее определить устойчивые сигналы для каждого состояния: источники и содержимое скриптов, загрузчики, назначения запросов, значимые элементы DOM и влияющие на безопасность HTTP-заголовки.
Правило нормализации должно быть версионируемым и проверяемым. Для каждого исключения сохраните причину, владельца и тест, который подтверждает, что правило не скрывает добавление скрипта, смену назначения или ослабление заголовка.
Минимальный контракт события изменения
Событие должно связывать наблюдение с конкретным состоянием страницы и версией эталона. Полезная запись содержит тип изменения, новое значение, время, релизный контекст, владельца, решение и ссылки на доказательства. Полезная временная линия показывает путь от первого наблюдения до закрытия, а не только снимок различий.
- 10:02 — новый источник впервые наблюдается на платёжной странице.
- 10:06 — назначен владелец; в журнале релизов соответствие не найдено.
- 10:20 — источник локализован или событие эскалировано по процедуре.
- 10:42 — решение, действие и подтверждение закрытия сохранены.
- Процесс мониторинга: Обнаружение изменений платёжной страницы
- Границы метода: Методология мониторинга JSIR
Пример события для первичного разбора
{
"event_id": "evt-2026-0716-17",
"payment_state": "checkout.payment",
"baseline_id": "base-2026-0715-r3",
"observed_at": "2026-07-16T10:02:11Z",
"change": {
"type": "script_source_added",
"value": "https://new.example/loader.js"
},
"release_id": null,
"owner": "security-operations",
"decision": "investigate",
"evidence_refs": ["snapshot-884", "headers-884"]
}Практический порядок действий
1
Определите платежные и околоплатежные страницы.
2
Зафиксируйте базовое состояние DOM, ресурсов и HTTP-заголовков.
3
Настройте регулярное обнаружение изменений и уведомления.
4
Опишите процедуру классификации, реакции и хранения доказательств.
Вопросы по теме
Подходит ли обычный FIM для PCI DSS 11.6.1?
Самостоятельно нет. FIM может помогать, но 11.6.1 требует видеть изменения платежной страницы в том виде, в котором её получает браузер конечного пользователя.
Что должен увидеть аудитор?
Логи проверок, базовое состояние страницы, события изменений, уведомления, регламент реакции, ответственных и подтверждение устранения или принятого решения.