Mens alle diskuterer, hvilken model der skriver den bedste kode, er et meget ældre og langt mindre glamourøst problem stille og roligt ved at vokse sammen med hvert nyt AI-datacenter: baseboard management controlleren, eller BMC'en. Sikkerhedsforskere fremlagde i denne uge resultater, der viser, at tusindvis af internetforbundne servere fra større producenter kan få installeret en bagdør eksternt gennem fejl i disse controllere — nogle af fejlene er over et årti gamle. Det er slet ikke en historie om AI. Det er en historie om den hardware, AI kører på, og den er værd at forstå, hvis du overvejer, hvor den næste bølge af AI-relaterede sikkerhedsjobs kommer fra.

Hvad en BMC faktisk er, og hvorfor den er skræmmende

En BMC er en lille, separat computer, der er loddet fast på stort set alle enterprise-serveres bundkort. Den kører sit eget operativsystem, sin egen netværksstak og har sin egen IP-adresse — helt uafhængigt af det operativsystem og de applikationer, der kører på hovedserveren. Administratorer bruger BMC'er til "lights-out"- eller "out-of-band"-administration: genstart af en maskine, genindlæsning af firmware, geninstallation af et operativsystem — alt sammen eksternt og, afgørende nok, også mens hovedserveren er slukket eller fuldstændig uden respons.

Det er også præcis det, der gør en kompromitteret BMC så farlig. En angriber, der kommer ind i en, behøver ikke, at værtsoperativsystemet kører, behøver ikke at omgå den endpoint-sikkerhed, der måtte være installeret på det, og kan fastholde adgangen på tværs af geninstallationer af operativsystemet, eftersom BMC'en befinder sig under og uden for det lag, som normale IT-sikkerhedsværktøjer overvåger. Ifølge den forskning, der blev omtalt i denne uge, er den protokol, der oftest er involveret, IPMI, og sikkerhedsforskere har advaret om denne type risiko siden mindst 2013. Med andre ord: Det her er ikke en ny fejl, men en gammel, kendt og strukturelt vanskelig kategori af fejl at udbedre, som branchen har accepteret i langt over et årti.

Hvorfor det betyder mere nu, ikke mindre

AI-udbygningen er fysisk set en af de største bølger af serverindkøb i historien — rack efter rack med GPU-servere, der installeres i nye og udvidede datacentre, så hurtigt leverandørerne kan sende dem. Hver eneste af disse servere leveres med en BMC, fordi BMC'er er den måde, datacenteroperatører administrerer flåder på i stor skala; man kan ikke gå ind i en lagerstor bygning og manuelt genstarte ti tusind maskiner én efter én. AI-boomet køber altså ikke kun computerkraft — det køber nødvendigvis også en tilsvarende stor flåde af små, utilstrækkeligt overvågede out-of-band-computere med en dokumenteret historik på over et årti med kritiske sårbarheder.

Det er den tekniske gæld: Udbygningstempoet er optimeret til at få GPU'er installeret i racks og træningskørsler startet, ikke til at auditere den management-firmware, der er indbygget i hvert bundkort under dem. Forskerne bag denne uges offentliggørelse beskrev angiveligt BMC'er som en "udbredt, utilstrækkeligt overvåget og utilstrækkeligt patchet parallel angrebsflade" — en beskrivelse, der går forud for AI-datacenterboomet, men det boom er det, der lige nu mangedobler antallet af BMC'er i produktion.

Den niche, det åbner

Hvis du forsøger at kortlægge, hvor sikkerhedskarrierer bevæger sig hen sammen med AI-infrastruktur, er de fleste oplagte spor — red-teaming af modeller, forsvar mod prompt injection, styring af agenter — allerede trængte og allerede godt dækket andre steder. Det samme gælder ikke hardware- og out-of-band-sikkerhedsaudit. Det er et ugælamourøst og usexet hjørne af infrastruktursikkerhed, som ikke dukker op i AI-keynotes, og netop dér ligger hullet: Efterspørgslen vokser med hvert nyt datacenter, og udbuddet af folk, der forstår angrebsflader på firmware-niveau og out-of-band-angrebsflader, er lille, fordi det oprigtigt er et andet kompetencesæt end applikations- eller cloud-sikkerhed.

Sådan ser arbejdet konkret ud:

  • Firmware- og protokolkompetence. At forstå IPMI (og dets kendte svage punkter — såsom den for længst forældede cipher suite 0, som nogle enheder stadig leveres med aktiveret) godt nok til at vurdere, om en given serverflåde er eksponeret, ikke kun teoretisk sårbar.
  • Audit af netværkssegmentering. At kontrollere, om BMC-/managementgrænseflader faktisk er isoleret på et dedikeret managementnetværk, eller om de kan nås fra produktionsnetværket eller det generelle internet — en grundlæggende kontrol, som igen og igen viser sig at mangle i praksis.
  • Gennemgang af legitimationsoplysninger og patchhygiejne. BMC'er leveres ofte med standard- eller leverandørfastsatte legitimationsoplysninger og firmware, der ikke indgår i et datacenters normale patchcyklus for operativsystemet, fordi det ikke er operativsystemet — og derfor let kan falde uden for ansvaret hos den, der ejer "patching".
  • Leverandør- og forsyningskædebevidsthed. BMC-firmware skrives normalt af et lille antal specialiserede leverandører og licenseres til serverproducenter, så en fejl i én leverandørs kode kan sprede sig til mange hardwaremærker på én gang — det er præcis det mønster, der ses i denne uges offentliggørelse. At vide, hvilken firmwarestak der ligger under hvilket servermærke, er en del af jobbet.

Sådan positionerer du dig faktisk til det

Det her er et ægte nicheområde, og det er rimeligt at være skeptisk over for, hvor mange dedikerede stillinger der vil blive oprettet, sammenlignet med at området forbliver en specialisering i eksisterende infrastruktur- eller sikkerhedsteams — vær ærlig over for dig selv om, at "BMC-sikkerhedsauditor" måske ender med at være en kompetence, du føjer til en bredere rolle inden for hardware-/datacentersikkerhed, snarere end en selvstændig jobtitel. Men uanset hvad giver nogle få konkrete, efterprøvelige skridt mening: Få praktisk erfaring med IPMI og out-of-band-administrationsværktøjer, hvis du har adgang til enterprise-servere eller endda brugt hardware, du kan bruge i et labmiljø; læs sikkerhedsbulletiner om BMC-firmware fra de større server- og BMC-firmwareproducenter, eftersom de offentliggør reelle sårbarheder, du kan studere; og hvis du allerede arbejder med cloud- eller infrastruktursikkerhed, så begynd at stille din egen organisations datacenter- eller hardwareindkøbsteam et enkelt, efterprøveligt spørgsmål — ligger vores BMC/IPMI-managementplan på et isoleret netværk, og hvem har ansvaret for at patche det? Hvis ingen har et sikkert svar, er det ikke bare et fund, men en demonstration af præcis den ekspertise, som denne niche har brug for.