روش میدانی ارزیابی امنیت شبکه؛ از دارایی تا ریسک قابل اجرا
ارزیابی امنیت شبکه اگر فقط از روی چکلیست انجام شود، معمولاً به گزارش پرحجم و کماثر میرسد. شبکه سازمانی زنده است: سرویس دارد، تغییر اضطراری دارد، rule قدیمی دارد، تیم نگهداری دارد و محدودیت کسبوکار دارد. روش میدانی یعنی قبل از نسخه دادن، مسیر واقعی ترافیک، داراییهای مهم، دسترسی مدیریتی، لاگ و نقاط تصمیم را ببینیم و بعد ریسکها را اولویتبندی کنیم.
چارچوبهایی مثل NIST CSF و CIS Controls برای نظم دادن به فکر مفیدند، اما جای مشاهده واقعی را نمیگیرند. در یک ارزیابی خوب، چارچوب مرجع است، نه متن نهایی گزارش. خروجی باید به مدیر فنی بگوید از کجا شروع کند، چه چیزی را همین هفته اصلاح کند، چه چیزی downtime میخواهد و چه چیزی باید در فاز بعدی طراحی شود.
مرحله اول: inventory قابل اعتماد
اول باید بدانیم چه چیزی داریم. inventory فقط لیست IP نیست. باید مشخص شود کدام تجهیزات در مرز اینترنت هستند، کدامها مسیر دیتاسنتر را کنترل میکنند، کدام فایروالها یا WAFها policy فعال دارند، کدام سرویسها public هستند، و کدام سیستمها اگر قطع شوند کسبوکار را متوقف میکنند. اگر همین مرحله دقیق نباشد، بقیه ارزیابی روی حدس ساخته میشود.
- تجهیزات edge، core، access، firewall، WAF، load balancer و VPN gateway جدا ثبت شوند.
- نسخه سیستمعامل، وضعیت پشتیبانی و مسیر backup config بررسی شود.
- سرویسهای حساس مثل AD، ایمیل، ERP، پنل مشتری و سامانه مالی علامتگذاری شوند.
- ارتباط شعب، دیتاسنتر، cloud و لینکهای پشتیبان روی نقشه ساده مشخص شوند.
مرحله دوم: مسیر ترافیک و مرزهای اعتماد
بعد از داراییها، باید مسیر ترافیک را فهمید. خیلی وقتها سازمان فکر میکند یک فایروال مرز اصلی است، اما مسیرهای دیگری از VPN قدیمی، لینک شعبه، port forwarding یا سیستم مانیتورینگ وجود دارد. ارزیابی واقعی باید نشان دهد ترافیک کاربران، سرورها، ادمینها و سرویسهای اینترنتی از کجا عبور میکنند و کجا لاگ نداریم.
در این مرحله، هدف پیدا کردن «نقطه ضعف عجیب» نیست؛ هدف پیدا کردن فرضهای غلط است. فرضهایی مثل اینکه همه مدیریت از شبکه داخلی انجام میشود، همه سرویسهای public پشت WAF هستند، یا هیچ rule قدیمی باز نمانده. این فرضها در حادثه واقعی هزینهساز میشوند.
مرحله سوم: دسترسی مدیریتی و تغییرات
دسترسی مدیریتی باید جدا از ترافیک عادی دیده شود. اگر پنل فایروال، سوئیچ، hypervisor یا کنترلر وایرلس با حساب مشترک و بدون لاگ استفاده میشود، حتی policy خوب هم به مرور خراب میشود. باید مشخص شود چه کسی تغییر میدهد، تغییر کجا ثبت میشود، چه کسی تأیید میکند و اگر خطا شد چطور rollback انجام میشود.
مرحله چهارم: تبدیل یافته به برنامه
گزارش ارزیابی نباید فقط severity داشته باشد. باید مسیر اجرا داشته باشد. برای هر یافته، بهتر است پنج چیز مشخص شود: اثر واقعی، احتمال رخداد، پیشنیاز اصلاح، ریسک تغییر و مالک اصلاح. این کار باعث میشود پیشنهادها از حالت کلی خارج شوند و به برنامهای تبدیل شوند که تیم شبکه بتواند با آن کار کند.
اتصال به مسیر خدمات
اگر هدف شما شروع چنین ارزیابی است، صفحه مشاور امنیت شبکه مسیر اصلی این خوشه است. برای تبدیل خروجی ارزیابی به طراحی و اصلاح مرحلهای، صفحه طراحی امنیت شبکه و هاردنینگ ادامه طبیعی همین مسیر است.
نمونه خروجی قابل استفاده برای ارزیابی
خروجی خوب بهتر است به سه بخش تقسیم شود: یافتههای فوری، اصلاحات مرحلهای و تصمیمهای معماری. یافته فوری چیزی است که با ریسک کم و اثر زیاد قابل اصلاح است؛ مثل بستن مدیریت از اینترنت یا حذف حساب قدیمی. اصلاح مرحلهای چیزی است که تست و زمانبندی میخواهد؛ مثل محدود کردن ruleهای قدیمی. تصمیم معماری هم چیزی است که بدون توافق مدیریتی جلو نمیرود؛ مثل تغییر segmentation یا جابهجایی WAF در مسیر ترافیک.
این تفکیک باعث میشود گزارش ارزیابی به لیست بلند و ترسناک تبدیل نشود. تیم فنی میتواند همان هفته چند مورد را ببندد، برای موارد حساس window بگیرد و برای تغییرهای معماری تصمیم بودجه و زمانبندی داشته باشد.

راهنمای خواندن دیتاشیت فایروال؛ چرا اعداد کارایی همیشه واقعی نیستند؟
جلوگیری از تغییرات همزمان در تجهیزات Cisco با Configuration Lock
Tuning WAF برای API؛ از Baseline تا Exception قابل دفاع
امنسازی پیکربندی سختافزار و نرمافزار؛ Baseline قابل دفاع برای شبکه
کنترل امنیت شماره ۲۰: تست نفوذ و Red Team؛ آزمون واقعی کنترلها
WAF چه زمانی لازم است و چه فرقی با فایروال شبکه دارد؟