چارچوب حسابرس: تفکر مثل یک حسابرس IS
نگاهی عملی به روشی که حسابرسان IS در مورد ریسک، کنترلها و شواهد استدلال میکنند — و چگونه این ذهنیت را در خود بسازید.
یک حسابرس IS برای یافتن هر خرابی یا پیکربندی غلط در یک سیستم استخدام نمیشود. کار باریکتر است و درستتر بگویم، سختتر: تشخیص اینکه آیا کنترلهای موجود اطمینان معقول میدهند که ریسکهای تجاری مدیریت میشوند یا خیر. این تمایز روش شما را برای تقریباً هر کار، از خواندن مجموعه قوانین دیوار آتش گرفته تا مصاحبه با صاحب سیستم تغییر میدهد.
ریسک اول، فناوری دوم
یک تست نفوذی میپرسد "آیا میتوانم این را بشکنم؟" یک حسابرس میپرسد "آیا این اهمیت دارد، و اگر ناموفق شود چه اتفاقی برای تجارت میافتد؟" قبل از لمس هر کنترل، حسابرس سعی میکند بفهمد که سیستم چه کاری انجام میدهد، چه دادههایی را لمس میکند و اگر رازداری، تمامیت یا دسترسپذیری به خطر بیفتد چه اتفاقی خواهد افتاد. این همان دلیلی است که برنامههای حسابرسی معمولاً با یک ارزیابی ریسک یا یک پیادهروی شروع میشوند، نه با یک اسکن آسیبپذیری.
بهطور عملی: اگر کنترلهای دسترسی روی سیستم حقوق و دستمزد را حسابرسی میکنید، سوال اول این نیست که "آیا MFA فعال است؟" بلکه "اگر فردی غیرمجاز میتواند دادههای حقوق را تغییر دهد یا PII را مشاهده کند تأثیر چیست؟" پس از آنکه تأثیر را بدانید، میتوانید قضاوت کنید که آیا کنترلهای موجود (MFA، گردشهای تصویب، تفکیک وظایف) متناسب هستند یا خیر.
شواهد نسبت به ادعا
صاحبان سیستم به شما میگویند که چیزها کار میکند. کار حسابرس تأیید است، نه اعتماد. این بدان معناست که از شما داراییهای درخواستی میکند: نقطهبرداری از صفحه پیکربندی، خروجی حقوق دسترسی کاربر، قسیمت تغییر با مهرهای زمانی تصویب، ورودیهای گزارش که نشان میدهند یک کنترل واقعاً فعال شده است. اگر کسی میگوید "ما هر سه ماه دسترسی را بررسی میکنیم"، حسابرس میخواهد سه سابقه بررسی آخر را ببیند، نه فقط سیاستی که آن را الزام میکند.
این عادت مبتنی بر شواهد آن است که یک بررسی از یک گفتگو در راهروا متمایز میکند. یک بررسی باید از تحقیق نجات یابد: چه چیزی تست شد، چه جمعیتی نمونهگیری شد، چه معیارهایی استفاده شد و چه اتفاقی واقعاً مشاهده شد. بیانیههای مبهم مانند "کنترلها کافی به نظر میرسند" در گزارشی که مدیریت و نظارتگران آن را میخوانند پایدار نیستند.
طراحی در مقابل اثربخشی عملیاتی
یکی از بیشترین تقسیمبندیهای ذهنی مفید در این زمینه جداسازی طراحی کنترل از عملیات کنترل است. سیاست رمز عبور که 14 کاراکتر و MFA را ایجاب میکند در کاغذ خوب طراحی شده است. اما اگر آخرین بررسی دسترسی 11 ماه پیش بود یا اگر حسابهای سرویس بدون مستندات مستثنی شوند، کنترل همانطور که در نظر گرفته شده عمل نمیکند. حسابرسان هر دو را تست میکنند: آیا کنترل همانطور که توضیح داده شده است وجود دارد، و آیا واقعاً روزانه دنبال میشود؟
این دلیلی است که نمونهگیری اهمیت دارد. تست دسترسی یک کاربر بسیار اطلاعات نمیدهد. کشیدن نمونهای از 25 کارمند منقضیشده و بررسی اینکه آیا حسابهای آنها در پنجره SLA غیرفعال شدهاند (مثلاً 24 یا 48 ساعت)، پایهای قابل دفاع برای نتیجهگیری میدهد.
تفکیک وظایف به عنوان یک موضوع مکرر
بخش بزرگی از یافتههای حسابرسی به تفکیک وظایف (SoD) برمیگردد: همان شخصی که یک تغییر را درخواست میکند آن را تصویب میکند، یا یک توسعهدهنده دسترسی مستقیم پایگاهداده تولید به همراه حقوق استقرار دارد. حسابرسان این همپوشانیها را مدام جستجو میکنند، زیرا خرابیهای SoD این است که تقلب و خرابیهای غیرمقصود بدون دیدهشدن توسط دیدگاه دوم از میان میرود.
هنگام بررسی یک محیط، بپرسید: چه کسی میتواند یک اقدام را شروع کند، چه کسی میتواند آن را تصویب کند و چه کسی میتواند آن را اجرا کند؟ اگر یک شخص دو یا بیشتر از این نقشها را بدون کنترل جبرانکننده (مثل گزارش تفصیلی که توسط شخص دیگری بررسی میشود) داشته باشد، این شکاف است که ارزش یادداشت دارد.
نوشتن بررسیهایی که تصحیح میشوند
یک بررسی از نظر فنی صحیح که کسی بر آن عمل نکند حسابرسی تلف شده است. بررسیهای خوب شرایط (چه مشاهده شد)، معیار (سیاست یا استانداردی که نقض میکند)، علت (چرا اتفاق افتاد) و تأثیر (چه ریسکی این ایجاد میکند) را بیان میکند — ساختار 4C کلاسیکی که بسیاری از مغازههای حسابرسی استفاده میکنند. بررسیهای مبهم مانند "کنترلهای دسترسی باید بهبود یابند" نادیده گرفته میشوند. بررسیهای خاص مانند "14 از 25 کارمند منقضی نمونهگیری شده دسترسی VPN را بیش از 5 روز پس از تاریخ برکناری خود حفظ کردند، که از SLA حذف 24 ساعت در سیاست SEC-014 تخطی میکند" تصحیح میشوند زیرا صاحب دقیقاً میداند که چه چیزی باید برطرف شود.
ساخت عادت
شما این چارچوب را با اجرای آن روی سیستمهای معمولی، نه فقط درگیریهای رسمی توسعه میدهید. یک برنامه را انتخاب کنید که روزانه استفاده میکنید و بپرسید: اگر ناموفق شود ریسک چیست، چه کنترلهایی وجود دارند و چگونه میتوانم ثابت کنم که کار میکنند؟ این را به اندازه کافی انجام دهید و غریزه حسابرس — شکگرایی همراه با تقاضا برای شواهد — خودکار میشود.
اگر این نوع تفکر کنترل و ریسک شما را علاقهمند میکند، برای تحکیم فنی عمیقتر بخشهای Korra Studio درباره مدلهای کنترل دسترسی و چارچوبهای حکمرانی امنیتی را بررسی کنید.
با کمک هوش مصنوعی نوشتهشده، بازبینی و منتشرشده توسط Michal Pilch (CISSP)، Korra Studio.
این یکی از یادداشتهای پایگاه دانش Korra Studio است — پلتفرم هر موضوع را با مربی یکبهیک جفت میکند.
شروع رایگانarrow_forward