relevo-manos

Uno de los controles clave dentro del estándar PCI DSS es el requerimiento 3.4. En él se establecen una serie de estrategias para la protección del PAN (Primary Account Number) cuando requiere ser almacenado si existe alguna justificación de negocio.  Los métodos que pueden ser empleados para dicha protección son:

  • Valores hash de una vía
  • Truncamiento
  • Criptografía sólida
  • Token y ensambladores de índices

Este artículo se focalizará en el último de ellos: la tokenización. Se describirán de forma general sus características, ventajas, desventajas, su aplicación en el entorno de PCI DSS para la securización del dato del PAN en el almacenamiento y la minimización del ámbito de cumplimiento.

Tokenización y protección de datos confidenciales

La tokenización es un concepto bastante sencillo pero efectivo. Consiste en el remplazo de un dato confidencial por otro que no lo es, pero que garantiza la misma operatividad. Funciona de la siguiente manera:

  1. El sistema de tokenización recibe el dato confidencial [D]: En función de las interfaces del aplicativo, el dato confidencial es obtenido desde un formulario, importado en un proceso batch, ingresado por un usuario o cargado desde otro aplicativo.
  2. El dato confidencial [D] es almacenado de forma centralizada: En este paso, el dato confidencial es almacenado en una ubicación centralizada (una base de datos, por ejemplo) y protegido empleando cifrado robusto. Esta ubicación recibe el nombre de “Data Vault“.
  3. El sistema de tokenización genera un token único [T] y lo asocia al dato confidencial almacenado previamente: La siguiente acción consiste en la generación de un token (o “testigo” en español) que no es más que un dato no confidencial que servirá de “alias” del dato confidencial [C] en procesos subsiguientes. Este token almacenado en el “Data Vault” y asociado de forma inequívoca al dato confidencial al cual representa, manteniendo siempre una tabla referencial dual [C]->[T].
  4.  El token es puesto en el flujo operativo del aplicativo, remplazando en todas las operaciones al dato confidencial [C] al cual representa.

En la siguiente imagen se presenta un ejemplo de tokenización empleando como dato confidencial [C] un número de tarjeta de pago (PAN):

tokenizacion

Como se puede ver, el núcleo de todo este proceso radica en el token [T]. Este es un dato no confidencial (es decir, no representa mayor riesgo a la organización en caso que sea filtrado o comprometido) y se genera bajo la premisa que desde él no se puede obtener ni inferir el dato confidencial con el que se relaciona. Otra característica del token  es que debe ser igual de operativo a su par confidencial [C], impactando lo menos posible en las aplicaciones que lo procesan o bases de datos que lo almacenan.

En el caso que por alguna razón operativa se requiera obtener el dato confidencial [C] relacionado con el token [T], el sistema de tokenización debe permitir un proceso de translación [T]->[C] con base en la tabla dual referencial citada anteriormente usando una interfaz segura. Este proceso se denomina des-tokenización (“de-tokenization” en inglés).

Esta técnica puede ser empleada en multitud de entornos donde se requiera proteger datos confidenciales, por ejemplo: números de cuenta bancarios, información de carácter médico, información de historial judicial, números de licencias de conducción o cualquier otro dato personal confidencial.

El concepto de remplazo de un dato por otro y de una tabla de translación relacionada no es ajeno al ámbito informático. Algunos ejemplos claros son las tablas de ARP (par Dirección MAC->Dirección IP), tablas de DHCP y tablas de DNS (par nombre de host->Dirección IP). A pesar que este tipo de sistemas han sido desarrollados para otras labores diferentes a la securización de datos, las tareas de remplazo y translación/traducción se asimilan a la operatividad de un sistema de tokenización.

Tokenización y PCI DSS

Tal como se comentaba al principio del artículo, el PCI SSC incluye las técnicas de tokenización dentro de los métodos de protección del PAN . De acuerdo con ello, el dato confidencial [C] en este modelo sería el PAN o número de la tarjeta de pago, que es el elemento a proteger. El token asociado puede ser generado siguiendo diferentes patrones, dependiendo de las necesidades. A continuación se enumeran algunos de los más empleados:

  • Remplazo total del PAN usando una cadena de números y/o letras con longitud arbitraria o limitada: Bajo este escenario, el token puede tener un formato diferente al PAN relacionado. Suele ser el más complicado de gestionar, ya que es necesario modificar las aplicaciones y bases de datos asociadas para que soporten dicho cambio.
  • Remplazo total del PAN empleando un token con la misma longitud y formato del PAN asociado: Este modelo permite la generación de un token con la misma longitud y formato que el PAN al que representa, impactando mínimamente cualquier sistema asociado. Esto es posible a través de dos técnicas denominadas “Format Preserving Tokenization” (FPT) y “Format Preserving Encryption” (FPE). Debido a que el PAN y el token tienen el mismo formato, es necesario definir una serie de controles para poderlos diferenciar. Este proceso se denomina “distinguibilidad de tokens” (“Token Distinguishability” en inglés). Una técnica que puede ser empleada es el uso del algoritmo de Luhn.
  • Remplazo parcial del PAN, manteniendo las primeras 6 y las últimas 4 posiciones iguales: En aquellas entidades que requieren visualizar las primeras 6 y las 4 últimas posiciones del PAN (máximos permitidos por el control 3.3 de PCI DSS), se puede optar por tokenizar de forma parcial el PAN manteniendo dichas posiciones iguales y remplazando los datos medios con un token. En este modelo – al igual que en el modelo anterior – se requiere el uso de una técnica de diferenciación entre PAN y token para evitar contaminación de datos.

Estos conceptos se resumen en la siguiente imagen:

tokens_tipos

Por otro lado – y dependiendo de las necesidades – un token puede ser generado para un único uso (“single-use”)  o para múltiples usos (“multi-use”). En un único uso, se genera un token cada vez que se requiera una transacción con el dato confidencial y su expiración será definida por dicho proceso, al contrario que el modelo de múltiples usos en el que el token puede ser utilizado en diferentes transacciones, manteniendo siempre la integridad referencial con el dato confidencial al cual representa.

Tokenización y reducción del entorno de cumplimiento (CDE)

El estándar PCI DSS define su ámbito de aplicabilidad de la siguiente manera:

“… El número de cuenta principal es el factor que define la aplicabilidad de los requisitos de PCI DSS. Los requisitos de PCI DSS se aplican si se almacena, procesa o transmite un número de cuenta principal (PAN). Si un PAN no se almacena ni procesa ni transmite, no se aplican los requisitos de PCI DSS…”

Siguiendo este criterio, un token no es un PAN por lo que los requerimientos de PCI DSS no aplican allí donde se almacene, se procese o se transmita, con lo cual aquellos procesos de la empresa por los que fluya un token no estarían sujetos al cumplimiento del estándar. Los elementos que se encontrarán dentro del entorno de cumplimiento serán el sistema de tokenización, el “data vault” y aquellos sistemas que interactúan con datos de tarjetas de pago, con lo cual el CDE (Cardholder Data Environment) se puede ver reducido de forma radical.

Sin embargo, para que esto sea válido hay que cumplir una serie de premisas:

  • El sistema de tokenización no debe proveer el PAN en ninguna respuesta a ninguna aplicación, sistema, red o usuario fuera del alcance de cumplimiento
  • Todos los componentes del sistema de tokenización deben estar ubicados en una red segura interna, aislados de cualquier red no confiable o fuera del alcance.
  • Únicamente se permitirán comunicaciones de entrada y de salida confiables en el entorno de tokenización.
  • La solución de tokenización debe usar algoritmos de criptografía robustos y protocolos de seguridad para salvaguardar los datos de tarjeta de pago cuando son almacenados y durante la transmisión en redes abiertas y públicas.
  • La solución de tokenización debe implementar controles de acceso robusto y medidas de autenticación de acuerdo con los requerimientos 7 y 8 de PCI DSS.
  • Los componentes del sistema de tokenización deben ser diseñados siguiendo estándares de configuración estrictos y protegerlos contra vulnerabilidades.
  • La solución de tokenización debe soportar un mecanismo para borrado seguro de datos de tarjeta de pago cuando sea requerido por la política de retención.
  • La solución de tokenización debe implementar registro de eventos, monitorización y alertas de forma apropiada para identificar cualquier actividad sospechosa e iniciar procedimientos de respuesta.

Soluciones de tokenización en el mercado

Finalmente, a continuación se enumeran algunas soluciones de tokenización que pueden ser empleadas para la implementación de esta tecnología en el cumplimiento de PCI DSS:

De igual manera, este tipo de servicios se pueden contratar en formato SaaS (Software as a Service), provisto por un tercero que puede ser una pasarela de pago o una empresa de seguridad. Dicho servicio recibe el nombre de Tokenization as a Service (TaaS).

Conclusión: Una solución de tokenización no elimina totalmente la necesidad de mantener y validar el cumplimiento de PCI DSS, pero simplifica los esfuerzos de implementación y mantenimiento reduciendo el número de componentes del sistema en los cuales los requerimientos de PCI DSS aplican, mientras que minimiza la exposición de datos confidenciales en los flujos de datos de la organización.

Referencias:

PCI SSC Information Supplement: PCI DSS Tokenization Guidelines (Agosto 2011)(https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf)

VISA Tokenization Best Practices version 1.0 (Julio 2010)(http://usa.visa.com/download/merchants/tokenization_best_practices.pdf)

Revista Red Seguridad 49 (Noviembre 2010): Fundamentos de tokenización y su aplicación en el cumplimiento de PCI DSS (http://isecauditors.com/sites/default/files//files/RedSeguridad_49_Tokenizacion.pdf)