¿Qué es la normativa PCI DSS?
Significado de la normativa PCI DSS
PCI DSS es un conjunto de estándares de seguridad establecidos en 2004 por las principales empresas de tarjetas de crédito porque, como era de esperar, las aplicaciones que procesan pagos son objetivos muy atractivos para hackers y agentes maliciosos.
La misión de PCI DSS es asegurar las transacciones con tarjetas de crédito y débito no solo para frenar las pérdidas de los bancos y del sector de las tarjetas de pago, sino también para aumentar la confianza y la seguridad de los consumidores. Esto se logra mediante un conjunto de controles de seguridad que protegen la confidencialidad, integridad y precisión de los datos de la tarjeta. Este estándar de cumplimiento se aplica a todas las organizaciones que almacenan, procesan y transmiten datos de tarjetas de crédito. A diferencia del NIST, que es un marco que se le anima encarecidamente, pero que no está obligado a seguir, es absolutamente necesario que cumpla con PCI DSS.
Requisitos de PCI DSS
PCI DSS consta de 12 requisitos agrupados en seis objetivos de control, garantizando que las organizaciones que procesan, almacenan o transmiten datos de tarjetas de crédito mantengan un entorno seguro. El cumplimiento ayuda a proteger la información del titular de la tarjeta y a fortalecer las medidas de seguridad generales.
Objetivo n.o 1: Creación de una red segura
- Regla n.o 1: Instalar y mantener un firewall
- Regla n.o 2: No utilice contraseñas o configuraciones predeterminadas del proveedor
Objetivo n.o 2: Proteja los datos del titular de la tarjeta
- Regla n.o 3: Proteja los datos almacenados del titular de la tarjeta
- Regla n.o 4: Cifrar los datos transmitidos del titular de la tarjeta
Objetivo n.o 3: Mantener un programa de gestión de vulnerabilidades
Regla n.o 5: Protéjase del malware
- Regla n.o 6: Desarrollar y mantener sistemas seguros
Objetivo n.o 4: Gestionar el control de acceso
- Regla n.o 7: Restringir el acceso a los datos del titular de la tarjeta
- Regla n.o 8: Identifique de forma única a todos los que tienen acceso a los datos del titular de la tarjeta
- Regla n.o 9: Restringir el acceso físico a los datos del titular de la tarjeta
Objetivo n.o 5: Supervisar y probar redes
- Regla n.o 10: Realice un seguimiento y supervise todo el acceso a los datos del titular de la tarjeta
- Regla n.o 11: Pruebe la seguridad del sistema
Objetivo n.o 6: Mantener una política de seguridad de la información
- Regla n.o 12: Crear y aplicar una política de seguridad de la información dentro de la organización
También hay cuatro niveles de cumplimiento, dependiendo del número anual de transacciones con tarjeta de crédito/débito procesadas. La clasificación determina lo que la organización debe hacer para seguir cumpliendo con las normas:
- Nivel 1: Más de 6 millones de transacciones al año - Requisito: Auditoría interna anual realizada por un auditor de PCI autorizado. Además, deben completar el análisis de PCI por parte de un proveedor de análisis aprobado (ASV) una vez al trimestre.
- Nivel 2: 1-6 millones de transacciones al año: - Requisito: Complete una evaluación anual utilizando un Cuestionario de autoevaluación (SAQ). Es posible que se requiera un análisis de PCI trimestral.
- Nivel 3: 20 000-1 millón de transacciones al año - Requisito: Autoevaluación anual y posiblemente una exploración de PCI trimestral.
- Nivel 4: Menos de 20 000 transacciones al año - Requisito: Autoevaluación anual y posiblemente una exploración de PCI trimestral.
Por qué es importante el cumplimiento de PCI DSS
Todos en la organización desempeñan un papel en el mantenimiento del cumplimiento de normativa. Comienza en la parte superior con los CISO y, a continuación, llega a los equipos de SecOps y DevOps. En un mundo ideal de DevSecOps, no existe una jerarquía en la responsabilidad de seguridad entre ambos equipos: trabajan en conjunto entre sí. SecOps debe ayudar a los equipos de DevOps a comprender lo que tienen que hacer y los desarrolladores deben ejecutar esto a nivel de aplicación.
Siguiendo los 12 requisitos de PCI DSS, estos son algunos ejemplos de cómo el cumplimiento continuo es un esfuerzo de equipo:
- Regla n.o 6: Los desarrolladores deben crear sistemas con la seguridad en mente
- Regla n.o 8: La gestión de identidad y acceso debe asignar a cada usuario un único requisito de ID de usuario ocho
- Regla n.o 9: El departamento de seguridad física debe asegurarse de que el acceso al edificio y a las salas de servidores esté controlado
- Regla n.o 10: Las operaciones de seguridad deben garantizar que se crean registros para registrar y realizar un seguimiento del acceso a los datos del titular de la tarjeta
- Regla n.o 11: Los equipos de operaciones y desarrollo deben trabajar juntos para probar servidores y software
- Regla n.o 12: La dirección debe desarrollar políticas y documentos asociados para detallar el nivel de seguridad de la información y cumplimiento que se debe lograr en su negocio
Todo esto, por decirlo todo, todos desempeñan un papel en el cumplimiento. No solo para el bien general de la organización, sino para que pueda crear e implementar de forma eficiente y con la confianza de que no va a recibir 10 000 alertas de SOS Slack después del lanzamiento de su aplicación.
Como dijimos, su responsabilidad recae principalmente en el nivel de aplicación. Esto incluye el uso de código fuente seguro, la garantía de configuraciones adecuadas para su canalización de CI/CD y mucho más. Es posible que esté pensando: Vale, pero ¿cómo se supone que debo saber cómo hacerlo? La buena noticia es que no es necesario ser un experto en seguridad o cumplimiento de normativa, al igual que no es necesario ser un neurocirujano para poner un Band-Aid en marcha. Se trata de conocer y aplicar los recursos adecuados (como una ayuda de banda en lugar de pegar una servilleta sobre la herida).
Para evitar configuraciones erróneas, puede consultar el sitio de documentación de su proveedor de servicios en la nube (CSP). Sin embargo, leer toda esta información puede llevar demasiado tiempo. Si ese es el caso para usted, le sugerimos (en lugar de ello, recomendamos encarecidamente) que utilice una solución de seguridad con automatización.
Violaciones de datos relacionadas con PCI DSS
La primera filtración que se le ocurre es el hackeo de Capital One que expuso 106 millones de solicitudes de tarjetas de crédito y condujo a una multa de 80 millones de dólares de los reguladores estadounidenses. Echemos un vistazo a otras filtraciones y cómo podrían haberse evitado consultando las reglas y objetivos de PCI DSS.
Vestíbulo
A principios de 2021, se hackeó Hobby Lobby. Un investigador independiente que utiliza el asa Boogeyman identificó la filtración. Descubrió una base de datos de acceso público en Amazon Web Services (AWS) que contenía información confidencial de más de 300 000 clientes de Hobby Lobby. La base de datos tenía un tamaño de 138GB y tenía nombres de clientes, direcciones, números de teléfono y detalles parciales de la tarjeta. Lo extraño en la misma base de datos era el código fuente de la aplicación de la empresa, que es otro problema.
La filtración fue el resultado de una base de datos en la nube mal configurada que era accesible públicamente. Se trata de una clara infracción de las normas PCI DSS n.o 3, n.o 7 y n.o 9, porque los datos de la tarjeta de pago se estaban almacenando en un servidor abierto. Hobby Lobby tampoco cumplió con la regla n.o 10, que establece que el acceso a los datos del titular de la tarjeta y los recursos de red relevantes se deben rastrear y supervisar. Claramente esto no estaba sucediendo, de lo contrario, la configuración errónea se habría solucionado y todo el problema se habría evitado en última instancia.
Macy’s
El principal minorista sufrió una filtración en octubre de 2019, que expuso los números de las tarjetas de pago, los códigos de seguridad y las fechas de caducidad de los clientes que utilizaron el sistema de pago online con la página de cartera Mi cuenta. Aunque Macy’s no reveló el número de clientes afectados, el minorista registró 55,7 millones de visitas mensuales en línea hasta abril de ese año. Y para ser francos, robar la información de un solo cliente es suficiente como una preocupación.
La filtración se produjo debido a un ataque dirigido de Magecart que inyectó malware en las páginas de pago y cartera. Es evidente que Macy’s infringió una gran cantidad de reglas de PCI DSS y lo más preocupante es el hecho de que Magecart es bien conocido. De hecho, Macy’s fue solo una de las muchas víctimas ese año, incluidas FILA, Ticketmaster, British Airways y otras. Los ataques anteriores a otros minoristas importantes deberían haber motivado a Macy’s a realizar auditorías de seguridad y a remediar cualquier vulnerabilidad según lo requerido por PCI DSS.