Cómo detectar la manipulación del lado del cliente: líneas base, monitoreo, alertas y evidencia

Empiece con una línea base

Un cambio solo puede verse frente a algo. Una línea base es un registro del estado correcto conocido de cada página de pago, tomado después de que usted haya revisado y aprobado lo que contiene. Debe incluir:

• cada script, por su dirección y una huella de su contenido, y cada script en línea por un hash;
• el contenido propio de la página que importa para el pago, como los formularios, sus campos y adónde se envían;
• los marcos incrustados y sus orígenes;
• las cabeceras de seguridad HTTP, en especial la Política de Seguridad de Contenido (CSP) (vea cabeceras de seguridad HTTP para páginas de pago);
• los dominios de terceros con los que contacta la página.

La línea base vale tanto como la revisión que hay detrás. Construirla a partir de un inventario de scripts que las personas hayan aprobado significa que la línea base ya lleva consigo las decisiones.

Qué cuenta como un cambio que merece una alerta

• Un script nuevo, eliminado o cuyo contenido ha cambiado.
• Un script que ahora viene de otra dirección o que carga algo nuevo.
• Un formulario que gana un campo o que envía a otro lugar.
• Una cabecera de seguridad ausente, debilitada o distinta, o una política que ahora permite un origen nuevo.
• Un nuevo dominio de terceros con el que contacta la página.

No toda diferencia es un ataque. Las publicaciones, las actualizaciones de proveedores y los cambios de marketing alteran las páginas. La forma de mantener significativas las alertas es vincular la detección a la aprobación: un cambio que coincide con una solicitud de cambio aprobada es esperado; uno que no, se investiga. Es la unión del 6.4.3 y el 11.6.1.

Desde dónde mirar: lo que recibe el cliente

El requisito 11.6.1 habla de las páginas y las cabeceras tal como las recibe el navegador del consumidor. Las formas de observarlo incluyen:

• Monitoreo sintético con un navegador real. Un navegador fuera de su red recorre el flujo de pago, incluidos los pasos detrás de un inicio de sesión, y registra lo que recibe. Es independiente de sus servidores y ve lo que ejecutaría el navegador de un cliente, pero solo ve lo que provoca su propia visita.
• Un script de informes incrustado. Informa desde los navegadores de visitantes reales, pero se ejecuta en el mismo lugar que el script de un atacante y este puede alterarlo o desactivarlo.
• Una función de proxy inverso o de CDN. Ve el tráfico que pasa por ella, pero no lo que hacen los scripts dentro del navegador.
• Monitoreo de integridad de archivos del lado del servidor. Detecta archivos cambiados en sus servidores, pero no los cambios hechos por scripts de terceros ni en tiempo de ejecución.

Los enfoques se complementan. Elija lo que convenga a su arquitectura y esté preparado para explicar a su evaluador cómo la combinación cubre la intención.

Con qué frecuencia comprobar

PCI DSS 11.6.1 fija un mínimo: al menos una vez cada siete días, o la frecuencia de su análisis de riesgos específico. Un skimmer que funciona durante una semana puede llevarse muchas tarjetas, por lo que muchas organizaciones comprueban a diario o con más frecuencia, sobre todo en las páginas de mayor volumen. Ajuste la frecuencia a su riesgo y documente el razonamiento. Haga también una comprobación inmediatamente después de cualquier publicación, publicación en el gestor de etiquetas o cambio de proveedor.

Alertas y respuesta

Haga que la alerta sea accionable

Una alerta debe decir qué página, qué cambió (antes y después si es posible), cuándo y desde dónde se vio por primera vez, y si coincide con un cambio aprobado. Envíela a personas designadas por un canal que consulten y registre quién respondió.

Decida de antemano qué ocurre después

1. Clasificar. ¿Se aprobó el cambio? Compárelo con los tickets de cambios y el registro de publicaciones del gestor de etiquetas.
2. Contener. Si no se aprobó, elimine o desactive el script o revierta el cambio, y valore si la página de pago debe seguir disponible mientras investiga.
3. Conservar la evidencia. Guarde la página tal como se recibió, los registros y el historial de cambios antes de que se sobrescriban.
4. Investigar la vía de entrada. Averigüe cómo se hizo el cambio y cierre esa vía; vea XSS y código skimmer inyectado.
5. Notificar. Siga su plan de respuesta a incidentes y sus contratos para informar a su adquirente, a las marcas de pago y a otros, y la ley sobre notificación de brechas.
6. Aprender. Actualice la línea base, el inventario y el plan.

Evidencia que conviene conservar

Para una evaluación querrá mostrar un proceso que funcionó durante todo el período, no solo el último resultado. Conserve el calendario o el análisis de riesgos, la línea base y sus aprobaciones, un historial de cada ejecución, cada alerta y lo que se decidió, y los registros de incidentes. Consérvelo al menos durante el período de evaluación, normalmente doce meses, y confirme la retención que espera su evaluador.