Respuesta corta: una vulnerabilidad no está corregida cuando alguien dice que aplicó el parche, sino cuando repetís el mismo método que la detectó y el hallazgo ya no aparece. Esa segunda medición es la verificación. Con evidencia guardada y sin reincidencias, el hallazgo pasa a cerrado. Si el reescaneo todavía la encuentra, el cambio no funcionó y el hallazgo vuelve a la etapa de decisión.
El parche aplicado es una intención. El reescaneo limpio es la prueba.
Por qué verificar
Un cambio puede quedar a medias de muchas maneras: el parche pedía un reinicio que no se hizo, se actualizó un servidor y quedó otro igual sin tocar, la instalación falló sin avisar, o la regla de firewall se cargó en la interfaz equivocada. En todos esos casos el ticket dice "resuelto" y la exposición sigue ahí.
La guía DHS/CISA (CRR Resource Guide — Vulnerability Management) incluye la verificación como una etapa propia del proceso: después de aplicar la disposición elegida, se repite el método de descubrimiento para confirmar que la vulnerabilidad desapareció. Si la remediación no fue efectiva, se vuelve a la etapa de decisión.
Qué se repite exactamente
La verificación usa el mismo método que encontró el problema:
| Cómo se detectó | Cómo se verifica |
|---|---|
| Escaneo autenticado de la herramienta | Reescaneo del mismo activo con la misma política de escaneo |
| Escaneo de red sin credenciales | Mismo escaneo, mismos puertos, contra el mismo destino |
| Revisión de versión instalada | Misma consulta de versión, ahora con el número corregido |
| Revisión de configuración | Misma comprobación del archivo o la política |
Si verificás con un método distinto, podés obtener un resultado distinto sin que cambie la realidad: una herramienta puede no detectar lo que otra sí. Un reescaneo con otra política o con menos credenciales puede dar un falso "limpio".
Reescaneo dirigido, no completo
No hace falta volver a escanear toda la red para cerrar un hallazgo. Un reescaneo dirigido apunta solo al activo y a la vulnerabilidad en cuestión. Es más rápido, molesta menos a los sistemas y genera una evidencia más fácil de leer.
Reglas para hacerlo bien:
- Con autorización y ventana acordada. Un reescaneo es tráfico de prueba contra un sistema productivo. Se avisa al dueño del servicio y se hace dentro de la ventana pactada.
- Después del cambio, no antes. Si el cambio requería reinicio, el reescaneo va después de ese reinicio.
- Con alcance acotado. El activo exacto, y los puertos o chequeos relevantes.
- Guardando el resultado. El informe del reescaneo es la evidencia que se enlaza en el registro.
Comparar antes y después
La evidencia más clara es la comparación de dos mediciones: el informe original y el posterior. Lo que se busca es simple: el hallazgo estaba y ya no está, y no apareció nada nuevo que no estaba antes. Esto último importa: a veces un cambio corrige un problema y abre otro, por ejemplo al habilitar un servicio alternativo.
Para escaneos de red, las herramientas de línea de comandos permiten comparar dos resultados y listar solo lo que cambió. En el material de descarga hay comandos concretos.
Cuándo alcanza una muestra
Cuando el mismo cambio se aplicó en decenas de equipos, reescanear cada uno puede ser desproporcionado. La guía contempla la verificación por muestreo: se revisa un porcentaje de los activos afectados, y ese porcentaje se acuerda y se documenta de antemano. Algunas reglas razonables:
- El criterio se escribe antes de empezar, no después de ver los resultados.
- Si una sola muestra falla, se verifica el lote completo.
- Los activos críticos o expuestos a internet se verifican siempre uno por uno.
La guía no fija un porcentaje: lo define cada organización, según el riesgo y el tamaño del universo.
Criterios de cierre
Un hallazgo pasa a cerrado cuando se cumplen todas estas condiciones:
- [ ] El reescaneo posterior al cambio no detecta la vulnerabilidad.
- [ ] La evidencia está guardada y enlazada en el registro.
- [ ] El servicio afectado sigue funcionando.
- [ ] Quien cierra no es quien aplicó el cambio.
- [ ] El registro quedó actualizado con la fecha de cierre.
Que verifique otra persona es la forma más barata de evitar que alguien cierre su propio error sin darse cuenta. En una PyME con un solo técnico, la alternativa es verificar con una herramienta automática y dejar la salida sin editar.
Si el hallazgo reaparece
Hay dos casos, y se tratan distinto:
- El reescaneo todavía lo detecta. La remediación no fue efectiva. El hallazgo vuelve a la etapa de decisión, y la pregunta es por qué falló: ¿faltó el reinicio?, ¿era otro componente?, ¿la mitigación no cubre ese camino? Ver Gestionar la exposición: parchear, mitigar o aceptar.
- Estaba cerrado y vuelve a aparecer semanas después. Se reabre la misma fila del registro, no una nueva, y se anota la fecha. Un hallazgo que reaparece suele indicar que un proceso lo está recreando: una imagen base vieja, una restauración de copia, un despliegue automático que reinstala la versión anterior. Ese patrón es la materia prima del análisis de causa raíz, tema de Causa raíz: por qué las mismas vulnerabilidades vuelven.
El registro donde se anota todo esto se explica en Registro de hallazgos: el repositorio central de vulnerabilidades.
Errores típicos
- Cerrar por el ticket. El técnico anota "parcheado" y el hallazgo se cierra sin reescaneo.
- Reescanear antes del reinicio. El resultado sigue mostrando la versión vieja y se interpreta como falla del parche.
- Cambiar el método. Otra herramienta, otra política, otro alcance: el resultado no es comparable.
- No guardar evidencia. Seis meses después nadie puede demostrar que se verificó.
- Cerrar sin mirar efectos colaterales. El parche corrigió la falla y rompió una integración.
Preguntas frecuentes
¿Hace falta reescanear después de cada parche mensual?
Para los hallazgos priorizados, sí. Para el parcheo de rutina, el siguiente escaneo programado cumple la función de verificación, siempre que su resultado se compare con el anterior.
¿Y si no tengo herramienta de escaneo?
Se verifica con lo que haya: la versión instalada del software, la existencia de la actualización en el sistema, o un escaneo de puertos con una herramienta gratuita. Lo importante es que el método de verificación sea el mismo que el de detección y que el resultado quede guardado.
¿Quién tiene que verificar?
Idealmente alguien distinto de quien aplicó el cambio. Si no es posible, que el resultado sea de una herramienta y no de una afirmación.
¿Cuánto tarda en cerrarse un hallazgo?
Depende de la prioridad y del plazo que fije tu política. Lo que sí conviene medir es cuántos hallazgos se cierran con evidencia y cuántos reaparecen.
En resumen
Verificar es repetir la medición con el mismo método y guardar el resultado. Sin esa prueba, el registro dice lo que alguien cree y no lo que ocurre. Lo que reaparece se reabre en la misma fila, porque ese historial es lo que permite encontrar la causa de fondo. Para esta semana: tomá los últimos cinco hallazgos que tu equipo marcó como resueltos y comprobá cuántos tienen un reescaneo posterior guardado. La semana cierra con Causa raíz: por qué las mismas vulnerabilidades vuelven.
4 páginas · el procedimiento paso a paso, en PDF. Gratis, por dejar tu email.