CVSS 10 اکیلا patch order نہیں، KEV اور affected version پہلے دیکھیں

CVE فہرست کو صرف CVSS کے بڑے سے چھوٹے نمبر میں ترتیب نہ دیں۔ پہلے ثابت کریں کہ متعلقہ product اور متاثرہ version واقعی آپ کے ماحول میں موجود ہے، پھر asset کا exposure اور KEV status دیکھیں؛ vendor fix، compensating control اور کاروباری اہمیت اس evidence کو عملی patch order میں بدلتے ہیں۔

اس جانچ کے بعد ہر asset–CVE جوڑی کو فوری کارروائی، منصوبہ بند التوا یا غیر متعلق قرار دیں۔ version یا exposure کی معلومات نامکمل ہوں تو نتیجہ بند کرنے کے بجائے اسے تحقیق کے لیے کھلا رکھیں، اور ہر فیصلے کے ساتھ مختصر evidence log محفوظ کریں۔

چھ خانوں کی triage worksheet بنائیں

ہر asset–CVE جوڑی کے لیے الگ قطار رکھیں۔ ایک ہی CVE دس servers پر مل سکتا ہے، مگر internet-facing production server اور isolated test system کا exposure، کاروباری کردار اور قابلِ قبول downtime یکساں نہیں ہوتے۔

• Asset اور exposure: asset ID، مالک، production یا test حیثیت، internet-facing راستہ اور network restrictions۔
• Affected version: نصب شدہ version، vendor کی متاثرہ range، detection کا طریقہ اور نتیجہ—affected، not affected یا unknown۔
• KEV status: catalog میں موجودگی، جانچ کی تاریخ اور درج شدہ required action یا due date، اگر موجود ہو۔
• Vendor fix: fixed version، patch یا mitigation، prerequisites، reboot اور ممکنہ service interruption۔
• Compensating control: feature disablement، network restriction، isolation یا دوسرا control، اور وہ attack path جسے یہ روکتا ہے۔
• Business criticality: service owner، data sensitivity، downtime tolerance، dependencies اور ممکنہ کاروباری اثر۔

Controlled values استعمال کریں: مثلاً exposure کے لیے Internet، Partner، Internal اور Isolated۔ evidence نہ ملنے کو No نہ لکھیں؛ Unknown کا مطلب ہے کہ فیصلہ ابھی مکمل نہیں، جبکہ No ایک ثابت شدہ منفی نتیجہ ہونا چاہیے۔

NVD کی technical updates کے مطابق CVE detail میں دستیاب affected configurations اور CISA-ADP سے حاصل شدہ SSVC data شامل ہیں؛ NIST نے KEV میں درج CVEs کو enrichment کی ترجیح بھی دی ہے، لیکن واضح کیا ہے کہ “Lowest Priority” processing label والا CVE کسی متاثرہ system پر پھر بھی نمایاں اثر ڈال سکتا ہے۔ اس لیے NVD کی enrichment priority کو اپنے ادارے کی patch priority نہ سمجھیں۔

Affected range سے applicability ثابت کریں

Scanner finding کو حتمی ثبوت نہ مانیں۔ package manager، application console، معتبر inventory یا vendor کے تجویز کردہ command سے installed version معلوم کریں، پھر advisory میں product edition، operating system، architecture، enabled component اور version boundaries ملائیں۔ صرف product name یکساں ہونا کافی نہیں۔

ایک فرضی مثال میں affected range >=4.2.0 اور <4.2.7 ہے۔ اس شرط کے تحت 4.2.5 متاثر ہے، 4.2.7 range سے باہر ہے اور 4.1.9 بھی اس مخصوص range میں شامل نہیں؛ البتہ پرانی branch کے لیے الگ range یا backported fix ہو تو اسے علیحدہ جانچنا ہوگا۔ “4.2” جیسی نامکمل inventory value سے فیصلہ ممکن نہیں، اس لیے نتیجہ Unknown رہے گا۔

Appliance، container یا bundled library میں version string بھی کافی نہیں ہو سکتی۔ vendor patch کو پرانے version identifier میں backport کر سکتا ہے، یا library موجود ہونے کے باوجود vulnerable function استعمال نہ ہو رہا ہو؛ ایسی صورت میں vendor advisory یا قابلِ حوالہ VEX statement کو evidence بنائیں اور صرف banner matching پر finding بند نہ کریں۔

KEV اور CVSS الگ سوالوں کے جواب ہیں

FIRST کی CVSS v4.0 رہنمائی کے مطابق Base score vulnerability کی داخلی technical severity بیان کرتا ہے، مکمل risk نہیں، اور score کی حد 0 سے 10 ہے؛ threat اور مخصوص environment کا context الگ شامل کرنا پڑتا ہے۔ چنانچہ CVSS 10 شدید ممکنہ اثر دکھاتا ہے، مگر یہ ثابت نہیں کرتا کہ آپ کا deployed version متاثر، حملہ آور کے لیے قابلِ رسائی یا واقعی exploit ہو رہا ہے۔

CISA کا KEV catalog حقیقی ماحول میں exploit ہونے والی vulnerabilities کی authoritative فہرست ہے اور CISA اسے vulnerability-management prioritization کا input بنانے کی ہدایت دیتا ہے۔ KEV entry exploitation evidence دیتی ہے، مگر remediation سے پہلے پھر بھی affected version، asset exposure اور catalog میں درج required action کو اپنے deployment سے ملانا ضروری ہے۔

فرضی طور پر، ایک affected اور internet-facing gateway پر KEV-listed CVSS 8.8 finding isolated lab کی non-KEV CVSS 10 finding سے پہلے آ سکتی ہے۔ دوسری finding ختم نہیں ہوتی؛ اس کا owner اور patch window برقرار رہتا ہے، مگر پہلی قطار میں applicability، exploitation evidence اور reachable attack path بیک وقت موجود ہیں۔

فوری، مؤخر یا غیر متعلق فیصلہ کریں

1. Applicability gate: product، edition، component یا installed version affected range میں نہ ہو تو version evidence کے ساتھ “غیر متعلق” کریں۔ معلومات ادھوری ہوں تو finding کھلی رکھیں۔
2. Exploitation gate: affected vulnerability KEV میں ہو تو exposure، مطلوبہ privileges اور vendor action فوراً جانچیں۔ internet-facing یا critical service میں قابلِ استعمال راستہ ہو تو emergency change یا فوری mitigation کے لیے escalate کریں۔
3. Exposure and impact gate: non-KEV vulnerability بھی فوری ہو سکتی ہے اگر remote attack path کھلا، sensitive data یا بنیادی service متاثر اور مؤثر control غیر موجود ہو۔ یہاں CVSS vector، صرف مجموعی score سے زیادہ مفید context دیتا ہے۔
4. Deferral gate: التوا تب منظور کریں جب فوری deployment کا operational نقصان زیادہ ہو اور آزمودہ compensating control متعلقہ attack path کو محدود کر رہا ہو۔ owner، منظوری، review date اور patch window درج کریں۔

“غیر متعلق” کا مطلب CVE record مٹانا نہیں بلکہ یہ ثابت کرنا ہے کہ اس asset پر remediation درکار نہیں۔ “مؤخر” بھی مستقل استثنا نہیں؛ KEV status، exposure، vendor advisory، control یا asset role بدلے تو قطار دوبارہ triage کریں۔

Fix اور compensating control کی حد جانچیں

Patch download دستیاب ہونا مکمل fix کا ثبوت نہیں۔ درست platform اور branch، superseded patches، prerequisites، rollback، reboot اور post-install version check درج کریں؛ deployment کے بعد vendor کے تجویز کردہ طریقے یا authenticated scan سے remediation verify کریں۔

Compensating control اسی attack path سے مربوط ہونا چاہیے جس سے exploitation ممکن ہے۔ management interface کو internet سے ہٹانا، vulnerable feature بند کرنا، ingress کو trusted sources تک محدود کرنا یا asset isolate کرنا مؤثر ہو سکتا ہے؛ generic monitoring یا غیر آزمودہ WAF rule کو مکمل protection نہ لکھیں۔ control owner، expiry اور validation evidence کے بغیر التوا قابلِ audit نہیں رہتا۔

Business criticality خودکار طور پر “سب سے پہلے patch” کا حکم نہیں۔ اہم service پر بے آزمائش update availability کو متاثر کر سکتی ہے، جبکہ compromise کا اثر بھی بڑا ہو سکتا ہے؛ اسی لیے rollout test، redundancy، backup اور maintenance window کو risk decision میں شامل کریں۔

Evidence log فیصلہ قابلِ audit رکھتا ہے

ہر قطار میں outcome، approver، timestamp اور اگلی review date درج کریں۔ inventory query یا command، scanner finding ID، vendor advisory reference، KEV check، control validation اور change ticket بھی محفوظ ہوں۔ evidence بدلے تو پچھلی entry overwrite نہ کریں؛ نئی entry audit trail کو برقرار رکھتی ہے۔

عملی queue بنانے کے لیے نئی findings کو assets سے ملائیں، unknown versions کی تحقیق کریں، affected rows پر KEV اور exposure دیکھیں، پھر fix یا control اور کاروباری deadline منظور کریں۔ یوں CVSS technical severity کا signal رہتا ہے، مگر اصل patch order متاثرہ deployment، exploitation evidence، reachable attack path اور کاروباری اثر سے بنتا ہے۔

یہ بھی پڑھیں:

• PaperCut zero-day کے لیے دوسرا emergency patch؛ پہلے والا کافی نہیں
• AI agent sandbox اکیلا کافی نہیں: دو پوسٹ مارٹم سے سکیورٹی چیک لسٹ
• Claude AI صرف chatbot نہیں: کام، coding اور منصوبوں کی اصل حدیں