Redacción. – Normalmente, pensamos que los riesgos de robos de información y datos bancarios se producen únicamente durante técnicas como el phishing o ransomware donde el usuario accede a páginas falsas y da su información o que la aplicación del banco es atacada. Pero antes de que eso suceda existen otros riesgos.
Estos peligros suelen esconderse en las etapas de desarrollo, despliegue y mantenimiento de los sistemas, exponiendo a las entidades financieras y a sus clientes a posibles amenazas, muchas de las cuales pasan desapercibidas incluso para técnicos y desarrolladores con experiencia.
Cómo son los ataques a apps bancarias durante su desarrollo
Cuando un usuario descarga una aplicación bancaria en su móvil, el recorrido previo del software involucra múltiples actores y etapas, lejos de la simple relación entre el banco y el cliente.
Desde la escritura del código fuente, la integración de librerías, hasta la automatización del despliegue, la cantidad de puntos susceptibles a intervención maliciosa aumenta de manera considerable. Esta complejidad amplía la superficie de ataque, es decir, el conjunto de elementos que pueden ser vulnerados por actores externos.
“Uno se imaginan la superficie de ataque es el dispositivo final. Pero resulta que es mucho más amplia y para que una aplicación llegue a tu dispositivo, alguien la construyó y hay gente que se dedica a vulnerar ese desarrollo”, contó Juan Carlos Cepeda – Principal Specialist Solution Architect para Red Hat.
Este fenómeno adopta formas que resultan difíciles de detectar mediante los controles convencionales. Un caso típico es la contaminación del software durante la fase de construcción.
El ‘producto final’ que parece funcional y seguro, puede incluir componentes o líneas de código introducidos maliciosamente en etapas previas. Esta manipulación puede ocurrir en elementos tan fundamentales como el código fuente o en las herramientas de automatización empleadas para compilar y desplegar el software.
Los riesgos en la automatización en el desarrollo de aplicaciones
La demanda de lanzar nuevas funcionalidades en lapsos muy cortos ha impulsado que la industria bancaria recurra a soluciones automatizadas. Los desarrolladores implementan scripts y robots software que aceleran tareas clave como la construcción, testeo y entrega de las aplicaciones.
Así se consigue reducir el time to market, la variable que mide la velocidad en poner un producto en manos de los usuarios.
No obstante, automatizar significa delegar tareas en sistemas programados que también pueden convertirse en blanco. Un simple error, o una manipulación en los scripts de despliegue, podría introducir vulnerabilidades aprovechables por los atacantes.
Puedes leer más: Cómo prepararse para los empleos relacionados con la IA que surgirán en la próxima década
Incluso cuando el código fuente principal parece inalterado, un script automatizado malicioso es capaz de añadir código peligroso justo antes del lanzamiento de la versión definitiva, sin que los controles tradicionales lo detecten.
“El script automatizado podía inyectar código, y no quedaba visible en el análisis del código fuente original”, aseguró Cepeda.
Estos riesgos implican que la seguridad no debe entenderse solo como una defensa en la etapa de producción, sino desde la misma construcción del software.
La cadena de suministros digitales abarca todo el ciclo de vida del producto: desde los cimientos tecnológicos hasta los módulos externos y librerías integradas, especialmente aquellas provenientes de comunidades de código abierto.
Cómo es posible crear apps bancarias seguras
Proteger una aplicación bancaria requiere de un enfoque integral, con medidas en todas las etapas del ciclo de desarrollo. Robert Calva, Ecosystem Solution Lead para Red Hat dio una comparación con la construcción de un edificio ejemplifica esta necesidad: los cimientos (el sistema operativo y las bases del software) deben resultar sólidos, pero también lo deben ser todas las capas superiores.
Los acabados y los cristales, que en el campo digital equivalen a las librerías o los plugins adicionales, pueden convertirse en un punto de fallo. Un error aparentemente menor, como la inclusión de un módulo defectuoso o malicioso, puede poner en peligro a toda la estructura.
El monitoreo constante y la administración post-lanzamiento cobran así una importancia crítica. Las entidades bancarias y sus aliados deben implementar sistemas de validación que permitan verificar que el producto final coincide exactamente con el que se sometió originalmente a revisión y verificación.
Es aquí donde entran en juego conceptos como la firma digital de objetos de software, práctica destinada a asegurar que las aplicaciones no han sido alteradas ni contaminadas en el proceso de construcción o distribución.
