Tokenization Guidelines Info Supplement - En.es

Estándar: PCI Data Security Standard (PCI DSS)
Versión: 2.0
Fecha: de agosto de 2011
Autor: La determinación del alcance SIG, Consejo de Estándares de

Seguridad PCI Tokenization Grupo de Trabajo
Suplemento información: DSS Directrices

Tokenization PCI
Suplemento Informativo • DSS Directrices Tokenization PCI • Agosto de 2011
Tabla de contenido
1 Resumen ejecutivo ................................................ .................................................. .......... 3
1.1 ................................................. objetivo .................................................. ................ 3
1.2 Público objetivo................................................ .................................................. 3 ..
1.3 Introducción a Tokenization ............................................... ...................................... 3
2 Tokenization general ................................................ .................................................. ..... 5
2.1 Tokenization componentes comunes del sistema de .............................................. ............. 6
2.1.1 Generación de emergencia ................................................ ..................................... 6
2.1.2 Mapeo de emergencia ................................................ ......................................... 7

2.1.3 Tarjeta de almacenamiento de datos ............................................... ......................................... 7
2.1.4 Criptográfica de administración de claves ............................................... ............... 7
2.2 Operaciones Tokenization ................................................ .......................................... 8
2.3 Consideraciones de seguridad Tokenization ............................................... ..................... 10
2.3.1 La segmentación de la red ................................................ ............................ 10

2.3.2 Autenticación ................................................. ........................................ 10
2.3.3 Supervisión ................................................. .............................................. 11
2.3.4 Distinguibilidad simbólico ................................................ .......................... 11
2.3.5 Requisitos de las PCI DSS ............................................... ........................... 12
2.4 Los roles y responsabilidades Tokenization .............................................. .................. 12
2.4.1 Modelos de implementación Tokenization ............................................... ............ 12
2.4.2 Responsabilidades mercantes ................................................ ....................... 14

2.4.3 Responsabilidades TSP ................................................ ............................... 15
3 Consideraciones de ámbito PCI DSS .............................................. ..................................... 17
3.1 PCI DSS Ámbito de Tokenization ............................................. .............................. 17
3.1.1 La determinación del alcance Principios ................................................ .................................. 17
3.1.2 Fuera del Alcance Consideraciones ............................................ ..................... 18
3.2 Ámbito lograr la máxima reducción de las PCI DSS ............................................. ..................... 18
4 Consideraciones adicionales ................................................ ............................................... 20
4.1 Fichas como medios de pago .............................................. .............................. 20
4.2 Comprender los riesgos ............................................... ......................................... 20
5 Conclusión ................................................. .................................................. ..................... 21
6 Agradecimientos ................................................. .................................................. ......... 22
7 Sobre el PCI Security Standards Council ............................................ ........................ 23
La intención de este documento es proporcionar información suplementaria. La información proporcionada aquí no reemplazar o sustituir los requisitos de 2
la Norma de Seguridad de Datos PCI.
1. Resumen Ejecutivo
1.1 Objetivo
El propósito de este Suplemento Informativo es proporcionar una guía para los actores de la industria de pagos en el desarrollo, la
evaluación, o la aplicación de una solución tokenización, incluyendo cómo puede afectar el alcance tokenización PCI DSS (PCI DSS).
Este documento proporciona una guía complementaria sobre el uso de tokenización y no sustituye ni reemplaza los requisitos de PCI
DSS.
Este documento no define las especificaciones técnicas o pasos necesarios para implementar una solución de tokenización, ni
describe cómo validar el cumplimiento de PCI DSS para entornos que utilizan tokenización. Este documento no es un respaldo para
cualquier tecnologías, productos o servicios específicos.
1.2 Destinatarios
Este Suplemento Informativo está destinado para los comerciantes que almacenan, procesan o transmiten datos de titulares de tarjetas y buscan
orientación sobre cómo implementar una solución de tokenización puede afectar el alcance de sus esfuerzos de conformidad con el (PCI DSS).
Otros miembros de la industria de pagos, incluyendo los procesadores de pago, compradores, proveedores de servicios, asesores y proveedores
de soluciones también pueden encontrar la información de este documento útil.
1.3 Introducción a la Tokenization
Tokenization es un proceso por el cual el número de cuenta primaria (PAN) se sustituye con un valor sustituto llamado un -token.‖
De-tokenización es el proceso inverso de redimir un contador para su valor PAN asociado. La seguridad de un token individuo se basa
predominantemente en la inviabilidad de determinar el PAN original, aunque solamente conocía el valor de alquiler.
Dependiendo de la implementación particular de una solución tokenización, fichas utilizadas en los sistemas comerciales y las aplicaciones pueden
no necesitar el mismo nivel de protección de seguridad asociados con el uso de PAN. El almacenamiento de fichas en lugar de PAN es una
alternativa que puede ayudar a reducir la cantidad de datos de titulares de tarjetas en el medio ambiente, reduciendo potencialmente el esfuerzo del
comerciante para implementar los requisitos de PCI DSS.
Los siguientes principios clave se refieren al uso de tokenización y su relación con las PCI DSS:
• soluciones Tokenization no eliminan la necesidad de mantener y validar el cumplimiento de PCI DSS, pero pueden simplificar los
esfuerzos de validación de un comerciante al reducir el número de componentes del sistema para el que se aplican los requisitos de
PCI DSS.
• Verificación de la eficacia de una aplicación tokenización es necesario y confirmando que incluye PAN no es recuperable desde
cualquier componente del sistema retirado del alcance de PCI DSS.
• sistemas y procesos Tokenization deben protegerse con fuertes controles de seguridad y vigilancia para asegurar que
continúe la efectividad de esos controles.
• Tokenization soluciones pueden variar enormemente entre las distintas aplicaciones, incluyendo las diferencias en los modelos de
implementación, los métodos de tokenización y de-tokenización, tecnologías y procesos. Los comerciantes están considerando el uso
de tokenización deben realizar una evaluación de riesgos y análisis exhaustivo para identificar y documentar las características únicas
de su aplicación en particular, incluyendo todas las interacciones con los datos de tarjetas de pago y los sistemas particulares de
tokenización y procesos.
2 Tokenization general
Uno de los objetivos principales de una solución tokenización debería ser para reemplazar los valores PAN sensibles con los valores simbólicos no
sensibles. Por señal debe considerarse como no sensibles, y por lo tanto no requiere ningún tipo de seguridad o protección, el testigo debe tener
ningún valor para un atacante.
Fichas vienen en muchos tamaños y formatos. Los ejemplos de algunos formatos de fichas comunes se incluyen en la siguiente tabla.
Cuadro 1: Ejemplos de formatos de Token *
PAN Simbólico Comentario
Simbólico consiste en caracteres alfabéticos y

3124 005917 23387 7aF1Zx118523mw4cwl5x2
numéricos
Simbólico consiste en caracteres numéricos

4959 0059 0172 3389 729129118523184663129
solamente
Token consta de PAN truncada (primero 6, última
4 de PAN se retienen) con caracteres alfabéticos

5994 0059 0172 3383 599400x18523mw4cw3383
y numéricos sustitución de dígitos centrales.
* Nota: En esta tabla se ofrece una selección de ejemplos solamente, y no incluye todos
posibles formatos token.
Las fichas pueden ser generalmente identificadas como ya sea de un solo uso o de usos múltiples. Un token de un solo uso se utiliza típicamente para
representar una, sola transacción específica. Un token multi-uso representa un PAN específico, y puede ser utilizado para el seguimiento de un PAN
individuo a través de múltiples transacciones. Un token de usos múltiples se asignen siempre un valor PAN particular, con el mismo valor simbólico
dentro del sistema de tokenización. La determinación de si un solo uso o de usos múltiples fichas, o una combinación de ambos, son apropiadas para un
entorno de comerciante en particular dependerá de las necesidades de negocio específico del comerciante para retener fichas.
Al evaluar un sistema de tokenización, es importante tener en cuenta todos los elementos de la solución global tokenización. Estos
incluyen las tecnologías y los mecanismos utilizados para capturar los datos de titular de tarjeta y cómo una transacción avanza a
través del entorno de comerciante, incluyendo la transmisión al procesador / adquirente. La solución tokenización también debe
abordar los posibles vectores de ataque contra cada componente y proporcionar la capacidad de confirmar con la confianza de que los
riesgos asociados se abordan.
La seguridad y la robustez de un sistema de tokenización en particular es dependiente de muchos factores, incluyendo la
configuración de los diferentes componentes, la aplicación general, y la disponibilidad y la funcionalidad de las características de
seguridad para cada solución.
2.1 Componentes comunes del sistema Tokenization
2.1.1 Generación de emergencia
generación de tokens describe el proceso o método de creación de un contador. Las formas comunes de generación de tokens incluyen
pero no se limitan a:
• Una función criptográfica matemáticamente reversible, sobre la base de un conocido fuerte algoritmo criptográfico y fuerte
clave criptográfica (con un modo seguro de funcionamiento y mecanismo de relleno)
• Una función criptográfica no reversible de un solo sentido (por ejemplo, una función hash con sal fuerte, secreto)
• Asignación a través de una función de índice, número de secuencia o un número generado aleatoriamente (no derivada
matemáticamente a partir de la PAN)
Nota: Si una ficha se genera como resultado del uso de una función hash, entonces es un esfuerzo relativamente trivial para una
persona malintencionada para reconstruir los datos originales PAN si tienen acceso tanto a la versión truncada y hash del PAN. Donde
hash y versiones truncadas de la misma PAN están presentes en el medio ambiente, controles adicionales deben estar en su lugar
para asegurar que las versiones hash y truncadas no pueden ser correlacionados para reconstruir el PAN originales.
Sea cual sea el método de generación se utiliza, la recuperación de la PAN original no debe ser computacionalmente factible conociendo
sólo el token o un número de fichas. Esto es cierto tanto para un solo uso y fichas de usos múltiples. Además, el acceso a múltiples
pares-token-a PAN no debe permitir la capacidad de predecir o determinar otros valores del PAN a partir del conocimiento de sólo fichas. Las
fichas deben tener ningún valor si comprometido o robado, y deben ser inservible a un atacante si un sistema de almacenamiento de fichas
sólo se ve comprometida.
Tenga en cuenta que donde generación de tokens se basa en un método de cifrado reversible (en el que el contador se deriva
matemáticamente a partir de la PAN original a través de la utilización de un algoritmo de cifrado y la clave de cifrado), el token
resultante es un PAN cifrado, y pueden estar sujetos a PCI DSS consideraciones, además de los incluidos en este documento. El PCI
SSC está evaluando además cómo estas consideraciones pueden afectar alcance DSS PCI para los tokens reversibles, basado en
cifrado.
No se permite Tokenization de datos confidenciales de autenticación (incluyendo los datos de banda magnética o equivalente en un
chip, los datos CAV2 / CVC2 / CVV2 / CID, y los PIN / bloques PIN) por PCI DSS Requisito 3.2.
2.1.2 Mapeo de emergencia
mapeo de emergencia es el proceso de asignar un símbolo para el valor original de PAN. Cuando se envía un PAN a la tokenización,
el token generado y el PAN originales se almacenan normalmente en la bóveda de tarjetas de datos. mapeo de emergencia ofrece la
posibilidad de recuperar, ya sea una PAN en particular o una ficha particular, dependiendo de cómo se implementa la solución y el
tipo de solicitud.
La capacidad de recuperar una PAN a cambio de su token asociado debe limitarse a los individuos, las aplicaciones y / o sistemas
específicamente autorizado. Cualquier componente del sistema que se puede utilizar para recuperar datos PAN tendría que ser
protegidos de acuerdo con PCI DSS.
2.1.3 tarjeta de almacenamiento de datos
En un sistema de tokenización, la bóveda datos de la tarjeta (o vault‖ -Datos) es el repositorio central para sartenes y tokens y es
utilizado por el proceso de token-mapeo. Dondequiera que exista datos PAN, tiene que ser controlada y protegida de acuerdo con
los requisitos de PCI DSS.
Debido a que contiene PAN, así como fichas, la bóveda de datos a menudo se presenta el objetivo más atractivo para los atacantes.
Compromiso de la bóveda de datos podría resultar potencialmente en el compromiso de todo el sistema tokenización, y los controles de
seguridad adicionales más allá de los requeridos en PCI DSS puede ser garantizado.
2.1.4 Gestión de claves de cifrado
gestión de claves criptográficas define los procesos para crear, utilizar, gestionar y proteger las claves criptográficas utilizadas para la
protección de los datos PAN. Las claves criptográficas deben ser administrados y protegidos de acuerdo con los requisitos de PCI DSS.
En una solución tokenización, gestión de claves de cifrado se aplica a las claves utilizadas para cifrar PAN en la bóveda de datos de la
tarjeta, así como cualquier claves utilizadas en la generación de las mismas fichas.
Donde la generación de token se basa en el uso de claves criptográficas, el compromiso de las claves podría resultar en el compromiso de
todas las fichas actuales y futuros generados con dichas claves. Las claves criptográficas utilizadas para la generación de fichas y
de-tokenización por lo tanto no deberían estar disponibles para cualquier aplicación, sistema, usuario o proceso fuera del sistema
tokenización seguro.
2.2 Operaciones Tokenization
Hay numerosas maneras de implementar una solución tokenización. Como principio general, las operaciones de tokenización y
de-tokenización deben ocurrir sólo dentro de un sistema tokenización claramente definido que incluye un proceso para solicitudes
aprobadas para presentar solicitudes de tokenización y de-tokenización. La Figura 1 muestra un ejemplo de un proceso de
tokenización.
Figura 1: Ejemplo de alto nivel de un proceso de tokenización
Nota: Este es sólo un ejemplo que ilustra un proceso de tokenización posible. Cada solución debe ser evaluado individualmente
para entender sus procesos particulares y flujos de datos.
Los pasos que se ilustran en este ejemplo incluyen:
1. Una aplicación solicitante pasa un PAN, junto con la información de autenticación es necesario, a un sistema de tokenización.
2. El sistema de tokenización verifica la información de autenticación presentado por la aplicación solicitante. Si esta comprobación
falla, el proceso de tokenización falla, y la información se registra para el monitoreo. De lo contrario, el proceso continúa con el
Paso 3.
3. El sistema de tokenización genera o recupera si ya existe-un contador asociado a la sartén y registra tanto a la bóveda datos de la
tarjeta, según las exigencias de PCI DSS para el almacenamiento de PAN.
4. El sistema de tokenización devuelve el token generado o recuperado en el Paso 3 a la aplicación solicitante.
De-tokenización típicamente invierte los pasos del proceso de tokenización. Un ejemplo de un proceso detokenization se siembra en
la Figura 2 a continuación.
Figura 2: ejemplo de alto nivel de un proceso de de-tokenización
Nota: Este es un ejemplo que ilustra sólo una posible proceso de de-tokenización. Cada solución debe ser evaluado individualmente
para entender sus procesos particulares y flujos de datos.
Los pasos que se ilustran en este ejemplo incluyen:
1. La aplicación solicitante pasa a una ficha, junto con la información de autenticación necesaria, a un sistema de tokenización.
2. El sistema de tokenización verifica la información de autenticación presentado por la aplicación solicitante. Si esta comprobación
falla, el proceso de de-tokenización falla, y la información se registra para el monitoreo. De lo contrario, el proceso continúa con
el Paso 3.
3. El sistema de tokenización consulta la bóveda de datos tarjeta para un registro asociado con el token, recupera el PAN si lo
encuentra, y continúa en el paso 4. Si no existe tal modo, la operación falla detokenization, y la información se registra para el
monitoreo.
4. El sistema de tokenización devuelve el valor PAN recuperado de la bóveda de datos de la tarjeta, si se encuentra, a la aplicación
solicitante. Si no se encuentra el PAN, se devuelve un mensaje de error.
Nota: Si PAN es recuperable por el comerciante, el medio ambiente del comerciante estará en posibilidades de PCI DSS. Con el fin de minimizar
la presencia de datos de titulares de tarjetas en un segmento medio ambiente comerciante o red en particular, el comerciante no necesitaría o
tienen la capacidad para recuperar el PAN una vez que el contador ha sido generado.
1. Las comunicaciones entre la aplicación solicitante y el sistema tokenización debe fijarse a evitar la interceptación o captura de
datos de titulares de tarjetas o información de mapeo token-a-PAN.
2. Los controles de acceso y autenticación fuerte debe existir para todos los accesos al sistema de tokenización, ya sea para los datos
tokenizing o de-tokenizing, y las credenciales de autenticación debe estar asegurado contra el acceso o uso no autorizado.
3. Seguridad de la bóveda de datos de la tarjeta es crítico para la seguridad del sistema tokenización en su conjunto, y se debe asegurar como
mínimo de acuerdo a los requisitos de PCI DSS para proteger los datos de titulares de tarjetas.
4. Todos los componentes dentro del sistema tokenización (por ejemplo, la generación de tokens y proceso de mapeo, bóveda de
datos, y la gestión de claves criptográficas) deben estar situados en un entorno compatible PCI DSS.
5. Cualquier componente del sistema con acceso a datos de PAN, o que tiene la capacidad de recuperar una PAN, a cambio de una ficha,
debe estar ubicado en un entorno compatible con PCI DSS.
2.3 Consideraciones de seguridad Tokenization
2.3.1 Segmentación de red
El sistema tokenización se considera parte del entorno de datos de titulares de tarjetas de la entidad (CDE), y debe ser segmentado
requisitos de la Norma de Seguridad de Datos PCI. Algunas consideraciones clave que se destacan por estos ejemplos incluyen:
adecuadamente (aislado) de todas las redes no esté en posibilidades de PCI DSS. redes, aplicaciones, usuarios, procesos y componentes
del sistema fuera ofscope no deberán tener acceso a la autenticación de credenciales que se pueden utilizar para autenticarse en el sistema
de tokenización o cualquier parte de la CDE.
2.3.2 autenticación
Sólo los usuarios autenticados y los componentes del sistema debe permitir el acceso al sistema de tokenización y procesos
tokenización / DE-tokenización. El método de autenticación deberá clasificar todos los puntos finales, incluyendo, pero no limitado a las
aplicaciones, las personas, los procesos y sistemas, para garantizar el nivel apropiado de acceso se concede. Además, se debe
considerar a los siguientes artículos de autenticación cuando se evalúa una solución tokenización:
• Identificación - Proporciona el nivel requerido de confianza y seguridad de que la aplicación, el usuario, proceso o sistema que
solicita el acceso se identifican de forma única.
• Inscripción - Establece y asegura la unicidad de la identidad durante el aprovisionamiento de cuentas.
• Autenticación - Valida la identidad de la aplicación, el usuario, proceso o sistema en el momento de la solicitud.
La intención de este documento es proporcionar información suplementaria. La información proporcionada aquí no reemplazar o sustituir los 10
• Autorización - Verifica la aplicación autenticado, el usuario, se permite que el proceso o sistema para enviar una solicitud, acceder a
un recurso particular (tal como de datos), o llevar a cabo una actividad en particular.
• Terminación - Elimina o revoca la capacidad de una aplicación, el usuario, proceso o sistema para la autenticación con éxito.
• Mantenimiento - Permite la gestión continua de cuentas, incluyendo pero no limitado a la modificación y terminación.
2.3.3 Supervisión
El sistema debe proporcionar tokenización monitorización completa y sólida. tendrán que ser rastreados, vigilados y registrados de
conformidad con los requisitos de PCI DSS y todos los accesos a las acciones dentro del sistema de tokenización. Además, el monitoreo
del sistema tokenización debe ser suficiente para detectar y personal alerta a cualquier mal funcionamiento, las anomalías, y el
comportamiento sospechoso que puede indicar solicitudes irregulares token-a-PAN o PAN-a-token de mapeo o la presencia de actividad no
autorizada dentro de la proceso de tokenización. Algunos sistemas de tokenización se pueden configurar para estrangular o rechazar las
solicitudes anormales, lo que reduce la exposición potencial de la actividad no autorizada.
2.3.4 simbólico distinguibilidad
La solución tokenización debe incluir un mecanismo para distinguir entre tokens y sartenes reales. Distinguibilidad apoya la capacidad
de un comerciante para identificar sus activos de datos sensibles (en este caso, PAN), de modo que las protecciones de seguridad
adecuadas se pueden aplicar y verificados. Esto también facilita los esfuerzos comerciales y asesor para validar el alcance de la CDE
como parte de su revisión anual de PCI DSS.
Sin la capacidad de distinguir entre un PAN y un token, el comercio o proveedor de servicio puede no darse cuenta de que el sistema de
tokenización no está funcionando según lo previsto. Además, PAN podrían ser erróneamente identificados como fichas, que pueden
conducir a errores de determinación del alcance de la CDE y la posibilidad de que PAN quedan desprotegidos y abiertos al compromiso.
Tenga en cuenta que algunas fichas están diseñadas para imitar el tipo y formato de los moldes originales, y puede que no sea posible
que un revisor humano para distinguir entre los dos tipos de datos. En este caso, puede necesitar una herramienta específica para ser
utilizada o función realizada para verificar que un presunto testigo es en realidad un símbolo y no una PAN.
El mecanismo o método para distinguir entre tokens y sartenes para una solución tokenización particular, deben ser compartidos con
los comerciantes utilizando esa solución, para permitir que los comerciantes la capacidad de verificar que su CDE se ha definido con
precisión y de ámbito.
2.3.5 Requisitos de las PCI DSS
Debido a que el sistema almacena tokenización, procesos y / o transmite los datos de titulares de tarjetas, se debe instalar, configurar y
mantener de una manera compatible con PCI DSS. Características de un sistema de tokenización que cumpla con los requisitos de PCI
DSS incluyen pero no se limitan a los siguientes:
1. El sistema de tokenización no proporciona ninguna PAN en respuesta a cualquier aplicación, sistema, red o usuario fuera del
CDE definido del comerciante.
2. Todos los componentes de tokenización se encuentran en las redes internas seguras que están aislados de cualquier no es de confianza y
redes fuera de alcance.
Se permiten las comunicaciones 3. Sólo de confianza dentro y fuera del entorno del sistema tokenización.
4. La solución tokenización hace cumplir los protocolos de seguridad y criptografía fuerte para proteger los datos de titulares de tarjetas cuando se
almacena y durante su transmisión a través de redes públicas abiertas.
5. La solución tokenización implementa fuertes controles de acceso y las medidas de autenticación de acuerdo con los requisitos de
PCI DSS 7 y 8.
6. Los componentes del sistema tokenización están diseñados para los estándares de configuración estrictas y están protegidos de
vulnerabilidades.
7. La solución tokenización soporta un mecanismo para la eliminación segura de datos de titulares de tarjetas como es requerido por una política de
retención de datos.
8. La solución tokenización implementa el registro, seguimiento, y alertando según sea apropiado para identificar cualquier actividad
sospechosa e iniciar los procedimientos de respuesta.
2.4 Funciones y responsabilidades Tokenization
Las consideraciones de seguridad examinado en el apartado anterior se aplican a la solución tokenización en su conjunto. Roles y
responsabilidades para una solución tokenización pueden ser distribuidos entre los diferentes grupos de interés que normalmente es el
proveedor de servicio de comerciante y tokenización (TSP) - dependiendo de su implementación o despliegue modelo en particular.
2.4.1 Modelos de implementación Tokenization
Ejemplos de implementaciones comunes de una solución tokenización incluyen los siguientes:
• Una solución in situ o en la casa que un comerciante maneja dentro de su infraestructura de TI
• Una solución externa para el cual una gestión delegados mercantes a un proveedor de servicios tokenización fuera de
la infraestructura y el control del comerciante
• Una solución híbrida que combina algunos componentes en las instalaciones con algunos componentes subcontratados
Para una solución tokenización externalizado o híbrido, la responsabilidad de que algunos componentes del sistema cumplir con PCI DSS
se pueden transferir parcialmente a partir de un comerciante a un tokenización
proveedor de servicios (TSP). En concreto, esto incluiría los componentes del sistema de tokenización que son gestionados por el
proveedor de servicios y están fuera del control del comerciante.
A modo de ejemplo, si un comerciante externaliza su bóveda de datos que contiene la tarjeta de PAN cifrados a un TSP, el TSP sería
responsable de asegurar que los controles de PCI DSS se aplican y se mantienen en el entorno donde se encuentra la bóveda. Los
comerciantes que planean utilizar una solución externalizada tokenización o híbrido para su CDE deben asegurarse de que
comprenden a fondo los detalles de la solución que se ofrece. Esto debe incluir la realización de una evaluación detallada de los
riesgos potenciales asociados con el uso de la solución. Además, es crucial que ambas partes entienden que controla y requisitos son
su responsabilidad, y que son responsabilidad de la otra parte. Las responsabilidades para el mantenimiento de los requisitos de PCI
DSS, y cualquier otro control que podrían afectar a la seguridad de los datos de los titulares, deben estar claramente definidos entre
las dos partes y se documentan en un acuerdo formal.
En una solución tokenización en las instalaciones, el comerciante mantiene el control sobre todos los componentes del sistema de
tokenización. En este escenario, el comerciante es totalmente responsable de cumplir con todos los requisitos aplicables de PCI DSS.
Comerciantes con soluciones en las instalaciones también tendrán que verificar los controles de segmentación que se implementan entre
su solución tokenización y cualquier otra red o sistemas outof-alcance. Antes de que un sistema o red pueden considerarse fuera del
alcance de PCI DSS, primero se debe verificar que el sistema / red no está conectado al CDE y que no puede recuperar los datos o el
acceso PAN u otra cuenta.
La Figura 3 ilustra un ejemplo de cómo responsabilidades pueden diferir entre comerciante y TSP, dependiendo de cómo se
implementa la solución.
Figura 3: Ejemplo de cómo comerciante y responsabilidades TSP pueden ser asignados para On-
premisa, híbridos y soluciones externalizadas
Nota: Algunos de los requisitos de PCI DSS se aplicarán al comerciante, incluso cuando una solución tokenización es compartida con otros o híbrido.
Por ejemplo, los controles de PCI DSS se aplicarán siempre que el PAN es procesada, almacenada o transmitida -como en el punto de captura, así
como en cualquier punto de-tokenización. Además, se requiere que el comerciante para implementar y mantener políticas y procedimientos para
administrar los proveedores de servicios cada vez que se comparte datos de titulares de tarjetas.
2.4.2 Responsabilidades Merchant
El comerciante tiene la responsabilidad última de la correcta aplicación de cualquier solución tokenización que utilizan,
incluyendo su despliegue y funcionamiento. Por otra parte, el comerciante es responsable de la validación de su entorno
tokenización como parte de su evaluación anual de cumplimiento de PCI DSS.
nivel de responsabilidad de la solución tokenización del comerciante puede variar en función del grado en que el comerciante maneja
ellos mismos o ha externalizado algunos o todos los componentes de la solución tokenización. Dependiendo de la implementación de la
solución tokenización, las responsabilidades del comerciante pueden incluir, pero no están limitados a algunos o todos de los siguientes:
• Asegúrese de que la división de la responsabilidad de la protección de datos de titulares está debidamente con ámbito y ejecutada.
• Verificar la adecuación de los controles de segmentación si estos controles no son parte de la solución suministrada.
• Realizar una evaluación de riesgos como parte de su diligencia debida al seleccionar un proveedor de servicios de tokenización. Los
comerciantes deben buscar un proveedor con los procesos de seguridad maduros que es capaz de proporcionar el nivel de seguridad
requerido, así como proporcionar la verificación de que los controles de seguridad definidos operatividad y eficacia.
• Asegúrese de que los acuerdos contractuales adecuados están en su lugar, con el proveedor de servicios tokenización reconociendo que el
proveedor de servicios es responsable de la seguridad de los datos de titulares de tarjetas procesados, almacenados y / o transmitidos por el
proveedor de servicios.
• Mantener y poner en práctica políticas y procedimientos para gestionar el proveedor de servicios de tokenización, incluido el seguimiento de su
estado de cumplimiento de PCI DSS al menos anualmente.
• Compruebe que la solución soporta y hace cumplir los requisitos de PCI DSS y la política de seguridad del comerciante,
incluyendo pero no limitado a:
o la retención y eliminación de datos
o control de acceso y autenticación
o políticas de uso
o La gestión de vulnerabilidades
o Registro, supervisión y alertas
• revisar los registros de interacción del comerciante con los sistemas y procesos de tokenización sobre una base regular para
asegurar que sólo los usuarios autorizados y componentes del sistema por el comerciante tienen acceso a los procesos de
tokenización / DE-tokenización.
• Asegúrese de que los planes de respuesta a incidentes y recuperación de desastres adecuadas están en su lugar para la posibilidad de
pérdida o compromiso del sistema tokenización. Los siguientes elementos deben ser considerados como parte de estos planes:
o Un análisis de riesgo de todos los componentes del sistema en el estudio para determinar el impacto de una
compromiso.
o Un análisis de riesgo para todos los componentes del sistema fuera de alcance que procesar, almacenar o transmitir
fichas para comprobar que no tienen acceso al sistema de tokenización o para datos de PAN, y para evaluar el impacto
de un compromiso de los datos tokenizados de esos sistemas.
o Estrategias para la recuperación en caso de un incidente o compromiso. Los ejemplos pueden

incluyen pero no se limitan a rechazar las solicitudes de supresión de tokenización de sistemas en riesgo, fichas
reemisión, y volver a cifrar PAN en la bóveda de datos con nuevas claves criptográficas.
Los comerciantes utilizando una solución tokenización híbrido o en las instalaciones pueden asumir el papel de un TSP dentro de su propia
organización, resultando en algunas o todas las responsabilidades de TSP (descritos más adelante) también es aplicable al comerciante.
2.4.3 Responsabilidades TSP
El TSP tiene la responsabilidad general para el diseño de una solución efectiva tokenización. Cuando un TSP gestiona uno o más
componentes de una solución tokenización en nombre de otros comerciantes, las responsabilidades adicionales pueden incluir, pero no
se limitan a algunos o todos de los siguientes:
• Verificar la seguridad de todos los componentes de tokenización bajo su control, de acuerdo con los requisitos de PCI DSS.
• Asegúrese de que la solución tokenización apoya el cumplimiento de PCI DSS de los clientes del TSP. Por ejemplo, la solución debería
proporcionar una transmisión segura de datos de titulares de tarjetas entre el cliente y el TSP, hacer cumplir los mecanismos de
autenticación seguras para las peticiones del cliente, implementar políticas de control de acceso de los clientes, etc.
• Asegúrese de que la solución tokenización es compatible con la asignación de responsabilidades de las PCI DSS entre el TSP y
sus clientes. Por ejemplo, la solución no debe volver PAN a un cliente sin el permiso expreso del cliente y el reconocimiento de
cómo esta acción podría afectar a la responsabilidad del cliente para asegurar los datos de titulares de tarjetas y para la
validación de los controles de PCI DSS.
• Asegúrese de que la responsabilidad de mantener y verificar los controles de PCI DSS están claramente definidos entre el cliente
y el TSP, y estas responsabilidades se documentan en un acuerdo de servicio tokenización.
• Desarrollar y proporcionar documentación a los clientes para ayudar en la correcta instalación, implementación y uso
de la solución tokenización.
El TSP deberán identificar claramente qué requisitos de PCI DSS, los componentes del sistema y los servicios están cubiertos por el
programa de cumplimiento de PCI DSS del TSP. Todos los aspectos de la solución no cubiertos por el TSP son responsabilidad del
comerciante para gestionar y evaluar. El TSP debe proporcionar suficiente evidencia y seguridad de que todos los procesos y
componentes bajo su control son compatibles con PCI DSS.
En resumen, un TSP debe asegurar su solución tokenización cumple todos los requisitos aplicables de PCI DSS, apoya a sus clientes los
esfuerzos de cumplimiento de PCI DSS, y ayuda a reducir al mínimo sus clientes necesidad de almacenar o acceder a datos de titulares de
tarjetas.
La intención de este documento es proporcionar información suplementaria. La información proporcionada aquí no reemplazar o sustituir los requisitos de dieciséis

3 Consideraciones de ámbito PCI DSS
requisitos de PCI DSS se aplican a todos los componentes del sistema dentro o conectados al CDE. El CDE se compone de personas,
procesos y tecnología que procesan, almacenan o transmiten datos de titulares de tarjetas o datos confidenciales de autenticación. Para
reducir el alcance de una evaluación de las PCI DSS, muchas organizaciones tratan de minimizar el número de componentes del sistema
que se incluyen en o conectados al CDE. Por ejemplo, la segmentación de la red, que aísla los sistemas que almacenan, procesan o
transmiten datos de titulares de tarjetas de las que no lo hacen, pueden reducir el alcance de la CDE, y por lo tanto el alcance de una
evaluación PCI DSS.
En general, tokenización puede proporcionar un modelo para centralizar el almacenamiento de datos de titulares de tarjetas y reducir al mínimo el
número de ocurrencias de datos de titulares de tarjetas en un entorno. Una solución tokenización se aplica adecuadamente puede reducir o eliminar
la necesidad de un comerciante para retener PAN en su entorno una vez que la transacción inicial ha sido procesada. Con controles de
segmentación y de procesos adecuados, una solución tokenización podría ayudar a minimizar el número de componentes del sistema de comercio
que necesitan ser protegidos de acuerdo con la norma PCI DSS.
3.1 PCI DSS Ámbito de Tokenization
Todos los elementos del sistema de tokenización y proceso, incluyendo de-tokenización y almacenamiento PAN, se consideran parte del entorno
de datos de titulares de tarjetas (CDE) y por lo tanto son de alcance para PCI DSS. Además, cualquier componente del sistema o proceso con el
acceso al sistema tokenización o el proceso de tokenización / de-tokenización se considera en su alcance. Los componentes del sistema que
están segmentados adecuadamente (aislado) del sistema de tokenización y el CDE; y que almacenan, procesan o transmitir sólo tokens; y que
no almacenar, procesar o transmitir cualquier datos de titulares de tarjetas o datos confidenciales de autenticación, puede considerarse fuera de
la CDE y posiblemente fuera del alcance de PCI DSS. En esta sección se proporcionan algunas directrices de alto nivel para la determinación
del alcance una solución tokenización para PCI DSS.
3.1.1 Principios de ámbito
Cuando la determinación del alcance de un entorno tokenización para PCI DSS, se aplican los siguientes principios generales:
• Todos los componentes de un sistema tokenización se consideran parte de la CDE y están siempre en su alcance, ya que almacenar,
procesar y / o transmiten datos de titulares de tarjetas.
• Los componentes del sistema que proporcionan la capacidad de realizar cualquiera de las siguientes funciones son en su alcance:
o Generar un token a cambio de un PAN
o Canjear un PAN a cambio de una ficha
• Cualquier componente del sistema o proceso con el acceso al sistema tokenización o procesos tokenización / detokenization se
considera en su alcance, ya que está conectado a la CDE.
• Cualquier otro componente del sistema situado dentro o conectado al CDE, incluso si no lleva a cabo las operaciones de
tokenización o de-tokenización, es en su alcance.
3.1.2 Consideraciones llegada fuera del alcance
Para ser considerado fuera del alcance de PCI DSS, fichas, y los componentes del sistema que almacenan, procesan y / o transmitir sólo las
fichas que también es necesario para cumplir con los objetivos siguientes:
• Recuperación del valor PAN asociado con un contador no debe ser computacionalmente factible a través del conocimiento de
sólo el contador, múltiples fichas, u otras combinaciones-token-a PAN.
• PAN no puede ser recuperada, incluso si el token y los sistemas que reside se vean comprometidos.
• Los componentes del sistema se dividen en segmentos (aislado) de cualquier aplicación, sistema, proceso o usuario con:
o La posibilidad de presentar una solicitud de-tokenización para esa señal y recuperar el PAN;
o El acceso al sistema tokenización, bóveda de datos o claves criptográficas para esa señal;
o Token de acceso a los datos de entrada u otra información que se pueden utilizar para de-tokenize o derivar
el valor PAN del token.
• Los componentes del sistema no están conectados al sistema o procesos tokenización, incluyendo la bóveda de datos, o el almacenamiento de
claves criptográficas.
• Los componentes del sistema que no se encuentran dentro o conectados al CDE, ni tienen acceso a las credenciales de
autenticación que se pueden utilizar para autenticarse en cualquier parte del CDE.
• Los componentes del sistema no almacenan, proceso o transmiten datos de titulares de tarjetas o datos confidenciales de
autenticación a través de cualquier otro canal.
• Los componentes del sistema que previamente almacenados, procesada o transmitida de datos de titulares de tarjetas antes de la implementación de
la solución tokenización se han examinado para asegurar que todos los rastros de datos de titulares de tarjetas se han eliminado de forma segura.
Reducción Alcance 3.2 Maximización de PCI DSS
La clave para los comerciantes que deseen reducir su alcance de PCI DSS es no almacenar, procesar o transmitir datos de titulares de tarjetas.
Donde hay una necesidad de almacenar datos de titulares de tarjetas, la retención debe limitarse a lo que se requiere para los negocios, legales
y / o con fines de regulación. Si no lo necesita, no lo guarde!
Si se utilizan fichas para reemplazar PAN en el entorno comercial, tanto las fichas y los sistemas en los que residen tendrán que ser
evaluados para determinar si requieren protección y deben estar en posibilidades de PCI DSS. Como se describió anteriormente, los
componentes del sistema de manipulación fichas que puede ser canjeado por un PAN o que pueden ser des-tokenizados para producir
el PAN sería en su alcance. Cualquier sistema conectados al sistema tokenización o el CDE también serían en su alcance. Para ser
considerado fuera del alcance de PCI DSS, tanto las fichas y los sistemas en los que residen tendría que tener ningún valor para un
atacante intentar recuperar PAN, ni deben de ninguna manera ser capaces de influir en la seguridad de los datos del titular o la CDE.
Como parte de la validación anual alcance de PCI DSS, los comerciantes deben revisar su uso de fichas para asegurar que los datos
de titulares de tarjetas no está fuera recuperable del CDE definido. También debe ser verificada que se utilizan fichas según lo
previsto, y que los sistemas considerados fuera de alcance se segmentan adecuadamente del CDE.
recomendaciones adicionales para maximizar la reducción de alcance para un entorno de comerciante incluyen los siguientes:
• Reemplazar el almacenamiento PAN con fichas siempre que sea posible;
• Limitar existencia de PAN hasta el punto de captura y la bóveda datos de la tarjeta;
• Minimizar el número de componentes del sistema que almacenan, procesan o transmitir PAN antes de la PAN siendo tokenized;
• Asegúrese de que PAN no está presente en mismo entorno que las fichas, fuera de la bóveda datos de la tarjeta;
• Asegúrese de que todos PAN y otros datos de titular de tarjeta se retira de los sistemas de código una vez que ha sido tokens;
• Elija una solución que garantiza PAN no es recuperable una vez una ficha ha sido emitido; por ejemplo:
o La solución tokenización no permite un contador para ser intercambiado por un valor PAN.
o El sistema no proporciona tokenización PAN al comerciante en cualquier respuesta.
o Una vez que un contador se ha emitido, todas las nuevas operaciones o de procesamiento (por ejemplo,
reembolsos, devolución de cargo, el seguimiento de la lealtad, etc.) pueden llevarse a cabo sin la necesidad de que el comerciante para
recuperar o acceder al PAN.
• Hacer cumplir la separación de funciones tales que los usuarios y los administradores de fichas no tienen acceso al PAN en el punto de
captura o en otra parte;
• Combinar una solución tokenización eficaz, segura con cifrado de punto a punto (P2PE), de manera que los únicos sartenes en el
medio ambiente están contenidos dentro de un dispositivo seguro, aprobado por la PTS en el punto de interacción (POI).
Nota: Si una ficha se puede utilizar para generar una transacción, pueden ser necesarias medidas adicionales de seguridad para proteger
contra el uso fraudulento de la ficha. Consulte “tokens como medios de pago” en la Sección 4 para obtener más información.
4 Consideraciones adicionales
4.1 Fichas como medios de pago
Una consideración importante cuando se evalúa una solución tokenización es si el token de sí mismo se puede utilizar en lugar de los datos de
titulares de tarjetas para realizar una transacción. Tokens que pueden ser utilizados como instrumentos de pago (a veces llamados -Alta-valor
tokens‖) potencialmente podría ser -monetized‖ o usados para generar transacciones fraudulentas, y por lo tanto pueden tener el mismo valor
para un atacante como los datos que están destinados a sustituir. Tokenization soluciones que apoyan este tipo de fichas deben tener
controles adicionales en el lugar para detectar y prevenir actividades fraudulentas intentos. Además, las fichas que se pueden utilizar para
iniciar una transacción pueden ser de alcance para PCI DSS, incluso si no pueden directamente pueden utilizar para recuperar PAN u otro
titular de la tarjeta; Por lo tanto, los comerciantes deben consultar con su adquirente y / o las marcas de pago directamente a determinar los
requisitos específicos para los tokens que pueden ser utilizados como instrumentos de pago.
4.2 Comprender los riesgos
Tokenization es una tecnología en evolución, y como con muchas tecnologías en desarrollo, en la actualidad existe una falta de estándares de la
industria para la implementación de soluciones de tokenización seguras. Las organizaciones deben evaluar cuidadosamente cualquier solución
antes de la implementación para comprender plenamente el impacto potencial de la CDE.
La arquitectura, la aplicación, y despliegue de soluciones de tokenización puede variar considerablemente, y los riesgos ya sea creados o
mitigarse estos sistemas son igualmente variada. Además, es probable que aumenten las amenazas a los sistemas de tokenización la llegada de
nuevos vectores de ataque. Estos factores hacen que mientras que un sistema de tokenización puede ser segura contra los ataques más
conocidos hoy en día, puede llegar a ser vulnerables a ataques creados en el futuro. Los comerciantes y los proveedores de servicios deben
continuar monitoreando para las nuevas amenazas y riesgos potenciales para su uso actual de tokenización.
Al evaluar una solución tokenización, tenga en cuenta que estas soluciones pueden introducir sus propias amenazas específicas y problemas de
seguridad. Al igual que con cualquier tecnología en evolución, se debe tener cuidado para comprender los riesgos asociados y evitar situaciones
que pueden dar lugar a riesgos de datos de titulares de tarjetas.
5. Conclusión
Tokens y soluciones tokenización se pueden implementar de muchas maneras, y los controles de seguridad o de proceso proporcionados por
una solución puede no ser adecuado o aplicable a otro. Además, la asignación de funciones y responsabilidades puede variar de acuerdo con
el método de solución o de despliegue en particular, y todas las entidades involucradas debe ser consciente de sus obligaciones para el
mantenimiento de los controles de seguridad y protección de los datos de titulares de tarjetas.
También tendrá que ser evaluado cuidadosamente para cada aplicación el nivel de reducción de las PCI DSS alcance que ofrece una solución
tokenización. Por ejemplo, las ubicaciones y los flujos de datos de titulares de tarjetas, la adecuación de la segmentación, y los controles en los
alrededores de los procesos de-tokenización y cartografía deben ser revisados y verificados para asegurar alcance adecuado de la aplicación
CDE y adecuada de los requisitos de seguridad PCI DSS.
6 Agradecimientos
El PCI SSC desea reconocer la contribución del Grupo de Trabajo Tokenization, antes parte del alcance del Grupo de Interés Especial
(SIG), en la preparación de este documento. El Tokenization grupo de trabajo formado por representantes de las siguientes
organizaciones:
3DSI nuBridges
appsec Soluciones de seguridad Patrick Townsend
Barnes & Noble Colegio Librero, LLC Paymetric Inc
BT Counterpane PayPal
Canadian Tire Corporation Limited PCI SSC
Canadian Tire Servicios Financieros Conocimiento
Cápita Group Plc propay
CipherOptics Protegrity
Sistemas Coalfire PWC
cybersource Rogers Communications
DSW Inc. RSA
Elavon S1 Corporación
FIS Global Las métricas de seguridad
Mallas de Seguridad Semtek
Contraste Shift 4
HSBC Swedbank Card Services AB
IBM Tesco
Illumis La hebilla Inc.
Información de Riesgos Gestión Plc El College Board
Ingenico T-Mobile
Intel La verdadera seguridad digital
Foro de Normas Internacionales de patio delantero Trustwave
John Lewis Plc US Bank
Las innovaciones clave Verifone
Marks & Spencer Verizon
comerciante de Enlace Verizon Business
MTXEPS Inc VFC
Nelnet Business Solutions (anteriormente InfiNet) Tensión
Nettitude laboratorios Witham
Nike WNCO
7 Sobre el PCI Security Standards Council
La misión del PCI Security Standards Council es mejorar la seguridad de la cuenta de pago por la educación y el conocimiento de la
Norma de Seguridad de Datos PCI y otras normas que aumentan la seguridad de los datos de pago de conducción.
El PCI Security Standards Council fue formada por las principales marcas de tarjetas de pago American Express, Discover Financial
Services, JCB International, MasterCard Worldwide y Visa Inc. para proporcionar un foro transparente en el que todos los interesados
puedan aportar información al continuo desarrollo, mejoramiento y difusión de la PCI Data Security Standard (DSS), PIN de seguridad
Requisitos de transacción (PTS), y el pago Estándar de Seguridad de datos de programa (PA-DSS). Se anima a los comerciantes,
bancos, procesadores y proveedores de puntos de venta a unirse como Organizaciones Participantes.

Tokenization Guidelines Info Supplement - En.es

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tokenization Guidelines Info Supplement - En.es

Uploaded by

Copyright:

Available Formats

Estándar: PCI Data Security Standard (PCI DSS)

Autor: La determinación del alcance SIG, Consejo de Estándares de

Suplemento información: DSS Directrices

1 Resumen ejecutivo ................................................ .................................................. .......... 3

1.1 ................................................. objetivo .................................................. ................ 3

1.2 Público objetivo................................................ .................................................. 3 ..

1.3 Introducción a Tokenization ............................................... ...................................... 3

2 Tokenization general ................................................ .................................................. ..... 5

2.1 Tokenization componentes comunes del sistema de .............................................. ............. 6

2.1.1 Generación de emergencia ................................................ ..................................... 6

2.1.2 Mapeo de emergencia ................................................ ......................................... 7

2.1.4 Criptográfica de administración de claves ............................................... ............... 7

2.2 Operaciones Tokenization ................................................ .......................................... 8

2.3 Consideraciones de seguridad Tokenization ............................................... ..................... 10

2.3.1 La segmentación de la red ................................................ ............................ 10

2.4 Los roles y responsabilidades Tokenization .............................................. .................. 12

2.4.1 Modelos de implementación Tokenization ............................................... ............ 12

2.4.2 Responsabilidades mercantes ................................................ ....................... 14

3 Consideraciones de ámbito PCI DSS .............................................. ..................................... 17

3.1 PCI DSS Ámbito de Tokenization ............................................. .............................. 17

3.1.1 La determinación del alcance Principios ................................................ .................................. 17

3.1.2 Fuera del Alcance Consideraciones ............................................ ..................... 18

4 Consideraciones adicionales ................................................ ............................................... 20

4.1 Fichas como medios de pago .............................................. .............................. 20

4.2 Comprender los riesgos ............................................... ......................................... 20

5 Conclusión ................................................. .................................................. ..................... 21

6 Agradecimientos ................................................. .................................................. ......... 22

7 Sobre el PCI Security Standards Council ............................................ ........................ 23

cualquier tecnologías, productos o servicios específicos.

de soluciones también pueden encontrar la información de este documento útil.

1.3 Introducción a la Tokenization

comerciante para implementar los requisitos de PCI DSS.

cualquier componente del sistema retirado del alcance de PCI DSS.

continúe la efectividad de esos controles.

ningún valor para un atacante.

Cuadro 1: Ejemplos de formatos de Token *

PAN Simbólico Comentario

Simbólico consiste en caracteres alfabéticos y

Simbólico consiste en caracteres numéricos

Token consta de PAN truncada (primero 6, última

4 de PAN se retienen) con caracteres alfabéticos

riesgos asociados se abordan.

La seguridad y la robustez de un sistema de tokenización en particular es dependiente de muchos factores, incluyendo la

seguridad para cada solución.

2.1 Componentes comunes del sistema Tokenization

2.1.1 Generación de emergencia

clave criptográfica (con un modo seguro de funcionamiento y mecanismo de relleno)

matemáticamente a partir de la PAN)

2.1.2 Mapeo de emergencia

protegidos de acuerdo con PCI DSS.

2.1.3 tarjeta de almacenamiento de datos

los requisitos de PCI DSS.

2.1.4 Gestión de claves de cifrado

2.2 Operaciones Tokenization

Figura 1: Ejemplo de alto nivel de un proceso de tokenización

Los pasos que se ilustran en este ejemplo incluyen:

tarjeta, según las exigencias de PCI DSS para el almacenamiento de PAN.

4. El sistema de tokenización devuelve el token generado o recuperado en el Paso 3 a la aplicación solicitante.

Figura 2: ejemplo de alto nivel de un proceso de de-tokenización

Los pasos que se ilustran en este ejemplo incluyen:

solicitante. Si no se encuentra el PAN, se devuelve un mensaje de error.

datos de titulares de tarjetas o información de mapeo token-a-PAN.

debe estar ubicado en un entorno compatible con PCI DSS.