Mens alle diskuterer hvilken modell som skriver den beste koden, skalerer et mye eldre og langt mindre glamorøst problem stille opp sammen med hvert nye AI-datasenter: hovedkortstyringskontrolleren, eller BMC. Sikkerhetsforskere la denne uken frem funn som viser at tusenvis av internettilkoblede servere fra store produsenter kan få installert en bakdør eksternt gjennom feil i disse kontrollerne – noen av svakhetene er over ti år gamle. Dette handler ikke om AI i det hele tatt. Det handler om maskinvaren AI kjører på, og det er verdt å forstå hvis du tenker på hvor den neste bølgen av AI-relaterte sikkerhetsjobber kommer fra.

Hva en BMC faktisk er, og hvorfor den er skremmende

En BMC er en liten, separat datamaskin som er loddet fast på så å si alle hovedkort for bedriftservere. Den kjører sitt eget operativsystem og sin egen nettverksstakk, og har sin egen IP-adresse – helt uavhengig av operativsystemet og applikasjonene som kjører på hovedserveren. Administratorer bruker BMC-er til «lights-out»- eller «out-of-band»-administrasjon: omstart av en maskin, nyprogrammering av fastvare, reinstallering av et operativsystem – alt eksternt, og avgjørende nok også mens hovedserveren er avslått eller fullstendig uten respons.

Det er også nettopp det som gjør en kompromittert BMC så farlig. En angriper som kommer seg inn i en, trenger ikke at vertsoperativsystemet kjører, trenger ikke å omgå eventuell endepunktsikkerhet som er installert på det, og kan opprettholde tilgangen gjennom reinstalleringer av operativsystemet, siden BMC-en befinner seg under og utenfor laget som normale IT-sikkerhetsverktøy overvåker. Ifølge forskningen som ble omtalt denne uken, er protokollen som oftest er involvert, IPMI, og sikkerhetsforskere har advart om denne typen risiko siden minst 2013. Med andre ord: Dette er ikke en ny feil, men en gammel, kjent og strukturelt vanskelig kategori av feil å utbedre, som bransjen har tolerert i godt over et tiår.

Hvorfor dette er viktigere nå, ikke mindre viktig

AI-utbyggingen er fysisk sett en av de største bølgene av serverinnkjøp i historien – rad på rad med GPU-servere settes inn i nye og utvidede datasentre så raskt leverandørene klarer å sende dem. Hver eneste av disse serverne leveres med en BMC, fordi BMC-er er måten datasenteroperatører administrerer flåter i stor skala på; du kan ikke gå inn i en lagerstor bygning og manuelt starte ti tusen maskiner på nytt for hånd. AI-boomen kjøper derfor ikke bare datakraft – den kjøper av nødvendighet en tilsvarende stor flåte av små, utilstrekkelig overvåkede «out-of-band»-datamaskiner med en dokumentert historikk på over ti år med kritiske sårbarheter.

Det er den tekniske gjelden: Utbyggingstakten er optimalisert for å få GPU-er i rackene og treningskjøringer i gang, ikke for å revidere administrasjonsfastvaren som er innebygd i hvert hovedkort under dem. Forskerne bak denne ukens avsløring skal ha beskrevet BMC-er som en «utbredt, utilstrekkelig overvåket og utilstrekkelig oppdatert parallell angrepsflate» – en beskrivelse som er eldre enn AI-datasenterboomen, men det er denne boomen som akkurat nå mangedobler antallet BMC-er i produksjon.

Nisjen dette åpner

Hvis du kartlegger hvor sikkerhetskarrierer er på vei parallelt med AI-infrastruktur, er de fleste åpenbare sporene – red teaming av modeller, forsvar mot prompt-injeksjon og styring av agenter – allerede tett befolket og godt dekket andre steder. Maskinvare- og «out-of-band»-sikkerhetsrevisjon er ikke det. Det er en lite glamorøs og lite sexy avkrok av infrastruktursikkerhet som ikke dukker opp i AI-hovedinnlegg, og nettopp der ligger gapet: Etterspørselen skalerer med hvert nye datasenter, mens tilgangen på personer som forstår angrepsflater på fastvarenivå og «out-of-band»-nivå, er liten fordi dette faktisk er et annet ferdighetssett enn applikasjons- eller skysikkerhet.

Slik ser arbeidet faktisk ut, i konkrete termer:

  • Kunnskap om fastvare og protokoller. Forstå IPMI (og de kjente svakhetene – som den for lengst avviklede chifferpakken 0, som enkelte enheter fortsatt leveres med aktivert) godt nok til å vurdere om en gitt serverflåte er eksponert, ikke bare teoretisk sårbar.
  • Revisjon av nettverkssegmentering. Kontrollere om BMC-/administrasjonsgrensesnitt faktisk er isolert på et dedikert administrasjonsnettverk, eller om de kan nås fra produksjonsnettverket eller det generelle internett – en grunnleggende kontroll som gang på gang viser seg å mangle i praksis.
  • Gjennomgang av legitimasjons- og oppdateringsrutiner. BMC-er leveres ofte med standardlegitimasjon eller leverandørangitt legitimasjon og fastvare som ikke inngår i et datasenters normale syklus for operativsystemoppdateringer, fordi det ikke er operativsystemet – og det er lett for dette å falle utenfor ansvarsområdet til den som har ansvar for «oppdatering».
  • Kunnskap om leverandører og leverandørkjeder. BMC-fastvare skrives vanligvis av et lite antall spesialiserte leverandører og lisensieres til serverprodusenter, slik at en svakhet i én leverandørs kode kan spre seg til mange maskinmerker samtidig – dette er nøyaktig mønsteret i denne ukens avsløring. Å vite hvilken fastvarestakk som ligger under hvilket servermerke, er en del av jobben.

Slik posisjonerer du deg faktisk for dette

Dette er et genuint nisjefelt, og det er rimelig å være skeptisk til hvor mange dedikerte stillinger som vil bli opprettet, sammenlignet med at dette forblir en spesialisering innad i eksisterende infrastruktur- eller sikkerhetsteam – vær ærlig med deg selv om at «BMC-sikkerhetsrevisor» kan ende opp som en ferdighet du legger til en bredere rolle innen maskinvare-/datasentersikkerhet, snarere enn en egen stillingstittel. Men noen få konkrete og etterprøvbare grep gir mening uansett: Skaff deg praktisk erfaring med IPMI og «out-of-band»-administrasjonsverktøy hvis du har tilgang til bedriftservere eller til og med brukt maskinvare du kan bruke i et testmiljø; les sikkerhetsvarsler fra leverandører om BMC-fastvare fra de store server- og BMC-fastvareprodusentene, siden de publiserer reelle sårbarhetsavsløringer du kan studere; og hvis du allerede jobber med sky- eller infrastruktursikkerhet, kan du begynne å stille din egen organisasjons datasenter- eller maskinvareinnkjøpsteam et enkelt, etterprøvbart spørsmål – ligger BMC-/IPMI-administrasjonsplanet vårt på et isolert nettverk, og hvem har ansvaret for å oppdatere det? Hvis ingen har et sikkert svar, er det ikke bare et funn, men også en demonstrasjon av nøyaktig den kompetansen denne nisjen trenger.