A simple lectura, pareciera una respuesta fácil: «remediar las vulnerabilidades debe ser nuestra prioridad». Sin embargo, en la práctica, y con tantos parches, configuraciones, librerías desactualizadas, shadow IT y hasta shadow AI, la remediación de las vulnerabilidades puede convertirse en un caos absoluto en muchas organizaciones.
Y es que gestionar las vulnerabilidades no depende de una tecnología (aunque muchos vendors digan lo contrario); sino de un proceso claramente establecido, implementado y que, en la medida de lo posible, haya madurado con el paso de los años.
Claro que es necesaria la tecnología y los sistemas automatizados para aumentar la eficiencia de un proceso, pero el proceso por sí mismo debería dictar qué tecnología lo puede volver más eficiente y maduro; y no al revés, en donde en muchos casos es la tecnología la que implementa el proceso, lo que dificulta su maduración debido a que no puede adaptarse si la tecnología no se adapta; es decir, se produce un bloqueo por el uso de cierta tecnología.
Remediación
Vayamos al inicio de todo. ¿Por qué necesitamos remediar una vulnerabilidad? Porque buscamos disminuir la probabilidad de que un riesgo se materialice. Sin embargo, es ahí en donde las herramientas y servicios muchas veces fallan y se requiere un análisis más profundo para lograr una correcta medición del riesgo.
A lo largo de más de 21 años de experiencia, me he encontrado con incontables reportes de análisis de vulnerabilidades y pruebas de penetración que carecen de niveles aceptables de presentación y que en muchas de las ocasiones generan más problemas de los que intentan resolver. Por mencionar algunos de los principales errores:
- Vulnerabilidades inexistentes: En algunas ocasiones, reportes completos son falsos positivos, inclusive en ejercicios de pruebas de penetración donde ni siquiera los pentesters se tomaron unos minutos para validar las salidas de alguna herramienta automatizada. Esto genera una carga importante adicional para quien lo revisa, atiende y posteriormente intente gestionar estas vulnerabilidades.
- Errores en redacción: El copy/paste en su máximo esplendor, un formato que se utilizó de otro cliente, en donde hasta copiaron la redacción de los principales hallazgos.
- Mala clasificación del riesgo: Al no existir un criterio de clasificación del riesgo, el consultor, «a ojo de buen cubero» como decimos en México, realiza la clasificación del riesgo, volviéndolo casi binario: «existe la vulnerabilidad, es de riesgo crítico».
Gestión de vulnerabilidades
Entonces si lo que buscamos en nuestro proceso es verdaderamente gestionar las vulnerabilidades, deberíamos tener en cuenta al menos dos consideraciones relevantes:
- La entrada del proceso; es decir, los resultados de las pruebas de penetración y análisis de vulnerabilidades deben contener información de valor para el negocio, donde no solo los niveles de riesgo se encuentren correctamente clasificados y con un criterio determinado, sino también verdaderas vulnerabilidades con recomendaciones específicas para lograr su atención expedita. Incluso es válido solicitar que los reportes ya se encuentren divididos por las áreas correspondientes que atenderán las vulnerabilidades.
- Los tiempos de ejecución de cada ejercicio. Recordemos que un análisis o una prueba es una «foto» del estado que tiene la tecnología en ese momento; pero a diferencia de una foto tradicional, un ejercicio correctamente realizado de análisis de vulnerabilidades y/o pruebas de penetración debe llevar también su duración adecuada. Es cierto que, cuando hablamos de cumplimiento, el tiempo es un factor que acorta de manera importante los ejercicios. Sin embargo, un atacante tendrá siempre la ventaja absoluta sobre el tiempo, pero un pentester solo tiene el tiempo que la empresa determine para hacer las pruebas. Un balance correcto entre el cumplimiento requerido y la cantidad de activos a probar ayudará a que los resultados tengan una mejor calidad.
- El tipo de ejercicio que se realizará, que depende directamente de los requerimientos del negocio (incluyendo, por supuesto, los de cumplimiento), pero sin dejar de lado la infraestructura crítica del negocio. Porque no todos los activos se involucran para el cumplimiento, pero todos deberían ser probados y evaluados en algún momento para disminuir la seguridad por oscuridad.
Más allá de la mitigación
Por último, y no menos importante, la atención de las vulnerabilidades encontradas no es simple mitigación, debería involucrar al menos los siguientes pasos:
- Revisión de los resultados del ejercicio: Cuanto menos dure esta actividad inicial, más tiempo se puede utilizar en las siguientes. Por tanto, este punto depende directamente de la calidad de los resultados. No obstante, será necesario en cualquier caso asegurarse de que los resultados son consistentes con las pruebas realizadas y se apegan a los requerimientos definidos y entregados al proveedor o herramienta utilizada.
- Priorización de vulnerabilidades: No todas las vulnerabilidades se pueden atender al mismo tiempo; y aunque en muchas ocasiones los KPI nos presionen, los planes de remediación deben priorizar las vulnerabilidades críticas y de riesgo alto. Ahora bien, no podemos dejar a un lado que los riesgos agregados pueden convertir varias vulnerabilidades de riesgo bajo y/o medio a riesgo alto.
- Evitar el riesgo: En la medida de lo posible, es conveniente deshabilitar un puerto o servicio o desinstalar una aplicación o librería (esas actividades que se deberían haberse realizado desde el hardening), puesto que estas acciones ahorran mucho tiempo, en lugar de considerar la remediación por configuración, actualización o desarrollo.
- Una acción para muchas vulnerabilidades: La mayoría de resultados incluyen vulnerabilidades diferentes que con una sola acción se pueden remediar todas o varias. Por ejemplo, cuando se detecta TLS 1.0, también se detectan los algoritmos y suites de cifrado obsoletos, generando hasta cuatro o cinco vulnerabilidades diferentes y que deshabilitando el protocolo TLS 1.0 todas quedarán remediadas.
- Identificar patrones de comportamiento que puedan ayudar a disminuir futuras detecciones: Por ejemplo, identificar si hay reincidencias; es decir, vulnerabilidades que ya se habían remediado pero vuelven a aparecer. De la misma forma, identificar si en ciertos activos el tipo de vulnerabilidad que se presenta es similar puede retroalimentar procesos internos de hardening.
Si bien el proceso de gestión de vulnerabilidades es complejo para la mayoría de las organizaciones, si contamos con un proceso adecuado y servicios de calidad, podremos obtener el mejor costo-beneficio al implementar cualquier tecnología.
