El objetivo del presente documento es listar los criterios utilizados para la evaluación del producto “reporte de resultado de revisión de vulnerabilidades para Apps móviles ”, así como los criterios considerados para iniciar la evaluación. Se describen además los niveles de severidad que han de otorgárseles a los hallazgos detectados durante la evaluación del producto y las distintas conclusiones que pueden resultar de la evaluación de acuerdo a los criterios y severidades.
Severidad de criterios y hallazgos
La severidad se refiere al grado de impacto en la seguridad de la app que tiene la no satisfacción de un criterio de evaluación y los hallazgos identificados a partir de ese criterio de evaluación.
Los niveles de severidad que serán utilizados durante las evaluaciones para clasificar tanto a criterios como a hallazgos son los siguientes:
| Grado Severidad | Descripción | Recomendación |
|---|---|---|
| Crítica | Se refiere a aspectos imprescindibles que comprometan la seguridad confidencialidad de los datos de la app y que sean un factor clave para elevar el grado de riesgo. Por ejemplo, hallazgos con severidad crítica detectados en el análisis de vulnerabilidades y que no se encuentran cerrados, no se realizan los análisis incluyendo el Top 10 de vulnerabilidades la OWASP, no se cuenta con conexión segura, entre otros.También se consideran críticos, aquellos aspectos que sean necesarios para identificar la aplicación considerada en el análisis. Por ejemplo nombre de la aplicación y fecha en que se realizó el análisis. |
Es necesario realizar la corrección de los hallazgos y lograr el cumplimiento de los criterios de evaluación de severidad crítica antes de publicar la app en la plataforma gob.mx |
| Alta | Se refiere a aspectos informativos de la app que pueden afectar directamente a la seguridad de la misma o que puedan servir para identificar más claramente la naturaleza de los hallazgos. Por ejemplo, descripción del ambiente donde se realizaron los análisis de vulnerabilidades, omisiones de las descripciones de los hallazgos detectados así como su posible impacto en el sistema, etc. |
Se recomienda realizar las adecuaciones pertinentes para atender los hallazgos, de primera instancia no se identifica un riesgo mayor en la publicación de la app en la plataforma gob.mx |
| Media | Se refiere a aspectos informativos de los reportes de vulnerabilidades que no afecten de manera directa a la seguridad de la app, pero que son importantes para registrar de manera completa la calidad desde la perspectiva de seguridad. |
Se recomienda realizar las adecuaciones pertinentes para atender los hallazgos, de primera instancia no se identifica un riesgo mayor en la publicación de la app en la plataforma gob.mx
|
Criterio para iniciar evaluación
Para iniciar la evaluación completa de los productos de tipo “reporte de resultado de revisión de vulnerabilidades para Apps móviles”, es necesario que estos cuenten con la información mínima suficiente para evidenciar que el aplicativo del cual se describen los resultados de análisis de vulnerabilidades cubre el estándar de servicios digitales de gob.mx.
En caso de que no se encuentre dicha información en los productos entregados por las dependencias, no es posible realizar el análisis de manera completa y confiable.
La información necesaria es aquella que muestre los resultados del análisis para los aspectos críticos y determinantes referentes a los temas descritos a continuación:
Almacenamiento inseguro de datos
Se refiere al manejo inseguro de los datos almacenados dentro de la aplicación móvil incluyendo base de datos locales, archivos de log, cookies, almacenamiento en memoria SD, archivos XML, sincronización con la nube. Además a las filtraciones de dicha información.
Comunicación insegura
Este riesgo cubre todos los aspectos involucrados en transmisión de información de forma insegura. Incluye comunicaciones de móvil a móvil, comunicaciones de aplicación a servidor o comunicaciones de móvil a otro. Este riesgo incluye todas las tecnologías de comunicación que un dispositivo móvil podría utilizar, incluyendo problemas de comunicación en TLS, problemas de NFC, Bluetooth y WiFi. También cubre el uso incorrecto de criptografía o uso de protocolos antiguos o vulnerables.
Autenticación y autorización inseguras
Se refiere al manejo inseguro de la autenticación del usuario, o la falta de autenticación cuando debería realizarse, mal manejo de sesiones, o a no mantener la identidad del usuario cuando es requerido. Adicionalmente, también se refiere al manejo de las autorizaciones que se brindan al usuario por medio de la autenticación. Es importante reconocer la diferencia entre autenticación y autorización. La autenticación es el acto de identificar a un individuo. Autorización es el acto de comprobar que el individuo identificado tiene los permisos necesarios para realizar el acto. Los dos están estrechamente relacionados como verificaciones de autorización siempre debe seguir inmediatamente la autenticación de una solicitud entrante de un dispositivo móvil.
Baja calidad del código
Se refiere a riesgos o problemas de seguridad en implementación a nivel de código en el cliente móvil. Son los riesgos que provienen de vulnerabilidades como desbordamientos de búfer, vulnerabilidades de cadena de formato y varios otros errores de nivel de código donde la solución es reescribir algún código que se esté ejecutando en el dispositivo móvil.
Los criterios considerados para evaluar cada uno de los temas descritos, se encuentran listados y marcados como críticos en la sección “Criterios de evaluación” de este documento.
Criterios de evaluación
Para evaluar la completitud y calidad de los productos, se realizará verificación estática basada en una lista de verificación que contiene los criterios de evaluación tanto generales como técnicos.
Criterios generales de evaluación
Se refiere a aquellos puntos que han de ser evaluados en el producto pero que no buscan inspeccionar a detalle los resultados reflejados en el reporte proporcionado por la dependencia, sino realizar un reconocimiento del producto, contemplan aspectos de identificación de aplicaciones, dependencias, herramientas utilizadas y secciones del reporte motivo de la evaluación.
Los criterios generales de evaluación del producto, así como su severidad, se listan a continuación:
| ID | Descripción | Nivel de interacción |
|---|---|---|
| 1 | Se identifica el nombre de la Aplicación. | Crítica |
| 2 | Se identifica la dependencia de gobierno a la que pertenece el sistema | Media |
| 3 | Se contemplan análisis dinámico y estático de vulnerabilidades | Crítica |
| 4 | Se incluye en el reporte al menos un ciclo previo y el ciclo de revisión posterior a la corrección de los hallazgos |
Crítica |
| 5 | Se resume el resultado de las revisiones realizadas | Alta |
| 6 | Se identifican las fechas en que fue realizado el análisis de vulnerabilidades | Crítica |
| 7 | Se describe el objetivo de la revisión / ciclo | Media |
| 8 | Se identifica el tipo y versión de los sistemas operativos que soporta la aplicación móvil. | Alta |
| 9 | Se describe la variedad de los diferentes dispositivos móviles que tiene como alcance la aplicación. | Media |
| 10 | Se describe la tecnología y framework con la que fue creada la solución móvil. Incluyen información de la aplicación y de los servicios web. |
Media |
Criterios técnicos de evaluación
Se refiere a aquellos puntos que han de ser evaluados en el producto que buscan inspeccionar a detalle los resultados reflejados en el reporte proporcionado por la dependencia, a fin de identificar si la app que ha sido analizada en busca de vulnerabilidades cumple con los requerimientos necesarios para su publicación en el portal gob.mx
Los criterios técnicos de evaluación del producto, así como su severidad, se listan a continuación:
| ID | Descripción | Nivel de interacción |
|---|---|---|
| 8 | Todos los hallazgos contenidos en los reportes de análisis de vulnerabilidades con severidad Crítica se encuentran corregidos o existe justificación para su no corrección. |
Crítica |
| 9 | En el listado de reglas de seguridad para el análisis dinámico, se considera la validación de las vulnerabilidades más críticas que afectan a una aplicación Móvil definido en el TOP 10 de la OWASP:
|
Crítica |
| 10 | Se identifican los resultados de las técnicas de inyección de código SQL y no se presenta riesgo de inyección. Todos los campos de entrada de la app y los servicios web se encuentran validados a caracteres especiales. Las evidencias mostradas hacen referencia a la aplicación móvil y también a los servicios API. |
Crítica |
| 11 | Se muestra evidencia que la aplicación móvil a la que se le hicieron los análisis no sea una versión de prueba y tiene un certificado válido. |
Crítica |
| 12 | Se valida que la aplicación móvil tras varios intentos fallidos con datos incorrectos en el login, este se bloquea temporalmente, evitando ataques por medio de fuerza bruta. |
Alta |
| 13 | Se muestra evidencia que la aplicación no permite copiar y pegar en campos que contengan o manejen información sensible. Por ejemplo: Datos de usuarios contraseñas, cuentas bancarias etc. |
Alta |
| 14 | Se especifica o se aprecia que la aplicación no almacena información sensible del usuario como nombre deusuario y contraseñas en los registros de la aplicación o que la información almacenada localmente en el dispositivo esta protegida. |
Crítica |
| 15 | Se informa el tipo de encriptación que tienen los datos sensibles al ser guardados en localmente en el dispositivos. La encriptación utilizada no es una encriptación débil, como: MD5 o SHA1 |
Alta |
| 16 | Se especifica si al salir de la aplicación o al cerrarla no se quede activa la sesión del usuario. | Alta |
| 17 | Se valida que para la comunicación se utiliza en la aplicación el protocolo TLS actual disponible. | Alta |
| 18 | Se describen los resultados del análisis de comunicaciones entre la aplicación móvil y el backend. La información enviada viene protegida. |
|
| 19 | Se evidencia que al momento en que se está instalando la aplicación, esta debe mostrar que permisos requiere por parte del usuario para acceder a mas funcionalidades del dispositivo como: cámara, GPS, almacenamiento int. y ext, etc. |
Media |
| 20 | Los datos sensibles como contraseñas se ocultan con otros símbolos cuando se escriben de modo que no son visibles | Media |
| 21 | Se identifica la versión del código evaluado. | Alta |
| 22 | En el listado de reglas de seguridad estática se encuentran clasificadas por:
|
Alta |
| 23 | Se identifica la cantidad de líneas de código evaluadas. | Alta |
| 24 | La cantidad de líneas de código están catalogadas por tecnología. | Alta |
| 25 | Se describen las tecnologías con que fue desarrollada la aplicación. | Alta |
| 26 | Se describen cantidad de archivos evaluados durante el análisis de vulnerabilidades estáticas | Alta |
| 27 | Se tienen todos los componentes de la aplicación identificados, tanto de terceros (frameworks, librerías), como propios, y se tienen identificadas las vulnerabilidades conocidas para estos componentes. |
Alta |