He notado que muchas de las organizaciones que desean cumplir con PCI DSS 3.2.1 tienen dudas sobre cómo cumplir con el requisito 3.4, por lo que en este, mi primer artículo, me tomé la tarea de explicar a detalle este requisito y cómo lo podamos abordar.

Para comenzar, entendamos el requisito 3.4:

Hasta este momento, sabemos que el PAN debe ser almacenado de forma ilegible y nos dan 5 alternativas para protegerlo:

Si bien anteriormente mencione que eran 5 alternativas, la quinta opción hace referencia al sub-requisito 3.4.1 que es cifrado de disco y profundizaremos un poco más.

A nivel de protección del dato, el requisito 3.4 establece que el dato PAN debe de almacenarse de manera ilegible a nivel archivo, columna (base de datos) o cifrado de disco.

He aquí cuando empieza la confusión: ¿Es requerido que cumpla con las 3 formas? Si solo cumplo con alguno de ellos, ¿puedo cumplir con el requisito 3.4?

Algunas organizaciones tienen limitaciones técnicas o presupuestales para poder implementar un control de seguridad para proteger el dato de la tarjeta, cómo puede ser la adquisición de un HSM para el cifrado de datos, alguna herramienta de tokenización o simplemente la plataforma no permite alguno de estos mecanismos de seguridad, como podría ser – a manera de ejemplo – un mainframe.

En estos casos, se puede explorar la alternativa del requisito 3.4.1 que establece:

Cómo lo dice la columna de guía, se pretende aceptar cifrado de disco como un método de protección de los datos de tarjeta de manera ilegible. No obstante, existen algunas consideraciones que tenemos que tomar en cuenta para que esta opción sea aceptada:

  1. Las llaves (claves de cifrado) con las que se cifra el disco deben tener un acceso lógico independiente a los mecanismos de autenticación del sistema operativo donde reside el disco.
  2. No usar una clave de descifrado que esté asociada a las bases de datos de cuentas de usuarios locales del sistema ni a credenciales generales de inicio de sesión de la red o que derive de estas.

Pongamos como ejemplo Microsoft Bitlocker. Esta herramienta tiene diferentes métodos para operar. Por ejemplo, puede autenticar directamente desde directorio activo (AD) o puede operar de manera stand-alone.

De acuerdo con él lineamiento número 1, autenticar por Active Directory no cumpliría con el requisito 3.4.1. Sin embargo, y se utiliza de manera stand-alone, la herramienta provee una llave (clave de cifrado) que puede ser introducida manualmente o a través de un dispositivo removible (USB). Si esa llave (clave de cifrado) no es introducida, no mostrará el logon al usuario, por lo que podemos decir que el segundo punto sí cumple con el requisito 3.4.1.

Vemos un escenario similar en el segundo lineamiento que establece que las llaves de descifrado no deben de asociarse a las cuentas de usuario. Autenticar mediante AD no cumpliría con el requisito 3.4.1, sin embargo, el método de stand-alone si lo hará, ya que es independiente tanto al sistema operativo donde reside el disco y no está asociado a una cuenta de usuario.

Ahora hay un punto importante que a tener en mente como lo establece la guía:

El cifrado de disco completo ayuda a proteger los datos en caso de la pérdida física del disco y, por lo tanto, debe ser compatible con dispositivos portátiles que almacenan los datos del titular de la tarjeta.

Pareciera que el requisito 3.4.1 solo está enfocado a medios de almacenamiento extraíbles, ya que viendo la probabilidad de que alguien se robe un disco duro (en caso de ser físico) de un servidor que nunca se apaga, es muy baja. Sin embargo, el council permite que el cifrado de disco de un servidor físico o virtual cumpla con el requisito 3.4.1.

Recuerden que cumplir no es sinónimo de ser seguros, por lo que si bien cifrar todo el disco para proteger la información de tarjetas puede ayudarte a cumplir con el requisito 3.4 y 3.4.1, realiza un análisis de riesgo para verificar si los datos están siendo protegidos adecuadamente o requieren controles de seguridad adicionales, esto dependerá de cada organización.

Hay varias alternativas para proteger los datos de tarjeta en reposo (data at rest). Sin embargo, la posibilidad y factibilidad de cada uno dependerá de la organización que los requiera, por lo que antes de decidir por alguna, analiza estas 5 alternativas y decide cuál es la que mejor se adapta a tus necesidades.

En futuros artículos ampliaremos los detalles técnicos relacionados con la implementación de este tipo de soluciones en entornos que deben alinearse con PCI DSS.

Referencias a otros post:

https://www.pcihispano.com/cifrado-de-unidades-lvm-y-el-requisito-3-4-1-de-pci-dss/

Referencias externas:

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-are-acceptable-formats-for-truncation-of-primary-account-numbers?q=truncate&l=en_US&fs=Search&