Qué es la gestión de vulnerabilidades y en qué se diferencia de un pentest

Cómo funciona la gestión de vulnerabilidades: el ciclo paso a paso

Descubrimiento de activos

No se puede proteger lo que no está en la lista. Este paso suele revelar servidores olvidados, servicios expuestos y equipos que nadie sabía que seguían conectados.

Escaneo e identificación

Herramientas que comparan versiones y configuraciones contra bases de vulnerabilidades conocidas. Producen mucho ruido: cientos de hallazgos, la mayoría irrelevantes para tu negocio.

Priorización

El paso que convierte el ruido en decisiones. Una vulnerabilidad crítica en un servidor de pruebas aislado importa menos que una media en el sistema que factura. La severidad técnica es solo la mitad del criterio. Los criterios habituales son tres: la severidad técnica (el puntaje CVSS, de 0 a 10), si ya se está explotando activamente (el catálogo KEV de la agencia estadounidense CISA lo registra) y qué tan crítico es el activo para el negocio. La priorización de vulnerabilidades los combina en una matriz de cuatro cuadrantes.

Remediación y verificación

Parchar, reconfigurar o compensar con otro control — y después comprobar que efectivamente quedó cerrada. Sin verificación, el registro dice que se arregló y la exposición sigue ahí.

Remediación de vulnerabilidades: parchar, mitigar o aceptar

Remediar no siempre significa parchar. Ante cada vulnerabilidad priorizada hay tres caminos, y los tres son legítimos si quedan registrados:

Parchar o corregir

Aplicar la actualización del fabricante o cambiar la configuración insegura. Es la opción preferible y, en la mayoría de los casos, la más barata.

Mitigar con otro control

Cuando no se puede parchar (un sistema antiguo, un equipo que el fabricante no permite actualizar, una ventana de mantención que no llega), se reduce la exposición de otra forma: aislar el equipo en la red, cerrar el puerto expuesto, restringir quién accede. La vulnerabilidad sigue ahí, pero ya no está al alcance.

Aceptar el riesgo por escrito

Si ni parchar ni mitigar tiene sentido económico, la gerencia acepta el riesgo con nombre, fecha y plazo de revisión. Lo que no puede pasar es que el riesgo se acepte por omisión.

En los tres casos, el ciclo termina igual: alguien verifica que el cambio quedó hecho, con un nuevo escaneo o una revisión, y la vulnerabilidad se cierra en el registro con su evidencia. Una remediación sin verificación es solo una tarea marcada como lista.

Gestión de vulnerabilidades y pentest: en qué se diferencian

Un pentest es una evaluación puntual: un especialista intenta explotar vulnerabilidades en una fecha determinada y entrega un informe. La gestión de vulnerabilidades es un proceso que corre todo el año.

Son complementarios y ninguno reemplaza al otro. Un pentest sin un programa detrás produce un informe que envejece en semanas y cuyos hallazgos nadie cierra. Un programa sin pruebas ocasionales nunca se valida contra un atacante real que combina debilidades que el escáner ve por separado.

El orden importa: hacer un pentest antes de tener el proceso suele ser gastar en descubrir lo que un escáner básico ya habría dicho, y más caro.

Cómo implementar la gestión de vulnerabilidades en una empresa mediana

El primer paso no cuesta licencias: es el inventario. Saber qué hay, quién lo administra y qué tan crítico es para operar. Sin eso, cualquier herramienta produce una lista que nadie puede priorizar.

Después se define la política de plazos, que es una decisión de negocio y no técnica: cuántos días para una vulnerabilidad crítica, cuántos para una alta. Un punto de partida razonable son treinta días para críticas y noventa para altas, ajustable según la exposición de cada empresa.

Recién entonces conviene incorporar herramientas de escaneo, y siempre con un dueño asignado por hallazgo. Una vulnerabilidad sin responsable y sin fecha reaparece idéntica en el reporte del mes siguiente, que es como la mayoría de los programas muere en silencio.

Funciona cuando cada parte sabe qué le toca. En una empresa mediana, el reparto típico es este:

Gerencia

Fija los plazos de remediación, autoriza las ventanas de mantención y firma las aceptaciones de riesgo.

Quien dirige la seguridad

Prioriza los hallazgos según el negocio, asigna un dueño a cada uno y verifica el cierre. Puede ser un CISO interno o un vCISO.

TI o el proveedor técnico

Escanea, parcha y reconfigura.

La separación importa por la misma razón que en una auditoría: quien aplica el parche no debería ser quien certifica que quedó cerrado.

Cómo se conecta con la norma chilena

La Ley 21.719 exige medidas de seguridad proporcionales al riesgo. Un sistema sin parchar que trata datos personales es difícil de defender como proporcional, sobre todo si la vulnerabilidad era conocida y estaba documentada en tu propio reporte.

Para quienes caen bajo la Ley 21.663, el registro de vulnerabilidades abiertas y cerradas es parte de la evidencia que se presenta ante una auditoría o tras un incidente. Ahí el valor del proceso no es solo haber cerrado la brecha, sino poder demostrar cuándo se detectó, quién la trató y en qué plazo.

Preguntas frecuentes