Threat modeling — STRIDE, attack surface আর কোন ঝুঁকি আগে

১ · তালা কেনার আগে ঘরটা দেখুন — threat modeling কী

ধরুন আপনি মিরপুরে নতুন একটি বাসা ভাড়া নিলেন। প্রথম দিনেই বাজারের সবচেয়ে দামি তালা কিনে সদর দরজায় লাগালেন। কিন্তু রান্নাঘরের জানালায় গ্রিল নেই, ছাদের দরজা খোলা, আর চাবির একটি কপি আগের ভাড়াটিয়ার কাছে রয়ে গেছে। তালাটি ভালো, কিন্তু টাকা খরচ হয়েছে ভুল জায়গায়।

বুদ্ধিমান মানুষ আগে ঘরটি ঘুরে দেখেন। কী কী রক্ষা করার আছে? কোন কোন পথে ঢোকা যায়? কোন ঝুঁকিটি সবচেয়ে বাস্তব? তারপর ঠিক করেন, আগে গ্রিল, পরে তালা। সফটওয়্যারের জন্য এই কাজটির নাম threat modeling.

পর্ব ২-এ আপনি threat, vulnerability আর risk-এর ভাষা শিখেছেন, আর পর্ব ৩-এ মূলনীতিগুলো। এই পর্বে সেই ভাষা কাজে লাগবে একটি প্রশ্নের উত্তরে: এই নির্দিষ্ট সিস্টেমে কোন নীতিটি কোথায় লাগবে?

এখানে একটি শব্দের ব্যাপারে সতর্ক থাকুন। কেউ কেউ “threat” বলতে সম্ভাব্য ঘটনা বোঝান, যেমন “জাল পেমেন্ট বার্তা গ্রহণ”। আবার threat intelligence-এর দলে শব্দটি প্রায়ই মানুষ বা দলকে বোঝায়, যাকে বলে threat actor. এই পর্বে threat মানে সম্ভাব্য ক্ষতিকর ঘটনা।

চারটি প্রশ্ন

Threat modeling শুনতে ভারী লাগে, কিন্তু Adam Shostack পুরো কাজটিকে চারটি সাধারণ প্রশ্নে এনেছেন। তাঁর ২০১৪ সালের বই Threat Modeling: Designing for Security-এর মাধ্যমে কাঠামোটি ছড়িয়ে পড়ে। প্রশ্নের ভাষা সময়ের সাথে একটু বদলেছে, আজকের রূপটি নিচে:

Shostack নিজে লিখেছেন, “what are we building” না বলে “working on” বলা ইচ্ছাকৃত: “building” শব্দটি মানুষকে একবারে-সব-নকশা ধারার দিকে টানে, অথচ চলমান সিস্টেমেও এই প্রশ্ন খাটে। আর “you” বদলে “we” করা হয়েছে, কারণ কাজটি দলের। Threat Modeling Manifesto-ও এই চার প্রশ্ন গ্রহণ করেছে, যদিও সেখানে শেষ প্রশ্নটির রূপ “Did we do a good enough job?”

২ · প্রশ্ন ১: সিস্টেমের ছবি — DFD আর trust boundary

না দেখে পাহারা দেওয়া যায় না। তাই প্রথম কাজ ছবি আঁকা। সবচেয়ে প্রচলিত ছবি data flow diagram, সংক্ষেপে DFD. এতে ক্লাস, ফাংশন বা server-এর নাম মুখ্য নয়। মুখ্য হলো ডেটা কোথা থেকে কোথায় যায়। পোস্ট অফিসে একটি চিঠির পথ যেভাবে আঁকবেন, ঠিক তেমন। DFD-র উপাদান মাত্র চারটি, সাথে একটি বিশেষ দাগ:

এবার একটি কাল্পনিক অনলাইন বাজারের checkout নিন। গ্রাহক কার্ট থেকে অর্ডার দেন, বাইরের একটি পেমেন্ট গেটওয়ে টাকা নেয়, আর support কর্মীরা refund করেন। পুরো পর্বে আমরা এই সিস্টেমই ব্যবহার করব। নিচের ছবিটি ধাপে ধাপে তৈরি হবে। “পরে” চাপুন।

ছবিটি নিখুঁত হওয়া জরুরি নয়। Manifesto-র একটি সতর্কবার্তাই হলো “perfect representation”-এর পেছনে ছোটা। লক্ষ্য হলো দলের সবার মাথায় একই ছবি থাকা। ছবির পাশে অনুমানগুলোও লিখে রাখুন, যেমন “গেটওয়ের সাথে HTTPS ব্যবহার হয়” বা “support কর্মীরা অফিসের network থেকেই ঢোকেন”। অনেক threat লুকিয়ে থাকে ভুল অনুমানে।

৩ · প্রশ্ন ২: STRIDE — কোন অক্ষর কোন গুণ ভাঙে

ফাঁকা কাগজের সামনে “কী ভুল হতে পারে?” প্রশ্নটি খুব বড়। মানুষ তখন চেনা বিপদ ছাড়া কিছু ভাবতে পারেন না। STRIDE এই সমস্যার সহজ ওষুধ: ছয়টি অক্ষর, ছয়টি প্রশ্ন। প্রতিটি অক্ষর একটি নিরাপত্তা-গুণ ভাঙে।

STRIDE কোনো নিখুঁত শ্রেণিবিভাগ নয়, এটি মনে করিয়ে দেওয়ার হাতিয়ার। একটি threat দুই অক্ষরে পড়লে তর্ক করার দরকার নেই; তালিকায় ওঠাটাই আসল। পরিচিত একটি ভুল হলো E-কে শুধু “admin হওয়া” ভাবা। সাধারণ গ্রাহক অন্যের অর্ডার বদলাতে পারলেও সেটি E, আর দেখতে পারলে I-ও বটে।

এবার একটি তীর ধরে ছয়টি অক্ষর হাঁটি। বেছে নিচ্ছি F3: গেটওয়ে থেকে Checkout API-তে আসা “paid” webhook. কারণ এই একটি বার্তা শুনেই সিস্টেম পণ্য পাঠিয়ে দেয়।

STRIDE-per-element: কোথায় কোন অক্ষর

প্রতিটি উপাদানে ছয়টি অক্ষর চালালে কাজ বিশাল হয়। তাই Microsoft-এর চর্চা থেকে এসেছে STRIDE-per-element: উপাদানের ধরন দেখে সাধারণত যেগুলো খাটে, সেগুলো ধরা। নিচের ছকটি বই ও tool-ভেদে সামান্য আলাদা হতে পারে, আর এটি শুরু করার পথ, দেয়াল নয়।

লক্ষ করুন, ওপরের walk-এ আমরা একটি flow-তে ছয়টি অক্ষরই ব্যবহার করেছি। ছক অনুযায়ী S আর R আসলে প্রেরক গেটওয়ের ঘরে, E গ্রহণকারী process-এর ঘরে পড়ে। প্রশ্ন একই, শুধু কোন ঘরে লিখবেন তা আলাদা। নিচের ছোট simulator এই ছকটি আমাদের খেলনা DFD-তে চালায়। এটি শুধু একটি in-memory তালিকা পড়ে; কোনো সিস্টেমের সাথে যোগাযোগ করে না।

// খেলনা DFD: কাল্পনিক অনলাইন বাজারের checkout (শুধু ধারণার জন্য)
const RULES = { external: "SR", process: "STRIDE", store: "TID", flow: "TID" };
const el = {
  customer: { kind: "external", zone: "internet" },
  gateway:  { kind: "external", zone: "partner" },
  support:  { kind: "external", zone: "staff" },
  checkout: { kind: "process",  zone: "app" },
  orders:   { kind: "process",  zone: "app" },
  ordersDb: { kind: "store",    zone: "data" },
  auditLog: { kind: "store",    zone: "data", isLog: true },
};
const flows = [
  ["F1", "customer", "checkout"], ["F2", "checkout", "gateway"],
  ["F3", "gateway", "checkout"],  ["F4", "checkout", "orders"],
  ["F5", "orders", "ordersDb"],   ["F6", "orders", "auditLog"],
  ["F7", "support", "orders"],
];
let total = 0, onBoundary = 0;
for (const [name, e] of Object.entries(el)) {
  // log রাখা store-এ R-ও প্রযোজ্য: log বদলালে অস্বীকারের প্রমাণ হারায়
  const letters = e.isLog ? "TRID" : RULES[e.kind];
  total += letters.length;
  console.log(name.padEnd(9), e.kind.padEnd(8), letters.split("").join(" "));
}
for (const [id, a, b] of flows) {
  const za = el[a].zone, zb = el[b].zone, cross = za !== zb;
  total += RULES.flow.length;
  if (cross) onBoundary += RULES.flow.length;
  const tag = cross ? `CROSSES ${za} -> ${zb}` : "same zone";
  console.log(id, `${a} -> ${b}`.padEnd(20), "T I D ", tag);
}
console.log("Threat questions to ask:", total);
console.log("Of these on boundary-crossing flows:", onBoundary);

৪ · Attack surface — কতগুলো দরজা খোলা, আর কোনগুলো লাগবেই না

আপনার বাসায় যত দরজা-জানালা, পাহারা দিতে হয় তত জায়গায়। ব্যবহার না হওয়া ছাদের দরজাটি ইট দিয়ে গেঁথে ফেললে সেখানে তালাও লাগে না, পাহারাও লাগে না। এই চিন্তাই attack surface: সিস্টেমের সেই সব জায়গার মোট পরিসর, যেখান দিয়ে বাইরের কেউ ডেটা ঢোকাতে, ডেটা বের করতে বা কোনো কাজ করাতে পারে।

Attack surface শুধু API নয়। কয়েকটি স্তরে ভাবুন:

কীভাবে মাপবেন

কোনো একক সর্বজনীন একক নেই। গবেষণায় Michael Howard, Jon Pincus আর Jeannette Wing “relative attack surface” ধারণা নিয়ে কাজ করেছেন, আর Manadhata ও Wing সিস্টেমের entry আর exit point, channel এবং অবিশ্বস্ত ডেটা ধরে একটি metric প্রস্তাব করেছেন। মূল কথাটি সহজ: সব দরজা সমান নয়। লগইন ছাড়া খোলা একটি দরজার ঝুঁকি লগইনের পেছনের দরজার চেয়ে বেশি।

দলের ভেতরের কাজের জন্য একটি সহজ ওজন-ভিত্তিক গণনা যথেষ্ট। নিচের ওজনগুলো ধরে নেওয়া, কোনো মান নয়। লক্ষ্য একই সিস্টেমের আগের আর পরের তুলনা, দুই কোম্পানির তুলনা নয়।

কমেছে (৭১ − ৩৭) ÷ ৭১ ≈ ৪৭.৯ শতাংশ। সংখ্যাটি নিজে থেকে “এতটা নিরাপদ” বলে না, শুধু দেখায় পরিসর ছোট হয়েছে। ছোট পরিসরেও একটি মারাত্মক ত্রুটি থাকতে পারে, আর বড় পরিসরও ভালোভাবে রক্ষিত হতে পারে।

কীভাবে কমাবেন

• বাদ দিন: ব্যবহার না হওয়া endpoint, পুরোনো API version, debug পাতা। সবচেয়ে সস্তা আর সবচেয়ে কার্যকর প্রতিরক্ষা হলো ফিচারটি না রাখা।
• লুকাবেন না, সরান: Admin কাজ internet থেকে সরিয়ে ভেতরের access-এ নিন। শুধু ঠিকানা গোপন রাখা প্রতিরক্ষা নয়।
• আগে পরিচয়, পরে কাজ: ভারী কাজ চালানোর আগে authentication আর স্বাক্ষর যাচাই করুন।
• অধিকার ছোট করুন: প্রতিটি process শুধু দরকারি table আর দরকারি কাজ পাবে।
• ডেটা কম রাখুন: যা রাখছেন না, তা ফাঁস হতে পারে না।
• নজর রাখুন: নতুন endpoint বা নতুন script যোগ হলে তালিকাও বদলাবে। তাই পরিসরের তালিকা একবারের কাজ নয়।

৫ · Attack tree — রক্ষকের চোখে “কীভাবে ঘটতে পারে”

STRIDE ছবি ধরে খোঁজে। Attack tree শুরু হয় উল্টো দিক থেকে: একটি অবাঞ্ছিত ফল ধরে। Bruce Schneier ১৯৯৯ সালে Dr. Dobb's Journal-এ ধারণাটি জনপ্রিয় করেন। গাছের মূলে থাকে লক্ষ্য, আর ডালে সেটি ঘটার সম্ভাব্য পথ। ডাল দুই রকম:

• OR ডাল: যেকোনো একটি পথ যথেষ্ট। তাই রক্ষককে সব পথ বন্ধ করতে হয়। গাছের শক্তি তার সবচেয়ে দুর্বল ডালের সমান।
• AND ডাল: সবগুলো ধাপ একসাথে লাগে। তাই রক্ষক একটি ভাঙলেই পথটি বন্ধ।

এখানে আমরা গাছটিকে ব্যবহার করি রক্ষার মানচিত্র হিসেবে। ডালে ব্যবস্থার দুর্বলতার নাম থাকে, কৌশলের বিবরণ নয়, আর প্রতিটি ডালের পাশে থাকে প্রতিরক্ষা। প্রচেষ্টার সংখ্যাগুলো ধরে নেওয়া আপেক্ষিক মান, ১ থেকে ৯ মাপে।

গাছটি দিয়ে হিসাব করুন। OR-এ সর্বনিম্ন, AND-এ যোগফল নিই। প্রচেষ্টা যত বেশি, রক্ষা তত ভালো।

শিক্ষাটি পরিষ্কার। সবচেয়ে সহজ পথ বন্ধ না করে অন্য ডালে যত খরচই করুন, মূলের মান বদলাবে না। আর AND ডালে একটি অংশ শক্ত করলেই পুরো পথ কঠিন হয়। এই কারণেই একটি মাত্র দুর্বল ডাল দিয়ে নিরাপত্তা বিচার হয়, সবচেয়ে শক্ত ডাল দিয়ে নয়।

৬ · কোন ঝুঁকি আগে — DREAD, risk ranking আর likelihood × impact

Threat-এর তালিকা হাতে এলে নতুন সমস্যা: সময় আর টাকা সীমিত। ধানমন্ডির দোকানদার জানেন, ঈদের আগে দোকানে আগে কোন দিকটি সামলাতে হবে। সব বিপদ সমান নয়। এই ক্রম ঠিক করার কয়েকটি উপায় আছে, আর প্রত্যেকটির দুর্বলতাও আছে।

DREAD আর কেন সে পিছিয়ে পড়ল

DREAD Microsoft-এর প্রথম দিকের নিরাপত্তা-উদ্যোগের সময় এসেছিল, আর Howard ও LeBlanc-এর Writing Secure Code বইয়ের মাধ্যমে পরিচিত হয়। পাঁচটি প্রশ্নে স্কোর দিয়ে গড় নেওয়া হয়: Damage (ক্ষতি কত), Reproducibility (কত সহজে আবার ঘটে), Exploitability (কত সহজে ঘটানো যায়), Affected users (কতজন আক্রান্ত), Discoverability (কত সহজে খুঁজে পাওয়া যায়)। স্কোরের মাপ উৎসভেদে আলাদা, কোথাও ০–১০, কোথাও ১–৩।

সমস্যা দেখুন। একই threat-কে দুজন রিভিউয়ার দুভাবে দেখলেন, মতভেদ শুধু একটি ঘরে:

একই সমস্যা, দুই সিদ্ধান্ত। Shostack-এর ২০১৮ সালের লেখা অনুযায়ী, মাঝের স্কোরে মানুষ একমত হন না, আর discoverability সময়ের সাথে বদলায়। আরেকটি বড় অসুবিধা ছিল বাইরের গবেষকদের জানানো ত্রুটিতে: এক ত্রুটি দুই পদ্ধতিতে দুই মান পেত। তিনি লিখেছেন, এই অভিজ্ঞতাই Microsoft-কে bug bar পদ্ধতির দিকে নিয়ে যায়, যেখানে আগে থেকে লেখা থাকে কোন ধরনের ত্রুটি কত গুরুতর। ঠিক কবে এবং কোন আনুষ্ঠানিক ঘোষণায় এই বদল হয়েছিল, তার নিশ্চিত তথ্য আমরা পাইনি। তবে DREAD পুরোপুরি হারিয়ে যায়নি, কিছু দল এখনো এটি বা এর রূপান্তর ব্যবহার করে। Discoverability নিয়ে আরেকটি নীতিগত আপত্তি হলো, এটি “লুকানো আছে, তাই নিরাপদ” ভাবনাকে পুরস্কার দেয়, যা পর্ব ৭-এর Kerckhoffs-এর নীতির উল্টো।

Likelihood × impact

সবচেয়ে প্রচলিত হিসাবটি সহজ: likelihood (ঘটার সম্ভাবনা) আর impact (ঘটলে ক্ষতি), দুটিই ১ থেকে ৫ মাপে, তারপর গুণ।

এই পর্বে আমরা ধরে নিচ্ছি: ১৫ বা বেশি উঁচু, ৮ থেকে ১৪ মাঝারি, ৭ বা কম নিচু। এই risk matrix-এর সীমা প্রতিষ্ঠানভেদে আলাদা। সংজ্ঞাও এক নয়: NIST SP 800-30 ঝুঁকিকে সম্ভাবনা আর প্রভাবের ফল হিসেবে দেখে, ISO 31000 একে অনিশ্চয়তার প্রভাব বলে, আর অনেক বই threat × vulnerability × asset-এর মতো রূপ লেখে। পরীক্ষায় যে সংজ্ঞা চাওয়া হয়েছে, সেটি অনুসরণ করুন।

Risk ranking আরও সহজও হতে পারে। শুরুতে দল শুধু উঁচু, মাঝারি, নিচু বলে সাজাতে পারে, অথবা তালিকায় দুটি করে threat তুলনা করে বলতে পারে কোনটি আগে। ছোট দলে এটিই প্রায়ই যথেষ্ট।

সিদ্ধান্তও শুধু “ঠিক করা” নয়। প্রতিটি threat-এর জন্য সাধারণত চারটি পথ থাকে:

প্রতিরক্ষার পরেও যা থেকে যায়, তা residual risk. কেউ যেন চুপচাপ না মানে, তাই “accept” সবসময় নাম আর তারিখসহ লিখে রাখুন। আর CVSS-এর সাথে গুলিয়ে ফেলবেন না: CVSS পরিচিত vulnerability-র তীব্রতা মাপে (পর্ব ৩২), threat model নকশার ঝুঁকি খোঁজে। টাকার হিসাবে ঝুঁকি মাপার পদ্ধতি FAIR আসবে পর্ব ৬৮-তে।

৭ · প্রশ্ন ৩ আর ৪: threat থেকে test আর backlog

অনেক threat model এখানেই মারা যায়: একটি সুন্দর দলিল, শেয়ার্ড ড্রাইভে ঘুমিয়ে। মহল্লার পাহারা কমিটি বসে যদি শুধু আলোচনা করে, কিন্তু কারও নামে কোনো দায়িত্ব না পড়ে, তাহলে রাতে কেউ পাহারা দেবে না। সফটওয়্যারে দায়িত্ব মানে backlog item, আর প্রমাণ মানে test. নিচে T1 threat-টিকে ধাপে ধাপে কাজে বদলানো দেখুন।

T1 (F3, S+T)
Actor : যে কেউ, যে webhook ঠিকানাটি জানে
Action: গেটওয়ে না হয়েও একটি "paid" বার্তা পাঠানো
Why   : আমরা বার্তার উৎস যাচাই করি না
Impact: টাকা ছাড়াই পণ্য বের হয়
Asset : বিক্রির টাকা, মজুদ

Risk     : 4 x 5 = 20 (উঁচু)
Decision : mitigate
Owner    : payment দল
Residual : L=1, I=5 --> 5

REQ-T1-a  স্বাক্ষর না মিললে বার্তা বাতিল, অর্ডার অপরিবর্তিত
REQ-T1-b  amount অর্ডারের মোটের সমান না হলে অর্ডার আটকে alert
REQ-T1-c  একই event id দ্বিতীয়বার এলে কোনো কাজ নয়
REQ-T1-d  প্রতিটি বাতিল বার্তা log হবে

TC-T1-1  (নিজের test পরিবেশ)
Given  order ORD-1001 আছে, status=pending, total=1200
When   স্বাক্ষরহীন একটি paid বার্তা test API-তে আসে
Then   উত্তর 401
And    ORD-1001-এর status এখনো pending
And    log-এ "webhook_rejected" আছে

SEC-41  Webhook স্বাক্ষর আর পরিমাণ যাচাই
Priority : উঁচু (T1, risk 20)
Estimate : 2 person-day
Owner    : payment দল
Done when: TC-T1-1 থেকে TC-T1-4 CI-তে সবুজ
           key rotation-এর নিয়ম লেখা হয়েছে

T1  status: closed-by-test   evidence: TC-T1-1..4
    residual: 5 (accepted, payment দল)
    review  : গেটওয়ে বদলালে আবার দেখতে হবে
Alert: webhook_rejected হঠাৎ বাড়লে on-call জানবে

“ভালো হলো কি না” যাচাইয়ের আরও কিছু প্রশ্ন: ছবিটি কি আজকের সিস্টেমের সাথে মেলে? প্রতিটি threat-এর কি সিদ্ধান্ত আছে? সব উঁচু ঝুঁকির কি test আছে? দলের বাইরের একজন পড়ে কি বুঝবেন? পরে কোনো incident হলে সেটি মডেলে ছিল কি না মিলিয়ে দেখুন; না থাকলে মডেলে যোগ করুন। Incident থেকে শেখার ধারা Cloud & DevOps কোর্সে দেখতে পারেন, আর এই কোর্সে পর্ব ৬১-তে আসবে।

৮ · দলের কাজে threat modeling, আর অন্য পদ্ধতি

বড় অনুষ্ঠানের মতো বছরে একবার threat modeling করলে কাজ হয় না, কারণ সিস্টেম প্রতি সপ্তাহে বদলায়। Manifesto-র নীতি হলো “early and often”, আর দলের চলমান কাজের ধারার সাথে মিলিয়ে ছোট ছোট অংশে করা। বাস্তবে এটি এমন দেখায়:

সময়গুলো দিকনির্দেশনার জন্য, কোনো মান নয়। বৈঠকে developer, tester, operations, আর সম্ভব হলে support ও ব্যবসার একজন রাখুন। Refund-এর ফাঁক প্রায়ই support কর্মীই সবচেয়ে ভালো জানেন। ছবি রাখুন কোডের পাশে, যাতে পরিবর্তনের সাথে সেটিও বদলায়। Threat register-কেও সাধারণ ফাইল বা issue হিসেবে রাখা যায়। পুরো secure SDLC-তে এর জায়গা দেখবেন পর্ব ৪৫-এ, আর CI/CD-র দিকটি DevSecOps পর্বে।

অন্য পদ্ধতি — একটি সংক্ষিপ্ত নোট

STRIDE একমাত্র পথ নয়। কাজ অনুযায়ী অন্যগুলোও দেখা যায়:

Tool হিসেবে খোলা উৎসের OWASP Threat Dragon বা Microsoft Threat Modeling Tool-এর মতো জিনিস আছে, তবে হোয়াইটবোর্ড আর একটি মার্কারও চলে। Tool চিন্তার জায়গা নিতে পারে না; এটি Manifesto-র মূল কথাগুলোর একটি।

৯ · পূর্ণ উদাহরণ — কাল্পনিক বাজারের checkout

এবার সব জোড়া দিই। একটি কাল্পনিক অনলাইন বাজারের দল ঈদের আগে নতুন checkout চালু করবে। তাদের হাতে এক sprint-এ ৮ person-day নিরাপত্তার কাজের সময়। সব স্কোর উদাহরণের জন্য ধরে নেওয়া।

প্রশ্ন ১ — কী নিয়ে কাজ করছি? Scope হলো অংশ ২-এর DFD. Scope-এর বাইরে: বিক্রেতার panel. অনুমান: কার্ডের তথ্য গেটওয়ের পাতাতেই নেওয়া হয়, আমাদের কাছে আসে না; গেটওয়ের সাথে একটি গোপন key ভাগ করা আছে; support কর্মীরা নিজ account-এ ঢোকেন। সম্পদ: বিক্রির টাকা, গ্রাহকের ফোন-ঠিকানা, অর্ডারের সঠিকতা, ঈদের সময় সেবা চালু থাকা।

প্রশ্ন ২ — কী ভুল হতে পারে? দল ৪৬টি প্রশ্ন ধরে এগিয়ে এই সাতটি threat লিখল:

প্রশ্ন ৩ — কী করব? দলের নিয়ম দুটি: ঝুঁকি ১৫ বা বেশি হলে আগে, বড় থেকে ছোট ক্রমে; বাকিগুলো সাজানো হবে প্রতি person-day-তে কতটা ঝুঁকি কমে তা দিয়ে। নিচের tool ঠিক এই হিসাব করে। left হলো প্রতিরক্ষার পরের ধরে নেওয়া ঝুঁকি, আর /day হলো (risk − left) ÷ days. এটি খেলনা হিসাব, in-memory তালিকার ওপর।

// সব স্কোর ধরে নেওয়া: L, I = 1..5; rL, rI = প্রতিরক্ষার পরে; days = person-day
const threats = [
  { id: "T1", fix: "Verify webhook signature+amount", L: 4, I: 5, rL: 1, rI: 5, days: 2 },
  { id: "T2", fix: "Price from server only",          L: 4, I: 4, rL: 1, rI: 4, days: 1 },
  { id: "T3", fix: "Ownership check on orders",       L: 3, I: 5, rL: 1, rI: 5, days: 2 },
  { id: "T4", fix: "Two-person refund approval",      L: 3, I: 4, rL: 1, rI: 4, days: 3 },
  { id: "T5", fix: "Rate limit and queue checkout",   L: 3, I: 3, rL: 2, rI: 2, days: 2 },
  { id: "T6", fix: "Append-only audit log",           L: 2, I: 4, rL: 1, rI: 4, days: 2 },
  { id: "T7", fix: "Mask phone/address in logs",      L: 3, I: 3, rL: 1, rI: 3, days: 1 },
];
const MUST = 15, BUDGET = 8; // নীতি: ঝুঁকি >= 15 হলে আগে; এই sprint-এ 8 দিন
for (const t of threats) {
  t.risk = t.L * t.I;
  t.left = t.rL * t.rI;
  t.perDay = (t.risk - t.left) / t.days;
}
const must = threats.filter(t => t.risk >= MUST).sort((a, b) => b.risk - a.risk);
const rest = threats.filter(t => t.risk < MUST).sort((a, b) => b.perDay - a.perDay);
let used = 0, n = 0;
const later = [];
console.log("#  id risk left /day days  mitigation");
for (const t of [...must, ...rest]) {
  if (used + t.days > BUDGET) { later.push(t); continue; }
  used += t.days;
  console.log(String(++n).padEnd(2), t.id, String(t.risk).padStart(4),
    String(t.left).padStart(4), t.perDay.toFixed(1).padStart(4),
    String(t.days).padStart(4), " " + t.fix);
}
console.log("Days used:", used, "of", BUDGET);
for (const t of later)
  console.log("Next sprint:", t.id, "risk", t.risk, "-", t.fix);

দল আলোচনা করে ক্রমটি রাখল, কারণ ঈদের ভিড়ে T5-এর দাম বেশি। তবে T4-এর জন্য একটি অস্থায়ী নিয়ন্ত্রণ যোগ করল। চূড়ান্ত তালিকা:

প্রশ্ন ৪ — কাজটি কি ভালো হলো? Release-এর আগে দল মিলিয়ে দেখল উঁচু তিনটির test সবুজ, DFD-তে একটি নতুন flow বাদ পড়েনি, আর T4-এর অস্থায়ী নিয়ন্ত্রণের একজন মালিক আছেন। ঈদের পরে তারা মডেলটি আবার খুলবে। এটিই পুরো চক্র: একটি ছবি, সাতটি threat, পাঁচটি কাজ, আর দুটি লিখিত স্থগিত সিদ্ধান্ত।

১০ · AI-এর যুগে threat modeling

AI threat model-এর খসড়া খুব দ্রুত বানাতে পারে, আর ভুলে যাওয়া প্রশ্ন মনে করিয়ে দিতে পারে। কিন্তু AI আপনার ব্যবসা জানে না, আপনার সিস্টেম দেখে না, আর ভুল উত্তরও আত্মবিশ্বাসের সাথে দেয়। তাই একে ভাবুন দ্রুত লিখতে পারা একজন নতুন সহকর্মী হিসেবে, যাঁর সব কাজ যাচাই করতে হয়।

AI-এর threat model হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি threat আমার DFD-র একটি নির্দিষ্ট উপাদানের সাথে মিলিয়েছি
• ব্যবসার নিয়মের ঝুঁকি (দাম, refund, অনুমোদন) নিজে আলাদা করে ভেবেছি
• উল্লেখ করা CVE আর standard মূল উৎসে খুঁজে পেয়েছি
• Prompt-এ কোনো secret বা ব্যক্তিগত তথ্য দিইনি
• প্রস্তাবিত কোড বা config-এর diff পড়েছি, আর নিজের test পরিবেশে চালিয়েছি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত একজন মানুষ নিয়েছেন, আর নাম লেখা আছে