Security Assessment & Hardeningتفاوت Vulnerability Scan، CVE Analysis، Configuration Assessment و Hardening؛ چرا اسکن آسیبپذیری بهتنهایی برای کاهش ریسک زیرساخت کافی نیست.
دو مسئله متفاوت: Software Vulnerability و Configuration Risk
Vulnerability Scanner معمولاً بهدنبال نسخه آسیبپذیر نرمافزار، Service قابل شناسایی یا نشانهای از CVE میگردد. Hardening Assessment بررسی میکند تنظیمات سیستم، Policyها و سرویسها با Baseline امنیتی چقدر فاصله دارند. این دو مجموعه همپوشانی دارند، اما جای یکدیگر را نمیگیرند.
یک سرور ممکن است Patchهای روز را داشته باشد ولی RDP یا SSH بیش از حد باز، Audit ناکافی یا Serviceهای غیرضروری فعال داشته باشد. برعکس، یک سیستم ممکن است از نظر CIS خوب باشد اما نسخه Library آسیبپذیری داشته باشد که نیاز به Patch فوری دارد.
CVE چه چیزی به ما میگوید؟
CVE شناسه یک آسیبپذیری شناختهشده است. برای عملیات واقعی باید CVE به Product و Version موجود روی Asset متصل شود. Severity، Exploit status و حضور در Catalogهای exploit-known میتوانند Priority را تغییر دهند.
اگر Asset Inventory دقیق نباشد، Vulnerability Correlation نیز ضعیف میشود. بنابراین Asset Discovery یک پیشنیاز مهم برای تحلیل قابل اتکای CVE است.
Configuration Risk چه چیزی را پوشش میدهد؟
Configuration Risk شامل مواردی است که الزاماً CVE ندارند: Password Policy ضعیف، Logging ناکافی، Protocol ناامن، Permission اشتباه، Management Access باز یا Security Option نامناسب. Baselineهایی مثل CIS و STIG برای این بخش مفید هستند.
| حوزه | نمونه Finding | روش اصلی |
|---|---|---|
| Software vulnerability | نسخه آسیبپذیر Package | CVE / Scanner |
| Configuration | SSH setting ناامن | CIS/STIG Assessment |
| Asset hygiene | نرمافزار غیرمجاز | Inventory / Discovery |
| Change | اصلاح کنترلشده | Hardening Plan |
اولویتبندی باید Context-aware باشد
اگر تیم فقط لیست Critical CVE را دنبال کند، ممکن است Configuration Exposure مهم را نبیند. اگر فقط Compliance Score را دنبال کند، ممکن است Exploit فعال روی نرمافزار را از دست بدهد. بهتر است Priority از ترکیب Severity، Exposure، Asset Criticality، Exploit Context و Change Feasibility ساخته شود.
گزارش خوب نباید فقط بگوید «چه چیزهایی بد هستند»؛ باید کمک کند تیم بفهمد «کدام مورد را چرا و با چه روشی زودتر اصلاح کند».
Workflow ترکیبی پیشنهادی
- Asset و Software Inventory را تثبیت کنید.
- Vulnerability Correlation را برای Product/Version اجرا کنید.
- Configuration Baseline را جداگانه Assess کنید.
- یافتهها را در یک Risk View مشترک مرور کنید.
- Patch، Configuration Change، Exception یا Compensating Control را انتخاب کنید.
- برای تغییرات Hardening از Backup و Pilot استفاده کنید.
- پس از اصلاح، هم Finding و هم سلامت سرویس را Verify کنید.
برای مدیریت چه گزارشی مفیدتر است؟
مدیریت معمولاً به هزاران Row فنی نیاز ندارد. گزارش مدیریتی بهتر است روند Exposure، تعداد Findingهای High/Critical، Coverage داراییها، وضعیت Remediation و موارد Blocked را نشان دهد. جزئیات Evidence باید برای تیم فنی در Drill-down باقی بماند.
این تفکیک باعث میشود یک دیتاست هم برای تصمیم مدیریتی و هم برای اقدام عملیاتی مفید باشد، بدون اینکه یکی قربانی دیگری شود.
گام بعدی
اگر این موضوع را برای شبکه واقعی بررسی میکنید، بهتر است قبل از هر تغییر Scope، نسخه پلتفرم و محدودیت Production مشخص باشد. میتوانید از صفحه خدمات مقاومسازی یا فرم درخواست ارزیابی شروع کنید.