Lideri de opinie

Securitatea AI nu este defectuoasă, doar apărăm lucrurile greșite

mm
Adaugă Unite.AI la sursele tale preferate pe Google

Industria securității cibernetice are un model pentru fiecare dată când apare o tehnologie nouă, începem imediat să construim ziduri în jurul ei. Am făcut acest lucru cu cloud-ul, am făcut acest lucru cu containerele și acum, o facem cu AI, cu toate acestea, de data aceasta, zidurile pe care le construim sunt în locuri complet greșite.

Intră în orice revizuire de securitate a întreprinderii astăzi și vei auzi aceleași priorități: securizarea modelelor AI, protejarea datelor de antrenament, validarea ieșirilor și implementarea copiloților AI. Furnizorii se grăbesc să vândă instrumente de “securitate AI” care se concentrează exclusiv pe controale la nivel de model, cum ar fi limitatoarele, apărările împotriva injecțiilor de prompt și platformele de monitorizare a modelului.

Dar atacatorii folosesc integrările dvs. AI ca autostrăzi către tot ce este altceva.

Suprafața reală de atac pe care nimeni nu o supraveghează

Un model pe care îl observăm constant în mediile întreprinderilor spune o poveste îngrijorătoare despre echipele de securitate care investesc puternic în securizarea mediilor de dezvoltare AI: controale de acces la model, cadre de guvernanță a datelor, instrumente de securitate MLOps. Acest lucru oferă o falsă încredere că AI-ul lor este “blocat”.

Când hărțiți suprafața reală de atac, vedeți că bot-urile de chat AI dețin adesea jetons OAuth pentru zeci de platforme SaaS, chei API cu permisiuni excesive de cloud și relații de încredere de identitate care pot crea căi directe de la o injecție simplă de prompt la infrastructura de producție. Modelele în sine pot fi securizate, dar ecosistemele în care trăiesc sunt adesea larg deschise și acest lucru nu este un caz marginal.

Întreprinderile utilizează acum o medie de 130+ aplicații SaaS, cu integrări AI care acoperă furnizorii de identitate, infrastructura cloud, bazele de date și sistemele de afaceri critice. Fiecare integrare este o cale potențială de atac și fiecare conexiune API este o limită de încredere pe care atacatorii o sondează activ.

Problema nu este că instrumentele noastre de securitate AI sunt defectuoase. Este că securizăm componente individuale, în timp ce atacatorii exploatează conexiunile dintre ele.

De ce securitatea centrată pe model ratează esența

Abordarea actuală a securității AI funcționează pe o înțelegere fundamentală greșită a modului în care funcționează atacurile moderne. Tratăm AI-ul ca pe un activ independent care necesită protecție, similar cu modul în care am putea securiza o bază de date sau o aplicație web. Dar AI-ul în producție nu există în izolare. Este un nod într-un graf complex de identități, permisiuni, API-uri și fluxuri de date.

Luăm în considerare o implementare tipică de AI a unei întreprinderi. Aveți un agent AI cu acces la Google Workspace. Este conectat la Salesforce prin API-uri. Este integrat cu Slack pentru notificări. Extrage date din bucket-urile AWS S3. Este autentificat prin Okta sau Azure AD. Declanșează fluxuri de lucru în ServiceNow.

Securitatea tradițională AI se concentrează pe modelul însuși: postura sa de securitate, validarea promptului, siguranța ieșirii. Dar atacatorii se concentrează pe integrări: ce pot ajunge prin conturi de servicii compromise, unde pot face pivot prin manipulări API, care limite de încredere pot traversa prin integrări exploatate.

Atacul nu începe sau se termină cu modelul AI. Modelul este doar punctul de intrare.

Căile de atac nu respectă granițele produselor

Aici este unde majoritatea organizațiilor se blochează. Au implementat instrumente de securitate care oferă fiecare vizibilitate într-un singur domeniu. Un instrument monitorizează permisiunile cloud. Altul urmărește configurațiile SaaS. Un al treilea gestionează guvernanța identității. Un al patrulea se ocupă de gestionarea vulnerabilităților.

Fiecare instrument vă arată propria lui parte a puzzle-ului. Niciunul nu vă arată cum se conectează piesele.

Conform Gartner, organizațiile utilizează acum o medie de 45+ instrumente de securitate. Cu toate acestea, în ciuda acestei investiții masive, atacatorii reușesc să lanseze atacuri prin înlănțuirea configurațiilor greșite din aceste domenii, deoarece niciun instrument nu poate vedea calea completă de atac.

Un atacator nu are nevoie să găsească o vulnerabilitate critică în modelul dvs. AI. El are nevoie doar să găsească o înlănțuire. Poate fi un rol IAM defect configurat, atașat la serviciul dvs. AI, care are permisiuni pentru un bucket S3, care conține credențiale pentru o aplicație SaaS care are acces de administrator la mediul dvs. de producție.

Fiecare configurație greșită individuală poate avea un scor “mediu” sau “scăzut” în instrumentele dvs. de securitate. Dar înlănțuite? Aceasta este o expunere critică. Și este complet invizibilă dacă priviți fiecare domeniu de securitate în izolare.

Imperativul managementului expunerii

Acesta este motivul pentru care conversația trebuie să se mute de la “securitatea AI” la gestionarea continuă a expunerii la amenințări pentru mediile integrate cu AI.

Nu este suficient să întrebați dacă modelele noastre AI sunt securizate. Echipele de securitate trebuie să înțeleagă ce poate ajunge un atacator dacă compromite un cont de serviciu AI. Au nevoie de vizibilitate în ceea ce privește modul în care configurațiile greșite din sistemele cloud, SaaS și identitate pot fi înlănțuite. Trebuie să știe cum integrările AI modifică suprafața lor de atac în timp real. Și trebuie să prioritizeze riscurile pe baza atacabilității reale, nu doar a scorurilor de gravitate.

Majoritatea programelor de securitate încă prioritizează riscurile în izolare, folosind scoruri CVSS și liste de verificare a conformității care ignoră complet dacă o vulnerabilitate este cu adevărat exploatabilă în mediul dvs. specific.

Acest decalaj este și mai pronunțat cu sistemele AI, deoarece acestea se schimbă constant. Noi integrări sunt adăugate săptămânal. Permisiunile evoluează. Conexiunile API se schimbă. Suprafața dvs. de atac de luna trecută nu este suprafața dvs. de atac de astăzi, dar evaluarea dvs. de securitate probabil că este.

Ce arată securitatea conștientă de calea de atac

Securizarea AI în producție necesită o abordare fundamental diferită și se reduce la patru schimbări cheie în gândire.

În primul rând, aveți nevoie de vizibilitate unificată în domeniile de securitate. Nu mai cereți fiecărui instrument de securitate să funcționeze în propria lui siloz. Instrumentele dvs. de securitate cloud, guvernanță a identității, gestionare SaaS și scanare a vulnerabilităților dețin toate piese ale puzzle-ului căii de atac. Acestea trebuie să partajeze date în timp real, astfel încât să puteți vedea cum se înlănțuie configurațiile greșite.

În al doilea rând, adoptați simularea continuă a căii de atac. Nu așteptați testele de penetrare sau exercițiile de echipă roșie pentru a descoperi căi exploatabile. Testați continuu cum poate un atacator să se deplaseze prin mediul dvs., concentrându-vă pe exploatabilitatea reală, mai degrabă decât pe scorurile teoretice de gravitate.

În al treilea rând, prioritați pe baza contextului. Un bucket S3 defect configurat nu este critic doar pentru că este public. Este critic dacă este public și conține credențiale și aceste credențiale au acces privilegiat și sunt accesibile dintr-o resursă expusă pe internet. Contextul contează mai mult decât orice scor individual.

Al patrulea, mutați-vă spre remedierea preventivă. Până când echipa dvs. de securitate investighează un alert, ați pierdut deja timp valoros de răspuns. Apărarea modernă necesită capacitatea de a închide căile exploatabile înainte de a fi folosite, nu după un incident.

Avertismentul pe care nu-l putem ignora

Pe măsură ce AI-ul devine încorporat în fiecare strat al stivei întreprinderii, suprafața de atac se extinde mai repede decât echipele de securitate pot raționa manual despre ea. Adăugăm integrări AI de 10 ori mai repede decât le securizăm.

Dacă securizați AI în izolare, protejând modelul și ignorând ecosistemul în care funcționează, sunteți deja în urmă. Atacatorii nu gândesc în termeni de instrumente, ci în termeni de căi. Ei nu exploatează vulnerabilități individuale. Ei înlănțuie configurații greșite din întregul dvs. mediu.

Întreprinderile care vor reuși să securizeze AI nu vor fi cele cu cele mai multe instrumente de securitate AI. Vor fi cele care înțeleg că securitatea AI este inseparabilă de gestionarea expunerii la amenințări de-a lungul întregii suprafețe de atac.

Securitatea modelului este un lucru de la sine înțeles. Ce contează este înțelegerea a ceea ce poate ajunge un atacator atunci când compromite o integrare AI. Până când echipele de securitate nu pot răspunde continuu, în timp real, la întregul mediu, nu securizează AI. Speră doar că zidurile pe care le-au construit sunt în locurile potrivite.

Piyush Sharma, Co-Fondator și CEO al Tuskira, aduce peste două decenii de expertiză în securitate cibernetică, sprijinită de o diplomă de licență în științe computaționale și un MBA. Antreprenor serial cu două ieșiri de succes, Piyush a deținut roluri proeminente de conducere a produselor și afacerilor, inclusiv la Symantec și Tenable. De asemenea, a fost CEO și co-fondator al Accurics, care a fost ulterior achiziționat de Tenable Inc. Inventator realizat, Piyush deține o duzină de brevete de invenție în securitate cibernetică, demonstrând contribuțiile sale inovatoare în domeniu.