Diagrama de flujo de gestión de vulnerabilidades (de escaneo a cierre)

¿Qué es diagrama de flujo de gestión de vulnerabilidades (de escaneo a cierre)?

La gestión de vulnerabilidades es el ciclo operativo recurrente que encuentra debilidades conocidas en todo el parque, decide cuáles importan, consigue que se corrijan y lo demuestra. El disparador es un calendario y no un evento: se abre una ventana de escaneo contra el inventario de activos, y todo lo que viene después depende de que ese inventario sea correcto. El diagrama de abajo sigue un ciclo de principio a fin: el alcance del escaneo y la cobertura de credenciales se acuerdan antes de escanear nada, se ejecuta el escaneo autenticado, los avisos del proveedor llegan junto con la salida propia del escáner, los hallazgos se deduplican y se confirman, una puntuación combina la gravedad con la explotabilidad y lo que realmente contiene el activo, se asignan una fecha límite y un propietario con nombre, un cambio lleva la corrección, un reescaneo cierra el hallazgo o lo reabre, y el registro y las métricas son lo que revisa la dirección antes de que se abra la siguiente ventana.

Esto es el programa, no la corrección. Lo que hace un propietario del sistema dentro de un único ticket —validar el hallazgo contra su propia configuración, elegir entre un parche, una actualización, un cambio de configuración y una baja de servicio, probarlo y desplegarlo— es el proceso de remediación de vulnerabilidades, y cuelga del único paso «Aplicar el parche, el cambio de configuración o el control compensatorio» dibujado aquí. El propio parche del proveedor, con su evaluación de aplicabilidad, sus pruebas fuera de producción, su despliegue por anillos y su reversión, es la gestión de parches, un ciclo aparte que este consume sin contenerlo. Y el flujo completo de excepciones de seguridad —justificación de negocio, controles compensatorios, un nivel de aprobación que sigue la puntuación de riesgo, un asiento en el registro y una revisión de renovación— se sitúa detrás de la decisión «¿Excepción aprobada con fecha de caducidad?» y no dentro de ella. Mantener esos límites visibles es lo que evita que un solo diagrama intente ser tres. Trata lo que sigue como un punto de partida que hay que adaptar bajo tu propia política de seguridad, tus obligaciones normativas y el criterio de un profesional de seguridad competente.

Cuatro decisiones sostienen el proceso. «¿Todo activo dentro del alcance es escaneable?» va primero porque los fallos de cobertura son invisibles: un activo al que ningún patrón de escaneo llega no genera hallazgos, y un panel limpio y un parque sin escanear se ven idénticos en el informe. «¿Explotación conocida o gravedad crítica?» es la bifurcación de priorización, y está en el carril del analista porque la evidencia de explotación es suya, mientras que la vía de emergencia que abre está en manos de la dirección de seguridad, que tiene la autoridad para interrumpir otro trabajo. «¿Es remediable dentro del SLA?» está deliberadamente en el carril de propietario del sistema / operaciones TI y no en el del analista —quien tiene que hacer el cambio es quien sabe si existe la ventana— y su rama negativa lleva a una decisión de excepción que pertenece a la dirección de seguridad, porque aceptar un riesgo es un acto de dirección y no de ingeniería. «¿El reescaneo muestra el hallazgo cerrado?» devuelve el proceso al analista, de modo que el cierre descanse sobre evidencia y no sobre que alguien marque un ticket como hecho.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles (Analista de vulnerabilidades, Propietario del sistema / Operaciones TI, Gestor de cambios, Dirección de seguridad y Proveedor) repartidos en seis fases: alcance y descubrimiento, escaneo e ingesta, triaje, priorización y asignación, remediación y verificación, e informe y revisión
• Una puerta de cobertura antes de cualquier escaneo: «¿Todo activo dentro del alcance es escaneable?» devuelve las credenciales que faltan y los agentes sin desplegar para que se corrijan, porque un activo contra el que el escáner no puede autenticarse casi no reporta nada y aun así cuenta como escaneado
• Dos vías de entrada a una sola cola: la salida propia del escáner y un aviso del proveedor que llega en el paso «Publicar el aviso y la versión corregida», de modo que algo anunciado entre ventanas de escaneo no quede sin propietario hasta el siguiente ciclo
• Un par de triaje que la mayoría de los diagramas comprime en una sola caja: «¿Hallazgo confirmado en el activo?» dirige los resultados no confirmados a «Descartar como falso positivo con evidencia», un terminal cerrado que aun así exige un motivo, una caducidad y un aprobador
• Puntuación y fecha límite como actos separados: «Puntuar por CVSS, explotabilidad y valor del activo» produce la puntuación, «¿Explotación conocida o gravedad crítica?» separa el trabajo de emergencia de la banda rutinaria, y solo entonces se nombra y se responsabiliza a un propietario de la corrección
• Cierre sobre evidencia, con dos bucles y una salida: «¿El reescaneo muestra el hallazgo cerrado?» reabre todo lo que sigue presente, «¿Es remediable dentro del SLA?» conduce a «¿Excepción aprobada con fecha de caducidad?», y los hallazgos vencidos se escalan antes de publicar las métricas

Cuándo usar esta plantilla

• Estás redactando o reescribiendo un estándar de gestión de vulnerabilidades y necesitas una sola imagen de quién escanea, quién puntúa, quién corrige y quién acepta el riesgo residual
• Los hallazgos envejecen más allá de su fecha límite y nadie sabe decir si se atascan en el triaje, en la asignación, en la ventana de cambio o en el reescaneo
• Estás seleccionando o sustituyendo un escáner y quieres tener el proceso acordado antes de configurar políticas de escaneo, almacenes de credenciales, grupos de activos y bandas de SLA
• Seguridad y operaciones TI no se ponen de acuerdo sobre qué cuenta como remediado, así que el reescaneo, la vía de excepción y la ruta de escalado tienen que quedar explícitos y con dueño
• Un auditor o un cuestionario de seguridad de un cliente ha pedido una descripción documentada de cómo se identifican, puntúan, remedian y verifican las vulnerabilidades

Cómo funciona

1. Cambia los carriles por tus roles

   Sustituye Analista de vulnerabilidades, Propietario del sistema / Operaciones TI, Gestor de cambios, Dirección de seguridad y Proveedor por los roles que existen de verdad en tu organización. En un equipo pequeño el analista y el propietario del sistema suelen ser la misma persona: fusiona esos carriles en vez de dibujar una entrega que solo existe en el papel. Aun así, mantén la dirección de seguridad separada, porque las ramas de excepción y escalado necesitan una autoridad que no sea también quien corrige.

2. Escribe tu regla de alcance y cobertura del escaneo

   Indica qué activos están dentro del alcance, cómo llegan ahí desde el inventario o la CMDB, cuáles se escanean con credenciales o agente y cuáles no, y con qué frecuencia se escanea cada grupo. Anota las exclusiones y quién puede concederlas. La cobertura es el número que da sentido a todos los demás números del programa, así que ponlo en el diagrama en vez de dejarlo en un ajuste de herramienta que nadie lee.

3. Define cómo se puntúa un hallazgo

   Indica qué escala de gravedad usas y de dónde sale la puntuación, y luego qué le añades. Una puntuación de gravedad describe el impacto técnico; la evidencia de explotación y el contexto del activo describen cuánto debería preocuparte esta semana. Escribe la combinación que usas de verdad, nombra sus entradas y registra quién puede anular una puntuación y sobre qué evidencia se apoya esa anulación.

4. Fija las bandas de SLA y arranca el reloj

   Pon tus propias fechas límite de corrección en el diagrama y borra los marcadores de posición. Acuerda cada banda con quienes tienen que cumplirla, y sé explícito sobre cuándo arranca el reloj, porque la fecha de detección, la fecha del ticket y la fecha de publicación del proveedor producen informes de antigüedad muy distintos sobre el mismo parque. Indica qué significa en la práctica la vía de emergencia y quién puede abrirla.

5. Acuerda la vía de excepción y escalado

   Decide quién puede aprobar una excepción, qué evidencia la acompaña, la vida máxima que puede tener y qué control compensatorio tiene que estar activo mientras dure. Después acuerda el escalado para todo lo que quede vencido sin excepción: a quién se avisa, a qué antigüedad y qué pasa si nada cambia después. Ambas vías necesitan una persona con nombre y no un buzón compartido.

6. Decide qué demuestra que un hallazgo está cerrado

   El cierre debería apoyarse en un reescaneo del activo afectado, no en que se marque un ticket como hecho. Escribe qué escaneo lo demuestra, cuánto tarda en ejecutarse tras una corrección, y qué pasa cuando el reescaneo sigue reportando el hallazgo. Registra si un control compensatorio cierra un hallazgo o solo lo reduce, porque esas dos convenciones producen registros y métricas muy distintos.

7. Recórrelo contra un hallazgo real

   Coge dos hallazgos del último ciclo, uno que se cerrara a tiempo y otro que se retrasara o acabara como excepción, y sigue el rastro de ambos por el diagrama. Cualquier paso que la gente describa y no esté dibujado, y cualquier paso dibujado que se salte en silencio en la práctica, es el hallazgo que merece la pena atender antes de publicar el proceso a nadie más.

Preguntas frecuentes

¿Cuáles son los pasos de un proceso de gestión de vulnerabilidades?

Un ciclo de escaneo se abre contra el inventario de activos, y el alcance y la cobertura de credenciales se fijan antes de ejecutar nada; los activos a los que el escáner no llega se corrigen y se reverifican. Se ejecuta el escaneo autenticado programado, y los avisos del proveedor que llegan entre escaneos se suman a la misma cola. Los hallazgos se deduplican y se enriquecen con datos de explotación, luego se confirman contra el activo, y todo lo no confirmado se descarta como falso positivo junto con su evidencia. Los hallazgos confirmados se puntúan por gravedad, explotabilidad y valor del activo, se dirigen a una vía de emergencia o a una banda de fecha límite estándar, y se asignan a un propietario de la corrección con nombre. El propietario remedia dentro del plazo, a través de una ventana de cambio cuando hace falta, o solicita una excepción con fecha de caducidad. Un reescaneo confirma el cierre o reabre el trabajo. Por último se actualiza el registro, se escalan los hallazgos vencidos, se publican las métricas de cobertura, antigüedad y cierre, y la dirección revisa la tendencia antes del siguiente ciclo.

¿Qué diferencia hay entre la gestión de vulnerabilidades y la gestión de parches?

La gestión de vulnerabilidades es el ciclo que descubre debilidades en todo el parque, las puntúa y las lleva hasta un cierre verificado, sea cual sea el tratamiento que acabe aplicándose. La gestión de parches es uno de esos tratamientos: el ciclo operativo que toma una versión del proveedor, evalúa si aplica, la prueba, la programa y la despliega. La guía del NIST sobre planificación de la gestión de parches en la empresa (SP 800-40 revisión 4) plantea lo mismo desde el otro lado, situando el parcheo como mantenimiento preventivo y como una de varias formas de responder al riesgo que crea una vulnerabilidad de software. La consecuencia práctica es que un programa de vulnerabilidades medido solo en parches instalados se subestima a sí mismo, porque los cambios de configuración, las actualizaciones, las bajas de servicio y los controles compensatorios también cierran hallazgos, y algunos hallazgos no tienen ningún parche que instalar.

¿Basta una puntuación CVSS para priorizar la remediación?

CVSS, mantenido por FIRST, puntúa la gravedad técnica de 0,0 a 10,0, y sus bandas cualitativas en la versión 3.1 son Baja de 0,1 a 3,9, Media de 4,0 a 6,9, Alta de 7,0 a 8,9 y Crítica de 9,0 a 10,0. La versión 4.0, publicada en 2023, conserva una puntuación base y añade grupos de métricas explícitos de Amenaza y de Entorno. Lo que CVSS deliberadamente no te dice es cuán probable es la explotación ni cuánto te importa un activo concreto. Los equipos suelen añadir otras dos señales: una puntuación de probabilidad de explotación como EPSS, también de FIRST, que estima la probabilidad de que una vulnerabilidad se explote en el mundo real en los próximos treinta días y se recalcula a diario, y evidencia de explotación real como el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA. El contexto del activo es la tercera entrada, y esa es solo tuya. Por eso este diagrama primero puntúa y después dirige según «¿Explotación conocida o gravedad crítica?» en vez de ordenar una lista por puntuación.

¿Con qué frecuencia deberían ejecutarse los escaneos de vulnerabilidades, y quién es dueño del proceso?

Los marcos difieren, así que toma la frecuencia del que te aplique a ti y no de una regla general. El control 8.8 del Anexo A de ISO/IEC 27001:2022, gestión de las vulnerabilidades técnicas, exige que se obtenga información sobre las vulnerabilidades técnicas de los sistemas en uso, que se evalúe la exposición y que se tomen las medidas adecuadas, pero no fija ningún intervalo y deja la cadencia a tu evaluación de riesgos. PCI DSS versión 4 es más prescriptivo para entornos con datos de titulares de tarjeta: escaneos internos de vulnerabilidades al menos cada tres meses y tras cualquier cambio significativo, realizados como escaneos autenticados, con escaneos externos a cargo de un Approved Scanning Vendor. Muchas organizaciones escanean con mucha más frecuencia que el mínimo porque el coste de otro escaneo es bajo. En cuanto a la propiedad, el reparto habitual es el que se dibuja aquí: seguridad es dueña de la detección, la puntuación y el informe; el propietario del sistema es dueño de la corrección; la dirección es dueña de las excepciones y los escalados. Un programa en el que seguridad también es dueña de la remediación tiende a atascarse, porque el analista no tiene ni los derechos de cambio ni el riesgo operativo.

¿Qué registros debería producir un proceso de gestión de vulnerabilidades?

Los suficientes para reconstruir cualquier hallazgo un año después sin abrir el escáner. En la práctica eso significa un asiento de registro por hallazgo con el activo afectado, la fecha de detección, la puntuación y lo que la alimentó, el propietario asignado, la fecha límite, el tratamiento elegido y la evidencia de cierre. Junto a eso están la configuración del escaneo y la evidencia de cobertura, para que un revisor pueda saber qué estaba dentro del alcance y qué estaba autenticado; la lista de descartes, con un motivo y una fecha de revisión para cada falso positivo; el registro de excepciones, con justificación, control compensatorio, aprobador y caducidad; y la salida del reescaneo que cerró cada hallazgo. El informe es el último registro: cobertura, antigüedad frente a las bandas de fecha límite y tasa de cierre a lo largo del tiempo, junto con lo que decidió la dirección cuando cambió la tendencia. Un revisor suele contrastar el registro contra el escáner y no al revés, así que los hallazgos sin explicar que existen en la herramienta pero no en el registro son el hallazgo habitual.