Gestión de vulnerabilidades para empresas en Uruguay

Encontrar vulnerabilidades es relativamente sencillo. Gestionarlas correctamente es otra cosa.

Muchas empresas realizan un escaneo de vulnerabilidades una o dos veces al año, reciben un informe con cientos o miles de hallazgos y consideran que con eso ya cuentan con un proceso de gestión de vulnerabilidades.

En realidad, un programa efectivo requiere mucho más: conocer los activos, detectar vulnerabilidades periódicamente, determinar cuáles representan un riesgo real para la organización, remediarlas, gestionar las excepciones y comprobar posteriormente que la corrección funcionó.

La frecuencia también genera dudas frecuentes: ¿hay que escanear una vez al año, cada seis meses, trimestralmente o todos los meses? ¿Es necesario utilizar credenciales? ¿Hay que corregir todo lo que aparece como crítico?

En esta guía explicamos cómo debería funcionar la gestión de vulnerabilidades en una empresa, qué recomiendan marcos como el Marco de Ciberseguridad de Uruguay 5.0 y CIS Controls, y cómo priorizar correctamente las vulnerabilidades encontradas.

¿Qué es la gestión de vulnerabilidades?

La gestión de vulnerabilidades es un proceso continuo mediante el cual una organización identifica, evalúa, prioriza, corrige y valida vulnerabilidades presentes en sus sistemas, aplicaciones y dispositivos.

Agesic describe un proceso compuesto por siete etapas:

Identificar activos.
Planificar el análisis de vulnerabilidades.
Ejecutar el análisis.
Clasificar las vulnerabilidades encontradas.
Priorizar las vulnerabilidades.
Remediar.
Validar.

La guía oficial de Agesic puede consultarse en Gestión de vulnerabilidades.

La última etapa suele ser una de las más olvidadas: una vulnerabilidad no debería considerarse cerrada simplemente porque alguien indicó que instaló un parche. Es necesario verificar que la vulnerabilidad dejó efectivamente de estar presente.

Escaneo de vulnerabilidades y gestión de vulnerabilidades no son lo mismo

Un escaneo es únicamente una parte del proceso.

Una herramienta como Nessus, Qualys, Rapid7, OpenVAS u otras soluciones similares puede identificar versiones vulnerables, configuraciones inseguras, parches faltantes y diferentes exposiciones técnicas.

Pero la herramienta no conoce por sí sola todo el contexto del negocio.

Por ejemplo, puede encontrar dos servidores con exactamente la misma vulnerabilidad crítica:

uno es un servidor de laboratorio sin información sensible y aislado de Internet;
el otro es el servidor VPN mediante el cual acceden remotamente todos los empleados.

La vulnerabilidad técnica puede ser idéntica, pero el riesgo para la organización no lo es.

Por eso, un programa de gestión debe combinar los resultados técnicos con información sobre los activos, la exposición, el impacto para el negocio y la probabilidad real de explotación.

¿Por qué es importante gestionar vulnerabilidades?

Los fabricantes publican continuamente nuevas vulnerabilidades y actualizaciones. Al mismo tiempo, los atacantes analizan esa misma información para desarrollar o utilizar mecanismos de explotación.

Esto genera una carrera entre tres actores:

el fabricante que publica una corrección;
la organización que debe identificar y corregir el problema;
el atacante que intenta explotarlo antes de que sea corregido.

Por ese motivo, CIS denomina a su Control 7 Continuous Vulnerability Management: la gestión no debería considerarse una actividad puntual realizada únicamente antes de una auditoría.

El primer requisito: saber qué activos tiene la empresa

No se puede proteger ni escanear correctamente aquello que no se sabe que existe.

Antes de implementar un programa de vulnerabilidades debería existir un inventario razonablemente completo de los activos tecnológicos.

Esto incluye, entre otros:

servidores físicos y virtuales;
estaciones de trabajo;
notebooks;
firewalls;
switches y routers;
hipervisores;
equipamiento de almacenamiento;
aplicaciones;
bases de datos;
servicios publicados en Internet;
infraestructura cloud;
dispositivos y sistemas pertenecientes a sucursales.

También resulta importante conocer información como propietario del activo, sistema operativo, versión, ubicación, función, criticidad y exposición.

Una herramienta de inventario como Lansweeper puede facilitar considerablemente esta tarea mediante descubrimiento y actualización automática de activos.

La propia guía de Agesic comienza su proceso de gestión de vulnerabilidades por la identificación de activos.

¿Cada cuánto debería realizarse un escaneo de vulnerabilidades?

No existe una única frecuencia correcta para todas las organizaciones.

La periodicidad debería depender de factores como:

criticidad de los sistemas;
exposición a Internet;
velocidad con la que cambia la infraestructura;
requisitos regulatorios;
nivel de riesgo aceptado;
capacidad de remediación de la organización.

Sin embargo, existen referencias útiles.

Recomendación de Agesic

En su guía de gestión de vulnerabilidades, Agesic recomienda que las organizaciones realicen evaluaciones de vulnerabilidades mensualmente, señalando que se publican vulnerabilidades de forma constante y que muchos fabricantes trabajan con ciclos mensuales de actualizaciones.

Puede consultarse la recomendación en Planificar el análisis de vulnerabilidades.

Marco de Ciberseguridad de Uruguay 5.0

El MCU 5.0 incorpora específicamente la gestión de vulnerabilidades técnicas dentro del requisito SO.1.

Entre sus controles se encuentran:

mantener actualizados el software de base y las aplicaciones críticas;
identificar los activos que no pueden actualizarse y establecer controles compensatorios;
contar con un plan documentado de gestión de vulnerabilidades y parches;
analizar notificaciones de CERTuy y otras fuentes;
clasificar y priorizar las vulnerabilidades;
establecer responsabilidades;
realizar revisiones y comunicar resultados al Responsable de Seguridad de la Información.

En particular, el control SO.1-8 del Nivel 3 establece que los escaneos de vulnerabilidades deben realizarse como mínimo semestralmente.

Esto debe interpretarse como un requisito concreto dentro de ese nivel de madurez, no como una recomendación de esperar seis meses entre evaluaciones cuando el riesgo justifica una frecuencia mayor.

Los requisitos completos pueden consultarse en MCU 5.0 – Gestionar las vulnerabilidades técnicas.

¿Qué recomienda CIS Controls?

CIS Controls v8 establece diferentes frecuencias según el tipo de activo:

activos internos: escaneo automatizado trimestral o más frecuente;
activos expuestos externamente: escaneo mensual o más frecuente;
remediación: proceso de corrección mensual o más frecuente, de acuerdo con la estrategia definida.

CIS también recomienda combinar escaneos autenticados y no autenticados para activos internos dentro de los grupos de implementación correspondientes.

Puede consultarse el CIS Control 7 – Continuous Vulnerability Management.

Entonces, ¿mensual, trimestral o semestral?

Para una empresa moderna, nuestra recomendación general sería evitar considerar una evaluación anual como un programa de gestión de vulnerabilidades.

Como referencia práctica:

Tipo de activo Frecuencia orientativa Motivo Servicios expuestos a Internet Mensual o más frecuente Son directamente accesibles por potenciales atacantes. Servidores críticos internos Mensual o trimestral Su compromiso puede producir un impacto importante en el negocio. Estaciones de trabajo Mensual o trimestral Permite detectar software vulnerable y problemas de actualización a escala. Infraestructura de menor criticidad Según riesgo, evitando intervalos excesivos La frecuencia debe ajustarse a criticidad, exposición y capacidad operativa. Después de cambios significativos Adicional al ciclo habitual Nuevos sistemas o cambios de arquitectura pueden introducir nuevas vulnerabilidades. Ante una vulnerabilidad crítica relevante Inmediato o extraordinario No debería esperarse al siguiente ciclo programado.

Por ejemplo, si mañana se publica una vulnerabilidad crítica activamente explotada que afecta al firewall de la empresa, no tendría sentido esperar hasta el próximo escaneo mensual.

La frecuencia programada debe complementarse con monitoreo de nuevas vulnerabilidades y evaluaciones extraordinarias cuando el riesgo lo justifique.

¿Qué es un escaneo autenticado?

Un escaneo autenticado utiliza credenciales autorizadas para que la herramienta pueda inspeccionar el sistema desde dentro.

Dependiendo de la plataforma, esto puede realizarse mediante:

credenciales administrativas de Windows;
SSH en Linux;
SNMP;
APIs;
otros mecanismos de autenticación compatibles con la herramienta.

Esto permite verificar con mucha mayor precisión:

parches instalados;
versiones de software;
configuraciones;
componentes que no necesariamente son visibles desde la red;
vulnerabilidades locales;
determinadas configuraciones inseguras.

Por ese motivo, para servidores y equipos internos, el escaneo autenticado suele proporcionar una visión considerablemente más completa.

¿Y para qué sirve un escaneo no autenticado?

Un escaneo sin credenciales observa el activo desde una perspectiva más parecida a la de otro dispositivo de la red o, si se realiza externamente, a la de un posible atacante desde Internet.

Puede resultar especialmente útil para identificar:

puertos abiertos;
servicios expuestos;
versiones detectables remotamente;
configuraciones inseguras visibles desde la red;
vulnerabilidades explotables sin autenticación.

Por eso, autenticado y no autenticado no son necesariamente alternativas. En determinados escenarios son evaluaciones complementarias.

¿Un escaneo autenticado puede romper algo?

Las herramientas profesionales de análisis de vulnerabilidades están diseñadas para realizar evaluaciones de manera segura, pero cualquier actividad de análisis técnico debe planificarse.

Especialmente en ambientes productivos deberían revisarse:

las políticas y plugins habilitados;
si se ejecutarán pruebas potencialmente disruptivas;
el horario del análisis;
la criticidad de los activos;
la capacidad disponible de los sistemas;
equipamiento antiguo o especialmente sensible;
credenciales utilizadas y privilegios asignados.

En sistemas extremadamente sensibles —por ejemplo, tecnología industrial, equipamiento médico, dispositivos antiguos o plataformas con restricciones específicas del fabricante— puede ser necesario aplicar una estrategia diferente.

¿Hay que corregir todas las vulnerabilidades críticas primero?

No necesariamente.

Este es uno de los errores más frecuentes de un programa de vulnerabilidades.

Una organización ejecuta un escaneo, ordena el informe por CVSS y decide:

“Primero corregimos todos los críticos, después los altos, después los medios”.

El CVSS es información muy útil, pero no representa por sí solo el riesgo específico para una organización.

Una vulnerabilidad debería priorizarse considerando diferentes variables.

Cómo priorizar correctamente una vulnerabilidad

Una estrategia de priorización puede considerar al menos:

severidad técnica: por ejemplo, CVSS;
explotación conocida: si existen evidencias de ataques reales;
exposición: Internet, redes internas, segmentos restringidos;
criticidad del activo: qué función cumple para el negocio;
datos almacenados: financieros, personales, credenciales, propiedad intelectual;
privilegios necesarios: si puede explotarse sin autenticación;
complejidad de explotación;
existencia de exploit público;
controles compensatorios: segmentación, WAF, EDR, firewall, restricciones de acceso;
impacto potencial: confidencialidad, integridad y disponibilidad.

Una vulnerabilidad CVSS 10 no siempre es el mayor riesgo

Supongamos que una empresa tiene dos vulnerabilidades:

Vulnerabilidad A

CVSS 10.0.
Servidor de laboratorio.
No está publicado en Internet.
Segmentado.
No contiene información sensible.

Vulnerabilidad B

CVSS 8.8.
Firewall o VPN corporativa.
Expuesto directamente a Internet.
Existe explotación activa conocida.
Permite acceso inicial a la red.

Priorizar automáticamente la vulnerabilidad A porque tiene una puntuación numérica superior podría ser una decisión incorrecta.

La vulnerabilidad B puede representar un riesgo considerablemente mayor para la organización.

CISA KEV: saber qué vulnerabilidades están siendo explotadas

Una fuente especialmente útil para priorización es el Known Exploited Vulnerabilities Catalog (KEV) de CISA.

Este catálogo contiene vulnerabilidades para las que existe evidencia de explotación real y CISA recomienda utilizarlo como una de las entradas para los procesos de priorización de vulnerabilidades.

Puede consultarse gratuitamente en CISA Known Exploited Vulnerabilities Catalog.

Para una empresa, una vulnerabilidad presente en KEV y expuesta en un activo relevante debería recibir una atención muy diferente a la de un hallazgo teórico sin explotación conocida.

¿Qué es EPSS?

Otra referencia que puede complementar la priorización es EPSS (Exploit Prediction Scoring System).

EPSS intenta estimar la probabilidad de que una vulnerabilidad publicada sea explotada en un período próximo basándose en datos observados y comportamiento real de amenazas.

Puede utilizarse junto con CVSS, KEV y contexto interno para evitar que el equipo dedique todos sus recursos a vulnerabilidades que técnicamente tienen alta severidad pero presentan una probabilidad de explotación comparativamente baja.

La información oficial se encuentra en FIRST – Exploit Prediction Scoring System.

Detectar no sirve si nadie remedia

Una organización puede tener la mejor herramienta de escaneo del mercado y continuar siendo vulnerable si los hallazgos nunca se convierten en acciones.

Por eso debería existir un proceso formal que determine:

quién recibe las vulnerabilidades;
quién es responsable de corregirlas;
qué plazo corresponde según el riesgo;
qué ocurre cuando no pueden corregirse;
quién acepta formalmente una excepción;
cómo se valida posteriormente la corrección;
cómo se informa el estado a los responsables de seguridad y dirección.

Definir SLA de remediación

Una práctica recomendable es definir tiempos máximos de tratamiento según riesgo.

Por ejemplo, una organización podría establecer internamente:

Prioridad Ejemplo de objetivo interno Crítica / explotación activa Atención inmediata o dentro de pocos días. Alta Corrección prioritaria dentro de un plazo reducido. Media Incluir en el ciclo regular de mantenimiento. Baja Planificar según riesgo y disponibilidad de recursos.

Estos plazos no deberían copiarse mecánicamente. Cada organización debería definirlos en función de sus riesgos, requisitos regulatorios, criticidad, capacidad operativa y acuerdos internos.

También deberían existir mecanismos de emergencia para vulnerabilidades que requieran una acción mucho más rápida que el ciclo normal de mantenimiento.

¿Qué pasa si no puedo aplicar el parche?

No todas las vulnerabilidades pueden corregirse inmediatamente.

Algunos sistemas presentan restricciones como:

software heredado;
dependencias con aplicaciones críticas;
equipamiento sin soporte;
restricciones impuestas por fabricantes;
riesgo operacional durante la actualización;
imposibilidad temporal de detener el servicio.

En estos casos no debería simplemente ignorarse el hallazgo.

Puede ser necesario implementar controles compensatorios, por ejemplo:

segmentación de red;
restricción de acceso;
reglas específicas de firewall;
WAF;
EDR;
monitoreo reforzado;
deshabilitación de funciones vulnerables;
restricciones de privilegios.

La excepción debería quedar documentada, incluyendo el riesgo, los controles compensatorios, el responsable de aceptarlo y una fecha de revisión.

El MCU 5.0 contempla específicamente la identificación de activos que por su tecnología no puedan actualizarse y la documentación de controles compensatorios.

Después de remediar hay que volver a escanear

La validación constituye la última etapa del proceso de Agesic y es fundamental.

Después de aplicar un parche o modificar una configuración debería comprobarse que:

la vulnerabilidad dejó de detectarse;
el cambio fue aplicado al activo correcto;
no quedaron otros sistemas afectados;
la corrección no produjo efectos no deseados;
el hallazgo puede cerrarse con evidencia.

Esto suele realizarse mediante un rescan específico de los activos remediados.

Un ticket marcado como “solucionado” no equivale necesariamente a una vulnerabilidad solucionada.

Gestión de vulnerabilidades y gestión de parches tampoco son exactamente lo mismo

La gestión de parches forma parte de la gestión de vulnerabilidades, pero no todas las vulnerabilidades se solucionan instalando una actualización.

Un hallazgo puede requerir:

instalar un parche;
actualizar una versión;
modificar una configuración;
cerrar un puerto;
deshabilitar un protocolo;
cambiar permisos;
eliminar software no autorizado;
reemplazar un producto fuera de soporte;
aplicar un control compensatorio.

NIST trata la gestión empresarial de parches como una actividad preventiva continua e incluye dentro del proceso la identificación, priorización, instalación y verificación de actualizaciones.

Puede consultarse NIST SP 800-40 Rev. 4 – Guide to Enterprise Patch Management Planning.

¿Qué relación tiene esto con ISO 27001?

ISO/IEC 27001:2022 incorpora dentro de su conjunto de controles la gestión de vulnerabilidades técnicas.

Una organización que utiliza ISO 27001 como marco debería disponer de procesos para obtener información sobre vulnerabilidades relevantes, evaluar su exposición y adoptar acciones apropiadas.

Esto no significa simplemente presentar un informe anual de un scanner.

Un auditor puede esperar evidencias relacionadas con:

proceso o procedimiento de gestión;
responsabilidades;
inventario de activos;
fuentes de información sobre vulnerabilidades;
resultados de evaluaciones;
criterios de priorización;
tratamiento de hallazgos;
gestión de excepciones;
evidencia de remediación.

Si tu organización trabaja con ISO 27001 también podés consultar nuestra guía sobre ISO 27001 en Uruguay.

Gestión de vulnerabilidades y pentesting: ¿cuál es la diferencia?

También es frecuente confundir un análisis de vulnerabilidades con una prueba de penetración.

Evaluación de vulnerabilidades Pentest / Ethical Hacking Busca identificar vulnerabilidades conocidas de forma amplia. Busca determinar qué vulnerabilidades pueden explotarse realmente y hasta dónde podría llegar un atacante. Altamente automatizable. Requiere una participación humana significativamente mayor. Puede ejecutarse con mucha frecuencia. Normalmente se realiza con menor frecuencia o ante cambios relevantes. Ideal para gestión continua. Ideal para validar escenarios de ataque y controles. Puede generar falsos positivos que deben analizarse. El especialista intenta validar y contextualizar los hallazgos.

Una práctica no sustituye necesariamente a la otra.

El propio MCU 5.0 contempla evaluaciones de vulnerabilidades y pruebas de intrusión dentro de sus mecanismos de revisión de seguridad.

Podés conocer más sobre nuestro servicio de Ethical Hacking y Pentesting.

Errores frecuentes en la gestión de vulnerabilidades

Algunos problemas que encontramos frecuentemente en las organizaciones son:

Escanear solamente una vez al año.
No utilizar credenciales en sistemas donde sería conveniente hacerlo.
No conocer todos los activos que deberían ser evaluados.
Escanear únicamente servidores y olvidar endpoints, equipos de red o servicios externos.
Priorizar exclusivamente por CVSS.
No definir responsables para cada hallazgo.
No establecer tiempos de remediación.
Aceptar excepciones indefinidamente sin revisión.
No volver a escanear después de aplicar las correcciones.
No informar métricas a los responsables de seguridad.

¿Qué métricas debería mirar una empresa?

Un informe mensual de vulnerabilidades debería mostrar más que la cantidad total de hallazgos.

Algunas métricas útiles son:

porcentaje de activos cubiertos por el escaneo;
porcentaje de activos escaneados con autenticación;
cantidad de vulnerabilidades por nivel de riesgo;
vulnerabilidades nuevas;
vulnerabilidades remediadas;
vulnerabilidades vencidas respecto del SLA;
tiempo medio de remediación;
vulnerabilidades con explotación conocida;
activos con mayor exposición acumulada;
excepciones y riesgos aceptados;
evolución respecto de períodos anteriores.

Una de las métricas más importantes es la tendencia.

Encontrar 500 vulnerabilidades en un mes no necesariamente significa que la situación sea peor que encontrar 100. Si aumentó la cobertura del escaneo, por ejemplo, el incremento puede ser consecuencia de una mejor capacidad de detección.

Cómo sería un proceso de gestión de vulnerabilidades razonable

En términos prácticos, un ciclo podría funcionar de la siguiente forma:

Mantener actualizado el inventario.
Definir el alcance de los activos que deben evaluarse.
Realizar escaneos periódicos internos y externos según corresponda.
Analizar y depurar resultados.
Priorizar utilizando riesgo técnico y contexto empresarial.
Asignar responsables y tiempos de tratamiento.
Aplicar parches o mitigaciones.
Documentar excepciones.
Realizar rescans para validar las correcciones.
Reportar métricas y tendencias.
Repetir el ciclo.

Lo importante es precisamente el último punto: volver a empezar.

¿Puede tercerizarse la gestión de vulnerabilidades?

Sí.

Para muchas organizaciones el principal problema no es adquirir una herramienta de escaneo, sino contar con las horas y los conocimientos necesarios para operar el proceso permanentemente.

Un servicio gestionado puede encargarse de actividades como:

programación de evaluaciones;
mantenimiento del alcance;
análisis técnico de resultados;
eliminación o análisis de falsos positivos;
priorización por riesgo;
coordinación con infraestructura;
seguimiento de remediaciones;
rescans;
gestión de excepciones;
reportes técnicos y ejecutivos.

Esto permite convertir una herramienta que genera reportes en un proceso real de reducción de riesgo.

Gestión de vulnerabilidades como servicio

En InfoSecura ayudamos a organizaciones a implementar y operar procesos continuos de gestión de vulnerabilidades dentro de nuestro servicio de vSecOps.

El servicio puede incluir:

evaluaciones periódicas de vulnerabilidades;
escaneos autenticados y no autenticados;
análisis y priorización de hallazgos;
seguimiento de remediaciones;
validación mediante rescans;
gestión de excepciones;
asesoramiento al equipo de infraestructura;
reportes técnicos y ejecutivos;
alineación con CIS Controls, ISO 27001 y MCU 5.0.

El objetivo no es simplemente entregar una lista de vulnerabilidades, sino ayudar a que la organización pueda responder tres preguntas:

¿Qué tenemos que corregir primero? ¿Quién debe hacerlo? ¿Y cómo comprobamos que realmente quedó solucionado?

Conocé nuestro servicio de vSecOps →

Preguntas frecuentes sobre gestión de vulnerabilidades

¿Cada cuánto debería una empresa hacer un escaneo de vulnerabilidades?

Depende del riesgo y de los activos evaluados. Agesic recomienda evaluaciones mensuales en su guía de gestión de vulnerabilidades. CIS Controls v8 establece como referencia evaluaciones trimestrales o más frecuentes para activos internos y mensuales o más frecuentes para activos expuestos externamente. El MCU 5.0 incorpora además un mínimo semestral dentro de su control SO.1-8 de Nivel 3.

¿Un escaneo anual es suficiente?

Para la mayoría de los entornos empresariales actuales, un único escaneo anual deja una ventana excesivamente amplia durante la cual pueden aparecer nuevas vulnerabilidades. Una estrategia basada en riesgo normalmente requiere una frecuencia mayor y evaluaciones extraordinarias ante cambios o vulnerabilidades críticas.

¿Conviene hacer un escaneo autenticado?

Sí, especialmente en activos internos. La autenticación permite detectar parches faltantes, versiones de software, configuraciones y vulnerabilidades que podrían no ser visibles únicamente desde la red. Los escaneos autenticados y no autenticados pueden complementarse.

¿Nessus hace un pentest?

No. Nessus es principalmente una plataforma de evaluación de vulnerabilidades. Un pentest implica análisis y validación manual, explotación controlada y evaluación de escenarios de ataque. Son actividades relacionadas pero diferentes.

¿Tengo que corregir primero todas las vulnerabilidades con CVSS 10?

No necesariamente. CVSS es uno de los factores que deberían considerarse. También deben evaluarse la criticidad del activo, exposición, explotación conocida, disponibilidad de exploits, impacto para el negocio y controles compensatorios existentes.

¿Qué hago si una vulnerabilidad no puede corregirse?

La organización debería analizar el riesgo, implementar controles compensatorios cuando sea posible y documentar formalmente la excepción, incluyendo responsable, justificación y fecha de revisión.

¿Cómo sé que una vulnerabilidad realmente fue corregida?

Después de la remediación debería realizarse una validación, normalmente mediante un nuevo escaneo del activo afectado. La vulnerabilidad debería cerrarse únicamente cuando exista evidencia de que dejó de estar presente o que el riesgo fue tratado adecuadamente.

¿Gestión de vulnerabilidades es lo mismo que gestión de parches?

No. La aplicación de parches es una de las posibles formas de remediar vulnerabilidades. Otros hallazgos pueden requerir cambios de configuración, actualización de versiones, restricciones de acceso, eliminación de software o controles compensatorios.

Fuentes y referencias

Contenido actualizado a septiembre de 2026. Las frecuencias y tiempos de remediación deben definirse según los riesgos, requisitos regulatorios, criticidad y características de cada organización. Las referencias incluidas representan marcos y recomendaciones diferentes y no deben interpretarse como una obligación universal aplicable a todas las empresas.