Terwijl iedereen discussieert over welk model de beste code schrijft, schaalt een veel ouder en veel minder glamoureus probleem stilletjes mee met elk nieuw AI-datacenter: de baseboard management controller, ofwel BMC. Beveiligingsonderzoekers presenteerden deze week bevindingen waaruit blijkt dat duizenden met internet verbonden servers van grote fabrikanten op afstand van een achterdeur kunnen worden voorzien via kwetsbaarheden in deze controllers — sommige van de fouten zijn al meer dan tien jaar oud. Dit gaat helemaal niet over AI. Het gaat over de hardware waarop AI draait, en het is de moeite waard dit te begrijpen als je nadenkt over waar de volgende golf van AI-gerelateerde beveiligingsbanen vandaan zal komen.

Wat een BMC eigenlijk is, en waarom die eng is

Een BMC is een kleine, afzonderlijke computer die op vrijwel elk moederbord van een enterpriseserver is gesoldeerd. Hij draait zijn eigen besturingssysteem, zijn eigen netwerkstack en heeft zijn eigen IP-adres — volledig onafhankelijk van het besturingssysteem en de applicaties die op de hoofdserver draaien. Beheerders gebruiken BMC's voor "lights-out"- of "out-of-band"-beheer: een machine opnieuw opstarten, firmware opnieuw flashen, een besturingssysteem opnieuw installeren, allemaal op afstand en, cruciaal, terwijl de hoofdserver is uitgeschakeld of volledig niet reageert.

Precies dat maakt een gecompromitteerde BMC ook zo gevaarlijk. Een aanvaller die toegang krijgt tot een BMC hoeft niet te wachten tot het hostbesturingssysteem draait, hoeft de endpointbeveiliging die daarop is geïnstalleerd niet te omzeilen en kan persistent blijven na het opnieuw installeren van het besturingssysteem, omdat de BMC onder en buiten de laag zit waarop normale IT-beveiligingstools toezicht houden. Volgens het onderzoek dat deze week werd behandeld, is het protocol dat het vaakst betrokken is IPMI, en beveiligingsonderzoekers waarschuwen al sinds minstens 2013 voor dit soort risico's. Met andere woorden: dit is geen nieuwe bug, maar een oude, bekende en structureel moeilijk op te lossen categorie bugs die de sector al ruim tien jaar heeft getolereerd.

Waarom dit nu juist belangrijker wordt

De AI-uitbouw is fysiek gezien een van de grootste aanschafgolven van servers in de geschiedenis — rijen en rijen GPU-servers die in nieuwe en uitgebreide datacenters worden geplaatst, zo snel als leveranciers ze kunnen leveren. Elk van die servers wordt met een BMC geleverd, omdat BMC's de manier zijn waarop datacenterbeheerders serverparken op schaal beheren; je kunt niet een gebouw ter grootte van een magazijn binnenlopen en tienduizend machines handmatig opnieuw opstarten. De AI-boom koopt dus niet alleen rekenkracht — hij koopt noodzakelijkerwijs ook een vergelijkbaar groot park van kleine, onvoldoende gemonitorde, out-of-band-computers met een gedocumenteerde geschiedenis van meer dan tien jaar aan kritieke kwetsbaarheden.

Dat is de technische schuld: de snelheid van de uitbouw is geoptimaliseerd om GPU's in racks te plaatsen en trainingsruns te starten, niet om de beheerfirmware te auditen die in elk moederbord daaronder is ingebakken. De onderzoekers achter de bekendmaking van deze week zouden BMC's hebben omschreven als een "alomtegenwoordig, onvoldoende gemonitord en onvoldoende gepatcht parallel aanvalsoppervlak" — een omschrijving die dateert van vóór de AI-datacenterboom, maar die boom vermenigvuldigt momenteel het aantal BMC's dat in productie is.

De niche die hierdoor ontstaat

Als je in kaart brengt waar beveiligingscarrières zich naast AI-infrastructuur naartoe bewegen, zijn de meest voor de hand liggende richtingen — red-teaming van modellen, verdediging tegen promptinjectie en governance van agents — al drukbezet en elders al goed afgedekt. Hardware- en out-of-band-beveiligingsaudits zijn dat niet. Het is een weinig glamoureuze, weinig sexy hoek van infrastructuurbeveiliging die niet voorkomt in AI-keynotes, en precies daarin zit het gat: de vraag schaalt mee met elk nieuw datacenter, terwijl het aanbod van mensen die firmware- en out-of-band-aanvalsoppervlakken begrijpen klein is, omdat het echt een andere vaardighedencombinatie is dan applicatie- of cloudbeveiliging.

Hoe het werk er concreet daadwerkelijk uitziet:

  • Kennis van firmware en protocollen. IPMI (en de bekende zwakke punten ervan — zoals cipher suite 0, die al lange tijd is uitgefaseerd maar op sommige apparaten nog steeds ingeschakeld wordt geleverd) goed genoeg begrijpen om te beoordelen of een bepaald serverpark blootstaat, en niet alleen theoretisch kwetsbaar is.
  • Audits van netwerksegmentatie. Controleren of BMC-/beheerinterfaces daadwerkelijk zijn geïsoleerd op een speciaal beheernetwerk, of dat ze bereikbaar zijn vanuit de productieomgeving of het algemene internet — een basismaatregel die in de praktijk herhaaldelijk blijkt te ontbreken.
  • Controles van referenties en patchbeheer. BMC's worden vaak geleverd met standaard- of door de leverancier ingestelde inloggegevens en firmware die geen deel uitmaakt van de normale patchcyclus van een datacenterbesturingssysteem, omdat het niet het besturingssysteem is — daardoor kan het gemakkelijk buiten de verantwoordelijkheid vallen van degene die "patching" beheert.
  • Kennis van leveranciers en de toeleveringsketen. BMC-firmware wordt meestal geschreven door een klein aantal gespecialiseerde leveranciers en in licentie gegeven aan serverfabrikanten, waardoor een fout in de code van één leverancier zich tegelijk over veel hardwaremerken kan verspreiden — precies dat patroon zien we in de bekendmaking van deze week. Weten welke firmwarestack onder welk servermerk zit, hoort bij het werk.

Hoe je jezelf hier daadwerkelijk voor positioneert

Dit is echt een nichegebied, en het is terecht om sceptisch te zijn over hoeveel specifieke formatieplaatsen hiervoor zullen ontstaan, in plaats van dat het een specialisatie binnen bestaande infrastructuur- of beveiligingsteams blijft — wees eerlijk tegen jezelf dat "BMC-beveiligingsauditor" uiteindelijk een vaardigheid kan zijn die je toevoegt aan een bredere functie in hardware-/datacenterbeveiliging, in plaats van een zelfstandige functietitel. Toch zijn een paar concrete, controleerbare stappen hoe dan ook zinvol: doe praktijkervaring op met IPMI en out-of-band-beheertools als je toegang hebt tot enterpriseservers of zelfs tweedehands hardware om mee te labben; lees beveiligingsadviezen van leveranciers over BMC-firmware van de grote makers van servers en BMC-firmware, aangezien zij echte kwetsbaarheden publiceren die je kunt bestuderen; en als je al in cloud- of infrastructuurbeveiliging werkt, begin je eigen datacenter- of hardware-inkoopteam een eenvoudige, verifieerbare vraag te stellen — staat onze BMC-/IPMI-beheerlaag op een geïsoleerd netwerk, en wie is verantwoordelijk voor het patchen ervan? Als niemand een zelfverzekerd antwoord heeft, is dat niet alleen een bevinding, maar ook een demonstratie van precies de expertise waar deze niche behoefte aan heeft.