Standard আর compliance — ISO 27001, NIST CSF, CIS, PCI DSS আর SOC 2

১ · সনদ থাকা আর নিরাপদ থাকা এক কথা নয়

একটি বাসের ফিটনেস সনদ আছে। কাগজ ঠিক, মেয়াদও আছে। কিন্তু গত রাতে ব্রেকের তেল ফুরিয়ে গেছে। সনদ বাসটিকে থামাবে না। আবার আরেকটি বাসের ব্রেক খুব ভালো, কিন্তু সনদের মেয়াদ শেষ। সেটি রাস্তায় চলার অনুমতি পাবে না।

নিরাপত্তার জগতেও ঠিক এই দুটি আলাদা প্রশ্ন আছে। নিরাপত্তা জিজ্ঞেস করে, “ঝুঁকি কি সত্যিই কম?” Compliance জিজ্ঞেস করে, “নির্ধারিত শর্ত পূরণ হয়েছে, আর তার প্রমাণ আছে?” দুটি অনেকটা মেলে, কিন্তু একটি অন্যটির বদলে চলে না।

তাহলে compliance-কে তুচ্ছ ভাবার কারণ নেই। এটি চারটি সত্যিকারের কাজ করে: বাধ্য করে মূল কাজগুলো করতে, ব্যবসার দরজা খোলে, দুই প্রতিষ্ঠানকে একই ভাষা দেয়, আর আইনি দায় মেটায়। সমস্যা হয় তখনই, যখন প্রমাণটিই লক্ষ্য হয়ে যায়।

পাঁচটি শব্দ, পাঁচ রকম বাধ্যবাধকতা

“আমাদের এটা মানতে হবে” বললে প্রথম প্রশ্ন হলো: কে বলছে, আর না মানলে কী হবে? নিচের টেবিলে উত্তরটি দেখুন।

২ · পাঁচ কাঠামোর মানচিত্র

পরিচিত নামগুলো একই তালিকায় থাকে বলে মনে হয় সব একই জিনিস। আসলে তা নয়। কোনোটি প্রতিষ্ঠান চালানোর ব্যবস্থা, কোনোটি কাজের তালিকা, কোনোটি বাইরের auditor-এর মতামত। নিচের ছবিতে দেখুন, বাইরের দাবি থেকে প্রমাণ পর্যন্ত স্তরগুলো কীভাবে সাজানো।

টেবিলের ROC, SAQ, AOC আর QSA অংশ ৬-এ বুঝিয়ে বলা হবে। CPA মানে যুক্তরাষ্ট্রের লাইসেন্সপ্রাপ্ত হিসাববিদ, আর AICPA তাঁদের পেশাজীবী সংগঠন।

৩ · ISO/IEC 27001:2022 — পরিচালনার ব্যবস্থা, শুধু control-এর তালিকা নয়

ISO 27001-এর কেন্দ্রে আছে ISMS, অর্থাৎ Information Security Management System. এটি কোনো software নয়। এটি হলো নীতি, দায়িত্ব, ঝুঁকির হিসাব আর উন্নতির একটি চক্র, যা প্রতিষ্ঠান ধারাবাহিকভাবে চালায়। হোটেলের রান্নাঘরে পরিষ্কার থাকা একদিনের কাজ নয়। কে দেখবে, কত দিন পরপর দেখবে, ভুল হলে কী হবে, এই পুরো রুটিনটাই ISMS-এর মতো।

Standard-এর শরীরের ৪ থেকে ১০ নম্বর clause-গুলো পূরণ করা বাধ্যতামূলক। সংক্ষেপে:

তারপর আছে Annex A: ৯৩টি control-এর তালিকা, চারটি theme-এ সাজানো। হিসাব মিলিয়ে নিন: ৩৭ + ৮ + ১৪ + ৩৪ = ৯৩।

এখানে সবচেয়ে কাজের দলিল হলো Statement of Applicability বা SoA. এতে প্রতিটি Annex A control-এর পাশে লেখা থাকে: এটি প্রযোজ্য কি না, কেন, আর বাস্তবায়িত কি না। Annex A কোনো অন্ধ চেকলিস্ট নয়। আগে risk treatment, তারপর সেই সিদ্ধান্ত থেকে control. ISO/IEC 27002 হলো সঙ্গী নির্দেশিকা; এটি বলে control বাস্তবে কীভাবে ভাবা যায়। সনদ দেওয়া হয় ২৭০০১-এ, ২৭০০২-এ নয়।

৪ · NIST CSF 2.0 আর 800 সিরিজ

ফেব্রুয়ারি ২০২৪-এ NIST প্রকাশ করে CSF 2.0 (CSWP 29). এটি বলে না “এই তিনটি যন্ত্র কিনুন।” এটি বলে কোন ফলাফল থাকা দরকার। ফলে ছোট দোকান থেকে বড় ব্যাংক, সবাই একই ভাষায় কথা বলতে পারে। Core-এ আছে ছয়টি Function, ২২টি Category আর ১০৬টি Subcategory. Incident-এর দিক থেকে Function-গুলো আপনি পর্ব ৬১-এ দেখেছেন।

Tier আর Profile দুটি আলাদা জিনিস, আর পরীক্ষায় প্রায়ই গুলিয়ে যায়।

• Tier বলে ঝুঁকি সামলানোর ধরন কতটা গোছানো: Partial (১), Risk Informed (২), Repeatable (৩), Adaptive (৪)। NIST-এর মতে সবাইকে Tier ৪-এ যেতে হবে এমন নয়; লক্ষ্য ঠিক হয় ঝুঁকি আর সামর্থ্য দেখে।
• Profile বলে আপনি কোন ফলাফলে কোথায় আছেন। Current Profile আজকের ছবি, Target Profile লক্ষ্য। দুইয়ের ফাঁক থেকেই কাজের তালিকা আসে।

NIST-এর আরও দুটি দলিলের নাম প্রায়ই শুনবেন:

• SP 800-53 Rev. 5 (২০২০, পরে ছোট হালনাগাদ): মার্কিন ফেডারেল system-এর জন্য বিশাল control ক্যাটালগ, ২০টি family-তে সাজানো। Baseline থাকে সঙ্গী দলিল SP 800-53B-তে। অন্য প্রতিষ্ঠানও এটি রেফারেন্স হিসেবে ব্যবহার করে।
• SP 800-171: সরকারের বাইরের প্রতিষ্ঠান যখন মার্কিন সরকারের নির্দিষ্ট সংবেদনশীল তথ্য (CUI) রাখে, তখনকার শর্ত। Rev. 3 (মে ২০২৪)-এ ১৭টি family আছে। তবে কোনো চুক্তি আগের Rev. 2-কেও ধরে থাকতে পারে, তাই আপনার চুক্তি কোন revision বলে সেটি পড়ুন।

৫ · CIS Controls v8.1 — কোথা থেকে শুরু করব

ISO বলে ব্যবস্থা বানাতে, CSF বলে ফলাফল ভাবতে। কিন্তু দশ জনের একটি প্রতিষ্ঠান সকালে উঠে কোন কাজটি আগে করবে? CIS Controls সেই প্রশ্নের উত্তর দেয়। জুন ২০২৪-এর v8.1-এ আছে ১৮টি Control আর ১৫৩টি Safeguard, অর্থাৎ পরিমাপযোগ্য নির্দিষ্ট কাজ। ক্রমটি ইচ্ছাকৃত: আগে সম্পদের তালিকা, কারণ যা জানেন না তা রক্ষা করবেন কীভাবে?

IG-গুলো ক্রমবর্ধমান: IG2-এর মধ্যে IG1 পুরোটা আছে। তাই ৫৬ + ৭৪ = ১৩০, আর ১৩০ + ২৩ = ১৫৩। পর্ব ৩০-এর CIS Benchmark আলাদা জিনিস: সেটি একটি নির্দিষ্ট OS বা পণ্যের configuration গাইড।

এবার একটি gap assessment করি। নিচের তালিকাটি IG1-এর আদলে বানানো খেলনা তালিকা, CIS-এর আসল Safeguard নয়। ওজনও আমাদের অনুমান।

// Toy list shaped like CIS IG1. Not the official safeguards.
// status: 1 = done with proof, 0.5 = partial, 0 = missing. weight: our toy priority.
const safeguards = [
  ['ASSET',    'hardware inventory kept up to date',    3, 0.5],
  ['ASSET',    'software inventory kept up to date',    2, 0],
  ['DATA',     'sensitive data listed, with owners',    2, 0],
  ['ACCESS',   'MFA on email and remote access',        3, 1],
  ['ACCESS',   'MFA on all admin accounts',             3, 0.5],
  ['ACCESS',   'leavers removed within one day',        2, 1],
  ['VULN',     'critical patches on a set deadline',    3, 0.5],
  ['BACKUP',   'offline backup, restore tested',        3, 0],
  ['LOG',      'audit logs kept and reviewed',          2, 0.5],
  ['PEOPLE',   'phishing reporting taught to staff',    1, 1],
  ['RESPONSE', 'named incident contact, written plan',  2, 0],
];

const family = {};
let earned = 0, possible = 0;
for (const [f, , weight, status] of safeguards) {
  family[f] = family[f] || { earned: 0, possible: 0 };
  family[f].earned += weight * status;
  family[f].possible += weight;
  earned += weight * status;
  possible += weight;
}
for (const [f, s] of Object.entries(family))
  console.log(f.padEnd(9), String(s.earned).padStart(4), '/', String(s.possible).padEnd(2),
    Math.round(100 * s.earned / s.possible) + '%');
console.log('TOTAL    ', earned, '/', possible, '=', Math.round(100 * earned / possible) + '%');

console.log('\nFix first (largest missing weight):');
safeguards.map(([f, name, w, st]) => ({ f, name, gap: w * (1 - st) }))
  .filter(x => x.gap > 0).sort((a, b) => b.gap - a.gap).slice(0, 4)
  .forEach((x, i) => console.log(i + 1, x.gap.toFixed(1), x.name));

ASSET      1.5 / 5  30%
DATA         0 / 2  0%
ACCESS     6.5 / 8  81%
VULN       1.5 / 3  50%
BACKUP       0 / 3  0%
LOG          1 / 2  50%
PEOPLE       1 / 1  100%
RESPONSE     0 / 2  0%
TOTAL     11.5 / 26 = 44%

Fix first (largest missing weight):
1 3.0 offline backup, restore tested
2 2.0 software inventory kept up to date
3 2.0 sensitive data listed, with owners
4 2.0 named incident contact, written plan

৬ · PCI DSS v4.0.1 — কার্ড ডেটা, scope আর SAQ

কার্ড ডেটা যে প্রতিষ্ঠান রাখে, প্রক্রিয়া করে বা পাঠায়, তার জন্য PCI DSS. বড় কার্ড কোম্পানিগুলো মিলে গড়া PCI Security Standards Council এটি দেখাশোনা করে। v4.0.1 প্রকাশিত হয় জুন ২০২৪-এ; v4.0 অবসরে যায় ৩১ ডিসেম্বর ২০২৪, আর ভবিষ্যতের জন্য রাখা নতুন শর্তগুলো কার্যকর হয় ৩১ মার্চ ২০২৫ থেকে। মূল কাঠামো ছয়টি লক্ষ্যের নিচে ১২টি requirement:

এখানে সবচেয়ে বড় ধারণা scope. কার্ডের পুরো নম্বর বা PAN এবং সংবেদনশীল authentication ডেটা যেখানে থাকে, চলে বা প্রক্রিয়া হয়, সেটি cardholder data environment (CDE). CDE-র সাথে যুক্ত system-ও সাধারণত scope-এ পড়ে। ব্যাংকের ভল্টের কথা ভাবুন: ভল্টের দরজা শক্ত, কিন্তু পুরো ভবনের সব কর্মী যদি ভল্টে ঢুকতে পারেন, তাহলে সবাইকেই যাচাই করতে হবে। ভল্টে ঢোকার পথ কমালে পরীক্ষাও কমে, ঝুঁকিও কমে।

Segmentation নিয়ে নিয়মটি সূক্ষ্ম। PCI DSS নিজে segmentation বাধ্যতামূলক করে না, তবে কার্যকর segmentation scope কমাতে পারে। আর যদি আপনি এর ওপর নির্ভর করেন, তাহলে তা পরীক্ষা করে প্রমাণ দিতে হয়। পথের ধারণা পর্ব ২২-এ, অনুমোদিত পরীক্ষা পর্ব ৫০-এ পাবেন।

একই হিসাব কোডে দেখুন। নিয়মটি এখানে সরল করা: কার্ড ডেটা ধরে এমন system, অথবা তার সাথে সরাসরি কথা বলতে পারে এমন system, দুটিই scope-এ। আসল standard-এর সংজ্ঞা আরও বিস্তৃত।

// Toy card environment. Simplified rule: a system is in scope if it
// holds card data, or can talk directly to a system that does.
const all = ['web-1', 'app-1', 'db-card', 'log-1', 'jump-1', 'mail-1',
  'wiki-1', 'build-1', 'hr-pc', 'sales-pc', 'cctv-1', 'guest-ap'];
const HOURS_PER_SYSTEM = 10;   // assumed audit effort, not a real figure

const scenarios = [
  { name: 'A flat network',       cardSystems: ['web-1', 'app-1', 'db-card'],
    links: 'everything' },
  { name: 'B segmented',          cardSystems: ['web-1', 'app-1', 'db-card'],
    links: [['web-1', 'app-1'], ['app-1', 'db-card'], ['app-1', 'log-1'],
            ['db-card', 'log-1'], ['jump-1', 'app-1'], ['jump-1', 'db-card']] },
  { name: 'C hosted page + token', cardSystems: [],
    links: [], touchesPayment: ['web-1'] },
];

function scope(s) {
  const inside = new Set([...s.cardSystems, ...(s.touchesPayment || [])]);
  for (const sys of all) {
    const reach = s.links === 'everything'
      ? s.cardSystems.length > 0
      : s.links.some(([a, b]) => (a === sys && s.cardSystems.includes(b))
                              || (b === sys && s.cardSystems.includes(a)));
    if (reach) inside.add(sys);
  }
  return all.filter(x => inside.has(x));
}

for (const s of scenarios) {
  const list = scope(s);
  const out = all.length - list.length;
  console.log(s.name.padEnd(22), 'in scope:', String(list.length).padStart(2),
    '| out:', String(out).padStart(2), '| audit hours:', list.length * HOURS_PER_SYSTEM);
  console.log('   ', list.join(' '));
}

A flat network         in scope: 12 | out:  0 | audit hours: 120
    web-1 app-1 db-card log-1 jump-1 mail-1 wiki-1 build-1 hr-pc sales-pc cctv-1 guest-ap
B segmented            in scope:  5 | out:  7 | audit hours: 50
    web-1 app-1 db-card log-1 jump-1
C hosted page + token  in scope:  1 | out: 11 | audit hours: 10
    web-1

SAQ না ROC? SAQ (Self-Assessment Questionnaire) হলো নিজের মূল্যায়নের ফর্ম। এর কয়েকটি ধরন আছে: সব কার্ডের কাজ বাইরে দেওয়া e-commerce-এর জন্য SAQ A, পাতা নিজের কিন্তু কার্ড ডেটা সরাসরি সেবাদাতার কাছে গেলে সাধারণত SAQ A-EP, আর অন্য অনেক ক্ষেত্রে দীর্ঘ SAQ D. বড় পরিসরে QSA এসে ROC (Report on Compliance) লেখেন। দুই ক্ষেত্রেই সাধারণত একটি AOC (Attestation of Compliance) সই হয়। লেনদেনের সংখ্যা অনুযায়ী level কার্ড কোম্পানির নিয়মে ঠিক হয়, আর আপনার acquirer কী চান, সেটিই আপনার জন্য চূড়ান্ত।

৭ · SOC 2, HIPAA আর খাতভিত্তিক নিয়ম

প্রথমে একটি নামের ফাঁদ। পর্ব ৬০-এর SOC মানে Security Operations Center. আর SOC 2-এর SOC মানে System and Organization Controls. দুটির মধ্যে কোনো সম্পর্ক নেই।

SOC 2 কোনো সনদ নয়। এটি একটি স্বাধীন CPA প্রতিষ্ঠানের লেখা report, যেখানে তারা একটি সেবা-প্রতিষ্ঠানের control নিয়ে নিজের মতামত দেয়। ভিত্তি হলো AICPA-র Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality আর Privacy. এর মধ্যে Security সব SOC 2-তে থাকে; বাকিগুলো সেবা আর প্রতিশ্রুতি দেখে বেছে নেওয়া হয়। SaaS কোম্পানির সাথে মার্কিন client-এর চুক্তিতে এটি বেশি দেখা যায়।

Client হিসেবে report পড়লে শুধু auditor-এর মতামত দেখবেন না। দেখবেন কোন সেবা scope-এ, সময়কাল কবে পর্যন্ত, কোথায় exception (control ঠিকমতো চলেনি এমন ঘটনা) আছে, আর “আপনাকে নিজে কী করতে হবে” অংশটি। Cloud provider-এর মতো সহযোগীকে report থেকে বাদ রাখা (carve-out) হয়েছে কি না, সেটিও দেখুন। এই পড়ার দক্ষতা পর্ব ৭১-এ আরও কাজে লাগবে।

আরও কিছু নিয়ম, সংক্ষেপে

• HIPAA (যুক্তরাষ্ট্র, ১৯৯৬): স্বাস্থ্য তথ্যের আইন। Security Rule প্রযোজ্য স্বাস্থ্যসেবা প্রতিষ্ঠান আর তাদের business associate-এর ওপর। বাংলাদেশের medical billing বা transcription প্রতিষ্ঠান সরাসরি নিয়ন্ত্রিত না হলেও চুক্তির মাধ্যমে এই শর্তে বাঁধা পড়তে পারে।
• GDPR: EU-র মানুষের ব্যক্তিগত তথ্য নিয়ে কাজ করলে প্রাসঙ্গিক। পর্ব ৭০-এ আসছে।
• ব্যাংক ও আর্থিক খাত: দেশে Bangladesh Bank-এর নির্দেশিকা; আন্তর্জাতিক লেনদেনে SWIFT-এর Customer Security Programme.
• EU-র খাতভিত্তিক নিয়ম: NIS2 আর DORA. EU client থাকলে তাঁরা এই দাবি চুক্তির মাধ্যমে আপনার দিকে পাঠাতে পারেন।

আপনার ক্ষেত্রে কোনটি প্রযোজ্য, তা ঠিক করার দায়িত্ব আইনজীবী আর compliance-দায়িত্বপ্রাপ্ত ব্যক্তির। এই তালিকা শুধু দিকনির্দেশ।

৮ · Crosswalk, evidence আর audit-প্রস্তুতি

ধরুন আপনাকে একসাথে ISO 27001, SOC 2 আর একটি client-এর প্রশ্নপত্র সামলাতে হবে। আলাদা তিনটি দল তিনবার একই MFA report জোগাড় করলে সময় নষ্ট। সমাধান হলো একটি নিজস্ব control তালিকা, আর তার সাথে প্রতিটি standard-এর crosswalk, অর্থাৎ কোন control কোন দাবির সাথে সম্পর্কিত তার মানচিত্র। NIST তার informative reference-গুলোতে CSF-এর সাথে অন্য দলিলের সম্পর্ক প্রকাশ করে; CIS-ও mapping প্রকাশ করে।

// Toy crosswalk. Teaching sample: always check a real mapping before use.
// A mapping says "these are related", not "these are the same".
const map = {
  mfa:       { iso: 'A.8.5',  csf: 'PR.AA-03', cis: '6.3-6.5', pci: '8.4',
               soc2: 'CC6.1', evidence: 'IdP MFA report' },
  logging:   { iso: 'A.8.15', csf: 'PR.PS-04', cis: '8',       pci: '10',
               soc2: 'CC7.2', evidence: 'SIEM retention screenshot' },
  patching:  { iso: 'A.8.8',  csf: 'PR.PS-02', cis: '7',       pci: '6.3',
               soc2: 'CC7.1', evidence: 'patch status export' },
  inventory: { iso: 'A.5.9',  csf: 'ID.AM-01', cis: '1',       pci: '12.5.1',
               soc2: 'CC6.1', evidence: 'asset register export' },
  backup:    { iso: 'A.8.13', csf: 'PR.DS-11', cis: '11',      pci: null,
               soc2: 'A1.2',  evidence: 'restore test record' },
};
const frameworks = ['iso', 'csf', 'cis', 'pci', 'soc2'];

function lookup(name) {
  const row = map[name];
  if (!row) return console.log(name + ': no mapping, read the standard itself');
  const refs = frameworks.map(f => f + '=' + (row[f] || 'none'));
  console.log(name.padEnd(10), refs.join(' '));
  console.log(' '.repeat(10), 'one proof:', row.evidence);
}
['mfa', 'backup', 'dlp'].forEach(lookup);

// How many separate requests does one proof answer?
let requests = 0;
for (const row of Object.values(map))
  requests += frameworks.filter(f => row[f]).length;
const proofs = Object.keys(map).length;
console.log('\nrequests:', requests, '| proofs needed:', proofs,
  '| reuse:', (requests / proofs).toFixed(1), 'requests per proof');

mfa        iso=A.8.5 csf=PR.AA-03 cis=6.3-6.5 pci=8.4 soc2=CC6.1
           one proof: IdP MFA report
backup     iso=A.8.13 csf=PR.DS-11 cis=11 pci=none soc2=A1.2
           one proof: restore test record
dlp: no mapping, read the standard itself

requests: 24 | proofs needed: 5 | reuse: 4.8 requests per proof

ভালো evidence কেমন

Audit evidence হলো এমন জিনিস যা অন্য একজন যাচাই করতে পারেন। পুলিশ-ফাঁড়ির রেজিস্টার খাতার মতো: তারিখ, কে লিখেছেন, ঘষামাজা নেই। ভালো evidence-এর পাঁচটি গুণ:

• সময় লেখা: কোন তারিখ বা সময়কালের প্রমাণ।
• উৎস পরিষ্কার: System থেকে সরাসরি পাওয়া, হাতে টাইপ করা নয়।
• পুরো তালিকা (population): “৩ জন ছেড়েছেন” বলার আগে জানতে হবে মোট কতজন ছেড়েছেন।
• Scope মেলে: ভুল account বা পরিবেশের screenshot নয়।
• মালিক আছে: কে সংগ্রহ করলেন, কে দেখলেন।

নকশা আর চালু থাকা আলাদা জিনিস। নীতি বলছে “প্রতি প্রান্তিকে access review হবে।” এটি নকশা। মার্চের সই করা review রেকর্ড হলো চালু থাকার প্রমাণ। Evidence-এর মেয়াদও থাকে, তাই audit-এর আগের সপ্তাহে ছোটাছুটি না করে সারা বছর তার হিসাব রাখা যায়:

// Evidence freshness on a simulated clock. Dates are invented.
const day = s => Date.UTC(+s.slice(0, 4), +s.slice(5, 7) - 1, +s.slice(8, 10)) / 86400000;
const today = day('2026-10-01');   // fixed, so the output never changes
const WARN_DAYS = 30;

// [what, owner, collected on, valid for N days, automated?]
const evidence = [
  ['MFA status report',       'IT',      '2026-09-28',  30, true],
  ['Access review, finance',  'Finance', '2026-07-10',  90, false],
  ['Restore test record',     'IT',      '2026-03-15', 180, false],
  ['Patch status export',     'IT',      '2026-08-20',  30, true],
  ['Penetration test report', 'CISO',    '2025-11-20', 365, false],
  ['Staff awareness roster',  'HR',      '2025-09-30', 365, false],
];

const tally = { FRESH: 0, 'DUE SOON': 0, STALE: 0 };
const rows = evidence.map(([what, owner, got, valid, auto]) => {
  const left = day(got) + valid - today;
  const state = left < 0 ? 'STALE' : left <= WARN_DAYS ? 'DUE SOON' : 'FRESH';
  tally[state] += 1;
  return { what, owner, left, state, auto };
}).sort((a, b) => a.left - b.left);

for (const r of rows)
  console.log(r.state.padEnd(9), String(r.left).padStart(4) + 'd',
    r.owner.padEnd(8), r.what, r.auto ? '(auto)' : '');
console.log('fresh:', tally.FRESH, '| due soon:', tally['DUE SOON'], '| stale:', tally.STALE);

// A broken automated job is the quiet risk: stale and marked auto.
const broken = rows.filter(r => r.state === 'STALE' && r.auto).map(r => r.what);
console.log('auto jobs to check:', broken.join(', ') || 'none');

STALE      -20d IT       Restore test record
STALE      -12d IT       Patch status export (auto)
STALE       -1d HR       Staff awareness roster
DUE SOON     7d Finance  Access review, finance
DUE SOON    27d IT       MFA status report (auto)
FRESH       50d CISO     Penetration test report
fresh: 1 | due soon: 2 | stale: 3
auto jobs to check: Patch status export

Compliance automation মানে API দিয়ে cloud, identity আর ticket system থেকে নিয়মিত evidence টেনে আনা। এতে screenshot-এর বোঝা কমে আর ভুল আগে ধরা পড়ে (Cloud posture দেখুন)। তবে যন্ত্র বলতে পারে “setting চালু”, বলতে পারে না “ঝুঁকিটি ঠিকভাবে বিচার হয়েছে।” সবুজ dashboard আর নিরাপদ প্রতিষ্ঠান একই জিনিস নয়।

Audit-প্রস্তুতি একটি অভ্যাস। প্রতিটি control-এর একজন মালিক রাখুন। লিখিত নীতি বাস্তবের সাথে মেলান। ব্যতিক্রম মালিক আর মেয়াদসহ খাতায় তুলুন। বছরে একবার mock audit করুন, যেখানে কেউ একটি নমুনা চেয়ে দেখবেন, “গত মাসের এই তিনটি change-এর approval দেখান।” আর একটি সীমারেখা মনে রাখুন: পরে বানানো তারিখ বা সাজানো evidence ভুল নয়, প্রতারণা। ফাঁক থাকলে ফাঁকটি বলুন।

৯ · ছোট কোম্পানির পথ আর কাগুজে নিরাপত্তার ফাঁদ

ঢাকার একটি কাল্পনিক ৩০ জনের software কোম্পানির কথা ভাবুন। একটি বিদেশি client ই-মেইলে লিখলেন, “চুক্তির আগে এই ৪০ প্রশ্নের security questionnaire পূরণ করে দিন।” এমন security questionnaire ছোট প্রতিষ্ঠানের জন্য প্রায়ই compliance-এর প্রথম সাক্ষাৎ। তাড়াহুড়োয় সব প্রশ্নে “Yes” লিখে দেওয়ার লোভ হয়। এখানেই ভুল হয়।

কোনটি আগে নেবেন

মূল নিয়ম: আগে জিজ্ঞেস করুন client আসলে কী চান। অনেক সময় “ISO চাই” বলার পেছনে থাকে “আমাদের ঝুঁকি দল সন্তুষ্ট হবে এমন প্রমাণ চাই।” তাহলে কী লাগবে, সেটি পরিষ্কার হলে অকারণ খরচ বাঁচে।

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

Audit fatigue আর কাগুজে নিরাপত্তা

প্রতি বছর একাধিক audit, শত শত প্রশ্ন, একই screenshot বারবার। এই ক্লান্তির নাম audit fatigue. তখন দল নিরাপত্তা ভাবা ছেড়ে শুধু “পাস” করার কথা ভাবে। এটিই paper compliance: নীতি আছে, মানে না কেউ। পর্ব ৫৪-এর compliance budget-এর কথা মনে করুন: মানুষের মনোযোগ সীমিত। লক্ষণগুলো হলো: audit-এর আগের মাসেই সব “চালু” হয়, নীতি অন্য কোম্পানি থেকে কপি করা, কেউ জানে না risk register কোথায়, আর finding প্রতি বছর একই।

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

• Heartland, ২০০৮: প্রতিষ্ঠানটি জানিয়েছিল যে এপ্রিল ২০০৮-এ তারা PCI-সনদপ্রাপ্ত ছিল। ঘটনাটি প্রকাশের পর মার্চ ২০০৯-এ Visa তাদের compliant service provider তালিকা থেকে সরায়, পরে নতুন assessment-এর পথ খোলা থাকে। ঘটনার সময় তারা সত্যিই compliant ছিল কি না, তা নিয়ে মতভেদ আছে।
• Target, ২০১৩: সংবাদে এসেছে, প্রতিষ্ঠানটি হামলার অল্প আগেই PCI compliant বলে স্বীকৃত হয়েছিল বলে জানিয়েছিল। মার্কিন সিনেটের রিপোর্ট দেখায় vendor-এর প্রবেশ, segmentation আর alert-এ ফাঁক ছিল বলে মনে হয় (পর্ব ৬৫)।
• Capital One, ২০১৯: বড় নিয়ন্ত্রিত ব্যাংকেও ঘটনা ঘটেছে। OCC-র অভিযোগে risk assessment আর internal audit-এর দুর্বলতার কথা আসে।

এগুলো থেকে “audit অকেজো” সিদ্ধান্ত নেওয়া ঠিক নয়। শিক্ষা হলো: assessment হলো একটি সময়ের, নমুনার ভিত্তিতে নেওয়া ছবি। হামলাকারী ছবির বাইরের দিনগুলোতে আসে। তাই সনদের পাশে থাকতে হবে নিয়মিত detection, মহড়া আর সৎ পরিমাপ। ঘটনার পরে কারণ বলা সহজ, তাই hindsight bias-ও মনে রাখুন।

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

Compliance-এর কাজে লেখা অনেক, তাই AI লোভনীয়। নীতির খসড়া, control-এর তুলনা বা প্রশ্নপত্রের প্রথম উত্তর দ্রুত আসে। কিন্তু এই ক্ষেত্রে ভুল প্রায়ই আত্মবিশ্বাসী ভাষায় আসে, আর আপনার সইয়ের নিচে গিয়ে সেই ভুল আপনার হয়ে যায়।

AI-এর সাহায্যে compliance-এর কাজ করলে — চেকলিস্ট

• প্রতিটি control বা clause নম্বর মূল দলিলের সর্বশেষ সংস্করণে মিলিয়েছি
• Standard-এর দীর্ঘ অংশ কপি না করে নিজের ভাষায় লিখেছি; মূল দলিল লাইসেন্স মেনে ব্যবহার করেছি
• নীতির প্রতিটি “হবে” বাক্য আমাদের বাস্তব কাজের সাথে মিলিয়ে দেখেছি
• Prompt-এ secret, client-এর ডেটা বা কর্মীর ব্যক্তিগত তথ্য দিইনি
• প্রতিটি “Yes”-এর পাশে evidence আছে, আর সই করেছেন একজন মানুষ