حادثه امنیتی همیشه با آژیر و داشبورد قرمز شروع نمیشود. گاهی یک لاگ عجیب است، یک اکانت که از جای نامعمول لاگین کرده، یک فایل که رمز شده، یا کاربری که میگوید سیستمش رفتار عجیبی دارد. اگر از قبل برنامه نداشته باشیم، همان ساعتهای اول با آزمون و خطا از دست میرود.
مبنای این مطلب: SANS Critical Security Control 19: Incident Response and Management، یعنی «مدیریت پاسخ به رخداد» در فهرست ۲۰ کنترل امنیتی SANS/CIS. متن زیر ترجمه خشک کنترل نیست؛ برداشت عملی از همان کنترل برای شبکه و زیرساخت سازمانی است.
کنترل شماره ۱۹ درباره مدیریت پاسخ به رخداد است. یعنی قبل از حادثه بدانیم چه چیزی رخداد حساب میشود، چه کسی تصمیم میگیرد، چه کسی سیستم را بررسی میکند و چه زمانی باید سرویس را قطع یا محدود کرد.
تعریف رخداد باید روشن باشد
هر هشدار کوچکی حادثه بزرگ نیست، ولی بعضی نشانهها باید سریع جدی گرفته شوند: ورود موفق مشکوک، اجرای بدافزار، تغییر غیرعادی دسترسیها، خروج حجم زیاد داده، رمز شدن فایلها، تغییر تنظیمات فایروال یا خاموش شدن لاگ.
نقشها را همان روز حادثه تعیین نکنیم
در زمان حادثه، ابهام خطرناک است. باید مشخص باشد چه کسی مسئول هماهنگی است، چه کسی لاگها را جمع میکند، چه کسی با مدیران ارتباط دارد، چه کسی تصمیم فنی میگیرد و چه کسی با کاربر یا پیمانکار صحبت میکند.
- لیست تماس افراد کلیدی آماده باشد.
- دسترسی اضطراری کنترلشده وجود داشته باشد.
- روش جمعآوری شواهد مشخص باشد.
- تصمیم قطع سرویس یا ایزوله کردن سیستم چارچوب داشته باشد.
اول مهار، بعد پاکسازی
اشتباه رایج این است که در لحظه اول همه چیز را پاک کنیم یا سیستم را سریع فرمت کنیم. شاید سرویس زودتر برگردد، ولی شواهد از بین میرود و ریشه مشکل معلوم نمیشود. در پاسخ به رخداد باید اول مهار کنیم، بعد شواهد لازم را حفظ کنیم، سپس پاکسازی و بازیابی انجام شود.
لاگ بدون زمان درست دردسر است
برای بررسی رخداد، زمان درست حیاتی است. اگر ساعت سرورها، فایروال و سیستمها هماهنگ نباشد، ساختن خط زمانی حادثه سخت میشود. لاگها باید نگهداری شوند و قابل جستجو باشند. این بخش به کنترل لاگ و مانیتورینگ وابسته است.
بعد از حادثه یاد بگیریم
بعد از کنترل حادثه نباید فقط خوشحال شویم که تمام شد. باید بررسی شود چه چیزی باعث رخداد شد، کدام هشدار دیده نشد، کدام دسترسی اضافه بود، کدام بکاپ کمک کرد یا نکرد و چه تغییری باید در فرآیندها انجام شود.
برای تصمیم بهتر درباره کنترل امنیت شماره ۱۹
پاسخ به رخداد یعنی داشتن برنامه کوتاه، نقشهای مشخص، لاگ قابل اعتماد، روش مهار و تمرین دورهای. روز حادثه وقت نوشتن برنامه نیست؛ وقت اجرای چیزی است که قبلا تمرین شده است.
تمرین پاسخ به رخداد باید کوچک و واقعی باشد
خیلی از سازمانها برنامه پاسخ به رخداد را به یک فایل طولانی تبدیل میکنند که روز حادثه کسی آن را باز نمیکند. تمرین بهتر میتواند کوچکتر باشد: یک سناریوی ورود مشکوک VPN، یک Rule تغییر کرده روی فایروال، یک سرور با ترافیک خروجی غیرعادی یا یک هشدار WAF که احتمالاً false positive نیست. مهم این است که تیم در همان تمرین بفهمد لاگ کجاست، چه کسی تصمیم میگیرد، چه کسی با مالک سرویس صحبت میکند و چه چیزی نباید قبل از جمعآوری شواهد پاک شود.
برای چارچوب رسمی، NIST SP 800-61 Rev.2 درباره Computer Security Incident Handling مرجع شناختهشدهای است و CIS Controls v8 هم روی Incident Response Management تأکید دارد. در اجرا، این منابع باید به یک playbook کوتاه و قابل تمرین تبدیل شوند؛ نه سندی که فقط برای audit نوشته شده باشد.
چند نشانه که برنامه هنوز خام است
- هیچکس نمیداند در تعطیلات با چه شمارهای باید تماس بگیرد.
- لاگ فایروال، VPN، WAF و سرورها ساعت هماهنگ ندارند.
- دسترسی اضطراری وجود دارد، اما مالک و زمان استفاده از آن مشخص نیست.
- بعد از حادثه، جلسه کوتاه درسآموختهها برگزار نمیشود.
اگر این موارد حل نشده باشند، حتی ابزارهای خوب هم در ساعت اول حادثه بهره کامل نمیدهند. ارتباط این کنترل با مانیتورینگ و پشتیبانی امنیت شبکه مستقیم است.
