Gestión de vulnerabilidades
Ejecutar un escáner de vulnerabilidades es la parte fácil. Cualquier herramienta le proporcionará un informe con mil hallazgos ordenados por una puntuación CVSS que no tiene prácticamente nada que ver con la posibilidad de que un atacante pueda realmente aprovechar esa vulnerabilidad en su contra hoy mismo. La gestión de vulnerabilidades es la disciplina que consiste en convertir esa gran cantidad de hallazgos en una breve lista de aspectos que realmente importan y, a continuación, asegurarse de que se solucionen.
La carencia que observo con mayor frecuencia no es la falta de análisis, sino la falta de priorización y de seguimiento. Los equipos reciben un informe, corrigen los problemas más sencillos y dejan el resto sin resolver porque no existe una responsabilidad clara sobre quién se encarga de la corrección ni cuál es realmente el plazo. Mientras tanto, el único hallazgo crítico que realmente puede ser objeto de explotación desde Internet —quizá un servicio de cara al público que ejecuta una versión antigua con una vulnerabilidad conocida— queda relegado a la página doce, junto a un centenar de hallazgos de baja gravedad en sistemas internos a los que nadie puede acceder desde el exterior.
Cómo lo gestiono
He configurado un análisis que abarca lo que realmente importa: la superficie de ataque externa, la red interna, la configuración en la nube y, cuando sea pertinente, el código de las aplicaciones. Pero el verdadero trabajo reside en el establecimiento de prioridades: cruzar la información sobre lo que es vulnerable, lo que está expuesto y lo que realmente causaría daños si se viera comprometido, de modo que su equipo se centre en solucionar las cinco cuestiones que importan esta semana, en lugar de perseguir una puntuación de gravedad. Creo flujos de trabajo de corrección con responsabilidades claras y acuerdos de nivel de servicio (SLA) realistas basados en el riesgo real, no en una política general del tipo «aplicar todos los parches en un 30 días» que acaba siendo ignorada por ser inviable.
También realizo un seguimiento del programa a lo largo del tiempo, no solo de los hallazgos individuales. Si sigue reapareciendo el mismo tipo de vulnerabilidad, se trata de un problema de proceso, no de aplicación de parches, y merece la pena solucionar la causa raíz: un proceso de compilación que no incluya una actualización de la imagen base, o un equipo que no cuente con un intervalo de aplicación de parches integrado en su calendario de implementación.
¿A quién va dirigido?
Si sus informes de análisis se acumulan sin leer, si no puede afirmar con certeza cuál es su vulnerabilidad más susceptible de ser explotada en este momento, o si está realizando análisis pero no está llevando a cabo las medidas correctivas necesarias, merece la pena solucionar esta situación.
Contacte conmigo y hablemos sobre qué es lo que realmente está analizando su entorno y qué ocurre con los resultados.