Requisitos de seguridad en PSD2

Cuando hablamos de PSD2 (Directiva (UE) 2015/2366) todos pensamos en el requerimiento de los bancos de disponer de APIs para que las fintech puedan acceder a los datos de sus clientes sin necesidad de realizar técnicas de screen scraping (técnica que queda expresamente prohibida), pero la Directiva va más allá.

En esta entrada nos vamos a centrar en los artículos que incluyen exigencias de seguridad para los proveedores de servicios de pago (PSP), que, aunque son pocos artículos, hacen referencias a reglamentos delegados y directrices marcadas por la Autoridad Bancaria Europea (EBA, por sus siglas en inglés).

La Protección de datos de carácter personal
El artículo 94, Protección de datos, si bien es bastante escueto, indica la necesidad de cumplir con las directivas de protección de datos y las normas naciones de transposición; al ser PSD2 una Directiva de 2015, no hace referencias al RGPD (Reglamento 2016/679), cosa que sí se incluye esta referencia en el anteproyecto de ley que se ha publicado en España para trasponer la Directiva 2015/2366. En resumen, se permitirá el tratamiento de datos personales para la prevención y descubrimiento del fraude, siempre de forma adecuada a lo estipulado en la legislación de cada país.

Riesgos: Operativos y de seguridad
Es en el artículo 95, Gestión de los riesgos operativos y de seguridad, donde se indica que la EBA debe publicar unas guías con medidas de seguridad que deberán adoptar los proveedores de servicios de pago. Estas directrices fueron publicadas en diciembre de 2017 y se estructuran en 9 apartados que vemos a continuación:
  1. Principio general
    Este apartado sirve como introducción e indica que los puntos sucesivos deben servir como guía, ya que el nivel de detalle dependerá en función de la naturaleza, alcance, complejidad y riesgo de los servicios que preste el PSP (Proveedor de Servicios de Pago).
  2. Gobierno
    En este apartado se indica la necesidad de que exista, dentro de la Organización, un framework de seguridad, aprobado y revisado por la Dirección al menos una vez al año (muy en la línea de que indica la ISO 27001).

    También (y nuevamente, alineado con los estándares ISO), indica que la gestión de la seguridad debe basarse en un modelo de gestión de riesgos. Esta gestión de riesgos estará documentada y deberá estar aprobada por la Dirección (además de ser consistente con el apetito por el riesgo de la Organización). Este análisis de riesgos debe ejecutarse de forma periódica y cada vez que haya un cambio significativo que afecte a los servicios de pago.

    También se menciona la necesidad de establecer 3 líneas de defensa o un sistema de gestión de riesgos y control equivalente. Generalmente, cuando hablamos de 3 líneas de defensa, incluimos por un lado la existencia de controles operativos; el segundo nivel es el de supervisión, que revisa los resultados de dichos controles y el tercer nivel es el de una auditoría (generalmente auditoría interna), que verifica todo el proceso de supervisión y que los controles sean acordes y adecuados a las necesidades.



    Las auditorías son exigidas en este mismo apartado, y deben ser llevadas a cabo por personal independiente al PSP; la frecuencia y alcance de la auditoría dependerá de los riesgos de seguridad tenidos en consideración.

    También se hacen referencias en este grupo de controles al control de proveedores, indicando que el PSP debe establecer controles cuando haya funciones operacionales externalizadas y que se deben definir objetivos de seguridad y de rendimiento a través de acuerdos de nivel de servicio (SLAs).
  3. Evaluación del riesgo
    Ya se ha hecho mención al marco de gestión de riesgos, pero este apartado profundiza. Se menciona la necesidad de identificar y establecer (y mantener actualizado) un inventario de activos, que incluya las principales funciones de negocio, roles clave y procesos de soporte y que sirva para clarificar la importancia e interrelación de cada uno de ellos en relación con los riesgos de seguridad y operacionales.

    En esta misma línea, y como indican la mayoría de los estándares de seguridad (estándares ISO o PCI DSS), se indica la necesidad de identificar y disponer de un inventario de activos actualizado regularmente.

    Como es habitual en los análisis de riesgos, tanto los activos como los procesos identificados tendrán que ser clasificados en términos de criticidad. No se hace ninguna referencia a esta clasificación, pudiéndose hacer de forma cuantitativa o cualitativa, a deseo del PSP.

    En este apartado se indica la necesidad de monitorizar de forma continua las amenazas y vulnerabilidades, así como revisar de forma periódica los escenarios de riesgo que tienen impacto sobre los procesos de negocio. En base a esto, las directrices exigen que se realice un análisis de riesgos con una periodicidad anual o cada vez que se realice un cambio significativo (nuevamente, en línea con los principales estándares de seguridad como PCI DSS o ISO 27001).

    Siguiendo las metodologías de análisis de riesgos habituales, el siguiente punto de estas directrices indica la necesidad de tratar los riesgos derivados de la evaluación anterior.
  4. Protección
    Este es sin duda uno de los apartados más ambiguos de estas directrices, dejando libertad al PSP de implantar las medidas que más se adecúen a él; según indica, el PSP deberá establecer e implantar medidas de seguridad preventiva que dependerán de los resultados del análisis de riesgos realizado (y, por tanto, será también labor del auditor externo comprobar y analizar si estas medidas son adecuadas a los riesgos inherentes de la Organización). Medidas de seguridad basadas en los riesgos, tal y como se indica en estándares como ISO 27001 o las legislaciones actuales (RGPD).

    Además, el PSP debe establecer una ‘defensa en profundidad’, es decir, debe establecer controles de seguridad que cubran los diferentes activos (personas, procesos y tecnología) involucrados en el servicio de pagos.


    Se hace también una aclaración en relación al concepto "defensa en profundidad", indicando que se requiere de al menos dos controles para cada riesgo y pone como ejemplos que haya dos factores de autenticación o que se implante, además de segmentación de redes, firewalls entre dichos segmentos.

    Estos controles deben estar enfocados a proteger la confidencialidad, integridad y disponibilidad de los activos críticos (sean lógicos o físicos), recursos e información y que se debe velar por estos principios en cualquier estado en el que la información se encuentre (en uso, en tránsito o durante su almacenamiento). Nuevamente se menciona en este punto la necesidad de cumplir con la legislación vigente y hace especial mención al RGPD.

    Cuando se realice un cambio en la infraestructura, el PSP deberá evaluar si ese cambio requiere de cambios en los controles existentes o si son necesarios nuevos controles de seguridad.

    El siguiente punto es básico en materia de seguridad y requiere que haya segregación de funciones y la utilización de principios de "least privilege". También en este punto se indica que se deben segregar los entornos IT para el desarrollo, pruebas y producción.

    Los datos que se obtengan deben limitarse a los requeridos para el servicio o negocio (deben ser relevantes y adecuados) y que deben considerarse su necesidad en la obtención, procesamiento, almacenamiento y visualización (vemos aquí una referencia directa a PCI, por ejemplo). Nuevamente, este control va muy alineado con los nuevos reglamentos europeos como el RGPD.

    Se deben tener controles para asegurar que los parches de seguridad se aplican al software.

    El siguiente control, si bien bastante simple a priori, es probablemente de los más complejos. Según indica, el PSP debe disponer de medidas de seguridad físicas adecuadas, en especial para proteger la información sensible de pago. Es lo único que dice, pero no indica qué son ‘medidas de seguridad físicas adecuadas’; obviamente, esto dependerá del análisis de riesgos y la información que se esté procesando y/o almacenando, pero no da ninguna indicación de las medidas de seguridad, por lo que estarán supeditadas al criterio del auditor (ya que en principio el auditor deberá comprobar los controles de seguridad).

    El siguiente control indica que se debe autorizar los accesos únicamente a personal autorizado y que estarán en concordancia con sus responsabilidades (ya habíamos mencionado anteriormente la necesidad de existencia del least privilege), que estarán alineadas con las necesidades de negocio.

    Mención especial a los controles de accesos de administradores, para los que indica que es necesario establecer “controles fuertes”. Para el caso concreto de la administración remota, indica específicamente la necesidad de utilizar autenticación fuerte. También indica en este punto que estos accesos deben ser supervisados (logs), revisados periódicamente y estar estrictamente limitados basados en la necesidad del saber. Algunos puntos más adelante, sí que indica claramente que el acceso remoto de administradores requerirá que se utilice autenticación fuerte.

    Los logs de acceso deberán ser almacenados durante un periodo de tiempo alineado con las funciones de negocio y criticidad de los activos (obviamente, siempre alineado también con los requerimientos legales).

    Hay un último punto en este apartado que indica que, si se utilizan herramientas, productos o algún tipo de software para gestionar en control de accesos, deben existir controles que prevengan que se puedan comprometer o circunvalar la protección dada por estas herramientas.
  5. Detección
    En este listado de controles se habla de la monitorización continua y la detección de amenazas. Para ello, el PSP deberán implementar procesos y dotar de recursos que permitan monitorizar las funciones de negocio, procesos de soporte y activos de la información de forma continua para detectar actividades anómalas, ya sea a nivel físico o lógico.
    Estos procesos deberán cubrir:
    • Factores internos y externos relevantes.
    • Transacciones, de cara a detectar usos inadecuados de acceso por proveedores de servicio u otras entidades.
    • Potenciales amenazas internas o externas.

    También deberán incluirse controles que permitan identificar fugas de información, código malicioso y otras amenazas para la seguridad, así como controles para estar al día de las vulnerabilidades del software y hardware que se utiliza en los servicios de pago.

    Además, deberán establecerse criterios y umbrales para clasificar los eventos de seguridad (de forma que se pueda saber si se trata de un "evento" o un "incidente", así como la criticidad del mismo).

    Y obviamente, el PSP deberá disponer de disponer de medidas y recursos que se encarguen de cumplir estos procesos y controles y reportarlos a la alta dirección en caso de ser necesario.
  6. Continuidad de negocio
    Se deberá implantar mecanismos que se encarguen de gestionar la continuidad del servicio de pago en caso de disrupción. Obviamente, la continuidad de negocio tendrá que ir en línea con la exposición a amenazas que tenga el PSP y el impacto potencial sobre las funciones críticas de negocio (que podrá ser un análisis cuantitativo o cualitativo). Es decir, se debe hacer una Business Impact Analysis (BIA) de cara a definir los procesos críticos de negocio y en base a este BIA, el PSP deberá establecer planes de continuidad de negocio que permitan reaccionar en caso de emergencia y medidas mitigatorias, que eviten o disminuyan los efectos adversos de una interrupción en el servicio.

    Adicionalmente, será necesario identificar una serie de escenarios (y, según el reglamento delegado, se deben incluir escenarios ‘extremos pero plausibles’) a los que el PSP puede estar expuesto.

    Con estas premisas, se definirán planes de recuperación que deberán estar documentados y actualizados en base a las lecciones aprendidas, pruebas, y nuevos riesgos identificados.

    La existencia de planes de continuidad de negocio implica, por definición, la necesidad de probarlo (para garantizar que funciona, para que quienes lo tienen que ejecutar se sientan cómodos y conozcan el procedimiento, etc.) y estas directrices indican que se debe testear, al menos, con carácter anual. Los objetivos de las pruebas serán proteger, y, si es necesario, reestablecer la integridad y disponibilidad de las operaciones. Este plan de pruebas también deberá ser actualizado año a año, basado en los resultados previos y las nuevas amenazas.
    El plan de pruebas incluirá:
    • Un conjunto de escenarios adecuado.
    • Que sea un reto para el personal involucrado.
    • Procedimientos para verificar la habilidad para responder a dicho escenario.

    Además, el PSP deberá monitorizar la eficiencia del plan de continuidad de negocio, de forma documentada, así como analizar los cambios y los resultados de las pruebas.

    Un aspecto muy importante que también se incluye en estas directrices es el de asegurar una comunicación eficiente durante una crisis (en tiempo y forma); este plan de comunicación incluirá actores relevantes internos y/o externos, proveedores, etc.
  7. Probar las medidas de seguridad

    El PSP deberá contar con un plan de pruebas (testing framework) que permita validar los controles de seguridad implantados; lo suficientemente abierto para soportar nuevas vulnerabilidades y amenazas y deberá asegurarse que se realizan pruebas después de un cambio significativo en la infraestructura.

    Además, este framework deberá incluir en su alcance los terminales y dispositivos de pago, así como los dispositivos utilizados para la autenticación de los usuarios y cualquier dispositivo o software que se facilite a los usuarios. Este marco de pruebas debe incluir:
    • Que las pruebas se ejecutan como parte del proceso de gestión de cambios, para asegurar la robustez y eficiencia de los mismos.
    • Que las pruebas son llevadas a cabo por personal independiente (con conocimientos y habilidades).
    • Que deben considerar escaneos de vulnerabilidad y test de penetración adecuados al nivel de riesgo del servicio de pago.

    El PSP deberá realizar las pruebas al menos con carácter anual para los servicios de pago considerados como críticos, mientras que los servicios no críticos podrán ser probados cada 3 años, aunque esto se basará en una aproximación basada en el riesgo.

    El último control de este punto indica que se deben evaluar los resultados de las pruebas y establecer las medidas de protección que resulten de dicho análisis.
  8. Concienciación y aprendizaje continuo
    En este apartado se habla de la concienciación que se debe dar a las partes interesadas; para garantizar una concienciación adecuada, se indica que el PSP debe establecer, identificar y monitorizar las amenazas que puedan afectar al servicio de pago. Serán de ayuda los incidentes que hayan podido ocurrir dentro y fuera de la organización, que deberán ser incluidos como "lecciones clave" para actualizar sus medidas de seguridad.

    El PSP establecerá un programa de formación para su staff, de forma que estén preparados para realizar sus tareas, reduciendo errores humanos, robo, fraude o pérdida de información. Además, para las personas en puestos clave, se impartirá formación con carácter anual (o con una frecuencia mayor si es necesario).

    También, dentro del plan de concienciación, se buscará educar a los colaboradores, de forma que sepan actuar en casos de riesgo y sepan cómo reportar cualquier actividad inusual o incidente.
  9. Gestionar la relación con el usuario

    Además de concienciar a sus empleados, el PSP establecerá e implantará procesos para concienciar a sus usuarios de los riesgos derivados del servicio de pago, así como le facilitará asistencias y guías, que serán actualizadas en base a las nuevas amenazas y vulnerabilidades. El PSP mantendrá al usuario informado sobre actualizaciones de seguridad en relación al servicio de pago.

    Si el producto lo permite, el PSP facilitará al usuario la opción de deshabilitar funcionalidades específicas del servicio de pago (por ejemplo, si el servicio de pago ofrece límites, se facilitará al usuario modificar dichos límites).

    Además, deberán proveer al usuario de opciones para recibir alertas en caso de que se inicien o se den intentos fallidos de iniciación de pagos, de cara a detectar operaciones fraudulentas.

    Por último, el PSP facilitará a los usuarios asistencia en relación a las consultas que puedan surgir, así como en el caso de notificaciones de anomalías o problemas de seguridad; deberá indicar los pasos para obtener esta asistencia.
Resumiendo
Desde mi punto de vista, estos controles operativos son muy completos; abordan la seguridad de un modo similar a un sistema de gestión basado en ISO 27001, tomando la gestión de riesgos como base para implantar controles y establecen un sistema de pruebas de cara a incluir un ciclo de mejora continua. Toma en consideración también la necesidad de dar poder a los usuarios y los contempla dentro del ciclo de la seguridad, ya que da responsabilidades de soporte a usuarios a los propios proveedores de servicios de pago, e incluye la posibilidad de que reciban alertas, de forma que puedan notificar al PSP en caso de vulnerabilidad o problemas con sus servicios. Estos controles no incluyen ninguna novedad, si no que han recogido las "best practices" existentes y las han aplicado a los sistemas de pago, intentando de esta forma que los PSP doten de una seguridad robusta a sus sistemas.

Autor: Antonio Martínez Jiménez - CISSP Instructor, ISO 20000 L.A., ISO 27001 L.A., ISO 22301 L.A.
Dpto. Consultoría

Interés legítimo, el cajón de sastre del RGPD

Desde que entró en vigor el Reglamento General de Protección de Datos (en adelante RGPD), y más aún, desde su aplicabilidad de forma obligatoria el día 25/06/2018, son muchas las dudas, por parte de las empresas y organizaciones, acerca de utilizar como base jurídica para sus tratamientos el denominado “interés legítimo”. Aunque a primera vista puede parecer un tema nuevo, lo cierto es que no se trata de ninguna novedad del RGPD, sino que este concepto ya estaba presente en la anterior Directiva 95/46.

El Reglamento exige que el consentimiento sea inequívoco y se otorgue de forma positiva por parte del interesado, actualmente, en aquellos casos en los cuales no se cuenta con un consentimiento otorgado con tales características y en los que, en principio, no tiene cabida ninguna otra base jurídica se está pretendiendo utilizar el “interés legítimo” como base jurídica legitimadora alternativa. Esta gran indeterminación que suscita el “interés legítimo”, puede conllevar a utilizar esta base jurídica como un cajón de sastre, lo cual puede conllevar una serie de problemas asociados para las empresas y organizaciones que pueden materializarse en forma de denuncias por parte de los interesados y sanciones por parte de la autoridad de control correspondiente.

Este concepto difuso es introducido en el artículo 6.1.f del RGPD, en concreto, cita lo siguiente “el tratamiento es necesario para la satisfacción de intereses legítimos perseguidos por el responsable del tratamiento o por un tercero, siempre que sobre dichos intereses no prevalezcan los intereses o los derechos y libertades fundamentales del interesado que requieran la protección de datos personales, en particular cuando el interesado sea un niño.”; y no debe extenderse su aplicación, de tal forma que resulte la opción de referencia a la que acudir a la hora de legitimar un tratamiento de datos de carácter personal por parte de un responsable del tratamiento. Es preciso realizar un estudio de cada uno de los tratamientos de datos de carácter personal para concretar la base jurídica que mejor se ajuste a dicho tratamiento, y abordar el “interés legítimo” como un fundamento jurídico más, y no pecar por exceso de aplicación del mismo.

Este acto de estudio requiere una ponderación entre el interés del responsable del tratamiento o terceros y los derechos y libertades de los interesados. Esta situación deriva en una ponderación meticulosa, que no consiste solo en una evaluación directa entre ambos intereses, sino que, se deben tener en cuenta diversos factores para tomar la decisión final.

Antes de empezar con dicha evaluación, debe definirse el concepto de interés legítimo, en el ámbito de la protección de datos; es un concepto que abarca un recorrido y significado más amplio que la mera base legítima que permite al responsable del tratamiento llevar a cabo dicho tratamiento. Además, este interés tiene que ser real, concreto, lícito y actual, es decir, no tiene cabida un potencial interés teórico o especulativo, debe estar articulado de una forma clara y concisa, por lo que debe estar lo suficientemente delimitado y definido, para poder ponerlo en contraprestación a los intereses y los derechos fundamentales del interesado y ser realizado de acuerdo con la legislación aplicable en materia de protección de datos o cualquier otra legislación o normativa de aplicación, que no atente contra el orden público, ni sea contrario a los principio generales del Derecho.

No cobra sentido alguno la creación de una lista predefinida y cerrada de intereses legítimos, ya que estos pueden ser infinitos atendiendo al responsable del tratamiento, finalidad, ámbito de la empresa, sector, etc. Sin embargo, el RGPD marca, a modo de ejemplo, algunos supuestos concretos de interés legítimo en los Considerandos contenidos entre el 47 y el 50 ambos incluidos. Algunos de estos ejemplos son:
  • La mercadotecnia directa.
  • La prevención del fraude.
  • Garantizar la seguridad de la red y de la información, así como de los servicios proporcionados a través de esos sistemas o redes de información.
  • Compartir datos personales dentro de un mismo grupo empresarial o entre entidades afiliadas a un mismo organismo central con fines administrativos internos.
  • La indicación de posibles actos delictivos o amenazas para la seguridad pública, así como la transmisión a la autoridad competente de los datos relacionados con dichos actos delictivos o amenazas para la seguridad pública.
Además, la nueva LOPD-GDD recoge los siguientes supuestos:
  • El tratamiento de los datos de empresarios individuales cuando se refieran a ellos en dicha condición y no se traten para entablar una relación con los mismos como personas físicas.
  • El tratamiento de los datos de las personas físicas que presten servicios en una persona jurídica, siempre que se trate de los datos mínimos imprescindibles para su localización profesional y se utilicen para mantener la relación con la persona jurídica.

Por otro lado, el GT29, en su Dictamen 06/2014, de 9 de abril de 2014, sobre el concepto de interés legítimo del responsable del tratamiento de los datos en virtud del artículo 7 de la Directiva 95/46/CE, expone más supuestos considerados como posibles tratamientos que pueden tener como base jurídica la fórmula del “interés legítimo”.

Una vez definido este concepto tan abstracto y presentados algunos ejemplos de tratamientos que pueden tener como base jurídica legitimadora el interés legítimo, la primera consideración a tener en cuenta es responder a la siguiente pregunta "¿Puede el responsable del tratamiento satisfacer su interés legítimo por otros medios menos invasivos?"; para ello se deben realizar los correspondientes análisis de proporcionalidad de las medidas técnicas y organizativas que se pretenden implantar. Si la respuesta a dicha cuestión es en sentido negativo, puede ocurrir que el tratamiento que se desea llevar a cabo sea un tratamiento no legitimado, o bien, que se deba buscar otra base jurídica de las expuestas en el artículo 6 del RGPD para legitimar dicho tratamiento; por otra parte, si la respuesta es afirmativa, es el momento de realizar la ponderación entre los distintos factores definidos anteriormente.

Para llevar a cabo esta ponderación y dilucidar si realmente existe un interés legítimo que pueda ser consistente como base jurídica de un tratamiento, se debe tener en cuenta:
  • La expectativa de los interesados
  • El impacto para los interesados
  • La relación interesados-responsable
  • Otras cuestiones más específicas del tratamiento específico sobre el cual se lleva a cabo el estudio.
Una vez valorados los criterios anteriores se obtendrá una respuesta provisional, sin tener en cuenta la posibles medidas técnicas y organizativas que el responsable pueda implantar para llevar a cabo el tratamiento, por lo que, como última fase de este análisis, es necesario valorar los riesgos y consecuencias en función de dichas medidas técnicas y organizativas implantadas por el responsable. Algunas de estas medidas pueden ser:
  • La utilización de técnicas de anonimización de los datos de carácter personal.
  • Cifrado de datos, que eviten la identificación directa de los mismos.
  • Formación en materia de seguridad y protección de datos de forma periódica a los empleados.
  • Procedimiento de backup o rollback que permita recuperar la máxima cantidad de información en el menor tiempo posible ante un incidente.
  • Facilitar a los interesados información transparente y más amplia que la exigida en el RGPD sobre el tratamiento de datos.
  • Etc.
Una vez valorados los criterios anteriores, el responsable dispone de toda la información necesaria para determinar si prevalece su interés legítimo sobre los derechos y libertades de los interesado o no. Si de una forma clara es así, se puede concluir que el tratamiento de datos está legitimado en base a un interés legítimo por parte del responsable, siempre cumpliendo con el resto de las obligaciones expuestas en el RGPD; en caso contrario, el responsable puede tener en cuenta una serie de garantías adicionales para determinar de forma clara si existe interés legítimo o no. Esto requerirá una evaluación ulterior y la implantación de medidas tanto técnicas como organizativas adicionales.

Es recomendable y conviene documentar todo este proceso de determinación del interés legítimo como base jurídica de un tratamiento.

Por último, cabe recordar que con independencia de que se den las condiciones y requisitos necesarios para basar el tratamiento en un interés legítimo, hay que cumplir con el resto de obligación estipuladas en el Reglamento General de Protección de Datos.

Ante la decisión de utilizar el interés legítimo como base legitimadora sin realizar previamente el estudio anteriormente descrito, puedo conllevar que, ante una posible investigación por parte de la autoridad de control correspondiente, en caso de España esta autoridad de control es la Agencia Española de Protección de Datos, se haga muy difícil la defensa del uso de esta base, lo que puede abocar en una sanción económica considerada dada la estructura y clasificación de sanciones recogida en el reglamento. Es por ello, que siempre que se requiera basar un tratamiento en un interés legítimo, es importante realizar la ponderación descrita y dejar todo el proceso documentado justificando cada decisión.



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

Principio de Minimización de Datos

En la era actual, en la que prácticamente, a nivel mundial todos nos encontramos conectados a través de internet, redes sociales, smartphones, etc. Nuestros datos de carácter personal, nuestros gustos, nuestra información más íntima, se ha convertido en uno de los mayores negocios y que más dinero mueven en el mundo.

En la edad de oro del Big Data y del Knowledge Discovery, de los datawarehouses y del datamining, resulta bastante sencillo extraer una gran cantidad de información personal de la actividad que realizamos en Internet. La gran mayoría de las personas no son conscientes de la ingente cantidad de datos que hacen públicos o que directamente venden de una forma gratuita a terceras empresas, movidas por una sociedad cada vez más dependientes de las nuevas tecnologías y de su uso no responsable.

La tendencia de las empresas, hoy en día, es recoger la máxima cantidad de datos posibles, aunque no sean necesarios para el trabajo que desempeñan, pero la forma en la cual se mueve el mundo, a mayor cantidad de datos mayor rentabilidad se puede obtener de los mismos.

Es por esto que, con la llegada del nuevo Reglamento Europeo de Protección de Datos, una de las mayores novedades y más llamativas, es la obligación del responsable del tratamiento a minimizar los datos recogidos. A grandes rasgos, esta obligación intenta preservar y proteger los datos de carácter personal de las personas físicas, es decir, empleando la política del “need to know”, evitando que terceras personas se apropien de forma indebida de datos que no les son necesarios para la prestación del servicio que ofertan.

Aunque este término pueda considerarse relativamente nuevo, lo cierto es que ya existía en otros frameworks de seguridad como, por ejemplo, OECD Privacy, en el que se hace referencia al término “Collection Limitation Principle” el cual viene a decir que deben existir límites para la recopilación de datos personales y que cualquier información de este tipo debe obtenerse por medio legales y justos, y que cuando corresponda con el conocimiento o consentimiento del interesado.
El principio de minimización de datos recogido en los artículos 5 y 25 del nuevo Reglamento Europeo, se centra en lo siguiente:
  • Cantidad de dato recogidos.
  • Tiempo de retención de los datos.
  • Número de personas con acceso a los datos.
  • Perímetro del tratamiento.
Aunque en minoría, cada vez existen más personas, a las cuales les preocupa los abusos que sus datos de carácter personal sufren o pueden sufrir. Esto da lugar a que exista una mayor reticencia por parte de estas personas a nuevos tratamientos o a la cesión de estos datos.

Esta problemática no es buena para ninguna de las dos partes, ni para los usuarios porque dejarían de beneficiarse de ciertos servicios que se han convertido necesarios en su día a día, ni para las empresas que verían reducidos por un lado los servicios que ofertan y, por otro lado, los beneficios que obtienen de los datos de carácter personal de las personas físicas que se los ceden.

Además, con la inclusión del nuevo Reglamento Europeo en materia de Protección de Datos, las sanciones que se derivan del mal uso de los datos de carácter personal se han visto fuertemente endurecidas, lo que supone una vía extra de preocupación para las empresas que tratan este tipo de datos.

Las sanciones más graves, para las empresas que decidan establecer la política de no actuación, serán de hasta 20 millones de euros o el 4% de su facturación anual global, la cifra más alta de las dos. Y las sanciones más leves, podrán llegar hasta los 10 millones de euros o el 2% de su facturación anual global, la cifra más alta de las dos. En concreto, la infracción de la no minimización de los datos de carácter personal se encuadraría dentro del segundo grupo, es decir, dentro del grupo de las sanciones más graves.

La solución a estos problemas de privacidad pasa por encontrar un término medio en el cual las dos partes se encuentren a gusto y confiables.

Por un lado, los usuarios; si las empresas son capaces de proporcionarle la confianza de que tiene total control y conocimiento sobre lo que ocurre con sus datos, éstos no tendrán ningún tipo de inconveniente en cederlos para futuros tratamientos.

Por otro lado, las empresas; que sean capaces de implementar de forma pública y comprobable una política de minimización de datos, conseguirán un ahorro logístico, ya que los datos que no se recogen no exigen gasto alguno y una ventaja competitiva frente a sus rivales, ya que generarán en el usuario una mayor confianza.

Lo que es seguro, es que ambas partes tienen que realizar un proceso de cambio de actitud y de conciencia sobre este tema por el bien de todos.



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

Novedades del RGPD con respecto a la LOPD

En nuestro día a día, y sobre todo desde la inclusión en nuestra sociedad del mundo IT como una herramienta indispensable en nuestras vidas, realizamos una gran cantidad de acciones que impactan en nuestra privacidad. Cuando nos encontramos caminando podemos ser grabados por las cámaras que regulan el tráfico, cuando entramos en cualquier tienda también existen cámaras de seguridad, cuando navegamos por Internet dejamos una huella gigantesca sobre nuestras preferencias, gustos, datos personales, lugares que visitamos, además, sin pretenderlo, podemos aparecer en fotografías subidas a Internet por terceras personas en sus redes sociales.

Muchas veces, no somos conscientes de la cantidad de datos que compartimos sin pararnos a pensar en quién tratará estos datos, cómo serán usados, si están debidamente almacenados, y lo que es más importante, si una vez compartidos podemos recuperarlos, borrarlos y / o modificarlos.

Por ello, es necesario un reglamento que regule todo este tipo de situaciones en referencia a nuestros datos de carácter personal. En España, desde el año 1999 existe la Ley Orgánica de Protección de Datos (LOPD) y desde el año 2007 su Reglamento de Desarrollo de la Ley de Protección de Datos (RDLOPD).

El 25 de mayo de 2016 entró en vigor el Reglamento General de Protección de Datos (RGPD), aunque su aplicación no se hizo efectiva hasta el 25 de mayo de 2018. En estos dos años, las empresas debían realizar un proceso de adaptación progresivo y continuo a dicho reglamento, en todos aquellos aspectos que sean compatibles con la normativa vigente.

La LOPD es de las más tuitivas de Europa, por lo que el RGPD no introduce tantas diferencias como en otros países, aunque existen una serie de obligaciones adicionales a cumplir a partir del 25 de mayo de 2018.

¿En qué afecta el RGPD a la LOPD? ¿Qué hay de nuevo en este reglamento? A continuación, vamos a ver las principales novedades del RGPD respecto a la LOPD y su reglamento de desarrollo.
  1. Obtención del consentimiento para el tratamiento de datos
    • LOPD: El consentimiento del interesado es “toda manifestación de voluntad libre, inequívoca, específica e informada, mediante la que el interesado consienta el tratamiento de datos personales que le conciernen”
    • RGPD: Añade que para considerar que el consentimiento es inequívoco, según el artículo 32 del RGPD, se requerirá una acción positiva que manifieste su conformidad o una declaración del interesado.  Ya no cabe el consentimiento tácito que en ocasiones permitía la LOPD, sobre todo en Internet. Por ejemplo, ya no se entenderá otorgado el consentimiento por la simple navegación en una página web.

      Además, se establecen condiciones específicas para obtener el consentimiento de los menores.
  2. Derechos de los interesados
    • LOPD: Los derechos marcados por la LOPD son los siguiente:
      • Derecho de acceso.
      • Derecho de rectificación.
      • Derecho de cancelación.
      • Derecho de oposición.
    • RGPD: Además de los derechos incluidos en la LOPD, el RGPD incluye los siguientes derechos:
      • Derecho de supresión: permite al interesado, en una serie de casos, obtener sin dilación indebida del responsable del tratamiento la supresión de los datos personales que le conciernan. No es más que una manifestación de los tradicionales derechos de oposición y cancelación, pero reforzado, y garantizado también en el entorno de Internet.
      • Derecho de limitación del tratamiento: consiste en reconocer la potestad del interesado de solicitar y obtener del responsable del tratamiento o fichero, una limitación del tratamiento de sus datos personales cuando concurran los siguientes supuestos:
        • Inexactitud.
        • Ilicitud.
        • Reclamaciones.
        • Oposición.
      • Derecho de portabilidad: permite al interesado recibir los datos personales que le incumban, que haya facilitado a un responsable del tratamiento por medios automatizados, en un formato estructurado, de uso común y lectura mecánica, y transmitidos a otro responsable del tratamiento sin que lo pueda impedir el primer responsable.
  3. Deber de información
    • LOPD: Actualmente, la LOPD establece que se debe informar, en todo proceso de recogida de datos de carácter personal, de la finalidad, de la existencia de un fichero, de la obligación o no de la entrega y sus consecuencias, de los derechos del interesado y la identidad del responsable. Además, si el responsable ha obtenido los datos de terceros, dispone de un plazo de 3 meses para informar al interesado, indicando siempre la procedencia de los datos.
    • RGPD: El nuevo reglamento europeo refuerza esta obligación, introduciendo nuevos aspectos que deben ser comunicados al interesado. Debe informarse, de la base jurídica del tratamiento, el periodo de conservación de los datos de carácter personal y que los interesados pueden reclamar ante las autoridades de protección de datos, si consideran que existe un problema con la forma en la cual están tratando sus datos. Además, si la información se ha obtenido de terceros, deberá informarse al interesado en el plazo máximo de un mes.
  4. Comunicación de fallos a la autoridad de protección de datos
    • LOPD: La actual legislación no regula esta casuística.
    • RGPD: El nuevo reglamento europeo incorpora la obligación del responsable del tratamiento de notificar cualquier violación de seguridad de los datos de carácter personal, tanto a la autoridad de protección de datos, como al interesado.
  5. Evaluación de impacto del tratamiento de datos personales
    • LOPD: La actual legislación no regula esta casuística.
    • RGPD: Establece la obligación de realizar una evaluación de impacto para aquellas empresas que realicen tratamientos de datos que puedan implicar un alto riesgo para los derechos y libertades de las personas físicas. En este análisis debe evaluarse el origen, la naturaleza, la particularidad y la gravedad de dicho riesgo.
  6. Aplicación de medidas de seguridad
    • LOPD: Establece en su RDLOPD una serie de medidas de seguridad a aplicar dependiendo de la clasificación de los datos de carácter personal que contenga, básicos, medios o altos.
    • RGPD: A diferencia de la LOPD, el RGPD no establece un listado de medidas de seguridad, sólo indica que las medidas de seguridad que se adopten deben ser apropiadas en función del riesgo. El desglose de las medidas de la LOPD, deberían bastar para cumplir con las obligaciones de protección de datos, por lo que dicho listado puede servir de manera orientativa a las empresas para medir su nivel de cumplimiento.
  7. Registro de tratamiento de datos
    • LOPD: La actual legislación no regula esta casuística.
    • RGPD: Las empresas u organizaciones que habitualmente realicen tratamiento de datos de riesgo para la los derechos y libertades de los interesados, o traten datos especialmente protegidos, o relativos a condenas e infracciones penales, deberán tener un registro de las actividades de tratamiento efectuadas bajo su responsabilidad. Este registro interno, el cual tienen que realizar tanto responsables como encargas del tratamiento, deberá realizarse por escrito, y contener información detallada acerca de cada uno de los tratamientos de datos que realicen.
  8. Delegado de protección de datos (DPO)
    • LOPD: La actual legislación no regula esta casuística.
    • RGPD: Nace la figura de Delegado de Protección de Datos, cuyas funciones son las siguientes:
      • Informar y asesorar al responsable del tratamiento de datos de carácter personal de las obligaciones que debe cumplir para alinearse con el reglamento general.
      • Supervisar la aplicación de las medidas de seguridad por el encargado del tratamiento en materia de protección de datos de carácter personal.
      • Supervisar la documentación, notificación y comunicación de las violaciones de datos de carácter personal.
      • Supervisar la respuesta a las solicitudes de la autoridad de protección de datos y cooperar con ella por solicitud de la misma o por iniciativa propia.
      • Ejercer de punto de contacto con la autoridad de protección de datos.

Por todos estos cambios, es conveniente que las empresas revisen su estructura interna para asegurar que tiene los mecanismos y medidas de seguridad correspondientes adecuadas para cumplir con el nuevo reglamento europeo. Además, de que tienen todo lo necesario para que el delegado de protección de datos pueda cumplir con su función adecuadamente, y que todos los empleados conocen los protocolos de actuación en materia de protección de datos.

En definitiva y sobre todo, es importante por un lado, adecuar las cláusulas de información al interesado y la recogida del consentimiento para que se realice conforme al nuevo reglamento y se haga efectiva sobre una base legítima válida y adecuada, y por otro lado, revisar todos los procedimientos de protección de datos y proveer a los sistemas que tratan los datos de carácter personal, de una capa de seguridad adecuada para proteger dichos datos y garantizar la seguridad de los mismos.



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

Bancos, Fintech…¿hasta dónde llega PSD2?

Directiva de Servicios de Pago 2 y antecedentes
Desde hace algunos meses todos venimos escuchando hablar de la Directiva 2015/2366, mejor conocida como PSD2 (Payment Services Directive 2). Mucho se ha hablado de esta directiva; de la obligación de los bancos de disponer formas de consultar sus servicios para minoristas (probablemente en forma de APIs). Sin embargo, esta directiva tiene un ámbito de aplicación y un alcance mucho más extendido.

La Unión Europea ha publicado varias normativas en relación a la seguridad de los pagos. Por ejemplo, en 2007, la Unión Europea creó la primera Directiva de Servicios de Pago, que sentó precedente para posteriormente generar el Reglamento SEPA, el cual definía la Single Euro Payments Area (o en castellano, Zona Única de Pagos en Euros).

Definiciones
Antes de continuar entrando en materia es necesario tener claro algunos conceptos:
¿Qué es el dinero electrónico?
El dinero electrónico se entiende como el valor monetario que cumple las siguientes características:
  • Se almacena en un soporte electrónico.
  • Es emitido al recibir fondos de un importe cuyo valor no será inferior al valor monetario emitido.
  • Es aceptado como medio de pago por empresas diferentes al emisor.
¿Qué son los servicios de pago?
Probablemente uno de los conceptos más importantes de toda la Directiva. Estos servicios de Pago se encuentran definidos en al Anexo I y son:
  • Servicios que permitan el depósito de efectivo en una cuenta de pago y todas las operaciones necesarias para la gestión de una cuenta de pago.
  • Servicios que permitan la retirada de efectivo de una cuenta de pago y todas las operaciones necesarias para la gestión de una cuenta de pago.
  • Ejecución de operaciones de pago, incluida la transferencia de fondos, a través de una cuenta de pago en el proveedor de servicios de pago del usuario u otro proveedor de servicios de pago:
    • Ejecución de adeudos domiciliados, incluidos los adeudos domiciliados no recurrentes.
    • Ejecución de operaciones de pago mediante tarjeta de pago o dispositivo similar.
    • Ejecución de transferencias, incluidas las órdenes permanentes.
  • Ejecución de operaciones de pago cuando los fondos estén cubiertos por una línea de crédito abierta para un usuario de servicios de pago:
    • Ejecución de adeudos domiciliados, incluidos los adeudos domiciliados no recurrentes.
    • Ejecución de operaciones de pago mediante tarjeta de pago o dispositivo similar.
    • Ejecución de transferencias, incluidas las órdenes permanentes.
  • Emisión de instrumentos de pago y/o adquisición de operaciones de pago.
  • Envío de dinero.
  • Servicios de iniciación de pagos.
  • Servicios de información sobre cuentas.
Como vemos, son muchos los casos por los que un proveedor de servicios de pago se ve afectado por la presente directiva, pero de aquí surge otra pregunta: ¿qué es una cuenta de pago?

Una cuenta de pago no deja de ser cualquier cuenta sobre la que un usuario puede hacer un depósito o una retirada de efectivo, como sería una cuenta corriente de un banco. Es cierto que no hay una definición estandarizada de lo que es una cuenta de pago, y, además, la Directiva presenta cierta ambigüedad con el propósito de englobar posibles cambios y avances tecnológicos futuros, haciendo que surjan dudas en relación al alcance de la misma.

Una de las descripciones más ampliamente aceptadas es la que da la autoridad financiera del Reino Unido (Financial Conduct Authority, FCA). Según la FCA, para establecer si una cuenta puede ser considerada de pago se deben considerar:
  • El propósito para el que ha sido creada la cuenta.
  • Las funcionalidades que ofrezca la propia cuenta (como, por ejemplo, si permite realizar o no transferencias).
  • Restricciones de la propia cuenta (si únicamente pueden realizarse retiradas de dinero en un momento dato, por ejemplo).
  • Que la cuenta tenga limitación en la retirada y depósito de dinero siendo necesaria la intervención o acuerdo de un proveedor de servicios.
  • La finalidad con la que el propio usuario utiliza la cuenta.
Teniendo todo esto en consideración, ejemplos de cuenta de pago se considerarían, además de las ya mencionadas cuentas corrientes, las cuentas de dinero electrónico, las cuentas de las tarjetas de crédito o las cuentas de ahorro flexibles.

Pero ¿a quién afecta PSD2? Los Proveedores de servicios de pago
Este año ha entrado en vigor la directiva PSD2 que, a raíz de los progresos en la integración de los pagos minoristas en la Unión Europea, sirve como actualización y revisión del marco jurídico para englobar los nuevos servicios y productos ofertados. También sirve para detallar y clarificar artículos que en directivas anteriores eran demasiado ambiguos o generalistas.

Teniendo esto en consideración, la norma establece una serie de directrices en materia de seguridad y los requisitos para poder establecerse como proveedor de servicios de pago, además de definir nuevos actores en base a los nuevos servicios ofertados por algunas organizaciones, pero ¿qué es un proveedor de servicios de pago?

Para contestar a esta pregunta vamos a ver las diferentes categorías para los proveedores de servicio de pagos que vienen detalladas en el artículo 1 de la presente directiva, y en las que se incluyen:
  • Las entidades de crédito, tal como se definen en el Reglamento (UE) 575/2013, artículo 4, apartado 1, punto 1: "una empresa cuya actividad consista en recibir del público depósitos y otros fondos reembolsables y en conceder créditos por cuenta propia". Se incluyen también las sucursales de dicha entidad, siempre y cuando se encuentren dentro del territorio de la Unión. Los bancos son un ejemplo de proveedor de servicios de pago que entran en esta categoría.
  • Entidades de dinero electrónico: Estas entidades se definen en la Directiva 2009/110/CE, artículo 2, punto 1, "toda persona jurídica a la cual se haya otorgado autorización de conformidad con el título II, para emitir dinero electrónico". En el título II de esta directiva se describen las condiciones para realizar actividades con dinero electrónico. En caso de disponer de oficinas en territorio de la Unión, éstas también se verán afectadas por PSD2.
    Paypal sería el ejemplo más conocido de una entidad que trabaja con moneda electrónica y que realiza transacciones a través de "dinero virtual".
  • Instituciones de giro postal capaces de prestar servicios de pago. Es decir, servicios de pago realizado por un servicio de correos. En España sería la propio Correos, o bien instituciones como Western Union.
  • El Banco Central Europeo y los bancos centrales nacionales cuando no actúen en su condición de autoridad monetaria. Esto será para los servicios de pago que ofrezcan estas entidades, más allá de su rol como autoridad monetaria.
  • Los estados miembros y sus autoridades regionales y locales cuando no actúen en su condición de autoridades públicas. Similar al caso anterior; cuando las autoridades ofrezcan servicios de pago y no estén relacionados con su rol como autoridad monetaria, deberán cumplir con PSD2.
  • Entidades de pago. En este apartado recaerán la mayoría de los proveedores de servicios de pago. Encontramos la definición de este concepto en el artículo 4, que indica: "una persona jurídica a la cual se haya otorgado autorización, de conformidad con el artículo 11, para prestar y ejecutar servicios de pago en toda la Unión". El artículo 11 incluye requisitos para conceder autorización a un proveedor, por lo que lo que nos interesa en este momento es el concepto de "Servicios de pago".
Uno de los nuevos actores definidos por la Directiva viene derivado del servicio de “iniciación de pagos”. Se trata de servicios online a través de los cuales un usuario inicia una orden de pago en la cual se accede a una cuenta de pago para iniciar una transferencia de fondos. Para más información, podemos consultar el FAQ del 12 de enero de 2018 de la Comisión Europea, en la que se indica que los proveedores de servicios de iniciación de pagos "ayudan a los consumidores a hacer transferencias de crédito online e informan al comercio de forma inmediata de la iniciación del pago, permitiendo el envío de los bienes o el acceso inmediato al servicio contratado online". Al indicar que se trata de transferencias de crédito online, se incluye la posibilidad de realizar pagos a través de internet sin necesidad de una tarjeta de crédito, siendo únicamente necesaria una cuenta de pago; aunque en España no estamos muy habituados a esta operativa, sí se ve en algunos países europeos.

El último actor que se define en esta nueva PSD2, es el de "Proveedor de servicios de información de cuentas" que se define como un servicio online que da información agregada sobre una o varias cuentas de pago en las que es titular el usuario del servicio en otro proveedor o proveedores de pago. Un ejemplo de este tipo de actores sería la empresa española Fintonic.

Ámbito de aplicación
Estos son los actores sobre quienes aplica la Directiva PSD2. No obstante, debemos considerar que estamos ante una directiva europea, por lo que el ámbito de aplicación también se verá impactado por diversas características, que se definen en el artículo 2. En este artículo, en el punto 1, se define que el alcance de PSD2 aplicará a los servicios de pago prestados dentro de la Unión, cosa que ya definía la Directiva de 2007. Sin embargo, en los subsiguientes puntos se amplía el alcance, incluyendo:
  • Operaciones de pago en monedas diferentes de las utilizadas en la Unión, cuando tanto emisor como receptor se encuentran establecidos dentro de la Unión.
  • Operaciones de pago donde el emisor o el receptor estén en la Unión (basta con que uno de los proveedores de servicio esté en la Unión), independientemente de la moneda utilizada.
A este aspecto cabe hacer dos aclaraciones, la primera es que la Directiva limita el alcance en estos escenarios: “Respecto de aquellas partes de la operación de pago que se lleven a cabo en la Unión”, dejando claro que es posible que los proveedores de servicios de pago no puedan cumplir sus obligaciones en relación a transacciones que tienen lugar fuera de la Unión.

También indicar que hay varios artículos (como el 45 o el 52) dentro de la Directiva que sirven como excepciones a los casos aquí listados. Estas excepciones darían para otro artículo, por lo que no las trataremos aquí.

Otras consideraciones
Otro de los aspectos que quiero destacar de esta nueva Directiva es el de la transparencia. Siguiendo los caminos marcados por otras regulaciones y directivas, PSD2 también es muy explícita exigiendo requisitos de transparencia. Lo podemos ver en al artículo 1, punto 2 “La presente Directiva establece asimismo normas en materia de los requisitos de transparencia”, donde ya se introduce esta necesidad y para la que se profundiza mucho más en el Título III “Transparencia de las Condiciones y Requisitos de Información Aplicables a los Servicios de Pago” (artículos 38-60). Este título se subdivide en cuatro capítulos, de los cuales me centraré en los capítulos 2 y 3. Estos capítulos son muy similares entre sí, y describen los derechos de deberes de todos los actores involucrados en los pagos; pagos singulares en el capítulo 2 y contratos marco en el capítulo 3.

En el artículo 44 (capítulo 2), por ejemplo, vemos cierto alineamiento con el RGPD, cuando se indica que el proveedor de servicios de pago estará “obligado a poner a disposición del usuario de servicios de pago, de un modo fácilmente accesible para él, la información y las condiciones … en relación con sus propios servicios, antes de que el usuario quede vinculado por cualquier contrato u oferta”, añadiendo además “La información y las condiciones estarán redactadas en términos fácilmente comprensibles, de manera clara y legible”, de manera que el usuario tenga claros sus derechos y obligaciones antes de utilizar el servicio cuando se trata de una operación de pago.

Continuando con este capítulo, por su parte, el artículo 45 da más detalle sobre la información que se requiere facilitar a los usuarios, mientras que los artículos 46-49 reflejan la información a aportar por el proveedor de servicios de pago a los diferentes actores durante y tras la ejecución de la operación.

En relación al capítulo 3, la estructura es similar al capítulo 2, solo que en este caso hablamos de contratos marco, obligando (artículo 51) a facilitar al usuario en un ‘soporte duradero’ la información y condiciones del servicio, detalladas en el artículo 52, que además recoge cláusulas sobre los gastos, tipos de interés, cambios y ceses de los contratos.

Mencionar también el artículo 40, donde se indica que el proveedor de servicios de pago no podrá cobrar al usuario por el suministro de la información, aunque se podrá cobrar por facilitar información adicional a través de canales de comunicación especificados en un contrato marco, siendo siempre un precio razonable y acorde a los costes efectivos.

España aún no ha publicado una ley que trasponga la Directiva 2015/2366 (a diciembre de 2018), aunque ya se dispone de un anteproyecto que se puede consultar en la web del Ministerio de Economía y Empresa, bastante alineado, aunque con algunos cambios estructurales; tendremos que esperar para ver cómo queda la ley finalmente.

Conclusiones
En resumen, esta directiva amplía los límites existentes en materia de servicios de pago, e incluye los nuevos roles para adaptarse a los cambios tecnológicos y nuevos actores que han surgido en los últimos años, mejorando los derechos de los ciudadanos y aumentando las responsabilidades de las compañías.

Sin duda, la mayor carga de trabajo esté en los propios bancos, ya que facilitar el acceso a su información supone, además del gasto en el desarrollo de la API y el gasto en seguridad consecuente (lo veremos en otro artículo, pero también se recogen necesidades en materia de continuidad de negocio y doble factor de autenticación), pierden su ‘monopolio’ en relación a esta información. Desde mi punto de vista, sin duda son los principales ‘perdedores’ de esta nueva directiva, aunque considero que también puede verse como una gran oportunidad de negocio, ya que al facilitar el acceso a la información de terceros tendrán una gran variedad de canales a través de los que ofrecer sus servicios.

Por su parte, los proveedores de servicios de pago pasarán a estar más regulados. A su favor tienen que para ellos será más fácil y transparente acceder a la información de los bancos (ya sea para acceder a información bancaria en el caso proveedores que se hagan consolidación de información como para los iniciadores de pago, que tendrán que consultar el saldo del usuario), pero, por el contrario, tendrán gran cantidad de obligaciones, siendo necesario establecerse como proveedor regulado, demostrar la disponibilidad de fondos propios (aunque esto no será necesario para todos los proveedores de servicios) y garantizar la seguridad a través de ciertos requerimientos técnicos incluidos en los reglamentos delegados.

¿Los grandes beneficiarios? Los usuarios, sin ninguna duda. Ganan en derechos, al tener la información fácilmente accesible; ganan en seguridad, pues su información debe ser tratada siguiendo ciertas pautas que están obligados a cumplir estos proveedores de servicio y ganan en el servicio prestado, ya que, al poder facilitar el acceso a su información a terceros, podrán elegir entre gran cantidad de proveedores que ofrezcan servicios similares y elegir el que más se adecúe a sus necesidades.

Bibliografía:
Guía PSD2 del European Banking Federation: https://www.betaalvereniging.nl/wp-content/uploads/EBF_PSD2_guidance_september2016.pdf
FAQ Payment Services de la Financial Conduct Authority: https://www.handbook.fca.org.uk/handbook/PERG/15/3.html?date=2016-02-03
FAQ PSD2 de la Comisión Europea: http://europa.eu/rapid/press-release_MEMO-15-5793_en.htm


Autor: Antonio Martínez Jiménez - CISSP Instructor, ISO 20000 L.A., ISO 27001 L.A., ISO 22301 L.A.
Dpto. Consultoría

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