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

La gestión de vulnerabilidades es el ciclo permanente de descubrir activos, identificar sus debilidades técnicas conocidas, priorizarlas según el riesgo real que representan, remediarlas y verificar que quedaron cerradas. La palabra que hace el trabajo es ciclo: no termina, porque cada semana aparecen vulnerabilidades nuevas en software que ya tenías instalado.

El dato que ordena la conversación en Chile es que el 55% de los ataques entra por una brecha que la organización ya conocía. No es un problema de detección: es un problema de que nadie tenía el proceso, el dueño ni el plazo para cerrarla.

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.

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í.

En qué se diferencia de un pentest

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 se implementa sin gastar de más

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.

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

¿Con qué frecuencia hay que escanear?

Depende de la exposición. Los sistemas accesibles desde internet conviene revisarlos al menos mensualmente; los internos pueden ir en un ciclo más largo. Lo que importa más que la frecuencia es que cada hallazgo relevante tenga dueño y plazo, porque escanear más seguido sin cerrar nada solo agranda la lista.

¿Un antivirus o EDR reemplaza esto?

No. El EDR detecta y responde a actividad maliciosa en los equipos; la gestión de vulnerabilidades cierra la puerta antes de que alguien entre. Son capas distintas: una reduce la probabilidad de que el ataque prospere, la otra reduce la superficie por la que puede empezar.

¿Sirve si tengo casi todo en la nube?

Sí, y cambia el foco. El proveedor de nube parcha su infraestructura, pero las configuraciones, los permisos, las aplicaciones que despliegas y los accesos siguen siendo tuyos. La mayoría de los incidentes en nube nace de una configuración incorrecta, no de una falla del proveedor.