AI-sikkerhed er ikke brudt, vi forsvarer bare de forkerte ting

Cybersikkerhedsbranchen har en mønster, når en ny teknologi opstår, vi starter straks med at bygge mure omkring den. Vi gjorde det med cloud, vi gjorde det med containere, og nu gør vi det med AI, undtagen denne gang er murene, vi bygger, i helt forkerte steder.

Gå ind i enhver virksomheds sikkerhedsreview i dag, og du vil høre de samme prioriteringer: sikring af AI-modeller, beskyttelse af træningsdata, validering af outputs og implementering af AI-drevne copiloter. Leverandører skynder sig at sælge “AI-sikkerhedsværktøjer”, der fokuserer eksklusivt på modelniveau-kontroller, såsom guardrails, prompt-injektionsforsvar og model-overvågningsplatforme.

Men angribere bruger dine AI-integrationer som motorveje ind i alt andet.

Det virkelige angrebsoverflade, som ingen holder øje med

En mønster, vi konsekvent observerer på tværs af virksomhedsmiljøer, fortæller en bekymrende historie om sikkerhedsteams, der investerer massivt i at sikre deres AI-udviklingsmiljøer: modeladgangskontroller, datastyringsrammer, MLOps-sikkerhedsværktøjer. Dette giver en falsk tillid til, at deres AI er “låst ned.”

Når du kortlægger den virkelige angrebsoverflade, ser du, at AI-chatbots ofte har OAuth- tokens til dusinvis af SaaS-platforme, API-nøgler med ekstensive cloud-tilladelser og identitetstilidsforhold, der kan skabe direkte veje fra en enkel prompt-injektion til produktionsinfrastruktur. Modellerne i sig selv kan være sikre, men økosystemerne, de lever i, er ofte åbne, og dette er ikke en randtilfælde.

Virksomheder bruger i dag i gennemsnit 130+ SaaS-applikationer, med AI-integrationer, der spænder over identitetsudbydere, cloud-infrastruktur, databaser og forretningskritiske systemer. Hver integration er en potentiel angrebsvej, og hver API-forbindelse er en tillidsgrænse, som angribere aktivt afprøver.

Problemet er ikke, at vores AI-sikkerhedsværktøjer er brudt. Det er, at vi sikrer enkeltkomponenter, mens angribere udnytter forbindelserne mellem dem.

Hvorfor model-centrisk sikkerhed går glip af pointen

Den nuværende tilgang til AI-sikkerhed opererer på en grundlæggende misforståelse af, hvordan moderne angreb fungerer. Vi behandler AI som en selvstændig aktiv, der kræver beskyttelse, ligesom vi måske sikrer en database eller en webapplikation. Men AI i produktion findes ikke i isolation. Det er en node i et komplekst graf over identiteter, tilladelser, API’er og datastrømme.

Betragt en typisk virksomheds AI-udvikling. Du har en AI-agent med adgang til din Google Workspace. Den er forbundet med Salesforce via API’er. Den er integreret med Slack til meddelelser. Den henter data fra AWS S3-buckets. Den er autentificeret gennem Okta eller Azure AD. Den udløser arbejdsgange i ServiceNow.

Traditionel AI-sikkerhed fokuserer på modellen i sig selv: dens sikkerhedsstilling, promptvalidering, output-sikkerhed. Men angribere fokuserer på integrationerne: hvad de kan nå gennem kompromitterede servicekonti, hvor de kan svinge gennem API-manipulationer, hvilke tillidsgrænser de kan krydse gennem udnyttede integrationer.

Angrebet starter ikke eller slutter med AI-modellen. Modellen er kun indgangspunktet.

Angrebsveje respekterer ikke produktgrænser

Her er, hvor de fleste organisationer går i stå. De har implementeret sikkerhedsværktøjer, der hver især giver indsigt i et enkelt domæne. Et værktøj overvåger cloud-tilladelser. Et andet sporer SaaS-konfigurationer. Et tredje styrer identitetsstyring. Et fjerde håndterer sårbarhedsstyring.

Hvert værktøj viser dig sin del af puslespillet. Ingen af dem viser dig, hvordan deleene hænger sammen.

Ifølge Gartner bruger organisationer i dag i gennemsnit 45+ sikkerhedsværktøjer. Alligevel, på trods af denne massive investering, udnytter angribere med succes miskonfigurationer på tværs af disse domæner, fordi intet enkelt værktøj kan se den komplette angrebsvej.

En angriber behøver ikke at finde en kritisk sårbarhed i din AI-model. De behøver kun at finde en kæde. Måske er det en miskonfigureret IAM-rolle, der er knyttet til din AI-tjeneste, som har tilladelser til en S3-bucket, som indeholder legitimationsoplysninger til en SaaS-applikation, der har administratoradgang til din produktionsmiljø.

Hver enkelt miskonfiguration kan score “medium” eller “lav” i dine sikkerhedsværktøjer. Men hvis de kædes sammen? Det er en kritisk eksponering. Og det er helt usynligt, hvis du ser på hvert sikkerhedsdomæne i isolation.

Det eksponeringsstyringsimperativ

Dette er hvorfor samtalen skal skifte fra “AI-sikkerhed” til kontinuerlig trusleksponeringsstyring for AI-integrerede miljøer.

Det er ikke nok at spørge, om vores AI-modeller er sikre. Sikkerhedsteams skal forstå, hvad en angriber kan nå, hvis de kompromitterer en AI-tjenestekonto. De skal have indsigt i, hvordan miskonfigurationer på tværs af cloud, SaaS og identitetssystemer kan kædes sammen. De skal vide, hvordan AI-integrationer ændrer deres angrebsoverflade i realtid. Og de skal prioritere risici baseret på den faktiske angrebarhed, ikke kun alvorlighedsscore.

De fleste sikkerhedsprogrammer prioriterer stadig risici i isolation, ved hjælp af CVSS-score og overholdelseschecklister, der fuldstændigt ignorerer, om en sårbarhed faktisk kan udnyttes i jeres specifikke miljø.

Denne lukning er endnu mere udtalt med AI-systemer, fordi de ændrer sig konstant. Nye integrationer tilføjes ugentligt. Tilladelser udvikler sig. API-forbindelser skifter. Din angrebsoverflade fra sidste måned er ikke din angrebsoverflade i dag, men din sikkerhedsbedømmelse er sandsynligvis det samme.

Hvad angrebsvejsbevidst sikkerhed faktisk ligner

At sikre AI i produktion kræver en fundamentalt anderledes tilgang, og det kommer ned til fire nøgleændringer i tankegang.

Først skal du have samlet indsigt på tværs af sikkerhedsdomæner. Stop med at bede hvert sikkerhedsværktøj om at operere i sin egen silo. Dit cloud-sikkerhed, identitetsstyring, SaaS-styring og sårbarhedsstyring værktøjer holder alle dele af angrebsvejpusslet. De skal dele data i realtid, så du kan se, hvordan miskonfigurationer kædes sammen.

Anden, omfavne kontinuerlig angrebsvejsimulation. Vent ikke på penetrationstests eller rød team-øvelser for at opdage udnyttelige veje. Test kontinuerligt, hvordan en angriber kan bevæge sig gennem dit miljø, med fokus på den faktiske udnyttelighed snarere end på teoretiske alvorlighedsscore.

Tredje, prioriter baseret på kontekst. En miskonfigureret S3-bucket er ikke kritisk, bare fordi den er offentlig. Den er kritisk, hvis den er offentlig og indeholder legitimationsoplysninger, og disse legitimationsoplysninger har privilegeret adgang, og de er tilgængelige fra en internet-eksponeret aktiv. Kontekst betyder mere end nogen enkelt score.

Fjerde, gå mod forbyggende afhjælpning. Når dit SOC-team er ved at undersøge en alarm, har du allerede tabt værdifuld respons tid. Moderne forsvar kræver evnen til at lukke udnyttelige veje, før de udnyttes, ikke efter en incident.

Advarslen, vi ikke kan ignorere

Da AI bliver integreret på tværs af hver lag i virksomhedsstakken, udvider angrebsoverfladen sig hurtigere, end sikkerhedsteams kan manuelt forstå det. Vi tilføjer AI-integrationer 10 gange hurtigere, end vi sikrer dem.

Hvis du sikrer AI i isolation, beskytter modellen, mens du ignorerer økosystemet, det opererer i, er du allerede bagefter. Angribere tænker ikke i værktøjer, de tænker i veje. De udnytter ikke enkelt sårbarheder. De kæder miskonfigurationer sammen på tværs af dit hele miljø.

Virksomhederne, der vil lykkes med at sikre AI, vil ikke være dem med de fleste AI-sikkerhedsværktøjer. De vil være dem, der forstår, at AI-sikkerhed er uadskillelig fra eksponeringsstyring på tværs af deres hele angrebsoverflade.

Model-sikkerhed er en grundlæggende forudsætning. Det, der betyder noget, er at forstå, hvad en angriber kan nå, hvis de kompromitterer en AI-integration. Indtil sikkerhedsteams kan svare på det kontinuerligt, i realtid, på tværs af deres hele miljø, sikrer de ikke AI. De håber bare, at murene, de har bygget, er på de rette steder.