IDS আর IPS — signature, anomaly আর false positive

১ · পাহারাদার আর গেটের দারোয়ান — IDS বনাম IPS

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

IDS (intrusion detection system) হলো পাহারাদার। এটি traffic বা host-এর কাজ দেখে, সন্দেহ হলে alert দেয়। IPS (intrusion prevention system) হলো দারোয়ান। এটি traffic-এর পথে বসে, আর নিয়ম মিললে packet বা connection আটকায়। NIST SP 800-94 (২০০৭) দুটিকে একসাথে IDPS বলে, কারণ অনেক পণ্য একই engine-এ দুই ভূমিকাই পালন করে। ফারাকটি তখন নির্ভর করে যন্ত্রটি কোথায় বসানো আর কীভাবে সাজানো তার ওপর।

Firewall থাকলে আবার IDS কেন

পর্ব ২১-এ network-এর ঝুঁকিগুলো দেখেছেন। পর্ব ২২ (Firewall আর segmentation) দেখিয়েছে, firewall মূলত ঠিক করে কোন ঠিকানা আর port থেকে কোন traffic যাবে। ধরুন মার্কেটের প্রধান ফটকে নিয়ম আছে, “দোকানের কর্মচারী ঢুকতে পারবেন।” Firewall সেই পরিচয়পত্র দেখে। কিন্তু অনুমোদিত দরজা দিয়ে আসা মানুষটি ভেতরে কী করছে, সে প্রশ্ন IDS-এর। Port 443 খোলা থাকতেই হবে, কিন্তু সেই পথে অস্বাভাবিক কিছু চলছে কি না, তা দেখার জন্য আলাদা চোখ লাগে।

কোথা থেকে দেখছে: network, host আর তাদের ফাঁক

এই দুটি প্রতিযোগী নয়, একে অপরের ফাঁক ঢাকে। Wazuh বা OSSEC-এর মতো টুল HIDS-এর পরিচিত উদাহরণ। আধুনিক EDR এই ধারণাকে আরও এগিয়ে নিয়েছে (পর্ব ৫৯)। Network-এর দিকে একই বিবর্তনের নাম NDR, যা metadata আর আচরণে বেশি জোর দেয়। মূলনীতিটি আসে পর্ব ৩-এর defense in depth থেকে। আর পর্ব ২-এ আপনি detective control হিসেবে এগুলোর জায়গা দেখেছেন।

২ · কোথায় বসাবেন — TAP, SPAN আর inline

একটি sensor শুধু সেই traffic-ই বিশ্লেষণ করতে পারে, যা তার কাছে পৌঁছায়। তাই placement প্রথম নকশার সিদ্ধান্ত। তিনটি পরিচিত পদ্ধতি আছে। প্রথম দুটিতে sensor শুধু কপি দেখে, তৃতীয়টিতে আসল traffic তার ভেতর দিয়ে যায়।

দারোয়ান অজ্ঞান হলে গেট খোলা, না বন্ধ?

Inline যন্ত্র নষ্ট হলে দুটি পথ। পর্ব ৩-এর ভাষায় fail open মানে traffic যাচাই ছাড়াই যেতে দেওয়া। আর fail closed মানে সব আটকে দেওয়া। কোনটি “সঠিক”, তার সার্বজনীন উত্তর নেই। প্রশ্নটি হলো, এই পথে কোন ক্ষতি বেশি: কিছুক্ষণ না-দেখা, না কি কিছুক্ষণ বন্ধ থাকা?

একটি যন্ত্রের ভেতরেও এই সিদ্ধান্ত থাকে। Suricata-র documentation অনুযায়ী IPS mode-এ memory সীমা ফুরিয়ে গেলে কী হবে, তা exception policy দিয়ে ঠিক করা যায়, আর পুরোনো ও নতুন version-এ default আলাদা হতে পারে। তাই আপনার version-এর documentation পড়ে আসল আচরণ পরীক্ষা করুন।

৩ · Signature detection — জানা ছাপ মেলানো

থানার দেয়ালে পরিচিত পকেটমারের ছবি থাকলে পুলিশ ভিড়ে তাকে চিনতে পারে। Signature detection এভাবেই কাজ করে। আগে থেকে জানা একটি নকশা লেখা থাকে। Traffic বা log সেই নকশার সাথে মিললেই alert. সুবিধা দুটি: দ্রুত, আর alert হলে কারণটি স্পষ্ট বলা যায়। একটি লেখা detection rule-এই সব কথা থাকে। আর বহু rule মিলে হয় ruleset, যা নিয়মিত হালনাগাদ করতে হয়।

একটি নিরীহ rule পড়া

নিচের উদাহরণটি হামলা নয়, একটি প্রতিষ্ঠানের নীতি দেখে। ধরুন একটি কাল্পনিক অনলাইন বাজারের নীতি হলো, অফিসের কম্পিউটার থেকে অননুমোদিত file-sharing সাইটে যাওয়া চলবে না।

alert tls $HOME_NET any -> $EXTERNAL_NET any ( \
  msg:"POLICY unapproved file-sharing host"; \
  flow:established,to_server; \
  tls.sni; content:"files.example.com"; nocase; \
  isdataat:!1,relative; \
  classtype:policy-violation; \
  sid:1000023; rev:1;)

এই rule-টি উদাহরণ, কিছু আটকায় না। শব্দভান্ডার Suricata-র ধাঁচের, Snort-এর ভাষা কাছাকাছি হলেও পুরোপুরি এক নয়। আপনার version-এ চালানোর আগে documentation দেখে নিন, আর শুধু নিজের lab-এ পরীক্ষা করুন। এখন একই ধারণা ছোট করে কোডে দেখি। নিচের matcher কোনো আসল network ছোঁয় না, শুধু কয়েকটি বানানো log লাইন পড়ে। প্রতিটি লাইনে আগে থেকে লেখা আছে সেটি আসলে ধরার মতো কি না।

// Toy signature matcher on fixed, harmless log lines. Nothing here touches a network.
const LOG = [
  { line: 'GET /index.html host=shop.example.com', bad: false },
  { line: 'GET /docs/admin-guide.pdf host=shop.example.com', bad: false },
  { line: 'GET /admin host=shop.example.com src=203.0.113.9', bad: true },
  { line: 'TLS sni=files.example.com src=198.51.100.21', bad: true },
  { line: 'TLS sni=newfiles.example.net src=198.51.100.22', bad: true },
  { line: 'TELNET src=198.51.100.30 dst=198.51.100.5 port=23', bad: true },
  { line: 'SSH src=198.51.100.31 dst=198.51.100.5 port=22', bad: false },
];
const rulesV1 = [
  { sid: 1, msg: 'admin path requested', test: s => s.includes('/admin') },
  { sid: 2, msg: 'unapproved file host', test: s => s.includes('sni=files.example.com') },
  { sid: 3, msg: 'cleartext telnet', test: s => s.includes('port=23') },
];
const rulesV2 = rulesV1.map(r => r.sid !== 1 ? r :
  { ...r, test: s => /^GET \/admin( |$)/.test(s) });  // exact path, not a substring

function scan(name, rules) {
  let tp = 0, fp = 0, fn = 0;
  console.log(`--- ${name}`);
  for (const { line, bad } of LOG) {
    const hit = rules.find(r => r.test(line));
    if (hit && bad) tp++;
    if (hit && !bad) { fp++; console.log(`FP   sid ${hit.sid}: ${line}`); }
    if (!hit && bad) { fn++; console.log(`MISS       ${line}`); }
  }
  console.log(`TP ${tp}  FP ${fp}  missed ${fn}`);
}
scan('rules v1 (substring)', rulesV1);
scan('rules v2 (exact path)', rulesV2);

Signature-এর সীমা

• শুধু জানা জিনিস: নতুন zero-day বা নতুন কৌশলের signature আগে থেকে থাকে না। কেউ আগে দেখেছেন, লিখেছেন, তারপর আপনি পেয়েছেন।
• চিহ্ন বদলায়: পর্ব ৫-এর pyramid of pain মনে করুন। IP বা hash বদলানো সহজ। তাই আচরণের ওপর লেখা rule বেশি টেকে।
• Rule বাড়লে খরচ বাড়ে: প্রতিটি rule CPU খায়। পুরোনো rule না ছাঁটলে sensor ধীর হয়, আর চাপের সময় packet বাদ পড়তে পারে।
• এনক্রিপশন: Payload-এর ভেতরের লেখা খুঁজতে হলে তা পড়তে পারতে হবে (অংশ ৬)।

৪ · Anomaly আর behaviour detection — স্বাভাবিকের সাথে তুলনা

মহল্লার চায়ের দোকানদার সবাইকে চেনেন। কেউ রাত তিনটায় একটি বন্ধ দোকানের সামনে পায়চারি করলে তাঁর কোনো ছবি মেলানোর দরকার হয় না। তিনি চেনা ছন্দটি জানেন, তাই বেমানান জিনিস চোখে পড়ে। Anomaly detection-এর ধারণা এটাই। প্রথমে baseline বানানো হয়, অর্থাৎ স্বাভাবিক সময়ের মাপ। তারপর তার থেকে বেশি সরে গেলে সতর্ক করা হয়।

সবচেয়ে সহজ পদ্ধতিটি পরিসংখ্যানের। শেষ কয়েকটি মানের গড় m আর standard deviation s বের করুন। নতুন মান x কতটা দূরে আছে, তা মাপে z-score:

নিচের খেলনায় প্রতি মিনিটের request গণনা আছে, আর t=12-এ একটি spike. ধরনটি লক্ষ করুন: একই ডেটায় baseline দুইভাবে শেখানো হচ্ছে। একবার সবকিছু শিখছে, আরেকবার flagged মান বাদ দিচ্ছে।

// Rolling mean and standard deviation on a toy series of requests per minute.
const SERIES = [100, 104, 98, 101, 97, 103, 99, 102, 100, 96, 105, 101,
                340, 103, 98, 104, 100, 102, 97, 101];  // one spike at t=12
const WINDOW = 8, LIMIT = 3, FLOOR = 2;   // FLOOR: smallest sd we accept

const stats = a => {
  const m = a.reduce((s, x) => s + x, 0) / a.length;
  const sd = Math.sqrt(a.reduce((s, x) => s + (x - m) ** 2, 0) / a.length);
  return { m, sd };
};
function detect(guarded) {
  const base = SERIES.slice(0, WINDOW);
  for (let t = WINDOW; t < SERIES.length; t++) {
    const { m, sd } = stats(base.slice(-WINDOW));
    const z = (SERIES[t] - m) / Math.max(sd, FLOOR);
    const hit = Math.abs(z) > LIMIT;
    const alarmAt = m + LIMIT * Math.max(sd, FLOOR);
    if (hit || t === 15) console.log(
      `t=${t} value=${SERIES[t]} mean=${m.toFixed(1)} sd=${sd.toFixed(1)} ` +
      `z=${z.toFixed(1)} alarm above ${alarmAt.toFixed(0)}` + (hit ? '  ALERT' : ''));
    if (!(guarded && hit)) base.push(SERIES[t]);  // guarded: flagged point stays out
  }
}
console.log('--- baseline learns everything, spike included');
detect(false);
console.log('--- baseline skips flagged points');
detect(true);

আচরণভিত্তিক detection

“অস্বাভাবিক সংখ্যা” ধরা এক জিনিস, আর একটি সন্দেহজনক ধরন ধরা আরেক জিনিস। Behavioural detection-এ বলা হয়, “একটি অফিসের কম্পিউটার অল্প সময়ে অনেকগুলো অভ্যন্তরীণ server-এ নতুন connection খুলছে।” এখানে কোনো নির্দিষ্ট ফাইল বা ঠিকানা লাগে না। এটি lateral movement-এর মতো কাজের ইঙ্গিত দিতে পারে, আবার নতুন inventory tool-ও হতে পারে। তাই context ছাড়া এটি শুধু একটি ইঙ্গিত।

Anomaly-এর তিনটি ফাঁদ

• স্বাভাবিক বদলায়: ঈদের সেলের সন্ধ্যায় বা বেতনের দিনে traffic কয়েকগুণ হয়। একে concept drift বলে, আর দিন-সময় অনুযায়ী আলাদা baseline এর একটি সমাধান।
• Baseline নিজেই দূষিত হতে পারে: শেখার সময় যদি সমস্যা চলছিল, তবে সেটিই “স্বাভাবিক” হয়ে যায়। কোডে আপনি তার ছোট রূপ দেখলেন।
• অস্বাভাবিক মানেই ক্ষতিকর নয়: বড় backup, নতুন release বা ভুল config, সবই বেমানান দেখায়। আর সতর্কভাবে চলা ক্ষতিকর কাজ বেমানান না-ও দেখাতে পারে।

৫ · Suricata, Snort আর Zeek — আর একটি alert-এর যাত্রা

তিনটি উন্মুক্ত উৎসের টুল এই জগতে খুব পরিচিত। এগুলো উদাহরণ মাত্র। আপনার প্রতিষ্ঠানের জন্য কোনটি ঠিক, তা দল, ডেটার পরিমাণ আর SIEM-এর ওপর নির্ভর করে। বাণিজ্যিক পণ্যেও একই ধারণা পাবেন।

সহজ করে বললে, rule engine প্রশ্ন করে “এই নিয়ম মিলল কি?” আর Zeek লিখে রাখে “network-এ কী কী ঘটল।” অনেক দল দুটি পাশাপাশি চালায়, কারণ alert পেলে তদন্তে পাশের log-টিই কাজে লাগে। এবার একটি alert শুরু থেকে শেষ পর্যন্ত দেখুন। সব ঠিকানা কাল্পনিক, আর sensor নিজের network-এই বসানো।

10:42:07  198.51.100.21:51544 → 203.0.113.80:443
          TCP handshake শেষ, ClientHello আসছে
sensor দেখছে কপি; আসল packet নিজের পথেই গেছে

flow:     established, to_server
app_proto: tls
sni:      files.example.com
ভেতরের ডেটা এনক্রিপ্টেড, এই নামটি ClientHello-তে খোলা

$HOME_NET -> $EXTERNAL_NET   মিলল
flow:established,to_server   মিলল
tls.sni = files.example.com  মিলল
action: alert  (block নয়)

{"event_type":"alert",
 "src_ip":"198.51.100.21",
 "dest_port":443,
 "app_proto":"tls",
 "alert":{"action":"allowed",
  "signature_id":1000023,
  "signature":
   "POLICY unapproved
    file-sharing host"},
 "tls":{
  "sni":"files.example.com"}}

host:      fin-laptop-07   (হিসাব বিভাগ)
owner:     কাল্পনিক কর্মী, ডেটা সংবেদনশীল
history:   এই rule-এ গত ৩০ দিনে ০টি alert
priority:  medium → high

দেখা হলো: flow-এর আকার, সময়, সংশ্লিষ্ট log
কর্মীর সাথে কথা: বড় ফাইল পাঠানোর দরকার ছিল
রায়: true positive, নীতি ভাঙা; ক্ষতিকর নয়
সাড়া: অনুমোদিত উপায় দেখানো, ticket বন্ধ

৬ · Encrypted traffic — খামের ভেতর নয়, খামের বাইরে যা দেখা যায়

পোস্ট অফিসের কর্মী বন্ধ খামের ভেতরের চিঠি পড়তে পারেন না। কিন্তু তিনি দেখতে পান খামটি কোথা থেকে কোথায় যাচ্ছে, কত ভারী, আর একই ঠিকানায় প্রতিদিন কতগুলো যায়। TLS-এর পরে IDS-এর অবস্থাও তাই। TLS কীভাবে কাজ করে, তা পর্ব ১২-এ দেখেছেন। এখানে প্রশ্ন শুধু একটি: sensor এখন কী দেখে?

Flow data আর fingerprint

Flow data হলো প্রতিটি connection-এর সারাংশ। NetFlow বা IPFIX-এর মতো ফরম্যাটে router নিজেই এটি দিতে পারে। এতে সব packet রাখার দরকার পড়ে না, ফলে অনেক দিনের ইতিহাস কম খরচে রাখা যায়। ধরনে নজর দিন: একটি যন্ত্র কি প্রতি ৬০ সেকেন্ডে ঠিক একই আকারের ছোট connection খুলছে? নাকি রাত দুটোয় বাইরে অনেক বেশি ডেটা পাঠাচ্ছে? এসবই প্রশ্ন, প্রমাণ নয়।

JA3 (Salesforce-এর গবেষকদের, ২০১৭) আর JA4 (FoxIO, ২০২৩) হলো TLS client-এর fingerprint. ClientHello-র কিছু ঘর, যেমন version, cipher suite আর extension, মিলিয়ে একটি ছোট চিহ্ন বানানো হয়। হাতের লেখা চেনার মতো: কে লিখেছে জানা যায় না, শুধু লেখার ধরনটি চেনা যায়।

• এটি পরিচয় নয়: একই browser version-এর লাখো মানুষের fingerprint একই হতে পারে। তাই একা এটি দিয়ে সিদ্ধান্ত নেবেন না।
• এটি বদলায়: Browser হালনাগাদ হলে চিহ্নও বদলাতে পারে। Chrome TLS extension-এর ক্রম এলোমেলো করা শুরু করলে JA3-এর স্থিরতা কমে যায়। JA4 ক্রম সাজিয়ে হিসাব করে এই সমস্যা কমায়।
• ভালো ব্যবহার: “এই server-এ সাধারণত কোন client আসে” তা জানা, আর নতুন কিছু দেখলে আরও প্রমাণ খোঁজা। লাইসেন্স আর সমর্থন টুলভেদে আলাদা, তাই আপনার টুলের documentation দেখুন।

তাহলে কি TLS খুলে দেখবেন?

TLS inspection-এ প্রতিষ্ঠানের যন্ত্র মাঝখানে বসে traffic খুলে দেখে। এতে দৃষ্টি বাড়ে, কিন্তু দাম আছে: কর্মীদের ব্যক্তিগত ডেটা, নতুন বিশ্বাসের বিন্দু, আর ভুল সাজালে TLS-ই দুর্বল হওয়া। তাই বহু জায়গায় ভারসাম্য হলো, শুধু দরকারি পথে এটি করা, ব্যাংক বা স্বাস্থ্যের মতো সাইট বাদ রাখা, লিখিত নীতি রাখা, আর বাকি দৃষ্টি endpoint ও application log থেকে নেওয়া। যন্ত্রের ভেতরে এনক্রিপশন খোলা অবস্থায় দেখার সুবিধাই HIDS আর EDR-এর বড় শক্তি।

৭ · Confusion matrix, precision, recall আর base-rate fallacy

ধরুন এক বিক্রেতা বললেন, “আমাদের detector ৯৯% সঠিক।” কিনবেন? এই অংশের পরে আপনি জানবেন, ঠিক কোন প্রশ্নটি করতে হবে। প্রথমে ফলাফলগুলোর নাম দরকার। প্রতিটি ঘটনার দুটি সত্য আছে: আসলে কী ছিল, আর detector কী বলল। চার ঘরের এই ছকটিকে confusion matrix বলে।

কথায় বললে, precision জিজ্ঞেস করে, “যত alert হলো, তার কতগুলো আসল?” Recall জিজ্ঞেস করে, “যত আসল ঘটনা ঘটল, তার কতগুলো ধরা পড়ল?” False positive rate জিজ্ঞেস করে, “নিরীহ ঘটনার কত অংশে ভুল alert হলো?” আর দুটিকে একসাথে মাপতে F1 score = 2 × precision × recall ÷ (precision + recall) ব্যবহার হয়। Accuracy নিয়ে সাবধান: ক্ষতিকর ঘটনা বিরল হলে এই সংখ্যা প্রায় কিছুই বলে না।

৯৯% সঠিক detector-এর আসল হিসাব

একটি কাল্পনিক network-এ দিনে ১০ লক্ষ ঘটনা ঘটে। এর মধ্যে ১০০টি আসলেই ক্ষতিকর, অর্থাৎ prevalence ০.০১%. Detector-এর recall ৯৯%, আর false positive rate ১%. “৯৯% সঠিক” কথাটির এটিই একটি স্বাভাবিক অর্থ। ধাপে ধাপে হিসাব করুন।

একই হিসাব Bayes-এর সূত্রেও আসে, যা লিখিত পরীক্ষায় কাজে লাগে:

এখন মানুষের খরচ ধরি। প্রতি alert-এ ৫ মিনিট ধরলে ১০,০৯৮ × ৫ = ৫০,৪৯০ মিনিট, অর্থাৎ প্রায় ৮৪১.৫ ঘণ্টা। ৮ ঘণ্টার shift-এ দিনে প্রায় ১০৫ জন analyst লাগত, শুধু ৯৯টি আসল ঘটনার জন্য। সংখ্যাগুলো অনুমান, কিন্তু ফলটি সতর্ক করার মতো। এবার calculator-এ prevalence আর false positive rate বদলে দেখুন।

// Base-rate calculator: 1,000,000 events a day. All numbers are assumptions.
const EVENTS = 1000000;
function run(prevalence, recall, fpr) {
  const bad = EVENTS * prevalence, good = EVENTS - bad;
  const tp = bad * recall, fn = bad - tp;
  const fp = good * fpr, tn = good - fp;
  return { tp, fp, fn, alerts: tp + fp,
    precision: tp / (tp + fp), accuracy: (tp + tn) / EVENTS };
}
const row = (a, r) => console.log(
  a.padEnd(10) + String(Math.round(r.tp)).padStart(7) +
  String(Math.round(r.fp)).padStart(8) +
  (r.precision * 100).toFixed(2).padStart(9) + '%' +
  (r.accuracy * 100).toFixed(2).padStart(8) + '%');
const head = n => console.log(n.padEnd(10) + '     TP      FP precision accuracy');

console.log('--- recall 99%, false positive rate 1%, prevalence changes');
head('prevalence');
for (const p of [0.1, 0.01, 0.001, 0.0001, 0.00001])
  row((p * 100) + '%', run(p, 0.99, 0.01));

console.log('--- prevalence 0.01%, recall 99%, false positive rate changes');
head('FP rate');
for (const f of [0.01, 0.001, 0.0001, 0.00001])
  row((f * 100) + '%', run(0.0001, 0.99, f));

const lazy = run(0.0001, 0, 0);
console.log('--- detector that never alerts');
console.log(`accuracy ${(lazy.accuracy * 100).toFixed(2)}%, real events caught ${lazy.tp}`);

৮ · Alert fatigue, tuning আর অন্ধ জায়গা ছাড়া suppression

রাখাল বালকের গল্পটি নিরাপত্তা দলের খুব চেনা। প্রতিদিন ভুল বাঁশি বাজলে, আসল বিপদের দিন কেউ আর দৌড়ায় না। একে alert fatigue বলে। এটি অলসতা নয়, এটি নকশার ফল। মানুষ এমন সিস্টেমে মনোযোগ ধরে রাখতে পারে না, যা বেশিরভাগ সময় ভুল বলে।

২০১৩ সালের Target breach নিয়ে মার্কিন সিনেট কমিটির কর্মীদের ২০১৪ সালের রিপোর্ট সংবাদমাধ্যমের তথ্যের ভিত্তিতে জানায়, malware-প্রতিরোধী যন্ত্র alert দিয়েছিল, কিন্তু নিরাপত্তা দল সেগুলোর ওপর ব্যবস্থা নিয়েছে বলে মনে হয় না। কারণ বাইরে থেকে নিশ্চিত বলা যায় না। তবে শিক্ষা পরিষ্কার: detection ঘটলেই সুরক্ষা ঘটে না। Alert থেকে সিদ্ধান্ত পর্যন্ত পুরো শিকলটি কাজ করতে হবে।

Tuning মানে আসল ঘটনা ধরার ক্ষমতা ধরে রেখে ভুল alert কমানো। নিচে একটি কাল্পনিক rule, যা গত সপ্তাহে ১,২০০টি alert দিয়েছে। ধরা যাক সবগুলো পর্যালোচনা করে ৬টি আসল পাওয়া গেছে। সিদ্ধান্তটি দেখুন।

Threshold-এর দাম

অনেক detector একটি score দেয়, আর আপনি ঠিক করেন কোন সীমার ওপরে alert হবে। সীমা নামালে কম ঘটনা ছুটে যায়, কিন্তু ভুল alert বাড়ে। উঠালে উল্টো। নিচে ২,০০০টি বানানো ঘটনা আছে, যার ২০টি আসল। Seed স্থির, তাই ফল প্রতিবার একই। ধরা হয়েছে প্রতি alert-এ ৫ মিনিট লাগে।

// Threshold tuning on 2,000 simulated events. Seeded PRNG, so every run is 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 rnd = mulberry32(23);
const events = [];
for (let i = 0; i < 1980; i++) events.push({ score: rnd() * 40 + rnd() * 40, bad: false });
for (let i = 0; i < 20; i++)   events.push({ score: 45 + rnd() * 50, bad: true });

const MINUTES_PER_ALERT = 5;
console.log('limit alerts  FP  missed precision recall review');
for (const limit of [40, 50, 60, 65, 70, 75, 80, 90]) {
  const hits = events.filter(e => e.score >= limit);
  const tp = hits.filter(e => e.bad).length;
  const fp = hits.length - tp, missed = 20 - tp;
  const precision = hits.length ? (tp / hits.length * 100).toFixed(1) : '-';
  const recall = (tp / 20 * 100).toFixed(0);
  const hours = (hits.length * MINUTES_PER_ALERT / 60).toFixed(1);
  console.log(String(limit).padStart(5) + String(hits.length).padStart(7) +
    String(fp).padStart(4) + String(missed).padStart(8) +
    (precision + '%').padStart(10) + (recall + '%').padStart(7) +
    (hours + 'h').padStart(7));
}

অন্ধ জায়গা না বানিয়ে suppression

Suppression হলো নির্দিষ্ট শর্তে alert দেখানো বন্ধ রাখা। নিচের উদাহরণ Suricata-র threshold.config-এর ধাঁচের। এটি শুধু এই sid আর এই host-এর জন্য:

# owner: netops-team  ticket: SEC-1042  review by: 2027-02-01
# reason: nightly backup to approved host
suppress gen_id 1, sig_id 1000031, track by_src, ip 198.51.100.10

দুটি জিনিস খেয়াল করুন। Suricata-র documentation-এ দেখানো syntax-এ মেয়াদের ঘর নেই, তাই মেয়াদ রাখতে হয় মন্তব্য আর ticket-এ, আর কোনো মানুষ বা script-কে তা যাচাই করতে হয়। আর track by_src পুরো host-কে এই rule থেকে সরায়, যা ওপরের stepper-এর ধাপ ৪-এর ঝুঁকি। জোড়া-ভিত্তিক নিয়ম দরকার হলে rule-এর শর্ত বদলানো বা SIEM-এ alert নিয়ন্ত্রণ করা বেশি সরু হতে পারে।

৯ · ধরা এড়ানোর চেষ্টা, defence in depth আর SIEM

একটি কথা সৎভাবে মেনে নিন: আক্রমণকারীরা ধরা পড়তে চায় না, আর তারা detection এড়ানোর চেষ্টা করে। কোনো একটি sensor সব কিছু দেখে না। কৌশলের বিস্তারিত এই কোর্সের বিষয় নয়, আর রক্ষকের দরকারও নেই। রক্ষকের উত্তরটি একই থাকে: একটি স্তরের ওপর ভরসা না করা। Network নিরাপত্তার ভিত্তি থেকেই এই ধারণা শুরু।

• স্তর: Network sensor, endpoint telemetry, application log, identity log আর honeypot. একটি ফাঁকি দিলেও অন্যটিতে চিহ্ন থাকতে পারে।
• প্রতিরোধ আগে: Segmentation, patch, MFA আর least privilege এমন ঘটনাই কমায়, যা ধরতে হতো।
• Coverage মাপা: পর্ব ৫-এর মতো detection coverage মানচিত্র বানান, যাতে detection gap জানা থাকে।
• Sensor-এর স্বাস্থ্য: নীরব sensor আর শান্ত network দেখতে একই। তাই packet drop, CPU, certificate মেয়াদ আর “শেষ event কখন এলো” মাপুন। নিজের lab বা অনুমোদিত সময়ে একটি নিরীহ পরীক্ষামূলক event পাঠিয়ে পুরো পথ যাচাই করুন।

Alert যায় SIEM-এ

একটি sensor-এর alert একা কম কথা বলে। SIEM-এ গিয়ে সেটি অন্য log-এর সাথে মেলে। প্রথমে সব উৎসের ক্ষেত্রকে একই নামে আনা হয়, যেমন src_ip. তারপর একই ঘটনার পুনরাবৃত্তি এক করা, asset-এর গুরুত্ব যোগ করা, আর অন্য উৎসের সাথে সম্পর্ক খোঁজা হয়। ধরুন IDS একটি সন্দেহজনক connection দেখল, আর কয়েক মিনিট পরে একই যন্ত্রে নতুন admin account তৈরি হলো। আলাদাভাবে দুটিই সাধারণ alert, একসাথে অনেক গুরুতর। এই কাজের নিয়ম লেখা, Sigma আর correlation পর্ব ৫৬ (SIEM আর detection rule)-এ আসবে। Log সংগ্রহের অবকাঠামো দেখতে centralized logging পড়তে পারেন।

১০ · AI-এর যুগে IDS আর IPS

AI একটি জটিল rule-কে সহজ ভাষায় বুঝিয়ে দিতে, alert-এর সারাংশ লিখতে, বা log-এ ধরন খুঁজতে ভালো সাহায্য করে। কিন্তু রায় দেওয়ার কাজটি তার হাতে ছেড়ে দিলে বিপদ। AI যা আত্মবিশ্বাস নিয়ে বলে, সেটি যাচাই করা analyst-এর আসল কাজ।

AI-এর পরামর্শ কাজে লাগানোর আগে

• Rule বা keyword আসল documentation-এ মিলিয়ে দেখেছি
• Rule বা suppression নিজের lab-এ আর পুরোনো ডেটায় পরীক্ষা করেছি
• AI-কে কোনো secret, আসল IP বা গ্রাহকের ডেটা দিইনি
• AI-এর দেওয়া CVE বা standard উৎসে গিয়ে পড়েছি
• মানুষকে প্রভাবিত করে এমন সিদ্ধান্ত, যেমন কর্মীর বিরুদ্ধে অভিযোগ, একজন মানুষ নিয়েছেন