کنترل امنیت شماره ۱۹: مدیریت پاسخ به رخداد؛ قبل از حادثه تمرین کنیم

حادثه امنیتی همیشه با آژیر و داشبورد قرمز شروع نمی‌شود. گاهی یک لاگ عجیب است، یک اکانت که از جای نامعمول لاگین کرده، یک فایل که رمز شده، یا کاربری که می‌گوید سیستمش رفتار عجیبی دارد. اگر از قبل برنامه نداشته باشیم، همان ساعت‌های اول با آزمون و خطا از دست می‌رود.

مبنای این مطلب: SANS Critical Security Control 19: Incident Response and Management، یعنی «مدیریت پاسخ به رخداد» در فهرست ۲۰ کنترل امنیتی SANS/CIS. متن زیر ترجمه خشک کنترل نیست؛ برداشت عملی از همان کنترل برای شبکه و زیرساخت سازمانی است.

کنترل شماره ۱۹ درباره مدیریت پاسخ به رخداد است. یعنی قبل از حادثه بدانیم چه چیزی رخداد حساب می‌شود، چه کسی تصمیم می‌گیرد، چه کسی سیستم را بررسی می‌کند و چه زمانی باید سرویس را قطع یا محدود کرد.

تعریف رخداد باید روشن باشد

هر هشدار کوچکی حادثه بزرگ نیست، ولی بعضی نشانه‌ها باید سریع جدی گرفته شوند: ورود موفق مشکوک، اجرای بدافزار، تغییر غیرعادی دسترسی‌ها، خروج حجم زیاد داده، رمز شدن فایل‌ها، تغییر تنظیمات فایروال یا خاموش شدن لاگ.

نقش‌ها را همان روز حادثه تعیین نکنیم

در زمان حادثه، ابهام خطرناک است. باید مشخص باشد چه کسی مسئول هماهنگی است، چه کسی لاگ‌ها را جمع می‌کند، چه کسی با مدیران ارتباط دارد، چه کسی تصمیم فنی می‌گیرد و چه کسی با کاربر یا پیمانکار صحبت می‌کند.

  • لیست تماس افراد کلیدی آماده باشد.
  • دسترسی اضطراری کنترل‌شده وجود داشته باشد.
  • روش جمع‌آوری شواهد مشخص باشد.
  • تصمیم قطع سرویس یا ایزوله کردن سیستم چارچوب داشته باشد.

اول مهار، بعد پاکسازی

اشتباه رایج این است که در لحظه اول همه چیز را پاک کنیم یا سیستم را سریع فرمت کنیم. شاید سرویس زودتر برگردد، ولی شواهد از بین می‌رود و ریشه مشکل معلوم نمی‌شود. در پاسخ به رخداد باید اول مهار کنیم، بعد شواهد لازم را حفظ کنیم، سپس پاکسازی و بازیابی انجام شود.

لاگ بدون زمان درست دردسر است

برای بررسی رخداد، زمان درست حیاتی است. اگر ساعت سرورها، فایروال و سیستم‌ها هماهنگ نباشد، ساختن خط زمانی حادثه سخت می‌شود. لاگ‌ها باید نگهداری شوند و قابل جستجو باشند. این بخش به کنترل لاگ و مانیتورینگ وابسته است.

بعد از حادثه یاد بگیریم

بعد از کنترل حادثه نباید فقط خوشحال شویم که تمام شد. باید بررسی شود چه چیزی باعث رخداد شد، کدام هشدار دیده نشد، کدام دسترسی اضافه بود، کدام بکاپ کمک کرد یا نکرد و چه تغییری باید در فرآیندها انجام شود.

جمع‌بندی عملی

پاسخ به رخداد یعنی داشتن برنامه کوتاه، نقش‌های مشخص، لاگ قابل اعتماد، روش مهار و تمرین دوره‌ای. روز حادثه وقت نوشتن برنامه نیست؛ وقت اجرای چیزی است که قبلا تمرین شده است.

Share
Published by

Recent Posts

کنترل امنیت شماره ۲۰: تست نفوذ و Red Team؛ آزمون واقعی کنترل‌ها

تست نفوذ و ردتیم وقتی ارزش دارد که خروجی آن به اصلاح واقعی کنترل‌ها برسد،…

13 ساعت ago

کنترل امنیت شماره ۱۸: امنیت نرم‌افزارهای کاربردی

وقتی برنامه وب آسیب‌پذیر باشد، شبکه سالم و فایروال مرتب هم همیشه نمی‌تواند جلوی سوءاستفاده…

13 ساعت ago

کنترل امنیت شماره ۱۷: آموزش امنیتی؛ چیزی که ابزار جای آن را نمی‌گیرد

آموزش امنیتی وقتی مفید است که به کار روزانه وصل باشد؛ نه یک فایل طولانی…

13 ساعت ago

کنترل امنیت شماره ۱۶: پایش و کنترل حساب‌های کاربری

اکانت رها شده، رمز قدیمی و دسترسی باقی‌مانده از شغل قبلی، از مسیرهای ساده ولی…

13 ساعت ago

کنترل امنیت شماره ۱۵: کنترل دسترسی بی‌سیم؛ وای‌فای را جدی بگیریم

شبکه بی‌سیم اگر درست کنترل نشود، عملا یک کابل شبکه است که تا بیرون ساختمان…

13 ساعت ago

کنترل امنیت شماره ۱۴: دسترسی بر اساس نیاز کاری، نه اعتماد کلی

در کنترل ۱۴ اصل ساده است: هرکس فقط همان چیزی را ببیند که برای کارش…

13 ساعت ago