Digital forensics — chain of custody, প্রমাণ সংরক্ষণ আর সীমা

১ · Digital forensics কী, আর incident response থেকে কোথায় আলাদা

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

Digital forensics হলো digital তথ্য চিহ্নিত করা, সংগ্রহ করা, পরীক্ষা ও বিশ্লেষণ করার বিজ্ঞানসম্মত কাজ, যেখানে তথ্যের অখণ্ডতা (integrity) রক্ষা হয় আর chain of custody লেখা থাকে। অর্থাৎ প্রমাণ কার হাতে কখন ছিল, তার পুরো হিসাব থাকে। NIST SP 800-86 (২০০৬) প্রায় এভাবেই ধারণাটি বোঝায়।

এর লক্ষ্যগুলো সহজ প্রশ্নের মতো:

• কী ঘটেছিল, কখন, কোন পথে? ঘটনার সময়রেখা আর root cause খোঁজা।
• কতটা ক্ষতি? কোন system আর কোন ডেটা ছোঁয়া হয়েছে, কোনটি হয়নি।
• প্রমাণ কি টিকবে? অন্য একজন যোগ্য পরীক্ষক একই প্রমাণ নিয়ে আপনার ফল যাচাই করতে পারবেন কি না।

সংজ্ঞা সব জায়গায় এক নয়। অনেক প্রতিষ্ঠান দুটি কাজকে একসাথে DFIR বলে, আর ছোট দলে একই মানুষ দুটিই করেন। NIST SP 800-86-এর নামেই আছে forensic কৌশলকে incident response-এর সাথে জুড়ে দেওয়ার কথা। পুরো প্রক্রিয়া পর্ব ৬১-এ, ক্ষতি থামানো পর্ব ৬২-এ, আর artifact ধরে সময়রেখা বানানো পর্ব ৬৪-এ আসবে। এই পর্বের বিষয় একটাই: প্রমাণকে এমনভাবে রাখা, যাতে পরে তার ওপর ভরসা করা যায়।

২ · আগে অনুমতি — কে, কোন অধিকারে, কতটুকু

পুলিশ যেমন ইচ্ছে হলেই কারও ঘরে তল্লাশি চালাতে পারে না, আপনিও পারেন না। Forensic দক্ষতা কোনো অধিকার দেয় না। পরীক্ষার কাজ শুরু হয় দুটি পথের একটি থেকে:

• মালিকের অনুমোদন: প্রতিষ্ঠান তার নিজের device আর account নিজের নীতি অনুযায়ী পরীক্ষা করায়, আর আপনি নিজের জিনিস পরীক্ষা করেন।
• বৈধ আইনি প্রক্রিয়া: আইন যাঁদের ক্ষমতা দিয়েছে, তাঁরা আদালত বা আইনের নির্ধারিত পথে কাজ করেন।

এর বাইরে প্রাক্তন সঙ্গীর ফোন, সহকর্মীর email বা প্রতিদ্বন্দ্বীর server “শুধু দেখা” চলে না, উদ্দেশ্য যত ভালোই হোক। অনুমতি ছাড়া প্রবেশ অপরাধ হতে পারে। আইনি সীমা আর লিখিত অনুমতি নিয়ে বিস্তারিত দেখুন পর্ব ৬-এ।

অনুমোদনের কাগজে যা থাকে

• কোন device, account বা log, আর তার মালিক কে
• উদ্দেশ্য, সময়সীমা আর কোন তারিখের ডেটা দেখা যাবে
• কারা কাজ করবেন, কে অনুমোদন দিলেন, কখন
• কী বাদ থাকবে, আর নতুন কিছু পেলে কার কাছে যাবেন
• ফল কে দেখবেন, প্রমাণ কতদিন থাকবে, পরে কীভাবে মুছবে

Privacy আর সীমা

একটি forensic image সবকিছুই তুলে আনে। অফিসের ফাইলের সাথে আসতে পারে ব্যক্তিগত ছবি, চিকিৎসার কাগজ বা বেতনের হিসাব। Image নেওয়া মানে সব পড়ার অনুমতি নয়। তাই scope-এর ভেতরেই খুঁজুন, প্রমাণ দেখার অধিকার অল্প কয়েকজনে রাখুন, আর কাজ শেষে নির্ধারিত নিয়মে মুছুন। ব্যক্তিগত device-এর (BYOD) জন্য আলাদা সম্মতি বা আইনি পথ লাগতে পারে। ডেটা-সংক্রান্ত আইন আর নীতি পর্ব ৭০-এ আসবে।

আরেকটি প্রস্তুতির নাম legal hold. মামলা বা তদন্তের সম্ভাবনা দেখা দিলে নিয়মিত মুছে ফেলার কাজ সংশ্লিষ্ট ডেটায় বন্ধ রাখতে হয়, আর এই সিদ্ধান্ত আসে আইন বিভাগের কাছ থেকে।

এবার একটি কাল্পনিক ঘটনা। একটি অনলাইন বাজারের হিসাব বিভাগের অফিসের laptop থেকে অস্বাভাবিক upload দেখা গেছে। Laptop প্রতিষ্ঠানের নিজের। ধাপে ধাপে দেখুন:

device  : LT-0231, company owned
purpose : unusual upload on 10 March
data    : work files, 1 to 10 March
not in  : personal folder, unless legal approves
by      : Head of Legal (signed)

state   : powered on, screen locked
network : Wi-Fi connected
cables  : charger only
photos  : front, side, serial label
clock   : device 120 s ahead of reference

disk    : full-disk encryption is on
risk    : power off may lose memory evidence
choice  : memory capture first, by trained staff
account : approved admin account
record  : tool, version, start and end time

item    : E-01
what    : laptop, serial LT-0231
extra   : charger E-02
power   : shut down as per playbook

bag     : tamper-evident, seal S-5521
signed  : IT officer, across the seal
photo   : sealed bag with number visible

#1  2026-03-10T10:20Z
from IT-Officer  to Examiner-A
item E-01  seal S-5521  intact
signed by both

৩ · NIST SP 800-86-এর চার ধাপ

পুরোনো ফাইল ঘেঁটে হিসাব মেলানোর মতোই forensics একটি ধারাবাহিক কাজ। NIST SP 800-86 (Kent ও সহলেখকেরা, ২০০৬) চারটি ধাপ দেখায়:

• Collection: কোন উৎসে প্রমাণ থাকতে পারে তা খোঁজা, তারপর অখণ্ডতা রেখে সংগ্রহ করা।
• Examination: বিশাল ডেটা থেকে দরকারি অংশ বের করা। যেমন অসংখ্য ফাইলের মধ্যে ১০ মার্চের upload-সংক্রান্ত log.
• Analysis: “কে, কী, কখন, কীভাবে” প্রশ্নের উত্তর খোঁজা। ভালো পরীক্ষক শুধু নিজের ধারণার পক্ষে নয়, বিপক্ষের প্রমাণও খোঁজেন।
• Reporting: যা পাওয়া গেল, যেভাবে পাওয়া গেল, আর যা বলা যায় না, তা স্পষ্ট করে জানানো।

RFC 3227 (BCP 55, ২০০২) বলে, computer প্রমাণকে পাঁচটি গুণ ধরে ভাবতে হয়:

৪ · Order of volatility — live response না dead-box

বাজার থেকে একসাথে বরফ, মাছ আর চাল আনলে আগে কোনটি সামলান? যেটি আগে নষ্ট হবে। প্রমাণও তাই। Volatile data বিদ্যুৎ গেলে বা সময়ে হারিয়ে যায়। RFC 3227 এই ক্রমকে বলে order of volatility:

এই তালিকা ২০০২ সালের, আর এটি পথনির্দেশ, চিরন্তন আইন নয়। RFC-র ক্রমে remote log পাঁচে। কিন্তু একটি SaaS সেবা যদি log মাত্র ৭ দিন রাখে, আর ৬ দিন পেরিয়ে গেছে, তাহলে সেটি disk-এর চেয়ে জরুরি। নিচের toy planner দুটি ক্রম পাশাপাশি দেখায়। এখানে কিছুই সংগ্রহ হয় না, সব তথ্য বানানো।

// Toy collection planner. Sources are made up; nothing is collected here.
// rank follows the RFC 3227 order (1 = most volatile). hoursLeft = our estimate.
const sources = [
  { name: "backup tape, last week",  rank: 7, hoursLeft: 8760, inScope: true },
  { name: "system disk",             rank: 4, hoursLeft: 720,  inScope: true },
  { name: "SaaS audit log",          rank: 5, hoursLeft: 24,   inScope: true },
  { name: "RAM of the laptop",       rank: 2, hoursLeft: 1,    inScope: true },
  { name: "temp folder",             rank: 3, hoursLeft: 12,   inScope: true },
  { name: "network connection list", rank: 2, hoursLeft: 0.5,  inScope: true },
  { name: "staff personal phone",    rank: 4, hoursLeft: 72,   inScope: false },
];
const URGENT_HOURS = 48;

const allowed = sources.filter(s => s.inScope);
const skipped = sources.filter(s => !s.inScope);
const byRank = [...allowed].sort((a, b) => a.rank - b.rank || a.hoursLeft - b.hoursLeft);

console.log("Plan by RFC 3227 rank:");
byRank.forEach((s, i) => {
  const flag = s.rank >= 4 && s.hoursLeft <= URGENT_HOURS ? "  <-- deadline!" : "";
  console.log(`${i + 1}. [rank ${s.rank}] ${s.name} (${s.hoursLeft} h)${flag}`);
});

const byDeadline = [...allowed].sort((a, b) => a.hoursLeft - b.hoursLeft);
console.log("\nPlan by estimated time left:");
byDeadline.forEach((s, i) => console.log(`${i + 1}. ${s.name} (${s.hoursLeft} h)`));

console.log("\nNot collected, outside written scope:");
skipped.forEach(s => console.log("- " + s.name + ": ask for separate authority"));

Live response বনাম dead-box

একসময় অনেক নির্দেশিকায় বলা হতো, প্লাগ টেনে দিন। আজ full-disk encryption, memory-তে চলা malware আর cloud-এর যুগে একটিমাত্র নিয়ম চলে না। কোন system-এ কী করবেন, তা ঘটনার আগেই playbook-এ ঠিক করে রাখুন। ঘটনার সময় নতুন করে ভাবার সময় থাকে না।

Memory acquisition

RAM-এর একটি কপি নেওয়াকে memory acquisition বলে। এতে পাওয়া যেতে পারে চালু process, network সংযোগ, খোলা ফাইলের টুকরো, যা disk-এ নেই। Disk image-এর মতো এটি স্থির ছবি নয়, কারণ কপির সময়েও RAM বদলাতে থাকে। ধরুন ৩২ GB RAM, কপির গতি ৫০০ MB/s. তাহলে ৩২,০০০ ÷ ৫০০ = ৬৪ সেকেন্ড লাগবে, আর এই সময়ে শুরুর অংশ আর শেষের অংশ ভিন্ন মুহূর্তের। একে smear বলা হয়। Tool নিজেও memory-র কিছু জায়গা নেয়। তাই একই ফল আর কখনো পাওয়া যাবে না। Hash শুধু বলে, কপি নেওয়ার পর সেটি বদলায়নি। RAM-এ কী খুঁজবেন, সেটি পর্ব ৬৪-এর বিষয়।

৫ · Forensic soundness — write blocker, copy, hash, verify

ব্যাংকের মূল দলিল কেউ আঁকিবুঁকি করে পড়েন না। সার্টিফায়েড কপি নিয়ে কাজ হয়, আর মূলটি লকারে থাকে। Forensics-এও তা-ই। Forensic soundness মানে এমনভাবে কাজ করা, যাতে প্রমাণ না বদলায়, আর অনিবার্য বদল জানা ও ব্যাখ্যা করা থাকে। এটি “কখনো শূন্য পরিবর্তন” বলে না, বলে “কোনো পরিবর্তন অজানা নয়।”

• Write blocker: Hardware বা software, যা পড়তে দেয় কিন্তু disk-এ লিখতে দেয় না। সাধারণ computer-এ disk জুড়লে OS নিজে থেকেই কিছু লিখে দিতে পারে। NIST-এর CFTT প্রকল্প এ ধরনের tool পরীক্ষা করে রিপোর্ট দেয়।
• Forensic image: Disk-এর bit-for-bit কপি। শুধু দেখা যায় এমন ফাইল নয়, ফাঁকা বলে চিহ্নিত অংশও এতে আসে, যা সাধারণ copy-paste-এ আসে না।
• SHA-256: পর্ব ৯-এর hash function, যা বড় ডেটার ছোট আঙুলের ছাপ দেয়।
• Verification: Image-এর hash আবার হিসাব করে মূলের সাথে মেলানো।
• Working copy: Master image তালাবদ্ধ থাকে, পরীক্ষক কাজ করেন আরেকটি কপিতে। ভুল হলে নতুন কপি নেওয়া যায়।

নিচের কোডে সত্যিকারের hashlib ব্যবহার হয়েছে, তবে “image”-টি ৪,০৯৬ byte-এর বানানো ডেটা। কোনো আসল disk ছোঁয়া হয় না।

# Fake evidence image: bytes built in memory, no real disk or real data.
import hashlib

def sha256(data):
    return hashlib.sha256(data).hexdigest()

pattern = b"FAKE-EVIDENCE-IMAGE-TOY-DATA-ONLY "
image = (pattern * 200)[:4096]          # 8 sectors of 512 bytes
acquired = sha256(image)
print("size            :", len(image), "bytes")
print("acquisition hash:", acquired)

copy_ok = bytes(image)                  # toy "working copy"
print("copy 1 verify   :", "MATCH" if sha256(copy_ok) == acquired else "MISMATCH")

changed = bytearray(image)
changed[1000] ^= 0x01                   # one bit of one byte changes
copy_bad = bytes(changed)
new_hash = sha256(copy_bad)
print("copy 2 hash     :", new_hash)
print("copy 2 verify   :", "MATCH" if new_hash == acquired else "MISMATCH")

a = int(acquired, 16)
b = int(new_hash, 16)
print("hash bits differ:", bin(a ^ b).count("1"), "of 256")

def sector_hashes(data, size=512):
    return [sha256(data[i:i + size]) for i in range(0, len(data), size)]

good = sector_hashes(image)
bad = sector_hashes(copy_bad)
diff = [i for i, (x, y) in enumerate(zip(good, bad)) if x != y]
print("sectors changed :", diff, "of", len(good))

কত সময় লাগে, আর hash কতটা ভরসার

গণনা ১: ১ TB disk, গতি ২০০ MB/s. ১,০০০,০০০ MB ÷ ২০০ = ৫,০০০ সেকেন্ড, অর্থাৎ প্রায় ৮৩ মিনিট। Verification-এর জন্য আবার পুরো disk পড়লে সময় প্রায় দ্বিগুণ হয়।

গণনা ২: ধরুন আপনার কাছে ২^৪০টি ফাইল (এক লক্ষ কোটির বেশি)। SHA-256-এর আউটপুট ২৫৬ bit. Birthday bound অনুযায়ী দুটি ফাইলের দৈবাৎ একই hash হওয়ার সম্ভাবনা মোটামুটি n² ÷ ২^২৫৭ = ২^৮০ ÷ ২^২৫৭ = ২^−১৭৭. বাস্তবে ধরে নেওয়া যায়, দৈব মিল হবে না।

নিজের একটি ফাইলে এই অভ্যাসটি করে দেখতে পারেন। কমান্ডগুলো শুধু আপনার নিজের ফাইলের জন্য:

# Linux: record the hash, then verify it later
sha256sum my-notes.txt > my-notes.sha256
sha256sum -c my-notes.sha256

# Windows PowerShell
Get-FileHash -Algorithm SHA256 my-notes.txt

৬ · Chain of custody — প্রমাণের হাজিরা খাতা

অফিসের রেজিস্টার খাতায় যেমন লেখা থাকে কে কখন চাবি নিলেন আর ফেরত দিলেন, chain of custody ঠিক তেমনই। প্রশ্ন একটাই: সংগ্রহ থেকে আদালত পর্যন্ত প্রতিটি মুহূর্তে প্রমাণ কার দায়িত্বে ছিল? প্রতিটি হস্তান্তরে একজন দেন, একজন নেন, দুজনেই সই করেন। পরের লাইনের “দিলেন” আগের লাইনের “নিলেন”-এর সাথে মিলতে হবে।

একই খাতায় ফাঁক দেখা দিলে কী হয়, ধাপে ধাপে দেখুন। লাইন ৩-এর পর পরীক্ষক ক laptop নিয়েছেন। কিন্তু পরের দিন লকারে জমা দিলেন পরীক্ষক খ।

#1 10 Mar 10:20  IT-Officer -> Examiner-A
#2 10 Mar 11:05  Examiner-A -> Locker-7
#3 10 Mar 18:30  Locker-7   -> Examiner-A

#3 10 Mar 18:30  Locker-7   -> Examiner-A
#4 11 Mar 09:10  Examiner-B -> Locker-7
gap: 14 h 40 min, holder unknown

hash now   : fce63572...69e8
hash before: fce63572...69e8   MATCH
known      : image bits are unchanged
unknown    : who held it, who saw the data

do not back-fill the form
ask both examiners, write what they say
check locker record and door camera
add a dated memo, signed by the writer

not automatically useless
weight may fall, or it may be refused
depends on the law and the facts
report must state the gap openly

এই পরীক্ষাগুলো যন্ত্রেও করা যায়। নিচে toy log-এর একটি যাচাইকারী। সব নাম আর hash বানানো।

// Toy chain-of-custody checker. Roles and hash tags are invented.
const HASH_AT_SEIZURE = "a1b2c3";
const log = [
  { n: 1, t: "2026-03-10T10:20Z", from: "IT-Officer", to: "Examiner-A", hash: "a1b2c3", signed: true },
  { n: 2, t: "2026-03-10T11:05Z", from: "Examiner-A", to: "Locker-7", hash: "a1b2c3", signed: true },
  { n: 3, t: "2026-03-10T18:30Z", from: "Locker-7", to: "Examiner-A", hash: "a1b2c3", signed: true },
  { n: 4, t: "2026-03-11T09:10Z", from: "Examiner-B", to: "Locker-7", hash: "a1b2c3", signed: true },
  { n: 6, t: "2026-03-11T14:00Z", from: "Locker-7", to: "Examiner-B", hash: "a1b2c3", signed: false },
  { n: 7, t: "2026-03-11T13:50Z", from: "Examiner-B", to: "Courier", hash: "ffff00", signed: true },
];

function check(entries) {
  const found = [];
  entries.forEach((e, i) => {
    if (!e.signed) found.push(`entry ${e.n}: no signature`);
    if (e.hash !== HASH_AT_SEIZURE) found.push(`entry ${e.n}: hash ${e.hash} differs from seizure hash`);
    if (i === 0) return;
    const prev = entries[i - 1];
    if (e.n !== prev.n + 1) found.push(`entry ${e.n}: number jumps from ${prev.n}`);
    if (e.from !== prev.to) found.push(`entry ${e.n}: gap, ${prev.to} had it, but ${e.from} handed it over`);
    if (Date.parse(e.t) <= Date.parse(prev.t)) found.push(`entry ${e.n}: time goes backwards`);
  });
  return found;
}

const clean = log.slice(0, 3);
console.log("entries 1-3:", check(clean).length, "findings");

const findings = check(log);
console.log("all entries:", findings.length, "findings");
findings.forEach(f => console.log(" - " + f));

৭ · সময় — time zone আর timestamp-এর ফাঁদ

ঢাকার সকাল ৯টা আর লন্ডনের সকাল ৯টা এক মুহূর্ত নয়। অথচ log-এ দুটোই “09:00” দেখাতে পারে। সময় ভুল বুঝলে পুরো ঘটনার ক্রম উল্টে যায়। RFC 3227-এর পরামর্শ সহজ: system clock আর UTC-র পার্থক্য লিখুন, আর প্রতিটি timestamp UTC না স্থানীয়, তা জানান।

• ঢাকা UTC+6. ২০২৬ সালে এখানে দিনের আলো বাঁচানোর সময় (DST) নেই, কিন্তু অনেক দেশে আছে। বাংলাদেশেও ২০০৯ সালের জুন থেকে বছরের শেষ পর্যন্ত ঘড়ি এক ঘণ্টা এগিয়ে ছিল। তাই পুরোনো log-এ time zone database দেখে নিন।
• Clock skew: Device-এর ঘড়ি সঠিক সময় থেকে আগে-পিছে থাকতে পারে। প্রমাণ নেওয়ার সময়ই পার্থক্য মেপে লিখুন। NTP ঠিক থাকলে ঝামেলা কমে।
• Format আলাদা: NTFS UTC-তে সময় রাখে, FAT রাখে স্থানীয় সময়ে। পুরোনো ধাঁচের syslog লাইনে প্রায়ই বছর বা time zone থাকে না। Unix time ১৯৭০ থেকে সেকেন্ডের হিসাব।
• ফাইলের সময় মানে মানুষের কাজ নয়: Copy করলে, restore করলে বা কোনো program চললেও file timestamp বদলাতে পারে। একটি সময় দিয়ে গল্প বানাবেন না, অন্য উৎসে মিলিয়ে দেখুন।

// Toy events from four sources. offsetMin = time zone written in the notes.
// skewSec = device clock minus true time, measured when evidence was taken.
const events = [
  { src: "firewall", local: "2026-03-10 11:04:10", offsetMin: 480, skewSec: 0, what: "outbound blocked" },
  { src: "laptop",   local: "2026-03-10 09:03:30", offsetMin: 360, skewSec: 120, what: "file opened" },
  { src: "saas",     local: "2026-03-10 03:02:50", offsetMin: 0, skewSec: 0, what: "new login" },
  { src: "server",   local: "2026-03-10 03:03:05", offsetMin: 0, skewSec: 0, what: "file uploaded" },
];

function toUtcMs(e) {
  // Read the text as if UTC, then remove the zone offset and the clock error.
  const asIfUtc = Date.parse(e.local.replace(" ", "T") + "Z");
  return asIfUtc - e.offsetMin * 60000 - e.skewSec * 1000;
}
const show = ms => new Date(ms).toISOString().slice(0, 19).replace("T", " ") + " UTC";

console.log("Sorted by the raw text (wrong):");
[...events]
  .sort((a, b) => a.local.localeCompare(b.local))
  .forEach(e => console.log(`  ${e.local}  ${e.src.padEnd(8)} ${e.what}`));

console.log("Sorted after conversion to UTC:");
const fixed = events.map(e => ({ ...e, utc: toUtcMs(e) })).sort((a, b) => a.utc - b.utc);
fixed.forEach(e => console.log(`  ${show(e.utc)}  ${e.src.padEnd(8)} ${e.what}`));

const first = fixed[0].utc, last = fixed[fixed.length - 1].utc;
console.log("Span:", (last - first) / 1000, "seconds");

৮ · Cloud, SaaS আর mobile — যেখানে disk হাতে নেই

ভাড়া বাসায় চুরি হলে পুরো ভবনের CCTV আপনার হাতে থাকে না, মালিকের কাছে চাইতে হয়। Cloud-এও তাই। Provider-এর physical disk আপনি খুলে আনতে পারবেন না। Shared infrastructure-এ তা অন্য গ্রাহকের ডেটাও ছোঁবে। তাই প্রমাণের মূল উৎস হয় cloud audit log, service log আর provider-এর দেওয়া export.

ভালো অভ্যাস:

• আগেই প্রস্তুত থাকুন। পর্ব ৫৫ অনুযায়ী log আলাদা account-এ পাঠান, retention ঠিক করুন, আর কেন্দ্রীয় log চালু রাখুন। ঘটনার পরে পুরোনো log আর তৈরি করা যায় না।
• Export নথিবদ্ধ করুন। কে, কোন account দিয়ে, কোন filter আর সময়সীমায় নিলেন, time zone কী, তা লিখুন। Export পাওয়ার সাথে সাথে hash করুন।
• সীমা বলুন। এই log provider বানিয়েছে, আপনি মূল বিশ্বাসের জায়গাটি দেখছেন না। Log-এ কী ধরা পড়ে না, রিপোর্টে তা লিখুন।
• চুক্তি আর অঞ্চল দেখুন। ডেটা কোন দেশে, আর provider কী দেবে, তা আইনি প্রশ্নও। NIST IR 8006 (২০২০) cloud forensics-এর এমন অনেক সমস্যা তালিকাভুক্ত করেছে।

Mobile প্রমাণ, সংক্ষেপে

ফোন কখনো স্থির থাকে না: message আসে, app নিজে থেকে চলে, দূর থেকে মুছে দেওয়ার নির্দেশও আসতে পারে। NIST SP 800-101 Rev. 1 (২০১৪) mobile forensics-এর নির্দেশিকা। সাধারণ চর্চায় অনুমোদিত সংগ্রহের পর ফোনকে network থেকে আলাদা রাখা হয়, যেমন Faraday bag-এ। ফোনে encryption আর lock থাকে, আর ডেটার বড় অংশ থাকে cloud backup-এ। ফোনে মানুষের পুরো ব্যক্তিগত জীবন থাকে, তাই এখানে অনুমতি আর privacy সবচেয়ে কড়া। প্রতিষ্ঠানের ফোনে MDM-এর নীতি আর log কাজে আসে। ঝুঁকির দিকটি পর্ব ৩৫-এ আছে। ফোনের lock ভাঙার কোনো পদ্ধতি এই কোর্সে শেখানো হয় না।

৯ · নোট, রিপোর্ট, সাক্ষ্য আর প্রমাণের সীমা

নোটের অভ্যাস

কাজ করতে করতেই লিখুন, পরে মনে করে নয়। প্রতিটি নোটে থাকে সময় (UTC), কী করলেন, কেন করলেন, কোন tool ও version, আর কী দেখলেন। ভুল হলে মুছবেন না, দাগ দিয়ে কেটে কারণ লিখুন। লক্ষ্য একটাই: অন্য একজন আপনার নোট পড়ে একই কাজ করতে পারবেন।

রিপোর্ট

একটি ভালো রিপোর্টে থাকে সারসংক্ষেপ, অনুমোদন ও scope, প্রমাণের তালিকা ও hash, tool ও পদ্ধতি, UTC-তে সময়রেখা, পর্যবেক্ষণ, মতামত, আর সীমা। পর্যবেক্ষণ আর মতামত আলাদা রাখুন:

বিশেষজ্ঞ সাক্ষী, উঁচু স্তরে

কোনো কোনো ঘটনায় পরীক্ষককে আদালতে বা তদন্ত কমিটির সামনে expert witness হিসেবে ব্যাখ্যা করতে হতে পারে। নিয়ম দেশ অনুযায়ী আলাদা। সাধারণ শিক্ষা কয়েকটি: নিজের দক্ষতার সীমার মধ্যে থাকুন, যা জানেন না তা বলুন “জানি না”, সরল ভাষায় বলুন, আর আপনাকে যিনি নিয়োগ দিয়েছেন তাঁর পক্ষ নেওয়া আপনার কাজ নয়। আপনার ভরসা আপনার নোট। আদালত কী গ্রহণ করবে (admissibility), তা আদালতই ঠিক করেন।

প্রমাণ বদলানো যায়

Digital প্রমাণ বদলানো, মুছে ফেলা বা নষ্ট হওয়া সম্ভব। মানুষের ভুলে, স্বয়ংক্রিয় পরিষ্কারের কাজে, আবার ইচ্ছাকৃতভাবেও। একে সাধারণভাবে anti-forensics বলে। এই কোর্সে তার কোনো কৌশল শেখানো হয় না, আর প্রমাণ নষ্ট করা নিজেই গুরুতর আইনি সমস্যা হতে পারে। রক্ষকের কাজ হলো নির্ভরতা কমানো: log দ্রুত অন্য জায়গায় পাঠানো, append-only বা WORM ভাণ্ডার, একাধিক উৎসে মিলিয়ে দেখা। আর মনে রাখুন, চিহ্ন না পাওয়া মানে ঘটনা ঘটেনি, তা প্রমাণ হয় না।

Tool-এর ভূদৃশ্য

নিচের নামগুলো শুধু উদাহরণ, কোনো সুপারিশ নয়। এগুলো ব্যবহার করবেন নিজের lab-এর sample-এ, বা লিখিত অনুমোদিত কাজে। Tool পুরো প্রমাণ নয়; একটি tool-এর ফল অন্য উপায়ে মিলিয়ে দেখা ভালো অভ্যাস।

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

AI log সাজাতে, নোট গুছাতে আর রিপোর্টের ভাষা সরল করতে পারে। কিন্তু প্রমাণের বিষয়ে একটি ভুল বাক্য মানুষের চাকরি বা মামলার ফল বদলে দিতে পারে। রিপোর্টে সই করবেন আপনি, AI নয়।

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

• আসল প্রমাণ, ব্যক্তিগত তথ্য বা secret কোনো অননুমোদিত AI সেবায় দিইনি
• AI-এর উল্লেখ করা প্রতিটি standard আর আইন মূল উৎসে মিলিয়েছি
• AI যে সময় রূপান্তর করেছে, তার অন্তত দুটি হাতে যাচাই করেছি
• রিপোর্টের প্রতিটি দাবির পেছনের প্রমাণ নিজে দেখেছি
• AI কোথায় ব্যবহার হয়েছে, প্রয়োজনে তা নোটে লিখেছি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত মানুষই নিয়েছেন