Containment, eradication আর recovery — ক্ষতি থামিয়ে ফেরা

১ · আগুন, ছাই আর ফিরে আসা — তিনটি আলাদা কাজ

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

পর্ব ৬০-এ SOC একটি alert-কে নিশ্চিত ঘটনা বলে চিহ্নিত করেছে। পর্ব ৬১ “Incident response — NIST-এর ধাপ, দল আর পরিকল্পনা” পুরো কাঠামো দেয়। এই পর্ব সেই কাঠামোর মাঝের অংশ, যেখানে হাত সত্যিই কাজ করে:

• Containment: ক্ষতি আর বিস্তার থামানো। হামলাকারী এখনো সিস্টেমে থাকতে পারে, কিন্তু তার নড়াচড়ার জায়গা কমে গেছে।
• Eradication: হামলাকারীর উপস্থিতি মুছে ফেলা: malware, তার persistence, চুরি হওয়া credential, আর ঢোকার পথ।
• Recovery: সিস্টেমকে স্বাভাবিক কাজে ফেরানো, আর ফেরার পর বাড়তি নজর রাখা।

NIST SP 800-61-এর পুরোনো সংস্করণে (Rev. 2, ২০১২) এই তিনটি কাজ একটি ধাপেই ছিল। ২০২৫ সালের Rev. 3 সাজানো হয়েছে CSF 2.0-এর function ধরে, তবে কাজের সারকথা একই। Recovery-র জন্য আলাদা করে আছে NIST SP 800-184 (২০১৬)।

স্বল্পমেয়াদি আর দীর্ঘমেয়াদি containment

২ · এখনই থামাবেন, না আগে দেখবেন?

এই পর্বের সবচেয়ে কঠিন সিদ্ধান্ত এটি। সহজ বুদ্ধি বলে, চোর দেখলেই তাড়িয়ে দিন। কিন্তু ঘরের লোক জানে না চোর কয়জন, কোন জানালা খোলা। একজনকে তাড়ালে বাকিরা সতর্ক হবে, চিহ্ন মুছবে, নতুন পথ বানাবে, অথবা তাড়াহুড়োয় বেশি ক্ষতি করবে।

একটি সরকারি উৎস এই ভাবনাকে সমর্থন করে। CISA-র যৌথ advisory AA20-245A (২০২০) ঘটনা সামলানোর সাধারণ ভুলের তালিকায় রেখেছে: তথ্য সংগ্রহের আগেই সিস্টেম ঠিক করে ফেলা, হামলাকারীর infrastructure-এ হাত দেওয়া, আগেভাগে block করা, আগেভাগে credential বদলানো, log না রাখা, আর আক্রান্ত network দিয়েই নিজেদের আলাপ করা। আবার NIST Rev. 2 সতর্ক করে, দেরিতে containment বিপজ্জনক, কারণ হামলাকারী এই সময়ে আরও ক্ষতি করতে পারে।

নিচের খেলনা helper একই যুক্তিতে পাঁচটি কাল্পনিক ঘটনা বিচার করে। এটি আসল কোনো সিস্টেম ছোঁয় না, আর সিদ্ধান্ত নেন একজন মানুষ।

// Toy containment helper. Facts are made up; a human lead makes the real call.
const incidents = [
  { id: 'INC-1', what: 'files being encrypted', destructive: true,
    gbPerHour: 0, toleranceGb: 0, canWatch: true, scopeKnown: false },
  { id: 'INC-2', what: 'stolen mailbox, one user', destructive: false,
    gbPerHour: 0.2, toleranceGb: 1, canWatch: true, scopeKnown: true },
  { id: 'INC-3', what: 'quiet web shell', destructive: false,
    gbPerHour: 0.5, toleranceGb: 3, canWatch: true, scopeKnown: false },
  { id: 'INC-4', what: 'database copy leaving', destructive: false,
    gbPerHour: 40, toleranceGb: 10, canWatch: true, scopeKnown: false },
  { id: 'INC-5', what: 'old server, no logs', destructive: false,
    gbPerHour: 0.1, toleranceGb: 5, canWatch: false, scopeKnown: false },
];
const MAX_WATCH_HOURS = 24;              // a watch must always have an end

function decide(f) {
  if (f.destructive) return ['CONTAIN NOW', 'damage is irreversible'];
  if (!f.canWatch) return ['CONTAIN NOW', 'we cannot see, so watching is blind'];
  if (f.scopeKnown) return ['EVICT TOGETHER', 'scope known, act in one window'];
  const limit = Math.min(f.toleranceGb / f.gbPerHour, MAX_WATCH_HOURS);
  if (limit < 1) return ['CONTAIN NOW', `tolerance gone in ${limit * 60} min`];
  return [`WATCH ${limit} h`, 'scope first, with a tripwire and an end time'];
}

for (const f of incidents) {
  const [action, why] = decide(f);
  console.log(`${f.id} ${f.what.padEnd(25)} ${action.padEnd(15)} ${why}`);
}

INC-1 files being encrypted     CONTAIN NOW     damage is irreversible
INC-2 stolen mailbox, one user  EVICT TOGETHER  scope known, act in one window
INC-3 quiet web shell           WATCH 6 h       scope first, with a tripwire and an end time
INC-4 database copy leaving     CONTAIN NOW     tolerance gone in 15 min
INC-5 old server, no logs       CONTAIN NOW     we cannot see, so watching is blind

৩ · Containment-এর হাতিয়ার — কোনটি কী থামায়

প্রতিটি হাতিয়ার একটি নির্দিষ্ট পথ বন্ধ করে। কোনটিই সব পথ বন্ধ করে না। তাই “account বন্ধ করেছি, শেষ” বলা বিপজ্জনক।

কিছু বদলানোর আগে প্রমাণ

Containment সিস্টেম বদলে দেয়, আর বদলানো প্রমাণ ফেরে না। RAM-এর তথ্য machine বন্ধ হলেই হারায়। তাই সাধারণ নিয়ম: যা দ্রুত মুছে যায়, তা আগে সংগ্রহ। একে বলে order of volatility (RFC 3227, ২০০২)। ক্ষতি চলতে থাকলে পুরো সংগ্রহের জন্য বসে থাকবেন না; যা পারেন নিন, কী বাদ গেল লিখে রাখুন।

• Machine বন্ধ না করে network থেকে আলাদা করা, যাতে RAM টিকে থাকে।
• VM বা cloud disk-এর snapshot, আর audit log-এর কপি অন্য নিরাপদ জায়গায়। Log-এর আয়ু ছোট হলে আগে সেটি বাড়ানো।
• প্রতিটি কাজের সময়, কর্তা আর কারণ লেখা। আইনি কাজে লাগলে chain of custody দরকার, বিস্তারিত পর্ব ৬৩-তে।

আরেকটি সূক্ষ্ম কথা NIST-এর Rev. 2-তেই আছে: কিছু malware নিজের সংযোগ কেটে গেলে ক্ষতি করার মতো করে বানানো হতে পারে। তাই network থেকে আলাদা করলেই ক্ষতি থেমেছে, এমন ধরে নেবেন না। Isolation-এর পরও host-টি দেখুন।

নিচে একটি কাল্পনিক অনলাইন বাজারের হিসাব বিভাগের account ধরে পুরো পথটি দেখুন। প্রতিটি ধাপে টেবিলের মান খেয়াল করুন, বিশেষ করে account বন্ধ হওয়ার পরও session কত থাকে।

৪ · Scope — ইঁদুর এক গর্তে নয়

বাড়িতে ইঁদুর ঢুকলে একটি গর্ত বুজিয়ে লাভ হয় না। সে আরেক গর্ত দিয়ে আসে, আপনি আবার বুজান। ইংরেজিতে একে বলে whack-a-mole. Scoping-এর লক্ষ্য এই খেলা থেকে বের হওয়া: সব গর্তের তালিকা বানিয়ে একসাথে বন্ধ করা।

Scope মানে শুধু “কোন machine” নয়। পাঁচটি তালিকা লাগে:

1. Host: কোন machine, VM, container-এ চিহ্ন আছে।
2. Account: কোন মানুষ, admin আর service account আক্রান্ত host-এ ব্যবহার হয়েছে।
3. Secret: কোন password, API key, certificate আক্রান্ত জায়গায় ছিল।
4. ডেটা: কী পড়া বা বাইরে নেওয়া হয়েছে। আইনি জানানোর দায় এখান থেকে আসে।
5. সময়: প্রথম খারাপ চিহ্ন কবে। Backup-এর কোন তারিখ পরিষ্কার, তা এতেই ঠিক হয়।

পদ্ধতিটি একটি চক্র। একটি IOC দিয়ে শুরু করুন, SIEM আর EDR-এ সবখানে খুঁজুন, নতুন host বা account পেলে তার থেকে নতুন IOC বের করুন, আবার খুঁজুন। নতুন কিছু না মেলা পর্যন্ত চলবে। এটি পর্ব ৫৮-এর hunting, শুধু এখানে শুরুর সূত্র জানা। হামলাকারীর পথ বোঝার জন্য lateral movement-এর ধারণা কাজে লাগে।

নিচের খেলনা tracker একটি জানা-খারাপ host থেকে login-এর খাতা ধরে সময়ের ক্রমে এগোয়। সময় কেন জরুরি? আক্রান্ত হওয়ার আগে যে account ওই host-এ ঢুকেছিল, সে শুধু ওই লগইনের কারণে সন্দেহভাজন নয়।

// Toy scope tracker: follow logins forward in time from one known-bad host.
// Log entries are made up: [hour, account, host].
const log = [
  [1, 'tania', 'web-01'], [3, 'rumi', 'app-02'], [6, 'deploy', 'web-01'],
  [7, 'deploy', 'app-02'], [8, 'svc-report', 'app-02'], [9, 'svc-report', 'db-01'],
  [10, 'rumi', 'hr-03'], [11, 'tania', 'db-01'], [12, 'tania', 'hr-03'],
  [13, 'sohel', 'pay-04'],
];
const FIRST_BAD = { node: 'web-01', hour: 5 };      // first evidence of intruder

const suspect = new Map([[FIRST_BAD.node, FIRST_BAD.hour]]);
for (const [hour, account, host] of log) {          // the log is in time order
  const acctBad = suspect.has(account) && suspect.get(account) <= hour;
  const hostBad = suspect.has(host) && suspect.get(host) <= hour;
  if (acctBad && !hostBad) {
    suspect.set(host, hour);
    console.log(`h${hour}: host ${host} reached by bad account ${account}`);
  } else if (hostBad && !acctBad) {
    suspect.set(account, hour);
    console.log(`h${hour}: account ${account} exposed on bad host ${host}`);
  }
}

const accounts = new Set(log.map(e => e[1]));
const all = new Set(log.flatMap(e => [e[1], e[2]]));
const bad = [...suspect.keys()];
console.log('hosts   :', bad.filter(n => !accounts.has(n)).join(', '));
console.log('accounts:', bad.filter(n => accounts.has(n)).join(', '));
console.log('not linked so far:', [...all].filter(n => !suspect.has(n)).join(', '));
console.log(`fixing only web-01 would leave ${bad.length - 1} of ${bad.length} open`);

h6: account deploy exposed on bad host web-01
h7: host app-02 reached by bad account deploy
h8: account svc-report exposed on bad host app-02
h9: host db-01 reached by bad account svc-report
h11: account tania exposed on bad host db-01
h12: host hr-03 reached by bad account tania
hosts   : web-01, app-02, db-01, hr-03
accounts: deploy, svc-report, tania
not linked so far: rumi, sohel, pay-04
fixing only web-01 would leave 6 of 7 open

৫ · Eradication — হামলাকারীর সব পথ তুলে ফেলা

Malware মুছলেই eradication হয় না। হামলাকারী ফিরে আসার ব্যবস্থা রেখে যায়, একে বলে persistence. আপনার কাজ এই জায়গাগুলো রক্ষকের চেকলিস্ট ধরে দেখা। এটি হামলার নির্দেশিকা নয়, বরং ঘর পরিষ্কারের তালিকা।

নিজের Linux server বা lab VM-এ চোখ বোলানোর জন্য কিছু পড়ার কমান্ড। এগুলো কিছু বদলায় না, শুধু দেখায়। অন্যের system-এ চালাবেন না।

systemctl list-unit-files --state=enabled
systemctl list-timers --all
crontab -l
ls -la /etc/cron.d /etc/cron.daily
sudo find /root /home -name authorized_keys -type f -exec ls -l {} +
sudo last -a -n 20

Rebuild, না clean?

পোকা ধরা একটি আমের পচা অংশ কেটে ফেলা যায়। কিন্তু ঝুড়ির ভেতর কোনটিতে পোকা আছে তা না জানলে পুরো ঝুড়ি বদলানোই নিরাপদ। সিস্টেমেও তাই। হামলাকারী যদি admin ক্ষমতা পেয়ে থাকে, তবে সে কী বদলেছে তার পুরো তালিকা আপনি জানেন না।

এরপর ঢোকার পথ বন্ধ। Scope থেকে root cause জানুন: patch না হওয়া VPN, ফাঁস হওয়া key, ফিশিং? পর্ব ৩২-এর মতো patch দিন, বা তা সম্ভব না হলে সেবা বন্ধ রাখুন। আসল ঢোকার পথ খোলা রেখে সব মুছলে হামলাকারী একই রাস্তায় ফেরে। এবার দেখুন, একটি account বাদ পড়লে কী হয়। ঘটনাটি কাল্পনিক, তবে ধরনটি বাস্তব।

৬ · Credential বদলের ক্রম — আগে কোনটি

সব password একসাথে বদলালেই কি হলো? না। ক্রম ভুল হলে নতুন password-ও হামলাকারী দেখে ফেলে। যে তালায় চাবি বানানো হয়, সেই কারখানায় যদি চোর বসে থাকে, তবে নতুন চাবিও তার হাতে যাবে। তাই আগে কারখানা, পরে চাবি।

মূল নিয়ম: যে জিনিস অন্যকে নিয়ন্ত্রণ করে, তা আগে। সাধারণ ক্রম এমন:

1. ঢোকার পথ বন্ধ আর হামলাকারীর চলমান প্রবেশ কাটা, নইলে নতুন secret-ও দেখা যাবে।
2. জরুরি admin (break-glass) আর cloud root: নিয়ন্ত্রণ আগে নিজের হাতে আনুন।
3. পর্ব ২০-এর privileged account, আর identity-র মূল: domain, IdP.
4. Secret vault আর KMS-এর admin access.
5. Service account, database password, API key, application secret.
6. সাধারণ ব্যবহারকারীর password, তাদের session বাতিল সহ।

Service account — যাকে সবাই ভুলে যায়

Service account মানুষের নয়, কোনো program-এর। তার password প্রায়ই বহু বছর একই থাকে, অনেক ফাইলে ছড়ানো থাকে, আর ক্ষমতা বেশি হয়। তার ওপর “ভাঙলে কী হবে” ভয়ে কেউ ছোঁয় না। সমাধান হলো আগে থেকে তালিকা রাখা: কোন account, কোন মালিক, কোন service ব্যবহার করে। ঘটনার রাতে এই তালিকা বানানো যায় না।

Active Directory আর krbtgt

পর্ব ৩১-এ দেখেছেন, Kerberos-এর ticket সিল করা হয় krbtgt account-এর key দিয়ে। পরিষদের সিলমোহর চুরি হলে যেমন জাল সনদ বানানো যায়, domain পুরো দখল হলে তেমনি হামলাকারী নিজেই ticket বানাতে পারে। তখন সাধারণ password বদলে লাভ হয় না।

তাই ধারণাটি হলো: krbtgt দুবার বদল, মাঝে ticket-এর সর্বোচ্চ আয়ু অপেক্ষা (ডিফল্টে ১০ ঘণ্টা)। কারণ পুরোনো একটি password ইতিহাসে থেকে যায়। সরাসরি পরপর দুবার বদলালে বৈধ ticket-ও ভাঙে, সেবা থমকে যায়। আর domain controller-এর replication সুস্থ কি না আগে দেখতে হয়। ঘটনার মাঝে এটি করার সিদ্ধান্ত নেন অভিজ্ঞ দল, Microsoft-এর সর্বশেষ নির্দেশিকা মিলিয়ে। Domain পুরো অবিশ্বস্ত হলে forest recovery-এর কথা ভাবতে হয়।

Cloud-এর key

Cloud-এ চুরি হওয়া key একটি পাসপোর্টের মতো। ঘরের দরজা বন্ধ করলেও পাসপোর্ট দিয়ে অন্য দেশে ঢোকা যায়। কাজগুলো এই ক্রমে ভাবুন:

• নিষ্ক্রিয়, মুছবেন না: সন্দেহভাজন key আগে disable করুন। মুছে ফেললে কে কী করেছে তা খোঁজা কঠিন হতে পারে, আর ভুল key হলে ফেরানো যায় না।
• স্বল্পায়ু credential ভুলবেন না: long-term key বন্ধ করলেই আগে নেওয়া temporary credential বন্ধ হয় না, সেগুলো মেয়াদ পর্যন্ত টিকতে পারে। উদাহরণ হিসেবে AWS-এর নথি বলে, এমন session বন্ধ করতে role-এ একটি deny policy বসাতে হয়, যা নির্দিষ্ট সময়ের আগে দেওয়া credential-কে অকেজো করে। অন্য provider-এর নিজস্ব উপায় আছে।
• Audit log পড়ুন: ওই key দিয়ে নতুন user, key বা role বানানো হয়েছে কি না দেখুন। এখানেই পরের persistence লুকিয়ে থাকে। বিস্তারিত Cloud & DevOps-এর secret ও KMS পর্বে।

এই নির্ভরতা একটি গ্রাফ, আর ক্রম বের করার গাণিতিক উপায় topological sort. নিচের খেলনা planner একই ঢেউয়ের কাজ একসাথে করে, তার আগের ঢেউ শেষ হলেই।

// Toy rotation planner: topological sort (Kahn) into waves. No real secrets.
// needs = what must be finished first. waitH = waiting time after this item.
function plan(items) {
  const left = new Map(Object.entries(items).map(([k, v]) => [k, new Set(v.needs)]));
  let clock = 0, wave = 0;
  while (left.size) {
    const ready = [...left].filter(([, n]) => n.size === 0).map(([k]) => k).sort();
    if (!ready.length) {
      console.log('CYCLE, cannot order:', [...left.keys()].join(', '));
      return;
    }
    console.log(`wave ${++wave} (t+${clock} h): ${ready.join(', ')}`);
    ready.forEach(k => left.delete(k));
    for (const n of left.values()) ready.forEach(k => n.delete(k));
    clock += Math.max(1, ...ready.map(k => items[k].waitH || 0));
  }
  console.log(`done by about t+${clock} h`);
}

plan({
  'entry-point-closed': { needs: [] },
  'admin-accounts':     { needs: ['entry-point-closed'] },
  'cloud-root-keys':    { needs: ['entry-point-closed'] },
  'vault-admin':        { needs: ['admin-accounts'] },
  'krbtgt-round-1':     { needs: ['admin-accounts'], waitH: 10 },
  'krbtgt-round-2':     { needs: ['krbtgt-round-1'] },
  'svc-backup':         { needs: ['vault-admin'] },
  'svc-report':         { needs: ['vault-admin'] },
  'db-password':        { needs: ['vault-admin'] },
  'app-secrets':        { needs: ['db-password'] },
  'user-passwords':     { needs: ['krbtgt-round-2'] },
});
console.log('---');
plan({ 'app-key': { needs: ['db-pass'] }, 'db-pass': { needs: ['app-key'] } });

wave 1 (t+0 h): entry-point-closed
wave 2 (t+1 h): admin-accounts, cloud-root-keys
wave 3 (t+2 h): krbtgt-round-1, vault-admin
wave 4 (t+12 h): db-password, krbtgt-round-2, svc-backup, svc-report
wave 5 (t+13 h): app-secrets, user-passwords
done by about t+14 h
---
CYCLE, cannot order: app-key, db-pass

৭ · Recovery — পরিষ্কারভাবে, ধাপে ধাপে ফেরা

Backup থেকে কীভাবে ফিরবেন, তার হিসাব আর ransomware-এর বিশেষ ক্রম আছে পর্ব ৩৪-এ। এখানে যেকোনো ঘটনার জন্য সাধারণ নীতি।

• Known-good উৎস: আক্রান্ত হওয়ার আগের পরিষ্কার সময়টি scope থেকে নিন। শুধু “সর্বশেষ backup” নিলে হামলাকারীর চিহ্নও ফিরে আসতে পারে। তারপর পুরোনো ডেটার ফাঁক পূরণ হবে অন্য উৎস থেকে।
• আলাদা জায়গায় আগে: Isolated recovery environment-এ restore করে পরীক্ষা, তারপর মূল network-এ। Immutable backup এখানে কাজে আসে।
• Rebuild: Server বানান golden image আর code থেকে, পুরোনো machine থেকে নয়। নতুন patch আর নতুন secret নিয়ে।
• Integrity যাচাই: ফাইলের hash মেলানো যথেষ্ট নয়, ব্যবসার হিসাবও মেলাতে হয়। যেমন অর্ডারের মোট টাকা মেলে কি না পেমেন্ট প্রদানকারীর রেকর্ডের সাথে।
• বাড়তি নজর: Heightened monitoring মানে ফেরার পর নতুন detection rule, বেশি log, IOC-এর ওপর সরাসরি alert আর পালা করে দেখা। প্রায়ই অন্তত কয়েক সপ্তাহ।
• ধাপে ধাপে: Staged rollout-এর মতো অল্প traffic থেকে শুরু, প্রতিটি ধাপের মাঝে soak time. সমস্যা হলে rollback ধাপে ধাপে।

নিচের খেলনা simulator সময় ধরে একই নিয়ম চালায়, আর ইচ্ছা করে একটি IOC বসানো আছে। Clock আসল নয়, সবই সিমুলেশন, আর seed-এর কারণে ফল সবসময় একই।

// Toy staged recovery on a simulated clock (minutes). Seeded, so always the same.
function mulberry32(a) {
  return () => { a |= 0; a = a + 0x6D2B79F5 | 0;
    let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const rand = mulberry32(62);
const STAGES = [{ pct: 5, soak: 30 }, { pct: 25, soak: 30 },
                { pct: 50, soak: 60 }, { pct: 100, soak: 120 }];
const MAX_ERR = 1.0, CHECK_EVERY = 10, REPAIR_MIN = 40;
const iocAt = new Map([[90, 'app-07 calls known-bad address']]);  // one toy event

let now = 0, i = 0, soaked = 0, worst = 0;
console.log(`t=0 start stage ${STAGES[0].pct}%`);
while (i < STAGES.length) {
  now += CHECK_EVERY; soaked += CHECK_EVERY;
  const err = 0.2 + rand() * 0.4 + STAGES[i].pct / 500;    // percent of requests
  worst = Math.max(worst, err);
  const ioc = iocAt.get(now);
  if (ioc || err > MAX_ERR) {
    console.log(`t=${now} HOLD at ${STAGES[i].pct}%: ${ioc || 'errors ' + err.toFixed(2)}`);
    now += REPAIR_MIN; i = Math.max(0, i - 1); soaked = 0; worst = 0;
    console.log(`t=${now} back to ${STAGES[i].pct}% after repair, soak restarts`);
    continue;
  }
  if (soaked >= STAGES[i].soak) {
    console.log(`t=${now} stage ${STAGES[i].pct}% passed, worst errors ${worst.toFixed(2)}%`);
    i++; soaked = 0; worst = 0;
    if (i < STAGES.length) console.log(`t=${now} start stage ${STAGES[i].pct}%`);
  }
}
console.log(`full service watched by t=${now} min (${(now / 60).toFixed(1)} h)`);

t=0 start stage 5%
t=30 stage 5% passed, worst errors 0.51%
t=30 start stage 25%
t=60 stage 25% passed, worst errors 0.42%
t=60 start stage 50%
t=90 HOLD at 50%: app-07 calls known-bad address
t=130 back to 25% after repair, soak restarts
t=160 stage 25% passed, worst errors 0.50%
t=160 start stage 50%
t=220 stage 50% passed, worst errors 0.63%
t=220 start stage 100%
t=340 stage 100% passed, worst errors 0.79%
full service watched by t=340 min (5.7 h)

৮ · কখন শেষ, আর ব্যবস্থাপনার সাথে কাজ

“ঘটনা শেষ” বলার শর্ত

শান্ত থাকা প্রমাণ নয়। Exit criteria আগে থেকে লিখে রাখলে চাপের মুখে তর্ক কমে।

• Scope-এর সব host আর account-এর কাজ শেষ, কেউ বাদ নেই
• Root cause জানা, আর ঢোকার পথ বন্ধ বলে যাচাই হয়েছে
• সব জানা IOC-তে নজর চলছে, ঠিক করা সময়ে কোনো নতুন সংকেত নেই
• Service ফিরেছে, ডেটার integrity ব্যবসার মালিক মেনেছেন
• আইনি ও নিয়ন্ত্রক জানানোর সিদ্ধান্ত হয়েছে, দেখুন পর্ব ৬
• Incident lead আর ব্যবসার দায়িত্বশীল ব্যক্তি লিখে বন্ধ করেছেন

ব্যবসার ধারাবাহিকতার সাথে মিল

Business continuity মানে সংকটেও জরুরি সেবা চালু রাখার পরিকল্পনা। Disaster recovery তার প্রযুক্তিগত অংশ, যার গভীরে যেতে দেখুন System Design-এর disaster recovery পর্ব। ঘটনায় দুটি পরিকল্পনা একসাথে কাজ করে, আর এখানে সংঘর্ষও হয়। তাই অগ্রাধিকার আগে থেকে ঠিক করে রাখা ভালো: কোন সেবা আগে ফিরবে, কতক্ষণ হাতে কাজ চলবে, কতটা ডেটা হারানো চলবে (RPO).

একটি সাধারণ ফাঁদ: disaster recovery-র কপিতে ফিরে যাওয়া। ঝড় বা আগুনে এটি ঠিক, কিন্তু হামলায় সেই কপিও আক্রান্ত হতে পারে, কারণ replication খারাপ জিনিসও কপি করে। তাই failover-এর আগে দেখুন, কপিটি পরিষ্কার কি না, আর একই credential সেখানেও চলে কি না।

চাপের মধ্যে ব্যবস্থাপনার সাথে

ব্যবস্থাপনা জানতে চান তিনটি কথা: কী হয়েছে, কত খরচ, কখন শেষ। আপনি তিনটিই পুরো জানেন না। তবুও কথা বলার ভালো উপায় আছে।

• জানা, অজানা, পরের সময়: “যা জানি, যা জানি না, পরের আপডেট বিকেল ৪টায়”। নিয়মিত সময় বাঁধলে বারবার ফোন কমে।
• সিদ্ধান্ত হিসেবে সামনে আনুন: “Payment service ২ ঘণ্টা বন্ধ রাখলে ঝুঁকি কমে, খরচ এই। আপনি কোনটি বেছে নেবেন?” Service বন্ধের সিদ্ধান্ত ব্যবসার, ঝুঁকির তথ্য আপনার।
• অনুমানকে অনুমান বলুন: “ডেটা চুরি হয়নি” না বলে “এখন পর্যন্ত প্রমাণ পাইনি, log ১৪ দিনের”।
• এক মুখপাত্র: গ্রাহক, কর্মী আর গণমাধ্যমের বার্তা আইনি পরামর্শের সাথে মিলিয়ে একজনের মাধ্যমে।
• মানুষকে বিশ্রাম: পালা বদল না হলে ক্লান্ত মানুষ ভুল করেন, আর এই ভুল ব্যয়বহুল।

৯ · Post-incident review — ক্ষত থেকে কাজের তালিকা

ঘটনার পর post-incident review না হলে একই ফাঁদে আবার পড়তে হয়। স্মৃতি তাজা থাকতে, সাধারণত কয়েক দিন থেকে দুই সপ্তাহের মধ্যে এটি করুন। সুর হবে blameless: “কে ভুল করল” নয়, “ব্যবস্থা কেন এই ভুল হতে দিল”। সংস্কৃতির দিকটি আছে পর্ব ৫৪-তে।

সময়রেখা আগে: কখন ঢুকল, কখন ধরা পড়ল, কখন থামল, কখন ফিরল। তা থেকে কয়েকটি মাপ আসে, যেমন dwell time, MTTD আর MTTR. তারপর প্রশ্ন: কী কাজ করল, কী করল না, পরের বার কোন detection এটি আগে ধরত?

Review-এর আসল ফল প্রতিবেদন নয়, কাজের তালিকা। একটি ভালো action item-এর চারটি অংশ:

“সতর্ক থাকতে হবে” কোনো কাজ নয়। মালিক ছাড়া কাজ কেউ করে না, আর ব্যক্তির বদলে “IT বিভাগ” লিখলে দায় হারিয়ে যায়। কাজগুলো ট্র্যাক করে শেষ করতে হয়, আর পরের মহড়ায় (পর্ব ৬৬) যাচাই করতে হয়। বড় ঘটনায় বিস্তারিত অনুসন্ধান, প্রমাণ আর সময়রেখা বানানো আসে পর্ব ৬৩ আর পর্ব ৬৪-তে।

১০ · AI-এর যুগে containment আর recovery

AI ঘটনার সময় দ্রুত log সারাংশ, সময়রেখা আর প্রতিবেদনের খসড়া দিতে পারে। কিন্তু এখানে ভুলের দাম খুব বেশি, কারণ এটি চলমান ব্যবসা আর আইনি প্রমাণ ছোঁয়।

• Prompt-এ secret, token, গ্রাহকের ডেটা বা ব্যক্তিগত তথ্য দিইনি
• AI-এর উল্লেখ করা CVE, standard আর command মূল উৎসে দেখেছি
• যে command সিস্টেম বদলায়, তা আগে lab-এ চালিয়েছি এবং diff পড়েছি
• AI-এর সারাংশের প্রতিটি দাবি মূল log-এ মিলিয়েছি
• মানুষের ওপর প্রভাব পড়ে এমন সিদ্ধান্ত একজন মানুষ নিয়েছেন