Analytics

viernes, 21 de diciembre de 2018

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