کنترل امنیت شماره ۱۹: مدیریت پاسخ به رخداد؛ قبل از حادثه تمرین کنیم
حادثه امنیتی همیشه با آژیر و داشبورد قرمز شروع نمیشود. گاهی یک لاگ عجیب است، یک اکانت که از جای نامعمول لاگین کرده، یک فایل که رمز شده، یا کاربری که میگوید سیستمش رفتار عجیبی دارد. اگر از قبل برنامه نداشته باشیم، همان ساعتهای اول با آزمون و خطا از دست میرود.
مبنای این مطلب: SANS Critical Security Control 19: Incident Response and Management، یعنی «مدیریت پاسخ به رخداد» در فهرست ۲۰ کنترل امنیتی SANS/CIS. متن زیر ترجمه خشک کنترل نیست؛ برداشت عملی از همان کنترل برای شبکه و زیرساخت سازمانی است.
کنترل شماره ۱۹ درباره مدیریت پاسخ به رخداد است. یعنی قبل از حادثه بدانیم چه چیزی رخداد حساب میشود، چه کسی تصمیم میگیرد، چه کسی سیستم را بررسی میکند و چه زمانی باید سرویس را قطع یا محدود کرد.
تعریف رخداد باید روشن باشد
هر هشدار کوچکی حادثه بزرگ نیست، ولی بعضی نشانهها باید سریع جدی گرفته شوند: ورود موفق مشکوک، اجرای بدافزار، تغییر غیرعادی دسترسیها، خروج حجم زیاد داده، رمز شدن فایلها، تغییر تنظیمات فایروال یا خاموش شدن لاگ.
نقشها را همان روز حادثه تعیین نکنیم
در زمان حادثه، ابهام خطرناک است. باید مشخص باشد چه کسی مسئول هماهنگی است، چه کسی لاگها را جمع میکند، چه کسی با مدیران ارتباط دارد، چه کسی تصمیم فنی میگیرد و چه کسی با کاربر یا پیمانکار صحبت میکند.
- لیست تماس افراد کلیدی آماده باشد.
- دسترسی اضطراری کنترلشده وجود داشته باشد.
- روش جمعآوری شواهد مشخص باشد.
- تصمیم قطع سرویس یا ایزوله کردن سیستم چارچوب داشته باشد.
اول مهار، بعد پاکسازی
اشتباه رایج این است که در لحظه اول همه چیز را پاک کنیم یا سیستم را سریع فرمت کنیم. شاید سرویس زودتر برگردد، ولی شواهد از بین میرود و ریشه مشکل معلوم نمیشود. در پاسخ به رخداد باید اول مهار کنیم، بعد شواهد لازم را حفظ کنیم، سپس پاکسازی و بازیابی انجام شود.
لاگ بدون زمان درست دردسر است
برای بررسی رخداد، زمان درست حیاتی است. اگر ساعت سرورها، فایروال و سیستمها هماهنگ نباشد، ساختن خط زمانی حادثه سخت میشود. لاگها باید نگهداری شوند و قابل جستجو باشند. این بخش به کنترل لاگ و مانیتورینگ وابسته است.
بعد از حادثه یاد بگیریم
بعد از کنترل حادثه نباید فقط خوشحال شویم که تمام شد. باید بررسی شود چه چیزی باعث رخداد شد، کدام هشدار دیده نشد، کدام دسترسی اضافه بود، کدام بکاپ کمک کرد یا نکرد و چه تغییری باید در فرآیندها انجام شود.
جمعبندی عملی
پاسخ به رخداد یعنی داشتن برنامه کوتاه، نقشهای مشخص، لاگ قابل اعتماد، روش مهار و تمرین دورهای. روز حادثه وقت نوشتن برنامه نیست؛ وقت اجرای چیزی است که قبلا تمرین شده است.

هاردنینگ Cisco؛ کنترل IP Options و کاهش فشار روی CPU
بکدور FIRESTARTER روی Cisco ASA/FTD؛ بعد از Patch هم تمام نمیشود
کنترل امنیت شماره ۱۵: کنترل دسترسی بیسیم؛ وایفای را جدی بگیریم
کنترل امنیت شماره ۱۶: پایش و کنترل حسابهای کاربری
کنترل امنیت شماره ۱۳: حفاظت از دادهها؛ وقتی فایل مهمتر از سرور است
جلوگیری از حملات Brute-force روی تجهیزات Cisco