Un informe trimestral publicado por la plataforma integrada de aplicaciones y seguridad Brazo de pared presta atención granular a un problema de seguridad crítico pero poco discutido para las fintech: sus API. Los informes se compilan de fuentes disponibles públicamente.
Cofundador y director ejecutivo de Wallarm Iván Novikov dijo que su objetivo para los informes era estimar la magnitud de las amenazas y agruparlas en secciones razonables. Esto ayuda a los CISO y a los gerentes de ciberseguridad a medir los peligros y construir modelos de riesgo. Cada trimestre, el equipo de Wallarm analiza cada incidente disponible, lo combina con información adicional y lo enriquece.
Novikov dijo que Focus produce análisis en tiempo real con mejor información que otros informes publicados con menos frecuencia. También identifica nuevos grupos de amenazas que pueden atribuirse a la proliferación del uso de API.
Las fugas de API son una amenaza emergente
Las inyecciones fueron, con diferencia, el mayor problema del trimestre. Sus 59 sucesos conocidos representan el 25% de las 239 acciones rastreadas. Las inyecciones ocurren cuando alguien envía comandos API peligrosos a través de un campo de entrada del usuario. Los fallos de autenticación ocupan el segundo lugar con 37. Se trata de fallos de verificación de identidad. Los problemas entre sitios ocupan el tercer lugar con 30.
Las fugas de API representan más del 10% de los incidentes. Afectan a Netflix, a los proveedores de software de código abierto y a las empresas de software empresarial. Novikov dijo que las fugas de API son un problema descubierto recientemente.
Hay dos tipos de API, incluido uno que se refiere específicamente a las fintech: las API abiertas para el sector bancario. Novikov dijo que las instituciones están interesadas en dos cosas, la primera es adónde viajan sus datos financieros. Esto incluye información de identificación personal e información de cuentas bancarias internas. Necesitan saber si el dinero se está desviando a un lugar donde no debería estar.
“Si observa que los números de cuentas bancarias internas están vinculados como un número de ruta, (los delincuentes) pueden hacer muchas cosas”, dijo Novikov. “Es posible que estén utilizando un esquema de fraude completamente diferente. Si recuerdas las películas con James Bond, dicen: ‘Conozco tu número de cuenta en Suiza’, es exactamente lo mismo”.
Estos elementos de datos podrían ser acceso privado a su API. Podrían ser certificados que usted emitió a un banco asociado y que se han visto comprometidos. Cada parte con la que comparte una clave es responsable de ella, pero usted es responsable de los datos abiertos.
Si bien los bancos tienen muchos recursos para protegerse si las contraseñas y las credenciales de inicio de sesión se ven comprometidas, Novikov dijo que las API tienen una clave, y eso es todo. Un banco lo acepta y tú eres socio.
“Por eso estamos desarrollando soluciones para resolver este problema, porque el problema es enorme”.
El envejecimiento de la infraestructura empeora el problema
La antigüedad de muchas API bancarias se suma al desafío. Con los mayores, es más difícil encontrar quién estableció la clave. Está en algún lugar del código. Novikov ha visto ejemplos de COBOL que se remontan a 1998.
“Está en algún lugar del código y puedes extraerlo desde allí”, dijo Novikov. “Es una clave codificada que alguien puso allí. Inicie sesión con XML y estará listo. Y ahora le estamos agregando una puerta de enlace API sofisticada y la llamamos banca abierta. Está abierto, pero está abierto desde un ángulo diferente. Está muy, muy lleno de agujeros.
Monitoriza a tus socios
Dada la magnitud del riesgo, corresponde a las instituciones financieras asegurarse de que pueden confiar en sus socios. Novikov dijo que los bancos se sienten más cómodos porque pueden definir los estándares que deben seguir sus proveedores de datos.
Es un poco más flexible para las fintech. Novikov los alienta a establecer sus estándares. Comparte una clave con un facilitador fintech y él es responsable de ella.
“Como fintech, no están regulados como un banco”, dijo Novikov. “Deberían hacerlo ellos mismos. En este caso, dependen (de los bancos) y deberían confiar en sí mismos. Este es un gran problema porque si quiero conectar mi Robinhood a mi banco, no tengo otra opción.
A falta de un estándar industrial, las fintechs pueden decidir qué nivel de seguridad utilizar. Y cuando todo su negocio se reduce a las API, es mejor que tenga una buena seguridad.
Vicepresidente de marketing Girish Bhat dijo que Wallarm está construyendo una plataforma nativa de la nube que también se puede utilizar localmente. Puede detectar ataques casi en tiempo real. Puede proporcionar recomendaciones de reparación y capacidades de remediación al trabajar con otras herramientas en un ecosistema fintech.
“Hay miles de millones de llamadas API”, dijo Bhat. “Podemos analizar esto en tiempo real y brindar la capacidad proactiva para mitigarlos. »
Las credenciales débiles y los problemas de criptografía son un elemento sorprendente en la lista de los 10 problemas principales. Novikov dijo que muchas empresas utilizan claves estándar predeterminadas.
“Es obvio para todos que no se deben usar claves estándar o predeterminadas, pero esto sucede cada vez más”, dijo. “Desafortunadamente, todavía no podemos deshacernos de esto como industria, por el motivo que sea”.
Cómo ChatGPT ayudó a desarrollar el sistema AAA de Wallarm
Wallarm utilizó ChatGPT para ayudar a clasificar las amenazas en un sistema AAA (autenticación, autorización y control de acceso). La autenticación es la primera línea de defensa. Al aislarlo, Wallarm puede centrarse en vulnerabilidades que explotan específicamente los fallos de autenticación.
Cuando la autorización se separa de la autenticación, ayuda a identificar casos en los que los sistemas otorgan permisos innecesarios. El control de acceso tiene en cuenta factores como el dispositivo, la dirección IP y la hora del día. Esto hace posible abordar las fallas en los mecanismos de aplicación.
“Podemos enfocar las API bancarias o la aplicación bancaria para verificar específicamente si un gerente puede hacer algo fuera de los privilegios de diseño”, dijo Novikov. “Y encontramos que con las aplicaciones empresariales es difícil eludir los controles de seguridad, los escáneres y todo lo demás que tienen.
“Sin embargo, es relativamente fácil cometer errores en el control de acceso porque el control de acceso a menudo se gestiona de forma sencilla; no es parte del código. Esto no solo nos permitirá marcar la casilla mientras ejecutamos algunas aplicaciones o API de cumplimiento y verificamos. El mal control de acceso es diferente: debes verificarlo por separado.
Enlace:
Fuente:
