En este nuevo artículo analizaremos los cambios de la nueva versión del estándar relativos a la protección de los datos de tarjeta, incluyendo la seguridad en el almacenamiento de los datos de cuenta dentro del entorno PCI DSS (requisito 3) y del envío de los datos de tarjeta de forma segura a través de redes abiertas y públicas utilizando cifrado robusto (requisito 4), ambos correspondientes al segundo objetivo de control definido en el estándar: "Protect Account Data".
Requisito 3: Protect Stored Account Data
El primer cambio dentro del requisito 3 lo volvemos a tener en el nombre del propio requisito, cuyo nombre en la versión 3.2.1 era "Protect stored cardholder data", incluyendo el término "datos de cuenta" en vez de "datos de tarjeta". En esta versión nos encontramos con la ampliación del concepto para la protección tanto de datos de tarjeta (CHD) como datos sensibles de autenticación (SAD).
Otro de los puntos que esclarece el estándar es la no necesidad de aplicar cifrado a los datos de cuenta que se encuentren en memoria no persistente o volátil como podría ser la RAM u otro tipo de memorias volátiles, aunque será necesario aplicar otros controles, como es el borrado de los mismos en memoria después de que se termine la necesidad de negocio de tenerlos. La organización debe asegurarse del estado no persistente de la memoria.
En esta nueva versión se tendrá en cuenta la evolución de la criptografía con la aparición de nuevos protocolos y algoritmos de cifrado que sustituirán a aquellos considerados como vulnerables.
Los principales cambios en este requisito los mencionamos a continuación:
- 3.1.2. Definición de roles y responsabilidades. Los roles y responsabilidades correspondientes al requisito 3 (protección de los datos de cuenta, protección de claves de cifrado, etc.) deberán ser formalmente asignados para garantizar que el personal es consciente de sus responsabilidades del día a día.
- 3.2.1. El almacenamiento de los datos de cuenta será mínimo implementando políticas, procedimientos y procesos de retención y eliminación. En la versión 3.2.1 se cubría con este requisito los datos de tarjeta. El sentido más amplio del estándar añade la protección de todos los datos de cuenta, añadiendo la protección también de los datos sensibles de autenticación. Por tanto, con este requisito se pretende que las políticas, procedimientos y procesos:
- Den cobertura a todas las localizaciones que almacenan datos de cuenta.
- Den cobertura para cualquier dato sensible de autenticación (SAD) almacenados antes de la autorización (buena práctica hasta el 31 de marzo de 2025).
- Limitar la cantidad y tiempo de almacenamiento en base a lo requerido por requerimientos legales o regulatorios o por necesidad de negocio.
- El periodo de retención tiene que incluir una justificación documentada de negocio.
- Establecer procesos de borrado seguro o eliminación de los datos para que no puedan ser recuperados una vez se supere el periodo de retención.
- Determinar un proceso para verificar, al menos una vez cada 3 meses, que los datos de cuenta son borrados de forma segura una vez superan el periodo de retención.
- 3.3.2. Cifrar los SAD que son almacenados electrónicamente antes de la autorización. La novedad de incluir la protección de los datos de cuenta en el requisito incluye el cifrado seguro de los mismos utilizando claves criptográficas robustas, a poder ser distintas de las utilizadas para la protección del PAN (buena práctica hasta el 31 de marzo de 2025).
- 3.4.1. Mostrar el BIN y los 4 últimos dígitos enmascarados cuando sea necesario mostrarlos. La versión 3.2.1 permitía solamente el mostrar los 6 primeros dígitos y los 4 últimos. Los cambios en la longitud de los BINes (cambio tratado en otro artículo del blog: "¡Bienvenido sea el IIN (BIN) de 8 dígitos! ¿Qué implicaciones conlleva, y cómo afecta al cumplimiento con PCI DSS 3.2.1 y 4.0?") han supuesto la actualización del presente subrequisito manteniendo el objetivo de limitar la visibilidad al BIN más los 4 últimos dígitos a las personas autorizadas.
- 3.4.2. Prevenir el copiar/relocalizar PANs cuando se utilicen tecnologías de acceso remoto. Establecer controles para prevenir el copiar/relocalizar PANs para todo el personal, salvo para aquellas personas con autorización explícita y documentada bajo una necesidad de negocio definida (buena práctica hasta el 31 de marzo de 2025).
- 3.5.1.1. Se utilizan hashes criptográficos con clave para la protección de PANs. Los hashes utilizados para proteger los PANs son hashes criptográficos con clave (HMAC, CMAC y GMAC con claves de al menos 128 bits) de todos los PANs. Se utilizan procesos y procedimientos de gestión de claves asociados que cumplen con los requisitos 3.6 y 3.7. Incluye como buena práctica el incorporar claves secretas generadas aleatoriamente (buena práctica hasta el 31 de marzo de 2025).
Otros cambios a tener en cuenta:
- 3.3.3. Protección de los SAD en emisores o compañías que soportan servicios de emisión y almacenan SAD. Se incluye la protección de los SAD utilizando cifrado robusto, así como buena práctica el utilizar una clave distinta a la utilizada para proteger los PANs (buena práctica hasta el 31 de marzo de 2025 y sólo para proveedores de servicio).
- 3.5.1.2. El cifrado a nivel de disco o de partición solo se utiliza para hacer los PANs ilegibles. Se establecen las directrices para implementar este modo de cifrado, acotándolo a medios electrónicos extraíbles o, si se utiliza para medios electrónicos no extraíbles, los PANs se harán ilegibles mediante otro mecanismo que cumpla con el requisito 3.5.1 (hashes unidireccionales, truncamiento, índice de tokens o cifrado robusto). (Buena práctica hasta el 31 de marzo de 2025).
- 3.6.1.1. Mantener una descripción documentada de la arquitectura criptográfica. La nueva versión del estándar incluye el documentar que se evita la utilización de las mismas claves de cifrado en producción y en los entornos de prueba, pudiendo incluir, como buena práctica, mecanismos de reporte automático (buena práctica hasta el 31 de marzo de 2025 y sólo para proveedores de servicio).
- 3.7.9. Documentación y distribución de guías para la transmisión, almacenamiento y actualización de claves de forma segura. En caso de que se compartan claves entre proveedores y clientes, los proveedores tendrán que encargarse de documentar y distribuir entre sus clientes guías para la transmisión, almacenamiento y actualización de claves de forma segura para prevenir que puedan ser gestionadas de forma inadecuada o expuestas a entidades no autorizadas.
Otro de los cambios con el que nos encontramos es con la eliminación de los pads (ensambladores) como forma segura para hacer ilegible el PAN dentro del requisito 3.5.1, quedando solamente como válidas las opciones de truncamiento, funciones hashes basadas en cifrado robusto, cifrado robusto e índice token.
Requisito 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
Del mismo modo que ocurría con los requisitos analizados hasta el momento, el requisito número 4 de la versión 4.0 de PCI DSS cambia también su nombre ("Encrypt transmission of cardholder data across open, public networks") especificando que se utilizará un tipo de cifrado robusto para la protección de los datos de tarjeta.
Con esta nueva versión se incluirán nuevos controles relativos a la protección de los datos de tarjeta en redes abiertas y públicas teniendo en cuenta la evolución de la criptografía o cambios en la forma de comunicación.
Los principales cambios en este requisito los mencionamos a continuación:
- 4.1.2. Definición de roles y responsabilidades. Los roles y responsabilidades correspondientes al requisito 4 (configuración segura de protocolos y certificados, gestión de inventario de claves y certificados, etc.) deberán ser formalmente asignados para garantizar que el personal es consciente de sus responsabilidades del día a día.
- 4.2.1. Utilizar certificados válidos para la protección de las transmisiones. En este subrequisito se añade el utilizar certificados válidos y confiables para proteger la integridad en las comunicaciones (certificados emitidos por una CA confiable) y que no hayan expirado para la protección de las transmisiones al listado de requisitos para el envío seguro de datos de tarjeta ya aportados en la versión 3.2.1 (claves y certificados de confianza, protocolos con versiones seguras y robustez apropiada para el cifrado). (Buena práctica hasta el 31 de marzo de 2025).
- 4.2.1.1. Inventario de claves y certificados. La nueva versión incluye la gestión de un inventario de claves y certificados para garantizar que los PANs son protegidos durante la transmisión, ayudando a la organización a mantener una trazabilidad de todos los algoritmos, protocolos, robustez de claves, custodios y fechas de expiración de claves que se utilizan para la transmisión. Con este inventario se permite a la entidad responder rápidamente a las vulnerabilidades descubiertas. De esta forma se evita utilizar protocolos con vulnerabilidades como SSL, SSH v1.0 o TLS temprano. Como buena práctica se establece que el inventario incluya a la CA emisora y la fecha de expiración del certificado para facilitar la revisión de los mismo, garantizando la integridad de las comunicaciones. (buena práctica hasta el 31 de marzo de 2025).
- 4.2.2. Protección del PAN con cifrado robusto cuando es mandado por tecnologías de mensajería de usuario final. Se elimina la posibilidad de mandar datos de tarjeta a través de tecnologías de mensajería de usuario final (email, SMS, mensajería instantánea, chats, etc.), que establecía la versión anterior, incluyendo el control del envío a través de cifrado seguro. Como buena práctica, el subrequisito establece que se utilice este tipo de tecnología donde haya una necesidad de negocio definida.
Conclusiones
La nueva versión del estándar ha introducido distintos cambios en todos los requisitos del estándar, algunos de mayor calado que otros. Se han analizado aquellos más importantes dentro de los requisitos 3 y 4, siendo estos:
- Definición de roles y responsabilidades para ambos requisitos.
- Protección y cifrado de los datos sensibles de autenticación (SAD).
- Mostrar enmascarados el BIN más los 4 últimos dígitos.
- Prevenir el copiar/relocalizar los PANs cuando se utilicen tecnologías de acceso remoto.
- Utilizar hashes criptográficos con clave para proteger el PAN.
- Utilizar certificados válidos y no expirados para proteger las transmisiones.
- Generar y mantener un inventario de claves y certificados.
La aplicabilidad de estos cambios dependerá en gran medida del tipo de organización que vaya a ser evaluada, así como el impacto que pueda suponer la actualización del estándar, por lo que es recomendable ponerse en contacto con empresas especializadas para una implantación correcta de la nueva norma.
Una vez analizados los cambios en los requisitos 3 y 4 de la nueva versión, se confirma la evolución del estándar para cubrir con la protección de los datos de cuenta una vez almacenados y transmitidos, aumentando el alcance a los datos sensibles de autenticación (SAD), incluyendo nuevos controles y adaptando antiguos para alcanzar un nivel de seguridad adecuado en el entorno. Esta actualización resuelve problemas y limitaciones aparecidas en los últimos años, como el uso de BINes de más de 6 dígitos, la utilización de nuevos protocolos de cifrado robustos o utilización de servicios de mensajería de usuario final. Además, con la nueva versión se incluyen una serie de buenas prácticas que facilitan la interpretación de los requisitos y la madurez en los mismos (utilización de claves distintas para los SAD que, para el PAN, incorporar claves secretas generadas aleatoriamente en las funciones hash, etc.).
En el siguiente artículo se analizarán los cambios en los requisitos 5 y 6 del estándar.
Bibliografía
- Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Versión 3.2.1, mayo 2018.
- Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Versión 4.0, marzo 2022.
- Payment Card Industry (PCI) Data Security Standard, Summary of Changes from PCI DSS Version 3.2.1 to 4.0, diciembre 2022.
Autor: Diego de la Horra - PCIP, ISO 27001 L.A.
Dpto. Consultoría
