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.

jueves, 4 de febrero de 2016

Gobierno electrónico en Latinoamérica II

En mi columna anterior hablaba como los nuevos medios han abaratado los costos de servicios que tradicionalmente requerian costosas capacidades de cómputo, y como los gobiernos podrian usar esta promesa para permitir mayor participación. 

Un aspecto importante para lograr un exitoso programa de gobierno electrónico es tener un mayor grado de interoperabilidad entre diversas organizaciones oficiales. Se considera que es la única manera de poder tener un solo punto de acceso a los servicios electrónicos oficiales. Una posible consecuencia es el ahorro a largo plazo en las inversiones tecnológicas necesarias si la interoperabilidad existe.

¿Pero qué significa que las organizaciones estén interconectadas? Para tal efecto se ha creado un índice o matriz de nivel de implementación o interoperabilidad, mejor conocido como GIMM, que está basado en las matrices de madurez. Esto incluye procesos comunes entre diferentes organizaciones, el uso común de codificación de documentos en lenguajes XML, etc.

Este proceso de unificación de criterios es largo y puede ser complicado. Un primer paso que algunos procesos exitosos han iniciado es tener un punto único de identificación y autenticación de usuarios. Tal es el caso de Chile y su programa de identificación electrónica única llamado Clave Única. Los chilenos han identificado claramente los lineamientos para lograr la interoperabilidad entre diferentes entidades oficiales. 

Otro caso de progreso en la zona es Colombia. Luego de varios años de estancamiento Colombia, el segundo país en la región, ha progresado rápidamente; pero el proceso no parece claro, las metas no están bien definidas y los indicadores de progreso no están disponibles en el sitio oficial.

El caso colombiano contrasta con el programa de gobierno electrónico de Chile. Colombia no posee aún un sitio único que permita al ciudadano validar sus credenciales y acceder a todos sus servicios. 
El primer paso para un caso exitoso es centralizar la coordinación entre institutiones y prestar las asesorías necesarias para guiar en la implementación exitosa del programa. No es sorprendente que Chile sea puntero en la región; el programa tiene unos objetivos bien delimitados y el progreso es transparente y la información está disponible para todos (ver http://www.modernizacion.gob.cl).

Pero a pesar de estos esfuerzos, la oferta latinoamericanca de gobierno electrónico aún no permite la participación activa de sus ciudadanos. Aun hay un buen trecho por recorrer.