লিখিত ও মৌখিক (ভাইভা) প্রশ্ন — crypto, network, web আর incident response

সংজ্ঞা: Vulnerability ব্যবস্থার ভেতরের দুর্বলতা। Threat সম্ভাব্য ক্ষতির কারণ। Risk হলো সেই ক্ষতি ঘটার সম্ভাবনা আর তার মাত্রার মিলিত মাপ।

উদাহরণ: কাল্পনিক অনলাইন বাজারের পুরোনো library-তে একটি ত্রুটি আছে (vulnerability). সংগঠিত অপরাধী দল এমন ত্রুটি খোঁজে (threat). ক্রেতার ডেটা ফাঁস হলে যে ক্ষতি হবে, সেটি risk.

সীমা: Threat, threat actor আর threat event-এর ব্যবহার উৎসভেদে আলাদা। উত্তরে যে সংজ্ঞা নিলেন, এক লাইনে বলে দিন।

নম্বর কোথায়: তিন সংজ্ঞা (৩), উদাহরণ বা ছক (১), risk কমানোর উপায় (১)। পর্ব ২ · পর্ব ১

যেখানে নম্বর কাটে: তিনটিকে সমার্থক লেখা; risk-এ সম্ভাবনা বা মাত্রা একটি বাদ দেওয়া।

Confidentiality মানে অনুমোদিত মানুষই পড়বেন। Integrity মানে অনুমতি ছাড়া বদল হবে না, হলে ধরা পড়বে। Availability মানে দরকারের সময় পাওয়া যাবে।

টানাটানি: Key হারালে encrypted ডেটাও হারায়, মানে confidentiality বাড়াতে গিয়ে availability ঝুঁকিতে পড়ে। যাচাইয়ের ধাপ বাড়লে কাজ ধীর হয়। তাই একটি control-এর দাম অন্য লক্ষ্যে দেখতে হয়।

নম্বর কোথায়: তিন সংজ্ঞা (৩), উদাহরণ (১), টানাটানি (১)। পর্ব ২

যেখানে নম্বর কাটে: Availability-কে “সবসময় চালু” লেখা; integrity-কে গোপনীয়তার সাথে মিলিয়ে ফেলা।

• Least privilege: কাজের জন্য যতটুকু দরকার, তার বেশি অধিকার নয়। হাতে গোনা কয়টি চাবিই দারোয়ানের কাছে থাকে, পুরো গোছা নয়। এটি Saltzer ও Schroeder-এর (১৯৭৫) নীতিগুলোর একটি।
• Defense in depth: একাধিক স্বাধীন স্তর, যাতে একটি ব্যর্থ হলেও অন্যটি থামায়।
• Fail secure: ব্যর্থ হলে নিরাপদ অবস্থায় বন্ধ, যেমন ভল্ট। Fail safe মানুষের প্রাণের দিকে খোলে, যেমন অগ্নিনির্গমনের দরজা। ব্যর্থতার দিক আগেই ঠিক করতে হয়।

হিসাব: P = c + (১ − c) × স্তরগুলোর গুণফল = ০.০৫ + ০.৯৫ × (০.১ × ০.১) = ০.০৫ + ০.০০৯৫ = ৫.৯৫%. স্বাধীন স্তর হলে ফল হতো ১%. মানে: common cause, যেমন একই admin account, স্তরের লাভের বড় অংশ খেয়ে ফেলে।

নম্বর কোথায়: তিন টীকা (৩), সূত্র ও হিসাব (২), মানে (১)। পর্ব ৩

যেখানে নম্বর কাটে: Fail secure আর fail safe গুলিয়ে ফেলা; স্তরের ঝুঁকি সরাসরি গুণ করে common cause ভুলে যাওয়া; defense in depth-কে একই tool দুবার বসানো ভাবা।

চার প্রশ্ন: কী নিয়ে কাজ করছি? কী ভুল হতে পারে? কী করব? কাজটি ভালো হলো কি না?

Trust boundary হলো যেখানে বিশ্বাসের মাত্রা বদলায়, যেমন browser থেকে API-তে ঢোকা। Data flow diagram-এ সীমানা পেরোনো প্রতিটি তীরে প্রমাণ ছাড়া কিছু মানা হয় না।

নম্বর কোথায়: চার প্রশ্ন (১), STRIDE (৩), trust boundary (১), উদাহরণ (১)। পর্ব ৪

যেখানে নম্বর কাটে: Non-repudiation-কে integrity লেখা; Threat modeling-কে শুধু scanner চালানো ভাবা।

সাত ধাপ: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, C2, Actions on Objectives.

Pyramid of Pain: Hash বা IP বদলানো হামলাকারীর জন্য সহজ, আচরণ (TTP) বদলানো কঠিন। তাই IOC দ্রুত কাজ দেয়, আর TTP-ভিত্তিক detection বেশি টেকে।

সীমা: ATT&CK vulnerability-র তালিকা নয়, সেটি CVE-এর কাজ। Coverage মানে পরীক্ষিত আচরণ, ম্যাপে সবুজ রং নয়।

নম্বর কোথায়: তুলনা (৩), সাত ধাপ (১), Pyramid of Pain (১), সীমা (১)। পর্ব ৫

যেখানে নম্বর কাটে: ATT&CK-কে CVE-এর মতো তালিকা বলা; tactic আর technique উল্টে লেখা; version না লেখা।

সংজ্ঞা: Encryption key ছাড়া ডেটা পড়া অসম্ভব করে। Symmetric-এ দুই পক্ষের একই গোপন key. Asymmetric-এ একটি public আর একটি private key-র জোড়া।

সংখ্যা: ১০০ জন জোড়ায় জোড়ায় গোপন কথা বলতে চাইলে symmetric-এ লাগে n(n − ১) ÷ ২ = ১০০ × ৯৯ ÷ ২ = ৪,৯৫০টি key. Asymmetric-এ প্রতিজনের এক জোড়া, মোট ২০০টি key.

একসাথে কেন: Hybrid ব্যবস্থায় public key দিয়ে একটি session key ঠিক হয়, তারপর দ্রুত symmetric encryption বড় ডেটা সামলায়। TLS এভাবেই চলে। Ephemeral key exchange এতে forward secrecy যোগ করে।

সীমা: শুধু encryption অখণ্ডতা দেয় না, তাই AEAD লাগে। আর public key-এর পরিচয় আসে certificate থেকে।

নম্বর কোথায়: সংজ্ঞা (২), ছক (৪), সংখ্যা বা উদাহরণ (২), hybrid ও সীমা (২)। পর্ব ৮ · পর্ব ১০

যেখানে নম্বর কাটে: “Asymmetric বেশি নিরাপদ” লেখা (শক্তি নির্ভর করে key size-এ, ধরনে নয়); RSA-তে encrypt আর sign-এর key উল্টে লেখা।

উদাহরণ: Download-এর পাতায় SHA-256 দেখে ফাইল মেলালেন, কিন্তু একই সাইট দখল হলে digest-ও বদলাতে পারে। Webhook-এ HMAC দুই পক্ষের মধ্যে কাজ করে। Software release-এ signature যেকোনো ব্যবহারকারী যাচাই করতে পারেন।

সীমা: Signature প্রমাণ করে key ব্যবহার হয়েছে, বার্তাটি সত্য তা নয়। hash(key + message) ব্যবহার করবেন না, HMAC নিন; ট্যাগ মেলান constant-time ফাংশনে।

নম্বর কোথায়: ছক (৫), উদাহরণ (২), সীমা (১)। পর্ব ৯ · পর্ব ১১

যেখানে নম্বর কাটে: Hash-কে encryption বলা; MAC-এ non-repudiation আছে লেখা; digest কোন পথে এল সেটি না ভাবা।

Nonce পুনরাবৃত্তি: একই key আর nonce-এ keystream একই, তাই C₁ ⊕ C₂ = P₁ ⊕ P₂. Key ফাঁস না হলেও বার্তার সম্পর্ক ফাঁস হয়। সমস্যাটি নীরব, তাই (key, nonce) নজরে রাখতে হয়।

AEAD: Authenticated Encryption with Associated Data. এটি গোপনীয়তা আর অখণ্ডতা একসাথে দেয়। AD অংশ encrypt হয় না, কিন্তু tag দিয়ে সুরক্ষিত, যেমন header. Random ৯৬-bit nonce-এ NIST-এর সীমা এক key-তে ২^৩২ বার encryption.

উপসংহার: নতুন কাজে যাচাই করা library-র AEAD নিন; নিজে mode জোড়া দেবেন না।

নম্বর কোথায়: ছক (৪), nonce (২), AEAD (২)। পর্ব ৮ · পর্ব ১৪

যেখানে নম্বর কাটে: IV আর nonce-কে গোপন ভাবা; AES-কে “mode ছাড়া নিরাপদ” লেখা; GCM-এর ক্ষতি শুধু গোপনতায় সীমিত ভাবা।

এই ছোট সংখ্যা শুধু শেখার জন্য, বাস্তবে এত ছোট মান নিরাপদ নয়।

1. A = g^a mod p = ৫^৬ mod ২৩ = ৮.
2. B = g^b mod p = ৫^১৫ mod ২৩ = ১৯.
3. Alice হিসাব করেন ১৯^৬ mod ২৩ = ২, Bob হিসাব করেন ৮^১৫ mod ২৩ = ২. গোপন মান ২, যা পথে কখনো যায়নি।

দুর্বলতা: Diffie-Hellman (১৯৭৬) একই গোপন মান দেয়, পরিচয় দেয় না। MITM দুই পক্ষের সাথে আলাদা key বসাতে পারে। সমাধান: key share-এর ওপর signature আর certificate, যেমন TLS-এ।

বাস্তবে: Session-প্রতি ephemeral ECDHE আর key মুছে ফেলা forward secrecy দেয়।

নম্বর কোথায়: তিন ধাপের হিসাব (৩), দুর্বলতা (২), প্রতিকার (১)। পর্ব ১০

যেখানে নম্বর কাটে: a বা b পথে পাঠানো লেখা; গোপন মানকে পরিচয়ের প্রমাণ ভাবা; mod ভুলে যাওয়া।

Certificate একটি নাম আর public key-কে বাঁধে, CA তাতে সই করে। শিকল হলো: Trust store-এর root → intermediate → server certificate.

যাচাই: স্বাক্ষর, মেয়াদ, CA flag, key usage, SAN-এ hostname, আর শিকলটি trust store-এর root-এ পৌঁছায় কি না।

Root offline কেন: ফাঁস হলে পুরো শিকল ভাঙে, আর intermediate সহজে বদলানো যায়।

Revocation: CRL বড় হয়, OCSP-তে গতি ও গোপনতার দাম আছে, আর অনেক client ব্যর্থ হলে এগিয়ে যায়। তাই ছোট মেয়াদ আর automation. Certificate Transparency জাল issuance ধরা সহজ করে, কিন্তু নিজে আটকায় না।

নম্বর কোথায়: শিকল (২), যাচাই (২), revocation (২)। পর্ব ১১

যেখানে নম্বর কাটে: CN-কে এখনো মূল জায়গা লেখা; CT-কে প্রতিরোধ বলা; private key certificate-এর ভেতরে আছে লেখা।

সংজ্ঞা: TLS দুই পক্ষের মাঝে গোপনতা, অখণ্ডতা আর server-এর পরিচয় যাচাই দেয়। TLS 1.3 এসেছিল RFC 8446-এ (২০১৮), আর এখনকার সংস্করণ RFC 9846 (২০২৬).

উদাহরণ: মোবাইল network-এ একটি RTT ২০০ ms হলে নতুন সংযোগে ডেটা শুরুর আগে TLS 1.2-তে প্রায় ৪০০ ms, TLS 1.3-এ প্রায় ২০০ ms লাগে (TCP-র সময় বাদে)।

সীমা: 0-RTT-এর ডেটা replay হতে পারে, তাই শুধু নিরাপদ কাজে। SNI সাধারণত এখনো দেখা যায়। TLS যেখানে শেষ, ডেটা সেখানে খোলা। ভালো configuration: TLS 1.3, আর TLS 1.2 শুধু ECDHE + AEAD সহ।

নম্বর কোথায়: সংজ্ঞা (১), ছক (৪), ছবি (৩), সীমা (২)। পর্ব ১২ · TLS ও HTTPS

যেখানে নম্বর কাটে: TLS 1.3-এ certificate খোলা যায় লেখা; forward secrecy-কে গোপন key-র দৈর্ঘ্য ভাবা; 0-RTT-এর ঝুঁকি বাদ দেওয়া।

Server-এর password জানার দরকার নেই, শুধু যাচাই করা দরকার। তাই plaintext বা ফেরানো যায় এমন encryption নয়, রাখতে হয় ধীর password hash.

SHA-256 কেন নয়: এটি দ্রুত, memory কম লাগে, cost বাড়ানো যায় না, তাই অনুমান সস্তা। Argon2id memory আর সময় দুটোই খরচ করায়। নতুন system-এ Argon2id, না পেলে scrypt; FIPS-এর শর্তে PBKDF2; bcrypt পুরোনো system-এ, যার সীমা ৭২ byte.

সীমা: ধীর hash ফাঁসের পরের অনুমান ধীর করে, phishing ঠেকায় না। পুরোনো hash আপগ্রেড হয় login-এর সময়।

নম্বর কোথায়: নীতি (১), ছক (৩), ধীর hash (২)। পর্ব ১৩

যেখানে নম্বর কাটে: Salt-কে গোপন লেখা; password encrypt করার কথা বলা; bcrypt-এর সীমাকে অক্ষর লেখা।

Envelope encryption: DEK ডেটা encrypt করে, KEK সেই DEK-কে মোড়ায়। মোড়ানো DEK ডেটার পাশে থাকে, KEK থাকে KMS বা HSM-এ। ছবি: ডেটা → DEK → KEK → root key, প্রতিটি তীরে “মোড়ায়” লিখুন।

লাভ: KEK rotate করলে শুধু DEK-গুলো আবার মোড়াতে হয়, পুরো ডেটা ছুঁতে হয় না। Key-এর জীবনের ছয় ধাপ: তৈরি, সংরক্ষণ, ব্যবহার, rotation, বাতিল, ধ্বংস।

সময়ের হিসাব: ডেটা x বছর গোপন রাখতে হবে, migration-এ y বছর লাগে, quantum আসতে z বছর। x + y > z হলে এখনই শুরু করতে হয়, কারণ আজ জমানো ট্র্যাফিক পরে খোলা যেতে পারে। z অজানা, তাই উত্তরে সেটিকে অনুমান বলুন।

নম্বর কোথায়: Envelope ও ছবি (৪), ছক (৩), সময়ের হিসাব (১)। পর্ব ১৪

যেখানে নম্বর কাটে: DEK আর KEK উল্টে লেখা; “quantum AES ভাঙবে” বলা; quantum আসার নির্দিষ্ট সাল দাবি করা।

ক্রম: আগে পরিচয় যাচাই, পরে অনুমতি। Authentication ছাড়া authorization অর্থহীন, আবার ঠিক login-এর পরেও অন্যের ডেটা দেখা গেলে সেটি authorization-এর ব্যর্থতা (পর্ব ৩৮)।

Factor: তিন ধরনের: যা জানেন, যা আছে, যা আপনি। Password আর PIN মিলিয়ে MFA হয় না, দুটিই “যা জানেন”।

নম্বর কোথায়: তিন সংজ্ঞা (৩), উদাহরণ (১), ক্রম (১)। পর্ব ১৫ · পর্ব ১৯

যেখানে নম্বর কাটে: দুটি শব্দ গুলিয়ে ফেলা; “login মানেই সব অনুমতি” লেখা।

TOTP: TOTP = HMAC(secret, ⌊t ÷ ৩০⌋), তারপর ৬ অঙ্কে ছোট করা। Server আর ফোন একই secret আর ঘড়ি ব্যবহার করে। Server-কে হিসাব করতে হয় বলে seed hash করা যায় না, encrypted রাখতে হয়।

OTP-র সীমা: কোডটি সাইটের নামের সাথে বাঁধা নয়। নকল পাতায় মানুষ টাইপ করলে সেটি আসল সাইটে relay হতে পারে।

Passkey (FIDO2/WebAuthn):

1. Server একটি random challenge পাঠায়।
2. Browser নিজে origin লিখে দেয়, মানুষ নয়।
3. যন্ত্রের private key challenge আর origin-এর ওপর সই করে।
4. Server নিজের public key দিয়ে যাচাই করে, origin-ও মেলায়।

নকল সাইটের origin আলাদা, তাই আসল সাইটের key সেখানে ব্যবহার হয় না। Database ফাঁস হলে শুধু public key যায়।

সীমা: MFA চুরি হওয়া session, malware আর দুর্বল recovery থামায় না। Login-এর শক্তি তার সবচেয়ে দুর্বল fallback-এর সমান।

নম্বর কোথায়: TOTP (২), OTP-র সীমা (১), passkey-র ধাপ (৩), সীমা (২)। পর্ব ১৬

যেখানে নম্বর কাটে: OTP-কে phishing-প্রতিরোধী বলা; TOTP seed hash করার কথা লেখা; recovery পথ ভুলে যাওয়া।

Cookie: Secure শুধু HTTPS-এ পাঠায়, HttpOnly JavaScript-এর পড়া আটকায়, SameSite cross-site পাঠানো সীমিত করে, __Host- prefix domain সীমিত করে।

যাচাই: Algorithm নিজের কোডের তালিকা থেকে, token-এর header দেখে নয়। তারপর signature, iss, aud, exp. Login-এর পরে session ID নতুন করুন, আর logout হোক server-এ।

নম্বর কোথায়: ছক (৩), cookie (২), যাচাই (১)। পর্ব ১৭

যেখানে নম্বর কাটে: JWT-কে encrypted বলা; cookie মোছাকে logout ভাবা; flag-কে XSS-এর পূর্ণ সমাধান লেখা।

OAuth delegated access দেয়: password নয়, সীমিত ও মেয়াদি token. OIDC তার ওপরে পরিচয়ের স্তর, ID token দিয়ে। সংক্ষেপে OAuth = authorization, OIDC = authentication.

1. App একটি code_verifier বানায়, তার SHA-256 থেকে code_challenge.
2. Browser authorization server-এ যায়, সাথে challenge, redirect URI আর state.
3. ব্যবহারকারী login করে অনুমতি দেন।
4. Browser কোডসহ app-এ ফেরে; app state মেলায়।
5. App কোড আর verifier দিয়ে token চায়, server hash মিলিয়ে token দেয়।

PKCE কী ঠেকায়: চুরি হওয়া কোড verifier ছাড়া ভাঙানো যায় না। state CSRF ঠেকায়; nonce ID token-এর replay ঠেকায়।

সীমা: Access token পরিচয়ের প্রমাণ নয়। Implicit আর password grant বাদ। Redirect URI হুবহু মিলতে হবে। Consent phishing-এ মানুষ আসল পাতায় অনুমতি দেন, তাই admin consent আর grant পর্যালোচনা লাগে।

নম্বর কোথায়: পার্থক্য (২), পাঁচ ধাপ (৩), PKCE ও state (২), সীমা (১)। পর্ব ১৮

যেখানে নম্বর কাটে: Access token দিয়ে login ধরা; state আর nonce গুলিয়ে ফেলা; PKCE-কে শুধু mobile-এর জন্য লেখা।

Role explosion: শাখা, পদ আর অঞ্চলের মিশ্রণে role গুণ হয়ে বাড়ে। ABAC-এর শর্ত তা কমায়। বাস্তবে দুটি মিশিয়ে ব্যবহার হয়।

ReBAC: সম্পর্কের পথ দেখে, যেমন “এই নথি যে folder-এ, আপনি তার সম্পাদক”। শেয়ার করা নথির app-এ মানায়।

সীমা: Model যেটিই হোক, ফল প্রয়োগ হবে server-এ, ডিফল্ট deny-তে। PDP সিদ্ধান্ত নেয়, PEP প্রয়োগ করে।

নম্বর কোথায়: ছক (৩), role explosion (১), ReBAC (১), server-এ প্রয়োগ (১)। পর্ব ১৯

যেখানে নম্বর কাটে: RBAC-কে সবসময় খারাপ বা ABAC-কে সবসময় ভালো লেখা; UI-তে বোতাম লুকানোকে authorization ভাবা।

Privileged account-ই সবচেয়ে দামি চাবি। প্রথম কাজ তালিকা আর মালিক: মানুষ, service account, shared account, API key.

• JIT: অধিকার শুধু দরকারের সময়, তাই সময় সীমিত।
• JEA: অধিকার শুধু দরকারি কাজে, তাই পরিধি সীমিত।
• Break-glass: JIT ব্যবস্থা ব্যর্থ হলেও কাজ করবে এমন জরুরি account. সুরক্ষা আসে সিল, alert, পর্যালোচনা আর মহড়া থেকে।
• বাকি স্তর: আলাদা admin account, secret vault, admin-এর নাগালের বাইরের log, ফাঁস হলে আগে revoke.

সীমা: Privileged ঘণ্টা কমা মানে পুরো ঝুঁকি কমা নয়। Service account আর API key-ও গুনতে হয়।

নম্বর কোথায়: তালিকা (১), JIT ও JEA (২), break-glass (১), বাকি স্তর (১)। পর্ব ২০

যেখানে নম্বর কাটে: JIT আর JEA উল্টে লেখা; shared admin password-কে গ্রহণযোগ্য বলা।

মূল ভাবনা: পুরোনো protocol-এ পরিচয় একটি দাবি, প্রমাণ নয়। তাই প্রশ্ন: কে যাচাই করছে?

HTTPS-এ দেখা যায়: IP, port, সময়, আকার, আর সাধারণত DNS ও SNI. URL path, cookie, body দেখা যায় না। Metadata থেকেও তথ্য মেলে, যেমন beaconing-এর নিয়মিত সময়। তবে একটি সংকেত দেখে সিদ্ধান্ত নয়।

নম্বর কোথায়: ছক (৩), মূল ভাবনা (১), metadata (২)। পর্ব ২১ · পর্ব ২৪

যেখানে নম্বর কাটে: Eavesdropping আর MITM এক লেখা; HTTPS-কে সবকিছু লুকানো ভাবা।

DMZ ছবি: Internet → firewall → DMZ (web server) → firewall → ভেতরের zone (database, অফিস). নিয়ম লিখুন: Internet থেকে DMZ-তে শুধু 443; DMZ থেকে database-এ শুধু নির্দিষ্ট port; Internet থেকে ভেতরে সরাসরি পথ নেই। বাইরে খোলা সেবা দখল হলেও ভেতরে সরাসরি পথ থাকে না।

ক্রম: সাধারণত first match, তাই আগের চওড়া নিয়ম পরের নিয়মকে ঢেকে দেয়; একে shadowed rule বলে, hit counter দিয়ে ধরা যায়। Microsegmentation আর egress সীমা lateral movement কমায়। Implicit deny আছে কি না নিজের পণ্যে যাচাই করুন।

সীমা: Firewall পথ নিয়ন্ত্রণ করে; অনুমোদিত পথের ভেতরের ঝুঁকি থামায় না। VLAN নিজে নিরাপত্তা নয়, মাঝে নিয়ম লাগে।

নম্বর কোথায়: ছক (২), DMZ ছবি (৩), ক্রম (২), সীমা (১)। পর্ব ২২

যেখানে নম্বর কাটে: DMZ থেকে database-এ সব খোলা রাখা; ক্রম না বলা; egress বাদ দেওয়া।

Detection: Signature জানা জিনিস ধরে, precision ভালো, অচেনা ধরন ফসকায়। Anomaly স্বাভাবিকের বাইরের জিনিস ধরে, অচেনা ধরন পেতে পারে, কিন্তু অস্বাভাবিক মানেই ক্ষতিকর নয়।

হিসাব: TP = ১০০ × ০.৯ = ৯০. নিরীহ = ৯৯,৯০০, FP = ৯৯,৯০০ × ০.০১ = ৯৯৯. Precision = TP ÷ (TP + FP) = ৯০ ÷ ১,০৮৯ ≈ ৮.২৬%. Accuracy প্রায় ৯৯% হলেও ১২টি alert-এর মধ্যে আসল প্রায় ১টি। এটিই base-rate fallacy.

সীমা: Encrypted traffic-এ NIDS মূলত metadata দেখে, ভেতরের দৃষ্টি আসে endpoint আর application log থেকে। অবস্থান নিয়ে পণ্যভেদে পার্থক্য আছে: একই যন্ত্র দুই mode-এ চলতে পারে।

নম্বর কোথায়: ছক (৩), ছবি (২), detection (২), হিসাব (৩)। পর্ব ২৩

যেখানে নম্বর কাটে: Accuracy দেখে সন্তুষ্ট হওয়া; FP হিসাবে মোট ঘটনা নেওয়া (নিরীহ নয়); IPS-এর ব্যর্থতার দিক না বলা।

IPsec: ESP গোপনীয়তা আর integrity দেয়। AH শুধু integrity আর উৎস যাচাই দেয়, NAT-এর সাথে মেলে না। Tunnel mode-এ পুরো packet ভেতরে, নতুন header; transport mode-এ শুধু payload সুরক্ষিত।

সীমা: VPN পথ রক্ষা করে; malware, phishing বা দুর্বল app থেকে নয়। VPN gateway সবচেয়ে দামি দরজা, তাই patch আর MFA জরুরি।

নম্বর কোথায়: ছক (৩), ESP ও AH (১), দুই mode (১), সীমা (১)। পর্ব ২৫

যেখানে নম্বর কাটে: VPN-কে phishing-প্রতিরোধ বলা; ZTNA-কে একটি পণ্য ভাবা।

DMARC pass: SPF বা DKIM-এর অন্তত একটি pass করবে এবং From-এর domain-এর সাথে aligned হবে। পথ: none → quarantine → reject, report পড়ে পড়ে।

DNSSEC বনাম DoH: DNSSEC উত্তরের সত্যতা দেয়, গোপনীয়তা দেয় না। DoT আর DoH পথের গোপনীয়তা দেয়, উত্তরের উৎস প্রমাণ করে না। কোনোটি অন্যটির বিকল্প নয়।

সীমা: এসবের পরেও registrar account সবার ওপরে: phishing-প্রতিরোধী MFA আর lock লাগে। পুরোনো CNAME সরান, নইলে subdomain takeover-এর ঝুঁকি থাকে।

নম্বর কোথায়: ছক (৪), DMARC শর্ত (২), DNSSEC ও DoH (২)। পর্ব ২৬

যেখানে নম্বর কাটে: SPF-কে From যাচাই বলা; alignment বাদ দেওয়া; DNSSEC-কে encryption লেখা।

WPA3: SAE handshake দেয়, তাই ধরে রাখা handshake থেকে offline অনুমান কঠিন হয়, forward secrecy আসে, আর PMF বাধ্যতামূলক। WPA2-Personal-এ লম্বা, এলোমেলো passphrase অপরিহার্য। WPA3-তেও ছোট passphrase চলবে না।

802.1X: Supplicant (client), authenticator (AP), authentication server (RADIUS). অফিসে প্রতিজনের আলাদা পরিচয় থাকে। Client-কে server-এর certificate যাচাই করতেই হবে।

সীমা: PMF jamming ঠেকায় না, সেটি radio-স্তরের সমস্যা। Inventory ছাড়া rogue AP ধরা যায় না। Rogue AP আপনার network-এ জোড়া অনুমোদনহীন AP; evil twin নাম নকল করে client টানে।

নম্বর কোথায়: WPA3 (২), 802.1X (২), সীমা (১)। পর্ব ২৭

যেখানে নম্বর কাটে: WPA3-কে “ভাঙা অসম্ভব” বলা; RADIUS-কে AP লেখা।

Reflection: জাল উৎসের ঠিকানায় খোলা service উত্তর পাঠায়, উত্তর বড় হলে ক্ষতি বাড়ে। টিকে থাকে জাল ঠিকানা আর খোলা service-এর কারণে, তাই সমাধান BCP 38 আর অদরকারি service বন্ধ।

হিসাব: ৬৪ byte frame + ২০ byte (preamble ও gap) = ৮৪ byte = ৬৭২ bit. ১,০০০,০০০,০০০ ÷ ৬৭২ ≈ ১৪.৯ লাখ pps.

সীমা: Link ভরলে নিজের firewall কিছু করতে পারে না, উজানে সাহায্য লাগে। Autoscaling সময় কেনে, bill বাড়ায়, database-এর bottleneck সরায় না। আগে থেকে runbook আর যোগাযোগ রাখুন, আর সিস্টেমের চাপ পরীক্ষা শুধু নিজের সিস্টেমে, লিখিত অনুমতিতে।

নম্বর কোথায়: ছক (২), reflection (২), হিসাব (১), সীমা (১)। পর্ব ২৮

যেখানে নম্বর কাটে: Gbps, pps, rps গুলিয়ে ফেলা; ৮৪ byte-এর জায়গায় ৬৪ ধরা; autoscaling-কে সমাধান বলা।

অনুমতি আগে: Capture শুধু নিজের যন্ত্রে, অথবা লিখিত অনুমতি আছে এমন network-এ। অন্যের traffic ধরা অপরাধ হতে পারে (পর্ব ৬)।

ধাপ: আগে প্রশ্নটি ঠিক করুন। Flow record দেখে কোথায় তাকাবেন তা বুঝুন। Capture filter দিয়ে যতটুকু দরকার ততটুকু ধরুন, তারপর display filter দিয়ে দেখুন। ক্রমে পড়ুন: DNS প্রশ্ন, TCP-র SYN, SYN-ACK, ACK, তারপর TLS-এর ClientHello. কোন ধাপের পরে দেরি হচ্ছে, সময়ের ফাঁক থেকে সেটি লিখুন।

HTTPS-এ দেখা যায়: ঠিকানা, port, সময়, আকার, আর প্রায়ই domain-এর নাম। বিষয়বস্তু দেখা যায় না।

সীমা: Capture file-এ cookie, নাম আর ব্যক্তিগত তথ্য থাকতে পারে। তাই সীমিত ধরুন, নিরাপদে রাখুন, সময়মতো মুছুন।

নম্বর কোথায়: অনুমতি (১), ধাপ (২), দেখা যায় কী (১), সীমা (১)। পর্ব ২৪

যেখানে নম্বর কাটে: অনুমতির কথা বাদ দেওয়া; সব traffic একসাথে ধরা; encryption সব লুকায় ভাবা।

FDE: মূলত বন্ধ যন্ত্র রক্ষা করে, যেমন হারানো ল্যাপটপ। চালু যন্ত্রে malware আর memory-র key থেকে রক্ষা করে না। Recovery key জমা রাখতে হয়।

নম্বর কোথায়: ছক (৩), FDE (২)। পর্ব ২৯ · পর্ব ৫৯

যেখানে নম্বর কাটে: EDR-কে শুধু “নতুন antivirus” লেখা; FDE-কে চালু যন্ত্রের সুরক্ষা ভাবা।

কাজের ক্রম: নিজের server-এর ভূমিকা বুঝে CIS Benchmark থেকে শুরু, একবারে একটি বদল, কার্যকর মান ও সেবা ও ফেরার পথ যাচাই, ব্যতিক্রম লিখে রাখা।

উদাহরণ: umask 027-এ নতুন ফাইল ৬৪০, নতুন folder ৭৫০.

সীমা: SELinux আটকালে enforcing বন্ধ করা সমাধান নয়। Denial পড়ে সবচেয়ে ছোট অনুমতি দিন। আর log যন্ত্রের বাইরে পাঠান।

নম্বর কোথায়: ছক (৩), ক্রম (২), সীমা (১)। পর্ব ৩০ · OS নিরাপত্তা

যেখানে নম্বর কাটে: সমস্যা হলে SELinux বন্ধের পরামর্শ; benchmark অন্ধভাবে বসানো।

Tiering: Tier 0 (DC ও পরিচয়ের যন্ত্র), Tier 1 (server), Tier 2 (workstation). নিয়ম: উপরের credential নিচে নামে না। Tier 0 admin workstation-এ logon করলে credential দুর্বল যন্ত্রে নামে।

LAPS: প্রতি যন্ত্রে local admin password অনন্য করে, তাই এক password থেকে অনেক যন্ত্রে ছড়ানো আটকায়।

সীমা: নিরাপত্তার প্রকৃত সীমা forest, domain নয়। Detection-এ 4728, 4732, 4756-এর মতো group বদলের event কেন্দ্রে পাঠান, আর AD restore-এর মহড়া দিন।

নম্বর কোথায়: Tiering (২), LAPS (১), ছক (২), সীমা (১)। পর্ব ৩১

যেখানে নম্বর কাটে: NTLM হঠাৎ বন্ধের পরামর্শ, না মেপে; domain-কে নিরাপত্তার সীমা বলা।

অগ্রাধিকার: Severity মানে ঝুঁকি নয়। কাল্পনিক দুটি ত্রুটি: ভেতরের test server-এ CVSS 9.8, EPSS কম; internet-মুখী login server-এ CVSS 7.5, KEV-এ আছে। দ্বিতীয়টি আগে। ক্রম: KEV → exposure ও asset-এর গুরুত্ব → EPSS → CVSS. SSVC সিদ্ধান্তের একটি কাঠামো দেয়।

চক্র: Asset, মূল্যায়ন, অগ্রাধিকার, সারানো, যাচাই, রিপোর্ট। Patch না গেলে compensating control আর মেয়াদসহ exception.

সীমা: EPSS ০.৪ মানে সাধারণভাবে ৪০% অনুমান, আপনার system-এ নয়। Asset জানা না থাকলে patch হয় না।

নম্বর কোথায়: ছক (৩), অগ্রাধিকার ও উদাহরণ (৩), চক্র (১), সীমা (১)। পর্ব ৩২

যেখানে নম্বর কাটে: শুধু CVSS দিয়ে ক্রম করা; CVE আর CWE উল্টে লেখা; EPSS-কে আপনার সিস্টেমের সম্ভাবনা বলা।

3-2-1-1-0: ৩ কপি, ২ মাধ্যম, ১ অন্য জায়গায়, ১ immutable বা offline, ০ restore ত্রুটি। Backup-এর login আলাদা রাখুন, কারণ হামলাকারী আগে backup খোঁজে।

RPO ও RTO: RPO কত ডেটা হারানো যায়, RTO কত সময় বন্ধ থাকা যায়। ১০ TB ৫০০ Mbps-এ ফেরাতে: ১০,০০০ × ৮,০০০ ÷ ৫০০ = ১,৬০,০০০ সেকেন্ড ≈ ৪৪.৪ ঘণ্টা। RTO ৮ ঘণ্টা হলে এই নকশা ব্যর্থ।

সীমা: Double extortion-এ চুরি হওয়া ডেটার সমস্যা backup সারায় না। আক্রান্ত হলে আগে network থেকে আলাদা করুন, প্রমাণ রাখুন। টাকা দিলেও নিশ্চয়তা নেই, আইনি ঝুঁকি থাকতে পারে।

নম্বর কোথায়: ছক (৩), 3-2-1-1-0 (২), RPO ও RTO (২), সীমা (১)। পর্ব ৩৩ · পর্ব ৩৪

যেখানে নম্বর কাটে: RPO আর RTO উল্টে লেখা; backup-কে পূর্ণ সমাধান বলা; restore পরীক্ষা বাদ দেওয়া।

1. Hash: বদল ধরে।
2. Signature ও secure boot: বলে কে অনুমোদন করেছে, অননুমোদিত firmware চলে না।
3. Anti-rollback: Counter পুরোনো বৈধ firmware-এর জানা ত্রুটিতে ফেরা আটকায়, কারণ পুরোনোটির সইও বৈধ।

IoT-র তিন রোগ: default password, update নেই, দীর্ঘ আয়ু। কেনার আগেই unique credential আর ঘোষিত support period চান। যন্ত্র আলাদা zone-এ রাখুন।

OT: Safety আর availability আগে, confidentiality পরে। তাই patch পরিকল্পিত সময়ে, আর segmentation বেশি গুরুত্ব পায়।

নম্বর কোথায়: তিন স্তর (৩), IoT (১), OT (১)। পর্ব ৩৫

যেখানে নম্বর কাটে: শুধু hash দিয়ে অনুমোদন প্রমাণ করা; OT-তে IT-র মতো সাথে সাথে patch-এর পরামর্শ।

Origin = scheme + host + port; path গণনায় আসে না। SOP এক origin-এর script-কে অন্য origin-এর response পড়তে দেয় না। ব্যাংকের কাউন্টারের মতো: খামটি জমা দেওয়া যায়, কিন্তু অন্যের খাম খুলে পড়া যায় না।

CORS সুরক্ষা নয়, একটি ছাড়: server জানায় কোন origin পড়তে পারবে। Credentials-সহ * চলে না, হুবহু origin আর Allow-Credentials লাগে। Origin প্রতিফলিত করে ফেরত দেওয়া বিপজ্জনক।

Preflight: Simple request-এর শর্তের বাইরে হলে browser আগে OPTIONS পাঠায়, যেমন PUT, JSON বা নিজের header.

সীমা: SOP পড়া আটকায়, পাঠানো নয়; তাই CSRF আলাদা সমস্যা। CORS browser-এর নিয়ম; API রক্ষা করে server-এর authentication আর authorization.

নম্বর কোথায়: Origin ও SOP (২), CORS (২), preflight (১), সীমা (১)। পর্ব ৩৬

যেখানে নম্বর কাটে: CORS-কে API-র firewall ভাবা; SOP request পাঠানো থামায় লেখা।

OWASP Top 10 একটি সচেতনতা-তালিকা: পূর্ণ মান নয়, compliance তালিকা নয়, দশটি bug-ও নয়। ক্রম আপনার কাজের ক্রম নয়।

২০২৫: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, A10 Mishandling of Exceptional Conditions.

ASVS: যাচাইযোগ্য requirement-এর মান, যাতে তিনটি level আছে। Top 10 সচেতন করে, ASVS মাপে। ২০২৫-এ SSRF আলাদা বিভাগ নয়, A01-এর ভেতরে।

নম্বর কোথায়: কী ও কী নয় (১), দশটি (৩), ASVS (১)। পর্ব ৩৭

যেখানে নম্বর কাটে: পুরোনো সংস্করণের ক্রম লেখা, সাল ছাড়া; Top 10-কে compliance মান বলা।

IDOR: Server ব্যবহারকারীর দেওয়া ID দিয়ে সরাসরি বস্তু আনে, মালিকানা মেলায় না। প্রতিকার: query-তে owner বা tenant, যা যাচাই করা session থেকে আসে; deny by default; এক জায়গায় policy. UUID আন্দাজ কঠিন করে, অনুমতির বিকল্প নয়।

Injection: ডেটা আর আদেশ একই পথে গেলে input query-র গঠন বদলাতে পারে।

-- বিপজ্জনক ধরন: লেখা জোড়া দিয়ে query, input গঠনে মেশে
query = "SELECT * FROM orders WHERE id = " + <user-input>

-- নিরাপদ: গঠন আগে, মান পরে
query = "SELECT * FROM orders WHERE id = ? AND owner_id = ?"
db.execute(query, [order_id, session_user_id])

Parameterized query কেন কাজ করে: গঠন আগে parse হয়, মান পরে আসে, তাই মান গঠন বদলাতে পারে না। দ্বিতীয় সারিতে owner মিলিয়ে IDOR-ও বন্ধ হলো।

সীমা: ORDER BY-এর কলাম bind হয় না, allowlist map লাগে। Validation বাড়তি স্তর, bind-এর বিকল্প নয়। Least privilege ক্ষতি সীমিত করে, injection থামায় না।

Detection: Query নজরদারি, প্রত্যাখ্যানের log, CI-তে দুই ব্যবহারকারীর authorization পরীক্ষা।

নম্বর কোথায়: IDOR (৩), injection ও উদাহরণ (৩), সীমা ও detection (২)। পর্ব ৩৮ · পর্ব ৩৯

যেখানে নম্বর কাটে: Client-side check-কে যথেষ্ট বলা; escaping-কে প্রধান প্রতিরক্ষা লেখা; কাজ করে এমন হামলার লেখা দেওয়া।

সংজ্ঞা: XSS-এ অবিশ্বস্ত ডেটা আপনার পাতায় কোড হয়ে চলে। CSRF-এ অন্য সাইট ব্যবহারকারীর browser দিয়ে আপনার app-এ অনিচ্ছাকৃত অনুরোধ পাঠায়।

উদাহরণ: কাল্পনিক অনলাইন বাজারের review-তে encoding ছাড়া ব্যবহারকারীর লেখা বসলে তা stored XSS. বাজারের “ঠিকানা বদল” যদি শুধু cookie দেখে কাজ করে, তাহলে সেটি CSRF-এর ঝুঁকিতে।

প্রতিরক্ষার ক্রম: XSS-এ দেখানোর ঠিক আগে context-এর নিয়মে encoding, auto-escaping চালু, লেখায় textContent, CSP দ্বিতীয় স্তর। CSRF-এ GET কিছু বদলাবে না, session-বাঁধা token, SameSite আর Origin স্তর।

সীমা: XSS থাকলে CSRF প্রতিরক্ষা ভেঙে পড়ে, কারণ script একই origin থেকে token পড়তে পারে। HttpOnly শুধু cookie পড়া আটকায়। CORS CSRF প্রতিরক্ষা নয়। Bearer header-এ CSRF কম, কারণ browser সেটি নিজে জোড়ে না।

নম্বর কোথায়: সংজ্ঞা (২), ছক (৪), উদাহরণ (২), সীমা (২)। পর্ব ৪০ · পর্ব ৪১

যেখানে নম্বর কাটে: দুটিকে একই বলা; encoding input-এ করা; HttpOnly-কে XSS-এর সমাধান লেখা; XSS থাকলে CSRF token টেকে ভাবা।

SSRF: ব্যবহারকারীর দেওয়া গন্তব্যে server নিজের পরিচয়ে অনুরোধ পাঠায়, ফলে ভেতরের সম্পদে পৌঁছাতে পারে। অফিসের পিয়নকে দিয়ে বন্ধ ঘর থেকে ফাইল আনানোর মতো।

প্রতিরক্ষা: গন্তব্যের allowlist, প্রতিটি resolved IP যাচাই, সেই IP-তেই সংযোগ, redirect বন্ধ, egress firewall, আলাদা fetch service. Cloud-এ IMDSv2 আর কম অধিকারের role দুটোই লাগে।

Upload: ঘোষণা নয়, byte দেখুন। মূল নাম নয়, server-এর বানানো এলোমেলো নাম। Web root নয়, object storage বা বাইরের folder. আকার ও সংখ্যার সীমা, আর প্রতিটি download-এ অধিকার যাচাই। Path-এ canonicalize করে base-এর ভেতরে আছে কি না মেলান।

সীমা: Denylist অসম্পূর্ণ হতে বাধ্য। Content-Type client-এর ঘোষণা মাত্র।

নম্বর কোথায়: SSRF (২), প্রতিরক্ষা (২), upload (২)। পর্ব ৪২

যেখানে নম্বর কাটে: IP denylist-কে যথেষ্ট বলা; extension দেখে file বিশ্বাস করা।

Gateway: Token, rate limit, schema দেখতে পারে। Object কার, সেই ব্যবসায়িক ডেটা তার কাছে সাধারণত থাকে না, তাই BOLA ঠেকাতে পারে না। Authorization তিন স্তরে: function, object, property.

WAF: সময় কেনে, code সারায় না। WAF-এর সাথেও parameterized query লাগে। Header ব্রাউজারকে নির্দেশ দেয়: CSP আগে Report-Only, HSTS আগে ছোট max-age.

সীমা: Rate limit গতি কমায়, BOLA সারায় না। তালিকায় না থাকা shadow API পাহারার বাইরে থাকে।

নম্বর কোথায়: ছক (৩), gateway (১), WAF (১), সীমা (১)। পর্ব ৪৩ · পর্ব ৪৪

যেখানে নম্বর কাটে: Rate limit-কে authorization ভাবা; WAF-কে স্থায়ী সমাধান বলা।

পার্থক্য: SBOM বলে কী আছে; SCA তালিকাকে দুর্বলতার সাথে মেলায়; SLSA বলে build কতটা বিশ্বস্ত, provenance প্রমাণসহ।

সীমা: Shift left মানে release-পরের কাজ বাদ নয়। Hash আর স্বাক্ষর বলে “একই জিনিস, এই উৎস থেকে”, “ভালো জিনিস” নয়। “দেরিতে ১০০ গুণ খরচ” কোনো সর্বজনীন সত্য নয়, উৎস দেখে বলুন। Memory safety-র জন্য নতুন code নিরাপদ ভাষায় লেখা আর ASan-এর মতো tool test-এ ব্যবহার করা ভালো পথ।

নম্বর কোথায়: ছক (৪), তিন সংজ্ঞা (৩), সীমা (১)। পর্ব ৪৫ · পর্ব ৪৬ · পর্ব ৪৭ · পর্ব ৪৮

যেখানে নম্বর কাটে: SBOM-কে scanner বলা; signature-কে “নিরাপদ code”-এর প্রমাণ ভাবা।

বাকিরা: IAST পরীক্ষার সময় ভেতর থেকে দেখে; SCA dependency দেখে; Fuzzing নতুন পথ খোলা ইনপুট রেখে গভীরে যায়। মানুষের review ব্যবসায়িক যুক্তি ধরে।

সীমা: শূন্য finding মানে নিরাপদ নয়। Finding-এর শেষ হোক regression test-এ, যা পুরোনো code-এ ব্যর্থ হয়।

নম্বর কোথায়: ছক (৩), বাকিরা (২), সীমা (১)। পর্ব ৪৯

যেখানে নম্বর কাটে: SAST আর DAST উল্টে লেখা; একটি tool-কে যথেষ্ট বলা।

RoE: Scope, সময়, পদ্ধতির সীমা, যোগাযোগ, ডেটার নিয়ম আর থামার শর্ত।

অনুমতি: Pentest আর হামলার মূল পার্থক্য সিস্টেমের মালিকের লিখিত অনুমতি। উদ্দেশ্য ভালো হলেও অনুমতির বিকল্প হয় না, আর অননুমোদিত প্রবেশ অপরাধ। ত্রুটি হঠাৎ পেলে থামুন, ডেটায় হাত দেবেন না, সঠিক পথে জানান (VDP). বাংলাদেশের বর্তমান আইনের জন্য পর্ব ৬ দেখুন, এই পাতা আইনি পরামর্শ নয়।

সীমা: রিপোর্টই পণ্য। Finding বন্ধ হয় retest-এ, দাবিতে নয়। Purple team-এ দুই পক্ষ একসাথে detection উন্নত করে।

নম্বর কোথায়: ছক (৪), RoE (২), অনুমতি (২)। পর্ব ৫০ · পর্ব ৬

যেখানে নম্বর কাটে: Scan-কে pentest বলা; red team-কে বড় pentest ভাবা; লিখিত অনুমতির কথা বাদ দেওয়া।

Prompt injection-এ লেখা model-এর আচরণ বদলে দেয়। Direct-এ লেখক ব্যবহারকারী; indirect-এ লেখা আসে নথি বা ওয়েব থেকে, ব্যবহারকারী নির্দোষ। OWASP LLM Top 10-এর ২০২৬ সংস্করণে এটি LLM01.

কারণ: Model-এর ভেতরে নির্দেশ আর ডেটা একই token-স্রোত, আলাদা পথ নেই।

প্রতিরক্ষা: Model ঠকবে ধরে নিয়ে নকশা: ন্যূনতম tool, ঝুঁকির কাজে মানুষের অনুমোদন, allowlist, sandbox. RAG-এ অনুমতি যাচাই খোঁজার সময়ই। Output অবিশ্বস্ত ইনপুট হিসেবে encode করুন।

নম্বর কোথায়: সংজ্ঞা (১), কারণ (১), প্রতিরক্ষা (৩)। পর্ব ৫১

যেখানে নম্বর কাটে: System prompt-কে নিরাপত্তার সীমান্ত ভাবা; filter-কে পূর্ণ সমাধান বলা।

সংজ্ঞা: Memory safety মানে program নিজের buffer-এর বাইরে যায় না, আর free হওয়া memory আর ব্যবহার করে না।

দুই ধরনের টুল: Canary, ASLR, NX, CFI আর shadow stack release build-এ ত্রুটি কাজে লাগানোর খরচ বাড়ায়, ত্রুটি সারায় না। ASan, UBSan, Valgrind আর fuzzing test-এ ত্রুটি খুঁজে দেয়, যাতে কোডেই সারানো যায়।

সীমা: সবচেয়ে কার্যকর পথ হলো নতুন কোড memory-safe ভাষায় লেখা, পুরো কোড নতুন করে না লিখেও। “গুরুতর ত্রুটির প্রায় ৭০%” Microsoft আর Chromium-এর বড় C ও C++ কোডের প্রকাশিত হিসাব, সব software-এর সূত্র নয়।

নম্বর কোথায়: সংজ্ঞা (১), ছক (২), দুই ধরনের টুল (২), সীমা (১)। পর্ব ৪৭

যেখানে নম্বর কাটে: Mitigation-কে সমাধান বলা; ASan-কে release-এর সুরক্ষা ভাবা; overflow কীভাবে কাজে লাগানো হয় তার ধাপ লেখা।

কেন কাজ করে: এটি মানুষের ভালো গুণ কাজে লাগায়: সাহায্য করা, কর্তৃত্ব মানা। Authority, তাড়া আর গোপনীয়তা একসাথে দেখলে থামুন।

পার্থক্য: Vishing আর smishing মাধ্যম (ফোন, SMS). Pretexting হলো বানানো গল্প, যা যেকোনো মাধ্যমে চলে।

BEC: অনুরোধের পথের বাইরে, চেনা নম্বরে call-back আর দ্বৈত অনুমোদন। ব্যাংকের তথ্য বদলে অপেক্ষার নিয়ম। DMARC শুধু domain নকল কমায়।

সীমা: কণ্ঠ বা ভিডিও আর একা প্রমাণ নয়। OTP আর PIN কাউকে নয়।

নম্বর কোথায়: কারণ (১), পার্থক্য (২), BEC (২)। পর্ব ৫২

যেখানে নম্বর কাটে: দোষ মানুষের ওপর চাপানো; একই mail-এ উত্তর দিয়ে যাচাই করা।

স্তর:

• Mail: SPF, DKIM, DMARC, ফিল্টার। কাছাকাছি নামের domain থামায় না।
• Login: Passkey সবচেয়ে শক্ত, কারণ signature origin-এ বাঁধা।
• মানুষ: এক চাপের report, URL ডান দিক থেকে পড়া, নিজে টাইপ করে ঢোকা।
• দল: দ্রুত triage, পরিধি মিলিয়ে quarantine, block.

সাড়া: দ্রুত জানানো; password reset; session বাতিল; MFA method, mail rule আর OAuth grant পরীক্ষা; একই বার্তা আর কারা পেয়েছেন, খোঁজা। শাস্তি নয়, ধন্যবাদ।

সীমা: Password reset একা যথেষ্ট নয়। Simulation-এ click rate একা নয়; report rate আর সময় মাপুন।

নম্বর কোথায়: স্তর (৩), সাড়া (২), সীমা (১)। পর্ব ৫৩

যেখানে নম্বর কাটে: শুধু training-এর কথা বলা; reset-এর পরে session আর rule ভুলে যাওয়া।

Awareness হলো জানা। Culture হলো কেউ না দেখলেও কী স্বাভাবিক, সেই সাধারণ বোঝাপড়া। জানলেই করা হয় না, তাই নিরাপদ পথ সহজ করতে হয়।

Just culture: সৎ ভুলে ধন্যবাদ ও শেখা, বেপরোয়া বা ইচ্ছাকৃত ক্ষতিতে নিয়মমাফিক ব্যবস্থা। এটি শাস্তিহীনতা নয়। ভুল জানাতে ভয় পেলে ঘটনা দেরিতে ধরা পড়ে।

নম্বর কোথায়: পার্থক্য (২), just culture (২)। পর্ব ৫৪

যেখানে নম্বর কাটে: Culture-কে বছরে একটি training ভাবা।

থাকবে: কে, কী, কখন, কোথায়, কোথা থেকে, ফল।

থাকবে না: Password, token, পূর্ণ কার্ড নম্বর, বাড়তি ব্যক্তিগত তথ্য। ক্ষেত্র ঠিক হোক allow-list দিয়ে।

• UTC: সব উৎস এক সময়রেখায় মেলে। মূল সময়ও রাখুন।
• যন্ত্রের বাইরে: দখল হওয়া যন্ত্রের স্থানীয় log মোছা যায়।
• Hash chain: বদল ধরে, আটকায় না। বাইরের anchor না থাকলে সব hash নতুন করে লেখা যায়।
• Retention: ঝুঁকি, আইন, privacy আর খরচ মিলিয়ে, উৎস ভেদে আলাদা।

নম্বর কোথায়: ক্ষেত্র (২), কী নয় (১), তিন কারণ (৩)। পর্ব ৫৫

যেখানে নম্বর কাটে: Log-এ password রাখা; hash chain-কে পরিবর্তন প্রতিরোধ বলা।

SIEM-এর সাত কাজ: Collect → normalise → enrich → search → correlate → alert → report. Log management রাখে ও খোঁজে; SIEM তার ওপর normalise, correlate আর alert করে।

Sigma: YAML-এ লেখা পণ্য-নিরপেক্ষ log rule format, যা converter দিয়ে SIEM query হয়। Field mapping আর test আপনার দায়িত্ব।

Fixed window: ধরা যাক নিয়ম “৫ মিনিটে ১০টি ব্যর্থ login”. ১২টি ব্যর্থতার ঝাঁক দুই বাক্সের সীমায় ৬ + ৬ ভেঙে গেলে দুই দিকেই সীমার নিচে থাকে। Sliding window এটি এড়ায়।

Precision বাড়ানো: Threshold + sequence + context. Rule-ও code: version, test, review. ছাড় সরু, মালিকসহ, মেয়াদসহ।

সীমা: নীরব উৎসের alert না থাকলে সবুজ পর্দার অর্থ নেই।

নম্বর কোথায়: সাত কাজ ও পার্থক্য (৩), Sigma (২), window (২), সীমা (১)। পর্ব ৫৬

যেখানে নম্বর কাটে: SIEM-কে শুধু log ভান্ডার বলা; IP তালিকা থেকে detection শুরু করা; noisy rule পুরো বন্ধ করা।

ছোট প্রতিষ্ঠানে একই মানুষ দুটি ভূমিকা নিতে পারেন, আর প্রতিষ্ঠানভেদে নামের ব্যবহার আলাদা। অনেক CSIRT ঘটনার বাইরেও সতর্কবার্তা আর vulnerability সমন্বয়ের কাজ করে। উত্তরে সেটি লিখে দিন।

Tier: Tier 1 triage, Tier 2 তদন্ত, Tier 3 গভীর বিশ্লেষণ ও hunting. Alert-এর পথ: triage, enrichment, investigation, escalation, closure.

Metric: MTTD, MTTA, MTTR-এর সংজ্ঞা আগে লিখুন, median দেখুন। Metric-কে লক্ষ্য বানালে সেটি নষ্ট হয়।

Staffing: সপ্তাহে ১৬৮ ঘণ্টা ÷ ৪০ = ৪.২ জন একটি আসনের নিচের সীমা, ছুটি ছাড়া। ছুটি ধরলে অন্তত ৫ জন। ছুটি, প্রশিক্ষণ, handover আর shrinkage মিলিয়ে পর্ব ৬০-এর পূর্ণ হিসাবে প্রায় ৬ জন।

নম্বর কোথায়: ছক (৩), tier (১), metric (১), staffing (১)। পর্ব ৬০ · পর্ব ৬১

যেখানে নম্বর কাটে: দুটিকে সবসময় আলাদা দল ধরা; MTTR-এর সংজ্ঞা না দেওয়া; ৪.২ জনকেই চূড়ান্ত উত্তর লেখা।

Threat intelligence: যা একটি সিদ্ধান্ত বদলায়। STIX তথ্যের ছাঁচ, TAXII আদান-প্রদানের পথ, TLP শেয়ারের সীমা।

Hunting loop: Hypothesis → তদন্ত → pattern ও TTP → analytics. কিছু না পেলেও সীমাসহ নথি লিখুন, সফল hunt-কে rule বানান।

সীমা: বিরল মানে সূত্র, প্রমাণ নয়। Attribution একটি মূল্যায়ন।

নম্বর কোথায়: ছক (৩), intelligence (১), loop (১), সীমা (১)। পর্ব ৫৭ · পর্ব ৫৮ · পর্ব ৫৯

যেখানে নম্বর কাটে: IOC feed-কেই intelligence বলা; hunting-কে alert দেখা ভাবা।

উদাহরণ: কাল্পনিক বাজারে অদ্ভুত login-এর alert এল (alert). Analyst যাচাই করে দেখলেন admin account দখল হয়েছে, incident ঘোষণা হলো। IC কাজ ভাগ করলেন, আলাপ গেল out-of-band পথে।

সীমা: তিনটি মানচিত্র একই কাজের আলাদা উপস্থাপন। Rev. 3 সুপারিশগুলোকে CSF 2.0-এর Function-এ সাজায় আর IR-কে ঝুঁকি ব্যবস্থাপনার অংশ করে। Plan আগে লিখে মহড়া দিন, ঘটনার রাতে বানানো যায় না।

নম্বর কোথায়: সংজ্ঞা (২), তুলনা (৩), ছবি (৩), উদাহরণ ও সীমা (২)। পর্ব ৬১

যেখানে নম্বর কাটে: প্রতিটি alert-কে incident বলা; PICERL-কে NIST-এর ধাপ লেখা; Rev. 3-এর বদল না জানা।

Account বন্ধ: Session, token, API key আর service account আলাদা করে বাতিল করতে হয়। ক্রম: নিয়ন্ত্রণকারী credential আগে। AD-তে krbtgt দুবার, মাঝে ticket-এর সর্বোচ্চ আয়ু অপেক্ষা।

Rebuild: Admin ক্ষমতা গেলে বা পরিবর্তনের পুরো তালিকা অজানা হলে।

সীমা: Scope (host, account, secret, ডেটা, সময়) না জেনে সরালে হামলাকারী ফেরে, একে whack-a-mole বলা হয়। সরানোর আগে প্রমাণ রাখুন।

নম্বর কোথায়: ছক (৩), account (১), rebuild (১), সীমা (১)। পর্ব ৬২

যেখানে নম্বর কাটে: তিনটিকে এক লেখা; আগে মুছে পরে প্রমাণ খোঁজা।

Chain of custody: প্রমাণ সংগ্রহ থেকে শেষ পর্যন্ত কার হাতে কখন ছিল, তার ধারাবাহিক নথি। অফিসের রেজিস্টার খাতার মতো: প্রতিটি হাতবদলে সই।

Order of volatility (RFC 3227): যা দ্রুত হারায়, তা আগে। Memory ও network সংযোগ → চলমান process → disk → archive.

কাজের ধারা: Write blocker (পড়তে দেয়, লিখতে দেয় না) → image → hash → verify → working copy. মূল জিনিসে কাজ নয়। NIST SP 800-86-এর ধাপ: collection, examination, analysis, reporting.

সীমা: Hash মিললে প্রমাণ হয় hash নেওয়ার পর bit বদলায়নি, কে করেছে বা অর্থ কী তা নয়। Hash custody-র বিকল্প নয়। শুরুর আগে মালিকের লিখিত অনুমোদন বা বৈধ আইনি প্রক্রিয়া লাগে।

নম্বর কোথায়: দুই সংজ্ঞা (২), কাজের ধারা (৩), সীমা (১)। পর্ব ৬৩

যেখানে নম্বর কাটে: Disk আগে, memory পরে লেখা; hash-কে পূর্ণ প্রমাণ বলা; অনুমোদনের কথা বাদ দেওয়া।

ধাপ: সব ঘটনা UTC-তে আনুন → ঘড়ির skew সংশোধন → ক্রমে সাজান → ফাঁক খুঁজুন → সময়, ঠিকানা, account আর path ধরে pivot করুন। Super timeline বহু artifact-কে এক ক্রমে আনে।

mtime ও ctime: mtime content বদলের সময়, ctime inode বদলের সময়। ctime তৈরির সময় নয়। একটি timestamp-এ ভরসা নয়, correlate করুন।

অনুপস্থিতি: Log না থাকলে ঘটনা না ঘটার প্রমাণ নয়। হতে পারে log চালু ছিল না, rotate হয়েছে বা মোছা হয়েছে। আগে rotation, restart, disk পূর্ণ দেখুন, তারপর অন্য উৎসে মেলান।

লেখার নিয়ম: Finding-এ প্রমাণ, confidence আর অজানা আলাদা।

নম্বর কোথায়: ধাপ (২), mtime ও ctime (১), অনুপস্থিতি (১), লেখা (১)। পর্ব ৬৪

যেখানে নম্বর কাটে: ctime-কে creation time লেখা; স্থানীয় সময় মিশিয়ে ফেলা।

Breach বিশ্লেষণ: উৎস যাচাই → সময়রেখা → কারণের স্তর (technical, process, governance) → control-এর mapping → পরীক্ষাযোগ্য কাজ। হামলার ধাপ পুনর্গঠন লক্ষ্য নয়।

উদাহরণ: ২০২১-এর Log4Shell-এর সময় প্রথম প্রশ্ন ছিল “আমাদের কোথায় এটি আছে?” তার উত্তর দেয় SBOM আর asset inventory.

সীমা: Hindsight bias থেকে সাবধান: ফল জানার পরে সব স্পষ্ট লাগে। প্রতিটি দাবির পাশে উৎস আর আস্থা লিখুন।

নম্বর কোথায়: ছক (২), বিশ্লেষণের ধাপ (২), সীমা (১)। পর্ব ৬৫ · পর্ব ৬৬

যেখানে নম্বর কাটে: Breach-এ একজনকে দোষ দেওয়া; সংখ্যা উৎস ছাড়া লেখা।

তিন ভূমিকা: Governance দিক ঠিক করে ও তদারকি করে; management কাজ চালায়; audit স্বাধীনভাবে যাচাই করে।

RACI: প্রতিটি কাজে ঠিক একজন A (Accountable). CISO সব ঝুঁকির মালিক নন; ঝুঁকির মালিক সাধারণত ব্যবসার নেতা।

নম্বর কোথায়: তিন ভূমিকা (১), ছক (৩), RACI (১)। পর্ব ৬৭

যেখানে নম্বর কাটে: Policy আর procedure উল্টে লেখা; একাধিক A রাখা।

হিসাব:

1. SLE = AV × EF = ৫০,০০,০০০ × ০.৪ = ২০,০০,০০০ টাকা।
2. ALE = SLE × ARO = ২০,০০,০০০ × ০.৫ = ১০,০০,০০০ টাকা প্রতি বছর।
3. নিট লাভ = ALE আগে − ALE পরে − control-এর খরচ = ১০ লাখ − ২ লাখ − ৩ লাখ = ৫ লাখ টাকা প্রতি বছর। তাই টাকার হিসাবে লাভজনক।

চার সিদ্ধান্ত: Mitigate, transfer, avoid, accept. Residual risk থাকবেই, একজন owner জেনে-বুঝে মেনে নেবেন।

FAIR: ঝুঁকি = Loss Event Frequency × Loss Magnitude. LEF = TEF × Vulnerability. উদাহরণ: TEF ২, vulnerability ০.২৫ হলে LEF ০.৫; LM ৪০ লাখ হলে সরল প্রত্যাশা ২০ লাখ টাকা। অনুমান দিন range-এ, যেমন ৯০% range.

সীমা: ALE গড় দেখায়, খারাপ বছর নয়। Heat map-এর ঘরে ভিন্ন ঝুঁকি মিশে যায়। Risk appetite সার্বিক মনোভাব, tolerance মাপা সীমা; সংজ্ঞা উৎসভেদে একটু আলাদা।

নম্বর কোথায়: হিসাব (৪), চার সিদ্ধান্ত (১), FAIR (২), সীমা (১)। পর্ব ২ · পর্ব ৬৮

যেখানে নম্বর কাটে: EF % না ভেঙে গুণ করা; control-এর খরচ বিয়োগ না করা; একক না লেখা।

Compliance বনাম security: প্রথমটি শর্ত পূরণের প্রমাণ, দ্বিতীয়টি ঝুঁকির বাস্তব অবস্থা। দুটোই দরকার, একটি অন্যটির বদলে চলে না। সনদ থাকা সত্ত্বেও breach হতে পারে।

কাজের কথা: Scope কমান ডেটা সরিয়ে, যেমন token ব্যবহার। Crosswalk দিয়ে প্রমাণ একবার জোগাড় করে বারবার ব্যবহার করুন।

নম্বর কোথায়: ছক (৪), compliance (১), কাজের কথা (১)। পর্ব ৬৯

যেখানে নম্বর কাটে: SOC 2-কে সনদ বলা; NIST CSF-এ পাঁচটি Function লেখা; ISO-র পুরোনো ১১৪ control লেখা।

Pseudonymization: ফেরানো যায়, তাই এখনো ব্যক্তিগত তথ্য। Anonymization: যুক্তিসংগতভাবে আর চেনা যায় না। Hash করা ফোন নম্বর বেনামি নয়, কারণ search space ছোট; keyed HMAC ভালো।

সীমা: Privacy আর security এক নয়: অনুমোদিত ব্যবহারও অন্যায্য হতে পারে। আগে data inventory, তারপর কমানো। বাংলাদেশের উপাত্ত আইনের জন্য পর্ব ৭০ দেখুন; এই পাতা আইনি পরামর্শ নয়।

নম্বর কোথায়: ছক (৪), দুই সংজ্ঞা (১), সীমা (১)। পর্ব ৭০

যেখানে নম্বর কাটে: Hash-কে বেনামি বলা; tokenization-কে encryption বলা; masking ফেরানো যায় লেখা।

Shared responsibility: Provider cloud-এর নিরাপত্তা দেখে; গ্রাহক cloud-এর ভেতরের ডেটা, পরিচয় আর সেটিং দেখেন। IaaS থেকে SaaS-এ আপনার কাজ কমে, কিন্তু ডেটা, পরিচয় আর সেটিং আপনার হাতেই থাকে।

Toxic combination: কয়েকটি ছোট সমস্যা মিলে সংবেদনশীল সম্পদের পথ বানায়, যেমন internet-মুখী VM + বড় role + public ডেটা। Finding গোনা নয়, পথ ভাঙুন।

Container: Host-এর kernel ভাগ করে, VM-এর নিজের kernel থাকে। তাই ছোট base, non-root, capability বাদ, privileged নয়, digest দিয়ে pin, default deny NetworkPolicy.

সীমা: Encryption থাকলেও বৈধ role-এর জন্য সেবা decrypt করে দেয়। Vendor-এর ক্ষেত্রেও কাজ বাইরে যায়, দায় যায় না (পর্ব ৭১); SaaS-এর configuration আপনার ভাগ।

নম্বর কোথায়: Shared responsibility (২), টুল (২), toxic combination (১), container (২), সীমা (১)। পর্ব ৭২ · পর্ব ৭৩ · পর্ব ৭১

যেখানে নম্বর কাটে: “Cloud-এ গেলে নিরাপত্তা provider-এর” লেখা; CNAPP-কে সমাধান বলা; container-কে VM-এর সমান আলাদা ভাবা।

সংজ্ঞা: Zero trust মানে implicit trust বাদ: network-এর অবস্থান নয়, পরিচয়, device আর ঝুঁকি দেখে প্রতিটি access-এ ন্যূনতম অনুমতি। মহল্লার গেট পেরোলেই সব বাড়িতে ঢোকা নয়, প্রতিটি দরজায় আলাদা দারোয়ান।

ছবি: Subject → PEP → সম্পদ। ওপরে control plane: PE + PA (দুটি মিলে PDP). PEP-এর দিকে PA-এর তীর, পাশে signal: identity, device, log, threat intelligence.

• PE: সিদ্ধান্ত নেয়।
• PA: সিদ্ধান্ত কার্যকর করে, পথ খোলে বা বন্ধ করে।
• PEP: সংযোগে প্রয়োগ করে।

Roadmap: তালিকা → identity ও MFA → device → app → data. বাকি সব সিদ্ধান্ত পরিচয়ের ওপর দাঁড়ায়, তাই পরিচয় আগে।

কী নয়: এটি একটি পণ্য নয়, নকশা। VPN বাদ দেওয়া বাধ্যতামূলক নয়। Hybrid অবস্থাই স্বাভাবিক। Revocation-এর সময়ই আসল মাপ, আর একটি “সাময়িক” নিয়ম সব ফিরিয়ে আনতে পারে।

নম্বর কোথায়: সংজ্ঞা (২), ছবি ও তিন অংশ (৩), roadmap (২), সীমা (১)। পর্ব ৭৪ · পর্ব ৭৫

যেখানে নম্বর কাটে: Zero trust-কে “কাউকে বিশ্বাস নয়” বলে থামা; পণ্য কেনাকেই বাস্তবায়ন বলা; PE আর PEP উল্টে লেখা।

মূল কথা: কাজ বাইরে দেওয়া যায়, দায় দেওয়া যায় না। Vendor-এর ভুলে গ্রাহকের ক্ষতি হলেও জবাব আপনাকেই দিতে হয়।

চক্র: তালিকা → tier → যাচাই → চুক্তি → নজরদারি → প্রস্থান। সম্পর্ক শেষ মানে access বন্ধ আর ডেটা ফেরত।

Tier: ডেটা, access আর ব্যবসার নির্ভরতা দেখুন। এই তিনের সবচেয়ে খারাপটিই স্তর ঠিক করে।

SOC 2 report: Logo নয়, সময়কাল, scope, exception আর গ্রাহকের দায় পড়ুন। প্রশ্নমালার “Yes” নিজে প্রমাণ নয়।

সীমা: চুক্তি ক্ষতিপূরণ দেয়, ক্ষতি থামায় না। থামায় technical control: ছোট access, আলাদা পরিচয়, MFA. Vendor breach-এর পরিকল্পনাও আগে থেকে রাখুন।

নম্বর কোথায়: চক্র (২), tier (১), SOC 2 (১), সীমা (১)। পর্ব ৭১

যেখানে নম্বর কাটে: দায় vendor-এর ওপর চাপানো; সব vendor-কে একভাবে যাচাই করা; প্রস্থানের কথা বাদ দেওয়া।

না; লক্ষ্য ঝুঁকি গ্রহণযোগ্য স্তরে রাখা। পর্ব ১

Key ছাড়া সবকিছু প্রকাশ হলেও ব্যবস্থা নিরাপদ থাকবে। পর্ব ৭

Non-repudiation; প্রতিকার audit log আর signature. পর্ব ৪

২^১০ = ১,০২৪ গুণ। পর্ব ৭

একই plaintext block একই ciphertext দেয়, তাই নকশা ফাঁস হয়। পর্ব ৮

প্রায় ১২৮ bit, birthday bound-এর কারণে। পর্ব ৯

প্রথম অমিলে থেমে সময়ের মাধ্যমে তথ্য ফাঁস করতে পারে; constant-time ফাংশন নিন। পর্ব ৯

ফাঁস হলে পুরো শিকল ভাঙে আর সরাতে সময় লাগে। পর্ব ১১

না, দুটিই “যা জানেন”। পর্ব ১৫

Push fatigue-র অন্ধ অনুমোদন; phishing নয়। পর্ব ১৬

সাধারণ JWS নয়; যে কেউ পড়তে পারে, স্বাক্ষর শুধু বদল ধরে। পর্ব ১৭

No read up, no write down; গোপনীয়তা রক্ষা করে। Biba অখণ্ডতার জন্য উল্টো। পর্ব ১৯

কাজ থাকুক বা না থাকুক, সবসময় চালু থাকা অধিকার। পর্ব ২০

Snooping binding table বানায়, DAI সেই টেবিল দিয়ে ARP যাচাই করে। পর্ব ২১

কোনো নিয়ম না মিললে আটকানো; সব পণ্যে নিজে থেকে থাকে না। পর্ব ২২

প্রথমটি কী ধরা হবে, দ্বিতীয়টি ধরা ডেটা থেকে কী দেখা যাবে। পর্ব ২৪

IPv4 ২০ + UDP ৮ + header ১৬ + tag ১৬. পর্ব ২৫

সাধারণত SPF; চিঠি না বদলালে DKIM টেকে। পর্ব ২৬

Server-এর state; ACK ফিরলে তবেই সংযোগ তৈরি হয়। পর্ব ২৮

Allowlist তালিকার বাইরে সব থামায়; denylist শুধু তালিকার জিনিস। পর্ব ২৯

uid চলতি অধিকার, auid প্রথম login-এর পরিচয়, যা sudo-তেও টেকে। পর্ব ৩০

ভেতরের আসল package আর configuration দেখে, অনুমান কম। Scan account least privilege-এ রাখুন। পর্ব ৩২

Ransomware টাকা চায়, wiper ধ্বংস করে; কিছু wiper ransomware সেজে আসে। পর্ব ৩৩

Output-এ, কারণ context তখনই জানা যায়। পর্ব ৪০

নিরাপদে জমা মান পরে জোড়া লেখায় ঢুকলে যে bug হয়; তাই সব query-তে bind. পর্ব ৩৯

CSP-র frame-ancestors; বড় কাজে re-authentication. পর্ব ৪১

আটকায় না, শুধু কী আটকাত তা জানায়। পর্ব ৪৪

যাচাই আর কাজ এক atomic ধাপে: শর্তসহ UPDATE, lock. পর্ব ৪৬

সীমার ভেতরে থাকা বনাম বস্তুর জীবনকালের ভেতরে থাকা। পর্ব ৪৭

দুটিই লক্ষ্যভিত্তিক; whaling-এ লক্ষ্য শীর্ষ কর্মকর্তা। পর্ব ৫৩

Severity ক্ষতির মাত্রা; priority কাজের ক্রম। পর্ব ৬০

একটি বৈশিষ্ট্য ধরে গুনে বিরল সারি বের করা; বিরল মানে সূত্র, প্রমাণ নয়। পর্ব ৫৮

সাধারণত প্রথমটি সিদ্ধান্তের পরিকল্পনা, দ্বিতীয়টি কাজের ধাপ; ব্যবহার প্রতিষ্ঠানভেদে আলাদা। পর্ব ৬০

সমন্বয় আর সিদ্ধান্ত, হাতে-কলমে তদন্ত নয়। পর্ব ৬১

আগে থেকে ঠিক করা out-of-band পথে। পর্ব ৬১

জানা তথ্য, নেওয়া ব্যবস্থা, পাঠকের করণীয়, পরের আপডেটের সময়। পর্ব ৬৬

KPI কর্মদক্ষতা মাপে; KRI ঝুঁকি সীমার দিকে যাচ্ছে কি না জানায়। পর্ব ৬৭

এক তারিখের নকশা বনাম সময়জুড়ে কার্যকারিতা। পর্ব ৭১

Key বন্ধ ও session বাতিল; commit মোছা যথেষ্ট নয়। পর্ব ৭২

সম্পদ জানা, শীর্ষ ঝুঁকি মাপা, MFA, পরীক্ষিত backup, IR plan. পর্ব ৭৫