Vendor আর third-party ঝুঁকি — যাচাই, চুক্তি আর নজরদারি

১ · আপনার দরজার চাবি এখন অন্যের হাতেও

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

প্রতিষ্ঠানের third party ঠিক এই ঠিকাদার। Payment gateway, courier-এর portal, hosting, হিসাবের software, এমনকি AC মেরামতের প্রতিষ্ঠান, সবাই আপনার ডেটা বা system-এ কিছুটা পৌঁছায়। তারা পর্ব ৪-এর attack surface-কে আপনার দেয়ালের বাইরে টেনে নিয়ে যায়।

তিনটি প্রকাশিত ঘটনা, তিনটি পথ

Target আর Change Healthcare-এর বিস্তারিত পাবেন পর্ব ৬৫-এ। আর এই পর্বের সীমানাটিও পরিষ্কার করি। পর্ব ৪৮ দেখেছে আপনার software-এর ভেতরে ঢোকা কোড: dependency, build, SBOM. এখানে আমরা দেখছি সেবা আর প্রতিষ্ঠান: যারা আপনার হয়ে কাজ করে, আপনার ডেটা রাখে, আপনার system-এ login করে। MOVEit দুই বিষয়েই প্রাসঙ্গিক, কারণ পণ্যটি software, আর ক্ষতি ছড়িয়েছে সেবাদাতাদের শিকল ধরে।

২ · তালিকা আর tier: কাকে কতটা যাচাই

একটি পুরোনো সত্য: যা তালিকায় নেই, তা রক্ষা করা যায় না। Asset inventory-র মতো vendor-এরও তালিকা লাগে। তালিকা বানাতে শুধু কেনাকাটার ফাইল দেখলে চলবে না। হিসাব বিভাগের bill, card-এর খরচ, SSO-তে যুক্ত app, Google বা Microsoft account-এ অনুমোদিত OAuth app, আর বিভাগীয় প্রধানদের প্রশ্ন করা, সবই দরকার। এভাবেই shadow IT বেরিয়ে আসে: মার্কেটিং দল card-এ নেওয়া একটি SaaS-এ গ্রাহকের তালিকা তুলে রেখেছে, অথচ IT জানে না।

প্রতিটি vendor-এর জন্য অন্তত এই ঘরগুলো রাখুন: নাম, প্রতিষ্ঠানের ভেতরের মালিক, সেবার কাজ, কোন ডেটা, কোন access, চুক্তির শেষ তারিখ, শেষ যাচাইয়ের তারিখ, breach-এর যোগাযোগ, tier. মালিক ঘরটিই সবচেয়ে জরুরি। মালিক ছাড়া vendor মানে অভিভাবকহীন চাবি। ভূমিকা ভাগের কথা আছে পর্ব ৬৭-এ।

সব vendor-কে একভাবে যাচাই করলে দুটির একটি হয়: হয় চা-পাতার সরবরাহকারীকে ৩০০ প্রশ্ন পাঠিয়ে সময় নষ্ট, নয়তো payment vendor-কে হালকা ছেড়ে দেওয়া। তাই vendor tiering. Hospital-এর triage-এর মতো, সবচেয়ে গুরুতর রোগী আগে, আর তাঁর পরীক্ষাও বেশি।

এখন প্রশ্ন, tier ঠিক হবে কীভাবে? অনেকে নম্বর যোগ করেন। নিচের কাল্পনিক vendor তালিকায় যোগফলের নিয়ম আর “সবচেয়ে খারাপ বৈশিষ্ট্য” নিয়ম পাশাপাশি চালান। নামগুলো বানানো, ডেটাও খেলনা।

// Toy vendors. Names and attributes are invented.
const vendors = [
  { name: 'ToyPay',     data: 'card',     access: 'api',    critical: true  },
  { name: 'ToyDesk',    data: 'personal', access: 'admin',  critical: false },
  { name: 'ToyCool',    data: 'none',     access: 'vpn',    critical: false },
  { name: 'ToyCourier', data: 'personal', access: 'portal', critical: true  },
  { name: 'ToyMail',    data: 'personal', access: 'none',   critical: false },
  { name: 'ToyDesign',  data: 'internal', access: 'none',   critical: false },
  { name: 'ToyTea',     data: 'none',     access: 'none',   critical: false },
];
const DATA = { none: 0, internal: 1, personal: 2, card: 3 };
const ACCESS = { none: 0, portal: 1, api: 2, vpn: 3, admin: 3 };

// The worst single attribute decides the tier.
function worstRule(v) {
  const worst = Math.max(DATA[v.data], ACCESS[v.access], v.critical ? 2 : 0);
  return worst === 3 ? 'T1' : worst === 2 ? 'T2' : 'T3';
}
// A common mistake: adding points, so a low score hides one big danger.
function sumRule(v) {
  const sum = DATA[v.data] + ACCESS[v.access] + (v.critical ? 2 : 0);
  return sum >= 5 ? 'T1' : sum >= 3 ? 'T2' : 'T3';
}

console.log('vendor      data      access  worst  sum');
for (const v of vendors) {
  const w = worstRule(v), s = sumRule(v);
  console.log(v.name.padEnd(11), v.data.padEnd(9), v.access.padEnd(7),
    w.padEnd(6), s, w === s ? '' : ' <-- rules disagree');
}
const count = {};
for (const v of vendors) count[worstRule(v)] = (count[worstRule(v)] || 0) + 1;
console.log('tier counts (worst rule):', JSON.stringify(count));

৩ · Due diligence: দাবি আর প্রমাণ আলাদা করা

মেয়ের বিয়ের আগে পাত্রের খোঁজ নেওয়ার কথা ভাবুন। পাত্রের নিজের কথায় সবই ভালো। তাই পরিবার প্রতিবেশী, অফিস আর পরিচিতদের কাছ থেকেও খবর নেয়। Due diligence-ও তাই: vendor-এর নিজের দাবি শোনা, তারপর স্বাধীন প্রমাণ মেলানো।

প্রশ্নমালা: কাজের, তবে যথেষ্ট নয়

Security questionnaire নিজে বানাতে হবে এমন নয়। প্রচলিত উদাহরণ হিসেবে Shared Assessments-এর SIG (লাইসেন্স লাগে, নিয়মিত হালনাগাদ হয়) আর Cloud Security Alliance-এর CAIQ (Cloud Controls Matrix থেকে তৈরি, cloud সেবার জন্য জনপ্রিয়). এগুলোর নাম উদাহরণ হিসেবে দিচ্ছি, সুপারিশ হিসেবে নয়। Version আর প্রশ্নসংখ্যা বদলায়, তাই প্রকাশকের সাইট দেখবেন। ছোট প্রতিষ্ঠানের জন্য বিশটি ভালো প্রশ্ন তিনশো মুখস্থ প্রশ্নের চেয়ে ভালো:

• Admin ও support কর্মীদের login-এ phishing-প্রতিরোধী MFA আছে কি? কীভাবে প্রমাণ দেবেন?
• আমাদের ডেটা কোথায় থাকে, কে দেখতে পারে, কতদিন থাকে, মুছলে backup থেকে কবে যায়?
• গত এক বছরে সবচেয়ে বড় security incident কী ছিল, কী বদলেছেন?
• কোন subprocessor-রা আমাদের ডেটা ছোঁয়?
• Backup থেকে ফেরার শেষ পরীক্ষা কবে হয়েছে, RTO কত ছিল?

প্রমাণের সিঁড়ি

প্রতিটি “Yes”-এর পেছনে প্রমাণের ওজন আলাদা: মুখের দাবি, নীতির নথি, স্বাধীন audit, আর সবচেয়ে ওপরে নিজে দেখা বা পরীক্ষার ফল। নিচের খেলনা scorer দেখুন। ওজনগুলো আমাদের ধরে নেওয়া, কোনো standard নয়।

// Toy questionnaire. Weights are our own assumption, not a standard.
const EVIDENCE = { none: 0, claim: 0.2, document: 0.5, audited: 0.8, tested: 1 };
const ANSWER = { yes: 1, partial: 0.5, no: 0 };
const controls = [
  { id: 'MFA on admin',   weight: 3, must: true  },
  { id: 'Encrypt backup', weight: 2, must: true  },
  { id: 'Breach process', weight: 2, must: false },
  { id: 'Access review',  weight: 2, must: false },
  { id: 'Staff training', weight: 1, must: false },
];
const replies = {
  VendorA: [['yes','claim'], ['yes','claim'], ['yes','claim'], ['yes','claim'], ['yes','claim']],
  VendorB: [['yes','tested'], ['yes','audited'], ['partial','document'], ['no','none'], ['yes','audited']],
};

for (const [name, rows] of Object.entries(replies)) {
  let max = 0, naive = 0, real = 0;
  const gaps = [];
  controls.forEach((c, i) => {
    const [ans, ev] = rows[i];
    max += c.weight;
    naive += c.weight * ANSWER[ans];
    real += c.weight * ANSWER[ans] * EVIDENCE[ev];
    // A must-have control needs more than a promise.
    if (c.must && (ans !== 'yes' || EVIDENCE[ev] < 0.5)) gaps.push(c.id);
  });
  const pct = x => (100 * x / max).toFixed(1).padStart(5) + '%';
  console.log(name, 'answers', pct(naive), '| evidence-weighted', pct(real));
  console.log('  must-have gaps:', gaps.length ? gaps.join(', ') : 'none');
  console.log('  decision:', gaps.length ? 'HOLD: get evidence first' : 'PROCEED to contract review');
}

৪ · SOC 2 report আর ISO সনদ সমালোচকের চোখে

পরীক্ষার সনদ দেখেই চাকরি দেওয়া আর নম্বরপত্র পড়া এক নয়। “We are SOC 2 compliant” logo-টি সনদের মতো। আসল তথ্য থাকে ভেতরের পাতায়।

SOC 2 (পরিচিতি পর্ব ৬৯-এ) আসে AICPA-র কাঠামো থেকে, মাপকাঠি Trust Services Criteria. Security অংশটি আবশ্যিক, বাকিগুলো (availability, processing integrity, confidentiality, privacy) vendor বেছে নেয়। এটি পাস-ফেলের সনদ নয়, একজন স্বাধীন CPA-র report. Type II report পড়ার ক্রম কাল্পনিক ToyPay দিয়ে দেখুন। আজকের তারিখ ধরুন ৩১ অক্টোবর ২০২৬, আর আপনি ব্যবহার করবেন তার API এবং merchant portal দুটোই।

SOC 2 Type II
Period: 2025-10-01 to 2026-03-31
Bridge letter through: 2026-06-30
Today: 2026-10-31 (214 days after period end)

In our opinion, in all material respects,
the description is fairly presented ...
Type: unqualified. No "except for".

In scope:      ToyPay Payment API
Out of scope:  Merchant Portal
Criteria:      Security, Availability

Hosting provider: carve-out method
Controls at the provider were not tested.

Control: leaver access removed in 1 day
Sample: 25 leavers
Exception: 2 removed after 3 days
Rate: 2/25 = 8%

Customers are expected to:
- enforce MFA for their portal users
- review their user list every quarter
- rotate API keys

1 new bridge letter or report
2 evidence for Merchant Portal
3 hosting provider's report
4 proof the leaver fix works
5 named owner for each CUEC

ISO সনদেও একই পড়া। সনদের scope বাক্যটি পড়ুন: হয়তো শুধু একটি অফিস বা একটি বিভাগ, আপনার সেবা নয়। Statement of Applicability চাইতে পারেন, যাতে দেখা যায় কোন control বাদ গেছে আর কেন। Certification body স্বীকৃত কি না, আর মেয়াদ চলছে কি না, দেখুন। ISO/IEC 27001 সনদ বলে ব্যবস্থাপনা পদ্ধতি আছে। প্রতিটি control নির্দিষ্ট দিনে কাজ করেছে, এমন কথা বলে না।

কাগজের মেয়াদ চুপচাপ ফুরিয়ে যায়। নিচের tracker সেই হিসাব রাখে। ধরে নেওয়া নিয়ম: report-এর সময়কাল শেষের ৩৬৫ দিন পর আর bridge letter-এর ৯২ দিন পর কাগজ পুরোনো, ৬০ দিনের মধ্যে হলে “DUE SOON”. আপনার নীতি অন্য হতে পারে। ঘড়িটি নকল, তাই ফল প্রতিবার একই।

// Simulated clock: the date is fixed, so the output never changes.
const TODAY = '2026-10-31';
const WARN_DAYS = 60;
const day = s => Date.UTC(+s.slice(0, 4), +s.slice(5, 7) - 1, +s.slice(8, 10)) / 86400000;

// "until" = the last day this paper can honestly vouch for.
const papers = [
  { vendor: 'ToyPay',     kind: 'SOC 2 Type II', until: '2026-03-31', maxAge: 365 },
  { vendor: 'ToyPay',     kind: 'bridge letter', until: '2026-06-30', maxAge: 92 },
  { vendor: 'ToyPay',     kind: 'PCI AOC',       until: '2026-11-20', maxAge: 0 },
  { vendor: 'ToyDesk',    kind: 'ISO 27001',     until: '2027-05-14', maxAge: 0 },
  { vendor: 'ToyCourier', kind: 'SOC 2 Type I',  until: '2025-06-30', maxAge: 365 },
  { vendor: 'ToyMail',    kind: 'pen test sum.', until: '2026-08-15', maxAge: 365 },
];

function check(p) {
  const end = day(p.until) + p.maxAge;      // when this paper goes stale
  const left = end - day(TODAY);
  const gap = Math.max(0, day(TODAY) - day(p.until));
  const status = left < 0 ? 'EXPIRED' : left <= WARN_DAYS ? 'DUE SOON' : 'OK';
  return { ...p, left, gap, status };
}

const rows = papers.map(check).sort((a, b) => a.left - b.left);
console.log('today', TODAY, '(simulated)');
console.log('vendor     paper          days-left  uncovered  status');
for (const r of rows)
  console.log(r.vendor.padEnd(10), r.kind.padEnd(14), String(r.left).padStart(9),
    String(r.gap).padStart(10), '', r.status);
const act = rows.filter(r => r.status !== 'OK').length;
console.log(act, 'of', rows.length, 'papers need action');

৫ · চুক্তি: যা লেখা নেই, তা চাওয়া যায় না

দোকান ভাড়া নেওয়ার সময় লিখিত চুক্তি করেন, কারণ বিরোধের দিনে মৌখিক কথা কাজে আসে না। Vendor-এর সাথেও নিরাপত্তার প্রত্যাশা চুক্তিতে না থাকলে breach-এর দিনে আপনার হাতে কিছুই থাকে না। নিচের সময়সীমাগুলো আলোচনার উদাহরণ, কোনো standard নয়।

ব্যক্তিগত তথ্য থাকলে আলাদা DPA লাগতে পারে। GDPR প্রযোজ্য হলে Article 28 processor-এর চুক্তিতে কিছু বিষয় বাধ্যতামূলক করে: নির্দেশ মেনে কাজ, subprocessor-এর অনুমোদন, audit-এ সহায়তা, শেষে তথ্য ফেরত বা মুছে ফেলা। বাংলাদেশে ব্যক্তিগত উপাত্ত সুরক্ষা আইন, ২০২৬ (৬৩ নং) আর জাতীয় উপাত্ত ব্যবস্থাপনা আইন, ২০২৬ (৮০ নং) প্রণীত হয়েছে, কিছু ধারা পরে গেজেটে কার্যকর হওয়ার কথা। আইনের প্রেক্ষিত দেখুন পর্ব ৬-এ আর পর্ব ৭০ · Privacy engineering-এ। ব্যাংক বা আর্থিক খাতে নিয়ন্ত্রকের নিজস্ব নির্দেশনাও থাকতে পারে। এই পাতা আইনি পরামর্শ নয়। চুক্তি আইনজীবী দিয়ে পড়িয়ে নেওয়া দরকার।

৬ · Onboarding আর SaaS-এ আপনার ভাগের কাজ

যাচাই আর চুক্তি শেষ, এবার আসল চাবি দেওয়ার পালা। পর্ব ৩-এর least privilege এখানে তিন নিয়মে দাঁড়ায়: প্রতিটি vendor-এর আলাদা পরিচয়, যত কম সম্ভব অধিকার, আর প্রতিটি মানুষের login-এ MFA. একটি কাল্পনিক অনলাইন বাজার ToyPay যুক্ত করছে। খেয়াল করুন, access আসে সবার শেষে।

Network-এ বসা vendor হলে পর্ব ২৫-এর application-ভিত্তিক access আর নির্দিষ্ট সময়ের just-in-time access ভাবুন। স্থায়ী VPN দেবেন না। Admin সুবিধা হলে session recording (পর্ব ২০)। Support vendor-এর ডেটা দেখা যত সীমিত করা যায়, তত ভালো।

SaaS-এর দায়িত্ব কার?

ফ্ল্যাট ভাড়ার মতো: ভবনের কলাম আর লিফট মালিকের, কিন্তু নিজের দরজায় তালা দেওয়া আপনার কাজ। Snowflake-এর গ্রাহকদের ঘটনায় (২০২৪) Mandiant-এর রিপোর্ট বলেছে, প্রায় ১৬৫টি প্রতিষ্ঠানকে সম্ভাব্য ঝুঁকির কথা জানানো হয়, এবং তদন্ত করা ঘটনাগুলো গ্রাহকের চুরি যাওয়া credential থেকে এসেছিল, যেসব account-এ MFA ছিল না। Snowflake-এর নিজের প্রতিষ্ঠানগত পরিবেশ ভাঙার প্রমাণ রিপোর্টে পাওয়া যায়নি।

ভাগটি প্রতি vendor-এ আলাদা, তাই ঠিক হিসাব SOC 2-র CUEC বা vendor-এর ডকুমেন্টে পড়ুন। Cloud-এর স্তরভিত্তিক ভাগ দেখবেন পর্ব ৭২-এ।

৭ · চলমান নজরদারি, fourth party আর concentration

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

• তারিখ: report, সনদ, চুক্তি নবায়ন আর tier-এর পুনর্যাচাই।
• বাহ্যিক সংকেত: Vendor-এর advisory আর status page, সংবাদ, পর্ব ৫৭-এর threat intelligence, পর্ব ৩২-এর KEV তালিকায় তাদের পণ্য।
• নিজের log: Vendor account কখন, কোথা থেকে login করছে, কত ডেটা নামছে। নিজের দিকের এই log-ই সবচেয়ে বিশ্বাসযোগ্য, কারণ vendor-এর খবরের অপেক্ষায় থাকতে হয় না।
• পরিবর্তন: মালিকানা বদল, নতুন subprocessor, নতুন ফিচারে AI, ডেটার নতুন অবস্থান।
• সেবার মান: SLA ভাঙা, বারবার outage, ধীর সাড়া।

Security rating সেবাগুলো বাইরে থেকে দেখা সংকেত দিয়ে নম্বর দেয়। এটি মেঘের ছবি দেখে আবহাওয়া আন্দাজের মতো কাজের, কিন্তু ভেতরের control দেখে না। ভালো নম্বর প্রমাণ নয়, খারাপ নম্বর প্রশ্ন করার কারণ।

Fourth party আর লুকানো একক বিন্দু

আপনার vendor-এর vendor হলো fourth party. তার সাথে চুক্তি নেই, তবু তার ব্যর্থতা আপনাকে ছোঁয়। সব শিকল শেষ পর্যন্ত জানা অসম্ভব। তাই T1 vendor-দের subprocessor তালিকা নিন, আর একটি প্রশ্ন করুন: “আমার কোন গুরুত্বপূর্ণ কাজগুলো একই জিনিসের ওপর দাঁড়িয়ে?”

একটি হিসাব। দুটি payment vendor রাখলে আপনি নিরাপদ বোধ করেন। প্রতিটির নিজস্ব availability ৯৯.৯% ধরুন, আর একটি বন্ধ থাকলে অন্যটি চলে। স্বাধীন হলে দুটি একসাথে বন্ধের সম্ভাবনা:

independent: 1 - (0.001 × 0.001) = 99.9999%  → প্রায় 31.5 সেকেন্ড/বছর
shared cloud 99.95%: 0.9995 × 0.999999 ≈ 99.9499% → প্রায় 4.39 ঘণ্টা/বছর

দুই vendor যদি একই cloud অঞ্চলে চলে, আর সেটির availability ৯৯.৯৫% ধরি, তাহলে বছরে আধা মিনিটের ঝুঁকি হয়ে যায় প্রায় ৪.৪ ঘণ্টা, প্রায় ৫০০ গুণ। সংখ্যাগুলো ধরে নেওয়া, ব্যর্থতাও বাস্তবে পুরো স্বাধীন হয় না। তবু শিক্ষাটি পরিষ্কার: দুটি নাম মানেই দুটি স্বাধীন পথ নয়।

৮ · Offboarding আর ছোট প্রতিষ্ঠানের কেনাকাটার ধারা

ভাড়াটে বাড়ি ছাড়লে চাবি ফেরত, হিসাব মেটানো, মিটার দেখা হয়। Vendor ছাড়ার সময়ও তাই। কিন্তু এই ধাপটিই সবচেয়ে বেশি ভুলে যাওয়া হয়, কারণ ততক্ষণে সবার মন নতুন vendor-এ। কর্মীর offboarding-এর মতোই vendor-এরও চেকলিস্ট লাগে:

• সব পরিচয় বন্ধ: মানুষের account, service account, API key, OAuth app, VPN, webhook.
• Vendor যেসব secret জানত, সেগুলো পাল্টানো (secret rotation).
• ডেটা ফেরত নেওয়া, পরীক্ষা করে দেখা যে export খোলে, তারপর মুছে ফেলার লিখিত প্রত্যয়ন।
• DNS record, firewall নিয়ম, allow list থেকে নাম সরানো।
• Register-এ “বন্ধ” লেখা, তবে নথি নীতিমাফিক সময় পর্যন্ত রাখা।

নিচের খেলনা checker একটি কাল্পনিক directory-তে এই কাজই করে। সব তথ্য একটি in-memory তালিকা, কোনো আসল system ছোঁয়া হয় না।

// Toy directory on a simulated date. Nothing here touches a real system.
const contracts = {
  ToyCool: { ended: '2026-06-30' },
  ToyDesk: { ended: null },
  ToyMail: { ended: '2026-09-15' },
};
const directory = [
  { id: 'svc-toycool-vpn',  vendor: 'ToyCool', type: 'vpn',   on: true,  last: '2026-10-12' },
  { id: 'agent1.toydesk',   vendor: 'ToyDesk', type: 'human', on: true,  last: '2026-10-30' },
  { id: 'agent2.toydesk',   vendor: 'ToyDesk', type: 'human', on: true,  last: '2026-03-02' },
  { id: 'key-toymail-send', vendor: 'ToyMail', type: 'api',   on: true,  last: '2026-09-10' },
  { id: 'oauth-toymail',    vendor: 'ToyMail', type: 'oauth', on: true,  last: '2026-09-12' },
  { id: 'old-toycool-tech', vendor: 'ToyCool', type: 'human', on: false, last: '2026-06-20' },
  { id: 'temp-contractor',  vendor: null,      type: 'human', on: true,  last: '2026-10-01' },
];
const TODAY = '2026-10-31';
const IDLE_DAYS = 90;
const day = s => Date.parse(s + 'T00:00:00Z') / 86400000;

function review(a) {
  if (!a.on) return null;
  if (!a.vendor) return ['HIGH', 'no owner vendor on record'];
  const ended = contracts[a.vendor].ended;
  if (ended && a.last > ended) return ['CRIT', 'used after contract end: open incident'];
  if (ended) return ['HIGH', 'contract ended, still enabled'];
  if (day(TODAY) - day(a.last) > IDLE_DAYS) return ['MED', 'idle over ' + IDLE_DAYS + ' days'];
  return null;
}

const rank = { CRIT: 0, HIGH: 1, MED: 2 };
const out = directory.map(a => [a, review(a)]).filter(x => x[1])
  .sort((x, y) => rank[x[1][0]] - rank[y[1][0]]);
for (const [a, [level, why]] of out)
  console.log(level.padEnd(5), a.id.padEnd(18), a.type.padEnd(6), why);
console.log(out.length, 'findings in', directory.length, 'accounts');

দশ জনের প্রতিষ্ঠানের জন্য সহজ ধারা

Security দল না থাকলেও এটুকু করা যায়। মোট সময় T1 vendor-এ কয়েক ঘণ্টা, ছোট vendor-এ মিনিট পনেরো।

একটি সরল spreadsheet, একজন মালিক আর বছরে এক দিন, এটুকুই বহু প্রতিষ্ঠানের চেয়ে এগিয়ে রাখে। Payment vendor-এর ব্যাংক হিসাব বদলের ইমেইল এলে vendor master বদলানোর আগে পরিচিত নম্বরে ফোন করুন (পর্ব ৫২)।

৯ · Vendor breach: খবর এলে কী করবেন

Vendor breach-এর সবচেয়ে কঠিন দিক হলো, তথ্য আপনার হাতে নেই, অথচ সিদ্ধান্ত আপনারই। পর্ব ৬১-এর ধাপগুলোই খাটে, তবে তিনটি বাড়তি বিষয় আছে: খবরটি যাচাই করা, vendor-কে ঠিক প্রশ্ন করা, আর নিজের দিকের access বন্ধ করা। কাল্পনিক support SaaS ToyDesk-এর ঘটনাটি ধাপে ধাপে দেখুন।

১০ · AI-এর যুগে vendor ঝুঁকি

AI দুই দিক থেকে এই পর্বে ঢোকে। প্রথমত, AI সেবা নিজেই একটি vendor: কর্মীরা যা পেস্ট করেন, তা সেই vendor-এর কাছে যায়। তাই ডেটা রাখার মেয়াদ, training-এ ব্যবহার আর subprocessor একইভাবে যাচাই করুন (পর্ব ৫১)। Shadow AI হলো নতুন shadow IT. দ্বিতীয়ত, AI দিয়ে প্রশ্নমালা পড়া, চুক্তি সারাংশ করা, এমনকি vendor-এর উত্তর লেখাও হচ্ছে। ফলে সুন্দর উত্তর আর সত্য উত্তরের ফারাক কমে গেছে, তাই প্রমাণের দাম আরও বেড়েছে।

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

• Report বা চুক্তি পেস্ট করার আগে NDA আর প্রতিষ্ঠানের AI নীতি দেখেছি
• কোনো secret, গ্রাহকের ব্যক্তিগত তথ্য বা API key পেস্ট করিনি
• AI-র প্রতিটি উদ্ধৃতি মূল নথির পাতায় মিলিয়েছি
• CVE, standard আর আইনের প্রতিটি উল্লেখ মূল উৎসে দেখেছি
• অনুমোদন, বাতিল আর গ্রাহককে জানানোর সিদ্ধান্ত একজন মানুষ নিয়েছেন