اولویت‌بندی آسیب‌پذیری بر اساس ریسک؛ چرا CVSS به‌تنهایی کافی نیست؟

CVSS برای بیان شدت فنی مفید است، اما پاسخ نمی‌دهد کدام Vulnerability برای سازمان شما فوریت بیشتری دارد. یک ضعف با امتیاز بالا روی سیستم آزمایشی ممکن است Risk کمتری از ضعف متوسط روی سامانه مالی اینترنتی داشته باشد.

چه Signalهایی باید کنار CVSS دیده شوند؟

• Business Criticality دارایی
• Internet Exposure
• وجود Exploit عملی یا Known Exploitation
• حضور در فهرست KEV
• Data Sensitivity
• Controlهای جبرانی
• سن و SLA اصلاح

KEV چه کمکی می‌کند؟

فهرست Known Exploited Vulnerabilities یک Signal مهم است چون نشان می‌دهد Vulnerability در دنیای واقعی Exploit شده است. اما حتی KEV هم باید کنار Context سازمان دیده شود؛ Asset، Exposure و Controlها هنوز اهمیت دارند.

سناریو

دو Vulnerability داریم: اولی CVSS 9.8 روی سیستم داخلی آزمایشی، دومی CVSS 8.1 روی VPN سازمانی اینترنتی و موجود در KEV. اولویت فقط با عدد Severity مشخص نمی‌شود؛ Context دوم Risk بالاتری می‌سازد.

از Finding فنی به Risk Scenario

یافته Scanner باید به Asset، Threat Event و Consequence متصل شود. این تبدیل همان چیزی است که Risk Register را از لیست CVE جدا می‌کند.

Risk-Based SLA

به‌جای SLA یکسان برای همه یافته‌ها، می‌توان Remediation Window را با Risk Tier تعیین کرد. Exception نیز باید Approver، دلیل و Expiry داشته باشد.

نقش MedaGRC

در نرم‌افزار مدیریت ریسک سایبری MedaGRC هدف این است که یافته فنی به Risk، Owner، Treatment و KRI وصل شود؛ نه اینکه Scanner جایگزین شود.

سخن پایانی

Severity می‌گوید Vulnerability از نظر فنی چقدر بد است؛ Risk می‌گوید برای سازمان شما چقدر مهم است. تصمیم Remediation باید بر اساس دومی گرفته شود.