অনুমোদিত penetration testing — scope, rules of engagement, রিপোর্ট আর bug bounty

১ · নিজের দরজায় নিজেই ধাক্কা দেওয়ানো কেন

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

Penetration testing বা pentest হলো সেই মহড়া। মালিকের অনুমতিতে অভিজ্ঞ মানুষ একটি সীমিত সময়ে দেখেন, দুর্বলতাগুলো বাস্তবে কতদূর গড়ায়। একটি প্রতিষ্ঠান নিজের টাকায় এটি করায় কয়েকটি কারণে:

• নকশা আর বাস্তবের ফাঁক ধরা। নীতিতে লেখা আছে “সব admin-এ MFA”, বাস্তবে একটি পুরোনো panel বাদ পড়েছে।
• বড় পরিবর্তনের আগে যাচাই। নতুন payment flow, নতুন mobile app বা cloud-এ স্থানান্তরের আগে একবার স্বাধীন চোখ।
• চুক্তি আর মানের চাহিদা। বড় client, বিমাকারী আর PCI DSS-এর মতো মান নিয়মিত পরীক্ষার প্রমাণ চাইতে পারে (পর্ব ৬৯).
• বিনিয়োগের অগ্রাধিকার। বাজেট কোথায় যাবে, তা অনুমানে নয়, প্রমাণে ঠিক করা। পর্ব ৪-এর threat model কাগজে ঝুঁকি দেখায়, pentest সেটি মিলিয়ে দেখে।
• রক্ষকদের অনুশীলন। পরীক্ষা চলার সময় SOC কী দেখল, কী দেখল না, সেটিও শেখার উপাদান।

২ · Scan, pentest, red team আর bug bounty — কোন প্রশ্নে কোনটি

চারটি কাজকে প্রায়ই এক নামে ডাকা হয়। ফলে প্রতিষ্ঠান scan-এর দাম দিয়ে pentest-এর আশা করে, বা অল্প বয়সের একটি system-এ red team চায়। একটি মহল্লার কথা ভাবুন:

প্রায়ই পাশের একটি শব্দ শুনবেন, purple team. এখানে red আর blue team একসাথে বসে, প্রতিটি কৌশল চালিয়ে দেখে detection কাজ করল কি না। লক্ষ্য লুকোচুরি নয়, দ্রুত শেখা। ক্রম হিসেবে সাধারণ পরামর্শ হলো: আগে vulnerability management, তারপর pentest, তারপর red team. Scan-এই যে ত্রুটি ধরা পড়ে, তার জন্য পেশাদার মানুষের দিন খরচ করা অপচয়।

Black, grey আর white box — পরীক্ষককে কতটা জানানো হবে

একটি প্রচলিত ভুল ধারণা হলো, black box-ই “আসল” পরীক্ষা। বাস্তব আক্রমণকারীর হাতে মাসের পর মাস সময় থাকে, আপনার পরীক্ষকের হাতে ১০ দিন। তথ্য দিলে পরীক্ষক সময় বাঁচিয়ে গভীরে যেতে পারেন। আপনি অনুমান কেনার বদলে কভারেজ কেনেন।

৩ · পদ্ধতিপত্র আর ধাপ — প্রতিটি ধাপ client-কে কী দেয়

পেশাদার কাজ ব্যক্তির খেয়ালে চলে না। একটি লিখিত পদ্ধতি অনুসরণ করলে দুটি লাভ হয়: কাজ পুনরাবৃত্তি করা যায়, আর client জানেন কী দেখা হয়েছে। তিনটি পরিচিত নথির ধাপের নাম জেনে রাখুন। এদের ভেতরের কৌশল এই কোর্সের বিষয় নয়।

নিচের ছবিতে PTES-এর ধাপগুলো ধারণা হিসেবে সাজানো। বাঁ পাশে ধাপ, ডান পাশে client-এর হাতে যা আসে। ব্যবস্থাপক হিসেবে এই ডান পাশটিই আপনার দেখার জিনিস।

Exploitation শব্দটি শুনে ভয় পাওয়ার কিছু নেই, আবার হালকাভাবে নেওয়ারও কিছু নেই। অনুমোদিত কাজে এর উদ্দেশ্য প্রমাণ, ক্ষতি নয়। সবচেয়ে ছোট যে কাজে ত্রুটিটি প্রমাণ হয়, সেখানেই থামা হয়। এই কাজে scanner, web proxy বা exploitation framework-এর মতো টুল ব্যবহৃত হয়, যেমন Nmap, Burp Suite, Metasploit নামগুলো শুনবেন। এগুলো অনুমোদিত কাজে থাকে বলেই শুধু নাম বললাম। এই কোর্স এদের ব্যবহার শেখায় না।

৪ · কাজ শুরুর আগে — scope থেকে স্বাক্ষর

একটি pentest-এর ভালো-মন্দ অনেকটাই ঠিক হয়ে যায় প্রথম কি-বোর্ড ছোঁয়ার আগে। Scope আর লিখিত অনুমতির মূল উপাদান পর্ব ৬-এ দেখেছেন। এখানে দেখব, কাগজগুলো কে, কখন, কোন ক্রমে তৈরি করেন। নিচের কাল্পনিক অনলাইন বাজারের অনুরোধটি স্বাক্ষর পর্যন্ত নিয়ে যান।

From   : Head of Technology, Bazaar Ltd
Reason : new checkout goes live next quarter
Goal   : can one customer reach another's orders?

Assets : web shop, customer API
Type   : grey box, two test accounts
Effort : 10 tester-days (assumed)
Env    : staging first, production read-only review

shop.example.com  owner: Bazaar Ltd     in
api.example.com   owner: Bazaar Ltd     in
pay.example.net   owner: Payment Vendor OUT
cloud host        provider policy read: yes

NDA signed by both sides
Statement of work: scope, price, deliverables
Liability and insurance reviewed by counsel

Window : 22:00-06:00 Asia/Dhaka
Banned : load tests, social engineering
Tester IPs shared with SOC: 203.0.113.10
Stop   : see stop-condition list
Contact: duty engineer, 24 hours

AUTH-2026-021 signed by system owner
Restore test: passed last week
Change freeze checked: none in window
Decision: GO on 2026-11-08 22:00

RoE-তে যা অবশ্যই ভাবতে হবে

এবার একটি ছোট simulator. এটি একটি বানানো scope document পড়ে বলে কাজ শুরু করা যাবে কি না। কোনো network নেই, শুধু কয়েকটি মান। খেয়াল করুন, প্রতিটি host-এর মালিকের স্বাক্ষরও এটি মিলিয়ে দেখে।

// Toy readiness check on a fictional scope document. No network, no real target.
const checks = [
  ['letter',    'signed authorisation letter'],
  ['roe',       'rules of engagement agreed'],
  ['window',    'time window with time zone'],
  ['contacts',  'emergency contacts on both sides'],
  ['stopRules', 'stop conditions written'],
  ['dataRules', 'evidence and data handling rules'],
  ['backup',    'recent restore test for production'],
];
function review(doc) {
  const blockers = checks.filter(([k]) => !doc[k]).map(([, label]) => label);
  // Every host needs an owner who has signed. Unknown owner means blocked.
  for (const h of doc.scope) {
    if (!doc.signedBy.includes(h.owner)) {
      blockers.push(`no signature from ${h.owner} for ${h.host}`);
    }
  }
  console.log(`${doc.name}: ${doc.scope.length} hosts, ${blockers.length} blocker(s)`);
  blockers.forEach(b => console.log('  BLOCK ' + b));
  console.log('  => ' + (blockers.length ? 'NOT READY, do not start' : 'READY for go/no-go'));
}
const draft = {
  name: 'Draft v1', letter: true, roe: true, window: false, contacts: true,
  stopRules: false, dataRules: true, backup: true,
  signedBy: ['Bazaar Ltd'],
  scope: [
    { host: 'shop.example.com', owner: 'Bazaar Ltd' },
    { host: 'api.example.com',  owner: 'Bazaar Ltd' },
    { host: 'pay.example.net',  owner: 'Payment Vendor' },
  ],
};
review(draft);
review({ ...draft, name: 'Draft v2', window: true, stopRules: true,
         scope: draft.scope.filter(h => h.owner === 'Bazaar Ltd') });

৫ · কাজ চলার সময় — প্রমাণ, সংবেদনশীল ডেটা আর থামার শর্ত

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

প্রমাণ রাখার নিয়ম

• কার্যবিবরণী। কে, কখন, কোন host-এ, কী করলেন, সবই সময়সহ লিখুন। অফিসের রেজিস্টার খাতার মতো। কোনো গোলমাল হলে এই খাতাই দেখায় কোনটি পরীক্ষকের কাজ, কোনটি নয়।
• ন্যূনতম প্রমাণ। ত্রুটি প্রমাণ করতে একটি নিজের test record যথেষ্ট হলে আসল গ্রাহকের দিকে যাবেন না। কত record আছে, তা গোনার জন্য সেগুলো নামানোর দরকার নেই।
• ঢেকে রাখা। Screenshot-এ নাম, ফোন, token ঢেকে দিন। ঢাকা মানে পিক্সেল সত্যিই মুছে ফেলা, ওপরে আধা-স্বচ্ছ দাগ নয়।
• এনক্রিপ্ট আর মেয়াদ। প্রমাণ এনক্রিপ্ট করা জায়গায়, সীমিত মানুষের হাতে। চুক্তির দিন পার হলে মুছে সেই কথা লিখিত জানানো।
• পরিষ্কার করে যাওয়া। Test account, পরীক্ষার ফাইল বা কনফিগারেশন যা তৈরি হলো, তার তালিকা রেখে শেষে সরানো, অথবা client-কে জানানো।

আইনি মামলার সম্ভাবনা থাকলে chain of custody লাগতে পারে, যা পর্ব ৬৩-তে আসবে। সাধারণ pentest-এর প্রমাণ forensic মানের হয় না, তবে সময়, উৎস আর সততা সেখানেও জরুরি।

Stop condition — কখন সঙ্গে সঙ্গে থামবেন

কিছু ঘটনায় “কাজটা শেষ করে জানাই” চলে না। এগুলো RoE-তে আগেই লেখা থাকে, আর যেকোনো পক্ষ থামাতে পারেন।

এবার একটি থামার ঘটনা ধাপে ধাপে দেখুন। ঘড়ি কাল্পনিক, ঘটনাও কাল্পনিক। পরীক্ষকের হাতে আগেই এমন একটি পদক্ষেপ তালিকা আছে বলে, রাত দুটোয়ও তিনি অনুমান করেন না।

02:05 reviewing staging admin roles, test account only
in scope: yes   window: yes

02:05 reviewing staging admin roles, test account only
02:14 unknown admin account "svc_tmp9", created 3 days ago
      no ticket, not ours, not in the handover list

02:14 unknown admin account "svc_tmp9"
02:15 STOP. all activity paused. nothing changed or deleted
account not opened, not disabled, not explored

02:15 STOP. all activity paused
02:19 phoned duty engineer (RoE contact 1), reached
      said: possible real intruder, tester IP 203.0.113.10

02:40 IR lead takes over
      received: tester log, source IP, time window
      result: tester actions separated from unknown actor

Testing paused 02:15 until IR lead confirms.
Addendum to AUTH-2026-021: window extended 2 nights.
Report: event recorded, details with IR team.

৬ · রিপোর্ট — যে নথির জন্য টাকা দেওয়া হয়

পরীক্ষা যত ভালোই হোক, রিপোর্ট দুর্বল হলে client-এর হাতে কিছুই থাকে না। একই রিপোর্ট দুই ধরনের পাঠক পড়েন, তাই দুটি স্তর লাগে।

“সীমাবদ্ধতা” অংশটি ছোট মনে হলেও সততার পরীক্ষা। কোন জিনিস দেখা হয়নি, কেন হয়নি, সেটি স্পষ্ট লিখুন। না লিখলে পাঠক ধরে নেবেন সবই দেখা হয়েছে।

Severity — CVSS আর ব্যবসার ঝুঁকি

CVSS একটি প্রযুক্তিগত তীব্রতা মাপে, যার পূর্ণ হিসাব পর্ব ৩২-এ করেছেন। আমাদের কাল্পনিক finding-এর vector হলো CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. অর্থাৎ network থেকে, সহজে, সাধারণ login দিয়ে, গোপনীয়তার বড় ক্ষতি। হিসাবটি মিলিয়ে নিন:

• ISS = 1 − (1 − 0.56) × 1 × 1 = 0.56, তাই Impact = 6.42 × 0.56 = 3.5952.
• Exploitability = 8.22 × 0.85 × 0.77 × 0.62 × 0.85 = 2.8353.
• যোগফল 6.4305, রাউন্ড-আপে 6.5, Medium.

কিন্তু CVSS জানে না যে এই ডেটা হাজার গ্রাহকের ঠিকানা আর কেনাকাটার হিসাব। FIRST-ও স্পষ্ট বলে, base score ঝুঁকি মাপার একক নয়। তাই অনেক রিপোর্টে পাশে থাকে একটি risk matrix: likelihood × impact, ১ থেকে ৫ স্কেলে (পর্ব ২). আমরা ধরলাম likelihood 4, কারণ যেকোনো গ্রাহক এটি করতে পারেন; impact 4, কারণ ব্যক্তিগত তথ্য। ফল ৪ × ৪ = ১৬। আমাদের বানানো স্কেলে ১৭–২৫ Critical, ১০–১৬ High, ৫–৯ Medium, ১–৪ Low. তাই ফল High. স্কেল প্রতিষ্ঠানভেদে আলাদা, সেজন্য রিপোর্টে স্কেলটি লিখে দিতে হয়। পরীক্ষক প্রস্তাব করেন, চূড়ান্ত ব্যবসায়িক ঝুঁকি মেনে নেন risk owner.

একটি finding লেখা — প্রমাণ থেকে সমাধান

নিচে একটি broken access control finding তৈরি হচ্ছে। ত্রুটির ধারণা আর প্রতিরক্ষা আছে পর্ব ৩৮-এ। এখানে দেখুন লেখার প্রক্রিয়া। সব নাম আর মান বানানো, কাজটি পরীক্ষকের নিজের দুটি test account-এ সীমিত।

Signed in as test-a. Viewed invoice owned by test-b.
Server returned test-b's invoice. Expected: denied.

Both accounts are ours. One confirmation only.
No other invoice numbers were tried.
No real customer record was opened.

Time   : 2026-11-09 22:41 Asia/Dhaka
Item   : screenshot, address field masked
SHA-256: recorded in evidence log
Retain : deleted 30 days after final report

CVSS 3.1 base : 6.5 Medium
Likelihood    : 4   any signed-in customer
Impact        : 4   personal data
Risk          : 4 x 4 = 16, High (scale in appendix)

Title : Customers can read each other's invoices
Asset : api.example.com, invoice endpoint
Impact: names, addresses and orders of any customer
        could be exposed to any signed-in customer

Fix   : check on the server that invoice.owner = session.user
Test  : add a regression test with two users
Detect: alert on many denied invoice lookups
Retest: requested after the fix ships

চূড়ান্ত finding-টি রিপোর্টে এমন দেখায়। “পুনরুৎপাদন” অংশটি মালিকের জন্য লেখা, যাতে তাঁর developer নিজের staging-এ নিজের দুটি account দিয়ে সমস্যাটি দেখতে পান।

উদাহরণ (কাল্পনিক finding, কোনো বাস্তব system নয়)
F-01  Customers can read each other's invoices
মাত্রা     : High (risk 16). CVSS 3.1 base 6.5 Medium
Asset      : api.example.com, invoice endpoint (staging)
প্রভাব     : যেকোনো login করা গ্রাহক অন্য গ্রাহকের নাম, ঠিকানা আর
             কেনাকাটার তথ্য দেখতে পারেন।
পুনরুৎপাদন: staging-এ দুটি test account নিন। প্রথম account দিয়ে
             দ্বিতীয় account-এর invoice দেখার চেষ্টা করুন।
             প্রত্যাশিত ফল প্রত্যাখ্যান, প্রাপ্ত ফল invoice.
প্রমাণ     : E-07
সমাধান    : প্রতিটি invoice অনুরোধে server-এ মালিকানা যাচাই করুন।
             দুই ব্যবহারকারীর regression test যোগ করুন।
সূত্র      : OWASP Top 10 (Broken Access Control), CWE-639
অবস্থা    : Open, retest বাকি

রিপোর্টের ক্রম সাজানো

পাঁচটি বানানো finding দুইভাবে সাজিয়ে দেখি। CVSS সংখ্যাগুলো উদাহরণ মাত্র।

// Toy report ordering. CVSS numbers are illustrative; likelihood and impact
// (1 to 5) are the client's business view of a fictional shop.
const band = r => r >= 17 ? 'Critical' : r >= 10 ? 'High' : r >= 5 ? 'Medium' : 'Low';
const findings = [
  { id: 'F-01', cvss: 6.5, like: 4, imp: 4, title: 'Other customers invoices readable' },
  { id: 'F-02', cvss: 5.3, like: 4, imp: 2, title: 'Stack trace in error page' },
  { id: 'F-03', cvss: 8.1, like: 3, imp: 5, title: 'Admin panel without MFA' },
  { id: 'F-04', cvss: 3.7, like: 1, imp: 2, title: 'Old TLS version on staging' },
  { id: 'F-05', cvss: 9.8, like: 2, imp: 3, title: 'Unpatched isolated build host' },
];
for (const f of findings) { f.risk = f.like * f.imp; f.rating = band(f.risk); }

const line = f => `${f.id}  cvss ${f.cvss.toFixed(1)}  risk ${String(f.risk).padStart(2)} ` +
                  `${f.rating.padEnd(8)} ${f.title}`;
console.log('Order by CVSS alone:');
[...findings].sort((a, b) => b.cvss - a.cvss).forEach(f => console.log('  ' + line(f)));

console.log('Report order (risk, then CVSS):');
const report = [...findings].sort((a, b) => b.risk - a.risk || b.cvss - a.cvss);
report.forEach((f, i) => console.log(`${i + 1} ` + line(f)));

const count = {};
report.forEach(f => count[f.rating] = (count[f.rating] || 0) + 1);
console.log('Summary:', JSON.stringify(count));

৭ · Developer-এর সাথে কাজ, retest আর বন্ধ করা

রিপোর্ট দেওয়া মানে কাজ শেষ নয়। অনেক প্রতিষ্ঠানে রিপোর্ট আসে, ভয় ছড়ায়, তারপর ফাইলে পড়ে থাকে। Finding-কে কাজে বদলানোর কিছু অভ্যাস:

• রিপোর্টের আগে ফোন। গুরুতর কিছু পেলে রিপোর্টের অপেক্ষা নয়, RoE অনুযায়ী তখনই জানান।
• Debrief সভা। পরীক্ষক আর developer একসাথে বসেন। প্রশ্ন হয় “কীভাবে ঠিক করব”, “কার দোষ” নয়। নিজের কোডের ত্রুটি শুনতে কারও ভালো লাগে না, তাই ভাষা নম্র রাখুন, ব্যক্তির নাম লিখবেন না।
• Finding থেকে ticket. প্রতিটি finding-এর একজন মালিক, একটি সময়সীমা (SLA) আর একটি ticket নম্বর।
• একই শ্রেণি খুঁজুন। পরীক্ষক নমুনা দেখান, পুরো তালিকা নয়। একটি endpoint-এ মালিকানা যাচাই নেই, এর মানে আরও থাকতে পারে। তাই মূল কারণ ধরে সব জায়গা দেখুন।
• মতভেদ লিখিত সামলান। Developer যদি বলেন “এটি ত্রুটি নয়”, প্রমাণ দেখুন। পরীক্ষক ভুলও হতে পারেন। মাত্রা বদলালে কারণসহ লিখুন।

Finding-এর জীবনচক্রটি একটি ছোট state machine. দুটি নিয়ম খেয়াল করুন: Developer “ঠিক করেছি” বললে সেটি শুধু দাবি, আর বন্ধ করতে পারে কেবল retest. ঝুঁকি মেনে নেওয়াও একটি বৈধ সমাপ্তি, তবে তাতে risk owner-এর স্বাক্ষর লাগে আর পুনর্বিবেচনার তারিখ লাগে (risk acceptance).

Retest মানে পুরো pentest আবার করা নয়। শুধু সেই finding-গুলোর সমাধান যাচাই, সাধারণত মূল পরীক্ষকের দ্বারা, মূল scope আর অনুমতির ভেতরে। মূল অনুমতির মেয়াদ শেষ হলে নতুন স্বাক্ষর নিন। নিচের ছোট tracker একটি কাল্পনিক event log চালিয়ে দেখায়, নিয়মগুলো কীভাবে কাজ করে।

// Toy retest tracker, simulated days. Only a retest can close a finding.
const allowed = {
  OPEN:     { 'fix-claimed': 'FIXED?', 'risk-accepted': 'ACCEPTED' },
  'FIXED?': { 'retest-pass': 'CLOSED', 'retest-fail': 'REOPENED' },
  REOPENED: { 'fix-claimed': 'FIXED?', 'risk-accepted': 'ACCEPTED' },
};
const slaDays = { High: 30, Medium: 60, Low: 90 };
const items = {
  'F-01': { sev: 'High',   state: 'OPEN' },
  'F-02': { sev: 'Medium', state: 'OPEN' },
  'F-03': { sev: 'High',   state: 'OPEN' },
  'F-04': { sev: 'Low',    state: 'OPEN' },
};
const log = [
  [ 9, 'F-01', 'fix-claimed'],   [12, 'F-03', 'retest-pass'],
  [14, 'F-01', 'retest-fail'],   [21, 'F-01', 'fix-claimed'],
  [24, 'F-01', 'retest-pass'],   [25, 'F-04', 'risk-accepted'],
  [40, 'F-02', 'fix-claimed'],   [65, 'F-03', 'fix-claimed'],
];
for (const [day, id, ev] of log) {
  const it = items[id], next = (allowed[it.state] || {})[ev];
  if (!next) { console.log(`day ${day}: ${id} ${ev} REJECTED (state ${it.state})`); continue; }
  console.log(`day ${day}: ${id} ${it.state} -> ${next}`);
  it.state = next;
  if (next === 'CLOSED' || next === 'ACCEPTED') it.endDay = day;
}
const today = 70;
console.log(`--- status on day ${today} ---`);
for (const [id, it] of Object.entries(items)) {
  const age = it.endDay ?? today;
  const late = age > slaDays[it.sev] ? ' OVER SLA' : '';
  console.log(`${id} ${it.sev.padEnd(6)} ${it.state.padEnd(8)} day ${age}${late}`);
}
const shut = Object.values(items).filter(i => i.state === 'CLOSED').length;
console.log(`closed by retest: ${shut} of ${Object.keys(items).length}`);

৮ · Vendor বাছাই, নৈতিকতা আর পেশার পথ

পরীক্ষক দলকে আপনি নিজের দুর্বলতার মানচিত্র তুলে দিচ্ছেন। তাই বাছাই শুধু দামের প্রশ্ন নয়, বিশ্বাসের প্রশ্ন। বাইরের সেবাদাতা বাছাইয়ের সাধারণ নিয়ম পাবেন পর্ব ৭১-এ। Pentest-এর জন্য বাড়তি প্রশ্নগুলো হলো:

CREST-এর মতো স্বীকৃতি বা কোনো সনদ একটি সংকেত, নিশ্চয়তা নয়। সবচেয়ে কাজের যাচাই হলো নমুনা রিপোর্ট পড়া আর পরীক্ষকের সাথে পনেরো মিনিট কথা বলা।

নৈতিকতা আর স্বার্থের সংঘাত

পেশাগত দায়িত্বের ভিত্তি আছে পর্ব ৬-এ। Pentest-এর সাধারণ conflict of interest হলো:

• যে প্রতিষ্ঠান system বানিয়েছে বা চালায়, সে-ই স্বাধীন পরীক্ষক হিসেবে সনদ দিচ্ছে।
• রিপোর্টে ত্রুটি যত বেশি, নিজের সমাধান-সেবা বিক্রি তত বেশি, তাই মাত্রা বাড়িয়ে লেখার টান।
• উল্টো টান: ব্যবস্থাপক অডিট পার হতে চান, বলছেন “এই finding-টি নামিয়ে দিন”।
• পরীক্ষক client-এর প্রতিদ্বন্দ্বীর কাজ করছেন, বা কোনো বিক্রেতার অংশীদার।

সমাধান: separation of duties, আগে থেকে জানানো, মাত্রা বদলের লিখিত কারণ। প্রমাণ না থাকলে client-এর চাপে finding মুছবেন না। বদলে যদি client ঝুঁকি মেনে নেন, রিপোর্টে সেটিই লিখুন। মনে রাখুন, রিপোর্টটি অন্য কেউ ভরসা করে পড়বেন: অডিটর, ব্যাংক বা client-এর গ্রাহক।

পেশার পথ

অনেকেই pentest-কে একটি নাটকীয় কাজ ভাবেন। বাস্তবে সময়ের বড় অংশ যায় পড়া, নোট রাখা, রিপোর্ট লেখা আর সভায়। ভালো ভিত্তি হলো network, OS, web আর programming, মানে এই কোর্সের আগের মডিউলগুলো। পথটি প্রায়ই developer, system admin বা SOC analyst থেকে আসে। নিজের ল্যাব, বৈধ অনুশীলন প্ল্যাটফর্ম আর CTF দিয়ে শুরু করুন (পর্ব ৬).

পরিচিত সনদের উদাহরণ: OffSec-এর OSCP, CompTIA PenTest+, GIAC-র GPEN, EC-Council-এর CEH, CREST-এর পরীক্ষা। এগুলোর বিষয়, ধরন আর শর্ত বদলায়, তাই প্রতিষ্ঠানের নিজের পাতা দেখুন। এখানে কোনোটির সুপারিশ করা হচ্ছে না, আর এই পর্বের কোনো প্রশ্ন কোনো সনদ-পরীক্ষা থেকে নেওয়া নয়।

৯ · VDP আর bug bounty — প্রতিষ্ঠানের দিক থেকে

গবেষকের দিকটি পর্ব ৬-এ দেখেছেন। এখানে প্রশ্ন হলো, আপনি প্রতিষ্ঠান হলে কী করবেন। বাড়ির সামনে একটি চিঠির বাক্স রাখার কথা ভাবুন। কেউ যদি দেখেন আপনার গেটের তালা ভাঙা, তিনি যেন জানানোর একটি পথ পান। সেই বাক্সটিই VDP. Bug bounty হলো তার ওপরে পুরস্কারের ঘোষণা। বাক্স ছাড়া পুরস্কার ঘোষণা করলে অনেক চিঠি এসে ঘরে ছড়িয়ে পড়বে।

VDP শুরু করার ন্যূনতম তালিকা

1. একটি নীতি পাতা: কোন asset ভেতরে, কোন পদ্ধতি নিষিদ্ধ, ডেটা দেখলে কী করবেন, safe harbor-এর ভাষা, কতদিনে সাড়া আশা করা যায়।
2. একটি যোগাযোগ পথ: নির্দিষ্ট email বা form, আর /.well-known/security.txt (security.txt, RFC 9116).
3. একজন মালিক: কে পড়বেন, কে অগ্রাধিকার দেবেন, ছুটির সময় কে থাকবেন।
4. ভেতরের পথ: রিপোর্ট কীভাবে ticket হবে, কে ঠিক করবেন, গবেষককে কখন জানানো হবে।
5. আইনি পর্যালোচনা: নীতিটি আইনজীবী দেখবেন। তৃতীয় পক্ষের system-এর অনুমতি আপনি দিতে পারবেন না।

Bug bounty কখন, আর কীভাবে

Bounty শুরুর আগে নিজেকে তিনটি প্রশ্ন করুন: scan আর ভেতরের পরীক্ষায় সহজ ত্রুটি কি কমেছে? প্রতি সপ্তাহে কতগুলো রিপোর্ট সামলানো যাবে? সমাধান করার ক্ষমতা আছে তো? উত্তর “না” হলে আগে VDP. অনেকে প্রথমে সীমিত আমন্ত্রিত প্রোগ্রাম করেন, পরে প্রকাশ্য। HackerOne, Bugcrowd বা Intigriti-র মতো প্ল্যাটফর্ম এই কাজ সহজ করতে পারে, আবার নিজেও চালানো যায়। এগুলো উদাহরণ মাত্র।

সবচেয়ে কঠিন অংশ হলো triage: অনেক রিপোর্ট আসে, তার বড় অংশ বাতিল বা duplicate. Scanner-এর ফল বিনা যাচাইয়ে পাঠানো, আর AI-এ বানানো রিপোর্টও বাড়ছে। নিচের toy simulator ছয়টি বানানো রিপোর্ট একটি নির্দিষ্ট ক্রমে পরীক্ষা করে। পুরস্কার এখানে শুধু কাল্পনিক point, কোনো টাকার হিসাব নয়।

// Toy bounty triage on fictional reports. Rules run in a fixed order.
const scope = ['shop.example.com', 'api.example.com'];
const reward = { High: 500, Medium: 150, Low: 50 };   // toy points, not money
const known = new Set(['api.example.com#invoice-access']);   // already tracked

const reports = [
  { id: 'R1', host: 'blog.example.org', bug: 'open-redirect',  sev: 'Low',    repro: true },
  { id: 'R2', host: 'api.example.com',  bug: 'invoice-access', sev: 'High',   repro: true },
  { id: 'R3', host: 'shop.example.com', bug: 'coupon-reuse',   sev: 'Medium', repro: true },
  { id: 'R4', host: 'shop.example.com', bug: 'coupon-reuse',   sev: 'Medium', repro: true },
  { id: 'R5', host: 'shop.example.com', bug: 'scanner-output', sev: 'High',   repro: false },
  { id: 'R6', host: 'api.example.com',  bug: 'staff-export',   sev: 'High',   repro: true,
    copiedRealData: true },
];
function triage(r) {
  if (!scope.includes(r.host)) return ['OUT-OF-SCOPE', 0];
  const key = `${r.host}#${r.bug}`;
  if (known.has(key)) return ['DUPLICATE', 0];
  if (!r.repro) return ['NEEDS-INFO', 0];
  known.add(key);
  if (r.copiedRealData) return ['VALID, POLICY REVIEW', 0];
  return ['VALID', reward[r.sev]];
}
const tally = {};
let total = 0;
for (const r of reports) {
  const [verdict, pts] = triage(r);
  console.log(`${r.id} ${r.bug.padEnd(15)} ${verdict.padEnd(21)} ${pts} pts`);
  tally[verdict] = (tally[verdict] || 0) + 1;
  total += pts;
}
const valid = (tally['VALID'] || 0) + (tally['VALID, POLICY REVIEW'] || 0);
console.log(JSON.stringify(tally));
console.log(`signal: ${valid} valid of ${reports.length}, ` +
            `${(100 * valid / reports.length).toFixed(1)}%; paid ${total} pts`);

প্রোগ্রাম চালানোর নিয়ম

• সাড়ার সময় মেনে চলুন। প্রথম সাড়া, triage আর পুরস্কারের সময় ঘোষণা করে সেটি রাখুন। নীরবতা গবেষককে রাগিয়ে তোলে।
• মাত্রা আর পুরস্কারের একটি প্রকাশ্য তালিকা রাখুন। বিরোধ কমে।
• সীমা ভাঙার ফল আগেই লিখুন। ভাষা স্পষ্ট রাখুন, তবে প্রতিশোধের ভঙ্গিতে নয়।
• Bounty-কে ঘটনা লুকানোর পথ বানাবেন না। কেউ আসল ডেটা নিয়ে টাকা চাইলে সেটি গবেষণা নয়, incident response-এর বিষয়।
• Pentest-এর বিকল্প নয়। Bounty অনিশ্চিত আর জনপ্রিয় অংশে ভিড় করে। পরীক্ষা নিশ্চিত কভারেজ দেয়। দুটি একে অন্যের পরিপূরক।

১০ · AI-এর যুগে pentest-এর ব্যবস্থাপনা

AI রিপোর্টের খসড়া, নমুনা নীতি আর developer-এর জন্য ব্যাখ্যা দ্রুত লিখতে পারে। কিন্তু এই পেশার ভিত্তি অনুমতি, প্রমাণ আর দায়। এই তিনটি কোনো মডেলের হাতে দেওয়া যায় না।

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

• Client-এর কোনো নাম, ঠিকানা, token বা প্রমাণ পেস্ট করিনি
• প্রতিটি CVE, CWE আর standard-এর সূত্র মূল উৎসে খুলে দেখেছি
• Severity নিজে হিসাব করেছি, AI-এর সংখ্যা মেনে নিইনি
• AI-এর দেওয়া সমাধান নিজের ল্যাবে চালিয়ে দেখেছি, কোনো যাচাই বন্ধ করেনি তো
• রিপোর্টে যা লিখেছি তার প্রতিটি দাবির প্রমাণ আছে, আর স্বাক্ষরকারী একজন মানুষ