তৃতীয়-পক্ষীয় ঝুঁকি সম্পূর্ণ থেকে শেষ পর্যন্ত: একটি ব্যবহারিক পরিভাষা

তৃতীয়-পক্ষীয় ঝুঁকি একটি স্বাক্ষরিত চুক্তি বা সম্পন্ন প্রশ্নাবলীতে থেমে থাকে না। "সম্পূর্ণ থেকে শেষ পর্যন্ত" মানে সরবরাহকারীর ঝুঁকিকে একটি জীবনচক্র হিসেবে বিবেচনা করা: যেই মুহূর্ত থেকে আপনি একটি সরবরাহকারীকে বিবেচনা করেন, সম্পূর্ণ সম্পর্ক জুড়ে, সেই দিন পর্যন্ত যখন আপনি সম্পর্ক ছিন্ন করেন এবং তাদের অ্যাক্সেস রদ করেন। সরবরাহকারীদের সাথে সম্পর্কিত বেশিরভাগ লঙ্ঘন ঘটে কারণ সংস্থাগুলি একটি পর্যায়ে ঝুঁকি পরিচালনা করে (সাধারণত অনবোর্ডিং) এবং বাকিটি ভুলে যায়।

সম্পূর্ণ থেকে শেষ পর্যন্ত প্রকৃতপক্ষে কী কভার করে

একটি সম্পূর্ণ তৃতীয়-পক্ষীয় ঝুঁকি প্রোগ্রাম চারটি স্বতন্ত্র পর্যায় স্পর্শ করে, প্রতিটির নিজস্ব নিয়ন্ত্রণ রয়েছে:

1. যথাযথ পরিশ্রম এবং নির্বাচন - আপনি কোনো কিছুতে স্বাক্ষর করার আগে, সরবরাহকারীর নিরাপত্তা অবস্থান মূল্যায়ন করুন। এতে SOC 2 রিপোর্ট পর্যালোচনা, ISO 27001 সার্টিফিকেশন, penetration test সারসংক্ষেপ এবং তাদের নিজস্ব উপঠিকাদার তালিকা অন্তর্ভুক্ত রয়েছে (চতুর্থ-পক্ষীয় ঝুঁকি এখানে লুকিয়ে থাকে)।
2. অনবোর্ডিং এবং চুক্তি - ডেটা হ্যান্ডলিং শর্তাবলী, লঙ্ঘনের বিজ্ঞপ্তি সময়সীমা, audit এর অধিকার শর্তাবলী এবং শুধুমাত্র একটি পাশের প্রশ্নাবলী নয় চুক্তিতেই অ্যাক্সেস স্কোপ সংজ্ঞায়িত করা।
3. চলমান পর্যবেক্ষণ - ক্রমাগত বা পর্যায়ক্রমিক পরীক্ষা: attack surface স্ক্যানিং, নিরাপত্তা রেটিং পরিষেবা (BitSight, SecurityScorecard), তাদের patch cadence পর্যালোচনা এবং তারা উপপ্রসেসর পরিবর্তন করলে বা একটি ঘটনা ঘটালে পুনর্মূল্যায়ন।
4. অফবোর্ডিং এবং সমাপ্তি - API keys, VPN অ্যাক্সেস, shared credentials রদ করা এবং চুক্তি অনুযায়ী ডেটা deletion বা return নিশ্চিত করা।

বেশিরভাগ প্রোগ্রাম ধাপ 1 এবং 2 এ শক্তিশালী এবং ধাপ 3 এবং 4 এ দুর্বল। 2022 সালে কম-ঝুঁকি হিসাবে মূল্যায়িত একটি সরবরাহকারী 2024 সালে unpatched সফ্টওয়্যার চালাচ্ছে হতে পারে, এবং কেউ যাচাই করেনি কারণ প্রশ্নাবলী একটি এককালীন গেট ছিল।

কেন চলমান পর্যায় যেখানে প্রোগ্রামগুলি ব্যর্থ হয়

অনবোর্ডিং প্রশ্নাবলী একটি স্ন্যাপশট। তারা আপনাকে বলে একটি সরবরাহকারীর নিরাপত্তা ফর্ম পূরণ করার দিনে কেমন ছিল। Attack surface সাপ্তাহিক পরিবর্তন হয়। একটি সরবরাহকারীর exposed S3 bucket, একটি expired TLS cert, সফ্টওয়্যারে একটি নতুন প্রকাশিত CVE যা তারা চালায় — কোনোটাই একটি point-in-time SIG বা CAIQ প্রশ্নাবলীতে দেখা যায় না।

সম্পূর্ণ থেকে শেষ পর্যন্ত প্রোগ্রামগুলি এটি সমাধান করে:

• Tiering - প্রতিটি সরবরাহকারীর একই পরিমাণে যাচাইকরণের প্রয়োজন নেই। PII-এ অ্যাক্সেস সহ একটি payroll প্রসেসর একটি office supplies সরবরাহকারীর চেয়ে গভীর এবং আরও ঘন ঘন পর্যালোচনা পায়। চুক্তির ডলার মূল্য নয়, ডেটা সংবেদনশীলতা এবং সিস্টেম অ্যাক্সেসের উপর ভিত্তি করে Tier করুন।
• স্বয়ংক্রিয় attack surface পর্যবেক্ষণ - সরঞ্জাম যা ক্রমাগত একটি সরবরাহকারীর জনসম্মুখ অবকাঠামো স্ক্যান করে খোলা ports, expired certs, paste sites-এ leaked credentials এবং exposed cloud storage-এর জন্য।
• Trigger-based পুনর্মূল্যায়ন - বার্ষিক renewal cycle-এর জন্য অপেক্ষা না করে একটি publicly প্রকাশিত breach, একটি merger/acquisition বা একটি significant product change-এর পরে অবিলম্বে একটি সরবরাহকারীর পুনর্পর্যালোচনা করুন।

অ্যাক্সেস সমস্যা কেউ ভালোভাবে ট্র্যাক করে না

এটি একটি ফাঁক যা ঘটনা postmortems-এ ক্রমাগত দেখা যায়: সরবরাহকারীরা সময়ের সাথে সাথে অ্যাক্সেস জমা করে এবং কেউ এটি prune করে না। একটি ঠিকাদার যার একটি তিন-মাসের প্রকল্পের জন্য VPN অ্যাক্সেসের প্রয়োজন ছিল আজও আঠারো মাস পরে বৈধ শংসাপত্র রয়েছে। একটি একীকরণ অংশীদারের API key কখনও প্রাথমিক pilot-এর পরে scoped down হয়নি।

সম্পূর্ণ থেকে শেষ পর্যন্ত ঝুঁকি ব্যবস্থাপনার জন্য শুধু একটি IT অ্যাসেট তালিকা নয়, সরবরাহকারী জীবনচক্র স্থিতির সাথে সংযুক্ত একটি অ্যাক্সেস ইনভেন্টরি প্রয়োজন। যখন একটি সরবরাহকারী সম্পর্ক শেষ হয়, কাউকে একটি checklist প্রয়োজন: SSO/SAML এন্ট্রি revoke করুন, shared API keys rotate করুন, firewalls এবং VPCs-এ allowlists থেকে সরান, ডেটা destruction সার্টিফিকেট নিশ্চিত করুন। এই ধাপ ছাড়িয়ে যাওয়া হল কীভাবে প্রাক্তন সরবরাহকারীরা চুক্তি শেষ হওয়ার বছর পরে ঘটনাগুলিতে প্রাথমিক অ্যাক্সেস ভেক্টর হয়ে ওঠে।

এই সপ্তাহ প্রয়োগ করার জন্য ব্যবহারিক framework

আপনি যদি একটি তৃতীয়-পক্ষীয় ঝুঁকি প্রোগ্রাম তৈরি বা audit করছেন, প্রথমে এই ফাঁকগুলির জন্য পরীক্ষা করুন:

• একটি documented tiering মডেল আছে, নাকি প্রতিটি সরবরাহকারী অ্যাক্সেস স্তর নির্বিশেষে একই প্রশ্নাবলী পায়?
• আপনার কাছে continuous monitoring আছে, নাকি শুধুমাত্র renewal-time পর্যালোচনা আছে?
• একটি formal offboarding checklist আছে যা credential revocation এবং data confirmation অন্তর্ভুক্ত করে?
• আপনার incident response plan স্পষ্টভাবে তৃতীয়-পক্ষীয়-originated ঘটনা কভার করে, কে কাকে নোটিফাই করে এবং কী সময়সীমার মধ্যে সহ?
• আপনি চতুর্থ পক্ষ (আপনার সরবরাহকারীদের সরবরাহকারী) ট্র্যাক করেন, নাকি দৃশ্যমানতা direct contract-এ থামে?

NIST SP 800-161 এবং ISO 27036-এর মতো frameworks এটিতে কাঠামো প্রদান করে, কিন্তু প্রকৃত শৃঙ্খলা সরবরাহকারী ঝুঁকিকে বছরে একবার পূরণ করা compliance checkbox নয় একটি ক্রমাগত প্রক্রিয়া হিসেবে বিবেচনা করা থেকে আসে যা একটি নির্দিষ্ট দল মালিক করে।

এটি তৈরি করার বিষয়ে আরও জানতে, Korra Studio-এর Blue Team-এর মধ্যে vendor risk frameworks, access control lifecycle management এবং incident response planning-এর সেগমেন্টগুলি দেখুন।