Anda di halaman 1dari 6

pci dss

opinión

Fundamentos de 'tokenización'
y el cumplimiento de PCI DSS
de protección de información confi- El ámbito de uso de estos disposi-
dencial son: tivos es bastante amplio, permitiendo
X Uso de técnicas de hash (cifrado minimizar el riesgo y el entorno invo-
no reversible). lucrado en la gestión de información
X Cifrado simétrico y asimétrico. sensible y cubriendo requerimientos
X Truncamiento. legales, operativos y administrativos:
X Trasposición. protección de información de carácter
X Enmascaramiento. personal (LOPD), datos de seguridad
X 'Tokenización'. social, información clínica, patentes y
datos de tarjetas de pago -a los que
Dependiendo de las necesidades afecta la normativa Payment Card
específicas, se puede optar por la Industry Data Security Standard (PCI
implementación de uno u otro meca- DSS)-, entre otros.
nismo e incluso un conjunto de ellos. A lo largo del escrito se describirá el
David Eduardo En este artículo se enfocará el análisis proceso general vinculado a la arqui-
en el concepto de "tokenización” o tectura y gestión del ciclo de vida de
Acosta uso de tokens1: valores únicos aso- los componentes de la 'tokenización',
Consultor senior de Seguridad de la ciados a datos confidenciales que así como la aplicación de esta técnica
Información de Internet Security Auditors son empleados como reemplazo de en un ambiente de cumplimiento nor-
estos últimos, con la característica mativo, poniendo especial énfasis en
diferencial de que el token no permite la norma de protección de datos de
Con el objetivo de proteger la infor- inferir el dato confidencial con el que tarjetas de pago PCI DSS.
mación confidencial que se almace- se relaciona, minimizando de esta La arquitectura básica de un siste-
na, se transmite y se procesa en un manera el riesgo de almacenamiento ma de 'tokenización' contempla tres
entorno corporativo, existen diversas inseguro y la necesidad de imple- componentes principales: una base de
alternativas técnicas para hacer ile- mentación de controles asociados a datos maestra centralizada, un servi-
gibles dichos datos y evitar que sean datos confidenciales, ya que el token cio de cifrado/'tokenización' e interfa-
visualizados por personal no autori- en sí no es catalogado como un dato ces de comunicación. Veamos dichos
zado. Algunos de esos mecanismos confidencial. componentes con más profundidad:

La BD maestra, centralizada
Posterior a la realización de un proce-
so interno de identificación y depura-
ción de datos confidenciales dentro
del entorno afectado (tal como se
explicará más adelante), los datos
confidenciales que tienen que ser pro-
tegidos deben ser centralizados en
una única base de datos (BD) o repo-
sitorio seguro (Data Vault, en inglés).
Junto con cada dato a ser protegido
se debe relacionar su token corres-
pondiente, garantizando su referencia
única. Esta base de datos deberá

Nota 1: A lo largo del texto se hará


referencia a “token” y “tokenización” por
ser palabras más difundidas en el ámbito
técnico. Sin embargo, su uso correcto
en castellano debería ser “testigos” y
“uso de testigos”, debido a su similitud
con las carreras de relevos.

88 red seguridad noviembre 2010


pci dss opinión

contemplar los siguientes controles


de seguridad:
o Aislamiento: Al ser el único ele-
mento que almacena datos confi-
denciales y que contiene la referencia
entre token y dato confidencial, la
base de datos maestra requiere ser
aislada del resto de componentes
del sistema. Aquellas interfaces de
comunicación de entrada/salida de
datos de la base maestra deben ser
controlados y securizados.
o Cifrado: Debido a que almace-
na datos confidenciales, la base de
datos maestra debe contener esta
información cifrada, cubriendo todos
los controles relacionados con gestión
de claves, custodia y copia de segu-
ridad. Es importante tener en cuenta
que los controles de 'tokenización' y
cifrado son complementarios y no son
excluyentes.
o Alcance: El token y su referencia la continuidad de la operación en
al dato confidencial deben ser válidos caso de problemas. Figura 1: Esquema de
tokenización: La base de datos
únicamente para un entorno limitado.
se encuentra aislada del resto de
Esto garantiza que, en el caso hipo- Servicio de cifrado/'tokenización' sistemas y mantiene mantiene
tético de que el listado completo de El proceso operativo de 'tokenización' una estructura de pares “dato
tokens y referencias sea comprome- consta de dos partes: confidencial–token”, donde “dato
tido, esta información no tendrá valor v Cifrado/descifrado de la informa- confidencial” se almacena cifrado.
alguno fuera del entorno definido. En ción confidencial almacenada en la
el caso de que se requiera compar- base de datos maestra centralizada.
tir el dato confidencial con un ente v Asignación de un token a dicho
externo, se recomienda implementar dato cifrado. legales y recepción de datos para ser
rutinas de conversión token-a-token 'tokenizados'). Por lo general, estas
y no entregar o compartir los datos Por lo tanto, se requiere de un interfaces están basadas en llama-
confidenciales ni permitir acceso no servicio que provea el cifrado/desci- das a conectores entre componentes,
controlado a la base de datos maes- frado de la información almacenada Applications Programming Internet
tra centralizada. en la base de datos y que gestione (API), Web Services, etc. Cualquier
o Autenticación, Autorización y la asignación y referencia de tokens entrada o salida desde o hacia estas
Registro (AAA): Únicamente el per- uno-a-uno con dicha información en interfaces deben ser registradas, defi-
sonal aprobado por la organización los procesos de entrada y salida de niendo controles de acceso específico,
debe poder tener acceso a la base datos confidenciales. seguridad en el transporte y acciones
de datos maestra centralizada y su Estos componentes (cifrado y 'toke- en caso de eventos sospechosos.
autenticación debe ser robusta, para nización') pueden estar contenidos Teniendo en cuenta que un dato
prevenir accesos no autorizados. dentro de un mismo servidor o separa- 'tokenizado' no es información con-
Igualmente, es requerido implementar dos, permitiendo independizar la ope- fidencial per se, cualquier otro control
mecanismos de monitorización sobre ratividad si se considera necesario. que se aplique para la protección
la base de datos maestra con el fin de de esta información en el resto de la
identificar cualquier actividad anómala Interfaces de comunicación infraestructura dejará de ser obligato-
o sospechosa en las peticiones de Finalmente, se encuentran las interfa- rio y pasará a ser recomendable.
conversión token-dato confidencial y ces de comunicación que engloban Todo el proceso se puede ver en la
mantener trazabilidad sobre transac- cualquier conexión entre componen- Figura 1: Se cuenta con una base de
ciones y acciones realizadas. tes internos (componente de cifrado, datos centralizada, la cual se encuen-
o Disponibilidad: Al convertirse en componente de 'tokenización' y lla- tra aislada del resto de sistemas en el
punto único de fallo y ser altamente madas a la base de datos) y aplicacio- entorno informático. Cualquier entrada
crítica para la gestión de la organiza- nes externas (rutinas de recuperación o salida de datos es registrada. La
ción, se debe disponer de una estra- para aquellos procesos que lo requie- base de datos mantiene una estructu-
tegia de disponibilidad que garantice ren por consideraciones de negocio o ra de pares “dato confidencial–token”,

red seguridad noviembre 2010 89


pci dss
opinión

donde “dato confidencial” se almace- para evitar la generación no autorizada aplicaciones y en consultas para ges-
na cifrado. Internamente se realizan de este tipo de dispositivos. tionar esta nueva información con un
las subrutinas de cifrado/descifrado y Igualmente –y con el fin de mini- nuevo formato.
generación/asignación de tokens. En mizar el impacto en el procesamien- Para solucionar esta situación,
la salida de tokens aplican los contro- to y almacenamiento y optimizar la se puede hacer uso de Format
les de transmisión normales conforme compatibilidad– es recomendable que Preserving Encryption (FPE), también
con las directivas de la organización, el token mantenga el mismo tipo conocido como Datatype Preserving
mientras que en la recepción o llega- de formato que el dato confidencial Encryption (DPE). Estas son funcio-
da de datos confidenciales se deben reemplazado hasta donde sea posi- nes criptográficas especiales que
aplicar controles de cifrado, integridad ble: longitud (14 ó 15 para tarjetas de –al igual que FPT– permiten que
y monitorización en la transmisión. pago, por ejemplo), codificación (alfa- los datos confidenciales tengan la
Una vez presentado el esquema típico bético, numérico, caracteres espe- misma estructura y formato que el
y los componentes de un sistema ciales, ASCII, EBCDIC, etc.) y tipo dato original posterior al proceso
que emplee 'tokenización' (y cifrado), de dato (char, varchar, blob, int, etc.), de cifrado, ofreciendo altos nive-
veremos en detalle el ciclo de vida del teniendo en cuenta que empleando les de seguridad. Un ejemplo de
token, el cual pasa por diferentes pro- estas restricciones se puede reducir el ello es Feistel Finite Set Encryption
cesos: generación, asignación, trans- conjunto de posibilidades de combi- Mode (FFSEM/FFX) [1], una variante
misión, almacenamiento y eliminación. nación para la generación de tokens. de Advanced Encryption Standard
Mantener el mismo formato y longi- (AES) que implementa FPE que se
Generación tud del dato confidencial en el token ha probado que es matemática-
La clave en el proceso de genera- ya es en sí una tarea complicada, mente segura y que se encuentra
ción de tokens es garantizar que el dependiendo de la forma como se en proceso de aprobación por el
dispositivo nunca pueda ofrecer infor- haya generado dicho dispositivo. Para National Institute of Standards and
mación directa ni permitir inferir los garantizar esta compatibilidad se ha Technology (NIST).
datos confidenciales con los cuales establecido una técnica conocida En cuanto al uso de FPE en
está relacionado. Dependiendo de las como Format Preserving Tokenization PCI DSS, Visa ha tenido en cuen-
necesidades, el token puede reempla- (FPT) que elimina la necesidad de ta este tipo de algoritmos dentro
zar total o parcialmente el dato confi- modificar aplicaciones y estructuras de sus Best Practices for Data
dencial y se puede generar asociado a de almacenamiento lógicas, definien- Field Encryption [2], aclarando que
cualquier método que produzca un
dato cifrado con la misma longitud
y formato del dato original ha de
Un sistema de 'tokenización' estar sujeto a, por lo menos, una
evaluación de seguridad indepen-
contempla una BD maestra, cifrado diente e implementación con base
en las recomendaciones de dicha
e interfaces de comunicación evaluación (incluyendo los aspectos
asociados a la gestión de claves).

Asignación
un dato específico de forma dinámica do un subconjunto finito de caracte- El proceso de asignación de dispositi-
(por ejemplo, asociado a una transac- res a ser empleados en los procesos vos debe asegurar la integridad en las
ción) o de forma estática (asociado a de generación de tokens, con lo cual referencias, es decir, que cada token
un dato confidencial hasta que dicho se permite reemplazar el dato confi- debe corresponder única y exclusiva-
dato deja de ser válido). dencial por otro valor con el mismo mente a un dato confidencial. La exis-
El valor del token puede ser genera- conjunto de caracteres y longitud. tencia de un token referenciando a
do de forma pseudoaleatoria, secuen- Este mismo criterio se aplica en dos o más datos diferentes puede dar
cial, usando trasposición o empleando el momento del almacenamiento de pie a problemas en el procesamiento
funciones criptográficas de una sola datos confidenciales cifrados y para y en el despliegue de información
vía (hash) o criptografía simétrica. En la generación de tokens pseudoalea- confidencial arbitraria.
cualquier caso, se debe validar que el torios empleando técnicas de cripto-
token es único para cada dato con- grafía. Una función tradicional de cifra- Transmisión
fidencial a ser protegido y que no se do puede tomar una cadena corta En el proceso de la transmisión se
repetirá o 'colisionará' con otro dato de datos y generar una secuencia identifican dos casuísticas, depen-
para asegurar la integridad en las refe- extensa de caracteres en hexadeci- diendo del tipo de dato enviado o
rencias. Añadido a esto, las funciones mal o en binario, que puede requerir recibido:
o subrutinas generadoras de tokens modificaciones en las estructuras de + Recepción y salida de tokens:
deben ser protegidas y controladas almacenamiento en bases de datos, Debido a que el token no es un dato

90 red seguridad noviembre 2010


pci dss
opinión

confidencial, le aplicarán los mismos proceso de eliminación del dato con- cantidad de información confidencial
controles que protegen a los datos no fidencial posterior a la superación del existente, su distribución, su opera-
confidenciales definidos dentro de la umbral de retención definido, el token tiva y el riesgo potencial al que se
organización conforme con la política sea eliminado, bloqueado o su refe- enfrenta, así como los desarrollos
de clasificación de datos. rencia sea liberada para ser reutilizada necesarios para integrar la solución
+ Recepción (alimentación) y si es necesario. en el entorno actual. Si se considera
salida (entrega) de datos confiden- Cuando una organización desea que una solución de 'tokenización' no
ciales: Se deben establecer canales implementar 'tokenización' para pro- es viable, se puede optar por trabajar
seguros para la recepción/entrega de teger su información a nivel interno o la con cualquiera de las demás opcio-
datos confidenciales. En la entrada, el que comparte con terceros, es impor- nes descritas al principio del artículo.
proceso se denomina “alimentación” tante la realización de los siguientes 4. Elección de la solución: Para
y consiste en la recepción de datos pasos de forma secuencial: proceder con la implementación, se
confidenciales desde los diferentes 1. Identificación: Revisión de los puede optar por el desarrollo de
orígenes posibles, su transmisión procesos e interfaces identificando los un sistema de 'tokenización' a nivel
segura, su almacenamiento seguro y flujos y activos en donde se encuentren interno o de una solución comercial
la relación con su token único (gene- presentes datos confidenciales durante que cumpla con las premisas anali-
ración). En la salida -por condiciones la transmisión (interfaces de conexión, zadas anteriormente en el proceso
operativas en ciertos escenarios- es canales, equipos activos de red, etc.), de generación, asignación, almace-
indispensable obtener a partir de un el procesamiento (aplicaciones, esque- namiento y eliminación de tokens.
token el dato confidencial relacionado. mas batch, online, etc.) y el almacena- De igual forma –y dependiendo del
Cuando ello sucede, todos los con- miento (bases de datos, ficheros de tipo y lugar de almacenamiento de
troles de seguridad en la transmisión usuario, depuración, históricos, registro los datos confidenciales–, se puede
deben ser activados (cifrado, integri- de eventos, copias de seguridad, alma- analizar una opción instalada sobre
dad, monitorización, etc.). cenamiento temporal, etc.). una base de datos ya existente o
una solución tipo appliance o equi-
po dedicado. En ambos casos, los
controles de aislamiento deberán ser
implementados.
Uno de los pasos iniciales en el 5. Migración: Identificadas las

proceso de PCI DSS es definir el entradas y salidas de los procesos


que tratan datos confidenciales, se

alcance de cumplimiento: 'scope' procede a implementar el sistema


de 'tokenización' de forma esca-
lonada con el fin de minimizar los
potenciales impactos que puedan
tener en la organización y gestionar
Almacenamiento 2. Validación: Posterior a la reali- aquellas excepciones no registradas
Tal como se ha descrito anterior- zación del inventario de activos que en el proceso de identificación inicial.
mente, el token en sí no es un dato procesan, almacenan y transmiten Se define un momento N de corte,
confidencial. Sin embargo, los datos datos confidenciales, la organización se empieza con la implementación
referenciados sí lo son, razón por la debe identificar aquellas operativas del proceso en nuevos datos, se
cual deben ser protegidos empleando que requieren del uso exclusivo y continúa con los datos operativos
cifrado o cualquier otro método que justificado de estos datos en texto hasta el momento de corte y se fina-
garantice su confidencialidad, integri- claro por condiciones del negocio, liza con los datos históricos. Cuanto
dad, disponibilidad y trazabilidad. Esto legales o administrativas y analizar menor sea el umbral de migración
aplica tanto a datos en uso como a si en las demás operativas el dato en estos tres núcleos, menor será el
copias de seguridad. Es importante confidencial puede ser reemplazado riesgo asociado con la información
también que en el proceso de migra- por un token sin afectar la operación confidencial almacenada, siendo lo
ción a 'tokenización' se implemente el normal. Esto ayudará a determinar más óptimo una migración paralela
sistema de tokens a datos confiden- si la reducción en el ámbito donde de toda la información. El objetivo es
ciales almacenados como históricos, reside el dato confidencial es prácti- centralizar los datos confidenciales
con el fin de evitar su despliegue en ca y justifica el Retorno de Inversión en un único lugar y gestionar las
consultas asociadas (por ejemplo, en (Return On Investment -ROI-). interfaces de conexión con aplicati-
datawarehousing). 3. Análisis de viabilidad: Tras vos mediante rutinas securizadas de
la identificación de dichos flujos, reemplazo por tokens.
Eliminación es necesario realizar un análisis de 6. Depuración: Cualquier dato
Finalmente, la plataforma de 'toke- impacto y viabilidad de emplear o confidencial que, por consideraciones
nización' deberá controlar que en el no 'tokenización', dependiendo de la legales u operativas, no deba ser

92 red seguridad noviembre 2010


pci dss opinión

La plataforma de 'tokenización' deberá controlar que en


el proceso de eliminación del dato confidencial posterior
a la superación del umbral de retención definido, el 'token'
sea eliminado, bloqueado, o su referencia, liberada

almacenado o datos redundantes que proteger los datos confidenciales que puntualmente los activos e interfaces
deben ser eliminados. fluyen a través de él. por los cuales fluye el PAN y, por lo
7. Mantenimiento: Después de la En una organización compleja, la tanto, son susceptibles de cumplir con
puesta en marcha de la solución, se implementación de PCI DSS es una PCI DSS. Otra alternativa puede ser
requiere un mantenimiento preventivo labor larga y costosa, debido a la gran que, en vez de reemplazar el PAN, se
y correctivo, ya que la base de datos cantidad de aplicaciones, equipos 'tokenicen' aquellas transacciones que
maestra centralizada se convierte en activos de red, bases de datos, fiche- hagan referencia a este dato.
punto único de fallo de todo el pro- ros y plataformas operativas involu- PCI DSS contempla los procesos de
ceso. Por ello, son imprescindibles cradas. Al ser el dato de PAN la clave 'tokenización' dentro del requerimiento
consideraciones de disponibilidad y en muchos procesos operativos, los 3.4 de la normativa (“Haga que el PAN
monitorización. riesgos son incontables: almacena- quede, como mínimo, ilegible en cual-
miento no autorizado en ficheros tem- quier lugar donde se almacene...”). Es
Tokenización en PCI DSS porales, de depuración, históricos, también recomendable que los con-
El estándar PCI DSS [3] aplica sobre registros, correos electrónicos, copias troles de enmascaramiento (reemplazo
aquellos activos que procesan, impresas, almacenamiento removible, por asteriscos, por ejemplo) se sigan
almacenan o transmiten el Primary imágenes, etc. implementando independientemente
Account Number (PAN). Asimismo, Frente a esto, el PCI Security de que se trate de un PAN real o un
prohíbe el almacenamiento de datos Standards Council (PCI SSC) [4] reco- PAN 'tokenizado', siguiendo las direc-
sensibles posterior a la autoriza- mienda el uso de segmentación y trices del requerimiento 3.3 (“Oculte el
ción (CVV2, Banda magnética, PIN/ aislamiento de los activos dentro del PAN cuando aparezca -los primeros
PINBLOCK) y define controles espe- scope para minimizar el riesgo y el seis y los últimos cuatro dígitos es la
ciales sobre datos personales del impacto en el cumplimiento y facilitar cantidad máxima de dígitos que apa-
titular de la tarjeta, código de servi- las labores de implementación y man- recerá-…”).
cio y fechas de expiración cuando tenimiento. De no realizar una segmen- El proceso de 'tokenización' del
esta información es almacenada en tación correcta, toda la red se encon- PAN puede ser completo (reemplazo
conjunto con el PAN. trará dentro del alcance (red plana). Es total del PAN por un token) o parcial
Uno de los pasos iniciales en el precisamente en este punto en el que (dejando los primeros seis y últimos
proceso de implementación de los las funcionalidades de la 'tokenización' cuatro dígitos iguales y reemplazando
controles de PCI DSS es definir el proveen beneficios en el ámbito de PCI por un token los datos intermedios, por
alcance de cumplimiento (scope), que DSS: reemplazar el dato del Personal ejemplo), dependiendo de la operativa
permite identificar cualquier activo Account Number (PAN) con un token de la organización (ver Figura 2).
relacionado de forma directa con el excluye de forma directa a cualquier Identificadas las entradas, salidas y
tratamiento de datos de tarjeta o que activo que almacene, procese o tras- operativas que requieren del PAN en
ofrece servicios a dicha plataforma. mita dicho dato 'tokenizado'. La reduc- texto claro (por ejemplo, procesos de
Estos activos deben cumplir de forma ción del alcance –dependiendo de la fraude o atención a incidencias), se
completa con todos los controles complejidad de la organización– es definen interfaces de comunicación
descritos por el estándar con el fin de drástica y permite delimitar e identificar seguras y se procede con la centrali-
zación de datos confidenciales y asig-
nación de tokens. Cualquier activo que
procese, almacene o transmita estos
dispositivos se encontrará fuera del
alcance de cumplimiento, con todas
las ventajas que ello provee: minimi-

Figura 2: Proceso de 'tokenización'


parcial de PAN (Personal Account
Number), que consiste en dejar los
primeros seis y cuatro últimos dígitos
iguales, reemplazando por un token los
datos intermedios.

red seguridad noviembre 2010 93


pci dss
opinión

zación del riesgo, ahorro en costes de


implementación y mantenimiento, etc.
(Ver Figura 3).
Por otra parte, dentro del proceso
de implementación y migración hacia
'tokenización' existirá un punto de
convivencia de PAN reales y 'toke-
nizados'. Para distinguir los unos de
los otros se puede hacer uso del
algoritmo de Luhn [5]. Cualquier PAN
válido cumplirá con este algoritmo,
por lo que se puede configurar que
la función de generación de tokens
produzca valores que no cumplan con
esta condición, facilitando las labores
de identificación de datos y evitar la
“contaminación” de datos reales con
datos 'tokenizados' sin control.
Dentro de la apuesta por la 'toke-
nización' que realizan las marcas de
pago, Visa ha publicado una serie de
mejores prácticas para 'tokenización'
(“Best practices for the tokenisation
of cardholder information”) [6], que
sirven como guía a cualquier organi-
zación que se esté planteando imple-
mentar este sistema dentro de sus
procesos internos como soporte a la
normativa PCI DSS. Figura 3: Cualquier activo que Sin embargo, la base de datos maes-
procese o transmita tokens se tra centralizada de tokens se convierte
Mayor control encontrará fuera del alcance en un punto único de fallo, que requiere
A pesar que el concepto de "tokeni- de cumplimiento, con todas las de protección robusta y de disponi-
ventajas que ello provee, como la
zación" en el ámbito de seguridad de bilidad con el fin de evitar potenciales
minimización del riesgo o el ahorro
la información es bastante reciente, por en costes de implementación. problemas dentro de la organización.
necesidades propias o por cumplimiento Con el uso de esta técnica, están-
de normativas se está empezando a dares como PCI DSS (orientado a
implementar en ambientes que requieren afectado. Empleando técnicas de conser- protección de datos en tarjetas de
protección de información confidencial. vación de formato de datos en subrutinas pago), LOPD, Ley de Portabilidad y
El reemplazo de un dato confidencial de cifrado (FPE) y 'tokenización' (FPT), Responsabilidad del Seguro Médico
por otro no confidencial que garantice la se puede mantener el mismo formato y (HIPPA, por sus siglas en inglés), y
misma operativa minimiza el riesgo y los longitud del dato confidencial en el token otros, minimizan su alcance y el riesgo
costes de implementación y manteni- haciendo transparente la migración y evi- relacionado con la información que
miento de controles y restringe el ámbito tando cambios de infraestructura. debe ser ser protegida.

David Eduardo Acosta Rodríguez es ingeniero de Sistemas de la Universidad Distrital “Francisco José de Caldas” en Bogotá
D.C. (Colombia). Màster en Seguretat de les Tecnologies de la Informació (MSTI) y Master in Project Management (MPM) de la
Universidad de La Salle–Ramón Llull (Barcelona, España). Cuenta con las certificaciones CISSP, CISM, CISA, BS25999 Lead
Auditor, CHFI, OPST, CCNA y PCI QSA. Es miembro de la IEEE, de ISMS Forum Spain y trabaja actualmente como consultor senior
en Seguridad de la Información en IsecAuditors. Las referencias que el autor destaca en este artículo son las siguientes:

[1] The FFX Mode of Operation for Format-Preserving Encryption http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/propo-


sedmodes/ffx/ffx-spec.pdf. Febrero de 2010.
[2] VISA Best Practices: Data Field Encryption Version 1.0 http://corporate.visa.com/_media/best-practices.pdf. 5 de octubre de
2009.
[3] PCI Data Security Standard http://es.pcisecuritystandards.org/minisite/en/pci-dss.html. Septiembre de 2010.
[4] PCI Security Standards Council http://es.pcisecuritystandards.org/minisite/en/index.html. Septiembre de 2010.
[5] Luhn algorithm http://en.wikipedia.org/wiki/Luhn_algorithm. Septiembre de 2010.
[6] PCI Security Standards Council “Best practices for the tokenisation of cardholder information” http://usa.visa.com/download/
merchants/tokenization_best_practices.pdf?13 de julio de 2010.
http://www.visaeurope.com/en/businesses__retailers/payment_security/idoc.ashx?docid=9706b57b-9238-4370-8dca-
838813e9cbf1&version=-1. Septiembre de 2010.

94 red seguridad noviembre 2010