lunes, 22 de febrero de 2016

Seguridad, un incómodo invitado. Lecciones de una aplicación móvil I


Hace unas semanas contaba que invitar tarde al personal de seguridad de informacion puede ser fatal para un proyecto. Continuo con la historia. El área de mercadeo de esta organización planeaba  lanzar la aplicación en un periodo de unos meses, tiempo corto dado los alcances esperados. Los tradicionales problemas de un proyecto que cambia sus alcances y objetivos no demoraron en aparecer. Pero la llegada tarde del personal de seguridad de información acervó el retraso en el desarrollo. 

El personal de seguridad carecía de experiencia en el manejo de aplicaciones móviles, pero si era un equipo curtido en auditorias de aplicaciones web tradicional.  Y empezaron con las preguntas tradicionales: ¿Qué tipo de datos se transmitirán al dispositivo móvil? ¿Es la comunicación entre el dispositivo móvil y el servicio web protegida con encripción? ¿Serán estos datos almacenados en el dispositivo móvil? ¿Cómo válida el servicio web al usuario? ¿La aplicación valida los datos que el usuario provee? ¿Hay alguna limpieza de los mensajes de error que el servicio web entrega? Todas estas simples preguntas de seguridad que se hacen durante el desarrollo de una aplicación. 

El personal de seguridad contaba con una ventaja y es que varias de esas preguntas hacen parte de la arquitectura de toda aplicación web que se aprueba. La paradoja de la situación fue que el desarrollo móvil no considero los mismos parámetros que se tienen para una aplicación tradicional. Y este parece ser un error común. A pesar de sus diferencias los delineamientos generales de seguridad en una aplicación web no son muy diferentes en una aplicación móvil. 

Todas estas preguntas en un estado avanzado de desarrollo empiezan a ser incómodas porque una respuesta que no se ajuste a los estándares de seguridad ocasiona retrasos en el desarrollo. 
Algunos de los cambios necesarios no eran complicados pero si vitales. Por ejemplo, tener todas las transacciones entre el dispositivo móvil y el servicio web vía HTTPS es un cambio menor que protege la confidencialidad de la información transmitida. Otros como la validación del dispositivo puede cambiar la arquitectura original. 

Usar el IMEI de un dispositivo para validar usuarios puede tener complicaciones de privacidad y más de una organización ha estado en líos por guardar esta información que permite identificar usuarios. Aun así no causaba mayor retraso deshabilitar la lectura y registro del IMEI (hoy Apple no permite el uso de este registro)

Sin embargo, el aspecto más problemático fue el almacenamiento de información en el dispositivo móvil. Un problema serio que enfrentan las aplicaciones móviles es la validación de usuarios cuando no hay acceso a la red, y validación local de usuario augura toda clase de problemas. Un bug de software, o peor acceso no autorizado, puede ser mortal para el buen nombre de una empresa. 

Una buena regla es que tu aplicación que terceros, clientes o socios comerciales, van a usar no  almacene datos en el dispositivo móvil.