← Volver al blog
Publicado 14 de septiembre de 20267 min de lectura

Cómo usar la inteligencia de amenazas para priorizar vulnerabilidades

Threat IntelligencePrioritizationVulnerability Management

Las puntuaciones de severidad te dicen lo grave que podría ser una vulnerabilidad. La inteligencia de amenazas te dice si alguien lo está intentando de verdad. Esa diferencia es la que separa un backlog de miles de hallazgos "Altos" de una lista corta de cosas que realmente necesitan atención esta semana.

Pero la inteligencia de amenazas también hace mucho ruido. Los feeds se solapan, los foros exageran y un solo mensaje sobre una prueba de concepto puede desencadenar una alarma por un fallo que nunca llega a explotarse. En esta guía vemos qué señales de inteligencia merece la pena incorporar a la priorización, cómo ponderarlas y cómo conseguir que cambien de verdad lo que tus equipos corrigen.

Por qué la severidad no basta

CVSS mide las características técnicas de un fallo, no el interés del atacante. EPSS añade una estimación estadística de la probabilidad de explotación, lo que es una gran mejora, pero modela todo internet, no quién ataca a tu sector o a tu stack. La inteligencia de amenazas aporta evidencia: explotación confirmada, código de exploit funcional, conversaciones entre atacantes y campañas que afectan exactamente a los productos que usas.

Las señales que importan, de más fuerte a más débil

Explotación confirmada

La señal más fuerte es la evidencia de que una CVE se está explotando. La fuente pública más conocida es el catálogo CISA Known Exploited Vulnerabilities (KEV), que solo incluye una vulnerabilidad cuando hay evidencia fiable de explotación activa y una acción de remediación clara. Si aún no tratas KEV como nivel máximo, empieza por nuestra guía de CISA KEV. Los avisos de fabricante que indican que un fallo se está "explotando activamente" pertenecen al mismo nivel.

Asociación con ransomware

Algunas vulnerabilidades explotadas se sabe que las usan operadores de ransomware. KEV lo indica cuando se conoce, y muchas fuentes de inteligencia rastrean qué CVE aparecen en cadenas de intrusión de ransomware. Importa porque implica herramientas maduras y repetibles y un impacto alto. Estas CVE merecen los plazos de remediación más cortos que tengas.

Exploit público y armado

Un exploit funcional en un framework o repositorio público baja el listón de "atacante experto" a "cualquiera con un script". Distingue entre un exploit armado (fiable, empaquetado, fácil de ejecutar) y una prueba de concepto que solo demuestra un fallo o requiere mucho trabajo adicional. Ambos suben la prioridad, pero no por igual.

Conversaciones en el underground y comercio de PoC

Foros de hacking, mercados clandestinos, canales de Telegram y sitios de pegado son donde se discuten, venden y pulen los exploits antes de llegar a los frameworks públicos. Menciones de una CVE que afecta a tus productos, ofertas de venta de un exploit o peticiones de acceso a organizaciones que usan una tecnología concreta son alertas tempranas. Pueden darte días o semanas de margen, pero también son la señal más ruidosa y requieren una ponderación cuidadosa. Nuestro artículo sobre monitorización de la dark web explica cómo funcionan estas fuentes.

Relevancia del objetivo

Una campaña contra tu sector, tu región o una tecnología de la que dependes sube la prioridad de las vulnerabilidades relacionadas incluso antes de que se nombre una CVE concreta. Es contexto, no evidencia: úsalo para desempatar, no para anular señales más fuertes.

Cómo ponderar la inteligencia sin perseguir ruido

El objetivo es que la inteligencia suba hallazgos en la cola cuando sea creíble, sin que cada rumor reinicie tu sprint. Algunos principios:

  1. Puntúa la confianza de forma explícita. Una entrada en KEV es de confianza alta. Un aviso de fabricante, también. Un exploit detallado en un repositorio conocido, media o alta. Un único mensaje en un foro afirmando que existe un exploit es de confianza baja hasta que se corrobore. Pondera cada señal por su confianza, no solo por su presencia.
  2. Exige corroboración a las fuentes débiles. Una mención en el underground debe marcar la CVE para vigilancia. Dos fuentes independientes, o conversaciones más una PoC pública, deben subir su prioridad.
  3. Aplica caducidad. Lo que se comentó la semana pasada pesa más que lo del año pasado. Deja que las señales de baja confianza pierdan peso con el tiempo si no se renuevan. La explotación confirmada, en cambio, no debería caducar: un fallo explotado sigue siendo peligroso hasta que se parchea.
  4. Cruza con tu entorno real. La inteligencia sobre un producto que no usas es irrelevante. Sobre un producto instalado en un único servidor de pruebas aislado, pesa menos que sobre un sistema de producción expuesto. Une siempre la inteligencia con tu inventario y tu exposición a internet.
  5. Que la inteligencia sea una entrada, no toda la puntuación. Combínala con severidad, EPSS, exposición, criticidad del activo y controles compensatorios en un único modelo basado en riesgo.

Un escalonado sencillo que puedes adoptar

  • Nivel 1, actuar ya: explotación confirmada o asociación con ransomware, en un activo expuesto o crítico.
  • Nivel 2, actuar este ciclo: exploit público armado o conversaciones corroboradas en el underground, sobre un activo relevante; o explotación confirmada en un activo interno de menor criticidad.
  • Nivel 3, planificado: una única mención de baja confianza, PoC no armada o EPSS alto sin evidencia directa.
  • Nivel 4, SLA estándar: sin señal de inteligencia; se gestiona por severidad y contexto.

Asocia cada nivel a un plazo de remediación para que la inteligencia cambie fechas, no solo colores en un panel. Nuestra guía de SLA de remediación y MTTR explica cómo definirlos.

Cerrar el ciclo hacia la remediación

La inteligencia solo reduce el riesgo cuando llega a quien parchea. Eso implica:

  • Repriorizar de forma continua. Cuando una CVE entra en KEV o se disparan las conversaciones, los hallazgos afectados deben subir automáticamente, no en la próxima revisión mensual.
  • Actualizar los tickets abiertos. Si el ticket ya existe, sube su prioridad y su plazo y añade el motivo. No crees un duplicado.
  • Explicar el porqué. "Subido a Nivel 1: añadido a KEV, uso por ransomware, presente en 4 servidores expuestos a internet" consigue acción. Un cambio de puntuación sin explicación se ignora.
  • Verificar el cierre. Confirma con un nuevo escaneo que la corrección se aplicó y conserva la evidencia para auditorías.

Errores habituales

  • Tratar cada elemento del feed como urgente. Volumen no es riesgo. Sin filtros de confianza y relevancia, la inteligencia se convierte en otra fuente de fatiga de alertas.
  • Ignorar la inteligencia porque hace ruido. El error contrario: la explotación confirmada es el mejor indicador de lo que los atacantes usarán a continuación.
  • Tener la inteligencia en una herramienta aparte. Si los analistas la leen en una consola y los ingenieros trabajan desde otra cola, la señal rara vez cruza.

Preguntas frecuentes

¿Basta con KEV? Es una base excelente, pero es deliberadamente conservador y va por detrás de la explotación temprana. Las señales del underground y de exploits te ayudan a actuar antes de que una CVE entre en el catálogo.

¿Cómo evito reaccionar a falsos anuncios de exploits? Puntúalos como baja confianza, exige corroboración y deja que caduquen si no aparece nada más.

¿La inteligencia debe imponerse a la criticidad del activo? No, hay que combinarlas. Una explotación confirmada en un activo aislado y no crítico puede seguir por debajo del mismo fallo en un sistema de producción expuesto.

Cómo ayuda priorIQ.ai

OnGuardIQ monitoriza fuentes de la deep y dark web, foros de hacking, mercados clandestinos, canales de Telegram y sitios de pegado en busca de conversaciones sobre exploits y PoC de las CVE presentes en tu entorno, con resúmenes por IA y alertas priorizadas por relevancia. PriorIQ Core combina esas señales de amenaza activa con CVSS, EPSS, CISA KEV, disponibilidad de exploits y contexto de negocio, agrupa los hallazgos en acciones de remediación y los envía a Jira, ServiceNow o Freshservice, para que la inteligencia cambie lo que se corrige primero.

Descubre cómo encajan los módulos o Solicita una demo.