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

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

مقدمه؛ چرا شناخت CVE برای امنیت سایبری ضروری است؟

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

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

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

شناسه CVE برای پاسخ به همین نیاز شکل گرفته است.

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

اما وجود یک شناسه استاندارد مانند CVE-2021-44228 باعث می‌شود تمام طرف‌ها بتوانند درباره یک آسیب‌پذیری مشخص صحبت کنند.

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

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

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

CVE چیست و چه کاربردی دارد؟

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

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

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

تعریف دقیق CVE

عبارت Common Vulnerabilities and Exposures از سه مفهوم اصلی تشکیل شده است:

• Common: ایجاد روشی مشترک و استاندارد برای اشاره به مشکلات امنیتی.
• Vulnerabilities: آسیب‌پذیری‌هایی که ممکن است امنیت یک محصول یا سامانه را تحت تأثیر قرار دهند.
• Exposures: اصطلاحی مرتبط با وضعیت‌هایی که می‌توانند شرایط مواجهه امنیتی نامطلوب ایجاد کنند.

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

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

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

مهم‌ترین اهداف CVE

مهم‌ترین کاربردهای این نظام عبارت‌اند از:

1. ایجاد شناسه استاندارد برای آسیب‌پذیری‌های امنیتی.
2. جلوگیری از سردرگمی ناشی از نام‌گذاری‌های متفاوت.
3. تسهیل تبادل اطلاعات میان پژوهشگران و تولیدکنندگان.
4. کمک به هماهنگی اطلاعیه‌های امنیتی و به‌روزرسانی‌ها.
5. امکان ارتباط میان ابزارهای مدیریت آسیب‌پذیری.
6. تسهیل گزارش‌نویسی و پیگیری مشکلات امنیتی.
7. کمک به شناسایی محصولات و نسخه‌های در معرض خطر.
8. فراهم‌کردن پایه‌ای مشترک برای ارزیابی و اولویت‌بندی اصلاحات.

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

تاریخچه CVE و سازمان‌های مسئول مدیریت آن

با گسترش اینترنت و افزایش تعداد نرم‌افزارها در دهه ۱۹۹۰، گزارش‌های امنیتی به‌سرعت افزایش یافتند.

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

برنامه CVE در سال ۱۹۹۹ برای ایجاد یک نظام نام‌گذاری مشترک معرفی شد.

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

CVE Program چیست؟

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

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

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

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

CNA چه نقشی در ثبت CVE دارد؟

CNA مخفف CVE Numbering Authority است.

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

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

وظایف معمول یک CNA شامل موارد زیر است:

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

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

ساختار شناسه CVE چگونه است؟

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

شناسه‌ها معمولاً از سه بخش تشکیل می‌شوند:

CVE-YYYY-NNNN

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

برای نمونه:

CVE-2021-44228

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

بخش اول؛ پیشوند CVE

پیشوند CVE نشان می‌دهد شماره موردنظر متعلق به نظام استاندارد شناسه‌گذاری آسیب‌پذیری‌هاست.

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

بخش دوم؛ سال شناسه

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

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

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

همچنین ممکن است شناسه در سالی رزرو شود و جزئیات آن در سال بعد انتشار پیدا کند.

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

بخش سوم؛ شماره اختصاصی آسیب‌پذیری

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

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

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

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

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

آیا هر CVE فقط یک آسیب‌پذیری را مشخص می‌کند؟

هدف نظام CVE این است که یک شناسه به یک آسیب‌پذیری مشخص اشاره کند.

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

ممکن است یک نقص مشترک در چند نسخه یا چند محصول وابسته وجود داشته باشد و همچنان تحت یک شناسه ثبت شود.

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

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

چرخه حیات CVE؛ از کشف آسیب‌پذیری تا انتشار اطلاعات

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

مرحله اول؛ کشف یا دریافت گزارش آسیب‌پذیری

فرایند ممکن است با شناسایی یک نقص توسط پژوهشگر، تیم داخلی توسعه، شرکت امنیتی یا گزارش کاربر آغاز شود.

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

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

به همین دلیل، کشف یک رفتار غیرعادی در نرم‌افزار لزوماً به معنای ثبت فوری CVE نیست.

مرحله دوم؛ بررسی و هماهنگی با مسئول محصول

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

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

این فرایند می‌تواند بخشی از سیاست افشای هماهنگ آسیب‌پذیری یا Coordinated Vulnerability Disclosure باشد.

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

مرحله سوم؛ رزرو شناسه CVE

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

وضعیت RESERVED به این معنی است که شماره اختصاص یافته، اما رکورد عمومی آن هنوز منتشر نشده است.

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

مرحله چهارم؛ انتشار رکورد

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

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

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

مرحله پنجم؛ تکمیل و اصلاح اطلاعات

انتشار CVE پایان فرایند بررسی نیست.

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

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

مرحله ششم؛ ردشدن شناسه در صورت لزوم

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

در چنین شرایطی ممکن است وضعیت آن به REJECTED تغییر کند.

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

اطلاعات موجود در یک رکورد CVE شامل چه مواردی است؟

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

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

شناسه و وضعیت رکورد

اولین بخش، CVE ID و وضعیت آن است.

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

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

توضیح آسیب‌پذیری

بخش Description ماهیت مشکل را توضیح می‌دهد.

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

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

در چنین شرایطی باید به اطلاعیه تولیدکننده و منابع تکمیلی مراجعه کرد.

محصولات و نسخه‌های تحت تأثیر

بخش Affected یکی از مهم‌ترین قسمت‌های رکورد است.

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

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

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

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

نوع ضعف امنیتی

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

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

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

شاخص‌های شدت خطر

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

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

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

منابع و راهکارهای اصلاح

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

برای مدیران سیستم، مراجعه به اطلاعیه رسمی تولیدکننده معمولاً یکی از مهم‌ترین اقدامات است؛ زیرا امکان دارد جزئیات دقیق نسخه اصلاح‌شده در آن ثبت شده باشد.

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

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

این مفاهیم ارتباط نزدیکی دارند، اما وظیفه آنها یکسان نیست.

تفاوت CVE و CVSS

CVE مشخص می‌کند درباره کدام آسیب‌پذیری صحبت می‌کنیم.

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

برای مثال، یک CVE می‌تواند امتیاز CVSS معادل ۹٫۸ داشته باشد.

در این مثال، CVE شناسه نقص است و عدد ۹٫۸ میزان شدت آن بر اساس نسخه و معیارهای مشخص CVSS را نشان می‌دهد.

بنابراین عبارت «امتیاز CVE برابر ۹٫۸ است» از نظر اصطلاح‌شناسی دقیق نیست. بهتر است گفته شود «امتیاز CVSS این آسیب‌پذیری ۹٫۸ است».

تفاوت CVE و CWE

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

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

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

از نگاه توسعه‌دهنده، CWE برای شناخت الگوهای اشتباه برنامه‌نویسی مفید است و CVE برای پیگیری نمونه‌های واقعی آن ضعف.

تفاوت CVE و NVD

CVE Program وظیفه مدیریت نظام شناسه‌ها و رکوردهای CVE را بر عهده دارد.

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

بنابراین NVD و CVE Program دو سامانه مستقل با نقش‌های مکمل هستند.

نکته مهم این است که ممکن است یک CVE منتشر شده باشد، اما بعضی اطلاعات تکمیلی آن هنوز در NVD آماده نشده باشند.

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

سیستم امتیازدهی CVSS چگونه کار می‌کند؟

CVSS یکی از مهم‌ترین ابزارهای مکمل CVE محسوب می‌شود.

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

نسخه‌های مختلف CVSS در رکوردهای امنیتی مشاهده می‌شوند. نسخه ۴٫۰ این استاندارد مدل تفصیلی‌تری برای توصیف ویژگی‌های فنی، شرایط تهدید و محیط عملیاتی ارائه می‌کند.

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

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

چه عواملی در CVSS بررسی می‌شوند؟

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

• Attack Vector: مسیر یا بستر لازم برای بهره‌برداری از آسیب‌پذیری.
• Attack Complexity: میزان پیچیدگی شرایط لازم برای سوءاستفاده.
• Privileges Required: سطح دسترسی موردنیاز مهاجم.
• User Interaction: نیاز یا عدم نیاز به تعامل کاربر.
• Confidentiality Impact: اثر بر محرمانگی اطلاعات.
• Integrity Impact: اثر بر صحت و یکپارچگی داده‌ها.
• Availability Impact: اثر بر دسترس‌پذیری خدمات.

در CVSS نسخه ۴، معیارهای دیگری مانند Attack Requirements نیز اهمیت دارند و تأثیر بر سامانه آسیب‌پذیر و سامانه‌های بعدی با جزئیات بیشتری تفکیک می‌شود.

چرا CVSS بالا همیشه به معنای خطر بیشتر نیست؟

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

آسیب‌پذیری اول امتیاز ۹٫۸ دارد، اما در یک سامانه آزمایشگاهی کاملاً جدا از شبکه عملیاتی وجود دارد.

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

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

دلیل این موضوع تفاوت میان شدت فنی و ریسک واقعی است.

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

چرا وجود CVE به معنای هک‌شدن سیستم نیست؟

یکی از برداشت‌های اشتباه کاربران این است که اگر برای نرم‌افزار نصب‌شده CVE منتشر شود، حتماً سیستم آنها هک شده است.

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

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

از جمله:

• آیا نسخه آسیب‌پذیر واقعاً نصب شده است؟
• آیا ویژگی یا مؤلفه آسیب‌پذیر فعال است؟
• آیا مسیر دسترسی لازم به آن وجود دارد؟
• آیا کنترل‌های محافظتی مؤثر هستند؟
• آیا شواهدی از تلاش برای سوءاستفاده مشاهده شده است؟
• آیا نشانه‌ای از دسترسی یا تغییر غیرمجاز وجود دارد؟

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

از طرف دیگر، نبود شناسه CVE نیز اثبات نمی‌کند که یک سیستم امن است.

بسیاری از نقص‌ها ممکن است هنوز کشف، تأیید یا منتشر نشده باشند.

چگونه یک شناسه CVE را جست‌وجو کنیم؟

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

مرحله اول؛ شناسه دقیق را پیدا کنید

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

ابتدا شناسه را دقیق ثبت کنید.

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

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

مرحله دوم؛ وارد پایگاه رسمی CVE شوید

نشانی اصلی برنامه CVE عبارت است از:

https://www.cve.org/

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

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

اگر رکورد در وضعیت RESERVED باشد، ممکن است جزئیات عمومی کافی در دسترس نباشند.

مرحله سوم؛ اطلاعات NVD را بررسی کنید

نشانی پایگاه داده NVD:

https://nvd.nist.gov/

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

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

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

مرحله چهارم؛ نسخه آسیب‌پذیر را شناسایی کنید

این مرحله از مهم‌ترین بخش‌های بررسی است.

صرف مشاهده نام یک نرم‌افزار در گزارش CVE کافی نیست.

باید مشخص شود:

• کدام محصول دقیقاً تحت تأثیر است؟
• چه نسخه‌هایی آسیب‌پذیر هستند؟
• مشکل به کدام مؤلفه مربوط می‌شود؟
• آیا پیکربندی خاصی برای تأثیرپذیری لازم است؟
• نسخه اصلاح‌شده کدام است؟

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

مرحله پنجم؛ اطلاعیه تولیدکننده را بخوانید

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

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

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

مرحله ششم؛ وضعیت واقعی سامانه خود را بررسی کنید

در آخر، باید اطلاعات عمومی CVE با وضعیت دارایی‌های واقعی مقایسه شود.

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

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

نمونه واقعی CVE؛ آسیب‌پذیری Log4Shell

یکی از نمونه‌های شناخته‌شده برای درک اهمیت CVE، شناسه CVE-2021-44228 است.

این شناسه با آسیب‌پذیری مشهور Log4Shell در کتابخانه Apache Log4j 2 ارتباط دارد.

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

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

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

یکی از دلایل مهم، گستردگی استفاده از Log4j در نرم‌افزارهای مختلف بود.

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

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

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

CVE چه کمکی به مدیریت این حادثه کرد؟

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

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

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

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

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

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

بنابراین استفاده از CVE باید در کنار مدیریت وابستگی‌ها، ثبت فهرست مؤلفه‌های نرم‌افزاری و به‌روزرسانی منظم انجام شود.

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

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

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

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

بررسی آسیب‌پذیری هسته وردپرس

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

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

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

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

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

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

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

Stored Cross-Site Scripting یا XSS ذخیره‌شده، نوعی آسیب‌پذیری است که در شرایط خاص می‌تواند باعث اجرای محتوای اسکریپتی ناخواسته در مرورگر کاربران شود.

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

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

بررسی آسیب‌پذیری قالب‌ها

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

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

مدیر سایت باید قالب فعال، قالب فرزند و قالب‌های غیرفعال باقی‌مانده روی سرور را در فهرست دارایی‌های خود در نظر بگیرد.

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

آیا تمام آسیب‌پذیری‌های وردپرس CVE دارند؟

خیر.

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

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

در نتیجه، اتکا به CVE به‌تنهایی برای مدیریت کامل امنیت وردپرس کافی نیست.

CVE در امنیت ووکامرس و فروشگاه‌های اینترنتی

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

به همین دلیل، تأثیر یک نقص امنیتی می‌تواند از اختلال ساده در نمایش سایت فراتر برود.

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

کدام مؤلفه‌ها باید بررسی شوند؟

• خود WooCommerce و نسخه نصب‌شده آن.
• افزونه‌های درگاه پرداخت.
• افزونه‌های مدیریت سفارش و فاکتور.
• افزونه‌های تخفیف و باشگاه مشتریان.
• سیستم‌های اتصال به انبار یا حسابداری.
• افزونه‌های ورود و ثبت‌نام کاربران.
• سرویس‌های متصل به API فروشگاه.

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

اهمیت کنترل دسترسی در فروشگاه

آسیب‌پذیری‌های مرتبط با Broken Access Control یا کنترل دسترسی ناقص می‌توانند برای فروشگاه‌ها خطرناک باشند.

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

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

اقدامات دفاعی پیشنهادی

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

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

برای تغییرات حساس، آزمون سازگاری در محیط Staging انجام دهید.

دسترسی مدیران را محدود و احراز هویت دومرحله‌ای یا 2FA را فعال کنید.

لاگ‌های امنیتی و تغییرات غیرمنتظره را بررسی کنید و مؤلفه‌های غیرضروری را حذف کنید.

ارتباط CVE با امنیت سرور و سیستم‌عامل

مدیریت CVE فقط مخصوص وب‌سایت‌ها نیست.

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

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

بررسی CVE در سرور لینوکسی

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

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

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

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

بررسی وب‌سرور و پایگاه داده

نرم‌افزارهایی مانند Apache HTTP Server، Nginx، MySQL و PostgreSQL ممکن است دارای اطلاعیه‌های امنیتی باشند.

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

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

اهمیت سرویس‌های در معرض اینترنت

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

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

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

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

چگونه خطر واقعی یک CVE را ارزیابی کنیم؟

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

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

اول؛ میزان تأثیرپذیری دارایی

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

اگر محصول وجود ندارد، معمولاً اقدام اصلاحی مستقیم برای آن دارایی لازم نیست.

اگر وجود دارد، باید نسخه و پیکربندی آن بررسی شود.

دوم؛ دسترسی‌پذیری مسیر آسیب‌پذیر

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

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

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

سوم؛ اهمیت دارایی

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

اهمیت تجاری، محرمانگی داده‌ها، تداوم خدمات و وابستگی سایر سامانه‌ها باید در نظر گرفته شوند.

چهارم؛ شواهد سوءاستفاده فعال

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

در چنین شرایطی نباید فقط به امتیاز CVSS تکیه کرد.

پنجم؛ کنترل‌های امنیتی موجود

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

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

ششم؛ قابلیت اصلاح

باید مشخص شود نسخه اصلاحی وجود دارد یا خیر.

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

تفاوت CVE، EPSS و KEV در اولویت‌بندی آسیب‌پذیری‌ها

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

دو مفهوم مهم دیگر، EPSS و KEV هستند.

EPSS چیست؟

EPSS مخفف Exploit Prediction Scoring System است.

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

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

برای مثال، مقدار فرضی ۰٫۳۰ به معنی برآورد احتمال ۳۰ درصدی مشاهده سوءاستفاده در افق ۳۰روزه مدل است.

این مقدار به معنی احتمال ۳۰ درصدی هک‌شدن سایت مشخص شما نیست.

EPSS شرایط اختصاصی زیرساخت، ارزش دارایی و تأثیر کسب‌وکاری را به‌طور کامل در نظر نمی‌گیرد.

KEV چیست؟

KEV مخفف Known Exploited Vulnerabilities است.

فهرست KEV توسط CISA برای ثبت آسیب‌پذیری‌هایی استفاده می‌شود که شواهد معتبر از سوءاستفاده واقعی از آنها وجود دارد.

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

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

چگونه این شاخص‌ها را کنار هم استفاده کنیم؟

برای تحلیل بهتر می‌توان از این چارچوب استفاده کرد:

• CVE مشخص می‌کند آسیب‌پذیری کدام است.
• CVSS شدت فنی آن را توصیف می‌کند.
• EPSS احتمال سوءاستفاده در بازه زمانی مشخص را تخمین می‌زند.
• KEV شواهد شناخته‌شده سوءاستفاده واقعی را نشان می‌دهد.
• اطلاعات محیط سازمان مشخص می‌کند مشکل تا چه اندازه برای دارایی‌های شما اهمیت دارد.

ترکیب این داده‌ها نسبت به رتبه‌بندی صرفاً براساس امتیاز CVSS تصمیم دقیق‌تری ایجاد می‌کند.

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

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

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

در چنین شرایطی باید اولویت اصلاح بر اساس ریسک تعیین شود.

مثال فرضی اول؛ آسیب‌پذیری بحرانی در سامانه جداشده

یک محصول داخلی دارای امتیاز CVSS بالا است.

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

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

مثال فرضی دوم؛ آسیب‌پذیری با شدت بالا در سرویس عمومی

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

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

نمونه جدول اولویت‌بندی

این جدول یک الگوی آموزشی است و جایگزین سیاست رسمی مدیریت ریسک سازمان نمی‌شود.

راهنمای عملی مدیریت CVE در هفت مرحله

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

مرحله اول؛ فهرست دارایی‌ها را تهیه کنید

تا زمانی که ندانید چه نرم‌افزارها و سرویس‌هایی دارید، نمی‌توانید تأثیر CVEها را به‌درستی مشخص کنید.

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

در سایت وردپرسی، افزونه‌ها و قالب‌ها نیز باید ثبت شوند.

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

مرحله دوم؛ اطلاعات آسیب‌پذیری را جمع‌آوری کنید

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

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

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

مرحله سوم؛ ارتباط CVE با دارایی را تأیید کنید

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

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

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

نتیجه بررسی باید مستند شود.

مرحله چهارم؛ ریسک را ارزیابی کنید

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

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

مرحله پنجم؛ راهکار اصلاح را انتخاب کنید

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

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

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

مرحله ششم؛ اصلاح را اعتبارسنجی کنید

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

بررسی وضعیت سرویس و آزمون عملکرد نیز ضروری است.

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

مرحله هفتم؛ نتیجه را ثبت و پایش را ادامه دهید

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

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

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

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

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

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

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

ابزارهایی مانند Nessus، OpenVAS و Greenbone در محیط‌های مجاز برای شناسایی مشکلات امنیتی به کار می‌روند.

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

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

در محیط عملیاتی نیز باید اثر احتمالی اسکن بر عملکرد خدمات بررسی شود.

ابزارهای تحلیل وابستگی

در توسعه نرم‌افزار، ابزارهای Software Composition Analysis یا SCA برای بررسی کتابخانه‌ها و وابستگی‌های استفاده‌شده کاربرد دارند.

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

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

استفاده از SBOM

SBOM مخفف Software Bill of Materials است.

SBOM فهرستی ساختاریافته از مؤلفه‌های نرم‌افزاری و وابستگی‌های آنها ارائه می‌کند.

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

برای مثال، در صورت انتشار CVE جدید برای یک مؤلفه پرکاربرد، وجود SBOM دقیق می‌تواند فرایند شناسایی سامانه‌های احتمالی تحت تأثیر را ساده‌تر کند.

ابزارهای مدیریت وصله

سامانه‌های Patch Management به برنامه‌ریزی، نصب و پیگیری به‌روزرسانی‌ها کمک می‌کنند.

ارتباط میان داده‌های CVE و وضعیت وصله‌ها باعث می‌شود تیم امنیت بتواند موارد اصلاح‌نشده را بهتر پیگیری کند.

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

استفاده از API برای دریافت اطلاعات CVE

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

به همین دلیل، بعضی پایگاه‌های داده رابط برنامه‌نویسی یا API ارائه می‌کنند.

API امکان دریافت ساختاریافته اطلاعات را برای سامانه‌های داخلی فراهم می‌کند.

API پایگاه NVD

پایگاه NVD دارای API برای جست‌وجو و دریافت اطلاعات آسیب‌پذیری‌هاست.

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

پیش از پیاده‌سازی باید مستندات رسمی API، محدودیت نرخ درخواست و تغییرات نسخه‌های آن بررسی شود.

کاربرد API در مدیریت امنیت

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

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

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

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

محدودیت‌های پردازش خودکار

اتصال API به معنی تشخیص قطعی آسیب‌پذیری نیست.

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

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

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

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

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

در چنین شرایطی ممکن است درخواست CVE مطرح شود.

ابتدا مشکل باید اعتبارسنجی شود

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

خطاهای معمول نرم‌افزاری، مشکلات ظاهری یا رفتارهای غیرمنتظره لزوماً واجد شرایط دریافت CVE نیستند.

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

ارتباط با تولیدکننده محصول

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

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

رعایت سیاست افشای مسئولانه و حفظ محرمانگی اطلاعات حساس در این مرحله اهمیت زیادی دارد.

بررسی وجود شناسه قبلی

پیش از درخواست باید بررسی شود آیا مشکل قبلاً ثبت شده است یا خیر.

گاهی یک نقص امنیتی توسط چند پژوهشگر مستقل شناسایی می‌شود.

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

ثبت درخواست از مسیر مناسب

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

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

همچنین دریافت CVE به‌تنهایی به معنی اثبات کیفیت پژوهش، تأیید همه ادعاها یا دریافت پاداش کشف آسیب‌پذیری نیست.

ارتباط CVE با مدیریت وصله‌های امنیتی

یکی از مهم‌ترین کاربردهای CVE، کمک به برنامه‌ریزی Patch Management است.

وصله امنیتی یا Security Patch تغییری است که برای برطرف‌کردن یا کاهش یک مشکل امنیتی در نرم‌افزار منتشر می‌شود.

چرا نصب به‌روزرسانی باید برنامه‌ریزی شود؟

نصب وصله ممکن است روی سازگاری افزونه‌ها، عملکرد سرویس یا وابستگی‌های نرم‌افزاری تأثیر بگذارد.

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

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

فرایند پیشنهادی اصلاح آسیب‌پذیری

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

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

پس از تهیه نسخه پشتیبان، تغییر در محیط مناسب آزمایش می‌شود.

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

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

اگر وصله امنیتی موجود نباشد چه کنیم؟

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

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

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

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

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

نقش CVE در تست امنیت و ارزیابی نفوذپذیری

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

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

استفاده از CVE در گزارش امنیتی

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

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

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

تفاوت یافته CVE با آسیب‌پذیری تأییدشده

گاهی اسکنر فقط بر اساس شماره نسخه هشدار می‌دهد.

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

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

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

بنابراین نتیجه ابزار باید اعتبارسنجی شود.

آیا برای انجام تست امنیت باید CVE داشته باشیم؟

خیر.

وجود شناسه CVE شرط لازم برای شناسایی یا گزارش یک ضعف امنیتی نیست.

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

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

CVE و آسیب‌پذیری روز صفر چه ارتباطی دارند؟

اصطلاح Zero-Day یا آسیب‌پذیری روز صفر معمولاً برای نقصی به کار می‌رود که هنوز فرصت مؤثر و کافی برای آماده‌سازی یا استقرار اصلاحیه آن وجود نداشته است؛ این اصطلاح به‌ویژه در زمینه سوءاستفاده پیش از دسترس‌بودن راهکار اصلاحی مطرح می‌شود.

اما CVE یک شناسه استاندارد است.

این دو مفهوم یکسان نیستند.

آیا آسیب‌پذیری Zero-Day می‌تواند CVE داشته باشد؟

بله.

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

در بعضی موارد، شناسه پیش از انتشار عمومی جزئیات رزرو شده است.

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

آیا تمام CVEها مربوط به Zero-Day هستند؟

خیر.

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

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

اهمیت مراقبت از تهدیدات روز صفر

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

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

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

محدودیت‌های CVE چیست؟

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

پوشش‌ندادن تمام مشکلات امنیتی

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

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

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

تفاوت کیفیت اطلاعات رکوردها

سطح جزئیات رکوردهای CVE یکسان نیست.

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

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

امکان تغییر اطلاعات

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

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

ناتوانی در تعیین ریسک سازمانی به‌تنهایی

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

این موارد نیازمند تحلیل مستقل هستند.

احتمال خطای تطبیق نسخه‌ها

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

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

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

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

اشتباه اول؛ برابر دانستن CVE با شدت خطر

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

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

اشتباه دوم؛ فرض اینکه هر CVE حتماً قابل سوءاستفاده است

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

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

اشتباه سوم؛ بی‌توجهی به آسیب‌پذیری‌های فاقد CVE

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

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

اشتباه چهارم؛ تکیه کامل بر CVSS

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

اشتباه پنجم؛ نادیده‌گرفتن نسخه دقیق محصول

گاهی فقط نسخه‌های مشخصی تحت تأثیر هستند.

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

اشتباه ششم؛ اعتماد مطلق به ابزار اسکن

اسکنرهای امنیتی ممکن است خطای مثبت کاذب یا False Positive داشته باشند.

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

نتایج مهم باید اعتبارسنجی شوند.

اشتباه هفتم؛ تصور اینکه WAF جایگزین وصله است

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

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

به همین دلیل باید آن را یک کنترل دفاعی مکمل یا جبرانی دانست.

اشتباه هشتم؛ فراموش‌کردن بررسی پس از اصلاح

نصب یک به‌روزرسانی بدون بررسی نتیجه می‌تواند اطمینان کاذب ایجاد کند.

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

اشتباه نهم؛ نداشتن برنامه منظم پایش

بررسی CVE فقط هنگام انتشار یک خبر مهم کافی نیست.

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

بهترین روش‌های استفاده از CVE برای مدیران سایت و متخصصان امنیت

برای استفاده مؤثر از اطلاعات CVE، رعایت چند اصل می‌تواند مفید باشد.

موجودی نرم‌افزارها را به‌روز نگه دارید

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

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

اطلاعیه‌های رسمی را دنبال کنید

صرف مطالعه خبرهای عمومی کافی نیست.

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

اصلاحات را بر اساس ریسک اولویت‌بندی کنید

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

از داده‌های قابل‌اعتماد استفاده کنید

تاریخ انتشار، وضعیت رکورد، نسخه‌های تحت تأثیر و اعتبار منابع را بررسی کنید.

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

نسخه پشتیبان و برنامه بازیابی داشته باشید

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

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

کنترل‌های امنیتی مکمل را فعال کنید

استفاده از 2FA، اصل حداقل دسترسی، محدودسازی سرویس‌های غیرضروری، پایش رویدادها و جداسازی مناسب شبکه می‌تواند سطح خطر را کاهش دهد.

گزارش‌های امنیتی را مستند کنید

برای هر آسیب‌پذیری مهم، علت تصمیم، مسئول اقدام و نتیجه اعتبارسنجی را ثبت کنید.

این مستندسازی برای بررسی‌های بعدی، ممیزی و مدیریت حوادث مفید است.

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

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

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

گام اول؛ ثبت مؤلفه‌ها

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

بهتر است افزونه‌های غیرفعال و مؤلفه‌های باقی‌مانده روی سرور نیز مشخص باشند.

گام دوم؛ تعیین اهمیت

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

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

گام سوم؛ بررسی اطلاعیه‌ها

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

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

گام چهارم؛ اجرای اصلاحات

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

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

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

گام پنجم؛ ثبت وضعیت

نتیجه بررسی را در یک گزارش ساده نگهداری کنید.

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

گام ششم؛ پایش پس از اصلاح

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

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

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

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

CVE مخفف چیست؟

CVE مخفف Common Vulnerabilities and Exposures است. این عبارت به نظام استاندارد نام‌گذاری و ثبت آسیب‌پذیری‌های امنیت سایبری اشاره می‌کند. هر شناسه CVE برای شناسایی یک آسیب‌پذیری مشخص به کار می‌رود.

CVE چه تفاوتی با آسیب‌پذیری امنیتی دارد؟

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

آیا هر CVE خطرناک است؟

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

آیا وجود CVE یعنی سایت من هک شده است؟

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

چگونه بفهمیم یک CVE روی سایت ما تأثیر دارد؟

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

CVE را از کجا جست‌وجو کنیم؟

وب‌سایت رسمی CVE در نشانی cve.org و پایگاه NVD در نشانی nvd.nist.gov از منابع اصلی برای جست‌وجوی شناسه‌ها و بررسی اطلاعات مرتبط هستند.

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

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

آیا CVE رایگان است؟

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

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

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

وضعیت RESERVED در CVE به چه معناست؟

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

وضعیت REJECTED در CVE چیست؟

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

آیا CVE شامل راهکار رفع آسیب‌پذیری است؟

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

آیا CVE فقط برای نرم‌افزارها استفاده می‌شود؟

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

آیا نبود CVE به معنی امن‌بودن محصول است؟

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

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

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

آیا CVEهای قدیمی همچنان اهمیت دارند؟

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

آیا CVE برای تست نفوذ ضروری است؟

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

بهترین راه مقابله با آسیب‌پذیری‌های CVE چیست؟

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

جمع‌بندی؛ چرا شناخت و استفاده صحیح از CVE اهمیت دارد؟

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

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

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

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

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

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

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

مهم‌ترین نکته این است که امنیت یک اقدام مقطعی نیست.

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

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