سازمانی را تصور کنید که صدها سرور، لپتاپ، ماشین مجازی، پایگاه داده و سرویس ابری دارد. فهرست دارایی شاید وجود داشته باشد، اما آیا معلوم است کدام دارایی حیاتی است؟ مالک آن چه کسی است؟ آخرین ارزیابی ریسک چه زمانی انجام شده؟ Patchها بهروز هستند؟ کنترلهای امنیتی آن واقعاً اجرا شدهاند؟
ممیزی دارایی در MedaGRC از یک لیست سختافزار فراتر میرود. دارایی به مالک، طبقهبندی، ریسک، کنترل، Evidence، Finding و اقدام اصلاحی متصل میشود. به همین دلیل ممیز میتواند از یک سرور مشخص شروع کند و مسیر کامل ریسک و کنترل آن را ببیند.
سناریو: سرور ERP با Patch عقبافتاده
سرور ERP یکی از داراییهای حیاتی سازمان است. در Inventory ثبت شده، مالک کسبوکاری و مالک فنی دارد و سطح اهمیت آن حیاتی است. در ممیزی دورهای مشخص میشود یک Patch امنیتی مهم بیش از ۴۵ روز عقب افتاده و دلیل مستندی برای استثنا وجود ندارد.
جدول گامهای ممیزی دارایی در MedaGRC
| گام | اقدام | شاهد | خروجی |
|---|---|---|---|
| ۱ | انتخاب دارایی حیاتی | Inventory و طبقهبندی اهمیت | دامنه ممیزی |
| ۲ | بررسی مالک و اطلاعات پایه | مالک کسبوکاری، مالک فنی و سرویس وابسته | اعتبار اطلاعات دارایی |
| ۳ | بررسی ریسکهای مرتبط | Risk Register و سناریوهای تهدید | ریسکهای فعال |
| ۴ | بررسی کنترلها | Patch، EDR/AV، Backup، Access Control و Logging | Control Coverage |
| ۵ | جمعآوری Evidence فنی | خروجی Endpoint Central، AssetExplorer یا ابزار مشابه | شاهد اجرای کنترل |
| ۶ | ثبت Finding | Patch بیش از ۴۵ روز عقبافتاده | عدمانطباق |
| ۷ | ارزیابی اثر بر ریسک | افزایش احتمال سوءاستفاده از آسیبپذیری | بازبینی Risk |
| ۸ | اقدام اصلاحی | Patch، Change کنترلشده یا Exception مصوب | Remediation |
| ۹ | تأیید شاهد جدید | نسخه جدید، گزارش اسکن و تأیید ممیز | Closure |
چرا دارایی نقطه شروع خوبی برای ممیزی است؟
دارایی نقطه اتصال دنیای فنی و مدیریتی است. وقتی یک دارایی حیاتی باشد، ریسکهای آن اهمیت بیشتری پیدا میکنند و کنترلهایش باید متناسب با همان اهمیت ارزیابی شوند. یک لپتاپ آزمایشگاهی و یک سرور ERP نباید صرفاً با یک چکلیست یکسان ممیزی شوند.
ممیز چه سؤالهایی میپرسد؟
- آیا این دارایی در Inventory ثبت شده و اطلاعاتش بهروز است؟
- مالک پاسخگو و مالک فنی مشخصاند؟
- طبقهبندی اطلاعات و اهمیت سرویس تعیین شده است؟
- ریسکهای مرتبط ارزیابی و بازبینی شدهاند؟
- کنترلهای Patch، Backup، دسترسی، ضدبدافزار و Logging اجرا میشوند؟
- استثناها تاریخ انقضا و تأیید رسمی دارند؟
- در صورت نقص، اقدام اصلاحی و مسئول آن مشخص است؟
اگر ابزار مدیریت دارایی داریم، باز هم GRC لازم است؟
ابزار ITAM یا Endpoint Management معمولاً پاسخ میدهد چه تجهیزی داریم و وضعیت فنی آن چیست. MedaGRC به سؤال دیگری پاسخ میدهد: این وضعیت برای ریسک و انطباق سازمان چه معنایی دارد؟ مثلاً عقبافتادن Patch فقط یک رخداد عملیاتی نیست؛ میتواند کنترل امنیتی را نامؤثر و سطح ریسک را تغییر دهد.
به همین دلیل خروجی ابزارهایی مانند AssetExplorer یا Endpoint Central میتواند بهعنوان Evidence وارد چرخه GRC شود، بدون اینکه MedaGRC بخواهد جای آن ابزارها را بگیرد.
دو خروجی مهم این ممیزی
خروجی اول: وضعیت انطباق دارایی. ممیز میبیند کدام کنترلها کامل، ناقص یا نامنطبق هستند. خروجی دوم: تأثیر بر ریسک. اگر کنترل ضعیف باشد، باید بررسی شود آیا Residual Risk هنوز قابل پذیرش است یا نیاز به Treatment جدید دارد.
برای تکمیل این موضوع، مقاله مدیریت داراییهای اطلاعاتی و Asset Inventory و صفحه نرمافزار مدیریت داراییهای اطلاعاتی را ببینید.
جمعبندی
در MedaGRC ممیزی دارایی یعنی حرکت از یک رکورد Inventory به یک تصمیم مدیریتی. ممیز از دارایی شروع میکند، ریسک و کنترل را بررسی میکند، Evidence فنی را میسنجد و اگر نقصی وجود داشته باشد، آن را تا اقدام اصلاحی و تأیید نهایی دنبال میکند. این همان تفاوت داشتن فهرست دارایی با حاکمیت واقعی بر دارایی است.
برای مشاهده نحوه اتصال ابزارهای عملیاتی به GRC، صفحه مرکز یکپارچهسازی MedaGRC را ببینید.

MedaGRC