کنترل‌های حساس امنیت شبکه؛ نقشه راه عملی برای کاهش ریسک

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

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

از دارایی شروع کنید، نه از ابزار

خیلی وقت‌ها امنیت با خرید ابزار شروع می‌شود؛ EDR، SIEM، اسکنر آسیب‌پذیری، WAF یا فایروال جدید. اما اگر ندانیم دارایی‌ها کدام‌اند، هیچ ابزاری تصویر کامل نمی‌دهد. کنترل‌های اولیه SANS/CIS دقیقا روی همین موضوع تاکید دارند: اول دارایی‌های سخت‌افزاری و نرم‌افزاری را بشناسید، بعد درباره محافظت از آن‌ها تصمیم بگیرید.

وقتی Inventory درست باشد، می‌توان فهمید کدام سیستم patch نشده، کدام دستگاه owner ندارد، کدام نرم‌افزار غیرمجاز است و کدام سرویس نباید در شبکه باشد. بدون این دید، گزارش‌های امنیتی بیشتر شبیه حدس هستند.

پیکربندی امن یعنی کاهش خطای تکراری

بخش بزرگی از ریسک‌ها از آسیب‌پذیری‌های عجیب شروع نمی‌شوند؛ از تنظیمات بد شروع می‌شوند. رمز پیش‌فرض، سرویس اضافه، دسترسی مدیریتی باز، لاگ خاموش، پروتکل قدیمی یا اکانت مشترک. کنترل‌های هاردنینگ و پیکربندی امن برای همین طراحی شده‌اند که این خطاهای تکراری کم شوند.

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

آسیب‌پذیری را فقط اسکن نکنید؛ اصلاح کنید

اسکن آسیب‌پذیری اگر به اصلاح وصل نباشد، فقط تولید گزارش است. کنترل‌های امنیتی زمانی اثر دارند که خروجی اسکن owner، deadline و اولویت داشته باشد. همه ضعف‌ها هم یک فوریت ندارند. آسیب‌پذیری روی VPN عمومی یا سرویس اینترنتی با یک ضعف مشابه روی سیستم آزمایشگاهی جدا از شبکه یکسان نیست.

اولویت‌بندی باید بر اساس ریسک واقعی انجام شود: شدت فنی، دسترسی‌پذیری از اینترنت، حساسیت دارایی، exploit فعال، وجود کنترل جبرانی و اثر روی کسب‌وکار. بعد از اصلاح هم باید دوباره بررسی شود که ضعف واقعا بسته شده است.

دسترسی‌ها را کمتر و قابل ردیابی کنید

یکی از مهم‌ترین بخش‌های کنترل‌های امنیتی، مدیریت دسترسی است. اکانت ادمین زیاد، دسترسی مشترک، رمزهای ذخیره‌شده در فایل، MFA خاموش و گروه‌های قدیمی Domain Admin معمولا دیر یا زود دردسر می‌سازند. دسترسی باید حداقلی، شخصی، زمان‌دار و قابل لاگ‌گیری باشد.

در شبکه‌های واقعی، حذف همه ریسک‌ها یک‌شبه ممکن نیست. اما می‌توان از مسیرهای حساس شروع کرد: VPN، پنل‌های مدیریتی، فایروال، Active Directory، سیستم مجازی‌سازی، بکاپ، ایمیل، هاست و ابزارهای مانیتورینگ. این‌ها اگر درست کنترل شوند، مسیر حمله خیلی کوتاه نمی‌ماند.

دفاع از مرز شبکه هنوز مهم است

با وجود cloud، remote work و SaaS، مرز شبکه تغییر کرده اما حذف نشده است. فایروال، VPN، DNS، ایمیل، WAF، segmentها، روترها و سرویس‌های اینترنتی هنوز باید درست طراحی و کنترل شوند. کنترل Boundary Defense یعنی بدانیم چه چیزی از بیرون قابل دسترسی است، چرا باز است، چه کسی owner آن است و چطور مانیتور می‌شود.

خیلی از حادثه‌ها از یک سرویس اینترنتی فراموش‌شده، یک پنل مدیریت قدیمی، یک rule بیش از حد باز یا یک VPN بدون MFA شروع می‌شوند. دفاع از مرز یعنی این مسیرها بی‌صاحب نمانند.

لاگ بدون استفاده، امنیت نمی‌سازد

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

برای شروع لازم نیست همه چیز پیچیده باشد. لاگ ورودهای مدیریتی، تغییرات firewall، خطاهای VPN، رویدادهای EDR، DNSهای مشکوک، ایمیل‌های فیشینگ و تغییرات اکانت‌های حساس ارزش زیادی دارند. بعد می‌توان این مسیر را با SIEM و use caseهای دقیق‌تر کامل کرد.

آموزش و فرآیند را کنار ابزار ببینید

کنترل‌های امنیتی فقط فنی نیستند. آگاهی امنیتی، فرآیند incident response، تست نفوذ، red team، مدیریت تغییرات و آموزش تیم فنی هم بخشی از کارند. اگر کاربر فیشینگ را تشخیص ندهد، اگر تیم نداند در حادثه چه کند، یا اگر تغییرات بدون ثبت انجام شود، بهترین ابزارها هم تنها می‌مانند.

آموزش خوب باید عملی باشد. برای تیم شبکه، مثال واقعی از firewall rule، VPN، SSH، backup و لاگ ارزشمندتر از متن‌های عمومی است. برای کاربران هم تمرین‌های کوتاه و مرتبط با ایمیل، رمز، فایل پیوست و MFA اثر بیشتری دارد.

چطور اجرای کنترل‌ها را شروع کنیم؟

لازم نیست همه کنترل‌ها را همزمان و کامل اجرا کنیم. بهتر است مرحله‌ای جلو برویم. اول دارایی‌ها و نرم‌افزارها را قابل مشاهده کنیم. بعد baseline امن و patch/vulnerability management را مرتب کنیم. سپس دسترسی‌های مدیریتی، لاگ‌گیری، دفاع مرزی و آموزش را قوی‌تر کنیم. در ادامه می‌توان به کنترل‌های پیشرفته‌تر مثل data protection، need-to-know، incident response و تست نفوذ منظم پرداخت.

• اولویت اول: Inventory دارایی و نرم‌افزار.
• اولویت دوم: پیکربندی امن، patch و آسیب‌پذیری.
• اولویت سوم: دسترسی مدیریتی، لاگ و مانیتورینگ.
• اولویت چهارم: دفاع مرزی، محافظت داده و پاسخ به حادثه.
• اولویت پنجم: آموزش، تست نفوذ و بهبود مستمر.

اشتباه رایج: تبدیل کنترل‌ها به چک‌باکس

اگر کنترل‌ها فقط برای پر کردن چک‌لیست اجرا شوند، اثر واقعی ندارند. مثلا داشتن SIEM بدون use case، داشتن اسکنر بدون اصلاح، داشتن لیست دارایی بدون owner یا داشتن policy بدون اجرا، امنیت واقعی ایجاد نمی‌کند. هر کنترل باید خروجی عملی داشته باشد و بتوانیم بگوییم بعد از اجرای آن چه ریسکی کمتر شده است.

بهتر است برای هر کنترل چند شاخص ساده داشته باشیم: چند درصد دارایی‌ها owner دارند، چند سیستم EDR ندارند، چند آسیب‌پذیری critical باز است، چند اکانت ادمین بدون MFA داریم، چند سرویس اینترنتی بدون owner است و میانگین زمان اصلاح چقدر است.

برای تصمیم بهتر درباره کنترل‌های حساس امنیت شبکه

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

برای تبدیل این کنترل‌ها به برنامه اجرایی متناسب با توپولوژی، فایروال‌ها و سرویس‌های موجود، مشاوره امنیت شبکه می‌تواند از ارزیابی وضعیت فعلی تا اولویت‌بندی تغییرات و طراحی rollback را پوشش دهد.

نقشه مرتب کنترل‌های امنیتی

برای اینکه سری کنترل‌های امنیتی به چند مطلب جدا و پراکنده تبدیل نشود، این مسیر به‌عنوان hub اصلی نگه داشته می‌شود. کنترل‌های ۱۳ تا ۲۰ و چند مطلب پایه مرتبط از اینجا قابل دنبال کردن هستند.

• کنترل ۱۳: حفاظت از داده‌ها
• کنترل ۱۴: دسترسی بر اساس نیاز کاری
• کنترل ۱۵: کنترل دسترسی بی‌سیم
• کنترل ۱۶: پایش و کنترل حساب‌های کاربری
• کنترل ۱۷: آموزش امنیتی
• کنترل ۱۸: امنیت نرم‌افزارهای کاربردی
• کنترل ۱۹: مدیریت پاسخ به رخداد
• کنترل ۲۰: تست نفوذ و Red Team
• پیکربندی امن تجهیزات شبکه
• هاردنینگ و امن‌سازی سیستم‌ها