CVSS چیست؟ چگونه شدت آسیب‌پذیری‌های امنیتی محاسبه می‌شود؟

CVSS چیست؟ CVSS یا Common Vulnerability Scoring System یک استاندارد بین‌المللی برای ارزیابی شدت آسیب‌پذیری‌های امنیتی است که با بررسی شرایط بهره‌برداری، میزان دسترسی موردنیاز مهاجم و تأثیر احتمالی آسیب‌پذیری بر محرمانگی، یکپارچگی و دسترس‌پذیری اطلاعات، امتیازی بین صفر تا ۱۰ اختصاص می‌دهد. این امتیاز به کارشناسان امنیت کمک می‌کند آسیب‌پذیری‌ها را طبقه‌بندی و برای رفع آن‌ها برنامه‌ریزی کنند.

مقدمه؛ چرا محاسبه شدت آسیب‌پذیری‌های امنیتی اهمیت دارد؟

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

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

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

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

اینجاست که استاندارد CVSS اهمیت پیدا می‌کند.

سیستم امتیازدهی CVSS تلاش می‌کند ویژگی‌های فنی یک آسیب‌پذیری را به شکلی ساختاریافته ارزیابی کند تا شدت آن قابل مقایسه و قابل گزارش باشد.

این استاندارد در مدیریت آسیب‌پذیری‌ها یا Vulnerability Management، تست نفوذ، ارزیابی امنیت وب‌سایت، تحلیل گزارش‌های امنیتی و تصمیم‌گیری درباره نصب وصله‌های نرم‌افزاری کاربرد گسترده‌ای دارد.

بااین‌حال، یک نکته اساسی وجود دارد: امتیاز CVSS به‌تنهایی نشان‌دهنده میزان ریسک واقعی یک آسیب‌پذیری برای یک سازمان نیست.

برای تصمیم‌گیری دقیق باید علاوه بر شدت فنی، اطلاعاتی مانند اهمیت دارایی، میزان دسترسی مهاجمان، شواهد بهره‌برداری واقعی و کنترل‌های دفاعی موجود نیز بررسی شوند.

در این مقاله از رخنه‌کاو، مفهوم CVSS، معیارهای امتیازدهی، تفاوت نسخه‌های 3.1 و 4.0، روش محاسبه شدت آسیب‌پذیری‌ها و کاربرد عملی این استاندارد در امنیت وب‌سایت‌ها و سرورها را به‌صورت جامع بررسی می‌کنیم.

CVSS چیست و چه کاربردی در امنیت سایبری دارد؟

CVSS مخفف Common Vulnerability Scoring System به معنای «سیستم امتیازدهی مشترک آسیب‌پذیری‌ها» است.

این استاندارد یک چارچوب باز و مستقل از فروشنده برای توصیف ویژگی‌های فنی آسیب‌پذیری‌های امنیتی ارائه می‌دهد.

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

استاندارد CVSS توسط سازمان FIRST مدیریت و توسعه داده می‌شود. FIRST یک سازمان بین‌المللی فعال در حوزه همکاری تیم‌های پاسخ‌گویی به رخدادهای امنیتی است.

در این چارچوب، برای هر آسیب‌پذیری مجموعه‌ای از ویژگی‌ها بررسی می‌شود؛ برای مثال، آیا بهره‌برداری از راه دور امکان‌پذیر است؟ آیا مهاجم به حساب کاربری نیاز دارد؟ آیا کاربر باید اقدامی انجام دهد؟ و در صورت موفقیت حمله، چه بخش‌هایی آسیب خواهند دید؟

خروجی این بررسی معمولاً شامل دو بخش است:

• امتیاز عددی CVSS بین 0.0 تا 10.0
• بردار امتیازدهی یا CVSS Vector که ویژگی‌های انتخاب‌شده برای محاسبه را مشخص می‌کند.

این دو بخش در کنار یکدیگر امکان بررسی و بازبینی نتیجه ارزیابی را فراهم می‌کنند.

چرا به یک استاندارد مشترک نیاز داریم؟

اصطلاحاتی مانند «خطرناک»، «شدید» یا «بحرانی» بدون وجود معیار مشخص می‌توانند برداشت‌های متفاوتی ایجاد کنند.

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

CVSS با تعریف معیارهای فنی، این اختلاف برداشت را کاهش می‌دهد.

برای مثال، اگر دو آسیب‌پذیری از نظر امکان بهره‌برداری و پیامدهای امنیتی تفاوت داشته باشند، این تفاوت می‌تواند در امتیاز و بردار CVSS آن‌ها منعکس شود.

البته CVSS جایگزین تحلیل کارشناسی نیست. انتخاب صحیح مقادیر معیارها همچنان به اطلاعات معتبر و قضاوت فنی نیاز دارد.

چه کسانی از CVSS استفاده می‌کنند؟

کارشناسان تست نفوذ از CVSS برای توصیف شدت یافته‌های امنیتی استفاده می‌کنند.

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

توسعه‌دهندگان می‌توانند از امتیازها برای برنامه‌ریزی اصلاح مشکلات نرم‌افزاری استفاده کنند.

مدیران سرور و وب‌سایت نیز با بررسی شدت آسیب‌پذیری‌ها، درباره نصب به‌روزرسانی‌ها، محدودسازی دسترسی و اعمال کنترل‌های دفاعی تصمیم می‌گیرند.

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

سطح‌بندی شدت آسیب‌پذیری‌ها در استاندارد CVSS

یکی از مهم‌ترین ویژگی‌های CVSS، تبدیل امتیاز عددی به سطح کیفی شدت آسیب‌پذیری است.

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

جدول زیر سطوح استاندارد CVSS را نشان می‌دهد:

این بازه‌ها در نسخه‌های 3.1 و 4.0 یکسان هستند؛ بااین‌حال روش محاسبه امتیاز در این دو نسخه تفاوت دارد.

آسیب‌پذیری با شدت کم یا Low

آسیب‌پذیری‌های این دسته معمولاً پیامد امنیتی محدودتری دارند یا بهره‌برداری از آن‌ها با محدودیت‌های فنی قابل‌توجهی همراه است.

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

البته شدت کم به معنای بی‌اهمیت بودن نیست.

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

آسیب‌پذیری با شدت متوسط یا Medium

این دسته شامل مشکلاتی است که می‌توانند پیامد امنیتی قابل‌توجهی ایجاد کنند، اما شرایط بهره‌برداری یا میزان تأثیر آن‌ها به اندازه آسیب‌پذیری‌های شدیدتر نیست.

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

نوع آسیب‌پذیری به‌تنهایی سطح CVSS آن را تعیین نمی‌کند؛ جزئیات فنی اهمیت دارند.

آسیب‌پذیری با شدت زیاد یا High

آسیب‌پذیری‌های High می‌توانند محرمانگی، یکپارچگی یا دسترس‌پذیری سیستم را به شکل جدی تحت تأثیر قرار دهند.

بعضی از ضعف‌های امنیتی که امکان دسترسی غیرمجاز به داده‌های حساس یا تغییر اطلاعات مهم را فراهم می‌کنند، ممکن است در این دسته قرار بگیرند.

وجود چنین آسیب‌پذیری‌هایی در سرویس‌های حساس معمولاً نیازمند بررسی و اقدام سریع تیم امنیت است.

آسیب‌پذیری بحرانی یا Critical

امتیازهای 9.0 تا 10.0 در دسته بحرانی قرار دارند.

این آسیب‌پذیری‌ها معمولاً ترکیبی از شرایط بهره‌برداری مساعد و پیامدهای امنیتی بسیار شدید دارند.

برای مثال، بعضی از آسیب‌پذیری‌های اجرای کد از راه دور یا Remote Code Execution که بدون احراز هویت قابل بهره‌برداری هستند، ممکن است امتیاز بحرانی دریافت کنند.

بااین‌حال، هر آسیب‌پذیری RCE الزاماً Critical نیست و امتیاز نهایی باید از روی معیارهای واقعی تعیین شود.

نکته مهم این است که سطح Critical بیانگر شدت فنی بالاست؛ نه اینکه حمله حتماً رخ داده یا در آینده رخ خواهد داد.

امتیاز CVSS چگونه محاسبه می‌شود؟

محاسبه CVSS بر اساس انتخاب مجموعه‌ای از معیارهای مشخص و پردازش آن‌ها با الگوریتم رسمی نسخه موردنظر انجام می‌شود.

در این فرایند، تحلیلگر ابتدا شرایط بهره‌برداری از آسیب‌پذیری را بررسی می‌کند.

سپس پیامدهای احتمالی موفقیت حمله را بر سیستم آسیب‌پذیر و سایر سیستم‌های مرتبط ارزیابی می‌کند.

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

در نسخه 4.0، معیارها در چهار گروه اصلی قرار می‌گیرند:

1. معیارهای پایه یا Base Metrics
2. معیارهای تهدید یا Threat Metrics
3. معیارهای محیطی یا Environmental Metrics
4. معیارهای تکمیلی یا Supplemental Metrics

هر گروه هدف متفاوتی دارد.

معیارهای پایه ویژگی‌های ذاتی آسیب‌پذیری را بیان می‌کنند. معیارهای تهدید اطلاعات متغیر درباره وضعیت بهره‌برداری را وارد ارزیابی می‌کنند. معیارهای محیطی شرایط استقرار و اهمیت سیستم را در نظر می‌گیرند و معیارهای تکمیلی اطلاعاتی برای تصمیم‌گیری بهتر ارائه می‌دهند.

در ادامه، هر گروه را جداگانه بررسی می‌کنیم.

معیارهای پایه CVSS یا Base Metrics چیست؟

معیارهای پایه مهم‌ترین بخش امتیازدهی CVSS هستند.

این معیارها ویژگی‌هایی را توصیف می‌کنند که از نظر فنی به آسیب‌پذیری مربوط هستند و با گذشت زمان یا تفاوت محیط‌های سازمانی تغییر نمی‌کنند.

در CVSS 4.0، یازده معیار پایه وجود دارد.

پنج معیار به شرایط بهره‌برداری مربوط می‌شوند و شش معیار پیامدهای امنیتی را ارزیابی می‌کنند.

۱. بردار حمله یا Attack Vector

معیار Attack Vector که با AV نمایش داده می‌شود، مشخص می‌کند مهاجم از چه موقعیتی می‌تواند آسیب‌پذیری را مورد بهره‌برداری قرار دهد.

این معیار چهار مقدار دارد:

Network یا N: بهره‌برداری از طریق شبکه و فراتر از یک محدوده مجاورت شبکه‌ای امکان‌پذیر است. آسیب‌پذیری لزوماً نباید از اینترنت عمومی در دسترس باشد تا این مقدار را دریافت کند.

Adjacent یا A: مهاجم باید از نظر منطقی یا پروتکلی در محدوده مجاور سیستم هدف قرار داشته باشد؛ برای مثال، در یک بخش مشخص از شبکه محلی.

Local یا L: بهره‌برداری به دسترسی محلی، قابلیت‌های اجرای برنامه در سیستم یا شرایطی مانند باز شدن یک فایل آسیب‌زا توسط کاربر وابسته است.

Physical یا P: بهره‌برداری نیازمند تماس یا دسترسی فیزیکی مهاجم به دستگاه است.

در شرایط برابر، آسیب‌پذیری قابل بهره‌برداری از طریق شبکه معمولاً شدت بیشتری نسبت به مشکلی دارد که به دسترسی فیزیکی نیازمند است.

اما نباید Network را با «قطعاً در دسترس اینترنت بودن» یکسان دانست.

۲. پیچیدگی حمله یا Attack Complexity

معیار AC میزان پیچیدگی فنی لازم برای عبور از شرایط یا سازوکارهای امنیتی داخلی را بررسی می‌کند.

در CVSS 4.0 دو مقدار وجود دارد:

Low یا L: بهره‌برداری به اقدامات پیچیده و ویژه برای عبور از سازوکارهای امنیتی نیاز ندارد.

High یا H: موفقیت حمله به عبور از محدودیت‌های امنیتی مشخص یا انجام اقدامات فنی پیچیده وابسته است.

برای مثال، اگر بهره‌برداری نیازمند دور زدن یک سازوکار حفاظتی داخلی مانند ASLR باشد، ممکن است پیچیدگی حمله بالا ارزیابی شود.

البته بالا بودن پیچیدگی لزوماً به معنای نیاز به زمان طولانی نیست. معیار AC درباره ویژگی‌های فنی بهره‌برداری است، نه مدت اجرای حمله.

۳. الزامات حمله یا Attack Requirements

معیار Attack Requirements با علامت AT در نسخه 4.0 معرفی شده است.

این معیار مشخص می‌کند آیا موفقیت حمله به شرایط خاصی در نحوه اجرا یا استقرار سیستم وابسته است یا خیر.

مقادیر آن عبارت‌اند از:

None یا N: بهره‌برداری به شرایط خاص عملیاتی وابسته نیست.

Present یا P: وقوع حمله به وجود شرایط مشخصی نیاز دارد که همیشه فراهم نیستند.

برای مثال، بعضی از آسیب‌پذیری‌ها به شرایط هم‌زمانی خاص یا Race Condition وابسته هستند.

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

تفکیک AT از AC یکی از تغییرات مهم CVSS 4.0 است و باعث می‌شود پیچیدگی فنی حمله با شرایط لازم برای وقوع آن اشتباه گرفته نشود.

۴. سطح دسترسی موردنیاز یا Privileges Required

معیار PR مشخص می‌کند مهاجم پیش از بهره‌برداری باید چه سطحی از دسترسی را در اختیار داشته باشد.

این معیار سه مقدار دارد:

None یا N: مهاجم به حساب کاربری یا مجوز قبلی نیاز ندارد.

Low یا L: مهاجم باید دارای دسترسی محدود، مانند حساب کاربری عادی، باشد.

High یا H: بهره‌برداری به دسترسی سطح بالا یا مدیریتی نیاز دارد.

فرض کنید یک آسیب‌پذیری در افزونه وردپرس فقط توسط مدیر سایت قابل فعال‌سازی باشد.

از نظر معیار PR، این وضعیت با مشکلی که یک بازدیدکننده ناشناس می‌تواند از آن بهره‌برداری کند، تفاوت دارد.

در شرایط برابر، نیاز نداشتن به دسترسی قبلی می‌تواند شدت آسیب‌پذیری را افزایش دهد.

۵. تعامل کاربر یا User Interaction

معیار UI بررسی می‌کند آیا موفقیت حمله به مشارکت یک کاربر دیگر، غیر از مهاجم، وابسته است یا خیر.

در CVSS 4.0 سه مقدار برای آن تعریف شده است:

None یا N: حمله بدون تعامل کاربر دیگر امکان‌پذیر است.

Passive یا P: کاربر باید تعامل محدودی انجام دهد که معمولاً مستلزم دور زدن آگاهانه حفاظت‌های امنیتی نیست.

Active یا A: کاربر باید اقدام مشخص و آگاهانه‌ای انجام دهد که برای موفقیت حمله لازم است.

برای مثال، مشاهده یک صفحه آلوده در بعضی از سناریوهای Stored XSS می‌تواند با تعامل غیرفعال مرتبط باشد.

در مقابل، واردکردن دستی اطلاعات خاص یا تأیید یک هشدار امنیتی ممکن است در دسته تعامل فعال قرار گیرد.

تمایز این موارد کمک می‌کند شرایط واقعی بهره‌برداری دقیق‌تر توصیف شوند.

معیارهای تأثیر آسیب‌پذیری در CVSS

پس از بررسی شرایط بهره‌برداری، باید مشخص شود موفقیت حمله چه پیامدهایی برای امنیت سیستم دارد.

در این قسمت، سه اصل اساسی امنیت اطلاعات اهمیت پیدا می‌کنند:

• Confidentiality یا محرمانگی
• Integrity یا یکپارچگی
• Availability یا دسترس‌پذیری

این سه اصل با عنوان CIA Triad شناخته می‌شوند.

CVSS 4.0 تأثیر آسیب‌پذیری بر سیستم آسیب‌پذیر و سیستم‌های بعدی را به‌صورت جداگانه بررسی می‌کند.

محرمانگی یا Confidentiality

محرمانگی به جلوگیری از دسترسی غیرمجاز به اطلاعات مربوط می‌شود.

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

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

در CVSS 4.0، تأثیر بر محرمانگی می‌تواند High، Low یا None باشد.

ارزیابی شدت این تأثیر به نوع اطلاعات و پیامد مستقیم افشای آن وابسته است.

یکپارچگی یا Integrity

یکپارچگی به جلوگیری از تغییر غیرمجاز اطلاعات و عملکرد سیستم اشاره دارد.

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

برای مثال، ضعف امنیتی که امکان تغییر اطلاعات سفارش‌های فروشگاهی را بدون مجوز فراهم می‌کند، می‌تواند تهدیدی برای Integrity باشد.

میزان تأثیر باید بر اساس گستره و اهمیت تغییرات قابل انجام تعیین شود.

دسترس‌پذیری یا Availability

دسترس‌پذیری به امکان استفاده کاربران مجاز از سیستم و خدمات آن اشاره دارد.

آسیب‌پذیری‌هایی که باعث اختلال در سرویس، توقف پردازش درخواست‌ها یا از کار افتادن یک سامانه می‌شوند، می‌توانند Availability را تحت تأثیر قرار دهند.

برای مثال، یک ضعف فنی ممکن است باعث شود سرویس در شرایط مشخصی از دسترس خارج شود.

در ارزیابی شدت، مدت اختلال به‌تنهایی تعیین‌کننده نیست و ماهیت پیامد فنی نیز باید بررسی شود.

تفاوت Vulnerable System و Subsequent System

یکی از ویژگی‌های مهم CVSS 4.0، تفکیک پیامدهای امنیتی برای دو محدوده است.

Vulnerable System: سیستمی که آسیب‌پذیری در آن وجود دارد.

Subsequent System: سیستم دیگری که در نتیجه بهره‌برداری از آسیب‌پذیری تحت تأثیر قرار می‌گیرد.

این تفکیک باعث می‌شود پیامدهای خارج از سیستم آسیب‌پذیر بهتر نمایش داده شوند.

برای مثال، یک ضعف امنیتی در یک سرویس ممکن است علاوه بر خود آن سرویس، موجب دسترسی غیرمجاز به یک سامانه مستقل دیگر شود.

در چنین وضعیتی، پیامدهای مستقیم و پیامدهای سیستم بعدی جداگانه ارزیابی می‌شوند.

معیارهای تأثیر در CVSS 4.0 عبارت‌اند از:

تمام این معیارها در بخش پایه نسخه 4.0 باید مقداردهی شوند.

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

معیارهای تهدید یا Threat Metrics در CVSS 4.0

گروه Threat برای در نظر گرفتن اطلاعات متغیر مربوط به وضعیت بهره‌برداری از آسیب‌پذیری استفاده می‌شود.

در نسخه 4.0، معیار اصلی این گروه Exploit Maturity است که با E نمایش داده می‌شود.

این معیار به اطلاعاتی مانند وجود نمونه اثبات مفهوم، ابزارهای بهره‌برداری و شواهد حملات واقعی مرتبط است.

وضعیت‌های Exploit Maturity

Attacked یا A: شواهدی از حملات هدف‌گرفته‌شده گزارش شده یا ابزارهای تسهیل‌کننده بهره‌برداری در دسترس هستند.

Proof-of-Concept یا P: نمونه اثبات مفهوم عمومی وجود دارد، اما شواهد لازم برای دسته Attacked احراز نشده است.

Unreported یا U: بر اساس اطلاعات تهدید در دسترس، نشانه‌ای از نمونه عمومی بهره‌برداری یا حمله گزارش‌شده وجود ندارد.

Not Defined یا X: اطلاعات کافی برای تعیین وضعیت ارائه نشده است.

در محاسبه CVSS 4.0، مقدار پیش‌فرض Not Defined برای معیار E از نظر اثر محاسباتی معادل Attacked در نظر گرفته می‌شود.

بنابراین نباید تصور کرد که تعریف‌نشدن اطلاعات تهدید لزوماً امتیاز را کاهش می‌دهد.

چرا اطلاعات تهدید باید به‌روزرسانی شود؟

وضعیت یک آسیب‌پذیری ممکن است با گذشت زمان تغییر کند.

در ابتدا ممکن است فقط اطلاعات فنی محدودی درباره آن وجود داشته باشد.

بعدها امکان دارد نمونه اثبات مفهوم منتشر شود یا شواهدی از بهره‌برداری واقعی به دست آید.

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

به همین دلیل، بازبینی دوره‌ای اطلاعات تهدید و استفاده از داده‌های معتبر برای مدیریت آسیب‌پذیری ضروری است.

معیارهای محیطی یا Environmental Metrics چیست؟

معیارهای Environmental برای تطبیق ارزیابی CVSS با محیط واقعی سازمان طراحی شده‌اند.

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

برای مثال، یک اختلال در دسترس‌پذیری ممکن است برای یک سامانه آزمایشی کم‌اهمیت‌تر از یک سرویس حیاتی باشد.

معیارهای محیطی این تفاوت‌ها را در چارچوب رسمی امتیازدهی منعکس می‌کنند.

اهمیت محرمانگی، یکپارچگی و دسترس‌پذیری

در CVSS 4.0 سه معیار برای بیان اهمیت الزامات امنیتی وجود دارد:

CR: اهمیت محرمانگی اطلاعات

IR: اهمیت یکپارچگی اطلاعات

AR: اهمیت دسترس‌پذیری خدمات

هرکدام می‌توانند مقدار Low، Medium، High یا Not Defined داشته باشند.

برای مثال، در یک پایگاه داده شامل اطلاعات خصوصی کاربران، محرمانگی ممکن است اهمیت بسیار بالایی داشته باشد.

در یک سامانه کنترل صنعتی، دسترس‌پذیری و یکپارچگی عملکرد ممکن است اهمیت ویژه‌ای پیدا کنند.

انتخاب این مقادیر باید با توجه به پیامدهای واقعی سازمان انجام شود.

معیارهای اصلاح‌شده یا Modified Metrics

CVSS امکان اصلاح معیارهای پایه بر اساس شرایط محیطی مشخص را نیز فراهم می‌کند.

این معیارها معمولاً با حرف M شروع می‌شوند؛ مانند MAV، MAC، MPR و MUI.

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

در صورت انطباق با دستورالعمل رسمی، این وضعیت می‌تواند در معیار محیطی مناسب منعکس شود.

البته وجود یک Firewall یا WAF به‌تنهایی دلیل کافی برای تغییر دلخواه امتیاز نیست.

باید مشخص شود کنترل امنیتی واقعاً کدام ویژگی بهره‌برداری را تحت تأثیر قرار داده است.

چرا امتیاز پایه و محیطی ممکن است متفاوت باشند؟

امتیاز پایه بر اساس ویژگی‌های ذاتی آسیب‌پذیری محاسبه می‌شود.

در مقابل، ارزیابی محیطی شرایط خاص استقرار و اهمیت دارایی را در نظر می‌گیرد.

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

برعکس، اهمیت بسیار بالای یک دارایی می‌تواند در ارزیابی محیطی آن نقش داشته باشد.

این تفاوت نشان می‌دهد که امتیاز عمومی یک آسیب‌پذیری همیشه برای تصمیم‌گیری نهایی کافی نیست.

معیارهای تکمیلی یا Supplemental Metrics در CVSS 4.0

نسخه 4.0 گروهی از معیارهای اختیاری به نام Supplemental معرفی کرده است.

این معیارها اطلاعات بیشتری درباره آسیب‌پذیری فراهم می‌کنند، اما مستقیماً امتیاز عددی CVSS را تغییر نمی‌دهند.

هدف آن‌ها کمک به تحلیلگران برای درک بهتر شرایط و تصمیم‌گیری آگاهانه‌تر است.

مهم‌ترین معیارهای Supplemental

Safety: مشخص می‌کند آیا بهره‌برداری از آسیب‌پذیری می‌تواند پیامد مرتبط با ایمنی انسان داشته باشد.

Automatable: بررسی می‌کند آیا مراحل اصلی بهره‌برداری در مقیاس چند هدف قابلیت خودکارسازی دارند.

Recovery: میزان امکان بازیابی خدمات پس از وقوع حمله را توصیف می‌کند.

Value Density: نشان می‌دهد یک رویداد بهره‌برداری تا چه اندازه می‌تواند دسترسی به منابع متمرکز یا گسترده ایجاد کند.

Vulnerability Response Effort: دشواری پاسخ اولیه و اجرای اقدامات لازم برای مقابله با آسیب‌پذیری را توصیف می‌کند.

Provider Urgency: میزان فوریت اعلام‌شده از سوی ارائه‌دهنده مربوط را منتقل می‌کند.

این معیارها در بعضی محیط‌ها اهمیت ویژه‌ای دارند.

برای نمونه، در یک سامانه صنعتی، پیامدهای مرتبط با ایمنی ممکن است برای تصمیم‌گیری عملیاتی بسیار مهم باشند.

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

نباید معیارهای Supplemental را با معیارهای محاسبه‌کننده مستقیم امتیاز اشتباه گرفت.

نحوه محاسبه امتیاز CVSS به‌صورت مرحله‌به‌مرحله

برای محاسبه صحیح CVSS، باید یک فرایند منظم و قابل بازبینی وجود داشته باشد.

انتخاب تصادفی مقادیر در محاسبه‌گر یا حدس زدن امتیاز از روی عنوان آسیب‌پذیری روش معتبری نیست.

مرحله اول: شناسایی دقیق آسیب‌پذیری

ابتدا باید مشخص شود ضعف امنیتی در کدام محصول، نسخه یا مؤلفه وجود دارد.

اطلاعات مهم عبارت‌اند از:

• نام نرم‌افزار یا سرویس آسیب‌پذیر
• نسخه‌های تحت تأثیر
• نوع ضعف امنیتی
• شرایط لازم برای بهره‌برداری
• پیامدهای فنی قابل انتظار
• وجود اصلاحیه یا راهکار کاهش خطر

در این مرحله بهتر است اطلاعات شناسایی‌شده با مستندات معتبر و شرایط واقعی سیستم تطبیق داده شوند.

مرحله دوم: تعیین نسخه استاندارد CVSS

قبل از امتیازدهی باید نسخه موردنظر انتخاب شود.

CVSS 3.1 و CVSS 4.0 معیارها و روش‌های محاسباتی یکسانی ندارند.

استفاده از بردار نسخه 3.1 در محاسبه‌گر نسخه 4.0 صحیح نیست.

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

مرحله سوم: بررسی شرایط بهره‌برداری

در این مرحله باید ویژگی‌های حمله تعیین شوند.

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

در CVSS 4.0، معیارهای AV، AC، AT، PR و UI در این مرحله مقداردهی می‌شوند.

هر مقدار باید بر اساس واقعیت فنی آسیب‌پذیری انتخاب شود.

مرحله چهارم: ارزیابی پیامدهای امنیتی

پس از تعیین شرایط بهره‌برداری، باید پیامدهای موفقیت حمله بررسی شوند.

آیا اطلاعات محرمانه افشا می‌شوند؟

آیا امکان تغییر غیرمجاز اطلاعات وجود دارد؟

آیا سرویس از دسترس خارج می‌شود؟

آیا سیستم مستقلی غیر از سیستم آسیب‌پذیر تحت تأثیر قرار می‌گیرد؟

پاسخ این پرسش‌ها مبنای انتخاب معیارهای تأثیر خواهد بود.

مرحله پنجم: تشکیل بردار CVSS

پس از مشخص شدن مقادیر، آن‌ها در قالب یک Vector String قرار می‌گیرند.

این بردار نشان می‌دهد امتیاز بر چه اساسی محاسبه شده است.

ثبت بردار اهمیت زیادی دارد؛ زیرا صرفاً مشاهده یک عدد، اطلاعات کافی درباره شرایط بهره‌برداری و پیامدها ارائه نمی‌کند.

مرحله ششم: محاسبه با ابزار معتبر

بردار باید در محاسبه‌گر سازگار با نسخه استاندارد وارد شود.

برای CVSS 4.0 می‌توان از محاسبه‌گر رسمی زیر استفاده کرد:

https://www.first.org/cvss/calculator/v4.0

برای نسخه 3.1 نیز محاسبه‌گر اختصاصی این نسخه در دسترس است:

https://www.first.org/cvss/calculator/3.1

این ابزارها با انتخاب معیارها، امتیاز عددی و بردار مربوط را نمایش می‌دهند.

مرحله هفتم: بررسی اطلاعات تهدید و محیط

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

برای تصمیم‌گیری دقیق‌تر می‌توان اطلاعات تهدید و معیارهای محیطی را نیز بررسی کرد.

در CVSS 4.0، بسته به گروه‌های صریحاً ارزیابی‌شده، برچسب‌هایی مانند CVSS-B، CVSS-BT، CVSS-BE و CVSS-BTE به کار می‌روند.

این برچسب‌ها به خواننده کمک می‌کنند بداند کدام گروه‌های اطلاعاتی در ارزیابی لحاظ شده‌اند.

مرحله هشتم: ثبت و بازبینی نتیجه

در پایان باید نسخه CVSS، امتیاز، بردار، مستندات ارزیابی و تاریخ بررسی ثبت شوند.

اگر اطلاعات جدیدی درباره آسیب‌پذیری منتشر شد، لازم است ارزیابی دوباره بررسی شود.

به‌خصوص اطلاعات تهدید و شرایط استقرار سازمان ممکن است با گذشت زمان تغییر کنند.

مثال عملی محاسبه CVSS 4.0

برای درک بهتر روش امتیازدهی، یک نمونه آموزشی را بررسی می‌کنیم.

فرض کنید آسیب‌پذیری مشخصی در یک سرویس شبکه‌ای باعث از دست رفتن شدید دسترس‌پذیری همان سرویس می‌شود.

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

همچنین بهره‌برداری به شرایط اجرایی خاص وابسته نیست.

در این نمونه، پیامد امنیتی فقط روی دسترس‌پذیری سیستم آسیب‌پذیر قرار دارد و محرمانگی و یکپارچگی تحت تأثیر قرار نمی‌گیرند.

مقادیر معیارهای نمونه

بردار CVSS 4.0 این نمونه به شکل زیر است:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

امتیاز حاصل از این بردار در CVSS 4.0 برابر است با:

CVSS-B: 8.7 — High

این عدد نشان می‌دهد سناریوی موردنظر از نظر شدت فنی در دسته High قرار می‌گیرد.

علت اهمیت این آسیب‌پذیری ترکیب شرایط نسبتاً آسان بهره‌برداری با پیامد شدید برای دسترس‌پذیری سیستم است.

البته عدد 8.7 به معنای احتمال ۸۷ درصدی وقوع حمله نیست.

همچنین صرفاً از این امتیاز نمی‌توان نتیجه گرفت که مهاجمان در حال بهره‌برداری واقعی از آسیب‌پذیری هستند.

برای چنین نتیجه‌گیری‌هایی باید شواهد مستقل بررسی شوند.

فرمول محاسبه CVSS چگونه کار می‌کند؟

بسیاری از کاربران تصور می‌کنند CVSS با جمع‌کردن چند امتیاز ساده محاسبه می‌شود.

درحالی‌که روش محاسبه در نسخه‌های مختلف پیچیده‌تر است.

فرمول محاسبه در CVSS 3.1

در نسخه 3.1، دو مفهوم اصلی برای محاسبه امتیاز پایه وجود دارد:

Exploitability: امتیاز مرتبط با شرایط فنی بهره‌برداری

Impact: امتیاز مربوط به پیامدهای امنیتی موفقیت حمله

بخش Exploitability در نسخه 3.1 از رابطه زیر استفاده می‌کند:

Exploitability = 8.22 × AV × AC × PR × UI

در این رابطه، AV، AC، PR و UI وزن‌های عددی تعریف‌شده در استاندارد هستند.

برای محاسبه بخش تأثیر، ابتدا مقدار ISS تعیین می‌شود:

ISS = 1 - [(1-C) × (1-I) × (1-A)]

در این فرمول، C، I و A به‌ترتیب وزن‌های تأثیر بر محرمانگی، یکپارچگی و دسترس‌پذیری هستند.

اگر Scope در وضعیت Unchanged باشد، مقدار Impact از رابطه زیر به دست می‌آید:

Impact = 6.42 × ISS

در حالت Scope Changed، فرمول متفاوتی برای Impact استفاده می‌شود.

امتیاز پایه با درنظرگرفتن Impact، Exploitability، وضعیت Scope، سقف عدد ۱۰ و قاعده گرد کردن رسمی محاسبه می‌شود.

بنابراین حتی در نسخه 3.1 نیز جمع‌کردن ساده اعداد کافی نیست.

مثال شناخته‌شده از CVSS 3.1

بردار زیر را در نظر بگیرید:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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

همچنین هر سه مؤلفه محرمانگی، یکپارچگی و دسترس‌پذیری تأثیر شدید دریافت کرده‌اند.

امتیاز پایه این بردار برابر است با:

9.8 — Critical

این مثال نشان می‌دهد چگونه مجموعه‌ای از ویژگی‌های بهره‌برداری و پیامدهای امنیتی می‌تواند به شدت بحرانی منجر شود.

روش محاسبه در CVSS 4.0

در نسخه 4.0، روش محاسبه به شکل اساسی تغییر کرده است.

این نسخه از ساختاری مبتنی بر MacroVector و Interpolation استفاده می‌کند.

در این روش، ترکیب‌های معیارها در گروه‌هایی از بردارهای دارای شدت قابل مقایسه قرار می‌گیرند.

برای این گروه‌ها مقادیر امتیاز تعریف شده و سپس با توجه به تفاوت بردار موردنظر نسبت به بردارهای مرجع، امتیاز نهایی تعیین می‌شود.

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

به همین دلیل، برای محاسبه CVSS 4.0 نباید از فرمول نسخه 3.1 استفاده کرد.

همچنین ساخت یک فرمول دستی ساده بر اساس جمع وزن معیارها جایگزین روش رسمی نسخه 4.0 نیست.

بهترین روش برای محاسبه دقیق، استفاده از پیاده‌سازی معتبر استاندارد و بررسی بردار کامل آسیب‌پذیری است.

تفاوت CVSS 3.1 و CVSS 4.0 چیست؟

نسخه 4.0 در نوامبر ۲۰۲۳ منتشر شد و تغییرات مهمی در مدل امتیازدهی ایجاد کرد.

این تغییرات با هدف بهبود دقت فنی، شفافیت ارزیابی و امکان استفاده از اطلاعات محیطی و تهدید انجام شدند.

جدول زیر تفاوت‌های اصلی را نشان می‌دهد:

حذف Scope چه تأثیری دارد؟

در نسخه 3.1، معیار Scope مشخص می‌کرد آیا بهره‌برداری از آسیب‌پذیری می‌تواند از محدوده امنیتی مؤلفه آسیب‌پذیر عبور کند یا خیر.

در نسخه 4.0، این معیار حذف شده و مدل تأثیر بر سیستم آسیب‌پذیر و سیستم بعدی جایگزین آن شده است.

این تغییر به تحلیلگران امکان می‌دهد پیامدهای امنیتی را به شکل مستقیم‌تری توصیف کنند.

البته مفهوم سیستم بعدی دقیقاً معادل معیار Scope در نسخه 3.1 نیست و نباید این دو را بدون بررسی تعریف‌های مربوط یکسان فرض کرد.

چرا Attack Requirements اضافه شد؟

در نسخه 3.1، بعضی از شرایط متفاوت بهره‌برداری در معیار Attack Complexity قرار می‌گرفتند.

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

این تفکیک در مواردی مانند Race Condition یا وابستگی به وضعیت مشخص سیستم، ارزیابی را دقیق‌تر می‌کند.

آیا امتیاز نسخه 4.0 همیشه بیشتر است؟

خیر.

تغییر روش امتیازدهی به معنای افزایش همیشگی شدت آسیب‌پذیری‌ها نیست.

ممکن است یک آسیب‌پذیری در نسخه‌های مختلف امتیاز متفاوتی دریافت کند.

این تفاوت الزاماً نشانه تغییر ماهیت آسیب‌پذیری نیست؛ بلکه ممکن است ناشی از مدل ارزیابی و معیارهای متفاوت باشد.

در گزارش‌های امنیتی باید شماره نسخه CVSS کنار امتیاز ثبت شود.

تفاوت CVSS با CVE و CWE چیست؟

در بررسی گزارش‌های امنیتی معمولاً اصطلاحات CVSS، CVE و CWE در کنار یکدیگر مشاهده می‌شوند.

بااین‌حال، این مفاهیم وظایف متفاوتی دارند.

CVE چیست؟

CVE مخفف Common Vulnerabilities and Exposures است.

شناسه CVE برای شناسایی و ارجاع به آسیب‌پذیری‌های امنیتی شناخته‌شده استفاده می‌شود.

برای مثال، ساختار شناسه می‌تواند به شکل زیر باشد:

CVE-YYYY-NNNNN

این قالب صرفاً یک نمونه نمایشی است و شناسه واقعی آسیب‌پذیری مشخصی محسوب نمی‌شود.

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

CWE چیست؟

CWE مخفف Common Weakness Enumeration است.

این چارچوب انواع ضعف‌های نرم‌افزاری و سخت‌افزاری را طبقه‌بندی می‌کند.

برای مثال، ضعف در کنترل دسترسی، اعتبارسنجی نامناسب ورودی و بعضی از مشکلات مدیریت حافظه می‌توانند در دسته‌بندی‌های CWE قرار گیرند.

CWE درباره نوع ضعف صحبت می‌کند؛ درحالی‌که CVSS شدت یک آسیب‌پذیری مشخص را توصیف می‌کند.

مقایسه CVE، CWE و CVSS

برای نمونه، ممکن است یک آسیب‌پذیری دارای شناسه CVE باشد، به یک دسته CWE مرتبط شود و امتیاز CVSS نیز برای آن منتشر شده باشد.

این اطلاعات مکمل یکدیگر هستند، اما جایگزین هم نیستند.

تفاوت CVSS و EPSS در ارزیابی آسیب‌پذیری‌ها

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

CVSS عمدتاً درباره شدت آسیب‌پذیری اطلاعات ارائه می‌دهد.

در مقابل، EPSS یا Exploit Prediction Scoring System برای پیش‌بینی احتمال مشاهده بهره‌برداری از یک آسیب‌پذیری در دنیای واقعی طراحی شده است.

EPSS چیست؟

EPSS یک مدل داده‌محور است که احتمال مشاهده فعالیت بهره‌برداری از یک آسیب‌پذیری منتشرشده را طی ۳۰ روز آینده تخمین می‌زند.

مقدار EPSS به‌صورت عددی بین صفر و یک ارائه می‌شود.

برای مثال، مقدار 0.20 نشان‌دهنده احتمال تخمینی ۲۰ درصد در چارچوب مدل EPSS است.

این عدد به معنای احتمال ۲۰ درصدی حمله موفق علیه سایت مشخص شما نیست.

EPSS اطلاعات محیطی هر سازمان، میزان دسترس‌پذیری دارایی و پیامدهای اختصاصی آن را به‌طور کامل در نظر نمی‌گیرد.

چرا CVSS بالا الزاماً به معنای احتمال حمله بالا نیست؟

ممکن است آسیب‌پذیری از نظر فنی بسیار شدید باشد، اما شواهد محدودی از بهره‌برداری آن وجود داشته باشد.

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

به همین دلیل، اولویت رسیدگی نباید فقط بر اساس CVSS Base Score تعیین شود.

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

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

نقش CISA KEV در اولویت‌بندی آسیب‌پذیری‌ها

علاوه بر CVSS و EPSS، بررسی شواهد بهره‌برداری واقعی اهمیت بسیار زیادی دارد.

فهرست Known Exploited Vulnerabilities یا KEV مجموعه‌ای از آسیب‌پذیری‌هایی است که شواهد معتبری از بهره‌برداری آن‌ها در دنیای واقعی وجود دارد.

این فهرست توسط CISA نگهداری می‌شود.

وجود یک آسیب‌پذیری در KEV می‌تواند نشانه بسیار مهمی برای تصمیم‌گیری درباره فوریت اصلاح باشد.

تفاوت KEV با CVSS

CVSS ویژگی‌های فنی آسیب‌پذیری را ارزیابی می‌کند.

KEV نشان می‌دهد بهره‌برداری واقعی از یک آسیب‌پذیری تأیید شده است.

بنابراین این دو منبع اطلاعات متفاوتی ارائه می‌کنند.

ممکن است آسیب‌پذیری دارای امتیاز CVSS کمتر از ۹ باشد، اما به دلیل بهره‌برداری فعال و حضور در زیرساخت حساس سازمان، به رسیدگی بسیار فوری نیاز داشته باشد.

ترکیب اطلاعات برای اولویت‌بندی

برای تصمیم‌گیری بهتر می‌توان چند پرسش را بررسی کرد:

آیا آسیب‌پذیری واقعاً در دارایی سازمان وجود دارد؟

آیا مؤلفه آسیب‌پذیر از مسیر موردنیاز حمله قابل دسترس است؟

آیا بهره‌برداری واقعی از آن گزارش شده است؟

احتمال تخمینی بهره‌برداری در آینده نزدیک چقدر است؟

در صورت موفقیت حمله، کدام اطلاعات و خدمات سازمان تحت تأثیر قرار می‌گیرند؟

آیا اصلاحیه رسمی یا راهکار کاهش خطر وجود دارد؟

پاسخ این پرسش‌ها به تیم امنیت کمک می‌کند اولویت‌ها را بر اساس شرایط واقعی تعیین کند.

کاربرد CVSS در امنیت وردپرس

وردپرس یکی از شناخته‌شده‌ترین سیستم‌های مدیریت محتوا است و از هسته، افزونه‌ها، قالب‌ها و مؤلفه‌های مختلف تشکیل می‌شود.

ضعف امنیتی ممکن است در هرکدام از این بخش‌ها وجود داشته باشد.

CVSS می‌تواند برای ارزیابی شدت آسیب‌پذیری‌های شناسایی‌شده در اکوسیستم وردپرس استفاده شود.

ارزیابی آسیب‌پذیری افزونه‌های وردپرس

فرض کنید یک افزونه دارای ضعف کنترل دسترسی است.

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

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

سپس باید بررسی شود آسیب‌پذیری چه عملیاتی را امکان‌پذیر می‌کند.

آیا فقط اطلاعات محدودی افشا می‌شود؟

آیا امکان تغییر تنظیمات حساس وجود دارد؟

آیا اطلاعات کاربران دیگر تحت تأثیر قرار می‌گیرند؟

هرکدام از این ویژگی‌ها بر انتخاب معیارهای CVSS اثر می‌گذارند.

ارزیابی آسیب‌پذیری XSS در وردپرس

Cross-Site Scripting یا XSS یکی از دسته‌های شناخته‌شده آسیب‌پذیری وب است.

بااین‌حال، تمام آسیب‌پذیری‌های XSS شدت یکسان ندارند.

برای ارزیابی باید نوع XSS، شرایط فعال شدن، میزان تعامل کاربر و پیامدهای امنیتی قابل اثبات بررسی شوند.

برای مثال، اجرای محتوای ناخواسته در مرورگر کاربر ممکن است در یک سناریو تأثیر محدودی داشته باشد، اما در سناریوی دیگری اطلاعات حساس یا عملکردهای مهم را تحت تأثیر قرار دهد.

به همین دلیل، نمی‌توان صرفاً از روی عنوان XSS یک امتیاز ثابت CVSS تعیین کرد.

ارزیابی ضعف‌های احراز هویت و کنترل دسترسی

ضعف‌های Authentication و Authorization ممکن است باعث دسترسی غیرمجاز کاربران به بخش‌هایی شوند که مجوز استفاده از آن‌ها را ندارند.

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

وجود یک ضعف امنیتی در قابلیت‌های مدیریتی سایت ممکن است پیامدهای جدی‌تری نسبت به یک عملکرد عمومی کم‌اهمیت داشته باشد.

بااین‌حال، شدت نهایی همچنان باید بر اساس معیارهای رسمی محاسبه شود.

CVSS و امنیت ووکامرس

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

برای مثال، یک ضعف کنترل دسترسی ممکن است امکان مشاهده غیرمجاز اطلاعات سفارش را فراهم کند.

در چنین حالتی، تیم امنیت باید میزان اطلاعات قابل دسترسی و پیامدهای فنی آسیب‌پذیری را ارزیابی کند.

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

CVSS به‌تنهایی نمی‌تواند تمام خسارت‌های مالی، اعتباری یا حقوقی احتمالی فروشگاه را محاسبه کند.

کاربرد CVSS در امنیت سرور و شبکه

اهمیت CVSS به وب‌سایت‌ها محدود نمی‌شود.

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

آسیب‌پذیری سرویس‌های شبکه

فرض کنید ضعف امنیتی در یک سرویس شبکه شناسایی شده است.

در ارزیابی اولیه باید بررسی شود آیا بهره‌برداری از راه دور امکان‌پذیر است یا خیر.

سپس مشخص می‌شود مهاجم به چه سطحی از دسترسی نیاز دارد و پیامدهای حمله چیست.

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

آسیب‌پذیری‌های سیستم‌عامل

بعضی از ضعف‌های امنیتی سیستم‌عامل ممکن است به افزایش سطح دسترسی یا Privilege Escalation مرتبط باشند.

در چنین مواردی، مهاجم احتمالاً به سطح مشخصی از دسترسی اولیه نیاز دارد.

بنابراین معیار Privileges Required نقش مهمی در ارزیابی خواهد داشت.

همچنین باید بررسی شود مهاجم پس از بهره‌برداری چه مجوزهای جدیدی به دست می‌آورد.

آسیب‌پذیری در زیرساخت‌های ابری

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

ارزیابی باید میان ویژگی‌های ذاتی ضعف امنیتی و تنظیمات اختصاصی سازمان تمایز قائل شود.

برای مثال، یک تنظیم دفاعی خاص ممکن است شرایط دسترسی به مؤلفه آسیب‌پذیر را محدود کرده باشد.

اما این موضوع نباید به تغییر دلخواه امتیاز پایه منجر شود؛ بلکه باید در بخش مناسب ارزیابی محیطی یا تحلیل ریسک منعکس شود.

آیا CVSS همان میزان ریسک امنیتی است؟

خیر. یکی از رایج‌ترین برداشت‌های اشتباه درباره CVSS، یکسان دانستن شدت آسیب‌پذیری با ریسک واقعی است.

شدت آسیب‌پذیری و ریسک امنیتی به هم مرتبط هستند، اما مفهوم یکسانی ندارند.

CVSS ویژگی‌های فنی و پیامدهای قابل انتظار بهره‌برداری را توصیف می‌کند.

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

مثال تفاوت شدت و ریسک

فرض کنید دو سرور دارای یک آسیب‌پذیری مشابه هستند و هر دو امتیاز پایه یکسانی دریافت کرده‌اند.

سرور اول به یک شبکه آزمایشی محدود تعلق دارد و اطلاعات مهمی در آن نگهداری نمی‌شود.

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

شدت فنی آسیب‌پذیری می‌تواند در هر دو یکسان باشد.

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

این تفاوت باید با بررسی شرایط محیطی و پیامدهای واقعی مشخص شود.

فرمول مفهومی ارزیابی ریسک

در مدیریت ریسک، معمولاً دو عامل اساسی بررسی می‌شوند:

احتمال وقوع یک رویداد نامطلوب و میزان پیامد آن.

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

بنابراین نباید امتیاز CVSS را مستقیماً به‌عنوان احتمال وقوع حمله، درصد خطر یا مقدار خسارت مالی تفسیر کرد.

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

برای مدیریت مؤثر آسیب‌پذیری‌ها، صرفاً مرتب‌کردن مشکلات بر اساس امتیاز CVSS کافی نیست.

یک روش مناسب باید چند مرحله مکمل داشته باشد.

ابتدا وجود آسیب‌پذیری را تأیید کنید

گزارش یک اسکنر به معنای اثبات قطعی آسیب‌پذیر بودن سیستم نیست.

ممکن است ابزار نسخه محصول را اشتباه تشخیص داده باشد یا مؤلفه آسیب‌پذیر در شرایط قابل بهره‌برداری قرار نداشته باشد.

بنابراین باید یافته با اطلاعات محصول، نسخه نصب‌شده و مستندات معتبر تطبیق داده شود.

میزان دسترسی به مؤلفه آسیب‌پذیر را بررسی کنید

وجود یک آسیب‌پذیری در سیستم داخلی و یک سرویس عمومی می‌تواند پیامد عملیاتی متفاوتی داشته باشد.

بررسی مسیرهای دسترسی، محدودیت‌های شبکه و شرایط واقعی استقرار اهمیت دارد.

البته محدودبودن دسترسی خارجی نباید باعث نادیده گرفتن تهدیدهای داخلی شود.

شواهد بهره‌برداری واقعی را در نظر بگیرید

وجود گزارش معتبر از بهره‌برداری فعال می‌تواند فوریت رسیدگی را افزایش دهد.

در چنین شرایطی، بررسی KEV، اطلاعات تهدید و هشدارهای مرتبط با محصول اهمیت پیدا می‌کند.

اهمیت دارایی را مشخص کنید

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

برای مثال، اختلال در سامانه پرداخت ممکن است پیامد عملیاتی متفاوتی نسبت به اختلال در یک محیط توسعه داشته باشد.

امکان اصلاح یا کاهش خطر را بررسی کنید

گاهی وصله امنیتی رسمی در دسترس است و می‌توان آن را پس از آزمون مناسب نصب کرد.

در شرایط دیگر ممکن است اصلاحیه هنوز ارائه نشده باشد.

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

این اقدامات باید متناسب با ماهیت آسیب‌پذیری باشند و اثربخشی آن‌ها ارزیابی شود.

نمونه عملی اولویت‌بندی سه آسیب‌پذیری

فرض کنید تیم امنیت یک سازمان با سه یافته روبه‌رو شده است.

در این مثال، اعداد صرفاً برای توضیح تصمیم‌گیری انتخاب شده‌اند و به CVE مشخصی نسبت داده نمی‌شوند.

در این سناریو، آسیب‌پذیری A از نظر شدت عمومی بحرانی است، اما اگر سازمان واقعاً محصول یا مؤلفه آسیب‌پذیر را نداشته باشد، اصلاح آن در همان محیط موضوعیت ندارد.

آسیب‌پذیری B با وجود امتیاز پایین‌تر از Critical، به دلیل شواهد بهره‌برداری واقعی و حضور در سرویس فعال ممکن است اولویت بالاتری داشته باشد.

آسیب‌پذیری C نیز نباید نادیده گرفته شود؛ اما زمان‌بندی اصلاح آن باید بر اساس شرایط محیطی و ریسک باقی‌مانده تعیین شود.

این مثال نشان می‌دهد که اولویت اصلاح آسیب‌پذیری الزاماً برابر با ترتیب نزولی CVSS Base Score نیست.

نقش ابزارهای اسکن امنیتی در امتیازدهی CVSS

ابزارهای Vulnerability Scanner برای شناسایی نسخه‌های آسیب‌پذیر، تنظیمات ناامن و برخی ضعف‌های امنیتی استفاده می‌شوند.

بسیاری از این ابزارها امتیاز CVSS را در گزارش‌های خود نمایش می‌دهند.

اما باید میان کشف آسیب‌پذیری و امتیازدهی آن تفاوت قائل شد.

آیا اسکنر خودش شدت آسیب‌پذیری را محاسبه می‌کند؟

این موضوع به نوع ابزار و روش پردازش اطلاعات آن بستگی دارد.

بعضی ابزارها امتیازهای منتشرشده در منابع آسیب‌پذیری را دریافت و نمایش می‌دهند.

برخی دیگر ممکن است از قواعد اختصاصی برای تعیین اولویت استفاده کنند.

بنابراین عدد نمایش‌داده‌شده در ابزار الزاماً نتیجه ارزیابی مستقل تمام معیارهای CVSS نیست.

چرا گزارش دو ابزار ممکن است متفاوت باشد؟

تفاوت نتایج می‌تواند ناشی از چند عامل باشد:

• استفاده از نسخه‌های متفاوت CVSS
• تفاوت در زمان به‌روزرسانی داده‌ها
• استفاده از ارزیابی‌های منتشرشده توسط منابع مختلف
• تفاوت در تشخیص نسخه نرم‌افزار
• استفاده از معیارهای اختصاصی برای اولویت‌بندی

برای بررسی دقیق باید امتیاز، نسخه CVSS، بردار و مبنای ارزیابی مقایسه شوند.

آیا نتیجه اسکنر کافی است؟

خیر.

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

تأیید آسیب‌پذیری، ارزیابی دارایی و بررسی کنترل‌های دفاعی باید بخشی از فرایند مدیریت امنیت باشند.

محدودیت‌های استاندارد CVSS

با وجود کاربرد گسترده CVSS، این استاندارد محدودیت‌هایی دارد که در تصمیم‌گیری امنیتی باید شناخته شوند.

۱. CVSS Base احتمال وقوع حمله را پیش‌بینی نمی‌کند

امتیاز پایه نمی‌گوید یک آسیب‌پذیری با چه احتمالی طی روزهای آینده مورد بهره‌برداری قرار خواهد گرفت.

برای بررسی وضعیت تهدید باید از اطلاعات تکمیلی استفاده کرد.

۲. امتیاز عمومی شرایط تمام سازمان‌ها را نشان نمی‌دهد

اهمیت دارایی‌ها، تنظیمات امنیتی و میزان مواجهه در محیط‌های مختلف متفاوت است.

بدون تحلیل محیطی، امتیاز پایه ممکن است برای اولویت‌بندی کافی نباشد.

۳. کیفیت نتیجه به اطلاعات اولیه وابسته است

اگر مقادیر معیارها اشتباه انتخاب شوند، نتیجه محاسبه نیز تصویر دقیقی از شدت آسیب‌پذیری نخواهد داشت.

۴. بعضی پیامدهای تجاری خارج از دامنه امتیاز پایه هستند

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

۵. شدت یک آسیب‌پذیری تمام زنجیره حمله را توصیف نمی‌کند

مهاجم ممکن است برای رسیدن به هدف خود از چند ضعف امنیتی استفاده کند.

امتیاز یک آسیب‌پذیری مشخص، لزوماً پیامد ترکیب آن با سایر ضعف‌ها را نشان نمی‌دهد.

۶. داده‌های آسیب‌پذیری ممکن است کامل نباشند

در برخی موارد، اطلاعات اولیه محدود است یا شرایط بهره‌برداری هنوز به‌خوبی مشخص نشده‌اند.

در نتیجه ممکن است ارزیابی اولیه بعداً نیازمند اصلاح شود.

۷. CVSS جایگزین تصمیم‌گیری سازمانی نیست

حتی یک امتیاز دقیق نیز نمی‌تواند به‌تنهایی تعیین کند سازمان باید کدام سامانه را ابتدا اصلاح کند.

برای این تصمیم باید شدت فنی، اطلاعات تهدید، اهمیت کسب‌وکار و محدودیت‌های عملیاتی در کنار هم بررسی شوند.

اشتباهات رایج هنگام استفاده از CVSS

شناخت خطاهای متداول به جلوگیری از برداشت‌های اشتباه و تصمیم‌گیری نادرست کمک می‌کند.

اشتباه اول: یکسان دانستن CVSS با احتمال هک شدن

امتیاز 9.8 به معنای احتمال ۹۸ درصدی هک شدن نیست.

CVSS در مقیاس صفر تا ۱۰ شدت فنی را بیان می‌کند و نباید به درصد احتمال حمله تبدیل شود.

اشتباه دوم: مقایسه امتیاز نسخه‌های مختلف بدون توجه به تفاوت آن‌ها

CVSS 3.1 و 4.0 از روش‌های محاسباتی متفاوت استفاده می‌کنند.

برای مقایسه صحیح، نسخه استاندارد باید همیشه مشخص باشد.

اشتباه سوم: تعیین امتیاز صرفاً بر اساس نام آسیب‌پذیری

برچسب‌هایی مانند SQL Injection، XSS، CSRF یا RCE برای تعیین امتیاز کافی نیستند.

شرایط بهره‌برداری و پیامدهای واقعی باید ارزیابی شوند.

اشتباه چهارم: نادیده گرفتن اطلاعات تهدید

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

اشتباه پنجم: فرض اینکه وجود WAF آسیب‌پذیری را برطرف کرده است

Web Application Firewall یا WAF ممکن است بعضی مسیرهای حمله را محدود کند.

اما این موضوع به معنای اصلاح کد آسیب‌پذیر نیست.

همچنین نباید صرفاً با فعال‌سازی WAF، امتیاز پایه CVSS را تغییر داد.

اشتباه ششم: استفاده از امتیاز بدون بردار CVSS

دو آسیب‌پذیری ممکن است امتیاز یکسانی داشته باشند، اما ویژگی‌های فنی متفاوتی ایجاد کنند.

بردار CVSS اطلاعات لازم برای درک و بازبینی مبنای امتیازدهی را فراهم می‌کند.

اشتباه هفتم: نادیده گرفتن آسیب‌پذیری‌های متوسط

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

بنابراین شدت متوسط به معنای نبود نیاز به اصلاح نیست.

اشتباه هشتم: انتخاب مقادیر بر اساس حدس

برای مثال، نباید بدون شواهد کافی فرض کرد که بهره‌برداری به دسترسی مدیریتی نیاز دارد یا فقط با تعامل کاربر انجام می‌شود.

هر معیار باید بر اساس اطلاعات قابل دفاع انتخاب شود.

اشتباه نهم: ثابت فرض کردن وضعیت تهدید

حتی اگر ویژگی‌های پایه یک آسیب‌پذیری تغییر نکنند، اطلاعات مرتبط با بهره‌برداری واقعی می‌توانند تغییر کنند.

در نتیجه، فرایند اولویت‌بندی باید امکان بازبینی دوره‌ای داشته باشد.

چک‌لیست ارزیابی و مدیریت آسیب‌پذیری با CVSS

برای استفاده عملی از CVSS در سازمان، می‌توان فرایند زیر را اجرا کرد.

شناسایی دارایی‌ها: فهرست نرم‌افزارها، افزونه‌ها، سرویس‌ها و تجهیزات زیرساختی تهیه و به‌روزرسانی شود.

بررسی نسخه‌های آسیب‌پذیر: مشخص شود محصولات موجود واقعاً در محدوده نسخه‌های تحت تأثیر قرار دارند یا خیر.

تأیید یافته‌های امنیتی: گزارش‌های اسکن با اطلاعات معتبر تطبیق داده شوند و یافته‌های نادرست حذف شوند.

ثبت شناسه‌های مرتبط: در صورت وجود، شناسه CVE و اطلاعات مرتبط با ضعف امنیتی ثبت شوند.

بررسی نسخه CVSS: مشخص شود امتیاز متعلق به نسخه 3.1، 4.0 یا نسخه دیگری است.

مطالعه بردار CVSS: شرایط بهره‌برداری و پیامدهای فنی از روی معیارهای ثبت‌شده بررسی شوند.

بررسی اطلاعات تهدید: داده‌های مرتبط با بهره‌برداری واقعی و احتمال حمله بررسی شوند.

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

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

تعیین اولویت اصلاح: بر اساس شدت، وضعیت تهدید و ریسک محیطی برنامه رسیدگی تهیه شود.

آزمایش اصلاحیه‌ها: وصله‌ها و تغییرات امنیتی پیش از استقرار در محیط عملیاتی حساس، متناسب با شرایط سیستم بررسی شوند.

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

مستندسازی: نتایج، تصمیم‌ها، تاریخ اصلاح و شواهد بررسی نگهداری شوند.

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

بهترین روش استفاده از CVSS در برنامه امنیت سازمان

برای بهره‌برداری مؤثر از CVSS، لازم است امتیازدهی با فرایند مدیریت آسیب‌پذیری سازمان هماهنگ شود.

تعریف مسئولیت‌ها

باید مشخص باشد چه تیمی آسیب‌پذیری‌ها را شناسایی می‌کند، چه افرادی نتایج را تأیید می‌کنند و مسئول اجرای اصلاحات چه کسی است.

نبود مسئول مشخص می‌تواند باعث شود حتی آسیب‌پذیری‌های مهم برای مدت طولانی بدون اقدام باقی بمانند.

تعیین سیاست اولویت‌بندی

سازمان باید سیاستی تدوین کند که در آن شدت CVSS، شواهد بهره‌برداری، اهمیت سرویس و میزان مواجهه در نظر گرفته شوند.

برای مثال، وجود آسیب‌پذیری تأییدشده در یک سرویس حساس که بهره‌برداری فعال از آن گزارش شده است، می‌تواند نیازمند رسیدگی فوری باشد.

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

ایجاد زمان‌بندی اصلاح

تعیین زمان اصلاح یا Remediation SLA به ماهیت سازمان، الزامات قانونی، نوع دارایی و سطح ریسک وابسته است.

برای مثال، یک سازمان ممکن است برای آسیب‌پذیری‌های بحرانی دارای بهره‌برداری فعال، فرایند اضطراری تعریف کند.

اما نباید زمان‌های ثابت اصلاح را به‌عنوان بخشی از استاندارد CVSS معرفی کرد.

CVSS شدت را تعیین می‌کند؛ سیاست زمان‌بندی اصلاح باید جداگانه تدوین شود.

پایش وضعیت اصلاحات

پس از تعیین اولویت، وضعیت هر آسیب‌پذیری باید تا زمان رفع یا پذیرش مستند ریسک پیگیری شود.

مواردی که اصلاح آن‌ها به تعویق افتاده‌اند، باید دارای دلیل مشخص و مسئول پیگیری باشند.

همچنین وجود کنترل جبرانی نباید بدون ارزیابی اثربخشی بهانه‌ای برای کنار گذاشتن اصلاح اصلی شود.

بازبینی مداوم

اطلاعات مربوط به آسیب‌پذیری‌ها، وضعیت تهدید و دارایی‌های سازمان ممکن است تغییر کنند.

بنابراین اولویت‌بندی نباید فقط یک‌بار انجام شود.

پایش مستمر کمک می‌کند تغییر شرایط به‌موقع در تصمیم‌ها منعکس شود.

سؤالات متداول درباره CVSS

CVSS چیست و مخفف چه عبارتی است؟

CVSS مخفف Common Vulnerability Scoring System است. این استاندارد برای توصیف ویژگی‌های فنی و محاسبه شدت آسیب‌پذیری‌های امنیتی استفاده می‌شود و معمولاً امتیازی بین صفر تا ۱۰ ارائه می‌دهد.

بالاترین امتیاز CVSS چقدر است؟

بالاترین امتیاز CVSS برابر 10.0 است. امتیازهای 9.0 تا 10.0 در دسته Critical یا بحرانی قرار می‌گیرند.

آیا CVSS 10 به معنای هک شدن قطعی سیستم است؟

خیر. امتیاز ۱۰ نشان‌دهنده شدت فنی بسیار بالای آسیب‌پذیری است. این عدد نشان نمی‌دهد حمله حتماً رخ داده یا بهره‌برداری از آن برای تمام مهاجمان در همه محیط‌ها امکان‌پذیر است.

تفاوت CVSS 3.1 و CVSS 4.0 چیست؟

نسخه 4.0 معیار Attack Requirements را اضافه کرده، تعامل کاربر را دقیق‌تر کرده، معیار Scope را حذف کرده و پیامدهای سیستم آسیب‌پذیر و سیستم بعدی را جداگانه بررسی می‌کند. همچنین روش محاسبه و گروه‌های معیار تغییر کرده‌اند.

آیا تمام آسیب‌پذیری‌های RCE امتیاز بحرانی دارند؟

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

آیا آسیب‌پذیری با امتیاز Medium باید اصلاح شود؟

بله، در صورت تأثیرپذیری سیستم باید برای آن تصمیم مناسب گرفته شود. شدت متوسط به معنای بی‌خطر بودن نیست و اولویت اصلاح به شرایط سازمان وابسته است.

چه تفاوتی میان CVSS و CVE وجود دارد؟

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

آیا می‌توان CVSS را برای آسیب‌پذیری افزونه‌های وردپرس استفاده کرد؟

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

آیا نصب افزونه امنیتی امتیاز CVSS را کاهش می‌دهد؟

فعال‌سازی افزونه امنیتی به‌خودی‌خود امتیاز پایه CVSS را کاهش نمی‌دهد. کنترل‌های دفاعی مؤثر ممکن است در ارزیابی محیطی و تحلیل ریسک لحاظ شوند، اما برای اصلاح ضعف امنیتی باید علت اصلی آن نیز برطرف شود.

آیا CVSS احتمال سوءاستفاده از آسیب‌پذیری را نشان می‌دهد؟

CVSS Base Score احتمال وقوع بهره‌برداری در یک بازه زمانی مشخص را ارائه نمی‌کند. برای بررسی احتمال تخمینی بهره‌برداری می‌توان از اطلاعاتی مانند EPSS و برای بررسی شواهد حملات واقعی از منابع تهدید استفاده کرد.

آیا CVSS 4.0 جایگزین نسخه 3.1 شده است؟

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

آیا امتیاز CVSS ممکن است تغییر کند؟

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

تفاوت CVSS و EPSS چیست؟

CVSS ویژگی‌ها و شدت فنی آسیب‌پذیری را توصیف می‌کند، درحالی‌که EPSS احتمال تخمینی مشاهده بهره‌برداری از یک آسیب‌پذیری را در ۳۰ روز آینده ارزیابی می‌کند. هیچ‌کدام به‌تنهایی تمام ریسک یک سازمان را مشخص نمی‌کنند.

آیا برای محاسبه CVSS باید فرمول‌ها را حفظ کنیم؟

خیر. شناخت معیارها و انتخاب صحیح مقادیر اهمیت بیشتری دارد. برای محاسبه دقیق می‌توان از محاسبه‌گر رسمی متناسب با نسخه استاندارد استفاده کرد.

آیا CVSS می‌تواند جایگزین تست نفوذ شود؟

خیر. CVSS روشی برای ارزیابی شدت آسیب‌پذیری است، اما تست نفوذ فرایندی برای بررسی امنیت سیستم و شناسایی یا اعتبارسنجی ضعف‌های امنیتی در محدوده مجاز محسوب می‌شود. این دو ابزار اهداف متفاوتی دارند.

جمع‌بندی؛ چرا آشنایی با CVSS برای امنیت سایت ضروری است؟

استاندارد CVSS یکی از مهم‌ترین ابزارهای طبقه‌بندی و ارزیابی شدت آسیب‌پذیری‌های امنیتی محسوب می‌شود.

این چارچوب با بررسی شرایط بهره‌برداری و پیامدهای احتمالی، امکان ارائه یک امتیاز عددی و بردار فنی قابل بررسی را فراهم می‌کند.

شناخت CVSS به کارشناسان امنیت، مدیران سرور، توسعه‌دهندگان و مدیران وب‌سایت کمک می‌کند گزارش‌های امنیتی را بهتر درک کنند و درباره اصلاح آسیب‌پذیری‌ها تصمیم‌های دقیق‌تری بگیرند.

در نسخه CVSS 4.0، معیارهای پایه، تهدید، محیطی و تکمیلی امکان توصیف جامع‌تری از ویژگی‌های آسیب‌پذیری را فراهم می‌کنند.

همچنین تفکیک پیامدهای سیستم آسیب‌پذیر و سیستم بعدی، معرفی Attack Requirements و اصلاح روش محاسبه از مهم‌ترین تغییرات این نسخه هستند.

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

برای اولویت‌بندی مؤثر، لازم است امتیاز CVSS در کنار اطلاعات تهدید، شواهد بهره‌برداری، اهمیت دارایی‌ها، میزان مواجهه و کنترل‌های امنیتی بررسی شود.

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

بهترین راهکار، ایجاد یک فرایند مستمر برای شناسایی آسیب‌پذیری، تأیید یافته‌ها، بررسی شدت، اولویت‌بندی مبتنی بر ریسک، نصب اصلاحیه‌ها و اعتبارسنجی نتایج است.

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

برای حفاظت بهتر از وب‌سایت و زیرساخت، ارزیابی دوره‌ای امنیت و رسیدگی مستند به آسیب‌پذیری‌های شناسایی‌شده را در برنامه نگهداری سیستم قرار دهید.