Continuando con el análisis a la versión 4.0 del estándar PCI DSS, en esta tercera parte de la serie se analizarán los requerimientos 3 y 4 que hacen parte del grupo “Protect Account Data”, enfocados a la protección de la confidencialidad y la integridad de los datos de tarjetas de pago durante su almacenamiento y su transmisión a través de redes abiertas y públicas.

Al igual que la mayoría de los requerimientos de PCI DSS 4.0, los requerimientos 3 y 4 fueron renombrados para ampliar su alcance, así como también para dar congruencia a estos controles con la aplicabilidad del estándar, tal y como se especifica en la sección 2 “PCI DSS Applicability Information”: Los requisitos de PCI DSS se aplican a las entidades con entornos en los que se almacenan, procesan o transmiten datos de cuentas (datos de titulares de tarjetas y/o datos sensibles de autenticación), y a las entidades con entornos que pueden afectar a la seguridad del CDE (PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of the CDE).

Mientras que en la versión 3.2.1 del estándar PCI DSS los nombres del grupo y de los requerimientos 3 y 4 hacían mención únicamente a la protección de los datos del titular de tarjeta (Cardholder Data), en la versión 4.0 este término se amplia no solo a los datos del titular de tarjeta, sino también a los datos confidenciales de autenticación (Sensitive Authentication Data), conforme con las definiciones de estos conceptos incluidas en el estándar:

Componentes del concepto «Account Data» en PCI DSS

Requerimiento 3: Protect Stored Account Data

Al igual que en las versiones anteriores del estándar PCI DSS, este requerimiento está enfocado a la protección de los datos de tarjetas durante su almacenamiento.

A pesar de que este requerimiento siempre ha incluido controles específicos orientados a la protección de los datos completos de la banda magnética, del PIN/PIN Block y del código de verificación de la tarjeta (Card Verification Code), el nombre del requerimiento (Protect Stored Cardholder Data) solamente hacía mención a los datos del titular de tarjeta (Cardholder Data), lo que añadía cierto punto de incoherencia entre los controles contenidos en este requerimiento y el nombre del requerimiento en sí, al no incluir los datos confidenciales de autenticación (Sensitive Authentication Data) de forma explícita.  En la versión 4.0 del estándar PCI DSS, esto ha sido solventado y ahora el nombre del requerimiento (Protect Stored Account Data) está alineado con los tipos de datos que protege (datos del titular de tarjeta (Cardholder Data) y datos confidenciales de autenticación (Sensitive Authentication Data), como parte de los datos de cuenta (Account Data)).

Algunos de los cambios más significativos en este requerimiento son:

Aclaración de los tipos de almacenamiento de tarjetas

En la versión 4.0 se han añadido a este requerimiento una serie de aclaraciones que se venían esperando desde hace mucho tiempo. En primera instancia, se hace una separación explícita de los tipos de almacenamiento de datos de tarjetas, incluyendo las restricciones y la aplicabilidad de controles para cada uno:

• Almacenamiento persistente (persistent storage) o no volátil: Este tipo de almacenamiento es aplicado cuando el dato de tarjeta es conservado una vez completado su objetivo comercial (por ejemplo, una transacción asociada). Dentro de este tipo de almacenamiento se encuentra el almacenamiento intencional o no intencional en medios de almacenamiento como discos duros, unidades de copias de seguridad, medios de almacenamiento extraíbles, etc. en forma de archivos de registro de eventos (logs), archivos históricos (history files), archivos de trazabilidad (trace files), contenidos de bases de datos, ficheros de volcado de memoria (memory/crash dump files), etc.Para este tipo de almacenamiento, todos los controles del requerimiento 3 son aplicables.
• Almacenamiento no persistente (non-persistent storage) o volátil: Este tipo de almacenamiento temporal es empleado cuando el dato de tarjeta es procesado durante su objetivo comercial únicamente. Dentro de este tipo de almacenamiento se encuentra la memoria RAM y otros tipos de memoria volátil, en donde la información se pierde cuando se interrumpe el flujo eléctrico. Para este tipo de almacenamiento, los datos deben ser removidos en cuanto su objetivo comercial haya sido finalizado. Sin embargo, controles adicionales como el cifrado de datos no son requeridos siempre y cuando los datos no sean movidos a un almacenamiento persistente, como se especifica en la FAQ 1042.

Aplicabilidad de PCI DSS en función del medio de almacenamiento

Controles para la protección de datos confidenciales de autenticación

Por otro lado, se han agregado aclaraciones y controles adicionales para la protección de los datos confidenciales de autenticación (Sensitive Authentication Data) almacenados antes de la finalización del proceso de autorización, incluyendo:

• Inclusión en la política de retención y borrado seguro, para limitar el almacenamiento de estos datos al mínimo necesario (req. 3.2.1),
• Cifrado de estos datos empleando criptografía robusta, incluso si los datos del PAN no se encuentran presentes en el entorno (req. 3.3.2 y 3.3.3).

Estos controles entrarán en vigor a partir del 31 de marzo de 2025.

Controles de enmascaramiento (masking) y BIN de 8 dígitos

Probablemente uno de los controles que más expectativa generaban en esta nueva versión del estándar PCI DSS fue el control relacionado con el enmascaramiento de los datos del PAN durante su visualización, dados los continuos cambios en los criterios de las marcas de pago relacionados con la entrada en vigencia del BIN/IIN de ocho (8) dígitos. En este sentido – y para no entrar en conflicto con las marcas de pago – el estándar mantuvo su posición neutral aclarando que, cuando el PAN sea visualizado, solamente el BIN/IIN (al margen de su longitud) y los últimos cuatro dígitos pueden ser mostrados. Si se requiere la visualización de dígitos adicionales, es necesario mantener un listado de roles con este privilegio, así como de su justificación de negocio.

Este control está alineado con la FAQ 1492 de febrero de 2021.

Copia/reubicación del PAN cuando se usan tecnologías de acceso remoto

En el estándar PCI DSS v.3.2.1, en el control 12.3.10 se prohibía la copia, reubicación y almacenamiento de datos de tarjetas en discos duros locales y medios de almacenamiento removibles cuando se accedía a estos datos a través de tecnologías de acceso remoto, salvo que existiera una necesidad de negocio autorizada. Este control ha sido movido del requerimiento 12 al requerimiento 3 en PCI DSS v4.0, aclarando que su aplicabilidad es únicamente al dato del PAN.

Este control entrará en vigor a partir del 31 de marzo de 2025.

Almacenamiento seguro del PAN

Uno de los controles estrella de PCI DSS es el control en donde se identifican los métodos autorizados para el almacenamiento de datos del PAN. Si bien estos métodos no han variado entre la versión 3.2.1 (req. 3.4) y la versión 4.0 (req. 3.5.1), sí que se han añadido varias aclaraciones:

• Si se hace uso de un hash, se debe aplicar la función a la totalidad del PAN empleando criptografía robusta (req. 3.5.1.1). Igualmente, ya no se permitirá el uso de una función de hash simple. A partir del 31 de marzo de 2025 se deberá hacer uso de algoritmos de hash criptográfico con clave (keyed cryptographic hashing algorithms) tales como HMAC, CMAC o GMAC. Obviamente, dicha clave deberá cumplir con los requisitos de gestión de claves criptográficas (reqs. 3.6 y 3.7).
• Si se emplea el truncamiento, no se puede usar un hash para remplazar la parte truncada del PAN. Adicionalmente, si en el mismo entorno existen versiones truncadas y con hash del mismo PAN o diferentes formatos de truncamiento del mismo PAN con base en los criterios de las marcas de pago (FAQ 1091), se deben aplicar controles adicionales (FAQ 2014).
• Si se emplea cifrado, se deben tener en cuenta los controles de gestión de claves y se debe hacer uso de criptografía robusta.
• Si se emplea tokenización (index tokens), se recomienda el uso de los criterios descritos en el documento Tokenization Product Security Guidelines del PCI SSC y el estándar ANSI X9.119-2-2017: Retail Financial Services – Requirements For Protection Of Sensitive Payment Card Data – Part 2: Implementing Post-Authorization Tokenization Systems.

Uso de cifrado a nivel de disco o de partición

Otro control que tenía problemas en su interpretación era el control relacionado con el uso de cifrado a nivel de disco o de partición. Mediante el uso de este mecanismo, los datos se cifran durante su almacenamiento, pero son automáticamente descifrados una vez el sistema se ejecuta o después de una autenticación correcta de un usuario, por lo que su efectividad es válida solamente mientras el medio de almacenamiento está fuera de línea (offline) protegiendo a la entidad si el medio es removido físicamente de forma no autorizada.

Cifrado transparente de datos (TDE)

A pesar de que era bien sabido que el uso de este tipo de cifrado solamente es aplicable cuando se almacena el PAN en un medio electrónico removible, al no estar esta restricción explícita en el control 3.4.1 de PCI DSS v3.2.1 muchas entidades empleaban este mecanismo para la protección del PAN cuando se almacenaba en bases de datos sin ningún otro control adicional (Transparent Data Encryption – TDE es un buen ejemplo de ello), quedando expuestas a un riesgo innecesario.

Para evitar esta ambigüedad en la interpretación del control, en la versión 4.0 el requerimiento 3.5.1.2 aclara que el uso del cifrado a nivel de disco o de partición solo puede ser aplicado en medios de almacenamiento removibles o, si se usa en otro tipo de medios (incluidos discos duros de servidores, unidades intercambiables en caliente (hot-swappable drives), copias de seguridad masivas en cinta (bulk tape-backups), etc.) se debe hacer uso de un mecanismo de protección adicional incluido en el control 3.5.1 (hash, cifrado, truncamiento o tokenización).

Mejoras en los procesos de gestión de claves de cifrado

Finalmente, los controles de gestión de claves criptográficas (req. 3.6 y 3.7) han sido actualizados para incluir servicios criptográficos en la nube, evitar el uso de la misma clave criptográfica en entornos de producción y de pruebas (req. 3.6.1.1, aplicable solo para proveedores de servicio y a partir del 31 de marzo de 2025), uso de generadores de números aleatorios aprobados dentro de un dispositivo criptográfico seguro (Secure Cryptographic Device – SCD) u otros estándares (como ISO 19592) para la generación de claves de claves o componentes de claves (req. 3.6.1.2 y 3.7.6) y responsabilidades adicionales en el caso que un proveedor de servicios comparta claves de cifrado con sus clientes (req. 3.7.9).

Requerimiento 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

Para la versión 4.0 de PCI DSS, el requerimiento 4 fue simplificado y se agregaron varias aclaraciones respecto al uso de criptografía robusta, principalmente para evitar que en el futuro se presenten situaciones como la ocurrida con la obsolescencia de SSL y el uso de versiones tempranas de TLS. Igualmente, se incorporaron bastantes conceptos que ya habían sido discutidos en el Information Supplement – Best Practices for Securing E-commerce, sobre todo aquellos vinculados con la gestión de certificados digitales.

En este sentido, los siguientes fueron los cambios principales en este requerimiento:

• Su aplicabilidad está limitada exclusivamente a la transmisión del PAN en redes públicas abiertas, dentro de las cuales se encuentran internet, tecnologías inalámbricas (Wi-FI y Bluetooth), tecnologías de comunicaciones móviles (celular) y satélite. De acuerdo con esto, el cifrado del PAN durante su transmisión dentro de redes internas no es obligatorio, pero si es una buena práctica.
• En el caso de que el PAN sea transmitido a través de redes públicas abiertas, se puede proteger mediante el cifrado de este dato antes de ser transmitido, encriptando la sesión sobre la cual se transmiten los datos o ambas cosas.

Uso de cifrado de datos y cifrado del canal en PCI DSS

Dependiendo de la opción implementada, se debe tener en cuenta lo siguiente:

• Si se cifran los datos antes de su transmisión, las claves empleadas para ello estarán cubiertas por los controles 3.6 y 3.7.
• Si se emplea cifrado del canal, se debe validar que:
  • Si se usan certificados, estos deben ser confiables y no deben estar expirados o revocados (este control entrará en vigor a partir del 31 de marzo de 2025).
  • Si se usan certificados autofirmados, éstos serán válidos si son emitidos por una entidad de certificación (Certificate Authority) interna, si el autor del certificado es confirmado y si el certificado es verificado y no está expirado.
  • Los protocolos empleados deben soportar solamente versiones seguras.
  • La fortaleza de la criptografía empleada debe ser apropiada a la metodología de cifrado en uso.
  • Se debe mantener un listado de las claves y certificados usados para proteger el PAN durante su transmisión (este control entrará en vigor a partir del 31 de marzo de 2025).
• En el caso de que la organización pueda recibir datos de tarjetas de pago no solicitados a través de canales de comunicación insegura, hay dos opciones para protegerlos:
  • Incluir el canal afectado dentro del CDE y protegerlo de acuerdo con los controles del estándar, o
  • Implementar medidas para prevenir que ese canal sea usado para transmisión de datos de tarjetas.

Otros controles, como la transmisión del PAN en redes inalámbricas o empleando tecnologías de mensajería de usuario final, continúan siendo válidos siempre y cuando se emplee criptografía robusta para ello.

En el siguiente artículo de esta serie se analizarán los requerimientos 4 y 5 de PCI DSS, orientados a la protección contra código malicioso, actualizaciones de seguridad, gestión de cambios y desarrollo seguro.

Referencias

• Information Supplement – Best Practices for Securing E-commerce https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf
• Use of SSL/Early TLS and Impact on ASV Scans https://www.pcisecuritystandards.org/documents/Use-of-SSL-Early-TLS-and-ASV-Scans.pdf
• Use of SSL/Early TLS for POS POI Terminal https://www.pcisecuritystandards.org/documents/Use-of-SSL-Early-TLS-for-POS-POI-Connections.pdf
• Tokenization Product Security Guidelines https://www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf
• PCI DSS Wireless Guidelines https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Wireless_Guidelines.pdf