Un informe trimestral publicado por la plataforma integrada de aplicaciones y seguridad brazo de pared presta atención detallada a una preocupación de seguridad crítica y poco debatida para las fintech: sus API. Los informes se desarrollan a partir de fuentes disponibles públicamente.
Cofundador y director ejecutivo de Wallarm Iván Nóvikov Dijo que su objetivo para los informes es estimar el alcance de las amenazas y agruparlas en secciones sensibles. 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 el enfoque produce análisis en tiempo real con mejores conocimientos que otros informes publicados con menos frecuencia. También identifica algunos grupos de amenazas nuevos que probablemente puedan atribuirse a la proliferación del uso de API.
Las fugas de API son una amenaza emergente
Las inyecciones fueron, con diferencia, el principal 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. Han afectado 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 y una afecta específicamente a las fintech: las API abiertas para banca. Novikov dijo que las instituciones están interesadas en dos cosas, la primera es rastrear adónde viajan sus datos financieros. Esto incluye información de identificación personal e información de cuentas bancarias internas. Necesitan saber si se desvía a algún lugar donde no debería.
"Si observa que los números de cuentas bancarias internas están conectados como un número de ruta, (los delincuentes) pueden hacer muchas cosas", dijo Novikov. “Pueden ejecutar esquemas de fraude completamente diferentes. Si recuerdas las películas con James Bond, dicen: 'Sé tu número de cuenta en Suiza', es exactamente lo mismo”.
Estos datos podrían ser acceso privado hablando con su API. Podrían ser certificados que usted emitió a un banco asociado que fueron 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 muchas opciones 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 creando 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 agrava el desafío. En el caso de los más antiguos, es más difícil encontrar quién definió la clave. Está en algún lugar del código. Novikov ha visto ejemplos en COBOL que se remontan a 1998.
"Está en algún lugar del código y se puede extraer de allí", dijo Novikov. “Es una clave codificada que alguien puso allí. Conéctese con XML y estará listo. Y ahora le ponemos una elegante puerta de enlace API encima y la llamamos banca abierta. Está abierto, pero está abierto desde una perspectiva diferente. Está muy, muy lleno de agujeros”.
Monitoriza a tus socios
Dado el considerable riesgo, corresponde a las instituciones financieras asegurarse de que puedan confiar en sus socios. Novikov dijo que hay más comodidad para los bancos, que 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. Comparta una clave con un facilitador de fintech y él será responsable de ella.
"Como fintech, no están regulados como un banco", dijo Novikov. “Deberían hacerlo por sí mismos. En este caso, dependen (de los bancos) y deberían confiar en sí mismos. Ese es un gran problema porque si quiero conectar mi Robinhood con mi banco, no tengo otra opción”.
Sin un estándar industrial, las fintechs pueden decidir cuánta seguridad emplear. Y cuando todo su negocio se reduce a las API, es mejor que la seguridad sea buena.
Vicepresidente de mercadotecnia
Bhat Girish 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 capacidad de remediación al trabajar con otras herramientas en un ecosistema fintech.
"Se están realizando miles de millones de llamadas API", dijo Bhat. "Podemos analizar eso en tiempo real y brindar la capacidad proactiva para mitigarlos".
Las credenciales débiles y los problemas de criptografía son un entrante sorprendente en la lista de los 10 problemas principales. Novikov dijo que muchas empresas utilizan claves estándar y predeterminadas.
"Es obvio para todos que no se deben utilizar claves estándar o predeterminadas, pero esto sigue sucediendo cada vez más", afirmó. "Desafortunadamente, todavía no podemos deshacernos de esto como industria por alguna razón".
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 las vulnerabilidades que explotan específicamente las lagunas de autenticación.
Cuando la autorización se separa de la autenticación, ayuda a identificar cuándo los sistemas otorgan permisos innecesarios. El control de acceso considera factores como el dispositivo, la dirección IP y la hora del día. Ayuda a identificar fallas en los mecanismos de aplicación.
"Podemos enfocar las API del banco 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 estamos viendo que con las aplicaciones empresariales es difícil eludir los controles de seguridad, los escáneres y todo lo que tengan.
“Sin embargo, es relativamente fácil cometer algunos errores en los controles de acceso porque a menudo el control de acceso simplemente se gestiona; no es parte del código. Nos permitirá no solo hacer clic en la casilla de verificación mientras ejecutamos algunas aplicaciones o API de cumplimiento y verificamos. Un mal control de acceso es diferente: debes verificarlo por separado”.
