Header Ads Widget

Ticker

6/recent/ticker-posts

Seguridad API de alto grado para bancos

 


Las instituciones financieras ocupan una zona especial para las API en gran parte debido a lo estrictos que son los conjuntos de reglas de cumplimiento normativo . Los datos que las instituciones financieras de apalancamiento están protegidos ampliamente por una variedad de ordenanzas reguladoras, y como tal, estos datos tienen que ser rigurosamente controlado, asegurado , y gestionado - de ahí la razón por la seguridad de la API de alto grado es una preocupación tan grave.

En este artículo, analizaremos las serias consideraciones de cumplimiento normativo inherentes al intercambio y la gestión de datos financieros . Examinaremos algunos métodos para proteger dichos datos y lo que se puede hacer (y se debe hacer) para garantizar la seguridad y protección del consumidor.

Consideraciones de cumplimiento normativo

¿Qué estándares regulatorios existen para las API financieras? Si bien enumerar cada organismo regulador podría ser una pieza completamente separada, destacar las pautas regulatorias más comunes ayudará a contextualizar algunas de las reglas con las que se encontrarán los proveedores de API del sector financiero.

  • Basilea II es un conjunto de estándares internacionales que requiere que las organizaciones financieras evalúen y mitiguen las pérdidas por riesgo operativo de los datos financieros. Se ocupa específicamente de la seguridad insuficiente para los datos y fallas del sistema debido a una configuración incorrecta y / o expectativas deficientes de las demandas del sistema y, como tal, es un buen punto de partida para muchos sistemas que planean utilizar datos financieros.
  • PSD2 : La segunda revisión de la Directiva de servicios de pago fue diseñada por la Comisión Europea para regular los servicios de pago tanto en la UE como en el Espacio Económico Europeo. La regulación se ocupa principalmente de la protección del consumidor y el establecimiento de derechos, obligaciones y expectativas para los proveedores de pagos y las instituciones financieras.
  • El Sistema de Calificación Uniforme de FFIEC para Tecnología de la Información (URSIT) es un estándar federal de los EE. UU. Para examinar a una empresa para los procesos adecuados de Auditoría, Gestión, Desarrollo, Adquisición, Soporte y Entrega. URSIT es una gran herramienta para configurar un proceso para identificar problemas de seguridad y puede servir como un tipo de marco para dicho proceso.
  • La Ley Gramm-Leach-Blilely es una ley federal de los EE. UU. Que requiere que las instituciones financieras garanticen la seguridad de los datos financieros y personales . Esta ley es la base de la Regla de protección de datos emitida por la FTC , que requiere un plan de seguridad de la información que incorpore evaluaciones de riesgo como parte de un proceso de auditoría de seguridad total.
  • PCI-DSS es un estándar regulatorio que requiere escaneo de vulnerabilidades y revisión del código fuente para garantizar que los datos y procesos de la industria de tarjetas de pago cumplan con los estrictos procesos de seguridad requeridos por los proveedores y los proveedores de pagos. PCI-DSS es clave para muchas organizaciones en línea, especialmente aquellas que administran el procesamiento de pagos para productos y, como tal, cualquier API que tenga un enfoque de monetización que integre el pago con tarjeta de forma nativa debe ser muy consciente de PCI-DSS y sus requisitos.
  • Sarbanes-Oxley requiere que los controles internos informen al proveedor como un medio para rastrear la precisión y seguridad de los datos financieros. Incluye mecanismos de auditoría bastante estrictos para los controles internos y exige el examen de los activos de TI, el software y las soluciones para determinar la resistencia a las filtraciones y exposiciones de datos.

Cabe señalar que, nuevamente, esta es solo una pequeña selección de los estándares regulatorios más comunes y de alto nivel ; dependiendo de dónde haga negocios en la región , las regulaciones pueden ser más amplias o más estrechas, y estas variaciones pueden volverse aún más marcadas por separado. campos dentro de la misma industria. Dicho esto, comprender estas estructuras regulatorias de alto nivel puede ayudar a enmarcar la conversación en el futuro.

Lea también: Cumplimiento de las nuevas y estrictas normas de la UE sobre protección de datos

Identificación de datos vitales

Con todo esto en mente, y una comprensión de cuán valiosos pueden ser nuestros datos financieros, también debemos identificar qué datos específicos están protegidos . En términos generales, podemos clasificar nuestros datos en una de tres categorías: datos personales , datos financieros y datos transaccionales .

Información personal

Los datos personales son exactamente lo que parece. Este tipo de datos es información específica del usuario y vincula cuentas con números de seguro social o sistemas de identificación nacional, direcciones, nombres y más. Este tipo de datos no es necesariamente peligroso de exponer por sí mismos (aunque los números de seguro social y otro contenido relacionado son a menudo importantes a nivel federal), pero en combinación con otros datos, se pueden usar para ataques personalizados y dirigidos .

Datos financieros

Los datos financieros son todos los datos relacionados con las cuentas mantenidas por los datos personales y, por lo general, tienen más que ver con los fondos disponibles para una persona, su posición en el banco, información crediticia y otros datos bancarios. Nuevamente, aunque no es específicamente peligroso por sí solo, en combinación con los Datos personales, puede convertirse rápidamente en una gran preocupación de seguridad para el usuario.

Datos transaccionales

Los datos transaccionales están íntimamente relacionados con los datos financieros, pero están separados aquí debido a la naturaleza de su generación de datos. Los datos transaccionales son los datos que dictan transferencias de fondos, compras, movimientos de una cuenta a otra, y más. A menudo se requiere que estos datos se guarden para la prevención del crimen organizado y las investigaciones de fraude , pero también podrían usarse para capturar códigos de autorización para ataques de repetición , rastrear compras por fraude y chantaje, o incluso usarse como un medio para rastrear la ubicación aproximada de una persona .

El peligro real surge cuando se combinan estos tipos de datos: conocer las tenencias de cuentas, direcciones, nombres y más puede resultar en un fraude masivo y daños al usuario. Como tal, todos los datos deben percibirse como críticos.

Leer más: Leyes de privacidad e intercambio internacional de datos: comparación de los estándares de la UE y los EE. UU.

Vulnerabilidades potenciales

Una de las principales preocupaciones de los datos financieros es mantenerlos confidenciales y exponerlos solo a quienes tienen derecho a verlos. El control de acceso es una parte importante de la protección financiera, ya que los titulares de las cuentas no serán las únicas personas que accedan a los datos. Los investigadores, auditores, gerentes bancarios, empleados y otros pueden tener que, de vez en cuando, acceder a los datos bancarios. Como tal y como tal, garantizar diferentes niveles de confidencialidad es clave para garantizar que las vulnerabilidades se mantengan al mínimo.

Los bancos también deben asegurar la integridad de los datos ; lo que significa que los datos se almacenan correctamente y sin alteraciones entre usos. Permitir que se modifiquen los montos de las tenencias de cuentas, los puntos de origen, la información transaccional y más, anularía todo el propósito de una institución financiera y generaría un caos. Por lo tanto, proteger los sistemas de acciones de escritura incorrectas y hacer copias de seguridad de estos libros de contabilidad en forma segura para su restauración es clave para garantizar que estas vulnerabilidades no se propaguen.

La disponibilidad también es un aspecto importante de la banca, ya que existe una gran cantidad de regulaciones relacionadas con garantizar que los usuarios e inversores tengan acceso a sus sistemas y fondos en todo momento. El tiempo de inactividad a menudo se asocia con un costo adicional, la pérdida de la confianza del inversor y la exposición de los sistemas a los ataques y, como tal, garantizar la disponibilidad mediante la distribución de la carga del servidor y el filtrado del tráfico fuzz es clave para cualquier institución bancaria.

Si bien existe una amplia gama de vulnerabilidades que no se analizan aquí, estas vulnerabilidades se incluirán en gran medida en las categorías anteriores.

Metodologías de seguridad API

Ahora que entendemos nuestras vulnerabilidades, podemos comenzar a buscar  soluciones para mitigarlas. Ninguna solución se aplicará a todos los niveles de la institución financiera, y esto debe tenerse en cuenta al promediar los costos y contextualizar las soluciones para sus casos de uso determinados.

Claves API

Las claves de API son un mecanismo fundamental de seguridad de API y se utilizan para API de bajo nivel y baja seguridad en todo el mundo. El concepto es simple: genere una clave para el usuario que lo identifique en el sistema, de modo que cuando se emita una solicitud, el propio sistema pueda identificar la clave y señalar al usuario como quien dice ser.

El problema es que las claves API en sí mismas no son del todo seguras . Las claves de API no están destinadas a servir como un método para asegurar el acceso, sino solo como un método para probar que el usuario es quien dice ser; en otras palabras, las claves de API no son autenticación y autorización, sino más bien identificación . Por lo tanto, usar una clave API como método de seguridad puede ser muy peligroso.

A esto se suma el hecho de que las claves API carecen de control en la granularidad (a menudo es una opción de identificación de "sí o no"), y rápidamente se encuentra en una situación en la que su clave API hace más daño que bien. Sin embargo, eso no quiere decir que las claves de API no tengan un propósito; hemos discutido esto en detalle en un artículo anterior sobre las API nórdicas :

… Las claves de API no son, por naturaleza, una solución completa. Si bien pueden estar perfectamente bien para fines de solo lectura, son una solución demasiado débil para igualar la complejidad de un sistema API de uso elevado ...

En otras palabras, las claves de API tienen un propósito muy específico y se pueden usar con gran efecto para funciones de solo lectura de puntos finales expuestos públicamente en datos inseguros (como verificar el estado del servidor o comenzar un proceso de autorización / autenticación más estricto), pero no deben ser considerado una solución de seguridad holística .

OAuth y JWT

Para proteger los datos, una combinación de OAuth y el uso de JWT puede resultar muy eficaz para proteger los datos. Esto es más fácil de contextualizar si trabajamos al revés mirando primero el JWT.

Los JWT , o JSON Web Tokens , son paquetes muy pequeños e independientes que contienen toda la información que el servidor necesitará para procesar una solicitud, y luego toda la información generada por el servidor que el usuario necesita. Como tal, el JWT representa una metodología de comunicación liviana y muy eficiente en la red API y ofrece todas las ventajas de JSON .

Sin embargo, los JWT no son cifrados y solo sirven para el proceso de codificación de los datos; como tales, son tan seguros como el sistema en el que residen. Esta es una advertencia importante de los JWT y debería ser parte de la conversación al adoptar el proceso de codificación.

Una nota al margen - en efecto, hay una especificación para el cifrado de JWT, conocido como JOSE - Firma de objetos JSON y cifrado - que puede ofrecer una mayor seguridad, especialmente cuando se combina con los más estrictos métodos de encriptación y seguridad.

Con nuestro paquete codificado fuera del camino, podemos comenzar a buscar otros métodos para asegurar el acceso al sistema en sí. OAuth es un sistema basado en tokens para autenticación y autorización. RFC 6749 creó OAuth 2.0 , una evolución de marco actualizada que se combina con una definición de uso de token de portador en RFC 6750 .

Si bien es cierto que OAuth es un sistema de autenticación y autorización, debe decirse que OAuth por sí solo no proporciona un protocolo de autenticación, sino que establece un marco para las metodologías y decisiones de autenticación. Su protocolo utiliza cuatro entidades generales para controlar el acceso a los datos:

  • Un propietario de recursos (RO) controla los datos que expone la API y se considera el "propietario" de dichos datos.
  • El servidor de autorización (AS) es un servicio de token de seguridad (STS) que emite, controla y revoca tokens para el acceso; a menudo también se lo denomina servidor OAuth en el sistema interno.
  • El Cliente es la aplicación, usuario, sitio web, etc. que solicita datos en nombre del propietario del recurso.
  • Finalmente, el servidor de recursos (RS) es el servicio que expone y almacena los datos, y normalmente es la propia API.
Gif de flujo de OAuth estándar

En este artículo se encuentra un ejemplo de un flujo de OAuth básico .

OAuth tiene grandes beneficios para las instituciones bancarias , pero quizás el mejor aspecto es que encaja con la organización natural de una institución financiera. El Cliente funciona como cajero o administrador, el AS funciona como un servidor interno que verifica la propiedad de la cuenta y el token funciona como una especie de tarjeta de identificación que verifica la propiedad y los derechos; de esta manera, al menos en situaciones seguras, OAuth es una gran solución para reflejar las estructuras organizativas del banco en la forma en que maneja sus propios datos. Es como la Ley de Conway en acción.

Leer más: ¿Por qué no puedo enviar JWT sin OAuth?

Conexión OpenID

OpenID Connect es una capa de identidad simple que está diseñada para colocarse sobre OAuth. OpenID Connect es en realidad la tercera revisión del enfoque OpenID y, más específicamente, se creó para superar las limitaciones de diseño anteriores de OpenID 2.0 en lo que respecta a Relying Parties, dependencia de XML y más. OAuth 2.0 es el sustrato de OpenID Connect y, como tal, utiliza la infraestructura HTTPS (específicamente TLS / SSL) para la seguridad de los datos.

Leer más: Casos de uso únicos de OpenID

Seguridad: ¿responsabilidad del proveedor de API?

Es importante discutir exactamente dónde existe realmente la responsabilidad de la seguridad de los datos para la industria financiera. En teoría, la responsabilidad de la seguridad debería existir en todos los niveles del espacio API, con los usuarios asegurando sus dispositivos, los clientes implementando un cifrado fuerte, etc. La realidad es que esta utopía no existe.

En consecuencia, el mejor enfoque es que el proveedor de API asuma la responsabilidad de seguridad. Tanto en términos de cumplimiento de las regulaciones como de responsabilidad moral, la seguridad es principalmente una preocupación para el proveedor de API.

Exploits e infracciones recientes

Esto tampoco es solo una tontería teórica: la falta de incorporación e internalización de estos problemas ha dado lugar a importantes exploits y brechas recientes de algunas organizaciones bastante grandes.

En 2014 se lanzó un ataque contra el banco Chase , que exponía la información financiera y personal de 76 millones de hogares y 7 millones de pequeñas empresas. La brecha fue un punto doloroso considerando que Chase gasta más de $ 250 mil millones anualmente en ciberseguridad, especialmente considerando que el costo de la violación se ha estimado en $ 1 mil millones de dólares.

No todas las infracciones son solo de instituciones financieras. Home Depot también fue objeto de un ciberataque en 2014, y los piratas informáticos utilizaron información de socios de un proveedor para exponer una gran cantidad de datos de compradores y empresas. El costo, antes de los reembolsos del seguro, se estima en $ 80 millones de dólares. La violación de Home Depot es un gran ejemplo de cómo las instituciones no pueden necesariamente confiar en otros en la cadena para brindar la seguridad adecuada; en este caso, fue el proveedor específicamente quien expuso los datos internamente.

Ambos casos son un cambio tonto en comparación con quizás la mayor brecha en los últimos años, la brecha de Equifax. . En 2017, Equifax reveló que un ataque cibernético reveló números de tarjetas de crédito e información de identificación personal de casi 143 millones de estadounidenses, casi la mitad de todo el país. La violación incluyó nombres, números de seguro social, fechas de nacimiento, direcciones, licencias de conducir, números de tarjetas de crédito y otra información financiera, lo que generó reclamos masivos de seguros y fraude generalizado. A septiembre de 2017, la violación le ha costado a Equifax casi $ 4 mil millones en participación de mercado perdida, y las reclamaciones de seguros y las medidas punitivas aún se están calculando.

En última instancia, estas son solo tres de las muchas infracciones en los últimos años, y a medida que la tecnología avanza drásticamente y los ataques dirigidos contra las instituciones se vuelven más maduros y complejos, es probable que aumente la cantidad de infracciones.

Conclusión

En última instancia, la seguridad de la API recae directamente sobre los hombros del proveedor de API y, por lo tanto, de la propia institución financiera: la falta de comprensión de las vulnerabilidades inherentes a dichas funciones comerciales, así como las preocupaciones fundamentales de la CIA dentro del ecosistema en general, puede resultar en pérdidas masivas. y exposiciones. Sin embargo, si una institución financiera internaliza estas preocupaciones desde el principio, estas funciones se pueden proporcionar de forma segura y con gran eficiencia.

¿Qué piensas? ¿Hay mayores preocupaciones sobre la seguridad financiera que no se mencionaron en este artículo? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios