Vulnerability management — CVE, CVSS, EPSS, KEV আর patch-এর অগ্রাধিকার

১ · ত্রুটি জানা আর ত্রুটি সারানোর মাঝের ফাঁক

পুরান ঢাকার একটি পুরোনো ভবন ভাবুন। ফায়ার সার্ভিস ঘোষণা করল, এক কোম্পানির এক ধরনের অগ্নিনির্বাপক যন্ত্রে ত্রুটি আছে। ভবনের ম্যানেজার কী করবেন? তাঁকে জানতে হবে ভবনে কতগুলো যন্ত্র আছে, কোন তলায় আছে, কোনগুলো সেই মডেলের। রান্নাঘরের পাশেরটি আগে বদলাতে হবে, ছাদের গুদামেরটি পরে। বদলানোর পর কেউ গিয়ে দেখবেন নতুনটি সত্যিই বসেছে কি না। আর মালিককে জানাতে হবে কতগুলো বাকি।

এই পুরো কাজটিই vulnerability management. Vulnerability মানে দুর্বলতা (পর্ব ২). আর patch management এর একটি অংশ মাত্র, যেখানে patch বসানো হয়। Scan চালিয়ে একটি লম্বা রিপোর্ট বানানো vulnerability management নয়। আসল কাজ শুরু হয় রিপোর্টের পরে।

প্রথম ধাপটিই ভিত্তি। Asset inventory না থাকলে বাকি পাঁচটি ধাপ অন্ধকারে চলে। তালিকায় থাকা দরকার যন্ত্র, software, version, মালিক, আর সেটি internet-এ খোলা কি না। Threat modeling-এ যা শিখেছেন (পর্ব ৪), সেটিও এখানে কাজে লাগে।

২ · CVE, CWE, CNA আর NVD — ত্রুটির নাম-ঠিকানা

একই ত্রুটিকে একেক প্রতিষ্ঠান একেক নামে ডাকলে কেউ কারও কথা মেলাতে পারবে না। তাই ১৯৯৯ সালে MITRE শুরু করে CVE তালিকা। একটি ত্রুটির একটি নম্বর, যেমন CVE-2021-44228. মাঝের অংশ বছর, শেষের অংশ ক্রমিক নম্বর। হাসপাতালের রোগীর রেজিস্ট্রেশন নম্বরের মতো, এটি শুধু পরিচয় দেয়, রোগ কতটা গুরুতর তা বলে না।

নম্বর দেন CNA (CVE Numbering Authority). বড় software নির্মাতা, নিরাপত্তা প্রতিষ্ঠান আর কিছু জাতীয় CERT এমন CNA. CVE-র জন্ম হয় সাধারণত সমন্বিত প্রকাশের (পর্ব ৬) পথ ধরে, আর তার সাথে আসে security advisory.

সব দুর্বলতার CVE থাকে না। আপনার নিজের লেখা app-এর ত্রুটি, ভুল configuration বা দুর্বল password-এর কোনো CVE নেই। তাই CVE-র তালিকা শেষ মানে নিরাপদ, এমন ভাবা ভুল।

NVD-র backlog: একটি উৎসের ওপর ভর না করা

দীর্ঘদিন প্রায় সবাই ধরে নিয়েছিলেন, NVD প্রতিটি CVE-তে স্কোর আর CPE (কোন পণ্য আক্রান্ত, তার মানসম্মত নাম) যোগ করবে। ২০২৪ সাল থেকে এই কাজ বড় আকারে পিছিয়ে পড়ে। NIST-এর ২০২৬ সালের ১৫ এপ্রিলের ঘোষণা অনুসারে সব CVE-তে তথ্য যোগ করার লক্ষ্য ছেড়ে ঝুঁকিভিত্তিক পথ নেওয়া হয়: KEV-এ থাকা CVE, মার্কিন সরকারে ব্যবহৃত software আর “critical software” আগে। বাকিগুলো তালিকায় থাকে, কিন্তু বাড়তি তথ্য না পেতেও পারে। CVE Program-এর অর্থায়ন নিয়েও ২০২৫ সালের এপ্রিলে শেষ মুহূর্তের অনিশ্চয়তা দেখা দিয়েছিল। এই দুটি বিষয় বদলাতে পারে, তাই বর্তমান অবস্থা nvd.nist.gov আর cve.org-এ দেখে নিন।

ব্যবহারিক শিক্ষা হলো, স্কোর না পেলে বসে থাকবেন না। সরাসরি vendor-এর advisory পড়ুন, আর CNA-র দেওয়া স্কোর দেখুন।

৩ · CVSS v3.1 — স্কোর হিসাব করুন হাতে

FIRST-এর CVSS একটি দুর্বলতার প্রযুক্তিগত তীব্রতাকে ০ থেকে ১০ স্কোরে আনে। ভূমিকম্পের রিখটার মাত্রার মতো, এটি বলে ঘটনাটি কত শক্তিশালী, আপনার বাড়ির কী হবে তা নয়। স্কোরের পাশে থাকে vector, যেমন:

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

Vector-ই আসল তথ্য। স্কোর শুধু তার সারসংক্ষেপ। প্রতিটি অক্ষরজোড়া একটি প্রশ্নের উত্তর:

সমীকরণ চারটি। সংখ্যাগুলো FIRST-এর প্রকাশিত স্পেসিফিকেশন থেকে নেওয়া:

ISS            = 1 - (1 - C) × (1 - I) × (1 - A)
Impact (S:U)   = 6.42 × ISS
Impact (S:C)   = 7.52 × (ISS - 0.029) - 3.25 × (ISS - 0.02)^15
Exploitability = 8.22 × AV × AC × PR × UI

Impact ≤ 0 হলে   Base = 0
S:U              Base = Roundup(min(Impact + Exploitability, 10))
S:C              Base = Roundup(min(1.08 × (Impact + Exploitability), 10))

Roundup মানে এক দশমিক ঘরে সবসময় ওপরের দিকে গোল করা। সাধারণ গোল করার মতো নয়: 4.02 হয় 4.1, কিন্তু 4.00 থাকে 4.0. এবার কাল্পনিক CVE-EXAMPLE-0003 ধরে হিসাবটি ধাপে ধাপে দেখুন। এটি একটি কাল্পনিক অনলাইন বাজারের গ্রাহক database-এ পাওয়া ত্রুটি, যা সামান্য অধিকারের একটি account দিয়ে network থেকে কাজে লাগানো যায়।

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

Scope বদলালে কী হয়

ধরুন একই ত্রুটি database process থেকে বেরিয়ে আশপাশের system-এও প্রভাব ফেলে, অর্থাৎ S:C. বাকি সব এক। তিনটি জিনিস বদলাবে:

• PR:L-এর ওজন 0.62 থেকে হয় 0.68, তাই Exploitability = 8.22 × 0.85 × 0.77 × 0.68 × 0.85 = 3.1096.
• Impact = 7.52 × (0.8064 − 0.029) − 3.25 × (0.8064 − 0.02)¹⁵ = 5.8460 − 0.0884 = 5.7576.
• যোগফল 8.8673, 1.08 দিয়ে গুণ করে 9.5766. Roundup-এ 9.6, Critical.

নিচের ক্যালকুলেটরটি স্পেসিফিকেশনের সমীকরণ থেকে লেখা। FIRST-এর প্রকাশিত নমুনা স্কোরের সাথে মিলিয়ে নিজেকে যাচাই করে। আপনি vector বদলে পরীক্ষা করতে পারেন।

// CVSS v3.1 base score, written from the published equations.
const W = { AV: { N: .85, A: .62, L: .55, P: .2 }, AC: { L: .77, H: .44 },
  UI: { N: .85, R: .62 }, CIA: { H: .56, L: .22, N: 0 } };
const PR = { U: { N: .85, L: .62, H: .27 }, C: { N: .85, L: .68, H: .5 } };

function roundup(x) {              // Appendix A of the specification
  const i = Math.round(x * 100000);
  return i % 10000 === 0 ? i / 100000 : (Math.floor(i / 10000) + 1) / 10;
}
function score(vector) {
  const m = Object.fromEntries(vector.split('/').map(p => p.split(':')));
  const iss = 1 - (1 - W.CIA[m.C]) * (1 - W.CIA[m.I]) * (1 - W.CIA[m.A]);
  const changed = m.S === 'C';
  const impact = changed ? 7.52 * (iss - .029) - 3.25 * Math.pow(iss - .02, 15)
                         : 6.42 * iss;
  const expl = 8.22 * W.AV[m.AV] * W.AC[m.AC] * PR[m.S][m.PR] * W.UI[m.UI];
  if (impact <= 0) return 0;
  return roundup(Math.min((changed ? 1.08 : 1) * (impact + expl), 10));
}
// Official sample scores from the FIRST v3.1 examples document.
const samples = [
  ['AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N', 7.5, 'Heartbleed'],
  ['AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H', 9.8, 'Shellshock'],
  ['AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N', 3.1, 'POODLE'],
  ['AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N', 6.4, 'MySQL SQLi'],
  ['AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H', 9.9, 'VMware escape'],
  ['AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H', 8.2, 'ThinkPwn'],
];
for (const [v, want, name] of samples) {
  const got = score(v);
  console.log(`${got === want ? 'OK ' : 'BAD'} ${got.toFixed(1)} ${name}`);
}
console.log('CVE-EXAMPLE-0003 ->', score('AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N').toFixed(1));

CVSS v4.0-তে কী বদলেছে

CVSS v4.0 প্রকাশিত হয় ২০২৩ সালের নভেম্বরে। তবে এখনো বহু তালিকা আর টুলে v3.1 চলে, তাই দুটিই চেনা দরকার।

• Attack Requirements (AT) যোগ হয়েছে: আক্রমণের জন্য লক্ষ্য system-এ বিশেষ পরিস্থিতি লাগে কি না।
• UI-র তিন মান: None, Passive, Active.
• Scope নেই: এর বদলে impact এখন আলাদা দুই সেটে: দুর্বল system-এর জন্য VC, VI, VA আর পরের system-এর জন্য SC, SI, SA.
• Temporal-এর জায়গায় Threat: Exploit Maturity মেট্রিক থাকে, আর Environmental দিয়ে নিজের পরিবেশ যোগ করা যায়।
• Supplemental metric: যেমন Safety আর Automatable. এগুলো বাড়তি তথ্য, স্কোর বদলায় না।
• নাম: CVSS-B মানে শুধু Base, CVSS-BT, CVSS-BE আর CVSS-BTE মানে Threat বা Environmental-ও ধরা হয়েছে। একটি স্কোর উদ্ধৃত করলে নামসহ লিখুন।
• হিসাব: আর সরল সূত্র নয়। Metric-গুলো MacroVector নামের দলে ভাগ হয়, বিশেষজ্ঞদের ঠিক করা lookup table থেকে মান আসে, তারপর interpolation. তাই পরীক্ষায় হাতে হিসাব v3.1-এই বেশি মানায়। v4.0-র জন্য FIRST-এর calculator ব্যবহার করুন।

৪ · Severity মানে ঝুঁকি নয় — EPSS, KEV আর SSVC

CVSS 9.8 দেখলেই কি সব ফেলে দৌড়াবেন? ঘূর্ণিঝড়ের কথা ভাবুন। ঝড়ের শক্তি একটি তথ্য। কিন্তু সিদ্ধান্ত নিতে আরও লাগে: ঝড় আসার সম্ভাবনা কত, ঝড় কি এর মধ্যেই আঘাত হেনেছে, আর আপনার ঘর উপকূলে না পাহাড়ে। CVSS-এর নিজের v3.1 user guide-ও বলে, base score তীব্রতা মাপে, ঝুঁকি নয়। ঝুঁকির হিসাবে সম্ভাবনা আর প্রভাব দুটোই লাগে (পর্ব ২).

EPSS পড়ার নিয়ম

• EPSS 0.40 মানে পরের ৩০ দিনে কোথাও exploit কার্যকলাপ দেখা যাওয়ার অনুমিত সম্ভাবনা ৪০%. এটি আপনার server-এ হামলার সম্ভাবনা নয়।
• Percentile আলাদা জিনিস। ৯৫তম percentile মানে ৯৫% CVE-র স্কোর এর সমান বা নিচে।
• EPSS ক্ষতির মাপ দেয় না। একটি ছোট ত্রুটিও সহজে exploit হতে পারে।
• স্কোর বদলায়। কম EPSS মানে চিরকাল নিরাপদ নয়, মডেল ভুলও করতে পারে।
• মডেলের নতুন version আসে। বর্তমান version আর তথ্য first.org/epss-এ দেখুন।

KEV পড়ার নিয়ম

KEV পেছনের দিকে তাকায়, এতে ওঠা মানে হামলা ঘটে গেছে। তালিকায় না থাকা মানে হামলা হচ্ছে না, এমন নয়। Proof of concept বা গবেষকের scan থাকলেই তালিকায় ওঠে না, লাগে বাস্তব হামলার প্রমাণ। CISA-র মতে মার্কিন ফেডারেল সংস্থার বাইরের প্রতিষ্ঠানও KEV-কে নিজের পরিকল্পনায় রাখতে পারে। ২০২৬ সালের জুনে BOD 26-04 আগের BOD 22-01 আর 19-02-কে সরিয়ে দিয়েছে, আর সময়সীমা ঠিক করে asset public কি না, KEV, automation আর technical impact দেখে। কয়েকটি ক্ষেত্রে সময় মাত্র ৩ দিন বলে প্রকাশিত। এটি শুধু মার্কিন ফেডারেল বেসামরিক সংস্থার জন্য বাধ্যতামূলক, আপনার প্রতিষ্ঠানের নিয়ম নয়। বিস্তারিত সূচির জন্য cisa.gov দেখুন। শেখার বিষয় হলো, এই চারটির কোনোটিই CVSS স্কোর নিজে নয়।

SSVC: সংখ্যা নয়, সিদ্ধান্ত

CMU SEI আর CISA-র গবেষকদের চিন্তা হলো, স্কোরের কাজ শেষে কেউ তো সিদ্ধান্তই নেন। তাই সরাসরি সিদ্ধান্তের প্রশ্ন করা যাক। CISA-র সংস্করণে পাঁচটি প্রশ্ন আর চার ফল:

ফল হয় Track (নিয়মিত সূচিতে), Track* (নিয়মিত সূচিতে, তবে কাছ থেকে নজর), Attend (তত্ত্বাবধায়কেরা যুক্ত হন, সূচির আগে সারান) আর Act (নেতৃত্বও যুক্ত হন, যত দ্রুত সম্ভব সারান)। Active হামলা, স্বয়ংক্রিয়, total impact আর জরুরি system হলে ফল Act. হামলা নেই, স্বয়ংক্রিয় নয়, partial আর কম গুরুত্ব হলে Track. মাঝের ঘরগুলোর জন্য CISA-র মূল tree দেখুন, মুখস্থ করার দরকার নেই।

৫ · সব মিলিয়ে সারানোর ক্রম

এবার একটি ছোট তালিকায় সব সংকেত এক করি। শেষ বিষয়টি হলো asset context: কোন যন্ত্র, কতটা জরুরি, internet থেকে কি পৌঁছানো যায়, চারপাশে segmentation (পর্ব ২২) আছে কি না, মালিক কে। নিচের কোডের সূত্রটি আমাদের বানানো, শেখার জন্য; কোনো মান নয়। ছয়টি ID-ই কাল্পনিক (CVE-EXAMPLE-0001 থেকে 0006), তাই শুধু শেষ চার অঙ্ক ছাপা হবে।

// Toy prioritiser. The formula is ours, for teaching; it is NOT a standard.
const vulns = [
  { id: '0001', cvss: 9.8, epss: .02,  kev: false, net: false, crit: 1, host: 'test lab server' },
  { id: '0002', cvss: 7.5, epss: .91,  kev: true,  net: true,  crit: 3, host: 'payment gateway' },
  { id: '0003', cvss: 8.1, epss: .40,  kev: false, net: false, crit: 3, host: 'customer database' },
  { id: '0004', cvss: 9.1, epss: .003, kev: false, net: false, crit: 1, host: 'print server' },
  { id: '0005', cvss: 6.5, epss: .62,  kev: true,  net: true,  crit: 2, host: 'staff VPN gateway' },
  { id: '0006', cvss: 5.3, epss: .001, kev: false, net: true,  crit: 1, host: 'company blog' },
];
function rank(v) {
  const likely = v.kev ? 1 : v.epss;        // KEV = already exploited
  const reach = v.net ? 1 : 0.6;            // internet-facing or not
  return likely * reach * (v.crit / 3) * (v.cvss / 10);
}
function tier(v) {
  if (v.kev && v.net) return 'P1';
  if (v.kev || (v.epss >= .3 && v.crit === 3)) return 'P2';
  if (v.cvss >= 7 && v.crit >= 2) return 'P3';
  return 'P4';
}
const byCvss = [...vulns].sort((a, b) => b.cvss - a.cvss);
const byRisk = [...vulns].sort((a, b) => rank(b) - rank(a));
console.log('CVSS only   : ' + byCvss.map(v => v.id).join(' '));
console.log('With context: ' + byRisk.map(v => v.id).join(' '));
console.log('');
for (const v of byRisk) {
  console.log(`${tier(v)} ${v.id} rank=${rank(v).toFixed(3)} ` +
    `cvss=${v.cvss} epss=${v.epss} kev=${v.kev ? 'Y' : 'N'} ${v.host}`);
}

৬ · নিজের system-এ scan, আর false positive

মূল্যায়নের প্রধান উপায় vulnerability scanner. এটি যন্ত্রের software আর version জেনে জানা দুর্বলতার সাথে মেলায়। দুই ধারণা জানা জরুরি:

Scanner-এর ফল অকাট্য নয়। False positive মানে আসলে নেই, কিন্তু রিপোর্টে আছে। সবচেয়ে সাধারণ কারণ backported fix: Linux distribution পুরোনো version নম্বর রেখেই fix বসায়, আর সরল scanner version দেখে সতর্ক করে। আরেকটি কারণ reachability: library আছে, কিন্তু দুর্বল ফাংশনটি কখনো ডাকা হয় না। এটি কম ঝুঁকি, তবে শূন্য নয়। False negative আরও বিপজ্জনক, কারণ ত্রুটি থাকে অথচ রিপোর্টে থাকে না। Equifax-এর ঘটনায় scan-এ না ধরা পড়া একটি প্রকাশিত ব্যর্থতা।

False positive দাবি করলে প্রমাণ রাখুন: vendor-এর advisory, package changelog, বা VEX ঘোষণা। “আমাদের এখানে হবে না” প্রমাণ নয়। Penetration testing scanner-এর কাজের পরিপূরক, কিন্তু আলাদা অনুমোদিত কাজ (পর্ব ৫০).

৭ · Patch management — দ্রুত, কিন্তু অন্ধভাবে নয়

Patch বসানো নিজেই একটি পরিবর্তন, আর পরিবর্তন system ভাঙতে পারে। Patch আসলে তিনটি প্রশ্ন: উৎসটি আসল তো (vendor-এর চ্যানেল, পর্ব ১১-এর signature যাচাই), আমাদের system-এ এটি কী ভাঙবে, আর ভাঙলে ফিরব কীভাবে?

• Ring: সমস্যা অল্প যন্ত্রেই ধরা পড়ে, ফলে blast radius ছোট থাকে।
• Maintenance window: বিদ্যুৎ অফিসের ঘোষিত লাইন মেরামতের সময়ের মতো। আগে জানানো হয়, ব্যবহারকারী প্রস্তুত থাকেন। ঈদের সেলের আগের রাতটি উইন্ডো হিসেবে ভুল সময়।
• Emergency change: নিয়ম ভাঙা নয়, আগে থেকে লেখা দ্রুত পথ। কে অনুমতি দেবেন, ন্যূনতম কী পরীক্ষা হবে, আর পরে কোন নথি হবে। অনুমতির মানুষ রাত ২টায় পাওয়া যাবেন কি না, তাও আগে ঠিক রাখুন।
• Rollback: Snapshot আর backup আগে নিন, আর ফেরার পথ পরীক্ষা করুন। Database schema বদলালে ফেরা কঠিন হতে পারে। মনে রাখুন, rollback ত্রুটিকে ফিরিয়ে আনে, তাই তখন compensating control লাগবে।
• বসানো মানেই চালু নয়: Service বা যন্ত্র restart না হলে পুরোনো কোড memory-তে চলতে পারে। তাই যাচাই আলাদা ধাপ।

নিচের সিমুলেটরে ১০০০টি কাল্পনিক host. একটি ভালো patch আর একটি খারাপ patch একই নিয়মে ছড়ানো হচ্ছে। কোনো ring-এ ২%-এর বেশি ব্যর্থ হলে থামবে। Seed স্থির, তাই ফল প্রতিবার এক।

// Patch ring rollout on a toy fleet, seeded so every run is the same.
function mulberry32(a) {
  return () => { a |= 0; a = a + 0x6D2B79F5 | 0;
    let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const rings = [['canary', 10], ['early', 90], ['broad', 400], ['critical', 500]];
const STOP_AT = 0.02;                       // halt if over 2% of a ring fails

function rollout(label, failRate, seed) {
  const rand = mulberry32(seed);
  let patched = 0, broken = 0;
  console.log(`${label} (true failure rate ${failRate * 100}%)`);
  for (const [name, size] of rings) {
    let bad = 0;
    for (let i = 0; i < size; i++) if (rand() < failRate) bad++;
    patched += size; broken += bad;
    const rate = bad / size;
    console.log(`  ${name.padEnd(8)} ${String(size).padStart(3)} hosts, ` +
                `${String(bad).padStart(2)} failed (${(rate * 100).toFixed(1)}%)`);
    if (rate > STOP_AT) {
      console.log(`  HALT and roll back. Patched ${patched}, broken ${broken}.`);
      return;
    }
  }
  console.log(`  Finished. Patched ${patched}, broken ${broken}.`);
}
rollout('Good patch', 0.002, 7);
rollout('Bad patch', 0.08, 7);
console.log(`Bad patch on all 1000 hosts at once: about ${1000 * 0.08} broken`);

Patch দেওয়া না গেলে: compensating control

কখনো patch নেই, কখনো যন্ত্রের নির্মাতা অনুমতি দেন না, কখনো পরের উইন্ডো দুই সপ্তাহ পরে। তখন compensating control. ঘরের তালা ভাঙা, মিস্ত্রি কাল আসবেন, আজ রাতে দারোয়ান বসানোর মতো।

Compensating control সময় কেনে, সমস্যা মেটায় না। CISA-ও KEV-এর নির্দেশনায় workaround-কে সাময়িক বলে, আর fix এলে তা বসাতে বলে।

৮ · SLA, exception আর metric

SLA লিখে ঠিক করে দেয় কোন অগ্রাধিকারের কাজ কত দিনে শেষ হবে। নিচের সংখ্যাগুলো ধরে নেওয়া, প্রতিটি প্রতিষ্ঠান নিজের ঝুঁকি আর সামর্থ্য দেখে ঠিক করে।

এবার CVE-EXAMPLE-0003-এর পুরো জীবন ধাপে ধাপে দেখুন। আগের ধাপের হিসাব থেকেই শুরু: CVSS 8.1, জরুরি গ্রাহক database.

নিচে একই ধরনের কয়েকটি ticket-কে একটি কল্পিত তারিখে দেখা হচ্ছে। আসল ঘড়ি ব্যবহার করা হয়নি, তাই ফল সবসময় এক।

// SLA ageing tracker on a simulated date. Days and dates are assumed.
const DAY = 86400000;
const d = s => Date.parse(s + 'T00:00:00Z');
const today = d('2026-03-20');              // simulated "today"
const SLA = { P1: 3, P2: 14, P3: 30, P4: 90 };   // target days, assumed
const items = [
  { id: '0002', pri: 'P1', found: '2026-03-16', closed: '2026-03-18' },
  { id: '0005', pri: 'P1', found: '2026-03-14', closed: null },
  { id: '0003', pri: 'P2', found: '2026-03-02', closed: '2026-03-13' },
  { id: '0007', pri: 'P2', found: '2026-02-20', closed: null },
  { id: '0008', pri: 'P3', found: '2026-03-01', closed: null },
  { id: '0004', pri: 'P4', found: '2026-01-10', closed: null, exception: '2026-06-30' },
];
const closedDays = [];
let breached = 0, open = 0;
for (const v of items) {
  const end = v.closed ? d(v.closed) : today;
  const age = Math.round((end - d(v.found)) / DAY);
  const left = SLA[v.pri] - age;
  let state = v.closed ? 'closed in time' : `open, ${left} days left`;
  if (v.closed) closedDays.push(age);
  else open++;
  if (left < 0) { state = v.closed ? 'closed late' : `OVERDUE by ${-left} days`; breached++; }
  if (v.exception) state += `, exception until ${v.exception}`;
  console.log(`${v.pri} ${v.id} age=${String(age).padStart(2)}d ${state}`);
}
const mttr = closedDays.reduce((a, b) => a + b, 0) / closedDays.length;
console.log(`MTTR of closed items: ${mttr.toFixed(1)} days (n=${closedDays.length})`);
console.log(`Open: ${open}, past SLA: ${breached} of ${items.length}`);

কোন metric দেখবেন

• Coverage: কত শতাংশ asset authenticated scan-এর আওতায়। এটি কম হলে বাকি সব সংখ্যা ভুয়া নিরাপত্তা দেয়।
• MTTR: অগ্রাধিকার অনুযায়ী আলাদা করে, গড়ের পাশে median সহ।
• Age: খোলা দুর্বলতার বয়স, সবচেয়ে পুরোনোটি কত দিনের, ৩০ বা ৯০ দিনের ওপরে কতগুলো।
• SLA মানা: সময়মতো কত শতাংশ, আর KEV-এ থাকা কতগুলো এখনো খোলা।
• Exception: কতগুলো চলছে, কতগুলোর মেয়াদ শেষ।

“মোট কত CVE বন্ধ হলো” দিয়ে দলকে বিচার করলে সহজগুলোই বন্ধ হবে, কঠিনগুলো পড়ে থাকবে। Metric যা গোনে, মানুষ তাই বদলায়।

Exception আর risk acceptance

সব সময়মতো হবে না। একটি যন্ত্রের নির্মাতা নতুন firmware দেবেন পরের বছর। তখন exception, অর্থাৎ risk acceptance-এর লিখিত রূপ (পর্ব ২). ভালো exception-এ থাকে:

• নির্দিষ্ট CVE, asset আর কারণ
• কোন compensating control বসানো আছে
• মেয়াদ শেষের তারিখ, যা ফুরালে আবার পর্যালোচনা হবে
• অনুমোদনকারী: ঝুঁকি যাঁর, সেই risk owner, শুধু engineer নন
• Risk register-এ এন্ট্রি, আর হামলার খবর এলে ছাড় বাতিলের শর্ত

EOL software: patch আর আসবে না

End of life মানে নির্মাতা আর নিরাপত্তা update দেবেন না। এটি কোনো scanner-এর একক ফলাফল নয়, একটি স্থায়ী ঝুঁকি, কারণ প্রতিটি নতুন ত্রুটি চিরকাল খোলা থাকবে। উপায়: EOL-এর তারিখ inventory-তে রাখা, আগে থেকে বদলের বাজেট করা, না গেলে আলাদা network-এ সরিয়ে রাখা, আর সময় কেনার মতো অর্থের বিনিময়ে বর্ধিত support থাকলে সেটি যাচাই করা। KEV-এর নির্দেশনাও বলে, পণ্য EOL হলে বা update সম্ভব না হলে সেটি network থেকে সরিয়ে ফেলতে। Legacy system বাদ দেওয়া ব্যবসায়িক সিদ্ধান্ত, তাই দায়ও ব্যবসার।

৯ · Zero-day সপ্তাহ — Log4Shell থেকে শিক্ষা

Zero-day-তে fix নেই বা সবে এসেছে। N-day-তে fix আছে, কিন্তু বসানো হয়নি। আসল হামলার বড় অংশ এই দ্বিতীয় দলে পড়ে বলে নানা প্রতিবেদনে বলা হয়, তাই নিয়মিত কাজটিই প্রথম প্রতিরক্ষা। তবু বড় zero-day এলে পুরো প্রতিষ্ঠান থমকে যায়।

২০২১ সালের ডিসেম্বরে প্রকাশিত Log4Shell (CVE-2021-44228) তার সবচেয়ে বড় উদাহরণ। Apache Log4j 2 হলো Java জগতের বহুল ব্যবহৃত logging library. ত্রুটিটির CVSS 10.0. ধারণাটি হলো, log-এ লেখা নির্দিষ্ট ধরনের text-কে library শুধু লেখা হিসেবে না রেখে একটি নির্দেশ হিসেবে ব্যাখ্যা করত। Log-এ তো ব্যবহারকারীর ইনপুট প্রায়ই লেখা হয়, তাই ঝুঁকি ছড়িয়ে পড়ে। বিস্তারিত হামলার ধাপ এখানে দরকার নেই। প্রতিরক্ষার শিক্ষাগুলোই আসল:

• কোথায় আছে কেউ জানতেন না। Log4j অনেক app-এ সরাসরি ছিল না, ছিল transitive dependency হয়ে, বা অন্য JAR-এর ভেতরে গুঁজে, বা vendor-এর পণ্যের ভেতরে।
• প্রথম fix শেষ fix নয়। 2.15.0-এর পরও আরও version আসে, কারণ পরে CVE-2021-45046 সহ আরও ত্রুটি ধরা পড়ে। তাই প্রথম দিনের সমাধান আবার যাচাই করতে হয়েছে।
• দীর্ঘ লেজ। মার্কিন Cyber Safety Review Board-এর ২০২২ সালের জুলাইয়ের রিপোর্ট একে “endemic” দুর্বলতা বলে, যা হয়তো এক দশক বা আরও বেশি সময় থেকে যাবে। সেই রিপোর্টই বলে, গুরুত্বপূর্ণ অবকাঠামোতে বড় হামলা বোর্ডের জানা ছিল না। অবশ্য রিপোর্ট করার বাধ্যবাধকতা না থাকায় এই তথ্যের সীমা আছে।

এবার একটি কাল্পনিক অনলাইন বাজারের zero-day সপ্তাহ দেখুন। ঘটনাটি বানানো, আর লাইব্রেরির নামও দেওয়া হয়নি। Log4Shell-এর পরিচিত ধরনটি মাথায় রেখে সাজানো।

SBOM-এর কাছে যে প্রশ্নগুলো করবেন

SBOM হলো software-এর উপকরণের তালিকা, বিস্কুটের প্যাকেটের গায়ে লেখা উপাদানের মতো। SPDX আর CycloneDX দুটি প্রচলিত ফরম্যাট। বিস্তারিত পর্ব ৪৮-এ। Zero-day-র দিনে দরকার এই প্রশ্নগুলোর দ্রুত উত্তর:

• এই component কোন কোন পণ্য আর image-এ আছে, কোন version?
• সরাসরি, নাকি transitive?
• সেই পণ্য এখন কোথায় চলছে, internet-মুখী কি না, মালিক কে?
• দুর্বল অংশটি সত্যিই চলে কি? Vendor কি VEX বা বিবৃতি দিয়েছেন?
• SBOM-টি কবেকার, আর চলমান system-এর সাথে মেলে তো?

১০ · AI-এর যুগে vulnerability management

AI লম্বা advisory সংক্ষেপ করতে, ticket লিখতে আর rollback পরিকল্পনার খসড়া করতে দারুণ। কিন্তু এই কাজে একটি ভুল নম্বর সরাসরি ভুল সিদ্ধান্তে নিয়ে যায়। আর এই ক্ষেত্রে সত্য প্রতিদিন বদলায়।

AI-এর সাহায্য নিলে — চেকলিস্ট

• প্রতিটি CVE নম্বর আর fixed version মূল উৎসে মিলিয়েছি
• অন্তত একটি CVSS vector নিজে পড়ে বা হিসাব করে দেখেছি
• Scan রিপোর্ট, secret বা ব্যক্তিগত তথ্য পেস্ট করিনি
• AI-এর দেওয়া fix-এর diff পড়েছি আর নিজের পরীক্ষা পরিবেশে চালিয়েছি
• Ticket বন্ধ, exception আর production পরিবর্তনের সিদ্ধান্ত একজন মানুষ নিয়েছেন