وقتی CVE جدید با امتیاز 9.8 منتشر میشود، واکنش درست همیشه «همهچیز را فوراً Patch کن» نیست؛ و واکنش درست قطعاً «صبر کنیم ببینیم چه میشود» هم نیست. اولویت باید از Risk واقعی سازمان بیاید.
CVSS فقط یک ورودی است
CVSS شدت فنی Vulnerability را توصیف میکند، اما نمیداند Asset شما اینترنتی است یا Offline، چه دادهای دارد، Exploit فعال وجود دارد یا نه و Patch چه Downtimeای ایجاد میکند. بنابراین تصمیم سازمانی باید Context اضافه کند.
پنج سؤال در ۳۰ دقیقه اول
- آیا Product/Version ما واقعاً Affected است؟
- Asset در اینترنت/DMZ است یا Internal؟
- Exploit عمومی یا Evidence of exploitation وجود دارد؟
- Asset چه Criticality و Data Sensitivity دارد؟
- Patch/Workaround/Compensating Control در دسترس است؟
مدل ساده Priority
| عامل | ریسک بالاتر وقتی… |
|---|---|
| Severity | Impact و Attack Complexity نامطلوب است. |
| Exploitability | PoC/Exploit فعال یا گزارش بهرهبرداری وجود دارد. |
| Exposure | سیستم Internet-facing یا مسیر دسترسی گسترده دارد. |
| Criticality | سرویس حیاتی یا Credential/Identity را کنترل میکند. |
| Control Gap | WAF/Segmentation/EDR یا Workaround مؤثر ندارید. |
اگر Patch فوراً ممکن نیست
- Workaround رسمی Vendor را اعمال کنید.
- Exposure را با Firewall/WAF/ACL محدود کنید.
- Feature آسیبپذیر را در صورت امکان Disable کنید.
- Monitoring/EDR Rule را تقویت کنید.
- تغییر را زماندار کنید و Owner/Deadline داشته باشد.
Patch Emergency بدون تست هم ریسک دارد
برای سرویس Critical، Emergency Change باید سریع باشد اما بیبرنامه نه. Snapshot/Backup، Health Check، Rollback Plan و Pilot روی Node غیرحیاتی میتواند زمان را کمی افزایش دهد ولی احتمال Outage گسترده را کاهش دهد.
Exploitability را با داده بیرونی غنی کنید
در کنار CVSS، وجود Exploit عمومی، گزارش بهرهبرداری واقعی و فهرستهایی مانند CISA Known Exploited Vulnerabilities میتواند Priority را تغییر دهد. EPSS نیز یک سیگنال احتمالی برای Exploit شدن Vulnerability در بازه زمانی کوتاه ارائه میکند. هیچکدام بهتنهایی Risk سازمان شما نیستند؛ آنها ورودی تصمیماند.
یک Matrix ساده بسازید
| Exposure / Exploit | Exploit فعال | PoC عمومی | Exploit شناختهشده نیست |
|---|---|---|---|
| Internet-facing Critical | P0 — فوری | P0/P1 | P1 |
| Internal Critical | P0/P1 | P1 | P2 |
| User Endpoint | P1 | P1/P2 | P2/P3 |
| Offline/Isolated | Context-based | P2 | P3 |
P0/P1/P2 تعریف داخلی شماست؛ مهم این است که SLA هر سطح مشخص باشد. مثلاً P0 ممکن است ۲۴ ساعت، P1 سه روز و P2 چرخه Patch عادی باشد.
Asset Inventory شرط Vulnerability Management است
اگر نمیدانید کدام Version روی کدام Server است، CVE Triage تبدیل به جستوجوی اضطراری میشود. CMDB کامل لازم نیست؛ حداقل Product، Version، Owner، Exposure و Criticality برای Assetهای مهم باید قابلQuery باشد.
بعد از Patch چه؟
Version/Build واقعاً تغییر کرده است.
Service Health و Application Function تست شده است.
Scanner یا Check Vendor تأیید میکند Vulnerability رفع شده است.
Compensating Control موقت اگر دیگر نیاز نیست حذف شده است.
Incident/Change Ticket با Evidence بسته شده است.
گزارش به مدیریت
بهجای ارائه لیست ۵۰۰ CVE، بگویید چند مورد Exploited + Internet-facing باز است، میانگین زمان Remediation چقدر است و کدام Business Owner SLA را شکسته است. Vulnerability Management زمانی بالغ میشود که گزارش آن به تصمیم منجر شود.
برای Vulnerability و Patch Management فرایند مشخص ندارید؟
میتوانیم یک Workflow اولویتبندی، Patch Ring و گزارش مدیریتی متناسب با شبکه شما تعریف کنیم.