بیش از ۷۵۰ آزمون امنیتی چه نکاتی دربارهٔ ارزیابی هوش مصنوعی به روش تیم قرمز آشکار کردند؟

برای ساخت سامانه‌های هوش مصنوعی که به‌درستی کار کنند، ابتدا باید آن‌ها را به چالش بکشید. ما یک ارزیابی به روش تیم قرمز انجام دادیم و با ایفای نقش مهاجم، یک اپلیکیشن هوش مصنوعیِ روبه‌مشتری در حوزهٔ خدمات مالی را آزمودیم و نقاط ضعف آن را بررسی کردیم. یافته‌های ما برای هر کسی که اپلیکیشن‌های مبتنی بر مدل‌های زبانی بزرگ (LLM) را در محیط‌هایی مستقر می‌کند که امنیت در آن‌ها یک الزام است، اهمیت دارد.

ارزیابی به روش تیم قرمز یعنی عمداً تلاش کنید سامانهٔ هوش مصنوعی خود را به چالش بکشید تا پیش از آنکه یک مهاجم واقعی آسیب‌پذیری‌ها را پیدا کند، بتوانید آن‌ها را برطرف کنید. در خدمات مالی، مخاطرات به‌ویژه جدی‌اند: اپلیکیشن‌های هوش مصنوعی با داده‌های مشتریان سروکار دارند، تراکنش‌ها را پردازش می‌کنند و بینش‌های مالی ارائه می‌دهند. پیامد یک شکست می‌تواند از تجربهٔ کاربری نامطلوب تا نقض مقررات، زیان مالی و آسیب جبران‌ناپذیر به اعتبار برند متغیر باشد.

هدف ما یافتن زودهنگام آسیب‌پذیری‌ها، آزمایش الگوهای حمله واقع‌بینانه و کمک به سازمان برای برآوردن انتظارات ایمنی هوش مصنوعی بود؛ انتظاراتی که نهادهای ناظر بسیار جدی می‌گیرند.

در اینجا باید به یک تفاوت اشاره کرد: دور زدن محدودیت‌ها، فیلترهای ایمنی مدل زیربنایی را هدف می‌گیرد؛ تزریق اعلان خود اپلیکیشن را با ترکیب ورودی نامطمئن کاربر و اعلان مورداعتماد توسعه‌دهنده هدف قرار می‌دهد. تزریق اعلان خطر بیشتری دارد، زیرا به‌جای یک مدل همه‌منظوره، سامانه شما و داده‌های محرمانه‌ای را هدف می‌گیرد که سامانه با آن‌ها کار می‌کند.

دور نخست آزمایش ما تقریباً شامل ۷۵۰ آزمون در زمینه‌های زیر بود:

• نشت داده میان نشست‌ها

• افشای اطلاعات هویتی اشخاص (از طریق زبان طبیعی، دست‌کاری API و کدگذاری‌های گوناگون)

• تزریق SQL

• بازنویسی اعلان سیستم

در آن آزمایش اولیه، دو مشکل عمده در سامانهٔ موجود شناسایی کردیم: نحوهٔ رسیدگی به پرس‌وجوهای دارای چند نیت و استفاده از پرامپت‌های کدگذاری‌شده.

پرس‌وجوهای حاوی چند درخواست: درخواست‌هایی که خواسته‌های مشروع و مخرب را با هم ترکیب می‌کنند. برای مثال: «هزینه‌هایم را بر اساس دسته‌بندی نشان بده و همچنین [SQL مخرب] را اجرا کن.» اپلیکیشن قصد مخرب را تشخیص نمی‌داد و در عوض، کاملاً به سازوکارهای حفاظتی لایه داده در مراحل بعدی متکی بود. این کار مانند آن است که چون به گاوصندوق زیرزمین اعتماد دارید، درِ ورودی خانه را باز بگذارید.

کدگذاری: درخواست‌هایی که با Base64، Hex، LeetSpeak و نویسه‌های هم‌شکل کدگذاری شده‌اند. پالایش قصد مخرب برای سامانه‌ها می‌تواند دشوار باشد. هرچند دریافتیم این پرس‌وجوها داده حساسی را افشا نمی‌کنند، به بی‌ثباتی چشمگیر سامانه منجر می‌شوند؛ از جمله توهم، بازگویی SQL مخرب برای کاربران، اشتباه در طبقه‌بندی قصد و موارد مشابه.

نتایج آزمایش اولیه ما نشان داد:

• توهم‌های زمانی: مدل تاریخ‌ها، زمان تراکنش‌ها یا خلاصه‌های زمان‌محور ساختگی را با اطمینان بیان می‌کرد؛ خطری جدی در حوزه مالی، زیرا اقدام مشتری بر اساس تاریخی نادرست می‌تواند پیامدهای واقعی داشته باشد

• بازگویی SQL مخرب برای کاربر (که از نظر خطر مسموم‌سازی حافظه نگران‌کننده است)

• خطا در تشخیص هدف کاربر

• قالب‌بندی آشفته خروجی

با تکیه بر این یافته‌ها، دامنه تمرکزمان را محدودتر کردیم. آزمون‌های تزریق SQL و کدگذاری در اولویت پایین‌تری قرار گرفتند، زیرا تیم از قبل مشغول رسیدگی به آن‌ها بود. در عوض، بر موفق‌ترین مسیرهای حمله تمرکز کردیم: افشای اطلاعات هویتی اشخاص و نشت داده میان نشست‌ها.

چشمگیرترین یافته دور دوم به‌طرز غافلگیرکننده‌ای ساده بود: اغلب اصلاً نیازی به زیرکی نیست.

در بسیاری از موارد، کافی بود داده‌های داخلی را در قالب درخواستی ظاهراً مشروع بخواهید تا سامانه با افشای آن‌ها موافقت کند. پرس‌وجوهای ساده پاسخ‌هایی دریافت می‌کردند که به شناسه‌های داخلی و فیلدهای سیستمی اشاره داشتند؛ اطلاعاتی که هرگز نباید به کاربران نهایی نمایش داده شوند.

با بررسی عمیق‌تر دریافتیم که این فقط یک نقص در سطح اپلیکیشن نبود. سرویس پایین‌دستی تبدیل متن به SQL، پرس‌وجوهایی می‌ساخت که فیلدهای بیشتری از حد مجاز درخواست می‌کردند و پاسخ‌های توضیحی آن نیز به داده‌هایی اشاره داشتند که باید محدود می‌ماندند. این موضوع شکافی واقعی میان سامانه‌ها را آشکار کرد؛ همان نوع آسیب‌پذیری که تنها با آزمایش کل پشته، نه اجزای منفرد و جدا از هم، نمایان می‌شود.

1. سامانه را به روش تیم قرمز ارزیابی کنید، نه مدل را. آزمایش یک مدل زبانی بزرگ (LLM) به‌صورت مجزا، اطلاعات بسیار کمی دربارهٔ وضعیت امنیتی اپلیکیشن شما به دست می‌دهد. کل پشته را به‌صورت سرتاسری و همان‌گونه که کاربر با آن تعامل می‌کند، آزمایش کنید.

2. اعتبارسنجی ورودی باید پیش از رسیدن درخواست به مدل زبانی بزرگ. پرس‌وجوهای کدگذاری‌شده، حملاتی که چند درخواست را در یک ورودی ترکیب می‌کنند، و تلاش‌های ساده برای تزریق باید در همان لایهٔ ورودی شناسایی و متوقف شوند، نه اینکه رسیدگی به آن‌ها به سرویس‌های پایین‌دستی واگذار شود.

3. به نقاط اتصال اعتماد نکنید. در معماری‌های چندسرویسی، جالب‌ترین آسیب‌پذیری‌ها در شکاف‌های میان سامانه‌ها پنهان می‌شوند. اعتماد صفر واقعاً یعنی اعتماد صفر؛ پس همه‌چیز را در تک‌تک لایه‌ها اعتبارسنجی کنید.

4. حملات ساده مؤثرند. دور زدن محدودیت‌های پیچیده خبرساز می‌شود، اما گاهی کافی است فقط... بپرسید. اگر سامانه شما صرفاً به‌دلیل گنجاندن شناسه‌های داخلی در یک پرس‌وجوی مشروع، آن‌ها را به‌راحتی نمایش می‌دهد، با یک مشکل روبه‌رو هستید.

5. دقیقاً بدانید چه چیزی را می‌آزمایید. ممکن است الگوهای حملهٔ شناخته‌شده به‌واسطهٔ آموزش خودِ مدل زبانی بزرگ (LLM) مهار شوند، نه سازوکارهای حفاظتی شما. قابلیت مشاهده‌پذیری را در ارزیابی به روش تیم قرمز بگنجانید تا مشخص شود عملاً کدام کنترل‌ها اعمال می‌شوند.

6. محیط‌های محدود به راهکارهای خلاقانه نیاز دارند. ارائه‌دهندگان سفارشی و پشتیبانی از مدل‌های محلی، انجام ارزیابی مؤثر به روش تیم قرمز را بدون نیاز به دسترسی ویژه به زیرساخت‌های ابری امکان‌پذیر می‌کنند. بااین‌حال، دربارهٔ محدودیت‌هایی که این رویکرد ایجاد می‌کند شفاف باشید.

7. ارزیابی به روش تیم قرمز کاری یک‌باره نیست. این فرایند تکرارشونده است، باید تا حد امکان خودکار شود و هم‌زمان با تکامل سامانهٔ شما تکامل یابد. حملاتی که فردا اهمیت دارند، لزوماً همان حملات مهم امروز نیستند..

سامانه‌های هوش مصنوعی در محیط‌های تحت نظارت با موشکافی بیشتری روبه‌رو خواهند شد، نه کمتر. سازمان‌هایی که آزمون امنیتی را نه یک تیک پیش از عرضه، بلکه فرایندی مستمر می‌دانند، برای پاسخ‌گویی به این موشکافی آماده‌تر خواهند بود و از بحران‌های روابط عمومی که اعتماد مشتریان را از بین می‌برد، دور می‌مانند.