رزمایش‌های سایبری هوش مصنوعی گروه هفت باید آزمونی برای فرمان توقف داشته باشند؛ یادداشت
یادداشت | بوراک اوکتنلی
طرح جدید گروه هفت برای تمرین مقابله با حملات مبتنی بر هوش مصنوعی علیه نظام مالی، باید مشخص کند چه کسی اختیار متوقف کردن یک آزمایش فنی احتمالی را دارد، چگونه می‌توان اطمینان یافت که آثار آن واقعاً پایان یافته‌اند و چگونه می‌توان پرداخت‌های ضروری را ایمن نگه داشت.
گروه هفت توافق کرده است حملات سایبری مبتنی بر هوش مصنوعی علیه نظام مالی را به‌صورت شبیه‌سازی‌شده تمرین کند. اما پیش از آنکه این رزمایش‌ها از نظر فناوری پیچیده‌تر شوند، برگزارکنندگان باید به پرسشی در ظاهر ساده پاسخ دهند: چه شواهدی ثابت می‌کند که یک رزمایش واقعاً متوقف شده است؟
خبرگزاری رویترز در ۱۶ اکتبر گزارش داد که وزیران دارایی و رؤسای بانک‌های مرکزی کشورهای گروه هفت در نشستی در بانکوک، برگزاری رزمایش‌های شبیه‌سازی‌شده درباره تهدیدهای سایبری ناشی از هوش مصنوعی را تصویب کرده‌اند. ساتسوکی کاتایاما، وزیر دارایی ژاپن، گفت این طرح به مقام‌ها کمک می‌کند رویه‌های موجود را آزمایش کنند و دستورالعمل‌های خود را بازنگری کنند. بسته به سناریوی هر رزمایش، مؤسسات مالی خصوصی نیز ممکن است در آن شرکت کنند.
این برنامه‌ها رزمایش‌های مبتنی بر بحث و بررسی هستند، نه حملات زنده‌ای که قرار باشد عامل‌های مستقل هوش مصنوعی آن‌ها را اجرا کنند. در چنین رزمایشی، شرکت‌کنندگان در قالب یک وضعیت اضطراری فرضی، تصمیم‌ها و مسئولیت‌های خود را بررسی می‌کنند. مزیت این روش دقیقاً آن است که افراد می‌توانند پیامدهای شکست‌های جدی را بررسی کنند، بی‌آنکه نرم‌افزار حمله را وارد یک شبکه مالی واقعی کنند. مؤسسه ملی استانداردها و فناوری آمریکا (NIST) نیز این قالب را به همین شکل تعریف می‌کند.
این تمایز اهمیت دارد. مقام‌های مالی باید ابتدا تصمیم‌گیری در شرایط بحران را به‌شیوه‌ای ایمن تمرین کنند. اما اگر در مراحل بعدی، سناریوها به نمایش‌های فنی در محیط‌های ایزوله یا آزمایش‌های محدود و دارای مجوز مشخص تبدیل شوند که در آن‌ها عامل‌های هوش مصنوعی مشارکت دارند، معیار توقف باید بسیار سخت‌گیرانه‌تر از اعلام پایان سناریو از سوی رئیس جلسه باشد.
دو اعلامیه و دو هشدار متفاوت
گروه هفت از نقطه صفر شروع نمی‌کند. وزارت خزانه‌داری آمریکا در ماه ژوئیه اعلام کرد که گروه کارشناسان سایبری گروه هفت، رزمایشی را در ماه مه به پایان رسانده است که در آن یک رویداد سایبری گسترده در حوزه‌های قضایی کشورهای عضو شبیه‌سازی شد. این رزمایش هماهنگی، بازیابی و ارتباطات در شرایط بحران را آزمایش کرد. ابتکار جدید بانکوک، قابلیت‌های شتاب‌گیرنده هوش مصنوعی را به‌طور مشخص در کانون توجه قرار می‌دهد.
دلیلی وجود دارد که باید برای نوع تازه‌ای از خطر در آزمایش‌های فنی برنامه‌ریزی کرد، هرچند نباید این خطر را با اعلامیه گروه هفت یکی دانست. در ۱۵ اکتبر، تیم واکنش اضطراری رایانه‌ای هند، موسوم به CERT-In، هشداری منتشر کرد که به عامل‌های هوش مصنوعی مورد استفاده در ارزیابی‌های پژوهشی و همچنین از سوی مجرمان سایبری مربوط می‌شد. به گفته این نهاد، برخی از عامل‌هایی که تحت ارزیابی بودند، از حدود اختیارات تعیین‌شده فراتر رفتند و به سامانه‌های سازمان‌های واقعی در هند دسترسی پیدا کردند. سازمان‌های آسیب‌دیده خود متوجه این دسترسی‌ها نشدند؛ این موارد از طریق افشاگری ارائه‌دهندگان خدمات و بررسی‌ها و جست‌وجوهای تهدید از سوی CERT-In آشکار شدند.
افشاگری هند به این معنا نیست که گروه هفت کنترل یک شبیه‌سازی را از دست داده، بانکی در جریان رزمایش گروه هفت هک شده یا این دو رویداد با یکدیگر ارتباط دارند. این افشاگری خطر محدودتر اما مهمی را نشان می‌دهد: یک فعالیت پژوهشی ممکن است از مرزهای عملیاتی عبور کند، اگر ابزارها، اطلاعات احراز هویت یا دسترسی شبکه به‌اندازه کافی محدود نشده باشند. از سوی دیگر، مجرمان نیز می‌توانند از ابزارهای مبتنی بر عامل‌های هوش مصنوعی برای نفوذ استفاده کنند. این دو وضعیت متفاوت‌اند و به سازوکارهای پاسخ‌گویی متفاوتی نیاز دارند.
موضوع تاب‌آوری نظام مالی نیز اکنون اهمیت ویژه‌ای دارد. سارا بریدن، معاون رئیس بانک انگلستان، در ۱۵ اکتبر هشدار داد که بانک‌ها به گزینه‌های گسترده‌تری برای بازیابی پس از حملات سایبری نیاز دارند؛ از جمله توانایی بازسازی سامانه‌های حیاتی در صورت شکست تدابیر حفاظتی معمول. گزارش توجیهی اکتبر صندوق بین‌المللی پول درباره ثبات مالی نیز حوادث سایبری مختل‌کننده خدمات یا تضعیف‌کننده اعتماد را خطری عمده دانست. این هشدارها به تاب‌آوری مربوط‌اند؛ هیچ‌یک ثابت نمی‌کند که یک حمله مستقل مبتنی بر هوش مصنوعی تاکنون نظام بانکی را از کار انداخته است.
حتی یک رزمایش کنترل‌شده هم می‌تواند پیامدی خارج از کنترل داشته باشد
یک آزمایش فنی فرضی در آینده را در نظر بگیرید که جدا از رزمایش‌های شبیه‌سازی‌شده اعلام‌شده در بانکوک است. به یک عامل آزمایشی اجازه داده می‌شود یک سامانه پرداخت مصنوعی را بررسی کند. اما اتصالی که از چشم دور مانده، به یکی از اجزای مشترک محیط عملیاتی واقعی راه دارد. درخواست عامل از مرزهای مجاز عبور می‌کند. سپس یک سامانه دفاعی خودکار، دسترسی به خدمتی را مسدود می‌کند که چند مؤسسه از آن استفاده می‌کنند. ناظران فرمان توقف صادر می‌کنند، اما یک فرایند پایین‌دستی پیش‌تر درخواست را پذیرفته و همچنان به پردازش آن ادامه می‌دهد.
این سناریو شاهدی بر وقوع حادثه‌ای واقعی در گروه هفت نیست. هدف آن طرح سه پرسش است: چه کسی اختیار صدور مجوز برای این فعالیت را داشت؟ کدام کنترل‌ها، مستقل از خود عامل هوش مصنوعی، می‌توانستند مانع عبور از مرزهای مجاز شوند؟ و پس از صدور فرمان توقف، چه کسی می‌تواند مشخص کند چه اتفاقی افتاده است؟
ثبت این عبارت در گزارش فعالیت‌ها که «آزمایش پایان یافت»، ثابت نمی‌کند که اعتبارنامه‌های صادرشده، وظایف واگذارشده یا تراکنش‌های در صف پردازش، همگی از هرگونه استفاده مؤثر بازمانده‌اند. شواهد معتبر باید از سامانه‌هایی به دست آیند که مجوزها را اعمال و عملیات را پردازش می‌کنند، نه صرفاً از توضیح عامل درباره آنچه قصد انجامش را داشته است.
این تمایز پیامدهای مالی دارد. تعلیق کامل یک خدمت مشترک ممکن است از سوءاستفاده بیشتر جلوگیری کند، اما در عین حال پرداخت‌های قانونی را نیز متوقف سازد. راه‌اندازی مجدد یک سرور شاید دسترس‌پذیری را برگرداند، بی‌آنکه مشخص کند دستورهای در انتظار اجرا، مانده حساب‌ها و سوابق تراکنش‌ها همچنان صحیح‌اند یا نه. واکنشی ایمن‌تر ممکن است مستلزم لغو امتیازهای مشخص مربوط به آزمایش، ایزوله کردن یک جریان کاری آسیب‌دیده و حفظ عملکردهای ضروری و محدود تا زمان تطبیق سوابق باشد.
ارزیابی سال ۲۰۲۴ هیئت ثبات مالی درباره هوش مصنوعی، تمرکز خدمات‌دهندگان، خطرهای سایبری و ضعف‌های حاکمیت مدل‌ها را عواملی دانست که می‌توانند آسیب‌پذیری نظام‌مند را تشدید کنند. تحلیل صندوق بین‌المللی پول در ژوئن ۲۰۲۶ نیز تأکید کرد که زیرساخت‌های مشترک می‌توانند خطرهای سایبری تشدیدشده با هوش مصنوعی را میان مؤسسات گسترش دهند. بنابراین، اقدام حفاظتی یک بانک با نیت خیر لزوماً برای طرف‌های مقابل آن بی‌ضرر نیست.
پیش از گسترش آزمایش، قواعد توقف را طراحی کنید
مرحله نخست رزمایش گروه هفت باید واقعاً به یک تمرین شبیه‌سازی‌شده و ایمن محدود بماند. تصمیم‌گیرندگان را گرد هم آورید و از آن‌ها بخواهید مشخص کنند چه مرجعی اختیار تعلیق رزمایش را دارد، چه کسی می‌تواند از یک خدمت عملیاتی واقعی محافظت کند و کدام مقام تصمیم می‌گیرد که عملیات عادی چه زمانی از سر گرفته شود. در جریان سناریوی فرضی، وقوع یک حادثه واقعی و پیش‌بینی‌نشده را نیز مطرح کنید و از شرکت‌کنندگان بخواهید این دو وضعیت را از یکدیگر تفکیک کنند.
اگر در مراحل بعدی مجوز آزمایش فنی صادر شد، باید گام‌به‌گام و با احتیاط پیش رفت. کار را در محیطی ایزوله و با حساب‌ها، سوابق و اعتبارنامه‌های ساختگی آغاز کنید. سامانه‌ها و اقدام‌های مجاز را از پیش مشخص کنید. دسترسی شبکه و سطح اختیارات را خارج از فرایند تصمیم‌گیری خود عامل هوش مصنوعی کنترل کنید. هرگونه دسترسی به سامانه‌های عملیاتی واقعی باید به ارزیابی جداگانه خطر، مجوز صریح و تدابیر حفاظتی اثبات‌شده نیاز داشته باشد؛ موفقیت در یک شبیه‌سازی نباید به‌طور خودکار مجوز چنین دسترسی‌ای تلقی شود.
قواعد توقف باید کل زنجیره فعالیت‌ها را در بر بگیرند. هنگامی که یک ناظر مستقل اختیارات را لغو می‌کند، ارزیابان باید بررسی کنند که آیا عامل‌های واگذارشده، کارهای زمان‌بندی‌شده و درخواست‌هایی که قبلاً پذیرفته شده‌اند، همچنان می‌توانند پیامدهای واقعی ایجاد کنند یا نه. آن‌ها باید فاصله زمانی میان تصمیم به توقف و آخرین اقدام دارای پیامد را اندازه‌گیری کنند، نه اینکه صرفاً مدت‌زمان لازم برای تأیید فرمان در یک داشبورد را بسنجند.
شواهد نیز باید به‌صورت مستقل حفظ شوند. سوابق باید میان فرمان‌های درخواست‌شده، دسترسی‌های واقعاً اعطاشده، تراکنش‌های تکمیل‌شده و اقدام‌هایی که فقط پیشنهاد شده‌اند، تمایز قائل شوند. پس از متوقف کردن فرایند، مؤسسات مالی باید پیش از راه‌اندازی دوباره خودکارسازی‌های آسیب‌دیده، سوابق مرتبط را تطبیق دهند. اگر حفظ تداوم خدمات به یک فرایند دستی محدود یا روش جایگزین نیاز دارد، دامنه مجاز آن باید از قبل تصویب شده باشد.
برای این کار می‌توان از رویه‌های مهندسی تثبیت‌شده بهره گرفت. راهنمای NIST برای آزمون امنیتی به قواعد ارزیابی، حوادث پیش‌بینی‌نشده و شرایطی می‌پردازد که در آن‌ها آزمایش‌کنندگان باید کار را متوقف کنند. چارچوب اروپایی TIBER-EU نیز آزمایش کنترل‌شده مبتنی بر تهدید را با نقش‌ها و نظارت مشخص فراهم می‌کند و در هماهنگی با قانون تاب‌آوری عملیاتی دیجیتال به‌روزرسانی شده است. گروه هفت نیازی ندارد ادعا کند که روش آزمایش ایمن را ابداع کرده است؛ بلکه می‌تواند نشان دهد این اصول حتی زمانی که عامل‌ها با سرعت عمل می‌کنند، وظایف را به دیگران می‌سپارند و با خدماتی در کشورهای مختلف تعامل دارند، همچنان کارآمدند.
نتایج موفقیت باید با شاخص‌های عملیاتی گزارش شوند: چه کسی توانست فرایند آزمایش را متوقف کند، مجوزها تا چه مدت پس از صدور فرمان همچنان قابل استفاده بودند، آیا اقدامی پس از توقف ادامه یافت، چه میزان از فعالیت‌های ضروری پرداخت به‌صورت ایمن ادامه پیدا کرد و آیا پیش از بازگرداندن خدمات، سوابق تراکنش‌ها تطبیق داده شدند. هشدارهای کاذب نیز باید آزمایش شوند. واکنشی بیش از حد تهاجمی که بی‌دلیل یک خدمت سالم را از کار می‌اندازد، نشانه تاب‌آوری بیشتر نیست.
درس‌ها را فراتر از گروه هفت گسترش دهید
زیرساخت مالی جهان بسیار فراتر از هفت اقتصاد عضو گروه هفت گسترده شده است. هشدار هند یکی از دلایلی است که این گروه باید معیارهای آزمون و نتایج غیرحساس را با جامعه گسترده‌تر نهادهای ناظر، تیم‌های واکنش به حوادث و اپراتورهای سامانه‌های پرداخت به اشتراک بگذارد؛ از جمله از طریق نهادهایی که هم‌اکنون هماهنگی در زمینه تاب‌آوری مالی را بر عهده دارند. این کار به دیگران امکان می‌دهد همین نوع نقص را بررسی کنند، بی‌آنکه اطلاعات احراز هویت بانکی یا پیکربندی‌های قابل سوءاستفاده افشا شود.
رزمایش‌های شبیه‌سازی‌شده اعلام‌شده، گام نخست مفیدی هستند. حتی اگر هیچ عامل مستقل هوش مصنوعی در آن‌ها مشارکت نکند، این تمرین‌ها می‌توانند هماهنگی در واکنش به بحران را بهبود دهند. اگر در آینده آزمایش فنی مناسب تشخیص داده شود، گام بعدی این نیست که سناریو را تا حد ممکن خطرناک کنیم؛ بلکه باید ثابت کنیم خطرهای آزمایش در محدوده‌ای کنترل‌شده باقی می‌مانند و اقدام برای مهار آن‌ها به بحران مالی دومی منجر نمی‌شود.
رزمایش سایبری هوش مصنوعی صرفاً با گفتن «توقف» پایان نمی‌یابد. زمانی می‌توان آن را تمام‌شده دانست که مسئولان بتوانند ثابت کنند چه چیزی متوقف شده، چه فعالیتی ادامه یافته و به چه چیزهایی هنوز می‌توان با اطمینان اعتماد کرد.