Mientras todos discuten 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 que muestran que miles de servidores conectados a internet de grandes fabricantes pueden recibir puertas traseras de forma remota mediante vulnerabilidades en estos controladores; algunas de las fallas tienen más de una década. Esto no es una historia sobre IA. Es una historia sobre el hardware en el que se ejecuta la IA, y vale la pena entenderla si estás pensando de dónde saldrá 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 una computadora pequeña e independiente, soldada a prácticamente todas las placas madre de servidores empresariales. Ejecuta su propio sistema operativo, su propia pila de red y tiene su propia dirección IP, totalmente independiente del sistema operativo y las aplicaciones que se ejecutan en el servidor principal. Los administradores usan los BMC para la gestión «lights-out» o «fuera de banda»: reiniciar una máquina, volver a cargar el firmware, reinstalar un sistema operativo, todo de forma remota y, lo que es fundamental, incluso cuando el servidor principal está apagado o no responde por completo.

Eso es exactamente lo que hace tan peligroso que un BMC esté comprometido. Un atacante que logra entrar en uno no necesita que el sistema operativo anfitrión esté ejecutándose, no necesita evadir la seguridad de endpoints instalada en él y puede mantener la persistencia incluso después de reinstalar el sistema operativo, ya que el BMC vive por debajo y fuera de la capa que supervisan las herramientas normales de seguridad informática. Según la investigación cubierta esta semana, el protocolo más comúnmente implicado es IPMI, y los investigadores de seguridad han señalado esta clase de riesgo desde al menos 2013. En otras palabras: no se trata de un error nuevo, sino de una categoría de errores antigua, conocida y estructuralmente difícil de solucionar, que la industria ha tolerado durante mucho más de una década.

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

La expansión de la IA es, en términos físicos, una de las mayores oleadas de adquisición de servidores de la historia: filas y filas de servidores con GPU que se instalan 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 puedes entrar a 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, también está comprando una flota de tamaño equivalente de computadoras pequeñas, poco supervisadas y fuera de banda, 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 instalar las GPU en los racks y comenzar las ejecuciones de entrenamiento, no para auditar el firmware de gestión integrado en cada placa madre que hay debajo. Según se informó, los investigadores responsables de la divulgación de esta semana describieron los BMC como una «superficie de ataque paralela, generalizada, poco supervisada y poco parcheada», una descripción anterior al auge de los centros de datos de IA, pero ese auge es lo que está multiplicando ahora mismo la cantidad de BMC en producción.

El nicho que esto abre

Si estás trazando el rumbo de las carreras de seguridad junto con la infraestructura de IA, la mayoría de los caminos obvios —red teaming de modelos, defensa contra la inyección de prompts y gobernanza de agentes— ya están saturados y bien cubiertos en otros espacios. La auditoría de seguridad de hardware y de sistemas fuera de banda no. Es un rincón poco glamuroso y nada sexy de la seguridad de infraestructura que no aparece en las conferencias principales de 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 al de la seguridad de aplicaciones o de la nube.

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

  • Conocimiento de firmware y protocolos. Entender IPMI (y sus puntos débiles conocidos —como la suite de cifrado 0, obsoleta desde hace mucho tiempo, que algunos dispositivos todavía distribuyen habilitada—) 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 pueden alcanzarse 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 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 alcance de quien sea responsable de «aplicar parches».
  • Conocimiento de proveedores y de la cadena de suministro. El firmware de los BMC normalmente es desarrollado por un pequeño número de proveedores especializados y se licencia a los fabricantes de servidores, por lo que una falla en el código de un proveedor puede propagarse al mismo tiempo entre 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 justo mostrarse escéptico sobre cuántos puestos dedicados se abrirán, en comparación con que siga siendo una especialización dentro de los equipos existentes de infraestructura o seguridad; sé honesto contigo mismo: «auditor de seguridad de BMC» podría terminar siendo una habilidad que agregues a un puesto más amplio de seguridad de hardware o de centros de datos, en lugar de convertirse en un título laboral independiente. Pero, de todos modos, tienen sentido algunas acciones concretas y comprobables: familiarízate de manera 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 para usarlo en 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 infraestructura, empieza a hacerle a tu propio equipo de centro de datos o de 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 aplicarle parches? Si nadie tiene una respuesta segura, eso no es solo un hallazgo, sino también una demostración exacta de la experiencia que este nicho necesita.