SOC পরিচালনা — tier, triage, playbook আর metric

১ · SOC আসলে কী করে

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

SOC (Security Operations Center) ঠিক এই জরুরি বিভাগ। আগের পর্বগুলোতে আপনি IDS, endpoint নিরাপত্তা আর ATT&CK-এর কথা জেনেছেন। পর্ব ৫৫ থেকে ৫৯-এ log, SIEM, threat intelligence, hunting আর EDR এসেছে। এই পর্বের প্রশ্ন আলাদা: এসব tool থেকে আসা সংকেত নিয়ে মানুষ প্রতিদিন কীভাবে কাজ করবেন?

SOC সব নিরাপত্তার কাজ করে না। Patch করা IT দলের কাজ হতে পারে। Policy লেখা governance দলের কাজ। বড় ঘটনায় CSIRT নেতৃত্ব দিতে পারে, আর সেই দল SOC-এর ভেতরে বা বাইরে থাকতে পারে। প্রতিষ্ঠানভেদে এই সীমা আলাদা, তাই কার কী দায়িত্ব সেটি আগেই লিখে রাখা দরকার। Incident response-এর পুরো পদ্ধতি পর্ব ৬১-তে আসবে।

আর একটি কথা: SOC-এ শুধু নিজের প্রতিষ্ঠানের অনুমোদিত সিস্টেমে কাজ হয়। সন্দেহজনক বাইরের ঠিকানায় পাল্টা কিছু করা কাজের অংশ নয়, আর তা অপরাধও হতে পারে। সীমাটি পর্ব ৬-এ দেখুন।

২ · SOC-এর মডেল আর ভূমিকা

SOC বানানোর একটিই ঠিক উপায় নেই। প্রতিষ্ঠানের আকার, ঝুঁকি আর বাজেট দেখে মডেল বাছতে হয়।

এই নামগুলোর ব্যবহার সবখানে এক নয়। একটি বিক্রেতার “virtual SOC” অন্যটির “MDR”-এর মতো হতে পারে। তাই নামের বদলে দেখুন: রাত তিনটায় কে সিদ্ধান্ত নেবেন, আর কোন কাজ করার অনুমতি তাঁর আছে?

দলের ভূমিকা

অনেক SOC-এ দল tier বা স্তরে ভাগ থাকে। ভাবুন থানার মতো: ডিউটি অফিসার অভিযোগ নেন, তদন্ত কর্মকর্তা গভীরে যান, আর জটিল মামলায় বিশেষজ্ঞ আসেন।

ছোট দলে একজনই কয়েকটি ভূমিকা নেন। Tier ব্যবস্থাও সবখানে নেই। অনেক দল এখন স্তর কমিয়ে একই analyst-কে শুরু থেকে শেষ পর্যন্ত কাজ দেন। দুই পদ্ধতিরই যুক্তি আছে, যা ভাবনার প্রশ্ন ৩-এ দেখবেন।

৩ · একটি alert-এর জীবন

একটি detection rule মিললে SIEM, EDR বা XDR একটি alert বানায়। Alert শুধু একটি সন্দেহ, প্রমাণ নয়। এরপর সেটি পাঁচটি ধাপ পেরোয়।

এবার একটি কাল্পনিক অনলাইন বাজারের একটি alert ধরে এগোন। সব নাম, সময় আর ঠিকানা বানানো। খেয়াল করুন, প্রতিটি ধাপে case-এর অবস্থা, মালিক আর সময় কীভাবে বদলায়।

ভালো triage note কেমন

একটি triage note পরের মানুষের জন্য লেখা। তিনি হতে পারেন রাতের tier 2, সকালের shift, বা ছয় মাস পরের নিরীক্ষক। অফিসের রেজিস্টার খাতার মতো, লেখা না থাকলে কাজটি প্রমাণিত নয়। নিচে দুটি উদাহরণ দেখুন।

খারাপ: Checked. Looks suspicious. Sending to T2.

ভালো:
What : Login for rina@example.com from new device, 02:02
Seen : IP 203.0.113.50 outside office range; first time on this device;
       MFA passed; user is in finance
Asked: User by phone, 02:29: approved one MFA prompt while asleep
Not checked: mailbox rules, other accounts
Verdict: Suspicious, medium-high confidence
Why escalated: Possible account takeover; I cannot revoke sessions
Next : Check mailbox rules and recent reads

ভালো note-এ সত্য, অনুমান আর অজানা আলাদা থাকে। “কী দেখিনি” লাইনটি সবচেয়ে সৎ, আর সবচেয়ে কাজের। এতে পরের জন একই কাজ আবার করেন না, আবার ধরেও নেন না যে সব দেখা হয়ে গেছে।

Verdict-গুলোও আলাদা রাখুন। True positive মানে আসল ক্ষতিকর ঘটনা। False positive মানে rule ভুল করেছে। Benign positive মানে rule ঠিক ধরেছে, কিন্তু কাজটি অনুমোদিত, যেমন IT দলের নির্ধারিত পরীক্ষা। Alahmadi, Axon আর Martinovic-এর ২০২২ সালের USENIX Security গবেষণাতেও দেখা যায়, analyst-রা “false alarm” আর “benign trigger” আলাদা করে ভাবেন। দুটোর সমাধানও আলাদা: প্রথমটিতে rule ঠিক করতে হয়, দ্বিতীয়টিতে ব্যতিক্রম লিখতে হয়।

৪ · Severity, priority আর triage queue

দুটি শব্দ প্রায়ই গুলিয়ে যায়। Severity বলে ঘটনাটি সত্যি হলে কতটা গুরুতর। Priority বলে কোনটি আগে ধরা হবে। একই ধরনের alert পরীক্ষার ল্যাবের কম্পিউটারে হলে priority কম, আর payment server-এ হলে অনেক বেশি। এই হিসাবে সম্পদের গুরুত্ব, তথ্যের আস্থা আর সময়ও যুক্ত হয়।

নিচের ছকটি একটি উদাহরণ। সময়গুলো অনুমান, কোনো মান নয়। আপনার প্রতিষ্ঠান নিজের ঝুঁকি দেখে ঠিক করবে আর SLA-তে লিখবে।

এবার queue চালিয়ে দেখি। একজন analyst, ছয়টি alert আর একটি simulated clock. প্রথমে যে আগে এসেছে সে আগে, তারপর priority score দিয়ে। Score-এ অপেক্ষার সময়ও যোগ হয়, যাতে ছোট alert চিরকাল পড়ে না থাকে।

// Toy queue: one analyst, simulated clock in minutes. Not real alerts.
const alerts = [
  { id: 'A1', at: 0,  name: 'failed logins, lab PC',   sev: 2, asset: 1, conf: 2, work: 10 },
  { id: 'A2', at: 1,  name: 'port sweep, guest Wi-Fi', sev: 1, asset: 1, conf: 2, work: 10 },
  { id: 'A3', at: 2,  name: 'AV blocked file, laptop', sev: 2, asset: 2, conf: 4, work: 10 },
  { id: 'A4', at: 4,  name: 'new admin, payment DB',   sev: 4, asset: 4, conf: 3, work: 25 },
  { id: 'A5', at: 5,  name: 'mail forward, finance',   sev: 3, asset: 3, conf: 4, work: 15 },
  { id: 'A6', at: 6,  name: 'old OS seen, printer',    sev: 1, asset: 1, conf: 4, work: 5 },
];
// Score = severity x asset value x confidence + 1 point per 5 minutes waited
const score = (a, now) => a.sev * a.asset * a.conf + (now - a.at) / 5;

function run(label, pick) {
  let now = 0, waiting = alerts.slice();
  console.log(label);
  while (waiting.length) {
    const ready = waiting.filter(a => a.at <= now);
    if (!ready.length) { now = Math.min(...waiting.map(a => a.at)); continue; }
    const a = pick(ready, now);
    console.log(`  t=${String(now).padStart(2)} ${a.id} waited ${String(now - a.at).padStart(2)} min  ${a.name}`);
    now += a.work;
    waiting = waiting.filter(x => x !== a);
  }
}
const oldest = list => list[0];
const best = (list, now) => list.reduce((x, y) => score(y, now) > score(x, now) ? y : x);
run('First come, first served:', oldest);
run('Priority score with ageing:', best);

৫ · Playbook, runbook আর SOAR

রাত তিনটায় ক্লান্ত মাথায় নতুন করে ভাবা কঠিন। তাই সিদ্ধান্তের পথ আগেই শান্ত মাথায় লিখে রাখা হয়। গার্মেন্টসে আগুন লাগলে কে কোন সিঁড়ি দিয়ে নামাবেন, সেই মহড়ার মতো।

Playbook সাধারণত বড় ছবি দেখায়: এই ধরনের ঘটনায় কী কী সিদ্ধান্ত, কে নেবেন, কখন কাকে জানাবেন। Runbook সাধারণত নির্দিষ্ট কাজের ধাপ দেখায়: একটি account কীভাবে আটকাবেন। তবে অনেক প্রতিষ্ঠান শব্দ দুটি উল্টে বা এক অর্থে ব্যবহার করে। তাই দলের ভেতরে সংজ্ঞা ঠিক করে নিন।

একটি ভালো playbook-এ থাকে: কখন শুরু হবে, কী তথ্য লাগবে, প্রতিটি সিদ্ধান্তের মালিক, কোন কাজ করা যাবে আর যাবে না, কাকে জানাতে হবে, আর কখন শেষ বলা যাবে। আর থাকে শেষ মহড়ার তারিখ। Tabletop মহড়া নিয়ে বিস্তারিত পর্ব ৬৬-তে।

SOAR: যন্ত্রের হাত, মানুষের বিচার

SOAR (Security Orchestration, Automation and Response) playbook-এর ধাপগুলো বিভিন্ন tool জুড়ে চালায়। Enrichment, ticket খোলা, বার্তা পাঠানোর মতো বিরক্তিকর কাজ এতে কমে। তবে প্রশ্ন একটাই: কোন কাজ মানুষ ছাড়া চলতে পারে?

এই নকশাকে বলে human in the loop. নিয়মটি সহজ: কাজটি যত সহজে ফেরানো যায় আর যত কম মানুষকে ছোঁয়, automation তত নিরাপদ। নিচের stepper-এ দেখুন একটি phishing রিপোর্ট কীভাবে এগোয়। যন্ত্র কোথায় থামে আর মানুষ কোথায় “না” বলেন, খেয়াল করুন।

একই ধারণা ছোট একটি toy program-এ। এখানে কোনো আসল system নেই, সব তথ্য memory-তে। লক্ষ্য করুন, প্রতিটি কাজ audit তালিকায় উঠছে, আর অনুমোদনের ফাংশনটি আলাদা।

// SOAR-like playbook on toy data. Nothing here touches a real system.
const intel = { 'login-verify.example.com': 'bad', 'news.example.org': 'ok' };
const staff = { 'rina@example.com': { dept: 'finance', vip: false } };
let clock = 0;
const audit = [];
const log = (who, what) => audit.push(`t+${clock++}m ${who.padEnd(6)} ${what}`);

function playbook(alert, approve) {
  log('soar', `enrich domain ${alert.domain}: ${intel[alert.domain] || 'unknown'}`);
  log('soar', `enrich user: ${staff[alert.user].dept}`);
  log('soar', `count copies in toy mailboxes: ${alert.copies}`);
  if (intel[alert.domain] !== 'bad') {
    log('soar', 'not known bad: send to analyst queue, take no action');
    return;
  }
  log('soar', 'AUTO quarantine reported message (reversible, one mailbox)');
  const ask = `purge ${alert.copies} copies and reset ${alert.user}?`;
  const answer = approve(alert, ask);
  log('human', `${ask} => ${answer}`);
  if (answer === 'yes') log('soar', 'purge and reset done, ticket updated');
  else log('soar', 'no change, ticket stays open with analyst');
}
const analyst = a => (a.clicked ? 'yes' : 'no');

playbook({ domain: 'news.example.org', user: 'rina@example.com',
           copies: 1, clicked: false }, analyst);
playbook({ domain: 'login-verify.example.com', user: 'rina@example.com',
           copies: 14, clicked: true }, analyst);
console.log(audit.join('\n'));

Case management

Chat-এর বার্তা হারিয়ে যায়। তাই case management tool-এ প্রতিটি case-এর একজন মালিক, অবস্থা, প্রমাণের লিংক, সময়রেখা আর সিদ্ধান্ত থাকে। একটি ticket-এর একাধিক মালিক মানে আসলে মালিক নেই। ভালো case পরে তিনটি কাজে লাগে: handover, নিরীক্ষা আর metric. প্রমাণ সামলানোর নিয়ম পর্ব ৬৩-তে দেখবেন। Case-এ গ্রাহকের ব্যক্তিগত তথ্য শুধু দরকারমতো রাখুন, আর দেখার অধিকারও সীমিত করুন।

৬ · Shift, 24x7 হিসাব, handover আর burnout

আপনার বস বললেন, “রাতদিন একজন বসিয়ে দিন। সপ্তাহে ১৬৮ ঘণ্টা, একজন ৪০ ঘণ্টা করেন, তাই ৪.২ জন, মানে ৫ জনেই হবে।” কথাটি শুনতে ঠিক, কিন্তু মানুষের ছুটি, অসুস্থতা, প্রশিক্ষণ আর shift-এর মাঝের সময় এতে নেই। হিসাবটি ভালো করে করি। সব সংখ্যাই অনুমান, আপনার প্রতিষ্ঠানের নিয়ম আর দেশের শ্রম আইন দেখে বদলাবেন।

// 24x7 staffing arithmetic. All inputs are assumptions: change them.
const weekHours = 40, leaveDays = 30, trainingDays = 10, shrinkage = 0.10;
const shiftHours = 8, overlapHours = 0.5;   // handover overlap per shift

const contract = 52 * weekHours;
const off = (leaveDays + trainingDays) * (weekHours / 5);
const onFloor = (contract - off) * (1 - shrinkage);
console.log('Hours in a week: 24 x 7 =', 24 * 7);
console.log('Naive answer: 168 / 40 =', (168 / weekHours).toFixed(1), 'people');
console.log('Contract hours per person per year:', contract);
console.log('Minus leave and training:', contract - off);
console.log('On-floor hours after shrinkage:', onFloor);

const shiftSeatYear = (shiftHours + overlapHours) * 365;
function staff(seats) {          // seats = [day, evening, night]
  const total = seats.reduce((s, n) => s + n * shiftSeatYear, 0);
  const people = total / onFloor;
  return `${seats.join('+')} seats: ${total} h/yr, ${people.toFixed(2)} => ${Math.ceil(people)} people`;
}
console.log('Hours for one seat, one shift, one year:', shiftSeatYear);
console.log(staff([1, 1, 1]));
console.log(staff([2, 2, 2]));
console.log(staff([3, 2, 2]));

Handover: দায়িত্ব বদলের মুহূর্ত

Shift handover SOC-এর সবচেয়ে দুর্বল মুহূর্তগুলোর একটি। ফ্যাক্টরিতে শিফট বদলের সময় যন্ত্র যেমন বন্ধ করা হয় না, SOC-ও থামে না। অসমাপ্ত কাজ দুই মানুষের মাঝখানে হারিয়ে যেতে পারে। নিচে একটি কাল্পনিক ভোরের handover দেখুন। প্রতিটি ধাপে note-এ একটি করে অংশ যোগ হচ্ছে।

Alert fatigue আর burnout

Alert fatigue কোনো চরিত্রের দুর্বলতা নয়, এটি নকশার সমস্যা। শহরে সারাদিন গাড়ির হর্ন বাজলে কেউ আর ফিরে তাকান না। একইভাবে একশোটি ভুল alert-এর পর একটি আসল alert-ও একই রকম লাগে। কারণটি অঙ্কেও আছে: আসল ঘটনা বিরল, তাই ভালো rule-এও বেশিরভাগ alert ভুল হতে পারে। এই base-rate fallacy পর্ব ২৩-এ বিস্তারিত আছে।

আরেকটি হিসাব দেখুন। দিনে ৪০০টি alert, প্রতিটিতে ১২ মিনিট। মোট ৪৮০০ মিনিট, মানে ৮০ ঘণ্টা কাজ। একজন প্রতিদিন ৬ ঘণ্টা মনোযোগ দিতে পারলে লাগে ৮০ ÷ ৬ ≈ ১৩.৩ জন। Alert অর্ধেক করা গেলে ৭ জনের কম লাগে। তাই tuning-এ সময় দেওয়া সবচেয়ে সস্তা নিয়োগ।

Burnout নিয়ে Sundaramurthy ও সহকর্মীদের একটি গবেষণা (SOUPS ২০১৫) SOC-এ মাঠপর্যায়ে কাজ করে দেখায় যে এটি মানুষ, প্রযুক্তি আর ব্যবস্থাপনার পরস্পর জড়ানো চক্র। একঘেয়ে কাজ, বিকাশের অভাব, স্বীকৃতির অভাব একে অন্যকে বাড়ায়। যা সাহায্য করে:

• একঘেয়ে কাজ automation-এ দেওয়া, আর analyst-কে rule ঠিক করার ক্ষমতা দেওয়া
• Shift ঘোরানোর ধরন আগেই জানানো, রাতের পর যথেষ্ট বিশ্রাম রাখা
• সপ্তাহে কিছু সময় শেখা, hunting বা tuning-এর জন্য queue-র বাইরে রাখা
• ভুল alert বন্ধ করার কাজকেও দলের কাজ হিসেবে মর্যাদা দেওয়া

৭ · Metric, আর metric-এর ফাঁদ

আগে সংজ্ঞা। এগুলো শিল্পে প্রচলিত, তবে কোনো একক মান নেই। আপনার প্রতিষ্ঠান কোথা থেকে কোথা পর্যন্ত মাপছে, লিখে রাখুন।

এবার ১২টি কাল্পনিক case থেকে metric বের করি। পাঁচটি আসল ঘটনার একটি ৩ দিন লুকিয়ে ছিল। গড় আর median কী বলে দেখুন। তারপর একটি স্বয়ংক্রিয় closing script কী করে, সেটিও দেখুন।

// Toy closed cases: [verdict, detect, acknowledge, resolve, escalated]
// Times in minutes. Detect time is known only for true positives (TP).
const cases = [
  ['TP', 12, 3, 38, 1], ['TP', 8, 5, 45, 1], ['TP', 20, 4, 60, 1],
  ['TP', 15, 6, 52, 1], ['TP', 4300, 12, 900, 1],
  ['FP', null, 7, 12, 1], ['FP', null, 2, 9, 0], ['FP', null, 9, 15, 0],
  ['FP', null, 4, 10, 0], ['BP', null, 6, 20, 0], ['BP', null, 3, 14, 0],
  ['BP', null, 5, 11, 0],
];
const mean = xs => xs.reduce((s, x) => s + x, 0) / xs.length;
function median(xs) {
  const s = [...xs].sort((a, b) => a - b), m = s.length >> 1;
  return s.length % 2 ? s[m] : (s[m - 1] + s[m]) / 2;
}
const show = (name, xs) =>
  console.log(`${name}: n=${xs.length} mean=${mean(xs).toFixed(1)} median=${median(xs)}`);

const tp = cases.filter(c => c[0] === 'TP');
show('MTTD (TP only)', tp.map(c => c[1]));
show('MTTA (all)    ', cases.map(c => c[2]));
show('MTTR (all)    ', cases.map(c => c[3]));
show('MTTR (TP only)', tp.map(c => c[3]));
const rate = (name, list) => console.log(
  `${name}: ${list.filter(c => c[0] === 'FP').length} FP, ` +
  `${list.filter(c => c[4]).length} escalated, of ${list.length} cases`);
rate('Rates', cases);

// Gaming: add 60 noisy alerts closed by a script in 1 minute, unread
const gamed = cases.concat(Array.from({ length: 60 }, () => ['FP', null, 0, 1, 0]));
console.log('--- after a closing script ---');
show('MTTA (all)    ', gamed.map(c => c[2]));
show('MTTR (all)    ', gamed.map(c => c[3]));
show('MTTR (TP only)', gamed.filter(c => c[0] === 'TP').map(c => c[3]));
rate('Rates', gamed);

এই ফাঁদের নাম Goodhart’s law: কোনো মাপকে লক্ষ্য বানালে সেটি আর ভালো মাপ থাকে না। MTTA-কে লক্ষ্য বানালে মানুষ পড়ার আগেই “ack” চাপেন। Alert কম করতে বললে rule বন্ধ হয়। Closure-এর সংখ্যা ধরলে কঠিন case কেউ ধরতে চান না।

বাঁচার উপায় কয়েকটি। Metric জোড়ায় দেখুন, যেমন গতি আর মান। প্রতি মাসে বন্ধ হওয়া alert-এর একটি নমুনা আরেকজন আবার পরীক্ষা করুন। TP আর সব alert-এর হিসাব আলাদা রাখুন। Detection পরীক্ষা করতে নিজের পরিবেশে অনুমোদিত নকল ঘটনা চালান। আর metric দিয়ে দলকে বোঝার চেষ্টা করুন, মানুষকে শাস্তি দিতে নয়। Coverage-এর জন্য ATT&CK মানচিত্রও কাজে লাগে, তবে রঙিন ঘর মানেই সুরক্ষা নয়। False negative, মানে যা ধরাই পড়েনি, কোনো dashboard-এ নিজে থেকে দেখা যায় না।

৮ · Maturity, ছোট প্রতিষ্ঠান আর যোগাযোগ

SOC কতটা পরিণত, কীভাবে মাপবেন

SOC-CMM একটি স্বমূল্যায়ন model, যার শুরু ২০১৬ সালে। এটি পাঁচটি ডোমেইনে প্রশ্ন করে: Business, People, Process, Technology আর Services. উদ্দেশ্য কারও সাথে প্রতিযোগিতা নয়, নিজের দুর্বল জায়গা খুঁজে পাওয়া। প্রশ্নের সংখ্যা আর স্কেল version-ভেদে বদলায়, তাই SOC-CMM-এর নিজস্ব সাইটের সর্বশেষ version দেখুন।

MITRE প্রকাশ করেছে 11 Strategies of a World-Class Cybersecurity Operations Center (Knerler, Parker, Zimmerman, ২০২২), যা ২০১৪ সালের Ten Strategies বইয়ের উত্তরসূরি। MITRE-র সাইটে বইটি বিনামূল্যে পাওয়া যায়। এর কৌশলগুলো সহজ ভাষায়:

1. কী রক্ষা করছেন আর কেন, তা জানা
2. SOC-কে কাজ করার ক্ষমতা দেওয়া
3. প্রতিষ্ঠানের প্রয়োজন মেনে কাঠামো গড়া
4. ভালো কর্মী নিয়োগ আর তাঁদের বিকাশ
5. Incident response-কে অগ্রাধিকার দেওয়া
6. Threat intelligence দিয়ে প্রতিপক্ষকে বোঝা
7. ঠিক ডেটা বেছে সংগ্রহ করা
8. Analyst-এর কাজের ধারা মেনে tool ব্যবহার
9. স্পষ্ট যোগাযোগ, সহযোগিতা আর তথ্য ভাগ
10. উন্নতির জন্য কর্মক্ষমতা মাপা
11. ধাপে ধাপে SOC-এর কাজ বাড়ানো

লক্ষ্য করুন, তালিকার বেশিরভাগই মানুষ, ক্ষমতা আর যোগাযোগ নিয়ে। কোনো নির্দিষ্ট পণ্যের নাম এতে নেই।

ছোট প্রতিষ্ঠান কী করবে

পাঁচজনের IT দল থাকলে নিজের 24x7 SOC কল্পনা না করাই ভালো। পাড়ায় প্রতিটি বাড়ি নিজের সেনাবাহিনী রাখে না, সবাই মিলে একজন দারোয়ান রাখে। সিঁড়ির মতো এগোন:

1. Cloud আর endpoint tool-এর নিজের alert চালু করে একটি মাত্র জায়গায় আনুন।
2. ৫–১০টি সবচেয়ে গুরুত্বপূর্ণ alert বাছুন: admin login, MFA বদল, mail forwarding, backup মোছা।
3. একটি ফোন নম্বর আর একটি on-call তালিকা রাখুন, যাতে বার্তাটি কারও কাছে পৌঁছায়।
4. রাতের জন্য MDR-এর মতো সেবা বিবেচনা করুন।
5. বড় ঘটনার জন্য আগেই একটি বাইরের সাহায্যের পথ ঠিক করে রাখুন।

বাইরের সেবা নিলে দায়িত্বও বাইরে চলে যায় না। চুক্তির আগে জিজ্ঞেস করুন: সেবার সময় কী, কী কী log দেখবেন, নিজে থেকে কোন কাজ করতে পারবেন, কতক্ষণে জানাবেন, আর ডেটা কোথায় থাকবে। বিস্তারিত পর্ব ৭১ (vendor ঝুঁকি) আর পর্ব ৭০ (উপাত্ত আইন)-এ আসবে।

IT আর নেতৃত্বের সাথে কথা বলা

SOC সাধারণত নিজের হাতে সার্ভার ঠিক করে না। IT দল করে। তাই সম্পর্কটি আগে থেকেই গড়তে হয়। ঘটনার রাতে প্রথম পরিচয় হলে কাজ এগোয় না। IT-কে অভিযোগের সুরে নয়, পরিষ্কার অনুরোধে বলুন: কোন যন্ত্র, কী দেখেছি, কী করতে হবে, কখনের মধ্যে, আর না করলে কী ঝুঁকি।

নেতৃত্ব জানতে চান তিনটি কথা: কী হয়েছে, ব্যবসায় কী প্রভাব, আর তাঁদের কাছ থেকে কোন সিদ্ধান্ত দরকার। TTP আর hash তাঁদের কাজে লাগে না। একটি উদাহরণ দেখুন:

রাত ২টায় finance বিভাগের একটি email account দখল হয়েছিল।
৩৮ মিনিটে তা বন্ধ করা হয়েছে। লেনদেন বা গ্রাহকের ডেটায় এখন পর্যন্ত
প্রভাবের প্রমাণ পাইনি, যাচাই চলছে। সকাল ১১টায় পরবর্তী আপডেট।
আপনার সিদ্ধান্ত দরকার: অচেনা যন্ত্রে login কঠোর করার অনুমোদন।

“এখন পর্যন্ত” আর “যাচাই চলছে” শব্দগুলো লক্ষ্য করুন। যা জানেন না, তা নিশ্চিত করে বলবেন না। পরে শোধরানো কঠিন।

৯ · বাংলাদেশে SOC ক্যারিয়ার আর ছোট প্রস্তুতি

SOC অনেকের নিরাপত্তা-ক্যারিয়ারের প্রথম দরজা, কারণ এখানে নানা ধরনের সিস্টেম একসাথে দেখা যায়। সাধারণভাবে ব্যাংক, আর্থিক সেবা, টেলিকম, বড় সফটওয়্যার প্রতিষ্ঠান, সরকারি সংস্থা আর নিরাপত্তা-সেবাদাতা প্রতিষ্ঠান এমন দক্ষতা খোঁজে। চাহিদা, পদের নাম আর শর্ত সময় ভেদে বদলায়, তাই নিজের চোখে সাম্প্রতিক বিজ্ঞপ্তি পড়ুন।

যাঁরা helpdesk, system বা network administration, অথবা সফটওয়্যারে কাজ করেন, তাঁদের অভিজ্ঞতা এখানে খুব কাজে লাগে। Certification সহায়ক হতে পারে, তবে কোনটি উপযোগী তা চাকরির বিজ্ঞপ্তি দেখে ঠিক করুন, আর ক্রয়ের আগে নিজে যাচাই করুন। কোনো certificate হাতে-কলমে দক্ষতার বিকল্প নয়।

ইন্টারভিউয়ের জন্য পরিস্থিতিভিত্তিক অনুশীলন পর্ব ৭৯-তে পাবেন।

১০ · AI-এর যুগে SOC

AI লম্বা log সংক্ষেপ করতে, query-র খসড়া বানাতে আর note-এর ভাষা ঠিক করতে ভালো সহকারী। কিন্তু সে আপনার পরিবেশ জানে না, আর ভুল বলেও আত্মবিশ্বাসী শোনায়। Verdict তাই মানুষের সই ছাড়া চূড়ান্ত নয়।

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

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