ارزیابی مداوم آسیب‌پذیری؛ از اسکن تا اصلاح واقعی

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

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

اول دارایی‌ها را بشناسید

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

Inventory باید حداقل شامل مالک سیستم، نقش، سیستم‌عامل، IP، موقعیت شبکه، سطح حساسیت، سرویس‌های باز و وضعیت پشتیبانی باشد. برای شبکه‌های کوچک هم یک فایل ساده و مرتب بهتر از هیچ چیز است؛ ولی در محیط‌های بزرگ‌تر بهتر است این اطلاعات از CMDB، ابزار مانیتورینگ، EDR، اسکن شبکه و سیستم مدیریت دارایی جمع شود.

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

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

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

همه آسیب‌پذیری‌ها یکسان نیستند

یک گزارش اسکن ممکن است صدها مورد نشان دهد، اما همه آنها یک فوریت ندارند. اولویت واقعی از ترکیب چند چیز به دست می‌آید: شدت فنی، قابل Exploit بودن، دسترسی‌پذیری از اینترنت، حساسیت دارایی، وجود داده مهم، امکان حرکت جانبی و اینکه آیا کنترل جبرانی مثل WAF، ACL یا Segment وجود دارد یا نه.

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

Patch Management باید عملیاتی باشد

رفع آسیب‌پذیری فقط نصب Patch نیست، ولی Patch Management بخش اصلی کار است. باید مشخص باشد چه کسی Patch را تست می‌کند، چه زمانی نصب می‌شود، چه سیستم‌هایی نیاز به reboot دارند و اگر Patch باعث اختلال شد مسیر برگشت چیست. بدون این برنامه، تیم‌ها معمولا اصلاح را عقب می‌اندازند تا زمانی که حادثه یا فشار بیرونی مجبورشان کند.

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

وقتی Patch ممکن نیست

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

این کنترل‌ها جای Patch دائمی نیستند، اما تا زمان اصلاح اصلی ریسک را قابل مدیریت‌تر می‌کنند. مهم این است که این وضعیت موقت به حالت دائمی و فراموش‌شده تبدیل نشود.

گزارش قابل اقدام

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

• موارد Critical اینترنتی را جدا و فوری گزارش کنید.
• موارد تکراری را گروه‌بندی کنید تا تیم در حجم گزارش گم نشود.
• برای هر مورد owner مشخص داشته باشید.
• بعد از اصلاح، دوباره اسکن کنید تا بسته شدن ضعف تایید شود.

ابزارهای رایج

برای ارزیابی آسیب‌پذیری می‌توان از ابزارهایی مثل Nessus، Qualys، Rapid7 InsightVM، OpenVAS/Greenbone، Tenable.io، Nmap NSE، Microsoft Defender Vulnerability Management و ابزارهای مشابه استفاده کرد. ابزار مهم است، اما کیفیت خروجی به Scope، Credential، برنامه اسکن، Inventory و پیگیری اصلاح وابسته است.

در محیط‌های ابری هم باید تنظیمات سرویس‌ها، دسترسی IAM، Storage عمومی، Security Groupها، Snapshotها و Imageهای قدیمی بررسی شوند. اسکن سرور کافی نیست؛ معماری و تنظیمات هم بخشی از سطح حمله هستند.

چک‌لیست سریع ارزیابی آسیب‌پذیری

• آیا Inventory دارایی‌ها به‌روز است؟
• آیا دارایی‌های اینترنتی با فاصله کوتاه‌تر اسکن می‌شوند؟
• آیا اسکن Credentialed برای سیستم‌های مهم فعال است؟
• آیا گزارش‌ها owner، deadline و وضعیت اصلاح دارند؟
• آیا موارد Critical بعد از اصلاح دوباره بررسی می‌شوند؟
• آیا سیستم‌های EOL یا بدون Patch جداگانه مدیریت شده‌اند؟
• آیا کنترل‌های جبرانی برای مواردی که فعلا Patch نمی‌شوند ثبت شده است؟

برداشت عملی از ارزیابی مداوم آسیب‌پذیری

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