هاردنینگ شبکه یعنی کم کردن سطح حمله بدون اینکه عملیات روزمره سازمان را بیدلیل سخت کنیم. اشتباه رایج این است که کار را از یک چکلیست بلند شروع کنیم و همه چیز را همزمان تغییر دهیم. در شبکه واقعی، این روش خطر قطعی سرویس و مقاومت تیمها را بالا میبرد. هاردنینگ خوب باید مرحلهای، قابل اندازهگیری و قابل برگشت باشد.
مرحله اول: Inventory واقعی
قبل از هر تغییر باید بدانیم چه داریم. فهرست تجهیزات، نسخه نرمافزار، IPهای مدیریتی، سرویسهای فعال، مسیرهای اینترنت، VPNها، VLANها و سیستمهای حساس باید روشن باشد. CIS Controls هم inventory سختافزار و نرمافزار را از اولین کنترلها میداند، چون بدون شناخت دارایی، هیچ hardening پایداری شکل نمیگیرد.
- تجهیزات edge، core، access، firewall، WAF و load balancer جدا فهرست شوند.
- نسخه سیستمعامل و firmware برای ریسک patch بررسی شود.
- دسترسی مدیریتی و حسابهای فعال مستند شود.
- سرویسهایی که واقعاً استفاده نمیشوند علامتگذاری شوند.
مرحله دوم: دسترسی مدیریتی و احراز هویت
در بسیاری از شبکهها، سریعترین کاهش ریسک از دسترسی مدیریتی شروع میشود. بستن مدیریت از اینترنت، محدود کردن source IP، فعال کردن احراز هویت قویتر، حذف حسابهای مشترک، ثبت لاگ ورود، و backup منظم config معمولاً اثر زیادی دارد و نسبت به تغییرات معماری کمریسکتر است.
این مرحله باید با احتیاط انجام شود. اگر تنها راه دسترسی به تجهیز را اشتباه ببندیم، عملیات مختل میشود. بنابراین قبل از تغییر باید console، دسترسی جایگزین، backup config و rollback plan آماده باشد.
مرحله سوم: segmentation و مسیرهای حساس
بعد از دسترسی مدیریتی، باید مرز بین کاربران، سرورها، تجهیزات مدیریت، سرویسهای عمومی و محیطهای حساس واضحتر شود. segmentation فقط ساخت VLAN نیست. باید policyهای عبور، log، exceptionها و مالکیت هر مسیر هم مشخص باشد. اگر همه شبکه به همه چیز دسترسی داشته باشد، یک آلودگی ساده میتواند به حادثه بزرگ تبدیل شود.
مرحله چهارم: لاگ، backup و بازبینی دورهای
هاردنینگ بدون log و بازبینی، به مرور فرسوده میشود. تغییرهای اضطراری، ruleهای موقت و حسابهای جدید اگر ثبت و بازبینی نشوند، دوباره همان سطح حمله قبلی برمیگردد. بهتر است برای هر ماه چند شاخص ساده داشته باشیم: تعداد ruleهای بدون مالک، تعداد حسابهای admin، سرویسهای مدیریتی باز، تجهیزات با نسخه قدیمی و خطاهای تکراری در لاگ.
مسیر خدمات در عربیان
برای شروع برنامه هاردنینگ در سطح سازمان، صفحه طراحی امنیت شبکه و هاردنینگ زیرساخت سازمانی مسیر اصلی است. برای دیدن مبانی امنیتی گستردهتر، مطلب کنترلهای حساس امنیت شبکه هم کمک میکند اولویتها از حالت سلیقهای خارج شوند.
هاردنینگ را با قطع کردن سرویس اشتباه نگیریم
هاردنینگ موفق یعنی کاهش ریسک با کمترین اختلال. اگر بدون شناخت وابستگیها سرویسها را ببندیم، ممکن است امنیت ظاهراً بهتر شود اما عملیات سازمان آسیب ببیند. برای همین هر تغییر باید قبل از اجرا سه پاسخ داشته باشد: چرا لازم است، چه چیزی ممکن است قطع شود، و اگر مشکل پیش آمد چطور برمیگردیم.
در شبکههای فعال، بهتر است اول سراغ تغییرهای کمریسک و پراثر برویم: محدود کردن مدیریت از اینترنت، حذف حسابهای قدیمی، فعال کردن log تغییرات، گرفتن backup منظم، اصلاح banner و سرویسهای غیرضروری، و کنترل دسترسی از شبکه مدیریت. بعد از آن میتوان سراغ segmentation جدیتر و تغییرهای معماری رفت.
شاخصهای ساده برای سنجش پیشرفت
- تعداد تجهیزات با دسترسی مدیریتی محدودشده.
- تعداد حسابهای admin حذف یا اصلاحشده.
- درصد تجهیزاتی که backup config معتبر دارند.
- تعداد سرویسهای غیرضروری بستهشده.
- تعداد ruleهای پرریسک که owner و توضیح پیدا کردهاند.
چطور از پراکندگی جلوگیری کنیم؟
بهتر است هر تغییر هاردنینگ به یک هدف روشن وصل باشد: دسترسی مدیریتی، مرزبندی شبکه، لاگ و مانیتورینگ، بهروزرسانی، یا backup. وقتی تغییرها بدون این دستهبندی انجام شوند، بعد از مدتی کسی نمیداند کدام تصمیم برای چه ریسکی گرفته شده است. این نظم کمک میکند برنامه هاردنینگ به یک پروژه مقطعی تبدیل نشود و در نگهداری ماهانه هم ادامه پیدا کند.
اولویتبندی هاردنینگ را با ریسک واقعی بسنجید
در هاردنینگ شبکه، همه تنظیمات ارزش یکسان ندارند. بستن یک سرویس مدیریتی باز روی اینترنت، محدود کردن دسترسی ادمین به jump host، فعال کردن لاگ روی مسیرهای حساس و جدا کردن شبکه کاربران از سرورها معمولاً اثر بیشتری از تغییرهای تزئینی دارد. اگر تیم شبکه با منابع محدود کار میکند، بهتر است اول سراغ کنترلهایی برود که سطح حمله را کم میکنند و در عین حال احتمال قطعی سرویس پایینتری دارند.
یک روش عملی این است که هر اقدام را با سه سؤال بسنجید: آیا این ضعف از بیرون یا از شبکه کاربری قابل سوءاستفاده است؟ آیا exploit آن میتواند به دسترسی مدیریتی، تغییر policy یا قطع سرویس برسد؟ آیا rollback آن روشن است؟ هر تغییری که جواب دو سؤال اول برایش مثبت و rollback آن ساده باشد، معمولاً در اولویت بالاتر قرار میگیرد. اگر rollback مبهم است، تغییر باید به change window و تست محدود منتقل شود، نه اینکه در ساعت کاری روی شبکه اصلی اعمال شود.
هاردنینگ فایروال و دسترسی مدیریتی را جدا نبینید
در خیلی از شبکهها فایروال از نظر Rule Base نسبتاً مرتب است، اما دسترسی مدیریتی خودش کنترل ضعیفی دارد. پنل مدیریتی از چند subnet دیده میشود، حسابهای قدیمی باقی ماندهاند، MFA یا AAA کامل نیست، و لاگ تغییرات بهدرستی بررسی نمیشود. در چنین وضعیتی حتی اگر policy ترافیک خوب نوشته شده باشد، مسیر تغییر غیرمجاز هنوز باز است. برای همین هاردنینگ باید دسترسی مدیریتی، accountها، backup، لاگ و مسیر deploy را کنار Ruleها ببیند.
اگر FortiGate، Cisco Firepower یا Juniper SRX دارید، کنترلهای پایه را از همین نقاط شروع کنید: محدود کردن management plane، ثبت owner برای Ruleها، حذف objectهای بلااستفاده، کنترل VPNهای مدیریتی، بررسی NATهای قدیمی و مطمئن شدن از ارسال لاگهای مهم به یک نقطه قابل جستوجو. این موارد مکمل پیادهسازی فایروال سازمانی و طراحی و هاردنینگ امنیت شبکه هستند؛ چون هاردنینگ بدون فهم مسیر ترافیک و مسئولیت سرویسها خیلی زود تبدیل به چکلیست بیاثر میشود.
از تغییرهای کوچک ولی قابل اندازهگیری شروع کنید
برای شروع، لازم نیست همه چیز را همزمان عوض کنید. یک batch کوچک انتخاب کنید: مثلاً سه سرویس مدیریتی باز، پنج Rule بدون owner، یک مسیر VPN قدیمی و یک دستگاه بدون backup قابل اتکا. برای هرکدام وضعیت قبل، تغییر انجامشده، ریسک باقیمانده و روش برگشت را ثبت کنید. بعد از اجرا، لاگ و اثر عملیاتی را ببینید. اگر هیچ incident یا قطعی ایجاد نشد و ریسک کم شد، batch بعدی را تعریف کنید.
این مدل باعث میشود هاردنینگ از حالت شعار خارج شود. تیم فنی میتواند نشان دهد چه چیزی بسته شده، چه چیزی هنوز باز است و کدام تصمیم نیاز به تأیید مدیریت دارد. در پروژههای واقعی، همین شفافیت از یک چکلیست بلند ارزشمندتر است؛ چون مشخص میکند کدام ریسک امروز قابل کم کردن است و کدام ریسک به طراحی، خرید ابزار یا تغییر معماری نیاز دارد.
