Mientras todo el mundo discute qué modelo escribe el mejor código, un problema mucho más antiguo y mucho menos glamuroso está creciendo silenciosamente junto con cada nuevo centro de datos de IA: el controlador de gestión de la placa base, o BMC. Esta semana, investigadores de seguridad presentaron hallazgos según los cuales miles de servidores conectados a internet de grandes fabricantes pueden recibir puertas traseras de forma remota mediante fallos en estos controladores; algunos de ellos tienen más de una década. Esto no es una historia sobre IA en absoluto. Es una historia sobre el hardware en el que funciona la IA, y vale la pena entenderla si estás pensando de dónde surgirá la próxima ola de empleos de seguridad relacionados con la IA.

Qué es realmente un BMC y por qué da miedo

Un BMC es un pequeño ordenador independiente soldado a prácticamente todas las placas base de servidores empresariales. Ejecuta su propio sistema operativo, su propia pila de red y tiene su propia dirección IP, todo ello completamente independiente del sistema operativo y las aplicaciones que se ejecutan en el servidor principal. Los administradores utilizan los BMC para la gestión «lights-out» o «fuera de banda»: reiniciar una máquina, volver a grabar el firmware, reinstalar un sistema operativo, todo de forma remota y, lo que es crucial, mientras el servidor principal está apagado o no responde por completo.

Eso es exactamente lo que hace tan peligroso a un BMC comprometido. Un atacante que consigue entrar en uno no necesita que el sistema operativo anfitrión esté funcionando, no necesita eludir la seguridad de endpoint que tenga instalada y puede persistir después de reinstalar el sistema operativo, ya que el BMC reside por debajo y fuera de la capa que supervisan las herramientas normales de seguridad informática. Según la investigación difundida esta semana, el protocolo implicado con mayor frecuencia es IPMI, y los investigadores de seguridad llevan señalando esta clase de riesgo desde al menos 2013. En otras palabras: no se trata de un fallo nuevo, sino de una categoría de fallos antigua, conocida y estructuralmente difícil de corregir que la industria ha tolerado durante mucho más de una década.

Por qué esto importa más ahora, no menos

La expansión de la IA es, físicamente, una de las mayores oleadas de adquisición de servidores de la historia: filas y filas de servidores con GPU que entran en centros de datos nuevos y ampliados tan rápido como los proveedores pueden enviarlos. Todos esos servidores se entregan con un BMC, porque los BMC son la forma en que los operadores de centros de datos gestionan flotas a escala; no se puede entrar en un edificio del tamaño de un almacén y reiniciar manualmente diez mil máquinas. Así que el auge de la IA no solo está comprando capacidad de cómputo: por necesidad, está comprando una flota equivalente de pequeños ordenadores fuera de banda, poco supervisados y con un historial documentado de más de una década de vulnerabilidades críticas.

Esa es la deuda técnica: la velocidad de expansión está optimizada para montar las GPU en los racks e iniciar las ejecuciones de entrenamiento, no para auditar el firmware de gestión integrado en cada placa base que hay debajo. Según se informa, los investigadores responsables de la divulgación de esta semana describieron los BMC como una «superficie de ataque paralela, generalizada, poco supervisada y con pocos parches», una descripción anterior al auge de los centros de datos de IA, pero ese auge es lo que está multiplicando ahora mismo el número de BMC en producción.

El nicho que esto abre

Si estás trazando hacia dónde se dirigen las carreras de seguridad junto con la infraestructura de IA, la mayoría de las áreas obvias —red teaming de modelos, defensa contra la inyección de prompts, gobernanza de agentes— ya están saturadas y ya están bien cubiertas en otros ámbitos. La auditoría de seguridad del hardware y de los sistemas fuera de banda no lo está. Es un rincón poco glamuroso y nada atractivo de la seguridad de infraestructuras que no aparece en las ponencias principales sobre IA, y precisamente ahí está la oportunidad: la demanda crece con cada nuevo centro de datos, y la oferta de personas que entienden las superficies de ataque a nivel de firmware y fuera de banda es reducida porque se trata de un conjunto de habilidades realmente distinto del de la seguridad de aplicaciones o de la nube.

Cómo es realmente el trabajo, en términos concretos:

  • Conocimientos de firmware y protocolos. Entender IPMI (y sus puntos débiles conocidos, como el conjunto de cifrado 0, obsoleto desde hace mucho tiempo, que algunos dispositivos todavía distribuyen habilitado) lo suficientemente bien como para evaluar si una flota de servidores determinada está expuesta, no solo si es vulnerable en teoría.
  • Auditorías de segmentación de red. Comprobar si las interfaces de BMC/gestión están realmente aisladas en una red de gestión dedicada o si se puede acceder a ellas desde producción o desde internet en general; un control básico que, una y otra vez, resulta estar ausente en entornos reales.
  • Revisiones de credenciales y mantenimiento de parches. Los BMC suelen distribuirse con credenciales predeterminadas o establecidas por el proveedor y con un firmware que no forma parte del ciclo normal de parches del sistema operativo de un centro de datos, porque no es el sistema operativo: es fácil que quede fuera del ámbito de quien sea responsable del «parcheado».
  • Conocimiento de proveedores y de la cadena de suministro. El firmware de los BMC suele estar escrito por un pequeño número de proveedores especializados y se licencia a los fabricantes de servidores, por lo que un fallo en el código de un proveedor puede propagarse simultáneamente a muchas marcas de hardware; ese es exactamente el patrón de la divulgación de esta semana. Saber qué pila de firmware se encuentra debajo de cada marca de servidores forma parte del trabajo.

Cómo posicionarte realmente para esto

Este es un campo verdaderamente especializado, y es razonable mostrarse escéptico sobre cuántos puestos específicos se abrirán para él frente a que siga siendo una especialización dentro de los equipos existentes de infraestructura o seguridad; sé honesto contigo mismo: «auditor de seguridad de BMC» puede acabar siendo una habilidad que añadas a un puesto más amplio de seguridad de hardware/centros de datos, en lugar de convertirse en un título laboral por sí mismo. Pero, en cualquier caso, tienen sentido algunos pasos concretos y comprobables: familiarízate de forma práctica con IPMI y las herramientas de gestión fuera de banda si tienes acceso a servidores empresariales o incluso a hardware de segunda mano con el que puedas montar un laboratorio; lee los avisos de seguridad de los proveedores sobre el firmware de BMC de los principales fabricantes de servidores y de firmware para BMC, ya que publican divulgaciones reales de vulnerabilidades que puedes estudiar; y, si ya trabajas en seguridad de la nube o de infraestructuras, empieza por hacerle al equipo de tu propia organización encargado del centro de datos o de la adquisición de hardware una pregunta sencilla y verificable: ¿nuestra red de gestión de BMC/IPMI está aislada y quién se encarga de aplicar los parches? Si nadie tiene una respuesta segura, eso no es solo un hallazgo, sino una demostración exacta de la experiencia que necesita este nicho.