SIEM আর detection rule — Sigma, correlation আর false positive কমানো

১ · অফিসের রেজিস্টার খাতা থেকে কন্ট্রোল রুম

একটি বড় মার্কেট ভাবুন। গেটের দারোয়ানের খাতা আছে, লকার রুমের আলাদা খাতা, হিসাব বিভাগের আলাদা রেকর্ড, আর CCTV-র ফুটেজ। প্রতিটি খাতায় সত্য লেখা আছে। কিন্তু রাত দুইটায় একজন গেট দিয়ে ঢুকল, পাঁচবার ভুল চাবি দিল, তারপর লকার খুলল, এই গল্পটি কোনো এক খাতায় নেই। গল্পটি পেতে হলে সব খাতা এক টেবিলে এনে সময় ধরে মেলাতে হয়। কন্ট্রোল রুম ঠিক এটাই করে।

SIEM (Security Information and Event Management) নিরাপত্তার সেই কন্ট্রোল রুম। নামটি Gartner-এর বিশ্লেষকদের ২০০৫ সালের দিকের লেখা থেকে ছড়ায় বলে সাধারণত ধরা হয়। পর্ব ৫৫-এ আপনি জেনেছেন কোন log রাখতে হয়। এই পর্বের প্রশ্ন হলো, সেই log থেকে কাজের সতর্কতা কীভাবে বের হবে। Sensor-এর দিক থেকে পর্ব ২৩ একই গল্প বলেছে।

কোন টুল?

উন্মুক্ত আর বাণিজ্যিক দুই ধরনের পণ্যই আছে। নিচের নামগুলো পরিচিত উদাহরণ, কোনো সুপারিশ নয়। Feature আর দাম সময়ের সাথে বদলায়, তাই নিজের ডেটার পরিমাণ, দলের দক্ষতা আর আইনি চাহিদা দেখে যাচাই করে নিন।

২ · Raw log থেকে alert — normalise আর enrich

নানা ভাষার মানুষ এক ঘরে কথা বললে একজন দোভাষী লাগে। Log-এর অবস্থাও তাই। একটি উৎস লেখে src, আরেকটি clientIP, তৃতীয়টি IpAddress. Parsing লেখা থেকে ঘর আলাদা করে। Normalisation সেই ঘরগুলোকে একটি common schema-য় আনে। Elastic Common Schema (ECS), Microsoft-এর ASIM, Splunk-এর CIM আর উন্মুক্ত OCSF এই চেষ্টারই উদাহরণ। সবার নকশা আলাদা, তাই এক schema-র rule অন্যটিতে সরাসরি না-ও চলতে পারে।

নিচের stepper একটি মাত্র log লাইন অনুসরণ করে। পরিবেশটি কাল্পনিক: একটি অনলাইন বাজারের নিজের server web1.

Oct 31 10:02:12 web1 sshd[820]: Failed password
for sadia from 203.0.113.7 port 40120 ssh2

time    = Oct 31 10:02:12
host    = web1
process = sshd
result  = Failed password
account = sadia
from    = 203.0.113.7

{
  "event_time": "2026-10-31T04:02:12Z",
  "event_category": "authentication",
  "outcome": "failure",
  "user": "sadia",
  "src_ip": "203.0.113.7",
  "host": "web1",
  "app": "sshd"
}

host_owner    payments-team
host_crit     high
internet      true
user_dept     finance
privileged    false
mfa           false
src_internal  false

10:02:01-10:02:12
failure × 6  (limit 5 in 5m)
10:02:15
success  user=sadia
rule matched: failed logons then success

title:    Failed logons then success
severity: high
entity:   user=sadia host=web1
why:      6 failures, then success, no MFA
owner:    payments-team
runbook:  RB-017

Context কেন নিয়ম বদলে দেয়

একই ঘটনা ভিন্ন প্রসঙ্গে ভিন্ন অর্থ বহন করে। রাত তিনটায় ব্যাংকের লকার রুমে ঢোকা আর দুপুরে ঢোকা এক কথা নয়। একই ভাবে, asset inventory আর identity তথ্য alert-কে ওপরে বা নিচে নামাতে পারে।

Enrichment সঠিক থাকলেই কাজে লাগে। পুরোনো asset তালিকা ভুল আত্মবিশ্বাস দেয়। আরেকটি বিষয়, যে সময় ঘটনা ঘটেছে সেই সময়ের তথ্য জুড়তে হয়। DHCP-তে একটি IP আজ এক যন্ত্রের, কাল আরেকটির হতে পারে। Threat intelligence-এর ব্যবহার পর্ব ৫৭-তে আসবে।

খোঁজার দুটি উদাহরণ

একই প্রশ্ন, দুই ভাষায়: “গত ১ দিনে কোন উৎস থেকে সবচেয়ে বেশি ব্যর্থ login?” টেবিল ও field-এর নাম কাল্পনিক, আর এই query কোনো আসল SIEM-এ চালানো হয়নি। ধরন বোঝার জন্য দেখুন।

index=auth action=failure earliest=-1d
| stats count AS failures dc(user) AS users BY src_ip
| sort - failures
| head 10

auth_events
| where timestamp > ago(1d) and outcome == "failure"
| summarize failures = count(), users = dcount(user) by src_ip
| top 10 by failures desc

৩ · Detection লেখা শুরু হয় আচরণ থেকে

পাড়ায় চুরি ঠেকাতে একজন চোরের ছবি টাঙানো সহজ। কিন্তু সে মাথা কামিয়ে এলে ছবি কাজ করে না। তার চেয়ে টেকসই নিয়ম হলো, “রাতে কেউ বন্ধ দোকানের তালায় হাত দিলে বাঁশি।” পর্ব ৫-এর pyramid of pain-এর কথাও এটাই। IP বা hash বদলানো সহজ, কাজের ধরন বদলানো কঠিন। তাই ভালো detection engineering শুরু হয় আচরণ থেকে, পণ্য বা IP তালিকা থেকে নয়।

1. প্রশ্ন: কোন ক্ষতি নিয়ে চিন্তিত? পর্ব ৪-এর threat model বা আগের ঘটনা থেকে শুরু করুন।
2. আচরণ: এক বাক্যে লিখুন। যেমন, “একটি উৎস অনেকবার login-এ ব্যর্থ হয়ে তারপর সফল হলো।”
3. Technique: MITRE ATT&CK-এ মেলান। এই আচরণের কাছাকাছি হলো T1110 (Brute Force), যার tactic Credential Access. T1110.001 Password Guessing, T1110.003 Password Spraying আর T1110.004 Credential Stuffing এর sub-technique. সংখ্যা পরে বদলাতে পারে, তাই attack.mitre.org-এ মিলিয়ে নিন।
4. Log: কোন log-এ এটি দেখা যায়, আর সেই log কি সত্যিই SIEM-এ আসছে? না এলে rule লিখে লাভ নেই, আগে log আনুন। এটি একটি detection gap.
5. স্বাভাবিক কাজ: নিরীহ কোন কাজ দেখতে একই রকম? ভুল password দেওয়া মানুষ, scanner, পুরোনো password-ওয়ালা script.
6. সাড়া: Alert এলে analyst কী করবেন? উত্তর না থাকলে rule-টি এখনো প্রস্তুত নয়।

৪ · Sigma — log-এর জন্য একটি সাধারণ rule ভাষা

প্রতিটি SIEM-এর নিজের query ভাষা। একটি ভালো rule SPL-এ লিখলে KQL-এ আবার লিখতে হয়। Sigma এই সমস্যার উত্তর। এটি YAML-এ লেখা, পণ্য-নিরপেক্ষ একটি rule format. ধারণাটি হলো, network-এর জন্য Snort rule বা ফাইলের জন্য YARA যা, log-এর জন্য Sigma তাই। একটি converter পরে rule-কে নির্দিষ্ট SIEM-এর query-তে রূপান্তর করে। প্রকল্পটির শুরু ২০১৭ সালের দিকে, Florian Roth আর Thomas Patzke-র নাম এর সাথে জড়িত। এখন sigmahq.io-তে specification আছে, যার v2.1.0 প্রকাশিত হয় ২০২৫ সালের আগস্টে।

নিচের rule একটি সাধারণ আচরণ দেখে: Windows-এর স্থানীয় Administrators দলে কেউ নতুন সদস্য যোগ করল। Event ID 4732 এই ঘটনা লেখে, আর S-1-5-32-544 হলো Administrators দলের পরিচিত SID. ATT&CK-এ T1098 (Account Manipulation) technique এর কাছাকাছি। পর্ব ৩১-এ এই log-এর জগৎ দেখেছেন।

title: Member Added to Local Administrators Group
id: 6f1c2d3e-8a47-4b19-9e52-7c0d4a1b3f60
status: test
description: Detects a user added to the local Administrators group on a Windows host.
references:
  - https://attack.mitre.org/techniques/T1098/
author: ABCL TECH course example
date: 2026-10-31
tags:
  - attack.persistence
  - attack.privilege-escalation
  - attack.t1098
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4732
    TargetSid: S-1-5-32-544
  filter_machine:
    SubjectUserName|endswith: '$'
  filter_deploy:
    SubjectUserName:
      - svc-deploy
      - svc-patch
    Computer|startswith: build-
  condition: selection and not 1 of filter_*
falsepositives:
  - Approved administrator onboarding
level: medium

নিচের কোড আসল Sigma engine নয়। এটি একই rule-এর ছোট রূপ, যা স্মৃতির ভেতরের ৬টি বানানো event-এ চলে। AND, OR আর not কীভাবে ফল ঠিক করে, এখানে হাতে-কলমে দেখুন।

// Toy Sigma-like matcher on in-memory events. Not a real Sigma engine.
const rule = {
  selection: { EventID: 4732, TargetSid: 'S-1-5-32-544' },
  filter_machine: { 'SubjectUserName|endswith': '$' },
  filter_deploy: { SubjectUserName: ['svc-deploy', 'svc-patch'],
                   'Computer|startswith': 'build-' },
};  // condition: selection and not 1 of filter_*

const events = [
  { id: 'e1', EventID: 4732, TargetSid: 'S-1-5-32-544', SubjectUserName: 'rahim', Computer: 'pay-db1' },
  { id: 'e2', EventID: 4732, TargetSid: 'S-1-5-32-544', SubjectUserName: 'PAY-DB1$', Computer: 'pay-db1' },
  { id: 'e3', EventID: 4732, TargetSid: 'S-1-5-32-544', SubjectUserName: 'SVC-DEPLOY', Computer: 'build-07' },
  { id: 'e4', EventID: 4732, TargetSid: 'S-1-5-32-544', SubjectUserName: 'svc-deploy', Computer: 'pay-db1' },
  { id: 'e5', EventID: 4732, TargetSid: 'S-1-5-32-555', SubjectUserName: 'rahim', Computer: 'pay-db1' },
  { id: 'e6', EventID: 4624, TargetSid: '-', SubjectUserName: 'rahim', Computer: 'pay-db1' },
];

const low = v => String(v).toLowerCase();       // Sigma strings ignore case by default
const ops = {
  eq: (a, b) => low(a) === low(b),
  endswith: (a, b) => low(a).endsWith(low(b)),
  startswith: (a, b) => low(a).startsWith(low(b)),
};
function matchMap(map, ev) {                    // keys are AND, list values are OR
  return Object.entries(map).every(([key, want]) => {
    const [field, op = 'eq'] = key.split('|');
    return [].concat(want).some(w => field in ev && ops[op](ev[field], w));
  });
}
for (const ev of events) {
  const sel = matchMap(rule.selection, ev);
  const fm = matchMap(rule.filter_machine, ev), fd = matchMap(rule.filter_deploy, ev);
  const alert = sel && !(fm || fd);
  console.log(`${ev.id} selection=${sel} filter_machine=${fm} filter_deploy=${fd} -> ${alert ? 'ALERT' : 'no alert'}`);
}

এবার পুরো পথটি দেখুন। একটি rule কীভাবে ধারণা থেকে deploy পর্যন্ত যায়, আর test কোথায় ফল বদলে দেয়।

একজন মানুষ বা account একটি server-এর
Administrators দলে নতুন সদস্য যোগ করল।

ATT&CK : T1098 Account Manipulation
Log    : Windows Security, EventID 4732
যাচাই  : group-change audit চালু আছে কি?
         log SIEM-এ আসছে কি?  হ্যাঁ

selection:
  EventID: 4732
  TargetSid: S-1-5-32-544
condition: selection

e1 rahim        pay-db1  ALERT  ঠিক
e2 PAY-DB1$     pay-db1  ALERT  ভুল
e3 SVC-DEPLOY   build-07 ALERT  ভুল
e4 svc-deploy   pay-db1  ALERT  ঠিক
e5, e6                   নীরব   ঠিক
ফল: ৪টি alert, ২টি ভুল

condition: selection and not 1 of filter_*

e1 ALERT, e4 ALERT
e2, e3, e5, e6 নীরব
ফল: ২টি alert, ০টি ভুল

pull request → review → test চলল → merge
status: test
দুই সপ্তাহ shadow mode: শুধু গণনা, কাউকে ডাকা নয়
ফল ভালো হলে: alert চালু, পরে status: stable

৫ · Threshold, sequence আর correlation

একবার ভুল password দেওয়া কিছুই প্রমাণ করে না। মোবাইল ব্যাংকিংয়ের PIN আপনিও ভুল দিয়েছেন। সন্দেহ জন্মায় সংখ্যা, ক্রম আর সম্পর্ক থেকে। তাই detection rule-এর তিনটি বড় ধরন আছে।

কী ধরে গুনবেন: group-by

একই ব্যর্থ login, কিন্তু কিসের ভিত্তিতে গোনা হচ্ছে তার ওপর ধরা পড়ে ভিন্ন আচরণ।

তাই একটি rule যথেষ্ট নয়, কয়েকটি rule একে অপরের ফাঁক ঢাকে। প্রতিরোধও আলাদা থাকুক: পর্ব ১৫-এর login throttling আর পর্ব ১৬-এর MFA অনেক ঘটনা আগেই থামায়। Detection সেগুলোর বিকল্প নয়।

Fixed bin বনাম sliding window

অনেকে সময়কে ০–৫, ৫–১০ মিনিটের বাক্সে ভাগ করে গোনেন। সহজ, কিন্তু একটি ফাঁদ আছে। ঝাঁকটি বাক্সের সীমায় পড়লে দুই ভাগ হয়ে যায়, আর দুই বাক্সই সীমার নিচে থাকে। Sliding window প্রতিটি নতুন event-এ ঠিক আগের ৫ মিনিট দেখে, তাই এই ফাঁদ নেই। নিচের ছবিতে সীমা ৫।

নিচের কোডে সময় বানানো, এক সেকেন্ডও সত্যি অপেক্ষা হয় না। তিনটি উৎসের ব্যবহার তিন রকম। সীমা ৫ মিনিটে ৫টি, আর সাফল্য ১০ মিনিটের মধ্যে এলে গুরুতর।

// Toy login events with a simulated clock (t = seconds). No network, no real logs.
const F = 'fail', S = 'success';
const row = (src, type, ...ts) => ts.map(t => ({ t, src, type }));
const events = [
  ...row('203.0.113.7', F, 240, 250, 270, 290, 310, 330), ...row('203.0.113.7', S, 345),
  ...row('198.51.100.20', F, 100, 400, 700, 1000), ...row('198.51.100.20', S, 1010),
  ...row('198.51.100.30', F, 60, 70, 80, 90, 100, 110),
].sort((a, b) => a.t - b.t);
const WINDOW = 300, LIMIT = 5, THEN = 600;     // 5 minutes, 5 failures, 10 minutes

function fixedBins(src) {                      // 0-299, 300-599, ...
  const bins = {};
  for (const e of events) if (e.src === src && e.type === F) {
    const b = Math.floor(e.t / WINDOW); bins[b] = (bins[b] || 0) + 1;
  }
  return Math.max(...Object.values(bins));
}
function sliding(src) {
  const fails = []; let fired = null, success = null;
  for (const e of events) {
    if (e.src !== src) continue;
    if (e.type === S && fired !== null && e.t - fired <= THEN) { success = e.t; break; }
    if (e.type !== F) continue;
    fails.push(e.t);
    while (e.t - fails[0] >= WINDOW) fails.shift();  // drop what left the window
    if (fails.length >= LIMIT && fired === null) fired = e.t;
  }
  return { fired, success };
}
for (const src of [...new Set(events.map(e => e.src))]) {
  const { fired, success } = sliding(src), maxBin = fixedBins(src);
  const verdict = success ? 'HIGH: fail burst then success' : fired ? 'MEDIUM: fail burst only' : 'no alert';
  console.log(`${src} max_in_fixed_bin=${maxBin} fixed=${maxBin >= LIMIT ? 'alert' : 'none'} ` +
              `sliding_fired_at=${fired} success_at=${success} -> ${verdict}`);
}

SIEM ছাড়াই: awk দিয়ে গণনা

ছোট server-এ SIEM না থাকলেও ধারণাটি কাজে লাগে। নিচের Bash block কোনো আসল log পড়ে না, নিজের ভেতরে বানানো নমুনা পড়ে। নিজের system-এ একই কৌশল চালাতে পারেন, যেখানে log পড়ার অনুমতি আপনার আছে। পর্ব ৩০-এ auth log-এর জায়গা দেখেছেন।

# Fixed sample built here; only addresses reserved for documentation.
awk -v limit=5 '
{
  for (i = 1; i <= NF; i++) if ($i == "from") { src = $(i + 1); user = $(i - 1) }
  if ($0 ~ /Failed password/) {
    fails[src]++
    if (!((src, user) in seen)) { seen[src, user] = 1; users[src]++ }
  } else if ($0 ~ /Accepted password/ && fails[src] >= limit) {
    after[src] = user
  }
}
END {
  for (s in fails) {
    level = "ok"
    if (fails[s] >= limit) level = "MEDIUM"
    if (s in after) level = "HIGH success_for=" after[s]
    printf "%-15s failed=%-2d users=%d %s\n", s, fails[s], users[s], level
  }
}' <<'LOG' | sort -t= -k2,2nr
Oct 31 10:01:02 web1 sshd[812]: Failed password for rahim from 198.51.100.20 port 51022 ssh2
Oct 31 10:01:40 web1 sshd[812]: Accepted password for rahim from 198.51.100.20 port 51022 ssh2
Oct 31 10:02:01 web1 sshd[820]: Failed password for admin from 203.0.113.7 port 40110 ssh2
Oct 31 10:02:03 web1 sshd[820]: Failed password for invalid user test from 203.0.113.7 port 40112 ssh2
Oct 31 10:02:05 web1 sshd[820]: Failed password for sadia from 203.0.113.7 port 40114 ssh2
Oct 31 10:02:07 web1 sshd[820]: Failed password for sadia from 203.0.113.7 port 40116 ssh2
Oct 31 10:02:09 web1 sshd[820]: Failed password for sadia from 203.0.113.7 port 40118 ssh2
Oct 31 10:02:12 web1 sshd[820]: Failed password for sadia from 203.0.113.7 port 40120 ssh2
Oct 31 10:02:15 web1 sshd[820]: Accepted password for sadia from 203.0.113.7 port 40122 ssh2
Oct 31 10:03:00 web1 sshd[830]: Failed password for invalid user oracle from 198.51.100.30 port 40200 ssh2
Oct 31 10:03:02 web1 sshd[830]: Failed password for invalid user guest from 198.51.100.30 port 40202 ssh2
Oct 31 10:03:04 web1 sshd[830]: Failed password for invalid user demo from 198.51.100.30 port 40204 ssh2
Oct 31 10:03:06 web1 sshd[830]: Failed password for invalid user web from 198.51.100.30 port 40206 ssh2
Oct 31 10:03:08 web1 sshd[830]: Failed password for invalid user ftp from 198.51.100.30 port 40208 ssh2
LOG

৬ · Mini detection — অনেক ব্যর্থ login, তারপর সাফল্য

এবার সব জোড়া দিই। লক্ষ্য একটি rule: একটি উৎস থেকে ৫ মিনিটে ≥ ৫ ব্যর্থ network login, তারপর ১০ মিনিটের মধ্যে একই উৎস থেকে সফল login. Sigma-তে এটি চারটি অংশ: দুটি base rule, একটি গণনা, আর একটি ক্রম। correlation অংশের নাম আর ঘর sigmahq.io-র specification মিলিয়ে লেখা। এখানে logon type 3 হলো network, 10 হলো Remote Desktop.

title: Failed Network Logon
name: failed_network_logon
id: 2b7e9a14-53c6-4d0f-a1e8-96f3c27d5b41
status: test
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
    LogonType:
      - 3
      - 10
  filter_local:
    IpAddress: '-'
  condition: selection and not filter_local
level: low
---
title: Successful Network Logon
name: successful_network_logon
id: c94d1f07-2ea3-4b68-8d15-3a70e6b2f9c8
status: test
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType:
      - 3
      - 10
  filter_local:
    IpAddress: '-'
  condition: selection and not filter_local
level: low
---
title: Many Failed Logons From One Source
name: many_failed_logons
id: 81a6e3d2-7f04-4c5b-b2d9-05e4c8f1a763
status: test
correlation:
  type: event_count
  rules:
    - failed_network_logon
  group-by:
    - IpAddress
  timespan: 5m
  condition:
    gte: 5
level: medium
---
title: Failed Logons Followed by Success From One Source
id: 3e05b7c9-d162-4a8e-9f37-b18c6d24e05a
status: test
description: Five or more failed logons from a source, then a success from the same source.
author: ABCL TECH course example
date: 2026-10-31
tags:
  - attack.credential-access
  - attack.t1110
correlation:
  type: temporal_ordered
  rules:
    - many_failed_logons
    - successful_network_logon
  group-by:
    - IpAddress
  timespan: 10m
falsepositives:
  - A user who mistypes a password many times, then succeeds
  - A shared NAT or VPN address used by many people
level: high

লক্ষ করুন, group-by লেখা হয় hyphen দিয়ে, আর many_failed_logons নিজেই একটি correlation, যাকে শেষ অংশ ব্যবহার করছে। Spraying-এর জন্য একই base rule-এ আলাদা একটি গণনা জোড়া যায়:

title: One Source Fails Against Many Accounts
id: a4d82f6c-19b7-4e03-8c5a-f27e01d6b394
status: test
correlation:
  type: value_count
  rules:
    - failed_network_logon
  group-by:
    - IpAddress
  timespan: 15m
  condition:
    field: TargetUserName
    gte: 10
level: medium

যে SIEM-এ Sigma correlation নেই, সেখানে একই ধারণা তার নিজের ভাষায় লিখতে হয়। নিচের দুটি কাল্পনিক টেবিলের ওপর লেখা, চালানো হয়নি।

index=auth (action=failure OR action=success)
| sort 0 _time
| streamstats time_window=5m count(eval(action="failure")) AS failures BY src_ip
| where action="success" AND failures>=5
| table _time src_ip user failures

let bursts = auth_events
  | where outcome == "failure"
  | summarize failures = count(), last_fail = max(timestamp)
      by src_ip, bin(timestamp, 5m)
  | where failures >= 5;
bursts
| join kind=inner (
    auth_events
    | where outcome == "success"
    | project src_ip, user, success_time = timestamp
  ) on src_ip
| where success_time between (last_fail .. (last_fail + 10m))
| project src_ip, user, failures, last_fail, success_time

দুটি উদাহরণে পার্থক্যটি খেয়াল করুন। SPL-ধাঁচের query-তে streamstats চলন্ত সময়ের জানালা নেয়, আর সাফল্যের ঠিক আগের ৫ মিনিট গোনে। KQL-ধাঁচের query bin() ব্যবহার করে, তাই ওপরের ছবির fixed bin-এর ফাঁদ এখানে রয়ে গেছে। সহজে পড়ার জন্য query-টি এমন রাখা হয়েছে। বাস্তবে ছোট ধাপের বাক্স বা পণ্যের নিজস্ব sequence সুবিধা দেখুন, যেমন Elastic-এর EQL-এ আলাদা sequence query আছে।

এই rule কী ধরে না

• ধীর চেষ্টা: ঘণ্টায় একটি ব্যর্থতা সীমা ছোঁয় না।
• ছড়ানো উৎস: চেষ্টা বহু ঠিকানা থেকে এলে IpAddress ধরে গোনা কাজ করে না।
• এক চেষ্টায় সঠিক password: Password আগেই ফাঁস হলে ব্যর্থতাই থাকে না। তার জন্য লাগে impossible travel-এর মতো আচরণের সংকেত।
• ভাগ করা ঠিকানা: এক NAT বা VPN-এর পেছনে বহু মানুষ থাকলে নিরীহ ঘটনাও মিলতে পারে।

৭ · Detection as code — version, test, review, deploy

কেউ যদি SIEM-এর screen-এ সরাসরি rule বদলায়, ছয় মাস পরে কেউ জানবে না কে, কেন, কী বদলেছিল। Detection as code-এর ধারণা সহজ: rule-কে সফটওয়্যারের মতো সামলানো। পর্ব ৪৯-এর test-এর শৃঙ্খলা এখানেও খাটে।

Test-এর মূল অংশ হলো নমুনা event: কয়েকটি আসল ধরনের (true positive) আর কয়েকটি নিরীহ কিন্তু কাছাকাছি ধরনের (false positive) ঘটনা। প্রতিবার ভুল ধরা পড়লে একটি নতুন নমুনা যোগ করুন। এটি একটি regression test. নিচের harness একটি ইচ্ছাকৃত দুর্বল খসড়া আর তার সংশোধিত রূপ পরীক্ষা করে।

// Detection test harness. Toy rule, toy events, simulated day number. Run before every deploy.
const seq = (src, failTimes, okTime) => [...failTimes.map(t => ({ t, src, ok: false })), { t: okTime, src, ok: true }];
const exceptions = [{ src: '198.51.100.5', owner: 'secops', ticket: 'SEC-2041', expiresDay: 30 }];

function ruleV1(evs, day) {                    // first draft
  return evs.filter(e => !e.ok).length > 5 && evs.some(e => e.ok);
}
function ruleV2(evs, day) {                    // fixed after the tests failed
  if (exceptions.some(x => x.src === evs[0].src && day < x.expiresDay)) return false;
  const seen = [];
  for (const e of [...evs].sort((a, b) => a.t - b.t)) {
    if (e.ok && seen.length >= 5) return true;
    if (!e.ok) { seen.push(e.t); while (e.t - seen[0] >= 300) seen.shift(); }
  }
  return false;
}
const tests = [
  ['TP burst then success', seq('203.0.113.7', [0, 5, 10, 15, 20, 25], 30), 1, true],
  ['TP exactly 5 failures', seq('203.0.113.8', [0, 5, 10, 15, 20], 30), 1, true],
  ['FP user mistypes 3 times', seq('198.51.100.20', [0, 20, 40], 60), 1, false],
  ['FP success came first', seq('198.51.100.21', [5, 6, 7, 8, 9, 10], 0), 1, false],
  ['FP slow, 1 fail per 10 min', seq('198.51.100.22', [0, 600, 1200, 1800, 2400, 3000], 3010), 1, false],
  ['FP scanner, exception active', seq('198.51.100.5', [0, 1, 2, 3, 4, 5], 6), 12, false],
  ['TP scanner, exception expired', seq('198.51.100.5', [0, 1, 2, 3, 4, 5], 6), 31, true],
];
function run(name, rule) {
  const failed = tests.filter(([, evs, day, want]) => rule(evs, day) !== want);
  console.log(`--- ${name}`);
  failed.forEach(([label, , , want]) => console.log(`FAIL ${label}: expected ${want}`));
  const ok = tests.length - failed.length;
  console.log(`${ok}/${tests.length} passed -> ${failed.length ? 'do not deploy' : 'ready for review'}`);
}
run('rule v1', ruleV1);
run('rule v2', ruleV2);

৮ · Tuning আর মাপ — alert fatigue কমানো

পর্ব ২৩-এ দেখেছেন, alert fatigue মানুষের দোষ নয়, নকশার ফল। সেখানেই base-rate fallacy-র হিসাবও আছে। ছোট করে মনে করি। ধরা যাক ১০,০০,০০০ ঘটনায় ১০টি আসল, rule ৯৯% আসল ঘটনা ধরে, আর ১% নিরীহ ঘটনায় ভুল করে। তখন TP ৯.৯, FP ০.০১ × ৯,৯৯,৯৯০ ≈ ১০,০০০, আর precision প্রায় ০.১%.

Correlation এখানে সাহায্য করে। ধরুন দ্বিতীয় একটি শর্ত যোগ হলো, যা ৯০% আসল ঘটনায় আর ১% নিরীহ ঘটনায় থাকে, আর দুই শর্ত পরস্পর স্বাধীন। এই স্বাধীনতা একটি অনুমান, বাস্তবে তা পুরো মেলে না। তখন TP ৯.৯ × ০.৯ ≈ ৮.৯, FP ≈ ১০০, precision ৮.৯ ÷ ১০৮.৯ ≈ ৮.২%. প্রায় ৮০ গুণ ভালো। দাম হলো recall ৯৯% থেকে ৮৯% হলো। এই লেনদেনটিই সব tuning-এর মূল কথা।

Tuning-এর আগে কারণ খুঁজুন: ভুল alert-গুলো কোথা থেকে আসছে? Allowlist বা ছাড় শেষ উপায়, প্রথম নয়। নিচের কাল্পনিক rule এক সপ্তাহে ৮৪০টি alert দিয়েছে। প্রতিটি alert দেখতে ১০ মিনিট লাগলে সেটি ১৪০ ঘণ্টার কাজ। সব পর্যালোচনা করে ১৪টি আসল পাওয়া গেছে। পুরোনো ডেটায় replay করে বিকল্পগুলো তুলনা করুন।

মেয়াদসহ ছাড় কেমন দেখতে

Sigma-র rule ফাইলে মেয়াদের কোনো প্রমিত ঘর আছে বলে আমাদের জানা নেই। তাই অনেক দল ছাড় আলাদা ফাইলে রাখে, আর CI মেয়াদ যাচাই করে। নিচের format কোনো মান নয়, শুধু একটি উদাহরণ।

# exceptions.yml: our own team format, not part of the Sigma standard
- rule: 3e05b7c9-d162-4a8e-9f37-b18c6d24e05a
  match:
    src_ip: 198.51.100.5
    user: svc-scan
    window: Tue 01:00-03:00
  owner: secops-team
  ticket: SEC-2041
  reason: Approved weekly scan of our own servers
  created: 2026-11-01
  expires: 2026-12-01

কী মাপবেন

MTTD-র একটি পূর্ণ হিসাব। পাঁচটি ঘটনা ধরা পড়তে সময় লেগেছে ১২, ২০, ৪৫, ১৮০ আর ২,৮৮০ মিনিট। গড় = ৩,১৩৭ ÷ ৫ = ৬২৭.৪ মিনিট, প্রায় ১০.৫ ঘণ্টা। কিন্তু median মাত্র ৪৫ মিনিট। একটি দুই দিনের ঘটনা গড়কে টেনে তুলেছে। তাই গড়ের সাথে median আর সবচেয়ে ধীর ঘটনাটিও দেখুন। MTTD শুধু যা ধরা পড়েছে তা গোনে, আর যা কখনো ধরা পড়েনি তা হিসাবেই নেই। Dwell time এর কাছের ধারণা, যার সংজ্ঞা উৎসভেদে একটু আলাদা হয়।

৯ · UEBA — “এই মানুষটির জন্য এটি স্বাভাবিক কি?”

পুরোনো দারোয়ান জানেন, করিম সাহেব প্রতিদিন সকাল নয়টায় আসেন। একদিন রাত তিনটায় এলে তিনি একটু ভাবেন। করিম সাহেবের কোনো নিয়ম ভাঙেনি, কিন্তু আচরণ বদলেছে। UEBA (User and Entity Behaviour Analytics) এই ধারণা log-এ আনে। প্রতিটি হিসাব, যন্ত্র বা service-এর জন্য একটি baseline শেখা হয়, আর তার থেকে বড় বিচ্যুতিতে risk score বাড়ে।

এটি ভালো কাজ করতে পারে যেখানে নির্দিষ্ট rule লেখা কঠিন, যেমন চুরি হওয়া account বা ভেতরের মানুষের অপব্যবহার। কিন্তু পর্ব ২৩-এর anomaly-র ফাঁদ এখানেও আছে: concept drift, দূষিত baseline, আর ব্যাখ্যা করা কঠিন ফল। ঈদের আগের সপ্তাহে হিসাব বিভাগের অস্বাভাবিক ব্যস্ততা কোনো অপরাধ নয়। মানুষের আচরণ মাপা গোপনীয়তার প্রশ্নও তোলে। লিখিত নীতি, সীমিত access আর মানুষের সিদ্ধান্ত ছাড়া শুধু score দেখে কারও বিরুদ্ধে ব্যবস্থা নেওয়া ঠিক নয়। ধরাবাঁধা rule আর UEBA তাই বিকল্প নয়, পরিপূরক। Endpoint-এর দিক পর্ব ৫৯-এ, আর SOC-এর দৈনন্দিন কাজ পর্ব ৬০-এ আসবে।

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

AI একটি দ্রুত সহকারী। সে rule-এর খসড়া লিখতে, log-এর সারাংশ করতে, query এক ভাষা থেকে অন্য ভাষায় নিতে পারে। অনেক SIEM-এ এখন এমন সহায়ক আছে। কিন্তু সে আপনার log, আপনার field আর আপনার স্বাভাবিক আচরণ দেখে না। তাই AI-এর দেওয়া rule একটি খসড়া, যা বাকি সব rule-এর মতোই test আর review পার হবে। Log পড়ানো হলে আরেকটি ঝুঁকি আছে। Username-এর মতো ঘর বাইরে থেকে আসে, তাই log-এর লেখা পর্ব ৫১-এর prompt injection হয়ে উঠতে পারে।

AI-এর লেখা rule চালুর আগে

• প্রতিটি technique ID, Event ID আর field প্রাথমিক উৎসে মিলিয়েছি
• Field নামগুলো আমার SIEM-এর আসল event-এ আছে
• অন্তত একটি true positive আর একটি false positive নমুনায় test করেছি
• পুরোনো ডেটায় replay করে alert-এর সংখ্যা দেখেছি
• একজন মানুষ review করেছেন, আর shadow mode দিয়ে শুরু করছি
• Prompt-এ কোনো secret বা ব্যক্তিগত তথ্য পাঠাইনি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত মানুষই নেবেন