Optimización de la Estrategia de Mitigación: El Rol Sustancial del Retest en la Gestión de Vulnerabilidades

Columna por Fernando Lagos.

De acuerdo a nuestro reporte anual 2022, en promedio las organizaciones tardan 23 días en mitigar una vulnerabilidad alta y 24 días una crítica, sin embargo hay algunas que nunca son mitigadas.

Un dato que no se muestra, es cuantas veces se le debe hacer un RETEST a la vulnerabilidad antes de que esta se marque como “mitigada”. Muchas veces, una incorrecta gestión de los RETEST significa triplicar o cuadriplicar los esfuerzos de los equipos de desarrollo, seguridad, gestión de proyectos, etc.

La correcta gestión de vulnerabilidades consiste en realizar un correcto levantamiento de estas y también preocuparse de su mitigación.

De acuerdo a mi experiencia, existen distintos procesos para poder detectar vulnerabilidades en plataformas tecnológicas, como ejercicios de red teaming, ethical hacking, análisis de vulnerabilidades, análisis estático de código, entre otros, pero existe un concepto que es transversal a cualquier tipo de actividad ofensiva, el RETEST.

El proceso de RETEST consiste en volver a verificar las vulnerabilidades o debilidades que fueron detectadas inicialmente, esto permite certificar la correcta mitigación y de esta forma disminuir el riesgo.

El RETEST es una actividad independiente del tipo de análisis. Incluso se puede ejecutar un RETEST luego de un proceso de hardening, por este motivo esta actividad toma un rol relevante en la gestión de vulnerabilidades y ciberseguridad.

Se centra sólo en los hallazgos. No es un proceso nuevo de descubrimiento de vulnerabilidades, esto significa que si en un primer análisis se detectaron 5 vulnerabilidades, durante el RETEST se verificarán estas 5 y eventualmente podrían aparecer nuevas, pero no es el foco.

De esta misma forma, si tenemos 5 vulnerabilidades, lo ideal es que se mitiguen estas 5 y luego se realice el retest. Muchos cometen el error de ejecutar 5 retest distintos a medida que van solucionando las vulnerabilidades, pero esto conlleva otro riesgo, ya que cada vez que se pasa a producción un nuevo cambio, existe el riesgo de que se toquen piezas que no serán analizadas en este RETEST.

Si nuestra organización no puede esperar a que se mitiguen todos los hallazgos o bien las vulnerabilidades detectadas son muchas más que 5, lo ideal es que se trabaje en un plan de mitigación donde se agrupen por criticidad y por tiempo de mitigación, con el fin de evitar publicar decenas de releases. Si queremos evitar esto, es recomendable generar una instancia especial para la corrección de los hallazgos y realizar pruebas en esa instancia, antes de pasar a producción para que, cuando se logre mitigar la mayor cantidad posible de hallazgos, pasen a producción todos juntos.

Otro problema muy común, es dejar pasar el tiempo antes de ejecutar la mitigación. My mientras pasa el tiempo, el sistema va sufriendo modificaciones, actualizaciones, etc, entonces, cuando se ejecuta el retest, las condiciones no son las mismas de cuando se ejecutó el test. Cuando eso ocurre, entonces es recomendable volver a ejecutar un análisis nuevo, ya que podrían haber funcionalidades que no fueron revisadas.

En resumen, las recomendaciones para la ejecución efectiva de un RETEST, y de esta forma poder asegurarnos que los hallazgos fueron mitigados correctamente, son las siguientes:

• Definir plazos acotados para la ejecución del RETEST y ojalá que se ejecute con la mayor cantidad de vulnerabilidades mitigadas
• Ejecutar el RETEST antes de lanzar un nueva versión con funcionalidades nuevas
• Ejecutar el RETEST idealmente bajo las mismas condiciones en las que se ejecutó el test
• Sabiendo que existen diversas formas de explotar una misma vulnerabilidad, si durante el RETEST se detectó la mitigación de una vulnerabilidad, se deben probar nuevas formas de ataque para intentar saltarse la mitigación

Finalmente, se debe considerar que el proceso de RETEST certifica que una vulnerabilidad descubierta fue mitigada correctamente, pero no garantiza que esta vulnerabilidad no vuelva a aparecer.