پیش از قضاوت درباره انگیزه، روشن کنید چه اتفاقی افتاده است
فرض کنید شرکتی فعال در چند منطقه متوجه می‌شود که یک حساب فروش، شب‌هنگام چند بار اطلاعات مشتریان را بارگیری کرده است. تیم امنیت یک هشدار ناهنجاری دریافت کرده، نه نتیجه تحقیقی که رفتار مخرب را ثابت کرده باشد. شاید کارمند مشغول تهیه گزارش فصلیِ تأییدشده باشد، شاید خرابی برنامه همگام‌سازی باعث تکرار بارگیری شده باشد و شاید فردی خارج از سازمان حساب را در اختیار گرفته باشد. فرایند رسیدگی باید ابتدا مشخص کند واقعاً به چه داده‌هایی دسترسی پیدا شده، از کدام هویت استفاده شده و هدف کاری چه بوده است. ساعت، مکان یا حجم بارگیری به‌تنهایی مبنای برچسب‌زدن به افراد نیست.
پیشنهاد JOTOglobal این است که کار را با یک سامانه و یک عملیات حساس، مثلاً خروجی‌گیری انبوه از سامانه مشتریان، آغاز کنید. مسئول کسب‌وکار مشخص می‌کند یک کار عادی به چه داده‌هایی نیاز دارد؛ مدیر برنامه مجوزها و رابط‌های خروجی‌گیری را توضیح می‌دهد؛ و تیم امنیت تعیین می‌کند چه گزارش‌های رویدادی در دسترس است. ابتدا همین سناریوی محدود را به فرایندی قابل بررسی تبدیل کنید و بعد آن را به پوشه‌های مشترک، ایمیل و سامانه‌های دیگر گسترش دهید. در غیر این صورت ممکن است فهرستی گسترده از هشدارها بسازید که کسی قادر به توضیح آن‌ها نباشد.
هشدار را به واقعیت‌های قابل بازبینی تبدیل کنید
در NIST SP 800-53 Rev.5، کنترل AU-2 به ثبت رویداد، AU-6 به بازبینی، تحلیل و گزارش سوابق ممیزی و AC-6 به اصل حداقل دسترسی مربوط است. این کنترل‌ها برای طراحی کنترل راهنما هستند، اما تعیین نمی‌کنند هر نقش شغلی باید روزانه چند رکورد بارگیری کند. فیلدها، تقسیم مسئولیت و روش‌های پذیرش در ادامه، پیشنهادهای اجرایی JOTOglobal هستند و باید با قابلیت سامانه و ریسک کسب‌وکار سازگار شوند. اجرای این پیشنهادها به معنای دریافت گواهی نیست.
هر سابقه در انتظار بررسی باید بتواند زمان رویداد، حساب، منبع هویت، شیء مورد دسترسی، نتیجه عملیات و شناسه نشستِ موجود را به هم مرتبط کند. ساعت سامانه و منطقه زمانی را ثبت و کلیک کاربر را از همگام‌سازی پس‌زمینه و فراخوانی حساب سرویس جدا کنید. اگر گزارش صرفاً وقوع خروجی‌گیری را نشان می‌دهد ولی محدوده داده‌ها را مشخص نمی‌کند، کمبود شواهد را ثبت کنید. یک فراخوانی رابط، اثبات نشت تمام پایگاه داده نیست. در یادداشت تحقیق، واقعیت‌های تأییدشده، فرضیه‌های نیازمند بررسی و گزارش‌های مفقود را جدا بنویسید.
جمع‌آوری گزارش‌ها باید هدف روشن و محدودیت دسترسی داشته باشد. تحلیلگر معمولاً ابتدا به دسته داده، تعداد رکورد و کد نتیجه نیاز دارد، نه لزوماً محتوای کامل اطلاعات مشتری. در تحقیقات مربوط به کارکنان، مطابق رویه سازمان نقش‌های تعیین‌شده مدیریتی، منابع انسانی یا حقوقی را دخیل کنید و دایره افراد مطلع را محدود نگه دارید. برای ساده‌کردن عیب‌یابی، اطلاعات شخصی، توکن کامل یا تمام داده‌های خروجی را در تیکتی که همه به آن دسترسی دارند کپی نکنید.
ناهنجاری را در زمینه کاری آن بررسی کنید
مسئول کشیک ابتدا بررسی می‌کند حساب متعلق به فرد شاغل است یا نه، نقش او اخیراً تغییر کرده یا نه، تیکت تأییدشده‌ای وجود دارد یا نه و دستگاه و نشست برنامه با کار موردنظر سازگارند یا نه. از مسیرهای ارتباطی داخلیِ شناخته‌شده استفاده کنید، نه اطلاعات تماس داخل ایمیل مشکوک. پرسش‌ها را درباره کار و زمان مطرح کنید: کدام وظیفه به این خروجی نیاز داشت، نتیجه برای چه کسی بود و فایل باید کجا نگهداری شود؟ هدف روشن‌کردن کار است، نه واداشتن کارمند به اثبات نداشتن نیت مخرب.
مسئول کسب‌وکار ضرورت کار را تأیید می‌کند، مسئول سامانه بررسی می‌کند مجوزها از محدوده آن فراتر رفته‌اند یا نه، و تیم امنیت نشانه‌های مرتبط مانند شکست‌های پیاپی ورود، تغییر غیرعادی مجوز یا نشست ناشناس را تحلیل می‌کند. هر نشانه منفرد ممکن است توضیح معقولی داشته باشد. وقتی چند شاهد مستقل یکدیگر را تأیید می‌کنند، اولویت رسیدگی را افزایش دهید. برای تیم‌های بین‌المللی، ساعات کار محلی و ترتیبات پشتیبانی از راه دور را نیز ثبت کنید تا همکاری معمول میان مناطق زمانی دائماً ناهنجاری تلقی نشود.
برای هر اقدام، محدوده، مسئول و شرط بازیابی تعیین کنید
اگر رویداد هنوز تأیید نشده و نشانه‌ای از ادامه آسیب وجود ندارد، می‌توان ابتدا گزارش‌های لازم را حفظ کرد، خروجی‌گیری جدید را محدود کرد یا بازبینی مسئول مربوط را خواست. اگر افشای اعتبارنامه یا ادامه عملیات خارج از مجوز تأیید شده است، نقش کشیکِ دارای اختیار باید طبق برنامه پاسخ، نشست‌های مربوط را لغو، حساب هدف را تعلیق یا رابط آسیب‌دیده را محدود کند. هدف اقدام را مشخص نگه دارید؛ ناهنجاری یک حساب دلیل کافی برای ازکارانداختن بی‌تمایز همه سامانه‌های یک واحد نیست. دلیل، نقش تأییدکننده، زمان اجرا و محدوده اثر هر اقدام را ثبت کنید.
پیش از بازگرداندن دسترسی، تأیید کنید اعتبارنامه‌ها و نشست‌ها در حد قابلیت سامانه رسیدگی شده‌اند، مجوزهای مربوط دوباره بررسی شده‌اند و کار عادی قابل ازسرگیری است. تغییر گذرواژه لزوماً همه نشست‌های موجود یا مجوزهای طرف ثالث را لغو نمی‌کند؛ قابلیت واقعی سامانه را موردبه‌مورد بررسی کنید. برای حساب مشترک، اعتبارنامه طولانی‌مدت سرویس و اتصالی که جداگانه قابل لغو نیست، اقدام جبرانی موقت و مسئول آن را ثبت و جایگزینی را برنامه‌ریزی کنید. عملیاتی را که از نظر فنی قابل انجام نیست، انجام‌شده گزارش نکنید.
سوابق تحقیق و سوابق بازیابی خدمت می‌توانند به هم مرتبط باشند، اما لازم نیست مخاطبانِ دارای دسترسی به آن‌ها یکسان باشند. تیم عملیات باید بداند کدام خدمت متوقف است، چه زمانی بازمی‌گردد و گام بعدی با چه کسی است. قضاوت‌های مربوط به کارکنان باید در اختیار نقش‌های مجاز باشد. این تفکیک هم به اقدام سریع تیم اجرایی کمک می‌کند و هم مانع انتشار حدس‌های تأییدنشده در گروه‌های پشتیبانی می‌شود.
فرایند را با سه نوع تمرین پذیرش ارزیابی کنید
تمرین اول، هشدار کاذب ناشی از کار عادی است: حساب آزمایشی یک عملیات انبوهِ تأییدشده انجام دهد؛ بررسی کنید هشدار به تیکت مرتبط می‌شود و مسئول کسب‌وکار می‌تواند آن را ببندد. تمرین دوم، تجاوز از محدوده دسترسی است: همان حساب برای داده‌ای خارج از وظیفه اقدام کند؛ رد دسترسی و موجودبودن گزارش را تأیید کنید و مطمئن شوید تلاش ناموفق، نشت موفق گزارش نمی‌شود. تمرین سوم، احتمال ازدست‌رفتن کنترل اعتبارنامه است: در محیط آزمایشیِ کنترل‌شده یک نشست ناشناس شبیه‌سازی کنید و بسنجید تیم کشیک می‌تواند طبق برنامه آن نشست را محدود و کار ضروری را بازیابی کند.
برای هر تمرین، شرط ایجاد رویداد، زمان عملیات، محل گزارش، نتیجه بررسی، اقدامات مهار و نتیجه بازیابی را نگه دارید. معیار پذیرش این است که شواهد به هم متصل باشند، مسئولان بتوانند مسئولیت را تحویل بگیرند، محدودیت واقعاً مؤثر باشد و پس از بازیابی مجوز ناخواسته‌ای باقی نماند. کسب‌وکار می‌تواند هدف زمانی پاسخ تعیین کند، اما باید نقطه شروع و پایان آن روشن باشد. زمان نخستین هشدار تا تأیید انسانی با زمان تأیید حادثه تا مسدودکردن دسترسی، دو شاخص متفاوت است.
درس‌های بازبینی را به مجوزها و کار روزمره تبدیل کنید
بازبینی نباید فقط درباره کسی باشد که روی هشدار کلیک کرده است. بپرسید چرا حساب به‌طور مستمر به این داده‌ها دسترسی داشت، آیا خبر خروج فرد یا تغییر نقش به مدیر سامانه رسید، آیا مجوز موقت منقضی شد و آیا حساب سرویس مسئول دائمی دارد. برای کارهای مشروعِ پرتکرار، فرایند خروجی‌گیری کنترل‌شده یا قواعد توضیح‌دهنده را بهتر کنید؛ برای هشدار فاقد شاهد، ثبت لازم را اضافه کنید. بالا بردن ساده آستانه برای کاهش تعداد هشدار و جمع‌آوری بی‌حد داده به‌جای تصمیم روشن، راه‌حل مناسبی نیست.
این فرایند برای سامانه‌های کاری دارای سوابق پایه هویت و عملیات مناسب است. در محیط دارای هویت مشترک، کپی آفلاین یا گزارش غیرقابل‌ردیابی، ابتدا مرز مسئولیت و قابلیت ثبت پایه را تکمیل کنید. می‌توان با یک فرایند خروجی‌گیری، یک مسئول کسب‌وکار و یک تمرین کامل شروع کرد و بر مبنای شواهد قابل بازبینی درباره سرمایه‌گذاری بعدی تصمیم گرفت. هدف نهایی شناسایی و محدودکردن به‌موقع دسترسی نامناسب است، در عین اینکه کار عادی امکان توضیح و بازیابی داشته باشد؛ نه اینکه هر اقدام غیرمعمول تهدیدی از سوی کارکنان تلقی شود.