lunes, 4 de octubre de 2021

El fraude en los pagos. Parte I: Los datos de tarjeta y los diferentes tipos de ataques

 1. Introducción

Esta publicación se compone de tres artículos. En este primer artículo, de carácter introductorio, se brinda información básica sobre las tarjetas de pago, los tipos de pago y los datos requeridos para efectuarlos. Es necesario introducir esta información al lector con el fin de asegurar un nivel de conocimiento mínimo. Una vez logrado este punto, se introducen los diferentes tipos de ataque a los que se encuentran expuestos los titulares de tarjetas de pago en el momento de utilizarlas.

1.1. Tipos de pago

Antes de empezar, es importante explicar las tipologías de pagos que hay cuando se habla de pagos realizados con tarjetas. Estos pagos se diferencian en dos tipos, los pagos presenciales (al que nos referiremos por sus siglas en inglés, CP, Card Present) y los pagos no presenciales, o pagos sin presencia de la tarjeta (CNP, Card Not Present). 

lunes, 13 de septiembre de 2021

XSS, Un mal que nunca acaba

Empecemos por ¿Qué es un Cross-Site Scripting o XSS?

Definámoslo de una manera sencilla, son un tipo de inyecciones. Un Cross-Site al final es una ejecución de código malicioso que puede ser JavaScript, HTML o cualquier otro lenguaje siempre y cuando el entorno donde se vaya a ejecutar sea compatible con la plataforma en la que se está ejecutando y afecte a la plataforma realizando acciones maliciosas definidas por el usuario que no espera la plataforma y esto se produce por un input mal filtrado.

Por definir un poquito los términos y para que ya nos vayan sonando, JavaScript es un lenguaje de programación interpretado que permite compilar el código durante la ejecución y actualmente es utilizado por muchísimas páginas web.

JavaScript permite que la aplicación cliente, es decir, el sitio web, procese la información que recibe del servidor o desea enviar como, por ejemplo, publicar un mensaje, enviar credenciales de usuario para iniciar sesión, etc., o incluso renderizar juegos. Actualmente se usa en muchas aplicaciones y distintas plataformas por ejemplo de CMS (Sistema de gestión de contenidos) como son Wordpress, Drupal, Jommla, Shopify, etc...

viernes, 3 de septiembre de 2021

Cambiamos nuestros números de teléfono a la Marcación Única Nacional en Colombia

Desde el 1 de septiembre de 2021 se ha implementado la marcación única nacional en Colombia, para unificar la longitud de los números telefónicos fijos y móviles a 10 dígitos, simplificando el acceso a los servicios e impulsando la transformación y modernización de las redes fijas en el país.

A partir del cambio contemplado en la regulación, el país dispondrá de un esquema unificado en el que se marcarán 10 dígitos para hacer todo tipo de llamadas desde teléfonos fijos y celulares a cualquier número telefónico de Colombia.

De esta forma, cuando quiera ponerse en contacto con nuestras oficinas en Bogotá tendrá que hacerlo de la siguiente forma:

viernes, 13 de agosto de 2021

El Esquema Nacional de Seguridad y la reducción de riesgos en Office 365

Algunas de las herramientas más comúnmente utilizadas hoy en día, en el ámbito de la gestión e intercambio de información, son las proporcionadas por el conjunto de programas de Microsoft Office 365. Dependiendo del plan contratado por el usuario u organización (hogar o empresa), el conjunto de programas ofrecido es distinto, no obstante, en este artículo se analizarán los riesgos de seguridad asociados a algunos de los servicios ofrecidos por el plan empresarial.
 
Siendo Internet Security Auditors una empresa dedicada especialmente a la seguridad de la información, este artículo pretende analizar el nivel de seguridad ofrecido por Microsoft Office 365 y las opciones ofrecidas para ser configuradas por parte del usuario según necesidades organizativas.

El artículo se centrará en el análisis de las dimensiones de confidencialidad, integridad y disponibilidad de la información, a través de las principales herramientas de intercambio de información que ofrece el plan empresarial, como lo son Microsoft Teams, SharePoint, Exchange y la propia plataforma de administración de Office 365, de acuerdo a los parámetros de seguridad analizados por el Esquema Nacional de Seguridad (ENS).

miércoles, 11 de agosto de 2021

Internet Security Auditors afianza su alianza con el (ISC)² como OTP de formación en Portugal y Ecuador

(ISC)², la asociación sin fines de lucro más grande del mundo de profesionales certificados en ciberseguridad, ha anunciado que Internet Security Auditors sigue afianzando su alianza, que se remonta al año 2006, con un nuevo paso como OTP (Official Training Provider) de formación en Portugal y Ecuador (añadidos a España y Colombia). Convirtiéndonos en los primeros OTP que ofrecerán cursos oficiales en estos dos países.

El equipo de servicios de Internet Security Auditors será responsable de brindar programas de educación y desarrollo profesional (ISC)² para las organizaciones, con cursos oficiales preparatorios para los exámenes de las certificaciones:

  • Certified Information Systems Security Professional (CISSP)
  • Certified Secure Software Lifecycle Professional (CSSLP)
  • Certified Cloud Security Professional (CCSP)

jueves, 5 de agosto de 2021

Impacto de la COVID-19 en el estándar PCI DSS (I)

La inmersión, sin precedentes en nuestra sociedad, del coronavirus, convertido en Pandemia Mundial, ha hecho que todos reconsideremos y revisemos la forma en la cual se estaban llevando a cabo los negocios y la forma en que vivimos en general. Esto ha desembocado en la obligación de modificar sustancialmente el entorno de trabajo y los procesos que, con fuerte arraigo, las empresas tenían establecidos.

Esta situación presenta una serie completamente nueva de desafíos para los equipos de cada organización en materia de cumplimiento, tecnología y seguridad de la información, ya que estos empleados ahora operan en un entorno potencialmente menos seguro y definitivamente menos privado.

lunes, 19 de julio de 2021

API Testing, preparando un buen análisis

Cuando nos disponemos a auditar un sitio web tenemos claro lo que vamos a encontrarnos menú, opciones, formularios, cuadros de búsqueda y mucho texto, sin embargo, cuando vamos a auditar una API, debemos comprender varios puntos esenciales con el objetivo de realizar una auditoría con una adecuada metodología.

¿Qué es una API?

Se trata de un conjunto de definiciones y protocolos que se utilizan para desarrollar e integrar el software de las aplicaciones permitiendo la comunicación entre dos aplicaciones a través de un conjunto de reglas, es decir la especificación formal que establece cómo un módulo de un software se comunica o interactúa con otro.

Imaginemos que nuestra organización tiene la necesidad de crear un aplicativo de movilidad como Uber o una tienda online. ¿Te imaginas que costoso sería en tiempo y recursos el desarrollo de algunos recursos desde cero? Por eso es mejor utilizar un servicio que ya existe como Google Maps o PayPal.
Ese es el concepto de API, no rehacer el trabajo que ya han hecho otros y así poder crear un aplicativo más potente que el resto.

Además, cuando tenemos la necesidad de crear un aplicativo multiplataforma, como aplicaciones móviles tanto para iOS como para Android incluso para tablets como padOS o aplicativos webs surge la necesidad de compartir el Backend entre dichos aplicativos y ahí también aparece la definición de API.


viernes, 16 de julio de 2021

Primera empresa en Iberoamérica en acceder al programa de Card Production (CPSA) del PCI SSC

 El programa de Card Production Security Assessor (CPSA) fue uno de los últimos en ser incorporado dentro del ecosistema de estándares de seguridad del PCI SSC y define los requerimiento tanto físicos como lógicos que deben cumplir todos los fabricantes y personalizadores de tarjetas de pago.

Internet Security Auditors se convierte, marcando un nuevo hito como líder regional de referencia en consultoría y auditoría, en la primera empresa en España y Latinoamérica en entrar en el programa CPSA.

Con este programa, la compañía refuerza su liderazgo como empresa auditora en los estándares PCI, reconocida por la calidad de sus servicios de consultoría y auditoría en estas normas, para colaborar en los procesos de implementación y certificación del cumplimiento de las normas en las que ya cuenta con las acreditaciones como QSA, ASV, PA-QSA, CPSA, QSA(P2PE) y 3DS Assessor y que ampliaremos a otros programas gestionados por el PCI SSC en próximas fechas, cubriendo la totalidad de normas del PCI SSC, situándonos como líderes destacados y que nos permiten ayudar a nuestros clientes ya no sólo en el cumplimiento y auditoría de estas normas si no de servicios normativos heterogéneos mediante nuestras Oficinas Técnicas de Ciberseguridad y Cumplimiento.

https://www.pcisecuritystandards.org/assessors_and_solutions/card_production_security_assessors

jueves, 8 de abril de 2021

El PCI SSC publica la versión 3.1 del estándar PCI PIN

El pasado 12 de marzo, el PCI SSC publicó la versión 3.1 del estándar de seguridad PCI PIN. Esta publicación, catalogada con una revisión menor, añade una serie de aclaraciones y actualizaciones del estándar en base al feedback recibido. El objetivo del presente artículo es el de comentar los principales cambios introducidos.

Junto con la publicación de la nueva versión del estándar, se ha publicado una entrada en el blog del PCI SSC con un par de preguntas respondidas por Emma Sutcliffe, Standards Officer del PCI SSC, así como un documento con el resumen de los cambios.

La mayoría de estos cambios, son meramente el añadir nuevas referencias o cambios en algunas frases utilizadas, sin embargo, hay algunos puntos interesantes para revisar:

miércoles, 24 de marzo de 2021

Charlas, eventos y entrevistas

Nuestro responsable del área de Ciberinteligencia Carlos Seisdedos, colaborará como ponente en la II edición del #INTELQUORUM2021, una Jornada dedicada a la Inteligencia y Seguridad Global. Carlos hablará sobre Inteligencia de Fuentes Abiertas como elemento de valor para la organización. El evento se celebra este viernes 26 de marzo de 18:00 a 19:30.
 
Carlos también fue entrevistado el pasado jueves 18 en una importante emisora de México y estuvo hablando sobre ciberdelitos cometidos mediante redes sociales, y también como los afrontamos en ISecAuditors. La entrevista completa en el siguiente enlace (a partir de min. 1:20:00):
https://www.spreaker.com/user/heraldo-de-mexico/jesus-martin-mendoza-18-mar-21
 
Por su lado, Vicente Aguilera participará en el debate “Digitalización global, mercado de datos personales y su regularización” del programa de radio Debat a Orgull junto a la periodista Karma Peiró. El debate se emitirá este lunes a las 19:00. https://orgull.cat/debataorgull

jueves, 18 de marzo de 2021

Wi-Fi DoS: CTS Frame Attack

CTS Frame Attack es un ataque destinado a la denegación de servicio que puede dejar inoperativa una red inalámbrica durante un largo periodo de tiempo. Para entender cómo funciona el ataque y que es un paquete CTS deberemos profundizar en la base del Networking.

Modelo OSI

El modelo OSI (Open Systems Interconnection Model) es un marco conceptual usado para describir las funciones de un sistema de redes. Estas funciones se caracterizan en un conjunto universal de reglas y requisitos para respaldar la interoperabilidad entre diferentes productos y software. Las comunicaciones entre un sistema informático se dividen en siete capas abstractas:

OSI Model

En este artículo vamos a ver la capa física y profundizar en la capa de enlace para entender y ejecutar con éxito nuestro CTS Frame Attack.

Charlas, Eventos y entrevistas

La semana pasada Carlos Seisdedos, responsable del departamento de Ciberinteligencia, tuvo la oportunidad de participar nuevamente en la emisora de Radio Onda Cero, en el programa La Brújula hablando sobre las implicaciones del ataque con ransomware y rescate solicitado al SEPE (Servicio Público de Empleo Estatal). El podcast completo en el siguiente enlace:
 
https://www.ondacero.es/programas/la-brujula/programas-completos/brujula-10032021_2021031060494f3d094c980001e26804.html
 
Y hablando del ataque al SEPE, también ha podido colaborar con El Periódico sobre: ¿qué hay detrás del ciberataque que ha paralizado el SEPE?
https://www.elperiodico.com/es/economia/20210311/hay-detras-ciberataque-paralizado-sepe-11573149
 
Carlos, también ha sido entrevistado en el periódico mexicano El Universal, dónde habla sobre quien debe controlar los contenidos que subimos a las plataformas, ¿las tecnológicas o las autoridades? El artículo completo: https://www.eluniversal.com.mx/mundo/quien-vigila-al-vigilante-si-se-regulan-las-redes-cuestiona-experto-en-ciberseguridad

lunes, 15 de marzo de 2021

CISO-as-a-Service (CISOaaS): Una opción para cumplir con el Real Decreto 43/2021

 Si algo ha demostrado la pandemia del Covid-19 es que los estados han de replantearse qué es y no es estratégico para el funcionamiento de un país y de entidades como la UE. Nadie pensó en la importante que podía llegar a ser esa pequeña empresa especialista en la fabricación de respiradores para UCI pero sí se pensaba en lo importante que era ese gran hospital que los usaba, nadie pensó en esa pequeña empresa farmacéutica que podía ser capaz de fabricar un medicamento o una vacuna en caso necesario, o esa empresa industrial que era capaz de fabricar esa pequeña pero importantísima pieza para un equipamiento médico. Así se han dado muchos casos. El tejido productivo es imprescindible en situaciones de crisis y gran parte de las empresas que forman ese tejido o no era valorado como se merecía en cuanto a su criticidad, pero, para lo que nos merece aquí, no era observado en cuanto a la ciberseguridad en la implicación que repercute por esa responsabilidad.

viernes, 12 de marzo de 2021

Ampliación del IIN (BIN) de 6 a 8 dígitos: ¿Qué implicaciones conlleva?

NOTA ACLARATORIA - SEPTIEMBRE 2021

El PCI SSC ha actualizado la FAQ#1091 relativa a los formatos de truncamiento aceptados por las marcas de pago. Este cambio incluye nuevos criterios por parte de VISA y Mastercard para todos aquellos PAN con un BIN de 8 cifras.

De este modo, se permite almacenar los 8 primeros dígitos (BIN) y otros 4 cualesquiera. Esto hace que únicamente deba eliminarse de forma permanente un segmento de 4 cifras, y no de 6 cifras.


Para los PAN con un BIN de 6 dígitos no hay cambios, por lo que en este caso se sigue exigiendo que únicamente sean legibles los primeros 6 y otros 4 cualesquiera, exigiendo que se elimine permanentemente un segmento de un mínimo de 6 dígitos.


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. 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.
Imagen sacada de: www.freepik.es

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.

Hoy en día, los números IIN tienen 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 misma 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.

Finalmente, cabe destacar que de acuerdo con el briefing publicado por Mastercard (2018), la marca de pago aplicará el cambio de longitud del IIN en abril de 2022.  Pero no es la única, en un documento publicado por VISA (2020b) se indica que el mes de abril de 2022 es la fecha límite establecida por VISA con el fin de que los adquirientes y los procesadores se encuentren preparados para trabajar con IINs de 8 dígitos. Además, en una nota de prensa posterior publicada por la misma VISA (2020a), se establece que la fecha de abril de 2022 sigue siendo completamente vigente, indicando que no se ve alterada por la situación de emergencia sanitaria causada por el virus SARS-CoV-2.

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.

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. Por ejemplo, dado un IIN de 8 dígitos, en la página web Binlist, se obtiene la siguiente información:




Implicaciones relacionadas con el cumplimiento PCI DSS

Antes de entrar en materia, y empezar a desgranar los requerimientos afectados de PCI DSS v3.2.1, 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?

En este caso, tiene que quedar claro que enmascaramiento y truncamiento son dos cosas muy distintas. Dado que se trata de una duda generalizada en comercios, y otras partes interesadas que deben cumplir con el estándar, el PCI SSC publicó la FAQ#1146 para aclararlo. De acuerdo con el PCI SSC (2014) las principales diferencias que hay entre ambos son las siguientes:

- “El enmascarado es un método para ocultar un segmento del PAN cuando este se muestra o se imprime, por ejemplo, en un recibo. […]”  (PCI SSC, 2014)

Por lo tanto, aplica únicamente a la visualización del PAN, y se trata de un método para ocultar valores de este de forma temporal, ya que, bajo una necesidad de negocio debidamente justificada, un empleado podría desenmascarar los 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, 2014)
Así pues, todos los valores del PAN truncados son irrecuperables, y no hay forma posible de recuperar el valor del PAN original.

Los requerimientos afectados de PCI DSS v3.2.1 son el 3.3 y el 3.4. En los siguientes apartados se analizan ambos requerimientos.

Requerimiento 3.3 del estándar PCI DSS v3.2.1

A continuación, se recoge el posicionamiento de las marcas de pago Mastercard y VISA, y el del PCI SSC, para el requerimiento 3.3 de PCI DSS v3.2.1.

3.3. Enmascare el PAN (número de cuenta principal) cuando aparezca (los primeros seis o los últimos cuatro dígitos es la cantidad máxima de dígitos que aparecerá), de modo que solo el personal con una necesidad comercial legítima pueda ver más que los primeros seis o los últimos cuatro dígitos del PAN.” (PCI SSC, 2018a)

De acuerdo con el briefing publicado por Mastercard (2018), la marca indica 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 puede 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 six and last four digits” of a PAN, an entity will be permitted to display more digits if needed but only with a documented business justification. […]” (Mastercard, 2018)

En un documento publicado por la marca de pago VISA (2020b), 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. Asimismo, también aprovechan para indicar que la longitud total del PAN seguirá siendo de 16 dígitos, salvo el caso de V PAY (disponible en Europa), que hace uso de números PAN con una longitud de 19 dígitos en algunas implementaciones específicas.

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, 2020b)

En el mismo sentido se expresa la FAQ#1492, publicada recientemente por el PCI SSC (2021), indicando que el requerimiento 3.3 requiere que como máximo solamente se pueden 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 del estándar PCI DSS v.3.2.1

El otro requerimiento afectado en la versión 3.2.1 de PCI DSS es el 3.4. A continuación, se realiza una breve explicación del requerimiento, y se recoge el posicionamiento de las marcas de pago Mastercard y VISA, y el del PCI SSC.

3.4. Convierta el PAN (número de cuenta principal) en ilegible en cualquier lugar donde se almacene (incluidos los datos que se almacenen en medios digitales portátiles, en medios de copia de seguridad y en registros) utilizando cualquiera de los siguientes métodos:

• Valores hash de una vía basados en criptografía sólida (el hash debe ser del PAN completo)
• Truncamiento (los valores hash no se pueden usar para reemplazar el segmento truncado del PAN)
• Tokens y ensambladores de índices (los ensambladores se deben almacenar de manera segura).
• Criptografía sólida con procesos y procedimientos asociados para la administración de claves.
” (PCI SSC, 2018a)
Según recoge la versión 3.2.1 del estándar PCI DSS publicado por el PCI SSC (2018a), si se quiere utilizar la opción del truncamiento para cumplir con el requerimiento 3.4, debe eliminarse de forma permanente un segmento de los datos del PAN, con el fin de que solamente se almacene una parte de este. Y, además, se indica que generalmente pueden almacenarse los primeros seis y los últimos cuatro dígitos.

De acuerdo con el briefing publicado por Mastercard (2018), la marca de pago tampoco introduce ningún cambio que permita adaptar el requerimiento 3.4 a la nueva realidad que aplicará el próximo mes de abril de 2022. Así pues, indica de forma clara y tajante que los formatos de truncamiento aceptados por Mastercard no se han visto alterados como resultado de la ampliación de la longitud del IIN de 6 a 8 dígitos, y que, si se requiere almacenar más de los 6 primeros y otros 4 dígitos cualesquiera, entonces el truncamiento no es una opción válida para cumplir con el requerimiento 3.4 de PCI DSS v3.2.1.

El texto concreto que contiene el briefing de Mastercard es el siguiente:

For Requirements 3.4, the maximum digits of a PAN that can be stored using truncation are “first six and any other four.” Mastercard’s acceptable truncation format has not changed as a result of the 8-digit BIN expansion mandate. If an entity needs to store more than “first six and any other four,” then truncation cannot be used to meet Requirement 3.4 and one of the other three approaches would need to be applied to render the PAN unreadable anywhere it is stored.(Mastercard, 2018)

Un lector familiarizado con PCI DSS seguramente piense que en los dos párrafos anteriores hay un error. Pero no es así. Se ha indicado ‘otros 4 dígitos cualesquiera’ intencionadamente. En el siguiente apartado, denominado “Entonces, ¿cómo queda la situación?”, se entenderá el motivo.

En el documento publicado por la marca de pago VISA (2020b), se indica de forma clara que PCI DSS exige que, al menos, 6 dígitos se trunquen o cifren para proteger los datos en reposo. E indica que, todos aquellos clientes que tengan una necesidad de exponer el BIN de 8 dígitos completo, tendrán que utilizar otros métodos tales como el cifrado, el hasheo o la tokenización.

El texto concreto que contiene el documento de VISA es el siguiente:

[..] After evaluating the expansion to eight-digit BINs, PCI advises that a minimum of six digits must be truncated or encrypted to protect data at rest. Clients that use truncation as their only method of complying with the PCI requirement for protecting data at rest, and who would like to expose the full eight-digit BIN as well as the last four digits, will need to add one or more of the other acceptable methods for data protection, such as encryption, hashing or tokenization [...]” (VISA, 2020b)

En el mismo sentido se expresa la FAQ#1492 publicada recientemente por el PCI SSC (2021), indicando que cada marca de pago tiene diferentes longitudes de BIN y PAN, y diferentes criterios, por lo que las preguntas sobre los requisitos de truncamiento deben dirigirse directamente a las propias marcas de pago aplicables en cada caso. En el siguiente apartado se analizan los métodos de truncamiento permitidos por cada marca de pago.

Entonces, ¿cómo queda la situación?

Si bien, por norma general, todas las marcas de pago aceptan que los métodos de truncamiento permiten almacenar de forma libre y sin restricciones los 6 primeros, y los 4 últimos dígitos del PAN, aplican algunas posibles flexibilizaciones que deben tenerse en consideración, y que van en línea con la casuística analizada en el caso del requerimiento 3.4.

De acuerdo con la FAQ#1091 publicada por el PCI SSC (2018b), los métodos de truncamiento permitidos según cada marca de pago son los siguientes:

Longitud del
PAN
Marca de pago
American Express Discover Mastercard JCB Visa

PAN con una longitud superior a los 16 dígitos

BIN de 6 dígitos

N/A N/A

Al menos deben eliminarse 6 dígitos.

Números máximos que pueden mantenerse:

PAN de 17 dígitos: “Los primeros 6 dígitos, y otros 5 cualesquiera

PAN de 18 dígitos: “Los 6 primeros dígitos, y otros 6 cualesquiera

PAN de 19 dígitos: “Los primeros 6 dígitos, y otros 7 cualesquiera”
N/A

Al menos deben eliminarse 6 dígitos.

Números máximos que pueden mantenerse:

PAN de 17 dígitos: “Los primeros 6 dígitos, y otros 5 cualesquiera

PAN de 18 dígitos: “Los 6 primeros dígitos, y otros 6 cualesquiera

PAN de 19 dígitos: “Los primeros 6 dígitos, y otros 7 cualesquiera

PAN con una longitud de 16 dígitos

BIN de 8 dígitos

N/A

Al menos deben eliminarse 6 dígitos.

Números máximos que pueden mantenerse:

Los primeros 6 dígitos, y otros 4 cualesquiera

Al menos deben eliminarse 6 dígitos.

Números máximos que pueden mantenerse:

Los primeros 6 dígitos, y otros 4 cualesquiera

N/A

Al menos deben eliminarse 6 dígitos.

Números máximos que pueden mantenerse:

Los primeros 6 dígitos, y otros 4 cualesquiera

PAN con una longitud de 16 dígitos

BIN de 6 dígitos
N/A

Al menos deben eliminarse 6 dígitos. Números máximos que pueden mantenerse: “Los primeros 6 dígitos, y otros 4 cualesquiera

PAN con una longitud de 15 dígitos

Al menos deben eliminarse 5 dígitos.

Números máximos que pueden mantenerse:

Los primeros 6 dígitos, y los últimos 4

N/A

Al menos deben eliminarse 5 dígitos.

Números máximos que pueden mantenerse:

Los primeros 6 dígitos, y otros 4 cualesquiera

N/A N/A
PAN con una longitud inferior a los 15 dígitos N/A

Números máximos que pueden mantenerse:

Los primeros 6 dígitos, y otros 4 cualesquiera
N/A N/A


Así pues, queda claro que, si bien el posicionamiento oficial y ampliamente aceptado por todas las marcas de pago pasa por permitir que los primeros 6 dígitos, y los últimos 4 dígitos no se trunquen (si este es el método usado para cumplir con el requerimiento 3.4), hay algunas excepciones que pueden aplicar (o no) en función de la marca de pago de las tarjetas utilizadas en el entorno.

Conclusiones

Una vez analizados los posicionamientos del PCI SSC, y de las marcas de pago Mastercard y VISA, queda claro lo siguiente:

  1. La norma general ampliamente aceptada por todas las marcas de pago sigue siendo que, en caso de aplicar truncamiento, únicamente se pueden almacenar, como máximo, los 6 primeros y los 4 últimos números del PAN de una tarjeta.
  2. La norma general ampliamente aceptada por todas las marcas de pago sigue siendo que el PAN enmascarado únicamente puede mantener visibles los 6 primeros y los 4 últimos números. Si se requiere la visualización de algún otro número adicional, se tendrá que desenmascarar de forma expresa, y siempre, justificando dicha visualización con una necesidad de negocio legítima, y aplicando el resto de los controles del estándar PCI DSS que pudieren ser de aplicación.

Por todo ello, con la versión actual del estándar, y teniendo en cuenta los posicionamientos vigentes emitidos por las marcas de pago y la FAQ#1492 del PCI SSC (2021), las casuísticas de cumplimiento para el requerimiento 3.3 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, 2018a). 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.

    Esto requerirá, pues, que en función del conjunto de números que se tengan que visualizar por necesidades legítimas y justificadas de negocio, se pueda (o no) cumplir con el requerimiento 3.4 haciendo uso del truncamiento, ya que este, es un método irreversible, de modo que un segmento truncado del PAN no puede ser recuperado.

Las casuísticas de cumplimiento para el requerimiento 3.4 quedan de la siguiente forma:

  1. Necesidad de almacenar únicamente el BIN de 8 dígitos: Si únicamente se requiere mantener el BIN, y se truncan todos los otros valores del PAN, se está cumpliendo con lo estipulado en la FAQ#1091 publicada por el PCI SSC (2018b), siempre que las tarjetas de pago tratadas sean de Mastercard, VISA y/o Discover.
  2. Necesidad de almacenar los últimos 4 números: Si únicamente se requiere mantener los últimos 4 números del PAN, y se truncan todos los otros dígitos, se está cumpliendo con lo estipulado en la FAQ#1091 publicada por el PCI SSC (2018b).
  3. Necesidad de almacenar el BIN de 8 dígitos, y los últimos 4 dígitos del PAN: Bajo esta casuística, y de acuerdo con toda la información publicada hoy en día por las marcas de pago y el PCI SSC, no se puede almacenar un segmento de 11 dígitos del PAN en claro si se quiere cumplir con la FAQ#1091 publicada por el PCI SSC (2018b).

    Los comercios, proveedores de servicio y terceras partes que se encuentren bajo esta casuística, tendrán que implantar alguna de las medidas adicionales previstas en el requerimiento 3.4 de PCI-DSS v3.2.1 publicado por el PCI SSC (2018a), 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 ensambladores de índices (los ensambladores se deben almacenar de forma segura)

Cabe mencionar que, además, tal y como nos recuerda la FAQ#1091 publicada por el PCI SSC (2018b), no se pueden utilizar múltiples métodos de truncamiento en un mismo entorno para una misma tarjeta de pago. Si por algún motivo justificado de negocio se requiere almacenar el mismo PAN, truncado de forma distinta en varios sistemas, se tendrán que aplicar controles de seguridad adicionales, con el fin de evitar que se puedan correlar las versiones truncadas.


Finalmente, aunque en un principio se esperaba la publicación de la nueva versión de PCI DSS a medianos de 2021 (Goodspeed, 2020), el PCI SSC ha ampliado el plazo de validación interna, por lo que, por ahora, no hay una fecha de publicación oficial. Se espera que esta se comunique a lo largo del presente año 2021 (Goodspeed, 2021). 

Pero ¿qué podemos esperar de dicha versión? ¿Abordará de una forma distinta esta casuística? De momento no ha transcendido mucha información pública, pero hay un cambio destacable. La aparición del enfoque personalizado (Holloway, 2020).

De acuerdo con el artículo publicado por Holloway (2020) en el blog oficial del PCI SSC, la versión 4.0 de PCI DSS seguirá contemplando un conjunto de requerimientos, pero estos podrán ser “modificados” por las organizaciones con el fin de adaptarse a las necesidades de negocio, siempre que se cumpla con el objetivo del requerimiento original.

Es importante destacar que:

- La organización deberá justificar el requerimiento personalizado, y generar documentación para que el QSA la pueda validar.
- La justificación de personalizar uno más requerimientos se deberá apoyar en un proceso de análisis y gestión de riesgos de seguridad maduro por parte de la organización.
- En última instancia, será el QSA el responsable de determinar si el enfoque propuesto por la organización puede ser aceptado para sustituir al requerimiento original. Para ello, el QSA definirá las pruebas de auditoría específicas para cada uno de los requerimientos afectados.

Este punto conlleva un gran cambio, en mayúsculas. Hasta ahora, los requerimientos de PCI DSS se tenían que cumplir a ‘rajatabla’, y no daban lugar alguno a modificaciones de este tipo, salvo el uso de controles compensatorios, los cuales daban poca flexibilidad a las organizaciones. Siempre que se tenía una casuística de cumplimiento especial, se tenía que definir el control compensatorio y validar con el QSA, banco adquiriente y/o marcas de pago.

Por lo tanto, si todo prosigue según lo esperado, los requerimientos equivalentes en la versión v4.0 podrían ser modificados bajo el enfoque personalizado contemplado por PCI DSS v4.0.

Pero hasta que la versión 4.0 de PCI DSS no sea una realidad, bajo PCI DSS v3.2.1, si alguien se encuentra bajo la casuística expuesta en este artículo, lo primero que debe hacer es contactar con su QSA para confirmar la viabilidad de las flexibilizaciones indicadas en el apartado “Entonces, ¿cómo queda la situación?”, y si es necesario, contactar con las entidades adquirientes y marcas de pago según corresponda para validar las flexibilizaciones que se quiere implementar.

Referencias bibliográficas
1- Goodspeed, L. (2020). PCI DSS v4.0: Anticipated Timelines and Latest Updates. PCI SSC. https://blog.pcisecuritystandards.org/pci-dss-v4-0-anticipated-timelines-and-latest-updates
2- Goodspeed, L. (2021). PCI DSS v4.0 Timeline Updated to Support an Additional RFC. PCI SSC. https://blog.pcisecuritystandards.org/pci-dss-v4.0-timeline-updated-to-support-an-additional-rfc
3- 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
4- Holloway, L. (2020). A View into Feedback from the PCI DSS v4.0 RFC. PCI SSC. https://blog.pcisecuritystandards.org/a-view-into-feedback-from-the-pci-dss-v4-0-rfc
5- Mastercard. (2018).  8-Digit BIN Expansion Mandate and PCI DSS Impact. https://www.mastercard.com/content/dam/public/mastercardcom/globalrisk/pdf/8-Digit-BIN-Expansion-Mandate-and-PCI-DSS-Impact.pdf
6- PCI SSC. (2014). 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
7- PCI SSC. (2018a). Requirements and Security Assessment Procedures version 3.2.1. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
8- PCI SSC. (2018b). 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
9- PCI SSC (2021). 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
10- VISA. (2020a). Numerics Initiative: Simplified Requirements for Eight-Digit Issuing BIN Adoption. https://usa.visa.com/dam/VCOM/global/support-legal/documents/numerics-initiative-simplified-requirements-for-eight-digit-issuing-bin-adoption.pdf
11- VISA. (2020b). 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



Autor: Marc de Tébar - CISM, PCIP, MCAF, SFPC
Dpto. Consultoría

lunes, 8 de marzo de 2021

Diferencias entre la ISO22301:2012 y la ISO22301:2019

 La Organización Internacional de Estandarización (ISO) es una entidad que nace en Londres en 1946, independiente y no gubernamental. Rápidamente se convierte en un referente a nivel mundial en compartición de conocimiento, desarrollo de estándares que soportan la innovación y que provee soluciones para los retos a escala global, con un total de 165 países miembros en el momento de la redacción de estas líneas, en diciembre de 2020.

viernes, 5 de marzo de 2021

Inteligencia de fuentes abiertas OSINT en la lucha contra el COVID-19

Toda información proveniente de fuentes abiertas obtenida en el transcurso de nuestra investigación, o recopilación de datos para un cliente ya sea mediante la utilización de sistemas de recolección propios o de un tercero, resulta totalmente imprescindible que deba ser analizada.

Por tanto, resulta necesario y conveniente aplicar diferentes técnicas de análisis con la finalidad de elaborar un producto de inteligencia que, como resultado de dicha evaluación, integración, análisis e interpretación, pueda ser de utilidad a nuestro cliente.

Como no me he cansado de explicar en las diferentes ponencias realizadas, la inteligencia ha de ser proactiva y ha de tratar de avanzarse a los acontecimientos para facilitar que el cliente pueda aprovechar las oportunidades que dicha inteligencia le proporciona como, por ejemplo, ayudándole a la protección contra las amenazas de la manera más eficiente, ya sea mediante la detección de elementos indiciarios de la preparación de un ataque u obteniendo elementos de quien está detrás de una campaña contra su organización.

Existen múltiples y variadas técnicas de análisis que nos ayudan en la interpretación de dichos datos, donde cada una de ellas juega un papel definido y está enfocada a un ámbito diferente de la ciberinteligencia. Así, por ejemplo, disponemos del análisis de alto impacto, diagramas de influencia, análisis estructural, análisis de actores, creación de escenarios e indicadores, o la descomposición visual, donde situaríamos el análisis de redes.

El análisis de redes es un complemento en las tareas del analista, proporcionando herramientas visuales que le ayudan en el análisis y estudio de cualquier tipología de red. El análisis de redes proporciona al analista los elementos necesarios para realizar una revisión, compilación e interpretación de los datos de los que se disponen, ofreciéndole la posibilidad de observar los datos desde un nuevo punto de vista.

Charlas, Eventos y Entrevistas

El Centro Criptológico Nacional (CCN) y el INCIBE organizan por primera vez la I Jornada STIC – Capítulo Colombia.
 
Este evento, que se celebrará los días 16 y 17 de marzo bajo el lema "Ciberseguridad el compromiso que nos une", pretende impulsar la colaboración y el intercambio de información en materia de ciberseguridad a nivel internacional.
 
Carlos Seisdedos, responsable del departamento de Ciberinteligencia ha sido seleccionado para presentar la ponencia: Técnicas OSINT para la generación de Inteligencia el día 17 de marzo a las 9:30 (hora colombiana).
 
Más información sobre el evento:
https://www.ccn-cert.cni.es/ijornada-colombia.html

miércoles, 3 de marzo de 2021

Análisis de los Cambios Introducidos por la v1.1 de PCI SSLCS

 El pasado 18 de febrero de 2021 el PCI SSC publicó en el repositorio de su página web (https://www.pcisecuritystandards.org/document_library) la actualización de cuatro documentos a sus versiones 1.1:


Dichos documentos pertenecen al Marco de Software Seguro (PCI SSF - PCI Software Security Framework) y, en concreto, del estándar PCI Secure Software Lifecycle Standard (PCI SSLCS).

El estándar PCI Secure SLC junto con el PCI Secure Software Standard (PCI SSS) forman parte del marco de seguridad de software PCI (SSF). Este estándar proporciona requisitos de seguridad y procedimientos de evaluación para que los fabricantes de software se integren en sus ciclos de vida de desarrollo de software y validen que existen prácticas seguras de gestión del ciclo de vida.

miércoles, 24 de febrero de 2021

Red Team "No siempre lo mejor es lo más difícil"

¿Qué es el Red Team?

Un equipo de Red Team es un grupo de pentesters altamente cualificados que son contratados por una organización para probar sus defensas y mejorar su eficiencia. Básicamente, es la forma para utilizar estrategias, sistemas y metodologías para simular un escenario real y preparar las defensas de la compañía. Dichos ataques tienen que representar un ataque real de ciberdelincuentes bajo un entorno controlado.

miércoles, 17 de febrero de 2021

ISecAuditors se asocia con Kompleye para reforzar la oferta de servicios de auditoría para PCI y SOC 2

Kompleye es una empresa con licencia de contador público y evaluador de HITRUST que ofrece evaluaciones SOC 1, SOC 2, Compliance Attestation, certificación HITRUST, NIST 800-53 y 800-171. Kompleye's ha ayudado a clientes de diferentes sectores a completar con éxito sus auditorías y a reducir el estrés de las mismas.

Internet Security Auditors (ISecAuditors) es una empresa líder en servicios de ciberseguridad y en normas PCI. Sus sedes en Europa y Sudamérica les permiten operar en todo el mundo. Ha realizado con éxito cientos de certificaciones de evaluación del cumplimiento de las normas PCI desde 2007, y evaluaciones de pruebas de seguridad desde 2001.

viernes, 12 de febrero de 2021

SSL/TLS: UNA MIRADA AL ATAQUE BREACH

Para definir y comprender correctamente el ataque BREACH, es necesario tener una noción básica acerca de los ataques de canal lateral de compresión y un claro entendimiento sobre los algoritmos de compresión.

Algoritmos de compresión

Uno de los algoritmos de compresión más famoso es DEFLATE, el cual define la base del formato de archivo ZIP, la biblioteca zlib, gzip, PNGs, etc., y se compone de una combinación de codificación Huffman y compresión LZ77.
En los algoritmos de compresión como DEFLATE, se utilizan dos enfoques:

  • 1°: Las letras más utilizadas obtienen la representación más corta.
  • 2°: Cualquier frase que se repita solo se almacena una vez.

Centrándose en el segundo enfoque, si cierta cadena de caracteres se repite en algún lugar del texto, solo se almacena la primera vez junto con punteros que señalan dónde se encuentra nuevamente la misma secuencia. La segunda vez que ocurre, se incluye una referencia a la primera ocurrencia. 

miércoles, 10 de febrero de 2021

Internet Security Auditors patrocinador del CIBERSEG 2021

 Un año más la UAH (Universidad de Alcalá de Henares) ha organizado una nueva edición de las Jornadas de Seguridad y Ciberdefensa, está vez totalmente de forma online, los días 11 y 12 de febrero.

El objetivo de estas jornadas es la promoción y la difusión de temas relacionados con la seguridad y la ciberdefensa en el ámbito universitario. Para ello, se han programado un conjunto de charlas y talleres relacionados con temas de interés en este ámbito.

Después de las múltiples participaciones de Vicente Aguilera como ponente, este año desde Internet Security Auditors participamos como patrocinadores del evento.

Más información e inscripciones desde el siguiente enlace:
https://ciberseg.uah.es/