وجود فایروال، ابزار حفاظت از سرورها و سامانه مدیریت رویدادهای امنیتی، به‌تنهایی نشان نمی‌دهد که سازمان از معماری دفاع در عمق مؤثری برخوردار است. ممکن است تمام این ابزارها در زیرساخت حضور داشته باشند، اما یک حساب مدیریتی سرقت‌شده همچنان امکان دسترسی به سرورها، تجهیزات شبکه و نسخه‌های پشتیبان را فراهم کند.
در قسمت اول مقاله مفهوم دفاع در عمق یا Defense in Depth، لایه‌های اصلی آن و نقش SOC و SIEM را بررسی کردیم. در این بخش، به این موضوع می‌پردازیم که چگونه می‌توان این رویکرد را به یک معماری عملیاتی تبدیل کرد؛ معماری‌ای که شکست یک کنترل را پیش‌بینی کند و برای شناسایی، مهار و بازیابی پس از آن آماده باشد.
طراحی دفاع در عمق از مسیر حمله
برای طراحی دفاع چندلایه، ابتدا باید مشخص شود مهاجم از چه مسیرهایی می‌تواند به دارایی‌های حساس برسد. فهرست تجهیزات و نرم‌افزارها نقطه شروع مفیدی است، اما ارتباط میان دارایی‌ها، حساب‌های کاربری و مجوزهای دسترسی نیز باید بررسی شود. برای مثال، در یک سامانه تحت وب، مسیر احتمالی حمله ممکن است از بهره‌برداری از یک آسیب‌پذیری آغاز شود، به اجرای کد روی سرور برنامه برسد و سپس به سوءاستفاده از حساب سرویس برای دسترسی به پایگاه داده منجر شود.
بیشتر بخوانید: تحلیل آسیب‌پذیری‌ها و نقاط ضعف حیاتی در سامانه‌های SIEM سازمانی
در این سناریو، هر مرحله به کنترل متناسب با خود نیاز دارد:
- اصلاح آسیب‌پذیری و استفاده از WAF برای کاهش احتمال بهره‌برداری از برخی حملات وب.
- مقاوم‌سازی سرور و محدودسازی مجوزهای حساب سرویس برای کاهش امکانات مهاجم.
- کنترل ارتباطات میان سرور برنامه و پایگاه داده برای محدود کردن دسترسی.
- ثبت و تحلیل فعالیت‌های مشکوک برای شناسایی حمله.
- تعریف اقدامات مهار و بازیابی برای مدیریت رخداد.
دفاع در عمق زمانی معنا پیدا می‌کند که برای ادامه مسیر مهاجم پس از عبور از یک لایه نیز کنترل وجود داشته باشد. بنابراین، در طراحی باید پرسید: اگر این کنترل شکست بخورد، چه چیزی حمله را شناسایی یا محدود می‌کند؟
استقلال لایه‌های امنیتی؛ وابستگی مشترک چگونه خطر ایجاد می‌کند؟
کنترل‌های مکمل باید تا حد امکان از شکست هم‌زمان ناشی از یک وابستگی مشترک محافظت شوند. اگر مدیریت سرورها، تجهیزات امنیتی و سامانه پشتیبان‌گیری همگی با یک حساب دارای امتیاز بالا انجام شود، سرقت همان حساب می‌تواند چندین لایه دفاعی را تضعیف کند. نمونه دیگر، نگهداری نسخه‌های پشتیبان در محیطی است که سیستم آلوده یا حساب مدیریتی آن امکان حذف و تغییر اطلاعات پشتیبان را دارد. در این شرایط، حمله‌ای که داده‌های اصلی را هدف می‌گیرد ممکن است قابلیت بازیابی را نیز از بین ببرد.
برای مشاوره رایگان و یا راه اندازی Splunk/SIEM و مرکز عملیات امنیت SOC با کارشناسان شرکت APK تماس بگیرید |
برای کاهش این وابستگی‌ها، باید دسترسی مدیریتی به تجهیزات امنیتی، زیرساخت مجازی‌سازی و سامانه پشتیبان‌گیری بررسی شود. تفکیک حساب‌های روزمره و مدیریتی، محدودسازی مسیرهای مدیریت و محافظت مستقل از نسخه‌های پشتیبان، از اقداماتی هستند که می‌توانند دامنه اثر نفوذ را کاهش دهند. استقلال لایه‌ها به معنی قطع ارتباط میان ابزارها نیست. ابزارها برای تبادل اطلاعات و پاسخ هماهنگ به ارتباط نیاز دارند؛ موضوع اصلی این است که نفوذ به یک بخش، اختیار کنترل تمام بخش‌های دیگر را در اختیار مهاجم قرار ندهد.
محدودسازی واقعی ارتباطات با تقسیم‌بندی شبکه
ایجاد VLANهای جداگانه، بدون اعمال سیاست‌های کنترل ارتباط، به‌تنهایی مانع حرکت مهاجم در شبکه نمی‌شود. اگر ارتباط میان بخش‌ها همچنان گسترده و بدون محدودیت باشد، جداسازی منطقی تأثیر حفاظتی محدودی خواهد داشت. در طراحی تقسیم‌بندی شبکه یا Network Segmentation باید ارتباطات موردنیاز هر سرویس مشخص شود. برای نمونه، سرور برنامه ممکن است به یک پورت مشخص روی پایگاه داده نیاز داشته باشد، اما نیازی به دسترسی به تمام سرورهای سازمان یا رابط مدیریتی سامانه پشتیبان‌گیری ندارد. سیاست‌های ارتباطی باید براساس همین نیازها تنظیم شوند. دسترسی‌های مدیریتی نیز بهتر است از مسیرهای مشخص و کنترل‌شده انجام شوند و فعالیت آن‌ها قابل ثبت و بررسی باشد.
این طراحی باید با مشارکت تیم‌های شبکه، زیرساخت و نرم‌افزار انجام شود؛ زیرا محدودسازی ارتباطات بدون شناخت وابستگی سرویس‌ها می‌تواند اختلال عملیاتی ایجاد کند. اجرای مرحله‌ای تغییرات و بررسی عملکرد سامانه‌ها، بخش ضروری این فرآیند است.
بیشتر بخوانید: پیاده‌سازی SIEM چگونه انجام می‌شود؟ بررسی مراحل اجرا و دلایل شکست پروژه‌های SIEM
مدیریت هویت؛ دفاع در برابر سوءاستفاده از دسترسی معتبر
بخشی از حملات با استفاده از حساب‌های معتبر انجام می‌شوند. در چنین شرایطی، صرفاً مجاز بودن ورود یا ارتباط شبکه نمی‌تواند نشانه کافی برای عادی بودن فعالیت باشد. مدیریت هویت در معماری دفاع در عمق باید علاوه بر احراز هویت، دامنه و مدت دسترسی را نیز کنترل کند. احراز هویت چندعاملی احتمال موفقیت برخی حملات مبتنی بر سرقت گذرواژه را کاهش می‌دهد، اما جایگزین محدودسازی مجوزها و پایش فعالیت حساب‌ها نمی‌شود.
حساب‌های مدیریتی، حساب‌های سرویس و دسترسی پیمانکاران باید متناسب با وظایفشان تنظیم شوند. برای مثال، حسابی که یک برنامه برای اتصال به پایگاه داده استفاده می‌کند نباید صرفاً برای سهولت راه‌اندازی، مجوز مدیریتی گسترده دریافت کند. بازبینی دسترسی‌ها نیز باید به تغییر نقش افراد، پایان همکاری و تغییر نیاز سرویس‌ها متصل باشد. دسترسی‌ای که زمانی ضروری بوده است، ممکن است پس از مدتی به یک مسیر غیرضروری برای سوءاستفاده تبدیل شود.
اتصال ابزارها به SIEM؛ از دریافت لاگ تا تشخیص قابل استفاده
ارسال لاگ به SIEM تنها آغاز کار است. اثربخشی این لایه به کیفیت رویدادها، پوشش منابع، هماهنگی زمان و قواعد تشخیص وابسته است. برای هر سناریوی تشخیص باید مشخص شود چه داده‌هایی لازم هستند. مثلاً بررسی سوءاستفاده از حساب مدیریتی ممکن است به رویدادهای احراز هویت، تغییر عضویت گروه‌ها، فعالیت روی سرورها و اطلاعات EDR نیاز داشته باشد. نبود یکی از این منابع می‌تواند بخشی از زنجیره فعالیت مهاجم را پنهان کند.
همچنین باید سلامت جریان داده پایش شود. قطع ارسال لاگ از یک سرور حساس، غیرفعال شدن ثبت رویداد یا تغییر نامناسب تنظیمات جمع‌آوری، ممکن است بدون خرابی ظاهری SIEM، دید امنیتی سازمان را کاهش دهد. معیار موفقیت، صرفاً تعداد منابع متصل یا حجم لاگ دریافتی نیست؛ باید مشخص شود کدام سناریوهای تهدید با این داده‌ها قابل تشخیص هستند و هشدار حاصل چگونه بررسی می‌شود.
پاسخ به رخداد باید پیش از وقوع حمله طراحی شود
هشداری که اقدام بعدی آن مشخص نیست، ممکن است زمان ارزشمند تیم امنیت را از بین ببرد. برای سناریوهای مهم، باید دستورالعمل پاسخ یا Playbook وجود داشته باشد. برای نمونه، در صورت مشاهده رفتار مشکوک روی یک سرور، لازم است مشخص شود چه کسی اعتبار هشدار را بررسی می‌کند، چه شواهدی باید حفظ شوند و ایزوله کردن سرور چه اثری بر سرویس خواهد داشت. مسئول تصمیم‌گیری و مسیر هماهنگی با تیم عملیاتی نیز باید روشن باشد.
ابزارهای SOAR می‌توانند بخشی از فعالیت‌ها مانند جمع‌آوری اطلاعات، ایجاد پرونده رخداد و اجرای اقدامات تعریف‌شده را خودکار کنند. بااین‌حال، اقداماتی مانند مسدودسازی حساب یا قطع ارتباط یک سامانه حساس باید متناسب با اطمینان تشخیص و پیامد عملیاتی طراحی شوند.خودکارسازی زمانی مفید است که فرآیند پاسخ روشن، آزموده‌شده و قابل پیگیری باشد.
یک سناریوی عملی: عبور ایمیل مخرب از لایه اول
فرض کنید یک ایمیل فیشینگ از کنترل امنیت ایمیل عبور می‌کند و کاربر فایل پیوست را اجرا می‌کند. در یک معماری دفاع در عمق، شکست لایه ایمیل پایان دفاع نیست. محدود بودن مجوزهای کاربر می‌تواند برخی تغییرات را دشوار کند. کنترل اجرای برنامه‌ها یا EDR ممکن است فعالیت مشکوک را متوقف یا شناسایی کند. سیاست‌های شبکه می‌توانند دسترسی سیستم آلوده به سرورها را محدود کنند و SIEM نیز با ترکیب اطلاعات Endpoint و احراز هویت، شواهد بیشتری برای بررسی فراهم کند.
اگر آلودگی تأیید شود، فرآیند پاسخ باید امکان مهار سیستم، بررسی حساب‌های درگیر و تعیین دامنه رخداد را فراهم سازد. در صورت آسیب به داده‌ها نیز بازیابی باید از نسخه‌های سالم و محافظت‌شده انجام شود. در این مثال، هر لایه وظیفه متفاوتی دارد. ارزش معماری از ترکیب پیشگیری، تشخیص، محدودسازی و بازیابی حاصل می‌شود.
اثربخشی دفاع در عمق را چگونه بسنجیم؟
ارزیابی باید نشان دهد کنترل‌ها در شرایط واقعی چه رفتاری دارند. آزمون نفوذ، تمرین پاسخ به رخداد و شبیه‌سازی مجاز سناریوهای حمله می‌توانند برای بررسی بخش‌های مختلف این معماری استفاده شوند. شاخص‌های مناسب نیز باید به پرسش‌های عملی پاسخ دهند:
| حوزه ارزیابی | پرسش کلیدی |
| پوشش حفاظت | چه تعداد از دارایی‌های حساس تحت کنترل‌های موردنیاز قرار دارند؟ |
| کیفیت تشخیص | کدام سناریوهای آزمایش‌شده هشدار قابل بررسی تولید می‌کنند؟ |
| سرعت مهار | فاصله شناسایی رخداد تا محدود شدن فعالیت مخرب چقدر است؟ |
| کنترل دسترسی | آیا حساب‌ها و سرویس‌ها فقط مجوزهای موردنیاز را دارند؟ |
| قابلیت بازیابی | آیا سرویس و داده‌ها در زمان هدف و با میزان ازدست‌رفتگی قابل قبول بازیابی می‌شوند؟ |
نتایج این بررسی‌ها باید به اصلاح معماری منجر شوند. اگر یک سناریو شناسایی نمی‌شود، باید علت آن در داده‌ها، قواعد تشخیص یا پوشش ابزارها بررسی شود. اگر بازیابی طولانی است، وابستگی سرویس‌ها و فرآیند بازگردانی باید بازنگری شوند. دفاع در عمق یک طراحی ثابت نیست. با تغییر سامانه‌ها، کاربران و مسیرهای دسترسی، کنترل‌ها نیز باید بازبینی شوند. سازمان زمانی از این رویکرد بهره می‌برد که بداند پس از شکست هر لایه، چه ظرفیت دیگری برای شناسایی حمله، محدود کردن خسارت و بازگرداندن خدمات در اختیار دارد.
