Cómo verificar que una vulnerabilidad quedó corregida y cerrar el hallazgo

Comprueba activos, versión, alcance y mitigaciones antes de cerrar una tarea de seguridad; distingue parche aplicado de riesgo mitigado.

Equipo enginerIT· 3 min de lectura
Siete comprobaciones antes de cerrar

Un instalador completado, un correo de confirmación o una tarea marcada como hecha no demuestran que todos los activos afectados dejaron de ser vulnerables. El cierre debe unir la lista de activos con una comprobación verificable y conservar pendientes y mitigaciones temporales.

Reutiliza el alcance original

Toma la lista de activos detectados y registra cuáles se evaluaron, cuáles no se encontraron y cuáles quedaron fuera por una razón demostrada. Si hay activos desconectados, sustituidos o sin propietario, crea un resultado pendiente. No reduzcas el número de equipos reescribiendo la lista sin dejar rastro.

Verifica versión o condición corregida

Consulta una fuente del sistema que confirme la versión instalada o la configuración modificada. Relaciona la comprobación con el identificador de activo y con la condición vulnerable del aviso. Un mensaje del sistema de despliegue puede ser una evidencia auxiliar, pero valida el estado final.

Comprueba el servicio y el activo

Confirma que el sistema sigue prestando la función esperada tras el cambio y que la verificación corresponde al equipo correcto. En caso de reinicio pendiente, instalación parcial o error reportado, conserva el hallazgo abierto y asigna la siguiente acción.

Separa estados de remediación

Usa estados distintos para parche aplicado y verificado, mitigación temporal vigente, afectado pendiente, no afectado con evidencia y desconocido. La CISA playbook separa sistemas remediados, mitigados, susceptibles o comprometidos; es una referencia para seguir el estado, aunque se redactó para agencias federales.

Fija revisión para cualquier mitigación temporal

Si restringir acceso o aislar el sistema reduce temporalmente la exposición, registra qué control se aplicó, quién lo mantiene y cuándo se revisa. Define el evento que permite volver a probar el parche. Una regla de firewall puede retirarse o cambiar; sin revisión, una mitigación pierde fiabilidad.

No mezcles corrección de vulnerabilidad con análisis de compromiso

El parche puede eliminar la condición vulnerable, pero no prueba que no hubiera actividad previa. Si existen alertas, accesos anómalos o indicadores relacionados, abre una revisión de seguridad separada. No marques como cerrado un posible incidente porque se aplicó una actualización.

Conserva la trazabilidad del cierre

Guarda CVE, activo, versión antes y después, ventana de cambio, responsable, hora de verificación, resultado y enlaces a incidencias asociadas. Si el cierre se revoca por información nueva, reabre el mismo caso o crea una relación explícita para mantener el historial.

Revisa el proceso cuando reaparece el hallazgo

Si el escaneo vuelve a detectar la vulnerabilidad, averigua si se aplicó en un sistema distinto, si una imagen volvió a desplegar una versión anterior o si el sensor conserva un resultado antiguo. Contrasta la fecha y el activo exactos antes de repetir el cambio.

Antes de ponerlo en marcha

  • ✓ La lista de activos afectados está identificada y reconciliada.
  • ✓ La versión o configuración final se comprueba desde una fuente fiable.
  • ✓ Los equipos fuera de línea quedan como pendientes, no cerrados.
  • ✓ La mitigación temporal tiene dueño, evidencia y fecha de revisión.
  • ✓ Los fallos de instalación tienen una cola y siguiente acción.
  • ✓ Las posibles señales de explotación se derivan a respuesta a incidentes.
  • ✓ El cierre guarda quién revisó la evidencia y cuándo.

Fuentes y documentación

Comprueba un cambio reciente desde el inventario y desde el activo.

Compara el estado esperado con la versión real, registra los dispositivos pendientes y pide a otra persona que confirme el criterio de cierre antes de cerrar el lote.

Cuéntanos qué necesitas →