অডিটরের দৃষ্টিভঙ্গি: একজন IS অডিটরের মতো চিন্তা করা

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

ঝুঁকি প্রথম, প্রযুক্তি দ্বিতীয়

একটি penetration tester জিজ্ঞাসা করে "আমি কি এটি ভাঙতে পারি?" একজন অডিটর জিজ্ঞাসা করে "এটি কি গুরুত্বপূর্ণ, এবং যদি এটি ব্যর্থ হয়, ব্যবসায়ের কী হয়?" একটি একক নিয়ন্ত্রণ স্পর্শ করার আগে, একজন অডিটর বোঝার চেষ্টা করে সিস্টেমটি কী করে, এটি কী ডেটা স্পর্শ করে, এবং গোপনীয়তা, অখণ্ডতা বা উপলব্ধতা ক্ষতিগ্রস্ত হলে কী ভুল হবে। এটিই কারণ অডিট প্রোগ্রামগুলি সাধারণত একটি vulnerability scan নয়, একটি ঝুঁকি মূল্যায়ন বা একটি walkthrough দিয়ে শুরু হয়।

ব্যবহারিকভাবে: যদি আপনি একটি পেরোল সিস্টেমে অ্যাক্সেস নিয়ন্ত্রণগুলি অডিট করছেন, প্রথম প্রশ্নটি "MFA সক্ষম করা আছে কিনা?" নয়। এটি "যদি একজন অননুমোদিত ব্যক্তি বেতন ডেটা পরিবর্তন করতে বা PII দেখতে পারে তবে প্রভাব কী?" একবার আপনি প্রভাব জানলে, আপনি বিচার করতে পারেন বিদ্যমান নিয়ন্ত্রণগুলি (MFA, অনুমোদন workflows, কর্তব্যের বিভাজন) আনুপাতিক কিনা।

প্রমাণ বনাম assertion

সিস্টেম মালিকরা আপনাকে বলবে জিনিসগুলি কাজ করে। একজন অডিটরের কাজ হল যাচাই করা, বিশ্বাস করা নয়। এর মানে artifacts এর জন্য জিজ্ঞাসা করা: একটি কনফিগারেশন পর্দার স্ক্রিনশট, ব্যবহারকারী অ্যাক্সেস অধিকারের একটি export, অনুমোদন timestamps সহ একটি change ticket, একটি লগ entry যা দেখায় একটি নিয়ন্ত্রণ সত্যিই fired হয়েছে। যদি কেউ বলে "আমরা ত্রৈমাসিক ভিত্তিতে অ্যাক্সেস review করি," অডিটর শেষ তিনটি review record দেখার জন্য বলে, শুধুমাত্র নীতি নয় যা এটি mandate করে।

এই evidence-based অভ্যাস হল যা একটি audit finding কে একটি hallway conversation থেকে আলাদা করে। একটি finding কে scrutiny সহ্য করতে হবে: কী পরীক্ষা করা হয়েছে, জনসংখ্যার কী sampling করা হয়েছে, কী criteria ব্যবহার করা হয়েছে, এবং কী সত্যিই observed হয়েছে। "নিয়ন্ত্রণগুলি পর্যাপ্ত মনে হয়" এর মতো vague statements একটি রিপোর্টে hold up করে না যা management এবং regulators পড়বে।

Design বনাম operating effectiveness

এই ক্ষেত্রের সবচেয়ে উপকারী মানসিক বিভাজনগুলির মধ্যে একটি হল control design কে control operation থেকে আলাদা করা। একটি পাসওয়ার্ড নীতি যা 14 অক্ষর এবং MFA প্রয়োজন করে কাগজে ভালভাবে ডিজাইন করা হয়েছে। কিন্তু যদি শেষ access review ছিল 11 মাস আগে, বা যদি service accounts বিনা documentation exempt করা হয়, তাহলে নিয়ন্ত্রণ intended অনুযায়ী operate করছে না। অডিটররা উভয় পরীক্ষা করে: নিয়ন্ত্রণটি বর্ণিত হিসাবে বিদ্যমান আছে কিনা, এবং এটি সত্যিই দিনে দিনে followed হচ্ছে কিনা?

এটিই sampling গুরুত্বপূর্ণ কেন। একজন ব্যবহারকারীর অ্যাক্সেস পরীক্ষা করা আপনাকে খুব বেশি বলে না। 25 টি terminated employees এর একটি sample টানা এবং checking করা তাদের accounts disable করা হয়েছে কিনা SLA window এর মধ্যে (say, 24 বা 48 ঘণ্টা) আপনাকে একটি conclusion এর জন্য একটি defensible basis দেয়।

Segregation of duties একটি recurring theme হিসেবে

audit findings এর একটি বিশাল অংশ segregation of duties (SoD) এর দিকে trace করে: একই ব্যক্তি যে একটি change request করে তা অনুমোদন করে, বা একজন developer এর কাছে একই সাথে production database access এবং deployment rights রয়েছে। অডিটররা ক্রমাগত এই overlaps দেখে, কারণ SoD failures হল কীভাবে fraud এবং unintentional errors slip through করে একটি দ্বিতীয় set of eyes ছাড়াই তাদের catch করার জন্য।

একটি environment review করার সময়, জিজ্ঞাসা করুন: একটি action initiate করতে কে পারে, একে অনুমোদন করতে কে পারে, এবং একে execute করতে কে পারে? যদি একজন ব্যক্তি একটি compensating control ছাড়াই দুটি বা তার বেশি ভূমিকা ধরে রাখে (যেমন detailed logging যা কেউ অন্য ব্যক্তি review করে), তাহলে এটি একটি gap documentation এর যোগ্য।

Findings লেখা যা fixed হয়

একটি technically correct finding যা কেউ act করে না একটি wasted audit। ভাল findings state করে condition (কী observed হয়েছে), criteria (কী নীতি বা মান এটি violate করে), cause (এটি কেন ঘটেছে), এবং effect (এই ঝুঁকি কী তৈরি করে) — অনেক audit shops ব্যবহার করে classic 4C structure। Vague findings যেমন "অ্যাক্সেস নিয়ন্ত্রণ উন্নত করতে হবে" ignored হয়। Specific ones যেমন "25 জন sampled terminated employees এর মধ্যে 14 জন তাদের termination date এর পাস 5 দিনের বেশি VPN অ্যাক্সেস রাখেন, নীতি SEC-014 এ 24-ঘণ্টার deprovisioning SLA violate করে" remediated হয় কারণ মালিক ঠিক জানে কী fix করতে হবে।

অভ্যাস গঠন

আপনি formal engagements নয়, ordinary systems এ এটি practice করে এই frame develop করেন। একটি application pick করুন যা আপনি daily ব্যবহার করেন এবং জিজ্ঞাসা করুন: এটি fail হলে ঝুঁকি কী, কী নিয়ন্ত্রণ বিদ্যমান, এবং আমি কীভাবে প্রমাণ করব তারা কাজ করে? যথেষ্ট বার এটি করুন এবং অডিটরের instinct — skepticism paired with a demand for evidence — automatic হয়ে যায়।

যদি এই ধরনের control-and-risk চিন্তা আপনাকে আগ্রহী করে, access control models এবং security governance frameworks এ আরও গভীর technical grounding এর জন্য Korra Studio এর segments check out করুন।