કાર્યક્ષમ AI સિસ્ટમ બનાવવા માટે પહેલાં તેની ખામીઓ શોધવી પડે. અમે હુમલાખોરોની જેમ વર્તીને નાણાકીય સેવાઓની ગ્રાહકલક્ષી AI એપ્લિકેશનનું પરીક્ષણ અને ઊંડાણપૂર્વક તપાસ કરવા રેડ ટીમિંગ હાથ ધર્યું. સુરક્ષા અનિવાર્ય હોય તેવી LLM-આધારિત એપ્લિકેશનો અમલમાં મૂકતા દરેક માટે અમારા તારણો મહત્ત્વના છે.
રેડ ટીમિંગ એટલે તમારી AI સિસ્ટમમાં ઇરાદાપૂર્વક ખામીઓ શોધવાનો પ્રયાસ, જેથી વાસ્તવિક હુમલાખોર તેમને શોધે તે પહેલાં તમે નબળાઈઓ સુધારી શકો. નાણાકીય સેવાઓમાં જોખમ ખાસ કરીને ઊંચું છે: AI એપ્લિકેશનો ગ્રાહકોના ડેટાનો ઉપયોગ કરે છે, વ્યવહારોની પ્રક્રિયા કરે છે અને નાણાકીય જાણકારી આપે છે. નિષ્ફળતાનાં પરિણામો ખરાબ વપરાશકર્તા અનુભવથી માંડીને નિયમનકારી ઉલ્લંઘન, નાણાકીય નુકસાન અને ભરપાઈ ન થઈ શકે તેવી બ્રાન્ડની હાનિ સુધી જઈ શકે છે.
અમારો હેતુ નબળાઈઓ વહેલી શોધવાનો, વાસ્તવિક હુમલાની રીતો ચકાસવાનો અને સંસ્થાને નિયમનકારો ખૂબ ગંભીરતાથી લેતી AI સુરક્ષાની અપેક્ષાઓ પૂરી કરવામાં મદદ કરવાનો હતો.
અહીં એક ભેદ સમજવો જરૂરી છે: જેલબ્રેક મૂળ મોડલના સુરક્ષા ફિલ્ટર પર હુમલો કરે છે, જ્યારે પ્રોમ્પ્ટ ઇન્જેક્શન ડેવલપરના વિશ્વસનીય પ્રોમ્પ્ટ સાથે અવિશ્વસનીય વપરાશકર્તા ઇનપુટનો ઉપયોગ કરીને એપ્લિકેશન પર જ હુમલો કરે છે. પ્રોમ્પ્ટ ઇન્જેક્શન વધુ જોખમી છે, કારણ કે તે સામાન્ય હેતુના મોડલને બદલે તમારી સિસ્ટમ અને તેમાં વપરાતા ગોપનીય ડેટાને નિશાન બનાવે છે.
અમારા પ્રથમ તબક્કામાં આ ક્ષેત્રોનાં આશરે 750 પરીક્ષણો સામેલ હતાં:
અલગ-અલગ સત્રો વચ્ચે ડેટા લીક થવો
PII જાહેર થવી (સ્વાભાવિક ભાષા, APIમાં ફેરફાર અને વિવિધ એન્કોડિંગ દ્વારા)
SQL ઇન્જેક્શન
સિસ્ટમ પ્રોમ્પ્ટને બિનઅસરકારક બનાવવું
પ્રારંભિક પરીક્ષણ દરમિયાન અમને હાલની સિસ્ટમમાં બે મોટી સમસ્યાઓ મળી: એકથી વધુ હેતુ ધરાવતી ક્વેરીનું સંચાલન અને કોડબદ્ધ પ્રોમ્પ્ટનો ઉપયોગ.
એકથી વધુ હેતુ ધરાવતી ક્વેરી: એવી વિનંતી જેમાં કાયદેસર અને દૂષિત માગણીઓ સાથે હોય. ઉદાહરણ તરીકે: “મારો ખર્ચ શ્રેણી પ્રમાણે બતાવો અને [દૂષિત SQL] પણ ચલાવો.” એપ્લિકેશન દૂષિત ઇરાદો પકડી શકતી નહોતી અને તેના બદલે પછીના ડેટા સ્તરની સુરક્ષા મર્યાદાઓ પર સંપૂર્ણપણે નિર્ભર હતી. આ એવું છે જાણે ભોંયરાની તિજોરી પર વિશ્વાસ હોવાથી તમે ઘરનો મુખ્ય દરવાજો ખુલ્લો છોડી દો.
એન્કોડિંગ: એવી વિનંતીઓ જે Base64, Hex, LeetSpeak અને સમાન દેખાતા અક્ષરોમાં કોડબદ્ધ હોય. સિસ્ટમ માટે દૂષિત ઇરાદાને ફિલ્ટર કરવો મુશ્કેલ બની શકે છે. અમને જાણવા મળ્યું કે આ ક્વેરીથી સંવેદનશીલ ડેટા જાહેર થયો નહોતો, પરંતુ તેમણે સિસ્ટમને નોંધપાત્ર રીતે અસ્થિર કરી હતી; જેમ કે ભ્રમજનક જવાબો, વપરાશકર્તાને દૂષિત SQLનું પુનરાવર્તન, હેતુના વર્ગીકરણમાં ગૂંચવણ વગેરે.
અમારા પ્રારંભિક પરીક્ષણનાં પરિણામોમાં આ બાબતો જોવા મળી:
સમયસંબંધિત ભ્રમજનક જવાબો: મોડલ આત્મવિશ્વાસથી ખોટી તારીખો, વ્યવહારોના સમય અથવા સમયમર્યાદિત સારાંશ રજૂ કરતું હતું. નાણાકીય સંદર્ભમાં આ મોટું જોખમ છે, કારણ કે ખોટી તારીખના આધારે ગ્રાહકની કાર્યવાહીથી વાસ્તવિક પરિણામો આવી શકે છે
વપરાશકર્તાને દૂષિત SQLનું પુનરાવર્તન કરીને બતાવવું (સ્મૃતિને દૂષિત કરવાના જોખમની દૃષ્ટિએ ચિંતાજનક)
હેતુનું ગૂંચવણભર્યું વર્ગીકરણ
અવ્યવસ્થિત આઉટપુટ ફોર્મેટ
આ તારણોના આધારે અમે અમારું ધ્યાન મર્યાદિત કર્યું. SQL ઇન્જેક્શન અને એન્કોડિંગ પરીક્ષણોને ઓછી પ્રાથમિકતા આપવામાં આવી, કારણ કે ટીમ પહેલેથી જ તેના પર કામ કરી રહી હતી. તેના બદલે અમે સૌથી સફળ હુમલાના માર્ગો પર ધ્યાન કેન્દ્રિત કર્યું: PII જાહેર થવી અને અલગ-અલગ સત્રો વચ્ચે ડેટા લીક થવો.
બીજા તબક્કાનું સૌથી ચોંકાવનારું તારણ અત્યંત સરળ હતું: ઘણી વાર જરાય ચતુરાઈની જરૂર પડતી નથી.
ઘણા કિસ્સામાં, કાયદેસર લાગતી વિનંતીના ભાગરૂપે આંતરિક ડેટા માગવો જ સિસ્ટમને તે જાહેર કરવા સંમત કરાવવા માટે પૂરતો હતો. સરળ ક્વેરીના જવાબોમાં એવા આંતરિક ઓળખચિહ્નો અને સિસ્ટમ ફીલ્ડનો ઉલ્લેખ થતો હતો જે અંતિમ વપરાશકર્તાને ક્યારેય દેખાવા ન જોઈએ.
વધુ ઊંડાણપૂર્વક તપાસતાં અમને જાણવા મળ્યું કે આ માત્ર એપ્લિકેશન સ્તરની નિષ્ફળતા નહોતી. પછીની ટેક્સ્ટ-ટુ-SQL સેવા જરૂર કરતાં વધુ ફીલ્ડ માગતી ક્વેરી બનાવી રહી હતી અને તેના સમજૂતીભર્યા જવાબોમાં પ્રતિબંધિત હોવા જોઈએ એવા ડેટાનો ઉલ્લેખ થતો હતો. આનાથી સિસ્ટમો વચ્ચેની વાસ્તવિક ખામી ઉજાગર થઈ. આવી નબળાઈ અલગ ઘટકોનું એકાંતમાં પરીક્ષણ કરવાથી નહીં, પરંતુ સમગ્ર તકનીકી માળખાનું પરીક્ષણ કરવાથી જ દેખાય છે.
મોડલનું નહીં, સિસ્ટમનું રેડ ટીમિંગ કરો. LLMનું અલગથી પરીક્ષણ કરવાથી તમારી એપ્લિકેશનની સુરક્ષાની સ્થિતિ વિશે બહુ ઓછી જાણકારી મળે છે. વપરાશકર્તા જે રીતે સંપર્ક કરે તે રીતે સમગ્ર તકનીકી માળખાનું શરૂઆતથી અંત સુધી પરીક્ષણ કરો.
LLM પહેલાં જ ઇનપુટની માન્યતા ચકાસવી જરૂરી છે. કોડબદ્ધ ક્વેરી, એકથી વધુ હેતુ ધરાવતા હુમલા અને મૂળભૂત ઇન્જેક્શન પ્રયાસો પ્રવેશબિંદુએ જ પકડાવા જોઈએ; આ જવાબદારી પછીની સેવાઓને સોંપવી ન જોઈએ.
જોડાણનાં સ્થાનો પર વિશ્વાસ ન કરો. એકથી વધુ સેવાઓ ધરાવતા માળખામાં સૌથી રસપ્રદ નબળાઈઓ સિસ્ટમોની વચ્ચેની ખામીઓમાં છુપાયેલી હોય છે. શૂન્ય-વિશ્વાસનો અર્થ ખરેખર કોઈ પર વિશ્વાસ નહીં, તેથી દરેક સ્તરે દરેક બાબતની માન્યતા ચકાસો.
સરળ હુમલા પણ સફળ થાય છે. અત્યાધુનિક જેલબ્રેક ચર્ચામાં રહે છે, પરંતુ ક્યારેક તમે માત્ર... માગી શકો છો. વપરાશકર્તા અન્યથા કાયદેસર ક્વેરીમાં આંતરિક ઓળખચિહ્નો ઉમેરે અને તમારી સિસ્ટમ તેને સહેલાઈથી જાહેર કરી દે, તો તે એક સમસ્યા છે.
તમે ખરેખર શાનું પરીક્ષણ કરી રહ્યા છો તે સમજો. હુમલાની જાણીતી રીતોને તમારી સુરક્ષા મર્યાદાઓને બદલે LLMની પોતાની તાલીમ જ પકડી શકે છે. વાસ્તવમાં કયા નિયંત્રણોની કસોટી થઈ રહી છે તે સમજવા માટે તમારા રેડ ટીમિંગમાં નિરીક્ષણક્ષમતા ઉમેરો.
મર્યાદિત વાતાવરણમાં સર્જનાત્મક ઉકેલો જરૂરી છે. કસ્ટમ પ્રદાતાઓ અને સ્થાનિક મોડલ માટેના સમર્થનથી વિશિષ્ટ ક્લાઉડ ઍક્સેસ વિના પણ સાર્થક રેડ ટીમિંગ શક્ય બને છે. પરંતુ તેના કારણે ઊભી થતી મર્યાદાઓ વિશે પારદર્શક રહો.
રેડ ટીમિંગ એક વખતનું કાર્ય નથી. તે પુનરાવર્તિત પ્રક્રિયા છે, શક્ય હોય ત્યાં તેને સ્વચાલિત કરવી જોઈએ અને તમારી સિસ્ટમની સાથે તેનો પણ વિકાસ થવો જોઈએ. આવતીકાલે મહત્ત્વના બનનારા હુમલા આજના મહત્ત્વના હુમલાઓ જેવા નહીં હોય.
નિયમનાધીન વાતાવરણમાં AI સિસ્ટમોની તપાસ ઘટશે નહીં, વધશે જ. જે સંસ્થાઓ સુરક્ષા પરીક્ષણને પ્રારંભ પહેલાં ટિક કરવાના ખાનાને બદલે સતત ચાલતી શિસ્ત માને છે, તે આ વધતી તપાસનો સામનો કરવા અને ગ્રાહકોનો વિશ્વાસ ગુમાવતી જનસંપર્ક આપત્તિઓ ટાળવા વધુ સારી સ્થિતિમાં હશે.