Qué es el catálogo KEV de CISA y por qué importa
KEV reúne vulnerabilidades con explotación observada y ayuda a priorizar parches. Qué indica el catálogo, a quién obliga CISA y cómo aplicarlo en una red propia.
El catálogo KEV de CISA reúne vulnerabilidades para las que existe evidencia de explotación real, y sirve como señal práctica para decidir qué corregir primero. KEV significa Known Exploited Vulnerabilities. No es una lista de todas las vulnerabilidades conocidas, ni un pronóstico de qué fallos podrían explotarse mañana: identifica CVE que CISA considera ya utilizados en ataques y los acompaña con datos de producto y acción recomendada.
Qué aparece en el catálogo
Cada entrada vincula un CVE con el fabricante y el producto afectado, un nombre breve, la fecha en que CISA la añadió y una acción requerida, normalmente instalar una actualización o aplicar una mitigación del proveedor. El registro también puede incluir una fecha límite de corrección para agencias federales y campos sobre campañas de ransomware o notas adicionales. Esa información permite automatizar búsquedas e informes, pero primero hay que resolver si el activo propio ejecuta realmente el producto y la versión afectada.
El CVE identifica una vulnerabilidad publicada; su presencia en KEV añade una señal distinta: hay evidencia de explotación en el mundo real. Eso no cuenta cuántas organizaciones han sido atacadas, no demuestra que una intrusión concreta haya usado esa falla y no reemplaza el aviso técnico del fabricante. Tampoco significa que todos los sistemas con ese nombre estén afectados: la versión, configuración y exposición importan. KEV es una lista de priorización, no un inventario de activos ni una evaluación completa de riesgo.
-InfraCrew dice: El catálogo te avisa de que el fuego ya ha prendido en algún lugar; aún tienes que comprobar si tu edificio comparte instalación.-
Por qué cambia la prioridad
Un equipo puede tener cientos de CVE abiertas y pocas ventanas de mantenimiento. La explotación observada cambia la conversación frente a ordenar todo solo por una puntuación de severidad: una vulnerabilidad con alta puntuación pero sin explotación conocida puede esperar detrás de una falla menos vistosa que ya se está usando contra sistemas expuestos. La prioridad final depende también del valor del activo, su ubicación, los controles existentes y el coste de interrumpirlo.
Para responsables de infraestructura, el catálogo convierte inteligencia dispersa sobre ataques en una cola accionable. Si un CVE KEV afecta a una puerta de acceso remoto, un hipervisor, un appliance de red o un servidor público, el riesgo operativo puede extenderse más allá de la máquina vulnerable. Un sistema comprometido en una posición privilegiada puede abrir caminos hacia otros activos; por eso, la clasificación del componente y su papel en la arquitectura forman parte de la decisión.
Cómo integrarlo en el trabajo diario
Cruza KEV con un inventario que incluya fabricante, producto, versión y ubicación, y confirma cada coincidencia con el aviso del proveedor. Evalúa exposición, privilegios, datos y dependencias; la fecha de alta ayuda a ordenar el seguimiento, pero no confirma por sí sola que una instalación esté afectada.
La acción recomendada puede ser instalar un parche, actualizar a una versión corregida o aplicar una mitigación cuando la actualización no esté disponible de inmediato. Valida la remediación en el sistema real: desplegar el paquete no siempre basta si el servicio no lo carga, el dispositivo no se reinicia cuando hace falta o una instancia olvidada queda fuera de la gestión central. Si no es posible parchear dentro de la ventana interna, registra una excepción con propietario, controles compensatorios y próxima revisión.
Las fechas de cumplimiento del catálogo tienen un matiz jurídico importante. CISA publica plazos para agencias federales civiles de Estados Unidos bajo sus directivas vinculantes; no son por defecto una obligación legal para cualquier empresa española o europea. Para el resto de organizaciones, KEV es una recomendación de priorización de CISA, que debe combinarse con regulación local, contratos y análisis propio. La directiva federal vigente, BOD 26-04, integra KEV en un enfoque de actualización basado en riesgo; conviene comprobar sus reglas actuales antes de reutilizar plazos antiguos de BOD 22-01.
-InfraCrew dice: Copiar la fecha límite federal a un calendario corporativo no convierte una obligación ajena en un plan de parcheo.-
Lo que KEV no resuelve
Que una vulnerabilidad no aparezca en el catálogo no demuestra que no sea peligrosa ni que no haya explotación fuera del conocimiento público de CISA. La ausencia en KEV no equivale a riesgo cero: el catálogo es selectivo y depende de evidencia y criterios de inclusión. Para priorizar el resto del backlog siguen haciendo falta el contexto del activo, los avisos del fabricante, la exposición, las señales de amenaza y la capacidad de recuperación.
KEV tampoco indica por sí solo cómo desplegar un parche sin causar una caída. En sistemas de producción, la urgencia debe convivir con una prueba razonable, respaldo, plan de reversión y ventana de cambio proporcional al riesgo. Un activo crítico expuesto puede requerir contención inmediata mientras se valida la actualización; una máquina aislada puede permitir un proceso distinto. La decisión útil une inteligencia de amenazas con topología y operación, en vez de transformar una lista externa en un botón automático de actualizar todo.
Diccionario de la Crew
CVE — Identificador público de una vulnerabilidad.
KEV — Catálogo de CISA sobre fallos explotados.
BOD 26-04 — Directiva federal de plazos para agencias civiles estadounidenses.
Mitigación — Control temporal que reduce exposición cuando el parche no está listo.