ما اخیراً مطلبی درباره «توکنومیکس» (Tokenomics) و حملات «ممانعت از کیف پول» (Denial of Wallet) منتشر کردیم؛ نوع جدیدی از حملات DDoS که با هدف افزایش بیش‌ازحد مصرف توکن‌های هوش مصنوعی انجام می‌شوند. اما پیش از آنکه متخصصان امنیت شروع به محافظت از فرایندهای هوش مصنوعی همکارانشان در برابر این تهدید جدید کنند، باید به خاطر داشته باشند که خودِ فرایندهای واحد امنیت اطلاعات نیز می‌توانند هدف چنین حمله‌ای قرار بگیرند. از آنجا که تیم‌های امنیتی اکنون به‌طور فعال در حال آزمایش و پیاده‌سازی انواع مختلف اتوماسیون مبتنی بر هوش مصنوعی هستند، تهدید مداخله خارجی با هدف از کار انداختن سیستم دفاعی، مستقیماً فرایندها و فناوری‌های خود آن‌ها را نیز تحت تأثیر قرار می‌دهد.

شرکت Elastic برآورد کرده است که بسته به معماری SOC مبتنی بر ایجنت (Agent-based SOC)، بررسی اولیه یک هشدار منفرد از یک میزبان می‌تواند برای مجموعه‌ای از ایجنت‌های بسیار تخصصی ۰٫۶۹ دلار هزینه داشته باشد، در حالی که این هزینه برای یک ایجنت عمومی با ۱۴ مهارت مختلف به ۳٫۴۲ دلار می‌رسد.

بااین‌حال، این میانگین‌ها دامنه بسیار گسترده‌ای از تغییرات را پنهان می‌کنند. در هر لحظه، پردازش اولیه یک هشدار ساده، مثلاً هزار توکن، می‌تواند به یک فرایند بررسی زنجیره‌ای تبدیل شود که شامل پردازش میلیون‌ها ورودی لاگ، فراخوانی API و سایر داده‌های مرتبط است؛ فرایندی که ممکن است تنها در عرض چند دقیقه به مصرف میلیون‌ها توکن منجر شود.

خود Elastic نیز تأیید کرده است که در SOC خود از مدل Claude Sonnet 4.6 استفاده می‌کند. این موضوع بلافاصله یک سؤال مهم ایجاد می‌کند: وقتی بودجه تمام شود یا فیلترهای امنیتی مدل فعال شوند چه اتفاقی می‌افتد؟

در بدترین حالت، ممکن است چنین سناریویی رخ دهد: SOC مبتنی بر هوش مصنوعی برای بررسی رویدادهای مشکوک، یک «ارکستر از ایجنت‌ها» را فعال می‌کند؛ چیزی که از نظر الگو شبیه حرکت جانبی در زیرساخت است. ایجنت، API شرکت Anthropic را فراخوانی می‌کند، اما بودجه ماهانه واحد مربوطه تمام شده و API خطا برمی‌گرداند. فرایند بررسی متوقف می‌شود و افراد مسئول ممکن است نیم روز بعد متوجه این موضوع شوند.

حتی بدون تمام شدن بودجه نیز همین اتفاق ممکن است رخ دهد؛ اگر «فیلترهای امنیتی» دائماً در حال تغییر یک ارائه‌دهنده بزرگ هوش مصنوعی، درخواست‌های SOC را مخرب تشخیص دهند. تجربه Hugging Face در بررسی نفوذ به زیرساخت این شرکت توسط OpenAI، نمونه‌ای از چنین وضعیتی است.

البته مهاجم نیز انگیزه کافی برای ایجاد چنین شرایطی دارد. او می‌تواند با وارد کردن پرامپت‌های مخرب در داده‌هایی که در اختیار سیستم‌های امنیتی قرار می‌گیرند، مستقیماً بر هزینه‌های مدافعان تأثیر بگذارد؛ داده‌هایی مانند رکوردهای DNS TXT، هدرهای HTTP، توضیحات داخل کد، نام فایل‌ها و موارد مشابه، با این امید که این پرامپت‌ها توسط سیستم‌های امنیت اطلاعات پردازش شوند.

برای مثال، در حمله GhostJacking، لاگ‌های WAF به‌عنوان مسیر تزریق پرامپت استفاده شدند. در یک مطالعه دانشگاهی نیز روش دیگری پیشنهاد شده است: پژوهشگران توانستند خودِ محدودکننده‌های امنیتی LLM را هدف قرار دهند و باعث شوند تأخیر درخواست‌ها ۱۴۸ برابر و تعداد توکن‌های مصرف‌شده ۶۳ برابر افزایش پیدا کند.

به بیان دیگر، سیستم از نظر تئوری همچنان به‌درستی کار می‌کند، اما تأخیر در پردازش هشدارها و هزینه‌های مرتبط با آن به شکل چشمگیری افزایش می‌یابد.

شکست خاموش و خطرناک

در سناریوهای مبتنی بر ایجنت، تمام شدن بودجه همیشه با یک خطای واضح، پیام «محدودیت درخواست‌ها رد شده است» و یک هشدار فوری برای افراد مسئول همراه نیست.

در برخی پیکربندی‌ها ممکن است سناریوهای «چریکی» شکل بگیرند: درخواست ارسال‌شده به مدل با پایان زمان مواجه می‌شود، سیستم به‌صورت خودکار به یک مدل ارزان‌تر تغییر می‌کند و در نتیجه کیفیت خروجی‌ها کاهش می‌یابد و اجرای زیرایجنت‌ها و وظایف دوره‌ای متوقف می‌شود.

در همین حال، تیم امنیتی ممکن است ساعت‌ها همچنان تصور کند که همه‌چیز مانند گذشته در حال کار است.

چگونه هزینه‌های هوش مصنوعی را در امنیت سایبری کنترل کنیم؟

مدیریت هزینه‌ها، طبیعتاً صرفاً به معنای «جلوگیری از هزینه‌کرد بیش از حد» نیست.

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

همین وضعیت می‌تواند در مورد توکن‌ها نیز رخ دهد؛ با این تفاوت که این اتفاق می‌تواند سریع‌تر و در مقیاس بزرگ‌تری رخ دهد. یک سیاست نامناسب برای کاهش هزینه می‌تواند عمق بررسی‌ها و کیفیت پاسخ‌گویی را به خطر بیندازد.

در نبود چنین سیاستی نیز تصمیم برای حذف یا محدود کردن چیزی را نه معمار سیستم یا CISO در مرحله طراحی، بلکه تحلیلگر شیفت ساعت ۳ بامداد خواهد گرفت. حتی ممکن است این محدودیت به‌صورت خودکار توسط فروشنده سیستم اعمال شود.

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

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

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

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

مجوزهای ایجنت‌ها و مجموعه ابزارهای در دسترس آن‌ها را محدود کنید. هرچه سیستم به اقدامات کمتری دسترسی داشته باشد، بهتر می‌تواند روی یک وظیفه محدود تمرکز کند، فرصت‌های کمتری برای افزایش هزینه خواهد داشت و احتمال اینکه یک فرد بیرونی بتواند از آن «سوءاستفاده» کند نیز کمتر خواهد بود.

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

برای جلوگیری از قطعی سرویس‌های ارائه‌دهندگان خارجی و حفظ کنترل کامل بر داده‌های سازمان، امکان استفاده از مدل‌های محلی مستقر در محل سازمان (On-Premises) را دست‌کم برای نیازهای امنیت اطلاعات بررسی کنید. این مدل‌ها ممکن است در سطح پیشرفته‌ترین مدل‌های موجود نباشند، اما تخصصی بودن و تنظیم دقیق آن‌ها با داده‌های شرکت می‌تواند عملکرد قابل‌قبولی را بدون بروز خطاهای غیرمنتظره فراهم کند.

در یک معماری پیچیده‌تر، می‌توان استفاده از LLMها را در چند سطح تقسیم کرد.

در خط اول دفاع، یعنی مسیریابی، فیلتر کردن نویز و غنی‌سازی داده‌ها، از مدل‌های کوچک مستقر در محل استفاده می‌شود. این کار نوسان هزینه‌ها را به میزان قابل‌توجهی کاهش می‌دهد.

سطح دوم شامل یک مدل محلی بزرگ است که وظایف اصلی را انجام می‌دهد: ارتباط دادن رویدادها، آزمایش فرضیه‌ها و کنار هم قرار دادن تصویر یک حادثه.

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

فقط موارد خاص و واقعاً پیچیده به مدل‌های پیشرفته مبتنی بر فضای ابری ارسال می‌شوند؛ ترجیحاً با تأیید صریح یک تحلیلگر انسانی.

در این ساختار، هزینه‌های متغیر همچنان وجود دارند، اما به تعداد محدودی از موارد محدود می‌شوند و هر مورد نتیجه یک انتخاب آگاهانه است، نه پیامد جانبی اجرای یک اسکریپت در طول شب.

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