Las necesarias hacen funcionar el sitio. Las demás miden qué páginas ayudan y qué anuncios traen a quien necesita a DM11. Tú eliges, y puedes revisarlo desde el pie de página.
GESTIÓN DE VULNERABILIDADES
Casi toda empresa que contrata escaneo descubre lo mismo: encontrar es la parte barata. El informe vuelve con cientos de elementos, el equipo corrige lo que puede, y seis meses después los mismos elementos siguen ahí, ahora acompañados de otros nuevos. La gestión de vulnerabilidades es el trabajo que convierte ese informe en una cola que avanza, con un orden definido por riesgo de negocio y alguien responsable de perseguirla hasta que el elemento desaparezca.
Este es un trabajo de rutina, y no un evento. No sustituye a la prueba de intrusión, que demuestra lo que un atacante consigue hacer, y la prueba de intrusión no sustituye a esta rutina, que cubre el año entero. Donde una exigencia formal pide las dos cosas, como en el PCI DSS, se contratan juntas y con alcances separados.
Quién conduce el trabajo
Análisis de vulnerabilidades con Qualys Certified Specialist
CEH, hacker ético certificado por EC-Council
CISA, auditoría de sistemas de información
17 años de gobernanza, riesgos y cumplimiento
QUÉ ES
La gestión de vulnerabilidades es la rutina de descubrir qué está expuesto, decidir qué importa primero, corregir y comprobar que la corrección funcionó. Cada una de esas cuatro etapas falla por un motivo distinto, y la que más falla no es el descubrimiento. Es la decisión de prioridad, porque exige a alguien que conozca el negocio y tenga mandato para decir que el elemento de gravedad alta puede esperar y el de gravedad media no.
Es el punto que casi todo el mundo se salta y el que más compromete el resto. Un informe que dice que el 94% de los activos está al día responde por el 94% de los activos que el escaneo vio, y no de lo que la empresa tiene. Lo que suele quedar fuera es siempre parecido: equipos de red antiguos, un sistema que un proveedor opera solo, un entorno de nube contratado por un área y la máquina que nadie sabe de quién es. La primera medición útil no es la cantidad de fallos, es la diferencia entre lo que dice el inventario y lo que encontró el escaneo.
El CVSS es una escala pública que describe cuán grave es un fallo en abstracto, y es útil exactamente para eso. Lo que no sabe es dónde está ese sistema en tu empresa, qué guarda, si es alcanzable desde fuera y si alguien lo está explotando ahora. Un fallo de gravedad media en un servidor expuesto que guarda datos de cliente gana a un fallo de gravedad alta en una máquina aislada de laboratorio, todos los días. Ordenar la cola solo por la nota es la forma más común de gastar el año corrigiendo lo que no cambia el riesgo.
La primera es la gravedad técnica, que el CVSS entrega gratis. La segunda es la criticidad de negocio: qué sostiene ese sistema, y qué pasa si se para o se filtra. La tercera es si el fallo se está explotando en el mundo real, porque un fallo antiguo con explotación conocida es más peligroso que uno nuevo y teórico. Solo la primera viene lista de la herramienta. Las otras dos dependen del inventario y de una conversación con quien opera, y eso es lo que separa la gestión de vulnerabilidades de una suscripción de escáner.
No publicamos números de plazo porque no son nuestros: quien define cuánto puede esperar cada gravedad es la empresa, junto con quien opera la TI. Lo que hace la DM11 es ayudar a llegar a un acuerdo que sobreviva al día a día, con el criterio de excepción escrito y con fecha de revisión. El punto es este: sin plazo acordado, la corrección compite con el ticket del día y pierde siempre, y cuando la TI está externalizada eso tiene que estar en el contrato, o no ocurre.
CUÁNDO TIENE SENTIDO
Las tres terminan en el mismo sitio: hay información sobre fallos y no hay proceso que la convierta en reducción de riesgo.
Es el caso más común. La herramienta se compró, corre, genera informe, y el informe se archiva. No falta tecnología: falta plazo acordado por gravedad, responsable por elemento y alguien con la tarea explícita de perseguir. Cuando la TI la opera un tercero, falta también la cláusula de contrato que hace que la corrección compita en igualdad con el ticket del día.
El PCI DSS exige escaneo trimestral a quien procesa tarjetas, además de la prueba anual. Un cliente grande en due diligence pregunta con qué frecuencia escanea la empresa y qué hace con el resultado, y la segunda parte de la pregunta suele no tener respuesta. Aquí el entregable que importa no es el informe, es el registro de que la cola fue perseguida.
Nube contratada por área, aplicación nueva cada trimestre, un proveedor que opera un sistema entero, una fusión que juntó dos redes. En ese escenario la primera entrega útil no es el escaneo, es el inventario: sin él no hay forma de saber qué quedó fuera, y todo porcentaje de cobertura es una suposición con apariencia de dato.
TRADUCIENDO LA PETICIÓN
Las cuatro formas en que llega la petición, con lo que significa cada una en la práctica y lo que cambia el tamaño del trabajo.
| Qué pidieron | Qué significa realmente | Qué cambia el tamaño |
|---|---|---|
| Queremos contratar escaneo de vulnerabilidades | Descubrimiento recurrente de lo que está expuesto, con revisión humana del resultado para separar hallazgo real de falso positivo. | Cantidad y diversidad de activos, si la nube entra en el mismo ciclo que la red, y si hay entornos a los que solo accede el proveedor. |
| Necesitamos un programa continuo | El ciclo entero: inventario, descubrimiento, validación, priorización, seguimiento de la corrección y medición de lo que cerró. | Si ya existe inventario, cuántos equipos corrigen, si la TI es propia o externalizada, y si hay acuerdo de plazo por gravedad. |
| El cliente pidió evidencia de que corregimos | Lo que va a leer un tercero es el registro del ciclo, y no la lista de hallazgos: qué se encontró, qué se corrigió, qué se aceptó y con qué justificación. | El periodo que cubre quien lo exige, y si las excepciones deben estar formalizadas con responsable y fecha de revisión. |
| Queremos priorizar mejor lo que ya encontramos | Trabajo de repriorización sobre la base existente, cruzando gravedad técnica con criticidad de negocio y explotación conocida. | Tamaño de la cola acumulada, si los activos tienen responsable definido y si existe clasificación de lo que sostiene cada sistema. |
Ninguno de estos empieza por comprar una herramienta. Cuando ya hay una, el trabajo suele ser hacerla rendir, y eso es más barato que cambiarla.
HISTORIAS
Cambiamos los nombres de los clientes con el mismo sigilo que va a proteger a tu empresa después. Los nombres cambian, el patrón de los problemas se repite. Cuando el cliente lo autoriza, mostramos referencias con nombre en una conversación.
Servicios financieros
El escaneo ocurría en plazo, el informe salía y se iba a una carpeta. El equipo de infraestructura corregía lo que podía entre un ticket y otro, sin plazo definido y sin un orden que alguien hubiera decidido. Los elementos de arriba eran siempre los mismos, y nadie sabía decir si eso era malo o normal.
No cambiamos la herramienta. Levantamos el inventario para descubrir qué no estaba viendo, definimos responsable por activo y nos sentamos con quien opera para acordar plazo por gravedad, con criterio de excepción escrito. La cola pasó a ordenarse por gravedad, criticidad del sistema y existencia de explotación conocida, y no por la nota aislada.
Varios elementos de lo alto de la lista antigua bajaron, porque estaban en entornos aislados, y elementos de gravedad media en servidores expuestos subieron. A partir del tercer ciclo la edad media de la cola empezó a bajar, que es el número que la dirección sigue desde entonces.
Tecnología
El informe trimestral mostraba un porcentaje alto de activos al día, y la empresa presentaba ese número en due diligence. Lo que nadie había medido era el denominador: el escaneo cubría la red corporativa, y no cubría las cuentas de nube abiertas por áreas de producto ni el entorno que un proveedor operaba solo.
Reconciliamos las listas que ya existían en sitios distintos, la de TI, la de finanzas y la de quien firma contratos, y el inventario pasó a venir de la propia cuenta de nube en lugar de una hoja mantenida a mano. Lo que opera el proveedor se convirtió en conversación contractual antes que técnica: quién escanea, con qué frecuencia, quién recibe y en qué plazo corrige.
El porcentaje bajó en el primer informe posterior al cambio, y esa bajada fue la mejor noticia del proyecto: por primera vez el número describía el entorno entero. La empresa dejó de presentar cobertura en due diligence y pasó a presentar cobertura junto con la diferencia medida contra el inventario.
Comercio electrónico
La exigencia de escaneo trimestral se cumplía, y el auditor pidió otra cosa: la prueba de que los hallazgos habían sido tratados. Había cuatro informes de descubrimiento y ningún registro de corrección, de aceptación de riesgo o de excepción. Lo que se había resuelto estaba resuelto, y nadie conseguía mostrarlo.
Montamos el registro del ciclo en lugar de otro informe de hallazgos: qué se encontró, qué se corrigió con la fecha, qué se aceptó y por quién, y qué quedó como excepción con responsable y fecha de revisión. La comprobación de que la corrección funcionó pasó a hacerse con un nuevo escaneo, y no con la palabra de quien corrigió.
La auditoría siguiente recibió el registro del ciclo y no pidió nada más. Un efecto lateral apareció pronto: con la excepción necesitando responsable y fecha, el número de excepciones informales bajó solo, porque varias existían únicamente por no haber sido escritas.
CÓMO LO CONDUCIMOS
Lo que separa este trabajo de una suscripción de escáner es que cada etapa produce una medición, y las mediciones dicen si el riesgo está bajando o solo cambiando de nombre.
Empieza aquí porque todo lo demás depende de esto. Levantamos los activos, reconciliamos las listas que ya existen en sitios distintos, la de TI, la de finanzas y la de quien firma contratos, y definimos responsable por elemento. Solo entonces la cobertura del escaneo significa algo, porque se mide contra el inventario y no contra sí misma.
Inventario conciliado, con responsable y criticidad por activo
Qué sostiene cada sistema, para que la priorización tenga base
Entornos que hoy quedan fuera del escaneo, listados con el motivo
Cobertura medida como la diferencia entre inventario y lo que el escaneo alcanza
Lo que pasa a medirseLa diferencia entre lo que la empresa tiene y lo que el escaneo ve, en número.
El escaneo corre en la periodicidad acordada, y el resultado pasa por revisión humana antes de convertirse en tarea. Esa revisión existe por un motivo práctico: un falso positivo entregado como tarea quema la confianza del equipo que corrige, y después de dos o tres veces pasa a tratar la cola entera como ruido. Lo que sale de aquí es una lista validada, y no la exportación de la herramienta.
Escaneo recurrente, con la periodicidad acordada en contrato
Revisión humana del resultado, separando hallazgo real de falso positivo
Hallazgo crítico comunicado fuera del ciclo, sin esperar al informe
Registro de lo que se descartó y por qué
Lo que pasa a medirseLista validada, con la tasa de falso positivo seguida ciclo a ciclo.
Es la etapa que decide si el año se gasta bien. Cruzamos la gravedad técnica con la criticidad del activo y con la información de explotación conocida en el mundo real, y la cola sale ordenada por riesgo y no por nota. Aquí también se define el plazo por gravedad, junto con quien opera, y el criterio para registrar una excepción con responsable y fecha de revisión.
Cola ordenada por gravedad, criticidad de negocio y explotación conocida
Plazo por gravedad acordado con quien opera, y no publicado por nosotros
Excepciones registradas con responsable, motivo y fecha de revisión
Derivación al equipo responsable, con el elemento ya asignado
Lo que pasa a medirseCada elemento tiene responsable, plazo y una razón escrita para estar en esa posición.
La etapa que convierte el informe en reducción de riesgo. Seguimos la cola hasta que el elemento desaparece del ciclo siguiente, comprobamos con un nuevo escaneo que la corrección funcionó, y medimos lo que importa: edad media de la cola, cuántos elementos cerraron en plazo y cuántos se reabrieron. Ese registro es lo que piden la auditoría y el cliente, más que la lista de hallazgos.
Comprobación con nuevo escaneo de que la corrección funcionó
Edad de la cola, elementos cerrados en plazo y reabiertos, medidos por ciclo
Informe de ciclo con lo que cerró, lo que quedó y la justificación de lo que quedó
Registro listo para auditoría y para el cuestionario del cliente
Lo que pasa a medirseLa cola tiene edad media medida, y baja de un ciclo al siguiente.
CON QUÉ FRECUENCIA
No publicamos periodicidad estándar ni plazo de corrección, porque los dos dependen de tu entorno y de un acuerdo con quien opera. Estos son los tres factores que más mueven la cadencia, y la primera conversación ya muestra en cuál está tu empresa.
Cuando existe, define el suelo y no el techo. El PCI DSS exige escaneo trimestral a quien procesa tarjetas, y un cliente grande suele preguntar la periodicidad en el cuestionario de due diligence. Fuera de una exigencia formal, la cadencia es una elección, y la elección correcta depende de los dos factores de abajo.
Un entorno estable, con pocos cambios por trimestre, sostiene un ciclo más espaciado sin perder nada. Un entorno donde entra una aplicación nueva cada mes, o donde la nube crece por decisión de un área, necesita un ciclo más corto, o el escaneo siempre describe un entorno que ya cambió.
Este es el factor que más gente olvida al elegir la cadencia. Escanear más rápido de lo que el equipo consigue corregir no reduce riesgo: aumenta la cola y el desánimo de quien la recibe. La cadencia tiene que caber en la capacidad de corrección, o el proceso produce informes en lugar de resultados.
PREGUNTAS FRECUENTES
Las dudas que aparecen en casi toda primera reunión, respondidas sin rodeos.
No, y la confusión sale cara en ambas direcciones. La gestión de vulnerabilidades es rutina del año entero y responde qué hay mal y en qué orden resolverlo. El pentest es un evento periódico y responde qué consigue hacer un atacante de verdad, encadenando fallos que aislados parecían pequeños. Uno cubre extensión, el otro cubre profundidad. Donde hay exigencia formal, se suelen pedir ambos: el PCI DSS, por ejemplo, exige escaneo trimestral y prueba anual. La comparación completa está en la página de pentest y análisis de vulnerabilidades.
En la mayoría de los casos, no. La herramienta rara vez es el problema: lo que suele faltar es inventario para saber qué no está viendo, plazo acordado por gravedad, responsable por elemento y alguien persiguiendo hasta que el elemento cierra. Hacer rendir la herramienta que ya existe es más barato y más rápido que cambiarla, y evita empezar el año en un proyecto de migración en lugar de en uno de reducción de riesgo. Si en algún momento la herramienta resulta ser el límite, eso aparece con evidencia y no como opinión.
No, y el motivo no es reserva comercial. El plazo de corrección no es nuestro para prometerlo: quien corrige es tu equipo o tu proveedor de TI, y un número publicado en la web se convertiría en compromiso de un tercero. Lo que hacemos es ayudar a llegar a un acuerdo de plazo por gravedad que sobreviva al día a día, con el criterio de excepción escrito, y perseguir contra ese acuerdo. Cuando la TI está externalizada, ese acuerdo tiene que estar en el contrato con el proveedor, o la corrección compite con el ticket del día y pierde siempre.
Resuelve un tercio de ella. El CVSS describe cuán grave es un fallo en abstracto, y es bueno en eso. Lo que no sabe es dónde está ese sistema en tu empresa, qué guarda, si es alcanzable desde fuera y si alguien lo está explotando ahora. Un fallo medio en un servidor expuesto con datos de cliente gana a uno alto en una máquina aislada de laboratorio. Las dos informaciones que faltan vienen del inventario y de una conversación con quien opera, y eso es lo que separa este trabajo de una suscripción de escáner.
Cuatro números, y ninguno es la cantidad de fallos encontrados, que sube cuando mejora la cobertura y por eso no sirve de termómetro. Medimos la cobertura, que es la diferencia entre el inventario y lo que el escaneo alcanza; la edad media de la cola, que muestra si avanza; cuántos elementos cerraron dentro del plazo acordado; y cuántos se reabrieron, que delata una corrección que no funcionó. Una quinta medición útil es la tasa de falso positivo, porque predice cuándo el equipo que corrige va a empezar a ignorar la cola.
Los dos entran en el mismo ciclo, y son justamente los que suelen quedar fuera y dejar el porcentaje bonito por omisión. En la nube, el inventario tiene que venir de la propia cuenta y no de una lista mantenida a mano, porque el crecimiento silencioso hoy viene casi todo de ahí. En lo que opera el proveedor, la conversación es contractual antes que técnica: quién escanea, con qué frecuencia, quién recibe el resultado y en qué plazo corrige. Sin eso escrito, el entorno existe en tu riesgo y no en tu informe.
Lo tiene, y con un alcance mucho menor de lo que el nombre sugiere. En una operación pequeña la gran ganancia no viene de una herramienta cara: viene de saber cuántos equipos y servicios existen, activar la actualización automática donde no haya motivo para no hacerlo, y tener a una persona mirando el resultado con regularidad. Eso solo ya quita de la mesa la mayor parte del riesgo de este frente, porque el ataque común usa un fallo conocido, con corrección publicada, en un programa que todo el mundo tiene. El programa completo entra después, cuando el entorno lo justifique.
Una conversación corta ya muestra cuánto de tu entorno no ve el escaneo de hoy, y qué tendría que existir para que la cola empiece a bajar. Si ya hay herramienta, el trabajo suele ser hacerla rendir.
Comparativas sobre este tema
Ver las 13 comparativasCenter for Internet Security · versão 8.1, de junho de 2024 · consultado el
NIST, instituto nacional de padrões e tecnologia dos Estados Unidos · NIST CSWP 29, publicado em 26/02/2024 · consultado el
OWASP Foundation · edição 2025, primeira revisão desde 2021 · consultado el
PCI Security Standards Council · PCI DSS v4.0.1 · consultado el
Esta página es informativa y describe cómo la DM11 lee y aplica las fuentes anteriores. No reproduce el texto de las normas, no sustituye la lectura del documento oficial y no sustituye una auditoría, una certificación, una evaluación independiente ni el asesoramiento jurídico. Donde la norma exige evaluación formal, quien la conduce es un organismo, auditoría o evaluador acreditado, siempre separado de quien preparó.