সরাসরি পর্বে যান
পর্ব ৭৫ · ৮০-এর মধ্যে · মডিউল ১২

ক্যাপস্টোন — একটি প্রতিষ্ঠানের নিরাপত্তা: threat model থেকে incident মহড়া পর্যন্ত

Capstone — Building a Security Programme for One Organisation, from Threat Model to Incident Rehearsal

Taught in Bangla, this capstone lesson builds a security programme for a fictional grocery: ten documents covering assets, threat model, a money-range risk register, identity, network, endpoint, web, API and secure software baselines, logging and detection, SOC versus MDR, an incident plan with a 60-minute rehearsal, a one-year roadmap, a one-page board summary and self-assessment.

এই পর্বে যা শিখবেন

  • সম্পদের তালিকা থেকে 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

দশ ধাপের নিরাপত্তা programme জানা ১ সম্পদ · ২ Threat model · ৩ ঝুঁকি গড়া ৪ পরিচয় · ৫ Network · ৬ Web · ৭ SDLC ধরা ও সাড়া ৮ Log ও detection · ৯ Incident মহড়া চালানো ১০ Governance · রোডম্যাপ · বোর্ড
ছবি ৭৫.১ — ওপর থেকে নিচে কাজ এগোয়। ঘটনা বা মহড়ার শিক্ষা আবার ওপরের সারিতে ফেরে, তাই কাজটি কখনো পুরো শেষ হয় না।

আপনার স্তরে কোন ধাপগুলো করবেন

স্তরযা করবেনফলাফল
শুরুর স্তরধাপ ১, ধাপ ২ (শুধু পেমেন্ট flow), ধাপ ৩ (৩টি ঝুঁকি), ধাপ ৪-এর MFA অংশ, আর ধাপ ৯-এর মহড়া পড়ে উত্তর লেখা৫টি ছোট নথি
মাঝের স্তরধাপ ১ থেকে ৯ পুরো, আর ধাপ ১০-এর vendor তালিকা৯টি নথি, ৫টি detection rule-এর পরীক্ষা
উন্নত স্তরসব ধাপ, রোডম্যাপ, বোর্ডের এক পাতা, ঝুঁকিতে Monte Carlo, নিজের ল্যাবে rule চালানোপুরো programme আর বন্ধুদের নিয়ে একটি মহড়া

তাজা বাজার কাল্পনিক। কোনো আসল দোকান, website বা app-কে এই প্রকল্পের নমুনা বানিয়ে পরীক্ষা করবেন না। নিরাপত্তা পরীক্ষার জন্য লিখিত অনুমতি লাগে; অনুমতি ছাড়া প্রবেশ অপরাধ। আইনের সীমা আছে পর্ব ৬-এ।

২ · ধাপ ১ আর ২: সম্পদ, ডেটা আর threat model

ধাপ ১ · সম্পদের তালিকা আর ডেটার মানচিত্র

ঘরে কী আছে না জানলে তালা কেনা যায় না। Asset inventory হলো কী কী আছে আর কার দায়িত্বে, তার তালিকা। Data inventory বলে কোন ডেটা কোথায় যায়। পদ্ধতি: পর্ব ২ (CIA), পর্ব ৩২ (সম্পদ), পর্ব ৭০ (ডেটা)।

সম্পদমালিকডেটাC-I-A গুরুত্বকোথায়, কতদিন
Order databaseCTOনাম, ফোন, ঠিকানা, অর্ডারউচ্চ-উচ্চ-উচ্চCloud, ৩ বছর (অনুমান)
CCTV রেকর্ডারAdmin প্রধানছবি, ভিডিওউচ্চ-মাঝারি-মাঝারিঅফিস, ৩০ দিন
Rider appOps প্রধানলোকেশন, ক্রেতার ঠিকানাউচ্চ-মাঝারি-উচ্চফোন + cloud, ৯০ দিন
………………………………………

ধাপ ২ · DFD আর STRIDE

এবার ছবি আঁকুন। Data flow diagram (DFD) দেখায় ডেটা কোন পথে চলে। Trust boundary হলো সেই দাগ, যেখানে বিশ্বাসের মাত্রা বদলায়, যেমন মহল্লার বাইরের রাস্তা আর বাড়ির গেট। প্রতিটি দাগ পার হওয়া flow-তে STRIDE-এর ছয়টি প্রশ্ন করুন। পদ্ধতি আছে পর্ব ৪-এ।

তাজা বাজারের DFD

Dashed lines are trust boundaries; F1 to F5 are flows to analyse

তাজা বাজারের data flow diagram Cloud সীমানা প্রধান কার্যালয়ের সীমানা ক্রেতা রাইডার Gateway API server Order DB Log Backup কর্মীর PC File server CCTV NVR F1 F2 F3 F4 F5 CCTV আলাদা zone-এ, cloud-এর পথ নেই
ছবি ৭৫.২ — F1 ক্রেতার HTTPS, F2 রাইডারের API, F3 gateway-র webhook, F4 database query, F5 কর্মীর admin প্রবেশ। F3 সরাসরি টাকার হিসাব বদলাতে পারে।
FlowSTRIDEকী ভুল হতে পারেControlপরীক্ষা
F1Spoofingঅন্যের অ্যাকাউন্টে loginRate limit, passkeyলকের নিয়ম test
F1Info disclosureঅন্যের অর্ডার দেখাServer-এ মালিকানা যাচাইদুই test account
F3Tamperingনকল “paid” বার্তাHMAC, পরিমাণ মেলানোভুল সই প্রত্যাখ্যান
F5Elevationকর্মী থেকে adminJIT, role আলাদামাসিক access review
………………………………………

ক্যাপস্টোনের মূল দক্ষতা হলো একটি অটুট শিকল: সম্পদ থেকে threat, threat থেকে control, control থেকে পরীক্ষা। একটি পেমেন্ট flow ধরে শিকলটি দেখুন।

  1. সম্পদঅর্ডারের অবস্থা
  2. FlowF3 webhook
  3. ThreatTampering
  4. Controlসই, পরিমাণ
  5. পরীক্ষা৪টি case
অর্ডার ১০৪২ · ২,৩৫০ টাকা (কাল্পনিক)
অবস্থা
গুণ
খাতায়
  1. সম্পদ। অর্ডার ১০৪২-এর অবস্থা pending. এই একটি শব্দ paid হলেই পণ্য বেরিয়ে যায়, তাই এখানে integrity সবচেয়ে জরুরি। গুদামের দারোয়ানের খাতায় “ছাড়পত্র” লেখার মতো। মালিক হিসাব প্রধান।
  2. Flow. Gateway টাকা পেয়ে আমাদের API-তে একটি webhook পাঠায়, অর্থাৎ নিজে থেকে একটি বার্তা। এটি trust boundary পার হচ্ছে, তাই বার্তাটি নিজে থেকে বিশ্বাসযোগ্য নয়।
  3. Threat. অবস্থাটি এখন প্রশ্নের মুখে। কেউ gateway সেজে (S) বা বার্তা বদলে (T) জানাতে পারে, টাকা এসেছে। ফল: বিনা টাকায় পণ্য। কৌশল এখানে বিষয় নয়, বিষয় হলো কী রক্ষা করছি। ঝুঁকির খাতায় R5 খোলা হলো।
  4. Control. বার্তা এলে আগে HMAC সই যাচাই, তারপর অর্ডারের পরিমাণ মেলানো। অবস্থা এখনো pending. এক বার্তা দুবার এলে idempotency দ্বিতীয়টিকে উপেক্ষা করে। রোডম্যাপে এটি C8.
  5. পরীক্ষা। ৪টি case: ঠিক সই হলে paid; ভুল সই হলে প্রত্যাখ্যান আর alert; পরিমাণ না মিললে আটকে রাখা; একই বার্তা দ্বিতীয়বার এলে কিছু না বদলানো। সব test build-এ চলে, তাই পরে কেউ ভুলে ভাঙতে পারবেন না।
  6. প্রমাণ। অর্ডার এখন 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 rangeLM range (লাখ)অনুমানের উৎসসিদ্ধান্ত
R1 ransomwareCTO০.১–০.৫২০–১২০দলের অনুমান, প্রকাশিত ঘটনাকমানো
………………………………………………

৪ · ধাপ ৪ আর ৫: পরিচয়, network আর endpoint-এর ভিত্তি

ধাপ ৪ · পরিচয়ের পরিকল্পনা

ব্যাংকের লকারে সবাই এক চাবি পান না। ধাপটি সেই নীতির লিখিত রূপ: কোন ধরনের মানুষ বা system কীভাবে নিজেকে প্রমাণ করবে, আর কতটুকু পাবে। পদ্ধতি: পর্ব ১৬, পর্ব ১৯, পর্ব ২০।

কেLoginঅধিকারযাচাই
ক্রেতাPassword + OTP, ঐচ্ছিক passkeyশুধু নিজের অর্ডারObject-level test
কর্মীSSO + MFARBAC ভূমিকা, least privilegeত্রৈমাসিক access review
AdminPhishing-প্রতিরোধী passkey বা security keyJust-in-time, ১ ঘণ্টা, অনুমোদনসহSession log
রাইডারApp-এ ফোনে বাঁধা tokenআজকের deliveryহারানো ফোনে token বাতিল test
Service, vendorWorkload identity, সময়-বাঁধা প্রবেশএকটি কাজSecret-এর বয়স রিপোর্ট
………………………………

সাথে দুটি লিখিত নিয়ম রাখুন। কর্মী চলে গেলে একই দিনে সব অ্যাকাউন্ট বন্ধ। আর দুটি break-glass অ্যাকাউন্ট সিলগালা খামের মতো তোলা থাকবে; ব্যবহার হলেই alert.

ধাপ ৫ · Network আর endpoint-এর baseline

Baseline মানে এমন ন্যূনতম মান, যার নিচে কোনো যন্ত্র বা network চলবে না। পদ্ধতি: পর্ব ২২, পর্ব ২৫, পর্ব ২৭, পর্ব ২৯, পর্ব ৩২, পর্ব ৩৫।

এলাকাতাজা বাজারের baselineপ্রমাণ
অফিসের zoneকর্মী, অতিথি Wi-Fi, CCTV আলাদা VLAN; মাঝে default denyRule তালিকা, নিজের network-এ যাচাই
CloudDatabase-এ public পথ নেই; admin যায় ZTNA বা VPN হয়েSecurity group রিপোর্ট
PCFull-disk encryption, স্থানীয় admin নয়, EDR৪০ যন্ত্রের অবস্থা
রাইডারের ফোনMDM বা work profile, screen lock, হারালে wipeEnrollment তালিকা
PatchCritical ৭ দিন, KEV-এ থাকা ত্রুটি ৪৮ ঘণ্টা (নিজেদের ধরা নিয়ম)Patch-এর বয়স
EmailSPF, DKIM, DMARC p=rejectDMARC রিপোর্ট

Cloud-এর ভাগাভাগি দায়িত্বের জন্য পর্ব ৭২, আর কর্মীর প্রবেশের নকশার জন্য পর্ব ৭৪ দেখুন। Hardening-এর নমুনা আছে পর্ব ৩০ আর পর্ব ৩১-এ।

৫ · ধাপ ৬ আর ৭: Web, API আর নিরাপদ software

ধাপ ৬ · Web আর API hardening, OWASP-এর সাথে মিলিয়ে

তালিকাটি পরীক্ষার খাতা নয়, নিজের app-এর প্রতিটি বৈশিষ্ট্যকে OWASP Top 10 (২০২৫) আর API Security Top 10 (২০২৩)-এর সাথে মেলানোর ফর্ম। পদ্ধতি: পর্ব ৩৭ থেকে পর্ব ৪৪।

বৈশিষ্ট্যOWASPপরিকল্পনাপরীক্ষাপর্ব
অর্ডার দেখাA01, API1Server-এ মালিকানা যাচাই (BOLA)দুই test account৩৮
পণ্য খোঁজাA05Parameterized queryCode review, SAST৩৯
ক্রেতার রিভিউA05Output encoding, CSPনিজের staging-এ header যাচাই৪০
LoginA07, API2Rate limit, ফাঁস হওয়া password আটকানোLimit-এর unit test১৫
ঈদের voucherAPI6প্রতি অ্যাকাউন্টে সীমাব্যবসার নিয়মের test৪৩
পেমেন্টের errorA10সন্দেহে fail secure: paid নয়Timeout test৪৪
………………………………………

ধাপ ৭ · Secure SDLC আর supply chain-এর গেট

গার্মেন্টসে প্রতিটি লাইনের শেষে একজন QC থাকেন। Software-এও তেমনি security gate বসে। কোনটি কাজ থামাবে আর কোনটি শুধু সতর্ক করবে, তা আগেই ঠিক করুন। পদ্ধতি: পর্ব ৪৫, পর্ব ৪৮, পর্ব ৪৯, DevSecOps.

স্তরগেটথামাবে?
নকশানতুন ডেটা flow হলে threat model হালনাগাদহ্যাঁ
Pull requestএকজনের review, secret scanningহ্যাঁ
BuildSAST, SCA, lockfile, SBOMCritical হলে হ্যাঁ
ReleaseSigned artifact, ধাপে ধাপে rollout, rollback-এর পথহ্যাঁ
চলমাননতুন ত্রুটির SLA, বছরে একবার অনুমোদিত pentest (পর্ব ৫০)রিপোর্ট
………………………

পেমেন্টের একটি ভালো নকশা-সিদ্ধান্ত: কার্ডের নম্বর আপনার server-এ আসবেই না। Gateway-র hosted page বা SDK ব্যবহার করলে PCI DSS-এর পরিধি অনেক ছোট হতে পারে, হয়তো SAQ A-এর পথে। পরিধি শূন্য হয় না। ঠিক কোন ফর্ম লাগবে, acquirer-এর সাথে নিশ্চিত করুন (পর্ব ৬৯)।

৬ · ধাপ ৮: Log, detection আর SOC না MDR

মহল্লার পাহারার তিনটি অংশ: কী দেখবেন, কখন বাঁশি বাজাবেন, বাঁশি শুনে কে আসবেন। পদ্ধতি: পর্ব ৫৫, পর্ব ৫৬, পর্ব ৫৯, পর্ব ৬০।

RuleLog উৎসঝুঁকিকে দেখবেনTest
অনেক ব্যর্থতার পর loginAPIR3, R4On-callPlanted event
ভুল সইয়ের webhookAPIR5On-callUnit test
অস্বাভাবিক বড় refundহিসাব appR4হিসাব প্রধাননমুনা ডেটা
Backup বন্ধ বা ব্যর্থBackupR1CTOমাসিক মহড়া
Break-glass ব্যবহারIdentityR1, 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 commanderOps প্রধান, বিকল্প CTO………
প্রযুক্তি, যোগাযোগ, লেখকCTO · marketing প্রধান · একজন scribe………
গুরুত্ব ঘোষণাS1: বিক্রি বন্ধ বা ডেটা ফাঁসের সন্দেহ………
Out-of-band পথআলাদা ফোন গ্রুপ, ছাপানো ফোন তালিকা………
RTO, RPO৪ ঘণ্টা, ২৪ ঘণ্টা………
বাইরের যোগাযোগআইনজীবী, gateway, cloud, IR সহায়তা, CIRT (জাতীয় ঘটনা-সাড়া দল)………

মহড়ার পরিস্থিতি

ঈদের আগের বৃহস্পতিবার সকাল ৯:২০। প্রধান কার্যালয়ের file server আর গুদামের PC-র ফাইল খোলা যাচ্ছে না। মুক্তিপণের একটি নোটে দাবি, ক্রেতার ডেটা নেওয়া হয়েছে। Cloud-এর API এখনো চলছে। Backup-এর একটি কপি immutable, আকারে ১২০ GB, গত রাতের। ঘটনা কীভাবে শুরু হলো, তা এই মহড়ার বিষয় নয়। সময়সূচি পর্ব ৬৬-এর মতোই: প্রথম ৫ মিনিট নিয়ম, শেষ ৮ মিনিট hotwash. কোনো system-এ হাত পড়বে না।

Decision log · মহড়ার ঘড়ি
মিনিট
সিদ্ধান্ত
কে
যুক্তি
  1. মিনিট ৫ · ঘোষণা। Ops প্রধান ঘোষণা করেন, এটি S1, আর তিনিই commander. দল মূল email ছেড়ে আলাদা ফোন গ্রুপে যায়। Scribe decision log-এ সময় লেখা শুরু করেন।
  2. মিনিট ১২ · বিচ্ছিন্ন করা। অফিস থেকে cloud-এর VPN পথ বন্ধ। দাম: গুদামে কয়েক ঘণ্টা কাগজে কাজ। যুক্তি: containment-এ ছড়ানো থামানো আগে আসে (পর্ব ৬২)।
  3. মিনিট ২০ · প্রমাণ। আক্রান্ত যন্ত্র মোছা হবে না, শুধু network থেকে আলাদা। Log আর snapshot রক্ষা, বাইরের IR সহায়তাকে ডাকা। মুছে ফেললে কী ঘটেছিল, তা আর জানা যাবে না (পর্ব ৬৩)।
  4. মিনিট ২৮ · পুনরুদ্ধার। ২০ MB/s গতিতে ১২০,০০০ ÷ ২০ = ৬,০০০ সেকেন্ড, মানে ১০০ মিনিট। যাচাইয়ে ৬০ মিনিট ধরে মোট ১৬০ মিনিট, যা ২৪০ মিনিটের RTO-র ভেতরে। তবে আগে পরিষ্কার পরিবেশ আর নতুন credential; এ হিসাব শুধু তখনই খাটে, যদি restore আগে পরীক্ষা করা থাকে।
  5. মিনিট ৩৬ · ডেটার দাবি। নোটের দাবি প্রমাণ নয়, উড়িয়ে দেওয়ার মতোও নয়। Log দেখে পরিধি ঠিক হবে। ব্যক্তিগত ডেটা গেলে কাকে কখন জানাতে হবে, আইনজীবী দেখবেন (পর্ব ৬, পর্ব ৭০), আর gateway-র চুক্তির শর্তও।
  6. মিনিট ৪৪ · মুক্তিপণ। Commander একা এই সিদ্ধান্ত নেন না। আগে লেখা নীতি অনুযায়ী মালিক আর আইনজীবী বসেন। Restore সম্ভব, তাই এখন উত্তর “না”; টাকা দিলেও ডেটা মুছবে, এমন নিশ্চয়তা নেই। এখানে আইনি দিকও আছে।
  7. মিনিট ৫২ · বার্তা ও শেখা। ১৫ মিনিটে তৈরি holding statement: জানা তথ্য, নেওয়া ব্যবস্থা, ক্রেতার করণীয়, পরের আপডেটের সময়। তারপর hotwash: তিনটি ফাঁক, প্রতিটিতে মালিক আর তারিখ। সেগুলোই ফিরে যায় ঝুঁকির খাতায়।

৮ · ধাপ ১০, রোডম্যাপ আর বোর্ডের এক পাতা

ধাপ ১০ · Governance, privacy আর vendor

এই ধাপ ঠিক করে, কে দায়িত্বে, কোন নিয়মে, আর বাইরের কে কতটা ঢুকছে। পদ্ধতি: পর্ব ৬৭, পর্ব ৬৯, পর্ব ৭০, পর্ব ৭১, পর্ব ৫৪।

বিষয়তাজা বাজারেপ্রমাণ
নীতি ও দায়িত্বএক পাতার নিরাপত্তা নীতি, মালিক অনুমোদিত; ঝুঁকির মালিক নির্দিষ্টস্বাক্ষরিত নথি
কাঠামোNIST CSF 2.0-র ছয় কাজে নিজের অবস্থা; ভিত্তি হিসেবে CIS Controls IG1এক পাতার profile
Privacyআইনি ভিত্তি, ডেটা কমানো, retention, ক্রেতার অনুরোধের পথপ্রক্রিয়ার তালিকা
CCTV, রাইডারের লোকেশনউদ্দেশ্য লেখা, রাখার সময় সীমিত, কে দেখবেন নির্দিষ্টদেখার log
VendorTier ১: 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 আগে লাগে।

অনুমিত হিসাব (লাখ টাকা)
কাজ
এই প্রান্তিকের খরচ
মোট খরচ
বাকি বাজেট
বছরে কমল
বাকি ঝুঁকি
  1. শুরু। বার্ষিক অনুমিত ঝুঁকি 35.5 লাখ, বাজেট 15 লাখ। ধাপ ১ থেকে ১০-এর নথি এই সময়েই তৈরি হয়, খরচ মূলত মানুষের সময়।
  2. Q1 · টিকে থাকা। MFA ও passkey (C1), immutable backup (C2), IR plan আর প্রথম মহড়া (C11). ৩ + ৩ + ২ = ৮ জন-সপ্তাহ, খরচ 3.5. কমে 5.0 + 4.5 + 1.5 = 11.0, বাকি ঝুঁকি 24.5.
  3. Q2 · ক্রেতার ডেটা ও টাকা। API-র মালিকানা যাচাই (C3), webhook সই (C8). ৬ + ২ = ৮ জন-সপ্তাহ, খরচ 1.8. মোট কমল 16.7, বাকি 18.8.
  4. Q3 · দেখতে পাওয়া। কেন্দ্রীয় log ও ১০টি rule (C7), ৪০ যন্ত্রে EDR (C5). ৫ + ৩ = ৮, খরচ 4.5. মোট খরচ 9.8, বাকি বাজেট 5.2, বাকি ঝুঁকি 14.3.
  5. 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, খোলা CORSDiff পড়া, নিজের ল্যাবে পরীক্ষা
অনুমোদন-ছাড়া বা injection-প্রবণ কোডReview, test, পর্ব ৪৯
Triage-এ বাড়তি আত্মবিশ্বাসমানুষের চূড়ান্ত সিদ্ধান্ত

নিচের prompt-এ আসল নাম বা গোপন তথ্য নেই, আর AI-কে সমালোচক হিসেবে রাখা হয়েছে, লেখক হিসেবে নয়। আসল প্রতিষ্ঠানের ক্ষেত্রে IP, চুক্তি, credential বা ক্রেতার তথ্য পেস্ট করবেন না।

তুমি একজন অভিজ্ঞ নিরাপত্তা পর্যালোচক। আমি একটি কাল্পনিক ৬০ জনের অনলাইন মুদি দোকানের নিরাপত্তা programme লিখেছি। নিচে আমার ঝুঁকির খাতা আর রোডম্যাপ আছে। [এখানে নিজের কাল্পনিক টেবিল পেস্ট করো] ১. কোন control-এর পেছনে কোনো ঝুঁকি নেই, আর কোন ঝুঁকির কোনো control নেই, তালিকা দাও। ২. কোন অনুমান সবচেয়ে দুর্বল, কেন বলো। ৩. কাজের ক্রমে কোনো নির্ভরতার ভুল আছে কি না দেখাও। ৪. কোনো CVE নম্বর, আইনের ধারা বা পরিসংখ্যান বানাবে না; নিশ্চিত না হলে "জানি না" বলো। ৫. শুধু রক্ষার পরামর্শ দাও, কোনো হামলার ধাপ নয়।

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-এ পরীক্ষা নয়।

  1. নতুন ঝুঁকি যোগ: ঝুঁকি R9: LEF ০.৪ থেকে ২.৫, LM ২ থেকে ১৮ লাখ। মাঝের বার্ষিক ক্ষতি আর দুই চূড়ার গুণফল বের করুন। ৫০ লাখের সীমা পার হয় কি? খাতায় কত নম্বরে বসবে?

    মাঝের LEF = √(০.৪ × ২.৫) = √১ = ১। মাঝের LM = √(২ × ১৮) = √৩৬ = ৬। বার্ষিক ক্ষতি ১ × ৬ = ৬ লাখ। উঁচু দিক ২.৫ × ১৮ = ৪৫ লাখ, তাই ৫০ লাখ পার হয় না। ৭.৭-এর R2-এর নিচে আর ৫.৭-এর R4-এর ওপরে, অর্থাৎ তৃতীয়। নতুন মোট ৪১.৫ লাখ।

  2. পরিকল্পনার সমালোচনা: এক পরামর্শদাতা বলছেন, “প্রথম প্রান্তিকেই ১০ লাখে SIEM আর একটি নতুন firewall কিনুন। MFA পরে হবে, কর্মীরা বিরক্ত হবেন।” তিনটি দুর্বলতা দেখান, আর বিকল্প বলুন।

    ১. ঝুঁকির শিকল নেই: কোন R কত কমবে, তা বলা হয়নি। ২. SIEM চালানোর মানুষ নেই, আর ১৫-র ১০ লাখ গেলে API আর backup-এর টাকা থাকে না। ৩. R1 আর R4-এর সবচেয়ে সস্তা প্রতিকার, MFA, পিছিয়ে গেল। বিরক্তির সমাধান হলো passkey আর ধাপে ধাপে চালু করা, বাদ দেওয়া নয়। বিকল্প: Q1-এ C1, C2, C11; সস্তা log সংরক্ষণ আগে; SIEM নিয়ে সিদ্ধান্ত চালানোর সামর্থ্য দেখে।

  3. আউটপুট অনুমান: ধাপ ৮-এর 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

    মানে: জানালা ছোট করলে ধীরগতির ঘটনা হারিয়ে যায়।

  4. নিজের একটি ছোট ক্যাপস্টোন: নিজের পরিবার বা ছোট ক্লাবের ডিজিটাল জীবনকে “প্রতিষ্ঠান” ধরুন। ৫টি সম্পদ, ৩টি ঝুঁকি, ৩টি control আর প্রতিটির একটি পরীক্ষা লিখুন।

    নমুনা উত্তর: সম্পদ: email, mobile wallet, ফোন, ছবির backup, Facebook পেজ। ঝুঁকি: email হারানো, ফোন চুরি, ছবি মুছে যাওয়া। Control ও পরীক্ষা: email-এ passkey, আর recovery code দিয়ে login মহড়া; ফোনে screen lock আর encryption, আর দূর থেকে মোছার পথ খুঁজে রাখা; ছবির ২টি কপি, আর একটি ছবি ফিরিয়ে দেখা। আসল ফলাফল হলো শিকল: প্রতিটি সারিতে সম্পদ, ঝুঁকি, control, পরীক্ষা।

নিজেকে যাচাই করুন

ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।

ক্রমএকটি নিরাপত্তা programme-এর কাজ সঠিক ক্রমে সাজান (▲▼ চেপে সরান)

  1. সম্পদ আর ডেটার তালিকা করা
  2. Threat model বানানো
  3. ঝুঁকি মেপে সাজানো
  4. Control বেছে রোডম্যাপ করা
  5. Test আর মহড়া দিয়ে যাচাই করা
  6. শিক্ষা নিয়ে ঝুঁকির খাতা হালনাগাদ করা

ঝুঁকি 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, নিষিদ্ধ কাজ আর রিপোর্টের নিয়ম পড়ে তার ভেতরে থাকা
  • ত্রুটি পেলে আগে সামাজিক মাধ্যমে জানানো

শব্দকোষ

লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন, অর্থ দেখাবে। এই পর্বের সব নতুন শব্দ এখানে একসাথে:

মনে রাখুন

  1. Programme-এর প্রাণ হলো শিকল: সম্পদ → threat → ঝুঁকি → control → পরীক্ষা.
  2. ঝুঁকি বলুন range-এ, টাকায়, অনুমানের উৎসসহ।
  3. আগে MFA, পরীক্ষিত backup আর IR plan; বড় টুল পরে, মানুষ তৈরি হলে।
  4. Planner খসড়া দেয়; শেষ ক্রম আর ঝুঁকি মেনে নেওয়া মানুষের সিদ্ধান্ত।
  5. নিরাপত্তা পরীক্ষার জন্য লিখিত অনুমতি লাগে। ল্যাব, অনুমতি দেওয়া CTF, bug bounty-র scope আর অনুমোদিত কাজই আপনার পথ।

পরের পর্বে: কোর্সের মূল অংশ এখানেই শেষ। পর্ব ৭৬ · Numerical সমস্যার অনুশীলনে entropy, key space, ঝুঁকি, CVSS আর detection-এর সব হিসাব পূর্ণ সমাধানসহ ঝালিয়ে নেবেন।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

এই পর্বটি শেয়ার করুন:
এই পর্বে ভুল পেয়েছেন? জানান