Zephyrnet-logo

Het is 10 uur. Weet u waar uw AI-modellen vanavond zijn?

Datum:

Als u dacht dat het beveiligingsprobleem van de softwaretoeleveringsketen vandaag de dag al moeilijk genoeg was, maak dan uw gordel vast. De explosieve groei van het gebruik van kunstmatige intelligentie (AI) zal het de komende jaren exponentieel moeilijker maken om met deze supply chain-problemen om te gaan. 

Ontwikkelaars, professionals op het gebied van applicatiebeveiliging en DevSecOps-professionals worden opgeroepen om de fouten met het hoogste risico op te lossen die op de loer liggen in wat lijkt op de eindeloze combinaties van open source en bedrijfseigen componenten die verweven zijn in hun applicaties en cloudinfrastructuur. Maar het is een voortdurende strijd om zelfs maar te begrijpen welke componenten ze hebben, welke kwetsbaar zijn en welke gebreken hen het meeste risico opleveren. Het is duidelijk dat ze al moeite hebben om deze afhankelijkheden in hun software op een verstandige manier te beheren.

Wat nog moeilijker zal worden, is het multipliereffect dat AI aan de situatie zal toevoegen.

AI-modellen als zelfuitvoerende code

Tools die geschikt zijn voor AI en machine learning (ML) zijn software die precies hetzelfde is als elke andere soort applicatie – en de code ervan heeft net zo goed te lijden onder onzekerheden in de toeleveringsketen. Ze voegen echter nog een andere assetvariabele toe aan de mix die het aanvalsoppervlak van de supply chain van AI-software aanzienlijk vergroot: AI/ML-modellen.

“Wat AI-applicaties onderscheidt van elke andere vorm van software is dat ze op de een of andere manier afhankelijk zijn van een zogenaamde machine learning-model”, legt Daryan Dehghanpisheh, medeoprichter van Protect AI, uit. “Als gevolg hiervan is dat machine learning-model zelf nu een aanwinst voor uw infrastructuur. Wanneer u activa in uw infrastructuur heeft, moet u de mogelijkheid hebben om uw omgeving te scannen, te identificeren waar deze zich bevinden, wat ze bevatten, wie machtigingen heeft en wat ze doen. En als je dat vandaag de dag niet met de modellen kunt, kun je ze ook niet beheren.”

AI/ML-modellen vormen de basis voor het vermogen van een AI-systeem om patronen te herkennen, voorspellingen te doen, beslissingen te nemen, acties te activeren of inhoud te creëren. Maar de waarheid is dat de meeste organisaties niet eens weten hoe ze überhaupt inzicht moeten krijgen in alle AI-modellen die in hun software zijn ingebed. Modellen en de infrastructuur eromheen zijn anders gebouwd dan andere softwarecomponenten, en traditionele beveiligings- en softwaretools zijn niet gebouwd om te scannen of te begrijpen hoe AI-modellen werken of welke gebreken ze vertonen. Dit maakt ze uniek, zegt Dehghanpisheh, die uitlegt dat het in wezen verborgen stukjes zelfuitvoerende code zijn.

“Een model is van nature een zichzelf uitvoerend stukje code. Het heeft een zekere mate van keuzevrijheid”, zegt Dehghanpisheh. “Als ik je zou vertellen dat je overal in je infrastructuur assets hebt die je niet kunt zien, die je niet kunt identificeren, je weet niet wat ze bevatten, je weet niet wat de code is, en ze voeren zichzelf uit en externe gesprekken voeren, dat klinkt verdacht veel als een toestemmingsvirus, nietwaar?'

Een vroege waarnemer van AI-onzekerheden

Dit probleem het hoofd bieden was de grote drijfveer achter hem en zijn medeoprichters om in 2022 Protect AI te lanceren, een van de vele nieuwe bedrijven die opduiken om problemen met modelbeveiliging en data-afstamming aan te pakken die in het AI-tijdperk opdoemen. Dehghanpisheh en mede-oprichter Ian Swanson zagen een glimp van de toekomst toen ze eerder samenwerkten aan het bouwen van AI/ML-oplossingen bij AWS. Dehghanpisheh was de wereldleider op het gebied van AI/ML-oplossingsarchitecten.

“Gedurende de tijd die we samen bij AWS doorbrachten, zagen we klanten in een ongelooflijk snel tempo AI/ML-systemen bouwen, lang voordat generatieve AI de harten en geesten van iedereen veroverde, van de C-suite tot het Congres”, zegt hij, en legt uit dat hij werkte samen met een reeks ingenieurs en experts op het gebied van bedrijfsontwikkeling, maar ook uitgebreid met klanten. “Toen beseften we hoe en waar de beveiligingskwetsbaarheden die uniek zijn voor AI/ML-systemen zich bevinden.”

Ze observeerden drie fundamentele zaken over AI/ML die ongelooflijke implicaties hadden voor de toekomst van cyberbeveiliging, zegt hij. De eerste was dat het tempo van de adoptie zo snel was dat ze uit de eerste hand zagen hoe snel er schaduw-IT-entiteiten opdoken rond AI-ontwikkeling en zakelijk gebruik die ontsnapten aan het soort bestuur dat toezicht zou houden op elke andere vorm van ontwikkeling in de onderneming.

De tweede was dat het merendeel van de tools die werden gebruikt – of ze nu commercieel of open source waren – werden gebouwd door datawetenschappers en opkomende ML-ingenieurs die nooit waren opgeleid in beveiligingsconcepten.

"Het resultaat was dat je hele nuttige, zeer populaire, zeer gedistribueerde en algemeen aanvaarde tools had die niet waren gebouwd met een security first-mentaliteit", zegt hij.

AI-systemen zijn niet ‘Security-First’ gebouwd

Als gevolg hiervan missen veel AI/ML-systemen en gedeelde tools de basis op het gebied van authenticatie en autorisatie en verlenen ze vaak te veel lees- en schrijftoegang in bestandssystemen, legt hij uit. In combinatie met onveilige netwerkconfiguraties en de inherente problemen in de modellen, raken organisaties verzand in opeenvolgende beveiligingsproblemen in deze uiterst complexe, moeilijk te begrijpen systemen.

“Dat deed ons beseffen dat de bestaande beveiligingstools, processen en raamwerken – hoe ver je ook ging, de context misten die machine learning-ingenieurs, datawetenschappers en AI-bouwers nodig zouden hebben”, zegt hij.

Ten slotte was de derde belangrijke observatie die hij en Swanson tijdens die AWS-dagen maakten dat er geen AI-inbreuken zouden komen. Ze waren al gearriveerd.

“We zagen dat klanten inbreuken hadden op een verscheidenheid aan AI/ML-systemen die hadden moeten worden ontdekt, maar dat niet zijn gebeurd”, zegt hij. “Wat ons dat vertelde is dat de set en de processen, evenals de elementen voor incidentresponsbeheer, niet speciaal waren gebouwd voor de manier waarop AI/ML werd ontworpen. Dat probleem is nog veel erger geworden nu generatieve AI aan kracht wint.”

AI-modellen worden op grote schaal gedeeld

Dehghanpisheh en Swanson begonnen ook in te zien hoe modellen en trainingsgegevens een unieke nieuwe AI-toeleveringsketen creëerden die net zo serieus zou moeten worden genomen als de rest van de software-toeleveringsketen. Net als bij de rest van de moderne softwareontwikkeling en cloud-native innovatie hebben datawetenschappers en AI-experts de vooruitgang in AI/ML-systemen gestimuleerd door het ongebreidelde gebruik van open source en gedeelde componenten – inclusief AI-modellen en de gegevens die worden gebruikt om deze te trainen. Zoveel AI-systemen, of ze nu academisch of commercieel zijn, zijn gebouwd volgens het model van iemand anders. En net als bij de rest van de moderne ontwikkeling blijft de explosie van de AI-ontwikkeling zorgen voor een enorme dagelijkse toestroom van nieuwe modelmiddelen die zich over de hele toeleveringsketen verspreiden, wat betekent dat het steeds moeilijker wordt om ze bij te houden.

Neem bijvoorbeeld het knuffelgezicht. Dit is tegenwoordig een van de meest gebruikte opslagplaatsen van open source AI-modellen online – de oprichters zeggen dat ze de GitHub van AI willen zijn. In november 2022 hadden Hugging Face-gebruikers 93,501 verschillende modellen met de community gedeeld. In november daaropvolgend waren dat opgeblazen tot 414,695 modellen. Nu, slechts drie maanden later, is dat aantal uitgebreid tot 527,244. Dit is een kwestie waarvan de reikwijdte met de dag groter wordt. En het zal het beveiligingsprobleem van de softwaretoeleveringsketen “op steroïden” brengen, zegt Dehghanpisheh.

A recente analyse door zijn firma ontdekt dat duizenden modellen die openlijk worden gedeeld op Hugging Face willekeurige code kunnen uitvoeren op het laden of infereren van modellen. Terwijl Hugging Face zijn repository op basis van beveiligingsproblemen scant, worden er onderweg veel modellen gemist. Minstens de helft van de zeer risicovolle modellen die in het onderzoek zijn ontdekt, werd door het platform niet als onveilig beschouwd, en Hugging Face maakt dit duidelijk in de documentatie. dat het bepalen van de veiligheid van een model uiteindelijk de verantwoordelijkheid is van de gebruikers ervan. 

Stappen voor de aanpak van AI-toeleveringsketen

Dehghanpisheh gelooft dat de hoeksteen van cyberbeveiliging in het AI-tijdperk eerst zal beginnen met het creëren van een gestructureerd begrip van de AI-afkomst. Dat omvat de afstamming van modellen en gegevens, die in wezen de oorsprong en geschiedenis van deze activa vormen, hoe ze zijn gewijzigd en de metagegevens die eraan zijn gekoppeld.

“Dat is de eerste plaats om te beginnen. Je kunt niet repareren wat je niet kunt zien, wat je niet kunt weten en wat je niet kunt definiëren, toch?” hij zegt.

Ondertussen gelooft Dehghanpisheh dat organisaties op het dagelijkse operationele niveau capaciteiten moeten opbouwen om hun modellen te scannen, op zoek naar fouten die niet alleen de verharding van het systeem kunnen beïnvloeden, maar ook de integriteit van de output ervan. Dit omvat zaken als AI-vooroordelen en storingen die fysieke schade in de echte wereld kunnen veroorzaken, bijvoorbeeld als een autonome auto tegen een voetganger botst.

"Het eerste is dat je moet scannen", zegt hij. “Het tweede is dat je die scans moet begrijpen. En de derde is dat als je eenmaal iets hebt gemarkeerd, je in wezen moet voorkomen dat dat model wordt geactiveerd. Je moet zijn keuzevrijheid beperken.”

De push voor MLSecOps

MLSecOps is een leveranciersneutrale beweging die de DevSecOps-beweging in de traditionele softwarewereld weerspiegelt.

“Net als bij de overstap van DevOps naar DevSecOps moet je twee dingen tegelijk doen. Het eerste wat je moet doen is de beoefenaars ervan bewust maken dat veiligheid een uitdaging is en dat het een gedeelde verantwoordelijkheid is”, zegt Dehghanpisheh. “Het tweede dat je moet doen is context geven en beveiliging plaatsen in tools die datawetenschappers, machine learning-ingenieurs, [en] AI-bouwers aan de top houden en voortdurend innoveren, maar ervoor zorgen dat de beveiligingsproblemen naar de achtergrond verdwijnen. .”

Bovendien zegt hij dat organisaties zullen moeten beginnen met het toevoegen van governance-, risico- en compliancebeleid, handhavingsmogelijkheden en incidentresponsprocedures die helpen bij het beheersen van de acties en processen die plaatsvinden wanneer onzekerheden worden ontdekt. Net als bij een solide DevSecOps-ecosysteem betekent dit dat MLSecOps een sterke betrokkenheid nodig heeft van zakelijke belanghebbenden tot aan de top van de managementladder.

Het goede nieuws is dat AI/ML-beveiliging profiteert van één ding dat geen enkele andere snelle technologische innovatie direct van de poort heeft gehad: namelijk regelgevende mandaten die direct van de poort komen. 

“Denk eens aan een andere technologietransitie”, zegt Dehghanpisheh. 'Noem één keer dat een federale toezichthouder of zelfs staatstoezichthouders zo vroeg hebben gezegd: 'Ho, ho, ho, je moet me alles vertellen wat erin staat.' Je moet prioriteit geven aan kennis van dat systeem. U moet prioriteit geven aan een stuklijst. Die is er niet.”

Dit betekent dat het waarschijnlijker is dat veel leiders op het gebied van de beveiliging eerder in de levenscyclus van de innovatie de steun zullen krijgen om AI-beveiligingsmogelijkheden uit te bouwen. Een van de duidelijkste tekenen van deze steun is de snelle verschuiving naar het sponsoren van nieuwe functies bij organisaties.

“Het grootste verschil dat de regelgevingsmentaliteit met zich mee heeft gebracht, is dat in januari 2023 het concept van een directeur van AI-beveiliging nieuw was en niet bestond. Maar in juni begon je die rollen te zien”, zegt Dehghanpisheh. “Nu zijn ze overal – en ze worden gefinancierd.”

spot_img

Laatste intelligentie

spot_img