Qué miden de verdad MASVS y MASTG

Una petición recurrente en la compra de seguridad móvil es una nota única para una aplicación: una letra, un porcentaje, algo que quepa en una diapositiva. Los estándares móviles de OWASP parecen dar exactamente eso, y con frecuencia se presentan como si lo dieran.

No lo dan, y la distancia entre lo que miden y lo que se supone que miden es suficiente para producir la decisión equivocada.

Dos documentos, dos trabajos

MASVS —Mobile Application Security Verification Standard— es una lista de requisitos de seguridad agrupados por categorías. Describe qué debería hacer una aplicación bien construida: cifrar lo que almacena, validar lo que recibe, resistir la manipulación.

MASTG —Mobile Application Security Testing Guide— es el manual de procedimiento. Para cada requisito establece cómo verificarlo: qué buscar, con qué herramienta y qué constituye evidencia.

MASVS enuncia el requisito. MASTG enuncia cómo se demuestra el cumplimiento. Una auditoría que cita MASVS sin MASTG ha enunciado una conclusión sin el método que la produjo.

La prueba práctica de esa distinción es la reproducibilidad. Un hallazgo registrado como «incumple MASVS-NETWORK» no lo puede verificar un tercero. Un hallazgo registrado como «incumple MASVS-NETWORK: networkSecurityConfig permite tráfico en claro hacia api.ejemplo.com, observado en el manifiesto fusionado de la build 4.2.1, SHA-256 …» se puede reproducir, discutir y confirmar como corregido.

Las ocho categorías

MASVS organiza los requisitos en ocho grupos:

Droidwatch asigna cada hallazgo a su categoría y produce una puntuación por categoría de 0 a 100, más una nota en letra. Las penalizaciones se ponderan por severidad: un hallazgo crítico resta 40 puntos a su categoría, uno alto 25, uno medio 10 y uno bajo 3. Los informativos no restan.

Conviene recorrer la aritmética una vez, porque determina cómo debe leerse una nota. Una categoría con un hallazgo crítico puntúa 60. Una categoría con cuatro hallazgos medios también puntúa 60. No son problemas equivalentes: el primero es un defecto único que probablemente tiene una única corrección, el segundo es un patrón. Una nota comprime esa diferencia hasta borrarla, y por eso la puntuación de categoría va junto a la lista de hallazgos y no en su lugar.

Atención a la dirección de la escala, porque invierte la del otro número del mismo informe. La puntuación MASVS va de 0 a 100 donde más alto es mejor. La puntuación de riesgo va de 0 a 100 donde más alto es peor. Dos números, el mismo rango, significado opuesto: confundirlos en un informe es un error frecuente y caro.

La limitación que importa

Ésta es la frase que debería acompañar a toda nota MASVS, y que Droidwatch incrusta en los propios datos del boletín y no sólo en la interfaz:

MASVS mide controles de seguridad, no intenciones. Una aplicación maliciosa bien construida puede puntuar alto.

No es una advertencia por prudencia. Se deduce directamente de lo que pide el estándar. Piensa en un troyano bancario que fija sus certificados, cifra su base de datos local con una clave guardada en el Keystore de Android, ofusca sus propias cadenas y detecta dispositivos rooteados.

Frente a MASVS esa aplicación es ejemplar. Implementa la seguridad de transporte correctamente, maneja el almacenamiento correctamente y satisface los requisitos de resiliencia mejor que la mayoría de aplicaciones legítimas, porque su autor tiene un interés operativo directo en resistir el análisis.

Su propósito es superponerse a la pantalla de acceso de un banco y reenviar las credenciales interceptadas. MASVS nunca se diseñó para notarlo.

El error inverso también está disponible. Una aplicación de banca minorista legítima que guarda un token de sesión en preferencias legibles por cualquiera y permite tráfico en claro hacia un endpoint de registro producirá un veredicto de riesgo benigno, porque nada en ella es hostil. Tampoco es segura para publicar. Ninguno de los dos números está mal; cada uno responde a una pregunta que no se le hizo al otro.

Dónde encaja cada número

La consecuencia práctica es que un informe de seguridad móvil necesita los dos números, usados para preguntas distintas.

El veredicto de riesgo responde a: ¿es hostil esta aplicación? Se apoya en señales de comportamiento —capacidad de superposición combinada con abuso de accesibilidad, intercepción de SMS, patrones de dropper, infraestructura de mando y control— y en reputación y coincidencias de reglas.

La nota MASVS responde a: ¿está bien construida esta aplicación? Es el instrumento correcto para una aplicación propia que va a publicarse, o para un componente de terceros que entra en la cadena de suministro.

Hacerle la primera pregunta a una nota MASVS produce el troyano descrito arriba: malware con sobresaliente. Hacerle la segunda a un veredicto de riesgo produce un veredicto benigno sobre una aplicación que no debería pasar la revisión.

La ausencia de evidencia

Hay una distinción más que cambia cómo debe leerse un boletín.

Una categoría sin hallazgos no es una categoría aprobada. Puede ser una categoría que nunca se evaluó, porque el análisis correspondiente no se ejecutó, porque la aplicación no ejercita esa superficie, o porque la evidencia necesaria vive detrás de una ejecución que el análisis no tuvo.

Este último caso es el habitual, y es estructural, no accidental. MASVS-RESILIENCE pregunta si una aplicación detecta manipulación y cómo responde; establecer la respuesta suele exigir ejecutarla bajo un depurador. MASVS-AUTH pregunta por la gestión de sesión, buena parte de la cual es comportamiento de servidor que un paquete no puede revelar. Un análisis estático de un .ipa —que es todo lo disponible en iOS, a lo largo de sus siete módulos— dejará más categorías sin evaluar que un análisis de Android que pueda acompañarse de instrumentación.

Droidwatch marca esas categorías como sin_evaluar en lugar de puntuarlas, e informa de cuántas de las ocho se evaluaron realmente. Un boletín con seis de ocho sin evaluar es un documento distinto de uno con ocho de ocho aprobadas, y confundir los dos es cómo «hicimos una evaluación MASVS» se convierte en una garantía que nadie verificó.

Es el mismo principio que gobierna el resto del informe: una herramienta forense tiene que distinguir miramos y no había nada de no miramos.

Cómo usarlo

Para una aplicación de terceros bajo sospecha, empieza por el veredicto y los hallazgos de comportamiento. Cita MASVS donde un incumplimiento concreto sostenga el caso: la transmisión de credenciales en claro, por ejemplo, es a la vez un fallo de MASVS-NETWORK y evidencia de intención cuando se combina con un endpoint de exfiltración.

Para una aplicación propia antes de publicar, empieza por MASVS. Recorre las categorías peor puntuadas y usa los procedimientos MASTG correspondientes para reproducir cada hallazgo antes de corregirlo. Un hallazgo que no se puede reproducir es un hallazgo que nadie puede confirmar que se ha arreglado.

Para una evaluación de cadena de suministro, lee los dos y trata las categorías sin evaluar como preguntas abiertas, no como aprobados. Es el contexto en el que más importa el recuento de categorías evaluadas, porque un componente se acepta con frecuencia por la fuerza de un boletín que nadie leyó más allá de la nota.

Para una puerta de publicación recurrente, las categorías MASVS son la medida estable y el veredicto de riesgo es el detector de anomalías. Las puntuaciones por categoría de una aplicación propia deberían moverse despacio y de forma previsible; una caída súbita en MASVS-CODE entre dos builds suele significar que cambió una dependencia. Automatizar esa comparación es para lo que sirve una puerta de pipeline.

Los dos números aparecen en el mismo informe, junto al mapeo MITRE ATT&CK Mobile y la evidencia a nivel de hallazgo. El recorrido del informe explica dónde está cada uno y cómo se organiza el resto del documento.

Para ver los dos números sobre una aplicación real, sube un APK. No se requiere método de pago.