La mayoría de programas de gestión de vulnerabilidades no fallan porque falten herramientas. Fallan porque convierten el riesgo en una lista plana de hallazgos y tratan casi todo como si tuviera el mismo peso.
En la práctica, no lo tiene. Una vulnerabilidad interna, con controles compensatorios y sin vías claras hacia privilegios, identidad o datos sensibles, no tiene el mismo impacto potencial que una vulnerabilidad explotada activamente, presente en un activo expuesto a internet, combinable con credenciales robadas o situada en un plano crítico de administración.
Por eso la pregunta útil ya no es “cuántas vulnerabilidades tiene la empresa”, sino esta:
¿cuáles de ellas tienen más probabilidad de convertirse antes en compromiso real del negocio?
Ahí es donde una buena gestión de vulnerabilidades deja de ser un ejercicio de cumplimiento y pasa a ser una capacidad real de reducción de riesgo.
Qué es de verdad la gestión de vulnerabilidades y por qué muchas empresas la hacen mal
Gestionar vulnerabilidades no consiste en lanzar un escáner, exportar un CSV y abrir tickets. Un programa maduro debería cubrir al menos estas fases:
- descubrimiento e inventario de activos
- identificación de vulnerabilidades y malas configuraciones
- validación y enriquecimiento contextual
- priorización por riesgo real
- remediación o mitigación
- verificación del cierre
- revisión continua del proceso
Ese enfoque es importante porque la mayoría de los problemas aparecen justo entre fases, no dentro de una sola. Se detecta una vulnerabilidad, pero no se conoce el activo. Se abre un ticket, pero no hay propietario. Se aplica un parche, pero no se valida. Se reduce el ruido, pero no se ataca primero lo que de verdad puede comprometer la organización.
Muchas empresas tropiezan siempre en los mismos puntos.
1. Se prioriza por CVSS y no por contexto
CVSS es útil, pero no basta. No incorpora por sí solo la criticidad del activo, su exposición, la existencia de explotación real, la presencia de credenciales comprometidas, ni la facilidad de movimiento lateral.
2. Se ignora la exposición real
Una debilidad en un activo publicado en internet, en un portal remoto, un firewall, una VPN o una consola cloud no debería competir en igualdad con otra similar en un entorno interno bien segmentado.
3. No existe un inventario fiable
Sin inventario, la gestión de vulnerabilidades se convierte en ruido técnico. No basta con conocer la IP o el hostname. Hay que saber quién es el propietario, qué función cumple el activo, qué criticidad tiene y qué dependencias arrastra.
4. Se separa vulnerabilidad de identidad
Ese es uno de los errores más peligrosos hoy. Una vulnerabilidad aparentemente moderada puede volverse prioritaria si existe una cuenta comprometida, un token expuesto, una contraseña reutilizada o una cuenta de servicio sin gobierno real.
Si además la empresa no tiene una auditoría de seguridad informática reciente, suele pasar lo mismo: se ve el hallazgo, pero no el contexto.
La priorización correcta: no por severidad aislada, sino por probabilidad de compromiso
Una priorización útil debería responder a una lógica muy simple:
exploitabilidad + exposición + criticidad del activo + valor para el atacante + estado de identidad y credenciales + controles compensatorios
Este modelo no busca complejidad académica. Busca tomar mejores decisiones.
Explotación conocida
La primera criba debería separar lo que ya está siendo explotado o tiene evidencias sólidas de abuso real. Aquí es donde conviene revisar de forma continua el catálogo KEV de CISA y cruzarlo con el propio inventario de activos.
Si una vulnerabilidad forma parte de KEV, deja de ser solo “grave” y pasa a ser “relevante ahora”.
Exposición
Después hay que mirar dónde está el activo:
- internet-facing
- acceso remoto
- edge devices
- VPN
- firewalls
- consolas cloud
- portales de terceros
- servicios publicados
- APIs expuestas
Una vulnerabilidad en un activo de ese tipo suele merecer una atención mucho más rápida que otra equivalente en red interna.
Si la organización no tiene control sobre lo que realmente publica o mantiene visible desde fuera, aquí encaja reforzar la superficie de ataque externa.
Criticidad del activo
No todos los activos pesan igual. En la práctica, casi siempre deben ir por delante:
- identidad y acceso
- Microsoft 365
- Azure, AWS o GCP
- firewalls y VPN
- backup
- hipervisores
- servidores de administración
- ERP y sistemas críticos
- herramientas remotas
- directorio y federación
Capacidad de movimiento lateral o escalada
Hay hallazgos que quizá no tumban un sistema por sí solos, pero sí abren puertas valiosas: acceso a administración, lectura de secretos, salto a otras redes, abuso de confianza, persistencia o elevación de privilegios.
Controles compensatorios
Segmentación, MFA fuerte, hardening, logging útil, PAM, EDR maduro, allowlisting o acceso condicional pueden cambiar mucho la prioridad real. No eliminan el riesgo, pero sí pueden modificar el orden operativo de remediación.
Por qué las credenciales comprometidas cambian la prioridad técnica
Aquí suele haber una confusión importante. La exposición de credenciales no es solo un problema de IAM. También afecta de lleno a la gestión de vulnerabilidades, porque cambia la probabilidad de explotación y reduce el esfuerzo que necesita un atacante para convertir una debilidad técnica en incidente real.
Cuando una organización tiene señales de credenciales comprometidas, como por ejemplo:
- usuarios o correos corporativos filtrados
- contraseñas reutilizadas
- tokens expuestos
- sesiones robadas
- claves embebidas en scripts o automatizaciones
- cuentas de servicio sin rotación
- trazas de infostealer en endpoints
entonces el backlog técnico ya no debería leerse igual.
Una vulnerabilidad en un portal remoto, en Microsoft 365, en una consola cloud o en un sistema de identidad vale más para un atacante cuando ya existe material de acceso circulando o potencialmente válido.
Por eso la exposición de credenciales obliga a revisar conjuntamente:
- MFA real y no nominal
- acceso condicional
- privilegios
- cuentas de servicio
- secretos y claves
- logs de autenticación
- sesiones activas
- endpoints con posible infostealer
Si el foco está en Entra ID, permisos, acceso federado o exceso de privilegios, el complemento natural es revisar identidad, accesos y postura cloud.
Dark web, infostealers y credenciales expuestas: qué conviene decir y qué no
Aquí merece la pena ser muy riguroso.
No toda mención en dark web significa compromiso activo. Hay muchos casos en los que los datos son antiguos, incompletos, duplicados, revocados o sencillamente irrelevantes para el entorno actual.
Usar cualquier “dark web mention” como argumento de marketing alarmista es un error. Daña credibilidad y lleva a malas decisiones.
Lo serio no es “aparecer en dark web”. Lo serio es una combinación como esta:
- credenciales recientes o plausibles
- cuenta todavía activa
- contraseña o token no rotado
- acceso asociado a un plano crítico
- ausencia de MFA fuerte
- evidencias de reuse
- logs o actividad sospechosa
Cuando eso ocurre, la organización debería elevar prioridad sobre:
- VPN
- acceso remoto
- Microsoft 365
- cloud admin
- herramientas de administración
- federación
- cuentas privilegiadas
- cuentas de servicio
También debería plantearse si necesita apoyo de SOC gestionado para visibilidad continua o incluso activar respuesta a incidentes si ya existen indicios de abuso.
Qué activos deberían ir delante en cualquier backlog serio
Si el programa necesita foco inmediato, mi recomendación práctica es empezar por este orden.
1. Edge y acceso remoto
- firewalls
- VPN
- gateways
- reverse proxies
- bastiones
- appliances
- portales de acceso remoto
2. Identidad y control
- Active Directory
- Entra ID
- MFA
- PAM
- federación
- SSO
- servidores de identidad
3. Cloud y Microsoft 365
- tenants
- suscripciones
- planos de administración
- permisos excesivos
- secretos expuestos
- configuraciones inseguras
- integraciones híbridas
Para esto, muchas veces tiene sentido combinar Microsoft 365 Security con una revisión de seguridad cloud.
4. Aplicaciones y APIs expuestas
- paneles de administración
- portales publicados
- APIs externas
- repositorios inseguros
- componentes vulnerables
- autenticación débil
5. Sistemas críticos de negocio
- ERP
- backup
- producción
- finanzas
- administración remota
- plataformas de operación
Modelo práctico de priorización para empresas
Una manera útil y realista de ordenar hallazgos es puntuar cada uno con estas capas:
1. Explotación
- KEV o explotación confirmada: prioridad muy alta
- PoC pública madura: alta
- sin explotación conocida: media o variable
2. Exposición
- internet-facing: muy alta
- acceso remoto o terceros: alta
- red interna segmentada: media
- entorno aislado: baja
3. Criticidad del activo
- identidad, cloud admin, edge, backup, ERP: alta
- infraestructura secundaria: media
- laboratorio o no productivo: baja
4. Valor para el atacante
- escalada
- acceso a secretos
- persistencia
- salto lateral
- administración
5. Controles compensatorios
- MFA fuerte
- segmentación
- PAM
- EDR
- hardening
- logging útil
- acceso condicional
6. Señales de credenciales comprometidas
- dominio afectado en datasets recientes
- usuario activo
- contraseña reutilizada
- token expuesto
- cuenta de servicio sin rotación
- posible infostealer
Lo importante no es la perfección matemática. Lo importante es que el backlog deje de ser una lista de CVEs y pase a ser una lista de caminos plausibles hacia compromiso real.
Qué métricas sí sirven y cuáles engañan
Métricas útiles
- porcentaje de activos conocidos frente a activos descubiertos
- tiempo de remediación para KEV
- tiempo de remediación para activos expuestos a internet
- porcentaje de hallazgos verificados como corregidos
- porcentaje de cuentas privilegiadas con MFA fuerte
- backlog abierto en edge, identidad, cloud y Microsoft 365
- número de hallazgos críticos ligados a exposición externa
- número de credenciales comprometidas con validez operativa confirmada
Métricas engañosas
- número total de CVEs sin contexto
- porcentaje general de parcheo mezclando activos críticos y triviales
- cierre administrativo de tickets sin verificación
- “hemos escaneado todo” cuando no hay inventario fiable
- un único SLA para cualquier tipo de activo
Dónde suele romperse la remediación
En la mayoría de organizaciones, la remediación falla menos por falta de intención y más por una mezcla de fricciones operativas.
Dependencias de negocio
No siempre se puede parchear cuando seguridad quiere. Hay ventanas, validaciones, cambios, pruebas y responsables distintos.
Falta de ownership
Se detecta el hallazgo, pero nadie lo posee de verdad. Sin propietario, el backlog envejece.
Inventario incompleto
Sin contexto de activo, no se sabe qué pesa más ni quién debe actuar.
Exceso de findings
Si todo es urgente, nada lo es.
Ausencia de mitigaciones temporales
Cuando no puede corregirse hoy, al menos debería mitigarse hoy:
- despublicar
- segmentar
- restringir acceso
- bloquear rutas de explotación
- elevar monitorización
- resetear credenciales
- rotar secretos
- revisar acceso privilegiado
Si el objetivo es validar exposición explotable y no solo inventariar hallazgos, puede ser útil contrastarlo con pentesting o, en casos más complejos, con red team.
Qué debería hacer una empresa de forma urgente
Semana 1: ordenar visibilidad
- revisar inventario de activos críticos
- identificar exposición externa real
- mapear edge, identidad, cloud y acceso remoto
- localizar cuentas de servicio y secretos de alto riesgo
Semana 2: reordenar el backlog
- cruzar hallazgos con KEV
- separar edge, identidad, cloud y Microsoft 365
- diferenciar activos críticos de secundarios
- subir prioridad a vulnerabilidades combinables con credenciales robadas
Semana 3: revisar identidad y credenciales
- validar MFA fuerte
- revisar privilegios
- rotar secretos sensibles
- comprobar señales de reuse
- buscar indicios de infostealer o de actividad anómala
Semana 4: cerrar mejor
- definir SLAs distintos según tipo de riesgo
- verificar remediaciones
- medir backlog por criticidad real
- establecer reporting ejecutivo entendible
- decidir si hace falta apoyo continuo
Si el entorno ya arrastra complejidad técnica o regulatoria, muchas empresas obtienen más valor cuando combinan gestión de vulnerabilidades con auditoría de seguridad informática y monitorización continua mediante SOC gestionado.
Un buen programa de gestión de vulnerabilidades no persigue “cero hallazgos”. Persigue algo más realista y mucho más útil: reducir el camino que lleva desde una debilidad técnica hasta un compromiso operativo.
Para conseguirlo, una empresa tiene que dejar de mirar las vulnerabilidades como una lista plana y empezar a tratarlas como parte de un sistema de riesgo donde importan:
- la explotación real
- la exposición del activo
- la criticidad del entorno
- la identidad asociada
- el estado de las credenciales
- y la capacidad de respuesta
Hoy, gestionar vulnerabilidades sin cruzarlas con identidad, superficie expuesta y señales de credenciales comprometidas es quedarse a mitad del trabajo.
La pregunta correcta no es cuántas vulnerabilidades tiene la organización.
La pregunta correcta es esta:
¿cuáles de ellas podrían explotarse antes, combinarse mejor con credenciales robadas y causar más daño al negocio si no se corrigen ya?
Si quiere convertir la gestión de vulnerabilidades en una capacidad real de reducción de riesgo, no en un listado de findings, en Hard2bit podemos ayudarle a combinar:
- gestión de vulnerabilidades
- auditoría de seguridad informática
- superficie de ataque externa
- Microsoft 365 Security
- identidad, accesos y postura cloud
- SOC gestionado
- respuesta a incidentes
para priorizar mejor, corregir antes y reducir el riesgo operativo de forma medible.
Adrián González. CEO Har2bit CyberSecurity