নিরাপত্তা সংস্কৃতি — সচেতনতা, ভুল রিপোর্ট আর দোষারোপহীন পরিবেশ

১ · শুধু tool দিয়ে নিরাপত্তা হয় না

একটি কাল্পনিক আমদানি অফিসের কথা ভাবুন। সেখানে firewall আছে, MFA আছে, প্রতিটি laptop-এ নিরাপত্তা software আছে। সোমবার সকালে হিসাব বিভাগের এক কর্মী ভুল করে একটি জাল invoice-এর link খুললেন আর password দিলেন। কয়েক মিনিট পরেই তিনি বুঝলেন কিছু একটা ঠিক হয়নি। কিন্তু তিনি কাউকে বললেন না। গত বছর একই ভুলের জন্য আরেকজনকে সবার সামনে বকা হয়েছিল। তিন দিন পর ঘটনাটি ধরা পড়ল, ততক্ষণে ক্ষতি অনেক বড়।

এখানে কোন tool ব্যর্থ হয়েছে? আসলে কোনোটিই পুরোপুরি নয়। ব্যর্থ হয়েছে অফিসের পরিবেশ। ভুল জানাতে ভয় লাগলে সবচেয়ে দামি সংকেতটিই হারিয়ে যায়। নিরাপত্তা সংস্কৃতি মানে নিরাপত্তা নিয়ে একটি দলের সাধারণ বোঝাপড়া: এখানে কী স্বাভাবিক, কী মূল্য পায়, আর ভুল হলে কী ঘটে।

“মানুষই সবচেয়ে দুর্বল কড়ি” কেন অকেজো কথা

কথাটি খুব প্রচলিত। মানুষ সত্যিই ভুল করেন, আর social engineering সেই ভুলকেই কাজে লাগায় (পর্ব ৫২)। সমস্যা হলো, এই কথা থেকে কোনো কাজের সিদ্ধান্ত বের হয় না। “মানুষ দুর্বল” বললে আমরা ধরে নিই নকশা ঠিক ছিল, আর মানুষই ত্রুটি। এতে তিনটি ক্ষতি হয়:

• নকশার দোষ চাপা পড়ে: যে system-এ বিশটি আলাদা password মনে রাখতে হয়, সেখানে খাতায় লেখা স্বাভাবিক।
• মানুষ শত্রু হয়ে যান: নিরাপত্তা দল তখন কর্মীর ওপর নজরদারি করে, আর কর্মীরা নিরাপত্তা দল এড়িয়ে চলেন।
• সবচেয়ে ভালো sensor হারায়: অদ্ভুত কিছু প্রথম চোখে পড়ে মানুষেরই। এমন বার্তা দেখে একজন কর্মী যা বোঝেন, অনেক tool তা বোঝে না।

২ · সচেতনতা, আচরণ আর সংস্কৃতি এক জিনিস নয়

ঢাকার মোটরবাইকের হেলমেট দিয়ে তিনটি স্তর বোঝা সহজ। হেলমেট না পরলে মাথায় আঘাতের ঝুঁকি বাড়ে, এটি প্রায় সবাই জানেন। জানা মানেই পরা নয়। কেউ কেউ শুধু পুলিশ দেখলে পরেন। আর কোনো দলে সবাই সবসময় পরেন, না পরলে সঙ্গীই মনে করিয়ে দেন। এই তিন অবস্থা হলো সচেতনতা, আচরণ আর সংস্কৃতি।

বেশিরভাগ “awareness program” প্রথম স্তরেই থেমে যায়। বছরে একবার slide দেখিয়ে সবার সই নেওয়া হয়। অথচ অনেকে আগেই জানতেন, তবু কাজের চাপে অন্যরকম করেছেন। তাই প্রশ্নটি হওয়া উচিত “মানুষ জানেন কি?” নয়, “সঠিক কাজটি করা কতটা সহজ, আর করলে কী ফল পান?”

যুক্তরাজ্যের NCSC ২০২৫ সালে ছয়টি cyber security culture নীতি প্রকাশ করেছে। সেগুলোর ভাব মোটামুটি এমন:

1. নিরাপত্তাকে প্রতিষ্ঠানের লক্ষ্য পূরণের সহায়ক হিসেবে দেখা।
2. খোলামেলা কথা বলার জন্য নিরাপত্তা, আস্থা আর প্রক্রিয়া গড়া।
3. নতুন ঝুঁকি আর সুযোগের সঙ্গে পরিবর্তনকে গ্রহণ করা।
4. সামাজিক রীতিকে নিরাপদ আচরণের পক্ষে রাখা।
5. সংস্কৃতির ওপর নিজের প্রভাবের দায় নেতার নেওয়া।
6. নিয়মগুলো সহজবোধ্য, সবার নাগালে আর হালনাগাদ রাখা।

খেয়াল করুন, এগুলো তৈরি রেসিপি নয়, বরং সুস্থ সংস্কৃতির চিহ্ন। এখানে “সংস্কৃতি” শব্দের ব্যাখ্যাও মতভেদপূর্ণ। কেউ একে মাপা যায় এমন আচরণ হিসেবে দেখেন, কেউ দেখেন গভীর বিশ্বাস ও মূল্যবোধ হিসেবে। তাই একটি survey-র নম্বরকে পুরো সংস্কৃতি ভাববেন না।

৩ · Security fatigue আর compliance budget

মোবাইল ব্যাংকিংয়ের PIN, অফিসের password, ফাইল পাঠানোর অনুমতি, পপ-আপ সতর্কবার্তা, MFA-র বার্তা: সারাদিন এগুলো জমতে থাকে। NIST-এর গবেষকেরা ২০১৬ সালে (Stanton, Theofanos, Prettyman ও Furman, IT Professional) সাক্ষাৎকার বিশ্লেষণ করে একে নাম দেন security fatigue: নিরাপত্তার সিদ্ধান্ত নিতে নিতে ক্লান্ত হয়ে মানুষ হাল ছেড়ে দেন, সহজ বিকল্প বেছে নেন বা সিদ্ধান্ত এড়িয়ে যান। গবেষণাটি ছোট আকারের গুণগত কাজ, তবে ধারণাটি অনেকের অভিজ্ঞতার সঙ্গে মেলে।

২০০৮ সালে Beautement, Sasse ও Wonham New Security Paradigms Workshop-এ একটি অর্থনৈতিক ধারণা দেন: compliance budget. কর্মীরা নিয়ম মানেন একটি সীমা পর্যন্ত, যতক্ষণ তাঁদের চোখে খরচ আর লাভের হিসাব মেলে। সীমা পেরোলে মানা কমতে থাকে। প্রতিষ্ঠান ব্যাংকের টাকার মতো এই সীমিত ইচ্ছাশক্তি খরচ করে। তাই কম গুরুত্বপূর্ণ নিয়মে এটি ফুরিয়ে গেলে জরুরি নিয়মের জন্য কিছু থাকে না। প্রবন্ধটি এই সীমার কোনো সর্বজনীন সংখ্যা দেয় না। নিচের ৩০ মিনিট শুধু আমাদের ধরে নেওয়া মান।

নিচের হিসাবটি একজন কর্মীর সপ্তাহের নিরাপত্তা-কাজের সময় বের করে, নিয়ম বদলের আগে আর পরে। প্রতিটি সংখ্যা কাল্পনিক। নিজের অফিসের জন্য নিজে সময় মেপে বসান।

// TOY ONLY: assumed numbers for one fictional office, not a measured study.
const STAFF = 40, WEEKS = 48, BUDGET = 30;   // BUDGET: minutes a week, also assumed
const before = [            // [task, times a week, minutes each]
  ['login to 6 separate apps', 30, 0.5],
  ['forgotten password reset',  2, 6],
  ['remote access reconnect',  10, 1.5],
  ['ticket for each file send', 1, 20],
  ['forced password change', 0.25, 10],
  ['long monthly policy quiz', 0.25, 30],
];
const after = [
  ['single sign-on login',      5, 0.5],
  ['password reset',         0.25, 6],
  ['remote access reconnect',   5, 0.5],
  ['approved shared folder',    1, 2],
  ['short monthly training', 0.25, 10],
];
function load(tasks, name) {
  let week = 0;
  for (const [task, times, mins] of tasks) {
    const t = times * mins; week += t;
    console.log('  ' + task.padEnd(27) + t.toFixed(1).padStart(5) + ' min/week');
  }
  const hours = week * WEEKS * STAFF / 60;
  console.log(name + ': ' + week.toFixed(1) + ' min/week per person; '
    + hours.toFixed(0) + ' staff hours a year; '
    + (week > BUDGET ? 'OVER' : 'within') + ' the ' + BUDGET + ' min budget');
  return hours;
}
const a = load(before, 'BEFORE'), b = load(after, 'AFTER');
const rollout = STAFF * 2;      // assumed: 2 hours each to set up the new way
console.log('Saved in year one: ' + (a - b - rollout).toFixed(0)
  + ' hours, after ' + rollout + ' rollout hours');

৪ · নিরাপদ পথকেই সহজ পথ বানান

মানুষকে স্রোতের বিপরীতে সাঁতার কাটতে বলার চেয়ে স্রোতের দিক বদলানো সহজ। মেট্রো রেলের স্টেশনে যেমন গেট দিয়েই যেতে হয়, নিজে নিজে সিদ্ধান্ত নিতে হয় না। নিরাপত্তাতেও লক্ষ্য একই: সঠিক কাজটি যেন স্বাভাবিকভাবেই হয়ে যায়।

নিয়ম কঠিন হলে কর্মীরা কাজ থামান না, পাশের পথ খোঁজেন। অনুমোদন ছাড়া ব্যক্তিগত email, চ্যাট app বা নিজের cloud ব্যবহারকে বলে shadow IT. একে “অপরাধ” না ভেবে একটি বার্তা হিসেবে পড়ুন: অনুমোদিত পথটি কাজের জন্য যথেষ্ট ভালো নয়। নিচে একটি কাল্পনিক অফিসের নিয়ম কীভাবে বদলাল দেখুন।

Onboarding আর offboarding

নতুন কর্মী প্রথম সপ্তাহেই বুঝে নেন এখানে আসলে কী চলে। তাই onboarding-এর দিনেই তিনটি জিনিস দিন: নিজের account আর MFA, password manager, আর “ভুল হলে কাকে জানাবেন” কার্ড। প্রয়োজন অনুযায়ী access দিন (least privilege). পদ বদলালে পুরোনো access সরান।

Offboarding সম্মানের সঙ্গে হওয়া দরকার, কিন্তু সময়মতো। শেষ কর্মদিবসে account বন্ধ, device ফেরত, ভাগ করা password বদল, আর তাঁর নামের API key বা token সরানো। এই পুরো ধারাকে বলে joiner-mover-leaver প্রক্রিয়া, যা পর্ব ১৯ আর পর্ব ২০-এর সঙ্গে যুক্ত। HR আর IT-র একটি যৌথ চেকলিস্টই ছোট অফিসের জন্য যথেষ্ট।

৫ · ভুল রিপোর্ট আর just culture

নিরাপত্তার ঘটনায় সময়ই ক্ষতির মাপ ঠিক করে। ৫ মিনিটে জানা গেলে password বদল। ৫ দিনে জানা গেলে হয়তো পুরো incident response. কর্মী ভুল লুকালে কোনো tool এই সময় ফেরাতে পারে না।

বিমান আর হাসপাতাল থেকে শেখা

বিমান চলাচলে ১৯৭৪ সালে TWA 514-এর দুর্ঘটনার পর জানা যায়, কয়েক সপ্তাহ আগে আরেকটি বিমান প্রায় একই ভুলে পড়তে যাচ্ছিল, কিন্তু সেই শিক্ষা সবার কাছে পৌঁছায়নি। এর পথ ধরেই ১৯৭৬ সালে NASA-র পরিচালনায় Aviation Safety Reporting System (ASRS) চালু হয়। পাইলটরা গোপনে near miss জানাতে পারেন। নিরপেক্ষ তৃতীয় পক্ষ রিপোর্ট সামলায়, আর নির্দিষ্ট শর্তে সীমিত দায়মুক্তি মেলে। হাসপাতালেও একই বাঁক দেখা যায়। ১৯৯৯ সালে মার্কিন Institute of Medicine-এর “To Err Is Human” প্রতিবেদন জোর দেয়, ব্যক্তিকে দোষ দেওয়ার চেয়ে system ঠিক করাই রোগীর নিরাপত্তার পথ।

Just culture শব্দটি জনপ্রিয় হয় James Reason (১৯৯৭)-এর কাজ আর Sidney Dekker-এর Just Culture বই (প্রথম সংস্করণ ২০০৭) থেকে। এর অর্থ “কোনো দায় নেই” নয়। এর অর্থ ন্যায্য সীমা: সৎ ভুলে শাস্তি নয়, কিন্তু ইচ্ছাকৃত ক্ষতিতে ব্যবস্থা। স্বাস্থ্যখাতে David Marx-এর জনপ্রিয় ভাগটি নিরাপত্তায় মিলিয়ে দেখুন। এটি একটি কাজের কাঠামো, আইন নয়, আর গবেষকদের মধ্যে এর সমালোচনাও আছে।

সীমা টানার একটি সহজ পরীক্ষা হলো substitution test: একই চাপ, একই তথ্য আর একই সরঞ্জামে একজন গড় যোগ্য সহকর্মী থাকলে কী করতেন? তিনিও একই কাজ করলে সমস্যা ব্যক্তির চেয়ে system-এ বেশি। সিদ্ধান্তটি একজনের হাতে না রেখে ছোট একটি দলের হাতে রাখা ভালো।

এবার একটি কাল্পনিক ঘটনা ধাপে ধাপে দেখুন। সময়গুলো খেয়াল করুন।

রিপোর্টের পথ হতে হবে খুব সহজ: mail-এ একটি বোতাম, একটি ফোন নম্বর বা WhatsApp-এর মতো চ্যাট নম্বর, রাতের shift-এও খোলা। সন্দেহটি ভুল প্রমাণিত হলেও ধন্যবাদ দিন। ভুল সতর্কতায় বকা খেলে পরের সত্যি রিপোর্টটি আর আসবে না। Near miss-ও রিপোর্ট করতে বলুন: “ক্লিক করিনি, কিন্তু প্রায় করে ফেলেছিলাম।” ক্ষতি ছাড়া শেখার সুযোগ এটিই।

৬ · মানুষ না খুঁজে ঘটনা পর্যালোচনা

Post-incident review মানে ঘটনার পরে বসে বোঝা, কী ঘটল আর কীভাবে পরের বার কম ক্ষতি হবে। Software operations জগতে একে blameless postmortem বলা হয়, যা Cloud & DevOps কোর্সে এসেছে। পুরো incident প্রক্রিয়া আসবে পর্ব ৬১ “Incident response — NIST-এর ধাপ, দল আর পরিকল্পনা”-তে।

“Blameless” মানে ঘটনা ঘিরে তথ্য লুকানো নয়। ঠিক উল্টো, মানুষ ভয় না পেলে পূর্ণ তথ্য দেন। মূল প্রশ্ন হলো: সেই মুহূর্তে কাজটি তাঁর কাছে যুক্তিসঙ্গত মনে হলো কেন? পরে সবকিছু জেনে “আগেই বোঝা উচিত ছিল” বলা সহজ। এই ফাঁদের নাম hindsight bias. একটি মাত্র root cause খোঁজার বদলে কয়েকটি contributing factor খোঁজা বেশি সৎ, কারণ বড় ঘটনা সাধারণত একাধিক ফাঁক মিলেই ঘটে।

দিন ১: সাপোর্ট দল গ্রাহকের ফোন নম্বরের
       sheet ভেন্ডরকে পাঠাল
       link: anyone with link
দিন ৭: ভেন্ডর নিজেই জানাল, link এখনো খোলা
দিন ৭: link বন্ধ, access log সংরক্ষণ

log: ৬ দিনে খোলা হয়েছে ৪ বার
     ৪ বারই ভেন্ডরের অফিস থেকে
     (এই log ঠিকঠাক ছিল বলেই জানা গেল)
লেখা: "সাপোর্ট অফিসার", কারও নাম নয়

• ভেন্ডরের অফিসের account ছিল না
• সেদিনই তালিকা দরকার ছিল
• “share” বোতামে default = সবার জন্য
• সর্বশেষ policy ইংরেজিতে, ৪০ পাতা

আগে: অফিসার অসাবধান ছিলেন।
পরে: ভুল সেটিং কেন সহজ পথ ছিল?
আগে: নিয়ম পড়া উচিত ছিল।
পরে: নিয়ম কি কাজের সময় পাওয়া যায়?

A1 default "শুধু প্রতিষ্ঠান"   IT      ৭ দিন
A2 link-এর মেয়াদ ৭ দিন        IT      ৭ দিন
A3 ভেন্ডরের guest account     অ্যাডমিন ১৪ দিন
A4 এক পাতার বাংলা নির্দেশ    সাপোর্ট লিড ১৪ দিন

A1 সম্পন্ন: নতুন খোলা link ০টি
A2 সম্পন্ন
A3 সম্পন্ন: ভেন্ডর guest ব্যবহার করছে
A4 সম্পন্ন
সবাইকে জানানো: ঘটনা, শিক্ষা, বদল

নিচের ছোট সরঞ্জামটি একটি শব্দ-তালিকা দেখে দোষের বাক্যকে system-এর প্রশ্নে বদলায়। এটি AI নয়, শুধু অভ্যাস গড়ার সহায়ক। শেষ উদাহরণে দেখবেন, তালিকায় না থাকলে সে পারে না।

// TOY ONLY: a small word lookup, not AI. real নয়, শুধু ধারণার জন্য।
const RULES = [
  { words: ['অসাবধান', 'খেয়াল করেনি'], ask: 'কাজের সময় কোন সংকেত ঝুঁকিটি দেখাতে পারত, আর কেন দেখায়নি?' },
  { words: ['ভুলে গেছে'], ask: 'কাজটি কি কারও মনে রাখার ওপর নির্ভর করছিল? কোনটি স্বয়ংক্রিয় হতে পারত?' },
  { words: ['নিয়ম ভেঙেছে'], ask: 'নিয়মটি মানা কতটা কঠিন ছিল, আর সবাই বাস্তবে কীভাবে কাজটি করেন?' },
  { words: ['দেরি করেছে'], ask: 'রিপোর্ট করতে কী বাধা ছিল? ভয়, অজানা পথ, নাকি কাজের চাপ?' },
  { words: ['প্রশিক্ষণ নেয়নি'], ask: 'প্রশিক্ষণ কি কাজের সময়ে আর নিজের ভাষায় পাওয়া যেত?' },
];
function reframe(sentence) {
  const hit = RULES.find(r => r.words.some(w => sentence.includes(w)));
  return hit ? hit.ask : '(no match: a human reviewer must rewrite this one)';
}
const notes = [
  'ক্যাশিয়ার অসাবধান ছিল।',
  'ডেভেলপার token মুছতে ভুলে গেছে।',
  'সাপোর্ট অফিসার নিয়ম ভেঙেছে।',
  'নতুন কর্মী রিপোর্ট করতে দেরি করেছে।',
  'হিসাব বিভাগই আসল সমস্যা।',
];
notes.forEach((n, i) => {
  console.log((i + 1) + '. blame : ' + n);
  console.log('   system: ' + reframe(n));
});

৭ · যে training সত্যিই কাজে লাগে

প্রথমে অপ্রিয় সত্যটি জানা দরকার। ২০২৫ সালের IEEE Symposium on Security and Privacy-তে প্রকাশিত UC San Diego Health-এর একটি গবেষণায় (Ho ও সহলেখকেরা, ১৯,৫০০-র বেশি কর্মী, ৮ মাস) বার্ষিক training-এর সঙ্গে phishing-এ ধরা পড়া কমার তাৎপর্যপূর্ণ সম্পর্ক পাওয়া যায়নি। ফাঁদে পড়ার পরপর দেখানো embedded training-এ ব্যর্থতার হার গড়ে কমেছে মাত্র ১.৭%, আর ৭৫%-এর বেশি training session-এ কর্মীরা তাতে এক মিনিটেরও কম সময় দিয়েছেন। ২০২২ সালে Lain, Kostiainen ও Čapkun-এর ১৪,৭৭৩ জনের ১৫ মাসের গবেষণায়ও embedded training-এর উপকার দেখা যায়নি, তবে কর্মীদের মিলিত রিপোর্ট দ্রুত phishing ধরতে কাজে লেগেছে। ফলাফল পরিবেশভেদে আলাদা হতে পারে, আর এ নিয়ে গবেষণা চলছে। তবে সিদ্ধান্তটি স্পষ্ট: training একা প্রধান প্রতিরক্ষা হতে পারে না। প্রযুক্তিগত বাধা আগে, training সহায়ক (পর্ব ৫৩ “Phishing প্রতিরক্ষা”)।

Training দিলে তা এভাবে দিন:

নিচের পরিকল্পনাকারী একটি ছোট কর্মী-তালিকা দেখে বের করে কার কোন module বাকি, আর মাসে ১৫ মিনিটের বেশি না দিয়ে তা সাজায়। Clock এখানে কাল্পনিক মাস নম্বর।

// TOY ONLY: fictional staff and a simulated clock (month numbers, no real date).
const NOW = 14;   // simulated month number
const MODULES = {
  'report-mistake': { mins: 5,  every: 12, roles: ['all'] },
  'password-mfa':   { mins: 10, every: 12, roles: ['all'] },
  'invoice-fraud':  { mins: 10, every: 6,  roles: ['accounts'] },
  'customer-data':  { mins: 10, every: 6,  roles: ['support'] },
  'secrets-in-code':{ mins: 15, every: 6,  roles: ['developer'] },
  'admin-access':   { mins: 15, every: 6,  roles: ['admin'] },
};
const staff = [
  { id: 'S1', role: 'accounts',  done: { 'report-mistake': 9, 'password-mfa': 1, 'invoice-fraud': 6 } },
  { id: 'S2', role: 'support',   done: { 'report-mistake': 9, 'password-mfa': 9, 'customer-data': 10 } },
  { id: 'S3', role: 'developer', done: { 'report-mistake': 2, 'password-mfa': 2, 'secrets-in-code': 7 } },
  { id: 'S4', role: 'admin',     done: {} },   // joined this month
];
const LIMIT = 15;  // at most 15 minutes in one month
function dueFor(p) {
  return Object.keys(MODULES).filter(name => {
    const m = MODULES[name];
    if (!m.roles.includes('all') && !m.roles.includes(p.role)) return false;
    return !(name in p.done) || NOW - p.done[name] >= m.every;
  });
}
for (const p of staff) {
  let month = NOW, used = 0;
  const plan = [];
  for (const name of dueFor(p)) {
    if (used + MODULES[name].mins > LIMIT) { month++; used = 0; }
    used += MODULES[name].mins;
    plan.push('M' + month + ':' + name);
  }
  console.log(p.id + ' ' + p.role.padEnd(10) + (plan.join('  ') || 'nothing due'));
}

Security champion আর নেতৃত্বের উদাহরণ

Security champion কথাটি আগে ডেভেলপার দলে দেখেছেন (পর্ব ৪৫)। ধারণাটি অফিসের প্রতিটি দলেই খাটে। প্রতিটি বিভাগের একজন আগ্রহী কর্মী সহকর্মীদের প্রশ্নের প্রথম ঠিকানা হন, আর নিরাপত্তা দলকে মাঠের বাস্তবতা জানান। তিনি পুলিশ নন, সেতু। তাঁর জন্য কাজের সময় বরাদ্দ রাখুন আর কাজের স্বীকৃতি দিন, নইলে এটি বিনা বেতনের বাড়তি বোঝা।

নেতার আচরণ সবচেয়ে জোরালো training. চেয়ারম্যান যদি বলেন “আমার জন্য MFA বাদ দিন”, তবে পুরো অফিস বার্তাটি বুঝে যায়। উল্টো দিকে, কোনো পরিচালক সভায় নিজের ভুল রিপোর্টের গল্প বললে অন্যদের ভয় অনেকটা কাটে। হিসাব অনুমোদনের মতো কাজে “বস ফোনে বলেছেন” দিয়ে নিয়ম ভাঙা বন্ধ করতে হলে নেতাদেরই আগে বলতে হবে: “আমার নামে এলেও যাচাই করুন।”

৮ · সংস্কৃতি মাপা, আর মাপার ফাঁদ

সংস্কৃতি সরাসরি দেখা যায় না, তবে এর ছাপ মাপা যায়। বেশি কাজের কয়েকটি মাপ:

• Report rate: যাঁরা সন্দেহজনক বার্তা পেলেন, তাঁদের কত ভাগ রিপোর্ট করলেন। ২৮ জন ÷ ৫০ জন = ৫৬%.
• Time to report: ঘটনা থেকে রিপোর্ট পর্যন্ত সময়। গড়ের চেয়ে median ভালো, কারণ একটি খুব দেরির রিপোর্ট গড়কে টেনে নেয়।
• নিজের ভুল নিজে জানানো: যাঁরা ভুল করলেন, তাঁদের কত ভাগ নিজেই বললেন। এটি আস্থার প্রায় সরাসরি মাপ।
• Near miss-এর সংখ্যা: শুরুতে বাড়া ভালো লক্ষণ। ঘটনা বেড়েছে এমন নয়, মানুষ বলতে শুরু করেছেন।
• নাম ছাড়া survey: “ভুল করলে জানাতে আমি নিরাপদ বোধ করি” এমন কয়েকটি প্রশ্ন, বছরে দুবার। ফল কমলে তার পরের কাজটিও জানান।

নিচের হিসাবে ৫০ জন কর্মী প্রতি প্রান্তিকে (quarter) একটি অনুশীলনী mail পান। Phishing simulation শুধু নিজের প্রতিষ্ঠানে, অনুমোদন নিয়ে, আগে থেকে জানানো নীতির অধীনে চালান। নিচের সংখ্যাগুলো কাল্পনিক।

// TOY ONLY: fictional quarters. Fifty staff get one practice mail each quarter.
const quarters = [
  { q: 'Q1', level: 'easy', sent: 50, clicked: 14, selfReport: 0, near: 1,
    mins: [410, 240, 300, 95, 180, 150] },
  { q: 'Q2', level: 'easy', sent: 50, clicked: 9, selfReport: 2, near: 3,
    mins: [200, 45, 90, 310, 60, 120, 75, 55, 130, 40, 150, 35, 80] },
  { q: 'Q3', level: 'hard', sent: 50, clicked: 17, selfReport: 6, near: 6,
    mins: [30, 55, 22, 90, 41, 18, 60, 35, 25, 70, 44, 15, 28, 50, 33, 19, 80, 26, 38, 47, 24] },
  { q: 'Q4', level: 'easy', sent: 50, clicked: 11, selfReport: 7, near: 9,
    mins: [12, 20, 9, 31, 15, 8, 25, 18, 11, 40, 14, 22, 10, 16, 35, 13, 19, 7, 28, 17,
           21, 12, 30, 9, 24, 15, 11, 26] },
];
function median(list) {
  const s = [...list].sort((a, b) => a - b), mid = Math.floor(s.length / 2);
  return s.length % 2 ? s[mid] : (s[mid - 1] + s[mid]) / 2;
}
const pct = (a, b) => (100 * a / b).toFixed(0).padStart(3) + '%';
console.log('qtr level click report ownClick near medianMin');
for (const r of quarters) {
  const reported = r.mins.length;
  console.log(r.q + '  ' + r.level + ' ' + pct(r.clicked, r.sent) + '  '
    + pct(reported, r.sent) + '   ' + pct(r.selfReport, r.clicked) + '   '
    + String(r.near).padStart(3) + '  ' + String(median(r.mins)).padStart(6));
}
const a = quarters[0], b = quarters[3];
console.log('report rate x' + (b.mins.length / a.mins.length).toFixed(1)
  + ', median time to report /' + (median(a.mins) / median(b.mins)).toFixed(1));

কর্মীর গোপনতা আর ন্যায্যতা

মাপতে গিয়ে নজরদারি শুরু হলে সংস্কৃতিই নষ্ট হয়। DLP, ব্যবহার-log আর simulation-এর ফল মানুষের জীবন স্পর্শ করে। কয়েকটি সীমা ঠিক করে নিন:

• উদ্দেশ্য আর স্বচ্ছতা: কী দেখা হয়, কেন, কতদিন রাখা হয়, লিখিতভাবে আগে জানান।
• প্রয়োজনের সমান: ঝুঁকির তুলনায় যতটুকু দরকার ততটুকুই। ব্যক্তিগত বার্তা পড়া বা ক্যামেরায় নজর সাধারণ নিরাপত্তার কাজ নয়।
• ফল আলাদা রাখা: Simulation-এর ব্যক্তিগত ফল বেতন, পদোন্নতি বা জনসমক্ষে অপমানের জন্য নয়। দলভিত্তিক সংখ্যা দেখুন।
• সবার জন্য এক নিয়ম: বড় কর্তাদের ছাড় নয়। চুক্তিভিত্তিক কর্মীদেরও সহায়তা ও রিপোর্টের পথ দিন।
• ন্যায্য ফাঁদ: বেতন, বোনাস বা অসুস্থ স্বজনের নামে নিষ্ঠুর ভুয়া mail নয়। প্রতারকেরা তা করলেও প্রতিষ্ঠানের করা উচিত নয়।

কর্মীর উপাত্ত সংগ্রহের আইনি দিক আছে, যা নিয়ে পর্ব ৬ আর পর্ব ৭০ “Privacy engineering” দেখুন। এই পর্ব আইনি পরামর্শ নয়; নিজের ক্ষেত্রে আইনজীবীর পরামর্শ নিন।

৯ · পরিবার, কমিউনিটি আর ছোট প্রতিষ্ঠান

নিরাপত্তা সংস্কৃতি শুধু অফিসের বিষয় নয়। সবচেয়ে কঠিন লড়াই হয়তো আপনার পরিবারে, যেখানে দাদি মোবাইল ব্যাংকিং ব্যবহার করেন আর ভাগ্নে সারাদিন গেম খেলে। মূল নীতি এখানেও একই: লজ্জা নয়, সহজ পথ।

প্রতারণা হলে দেরি না করে ব্যাংক বা মোবাইল আর্থিক সেবার কার্ড ও app-এ লেখা অফিসিয়াল নম্বরে ফোন করুন। জরুরি প্রয়োজনে জাতীয় জরুরি সেবা ৯৯৯, আর শিশুদের জন্য চাইল্ড হেল্পলাইন ১০৯৮ আছে। নম্বরগুলো সরকারি উৎস থেকে যাচাই করে পরিবারের সবার ফোনে রাখুন।

ছোট প্রতিষ্ঠানের ৯০ দিনের পরিকল্পনা

আলাদা নিরাপত্তা দল নেই এমন ২০ জনের অফিসের জন্য একটি নমুনা। লক্ষ্য একবারে সব নয়, প্রতি মাসে দৃশ্যমান কিছু উন্নতি।

মহড়ার পূর্ণ পদ্ধতি আসবে পর্ব ৬৬ “Tabletop exercise”-এ, আর নিয়ম ও ভূমিকা আসবে পর্ব ৬৭ “নিরাপত্তা governance”-এ। Ransomware-এর মতো বড় ঘটনার প্রস্তুতি পর্ব ৩৪-এ আছে। ৯০ দিনে সংস্কৃতি পুরো বদলায় না, শুধু সঠিক দিকে চলা শুরু হয়।

১০ · AI-এর যুগে নিরাপত্তা সংস্কৃতি

AI কর্মীদের কাজ দ্রুত করে, আবার নতুন অভ্যাসও আনে। ব্যক্তিগত AI account-এ অফিসের ফাইল পেস্ট করা (shadow AI) হলো shadow IT-র নতুন রূপ, আর চিকিৎসাও একই: নিষেধ করে নয়, অনুমোদিত সহজ পথ দিয়ে (পর্ব ৫১)। সেইসঙ্গে প্রতারকেরাও AI দিয়ে নিখুঁত বাংলায় বার্তা লিখতে পারে, তাই বানান ভুল দেখে phishing চেনার পুরোনো পরামর্শ দুর্বল হচ্ছে। তাই প্রক্রিয়াগত যাচাই (ফোনে ফিরতি কল, দুজনের অনুমোদন) আরও জরুরি।

Policy লেখা, training-এর খসড়া বা review-র প্রশ্ন বানাতে AI কাজে লাগে। কিন্তু AI প্রায়ই ভুল করে: অস্তিত্বহীন CVE, standard বা গবেষণার নাম বানায়, পুরোনো পরামর্শ দেয় (MD5, ECB, salt ছাড়া hash, জোর করে password বদল), error সারাতে verify=False বা chmod 777-এর মতো নিরাপত্তা বন্ধের পথ বলে, injection বা অনুমতি-পরীক্ষাহীন কোড লেখে, আর triage-এ অতিরিক্ত আত্মবিশ্বাস দেখায়। ঘটনার নথি AI-তে পেস্ট করলে গোপন তথ্যও ফাঁস হতে পারে।

AI ব্যবহারের চেকলিস্ট

• নাম, গ্রাহকের তথ্য, password বা token পেস্ট করিনি
• AI-এর দেওয়া CVE, standard আর গবেষণার নাম মূল উৎসে নিজে পড়ে দেখেছি
• Training-এর খসড়া একজন আসল কর্মীকে পড়িয়ে দেখেছি
• AI-এর পরামর্শ নিজের পরীক্ষাগারে পরীক্ষা করেছি, আর পরিবর্তনের diff দেখেছি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত মানুষের হাতেই রেখেছি (human in the loop)