Forensic artifact — log, memory, disk আর timeline বানানো

১ · Artifact-এর চিন্তা — একটি সিস্টেম কী কী মনে রাখে

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

কম্পিউটারও তাই। Forensic artifact হলো সিস্টেমের স্বাভাবিক কাজের ফলে থেকে যাওয়া চিহ্ন। Windows প্রোগ্রাম দ্রুত খুলতে একটি file রাখে। File system হিসাব রাখতে সময় লেখে। Web server সমস্যা ধরতে log লেখে। Digital forensics-এর কাজ হলো এই চিহ্নগুলো থেকে অতীতের ঘটনা সাবধানে গড়ে তোলা।

প্রতিটি artifact পড়ার সময় চারটি প্রশ্ন করুন:

শেষ প্রশ্নটি সংগ্রহের ক্রম ঠিক করে। RFC 3227 (২০০২, Brezinski ও Killalea) বলে, যা দ্রুত হারায় তা আগে সংগ্রহ করুন। একে order of volatility বলে। ধারণাটি পর্ব ৬৩-তে এসেছে। এখানে দেখুন কোন স্তরে কোন artifact থাকে।

২ · Windows artifact — কোনটি কী বলে, কোনটি বলে না

Windows-এ artifact অনেক। শুরুতে নিচের কয়েকটি চিনলেই চলবে। এগুলো সবই সিস্টেমের নিজের প্রয়োজনে তৈরি, তাই Microsoft-এর নথি বা স্বীকৃত গবেষণা মিলিয়ে অর্থ যাচাই করুন। Windows version বদলালে আচরণও বদলাতে পারে।

Run key-এর পথ Microsoft-এর নথিতে আছে: HKLM\Software\Microsoft\Windows\CurrentVersion\Run আর একই পথ HKCU-এর নিচে। Persistence খুঁজতে এই জায়গাগুলো প্রথম দিকেই দেখা হয়। Windows-এর audit কীভাবে চালু করবেন, তা পর্ব ৩১-এ আছে। Sysmon আর EDR থাকলে process-এর ইতিহাস আরও ভালো পাওয়া যায়।

৩ · Linux artifact — log, history, cron আর তিনটি সময়

Linux-এ বেশিরভাগ artifact সাধারণ লেখার file. তবে distribution ভেদে পথ আলাদা। নিচের তালিকা প্রচলিত ধরন, নিশ্চিত নিয়ম নয়।

Shell history-র সীমা থেকেই একটি প্রতিরক্ষার শিক্ষা আসে। কমান্ডের ভরসাযোগ্য হিসাব চাইলে আগে থেকে auditd চালু করে log অন্য জায়গায় পাঠাতে হয় (পর্ব ৩০)। ঘটনার পর সেই প্রস্তুতি নেওয়া যায় না।

mtime, atime, ctime

প্রতিটি file-এর inode-এ সময় রাখা থাকে। নামগুলো বিভ্রান্তিকর। বিশেষ করে ctime মানে “created” নয়, “changed”. পরীক্ষাতেও এই ভুলটিই ধরা হয়।

৪ · Web, application আর cloud log

Web server log বলে কে কোন পথে কী অনুরোধ করেছিল, উত্তরের status কত। সাধারণ combined format-এ থাকে IP, সময়, request line, status, আকার, referrer আর user-agent. তিনটি সীমা মনে রাখুন:

• POST-এর ভেতর থাকে না। সাধারণ log দেখায় কোথায় পাঠানো হয়েছে, কী পাঠানো হয়েছে তা নয়।
• IP মানেই মানুষ নয়। Proxy, CDN বা NAT-এর পেছনে আসল ঠিকানা আলাদা হতে পারে। User-agent লেখা বদলানোও সহজ।
• সময়ের অর্থ tool ভেদে আলাদা। Apache-র নথি অনুযায়ী %t হলো অনুরোধ পাওয়ার সময়। nginx log লেখে অনুরোধ শেষে। তাই বড় upload-এর nginx সারি শুরুর সময় দেখায় না।

Application log ব্যবসার ভাষায় কথা বলে: কোন user login করলেন, কে কোন report export করলেন। Web log যা বলতে পারে না, এটি অনেক সময় তা বলে। তবে কী লেখা হবে, তা ডেভেলপার ঠিক করেছেন। ভালো application log কেমন হয়, পর্ব ৫৫-এ দেখেছেন।

Cloud audit log cloud-এর সবচেয়ে গুরুত্বপূর্ণ artifact, কারণ সেখানে disk হাতে নেওয়া প্রায়ই সম্ভব নয়। এটি বলে কোন identity কোন API call করল, কোথা থেকে, ফল কী। কয়েকটি বাস্তব সীমা:

বিস্তারিত নকশা Centralized logging পর্বে আছে। মোদ্দা কথা, যে data event লেখা হয়নি, তদন্তে তা তৈরি করা যায় না।

৫ · Memory আর মুছে যাওয়া ডেটা

Memory analysis: সেই মুহূর্তের ছবি

Disk হলো অফিসের আলমারি। RAM হলো টেবিল, যেখানে এই মুহূর্তের কাজ ছড়ানো। Memory forensics মানে RAM-এর একটি কপি নিয়ে পরে বিশ্লেষণ করা। Volatile data কয়েকটি প্রশ্নের উত্তর দিতে পারে, যা disk পারে না:

Memory-র সীমাও আছে। এটি একটি মুহূর্তের ছবি, ইতিহাস নয়। কপি নেওয়ার কাজটিও সিস্টেমে সামান্য বদল ঘটায়, তাই কী করলেন তা নোট করুন। এতে password আর ব্যক্তিগত ডেটা থাকতে পারে, তাই কপিটি প্রমাণের মতোই গোপনে রাখুন। Volatility-র মতো open source framework গবেষণা ও প্রশিক্ষণে পরিচিত একটি উদাহরণ। আর server বন্ধ করা বা restart দেওয়ার আগে ভাবুন, কারণ এই প্রমাণ তখনই হারায়।

File carving: সূচি ছাড়া ডেটা খোঁজা

File “মুছলে” সাধারণত ডেটা সঙ্গে সঙ্গে মোছে না। File system শুধু জায়গাটিকে খালি বলে চিহ্নিত করে। বইয়ের সূচি থেকে একটি অধ্যায়ের নাম কেটে দিলেও পাতাগুলো বইয়ে থাকে, পরে হয়তো অন্য লেখা বসে। এই জায়গাকে unallocated space বলে।

File carving সূচির ওপর নির্ভর না করে raw byte-এ file-এর চেনা গঠন খোঁজে। যেমন JPEG ছবি শুরু হয় FF D8 FF দিয়ে, শেষ হয় FF D9 দিয়ে। এর সীমা স্পষ্ট:

• নাম, folder আর সময় সাধারণত হারায়। তাই উদ্ধার করা file timeline-এ বসানো কঠিন।
• File টুকরো টুকরো থাকলে জোড়া ভুল হতে পারে। Garfinkel-এর ২০০৭ সালের DFRWS গবেষণাপত্রে এই সমস্যা নিয়ে কাজ আছে।
• SSD-তে TRIM মুছে দেওয়া জায়গা পরিষ্কার করে ফেলতে পারে, তাই উদ্ধার অনেক সময় সম্ভব হয় না।
• Encryption থাকলে raw byte-এ চেনা গঠন পাওয়া যায় না।
• অপ্রাসঙ্গিক ব্যক্তিগত ডেটাও উঠে আসতে পারে। Scope আর গোপনীয়তার নিয়ম মানুন।

কাজটি সবসময় মূল disk-এ নয়, forensic image-এর কপিতে করুন, আর hash মিলিয়ে রাখুন (পর্ব ৬৩)। Chain of custody ভাঙলে ভালো বিশ্লেষণও দুর্বল হয়ে যায়।

৬ · Timestamp — সবচেয়ে দরকারি, সবচেয়ে ভুল-প্রবণ

File-এর সময়গুলোকে একসাথে MACB বলে: Modified, Accessed, Changed (metadata), Born. NTFS-এ একই ধারণাকে অনেক সময় MACE লেখা হয়। NTFS-এ একটি file-এর সময় $STANDARD_INFORMATION আর $FILE_NAME, দুই জায়গায় থাকে। এই দুইয়ের অমিল একটি সূত্র, কিন্তু একা প্রমাণ নয়।

সময় ভুল বা বিভ্রান্তিকর হয় বেশিরভাগ ক্ষেত্রে কোনো দুষ্ট উদ্দেশ্য ছাড়াই:

ইচ্ছাকৃত বদলও সম্ভব, একে timestomping বলে (MITRE ATT&CK T1070.006). তদন্তকারীর জন্য এর শিক্ষা একটিই: timestamp অবিশ্বাস্য হতে পারে, তাই correlate করুন। File system-এর সময়, journal, log, অন্য host-এর log আর network রেকর্ড আলাদা জায়গায় থাকে। একসাথে সবগুলো মিলে গেলে ভরসা বাড়ে। না মিললে সেটি ব্যাখ্যা করতে হয়।

৭ · Super timeline — সব উৎস এক ক্রমে

একটি উৎস পড়লে গল্পের এক টুকরো মেলে। Super timeline হলো file system, log, registry, browser, সব ঘটনাকে এক সময়-ক্রমে সাজানো। ধারণাটি জনপ্রিয় হয় Kristinn Guðjónsson-এর ২০১০ সালের SANS গবেষণাপত্র “Mastering the Super Timeline With log2timeline” থেকে। পরে Plaso নামে এর Python রূপ তৈরি হয়। এটি একটি উদাহরণমাত্র। Spreadsheet, SIEM বা নিজের script দিয়েও ছোট timeline বানানো যায়।

Plaso-র নথিতে প্রচলিত ব্যবহার এমন। কমান্ড দুটি আপনার অনুমোদিত image-এর কপিতে চালানোর জন্য, আর option version-ভেদে বদলাতে পারে:

# উদাহরণ: নিজের অনুমোদিত image-এর কপিতে, মূল প্রমাণে নয়
log2timeline.py --storage-file timeline.plaso /PATH/image.E01
psort.py -w timeline.csv timeline.plaso

প্রথম কমান্ড ঘটনা বের করে একটি storage file বানায়। দ্বিতীয়টি তা থেকে সাজানো ফল দেয়। ফল প্রায়ই লাখ লাখ সারি, তাই সময়ের জানালা আর সূত্র ধরে ছাঁকতে হয়। Timesketch-এর মতো tool দলবদ্ধ বিশ্লেষণে সাহায্য করে। হাতে বানানোর ধাপগুলো দেখলে tool-এর কাজ বোঝা সহজ হবে।

web : [10/Mar/2026:02:14:07 +0600]
      POST
auth: 2026-03-09T20:24:51Z
      Accepted
fw  : 1773087984 ALLOW to :22

web : 20:14:07Z POST
auth: 20:24:51Z Accepted
fw  : 20:26:24Z ALLOW to :22

20:24:51Z auth login সফল
20:26:24Z fw   সংযোগের অনুমতি
সংযোগের আগে login হতে পারে না
পার্থক্য: 93 s

web : 20:14:07Z  >  20:15:41Z
auth: 20:24:51Z  >  20:26:25Z
fw  : 20:26:24Z  (বদল নেই)

20:15:41Z web  POST /admin/upload
20:26:24Z fw   ALLOW 198.51.100.77 to :22
20:26:25Z auth Accepted publickey deploy
note: host clock 94 s behind, ±few s

এবার একই কাজ Bash-এ। নিচের block নিজেই তিনটি নমুনা log বানায়। শুধু UTC-তে আনে আর sort করে। সারিগুলো ছোট করা হয়েছে, আসল combined format-এ আরও ঘর থাকে।

# নমুনা log: block নিজেই বানায়, host-এর কোনো ডেটা পড়ে না
d=$(mktemp -d); cd "$d"
cat > web.log <<'EOF'
203.0.113.45 - - [10/Mar/2026:02:14:07 +0600] "POST /admin/upload" 200
203.0.113.45 - - [10/Mar/2026:02:16:33 +0600] "GET /uploads/img_7731.php" 200
EOF
cat > auth.log <<'EOF'
2026-03-09T20:24:51Z sshd: Accepted publickey for deploy from 198.51.100.77
2026-03-09T20:27:12Z crontab: (deploy) REPLACE (deploy)
EOF
cat > fw.log <<'EOF'
1773087984 ALLOW 198.51.100.77 to shop-web-01:22
EOF
utc() { date -u -d "$1" +%Y-%m-%dT%H:%M:%SZ; }
{
  while read -r ip _ _ ts tz rest; do
    t=${ts#[}; day=${t%%:*}; clock=${t#*:}
    printf '%s web  %s %s\n' "$(utc "${day//\// } $clock ${tz%]}")" "$ip" "$rest"
  done < web.log
  while read -r t rest; do
    printf '%s auth %s\n' "$t" "$rest"
  done < auth.log
  while read -r e rest; do
    printf '%s fw   %s\n' "$(utc "@$e")" "$rest"
  done < fw.log
} | sort
cd /; rm -rf "$d"

পরের block বেশি উৎস নিয়ে উৎস-ভিত্তিক timezone আর ঘড়ির সংশোধন যোগ করে। প্রতিটি সারিতে আগের ঘটনা থেকে কত সেকেন্ড পরে, সেটিও দেখায়।

// toy নমুনা: সব ডেটা কাল্পনিক। উৎস ভেদে timezone আর ঘড়ি আলাদা
const sources = {
  web:  { offsetMin: 360, fixSec: 94 }, // +0600, host ঘড়ি 94 s পিছিয়ে
  app:  { offsetMin: 360, fixSec: 94 },
  auth: { offsetMin: 0,   fixSec: 94 }, // UTC, কিন্তু একই host ঘড়ি
  file: { offsetMin: 0,   fixSec: 94 },
  fw:   { offsetMin: 0,   fixSec: 0  }, // UTC, ঘড়ি NTP-তে মেলানো
};
const raw = [
  ['fw',   '2026-03-09T20:44:02', '198.51.100.77 out 48211900 B'],
  ['auth', '2026-03-09T20:27:12', 'crontab REPLACE (deploy)'],
  ['web',  '2026-03-10T02:14:07', 'POST /admin/upload 200'],
  ['file', '2026-03-09T20:19:40', 'authorized_keys mtime'],
  ['app',  '2026-03-10T02:13:40', 'session staff-04 203.0.113.45'],
  ['fw',   '2026-03-09T20:26:24', 'ALLOW 198.51.100.77 to :22'],
  ['web',  '2026-03-10T02:16:33', 'GET /uploads/img_7731.php 200'],
  ['auth', '2026-03-09T20:24:51', 'Accepted publickey deploy'],
  ['file', '2026-03-09T20:14:08', 'img_7731.php ctime'],
  ['app',  '2026-03-10T02:41:18', 'export customers rows=1842'],
];
function toUtcMs(src, stamp) {
  const s = sources[src];
  const asIfUtc = Date.parse(stamp + 'Z');
  return asIfUtc - s.offsetMin * 60000 + s.fixSec * 1000;
}
const rows = raw.map(([src, stamp, msg]) => ({ src, msg, ms: toUtcMs(src, stamp) }));
rows.sort((a, b) => a.ms - b.ms);
let prev = null;
for (const r of rows) {
  const clock = new Date(r.ms).toISOString().slice(11, 19) + 'Z';
  const delta = prev === null ? '' : ' +' + (r.ms - prev) / 1000 + 's';
  console.log(clock, r.src.padEnd(4), r.msg + delta);
  prev = r.ms;
}

৮ · একটি পুরো timeline — ছোট web server-এর কাল্পনিক ঘটনা

পটভূমি (নমুনা): একটি কাল্পনিক অনলাইন বাজারের একটি server shop-web-01. ১০ মার্চ সকালে বাইরের firewall রিপোর্টে আগের রাতে অস্বাভাবিক বড় outbound transfer দেখা গেল। Hosting কর্মীরা ততক্ষণে server restart দিয়েছেন, তাই memory-র প্রমাণ নেই। দলের হাতে আছে disk image, local log, কেন্দ্রীয় log server-এর কপি, firewall log আর release-এর নথি। সব সময় ঘড়ি ঠিক করা UTC-তে। ঘটনার কৌশল নয়, শুধু প্রমাণের পথ দেখানো হচ্ছে।

Pivoting: এক সূত্র থেকে পরের সূত্রে

Pivoting মানে হাতের তথ্য থেকে পাশের উৎসে যাওয়া। হাতিয়ার চারটি: সময়, ঠিকানা, account, আর file path. দল শুরু করল web log-এর একটি অদ্ভুত সারি থেকে।

20:18:07Z 203.0.113.45
GET /uploads/img_7731.php 200
uploads-এ ছবি থাকার কথা, script নয়

20:26:25Z sshd: Accepted publickey
for deploy from 198.51.100.77
এই ঠিকানা আগে কখনো দেখা যায়নি

/home/deploy/.ssh/authorized_keys
mtime 20:21:14Z  ctime 20:21:14Z
login-এর 5 min 11 s আগে বদলেছে

20:26:24Z ALLOW in  to :22
20:44:02Z out 48211900 B, same IP
NTP-তে মেলানো, আলাদা যন্ত্র

জানা   : ঘটনার ক্রম
অনুমান : দুই ঠিকানা একই পক্ষ
অজানা  : staff-04 session কীভাবে গেল
অজানা  : file-এর ভেতরের request

Timestamp-এর দ্বন্দ্ব: দ্বিতীয় উৎস কীভাবে মেটায়

একজন সদস্য আপত্তি তুললেন, “img_7731.php-এর mtime তো ২০২৩ সালের। এটি পুরোনো file, এই ঘটনার নয়।” দ্বন্দ্বটি নিচের ধাপে মিটল।

File : uploads/img_7731.php
mtime: 2023-06-12 08:41:02
দাবি: file-টি ২০২৩ থেকেই আছে

mtime: 2023-06-12 08:41:02
ctime: 2026-03-09 20:15:42Z
Birth: 2026-03-09 20:15:42Z
একই file, দুটি গল্প

পাশের file-এর ctime (নমুনা):
img_7729.jpg  2026-02-26
img_7730.jpg  2026-03-04
Restore হলে সব এক সময়ে থাকত

web     : 20:15:41Z POST /admin/upload
release : শেষ release 2026-02-26
manifest: img_7731.php নেই

Arrived: 2026-03-09 ~20:15:42Z
Confidence: high
mtime 2023: not relied on,
cause not established

Log-এর ফাঁক খোঁজা

Log gap মানে যে সময়ে log থাকার কথা, অথচ নেই। শান্ত server-ও cron-এর কারণে নিয়মিত কিছু লেখে। তাই লম্বা নীরবতা একটি সূত্র। নিচের block local auth.log-এ ফাঁক খোঁজে, আর একই host থেকে কেন্দ্রীয় server-এ পাঠানো কপির সাথে মেলায়। এই দুটি log ঘড়ি-ঠিক-করা নয়, দুই কপিই host-এর ঘড়ির সময়।

// toy নমুনা: একই host-এর log, disk-এর কপি আর কেন্দ্রীয় কপি
const toSec = t => { const [h, m, s] = t.split(':').map(Number); return h * 3600 + m * 60 + s; };
const fmt = s => [s / 3600 | 0, (s % 3600) / 60 | 0, s % 60].map(n => String(n).padStart(2, '0')).join(':');
const LIMIT = 15 * 60;   // cron প্রতি 10 মিনিটে লেখে, তাই 15 মিনিট নীরব মানে সন্দেহ

const localLog = ['20:30:01 CRON', '20:40:01 CRON', '20:46:12 sshd session closed',
  '23:10:03 CRON', '23:20:01 CRON'];
const centralLog = ['20:30:01 CRON', '20:40:01 CRON', '20:46:12 sshd session closed',
  '20:50:01 CRON', '21:00:01 CRON', '21:02:44 sshd Accepted publickey deploy',
  '21:10:01 CRON', '21:20:01 CRON', '21:30:01 CRON', '21:40:01 CRON', '21:50:01 CRON',
  '22:00:01 CRON', '22:10:01 CRON', '22:20:01 CRON', '22:30:01 CRON', '22:40:01 CRON',
  '22:50:01 CRON', '23:00:01 CRON', '23:10:03 CRON', '23:20:01 CRON'];

function gaps(log) {
  const out = [];
  for (let i = 1; i < log.length; i++) {
    const a = toSec(log[i - 1].slice(0, 8)), b = toSec(log[i].slice(0, 8));
    if (b - a > LIMIT) out.push([a, b]);
  }
  return out;
}
console.log('local   gaps:', gaps(localLog).length, '| central gaps:', gaps(centralLog).length);
for (const [a, b] of gaps(localLog)) {
  const mins = ((b - a) / 60).toFixed(1);
  console.log(`local silent ${fmt(a)} to ${fmt(b)} (${mins} min)`);
  const inside = centralLog.filter(l => { const t = toSec(l.slice(0, 8)); return t > a && t < b; });
  console.log('central has', inside.length, 'lines inside; non-CRON lines:');
  inside.filter(l => !l.includes('CRON')).forEach(l => console.log('  ' + l));
}

৯ · Hypothesis, bias আর confidence দিয়ে finding লেখা

Timeline ঘটনা সাজায়, ব্যাখ্যা দেয় না। ব্যাখ্যার জন্য একাধিক সম্ভাবনা লিখতে হয়। Richards Heuer তাঁর Psychology of Intelligence Analysis (১৯৯৯) বইয়ে Analysis of Competing Hypotheses (ACH) পদ্ধতি বর্ণনা করেন। মূল কথা: প্রিয় ব্যাখ্যার পক্ষে প্রমাণ না গুনে, প্রতিটি প্রমাণ কোন ব্যাখ্যার বিপক্ষে যায় সেটি দেখুন। কারণ একই প্রমাণ অনেক ব্যাখ্যার সাথে মিলতে পারে, আর একটি শক্ত বিরোধী প্রমাণ একটি ব্যাখ্যাকে বাদ দিতে পারে।

নিচের toy tracker চারটি ব্যাখ্যা আর সাতটি প্রমাণ মেলায়। এখানে dpkg log-এর একটি সারিও আছে: openssl upgrade, ঠিক ঘটনার রাতে। শুরুতে এটি ভয়ের মনে হয়েছিল।

// toy নমুনা: ACH ধাঁচের hypothesis tracker. '+' পক্ষে, '-' বিপক্ষে
const hypotheses = {
  H1: 'entry through the upload feature',
  H2: 'SSH password guessing on deploy',
  H3: 'routine deployment by staff',
  H4: 'intruder installed a package',
};
const evidence = [
  ['E1 POST then new file 1 s later',        { H1: '+' }],
  ['E2 img_7731.php not in release manifest', { H1: '+', H3: '-' }],
  ['E3 key added before first SSH login',    { H1: '+' }],
  ['E4 0 failed logins in 7 days of log',    { H2: '-' }],
  ['E5 no ticket, no release that night',    { H3: '-' }],
  ['E6 openssl upgrade by nightly timer',    { H4: '-' }],
  ['E7 same upgrade job ran on 30 past days', { H4: '-' }],
];
const result = Object.keys(hypotheses).map(id => {
  const marks = evidence.filter(([, m]) => m[id]);
  const pro = marks.filter(([, m]) => m[id] === '+').map(([e]) => e.split(' ')[0]);
  const con = marks.filter(([, m]) => m[id] === '-').map(([e]) => e.split(' ')[0]);
  const status = con.length >= 2 ? 'REJECTED' : con.length === 1 ? 'WEAK' : 'STANDING';
  return { id, pro, con, status };
});
// Heuer-এর মূল কথা: কত প্রমাণ পক্ষে নয়, কত প্রমাণ বিপক্ষে, সেটি দেখুন
result.sort((a, b) => a.con.length - b.con.length);
for (const r of result) {
  console.log(`${r.id} ${r.status.padEnd(8)} ${hypotheses[r.id]}`);
  console.log(`   for: ${r.pro.join(' ') || '-'} | against: ${r.con.join(' ') || '-'}`);
}

Analyst bias: আপনার মনও একটি উৎস

Confidence-সহ finding

“হ্যাকার ডেটা চুরি করেছে” একটি বাক্য, finding নয়। ভালো finding-এ থাকে দাবি, প্রমাণ, confidence level, আর বিকল্প ব্যাখ্যা। মার্কিন গোয়েন্দা সংস্থার ICD 203 নির্দেশিকা একটি দরকারি পার্থক্য করে: ঘটনাটি কতটা সম্ভব, আর আপনার প্রমাণ কতটা শক্ত, এই দুটি আলাদা কথা। তিন স্তরের অর্থ দলে আগে ঠিক করে নিন। একটি প্রচলিত ব্যবহার নিচে দেওয়া হলো, এটি কোনো সার্বজনীন মান নয়।

সবশেষে আলাদা করে লিখুন অজানা: staff-04 session কীভাবে গেল, local log-এর ফাঁকের কারণ, আর memory না থাকায় কী দেখা যায়নি। “কোনো প্রমাণ পাইনি” আর “ঘটেনি” এক কথা নয়। এই লেখাই পরে incident response-এর সিদ্ধান্ত, গ্রাহককে জানানো আর আইনি কাজে ব্যবহার হয়। তাই অনুমানকে তথ্যের ভাষায় লিখবেন না। প্রতিরক্ষার শিক্ষাগুলোও লিখুন: uploads folder-এ script চলা বন্ধ (পর্ব ৪২), app-এর আলাদা কম-অধিকারের account, NTP নজরদারি, আর কেন্দ্রীয় log.

১০ · AI-এর যুগে forensic বিশ্লেষণ

AI লম্বা log সংক্ষেপ করতে, artifact-এর অর্থ বোঝাতে আর parser লিখতে সাহায্য করে। কিন্তু forensic কাজে ভুল বাক্যের দাম বেশি। একটি ভুল সময় বা বানানো event মানুষের চাকরি, গ্রাহকের কাছে ঘোষণা বা আইনি সিদ্ধান্তে প্রভাব ফেলতে পারে।

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

• আসল log, secret, ব্যক্তিগত ডেটা বা গ্রাহকের তথ্য অনুমোদন ছাড়া প্রম্পটে দিইনি
• AI-এর উদ্ধৃত প্রতিটি সারি মূল প্রমাণের কপিতে খুঁজে পেয়েছি
• প্রতিটি Event ID আর artifact-এর অর্থ মূল নথিতে মিলিয়েছি
• সময়ের রূপান্তর অন্তত তিনটি সারিতে হাতে হিসাব করেছি
• AI-এর বানানো parser-কে নিজের ল্যাবে নমুনা ডেটায় পরীক্ষা করেছি
• চূড়ান্ত finding আর মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত একজন মানুষ নিয়েছেন