Threat Model Document
Threat Model Document
নিজের কোনো প্রজেক্টের জন্য একটা সম্পূর্ণ, পেশাদার-মানের threat model document লিখুন — system overview থেকে STRIDE pass, risk ranking, আর প্রতিটা threat-কে module-এর নির্দিষ্ট lesson-এ mitigation হিসেবে map করা পর্যন্ত।
কেন এই প্রজেক্ট
আগের লেসনে STRIDE শিখেছেন NoteShare নামের একটা কাল্পনিক system দিয়ে — পড়া সহজ, কারণ example-টা কেউ একজন আগে থেকেই সাজিয়ে দিয়েছে। আসল পরীক্ষা তখনই শুরু হয় যখন সামনে কেউ diagram এঁকে দেয় না, কেউ বলে দেয় না কোন আটটা row হবে — শুধু আপনার নিজের, অসম্পূর্ণ, half-documented কোনো প্রজেক্ট থাকে, আর প্রশ্নটা থাকে: এখানে ঠিক কী ভুল হতে পারে?
এই প্রজেক্টে কোনো নতুন কোড লিখবেন না। বরং সবচেয়ে কঠিন এবং সবচেয়ে কম-অনুশীলিত দক্ষতাটা অনুশীলন করবেন — নিজের বা পরিচিত কোনো real system-এর জন্য গোড়া থেকে শেষ পর্যন্ত একটা সম্পূর্ণ threat model document লেখা, এমনভাবে যা আসলেই একটা engineering team ব্যবহার করতে পারবে। প্রতিটা section-এ একটা করে “worked example” থাকবে — একটা illustrative SaaS note-taking app যাকে আমরা এখানে QuickNote বলব (আগের লেসনের NoteShare-এরই একটা বড়, বাস্তবঘেঁষা সম্প্রসারণ — search, password-reset email, আর session store যোগ করা হয়েছে) — কিন্তু আসল deliverable সেটা না, আসল deliverable আপনার নিজের প্রজেক্টের document।
আর সবচেয়ে গুরুত্বপূর্ণ প্রাপ্তিটা document-টা নয়, অভ্যাসটা। এই মডিউলের বাকি ১৯টা লেসন — cryptography থেকে memory safety পর্যন্ত — প্রতিটাই একটা নির্দিষ্ট mitigation শেখায়। কিন্তু কোন mitigation কোথায় দরকার, সেই প্রশ্নের উত্তর কোনো লেসন একা দেয় না — সেটা দেয় থ্রেট মডেল। এই প্রজেক্ট শেষ হলে আপনার হাতে থাকবে একটা reusable skill: যেকোনো নতুন system দেখে, প্রায় যান্ত্রিকভাবে, কোথায় বেশি বিনিয়োগ করবেন সেই সিদ্ধান্ত নেওয়া।
ধাপে ধাপে
১. System overview ও scope
প্রথমেই ঠিক করুন কী নিয়ে লিখছেন — একটা গোটা company না, একটা নির্দিষ্ট system বা service। খুব বড় scope নিলে document কখনো শেষ হবে না; খুব ছোট নিলে trust boundary-ই থাকবে না বিবেচনা করার মতো। ভালো scope-এর আকার: একটা backend service, একটা mobile app + তার API, বা একটা নির্দিষ্ট নতুন feature যেটা কয়েকটা component ছুঁয়ে যায়।
Overview section-এ চারটা জিনিস লিখুন:
- এক-প্যারাগ্রাফ বর্ণনা — system কী করে, কারা ব্যবহার করে
- Component/service তালিকা — প্রতিটা আলাদা প্রসেস, database, third-party integration যার সাথে system কথা বলে
- Adversary model — কে আক্রমণ করতে পারে? (anonymous external, authenticated user, insider/compromised-service — আগের লেসনের তিন স্তর মনে করুন)
- Trust boundary তালিকা — কোথায় কোথায় বিশ্বাসের স্তর বদলায়
নিজের প্রজেক্ট না থাকলে, বা এখনো ছোট বলে যথেষ্ট জটিল না মনে হলে, QuickNote-কে নিজের প্রজেক্ট ধরে পুরো ব্যায়ামটা করুন — কাঠামোটা শিখে নেওয়াই আসল লক্ষ্য।
Worked example — QuickNote system overview:
QuickNote একটা note-taking web app। User account বানিয়ে login করে, note লেখে, ছবি/PDF attach করে, চাইলে একটা note অন্য কাউকে link দিয়ে share করে, আর নিজের সব note-এর ভেতর keyword দিয়ে search করতে পারে। Password ভুলে গেলে email-এ reset link পাঠানো হয়। একজন admin user-account manage করে।
| Component | ধরন | কাজ |
|---|---|---|
| Web App / Backend API | Process | সব business logic — auth, note CRUD, search, share |
| Database (Postgres) | Data store | User, note, session-metadata |
| File Storage (S3-জাতীয়) | Data store | Uploaded ছবি/PDF |
| Session Store (Redis) | Data store | Active session token → user-id lookup |
| Admin Panel | Process | User-account management (আলাদা privileged UI) |
| Email/SMTP Service | External (third-party) | Password-reset email পাঠানো |
| Browser | External entity | Anonymous visitor বা logged-in user |
Adversary model তিন স্তর: (১) anonymous internet visitor, (২) authenticated user যে অন্য user-এর ডেটা বা admin-ক্ষমতা চায়, (৩) কোনো একটা compromised dependency বা internal service (উদাহরণ: image- processing library-তে RCE)।
Checkpoint: আপনার overview section-এ component তালিকা, adversary model, আর কমপক্ষে দুইটা trust boundary স্পষ্টভাবে লেখা আছে কিনা যাচাই করুন — কেউ আপনাকে না চিনেও শুধু এই section পড়ে system-টা কল্পনা করতে পারলে section-টা যথেষ্ট।
২. Asset ও data classification
প্রতিটা system-এ কিছু জিনিস আছে যা হারালে বা ফাঁস হলে বাস্তব ক্ষতি হয় — সেগুলোই asset। প্রতিটা asset-কে অন্তত তিনটা প্রশ্নে classify করুন: এটা কী ধরনের ডেটা (credential / PII / business data / availability)? কে দেখতে পারবে (public / internal / owner-only / admin-only)? ফাঁস বা নষ্ট হলে ক্ষতির মাত্রা কেমন (low / medium / high / critical)?
Worked example — QuickNote asset classification:
| Asset | ধরন | দেখতে পারবে | ফাঁস হলে ক্ষতি |
|---|---|---|---|
| Password hash | Credential | কেউ না (সরাসরি) | Critical — offline crack চেষ্টা সম্ভব হয় |
| Session token | Credential | শুধু owner (browser cookie-তে) | Critical — সরাসরি account takeover |
| Note content | Business data / possibly PII | Owner + যাদের সাথে share করা | High — ব্যক্তিগত/গোপনীয় তথ্য থাকতে পারে |
| Uploaded file | Business data | Owner + share-প্রাপ্ত | High — একই কারণে note content-এর মতো |
| User email | PII | System + user নিজে | Medium — enumeration/phishing-এ ব্যবহারযোগ্য |
| Audit log | Business data | Admin-only | Medium — না থাকলে repudiation, ফাঁস হলে activity-pattern leak |
| Service availability | Availability | সবাই (uptime) | Medium-High — ব্যবসা-নির্ভর কতটা তার ওপর নির্ভর করে |
লক্ষ্য করুন classification-টা শুধু “সব গুরুত্বপূর্ণ” বলে থেমে থাকে না — password hash আর user email দুইটাই sensitive কিন্তু একই মাত্রার না, আর এই পার্থক্যটাই পরের ধাপে risk prioritization-কে দিক দেখাবে।
Checkpoint: আপনার asset তালিকায় কমপক্ষে একটা credential-শ্রেণির, একটা PII/business-data-শ্রেণির, আর availability নিজেই — এই তিন ধরনের asset আলাদা row হিসেবে আছে কিনা দেখুন।
৩. Data flow diagram
Diagram-এর লক্ষ্য জটিল না — চারটা shape যথেষ্ট: external entity (box, system-এর বাইরের কেউ — browser, third-party service), process (round-corner box, ডেটা নিয়ে কিছু করে), data store (দুই-লাইনের box, ডেটা জমা রাখে), আর data flow (তীরচিহ্ন, ডেটা একদিক থেকে আরেকদিকে যায়)। যেখানে তীর একটা trust-level থেকে আরেকটায় পার হয়, সেখানে একটা trust boundary লাইন আঁকুন — এই লাইন পার-হওয়া প্রতিটা তীরই পরের ধাপে STRIDE-এর candidate।
Worked example — QuickNote data flow diagram:
trust boundary #1 (internet ↔ app)
═══════════════════════════════════
┌───────────┐ login/search/share ┌──────────────┐
│ Browser │ ─────────────────────────► │ Backend API │
│(anon/user)│ ◄───────────────────────── │ (process) │
└───────────┘ └───────┬───────┘
│
┌───────────────┬───────────────┼───────────────┐
▼ ▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ Postgres │ │File Storage│ │ Redis │ │ SMTP/Email │
│(data store)│ │(data store)│ │(data store)│ │ (external) │
└────────────┘ └────────────┘ └────────────┘ └────────────┘
trust boundary #2 (app ↔ admin)
═══════════════════════════════
┌───────────┐ manage users ┌──────────────┐
│ Admin │ ─────────────────────────► │ Admin Panel │──► Postgres
│(operator) │ ◄───────────────────────── │ (process) │
└───────────┘ └──────────────┘
trust boundary #3 (app ↔ third-party)
═══════════════════════════════════════
Backend API ──reset-email──► SMTP Service (বাইরের, নিয়ন্ত্রণের বাইরে)তিনটা trust boundary — লেসনে দুইটা ছিল (internet↔app, app↔admin), এখানে তৃতীয়টা যোগ হলো কারণ SMTP service একটা third-party — সেই বিশ্বাসের মাত্রা internal component-এর চেয়ে ভিন্ন, তাই সেটাও নিজের মতো একটা boundary।
Checkpoint: ডায়াগ্রামে প্রতিটা component অন্তত একবার আসছে কিনা, আর প্রতিটা trust boundary-পার-হওয়া arrow স্পষ্টভাবে চিহ্নিত কিনা যাচাই করুন — যা ডায়াগ্রামে নেই তা STRIDE pass-এ ভুলে যাওয়ার সবচেয়ে বড় কারণ।
৪. STRIDE pass — প্রতিটা component-এ, একটাতেও নয়
এইটাই document-এর সবচেয়ে ভারী অংশ। আগের লেসনের নিয়মটা মনে করুন — প্রতিটা element-এ STRIDE-এর প্রাসঙ্গিক subset প্রশ্ন করা, “প্রযোজ্য না” হলেও সেটা একটা লেখা সিদ্ধান্ত, চুপচাপ বাদ দেওয়া না। এবার সেটা পুরো diagram-এর ওপর সিস্টেমেটিকভাবে করুন — শুধু একটা component না, প্রতিটা component আর প্রতিটা boundary-crossing flow-এ।
Worked example — QuickNote-এর সম্পূর্ণ STRIDE pass:
আগের লেসনের আটটা row-এর ওপর ভিত্তি করে, এখানে নতুন component (search, email, session store)-এর জন্য threat যোগ করে পুরো তালিকাটা দাঁড় করানো হলো:
| Component | STRIDE | নির্দিষ্ট threat | Mitigation |
|---|---|---|---|
| Session / login | Spoofing | Predictable token বা credential-stuffing দিয়ে impersonation | Random session id, rate-limit, MFA |
| Note content (write path) | Tampering | IDOR — note_id বদলে অন্যের note edit | Per-object ownership check প্রতিটা write-এ |
| Note content (write path) | Tampering | String-concat query দিয়ে SQL injection | সবসময় parameterized query |
| Delete/upload action | Repudiation | কে করল প্রমাণ নেই, অস্বীকার করা যায় | Append-only audit log, আলাদা storage |
| File storage | Information Disclosure | Sequential path enumerate করে অন্যের ফাইল দেখা | Random storage key + per-access permission check |
| Upload endpoint | Denial of Service | Size-limit-হীন upload দিয়ে disk/CPU নিঃশেষ | Size limit, rate limit, processing timeout |
| Uploaded file serving | Elevation of Privilege | Webroot-এ script হিসেবে চালানো | Webroot-বাইরে storage, fixed content-type |
| Admin panel | Elevation of Privilege | শুধু URL-secrecy, কোনো role-check নেই | Explicit role-check middleware |
| Search endpoint | Tampering | String-concat search query দিয়ে SQL injection | Parameterized query / ORM query-builder |
| Search endpoint | Information Disclosure | Owner-filter ছাড়া search অন্য user-এর note ফেরত দেয় | প্রতিটা search query-তে বাধ্যতামূলক user_id filter |
| Email/SMTP flow | Information Disclosure | Reset-response ভিন্ন হলে (email আছে/নেই) account enumeration সম্ভব | ইমেইল থাকুক বা না থাকুক একই generic response |
| Email/SMTP flow | Denial of Service | Rate-limit ছাড়া বারবার reset-request পাঠিয়ে email-bombing বা SMTP quota শেষ | Per-account ও per-IP rate limit reset-endpoint-এ |
| Session store (Redis) | Information Disclosure | Auth ছাড়া internal network-এ session store expose, compromised service সব session পড়তে পারে | Redis-এ auth চালু, network segmentation, internal-only access |
| Session store (Redis) | Denial of Service | TTL ছাড়া session জমে memory নিঃশেষ | প্রতিটা session-এ expiry/TTL, eviction policy |
চৌদ্দটা row — আগের আটটার ওপরে নতুন ছয়টা, কারণ নতুন component মানেই নতুন প্রশ্ন করার জায়গা। লক্ষ্য করুন প্রতিটা component অন্তত একবার, আর কিছু component (search, email, session store) একাধিকবার আসছে — কারণ একটা component-এ একাধিক STRIDE category প্রযোজ্য হতে পারে, সেটাই স্বাভাবিক।
নিজের document লেখার সময় প্রতিটা component-এর পাশে ছয়টা অক্ষরই মনে-মনে বলে যান — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — এমনকি “এখানে প্রযোজ্য না” হলেও এক লাইনে কেন লিখে রাখুন, ছয় মাস পরে সেই যুক্তিটাই আবার মনে করিয়ে দেবে কেন কিছু বাদ দেওয়া হয়েছিল।
Checkpoint: আপনার document-এ কমপক্ষে পাঁচটা component-এর জন্য সবগুলো STRIDE category বিবেচনা করা হয়েছে কিনা যাচাই করুন — এমনকি “প্রযোজ্য না” লেখা row-ও গণনায় ধরুন, শুধু “চিন্তা করা হয়েছে” প্রমাণ থাকাই দরকার।
৫. Risk prioritization
চৌদ্দটা threat একসাথে ঠিক করার বাজেট কারও নেই — তাই এবার র্যাংক করুন। সহজ সূত্র: Likelihood (১-৫) × Impact (১-৫) = Risk Score। Likelihood মাপুন — কতটা সহজে exploit করা যায়, adversary-র কতটুকু ক্ষমতা লাগে। Impact মাপুন — asset classification (ধাপ ২) থেকে সরাসরি টানুন, critical asset ছুঁলে impact বেশি।
Worked example — QuickNote risk ranking (উপরের তালিকা থেকে শীর্ষ ছয়টা):
| Threat | Likelihood (১-৫) | Impact (১-৫) | Score | র্যাংক |
|---|---|---|---|---|
| Note-edit IDOR (Tampering) | ৪ — কোনো special tool লাগে না, শুধু id বদলানো | ৫ — অন্য user-এর ডেটা সরাসরি বদলে যায় | ২০ | ১ |
| Search/note SQL injection (Tampering) | ৩ — চেনা payload, কিন্তু ORM ব্যবহার হলে auto-block | ৫ — পুরো database-এ read/write | ১৫ | ২ |
| Admin panel role-check অনুপস্থিত (EoP) | ২ — URL গুঁজে পাওয়া লাগে | ৫ — পুরো admin ক্ষমতা | ১০ | ৩ |
| Password-reset user enumeration (Info Disclosure) | ৪ — স্বয়ংক্রিয়ভাবে scan করা সহজ | ৩ — সরাসরি takeover না, কিন্তু targeted attack-এর প্রথম ধাপ | ১২ | ৩ (tie) |
| File-path enumeration (Info Disclosure) | ৩ — sequential id অনুমান | ৪ — private file দেখা যায় | ১২ | ৩ (tie) |
| Session store DoS — TTL নেই (DoS) | ২ — সময় লাগে জমতে | ৩ — availability কমে, ডেটা হারায় না | ৬ | ৬ |
র্যাংকিং-এর সিদ্ধান্ত স্পষ্ট এখন — IDOR আর SQL injection প্রথমে fix হবে, session-TTL সবার শেষে। এইটাই risk-prioritization-এর আসল কাজ: “সব ঠিক করব” থেকে “এই দুইটা আগে, বাকিগুলো এই ক্রমে” — একটা বাস্তব sprint-planning-এ অনুবাদযোগ্য সিদ্ধান্তে বদলে দেওয়া।
Checkpoint: আপনার document-এর সবগুলো threat-এর একটা risk-score আছে, আর top-৩ threat আলাদাভাবে highlight করা আছে কিনা যাচাই করুন — স্কোর ছাড়া তালিকা শুধু একটা brainstorm, স্কোর-সহ তালিকা একটা কাজের-পরিকল্পনা।
৬. Mitigation mapping — module-এর lesson-গুলো এবার কাজে লাগবে
এতদিন যা শিখেছেন সেটার আসল পরীক্ষা এই ধাপ — প্রতিটা উল্লেখযোগ্য threat-এর পাশে শুধু “ঠিক করব” লিখলে চলবে না, ঠিক কোন technique, আর সেই technique-টা এই module-এর কোন লেসনে শেখানো হয়েছে তা নাম করে লিখুন। এটাই document-কে “ভালো নিয়ত”-এর তালিকা থেকে actionable engineering-plan-এ বদলে দেয়।
Worked example — QuickNote mitigation mapping (মডিউলের লেসন-নাম-সহ):
| Threat | Mitigation technique | কোন লেসনে শেখা |
|---|---|---|
| Note-edit IDOR | প্রতিটা write-এ per-object ownership/role check | security/authorization |
| Search/note SQL injection | Parameterized query, কখনো string-concat না | security/injection-attacks |
| Admin panel-এ role-check অনুপস্থিত | Explicit role-check middleware, URL-secrecy না | security/authorization |
| Password-reset user enumeration | Uniform response, timing-consistent handling | security/authentication |
| Session token predictable/spoofable | Cryptographically random token, HttpOnly+Secure+SameSite cookie flag | security/authentication, security/cryptography-fundamentals |
| Password hash দুর্বল/plaintext | Adaptive hash (bcrypt/argon2), salt, work-factor | security/password-storage |
| File-path enumeration | Random storage key (UUID/CSPRNG), owner-check | security/hash-functions, security/cryptography-fundamentals |
| Uploaded file-content tamper/integrity | Content checksum যাচাই আপলোড ও ডাউনলোডে | security/hash-functions |
| Note content transport-এ eavesdrop | TLS বাধ্যতামূলক, weak cipher বন্ধ | security/tls-security |
| Repudiation — কে delete করল প্রমাণ নেই | Append-only, hash-chained audit log | security/hash-functions, security/digital-signatures-pki |
| Note-এ malicious script injected হয়ে অন্য user-এর browser-এ চলা | Output encoding, Content-Security-Policy | security/xss-csrf-ssrf |
| Share-link click-এ state-changing action জোর করে করানো | CSRF token, SameSite cookie | security/xss-csrf-ssrf |
| File-preview ফিচার internal URL fetch করে | SSRF-প্রতিরোধী URL validation, allowlist | security/xss-csrf-ssrf |
| Image-processing native library-তে crafted-file crash | Bounds-checked parsing, fuzz-testing | security/memory-safety-buffer-overflow |
| File-size check integer overflow দিয়ে bypass | Safe-arithmetic check, unsigned-overflow guard | security/integer-overflow-vulnerabilities |
| Native extension-এ freed মেমরি আবার ব্যবহার (crash/RCE) | Ownership discipline, sanitizer-চালিত টেস্ট | security/use-after-free-double-free |
| উপরের সব native-code bug-এর blast radius কমানো | Stack canary, ASLR, NX, CFI বিল্ড-ফ্ল্যাগ | security/mitigations-canaries-aslr-nx-cfi |
| Image-processing subprocess পুরো host-এ RCE ঘটালে | Subprocess sandbox/isolation, least-privilege process user | security/sandboxing-isolation |
| Third-party npm/pip dependency-তে backdoor বা known-CVE | Dependency pinning, lockfile audit, SBOM | security/supply-chain-security |
| Encrypted file-at-rest দরকার (compliance/sensitivity) | Symmetric encryption, key-rotation | security/symmetric-encryption |
| Share-লিংক-এ end-to-end encrypted note দরকার হলে | Public-key encryption note-content-এর ওপর | security/asymmetric-crypto |
| Merge করার আগে এই সব bug ধরার প্রক্রিয়া | Checklist-ভিত্তিক secure code review PR-এ | security/secure-coding-review |
| Shared-hosting/cloud VM-এ cross-tenant তথ্য-leak-এর ঝুঁকি | Infra নির্বাচনে speculative-execution isolation বিবেচনা | security/side-channels-spectre-meltdown |
লক্ষ্য করার মতো: প্রতিটা row-এর ডান কলামে module-এর প্রায় প্রতিটা লেসন অন্তত একবার এসেছে। এটাই এই প্রজেক্টের গোপন উদ্দেশ্য — আপনি সবেমাত্র পুরো security module শেষ করেছেন, কিন্তু আলাদা-আলাদা লেসনে শেখা টুকরাগুলো এখনো একটা connected map হয়ে ওঠেনি। Mitigation mapping সেই map-টাকেই কাগজে নামিয়ে আনে।
Checkpoint: আপনার mitigation-mapping টেবিলে risk-prioritization-এ top-৫-এর মধ্যে থাকা প্রতিটা threat-এর জন্য একটা নির্দিষ্ট technique এবং একটা নির্দিষ্ট lesson-slug লেখা আছে কিনা যাচাই করুন — শুধু “encrypt করব” যথেষ্ট না, “কোন লেসনের কোন primitive দিয়ে” পর্যন্ত নির্দিষ্ট হতে হবে।
৭. Document assembly ও review cadence
শেষ ধাপ — এই সাতটা section-কে একটা document-এ জোড়া দিন, আর সবচেয়ে গুরুত্বপূর্ণ, এটাকে living document হিসেবে ট্রিট করুন, একবারের artifact না। তিনটা practical অভ্যাস:
- Version করুন — প্রতিটা বড় revision-এ একটা version number (v1.0, v1.1…) আর তারিখ, যাতে কেউ জিজ্ঞেস করলে বলতে পারেন “এই threat model কবে শেষবার আপডেট হয়েছিল”
- Review trigger ঠিক করুন — নতুন major feature, নতুন third-party integration, বা architecture-বদল হলেই এই document ফিরে দেখা; পাশাপাশি একটা নিয়মিত interval (যেমন প্রতি quarter) রাখুন পুরনো অংশ revisit করার জন্য, এমনকি কিছু না বদলালেও — লেসনের চার-প্রশ্ন framework-এর চতুর্থ প্রশ্নটাই (“কাজটা ভালো হলো কিনা”) এই loop-এর উৎস
- সহজে খুঁজে পাওয়া যায় এমন জায়গায় রাখুন — repo-র সাথে (যেমন
docs/threat-model.md), যাতে code-review-এর সময় পাশাপাশি খোলা যায়, কোনো আলাদা wiki-তে হারিয়ে না যায়
Document-এর শেষে একটা ছোট “Open questions / accepted risk” section রাখুন — যে threat-গুলো এখনই fix করার মতো priority পায়নি, কিন্তু সচেতনভাবে accept করা হয়েছে, সেগুলো লিখে রাখুন। এইটাই আগের লেসনের misconception-খণ্ডনের ঠিক প্রয়োগ — “perfect security” লক্ষ্য না, সচেতন সিদ্ধান্ত লক্ষ্য।
Checkpoint: আপনার document-এ একটা version/date header আছে, একটা নির্দিষ্ট review-trigger লেখা আছে, আর কমপক্ষে একটা “accepted risk” সচেতনভাবে লেখা আছে কিনা যাচাই করুন।
নিজেকে চ্যালেঞ্জ করুন
- একজন সহকর্মী বা বন্ধুকে দিয়ে আপনার threat model-টা “red-team” করান — উদ্দেশ্য একটাই, কোন component বা flow আপনি একেবারে বাদ দিয়ে গেছেন সেটা খুঁজে বের করা
- এমন একটা system থ্রেট-মডেল করুন যেটা আপনি নিজে বানাননি — একটা open-source project-এর README আর architecture-doc পড়ে বাইরে থেকে একটা STRIDE pass চালান, তারপর maintainer-দের security-doc-এর সাথে তুলনা করুন
- একই system-এর জন্য STRIDE-এর বদলে একটা হালকা framework (যেমন শুধু “top ৫ প্রশ্ন” checklist) দিয়ে আবার চালান — কোনটা দ্রুত, কোনটা বেশি ফাঁক ধরে, লিখে তুলনা করুন
- Risk-prioritization টেবিলটা DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) দিয়ে আবার স্কোর করুন — likelihood×impact-এর র্যাংকিং-এর সাথে কতটা মেলে, কোথায় আলাদা হয়
- আপনার document-এর mitigation-mapping অংশ থেকে সবচেয়ে high-risk একটা item বেছে নিয়ে বাস্তবে implement করুন — শুধু কাগজে না, কোডে
- তিন মাস পরে ক্যালেন্ডারে reminder সেট করে সত্যিকারের review cadence টেস্ট করুন — architecture কতটা বদলেছে, কতগুলো threat এখনো প্রাসঙ্গিক, নতুন কী যোগ করতে হবে
যা এখানে শিখলেন, পরে যেখানে লাগবে
| এখানে | পরে |
|---|---|
| Scope-করা system overview লেখা | Design-review meeting-এ architecture সংক্ষেপে উপস্থাপন করা |
| Asset classification | Compliance/audit-এর প্রথম প্রশ্ন — “কী ধরনের ডেটা রাখেন” |
| Data flow diagram + trust boundary | Security architect-দের সাথে কথা বলার একটা সাধারণ ভাষা |
| সিস্টেমেটিক STRIDE pass | Code-review-এ “এই PR-এ নতুন কোনো threat এল কি” প্রশ্ন করার অভ্যাস |
| Likelihood × impact prioritization | Incident-এর পরে postmortem-এ severity নির্ধারণ |
| Lesson-নাম-সহ mitigation mapping | Ticket লেখার সময় সরাসরি “কোন primitive” নির্দিষ্ট করা |
| Living-document review cadence | Team-এর নিয়মিত security-review process ডিজাইন করা |