API de Open Banking en PSD2: cómo mitigar el riesgo

Frederik Mennes, 14 de Mayo de 2018

En los últimos años, la banca abierta ha recibido mucha atención en el sector de servicios financieros. La banca abierta significa que los bancos abren sus sistemas a proveedores de servicios financieros autorizados de terceros, por lo que estas empresas pueden iniciar y procesar pagos y transacciones financieras a solicitud de los clientes del banco.

La banca abierta promete desbloquear la innovación que mejorará profundamente la experiencia bancaria e introducirá nuevos servicios financieros. Por ejemplo, los proveedores de terceros (TPP) pueden proporcionar aplicaciones que permitan a los consumidores consultar varias cuentas bancarias desde una sola aplicación, o aplicaciones que faciliten a las empresas compartir datos con sus contadores.

Bajo PSD2, los bancos deben ofrecer una interfaz que permita a los TPP comunicarse con ellos. De esa manera, si el consumidor desea utilizar proveedores de servicios financieros que no sean el banco, estos proveedores pueden obtener acceso a los sistemas del banco y atender a los clientes del banco a través de la interfaz de comunicación abierta.

Esto no está exento de riesgos. De acuerdo a McKinsey & Company , “La mayoría de los bancos informan que no esperan que la seguridad se convierta en un problema bajo PSD2; Sin embargo, también reconocen que deben invertir en la gestión del fraude. Los bancos son responsables de mitigar el riesgo de fraude y deberán implementar controles avanzados, que incluyan análisis avanzados (por ejemplo, para validar el origen de las llamadas entrantes a la API) y herramientas sólidas para detectar ataques de fraude. Los encuestados [Encuesta PSD2 de la Práctica Global de Pagos McKinsey 2017] indicaron que El riesgo de fraude derivado del acceso de terceros a las cuentas es una preocupación grave y la prevención del fraude es una prioridad. "

Riesgos para los bancos

La introducción de API abiertas hace que los bancos dependan de la seguridad de los TPP que utilizan estas API. Los posibles escenarios de amenazas incluyen:

  • Una violación de datos en un TPP expone a los clientes del banco
    • Los TPP almacenarán los datos financieros de los consumidores. Si se viola un TPP, eso podría exponer los datos del cliente del banco, lo que a su vez podría afectar la reputación del banco. A la luz de la europea Reglamento general de protección de datos (GDPR), los bancos deben asegurarse de que los TPP implementen medidas técnicas y organizativas apropiadas para proteger los datos de los clientes.
  • Solicitudes fraudulentas de un TPP comprometido
    • Si se piratea un TPP, eso podría dar lugar a solicitudes fraudulentas de información sobre los clientes de un banco, o solicitudes de pago fraudulentas del TPP al banco. Tal incidente podría ocurrir a través de vulnerabilidades en la aplicación móvil o aplicación web del TPP. Dado que los bancos son los primeros responsables de las transacciones financieras no autorizadas de la cuenta bancaria de un usuario, una violación de seguridad en un TPP puede tener serias consecuencias para los bancos.
  • Solicitudes fraudulentas de los empleados de TPP
    • Un empleado descontento en un TPP podría emitir solicitudes fraudulentas de información sobre los clientes de un banco o iniciar pagos fraudulentos.
Missing elemento multimedia.

Los bancos deben adoptar una serie de medidas de seguridad técnicas y organizativas para abordar estas y otras amenazas. En el contexto de la banca abierta, los bancos pueden mitigar el riesgo de múltiples maneras:

1) Utilizar análisis de riesgo de transacción
Los bancos pueden usar el análisis de riesgo de transacción para:

  • Detectar transacciones fraudulentas y el comportamiento del usuario. Las Normas Técnicas Regulatorias (RTS) de PSD2 exigen que los proveedores de servicios de pago (PSP), incluidos los bancos, realicen un análisis de riesgo de todas las transacciones financieras que procesan. De esta manera, los PSP pueden detectar el fraude de pagos, como el fraude sin tarjeta.
  • Detectar incidentes de seguridad en TPP. El análisis de riesgo de transacción se puede utilizar para detectar comportamientos anormales en solicitudes que se originan en TPP, identificar transacciones sospechosas de TPP, detectar secuencias atípicas de llamadas API y todo esto en tiempo real.
  • Detectar vulnerabilidades de implementación de API. Las debilidades en la implementación de las API pueden dar lugar a transacciones fraudulentas y comportamientos inusuales del usuario, que pueden detectarse mediante el monitoreo avanzado de fraudes.

2) Elija el modelo de autenticación correcto
Autenticación fuerte del cliente es crítico, ya sea Autenticación de dos factores , autenticación multifactor , autenticación biométrica , u otro. Sin embargo, diferentes modelos de autenticación tienen sus propias características e implicaciones de seguridad. Para el banco, generalmente es mejor usar un modelo que coloque el proceso de autenticación con el banco mismo o con un proveedor de seguridad externo. Esto significa que el banco continuará comunicándose directamente con el usuario en lugar de hacerlo a través del TPP. Al hacerlo, hay más información disponible para el banco para el análisis del riesgo de transacción, incluida la prueba de eventos de autenticación, que es relevante para manejar disputas sobre la responsabilidad de una transacción fraudulenta.

3) Proteja el canal de comunicación con TPP
Los bancos deben proteger el intercambio de datos con sus TPP. Piense en la autenticación mutua entre un banco y TPP utilizando, por ejemplo, protocolos SSL / TSL.

4) Solicitar informes de auditoría de seguridad independientes de los TPP
La Comisión Europea ha anticipado riesgos de seguridad bajo PSD2 y, por lo tanto, requiere que los PSP y TPP administren los riesgos operativos y de seguridad. Más específicamente, el Artículo 95 (1) de PSD2 requiere que los PSP establezcan un marco con medidas de mitigación apropiadas para gestionar los riesgos operativos y de seguridad relacionados con los servicios financieros que prestan. El establecimiento, la implementación y el monitoreo de las medidas de seguridad deben cubrir lo siguiente:

  • Gobernanza, incluido el marco de gestión de riesgos operativos y de seguridad, los modelos de gestión y control de riesgos y la subcontratación
  • Evaluación de riesgos, incluida la identificación, clasificación y evaluación de riesgos de funciones, procesos y activos.
  • Protección de la integridad de datos, sistemas y confidencialidad, seguridad física y control de activos.
  • Monitoreo, detección y reporte de incidentes de seguridad.
  • Gestión de la continuidad del negocio, incluidas las pruebas de los planes de continuidad del negocio, la gestión de incidentes y la comunicación de crisis.
  • Pruebas independientes de medidas de seguridad.

Los bancos deben solicitar que los TPP proporcionen informes de pruebas de seguridad independientes para verificar la madurez de sus prácticas de seguridad.

5) Evite vulnerabilidades de seguridad en la implementación de API
Para protegerse contra los ataques de inyección, asegúrese de que, sea cual sea el formato de datos que utilice la API, el componente de software de la API que analiza las estructuras de datos está reforzado contra los ataques. Además, los bancos deben proteger la desinfección de insumos para evitar la inyección de todas las formas. El análisis y las pruebas de seguridad deben cubrir todas las API y herramientas para que los bancos puedan descubrirlas y analizarlas de manera efectiva.

API de banca abierta y cómo protegerlos

Las API abiertas requeridas por PSD2 indudablemente conducirán a servicios y aplicaciones bancarias nuevos e innovadores. Al mismo tiempo, sin embargo, los bancos deben evitar que los delincuentes accedan a los datos y transacciones de los clientes. Por lo tanto, los bancos y los TPP deben ser conscientes de los riesgos y ofrecer una protección suficiente. Para obtener más información, descargue este documento técnico:

API de banca abierta en PSD2: amenazas y soluciones de seguridad

Este blog se inspiró en un artículo de Frederik Mennes que apareció por primera vez en Techzine .

Frederik dirige el Centro de Competencia de Seguridad de OneSpan, donde es responsable de los aspectos de seguridad de los productos y la infraestructura de OneSpan. Tiene un profundo conocimiento de las tecnologías de autenticación, gestión de identidades, normativa y seguridad para aplicaciones en la nube y móviles.