تمرین باید تصمیمها را بیازماید، نه از بر خواندن طرح را
یک شرکت فرضی را در نظر بگیرید که هر سال یک تمرین رومیزی رخداد امنیتی برگزار میکند. در روز تمرین، تسهیلگر اعلام میکند «باجافزار شناسایی شد»، نمایندگان هر واحد بخشهایی از طرح را که به آنها مربوط است بلند میخوانند، دو ساعت بعد همه فهرست حضور را امضا میکنند و گزارش مینویسد «تمرین با موفقیت انجام شد». چند ماه بعد رخدادی واقعی پیش میآید و تازه تیم درمییابد که شماره تلفن کشیک در طرح اکنون متعلق به شخص دیگری است، هیچکس بهروشنی اختیار تصمیمگیری درباره قطع شبکه تولید را ندارد، و درباره اینکه کدام مدیر ارشد باید بیانیه بیرونی را تأیید کند اختلاف وجود دارد. تمرین برگزار شده بود، اما مهمترین چیزها را نیازموده بود.
راهنمای NIST درباره برنامههای آزمون، آموزش و تمرین، تمرین رومیزی را فعالیتی مبتنی بر گفتوگو تعریف میکند که تجهیزات یا منابع دیگری را به کار نمیگیرد و در آن تسهیلگر شرکتکنندگان را در یک یا چند سناریو هدایت میکند تا درباره نقشها و واکنشهایشان در شرایط اضطراری گفتوگو کنند. این راهنما تمرین رومیزی را به مراحل طراحی، تهیه، اجرا و ارزیابی تقسیم میکند و توصیه میکند در مرحله طراحی، اهداف مشخص شوند و تسهیلگر و ثبتکننده داده تعیین شوند و پس از تمرین گزارش پس از اقدام تهیه شود. این راهنما در سال ۲۰۰۶ منتشر شده و میتواند پایه روششناختی باشد، نه الزام انطباقی کنونی. JOTOglobal بر این پایه پیشنهاد میکند هر تمرین رومیزی حول چند تصمیمی طراحی شود که افراد باید در همان لحظه بگیرند، تا شرکتکنندگان استدلال و حدود اختیار خود را آشکار کنند، نه اینکه متنی را تکرار کنند.
سناریو و ورودیها را حول نقاط تصمیم طراحی کنید
مرحله طراحی به رهبری مسئول امنیت انجام میشود. او ابتدا طرح یا فرایندی را که این بار باید آزموده شود برمیگزیند و سپس سه تا پنج نقطه تصمیم را فهرست میکند؛ برای نمونه اینکه آیا یک سامانه کسبوکاری جدا شود، آیا به نهادهای نظارتی یا مشتریان اطلاع داده شود، آیا با مراجع انتظامی تماس گرفته شود، آیا سایت پشتیبان فعال شود و چه کسی پیام بیرونی را تأیید میکند. خود سناریو کوتاه میماند و اطلاعات پیچیده در ورودیهایی قرار میگیرد که مرحلهبهمرحله ارائه میشوند. هر ورودی با یک نقطه تصمیم متناظر است و مشخص میکند در چه زمانی، به کدام نقش و برای برانگیختن چه گفتوگویی ارائه میشود. سناریوها باید بر معماری سامانهها و روابط تأمینکنندگان خود شرکت استوار باشند، نه اینکه از نمونههای عمومی رونویسی شوند، تا شکافهای آشکارشده مشخص و قابل اصلاح باشند. پس از تکمیل طراحی، یکی از همکارانی که در تمرین شرکت ندارد میتواند سناریو را بخواند تا تأیید کند ورودیها پاسخها را از پیش لو نمیدهند و آنقدر غیرواقعی نیستند که شرکتکنندگان آنها را بیربط بدانند.
شرکتکنندگان بر اساس تصمیمهای درگیر دعوت میشوند: مسئول پاسخ فنی، صاحبان سامانههای کسبوکاری، واحد حقوقی یا انطباق، ارتباطات بیرونی، منابع انسانی و نمایندهای از مدیریت که اختیار تأیید اقدامات مهم را دارد. در نخستین تمرین، کارکنان فنی و مدیریت میتوانند جداگانه تمرین کنند و سپس در یک جلسه مشترک هماهنگی آزموده شود، که با توصیه راهنما نیز همخوان است. تسهیلگر آهنگ جلسه را مدیریت میکند و بهجای شرکتکنندگان پاسخ نمیدهد. ثبتکننده داده فقط ثبت میکند و در گفتوگو شرکت نمیکند و برای هر نقطه تصمیم یادداشت میکند چه کسی آن را مطرح کرد، بر چه مبنایی، آیا باید منتظر تأیید کسی میماندند و چه مدت، و چه شکافهای اطلاعاتی یافت شد. یک هفته پیش از تمرین، راهنمای شرکتکنندگان که قواعد، زمانبندی و الزامات محرمانگی را توضیح میدهد ارسال میشود.
در جریان تمرین، درباره مبنا و اختیار بپرسید
هنگامی که پاسخی مبهم است، تسهیلگر دو پرسش پیگیری میپرسد: این قضاوت را بر پایه چه اطلاعاتی انجام میدهید و آیا واقعاً در این لحظه میتوانید به آن اطلاعات دست یابید؛ و چه کسی این تصمیم را تأیید میکند و اگر در دسترس نباشد چه کسی میتواند جانشین او شود. برای نمونه، اگر کسی بگوید «بیدرنگ به مشتریان اطلاع میدهیم»، تسهیلگر میتواند بپرسد فهرست مشتریان در کدام سامانه است، آیا آن سامانه در جریان رخداد در دسترس است و چه کسی متن اطلاعیه را نهایی میکند. چنین پرسشهایی اغلب فاصله میان اسناد و واقعیت را آشکار میکنند؛ مانند رابطی که از شرکت رفته، اطلاعات تماس پشتیبان که در سامانه آسیبدیده ذخیره شده، یا مجوزی که فقط سمت را نام برده اما جانشین ندارد. ثبتکننده داده این شکافها را همانگونه که هستند ثبت میکند و در همان لحظه درباره اینکه چه کسی درست میگوید بحث نمیکند، تا شرکتکنندگان برای محافظت از خود از وضعیت واقعی طفره نروند.
تمرین معمولاً نباید بیش از نیم روز طول بکشد و دستکم سی دقیقه برای جمعبندی حضوری در نظر گرفته شود که در آن شرکتکنندگان دو یا سه مسئلهای را که بیش از همه نگرانشان کرده نام ببرند. تسهیلگر برای پاسخ دادن عجله نمیکند، بلکه مسائل را برای گزارش پس از اقدام ثبت میکند. اگر تمرین شامل نام واقعی مشتریان، آسیبپذیری سامانهها یا جزئیات قرارداد باشد، توزیع مطالب باید کنترل شود و مطالب پس از پایان جمعآوری شوند تا خود اسناد تمرین منبع نشت اطلاعات نشوند. شرکتهایی که در چند منطقه فعالیت دارند میتوانند تمرین را بهصورت برخط برگزار کنند، اما باید مطمئن شوند نمایندگان مناطق همزمان در گفتوگوی نقاط تصمیم کلیدی شرکت دارند.
گزارش پس از اقدام، پیگیری اصلاحات و محدوده کاربرد
ظرف دو هفته پس از تمرین، مسئول امنیت بر پایه یادداشتهای ثبتکننده داده گزارش پس از اقدام را تکمیل میکند. گزارش بهجای اینکه فقط بگوید تمرین موفق بود، آنچه را واقعاً در هر نقطه تصمیم گفتوگو شد، مسائل یافتشده، اصلاحات پیشنهادی، مسئول هر مورد و مهلت آن را فهرست میکند. موارد اصلاحی باید در سامانه پیگیری کارهای روزمره ثبت شوند و پیش از شروع تمرین بعدی، تیم بررسی کند که آیا موارد قبلی تکمیل شدهاند و آگاهانه در سناریوی تازه بیازماید که آن تغییرات کارآمد هستند یا نه. یکی از خطاهای رایج این است که هدف «قبولی همه» تعیین شود که به سناریوهای بیش از حد ملایم میانجامد. خطای دیگر این است که فقط پاسخ فنی تمرین شود و پیوند آن با ارتباطات بیرونی، قضاوت حقوقی و تداوم کسبوکار نادیده بماند.
طراحی سناریو، شیوه پرسش و روش پیگیری در این مقاله، توصیه سازمانی JOTOglobal است و جایگزین الزامات مشخص نهادهای نظارتی صنعت درباره تمرین نیست. تمرین رومیزی فقط میتواند طرحها و فرایندهای تصمیمگیری را بیازماید و نمیتواند تأیید کند که سامانهها واقعاً در زمان مقرر بازیابی میشوند؛ این موضوع به تمرین عملیاتی یا آزمون فنی بهعنوان مکمل نیاز دارد. دفعات، دامنه و سطح مشارکت را هر شرکت باید بر اساس اهمیت کسبوکار، تغییرات اخیر و منابع در دسترس تعیین کند و هر بخشی که به اطلاعرسانی به نهادهای نظارتی بیرونی مربوط است باید از مقررات حوزه قضایی مربوط پیروی کند.
