Sus equipos de red ejecutan firmware vulnerable. Simplemente no lo sabe.
El punto ciego de la seguridad empresarial que los atacantes ya han encontrado
1. La capa olvidada de su superficie de ataque
Todo equipo de seguridad tiene un proceso de gestión de vulnerabilidades. Qualys analiza los servidores. Tenable vigila los puestos. El SIEM recoge los registros. El Patch Tuesday figura en todos los calendarios.
Pero hágale a su equipo una pregunta sencilla: ¿cuáles de sus equipos de red ejecutan ahora mismo un firmware con una CVE crítica conocida?
La mayoría de las organizaciones no sabe responder. No porque no les importe, sino porque las herramientas nunca se diseñaron para ello.
La infraestructura de red es el esqueleto de su organización. Los switches transportan cada paquete. Los routers conectan cada sede. Los firewalls aplican cada política. Los puntos de acceso son la puerta de entrada de cada dispositivo inalámbrico de sus edificios. Estos equipos funcionan 24/7, rara vez se reinician y sus versiones de firmware casi nunca se siguen con el mismo rigor que el software de servidores y puestos.
Los puntos de acceso merecen una mención especial. Suelen desplegarse en gran número, se gestionan desde controladoras inalámbricas o plataformas en la nube independientes y se olvidan en cuanto están en servicio. Sin embargo, ejecutan pilas de firmware embebido completas y se sitúan en el borde físico de su red, al alcance de cualquiera con un adaptador Wi-Fi cerca.
La incómoda verdad: un switch o un punto de acceso que lleva 3 años con el mismo firmware tiene casi con toda seguridad al menos una vulnerabilidad crítica pública. La cuestión es si alguien en su organización sabe cuál.
2. Por qué el firmware es distinto y más difícil de seguir
Los escáneres de vulnerabilidades tradicionales se diseñaron en torno a sistemas operativos y aplicaciones. Consultan un inventario de software conocido, lo cruzan con una base de datos de CVE y generan una lista.
El firmware de los equipos de red rompe todas esas suposiciones:
Ninguna interfaz de consulta estándar: las versiones de firmware no se exponen mediante protocolos de escaneo como ocurre con las versiones de sistema operativo
Esquemas de versionado fragmentados:
15.2(4)M,ArubaOS 10.4.0.3,FortiOS 7.4.1; ninguno se corresponde limpiamente con los identificadores de CVE sin una lógica importante específica de cada fabricanteSensibilidad a la subversión: una misma rama de firmware puede ser vulnerable en una subversión y estar corregida en la siguiente
Heterogeneidad de protocolos: muchos equipos solo exponen su versión por CLI SSH, API REST propietarias o NETCONF, y cada fabricante lo hace de forma distinta
Complejidad multifabricante: Cisco + Aruba + Fortinet + Juniper + Ubiquiti + Ruckus multiplica esta fragmentación de forma exponencial, sobre todo cuando las controladoras inalámbricas gestionan cientos de puntos de acceso, cada uno con su propia versión de firmware
¿El resultado? La mayoría de las organizaciones no tiene ninguna visibilidad estructurada de la postura de seguridad del firmware de su infraestructura de red. En el mejor de los casos, una hoja de cálculo que alguien actualizó hace seis meses.
3. El problema del ciclo de vida: equipos en fin de vida a la vista de todos
Las vulnerabilidades del firmware son una parte del problema. El hardware en fin de vida (EoL) es la otra, y ambas están muy relacionadas.
Cuando un fabricante declara un equipo en fin de vida, deja de publicar actualizaciones de firmware. Cualquier CVE descubierta después de esa fecha nunca se corregirá. El equipo queda vulnerable de forma permanente por diseño.
Aun así, en la mayoría de los entornos empresariales los equipos en fin de vida siguen funcionando años después de que termine su ciclo. Los motivos son siempre los mismos: ciclos presupuestarios, complejidad de la migración y el hecho de que el switch «todavía funciona» y nadie se dio cuenta de que había quedado sin soporte. Los puntos de acceso son especialmente propensos: instalados en los falsos techos de decenas de plantas, suelen sobrevivir a su periodo de soporte simplemente porque nadie los sigue uno a uno.
Un equipo en fin de vida no es solo infraestructura envejecida: es una vulnerabilidad sin parche con carácter permanente. No va a llegar ninguna corrección. La única solución es sustituirlo.
El problema se agrava porque la información del ciclo de vida está dispersa en portales de fabricantes, boletines de producto y PDF que cambian sin previo aviso. No existe una fuente única de referencia. Seguir manualmente el fin de vida en un entorno multifabricante no es una tarea operativa realista.
La mayoría de las organizaciones descubre su exposición al fin de vida de una de estas dos formas: durante una auditoría de cumplimiento o después de un incidente. Ninguno de los dos es un buen momento para enterarse.
4. Seguir las CVE sin el contexto del firmware es solo ruido
Los equipos de seguridad reciben flujos de CVE. Están suscritos a los avisos de los fabricantes. Tienen reglas SIEM que saltan ante cada nueva CVE crítica. Pero sin saber exactamente qué versión de firmware ejecuta cada equipo, cada alerta de CVE carece de sentido.
¿Afecta realmente a su red la CVE-2025-20352, el zero-day crítico de SNMP que afecta a más de 2 millones de equipos Cisco?
Solo puede responder si sabe:
Qué equipos de su infraestructura ejecutan Cisco IOS o IOS-XE
La versión exacta de firmware de cada uno de esos equipos
Si esas versiones entran en el rango afectado del aviso
Si ya se ha desplegado un firmware corregido
Sin ese inventario, los equipos de seguridad tienen que elegir entre dos malas opciones: tratar cada CVE como si pudiera afectar a todos los equipos (fatiga de alertas, parálisis operativa) o suponer que los equipos están bien porque nadie ha informado de ningún problema (optimismo ciego).
Ninguna de las dos es una postura de seguridad. Ambas son un riesgo.
5. Cómo es una gestión de vulnerabilidades basada realmente en el firmware
Una gestión eficaz de la seguridad del firmware exige tres capacidades que funcionen juntas:
Un inventario de firmware preciso y en tiempo real
Necesita conocer, para cada equipo de su red, la versión exacta de firmware: no una estimación ni lo que se desplegó el trimestre pasado. El inventario debe actualizarse automáticamente a medida que se parchean o sustituyen los equipos y abarcar toda la diversidad de fabricantes de su entorno.
Correlación de las CVE a nivel de firmware
Una CVE que afecta a «Cisco IOS» no sirve de mucho. Una CVE que afecta a «Cisco IOS 15.2(4)M a 15.6(3)M» sí. El motor de vulnerabilidades debe asociar la versión exacta de firmware de cada equipo con los rangos afectados publicados en los avisos de los fabricantes y mostrar solo las CVE realmente pertinentes para su inventario.
Seguimiento del fin de vida por equipo
Cada equipo debe indicar su estado de ciclo de vida: con soporte, próximo al fin de vida o ya fuera de él. Este contexto convierte los datos de vulnerabilidades en una priorización accionable. Un equipo en fin de vida con dos CVE críticas es algo muy distinto de un equipo con soporte que puede parchearse.
6. Cómo lo resuelve ConnectMyAssets
ConnectMyAssets ha creado el módulo de vulnerabilidades que les faltaba a los equipos de red, y somos la única plataforma del mercado que aborda así la seguridad de los equipos de red.
Descubrimiento automático del firmware en toda su infraestructura
ConnectMyAssets se conecta a todos los equipos de su infraestructura de red mediante un motor de inteligencia multifabricante propio, diseñado para cubrir toda la diversidad de fabricantes, generaciones de firmware y modelos de comunicación de los entornos empresariales reales. Switches, routers, firewalls y puntos de acceso por igual. Sin agentes. Sin inventario manual. Sin hojas de cálculo. La CMDB se mantiene actualizada automáticamente en entornos multifabricante con Cisco, Aruba, Fortinet, Juniper, Ubiquiti, Ruckus y muchos otros, incluidas las controladoras inalámbricas que gestionan grandes despliegues de puntos de acceso.
Puntuación de las CVE ajustada al firmware
Nuestro motor de vulnerabilidades cruza la versión de firmware de cada equipo con una base de datos de CVE mantenida activamente y normalizada por fabricante. No nos limitamos a mostrar las CVE que mencionan el nombre de un fabricante: comprobamos los rangos de versiones afectadas exactos. El resultado es una lista de equipos realmente expuestos, con su puntuación CVSS e indicaciones de corrección. No una lista de equipos que podrían estar afectados.
Cuando se publica una nueva CVE crítica, como la CVE-2025-20352, el zero-day de SNMP que expuso a más de 2 millones de equipos Cisco, ConnectMyAssets le indica de inmediato qué equipos de su infraestructura ejecutan un firmware afectado. No en teoría. En concreto.
Visibilidad del fin de vida integrada
Cada equipo de su inventario en ConnectMyAssets indica su estado de ciclo de vida. Los equipos próximos al fin de vida se señalan de forma proactiva. Los que ya han superado su fecha de fin de vida aparecen en una vista dedicada, para que pueda planificar su sustitución en lugar de operar indefinidamente una infraestructura sin soporte.
Combinado con los datos de CVE del firmware, esto le da una matriz de riesgos que antes no existía: qué equipos están en fin de vida, cuáles tienen CVE sin corregir y cuáles ambas cosas, que son los que deben encabezar de inmediato su lista de remediación.
En resumen
La infraestructura de red es demasiado crítica para gestionarla con hojas de cálculo y PDF de fabricantes. Las vulnerabilidades del firmware son reales, se explotan activamente y afectan a equipos que sus herramientas de seguridad actuales nunca se diseñaron para cubrir.
Las organizaciones resilientes serán las que cierren esta brecha antes de que un atacante la encuentre. Eso significa saber exactamente qué firmware ejecuta cada equipo, exactamente qué CVE le afectan y exactamente qué equipos han superado su ciclo de vida con soporte.
Para eso se creó ConnectMyAssets.
