Google MASA: ¿Qué requisitos de seguridad deben cumplir las apps?

Desde los albores de la civilización, el ser humano ha deseado estandarizar los grandes avances tecnológicos que ha ido generando. El Imperio Romano extendió su forma de construir calzadas, puentes o acueductos por todos los territorios que fue conquistando. Logrando que la infraestructura de todo el imperio fuese estándar. Las fábricas de la Revolución Industrial siguieron patrones análogos en todo el mundo. Y, al fin y al cabo, cuestiones como el código de circulación de los vehículos son prácticamente iguales en todo el planeta. En uno de los ámbitos más importantes de la actualidad: la ciberseguridad, también se apuesta por la estandarización como garantía para implementar pruebas y requisitos de seguridad similares a nivel global. Precisamente, ese es el objetivo de OWASP y, también, el de Google MASA, un aparatado específico de móviles que forma parte de la iniciativa App Defense Alliance.

Hoy en día existen miles de aplicaciones móviles. De hecho, a través de las apps podemos realizar cientos de acciones de nuestra vida cotidiana. Esto se traduce, también, en que existe una ingente cantidad de compañías desarrollándolas, desde cualquier parte del planeta y formando parte de los más variados sectores económicos. Esta diversidad, tan valiosa para los usuarios y para las empresas, supone un desafío en lo que respecta a la seguridad del ecosistema de aplicaciones. ¿Cómo se pueden evaluar apps tan diferentes entre sí? ¿Qué requisitos de seguridad se establecen? En una economía global, ¿quién determina cuáles son los protocolos y procedimientos a seguir?

Para afrontar la diversidad del ecosistema de aplicaciones con éxito, hace falta recurrir a nuestra vieja aliada: la estandarización. Por ello, la fundación OWASP recopila buenas prácticas en ciberseguridad de todo el mundo y publica materiales, guías y metodologías que se han convertido en un estándar empleado y aceptado en todo el planeta.

1. MASA, el framework que engloba las Ms de seguridad para apps móviles

Tal es la relevancia de la metodología OWASP en el sector de la ciberseguridad, que Google se ha acogido a ella para poner en marcha una iniciativa de gran calado en lo que respecta a la protección de las aplicaciones móviles: MASA.

1.1. Framework Google MASA: Protegerse y generar confianza

El Mobile Application Security Assessment (MASA) es un proyecto que busca, como su propio nombre indica, fomentar la evaluación de seguridad de las aplicaciones móviles. Para ser más concretos, de las apps que están disponibles para todos los usuarios en la Play Store. Así, los desarrolladores que sometan sus apps a dichas evaluaciones, obtendrán:

• Una panorámica amplia de su nivel de protección, implementando las modificaciones necesarias para subsanar las vulnerabilidades encontradas durante el testeo.
• Una insignia que figurará en la Play Store para que los usuarios sepan que la aplicación está protegida.

¿En qué consisten estas evaluaciones de seguridad? ¿Quién las ha de realizar? Aquí es donde entran en juego dos documentos fundamentales generados por OWASP: MASVS y MSTG.

1.2. MASVS: Niveles y controles de seguridad que deben cumplir las apps

El OWASP Mobile Application Security Verification Standard (MASVS) recopila, sistematiza y estandariza los requisitos de seguridad que deben cumplir las aplicaciones móviles para protegerse frente a ataques maliciosos y la explotación de vulnerabilidades. Para ello, MASVS pone en marcha un sistema que conjuga dos elementos: niveles y controles de seguridad.

La propuesta de OWASP contempla dos niveles de seguridad. El primero (L1) es recomendable para todas las aplicaciones del mercado. El segundo (L2) debería ser cumplido por aplicaciones que manejan datos sensibles, como las apps bancarias.

Por otra parte, establece una serie de requerimientos agrupados en siete grandes categorías. De tal manera que, en función del nivel de seguridad escogido, se deberán cumplir solo los requerimientos L1 o, a mayores, también los que están pensados para el L2 y que son más exigentes o específicos.

1.3. MSTG: Testear para comprobar

Pero el trabajo de OWASP no se limita a estipular una serie de controles de seguridad, exigibles en cualquier tipo de aplicación, sin importar su procedencia o características. Sino que cuenta con una guía para estandarizar cómo se deben ejecutar las pruebas para comprobar si las apps cumplen o no con los requisitos de seguridad de MASVS.

Este documento es el Mobile Security Testing Guide (MSTG). Una herramienta de trabajo de primer nivel empleada por analistas de ciberseguridad de todo el mundo. El MSTG estipula con precisión qué procedimientos se deben llevar a cabo para realizar cada prueba y ofrece soluciones técnicas para facilitar el trabajo de los profesionales.

Al ser reconocido como un estándar de facto, el MSTG garantiza que las pruebas de seguridad sean homogéneas, las realice quien las realice y sea cual sea la aplicación sometida al testeo.

De tal manera que el MASVS establece los requerimientos de seguridad e indica qué prueba hay que realizar para comprobar cada requerimiento.

Mientras que el MSTG desarrolla los procedimientos que se deben poner en marcha para realizar cada una de las pruebas con éxito. A partir de ahí, será el turno de los analistas y las compañías que prestan servicios de ciberseguridad. Estos deberán contar con el conocimiento, la pericia técnica y la experiencia necesarios para efectuar los testeos con éxito.

2. Los requisitos exigidos en la última versión de Google MASA

Originalmente, Google MASA hacía referencia a que las evaluaciones de las apps que se sumaran al proyecto debían comprobar los requerimientos que el MASVS estipula para el nivel 1 de seguridad.

Sin embargo, en la última versión de la iniciativa, que ha visto la luz en el mes de julio, se ha procedido a eliminar los requerimientos de la categoría uno de MASVS: Requisitos de arquitectura, diseño y modelado de amenazas.

Además, cabe precisar que Google MASA no exige todos los requisitos de seguridad de nivel 1, sino que algunos de ellos no forman parte de las especificaciones planteadas por MASA. Por ello, es importante detallar con precisión cuáles son los 32 requisitos que deben cumplir las aplicaciones móviles si quieren acogerse a Google MASA.

A continuación, vamos a abordar estos requerimientos y las pruebas asociadas a ellos, dividiéndolos en las seis categorías de MASVS relevantes en lo que respecta a la evaluación requerida por Google.

2.1. Almacenamiento de datos y privacidad

Uno de los aspectos más importantes en lo que concierne a la seguridad de las aplicaciones móviles es el almacenamiento y la protección de datos sensibles de los usuarios y negocios. Puesto que:

• Los datos sensibles que figuran en una app, pueden exponerse a otra que se ejecuta en el mismo dispositivo.
• Los datos se pueden filtrar en la nube, las copias de seguridad o la caché del teclado.
• Los dispositivos móviles se pueden perder y sustraer, facilitando el acceso físico a los datos.

Por ello, es necesario realizar una serie de controles que aseguran la información sensible. De los ocho requisitos recogidos en MASVS para el nivel 1 de seguridad, Google MASA exige cumplir con los seis siguientes:

1. Las funcionalidades de almacenamiento de credenciales del sistema deben de ser utilizadas para almacenar información sensible. Entre ésta, OWASP destaca la información personal, las credenciales de usuario o las claves criptográficas.
2. No se debe almacenar información sensible fuera del contenedor de la aplicación.
3. No se escribe información sensible en los registros de la aplicación.
4. Se desactiva la caché del teclado en los campos de texto que contienen información sensible.
5. No se expone información sensible a través de la interfaz de usuario. Esta información incluye datos tan importantes como contraseñas o números de tarjetas de crédito.
6. La aplicación ofrece al usuario toda la información sobre los datos personales que procesa y las mejores prácticas en seguridad que debería seguir el usuario al emplearla.

2.2. Criptografía

La criptografía es un elemento central en el desarrollo de aplicaciones y, también, en su seguridad. Por ello, es crucial que los desarrolladores sigan escrupulosamente las convenciones criptográficas estándar, así como las mejores prácticas a nivel global, prestando especial atención a tres cuestiones básicas:

• Empleo de librerías criptográficas seguras y contrastadamente probadas.
• Elección y configuración apropiadas de primitivas criptográficas.
• Uso de generadores de números aleatorios seguros.

Para comprobar dichas cuestiones, MASVS establece seis requisitos de seguridad, aplicables tanto al nivel 1 como al nivel 2 y que Google MASA también exige en su totalidad:

1. La app no depende, exclusivamente, de criptografía simétrica, cuyas claves están presentes en el código fuente de la aplicación.
2. Se emplean primitivas criptográficas sobradamente probadas.
3. Las primitivas criptográficas que se usan son las apropiadas para el caso de uso particular de la app. Además, su configuración se ha llevado a cabo siguiendo las mejores buenas prácticas en la materia.
4. No se emplean protocolos o algoritmos criptográficos considerados obsoletos en materia de seguridad.
5. No se reutiliza una misma clave criptográfica para múltiples propósitos.
6. Se emplea un generador de números aleatorios seguro para generar valores aleatorios.

2.3. Autenticación y manejo de sesiones

Los expertos a cargo de realizar el MASVS sostienen que una parte vital de la arquitectura global de las apps móviles radica en que los usuarios deban iniciar sesión en un servicio remoto. Y, si bien, esto se centra en el servidor, es importante fijar unos requerimientos focalizados en cómo se deben manejar las cuentas y sesiones de cada usuario.

De los ocho controles exigibles para las aplicaciones que se sometan a una evaluación de nivel 1, Google MASA incluye los seis primeros:

1. Autenticación para servicios en remoto. Lo cual implica que se ponga en marcha un mecanismo de autenticación incluyendo usuario y contraseña en el servidor remoto.
2. En caso de que se emplee gestión de sesión por estado, el servidor remoto debe emplear identificadores de sesión generados aleatoriamente, para autenticar las solicitudes de los clientes sin enviar credenciales a los usuarios.
3. Si se usa la autenticación basada en tokens sin estado, el servidor remoto debe proporcionar un token que haya sido firmado empleando un algoritmo seguro.
4. En el momento en el que el usuario cierra la sesión, ésta también concluye en el servidor.
5. Se ha establecido una política de contraseñas y se aplica en el servidor o punto final remoto.
6. El servidor pone en marcha un mecanismo de protección en el caso de que se ingresen credenciales de autenticación en una cantidad excesiva.
7. Las sesiones se invalidan en el servidor, después de que se produzca un período predefinido de actividad. Asimismo, los tokens de acceso también expiran tras este plazo de tiempo.

2.4. Comunicación a través de la red

Un aspecto importante a la hora de comprobar el nivel de seguridad de una aplicación es la comunicación que se establece entre ésta y los servicios del servidor. De tal manera que es indispensable garantizar la confidencialidad e integridad de los datos intercambiados. Para ello, la versión 1.4.2. de MASVS establece que, como mínimo, se deben utilizar canales seguros y cifrados, empleando el protocolo TLS, de acuerdo a las configuraciones apropiadas. Esto se traduce en tres requisitos básicos que deben cumplir todas las aplicaciones sometidas a una verificación de nivel 1:

1. La información se envía, de forma cifrada, utilizando el protocolo TLS. Y el canal seguro es usado consistentemente en la app móvil.
2. Las configuraciones del protocolo TLS van en consonancia con las mejores prácticas del sector. En caso de que el sistema operativo del dispositivo móvil no soporte los estándares recomendados, se siguen dichas prácticas de la mejor manera posible.
3. La aplicación verifica el certificado X.509 del punto final remoto, al establecer el canal seguro. Además, solo se aceptan certificados firmados por una autoridad de certificación (CA) de confianza.

2.5. Interacción con la plataforma

Esta categoría de requisitos de MASVS se centra en comprobar que se emplean las APIs de la plataforma y los componentes estándar de forma segura. A mayores, los cuatro requisitos exigidos por Google MASA ponen el foco de atención en cómo se efectúa la comunicación entre apps: inter-process communication (IPC). Cabe señalar, así mismo, que MASVS incluye otros cuatro requisitos necesarios para el nivel 1, a mayores de los que vamos a señalar a continuación:

1. La app requiere la cantidad de permisos mínimamente necesaria.
2. Todos los inputs que provienen tanto del usuario como de una fuente externa son debidamente validados y, de ser necesario, saneados. Ello incluye la información recibida a través de mecanismos IPC como los Intents, las URLs y los datos provenientes de la red.
3. Ninguna funcionalidad sensible es expuesta a través de esquemas de URL. Y si lo hace es porque dicho mecanismo está protegido con garantías.
4. No se expone ninguna funcionalidad sensible a través de mecanismos IPC. A no ser, como en el caso anterior, que estos mecanismos ofrezcan las suficientes garantías de seguridad.

2.6. Calidad de código y configuración del compilador

La última categoría de MASVS que incluye requisitos para el nivel 1 de seguridad gira en torno a la calidad del código y la configuración del compilador. Mediante estos controles, OWASP busca fomentar que los evaluadores se aseguren de que las prácticas de seguridad básicas se llevaron a cabo a la hora de desarrollar la aplicación. Y que, además, se han activado las funcionalidades ofrecidas por el compilador. Esto se traduce en nueve requerimientos, aplicables tanto al nivel 1 como al nivel 2. Si bien, Google MASA solo exige el cumplimiento de los cinco primeros y el último:

1. La aplicación es firmada y cuenta con un certificado válido, cuya clave privada está protegida de manera óptima.
2. La app fue publicada en modo release y con las configuraciones adecuadas.
3. Los símbolos de depuración han sido eliminados de los binarios nativos.
4. Los códigos de depuración o de asistencia al desarrollador tienen que ser eliminados. Por ejemplo, código de test, backdoors o configuraciones ocultas. Además, la aplicación no debe hacer logs detallados de errores ni de mensajes de depuración.
5. Los componentes de terceros han sido identificados y revisados, teniendo en cuenta las vulnerabilidades conocidas.
6. Las funcionalidades de seguridad gratuitas de las herramientas están activadas. Algunas de estas funcionalidades son la byte-code minification, la protección de la pila o el conteo automático de referencias.

3. Un sistema integral de verificación de la seguridad de las apps

Si bien la clave del sistema estándar de verificación de OWASP radica en la relación entre los requisitos de seguridad de MASVS y las pruebas o test asociadas a cada uno de ellos que figuran en MSTG; ambos documentos incluyen más información de gran ayuda para analistas, compañías de servicios de ciberseguridad y desarrolladores de apps móviles.

Así, MASVS, al final de cada categoría de requerimientos aporta un apartado de información en que se vinculan estos requisitos con el top 10 de OWASP sobre riesgos de aplicaciones móviles y con las principales vulnerabilidades (CWE) conocidas en estos ámbitos. Esto contribuye a dotar a toda la metodología OWASP de coherencia y cohesión y contribuye a que los analistas desenvuelvan sus actividades en un marco de trabajo estandarizado y común.

Por su parte, MSTG, además de contextualizar y explicar múltiples pruebas o test que permiten verificar el cumplimiento o no de los requisitos, aporta soluciones técnicas y consejos metodológicos. Asimismo, al final de esta detallada guía, el equipo de OWASP facilita a los analistas una serie de herramientas de testeo, de cara a facilitar el proceso de evaluación de los requisitos.

4. ¿Qué pasa si las aplicaciones no cumplen los requisitos de Google MASA?

Si una vez que el laboratorio autorizado realiza la evaluación, detecta requisitos que no se cumplen, el desarrollador deberá llevar a cabo las acciones necesarias para corregir los problemas o insuficiencias de seguridad encontrados.

En esta labor, contará con el informe emitido por los evaluadores. Dicho documento deberá incluir comentarios de evaluación y proporcionar los pasos a seguir para subsanar las vulnerabilidades detectadas. Una vez que estas acciones se hayan completado con éxito y la app cumpla con los requisitos, el laboratorio enviará un informe de validación directamente a Google, para que ésta emita la insignia de Google MASA.

De ahí que sea imprescindible que la compañía que realice el proceso de evaluación de la seguridad de la app, tenga tras de sí un amplio bagaje en el terreno de la ciberseguridad y la ciberinteligencia. Puesto que no solo tiene que realizar las pruebas, sino que tiene que contar con los conocimientos necesarios como para realizar recomendaciones que se ajusten a los problemas detectados y las características de la aplicación móvil estudiada.

En definitiva, el framework Google MASA se apoya en la metodología de OWASP para extender por todo el ecosistema de aplicaciones móviles unos requisitos de seguridad estándar.

Para ello, las apps deben someterse a evaluaciones independientes en las que, a través de las pruebas incluidas en el MSTG de OWASP, se comprueba si las aplicaciones móviles cumplen con los requisitos de seguridad básicos incluidos en MASVS. El objetivo final es salvaguardar la información que empresas y personas les confían y proteger a los negocios y la intimidad de los usuarios.