مقدمه
اگر اخبار امنیت سایبری را دنبال کرده باشید، احتمالاً با شناسه‌هایی مانند CVE-2021-44228 یا CVE-2026-111497 مواجه شده‌اید. این شناسه‌ها معمولاً در گزارش‌های مربوط به باگ‌های امنیتی، انتشار وصله‌های نرم‌افزاری و هشدارهای مربوط به حملات سایبری دیده می‌شوند.
اما CVE دقیقاً چیست؟ آیا هر آسیب‌پذیری دارای یک CVE است؟ آیا وجود یک شناسه CVE به این معناست که سیستم شما هک شده یا حتماً در معرض حمله قرار دارد؟ و چگونه می‌توان فهمید که یک آسیب‌پذیری تا چه اندازه خطرناک است؟
در این مقاله، مفهوم CVE، نحوه نام‌گذاری آسیب‌پذیری‌ها، تفاوت CVE با CVSS، ارتباط آن با پایگاه داده‌های امنیتی و روش استفاده از این اطلاعات برای افزایش امنیت سرورها و وب‌سایت‌ها را بررسی می‌کنیم.
CVE چیست؟
عبارت CVE مخفف Common Vulnerabilities and Exposures است که می‌توان آن را «آسیب‌پذیری‌ها و مواجهه‌های مشترک» ترجمه کرد.
CVE نام یک برنامه بین‌المللی برای شناسایی و ثبت آسیب‌پذیری‌های امنیتی افشاشده در نرم‌افزارها، سخت‌افزارها و سایر محصولات فناوری است. هدف اصلی این برنامه آن است که هر آسیب‌پذیری شناخته‌شده، در صورت تخصیص شناسه، با یک کد مشخص و یکتا قابل ارجاع باشد.
به زبان ساده، CVE مانند یک شماره شناسایی برای یک نقص امنیتی است. این شماره به کارشناسان امنیت، توسعه‌دهندگان، مدیران شبکه و شرکت‌های تولیدکننده نرم‌افزار کمک می‌کند درباره یک آسیب‌پذیری مشخص صحبت کنند، بدون اینکه ابهامی درباره منظورشان وجود داشته باشد.
برای مثال، هنگامی که یک شرکت امنیتی اعلام می‌کند نسخه‌ای از یک نرم‌افزار دارای آسیب‌پذیری CVE-XXXX-XXXXX است، کارشناسان می‌توانند با جست‌وجوی همان شناسه، اطلاعات مرتبط با نقص، محصولات تحت تأثیر، منابع فنی و اصلاحیه‌های احتمالی را بررسی کنند.
فهرست رسمی این شناسه‌ها از طریق وب‌سایت پروژه CVE در دسترس است:
ساختار شناسه CVE چگونه است؟
شناسه‌های CVE از یک قالب مشخص پیروی می‌کنند:
CVE-YYYY-NNNNN
اجزای این شناسه عبارت‌اند از:
- CVE: نشان‌دهنده برنامه شناسه‌گذاری آسیب‌پذیری‌ها.
- YYYY: سال مرتبط با تخصیص شناسه.
- NNNNN: شماره شناسایی آسیب‌پذیری که می‌تواند تعداد رقم‌های بیشتری نیز داشته باشد.
برای مثال، شناسه زیر را در نظر بگیرید:
CVE-2021-44228
این شناسه به آسیب‌پذیری مشهور Log4Shell در کتابخانه Apache Log4j اشاره دارد.
وجود سال ۲۰۲۱ در شناسه به معنای آن نیست که آسیب‌پذیری الزاماً در همان سال کشف شده یا از همان سال مورد سوءاستفاده قرار گرفته است. سال درج‌شده بخشی از ساختار شناسه است و نباید آن را به‌تنهایی معادل تاریخ کشف یا بهره‌برداری دانست.
همچنین، شماره انتهایی CVE نشان‌دهنده شدت آسیب‌پذیری نیست. برای مثال، نمی‌توان نتیجه گرفت که CVE با شماره بزرگ‌تر خطرناک‌تر از CVE با شماره کوچک‌تر است.
چرا به آسیب‌پذیری‌ها شناسه CVE اختصاص داده می‌شود؟
تصور کنید یک آسیب‌پذیری در یک کتابخانه نرم‌افزاری کشف شده باشد که هزاران وب‌سایت و سرور از آن استفاده می‌کنند.
توسعه‌دهنده نرم‌افزار، پژوهشگران امنیتی، شرکت‌های ارائه‌دهنده ابزارهای امنیتی و مدیران سیستم ممکن است هرکدام گزارش جداگانه‌ای درباره همان نقص منتشر کنند. بدون یک شناسه مشترک، تشخیص اینکه این گزارش‌ها به یک آسیب‌پذیری واحد اشاره دارند یا چند آسیب‌پذیری متفاوت، دشوار می‌شود.
CVE این مشکل را کاهش می‌دهد و امکان می‌دهد اطلاعات مربوط به یک آسیب‌پذیری با شناسه مشخصی به یکدیگر ارجاع داده شوند.
مهم‌ترین کاربردهای CVE عبارت‌اند از:
۱. شناسایی دقیق آسیب‌پذیری‌ها: جلوگیری از اشتباه گرفتن گزارش‌های مختلف درباره یک نقص.
۲. مدیریت وصله‌های امنیتی: کمک به مدیران سیستم برای شناسایی اصلاحیه مرتبط با نقص موردنظر.
۳. ارزیابی امنیت محصولات: بررسی اینکه کدام نسخه‌های نرم‌افزار تحت تأثیر یک آسیب‌پذیری قرار دارند.
۴. یکپارچه‌سازی ابزارهای امنیتی: امکان استفاده از شناسه‌های استاندارد در اسکنرهای آسیب‌پذیری، سامانه‌های مدیریت دارایی و فرایندهای پاسخ به رخداد.
۵. اشتراک‌گذاری اطلاعات امنیتی: فراهم کردن زبان مشترک میان پژوهشگران، تولیدکنندگان نرم‌افزار و تیم‌های امنیتی.
آیا هر باگ نرم‌افزاری یک CVE دارد؟
خیر. هر باگ نرم‌افزاری الزاماً یک آسیب‌پذیری امنیتی نیست و هر آسیب‌پذیری نیز لزوماً دارای شناسه CVE منتشرشده نیست.
برای مثال، اگر یک برنامه در شرایط خاص محاسبات ریاضی را اشتباه انجام دهد، ممکن است با یک باگ عملکردی روبه‌رو باشیم. اما اگر یک خطای برنامه‌نویسی امکان دسترسی غیرمجاز به اطلاعات، دور زدن کنترل‌های امنیتی یا اجرای کد مخرب را فراهم کند، احتمالاً با یک مسئله امنیتی مواجه هستیم.
بااین‌حال، مرز میان این دو همیشه ساده نیست. یک باگ ظاهراً معمولی نیز ممکن است در شرایط خاص پیامد امنیتی داشته باشد.
شناسه‌های CVE معمولاً به آسیب‌پذیری‌هایی اختصاص داده می‌شوند که اطلاعات مربوط به آن‌ها به‌صورت عمومی افشا شده است و فرایند تخصیص شناسه را طی می‌کنند. این فرایند توسط نهادهای مجاز موسوم به CNA یا مراجع مسئول در برنامه CVE انجام می‌شود.
بنابراین، نبود یک شناسه CVE به معنای ایمن بودن نرم‌افزار نیست. ممکن است نقص هنوز افشا نشده باشد، در حال بررسی باشد یا هنوز شناسه عمومی دریافت نکرده باشد.
تفاوت CVE و CVSS چیست؟
یکی از رایج‌ترین اشتباهات در اخبار امنیت سایبری، یکسان دانستن CVE و CVSS است. این دو مفهوم به یکدیگر مرتبط‌اند، اما کاربرد متفاوتی دارند.
| ویژگی | CVE | CVSS |
|---|---|---|
| مفهوم | شناسه استاندارد آسیب‌پذیری | چارچوب ارزیابی شدت آسیب‌پذیری |
| کاربرد اصلی | شناسایی و ارجاع به یک نقص | برآورد شدت فنی نقص |
| قالب | مانند CVE-2021-44228 |
امتیاز عددی از ۰ تا ۱۰ |
| آیا خطر را به‌تنهایی مشخص می‌کند؟ | خیر | شدت را ارزیابی می‌کند، نه تمام ریسک سازمانی را |
| نمونه استفاده | جست‌وجوی یک نقص مشخص | اولویت‌بندی اولیه اصلاح آسیب‌پذیری‌ها |
CVSS مخفف Common Vulnerability Scoring System است. این استاندارد توسط FIRST مدیریت می‌شود و برای ارزیابی شدت آسیب‌پذیری‌ها به کار می‌رود.
در CVSS نسخه‌های ۳.۱ و ۴.۰، امتیازها از صفر تا ده هستند. در نسخه ۳.۱، طبقه‌بندی رایج شدت به این صورت است:
- ۰٫۰: بدون شدت (None)
- ۰٫۱ تا ۳٫۹: کم (Low)
- ۴٫۰ تا ۶٫۹: متوسط (Medium)
- ۷٫۰ تا ۸٫۹: زیاد (High)
- ۹٫۰ تا ۱۰: بحرانی (Critical)
در نسخه ۴.۰ نیز طبقه‌بندی شدت مشابه است، اما مرزبندی دقیق آن با نسخه ۳.۱ تفاوت‌هایی دارد. برای تفسیر درست امتیاز باید نسخه CVSS مشخص باشد.
نکته مهم این است که امتیاز CVSS به‌تنهایی تعیین نمی‌کند یک آسیب‌پذیری برای سازمان شما چقدر خطرناک است. میزان دسترسی مهاجم، در دسترس بودن اکسپلویت، قرار گرفتن سامانه در معرض اینترنت و اهمیت دارایی آسیب‌پذیر نیز باید بررسی شوند.
تفاوت CVE، CWE، NVD و KEV چیست؟
در گزارش‌های امنیتی، علاوه بر CVE و CVSS، اصطلاحات دیگری نیز دیده می‌شوند که شناخت آن‌ها برای درک دقیق گزارش‌ها مفید است.
۱. CWE؛ دسته‌بندی ضعف‌های امنیتی
CWE مخفف Common Weakness Enumeration است. این مجموعه، انواع ضعف‌های متداول در طراحی، پیاده‌سازی و توسعه نرم‌افزار را دسته‌بندی می‌کند.
برای مثال، ضعف‌های مربوط به مدیریت نادرست حافظه، اعتبارسنجی ناکافی ورودی‌ها و کنترل دسترسی نامناسب می‌توانند در دسته‌بندی‌های CWE قرار بگیرند.
تفاوت اصلی این است که CWE معمولاً به یک نوع ضعف یا الگوی مشکل اشاره می‌کند، در حالی که CVE شناسه یک آسیب‌پذیری مشخص است.
۲. NVD؛ پایگاه داده ملی آسیب‌پذیری‌ها
NVD مخفف National Vulnerability Database است و توسط مؤسسه ملی استانداردها و فناوری آمریکا (NIST) نگهداری می‌شود.
این پایگاه داده از اطلاعات CVE استفاده می‌کند و در مواردی اطلاعات تکمیلی، از جمله امتیازهای CVSS، محصولات تحت تأثیر و جزئیات فنی مرتبط را ارائه می‌دهد.
آدرس رسمی:
نکته مهم اینکه CVE و NVD یک سامانه واحد نیستند. ثبت یک شناسه در فهرست CVE و تکمیل تحلیل آن در NVD دو فرایند مرتبط اما مجزا هستند. ممکن است جزئیات یک رکورد در NVD هنوز کامل نشده باشد؛ بنابراین، نبود یک امتیاز یا تحلیل تکمیلی را نباید به معنای نبود خطر تلقی کرد.
۳. KEV؛ فهرست آسیب‌پذیری‌های مورد سوءاستفاده واقعی
KEV مخفف Known Exploited Vulnerabilities است. این فهرست توسط آژانس امنیت سایبری و امنیت زیرساخت آمریکا (CISA) منتشر می‌شود و آسیب‌پذیری‌هایی را مشخص می‌کند که شواهدی از سوءاستفاده واقعی از آن‌ها وجود دارد.
آدرس رسمی:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
وجود یک CVE در فهرست KEV علامت مهمی برای اولویت‌بندی اصلاحات است؛ زیرا نشان می‌دهد آسیب‌پذیری صرفاً یک نقص نظری نیست و در عمل مورد سوءاستفاده قرار گرفته است.
البته نبود یک آسیب‌پذیری در این فهرست نیز تضمین نمی‌کند که هیچ مهاجمی از آن سوءاستفاده نمی‌کند.
شدت یک آسیب‌پذیری چگونه تعیین می‌شود؟
هنگامی که یک آسیب‌پذیری امنیتی منتشر می‌شود، ممکن است با برچسب‌هایی مانند Low، Medium، High یا Critical مواجه شوید.
این برچسب‌ها معمولاً بر اساس امتیازدهی استانداردهایی مانند CVSS یا ارزیابی‌های امنیتی ارائه‌دهنده نرم‌افزار تعیین می‌شوند.
در ارزیابی شدت، عواملی مانند موارد زیر اهمیت دارند:
- آیا مهاجم می‌تواند از راه دور به آسیب‌پذیری دسترسی پیدا کند؟
- آیا برای بهره‌برداری به احراز هویت نیاز است؟
- آیا تعامل کاربر قربانی لازم است؟
- آیا بهره‌برداری می‌تواند به اجرای کد منجر شود؟
- آیا اطلاعات محرمانه در معرض افشا قرار می‌گیرند؟
- آیا امکان تغییر داده‌ها یا مختل کردن سرویس وجود دارد؟
برای مثال، یک آسیب‌پذیری اجرای کد از راه دور در نرم‌افزاری که مستقیماً از اینترنت قابل دسترسی است، ممکن است به دلیل پیامدهای احتمالی و سهولت دسترسی مهاجم، اولویت بسیار بالایی داشته باشد.
در مقابل، نقصی که تنها در شرایط محدود و پس از دسترسی‌های خاص قابل بهره‌برداری است، ممکن است اولویت متفاوتی داشته باشد.
این موضوع نشان می‌دهد که بررسی عنوان آسیب‌پذیری و امتیاز آن کافی نیست؛ باید شرایط واقعی محیط نیز در نظر گرفته شود.
آسیب‌پذیری روز صفر (Zero-Day) چه ارتباطی با CVE دارد؟
اصطلاح Zero-Day یا روز صفر به آسیب‌پذیری‌ای اشاره دارد که در زمینه مورد بحث، برای رفع آن هنوز فرصت کافی یا اصلاحیه در دسترس نبوده است. این اصطلاح به‌تنهایی یک شناسه یا سطح شدت استاندارد نیست و کاربرد دقیق آن به وضعیت افشا و اصلاح نقص بستگی دارد.
یک آسیب‌پذیری روز صفر ممکن است بعداً شناسه CVE دریافت کند. همچنین ممکن است یک آسیب‌پذیری دارای CVE باشد، اما هنوز اصلاحیه‌ای برای آن منتشر نشده باشد.
بنابراین، این سه مفهوم را نباید با یکدیگر اشتباه گرفت:
- CVE: شناسه آسیب‌پذیری.
- Zero-Day: توصیف وضعیت آسیب‌پذیری در ارتباط با زمان کشف، افشا یا در دسترس بودن اصلاحیه.
- CVSS: چارچوب ارزیابی شدت آسیب‌پذیری.
همچنین، روز صفر بودن به‌تنهایی به معنای بحرانی بودن نیست؛ شدت و پیامدهای هر نقص باید جداگانه ارزیابی شوند.
چگونه یک CVE را بررسی کنیم؟
اگر شناسه یک آسیب‌پذیری را در خبر امنیتی، گزارش اسکنر یا اطلاعیه تولیدکننده نرم‌افزار مشاهده کردید، مراحل زیر به شما کمک می‌کنند وضعیت آن را بهتر ارزیابی کنید.
مرحله اول: شناسه را در منابع معتبر جست‌وجو کنید
از وب‌سایت رسمی CVE یا پایگاه داده NVD استفاده کنید:
- فهرست رسمی CVE: https://www.cve.org/
- پایگاه داده NVD: https://nvd.nist.gov/
با جست‌وجوی شناسه می‌توانید توضیحات اولیه و پیوندهای مربوط به منابع فنی را پیدا کنید.
مرحله دوم: محصولات و نسخه‌های آسیب‌پذیر را شناسایی کنید
مهم‌ترین سؤال این است که آیا محصول مورد استفاده شما تحت تأثیر قرار گرفته است یا خیر.
نام نرم‌افزار به‌تنهایی کافی نیست. باید نسخه دقیق، شاخه نرم‌افزار، نوع بسته، سیستم‌عامل و شرایط ذکرشده در اطلاعیه را بررسی کنید.
برای مثال، ممکن است یک نقص تنها در نسخه‌های خاصی از یک کتابخانه وجود داشته باشد یا تنها در صورت فعال بودن یک قابلیت مشخص قابل بهره‌برداری باشد.
مرحله سوم: وضعیت اصلاحیه را بررسی کنید
اطلاعیه رسمی سازنده را مطالعه کنید تا مشخص شود:
- آیا نسخه اصلاح‌شده منتشر شده است؟
- کدام نسخه‌ها تحت تأثیر قرار دارند؟
- آیا راهکار موقت وجود دارد؟
- آیا پس از نصب اصلاحیه، اقدام دیگری لازم است؟
در صورت وجود وصله رسمی، معمولاً به‌روزرسانی به نسخه اصلاح‌شده بهترین راهکار است.
مرحله چهارم: شدت و احتمال بهره‌برداری را ارزیابی کنید
امتیاز CVSS را در کنار وضعیت واقعی بهره‌برداری بررسی کنید. وجود شواهد سوءاستفاده واقعی، انتشار کد اکسپلویت، قرار گرفتن آسیب‌پذیری در فهرست KEV و دسترسی اینترنتی سامانه می‌توانند در اولویت‌بندی مؤثر باشند.
مرحله پنجم: وضعیت محیط خود را بررسی کنید
پس از شناسایی نسخه‌های آسیب‌پذیر، مشخص کنید که آیا دارایی موردنظر واقعاً در زیرساخت شما وجود دارد یا خیر.
برای این کار، فهرست نرم‌افزارها، بسته‌ها، افزونه‌ها، کتابخانه‌ها، نسخه‌های سیستم‌عامل و سرویس‌های در معرض اینترنت را بررسی کنید.
پس از نصب اصلاحیه نیز مطمئن شوید که به‌روزرسانی واقعاً اعمال شده، سرویس‌های لازم راه‌اندازی مجدد شده‌اند و نسخه فعال نرم‌افزار با نسخه اصلاح‌شده مطابقت دارد.
آیا وجود CVE به معنای هک شدن سیستم است؟
خیر. این یکی از مهم‌ترین نکاتی است که باید درک شود.
وجود یک آسیب‌پذیری در نرم‌افزار نصب‌شده به معنای آن است که شرایطی برای ایجاد مشکل امنیتی وجود دارد؛ اما به‌تنهایی اثبات نمی‌کند که مهاجمی از آن استفاده کرده یا سیستم شما را به خطر انداخته است.
برای ارزیابی احتمال وقوع حمله، باید موارد زیر را بررسی کنید:
۱. آیا نسخه آسیب‌پذیر واقعاً روی سیستم نصب شده است؟
۲. آیا قابلیت یا مؤلفه آسیب‌پذیر فعال است؟
۳. آیا مهاجم می‌تواند به مسیر آسیب‌پذیر دسترسی پیدا کند؟
۴. آیا اکسپلویت عملی و قابل استفاده‌ای وجود دارد؟
۵. آیا نشانه‌ای از فعالیت مشکوک، دسترسی غیرمجاز یا اجرای کد مشاهده می‌شود؟
به همین دلیل، مدیریت آسیب‌پذیری و بررسی رخدادهای امنیتی دو فرایند مرتبط اما متفاوت هستند. نصب وصله می‌تواند نقص را برطرف کند، اما اگر احتمال بهره‌برداری قبلی وجود داشته باشد، بررسی لاگ‌ها و شواهد امنیتی نیز ضروری است.
چرا مدیران سرور باید اخبار CVE را دنبال کنند؟
در زیرساخت‌های سازمانی، یک آسیب‌پذیری در نرم‌افزارهای پرکاربرد ممکن است چندین سرویس و سامانه را به‌طور هم‌زمان تحت تأثیر قرار دهد.
برای مثال، یک کتابخانه آسیب‌پذیر ممکن است در چندین برنامه وب، سرویس داخلی یا ابزار مدیریتی مورد استفاده قرار گرفته باشد. در چنین شرایطی، به‌روزرسانی تنها یک برنامه لزوماً تمام ریسک را برطرف نمی‌کند.
مدیران فناوری اطلاعات بهتر است فرایند مشخصی برای مدیریت آسیب‌پذیری داشته باشند که شامل این موارد باشد:
- تهیه فهرست به‌روز از دارایی‌ها و نرم‌افزارهای سازمان.
- دریافت هشدارهای امنیتی از منابع معتبر.
- تطبیق آسیب‌پذیری‌ها با نسخه‌های نصب‌شده.
- اولویت‌بندی بر اساس شدت، احتمال بهره‌برداری و اهمیت دارایی.
- نصب وصله‌ها در چارچوب مدیریت تغییرات.
- بررسی نتیجه اصلاح و ثبت سوابق.
- پیگیری سامانه‌هایی که به دلیل محدودیت فنی امکان به‌روزرسانی فوری ندارند.
هدف این فرایند، واکنش سریع اما کنترل‌شده به آسیب‌پذیری‌هاست؛ نه نصب بدون بررسی هر به‌روزرسانی یا اتکا به یک عدد در گزارش امنیتی.
جمع‌بندی
CVE یکی از مفاهیم پایه در امنیت سایبری است که به شناسایی استاندارد آسیب‌پذیری‌های افشاشده کمک می‌کند. بااین‌حال، برای استفاده صحیح از اطلاعات امنیتی باید تفاوت آن با CVSS، CWE، NVD و KEV را بدانیم.
یک شناسه CVE به‌تنهایی نشان‌دهنده شدت آسیب‌پذیری، امکان بهره‌برداری در تمام محیط‌ها یا وقوع یک حمله موفق نیست. ارزیابی دقیق به بررسی نسخه‌های آسیب‌پذیر، شرایط بهره‌برداری، وضعیت اصلاحیه و میزان مواجهه واقعی سامانه نیاز دارد.
برای کاربران عادی، آشنایی با CVE به درک بهتر هشدارهای امنیتی و اهمیت به‌روزرسانی نرم‌افزارها کمک می‌کند. برای مدیران سرور، توسعه‌دهندگان و متخصصان امنیت نیز این شناسه‌ها بخشی مهم از فرایند شناسایی، اولویت‌بندی و رفع آسیب‌پذیری‌ها هستند.
قاعده کاربردی: وقتی با یک CVE مواجه می‌شوید، تنها به شماره یا امتیاز شدت آن اکتفا نکنید؛ بررسی کنید کدام نسخه‌ها آسیب‌پذیرند، آیا محیط شما تحت تأثیر است، چه اصلاحیه‌ای منتشر شده و آیا نشانه‌ای از بهره‌برداری واقعی وجود دارد.
منابع معتبر برای مطالعه بیشتر
۱. پروژه رسمی CVE: https://www.cve.org/
۲. پایگاه داده ملی آسیب‌پذیری‌ها (NVD): https://nvd.nist.gov/
۳. راهنمای رسمی CVSS از FIRST: https://www.first.org/cvss/
۴. فهرست آسیب‌پذیری‌های مورد سوءاستفاده واقعی CISA (KEV): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
۵. مجموعه ضعف‌های امنیتی CWE: https://cwe.mitre.org/
این مقاله با هدف آموزش مفاهیم پایه مدیریت آسیب‌پذیری تهیه شده است. برای تصمیم‌گیری عملیاتی، اطلاعیه رسمی سازنده محصول و جزئیات نسخه‌های تحت تأثیر را بررسی کنید.
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.