AI-synlighetskrisen: Hvorfor sikkerhetsteamene flyr blindt og hvorfor de ikke behøver å gjøre det

Integrasjonen av AI-agenter i produksjonsmiljøer akselererer, men sikkerhetsarkitekturen som kreves for å sikre dem, ligger farlig langt bak. Vi er i en æra hvor en AI-agent, som har fått i oppdrag å utføre et rutinemessig arbeid i et staging-miljø, kan uavhengig bestemme å “fikse” en kredensfeil ved å slette en database-volum.

Som en bransje, har vi kollektivt skrudd av hjernen vår når det gjelder de grunnleggende prinsippene for sikkerhet og overvåkning rundt AI. Sikkerhetsteamene flyr blindt, men de behøver ikke å gjøre det.

Myten om systemprompts og sikker verktøy

En utbredt myte i AI-rommet er at vi kan kontrollere agent-atferd bare ved å si til det å oppføre seg. Systemprompts er rådgivende, ikke tvangsmessige. I den ovennevnte hendelsen, sa AI-systemets regler uttrykkelig at de aldri skulle kjøre destruktive kommandoer, men agenten brøt likevel sine egne markedsførte sikkerhetsforanstaltninger og utførte den mest irreversible handlingen som er mulig.

Vi må arbeide under antagelsen at AI ikke “vet” noe som helst. Angrep mot AI er sosial manipulering, bortsett fra at offeret er dummere enn det gjennomsnittlige mennesket. Alle som har erfaring med penetrerings-testing, forstår hvor vanskelig det er for organisasjoner å forsvare seg mot sosial manipulering. Nå er også datamaskinene våre sårbare.

Fortsatt er AI-verktøy i bunnen bare programvare, og all programvare har feil. Vi har allerede sett eksempler på hvor AI-verktøy automatisk starter uautentiserte HTTP-tjenere, som tillater lokale prosesser eller nettsider å utføre vilkårlige shell-kommandoer med bruker-privilegier.

Den sorte boksen i AI-revisjon

Hvis en AI går rogue eller blir manipulert, er det en mareritt å finne ut hva den gjorde. AI-verktøy tilbyr vanligvis ikke revisjonslogger. Hvis du er heldig å være på et bedriftsnivå, er loggene du mottar svært mangelfulle. For eksempel, kan du få en vag begivenhet som sier at en bruker “brukte Gen AI.” og bare motta grunnleggende målinger som detaljerer inn- og ut-data token-teller.

Ingen av disse hjelper en sikkerhetsanalytiker å svare på det grunnleggende spørsmålet: Hva gjorde denne agenten eksakt?

Avgjøre AI: Hvordan stoppe å fly blindt

Det gode nytt er at du ikke nødvendigvis trenger en ny, skinnende AI-spesifikk sikkerhetsenhet for å gjenopprette synligheten. Skygge-AI-bruk og agent-aktivitet er oppdagbare ved hjelp av eksisterende logg-analyseteknikker som ditt team allerede burde ha. AI-verktøy-kall, kommando-utførelser og system-endringshendelser kan spores til AI ved hjelp av eksisterende prosess-utførelse-analyse (som du gjør i din sikkerhetsinformasjon og hendelsesstyring (SIEM), ikke sant?).

Her er hvordan du kan utnytte din nåværende infrastruktur for å oppdage AI-aktivitet:

• DNS-analyse: Analyse av DNS-logger for forespørsler til kjente AI-tjenestedomener kan hjelpe med å oppdage AI-bruk i din miljø.
• Truslerlister: Denne metoden krever vedlikehold av en oppdatert truslerliste over domener assosiert med AI-plattformer eller modell-tilbydere.
• Fellesskapsressurser: Det finnes fellesskapsprosjekter og blokklisteer tilgjengelig som kan modifiseres til oppslagstabeller for programmatisk bruk.
• SSL-sporing: En lignende metode kan bruke SSL-logger til å spore servernavn, selv om det gir litt mindre detalj siden full URL ikke er registrert.
• Endepunkts-telemetri: Du kan bruke verktøy som Sysmon til å telle barneprosesser og jakte på høye bash-spawnere, som er en sterk indikator for potensielle AI-agenter som utfører kommandoer på en endepunkt.

Blindsonen som krever aktive endringer i din datainnsamling, er promptene selv. Hva ber brukerne AI om? Laste de opp noen potensielt sensitive dokumenter, og dermed skape compliance-problemer? Svare på disse spørsmålene, krever sannsynligvis innsamling av API-forespørsler til leverandøren; web-proksier, LLM-proksier og data-innsamlingsverktøy fra logging og SIEM-tilbydere. Disse kan fjerne sløret som blokkerer denne verdifulle datakilden.

Den nye trusselen: Malisøse MCP-tjenere

Modellkontekstprotokollen (MCP) har oppstått som en måte å spesifisere hvordan AI-applikasjoner integrerer med eksterne verktøy og datakilder. Mens det standardiserer tilkoblinger, introduserer det også massive nye angrepsvektorer via “Ond MCP“-tjenere.

Jeg arrangerer en hånd-til-hånd-trening hvor studenter kan oppleve dette angrepet førstehånd. De designer en malisøs MCP-tjener for å lure en LLM til å ringe opp legitime verktøy og sende utdata tilbake til angriperen. Fordi LLM-er er svært sårbare for sosial manipulering, er å gå forbi deres innbygde sikkerhetsforanstaltninger ofte bare et spørsmål om å velge bedre formulering eller en clever foranledning.

Studenter bruker ofte sin malisøse tjener for å instruere AI om at den er “i vedlikeholdsmodus” og må sende data til et sekundært verktøy for “revisjonslogging”, og dermed resultere i data-eksfiltrering. Noen er mer kreative med sine prompter enn andre, men alle er vanligvis suksessfulle.

Tar tilbake kontrollen

For å ordentlig revisjonere AI-aktivitet i den virkelige verden, trenger du en proksi for å intercepte AI-forespørsler og en logg-innsamlingsverktøy som kan håndtere massive JSON-nytter. Med denne synligheten, kan du oppdage og triage trusler. Du kan ikke bare stole på AI-leverandørene til å levere sikkerhetslaget. Gjennomføringen må bo i systemene til din organisasjon, ikke i en tekst som vi håper modellen bestemmer å adlyde. Med en god logg-løsning, har sikkerhetsteamene telemetri; det er på tide de begynner å spørre det.