Vicente Aguilera entrevistado en el programa No Pot Ser! (No puede ser!) de TV3

https://pbs.twimg.com/media/D3z3CSrW4AAWpyW.jpg

Este domingo día 14 se emite la entrevista que realizó Vicente en el programa No pot ser! (No puede ser!) de la televisión catalana (TV3).

Jordi Basté, presentador del programa, explorará en este nuevo capítulo como de vulnerable es nuestra privacidad en Internet, y para ello ha contado con la ayuda de varios expertos en seguridad, entre los que se encuentra Vicente.

El programa completo en el siguiente enlace:
https://www.ccma.cat/tv3/alacarta/no-pot-ser/big-data-big-brother/video/5836380/

Eventos de Ciberseguridad para el mes de abril

Este mes de abril, se celebran varios eventos de seguridad, en los que Vicente Aguilera y Carlos Seisdedos participarán como ponentes.
  • Congreso de Ciberseguridad de Zaragoza #CONPILAR19 los días 12-13 de abril. Vicente y Carlos participarán con la ponencia: Twitter: la máquina de captar votos.


  • Overdrive Hacking Conference los días 26-27 de abril en Girona. Evento en el que Vicente a sido invitado para ofrecer la Keynote.
  • OSINT City los días 26-27 de abril en Sevilla. Taller conjunto de Vicente y Carlos: “Técnicas OSINT para la detección y análisis de perfiles terroristas” en el que se dará a conocer el uso de las redes sociales por parte de terroristas de etiología yihadista y cómo mediante técnicas OSINT es posible monitorizar sus actividades y obtener información que pueda convertirse en inteligencia procesable.


La experiencia RootedCON, vivida en su X aniversario

Esta edición 2019 de RootedCON Madrid, se llevó a cabo del 28 al 30 de Marzo en el espléndido entorno de Kinépolis Madrid Ciudad de la Imagen. No obstante, las actividades dieron comienzo realmente el 25 de marzo, con tres días intensos dedicados a formaciones (bootcamps) impartidas por expertos en la materia (entre los que se encontraban Raúl Siles y su taller sobre tecnologías inalámbricas, Pablo San Emeterio formando sobre explotación de vulnerabilidades, o Pablo González Pérez y su taller sobre pentesting).

Nuestra experiencia comienza la noche previa al inicio de las conferencias, es decir, la noche del 27 de marzo, donde asistimos a la habitual cena cóctel de ponentes en el restaurante Larumbe. Ya en su entrada, y ejerciendo de perfecto anfitrión, Román Ramiŕez (fundador de RootedCON) recibía a los invitados. Se trata de una ocasión perfecta para, en un entorno distendido, poder intercambiar opiniones, realizar nuevos contactos, o reencontrarse con aquellas personas con las que hace algún tiempo que no coincides. Además de tener la oportunidad de conversar con otros ponentes, también asisten patrocinadores y medios que asistirán al evento.

Jueves 28 de marzo
El jueves 28 de marzo, a primera hora, nos presentamos en Kinépolis donde ya se respiraba el "ambiente Rooted". Las colas para las acreditaciones eran considerables, pero sin llegar a exasperar. Sabes que vas a asistir a grandes momentos y, además, la espera sirve para comentar las últimas impresiones. Una vez dentro, muchas caras conocidas, muchos amigos, y mucho por aprender. Nota destacada: el número de asistentes a Rooted 2019 superó los 2200.

En el hall, diversos stands de empresas del sector anunciaban sus servicios. También se encontraba el espacio habitual de 0xWORD y sus conocidos libros de seguridad.

La primera conferencia de la jornada comenzó a las 10:30h y, bajo el título "Aproximación algorítmica al talento en ciberseguridad", Raúl Riesco Granadino (Head of Intelligence and ICS, INCIBE) nos narraba la evolución que ha sufrido la demanda de talento, la necesidad del mercado actual de especialistas en ciberseguridad, así como las habilidades que más escasean actualmente (entre las que destacan: detección de intrusiones, desarrollo de software y mitigación de ataques) entre otros aspectos. Así, comentó que las titulaciones y certificaciones, aunque valoradas, quedan relegadas a un segundo plano frente a la experiencia y conocimientos de la persona.

A continuación, Andrés Ruíz y Mar López (Responsable de Ciberseguridad, Departamento de Seguridad Nacional) hicieron una divertida exposición sobre "Descifrando la Seguridad Nacional". Obviamente, no revelaron ningún tipo de información sensible, pero siempre es de agradecer que este tipo de organismos tengan visibilidad en eventos de ciberseguridad, puedan expresar su punto de vista y podamos conversar con ellos.

Tras la entrega de Premios Antonio Ropero, y la pausa para el coffe-break, llegó el turno de Pablo Estevan Fernández (RSA) y su ponencia "Análisis de amenazas con herramientas de visibilidad avanzadas". Nos explicó cómo, tras sufrir RSA un incidente de seguridad hace pocos años, optaron por adquirir una de las empresas que les ayudó a identificar el origen de la intrusión, software que han ido mejorando durante este tiempo. Básicamente, trasladó la idea de que nadie es invencible, por lo que conviene ser proactivos y disponer de capacidad de detección de incidentes, así como de una clara estrategia al respecto.

Más tarde, asistimos a la conferencia "N4J, Horizonte de sucesos" impartida por Francisco Javier Sucunza Berasain. Nos habló de los "knowledge graphs", como una conexión dinámica de repositorios de datos de distintos tipos y que enlazan con fuentes externas de una manera inteligente. Como resultado, permite inferir conocimiento a través del contexto y las relaciones. Francisco comentó la diferencia entre consultas SQL y consultas con Cypher (el lenguaje de consulta de grafos para Neo4j), dejando en evidencia la facilidad y la potencia de Cypher en este contexto.


Viernes 29 de marzo
El viernes 29 de marzo era el día de nuestra participación. Acudimos con tiempo suficiente a la primera conferencia "Hackers vs Cine: las loca ciberhistoria del cine. mitos y desventuras de la ciberseguridad en el séptimo arte" que impartieron conjuntamente Francisco Jośe Ramírez Vicente (Telefónica) y José Manuel Vera Ortiz (Revista SIC). Como ya anunciaron en su inicio, no se trataba de una charla técnica. Sin embargo, resultó muy entretenida recordando viejas (y no tan viejas) películas en las que se había tratado la ciberseguridad de mejor o peor manera. Por supuesto, se habló del origen de la palabra hack y cómo se había desvirtuado gracias a los periodistas y el sensacionalismo, y no faltaron referencias a Steve Jobs, Bill Gates, Steve Wozniak, Richard Stallman, Kevin Mitnick o John Draper (el Capitán Crunch), entre otros muchos.

A continuación, en la misma sala, nos llegaba el turno a nosotros (Carlos Seisdedos y Vicente Aguilera), que impartimos la conferencia "Análisis de redes sociales (ARS) y detección de comunidades virtuales". Tras una breve introducción para contextualizar a los asistentes en los conceptos que se tratarían después, realizamos algunas demostraciones en vivo utilizando una pequeña aplicación que desarrollamos específicamente para Rooted. Mostramos el potencial que se dispone al analizar las redes sociales mediante la aplicación de técnicas de inteligencia artificial, y como pueden ser monitorizadas a tiempo real para analizar su contenido. De esta forma, utilizamos distintos videos en los que se podían realizar búsquedas por palabras clave (que se mostraran en alguna secuencia del video), o incluso búsquedas basadas en nombres de personas que aparecían en los videos, gracias al reconocimiento facial. Para ello, pusimos el ejemplo del rey Felipe VI que aparecía en un video durante la manifestación tras los fatídicos atentados terroristas sufridos en Barcelona. A continuación, presentamos una metodología de análisis de redes sociales, la importancia de considerar las redes formales e informales en los procesos de análisis de objetivos, así como su uso en acciones de influencia. Finalmente, realizamos diversas demostraciones en las que se mostraba la evolución de una red social a lo largo del tiempo: conexiones entre nodos, publicación y clasificación de contenidos, detección de comunidades virtuales, etc.

Queremos agradecer su asistencia a todos los que nos acompañaron durante la conferencia, que despertó gran expectación a juzgar por el número de asistentes a la misma.

Tras la pausa para la comida, llegó un momento que seguro era de los más esperados por la mayoría de las asistentes en base a las colas que se formaban con más de media hora de antelación. Nos referimos a la conferencia de Chema Alonso (CDO de Telefónica) titulada "A hacker's gotta do what a daddy's gotta do". Con una duración más reducida de lo esperada (lo bueno si breve...) Chema nos comentó su experiencia personal acerca de cómo los hijos se introducen en la tecnología a edades cada vez más tempranas. Con dos divertidos videos, nos hizo ver como sus hijas le acompañan en algunas de sus experiencias.


Sábado 30 de marzo
El sábado 30 de marzo, únicamente pudimos asistir a la interesante conferencia de Pablo González y Enrique Blanco, del Departamento de Ideas Locas de Telefónica. Nos hablaron sobre IA aplicada a la ciberseguridad, y nos mostraron resultados de su investigación con ejemplos prácticos en vivo. Especialmente llamativo fue lo que llamaron "La estafa del CDO", en la que, tras un modelo entrenado previamente, conseguían suplantar la imagen y voz de Chema Alonso para llevar a cabo una acción maliciosa. También nos ilustraron sobre las famosas GANs (Generative Adversarial Networks) y la elaboración de deep fakes. Los patrones biométricos que pueden identificarse en los videos permiten detectar manipulaciones que pueden derivar en fake news. Se trata de un problema que puede abordarse mediante técnicas de machine learning.

De forma previa a la conferencia de Pablo González y Enrique Blanco, Román Ramírez ofreció un reconocimiento especial a Agux, una de las personas que asiste fielmente a todas las ediciones de RootedCON y que, además, es de los primeros en inscribirse y personarse en los eventos.

Finalmente, queremos felicitar a RootedCON por su X aniversario y el gran éxito conseguido, así como agradecer a los organizadores por permitirnos participar en esta edición y hacernos sentir como en casa.

Autores:
Vicente Aguilera - CISA, CISSP, CSSLP, ITILF, PCI ASV, CEH, ECSP, OPST/A OWASP Spain Chapter Leader. Director Departamento de Auditoría.
Carlos J. Seisdedos. Responsable Departamento Ciberinteligencia.

Análisis de la actividad en Twitter relacionada con los candidatos de los principales partidos políticos

Con motivo de las próximas elecciones generales en España el próximo 28 de abril, en Internet Security Auditors hemos realizado el análisis de la actividad en Twitter relacionada con los candidatos de los principales partidos políticos: Pedro Sánchez (PSOE), Pablo Casado (PP), Albert Rivera (Ciudadanos), Pablo Iglesias (Podemos) y Santiago Abascal (VOX), elaborando una serie de infografías con la información más relevante.

Hoy publicamos las infografías que resumen la actividad en Twitter del periodo comprendido entre el viernes 8 y el jueves 14 de marzo, en el que se han analizado más de 400.000 tuits. Entre la información que se muestra, se encuentra la siguiente:
  • Datos sobre el perfil de cada candidato
  • Actividad de cada candidato desglosada por horas
  • Aplicaciones utilizadas por cada candidato
  • Nube de hashtags utilizados por cada candidato
  • Número de menciones a cada candidato, desglosada por día
  • Franjas horarias de cada día con mayor número de menciones a cada candidato
  • Evaluación y clasificación de los mensajes en los que se menciona a cada candidato, desglosados en: Muy positivo, Positivo, Neutral, Negativo y Muy negativo.
  • Nube de palabras más utilizadas por cada candidato

Infografía Pedro Sánchez (PSOE):

https://www.isecauditors.com/downloads/infografias_2019/pedro-sanchez.png

Infografía Pablo Casado (PP):

https://www.isecauditors.com/downloads/infografias_2019/pablo-casado.png















Infografía Albert Rivera (Ciudadanos):

https://www.isecauditors.com/downloads/infografias_2019/albert-rivera.png















Infografía Pablo Iglesias (Podemos):

https://www.isecauditors.com/downloads/infografias_2019/pablo-iglesias.png















Infografía Santiago Abascal (VOX):

https://www.isecauditors.com/downloads/infografias_2019/santiago-abascal.png















Dejamos en manos del lector la interpretación de los interesantes resultados que revelan estas infografías, y le invitamos a permanecer atento a las próximas actualizaciones.

Carlos Seisdedos invitado al curso Terrorismo, inmigración y ciberamenazas: nuevos desafíos del siglo XXI para debatir sobre Ciberinteligencia

El próximo 26 de abril da comienzo el curso: Terrorismo, inmigración y ciberamenazas: nuevos desafíos del siglo XXI organizado por la Fundación General de la Universidad de Málaga y Carlos Seisdedos, ha sido invitado como experto en la materia para debatir sobre estos temas.

Más información:
https://fguma.es/course/terrorismo-inmigracion-ciberamenazas-nuevos-desafios/

Tokenización en PCI DSS: FAQ y diseño básico de una solución con AWS (Capítulo 1)

La mejor manera sin duda alguna de reducir el ámbito de aplicación de PCI-DSS sobre cualquier sistema que trate datos de tarjeta, resulta tan eficaz como obvia: no usar datos de tarjeta.

Lamentablemente, no siempre es posible, por lo que una buena aproximación puede ser la tokenización de estos datos de tarjeta; otra sería el cifrado, del cual podemos hablar en otro artículo si algún lector está interesado.

En este artículo trataremos el tema de la tokenización en relación a PCI-DSS, repasando los conceptos básicos de la tokenización, hasta mostrar un diseño básico de implementación de un tokenizador para las tarjetas de pago empleando los servicios en la nube de Amazon Web Services.

Hemos dividido el artículo en dos partes:
  • Capítulo 1:  Tokenización, ¿qué, por qué y para qué?
  • Capítulo 2:  Diseño básico de una solución en AWS
A lo largo del artículo, para evitar interpretaciones erróneas o confusas, emplearemos la nomenclatura oficial en inglés vista en la norma y guías del PCI Security Standards Council (PCI SSC), VISA, MASTERCARD y Amazon Web Services (AWS).

Capítulo 1. Tokenización, ¿qué, por qué y para qué?

Antes de entrar en materia, esta primera parte la dedicaremos a clarificar algunas preguntas frecuentes que suelen surgir al respecto de la tokenización así como algunas confusiones o interpretaciones poco precisas que suelen traer de cabeza a aquellas organizaciones que deciden emprender un proyecto de tokenización en sus servicios.

Definiciones y conceptos previos:

Acquirer: también se lo conoce como "banco adquirente" o "institución financiera adquirente", es la entidad bancaria que ofrece al comercio el procesado de sus transacciones de tarjetas de pago, y por lo tanto existirá un contrato entre el adquiriente y el comercio para la prestación de dichos servicios. El adquiriente está reconocido por una marca de pago como tal (Visa los denomina como “Visa Europe member”), y se encuentran sujetos a las reglas y procedimientos de las marcas de pago con respecto al cumplimiento del comerciante.

Issuer: También se lo conoce como "banco emisor" o "entidad financiera emisora", es la entidad bancaria responsable o que respalda la emisión de las tarjeta bancarias a su titular junto con el PIN, o que presta servicios de emisión relacionados (p.ejem. servicio de autenticación de las transacciones).

Processing: operaciones entre una o varias redes de pagos que incluye los servicios de:
  • «Authorization» (autorización): garantizar que la transacción sea válida
  • «Clearing» (compensación): garantizar la disponibilidad de fondos
  • «Settlement» (liquidación): garantizar que el importe se abone y cargue de forma apropiada.


Nota aclaratoria: En España, tenemos una casuística un poco especial, ya que en la práctica los adquirientes no realizan el procesado de las transacciones, esa función la delegan en sus procesadores de pago (Redsys  o Cecabank ), que prestan el servicio en su nombre de manera trasparente para el comercio (son denominados “member agent” por Visa), las cuales a su vez están conectadas a redes de pagos para operativas internacionales (Visa,Mastercard, UnionPay, AMEX, etc.) y nacionales (por un lado ServiRed  y Sistema 4B , dependientes de Redsys, y por otro euro6000 , dependiente de Cecabank); cómo ver una red de pago de forma simplificada, como un procesador junto con varias entidades bancarias adheridas. La fusión entre las diversas redes de pago nacionales fue aprobada por la CNMV el pasado 1 de febrero del 2018.

Datos sensibles de autenticación: son los datos correspondientes a la banda magnética o datos equivalentes en chip de la tarjeta, el CAV2/CVC2/CVV2/CID, o el PINs/PIN blocks.

Pre-authorizatoin: también abreviado como “pre-auth”, en esta operación únicamente existe un flujo de información, no se lleva a cabo ningún flujo contable. Típicamente, cuando un comercio recaba los datos de tarjeta para un pago pero no va a procesarlo hasta pasado un tiempo, p.ejem. al generar las reservas en hoteles, cuyo cobro muchas veces no se realiza hasta el check-out, o en el alquiler de vehículos, se lanza una pre-autorización con el objetivo único de validar que la tarjeta existe, se encuentra activa y tiene fondos suficientes (nunca puede ser con un importe superior al total final). Ésta “pre-auth” expirará normalmente en los siguientes 7 días para MASTERCARD o en 30 días para VISA en caso de que finalmente no se acabe realizando la “authorization” por la totalidad del importe (estos periodos suelen variar en cada marca de tarjeta según el Merchant Category Code (MCC) asignado a la entidad. En el caso de tarjetas de crédito, esta “reserva” se suele visualizar como un decremento en el límite de crédito en la cuenta destino; en el caso de las de débito, de suele observar como un asiento contable temporal.

Pregunta: ¿A qué nos referimos con tokenización en el mundo PCI-DSS?

Respuesta corta: PCI-DSS aplica sobre los datos de tarjeta, si en su lugar tenemos un token…. quizás pueda evitar que me aplique PCI-DSS.

Respuesta larga: La idea subyacente de la tokenización es simple: transmutar algo valioso y útil como es un PAN en algo que no vale nada por sí mismo, como es un identificador formado por una secuencia de dígitos y/o caracteres que llamaremos token, y que solo puede ser usado para iniciar una transacción dentro de un contexto determinado (una aplicación, sistema, etc.). Para saber identificar si estamos realizando una adecuada implantación de nuestro sistema de tokenización debemos tener presente en todo momento esta máxima; en el momento en que un atacante pudiese darle valor a ese token en otros contextos no autorizados (i.e. emplearlo para realizar una transacción cuando y donde quiera, p.ejem. en otros comercios), nuestra solución dejará de ser viable, al menos para el propósito de reducir el alcance de PCI-DSS.

Pregunta: ¿qué datos puedo tokenizar?

Respuesta corta: según el requerimiento 3.2 de PCI-DSS, todo dato de tarjeta es tokenizable salvo los datos sensibles de autenticación (banda magnética o datos equivalentes en chip, CAV2/CVC2/CVV2/CID, y PINs/PIN blocks)

Respuesta larga:  en caso de que llegásemos a generar un token a partir de estos datos sensibles antes de realizar la “Authorization”, deberá ser tratado tal y como se haría con el dato en claro, debiendo ser igualmente borrado una vez se haya recibido la autorización de la transacción , cuya única excepción será en caso de que seamos un emisor de tarjetas o participemos en la emisión de las mismas. En este sentido, es importante tener claro el concepto de “pre-authorization” frente al de “authorization” de una transacción que describimos en el apartado inicial “Definiciones y conceptos previos”. Mientras dure la “pre-authorization”, los datos sensibles de autenticación o el token generado en su lugar, podrán ser almacenados.

Pregunta: ¿Qué tipos de tokens existen? ¿aplica PCI-DSS sobre todos ellos?

Respuesta corta: Varios, incluso podemos tener diferentes formas de clasificarlos, dependiendo de quién los genera y emite, con qué límites se pueden emplear (en qué contexto o si puede ser empleada más de una vez); cada uno tiene sus ventajas e inconvenientes y sobre algunos no aplica PCI-DSS.

Respuesta larga:
Según PCI-DSS, tenemos los siguientes tipos de tokens:
  • Acquiring tokens: son tokens generados por el adquiriente, un comercio o un proveedor a partir del PAN original facilitado por el titular de la tarjeta. No sigue ningún estándar o norma, generándose según criterios y formatos que la entidad desee ya que generalmente es solo para su propio uso. Una vez generados, este tipo de tokens no pueden ser empleados para posteriores autorizaciones , a menos que sea para procesar pagos recurrentes ya autorizados (es importante tener en cuenta que para los pagos recurrentes no es necesario conservar los datos sensibles de autenticación una vez ya se ha realizado la primera autorización), o bien si ofrecemos al usuario la posibilidad de almacenar sus PAN para futuras compras, conocido como “card-on-file” por PCI-DSS (en este caso, será necesario solicitar de nuevo al titular los datos sensibles de autenticación para poder autorizar la transacción).

    Este tipo de tokens serán los que podremos generar como comercio o proveedor de servicios y será el objeto de nuestro diseño de tokenizador.
  • Issuer tokens: llamados también electronic-only PANs, Virtual Credit Card (VCC) por VISA o Virtual Card Number (VCN) por MASTERCARD, son generados por los emisores del pago y son indistinguibles de un PAN real. Son ampliamente usados por el sector turístico (p.ejem. Online Travel Agencies (OTA) como Booking.com o Expedia.com, y Global Distribution System (GDS) como Amadeus) en su modalidad “single-use o one-time” ya que una vez empleadas para trasferir el pago a algún comercio como un hotel (entendiéndose el concepto de “empleadas” por el hecho concreto de que ya se ha realizado la autorización de la transacción), no pueden volver a ser usadas para futuras transacciones sin ser rechazadas.

    Sobre estos últimos tokens, cuyo acrónimo es SU-VCC/VCN (Single-use Virtual Credit Card/Number), cada una de las marcas de pago determina si le aplica PCI-DSS o no y bajo qué circunstancias; en el caso concreto de VISA y MASTERCARD, a fecha de este artículo, nos indican expresamente que no es necesario protegerlos bajo PCI-DSS (si solo tratamos este tipo de tokens en nuestros sistemas, podríamos no aplicar PCI-DSS sobre éstos). En el caso de VISA matiza una excepción: solo estaremos exentos de aplicar PCI-DSS sobre los mismos si somos el receptor del token (el caso habitual si somos un comercio), pero no si lo emitimos o participamos de algún modo en la emisión de los mismos.

    En el caso de que tratemos con MU-VCC/VCN (Multi-use Virtual Credit Card/Number), i.e. tarjetas válidas para más de una transacción, siempre nos aplicará PCI-DSS.
  • Payment tokens: también llamados EMVCo Payment Tokens, son emitidos a los propios titulares de la tarjeta, así como a los merchants que empleen sus servicios, por los proveedores de tokenización (TSP) registrados bajo el esquema EMVCo Technical Framework  y que deben cumplir a su vez con la norma PCI TSP. El titular del token lo puede usar en un comercio como si de una tarjeta real se tratase, y es muy habitual en los pagos “1-Clic” en comercios online donde se busca evitar que el usuario tenga que volver a introducir sus datos de tarjeta. En este escenario, el titular de la tarjeta únicamente emplea el token para realizar el pago, y el comercio únicamente recibe ese token para iniciar la transacción.
    Un par de ejemplos típicos en comercio online lo encontramos en Paypal, empleado directamente por el titular de la tarjeta o ApplePay; en el caso del comercio en venta presencial, lo podemos encontrar en tarjetas empleadas por compañías de alquiler de vehículos por horas, donde realizamos el pago de combustible con tarjetas físicas con un token en formato chip.
    Cualquier comercio o proveedor que únicamente trate en sus sistemas EMV Payment Tokens, no está obligado a implementar PCI-DSS.
     
Pregunta: soy un comercio o proveedor ¿en qué medida puedo reducir la aplicación de PCI-DSS empleando tokens?

Respuesta corta: como la mayoría de las cosas en la vida, depende y mucho, y en este aspecto el PCI SSC no concreta más de lo estrictamente necesario, dejándolo a criterio de las marcas de pago y adquirientes según cada caso.

Respuesta larga: de manera muy resumida, tenemos dos grandes opciones si decidimos aplicar tokenización para reducir el alcance de PCI-DSS (mostradas de mayor reducción del entorno a menos, y dejando de lado otras soluciones híbridas que habría que analizar en cada caso concreto):

Opción 1) Contratar los servicios de un proveedor de tokenización de manera que únicamente almacenemos, procesemos o trasmitamos tokens en nuestros sistemas. En este escenario, dependerá de cómo integremos en nuestros sistemas la pasarela del proveedor de tokenización, a modo ilustrativo y no limitativo, podríamos tener que:
  • Aplicar los requerimientos relativos a un SAQ A/ROCA si somos un comercio o los análogos dentro de un SAQ-DA o ROCA si somos un proveedor, cuando integramos la plataforma del tokenizador en una redirección o iframe donde el titular de la tarjeta introduzca sus datos en una web ajena a la nuestra. 
  • Aplicar los requerimientos relativos a un SAQ A-EP/ROCA-EP si somos un comercio o los análogos dentro de un SAQ-DA-EP o ROCA-EP si somos un proveedor, cuando integramos la plataforma del tokenizador empleando un formulario de captura de datos del titular de la tarjeta generado por nosotros mediante métodos y acciones Javascript, o una API/Webhook (también llamado “Direct Post”). 
  • Aplicar los requerimientos relativos a un SAQ D/ROC si capturamos y enviamos los datos de tarjeta vía XML, JSON, otros… 

Opción 2) Montar nuestro propio tokenizador (estaríamos generando los llamados “acquiring tokens”), de manera que al menos una parte de nuestro entorno única y exclusivamente tenga acceso a los tokens, no esté conectado el sistema o red directamente a la zona del tokenizador y no tenga acceso a la obtención de los PANs o funciones/API que devuelvan el PAN a partir de los datos que posea.

En este escenario, por norma general, sobre el entorno que procese/almacene o transmita únicamente los tokens, podríamos dejarlo fuera del alcance de PCI-DSS (en caso de duda, siempre se deberá acudir a un PCI-DSS QSA debidamente acreditado, el cual valorará esta exclusión del alcance).

Veamos un clásico ejemplo de mal diseño…

Supongamos que soy un comercio y despliego una solución capaz de tokenizar mis datos de tarjeta (PANs), y qué como resultado, mi solución me devuelve el token más un hash de la tarjeta, los cuales almacenaré en una base de datos que yo, a priori, considero fuera de alcance de PCI-DSS, ya que teóricamente no hay ningún dato de tarjeta…

PAN original:   1111 2222 3333 4444

Token generado:   1111 22ab cdef 4444

Hash: 62530E41812B2028A7B0415237A10DA8475EB5739F36529734C3BB777083E26

En este ejemplo, el algoritmo hash empleado no tiene mayor importancia.

¿y dónde está el problema?

Fijémonos que cualquiera que acceda al token y al hash, podría de manera trivial encontrar por fuerza bruta en un corto tiempo cuales son los valores truncados ya que sólo hay 10^6 combinaciones posibles, y eso sin descartar aquellas combinaciones que no cumplan el algoritmo de Luhn. Por todo esto, podemos llegar a valorar que allá donde se almacene el token más el hash, será equivalente en cuanto a los requerimientos de PCI-DSS aplicables, a tener el PAN en claro almacenado.

Finalmente, se nos presenta un dilema cuando revisamos la guía emitida por el PCI SSC relativa a la generación de “acquiring tokens” que lleva por título “Information Supplement - PCI DSS Tokenization Guidelines”  (importante notar que, al fin y al cabo, son eso: “guías”, no se consideran parte de la norma), en su página 20 nos presenta lo que llama “high-value tokens”, que al parecer son todos aquellos tokens que permitan iniciar una transacción por sí mismos, en cuyo caso, serán consideramos como si fuesen PANs en claro y les aplicarán los mismos requerimientos de PCI-DSS.

En este sentido, y como opinión personal después de que tras años de la aparición de dicha guía, aún no se haya especificado nada más concreto y clarificador de qué es un “high-value token”, es necesario una evaluación detallada de cada implementación por un PCI-DSS QSA, con el fin de determinar si ese token es o no de este tipo en base a: cómo se genera, en qué contexto se puede usar, cual es el riesgo real de fraude, etc.

En el siguiente capítulo…
En el próximo capítulo, Diseño básico de una solución en AWS, presentaremos el código básico y diseño de la arquitectura serverless que pretendemos desplegar a modo de prueba de concepto en nuestra cuenta de Amazon Web Services (https://aws.amazon.com), empleando, entre otros, los servicios de AWS API Gateway, AWS Lamda, etc…

Autor: Ero Rodríguez Losada - CISA, CRISC, PCI QSA, PCIP, ISO 22301 L.A., ITILF
Dpto. Consultoría

Vicente Aguilera y Carlos Seisdedos participan en el evento CISO Day 2019

El próximo 12 de junio se celebra en Madrid el evento CISO Day 2019, uno de los eventos que marcarán la agenda del sector de la ciberseguridad en este 2019.

Un evento que hace hincapié en la importancia del flujo de información dentro de una industria tan cambiante y retadora como la de la ciberseguridad. Basará su agenda en los 6 niveles fundamentales de la ciberseguridad: Estratégico (CISO), Analítico (Ciberinteligencia), Institucional (INCIBE), Innovador (CyberStartup), Security (Proveedores) y Técnico (Hacking).

Vicente Aguilera y Carlos Seisdedos participarán este año en la mesa redonda con la temática de Ciberinteligencia.

Más información sobre el evento en:
https://cisoday.es/