Respuesta corta: las vulnerabilidades vuelven porque el proceso que las genera sigue funcionando. Parchear un hallazgo lo corrige una vez. El análisis de causa raíz pregunta por qué existió, encuentra la falla del proceso que lo permitió y la corrige, para que el siguiente escaneo no traiga lo mismo. Se hace sobre los hallazgos que se repiten o que pesan mucho, no sobre todos.
Un parche arregla un equipo. Una causa raíz bien corregida evita cientos de hallazgos futuros.
Dónde encaja en el ciclo
Esta es la última etapa del ciclo de gestión de vulnerabilidades que sigue la guía DHS/CISA (CRR Resource Guide — Vulnerability Management). La semana recorrió las cuatro anteriores:
- Registrar cada hallazgo en un repositorio central. Ver Registro de hallazgos: el repositorio central de vulnerabilidades.
- Priorizar con más de una señal. Ver Cómo priorizar vulnerabilidades: CVSS, EPSS, KEV y criticidad del activo.
- Decidir qué hacer: parchear, mitigar o aceptar. Ver Gestionar la exposición: parchear, mitigar o aceptar.
- Verificar con un reescaneo. Ver Verificar la remediación: cerrar el ciclo con un reescaneo.
- Analizar la causa raíz de lo que se repite o duele.
Las primeras cuatro tratan cada hallazgo. La quinta trata el sistema que los produce, y por eso es la que baja el volumen con el tiempo.
Qué causas suelen aparecer
La guía enumera causas típicas de una vulnerabilidad: un problema del fabricante, una configuración errónea, una política que no se cumplió, un mal diseño, una capacitación insuficiente y la complejidad operativa. En una PyME, esas categorías se ven así:
| Causa típica | Cómo se ve en la práctica |
|---|---|
| Inventario incompleto | Equipos que nadie sabía que existían y que nunca se escanearon ni parchearon |
| Parcheo sin ventana | Los parches quedan postergados porque no hay un momento acordado para aplicarlos |
| Imágenes base viejas | Cada equipo o servidor nuevo nace con el software desactualizado y los hallazgos vuelven |
| Software fuera de soporte | El fabricante ya no publica correcciones y no hay plan de reemplazo |
| Falta de dueño | El hallazgo está registrado, pero nadie responde por resolverlo |
| Configuración por defecto | Se instalan servicios con las opciones de fábrica y no se endurecen |
| Problema del fabricante | La falla viene del producto y la empresa no puede corregirla por sí misma |
La lista no es cerrada. Sirve como punto de partida para las preguntas.
El método de los 5 porqués
Es una técnica simple: se parte del hallazgo y se pregunta "¿por qué?" cinco veces, o las que hagan falta, hasta llegar a algo que se pueda corregir en el proceso. Un ejemplo ilustrativo:
| Pregunta | Respuesta |
|---|---|
| ¿Por qué apareció la misma falla en tres servidores nuevos? | Se crearon desde la misma imagen de instalación |
| ¿Por qué la imagen tiene el software viejo? | Nadie la actualiza desde que se armó |
| ¿Por qué nadie la actualiza? | No figura como activo en el inventario ni tiene responsable |
| ¿Por qué no figura? | El inventario solo registra equipos físicos, no plantillas |
| ¿Por qué solo equipos físicos? | Nunca se definió qué entra en el inventario |
La causa raíz es la falta de una definición de alcance del inventario; la imagen vieja es el síntoma. Corregir eso evita el problema también en las próximas plantillas.
Reglas para que funcione:
- Preguntar por procesos, no por personas. "Falló el técnico" es un punto de parada cómodo y no produce ningún cambio de proceso.
- Aceptar más de una causa. Un hallazgo puede tener dos o tres.
- Parar cuando la respuesta es algo que podés cambiar. Si la respuesta es "porque el fabricante lo diseñó así", la causa quedó fuera de tu control.
Qué hacer con la causa encontrada
La guía distingue dos tipos de acciones:
- Correctivas: arreglan lo que ya falló. Actualizar la imagen base, reconstruir el servidor, reinstalar el equipo.
- Preventivas: impiden que se repita. Definir el inventario completo, fijar una ventana de parcheo mensual, asignar un dueño a cada sistema, reemplazar el software sin soporte.
Cada acción lleva responsable, fecha y un resultado esperado. Después se actualiza el registro de hallazgos con la causa identificada y se monitorea el efecto: si en los siguientes escaneos el mismo tipo de hallazgo deja de aparecer, la acción funcionó. Si sigue apareciendo, la causa estaba mal identificada y el análisis se repite.
Cuándo no conviene hacerlo
La guía reconoce dos límites. El primero: algunas vulnerabilidades están fuera del control de la organización, por ejemplo una falla de diseño de un producto sin alternativa. Ahí la salida es mitigar o aceptar con firma y vencimiento, no investigar.
El segundo es de costo y beneficio. Un análisis de causa raíz consume horas de personas que conocen el sistema. Tiene sentido cuando:
- el mismo hallazgo reaparece más de una vez,
- el hallazgo es de prioridad alta,
- varios hallazgos distintos parecen venir de un mismo origen.
Para un hallazgo aislado y de baja prioridad, el parche y la verificación alcanzan.
Cómo elegir qué analizar
Una forma práctica de decidir es contar. Con el registro de hallazgos al día, hacé tres preguntas:
- ¿Qué hallazgos fueron reabiertos más de una vez?
- ¿Qué tipo de vulnerabilidad aparece en más activos? Por ejemplo, el mismo componente desactualizado en muchos equipos.
- ¿Qué activos acumulan más hallazgos vencidos?
Esas tres listas son el punto de partida. Un análisis por trimestre, bien hecho, rinde más que muchos hechos de apuro.
Errores típicos
- Parar en la primera respuesta. "No se parcheó a tiempo" describe el síntoma, no la causa.
- Buscar un culpable. Un análisis que termina en una persona no produce cambios de proceso.
- No convertir la causa en acción. Se documenta el análisis y no se asigna ninguna tarea.
- No medir después. Sin seguimiento, nadie sabe si la acción sirvió.
- Analizarlo todo. El método es caro y debe reservarse para lo que lo justifica.
Preguntas frecuentes
¿Cada cuánto conviene hacer un análisis de causa raíz?
Cuando un hallazgo se reabre por segunda vez o cuando una familia de hallazgos aparece en muchos equipos. Para una PyME, un análisis trimestral sobre lo más repetido suele alcanzar.
¿Quién tiene que participar?
Quien opera el sistema, quien lo administra y alguien con capacidad de cambiar el proceso. Sin esa tercera persona, las acciones preventivas quedan sin dueño.
¿Los 5 porqués son siempre cinco?
No. Son una guía. Se pregunta hasta llegar a una causa sobre la que se pueda actuar, que puede ser la tercera respuesta o la séptima.
¿Qué hago si la causa es un software sin soporte que no puedo reemplazar?
Es un caso de aceptación de riesgo, con controles compensatorios, firma del dueño del riesgo y fecha de vencimiento. La causa raíz queda registrada y el reemplazo pasa a ser una acción con fecha.
En resumen
El ciclo de gestión de vulnerabilidades se cierra cuando lo que aprendés de un hallazgo cambia el proceso. Registrar, priorizar, decidir y verificar dan control sobre lo que ya apareció. El análisis de causa raíz reduce lo que va a aparecer. Esta semana: elegí el hallazgo que más veces se reabrió en tu registro y respondé los cinco porqués por escrito, con la persona que administra ese sistema. En el material de descarga hay una plantilla para hacerlo.
5 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.