lunes, 5 de septiembre de 2022

¡Bienvenido sea el IIN (BIN) de 8 dígitos! ¿Qué implicaciones conlleva, y cómo afecta al cumplimiento con PCI DSS 3.2.1 y 4.0?

NOTA: la fecha de edición de este artículo fue el pasado 05 de abril de 2022. Durante este tiempo, podría haber cambios nuevos no introducidos en el presente artículo.

Introducción

Este artículo trata sobre la ampliación del valor del IIN, y las implicaciones que esto conlleva para el cumplimiento con el estándar PCI DSS en sus versiones v3.2.1 y v4.0. A lo largo de estos últimos meses, las marcas de pago han ido modulando su posicionamiento original. Además, el PCI SSC ha publicado la nueva versión de PCI DSS, la 4.0, y también ha actualizado el contenido de varias FAQ utilizadas como referencia.  Por todo ello, ha sido necesario crear un nuevo artículo que se adapte a la realidad actual.

Antes de entrar en el tema de fondo, es necesario hacer una pequeña introducción con el fin de explicar las partes que conforman el Primary Account Number (PAN), o Número de Cuenta Primario.


Dicho número, se encuentra presente en la cara principal de todas las tarjetas de pago, y de acuerdo con lo establecido por la norma ISO/IEC 7812:2017 publicada por la Organización Internacional de Normalización ISO/IEC (2017), se compone de los siguientes valores:

  1. Número de identificación del emisor (IIN): Este número identifica a la institución que emitió la tarjeta de pago al titular. Cabe destacar, además, que el primer dígito del IIN se denomina identificador principal de la industria (MII) y que identifica a la categoría de entidad que emitió la tarjeta de pago.

    Anteriormente, el IIN se denominaba BIN, y sus siglas significaban número de identificación de banco. Las marcas de pago VISA y Mastercard siguen utilizando esta denominación.
  2. Número de identificación de cuenta individual: Identificador de cuenta individual. Se trata de un campo de longitud variable.

  3. Número de control: Dígito de control que se calcula haciendo uso del algoritmo de Luhn. El algoritmo de Luhn se utiliza para generar este número, y para comprobar a posteriori si un PAN de tarjeta es válido o no.

    Figura 1: Datos mostrados en el anverso de una tarjeta de pago. Imagen original obtenida de pixabay.com. La imagen ha sido modificada para el presente artículo, teniendo en cuenta las especificidades de la marca de pago VISA, con la información publicada en el documento ‘What Merchants Need to Know to Prepare for 8-Digit BINs’ publicado por VISA (2021).

Norma ISO/IEC 7812:2017

El formato del número de identificación del emisor (IIN), y el del número de cuenta primario (PAN), se regula por la norma internacional ISO/IEC 7812:2017. La primera publicación de esta norma se remonta a 1985, y desde entonces se han producido varias actualizaciones. Actualmente, se compone de dos partes:

  1. ISO/IEC 7812-1:2017: Sistema de enumeración.
  2. ISO/IEC 7812-2:2017: Procedimientos de solicitud y registro.

Hasta ahora, los números IIN tenían una longitud de 6 dígitos, pero con el fin de garantizar la disponibilidad de números en el futuro, en la última versión de la ISO/IEC 7812-1 se indica que el valor del IIN debe pasar a ser de 8 dígitos. Asimismo, en la propia ISO/IEC 7812-1 también se indica que el valor mínimo del PAN debe pasar a ser de 10 dígitos, en lugar de los 8 contemplados hasta la fecha, por lo tanto, el PAN tendrá una longitud variable de 10 a 19 dígitos.

Cabe destacar que este cambio relacionado con el aumento de longitud del IIN ha entrado en vigor en abril de 2022.

Uso del IIN

El aumento de la longitud del IIN es un cambio que puede parecer menor, pero que no lo es. No solamente tiene implicaciones a nivel de cumplimiento normativo, también conlleva cambios funcionales en los sistemas utilizados por los procesadores de pago, las entidades financieras, los comercios etc.

La base de datos de valores IIN la gestiona la Asociación Americana de Banqueros. Actúa como autoridad de registro, y es la responsable de asignar rangos de IIN a las distintas redes emisoras.

El valor IIN es comúnmente utilizado para realizar comprobaciones tales como identificar:

  • La marca de la tarjeta de pago. Por ejemplo: VISA, Mastercard.
  • El tipo de tarjeta de pago. Por ejemplo: Crédito, Débito, Prepago.
  • El banco emisor de la tarjeta de pago. Por ejemplo: Banco ficticio A.
  • El país en el que se emitió la tarjeta de pago. Por ejemplo: USA.

Estas comprobaciones se acostumbran a realizar por varios motivos. Algunos de los más comunes son los operacionales, funcionales, y de control y prevención del fraude.

Hay multitud de páginas web y de APIs disponibles para extraer la correlación de datos relacionados con un número IIN, y también para conocer los números IIN utilizados en cada país. Por ejemplo, dado un IIN de 8 dígitos, en la página web https://www.creditcardvalidator.org, se obtiene la siguiente información:

Figura 2: IIN asignado a un banco de Francia. Captura de pantalla de la página creditcardvalidator.org.


Implicaciones relacionadas con el cumplimiento PCI DSS

Antes de entrar en materia, y empezar a desgranar los requerimientos afectados de PCI DSS, es necesario hacer una aclaración previa, ya que los conceptos de ‘enmascaramiento’ y ‘truncamiento’ deben quedar claros desde un principio.

¿Enmascaramiento y truncamiento son lo mismo?
Enmascaramiento y truncamiento son dos cosas muy distintas, pero esto no siempre queda claro. Dado que se trata de una duda generalizada y recurrente, el PCI SSC publicó la FAQ#1146. De acuerdo con el PCI SSC (2021b) las principales diferencias que hay entre ambos son las siguientes:
  • “El enmascaramiento es un método para ocultar un segmento del PAN cuando este se muestra o se imprime, por ejemplo, en un recibo. […]”  (PCI SSC, 2021b)

    Por lo tanto, aplica únicamente a la visualización del PAN, y se trata de un método para ocultar valores de forma temporal. Bajo una necesidad de negocio debidamente justificada, un empleado podría desenmascarar otros valores.
  • El truncamiento, en cambio, “es un método utilizado para que un segmento del PAN sea ilegible de forma permanente, y aplica cuando el PAN se almacena electrónicamente. […]” (PCI SSC, 2021b)

    Así pues, todos los valores del PAN truncados son irrecuperables, y no hay forma posible de recuperar el valor de los dígitos del PAN original.
Figura 3: Truncamiento vs enmascaramiento. Figura de elaboración propia.

Las implicaciones que puede tener un IIN de 8 dígitos vs el BIN tradicional de 6 dígitos tienen que ver, principalmente, con dos requerimientos de PCI DSS. A continuación, se analizan ambos requisitos y, además, se comparan las equivalencias de estos entre PCI DSS v3.2.1 y v4.0.

Requerimiento 3.3 (PCI DSS v3.2.1) o 3.4.1  (PCI DSS v4.0)

El primer requerimiento tiene que ver con la visualización del PAN en pantallas, recibos etc. Este requerimiento lo que hace es limitar el número de dígitos que pueden ser legibles cuando se muestra un PAN. Para ello, un segmento del PAN debe ser enmascarado con el fin de ocultarlo.

Desde el anuncio de la adopción del IIN de 8 dígitos, tanto el PCI SSC como las marcas de pago se pronunciaron indicando que no había cambios de interpretación, ni flexibilidad alguna, sobre lo estipulado por el requerimiento 3.3 de PCI DSS v3.2.1. Esto conlleva que, para esta versión de PCI DSS, únicamente se puedan mostrar como máximo los 6 primeros y los últimos 4 dígitos, y que el resto deban enmascararse.

El requerimiento equivalente en la recién publicada versión v4.0 es el 3.4.1. El gran cambio es que en esta versión ya no se limita la visualización a los 6 primeros dígitos y a los últimos 4, sino que se ha cambiado el concepto ‘6 primeros dígitos’ por ‘BIN’. Esto supone un cambio de paradigma muy importante; esta posibilidad no se ha abierto hasta la publicación de la nueva versión.

A continuación, se puede ver la comparativa del requerimiento entre ambas versiones:

Figura 4: Imagen que ilustra los requerimientos 3.3 (PCI DSS v3.2.1) y 3.4.1 (PCI DSS v4.0). Elaboración propia.
Hasta ahora, se entendía que el requerimiento 3.3 de PCI DSS v.3.2.1 ya contemplaba que, en un momento dado, un empleado pudiera visualizar dígitos adicionales a los 6 primeros y 4 últimos. Eso sí, para ello se exigía una necesidad de negocio debidamente justificada, fundamentada y documentada, y se tenía que establecer un proceso concreto con medidas de seguridad adicionales.

Las marcas de pago y el propio PCI SSC se han pronunciado de forma clara y tajante en no flexibilizar la interpretación del requerimiento 3.3 de PCI DSS v.3.2.1. De hecho, los posicionamientos de las marcas de pago Mastercard y VISA son los siguientes:

Mastercard: Las diferentes actualizaciones del briefing publicado por Mastercard (2021) siempre han contemplado que el aumento de la longitud del IIN de 6 a 8 dígitos no provoca modificación alguna sobre este requisito. En el mismo documento se indica, además, que si se requiere la visualización de cualquier otro dígito, esta únicamente pueda realizarse bajo una justificación de negocio debidamente fundamentada y documentada.

El texto concreto presente en el briefing de Mastercard es el siguiente:

“[…] For Requirement 3.3, the masking approach should always ensure that only the minimum number of digits is displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, mask the PAN so that individuals performing that function can view only the last four digits. While the intent of Requirement 3.3 is to display no more than the “first 6 and last 4 digits” of a PAN, an entity will be permitted to display more digits if needed but only with a documented business justification. (Mastercard, 2021)
VISA: En un documento publicado por la marca de pago VISA (2020), se hace hincapié en que PCI DSS permite la visualización de todos o parte de los dígitos del PAN ante una necesidad de negocio debidamente justificada y legítima.

El texto concreto del documento de VISA es el siguiente:
[…] Data Presented on Screens and Reports: Provisions already within the PCI DSS allow users with a legitimate business need to see any or all of the PAN digits [...] (VISA, 2020)
PCI SSC: En el mismo sentido se expresa la FAQ#1492, publicada por el PCI SSC (2021a), indicando que el requerimiento 3.3 requiere que como máximo solamente se puedan mostrar los primeros 6 y los últimos 4 dígitos, salvo que exista una justificación de negocio documentada y legítima, la cual debe ser aprobada por la dirección/gerencia, y generar evidencias que deben almacenarse y ponerse a disposición de los auditores para su revisión durante la auditoría PCI DSS.

Requerimiento 3.4 (PCI DSS v3.2.1) o 3.5.1 (PCI DSS v4.0)

El otro requerimiento que tiene que ver con el aumento del IIN de 6 a 8 dígitos, es el que contempla las medidas de seguridad y protección que debe tener el PAN almacenado. Uno de los métodos que puede ser utilizado para el almacenamiento es el denominado truncamiento, con el fin de eliminar un segmento del PAN de forma permanente, es decir, de forma irrecuperable.

Así pues, el requerimiento afectado en la versión 3.2.1 de PCI DSS es el 3.4, y en la 4.0 el 3.5.1. A continuación, se puede observar la comparativa del requerimiento afectado entre ambas versiones, el posicionamiento de las marcas de pago Mastercard y VISA, y el del propio PCI SSC.

Figura 5: Imagen que ilustra los requerimientos 3.4 (PCI DSS v3.2.1) y 3.5.1 (PCI DSS v4.0). Elaboración propia.

Se puede observar que el core del requerimiento sigue siendo el mismo, y que únicamente se añade un pequeño detalle indicando que deben aplicarse medidas adicionales si un mismo PAN se encuentra hasheado y truncado, o bien si existen diferentes versiones truncadas de un mismo PAN. Cabe destacar que esto no es un posicionamiento nuevo, ya que antes aparecía en una nota aclaratoria, en los procedimientos de prueba, y en las diferentes FAQ publicadas por el PCI SSC. Eso sí, el uso de One-time Pads deja de ser un método válido, ya que en la v4.0 únicamente se menciona index tokens.

El quid de la cuestión de este método es saber el conjunto de dígitos que pueden restar en claro, y los que deben truncarse. Aunque este valor lo debe especificar cada marca de pago, y que en un principio los posicionamientos de estas eran desencontrados, finalmente lograron homogeneizarlos. La FAQ#1091, publicada por el PCI SSC (2022a), recoge los diferentes posicionamientos:

Figura 6: Figura que ilustra el contenido de la FAQ#1091 publicada por el PCI SSC (2022a). Elaboración propia.

Los posicionamientos de las marcas de pago Mastercard y VISA son los siguientes:

Mastercard: Ha ido modulando su posicionamiento sobre este requerimiento. Así pues, en un primer momento se afirmaba de forma clara y tajante que los formatos de truncamiento aceptados por Mastercard no se habían visto afectados por la ampliación de la longitud del IIN de 6 a 8 dígitos, y que si se requería almacenar más de los 6 primeros y otros 4 dígitos cualesquiera, que entonces el truncamiento no era una opción válida para cumplir con el requerimiento 3.4 de PCI DSS v.3.2.1. Aun así, su posición actual ha dado una vuelta de 180 grados y contempla que, para el requerimiento 3.4, el máximo número de dígitos que puedan ser almacenados utilizando el truncamiento sea de los primeros 8, y otros 4 cualesquiera.

El texto concreto que contiene el briefing actualizado de Mastercard (2021) es el siguiente:

“For Requirements 3.4, the maximum digits of a PAN that can be stored using truncation are “first 8, any other 4.”” (Mastercard, 2021)
VISA: Esta marca de pago también ha ido modulando su posicionamiento. En el documento de FAQs publicado por VISA (2020), se indicaba que se tenían que truncar o cifrar un mínimo de 6 dígitos. También se indicaba que todos aquellos clientes con una necesidad de exponer el BIN de 8 dígitos al completo, debían utilizar otros métodos tales como el cifrado, el hasheo o la tokenización. Aun así, VISA también ha ido flexibilizando su criterio, y ahora mismo en el documento Numerics Initiative 8-Digit BIN PCI Webinar publicado por VISA (2022) se puede apreciar lo siguiente:

Figura 7: Posicionamiento de VISA para el truncamiento del PAN. En este caso, se indica que deben truncarse un mínimo de 4 dígitos, y que como máximo pueden quedar en claro, sin truncar, los 8 primeros y los 4 últimos. Por lo tanto, solo se almacenaría en la BBDD una entrada del tipo: “12345678****1234”. Captura de pantalla de la diapositiva 7 del documento ‘Numeric Initiative 8-Digit BIN PCI webinar’.



Conclusiones

Por todo ello, teniendo en cuenta los posicionamientos vigentes emitidos por las marcas de pago y la FAQ#1492 del PCI SSC (2021a), las casuísticas de cumplimiento para el requerimiento 3.3 de la v3.2.1 y 3.4.1 de la versión 4.0 quedan de la siguiente forma:

  1. Sin una necesidad legítima de negocio, únicamente se pueden visualizar los 6 primeros y los últimos 4 dígitos de un PAN, según recoge ya actualmente PCI DSS v3.2.1 (PCI SSC, 2018). En caso de existir dicha necesidad, se podrán visualizar el resto de los valores que sean necesarios, siempre que dichas visualizaciones se hagan teniendo en cuenta todos los requerimientos aplicables.
  2. En cambio, si se evalúa a una empresa con la v4.0, el requerimiento 3.4.1 permite la visualización del IIN y los últimos 4 dígitos sin la necesidad de tomar medidas de seguridad adicionales.

Las casuísticas de cumplimiento para el requerimiento 3.4 de la versión 3.2.1, y el 3.5.1 de la versión 4.0, quedan de la siguiente forma:

  1. Necesidad de almacenar únicamente el IIN de 8 dígitos: Si únicamente se requiere mantener el IIN, y se truncan todos los otros dígitos del PAN, se está cumpliendo con lo estipulado en la FAQ#1091 publicada por el PCI SSC (2022a), siempre que las tarjetas de pago tratadas sean de Mastercard, VISA, Discover, UnionPay o JCB.

  2. Necesidad de almacenar los últimos 4 dígitos: Si únicamente se requiere mantener los últimos 4 dígitos del PAN, y se truncan todos los otros, se está cumpliendo con lo estipulado en la FAQ#1091 publicada por el PCI SSC (2022a).

  3. Necesidad de almacenar el BIN de 8 dígitos, y los últimos 4 dígitos del PAN: Si se requiere mantener los 8 primeros dígitos del PAN y otros 4 cualesquiera, y se truncan todos los otros dígitos, se está cumpliendo con lo estipulado en la FAQ#1091 publicada por el PCI SSC (2022a).

  4. Necesidad de almacenar más de los 8 primeros dígitos y otros 4 dígitos cualesquiera, o bien de almacenar un mismo PAN con más de un método de truncamiento en función del sistema/activo o almacenar un mismo PAN hasheado y truncado a la vez:

    Los comercios, proveedores de servicio y terceras partes que se encuentren bajo esta casuística, tendrán que implantar alguna de las medidas adicionales, tales como podrían ser:

    a. La implementación de sistemas de cifrado y descifrado utilizando criptografía robusta
    b. Valores hash de una vía basados en criptografía sólida (el hash debe ser del PAN entero)
    c. Tokens. Y en la versión 3.2.1 de PCI DSS, también se acepta el uso de ensambladores de índices (los ensambladores se deben almacenar de forma segura)

Finalmente, vemos como las marcas de pago, y por ende el PCI SSC, se han tenido que adaptar a las necesidades funcionales y de negocio expresadas por varias empresas, y es que el aumento del IIN podía tener unas consecuencias de gran repercusión para sus entornos de cumplimiento.

Referencias bibliográficas

1- ISO/IEC. (2017). ISO/IEC 7812-1:2017(en) Identification cards — Identification of issuers — Part 1: Numbering system. https://www.iso.org/obp/ui/#iso:std:iso-iec:7812:-1:ed-5:v1:en
2- Mastercard. (2021).  8-Digit BIN Expansion and PCI Standards. https://www.mastercard.com/content/dam/public/mastercardcom/globalrisk/pdf/8-Digit%20BIN%20Expansion%20and%20PCI%20Standards%20-%20FINAL%20(10-20-2021).pdf
3- PCI SSC. (2018). Requirements and Security Assessment Procedures version 3.2.1. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
4- PCI SSC (2021a). How can an entity meet PCI DSS requirements for PAN masking and truncation if it has migrated to 8-digit BINs?. https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-can-an-entity-meet-PCI-DSS-requirements-for-PAN-masking-and-truncation-if-it-has-migrated-to-8-digit-BINs
5- PCI SSC. (2021b). What is the difference between masking and truncation? https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-is-the-difference-between-masking-and-truncation
6- PCI SSC. (2022a). What are acceptable formats for truncation of primary account numbers?. https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-are-acceptable-formats-for-truncation-of-primary-account-numbers
7- PCI SSC. (2022b). Requirements and Testing Procedures version 4.0. https://www.pcisecuritystandards.org/documents/PCI-DSS-v4_0.pdf
8- VISA. (2020). Preparing for the Eight-Digit BIN. Frequently Asked Questions. https://usa.visa.com/dam/VCOM/global/partner-with-us/documents/visa.com-numerics-faq.pdf
9- VISA. (2021). What Merchants Need to Know to Prepare for 8-Digit BINs. https://usa.visa.com/content/dam/VCOM/regional/na/us/partner-with-us/documents/what-merchants-need-to-know-lac-webinars-english-october-2021.pdf
10- VISA. (2022). Numerics Initiative 8-Digit BIN PCI Webinar.  https://usa.visa.com/content/dam/VCOM/regional/na/us/partner-with-us/documents/8-digit-bin-pci-webinar-presentation-deck-visa-com-version.pdf


Autor: Marc de Tébar - ISO 27001 L.A., CISM, PCIP, MCAF, SFPC
Departamento Consultoría