এই পর্বে যা শিখবেন
- সম্পদের তালিকা থেকে threat model আর ঝুঁকির খাতা বানানো
- পরিচয়, network, web, software আর detection-এর পরিকল্পনাকে ঝুঁকির সাথে জোড়া
- Incident পরিকল্পনা লেখা আর ৬০ মিনিটের ransomware মহড়া চালানো
- বাজেট আর সময়ের ভেতরে এক বছরের রোডম্যাপ ও বোর্ডের সারাংশ তৈরি করা
- নিজের কাজ মূল্যায়ন করা আর আইনের ভেতরে থেকে অনুশীলনের পথ বেছে নেওয়া
১ · প্রকল্পটি: তাজা বাজারকে নিরাপদ করা
এতদিন আপনি কোর্সের একেকটি বিষয় আলাদা শিখেছেন: তালা, চাবি, পাহারা, খাতা। এবার একটি পুরো বাড়ি সামলাতে হবে। ক্যাপস্টোন মানে শেষের সেই প্রকল্প, যেখানে সব শেখা এক জায়গায় কাজে লাগে। এই প্রকল্পটি পুরোপুরি প্রতিরক্ষামূলক। এখানে কোনো system-এ আক্রমণ নেই, সব কাজ কাগজে, খাতায় আর এই পাতার ছোট সিমুলেটরে।
তাজা বাজার (কাল্পনিক)
ঢাকার একটি অনলাইন মুদি দোকান। ৬০ জন কর্মী, website, mobile app আর নিজস্ব delivery rider.
নাম, মানুষ, সংখ্যা সবই বানানোপ্রযুক্তি
কার্ড আর mobile wallet-এর টাকা আসে একটি payment gateway হয়ে। ছোট একটি cloud deployment-এ API আর database চলে।
Cloud + head officeপ্রধান কার্যালয়
Windows PC, একটি file server, গুদামের printer, আর CCTV-র রেকর্ডার (NVR).
Wi-Fi-তে অতিথিও আসেনআপনার ভূমিকা
মালিক আপনাকে এক বছরের নিরাপত্তা পরিকল্পনা বানাতে বলেছেন। ধরে নেওয়া বাজেট ১৫ লাখ টাকা। দলের হাতে প্রতি প্রান্তিকে ৮ জন-সপ্তাহ সময়।
সব টাকার অঙ্ক অনুমানপুরো কাজটি একটি নিরাপত্তা programme: দশটি ধাপ, তারপর রোডম্যাপ আর বোর্ডের সারাংশ। প্রতি ধাপের ফল পরের ধাপের কাঁচামাল। প্রতিটি ধাপে আগের পর্বের পদ্ধতিই ব্যবহার হবে, তাই আটকে গেলে লিংক ধরে ফিরে যান।
দশ ধাপের নিরাপত্তা programme
Know, build, detect and respond, then run it as a business
আপনার স্তরে কোন ধাপগুলো করবেন
| স্তর | যা করবেন | ফলাফল |
|---|---|---|
| শুরুর স্তর | ধাপ ১, ধাপ ২ (শুধু পেমেন্ট flow), ধাপ ৩ (৩টি ঝুঁকি), ধাপ ৪-এর MFA অংশ, আর ধাপ ৯-এর মহড়া পড়ে উত্তর লেখা | ৫টি ছোট নথি |
| মাঝের স্তর | ধাপ ১ থেকে ৯ পুরো, আর ধাপ ১০-এর vendor তালিকা | ৯টি নথি, ৫টি detection rule-এর পরীক্ষা |
| উন্নত স্তর | সব ধাপ, রোডম্যাপ, বোর্ডের এক পাতা, ঝুঁকিতে Monte Carlo, নিজের ল্যাবে rule চালানো | পুরো programme আর বন্ধুদের নিয়ে একটি মহড়া |
তাজা বাজার কাল্পনিক। কোনো আসল দোকান, website বা app-কে এই প্রকল্পের নমুনা বানিয়ে পরীক্ষা করবেন না। নিরাপত্তা পরীক্ষার জন্য লিখিত অনুমতি লাগে; অনুমতি ছাড়া প্রবেশ অপরাধ। আইনের সীমা আছে পর্ব ৬-এ।
২ · ধাপ ১ আর ২: সম্পদ, ডেটা আর threat model
ধাপ ১ · সম্পদের তালিকা আর ডেটার মানচিত্র
ঘরে কী আছে না জানলে তালা কেনা যায় না। Asset inventory হলো কী কী আছে আর কার দায়িত্বে, তার তালিকা। Data inventory বলে কোন ডেটা কোথায় যায়। পদ্ধতি: পর্ব ২ (CIA), পর্ব ৩২ (সম্পদ), পর্ব ৭০ (ডেটা)।
| সম্পদ | মালিক | ডেটা | C-I-A গুরুত্ব | কোথায়, কতদিন |
|---|---|---|---|---|
| Order database | CTO | নাম, ফোন, ঠিকানা, অর্ডার | উচ্চ-উচ্চ-উচ্চ | Cloud, ৩ বছর (অনুমান) |
| CCTV রেকর্ডার | Admin প্রধান | ছবি, ভিডিও | উচ্চ-মাঝারি-মাঝারি | অফিস, ৩০ দিন |
| Rider app | Ops প্রধান | লোকেশন, ক্রেতার ঠিকানা | উচ্চ-মাঝারি-উচ্চ | ফোন + cloud, ৯০ দিন |
| ……… | ……… | ……… | ……… | ……… |
ধাপ ২ · DFD আর STRIDE
এবার ছবি আঁকুন। Data flow diagram (DFD) দেখায় ডেটা কোন পথে চলে। Trust boundary হলো সেই দাগ, যেখানে বিশ্বাসের মাত্রা বদলায়, যেমন মহল্লার বাইরের রাস্তা আর বাড়ির গেট। প্রতিটি দাগ পার হওয়া flow-তে STRIDE-এর ছয়টি প্রশ্ন করুন। পদ্ধতি আছে পর্ব ৪-এ।
তাজা বাজারের DFD
Dashed lines are trust boundaries; F1 to F5 are flows to analyse
| Flow | STRIDE | কী ভুল হতে পারে | Control | পরীক্ষা |
|---|---|---|---|---|
| F1 | Spoofing | অন্যের অ্যাকাউন্টে login | Rate limit, passkey | লকের নিয়ম test |
| F1 | Info disclosure | অন্যের অর্ডার দেখা | Server-এ মালিকানা যাচাই | দুই test account |
| F3 | Tampering | নকল “paid” বার্তা | HMAC, পরিমাণ মেলানো | ভুল সই প্রত্যাখ্যান |
| F5 | Elevation | কর্মী থেকে admin | JIT, role আলাদা | মাসিক access review |
| ……… | ……… | ……… | ……… | ……… |
ক্যাপস্টোনের মূল দক্ষতা হলো একটি অটুট শিকল: সম্পদ থেকে threat, threat থেকে control, control থেকে পরীক্ষা। একটি পেমেন্ট flow ধরে শিকলটি দেখুন।
- সম্পদঅর্ডারের অবস্থা
- FlowF3 webhook
- ThreatTampering
- Controlসই, পরিমাণ
- পরীক্ষা৪টি case
| অবস্থা | |
| গুণ | |
| খাতায় |
- সম্পদ। অর্ডার ১০৪২-এর অবস্থা
pending. এই একটি শব্দpaidহলেই পণ্য বেরিয়ে যায়, তাই এখানে integrity সবচেয়ে জরুরি। গুদামের দারোয়ানের খাতায় “ছাড়পত্র” লেখার মতো। মালিক হিসাব প্রধান। - Flow. Gateway টাকা পেয়ে আমাদের API-তে একটি webhook পাঠায়, অর্থাৎ নিজে থেকে একটি বার্তা। এটি trust boundary পার হচ্ছে, তাই বার্তাটি নিজে থেকে বিশ্বাসযোগ্য নয়।
- Threat. অবস্থাটি এখন প্রশ্নের মুখে। কেউ gateway সেজে (S) বা বার্তা বদলে (T) জানাতে পারে, টাকা এসেছে। ফল: বিনা টাকায় পণ্য। কৌশল এখানে বিষয় নয়, বিষয় হলো কী রক্ষা করছি। ঝুঁকির খাতায়
R5খোলা হলো। - Control. বার্তা এলে আগে HMAC সই যাচাই, তারপর অর্ডারের পরিমাণ মেলানো। অবস্থা এখনো
pending. এক বার্তা দুবার এলে idempotency দ্বিতীয়টিকে উপেক্ষা করে। রোডম্যাপে এটিC8. - পরীক্ষা। ৪টি case: ঠিক সই হলে
paid; ভুল সই হলে প্রত্যাখ্যান আর alert; পরিমাণ না মিললে আটকে রাখা; একই বার্তা দ্বিতীয়বার এলে কিছু না বদলানো। সব test build-এ চলে, তাই পরে কেউ ভুলে ভাঙতে পারবেন না। - প্রমাণ। অর্ডার এখন
paid. প্রতিদিন gateway-র রিপোর্টের সাথে payment reconciliation হয়। মিল না হলে alert. এই দৈনিক মিলই প্রমাণ যে control চলছে। শিকলের কোনো কড়া ফাঁকা থাকলে নকশাটি অসম্পূর্ণ।
৩ · ধাপ ৩: ঝুঁকির খাতা, টাকার range-এ
Risk register হলো ঝুঁকির হিসাবের খাতা। পদ্ধতি পর্ব ৬৮-এর FAIR-ধাঁচের: দুটি প্রশ্নকে আলাদা করা, আর একটি সংখ্যার বদলে range দেওয়া।
- LEF: বছরে কয়টি ক্ষতির ঘটনা।
- LM: এক ঘটনায় কত ক্ষতি।
- মাঝের মান ধরতে এখানে range-এর geometric mean নেওয়া হলো: √(নিচু × উঁচু).
হাতে হিসাব, R1: LEF ০.১ থেকে ০.৫, মাঝের মান √০.০৫ ≈ ০.২২৪। LM ২০ থেকে ১২০ লাখ, মাঝের মান √২৪০০ ≈ ৪৯। গুণফল ≈ ১১ লাখ টাকা প্রতি বছর। সব উঁচু দিক একসাথে ধরলে ০.৫ × ১২০ = ৬০ লাখ।
// Taza Bazar risk register (fictional). Amounts in lakh taka.
// lef = loss events per year, lm = loss per event, as [low, high] ranges.
const risks = [
{ id: "R1", name: "ransomware at head office", lef: [0.1, 0.5], lm: [20, 120] },
{ id: "R2", name: "customer data via API flaw", lef: [0.2, 1], lm: [5, 60] },
{ id: "R3", name: "customer account takeover", lef: [2, 10], lm: [0.3, 2] },
{ id: "R4", name: "staff phishing, fake refunds", lef: [1, 4], lm: [1, 8] },
{ id: "R5", name: "forged payment webhook", lef: [0.5, 2], lm: [0.5, 5] },
{ id: "R6", name: "DDoS during a sale", lef: [0.5, 2], lm: [1, 10] },
{ id: "R7", name: "vendor breach", lef: [0.1, 0.5], lm: [3, 30] },
{ id: "R8", name: "CCTV recorder exposed", lef: [0.2, 1], lm: [0.5, 6] },
];
const TOLERANCE = 50; // one bad year for one risk, assumed by the owners
const mid = ([lo, hi]) => Math.sqrt(lo * hi); // geometric middle of a range
const rows = risks.map((r) => ({
...r,
ale: mid(r.lef) * mid(r.lm), // yearly loss, middle estimate
worst: r.lef[1] * r.lm[1], // both ranges at their high end
})).sort((a, b) => b.ale - a.ale);
console.log("rank id yearly high flag risk");
rows.forEach((r, i) => {
const flag = r.worst > TOLERANCE ? "OVER" : "-";
console.log(`${i + 1} ${r.id} ${r.ale.toFixed(1).padStart(5)} ${r.worst.toFixed(0).padStart(4)} ${flag.padEnd(4)} ${r.name}`);
});
const total = rows.reduce((s, r) => s + r.ale, 0);
const top3 = rows.slice(0, 3).reduce((s, r) => s + r.ale, 0);
console.log(`total ${total.toFixed(1)} lakh, top 3 share ${(100 * top3 / total).toFixed(0)}%`);R1 আর R2 শীর্ষে, আর দুটিরই high ৬০ লাখ, যা মালিকের ধরে নেওয়া ৫০ লাখের সীমা ছাড়ায়, তাই OVER. মোট 35.5 lakh, আর শীর্ষ তিনটি মিলে 69%. লক্ষ্য করুন, R3 ঘটে অনেক বেশিবার, তবু মোট ক্ষতিতে সে চতুর্থ। সাবধান: high দুই range-এর চূড়া গুণ করে পাওয়া, এটি কোনো ৯০% সীমা নয়। আর মাঝের মান গুণ করলে গড় পাওয়া যায় না; উন্নত স্তরে পর্ব ৬৮-এর Monte Carlo চালান।
| ID, ঝুঁকি | মালিক | LEF range | LM range (লাখ) | অনুমানের উৎস | সিদ্ধান্ত |
|---|---|---|---|---|---|
| R1 ransomware | CTO | ০.১–০.৫ | ২০–১২০ | দলের অনুমান, প্রকাশিত ঘটনা | কমানো |
| ……… | ……… | ……… | ……… | ……… | ……… |
৪ · ধাপ ৪ আর ৫: পরিচয়, network আর endpoint-এর ভিত্তি
ধাপ ৪ · পরিচয়ের পরিকল্পনা
ব্যাংকের লকারে সবাই এক চাবি পান না। ধাপটি সেই নীতির লিখিত রূপ: কোন ধরনের মানুষ বা system কীভাবে নিজেকে প্রমাণ করবে, আর কতটুকু পাবে। পদ্ধতি: পর্ব ১৬, পর্ব ১৯, পর্ব ২০।
| কে | Login | অধিকার | যাচাই |
|---|---|---|---|
| ক্রেতা | Password + OTP, ঐচ্ছিক passkey | শুধু নিজের অর্ডার | Object-level test |
| কর্মী | SSO + MFA | RBAC ভূমিকা, least privilege | ত্রৈমাসিক access review |
| Admin | Phishing-প্রতিরোধী passkey বা security key | Just-in-time, ১ ঘণ্টা, অনুমোদনসহ | Session log |
| রাইডার | App-এ ফোনে বাঁধা token | আজকের delivery | হারানো ফোনে token বাতিল test |
| Service, vendor | Workload identity, সময়-বাঁধা প্রবেশ | একটি কাজ | Secret-এর বয়স রিপোর্ট |
| ……… | ……… | ……… | ……… |
সাথে দুটি লিখিত নিয়ম রাখুন। কর্মী চলে গেলে একই দিনে সব অ্যাকাউন্ট বন্ধ। আর দুটি break-glass অ্যাকাউন্ট সিলগালা খামের মতো তোলা থাকবে; ব্যবহার হলেই alert.
ধাপ ৫ · Network আর endpoint-এর baseline
Baseline মানে এমন ন্যূনতম মান, যার নিচে কোনো যন্ত্র বা network চলবে না। পদ্ধতি: পর্ব ২২, পর্ব ২৫, পর্ব ২৭, পর্ব ২৯, পর্ব ৩২, পর্ব ৩৫।
| এলাকা | তাজা বাজারের baseline | প্রমাণ |
|---|---|---|
| অফিসের zone | কর্মী, অতিথি Wi-Fi, CCTV আলাদা VLAN; মাঝে default deny | Rule তালিকা, নিজের network-এ যাচাই |
| Cloud | Database-এ public পথ নেই; admin যায় ZTNA বা VPN হয়ে | Security group রিপোর্ট |
| PC | Full-disk encryption, স্থানীয় admin নয়, EDR | ৪০ যন্ত্রের অবস্থা |
| রাইডারের ফোন | MDM বা work profile, screen lock, হারালে wipe | Enrollment তালিকা |
| Patch | Critical ৭ দিন, KEV-এ থাকা ত্রুটি ৪৮ ঘণ্টা (নিজেদের ধরা নিয়ম) | Patch-এর বয়স |
SPF, DKIM, DMARC p=reject | DMARC রিপোর্ট |
Cloud-এর ভাগাভাগি দায়িত্বের জন্য পর্ব ৭২, আর কর্মীর প্রবেশের নকশার জন্য পর্ব ৭৪ দেখুন। Hardening-এর নমুনা আছে পর্ব ৩০ আর পর্ব ৩১-এ।
৫ · ধাপ ৬ আর ৭: Web, API আর নিরাপদ software
ধাপ ৬ · Web আর API hardening, OWASP-এর সাথে মিলিয়ে
তালিকাটি পরীক্ষার খাতা নয়, নিজের app-এর প্রতিটি বৈশিষ্ট্যকে OWASP Top 10 (২০২৫) আর API Security Top 10 (২০২৩)-এর সাথে মেলানোর ফর্ম। পদ্ধতি: পর্ব ৩৭ থেকে পর্ব ৪৪।
| বৈশিষ্ট্য | OWASP | পরিকল্পনা | পরীক্ষা | পর্ব |
|---|---|---|---|---|
| অর্ডার দেখা | A01, API1 | Server-এ মালিকানা যাচাই (BOLA) | দুই test account | ৩৮ |
| পণ্য খোঁজা | A05 | Parameterized query | Code review, SAST | ৩৯ |
| ক্রেতার রিভিউ | A05 | Output encoding, CSP | নিজের staging-এ header যাচাই | ৪০ |
| Login | A07, API2 | Rate limit, ফাঁস হওয়া password আটকানো | Limit-এর unit test | ১৫ |
| ঈদের voucher | API6 | প্রতি অ্যাকাউন্টে সীমা | ব্যবসার নিয়মের test | ৪৩ |
| পেমেন্টের error | A10 | সন্দেহে fail secure: paid নয় | Timeout test | ৪৪ |
| ……… | ……… | ……… | ……… | ……… |
ধাপ ৭ · Secure SDLC আর supply chain-এর গেট
গার্মেন্টসে প্রতিটি লাইনের শেষে একজন QC থাকেন। Software-এও তেমনি security gate বসে। কোনটি কাজ থামাবে আর কোনটি শুধু সতর্ক করবে, তা আগেই ঠিক করুন। পদ্ধতি: পর্ব ৪৫, পর্ব ৪৮, পর্ব ৪৯, DevSecOps.
| স্তর | গেট | থামাবে? |
|---|---|---|
| নকশা | নতুন ডেটা flow হলে threat model হালনাগাদ | হ্যাঁ |
| Pull request | একজনের review, secret scanning | হ্যাঁ |
| Build | SAST, SCA, lockfile, SBOM | Critical হলে হ্যাঁ |
| Release | Signed artifact, ধাপে ধাপে rollout, rollback-এর পথ | হ্যাঁ |
| চলমান | নতুন ত্রুটির SLA, বছরে একবার অনুমোদিত pentest (পর্ব ৫০) | রিপোর্ট |
| ……… | ……… | ……… |
পেমেন্টের একটি ভালো নকশা-সিদ্ধান্ত: কার্ডের নম্বর আপনার server-এ আসবেই না। Gateway-র hosted page বা SDK ব্যবহার করলে PCI DSS-এর পরিধি অনেক ছোট হতে পারে, হয়তো SAQ A-এর পথে। পরিধি শূন্য হয় না। ঠিক কোন ফর্ম লাগবে, acquirer-এর সাথে নিশ্চিত করুন (পর্ব ৬৯)।
৬ · ধাপ ৮: Log, detection আর SOC না MDR
মহল্লার পাহারার তিনটি অংশ: কী দেখবেন, কখন বাঁশি বাজাবেন, বাঁশি শুনে কে আসবেন। পদ্ধতি: পর্ব ৫৫, পর্ব ৫৬, পর্ব ৫৯, পর্ব ৬০।
| Rule | Log উৎস | ঝুঁকি | কে দেখবেন | Test |
|---|---|---|---|---|
| অনেক ব্যর্থতার পর login | API | R3, R4 | On-call | Planted event |
| ভুল সইয়ের webhook | API | R5 | On-call | Unit test |
| অস্বাভাবিক বড় refund | হিসাব app | R4 | হিসাব প্রধান | নমুনা ডেটা |
| Backup বন্ধ বা ব্যর্থ | Backup | R1 | CTO | মাসিক মহড়া |
| Break-glass ব্যবহার | Identity | R1, R4 | মালিক + CTO | ত্রৈমাসিক |
| ……… | ……… | ……… | ……… | ……… |
একটি detection rule-ও কোডের মতো, তাই তারও test লাগে। নিচের খেলনা ডেটায় ৪টি login-এর উত্তর আগে থেকেই জানা। Rule-এর দুই সেটিং বদলে দেখা হচ্ছে: কতগুলো ব্যর্থতা (n), আর কত মিনিটের জানালা (win). এটি শুধু log-এর ছোট তালিকায় চলে, কোনো system-এ নয়।
// Mini detection test on toy events (fictional; clock in minutes).
// truth: "bad" = planted by the test author, "ok" = normal activity.
const f = (t, src, user) => ({ t, k: "fail", src, user });
const ev = [
f(10, "203.0.113.7", "a1"), f(11, "203.0.113.7", "a2"), f(12, "203.0.113.7", "a3"),
f(13, "203.0.113.7", "a4"), f(14, "203.0.113.7", "a5"),
{ t: 15, k: "login", src: "203.0.113.7", user: "a5", truth: "bad" },
f(20, "198.51.100.9", "b1"), f(21, "198.51.100.9", "b1"), f(22, "198.51.100.9", "b1"),
{ t: 23, k: "login", src: "198.51.100.9", user: "b1", truth: "ok" },
f(30, "203.0.113.20", "c1"), f(45, "203.0.113.20", "c2"),
f(60, "203.0.113.20", "c3"), f(75, "203.0.113.20", "c4"),
{ t: 90, k: "login", src: "203.0.113.20", user: "c4", truth: "bad" },
{ t: 100, k: "login", src: "198.51.100.30", user: "d1", truth: "ok" },
];
// Rule: a login after at least `n` failures from one source in `win` minutes.
const rule = (n, win) => ev.filter((e) => e.k === "login").map((e) => ({
...e,
alert: ev.filter((x) => x.k === "fail" && x.src === e.src && x.t < e.t && e.t - x.t <= win).length >= n,
}));
function score(n, win) {
const r = rule(n, win);
const tp = r.filter((e) => e.alert && e.truth === "bad").length;
const fp = r.filter((e) => e.alert && e.truth === "ok").length;
const fn = r.filter((e) => !e.alert && e.truth === "bad").length;
const precision = tp + fp ? tp / (tp + fp) : 0, recall = tp + fn ? tp / (tp + fn) : 0;
console.log(`n=${n} win=${String(win).padStart(2)} TP=${tp} FP=${fp} FN=${fn} ` +
`precision=${precision.toFixed(2)} recall=${recall.toFixed(2)}`);
}
[[3, 10], [5, 10], [3, 60], [4, 60]].forEach(([n, w]) => score(n, w));
// A rule also needs a test that it stays quiet on normal activity.
const quiet = !rule(4, 60).find((e) => e.src === "198.51.100.30").alert;
console.log(`quiet on normal login: ${quiet ? "PASS" : "FAIL"}`);n=3 win=10-এ একজন ভুলো ক্রেতাও ধরা পড়ে (FP=1), আর ধীরগতির ঘটনাটি ফসকে যায় (FN=1). n=5 win=10-এ precision 1.00 হলেও recall 0.50. n=4 win=60 সব মেলায়, কিন্তু উল্লাসের কারণ নেই: ৪টি নমুনায় মিলে যাওয়া মানে rule-টি এই ডেটায় সাজানো হয়েছে। আসল প্রমাণ আসে নতুন ডেটায়। শেষ লাইনের PASS নিশ্চিত করে, স্বাভাবিক login-এ alert বাজে না।
নিজস্ব SOC, না MDR?
একটি আসনকে ২৪ ঘণ্টা ৭ দিন চালাতে সপ্তাহে ১৬৮ ঘণ্টা লাগে। একজন ৪০ ঘণ্টা কাজ করলে ১৬৮ ÷ ৪০ = ৪.২ জন, ছুটি ধরলে অন্তত ৫ জন। মাসে ধরে নেওয়া ৬০ হাজার টাকায় ৫ × ০.৬ × ১২ = ৩৬ লাখ, পুরো বাজেটের দ্বিগুণের বেশি। তাই নিজস্ব SOC বাদ।
বিকল্প MDR, অর্থাৎ বাইরের দল আপনার হয়ে নজর রাখে, ধরে নেওয়া বছরে ৬ লাখ। আরেক বিকল্প: কাজের সময়ে on-call আর EDR-এর alert. সিদ্ধান্তটি অংশ ৮-এ টাকার হিসাবে হবে। মনে রাখুন, MDR থাকলেও ব্যবসার সিদ্ধান্ত আর ঘটনার দায় আপনারই থাকে।
৭ · ধাপ ৯: Incident পরিকল্পনা আর ৬০ মিনিটের মহড়া
আগুন লাগার পরে সিঁড়ি খোঁজা যায় না। IR plan হলো আগে থেকে লেখা সিঁড়ির নকশা, আর tabletop exercise হলো সিঁড়ি দিয়ে হাঁটার আলোচনা-মহড়া। পদ্ধতি: পর্ব ৬১, পর্ব ৬২, পর্ব ৬৩, পর্ব ৩৪, পর্ব ৬৬।
| পরিকল্পনার অংশ | তাজা বাজারে | আপনার |
|---|---|---|
| Incident commander | Ops প্রধান, বিকল্প CTO | ……… |
| প্রযুক্তি, যোগাযোগ, লেখক | CTO · marketing প্রধান · একজন scribe | ……… |
| গুরুত্ব ঘোষণা | S1: বিক্রি বন্ধ বা ডেটা ফাঁসের সন্দেহ | ……… |
| Out-of-band পথ | আলাদা ফোন গ্রুপ, ছাপানো ফোন তালিকা | ……… |
| RTO, RPO | ৪ ঘণ্টা, ২৪ ঘণ্টা | ……… |
| বাইরের যোগাযোগ | আইনজীবী, gateway, cloud, IR সহায়তা, CIRT (জাতীয় ঘটনা-সাড়া দল) | ……… |
মহড়ার পরিস্থিতি
ঈদের আগের বৃহস্পতিবার সকাল ৯:২০। প্রধান কার্যালয়ের file server আর গুদামের PC-র ফাইল খোলা যাচ্ছে না। মুক্তিপণের একটি নোটে দাবি, ক্রেতার ডেটা নেওয়া হয়েছে। Cloud-এর API এখনো চলছে। Backup-এর একটি কপি immutable, আকারে ১২০ GB, গত রাতের। ঘটনা কীভাবে শুরু হলো, তা এই মহড়ার বিষয় নয়। সময়সূচি পর্ব ৬৬-এর মতোই: প্রথম ৫ মিনিট নিয়ম, শেষ ৮ মিনিট hotwash. কোনো system-এ হাত পড়বে না।
| মিনিট | |
| সিদ্ধান্ত | |
| কে | |
| যুক্তি |
- মিনিট ৫ · ঘোষণা। Ops প্রধান ঘোষণা করেন, এটি S1, আর তিনিই commander. দল মূল email ছেড়ে আলাদা ফোন গ্রুপে যায়। Scribe decision log-এ সময় লেখা শুরু করেন।
- মিনিট ১২ · বিচ্ছিন্ন করা। অফিস থেকে cloud-এর VPN পথ বন্ধ। দাম: গুদামে কয়েক ঘণ্টা কাগজে কাজ। যুক্তি: containment-এ ছড়ানো থামানো আগে আসে (পর্ব ৬২)।
- মিনিট ২০ · প্রমাণ। আক্রান্ত যন্ত্র মোছা হবে না, শুধু network থেকে আলাদা। Log আর snapshot রক্ষা, বাইরের IR সহায়তাকে ডাকা। মুছে ফেললে কী ঘটেছিল, তা আর জানা যাবে না (পর্ব ৬৩)।
- মিনিট ২৮ · পুনরুদ্ধার। ২০ MB/s গতিতে ১২০,০০০ ÷ ২০ = ৬,০০০ সেকেন্ড, মানে ১০০ মিনিট। যাচাইয়ে ৬০ মিনিট ধরে মোট ১৬০ মিনিট, যা ২৪০ মিনিটের RTO-র ভেতরে। তবে আগে পরিষ্কার পরিবেশ আর নতুন credential; এ হিসাব শুধু তখনই খাটে, যদি restore আগে পরীক্ষা করা থাকে।
- মিনিট ৩৬ · ডেটার দাবি। নোটের দাবি প্রমাণ নয়, উড়িয়ে দেওয়ার মতোও নয়। Log দেখে পরিধি ঠিক হবে। ব্যক্তিগত ডেটা গেলে কাকে কখন জানাতে হবে, আইনজীবী দেখবেন (পর্ব ৬, পর্ব ৭০), আর gateway-র চুক্তির শর্তও।
- মিনিট ৪৪ · মুক্তিপণ। Commander একা এই সিদ্ধান্ত নেন না। আগে লেখা নীতি অনুযায়ী মালিক আর আইনজীবী বসেন। Restore সম্ভব, তাই এখন উত্তর “না”; টাকা দিলেও ডেটা মুছবে, এমন নিশ্চয়তা নেই। এখানে আইনি দিকও আছে।
- মিনিট ৫২ · বার্তা ও শেখা। ১৫ মিনিটে তৈরি holding statement: জানা তথ্য, নেওয়া ব্যবস্থা, ক্রেতার করণীয়, পরের আপডেটের সময়। তারপর hotwash: তিনটি ফাঁক, প্রতিটিতে মালিক আর তারিখ। সেগুলোই ফিরে যায় ঝুঁকির খাতায়।
৮ · ধাপ ১০, রোডম্যাপ আর বোর্ডের এক পাতা
ধাপ ১০ · Governance, privacy আর vendor
এই ধাপ ঠিক করে, কে দায়িত্বে, কোন নিয়মে, আর বাইরের কে কতটা ঢুকছে। পদ্ধতি: পর্ব ৬৭, পর্ব ৬৯, পর্ব ৭০, পর্ব ৭১, পর্ব ৫৪।
| বিষয় | তাজা বাজারে | প্রমাণ |
|---|---|---|
| নীতি ও দায়িত্ব | এক পাতার নিরাপত্তা নীতি, মালিক অনুমোদিত; ঝুঁকির মালিক নির্দিষ্ট | স্বাক্ষরিত নথি |
| কাঠামো | NIST CSF 2.0-র ছয় কাজে নিজের অবস্থা; ভিত্তি হিসেবে CIS Controls IG1 | এক পাতার profile |
| Privacy | আইনি ভিত্তি, ডেটা কমানো, retention, ক্রেতার অনুরোধের পথ | প্রক্রিয়ার তালিকা |
| CCTV, রাইডারের লোকেশন | উদ্দেশ্য লেখা, রাখার সময় সীমিত, কে দেখবেন নির্দিষ্ট | দেখার log |
| Vendor | Tier ১: gateway, cloud. Tier ২: SMS. Tier ৩: বাকিরা | Vendor তালিকা, চুক্তির শর্ত |
| মানুষ | ছোট সচেতনতা সেশন, দোষারোপহীন রিপোর্টের পথ | রিপোর্টের হার |
Privacy-র আইনি দায়িত্ব ঠিক করতে ব্যক্তিগত উপাত্ত সুরক্ষা আইন, ২০২৬-এর কোন ধারা কবে থেকে চালু, আইনজীবীর সাথে মিলিয়ে নিন। এই পর্ব আইনি পরামর্শ নয়।
রোডম্যাপ: কোন কাজ আগে
১২টি কাজ, প্রতিটির খরচ, সময় আর ঝুঁকি কমানোর অনুমান আছে। ধরা যাক, ১৫ লাখ টাকা আর প্রতি প্রান্তিকে ৮ জন-সপ্তাহ। প্রতি টাকায় সবচেয়ে বেশি ঝুঁকি কমে, এমন কাজ আগে নেওয়া একটি সহজ নিয়ম। প্রশ্ন হলো, সেটি কি সেরা? সমস্যাটি আসলে knapsack problem, তাই ১২টি কাজের সব ৪,০৯৬টি সমাবেশ মিলিয়েও দেখা হচ্ছে।
// Pick controls by yearly risk reduction per lakh, within budget and team time.
// cost = lakh taka, wk = person-weeks, cut = assumed yearly reduction (lakh).
const items = [
["C1", "MFA and passkeys", 1.0, 3, 5.0], ["C2", "immutable backup", 2.0, 3, 4.5],
["C3", "API object checks", 1.5, 6, 4.5], ["C4", "CDN, WAF, rate limit", 2.5, 2, 3.3],
["C5", "EDR on 40 devices", 3.5, 3, 2.5], ["C6", "MDR service", 6.0, 2, 3.0],
["C7", "central logs, 10 rules", 1.0, 5, 2.0], ["C8", "webhook signature", 0.3, 2, 1.2],
["C9", "vendor review", 0.5, 3, 0.9], ["C10", "CCTV on own VLAN", 0.4, 1, 0.5],
["C11", "IR plan, tabletop", 0.5, 2, 1.5], ["C12", "just-in-time admin", 1.5, 3, 1.5],
].map(([id, name, cost, wk, cut]) => ({ id, name, cost, wk, cut }));
const BUDGET = 15, WEEKS = 8, QUARTERS = 4;
const byValue = [...items].sort((a, b) => b.cut / b.cost - a.cut / a.cost);
const free = Array(QUARTERS).fill(WEEKS), plan = [[], [], [], []];
let spent = 0, cut = 0;
for (const c of byValue) {
const q = free.findIndex((w) => w >= c.wk);
if (q < 0 || spent + c.cost > BUDGET) { console.log(`skip ${c.id} ${c.name}`); continue; }
plan[q].push(c); free[q] -= c.wk; spent += c.cost; cut += c.cut;
}
plan.forEach((p, q) => console.log(`Q${q + 1}: ${p.map((c) => c.id).join(" ")}` +
` cost ${p.reduce((s, c) => s + c.cost, 0).toFixed(1)} weeks ${WEEKS - free[q]}`));
console.log(`greedy: spent ${spent.toFixed(1)} of ${BUDGET}, cut ${cut.toFixed(1)} a year`);
// Check every subset. 12 items give 4096 subsets, small enough here.
let best = { cut: 0, ids: "" };
for (let m = 0; m < 1 << items.length; m++) {
const s = items.filter((_, i) => m >> i & 1);
const cost = s.reduce((a, c) => a + c.cost, 0), wk = s.reduce((a, c) => a + c.wk, 0);
const v = s.reduce((a, c) => a + c.cut, 0);
if (cost <= BUDGET + 1e-9 && wk <= WEEKS * QUARTERS && v > best.cut + 1e-9)
best = { cut: v, cost, wk, ids: s.map((c) => c.id).join(" ") };
}
console.log(`best subset: cut ${best.cut.toFixed(1)}, cost ${best.cost.toFixed(1)}, weeks ${best.wk}`);
console.log(`ids: ${best.ids}`);সহজ নিয়ম spent 11.2-এ থেমে cut 24.9 পায়। C5-কে আলাদা করে দেখুন: Q4-এ জায়গা ছিল মাত্র ২ জন-সপ্তাহ, তাই সে বাদ গেল, যদিও টাকা বাকি ছিল। সব সমাবেশ দেখলে best subset পায় cut 26.9, খরচ 14.3, সময় পুরো 32. তফাত ২ লাখ। এতে C10 বাদ গেছে আর C5 এসেছে। হিসাবে তিনটি ফাঁক আছে: কাজগুলোর ঝুঁকি কমা কিছুটা একই ঝুঁকিতে পড়ে, তাই যোগফল বেশি দেখায়; কোন কাজ কার আগে, কোড জানে না; আর cut নিজেই অনুমান।
MDR-এর সিদ্ধান্ত: C6 ৬ লাখে ৩ লাখ কমায়, তাই প্রথম বছরে নেওয়া হলো না। প্রথম বছর on-call আর EDR. এটি “না” নয়, “এখন না”: লিখে রাখুন, Q4-এ আবার দেখবেন। আর নিচে মানুষের হাতে সাজানোর সময় ক্রম বদলেছে: backup আর MFA আগে, কারণ R1 সবচেয়ে বড়, আর detection বানাতে log আগে লাগে।
| কাজ | |
| এই প্রান্তিকের খরচ | |
| মোট খরচ | |
| বাকি বাজেট | |
| বছরে কমল | |
| বাকি ঝুঁকি |
- শুরু। বার্ষিক অনুমিত ঝুঁকি 35.5 লাখ, বাজেট 15 লাখ। ধাপ ১ থেকে ১০-এর নথি এই সময়েই তৈরি হয়, খরচ মূলত মানুষের সময়।
- Q1 · টিকে থাকা। MFA ও passkey (C1), immutable backup (C2), IR plan আর প্রথম মহড়া (C11). ৩ + ৩ + ২ = ৮ জন-সপ্তাহ, খরচ 3.5. কমে 5.0 + 4.5 + 1.5 = 11.0, বাকি ঝুঁকি 24.5.
- Q2 · ক্রেতার ডেটা ও টাকা। API-র মালিকানা যাচাই (C3), webhook সই (C8). ৬ + ২ = ৮ জন-সপ্তাহ, খরচ 1.8. মোট কমল 16.7, বাকি 18.8.
- Q3 · দেখতে পাওয়া। কেন্দ্রীয় log ও ১০টি rule (C7), ৪০ যন্ত্রে EDR (C5). ৫ + ৩ = ৮, খরচ 4.5. মোট খরচ 9.8, বাকি বাজেট 5.2, বাকি ঝুঁকি 14.3.
- Q4 · দেয়াল আর অন্যরা। CDN ও WAF (C4), vendor পর্যালোচনা (C9), JIT admin (C12). ২ + ৩ + ৩ = ৮, খরচ 4.5. বছর শেষে মোট 14.3, হাতে 0.7, বাকি ঝুঁকি 8.6. ঈদের সেল Q2-তে পড়লে C4 আগে আনতে হবে। C10-এর জন্য ১ জন-সপ্তাহ বের হলে সেটিই প্রথম যোগ হবে।
বোর্ডের এক পাতা
মালিক বা বোর্ড CVE চান না, চান সিদ্ধান্ত নিতে। Executive summary-তে ব্যবসার ভাষা, সংখ্যার সাথে তার অনিশ্চয়তা, আর স্পষ্ট চাওয়া থাকে।
তাজা বাজার · নিরাপত্তা programme · ২০২৭ (সব অঙ্ক অনুমান)
অবস্থা : maturity ২১%, প্রধান ফাঁক log আর vendor
বড় ঝুঁকি : ১. ransomware ২. API দিয়ে ডেটা ফাঁস ৩. কর্মীর phishing
আর্থিক ছবি: বার্ষিক ঝুঁকি প্রায় ৩৫.৫ লাখ, খারাপ বছরে এক ঝুঁকিতেই ৬০ লাখ
পরিকল্পনা: ১৪.৩ লাখে বাকি ঝুঁকি প্রায় ৮.৬ লাখ (overlap-এর কারণে আসল
মান কিছুটা বেশি হতে পারে)
যা হবে না: এই বছর MDR নয়; Q4-এ আবার দেখা হবে
চাই : ১. ১৫ লাখ অনুমোদন ২. মুক্তিপণ নীতি ৩. বাকি ঝুঁকি মেনে নেওয়ার
স্বাক্ষর ৪. ডেটার দায়িত্বপ্রাপ্ত একজন
মাপকাঠি : admin-এ phishing-প্রতিরোধী MFA ১০০%, restore test ত্রৈমাসিক,
Critical patch ৭ দিনে ৯০%, মহড়া বছরে ২ বার
পরের রিপোর্ট: তিন মাস পরে
৯ · নিজেকে মূল্যায়ন, আর এরপর কী
প্রকল্পের rubric
| মাপকাঠি | নম্বর | পূর্ণ নম্বর পেতে |
|---|---|---|
| সম্পূর্ণতা | ১৫ | নিজের স্তরের সব নথি আছে, ফাঁকা ঘর নেই |
| অটুট শিকল | ২৫ | যেকোনো control ধরে ঝুঁকি, সম্পদ আর পরীক্ষা পর্যন্ত যাওয়া যায় |
| সংখ্যার সততা | ১৫ | Range আছে, অনুমানের উৎস লেখা, হিসাব মেলে |
| পরীক্ষাযোগ্যতা | ২০ | প্রতিটি দাবির প্রমাণ বা test আছে, ব্যর্থ হলে কী বোঝায় তাও |
| বাস্তবতা | ১৫ | বাজেট, সময় আর ৬০ জনের দলে সত্যিই করা যায় |
| আইন ও নৈতিকতা | ১০ | অনুমতির সীমা স্পষ্ট, ব্যক্তিগত ডেটা সুরক্ষিত, আইনি পরামর্শের জায়গা চিহ্নিত |
৫০-এর নিচে হলে শিকলের ফাঁকা কড়া খুঁজুন। ৭০ মানে কাজের মান ভালো। ৮৫-এর ওপরে হলে নিজের কাজ একজন অভিজ্ঞ মানুষকে দেখান। নিজের নম্বর নিজে দেওয়ার সময় উদার হওয়া সহজ, তাই একজন বন্ধুকেও নম্বর দিতে বলুন।
Programme কতটা পরিণত
উপরের rubric আপনার প্রজেক্ট মাপে। আর maturity model মাপে প্রতিষ্ঠানকে। তাজা বাজারের শুরুর আর এক বছর পরের অনুমিত নম্বর দেখুন। নম্বর বাড়াতে চাইলে আগে প্রমাণ দেখাতে হবে।
// Programme maturity rubric. Score each domain 0 to 4 against written evidence.
// 0 none, 1 ad hoc, 2 written, 3 running with proof, 4 measured and improving.
const domains = [
["assets and data", 2, "finish the data map, name an owner per asset"],
["risk register", 2, "review the top risks every quarter"],
["identity", 3, "phishing-resistant login for every admin"],
["network and endpoint", 2, "separate zones, turn on disk encryption"],
["web and API", 3, "add object-level tests to the build"],
["secure SDLC", 2, "make secret and dependency checks blocking"],
["logging and detection", 3, "test each rule with planted events"],
["incident response", 3, "run a tabletop, test a restore"],
["governance and privacy", 2, "assign data duties, set retention"],
["vendors", 1, "list vendors, tier them, check contracts"],
];
const start = [2, 1, 1, 1, 1, 0, 0, 1, 1, 0];
const after = [3, 3, 3, 2, 3, 2, 2, 3, 2, 2];
const maxScore = domains.reduce((s, d) => s + d[1] * 4, 0);
function report(label, scores) {
const total = domains.reduce((s, d, i) => s + d[1] * scores[i], 0);
const pct = 100 * total / maxScore;
const level = pct < 25 ? "initial" : pct < 50 ? "basic" : pct < 75 ? "managed" : "strong";
console.log(`${label}: ${total}/${maxScore} = ${pct.toFixed(0)}% (${level})`);
// Lowest score first; on a tie, the larger weighted gain first.
const next = domains.map((d, i) => ({ d, gain: d[1] * (4 - scores[i]), s: scores[i] }))
.sort((a, b) => a.s - b.s || b.gain - a.gain).slice(0, 3);
next.forEach((n) => console.log(` next (${n.s}/4, gain ${n.gain}): ${n.d[0]}: ${n.d[2]}`));
}
report("start", start);
report("after one year", after);শুরুতে 19/92 = 21%, স্তর initial. যে তিনটি ক্ষেত্রে নম্বর শূন্য, সেগুলোই আগে আসে, আর ওজন বেশি বলে logging and detection প্রথমে। এক বছর পরে 59/92 = 64%, স্তর managed. এখানেই প্রজেক্টটি ঘুরে আসে: নতুন বছরের কাজ শুরু হয় এই next তালিকা থেকে। সীমা রেখা আর ওজন আমাদের ধরা, কোনো standard নয়। নম্বর শুধু নিজের অগ্রগতি দেখায়, অন্য প্রতিষ্ঠানের সাথে তুলনা নয়।
এরপর কী শিখবেন
| লক্ষ্য | গভীরে যান | যা বানিয়ে দেখাবেন |
|---|---|---|
| SOC analyst | পর্ব ৫৫–৬৪, পর্ব ৭৯ | ৫টি rule, test আর triage নোট |
| Security engineer | পর্ব ১৫–২০, ৩৬–৫১, পর্ব ৮০ | একটি ছোট app-এর threat model আর সমাধান |
| GRC, ঝুঁকি | পর্ব ৬৭–৭১ | এই প্রজেক্টের ঝুঁকির খাতা, বোর্ডের পাতা |
| Cloud নিরাপত্তা | পর্ব ৭২–৭৪, Cloud & DevOps | নিজের test account-এ baseline |
| পরীক্ষার প্রস্তুতি | পর্ব ৭৬–৭৮ | সময় ধরে numerical আর লিখিত অনুশীলন |
আইনের ভেতরে থেকে অনুশীলন
নিজের ল্যাব
Home lab: নিজের কম্পিউটারে virtual machine, বাইরের network থেকে আলাদা। Hardening, log আর detection সেখানেই অনুশীলন করুন।
নিজের যন্ত্র, নিজের networkঅনুমতি দেওয়া CTF
CTF হলো সাজানো প্রতিযোগিতা। আয়োজকের নিয়ম আর দেওয়া লক্ষ্যই সীমা। প্রতিযোগিতার বাইরের কিছুতে হাত দেবেন না। Blue team ধরনের CTF-ও আছে।
নিয়ম আগে পড়ুনPublic bug bounty
Bug bounty-তে শুধু প্রকাশিত scope, নিষিদ্ধ কাজের তালিকা আর রিপোর্টের নিয়ম মানা। অন্যের ডেটা না দেখা, সন্দেহ হলে থেমে জিজ্ঞেস করা (পর্ব ৫০)।
Scope-এর বাইরে অনুমতি নেইঅনুমোদিত কাজ
চাকরি বা চুক্তিতে কাজ হয় লিখিত authorization, scope আর rules of engagement ধরে।
কাগজ আগে, কাজ পরেআবারও: নিরাপত্তা পরীক্ষার জন্য লিখিত অনুমতি লাগে। ভালো উদ্দেশ্য অনুমতির বিকল্প নয়। চেনা কোনো দোকানের website-এ ত্রুটি চোখে পড়লে পরীক্ষা চালিয়ে যাবেন না; তাদের VDP বা যোগাযোগের পথে জানান (পর্ব ৬)।
আরও গভীরে: Programme-এর কাঠামো নিয়ে একমত হওয়া একটিমাত্র নকশা নেই। NIST CSF 2.0 (২০২৪) ফলাফল বলে দেয়, উপায় বলে না; CIS Controls ক্রমসহ করণীয় বলে; ISO/IEC 27001:2022 পরিচালনার ব্যবস্থা চায়। ঝুঁকি কমানোর অর্থনীতিতে Gordon ও Loeb-এর ২০০২ সালের মডেল একটি সীমার কথা বলে (পর্ব ৬৮)। সেটি মডেলের শর্তে খাটে, বাজেটের সূত্র নয়।
পরীক্ষা ও ইন্টারভিউতে:
- একটি ছোট কোম্পানিতে প্রথম ৯০ দিনে কী করবেন? সম্পদ জানা, শীর্ষ ঝুঁকি মাপা, MFA, পরীক্ষিত backup, IR plan.
- LEF ০.৪, LM ২৫ লাখ হলে বার্ষিক ক্ষতি? ১০ লাখ, তবে range-সহ বলুন।
- ২৪×৭ একটি আসনে কতজন? ১৬৮ ÷ ৪০ = ৪.২, ছুটিসহ অন্তত ৫ জন।
- MDR কী দেয় না? ব্যবসার সিদ্ধান্ত, আইনি দায় আর নিজের ডেটার জ্ঞান।
- Control কাজ করছে, কীভাবে জানবেন? লিখিত test, চলমান প্রমাণ আর মহড়া দিয়ে।
১০ · AI-এর যুগে ক্যাপস্টোন
AI একটি দারুণ খসড়া-লেখক: ফর্ম সাজায়, ফাঁক দেখায়, ভাষা সহজ করে। কিন্তু সে আপনার প্রতিষ্ঠানকে চেনে না, আর আত্মবিশ্বাসে ভুল বলে। আপনার নথিতে তার সাধারণ ভুলগুলো:
| AI যা করতে পারে | কীভাবে ধরবেন |
|---|---|
| নেই এমন CVE, standard বা আইনের ধারা বানানো | মূল উৎস খুলে মিলিয়ে দেখা |
| বানানো পরিসংখ্যান দিয়ে ঝুঁকির সংখ্যা | প্রতিটি অনুমানের উৎস লেখা |
| পুরোনো পরামর্শ: MD5, ECB, salt ছাড়া hash | পর্ব ১৪-এর সাথে মেলানো |
Error সারাতে check বন্ধ: verify=False, chmod 777, খোলা CORS | Diff পড়া, নিজের ল্যাবে পরীক্ষা |
| অনুমোদন-ছাড়া বা injection-প্রবণ কোড | Review, test, পর্ব ৪৯ |
| Triage-এ বাড়তি আত্মবিশ্বাস | মানুষের চূড়ান্ত সিদ্ধান্ত |
নিচের prompt-এ আসল নাম বা গোপন তথ্য নেই, আর AI-কে সমালোচক হিসেবে রাখা হয়েছে, লেখক হিসেবে নয়। আসল প্রতিষ্ঠানের ক্ষেত্রে IP, চুক্তি, credential বা ক্রেতার তথ্য পেস্ট করবেন না।
AI-এর সাহায্য নেওয়ার চেকলিস্ট
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিয়ে নিজে কিছুক্ষণ ভাবুন, তারপর “→ উত্তর” চাপুন।
প্র ০১সব control থাকলেও একটি programme ব্যর্থ হয় কীভাবে? Compliance সনদ কি নিরাপত্তার প্রমাণ?
Target-এর ২০১৩ সালের ঘটনাটি এর পরিচিত উদাহরণ। মার্কিন সিনেট কমিটির majority staff রিপোর্ট (মার্চ ২০১৪) প্রকাশিত তথ্যের ভিত্তিতে বলে, শুরু হয়েছিল একটি vendor-এর credential থেকে, সব vendor-এর জন্য two-factor ছিল না, কম সংবেদনশীল অংশ থেকে গ্রাহকের তথ্যের দিকে যাওয়া সম্ভব হয়েছিল, আর স্বয়ংক্রিয় alert-এর ওপর আপাতদৃষ্টিতে ব্যবস্থা নেওয়া হয়নি। প্রতিষ্ঠানের তৎকালীন প্রধান নির্বাহী প্রকাশ্যে বলেছিলেন, ঘটনার কয়েক মাস আগে তারা PCI মান পূরণের সনদ পেয়েছিল। মনে রাখুন, রিপোর্টটি জনসমক্ষে থাকা তথ্যের ওপর দাঁড়ানো, তাই সাবধানে পড়া দরকার (পর্ব ৬৫)।
শিক্ষাটি এই নয় যে detection tool বা PCI অকেজো। শিক্ষা হলো, প্রতিটি টুকরো থাকা আর টুকরোগুলোর জোড়া লাগা আলাদা কথা। Alert ছিল, কিন্তু কে দেখবেন? Segmentation ছিল, কিন্তু vendor-এর পথ পরীক্ষা হয়েছিল কি? সনদ একটি নির্দিষ্ট সময়ে, নির্দিষ্ট পরিধিতে, নমুনা দেখে দেওয়া মতামত। সেটি পরের দিনের অবস্থার নিশ্চয়তা নয়।
তাই এই প্রজেক্টে “কে দেখবেন” আর “কীভাবে জানবেন” কলামগুলো আছে। আপনার তাজা বাজারে একটি rule বসানো হলো, কিন্তু রাত ২টায় সেটি কার ফোনে বাজবে? সেই নাম না থাকলে, control-টি কাগজে আছে, ঘটনায় নেই। একই প্রশ্ন vendor-এর ক্ষেত্রেও: SMS সেবাদাতার অ্যাকাউন্ট কোথায় পৌঁছাতে পারে, কেউ কি সত্যিই পরীক্ষা করে দেখেছেন? ছোট দোকানে এই জোড়াগুলো আরও নাজুক, কারণ একই মানুষ অনেক দায়িত্বে থাকেন, আর ছুটিতে গেলে পুরো পাহারাই থেমে যায়।
মূল উপলব্ধি: নিরাপত্তা তালিকার যোগফল নয়, একটি চলমান ব্যবস্থা। মালিক, পরীক্ষা আর প্রমাণ ছাড়া প্রতিটি control শুধু একটি দাবি।
প্র ০২SIEM-এর মতো বড় টুল না কিনে কেন MFA আর backup দিয়ে শুরু?
দুটি বহুল আলোচিত ঘটনা দেখুন। Colonial Pipeline-এর ২০২১ সালের সিনেট শুনানিতে প্রধান নির্বাহী জানান, হামলাকারীরা একটি পুরোনো VPN profile ব্যবহার করেছিল, যাতে শুধু single-factor ছিল। Change Healthcare-এর ২০২৪ সালের ঘটনায় মূল প্রতিষ্ঠানের প্রধান নির্বাহী মার্কিন House কমিটির শুনানিতে জানান, চুরি করা credential দিয়ে যে দূরবর্তী portal-এ ঢোকা হয়, তাতে MFA ছিল না। দুই ক্ষেত্রেই বড় ক্ষতির পেছনে ছিল একটি মৌলিক ফাঁক। এটি বলে না যে MFA থাকলে সব ঠেকত; কেবল বলে, ভিত্তির ফাঁকের দাম কত হতে পারে।
এর পেছনে তিনটি যুক্তি। এক, মৌলিক control অনেক ধরনের ঝুঁকি একসাথে কমায়, তাই তাজা বাজারের হিসাবে C1-এর প্রতি টাকার ফল সবচেয়ে বেশি। দুই, SIEM নিজে কিছু থামায় না; সে শুধু দেখায়, আর দেখার পর কাজ করার মানুষ লাগে। ৬০ জনের দলে সেই মানুষ না থাকলে দামি টুলটি অব্যবহৃত alert-এর স্তূপ হয়। তিন, backup হলো শেষ বাধা: সব প্রতিরোধ ব্যর্থ হলেও ব্যবসা ফিরতে পারে, যদি restore পরীক্ষিত থাকে।
CIS Controls-এর Implementation Group 1-এর ৫৬টি safeguard একই চিন্তা থেকে এসেছে: ছোট দলের জন্য মৌলিক কাজের একটি সীমিত তালিকা। তবে এর মানে এই নয় যে log পরে হলেও চলে। ঘটনা ঘটলে log না থাকলে পরিধি জানা যায় না। তাই সস্তা log সংরক্ষণ আগে শুরু করা বুদ্ধিমানের কাজ, যদিও পুরো detection পরে আসে। ক্রমটি তাই নিয়ম নয়, যুক্তি; প্রতিষ্ঠান বদলালে ক্রমও বদলাতে পারে।
মূল উপলব্ধি: প্রথমে সবচেয়ে সাধারণ পথগুলো বন্ধ করুন আর ফেরার পথ নিশ্চিত করুন। জটিল টুল তখনই কাজের, যখন তাকে চালানোর মানুষ ও ভিত্তি তৈরি।
প্র ০৩“প্রতি টাকায় ঝুঁকি কমানো” হিসেবে কাজ সাজানোর সীমা কোথায়?
গণিতে এটি knapsack problem: সীমিত ব্যাগে সবচেয়ে দামি জিনিস ভরা। সাধারণ রূপে এটি NP-hard, অর্থাৎ বড় আকারে নিখুঁত সমাধান খোঁজা কঠিন। ১২টি কাজে ৪,০৯৬টি সমাবেশ সহজ, ৬০টি কাজে ২-এর ৬০ ঘাত, যা গুনে শেষ করার মতো নয়। লোভী (greedy) নিয়ম তাই জনপ্রিয়, তবে ছোট উদাহরণেই সে হারে। ধরুন বাজেট ১০; A-র খরচ ৬, ফল ৯; B আর C-এর খরচ ৫ করে, ফল ৭ করে। লোভী নিয়ম A নেয়, ফল ৯; অথচ B + C-এর ফল ১৪।
গণিতের চেয়েও বড় সীমা অন্য জায়গায়। প্রথমত, ঝুঁকি কমা যোগ হয় না। MFA আর EDR দুটোই ransomware কমায়; একটি থাকলে অন্যটির বাড়তি লাভ কম। দ্বিতীয়ত, কাজের নির্ভরতা আছে: rule বানাতে log লাগে। তৃতীয়ত, গড় ক্ষতি দিয়ে সাজালে বিরল কিন্তু ধ্বংসাত্মক ঘটনা ছোট দেখায়। একটি দোকানের জন্য ৬০ লাখ ক্ষতির বছর হয়তো টিকে থাকার প্রশ্ন, শুধু গড়ের সংখ্যা নয়। চতুর্থত, আইন বা চুক্তির কিছু কাজ বাধ্যতামূলক; সেগুলো হিসাবের বাইরে থেকেই আগে করতে হয়।
Gordon ও Loeb-এর ২০০২ সালের মডেলও বলে, সর্বোত্তম বিনিয়োগ প্রত্যাশিত ক্ষতির চেয়ে কম হয়, আর তাদের ধরে নেওয়া ধরনের ক্ষেত্রে সীমাটি প্রায় ৩৭%. এটি নির্দিষ্ট শর্তের ফল। তাকে বাজেটের সূত্র ভাবা ভুল। সংখ্যার আসল কাজ হলো অনুমান প্রকাশ্যে আনা, যাতে অন্যরা প্রশ্ন করতে পারেন।
মূল উপলব্ধি: Planner একটি যুক্তিসংগত খসড়া দেয়, রায় নয়। নির্ভরতা, চূড়ান্ত ঝুঁকি আর বাধ্যবাধকতা বিচার করে মানুষকেই শেষ ক্রম ঠিক করতে হয়, আর কেন বদলালেন, তা লিখে রাখতে হয়।
প্র ০৪ছোট প্রতিষ্ঠান নিজস্ব SOC বানাবে, MDR কিনবে, না কিছুই করবে না?
সংখ্যা দিয়ে শুরু করি। ২৪×৭ একটি আসনে ন্যূনতম ৪.২ জন লাগে। কিন্তু একজনের আসনে ছুটি, প্রশিক্ষণ বা অসুস্থতায় কেউ থাকে না, আর একা রাতের পালায় থাকা মানুষ দ্রুত ক্লান্ত হন। তাই বাস্তবে দলটি বড় হয়, আর কয়েকজন দক্ষ মানুষ ছাড়লে পুরো ব্যবস্থা ভেঙে পড়ে। টাকার হিসাবে তাজা বাজারের ৩৬ লাখ শুধু বেতন; এর সাথে টুল, log সংরক্ষণ আর ব্যবস্থাপনা যোগ হবে। তাই ৬০ জনের দোকানে নিজস্ব ২৪×৭ SOC প্রায় কখনোই যুক্তিসংগত নয়।
MDR সেই খরচ অনেকের মধ্যে ভাগ করে। তবে কয়েকটি প্রশ্ন আগে করতে হয়। তারা কি শুধু জানায়, না যন্ত্র বিচ্ছিন্নও করতে পারে? কোন log দেখে? রাতে alert এলে আপনার দিকে কে উত্তর দেবেন? ডেটা কোথায় থাকে? সে নিজেও একটি Tier ১ vendor, তাই পর্ব ৭১-এর যাচাই খাটে। আর তাদের কাছে আপনার অ্যাকাউন্ট আছে মানে নতুন একটি ঝুঁকিও তৈরি হলো।
“কিছুই না” বলাও একটি সিদ্ধান্ত, যদি সেটি সচেতন আর লিখিত হয়। তাজা বাজারের প্রথম বছরের পথটি মাঝামাঝি: on-call তালিকা, EDR-এর alert আর কয়েকটি উচ্চ-সংকেতের rule. এর ফাঁক স্পষ্ট: রাতের বেলা সাড়া ধীর হতে পারে। সেই residual risk মালিক জেনে মেনে নেন, আর পরের বছরের হিসাবে MDR আবার ওঠে। ঈদের মৌসুমের মতো ঝুঁকির সময়ে সীমিত সময়ের সেবা নেওয়াও একটি বিকল্প হতে পারে, যদি সেবাদাতা তা দেন।
মূল উপলব্ধি: প্রশ্নটি “কোন টুল” নয়, “alert বাজলে কে, কত দ্রুত, কী ক্ষমতা নিয়ে সাড়া দেবেন”। উত্তরটি আউটসোর্স করা যায়, দায়টি নয়।
প্র ০৫ভালো উদ্দেশ্যে অনুমতি ছাড়া কারও website পরীক্ষা করলে সমস্যা কোথায়? আইনি অনুশীলনের পথ কীভাবে তৈরি হলো?
সমস্যা উদ্দেশ্যে নয়, অনুমতিতে। মালিক আপনার উদ্দেশ্য জানেন না। আপনার পরীক্ষা তাঁর log-এ হামলার মতোই দেখায়, তাঁর দলকে রাত জাগায়, আর ছোট system-কে নামিয়েও দিতে পারে। ডেটা চোখে পড়লে আপনি অন্যের ব্যক্তিগত তথ্যও দেখে ফেললেন। অনেক দেশের আইনে অনুমতি ছাড়া প্রবেশ অপরাধ, বাংলাদেশের অবস্থান পর্ব ৬-এ দেখুন।
অনুশীলনের বৈধ পথগুলো ধীরে গড়ে উঠেছে। ১৯৯৫ সালে Netscape তার browser-এর ত্রুটির জন্য পুরস্কারের একটি কর্মসূচি চালু করে, যাকে প্রথম দিকের bug bounty ধরা হয়। ১৯৯০-এর দশকে নিরাপত্তা সম্মেলন DEF CON-এ CTF প্রতিযোগিতা জনপ্রিয় হতে শুরু করে; সেখানে লক্ষ্যগুলো তৈরিই হয় ভাঙার অনুশীলনের জন্য। ২০১৬ সালে মার্কিন প্রতিরক্ষা দপ্তর “Hack the Pentagon” কর্মসূচি চালায়, যা দেখায়, সরকারও নির্দিষ্ট scope-এ বাইরের গবেষকদের লিখিত নিয়মে আমন্ত্রণ জানাতে পারে। ISO/IEC 29147 ত্রুটি প্রকাশের প্রক্রিয়াকে মান হিসেবে লিখে রাখে।
লক্ষ্য করুন, প্রতিটি পথের মূলে একই জিনিস: মালিকের আগে থেকে দেওয়া, লিখিত, সীমাবদ্ধ অনুমতি। বেশিরভাগ bug bounty-র নিয়মে কোন ঠিকানা, কোন ধরনের পরীক্ষা নিষিদ্ধ, আর ডেটা পেলে কী করবেন, সব লেখা থাকে। Scope-এর বাইরে এক পা দিলে সেই সুরক্ষা আর থাকে না। অন্য দেশের কর্মসূচিতে অংশ নিলেও নিজের দেশের আইন প্রযোজ্য হতে পারে। তাই শুরুতে নিজের ল্যাব আর অনুমতি দেওয়া CTF-ই সবচেয়ে নিরাপদ পথ; সেখানে ভুল হলেও কারও ক্ষতি হয় না।
মূল উপলব্ধি: একজন পেশাদারের পরিচয় তাঁর দক্ষতায় যতটা, ততটাই তাঁর সীমা মানায়। নিরাপত্তা পরীক্ষার জন্য লিখিত অনুমতি লাগে; সেটি বাধা নয়, এটাই এই পেশার ভিত্তি।
অনুশীলন
সবগুলো কাল্পনিক ডেটায় করুন। কোনো আসল system-এ পরীক্ষা নয়।
-
নতুন ঝুঁকি যোগ: ঝুঁকি R9: LEF ০.৪ থেকে ২.৫, LM ২ থেকে ১৮ লাখ। মাঝের বার্ষিক ক্ষতি আর দুই চূড়ার গুণফল বের করুন। ৫০ লাখের সীমা পার হয় কি? খাতায় কত নম্বরে বসবে?
মাঝের LEF = √(০.৪ × ২.৫) = √১ = ১। মাঝের LM = √(২ × ১৮) = √৩৬ = ৬। বার্ষিক ক্ষতি ১ × ৬ = ৬ লাখ। উঁচু দিক ২.৫ × ১৮ = ৪৫ লাখ, তাই ৫০ লাখ পার হয় না। ৭.৭-এর R2-এর নিচে আর ৫.৭-এর R4-এর ওপরে, অর্থাৎ তৃতীয়। নতুন মোট ৪১.৫ লাখ।
-
পরিকল্পনার সমালোচনা: এক পরামর্শদাতা বলছেন, “প্রথম প্রান্তিকেই ১০ লাখে SIEM আর একটি নতুন firewall কিনুন। MFA পরে হবে, কর্মীরা বিরক্ত হবেন।” তিনটি দুর্বলতা দেখান, আর বিকল্প বলুন।
১. ঝুঁকির শিকল নেই: কোন R কত কমবে, তা বলা হয়নি। ২. SIEM চালানোর মানুষ নেই, আর ১৫-র ১০ লাখ গেলে API আর backup-এর টাকা থাকে না। ৩. R1 আর R4-এর সবচেয়ে সস্তা প্রতিকার, MFA, পিছিয়ে গেল। বিরক্তির সমাধান হলো passkey আর ধাপে ধাপে চালু করা, বাদ দেওয়া নয়। বিকল্প: Q1-এ C1, C2, C11; সস্তা log সংরক্ষণ আগে; SIEM নিয়ে সিদ্ধান্ত চালানোর সামর্থ্য দেখে।
-
আউটপুট অনুমান: ধাপ ৮-এর detection কোডে
score(4, 30)চালালে আউটপুট কী হবে? আগে হাতে বের করুন। ঘটনা:203.0.113.7-এর ৫টি ব্যর্থতা ১০ থেকে ১৪ মিনিটে, login ১৫-তে;198.51.100.9-এর ৩টি ব্যর্থতা ২০ থেকে ২২ মিনিটে, login ২৩-এ;203.0.113.20-এর ব্যর্থতা ৩০, ৪৫, ৬০, ৭৫ মিনিটে, login ৯০-এ;198.51.100.30-এর login ১০০-তে, আগে কোনো ব্যর্থতা নেই।প্রথম ঠিকানায় ৫টি ব্যর্থতা, alert, TP. দ্বিতীয়টিতে ৩টি, ৪-এর কম, alert নেই, FP নয়। তৃতীয়টিতে login ৯০-এ; ৩০ মিনিটের জানালায় পড়ে শুধু ৬০ আর ৭৫, মানে ২টি, তাই alert নেই, FN. চতুর্থ ঠিকানায় ব্যর্থতা নেই। আউটপুট:
n=4 win=30 TP=1 FP=0 FN=1 precision=1.00 recall=0.50মানে: জানালা ছোট করলে ধীরগতির ঘটনা হারিয়ে যায়।
-
নিজের একটি ছোট ক্যাপস্টোন: নিজের পরিবার বা ছোট ক্লাবের ডিজিটাল জীবনকে “প্রতিষ্ঠান” ধরুন। ৫টি সম্পদ, ৩টি ঝুঁকি, ৩টি control আর প্রতিটির একটি পরীক্ষা লিখুন।
নমুনা উত্তর: সম্পদ: email, mobile wallet, ফোন, ছবির backup, Facebook পেজ। ঝুঁকি: email হারানো, ফোন চুরি, ছবি মুছে যাওয়া। Control ও পরীক্ষা: email-এ passkey, আর recovery code দিয়ে login মহড়া; ফোনে screen lock আর encryption, আর দূর থেকে মোছার পথ খুঁজে রাখা; ছবির ২টি কপি, আর একটি ছবি ফিরিয়ে দেখা। আসল ফলাফল হলো শিকল: প্রতিটি সারিতে সম্পদ, ঝুঁকি, control, পরীক্ষা।
নিজেকে যাচাই করুন
ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।
ক্রমএকটি নিরাপত্তা programme-এর কাজ সঠিক ক্রমে সাজান (▲▼ চেপে সরান)
- সম্পদ আর ডেটার তালিকা করা
- Threat model বানানো
- ঝুঁকি মেপে সাজানো
- Control বেছে রোডম্যাপ করা
- Test আর মহড়া দিয়ে যাচাই করা
- শিক্ষা নিয়ে ঝুঁকির খাতা হালনাগাদ করা
ঝুঁকি A: বছরে ০.৪টি ঘটনা, প্রতিটিতে ২৫ লাখ ক্ষতি। ঝুঁকি B: বছরে ৪টি ঘটনা, প্রতিটিতে ১ লাখ। শুধু বার্ষিক প্রত্যাশিত ক্ষতি দেখলে কোনটি আগে?
- B, কারণ বেশিবার ঘটে
- A, কারণ বছরে ১০ লাখ বনাম ৪ লাখ
- দুটি সমান
- হিসাব করা যায় না
সপ্তাহে ৪০ ঘণ্টা কাজ ধরে, ২৪×৭ একটি SOC আসন চালাতে ছুটি বাদে ন্যূনতম কতজন লাগে?
- ৩ জন
- ৩.৫ জন
- ৪.২ জন
- ৮ জন
একটি দোকান gateway-র hosted payment page ব্যবহার করে, কার্ডের নম্বর তার server-এ আসে না। কোন কথাটি সবচেয়ে ঠিক?
- কার্ড নিরাপত্তার সব দায় শেষ
- PCI DSS-এর সব শর্ত আগের মতোই থাকে
- Webhook যাচাইয়ের আর দরকার নেই
- পরিধি ছোট হয়, তবে website আর webhook-এর দায়িত্ব থাকে
Webhook-এ “paid” বার্তা এলে অর্ডার পাঠানোর আগে কোন সমন্বয়টি সবচেয়ে ভালো?
- URL গোপন রেখে বার্তাটি মেনে নেওয়া
- HMAC সই, পরিমাণ মেলানো, idempotency আর দৈনিক reconciliation
- ক্রেতার app-এর পাঠানো অবস্থা মেনে নেওয়া
- বার্তাটি Base64-এ পাঠানোর শর্ত দেওয়া
বাজেট ১০। A: খরচ ৬, ফল ৯। B: খরচ ৫, ফল ৭। C: খরচ ৫, ফল ৭। প্রতি টাকার ফল দেখে লোভী নিয়মে আর সেরা সমাবেশে মোট ফল কত?
- লোভী ৯, সেরা ১৪
- লোভী ১৪, সেরা ১৪
- লোভী ৯, সেরা ১৬
- লোভী ৭, সেরা ৯
আপনি নিরাপত্তা শিখছেন। একটি public bug bounty কর্মসূচিতে যোগ দেওয়ার আগে কী করবেন?
- প্রতিষ্ঠানের সব domain পরীক্ষা শুরু করা
- আগে একটি অন্য দোকানে অনুমতি ছাড়া হাত পাকানো
- Scope, নিষিদ্ধ কাজ আর রিপোর্টের নিয়ম পড়ে তার ভেতরে থাকা
- ত্রুটি পেলে আগে সামাজিক মাধ্যমে জানানো
শব্দকোষ
লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন, অর্থ দেখাবে। এই পর্বের সব নতুন শব্দ এখানে একসাথে:
মনে রাখুন
- Programme-এর প্রাণ হলো শিকল: সম্পদ → threat → ঝুঁকি → control → পরীক্ষা.
- ঝুঁকি বলুন range-এ, টাকায়, অনুমানের উৎসসহ।
- আগে MFA, পরীক্ষিত backup আর IR plan; বড় টুল পরে, মানুষ তৈরি হলে।
- Planner খসড়া দেয়; শেষ ক্রম আর ঝুঁকি মেনে নেওয়া মানুষের সিদ্ধান্ত।
- নিরাপত্তা পরীক্ষার জন্য লিখিত অনুমতি লাগে। ল্যাব, অনুমতি দেওয়া CTF, bug bounty-র scope আর অনুমোদিত কাজই আপনার পথ।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পর্ব ৭৬ · Numerical সমস্যার অনুশীলনপরবর্তী পর্বEntropy, key space, ঝুঁকি, CVSS আর detection, পূর্ণ সমাধানসহ।
- সাইবার নিরাপত্তা · কোর্স হোম৮০টি পর্বপুরো কোর্সের রোডম্যাপ।
- পর্ব ৪ · Threat modelingপিছনে দেখুনDFD, STRIDE আর threat থেকে backlog.
- পর্ব ৬৮ · Cyber risk managementপিছনে দেখুনFAIR, range আর Monte Carlo.
- পর্ব ৬৬ · Tabletop exerciseপিছনে দেখুনপুরো মহড়ার নকশা, inject আর after-action report.
- System Design · Security designপাশের ট্র্যাকবড় system-এর নিরাপত্তার নকশা।
- Cloud & DevOps · Incident managementপাশের ট্র্যাকপ্রকৌশল দলের incident-এর চর্চা।
- NIST Cybersecurity Frameworkমূল উৎসCSF 2.0, profile আর সহায়ক নথি।
- CIS Critical Security Controlsমূল উৎসSafeguard আর Implementation Group.