ارزیابی امنیت شبکه اگر فقط با چند اسکن و چند توصیه عمومی انجام شود، خروجی قابل اجرا نمیدهد. شبکه واقعی پر از استثناست: سرویس قدیمی، مسیر VPN، شعبهای که پهنای باند محدود دارد، Ruleی که کسی جرأت حذف آن را ندارد، یا سیستمی که اگر پنج دقیقه قطع شود، کسبوکار را درگیر میکند. برای همین قبل از پیشنهاد تغییر، باید شواهد کافی جمع شود.
شواهد یعنی دادهای که بتوان بر اساس آن تصمیم گرفت. اگر میگوییم یک Rule باید محدود شود، باید بدانیم چه ترافیکی از آن عبور میکند، مالک سرویس کیست، آخرین hit چه زمانی بوده، آیا لاگ داریم، و اگر Rule را تغییر دهیم چه تستی باید انجام شود. بدون این اطلاعات، گزارش امنیتی تبدیل به سندی میشود که شاید درست باشد، اما کسی در شبکه production حاضر نیست اجرا کند.
اول معماری را بفهمید، بعد ضعفها را لیست کنید
اولین شواهد مربوط به معماری است: توپولوژی، مسیر اینترنت، DMZ، ارتباط شعب، VPN، شبکه مدیریت، VLANهای حساس، سرویسهای عمومی، سیستمهای مانیتورینگ و مسیر backup. اگر این تصویر روشن نباشد، شدت ریسک درست سنجیده نمیشود. یک port باز روی سرور آزمایشگاهی با همان port روی سامانه مالی یکی نیست؛ هر دو ممکن است از نظر scanner شبیه باشند، اما اثر عملی متفاوتی دارند.
در همین مرحله باید مشخص شود کدام تجهیزات نقش کنترل اصلی دارند: FortiGate یا Firepower در مرز، FortiWeb یا F5 ASM برای وب، F5 BIG-IP برای load balancing، Juniper SRX برای segment یا شعبه، و سوئیچهای core برای کنترل مسیر. ارزیابی امنیتی خوب این نقشها را جدا میکند و برای هر کدام شواهد متناسب میخواهد.
Rule Base بدون لاگ نصف واقعیت است
خیلی از گزارشها Rule Base را export میکنند و بعد بر اساس نام و objectها تصمیم میگیرند. این شروع خوبی است، اما کافی نیست. باید hit count، آخرین استفاده، لاگ forward traffic، NAT، object groupها و مسیر برگشت هم دیده شود. اگر Rule ظاهراً باز است اما سالها هیچ hitی ندارد، یک نوع تصمیم لازم است. اگر همان Rule روزانه ترافیک حیاتی دارد، تصمیم باید مرحلهای و با تست باشد.
- Ruleهای بدون مالک یا توضیح باید جدا شوند.
- Objectهای تکراری یا بیش از حد بزرگ باید بررسی شوند.
- NATهای قدیمی و مبهم باید به سرویس واقعی وصل شوند.
- لاگ باید نشان دهد چه چیزی واقعاً استفاده میشود.
- برای حذف یا محدودسازی، بازه مشاهده لازم است.
دسترسی مدیریتی و تغییرات را کنار سرویس ببینید
امنیت شبکه فقط مسیر عبور کاربران نیست. مسیر مدیریت هم باید شواهد داشته باشد: چه کسانی به فایروال، سوئیچ، WAF و load balancer دسترسی دارند؟ ورودها کجا log میشود؟ آیا حساب مشترک وجود دارد؟ آیا backup قبل از تغییر گرفته میشود؟ آیا تغییرها comment یا ticket دارند؟ اگر مسیر مدیریت ضعیف باشد، حتی Rule Base مرتب هم تصویر کامل امنیت نمیدهد.
در ارزیابی درست، خروجی نباید فقط «اینها مشکل دارند» باشد. باید اولویت بدهد: کدام مورد سریع و کمریسک اصلاح میشود، کدام مورد نیاز به change window دارد، کدام مورد وابسته به تصمیم مدیریتی است، و کدام مورد باید اول پایش شود. این تفکیک باعث میشود گزارش از حالت توصیه عمومی خارج شود و به برنامه اجرا نزدیک شود.
خروجی قابل دفاع چه شکلی است؟
خروجی خوب برای هر مورد چهار بخش دارد: شواهد، ریسک، پیشنهاد تغییر، و روش تست/rollback. اگر میخواهیم دسترسی مدیریتی FortiGate را محدود کنیم، باید مسیر فعلی، ریسک فعلی، تغییر پیشنهادی، تست دسترسی بعد از تغییر و روش برگشت مشخص باشد. اگر میخواهیم یک Rule در Firepower یا Juniper محدود شود، باید hit، سرویس، مالک و سناریوی تست داشته باشیم.
این مطلب با مشاوره امنیت شبکه و روش میدانی ارزیابی امنیت شبکه هممسیر است. ارزیابی خوب قرار نیست تیم فنی را با یک لیست ترسناک تنها بگذارد؛ باید مسیر اصلاح را طوری نشان دهد که قابل اجرا، قابل پیگیری و قابل دفاع باشد.
مصاحبه فنی هم بخشی از شواهد است
همه شواهد از ابزار به دست نمیآید. گاهی باید با تیم شبکه، تیم سیستم، تیم امنیت و مالک سرویس صحبت کرد تا بفهمیم چرا یک Rule قدیمی هنوز مانده، کدام سرویس در ظاهر کماهمیت است اما در زمان خاصی حیاتی میشود، یا کدام تغییر قبلاً باعث قطعی شده است. این اطلاعات اگر کنار export فایروال و لاگ قرار نگیرد، تحلیل خشک و ناقص میشود.
در یک ارزیابی خوب، حدسها از شواهد جدا نوشته میشوند. مثلاً اگر فکر میکنیم یک NAT قدیمی دیگر استفاده نمیشود، باید بنویسیم بر اساس چه بازه لاگ، چه hit count و چه تأییدی از مالک سرویس به این نتیجه رسیدهایم. همین تفکیک کمک میکند تصمیمهای پرریسک مرحلهای اجرا شوند و تیم فنی احساس نکند گزارش امنیتی واقعیت محیط را ندیده است.
برای اینکه این موضوع در اجرا هم نتیجه بدهد، بهتر است بعد از هر تغییر یک شاخص ساده برای موفقیت داشته باشیم: آیا سرویس سالم مانده، آیا لاگ کافی داریم، آیا مسیر rollback روشن است، و آیا تیم فنی میتواند سه ماه بعد دلیل این تصمیم را بفهمد؟ اگر جواب این سؤالها مثبت نباشد، حتی تغییر درست هم در نگهداری روزمره دردسر میسازد.
همین نگاه ساده جلوی کارهای نمایشی را میگیرد. معیار موفقیت باید در شبکه واقعی قابل مشاهده باشد، نه فقط در متن گزارش.
در کار اجرایی، یک نکته دیگر هم مهم است: هر پیشنهاد باید صاحب، زمان بازبینی و سطح ریسک داشته باشد. اگر پیشنهادی این سه مورد را ندارد، احتمالاً هنوز برای اجرا آماده نیست. این کار متن را از توصیه عمومی جدا میکند و به برنامهای تبدیل میکند که تیم فنی میتواند آن را مرحلهبهمرحله دنبال کند.
