En el mundo actual del e-commerce (comercio electrónico), la seguridad de los datos de pago es primordial. Un tipo de amenaza que ha aumentado significativamente en los últimos años es el e-skimming, donde atacantes buscan robar información de tarjetas de pago directamente desde los navegadores de los clientes. A medida que las plataformas de e-commerce se vuelven más complejas y dependen de scripts externos, estos ataques se han vuelto más comunes.
Este blog se basa en la guía del PCI Security Standards Council para comprender y abordar los Requisitos 6.4.3 y 11.6.1 del PCI DSS versión 4.x, los cuales están diseñados para mitigar los riesgos de e-skimming.
¿Cuáles son los riesgos y cómo atacan?
Los sitios web de e-commerce modernos a menudo utilizan una gran cantidad de scripts para diversas funcionalidades, muchos de ellos provenientes de terceros. Si estos scripts no se gestionan correctamente, pueden convertirse en una puerta de entrada para los atacantes.
Existen varios tipos de ataques de skimming que afectan un e-commerce, incluyendo:
- Ataques a la cadena de suministro: Comprometiendo scripts de terceros, permitiendo la inyección de código malicioso sin detección inmediata.
- Ataques de inyección de scripts: Insertando scripts no autorizados en la página de pago para capturar datos y enviarlos a dominios controlados por los atacantes. Estos ataques también se conocen como Magecart o Formjacking.
- Skimming silencioso: El script malicioso opera en segundo plano sin que el cliente note nada sospechoso.
- Skimming de doble entrada: Se presenta un formulario de pago falso antes del legítimo, engañando al cliente para que ingrese sus datos dos veces.
Entendiendo los Requisitos PCI DSS 6.4.3 y 11.6.1
Para combatir estas amenazas en los e-commerce, el PCI DSS v4.0 introdujo los requisitos 6.4.3 y 11.6.1.
Requisito 6.4.3: Se centra en la gestión de todos los scripts de la página de pago que se cargan y ejecutan en el navegador del consumidor. Este requisito tiene tres elementos clave:
- Autorización: Implementar un método para confirmar que cada script está autorizado.
- Integridad: Implementar un método para asegurar la integridad de cada script, garantizando que no contenga contenido no autorizado o malicioso. Ejemplos incluyen el uso de Content Security Policy (CSP) y Sub-Resource Integrity (SRI).
- Inventario y Justificación: Mantener un inventario de todos los scripts con una justificación técnica o comercial por la cual cada uno es necesario.
Requisito 11.6.1: Requiere la implementación de un mecanismo de detección de cambios y manipulaciones para alertar al personal sobre modificaciones no autorizadas (incluyendo indicadores de compromiso, cambios, adiciones y eliminaciones) en los encabezados HTTP que impactan la seguridad y el contenido de los scripts de las páginas de pago tal como los recibe el navegador del consumidor. Este mecanismo debe evaluar los encabezados HTTP y las páginas de pago al menos semanalmente o con una frecuencia definida en un análisis de riesgos específico.
¿Cómo cumplir con estos requisitos?
La guía proporciona varias aproximaciones, mejores prácticas, controles y técnicas para ayudar a cumplir con estos requisitos. Algunas de ellas incluyen:
- Minimizar el número de scripts en las páginas de pago.
- Mover scripts a iframes aislados para limitar su acceso.
- Limitar las fuentes de los scripts.
- Comprender y establecer una línea base del comportamiento de los scripts.
- Implementar Content Security Policy (CSP) para controlar los recursos que el navegador puede cargar y ejecutar.
- Utilizar Sub-resource Integrity (SRI) para asegurar que los recursos estáticos no hayan sido alterados.
- Implementar monitoreo de páginas web, ya sea basado en agentes o sin agentes, para detectar actividades maliciosas.
- Utilizar soluciones basadas en proxy para interceptar y analizar el tráfico web.
- Emplear técnicas como file hashing, limiting sources by URL, nonces, behavior monitoring y static analysis.
Responsabilidades y Aplicabilidad
La aplicabilidad de estos requisitos y las responsabilidades de los comerciantes y los Proveedores de Servicios de Terceros (TPSPs) varían según cómo se implementan las soluciones de pago. Por ejemplo, en escenarios de sitios web totalmente subcontratados, el comerciante podría no tener responsabilidades directas relacionadas con estos requisitos, mientras que el TPSP sí las tendría. Es crucial entender el alcance del PCI DSS en entornos de e-commerce, especialmente en aplicaciones de una sola página (SPAs) donde todos los scripts dentro de la aplicación se consideran parte del mismo entorno.
Evidencia de Cumplimiento
Para demostrar el cumplimiento de estos requisitos durante una evaluación PCI DSS, las entidades deben tener disponible documentación sobre sus políticas, procedimientos, inventarios de scripts, registros de autorización y configuraciones de sistemas. Los evaluadores buscarán evidencia de que los procesos definidos se siguen y que los mecanismos de detección están configurados y funcionando correctamente.
En resumen, la protección contra el e-skimming es esencial para cualquier negocio de e-commerce. Comprender e implementar los Requisitos PCI DSS 6.4.3 y 11.6.1, junto con las mejores prácticas y técnicas descritas en esta guía, ayudará a reducir significativamente el riesgo de robo de datos de pago y a mantener la confianza de tus clientes
Source: pcisecuritystandards
También te puede Interesar: Preguntas Frecuentes sobre Bloques de Claves (Key Blocks) según el PCI SSC
