कार्यक्षम AI प्रणाली तयार करायची असेल, तर प्रथम ती ब्रेक करून पाहावी लागते. वित्तीय सेवांमधील ग्राहकांसाठी असलेल्या AI ॲप्लिकेशनची चाचणी आणि सखोल तपासणी करण्यासाठी आम्ही हल्लेखोरांची भूमिका घेत रेड टीमिंग मोहीम राबवली. जिथे सुरक्षेशी तडजोड शक्य नाही अशा LLM-आधारित ॲप्लिकेशनचे उपयोजन करणाऱ्या प्रत्येकासाठी आमचे निष्कर्ष महत्त्वाचे आहेत.
खऱ्या हल्लेखोराने असुरक्षा शोधण्याआधी त्या दूर करता याव्यात, यासाठी जाणीवपूर्वक आपली AI प्रणाली ब्रेक करण्याचा प्रयत्न करणे म्हणजे रेड टीमिंग. वित्तीय सेवांमध्ये धोका विशेषतः मोठा असतो: AI ॲप्लिकेशन ग्राहकांचा डेटा हाताळतात, व्यवहारांवर प्रक्रिया करतात आणि आर्थिक सखोल माहिती देतात. अपयशाचे परिणाम खराब वापरकर्ता अनुभवापासून नियामक नियमांचे उल्लंघन, आर्थिक नुकसान आणि भरून न निघणारी ब्रँडहानी यांपर्यंत होऊ शकतात.
असुरक्षा लवकर शोधणे, वास्तववादी हल्ला पद्धती तपासणे आणि नियामक अत्यंत गांभीर्याने घेत असलेल्या AI सुरक्षा अपेक्षा पूर्ण करण्यास संस्थेला मदत करणे हे आमचे उद्दिष्ट होते.
येथे एक फरक समजून घेणे महत्त्वाचे आहे: जेलब्रेक मूळ मॉडेलच्या सुरक्षा गाळण्यांवर हल्ला करतो, तर प्रॉम्प्ट इंजेक्शन डेव्हलपरच्या विश्वसनीय प्रॉम्प्टसोबत अविश्वसनीय वापरकर्ता इनपुट वापरून थेट ॲप्लिकेशनवर हल्ला करतो. प्रॉम्प्ट इंजेक्शनचा धोका अधिक असतो, कारण ते सर्वसाधारण वापराच्या मॉडेलऐवजी तुमच्या प्रणालीला आणि ती हाताळत असलेल्या गोपनीय डेटाला लक्ष्य करते.
आमच्या चाचणीच्या पहिल्या फेरीत पुढील प्रकारच्या सुमारे 750 चाचण्या होत्या:
क्रॉस-सेशन डेटा गळती
वैयक्तिक ओळख पटवणारी माहिती उघड होणे (नैसर्गिक भाषा, API फेरफार आणि विविध एन्कोडिंगद्वारे)
SQL इंजेक्शन
सिस्टम प्रॉम्प्ट ओव्हरराइड्स
त्या प्रारंभिक चाचणीत आम्हाला विद्यमान प्रणालीतील दोन प्रमुख समस्या आढळल्या: अनेक हेतू असलेल्या क्वेरींची हाताळणी आणि एन्कोड केलेल्या प्रॉम्प्टचा वापर.
अनेक हेतू असलेल्या क्वेरी: वैध आणि दुर्भावनापूर्ण मागण्या एकत्र असलेल्या विनंत्या. उदाहरणार्थ: “माझा खर्च श्रेणीनुसार दाखवा आणि [दुर्भावनापूर्ण SQL] चालवा.” ॲप्लिकेशनला हा दुर्भावनापूर्ण हेतू ओळखता येत नव्हता आणि तो पूर्णपणे पुढील डेटा स्तरावरील सुरक्षा उपायांवर अवलंबून होता. हे तळघरातील तिजोरीवर विश्वास असल्यामुळे घराचा मुख्य दरवाजा उघडा ठेवण्यासारखे आहे.
एन्कोडिंग: Base64, Hex, LeetSpeak आणि समरूप चिन्हांमध्ये एन्कोड केलेल्या विनंत्या. प्रणालींना दुर्भावनापूर्ण हेतू गाळून टाकणे कठीण होऊ शकते. या क्वेरींमुळे संवेदनशील डेटा उघड झाला नाही, पण त्यांनी प्रणाली मोठ्या प्रमाणात अस्थिर केली. त्यातून (भ्रम, दुर्भावनापूर्ण SQL वापरकर्त्यांनाच परत सांगणे आणि हेतूचे गोंधळलेले वर्गीकरण) अशा समस्या उद्भवल्या.
आमच्या प्रारंभिक चाचणीचे निष्कर्ष असे होते:
कालानुरूप भ्रम: मॉडेलद्वारे आत्मविश्वासाने सांगितलेल्या परंतु बनावट तारखा, व्यवहाराचे टाइमस्टॅम्प किंवा कालबद्ध सारांश परत मिळणे—आर्थिक संदर्भात हा एक मोठा धोका आहे, जिथे चुकीच्या तारखेला कृती करणाऱ्या ग्राहकाचे गंभीर परिणाम होऊ शकतात
दुर्भावनापूर्ण SQL वापरकर्त्यालाच परत सांगणे (मेमरी दूषित होण्याच्या धोक्याच्या दृष्टीने चिंताजनक)
गोंधळलेले हेतू वर्गीकरण
विस्कळीत आउटपुट फॉरमॅटिंग
या निष्कर्षांच्या आधारे आम्ही तपासणीची व्याप्ती मर्यादित केली. SQL इंजेक्शन आणि एन्कोडिंग चाचण्यांना कमी प्राधान्य देण्यात आले, (कारण आमची टीम आधीच त्यावर काम करत होती). त्याऐवजी, आम्ही सर्वाधिक यशस्वी ठरलेल्या हल्ल्यांवर लक्ष केंद्रित केले: वैयक्तिक ओळख पटवणारी माहिती उघड होणे आणि सत्रांदरम्यान गळती.
दुसऱ्या फेरीतील सर्वांत ठळक निष्कर्ष आश्चर्यकारकपणे साधा होता: अनेकदा अजिबात चलाखी करण्याची गरज नसते.
अनेक प्रकरणांत, वैध वाटणाऱ्या विनंतीचा भाग म्हणून अंतर्गत डेटा फक्त मागितल्यावर प्रणाली तो उघड करण्यास तयार झाली. साध्या क्वेरींच्या प्रतिसादांत अंतर्गत ओळखचिन्हे आणि वापरकर्त्यांसमोर कधीही न दिसणारी सिस्टम फील्ड नमूद होत होती.
अधिक सखोल तपासणी केल्यावर आम्हाला आढळले की हे केवळ ॲप्लिकेशन स्तरावरील अपयश नव्हते. पुढील मजकूर-ते-SQL सेवा आवश्यकतेपेक्षा जास्त फील्ड मागणाऱ्या क्वेरी तयार करत होती आणि तिच्या स्पष्टीकरणात्मक प्रतिसादांत प्रतिबंधित असायला हवा असा डेटा नमूद होत होता. यामुळे प्रणालींमधील खरी फट उघड झाली. ही अशी असुरक्षा आहे जी स्वतंत्र घटकांची वेगवेगळी चाचणी केल्यावर नव्हे, तर संपूर्ण तंत्ररचनेची चाचणी केल्यावरच समोर येते.
मॉडेलची नव्हे, प्रणालीची रेड टीमिंग करा. LLM ची स्वतंत्रपणे चाचणी केल्याने ॲप्लिकेशनच्या सुरक्षा स्थितीबद्दल फारशी माहिती मिळत नाही. वापरकर्ता जसा संवाद साधेल, तशी संपूर्ण तंत्ररचनेची सुरुवातीपासून शेवटपर्यंत चाचणी करा.
इनपुटचे प्रमाणीकरण LLM पूर्वीच झाले पाहिजे. एन्कोड केलेल्या क्वेरी, अनेक हेतूंचे हल्ले आणि साधे इंजेक्शनचे प्रयत्न सीमेवरच पकडले पाहिजेत. हे काम पुढील सेवांवर सोपवू नये.
जोडलेल्या भागांवर विश्वास ठेवू नका. मल्टी-सर्व्हिस आर्किटेक्चरमध्ये, सिस्टीममधील फटींमध्येच सर्वात धोकादायक असुरक्षितता दडलेली असते. झिरो-ट्रस्ट म्हणजे झिरो-ट्रस्टच, म्हणून प्रत्येक स्तरावर प्रत्येक गोष्टीची पडताळणी करा.
साधे हल्लेही यशस्वी होतात. अत्याधुनिक जेलब्रेकचीच चर्चा होते, पण कधीकधी तुम्ही फक्त... विचारू शकता. वापरकर्त्याने अन्यथा वैध असलेल्या क्वेरीत अंतर्गत ओळखचिन्हे समाविष्ट केल्यावर तुमची प्रणाली ती सहज उघड करत असेल, तर ती समस्या आहे.
आपण नेमके कशाची चाचणी करत आहोत हे समजून घ्या. ज्ञात हल्ला पद्धती तुमच्या सुरक्षा उपायांऐवजी LLM च्या स्वतःच्या प्रशिक्षणामुळे रोखल्या जाऊ शकतात. प्रत्यक्षात कोणती नियंत्रणे वापरली जात आहेत हे समजण्यासाठी रेड टीमिंगमध्ये निरीक्षणक्षमता अंगभूत करा.
मर्यादित वातावरणांसाठी सर्जनशील उपाय आवश्यक असतात. सानुकूल प्रदाते आणि स्थानिक मॉडेलचे समर्थन यांमुळे विशेषीकृत क्लाउड प्रवेशाशिवायही अर्थपूर्ण रेड टीमिंग शक्य होते. पण त्यामुळे निर्माण होणाऱ्या मर्यादा स्पष्टपणे सांगा.
रेड टीमिंग ही एकदाच करण्याची प्रक्रिया नाही. ही पुनरावृत्तीने चालणारी प्रक्रिया आहे. शक्य तिथे ती स्वयंचलित असावी आणि तुमच्या प्रणालीसोबत विकसित होत राहावी. उद्या महत्त्वाचे ठरणारे हल्ले आज महत्त्वाच्या असलेल्या हल्ल्यांसारखे नसतील.
नियंत्रित वातावरणातील AI प्रणालींची तपासणी कमी होण्याऐवजी, उलट अधिकच वाढेल. ज्या संस्था सुरक्षा चाचणीला केवळ उत्पादन बाजारात आणण्यापूर्वीची एक औपचारिकता न मानता, एक निरंतर चालणारी प्रक्रिया म्हणून हाताळतात, त्या या तपासणीला सामोरे जाण्यासाठी अधिक सक्षम ठरतील आणि ग्राहकांचा विश्वास गमावण्यास कारणीभूत ठरणारे जनसंपर्काचे मोठे नुकसान टाळू शकतील.