Políticas de privacidad online, tras el RGPD

Recientemente la Agencia Española de Protección de Datos (AEPD) ha publicado una nota de prensa y un informe relativo a la adaptación de las políticas de privacidad online al Reglamento General de Protección de Datos (RGPD).

En esta labor, durante los primeros meses de vida del RGPD, es decir, desde el 25 de mayo de 2018, que es cuando es de obligado cumplimiento este reglamento, la AEPD ha analizado las políticas de privacidad de varias empresas que prestan sus servicios desde Internet, y ha recogido en una nota de prensa las incidencias y errores más comunes, ofreciendo las recomendaciones oportunas para paliarlas y, así cumplir con el RGPD.

En esta nota de prensa se destaca que, las políticas de privacidad no son concisas y no facilitan al usuario final e interesados su comprensión como se indica y exige en el RGPD; no se utiliza un lenguaje conciso y claro, y en cambio, se utilizan “expresiones ambiguas o demasiado genéricas, que no aportan información real”. Hay que recalcar que uno de los principios sobre los que se basa el reglamento es el principio de transparencia, basado en el objetivo de aportar una mayor cantidad de información al interesado, de tal modo que este conozca, antes de que proporcione cualquier tipo de dato a un tercero, de qué forma se van a tratar sus datos y los derechos y vías de reclamación de las que dispone en caso de que sea consciente o crea que sus datos no se están tratando de una forma lícita en base a los principios del reglamento.

En el análisis realizado, se hace hincapié en cómo se enumeran las finalidades para las cuales se pretenden hacer uso de los datos de los interesados, y la no opción por parte de las empresas, para que los interesados puedan dar el consentimiento de forma granulada en las finalidades que precisan. En este sentido, el objetivo que persigue el reglamento es que el interesado tenga en todo momento control de las finalidades para las cuales quiere proporcionar sus datos personales a una empresa. Una mala práctica, que se viene llevando a cabo en los últimos años, es la de aglutinar varias finalidades bajo el mismo consentimiento, cuando en ocasiones, estas finalidades no son necesarias para prestar el servicio que el cliente desea contratar, como, por ejemplo, la de envío de comunicaciones comerciales. Por esto, se debe poner en práctica una política que permita granular cada una de las finalidades para las cuales una empresa desea tratar los datos personales, otorgando el control al interesado de escoger la finalidad o finalidades que le satisfagan.

Por otro lado, puede darse la situación que alguna de las finalidades sea imprescindible para la prestación del servicio, en este caso, el responsable del tratamiento deberá indicar en la política de privacidad esta condición y que sea el interesado el que decida si prestar sus datos o no.
Otro aspecto que se destaca de este análisis, y que se debe tener en cuenta, es la información que se proporciona al interesado relativa al periodo de conservación de los datos de carácter personal, en la cual se ha detectado que no se ofrece al interesado una información clara acerca de cuánto tiempo se conservan los datos, indicando la normativa aplicable, el plazo establecido por la misma, o la información que permita al usuario calcular dicho plazo, más bien, se utilizan frase genéricas que no aportan ningún tipo de valor ni información al interesado.

Por último, también se indican los errores existentes en cuanto a la base que legitima el uso de los datos personales por parte de un responsable del tratamiento, en la que la AEPD explica el mal uso que se viene haciendo del interés legítimo por parte de las empresas para legitimar un tratamiento de datos de carácter personal. El Grupo de Trabajo del artículo 29 (GT29) ya indicó, que es necesario realizar una ponderación y un análisis detallado entre el interés del responsable de datos de carácter personal y de los derechos y libertades del interesado, con el objetivo de poder decidir si un tratamiento de datos de carácter personal puede ser legitimado por esta base, si se debe buscar otra base legitimadora o incluso puede que no sea un tratamiento lícito, y por tanto no se pueda llevar a cabo.

Por último, una vez que entre vigor la nueva legislación de protección de datos en España, quedará por analizar, las particularidades que se añadan respecto a estos puntos y cómo afectará a las empresas en sus políticas y procesos de negocio.


Autor: Sergio Moreno - PCIP, CCNA
Dpto. Consultoría

Vicente Aguilera participa un año más en el CyberCamp como ponente y miembro del jurado del Hackathon





Un año más se celebra una nueva edición del CyberCamp el gran evento de ciberseguridad anual organizado por el Instituto Nacional de Ciberseguridad de España (INCIBE) en el que, a través de un amplio programa de actividades, se pretende ofrecer contenidos de interés para todos los públicos. Y un año más han contado con Vicente Aguilera cómo miembro del jurado de la ya conocida competición presencial de desarrollo colaborativo de software y/o hardware: Hackathon.

También estará presente como ponente en el taller: Aplicación de técnicas OSINT/SOCMINT para la detección y análisis de perfiles terroristas, el viernes 30 de noviembre y será retransmitido por streaming.

Este taller técnico mostrará el uso avanzado de dos herramientas ("tinfoleak" y "magneto") que permiten analizar los contenidos publicados en las redes sociales Twitter y Telegram y permitirá conocer a los asistentes cómo es posible utilizar estas herramientas para extraer datos e información útil para la generación de inteligencia por parte de un analista.

Riesgos en el uso de las Redes Sociales

Muchas veces no somos conscientes de la aparente “necesidad” de estar en las RRSS y los riesgos que estas nos pueden suponer a muchos de nosotros. El ser humano es social por naturaleza, y las RRSS permiten llevar al extremo esa característica. Parece ser que la sociedad nos “obliga” a tener presencia en las redes y da la sensación de que nuestro valor reside en el número de seguidores que tenemos.

Las RRSS han motivado que nos encontremos más expuestos, y que un tercero pueda llegar a obtener un gran volumen de información sobre nosotros. En general, no sólo se utilizan para fines profesionales, sino más aún para fines personales, con perfiles públicos y abiertos.

Al publicar contenido, por ejemplo, puede estar activa la geolocalización, la cual nos revela datos de la ubicación desde la que se publica dicho contenido y, por tanto, el lugar en el que se encuentra una persona, o publicar fotográficas que revelan datos sensibles o pequeños detalles que pueden ser aprovechados por un tercero, además de otros muchos aspectos que pueden ser detectados y abusados por personas con fines maliciosos.

El problema de la geolocalización
Existen diversos mecanismos que ayudan a validar la información de los usuarios que se encuentra expuesta. A continuación, vamos a utilizar una herramienta a modo de ejemplo, para listar algunos de los datos mencionados anteriormente:

Tinfoleak- es una aplicación open-source desarrollada en Python y disponible aquí para su descarga: “https://github.com/vaguileradiaz/tinfoleak”. La herramienta permite extraer información de las publicaciones realizadas por los usuarios de Twitter. Para ello, se pueden realizar consultas en base a un nombre de usuario, unas coordenadas geográficas, o determinados filtros (fecha y hora de origen y fin, palabras  clave, aplicaciones utilizadas, etc.)

A  continuación, se muestra la cabecera del informe HTML que genera como resultado (en este caso,
sobre el usuario “CIA”):


Una de las funciones implementadas en tinfoleak es la búsqueda de publicaciones en un área geográfica determinada. Por ejemplo, a partir de unas coordenadas y un radio de acción, la herramienta extrae información y la muestra de forma estructurada revelando los datos más relevantes. La siguiente captura muestra como es posible identificar el lugar en el que se encontraban los usuarios, así como el contenido que publican y las aplicaciones utilizadas:


Alguien que identifique nuestra ubicación, puede utilizarla para conocer si nos encontramos fuera de la vivienda (por tanto, susceptible de sufrir un robo) o para predecir nuestros movimientos (por ejemplo, para conocer nuestro lugar de trabajo, el colegio de nuestros hijos, o donde vamos a cenar los viernes por la noche).

El uso del doble perfil
En muchas ocasiones, los usuarios disponen de varias cuentas en RRSS. Una, la “oficial” y otra la “oculta” donde utilizando un perfil anónimo permite dar rienda suelta a la verdadera personalidad del usuario.

Podría citar algún ejemplo mediático como el caso de la gran actriz Jennifer Lawrence (“Los juegos del hambre”), que ha confesado que tiene una cuenta secreta en redes sociales desde hace años. Otro ejemplo sería el de James Comey, ahora exdirector del FBI, que reconoció él mismo en una conferencia sobre inteligencia y seguridad nacional que tenía cuentas secretas en Twitter e Instagram solo para familiares y amigos cercanos. Otro caso es el de Adele, quien dice tener una cuenta secundaria en Twitter porque sus representantes no le tenían permitido publicar en su propio perfil sin supervisión (por si decía cosas inapropiadas cuando se encontraba en un estado de embriaguez).

Es increíble como las noticias falsas (fake news) creadas ya sea por un usuario, organización, un estado... pueden llegar a influenciar en la sociedad. Este tipo de noticias por lo general suelen jugar mucho con los sentimientos. Esto logra que en cuestión de minutos miles de personas pueden tomar estas noticias como reales. La gente que está detrás de estas noticias falsas quieren causar algún tipo de impacto en nuestra sociedad. Veamos algunos ejemplos:

Ejemplo1: El falso independentista. El 1 de octubre circuló en Twitter la fotografía de un hombre que tiene la mitad del rostro ensangrentado. A su lado, otra persona la auxilia poniendo sobre su cabeza una tela verde. El texto del tuit decía que había sido herido en un barrio de Barcelona con un proyectil de goma de las fuerzas antidisturbios y pedía la renuncia de Rajoy a la presidencia del gobierno de España. La imagen fue replicada como prueba de los excesos de la Policía en Cataluña, pero se trataba de una foto tomada en el 2012. El hombre de la imagen era un minero que había resultado herido cinco años antes en una protesta en Madrid.


Ejemplo2: Una mujer con hiyab en el puente Westminster. El 22 de marzo de 2017 un vehículo arrolló a decenas de personas sobre el puente Westminster de Londres, matando a 6 y dejando heridas a 49. El atentado fue reivindicado por el Estado Islámico. Horas después del ataque, la foto de una mujer musulmana con hiyab (velo que cubre la cabeza) y que camina al lado de un grupo de personas que atiende a un herido sobre el puente, circuló en Twitter. El post comentaba que la joven seguía su paso con actitud indiferente ante las víctimas y varios se sumaron a esa crítica. Días después, la mujer se pronunció sin revelar su nombre a través de TellMAMA, una organización que lucha contra la islamofobia en Reino Unido. Comentaba que no sólo estaba destrozada por sufrir las consecuencias de un ataque terrorista, sino que también le inquietaba ver su foto en las redes sociales las cuales hablaban de odio hacia su persona y comentarios xenófobos.


Es lógico que quien crea este tipo de noticias lo hace con una intención y no precisamente buena.

Cada día mucha gente sube fotos, videos, audios y demás contenido a redes sociales, pero … ¿sabemos qué información estamos suministrando (consciente o inconscientemente) cada vez que publicamos contenido? ¿Nos preguntamos acaso quien podría llegar a ver lo que publicamos? ¿Qué uso podrían hacer de nuestra información?

Realmente, no nos paramos a pensar en el tipo de personas que pueden acceder a nuestras publicaciones: ciberdelincuentes, ciberterroristas, empresas organizadas, etc...  que quieren aprovecharse del usuario con el fin de ganar dinero a su costa u obtener datos para ser utilizados con fines maliciosos y/o infectar a su vez a otros usuarios, facilitando así su distribución.

Alguna de sus técnicas, por comentar un ejemplo claro, sería el típico mensaje que nos ha llegado a todos y nos indica “por favor comparte este mensaje…”. No todo el mundo reflexiona sobre las intenciones de la persona que ha creado dicho mensaje, y lo difunde de forma totalmente ingenua. Dicho mensaje podría contener un enlace que nos acabe infectando, extraiga datos privados, etc. El atacante se aprovecha de la falta de concienciación en seguridad de los usuarios y consigue, en muchos casos, su objetivo.

Juegan también mucho con los sentimientos. El hecho de engañar a las personas con mensajes y añadir fotos en los cuales se hablan o se hace referencia a desgracias (temas relacionados enfermedades, desastres naturales, pobreza, delincuencia, agresiones, pagos, etc..).
A continuación, se muestran algunos de los casos posiblemente más habituales en las redes.

Usos maliciosos y abusos más habituales en las RRSS
  • Enlaces maliciosos compartidos
    Si tuviéramos que seleccionar alguno de los ejemplos más peligrosos haciendo referencia a todo lo hablado anteriormente mencionaríamos los enlaces maliciosos. Por ejemplo, los típicos mensajes que nos incitan a hacer clic para acceder a determinado contenido nos indican que nuestro número de teléfono ha sido seleccionado, o que hemos sido ganadores de un concurso, entre otros. Al final, todos pretenden que ejecutemos código malicioso con el que el atacante consigue un beneficio. De esta forma, pueden capturar información personal, acceder al contenido de los mensajes, enviar mensajes a nuestros contactos, modificar la configuración de seguridad, eliminar ficheros, robar documentos, o inutilizar el dispositivo.
  • Bulos o hoax
    Igualmente, existen los bulos o hoax, es decir, las noticias falsas que hemos recibido prácticamente todos. Así, por ejemplo, muchas veces nos llegan cadenas o enlaces de tipo: haz esta acción o te quedarás sin WhatsApp, reenvía este mensaje a diez personas porque WhatsApp si no tendrá un coste mensual, mira el nuevo radar que ha sacado la Dirección General de Tráfico, etc.
Algunos ejemplos:
Esta, por ejemplo, es una petición típica de solicitud de amistad que suele recibirse con frecuencia:

Si nos fijamos en el enlace como podemos ver esta acortado: https://goo.gl/5NkNsA
Si accedemos a la web URL x-ray (ulrxray.com) veremos realmente donde apunta ese enlace:

Como podemos ver apunta realmente a:

http://yjelm.instagirlsonline.com/

Esta página está clasificada como un redirector de navegador. YJELM.INSTAGIRLSONLINE.COM modifica la configuración de un navegador web y/o muestra anuncios emergentes no deseados. Este código puede reemplazar la página de inicio existente, la página de error o la página de búsqueda del navegador con el dominio YJELM.INSTAGIRLSONLINE.COM.

Se puede obtener más información en estas dos webs acerca de la página y sus posteriores consecuencias una vez se ha accedido:
https://greatis.com/blog/howto/remove-yjelm-instagirlsonline-com.htm
https://malwaretips.com/blogs/remove-yjelm-instagirlsonline-com/

Otro ejemplo, sería el típico mensaje cuando al visitar una página se nos abre el molesto pop-up:
Haz clic aquí – (Son ganchos para que pinches)



Otro mensaje que llama a muchos la atención es este:

Comentar que es totalmente falso. Este tipo de radares no se usan en España (el de la imagen es de Suiza)
También nos encontramos con las típicas cadenas falsas como esta, que pretenden que lo reenvíes salvo pena de sufrir algún coste económico:



Otro mensaje como el siguiente indicar que son fraudes:



Otro enlace que nos llega mucho por WhatsApp, Facebook, Instagram. con contenido malicioso

Las personas que están detrás de todo esto están controlando de alguna manera a las personas que han compartido ese mensaje y posteriormente focalizan sus ataques sobre ellas. Ya sea enviando publicidad, obteniendo datos de esa persona para otros fines o crear una alarma social.

También mencionar los típicos mensajes que llegan de números que no conoces indicando que se realice una llamada a un determinado número, o que hay una incidencia en tu línea, que has recibido un paquete y has de desplazarte a una dirección para recogerlo, etc. en los cuales te indican que si no lo haces tendrás problemas y tendrás que hacer frente a las consecuencias. En realidad, todo esto no son más que los famosos mensajes PREMIUM, que provocan que en cuanto se realice la llamada o se envíe un SMS, comiencen a cobrar al usuario una tarificación especial.


¿Como protegernos?
A continuación, se muestran algunas recomendaciones:
  • Aplicar el sentido común: si vemos un enlace el cual no es de una dirección fiable no lo abramos y si tenemos dudas, podemos utilizar un servicio web que nos muestre la URL completa del enlace acortado (como http://urlxray.com), y utilizar algunos servicios que verifican enlaces maliciosos, como:
    https://www.virustotal.com/#/home/url
    http://www.urlvoid.com/
    http://app.webinspector.com/
    https://vms.drweb.com/online/?lng=en
    https://www.psafe.com/dfndr-lab/
  • Para evitar gastos asociados a timos telefónicos, hablar con nuestra operadora de telefonía y solicitar que se bloqueen los servicios premium y llamadas 902.
  • No compartir cadenas o mensajes sin antes haber verificado que el remitente es de confianza, ya que en la mayoría de los casos son todo bulos.¡
  • Usar siempre fuentes seguras para descargar aplicaciones y detenernos a revisar los permisos que requiere cuando instalemos una aplicación.
  • No conectarnos a una Wifi pública, ya que una persona ajena podría interceptar las comunicaciones, por lo que podrían hacerse con nuestros datos, infectarnos o acceder en su defecto a nuestro equipo o dispositivo. En caso de que necesitemos conectarnos, utilizar siempre una VPN, la cual nos ofrece una conexión virtual de punto a punto (es como una especie de túnel).
  • Configurar siempre el doble factor de autenticación (verificación en dos pasos) en las aplicaciones que utilicemos.
  • Disponer de antivirus actualizado en todos los dispositivos que utilicemos.
  • Mantener el dispositivo o equipo actualizado.

¿Cómo saber si tenemos infectado nuestro dispositivo móvil?
A continuación, se describen algunos métodos que podrían permitir detectar si nuestro terminal ha sido infectado:
  • Instalar un antivirus para detectar las posibles amenazas y en su defecto eliminarlas.
  • Observar si el dispositivo funciona más lento de lo habitual
  • Observar si nuestra página de inicio del navegador ha sido modificada
  • Observar si al navegar notamos que nos redirigen a otras páginas que no son las que hemos solicitado o se muestran pop-up (típicas ventanas con publicidad).
  • Observar si notamos picos en el consumo de datos.
  • Observar si notamos un exceso en el uso de la batería.
  • Observar si nuestra factura telefónica tiene un coste superior al habitual.



Autor: Héctor Berrocal Vidal - CEH, MCP, CCNA, ITIL
Dpto. Auditoría

Vicente Aguilera entrevistado en el programa de radio En casa de Herrero

El pasado viernes 28 de septiembre Vicente fue entrevistado por Luis Herrero en su programa de radio En casa de Herrero.

El motivo de la entrevista fue el último incidente de seguridad sufrido por Facebook, donde se habrían puesto en riesgo 50 millones de cuentas de usuario.

La vulnerabilidad afectaba a la funcionalidad (“ver como”) que fue deshabilitada, y se revocaron los tokens de acceso de 90 millones de usuarios, lo que implicaba una re-autenticación por parte de los usuarios en la aplicación de esta red social. El problema no sólo afectaba a Facebook, sino también a todas aquellas aplicaciones en las que los usuarios usaban Facebook para autenticarse (por ejemplo: Tinder, Spotify, o Airbnb entre otras muchas).

Gestión del Cambio Significativo PCI DSS v3.2

Para todo el que se haya visto involucrado o haya tenido que trabajar con el estándar PCI DSS y, especialmente, aquellos que hayan tenido que “sufrir” su implantación y mantenimiento en cualquier de sus alcances, sabrán que dicho estándar deja bastantes ambigüedades y conceptos de los que no termina del todo de definir con exactitud. Esta posición es entendible si tenemos en mente la gran variedad de tipos de entornos, tecnologías y necesidades de negocio que nos podemos encontrar en la vida real que traten datos de tarjetas de pago.

Para mitigar este hecho, el SSC viene publicando con cada versión del estándar, un documento (aquí su enlace en su última versión) a modo de glosario, en el cual recopila diversos conceptos, términos, abreviaciones y acrónimos. Uno de estos términos, y sobre el que trata este artículo, es el Cambio Significativo, con la particularidad de que este concepto no viene recogido ni detallado en el glosario anteriormente mencionado.

Si recopilamos y extraemos del propio estándar todas las menciones que se hacen a cambio significativo, nos encontramos con:
  • En el requisito 11.2.3, se hace referencia a este término como “la determinación de qué constituye un cambio significativo depende totalmente de la configuración de cada entorno.”
  • En el requisito 12.2, sin embargo, pone el ejemplo de “adquisiciones, fusiones o reubicaciones, etc.” relacionado con los componentes del entorno.
  • Por último, en el requisito 11.2 se expone el ejemplo de “la instalación de nuevos componentes del sistema, cambios en la topología de la red, modificaciones en las reglas de firewall, actualizaciones de productos”.
Como se puede observar, es imposible extraer una definición clara y concisa de este término. En cambio, si se puede extraer claramente las implicaciones que conlleva considerar un cambio como “cambio significativo”, y dichas implicaciones suponen en la mayoría de los casos un gran esfuerzo económico y dedicación de personal. Las implicaciones y los requisitos que comúnmente se llegan a aplicar se resumen en:
  • Documentar dicho cambio, aplicar todos los requisitos del estándar y actualizar los documentos correspondientes (Req. 6.4.6)
  • Análisis de vulnerabilidades externo e interno (Req. 11.2)
  • Test de intrusión interno y externo (Req. 11.3)
  • Análisis de Riesgos (Req. 12.2)
Partiendo de esta base y si se analiza desde un enfoque práctico, ejemplos de dichos cambios significativos pueden ser:
  • Cambios de reglas de firewall/router en accesos públicos
  • Cambios sobre los controles de segmentación
  • Cambios de infraestructura, nuevos equipos, nuevo software o protocolos
  • Cambios sobre la aplicación de pago o servicios
  • Nuevos proveedores de servicios o cambio en el servicio de proveedores (intercambio de datos)
Las reglas de firewall son uno de los puntos más críticos, y debe tenerse en cuenta si se están abriendo nuevas interfaces externas o se están poniendo zonas adicionales, o el cambio de reglas implica un cambio de varias reglas de manera simultánea que puedan afectar de algún modo la segmentación. En estos casos es muy probable que se considere como un cambio significativo. Por otro lado, si el cambio es porque a un servidor se le cambió la dirección IP o porque se cambió el puerto por el que se maneja un servicio, en esos casos debe ser estudiando con detalle, para evaluar el riesgo y comprobar si efectivamente estamos ante un cambio significativo o no.

Sobre las nuevas versiones que sean desplegadas de las aplicaciones de pago, típicamente se consideran como cambio significativo, pero su actuación sería parcial, es decir, el análisis de riesgos se debería ejecutar solo en caso de que se activen nuevos servicios, pero el análisis de vulnerabilidades si debería ejecutarse en este caso. Nunca hay que olvidar que todo cambio independiente de si es más o menos crítico debe documentarse, tal y como se especifica en el requisito 6.4.6.

Para finalizar, es necesario enfatizar que la organización tiene la responsabilidad de tratar, a través de los criterios definidos en el documento relativos al procedimiento interno de gestión de cambios, el hecho de clasificar el cambio como significativo o no. Por otro lado, esta acción será objeto de revisión durante una auditoría, en la que un QSA comprobará a través de las evidencias correspondientes, que se han aplicado los criterios correctos acorde al estándar.

Autor: Alberto Villar - CISSP, PCI QSA
Dpto. de Auditoría

PCI DSS VS. GDPR

El 25 de mayo de 2018 entró en aplicación el Reglamento General de Protección de Datos Europeo (o General Data Protection Regulation, de aquí en adelante GDPR),  que remplazó a la Directiva de Protección de Datos 95/46/EC, y que fue diseñado con el objetivo de alinear todas las leyes de protección de datos en países europeos, proteger y darle control de sus datos privados a los ciudadanos europeos y establecer un marco de trabajo homogéneo en términos de privacidad para que las organizaciones e individuos puedan ejercer sus derechos y conozcan sus responsabilidades.

A pesar de que ya existían estándares orientados a la protección de la información de identificación personal (Personally Identifiable Information – PII) como el estándar ISO/IEC 29100:2011 y recomendaciones internacionales en materia de protección de datos provenientes de la OCDE (Organización para la Cooperación y el Desarrollo Económicos), del Foro de Cooperación Económica Asia Pacífico (APEC), de Federal CIO Council, de la Red de Autoridades Francófonas, de la Red Iberoamericana de Protección de Datos y de la Global Privacy Enforcement Network (GPEN), ninguno de ellos había tenido el impacto que ha tenido este reglamento, sobre todo motivado por los altos costes de las multas por incumplimiento (4% de la facturación anual o hasta 20 millones de Euros) y en la obligatoriedad de su implementación por parte de los estados miembro (GDPR es un reglamento, no una directiva, no requiere que los gobiernos nacionales aprueben ninguna legislación habilitante y es directamente vinculante y aplicable).

En términos de aplicabilidad de este reglamento, el elemento clave que lo define es el concepto de datos personales. Según la Comisión Europea, los datos personales son "toda información sobre una persona física identificada o identificable ("el interesado")". Por otro lado, complementa: "se considerará persona física identificable toda persona cuya identidad pueda determinarse, directa o indirectamente, en particular mediante un identificador, como por ejemplo un nombre, un número de identificación, datos de localización, un identificador en línea o uno o varios elementos propios de la identidad física, fisiológica, genética, psíquica, económica, cultural o social de dicha persona". Algunos ejemplos de datos personales son:
  • Nombre y apellidos,
  • Domicilio,
  • Dirección de correo electrónico, del tipo nombre.apellido@empresa.com,
  • Número de documento nacional de identidad,
  • Datos de localización (como la función de los datos de localización de un teléfono móvil),
  • Dirección de protocolo de internet (IP),
  • El identificador de una cookie,
  • El identificador de la publicidad del teléfono,
  • Los datos en poder de un hospital o médico, que podrían ser un símbolo que identificara de forma única a una persona.
  • Datos de tarjetas de pago (PAN y nombre del titular).
Precisamente, es en este último punto en el cual GDPR converge con el estándar PCI DSS: La protección de los datos de tarjetas de pago vinculadas con ciudadanos europeos. No obstante, son documentos diferentes pero que pueden ser empleados indistintamente como complemento para lograr el cumplimiento de uno o del otro y no son excluyentes. De hecho, Jeremy King, Director Internacional del PCI SSC para Europa, comentó en una entrevista:

"La gente acude a mí y me dice: '¿Cómo logro el cumplimiento de GDPR?' ... Comience con PCI DSS".

A continuación, se presenta una tabla comparativa entre GDPR y PCI DSS, que le permitirá al lector establecer las pautas básicas para el establecimiento de programas de alineación entre estos dos marcos normativos.

RGPD/GDPR PCI DSS
Tipo Legal/Gubernamental (regulación europea). Industrial (marcas de tarjetas que conforman el PCI SSC: VISA, MasterCard, AMEX, Discover y JCB).
Organismo global encargado del marco normativo Comité Europeo de Protección de Datos (artículo 68). Payment Card Industry Security Standards Council (PCI SSC).
Fecha efectiva de cumplimiento 25 de mayo de 2018 (artículo 99). La primera versión de PCI DSS se publicó el 14 de diciembre de 2004. Se realizan actualizaciones de versiones de forma periódica.
Cuerpo normativo remplazado El RGPD / GDPR remplaza y deroga a la Directiva 95/46/EC del Parlamento Europeo (artículo 94). PCI DSS remplaza (pero no deroga) los estándares de seguridad de cada una de las marcas de pago:
  • American Express – Data Security Operating Policy (DSOP)
  • Discover – Discover Information Security Compliance (DISC)
  • JCB International – Data Security Program (DSP)
  • MasterCard – Site Data Protection (SDP)
  • Visa USA – Cardholder Information Security Program (CISP)
  • Visa International – Account Information Security Program (AIS)
Datos dentro del alcance de cumplimiento Aplica al tratamiento total o parcialmente automatizado de datos personales (información personal de identificación / "Personally Identifiable Information" - PII) relacionados con personas en la Unión Europea (artículo 2). El número de cuenta principal (Primary Account Number - PAN) es el factor que define la aplicabilidad de PCI DSS. Si el nombre del titular de tarjeta, el código de servicio y/o la fecha de vencimiento se almacenan, procesan o transmiten con el PAN o se encuentran presentes de algún otro modo en el entorno de datos del titular de la tarjeta, se deben proteger de conformidad con los requisitos aplicables de PCI DSS.
Operaciones afectadas Aplica a cualquier operación o conjunto de operaciones realizadas sobre datos personales o conjuntos de datos personales, ya sea por procedimientos automatizados o no, como la recogida, registro, organización, estructuración, conservación, adaptación o modificación, extracción, consulta, utilización, comunicación por transmisión, difusión o cualquier otra forma de habilitación de acceso, cotejo o interconexión, limitación, supresión o destrucción; (artículo 4). Aplica a cualquier operación de almacenamiento, procesamiento o transmisión de datos del titular de la tarjeta (CHD) y/o datos confidenciales de autenticación (SAD).
Derechos del interesado Los ciudadanos europeos tienen derecho a lo siguiente (artículo 13):
  • Obtener información sobre el tratamiento de sus datos personales,
  • Obtener acceso a los datos personales que le conciernen,
  • Pedir que los datos personales incorrectos, inexactos o incompletos sean corregidos,
  • Solicitar que los datos personales sean borrados cuando ya no sean necesarios o si el tratamiento es ilícito,
  • Oponerse al tratamiento de sus datos personales con fines de mercadotecnia o por motivos relacionados con su situación particular,
  • Solicitar la limitación del tratamiento de sus datos personales en determinados casos,
  • Recibir sus datos personales en un formato de lectura mecánica y enviarlos a otro responsable del tratamiento («portabilidad de datos»),
  • Solicitar que las decisiones basadas en un tratamiento automatizado que le incumban o le afecten significativamente y basadas en sus datos personales sean tomadas por personas físicas y no solamente por ordenadores; asimismo, tiene derecho, en este caso, a expresar su punto de vista y a impugnar dicha decisión.
No se contemplan derechos específicos de los interesados sobre los datos de tarjetas de pago obtenidos en función del negocio.
Solicitud de consentimiento Una solicitud de consentimiento en el momento de la captura de los datos personales debe presentarse de forma clara y concisa, empleando un lenguaje fácil de entender, y diferenciarse claramente de otras informaciones, como las condiciones de uso. La solicitud debe especificar qué uso se hará de sus datos personales e incluir los datos de contacto de la empresa que trata los datos. El consentimiento debe darse libremente y ser una manifestación específica, informada e inequívoca (artículo 7). No se requiere de una solicitud de consentimiento explícita en el momento de captura de los datos de tarjetas de pago.
Entidades que lo deben cumplir Se definen dos grupos de entidades que deben cumplir con este reglamento, siempre que traten con información personal de identificación de ciudadanos en la Unión Europea, no importa su ubicación (capítulo IV):
  • Responsable del tratamiento ("data controller"): Entidades o individuos que necesitan procesar datos personales para su negocio. Ellos determinan los propósitos y la manera en que se procesan los datos personales.
  • Encargado del tratamiento ("data processor"): Persona física o jurídica, autoridad pública, servicio u otro organismo que trate datos personales por cuenta del responsable del tratamiento.
En función de la cantidad anual de transacciones con tarjetas realizadas y del tipo de entidad (comercio o proveedor de servicio), se requiere:
  • La ejecución de una auditoría anual en sitio realizada por auditores certificados (QSA), o
  • Rellenar un cuestionario de autoevaluación anual (SAQ).
Controles de seguridad a implementar La aplicabilidad de medidas técnicas y organizativas para demostrar la conformidad del tratamiento con el Reglamento son discrecionales (no se describen de forma explícita) y deben ser elegidas por el Responsable o el Encargado del tratamiento (artículos 25 y 32) mediante el concepto de protección de los datos desde el diseño y por defecto. Las medidas técnicas, físicas y administrativas a implementar se describen a lo largo de los 12 requisitos del estándar. Se trata de controles de seguridad a bajo nivel definidos explícitamente. También se incluyen controles alternativos o compensatorios, en caso de que la implementación del control descrito en el estándar no pueda ser cubierta debido a una justificación técnica o de negocio.
Técnicas para la protección de los datos afectados
  • Seudonimización.
  • Encriptación.
    (artículo 32)
  • Valores hash de una vía basados en criptografía sólida.
  • Truncamiento.
  • Tokens y ensambladores de índices.
  • Criptografía sólida con procesos y procedimientos asociados para la administración de claves.
    (requisito 3.4)
Persona encargada de la supervisión del cumplimiento en la organización Se debe designar un delegado de protección de datos (artículo 37) siempre que:
  • el tratamiento lo lleve a cabo una autoridad u organismo público, excepto los tribunales que actúen en ejercicio de su función judicial;
  • las actividades principales del responsable o del encargado consistan en operaciones de tratamiento que, en razón de su naturaleza, alcance y/o fines, requieran una observación habitual y sistemática de interesados a gran escala, o
  • las actividades principales del responsable o del encargado consistan en el tratamiento a gran escala de categorías especiales de datos personales con arreglo al artículo 9 y de datos relativos a condenas e infracciones penales a que se refiere el artículo 10.
Se requiere definir un rol de responsable de cumplimiento de PCI DSS si la entidad afectada es un proveedor de servicio (req. 12.4.1) o una entidad designada (según el anexo A3 – A3.1.1). Para los demás comercios es solo una recomendación.
Entidad encargada de supervisar la aplicación del marco normativo Cada Estado miembro delega la responsabilidad de supervisar la aplicación del marco normativo en una "autoridad de control" ("supervisory authority") o "autoridad nacional de protección de datos" (APD), con el fin de proteger los derechos y las libertades fundamentales de las personas físicas en lo que respecta al tratamiento y de facilitar la libre circulación de datos personales en la Unión (artículo 51). Las marcas de tarjetas de pago gestionan de forma independiente el cumplimiento de los comercios y proveedores de servicio. Pueden delegar la centralización de reportes de cumplimiento en bancos adquirientes.
Realización de evaluaciones de impacto / análisis de riesgos Cuando sea probable que un tipo de tratamiento, en particular si utiliza nuevas tecnologías, por su naturaleza, alcance, contexto o fines, entrañe un alto riesgo para los derechos y libertades de las personas físicas, el responsable del tratamiento realizará, antes del tratamiento, una evaluación del impacto de las operaciones de tratamiento en la protección de datos personales (artículo 35). Para identificar los potenciales riesgos que puedan afectar a los activos del entorno de cumplimiento, PCI DSS requiere la realización anual de un análisis formal de riesgos basado en una metodología aceptada por la industria (req. 12.2).
Umbrales de almacenamiento de los datos protegidos Los datos personales deben ser mantenidos de forma que se permita la identificación de los interesados durante no más tiempo del necesario para los fines del tratamiento de los datos personales ("limitación del plazo de conservación" - artículo 5). No se deben almacenar los datos confidenciales de autenticación después de la autorización, incluso si están cifrados (req. 3.1).
Reporte de brechas de seguridad (incidentes) En caso de violación de la seguridad de los datos personales, el responsable del tratamiento la notificará a la autoridad de control competente de conformidad con el artículo 55 sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella, a menos que sea improbable que dicha violación de la seguridad constituya un riesgo para los derechos y las libertades de las personas físicas. Si la notificación a la autoridad de control no tiene lugar en el plazo de 72 horas, deberá ir acompañada de indicación de los motivos de la dilación (artículo 33). El requisito 12.10 requiere la definición de un plan de respuesta a incidentes, su revisión y prueba anual, designación de personal y formación al mismo y un plan de mejora contínua. El reporte de incidentes se debe dirigir directamente a las marcas, de acuerdo con los procedimientos y tiempos estipulados por cada una de estas entidades.

Igualmente, incluye la necesidad de realizar un análisis de requisitos legales necesarios para el informe de riesgos, dentro de los cuales se contempla GDPR.
Comunicación de una brecha de seguridad al interesado Cuando sea probable que la violación de la seguridad de los datos personales entrañe un alto riesgo para los derechos y libertades de las personas físicas, el responsable del tratamiento la comunicará al interesado sin dilación indebida (artículo 34). No se requiere de forma explícita una notificación al interesado, pero esta acción puede formar parte de las actividades de prevención, contención y recuperación del incidente a ser establecidas por las marcas posterior a una investigación.
Responsable de la investigación de incidentes Las tareas de investigación de incidentes relacionados con datos personales recaen en la autoridad de control. Dependiendo de la magnitud del incidente, las marcas pueden exigirle a la entidad afectada la contratación de los servicios de un PCI Forensic Investigator (PFI). Los PFI son empresas homologadas y listadas en el sitio web del PCI SSC encargadas de la investigación, generación de reportes y soporte a la entidad afectada en caso de un incidente.
Sanciones por incumplimiento Se sancionará con multas administrativas de 20.000.000 EUR como máximo o, tratándose de una empresa, de una cuantía equivalente al 4 % como máximo del volumen de negocio total anual global del ejercicio financiero anterior, optándose por la de mayor cuantía (artículo 83). Las multas por incumplimiento son establecidas de forma unilateral por las marcas de pago en función del incidente. No existen tablas públicas con estos datos.

Ya sea que se necesite implementar GDPR en un entorno alineado con PCI DSS o viceversa, el primer paso consistirá en la ejecución de un análisis diferencial de cumplimiento ("gap analysis") para detectar incumplimientos y definir acciones correctivas.

Conclusión
Por definición, el dato del PAN (Primary Account Number – Número Primario de Cuenta) y los demás datos vinculados con tarjetas de pago (nombre del titular, datos completos de la banda magnética, etc.) son considerados como información personal de identificación ("Personally Identifiable Information" - PII), ya que que pueden usarse para identificar, contactar o localizar a una persona en concreto, o pueden usarse, junto a otras fuentes de información, para hacerlo.

Por esta razón, aparte de los controles de seguridad exigidos por las marcas de pago para su protección (como es el caso de PCI DSS), también requieren cumplir con las normativas legales de protección de datos exigidas en cada región (como es el caso de GDPR). En este caso, hay que tener presente que PCI DSS no sustituye las leyes locales ni regionales, las regulaciones gubernamentales ni otros requisitos legales.


Autor: David Eduardo Acosta CISSP|I, CISM, CISA, CRISC, C|EH, C|HFI Instructor, OPST, PCI SSC QSA for DSS/P2PE/3DS/TSP Dpto. Consultoría

Firmamos acuerdo con el Capítulo de ISACA Bogotá

Internet Security Auditors y el Capítulo de ISACA en Bogotá han firmado un acuerdo para la colaboración en la promoción de los cursos oficiales y diferentes capacitaciones ofrecidas por ambas organizaciones, rubricado por el Presidente de ISACA Bogotá, Víctor A. Vásquez y el Director Global de Ventas y Alianzas de Internet Security Auditors, Daniel Fernández.

Este Acuerdo incluye el acceso a las capacitaciones de la compañía para los miembros del Capítulo con descuentos para sus asociados y también facilitará el acceso a los clientes de Internet Security Auditors a los cursos de la Asociación en Bogotá.

ISACA, fundada el año 1969, es una de las organizaciones con más reconocimiento a nivel mundial, con más de 140.000 en 180 países y con certificaciones que año tras año se sitúan en el top 5 del reconocimiento mundial en la ciberseguridad.

Con este acuerdo, Internet Security Auditors refuerza su compromiso con la difusión de la formación oficial en alianza con una de las asociaciones de profesionales de la Ciberseguridad y Auditoría con más penetración en el país, demostrando la capacidad y voluntad de facilitar el acceso a las certificaciones y cursos del máximo nivel que ofrece la compañía para los miembros de ISACA.