El objetivo del presente documento es listar los criterios utilizados para la evaluación del producto “reporte de resultado de revisión de vulnerabilidades”, entregado por las instituciones a la Secretaría de la Función Pública, 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 del aplicativo y/o trámite 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 y confidencialidad de los datos de la aplicación/sistema 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 |
Se recomienda realizar las adecuaciones pertinentes para atender los hallazgos, de primera instancia no se identifica un riesgo mayor en la publicación del trámite/aplicación en la plataforma gob.mx |
| Alta | Se refiere a aspectos informativos de la aplicación que pueden afectar directamente al rendimiento del sistema / aplicación o que puedan servir para identificar más claramente la naturaleza de los hallazgos. Por ejemplo, descripción de los objetivos, acuerdos de los niveles servicios, 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 del trámite/aplicación 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 del sistema / aplicación, pero que son importantes para registrar de manera completa la calidad del sistema /aplicación desde la perspectiva de seguridad. Por ejemplo, el objetivo de la revisión/ciclo de análisis, descripción |
Se recomienda realizar las adecuaciones pertinentes para atender los hallazgos, de primera instancia no se identifica un riesgo mayor en la publicación del trámite/aplicación en la plataforma gob.m |
Criterios para iniciar evaluación
Para iniciar la evaluación completa de los productos de tipo “reporte de resultado de revisión de vulnerabilidades” entregado por las dependencias a La Secretaría de la Función Pública, 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 a La Secretaría de la Función Pública, 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:
Puertos Abiertos
Los puertos abiertos en los equipos de cómputo, servidores o instancias virtuales donde se aloja el aplicativo representan una vulnerabilidad crítica, debido a que estos pueden ser aprovechadas por un usuario mal intencionado para acceder al aplicativo. Los puertos que estén abiertos deben ser únicamente los que la aplicación necesita y con las medidas de seguridad pertinentes que hacen más segura la aplicación.
Cross-site Scripting (XSS)
Es un tipo de vulnerabilidad informática o agujero de seguridad detectado en las aplicaciones Web, que permite a una tercera persona inyectar código en páginas web visitadas por el usuario. XSS es un vector de ataque que puede ser utilizado para robar información delicada, secuestrar sesiones de usuario, y comprometer el navegador, subyugando la integridad del sistema. Esta situación es usualmente causada al no validar correctamente los datos de entrada que son usados en cierta aplicación, o no sanear la información adecuadamente para su presentación como página web.
Inyección SQL
Es un método de infiltración de código SQL intruso que se vale de una vulnerabilidad informática que se presenta al existir una mala o nula validación de datos con los que se realizan operaciones sobre una base de datos. El origen de la vulnerabilidad radica en la incorrecta validación o filtrado de las variables utilizadas en un programa que contiene, o bien genera, código SQL. Es un tipo de vulnerabilidad que puede ocurrir en cualquier lenguaje de programación.
Exposición de Metadatos
Los metadatos que una aplicación/sistema puede alojar no deben ser expuestos al público, ya que esto no cumpliría con las normativas de privacidad de los datos de los usuarios. Ejemplo de metadatos:
- Correos Electrónicos
- Direcciones o teléfonos personales de clientes / usuarios
- Usuarios o contraseñas
- Versiones o información de servidores web u otros elementos de la configuración.
Comunicación Segura
La utilización de los protocolos HTTPS, SSL y TLS con versiones seguras en la totalidad del aplicativo/sistema es de gran importancia ya que se asegura que la información que viaja entre los servidores y usuarios está encriptada a un nivel alto y aumenta la calidad de la seguridad y confidencialidad de los datos.
Ambiente Productivo o idéntico en cuanto a configuraciones, dimensión y capacidad para considerar correcta la realización del análisis de vulnerabilidades estáticas y dinámicas deben realizarse en el ambiente productivo o uno idéntico en cuanto a:
- Configuraciones
- Componentes
- Versiones
- Dimensión
- Capacidad
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 | Criterio para iniciar evaluación | Nivel de interacción |
|---|---|---|
| 1 | Se identifica el nombre de la Aplicación-Sistema | 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 |
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 el aplicativo, sistema o trámite que ha sido analizado 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 | Criterio para iniciar evaluació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 un sistema web definido en el TOP 10 vigente de la OWASP:
|
Crítica |
| 10 | Si emplea comunicación segura, se identifican las versiones de las capas de transporte TLS/SSL. La versión de TLS debe ser al menos 1.2 |
Crítica |
| 11 | Se identifican los resultados de las técnicas de inyección utilizadas y no se presenta riesgo de inyección. | Crítica |
| 12 | Se informa sobre los resultados del análisis utilizando las técnicas de cambio de parámetros controlado s por el usuario y no se presenta riesgo. |
Crítica |
| 13 | Se informa sobre los resultados del análisis de XSS para los componentes AJAX, JSON, JavaScript y no se presenta riesgo. |
Crítica |
| 14 | Se informa los resultados sobre el análisis de los metadatos ocultos en las páginas web, y se muestra que no existe información sensible como:
|
Crítica |
| 15 | Se identifican los resultados del escaneo de puertos dentro del análisis dinámico de vulnerabilidades y no existen puertos abiertos adicionales a los necesarios, existiendo justificación descrita de la necesidad de puertos abiertos. |
Crítica |
| 16 | Se identifica el estado actual de las vulnerabilidades detectadas. | Alta |
| 17 | Se identifica el listado final completo de vulnerabilidades encontrados durante la revisión. | Alta |
| 18 | Se identifica en que parte del código /modulo/ funcionalidad fue localizada cada una de las vulnerabilidades. | Alta |
| 19 | Se clasifica por severidad cada vulnerabilidad detectada. | Alta |
| 20 | Se proporciona una comparación del listado de hallazgos de vulnerabilidades de todos los ciclos ejecutados. | Alta |
| 21 | Se describe las acciones que se emplearon para mitigar el riesgo de cada una de las vulnerabilidades detectadas. |
Alta |
| 22 | Se identifica el listado de reglas de seguridad dinámica y estática que se emplearon para la revisión de vulnerabilidades. |
Alta |
| 23 | Se describe los frameworks que fueron utilizados para el desarrollo de la aplicación. | Alta |
| 24 | Se describe el impacto hacia el sistema de cada vulnerabilidad detectada. | Alta |
| 25 | Se identifica el ambiente donde se ejecutó el análisis de vulnerabilidades dinámicamente y este ambiente es el productivo actual o es idéntico en cuanto a:
|
Alta |
| 26 | Si el ambiente no es producción o similar, se identifica la razón y justificación de no realizarlo ahí o bajo esas condiciones. |
Alta |
| 27 | Se describe las URLs del aplicativo que fue objeto de análisis dinámico de vulnerabilidades. | Alta |
| 28 | Se identifica si el ambiente donde se realizó el análisis dinámico de vulnerabilidades está funcionando sobre comunicación segura HTTPS. |
Alta |
| 29 | Se describe si el análisis dinámico de vulnerabilidades fueron realizadas desde adentro o fuera de la red interna. | Alta |
| 30 | Se identifica el tipo de web server en donde está instalada la aplicación. | Alta |
| 31 | Se identifica la versión y tipo de la base de datos del sistema | Alta |
| 32 | Se identifica el tipo y versión del sistema operativo | Alta |
| 33 | Se identifica la versión del código evaluado | Alta |
| 34 | En el listado de reglas de seguridad estática se encuentran clasificadas por:
|
Alta |
| 35 | Se identifica la cantidad de líneas de código evaluadas. | Alta |
| 36 | La cantidad de líneas de código están catalogadas por tecnología. | Alta |
| 37 | Se describen las tecnologías con que fue desarrollada la aplicación. | Media |
| 38 | Se describen cantidad de archivos evaluados durante el análisis de vulnerabilidades estáticas. | Media |