کارآمد اے آئی نظام بنانے کے لیے پہلے انہیں توڑنا پڑتا ہے. ہم نے ریڈ ٹیمنگ کی ایک مہم چلائی، جس میں حملہ آور بن کر مالیاتی خدمات کی صارفین کے لیے بنائی گئی اے آئی ایپ کو جانچا اور پرکھا. ہمیں جو کچھ ملا، وہ LLM سے چلنے والی ایسی ایپلی کیشنز تعینات کرنے والے ہر شخص کے لیے اہم ہے جہاں سیکیورٹی ناگزیر ہے.
ریڈ ٹیمنگ میں جان بوجھ کر آپ کے اے آئی نظام کو توڑنے کی کوشش کی جاتی ہے تاکہ کسی حقیقی حملہ آور سے پہلے کمزوریاں دور کی جا سکیں. مالیاتی خدمات میں خطرات خاص طور پر سنگین ہیں: اے آئی ایپلی کیشنز صارفین کے ڈیٹا تک رسائی رکھتی ہیں، لین دین پر کارروائی کرتی ہیں اور مالی معلومات فراہم کرتی ہیں. ناکامی کے نتائج خراب صارف تجربے سے لے کر ضوابط کی خلاف ورزی، مالی نقصان اور برانڈ کو ناقابل تلافی نقصان تک ہو سکتے ہیں.
ہمارا مقصد کمزوریوں کو جلد تلاش کرنا، حقیقت پسندانہ حملوں کے طریقے آزمانا اور ادارے کو اے آئی کی حفاظت سے متعلق ان توقعات پر پورا اترنے میں مدد دینا تھا جنہیں ریگولیٹر بہت سنجیدگی سے لیتے ہیں.
یہاں ایک فرق سمجھنا ضروری ہے: جیل بریک بنیادی ماڈل کے حفاظتی فلٹرز پر حملہ کرتا ہے، جبکہ پرومپٹ انجیکشن غیر معتبر صارف ان پٹ کو ڈویلپر کے معتبر پرومپٹ کے ساتھ ملا کر خود ایپلی کیشن کو نشانہ بناتا ہے. پرومپٹ انجیکشن زیادہ خطرناک ہے کیونکہ یہ کسی عمومی ماڈل کے بجائے آپ کے نظام اور اس میں استعمال ہونے والے خفیہ ڈیٹا کو نشانہ بناتا ہے.
ہماری جانچ کے پہلے دور میں درج ذیل شعبوں کے تقریباً 750 ٹیسٹ شامل تھے:
مختلف سیشنز کے درمیان ڈیٹا کا افشا
PII کا افشا، قدرتی زبان، API میں جوڑ توڑ اور مختلف انکوڈنگز کے ذریعے
SQL انجیکشن
سسٹم پرومپٹ کو بے اثر کرنا
اس ابتدائی جانچ کے دوران ہم نے موجودہ نظام میں دو بڑے مسائل شناخت کیے: متعدد مقاصد والے استفسارات کو سنبھالنا اور انکوڈ شدہ پرومپٹس کا استعمال.
متعدد مقاصد والے استفسارات: ایسی درخواستیں جن میں جائز اور بدنیتی پر مبنی مطالبات یکجا ہوں. مثلاً: ”میرے اخراجات زمرے کے لحاظ سے دکھائیں اور [بدنیتی پر مبنی SQL] بھی چلائیں.“ ایپلی کیشن بدنیتی پر مبنی ارادے کو پکڑ نہیں رہی تھی اور مکمل طور پر بعد کی ڈیٹا سطح کی حفاظتی رکاوٹوں پر منحصر تھی. یہ ایسا ہی ہے جیسے تہہ خانے کی تجوری پر بھروسا کرکے گھر کا مرکزی دروازہ کھلا چھوڑ دیا جائے.
انکوڈنگ: ایسی درخواستیں جو Base64، Hex، LeetSpeak اور ہم شکل حروف میں انکوڈ کی گئی ہوں. نظاموں کے لیے بدنیتی پر مبنی ارادے کو چھانٹنا مشکل ہو سکتا ہے. اگرچہ ان استفسارات سے حساس ڈیٹا ظاہر نہیں ہوا، لیکن انہوں نے نظام کو خاصا غیر مستحکم کیا، جیسے واہمے پیدا ہونا، بدنیتی پر مبنی SQL صارفین کو دہرا کر دکھانا اور ارادے کی درجہ بندی میں الجھن.
ہماری ابتدائی جانچ کے نتائج میں یہ مسائل سامنے آئے:
زمانی واہمے: ماڈل کا پورے اعتماد سے من گھڑت تاریخیں، لین دین کے اوقات یا مخصوص مدت کے خلاصے دینا۔ مالیاتی تناظر میں یہ بڑا خطرہ ہے کیونکہ غلط تاریخ پر عمل کرنے سے صارف کو حقیقی نقصان ہو سکتا ہے.
بدنیتی پر مبنی SQL کو صارف کے سامنے دہرانا، جو میموری کو آلودہ کرنے کے خطرات کے لحاظ سے تشویش ناک ہے
ارادے کی درجہ بندی میں الجھن
بے ترتیب آؤٹ پٹ فارمیٹنگ
ان نتائج کی بنیاد پر ہم نے اپنی توجہ محدود کر دی. SQL انجیکشن اور انکوڈنگ کے ٹیسٹوں کو کم ترجیح دی گئی کیونکہ ٹیم پہلے ہی ان مسائل پر کام کر رہی تھی. اس کے بجائے ہم نے حملے کے سب سے کامیاب طریقوں پر توجہ دی: PII کا افشا اور مختلف سیشنز کے درمیان ڈیٹا کا رساؤ.
دوسرے دور کی سب سے چونکا دینے والی دریافت حیرت انگیز حد تک سادہ تھی: اکثر کسی چالاکی کی ضرورت ہی نہیں پڑتی.
بہت سے معاملات میں داخلی ڈیٹا بس مانگ لینا ہی کافی تھا، بشرطیکہ اسے بظاہر جائز درخواست کے طور پر پیش کیا جائے، اور نظام اسے ظاہر کرنے پر راضی ہو جاتا تھا. سادہ استفسارات کے جواب میں ایسے داخلی شناختی نمبروں اور سسٹم فیلڈز کا حوالہ دیا جاتا تھا جو آخری صارفین کو کبھی نظر نہیں آنے چاہییں.
مزید گہرائی سے جانچنے پر معلوم ہوا کہ یہ محض ایپلی کیشن کی سطح کی ناکامی نہیں تھی. بعد کی متن سے SQL بنانے والی سروس ایسے استفسارات تیار کر رہی تھی جو ضرورت سے زیادہ فیلڈز طلب کرتے تھے، اور اس کے وضاحتی جوابات میں ایسے ڈیٹا کا حوالہ آتا تھا جس تک رسائی محدود ہونی چاہیے تھی. اس سے نظاموں کے درمیان ایک حقیقی دراڑ سامنے آئی، یعنی ایسی کمزوری جو انفرادی اجزا کو الگ الگ جانچنے کے بجائے پورے ٹیکنالوجی مجموعے کو جانچنے پر ہی ظاہر ہوتی ہے.
ماڈل کی نہیں، پورے نظام کی ریڈ ٹیمنگ کریں. کسی LLM کو الگ سے جانچنے پر آپ کی ایپلی کیشن کی سیکیورٹی کی حالت کے بارے میں بہت کم معلوم ہوتا ہے. صارف کے تعامل کی طرح پورے ٹیکنالوجی مجموعے کو ابتدا سے انتہا تک جانچیں.
ان پٹ کی توثیق LLM سے پہلے ہونی چاہیے. انکوڈ شدہ استفسارات، متعدد مقاصد والے حملوں اور انجیکشن کی بنیادی کوششوں کو نظام کی سرحد پر ہی پکڑنا چاہیے، نہ کہ یہ ذمہ داری بعد کی سروسز کو سونپنی چاہیے.
نظاموں کے جوڑوں پر بھروسا نہ کریں. متعدد سروسز والے ڈھانچوں میں سب سے دلچسپ کمزوریاں نظاموں کے درمیان موجود دراڑوں میں چھپی ہوتی ہیں. صفر اعتماد کا مطلب واقعی صفر اعتماد ہے، اس لیے ہر سطح پر ہر چیز کی توثیق کریں.
سادہ حملے بھی کامیاب ہوتے ہیں. جدید جیل بریک سرخیاں بنتے ہیں، لیکن کبھی کبھی آپ بس... پوچھ سکتے ہیں. اگر صارف کے کسی بظاہر جائز استفسار میں داخلی شناختی نمبر شامل کرنے پر آپ کا نظام خوشی سے انہیں ظاہر کر دیتا ہے تو یہ ایک مسئلہ ہے.
سمجھیں کہ آپ حقیقت میں کس چیز کی جانچ کر رہے ہیں. ممکن ہے حملوں کے معروف طریقوں کو آپ کی حفاظتی رکاوٹوں کے بجائے LLM کی اپنی تربیت روک رہی ہو. اپنی ریڈ ٹیمنگ میں مشاہدہ پذیری شامل کریں تاکہ معلوم ہو سکے کہ حقیقت میں کون سے حفاظتی کنٹرول آزمائے جا رہے ہیں.
محدود ماحول کے لیے تخلیقی حل درکار ہوتے ہیں. مخصوص فراہم کنندگان اور مقامی ماڈل کی معاونت، خصوصی کلاؤڈ رسائی کے بغیر بھی بامعنی ریڈ ٹیمنگ ممکن بناتی ہے. لیکن اس سے پیدا ہونے والی حدود واضح طور پر بیان کریں.
ریڈ ٹیمنگ ایک بار کا کام نہیں ہے. یہ ایک تکراری عمل ہے، جہاں ممکن ہو اسے خودکار ہونا چاہیے اور نظام کے ارتقا کے ساتھ اسے بھی بدلنا چاہیے. کل اہم ہونے والے حملے آج اہم حملوں جیسے نہیں ہوں گے.
ضابطہ بند ماحول میں اے آئی نظاموں کی جانچ پڑتال کم نہیں بلکہ مزید سخت ہوگی. جو ادارے سیکیورٹی جانچ کو اجرا سے پہلے محض ایک خانہ پُر کرنے کے بجائے مسلسل جاری رہنے والا عمل سمجھتے ہیں، وہ اس جانچ پڑتال کا بہتر سامنا کر سکیں گے اور تعلقات عامہ کے ان بحرانوں سے بچیں گے جن کے باعث صارفین کا اعتماد ختم ہو جاتا ہے.