MedaGRC
سازمانی را تصور کنید که برای مدیریت خدمات فناوری اطلاعات، Endpointها، رخدادهای امنیتی، هویت و دسترسی و پایش زیرساخت از ابزارهای حرفه‌ای استفاده می‌کند. در نگاه اول تقریباً همه چیز مهیاست؛ اما کافی است مدیر امنیت اطلاعات یک سؤال ساده مطرح کند: «مهم‌ترین ریسک فناوری اطلاعات سازمان چیست، مالک آن چه کسی است و برای کاهش آن دقیقاً چه اقدامی در جریان است؟»
اینجاست که تفاوت میان مدیریت فناوری اطلاعات و حاکمیت، ریسک و انطباق روشن می‌شود. اطلاعات ممکن است در چند سامانه مختلف وجود داشته باشد، اما تصمیم مدیریتی درباره ریسک، کنترل، عدم انطباق، اقدام اصلاحی و شواهد ممیزی به یک لایه مرکزی نیاز دارد.
محصولات ManageEngine چه چیزی را خوب پوشش می‌دهند؟
محصولات ManageEngine طیف وسیعی از نیازهای عملیاتی فناوری اطلاعات را پوشش می‌دهند. ServiceDesk Plus برای مدیریت خدمات، Endpoint Central برای مدیریت Endpoint، Log360 برای تحلیل رویدادهای امنیتی، PAM360 برای دسترسی‌های ممتاز و OpManager Plus برای پایش زیرساخت، هرکدام مسئله مشخصی را حل می‌کنند.
این ابزارها داده و کنترل عملیاتی بسیار ارزشمندی تولید می‌کنند، اما GRC سؤال دیگری می‌پرسد: کدام دارایی برای کسب‌وکار حیاتی است؟ چه ریسک‌هایی آن را تهدید می‌کنند؟ چه کنترل‌هایی برای آن تعریف شده‌اند؟ مالک کنترل و ریسک چه کسی است؟ کنترل واقعاً اجرا شده یا فقط در سند نوشته شده؟ و اگر کنترل مؤثر نباشد چه اقدام اصلاحی باید انجام شود؟
مسئله سازمان‌ها کمبود ابزار نیست؛ نبود ارتباط میان ابزارهاست
فرض کنید Endpoint Central نشان می‌دهد تعدادی از سرورهای حیاتی دارای وصله امنیتی بحرانی نصب‌نشده هستند. این یک داده عملیاتی مهم است. اما در نگاه GRC باید مشخص شود این سرورها به کدام دارایی‌ها و سرویس‌های کسب‌وکار مرتبط هستند، ریسک ناشی از ضعف چگونه ارزیابی می‌شود، کنترل مدیریت وصله چه وضعیتی دارد، مسئول کنترل چه کسی است و اگر سطح ریسک از حد قابل قبول بیشتر باشد چه اقدام اصلاحی باید ایجاد شود.
پس از رفع مشکل نیز باید شواهد اجرای کنترل باقی بماند. این همان نقطه‌ای است که MedaGRC وارد می‌شود.
MedaGRC قرار نیست جای ManageEngine را بگیرد
MedaGRC جای ServiceDesk Plus، Endpoint Central، Log360، PAM360 یا OpManager نیست. جایگاه آن یک لایه بالاتر است: ایجاد تصویر واحد از حاکمیت، ریسک و انطباق سازمان.
به زبان ساده، ابزارهای عملیاتی می‌توانند بگویند «چه اتفاقی افتاده است؟» اما GRC باید پاسخ دهد «این اتفاق برای سازمان چه معنایی دارد و چه کاری باید درباره آن انجام شود؟»
یک سناریوی واقعی
فرض کنیم واحد امنیت متوجه می‌شود حساب برخی کارکنانی که از سازمان خارج شده‌اند هنوز در بخشی از سامانه‌ها فعال است. ابزار مدیریت هویت می‌تواند این وضعیت را شناسایی کند و سامانه Audit نیز تغییرات و فعالیت‌های حساب را نشان دهد. اما MedaGRC موضوع را در سطح حاکمیتی دنبال می‌کند: دارایی مرتبط مشخص می‌شود، ریسک دسترسی غیرمجاز ثبت یا به‌روزرسانی می‌شود، کنترل مرتبط به آن متصل می‌شود، مالک کنترل تعیین می‌شود، سطح ریسک ارزیابی می‌شود و برای ضعف مشاهده‌شده اقدام اصلاحی تعریف می‌شود.
پس از رفع مشکل، مدرک اجرای کنترل به همان زنجیره متصل می‌ماند و در ممیزی بعدی قابل ارائه است. این تفاوت میان «داشتن اطلاعات» و «مدیریت ریسک» است.
جایگاه ISMS در این معماری
یکی از اهداف اصلی MedaGRC تبدیل ISMS از مجموعه‌ای از فایل‌ها، فرم‌ها و جلسات دوره‌ای به یک سیستم زنده است. دارایی، ریسک، کنترل، مسئول، Evidence، عدم انطباق و اقدام اصلاحی نباید جزایری جدا از هم باشند.
در بخش چارچوب‌ها و استانداردها می‌توان الزامات را به کنترل‌ها متصل کرد و در بخش ممیزی و انطباق شواهد، یافته‌ها و اقدامات اصلاحی را در ادامه همان زنجیره دنبال کرد.
COBIT هم باید از سند به عملیات برسد
مشکل مشابهی درباره COBIT وجود دارد. در بسیاری از سازمان‌ها COBIT مطالعه می‌شود، جلساتی برگزار می‌شود و مجموعه‌ای از اسناد تولید می‌شود؛ اما ارزش واقعی زمانی ایجاد می‌شود که اهداف حاکمیتی، مسئولیت‌ها، شاخص‌ها، کنترل‌ها، ریسک‌ها و اقدامات اصلاحی در یک محیط عملیاتی مدیریت شوند.
MedaGRC برای کاهش فاصله میان «چارچوب» و «اجرا» طراحی شده است.
استقلال از ManageEngine یک اصل طراحی است
با وجود تجربه مدانت در راهکارهای ManageEngine، MedaGRC به هیچ‌کدام از این محصولات وابسته نیست. سازمانی که هیچ محصول ManageEngine در اختیار ندارد نیز می‌تواند از قابلیت‌های اصلی MedaGRC استفاده کند. در مقابل، اگر سازمان از ManageEngine یا ابزارهای مدیریتی دیگر استفاده کند، امکان همگام‌سازی داده‌ها می‌تواند ورود دستی اطلاعات را کاهش دهد و شواهد واقعی‌تری برای کنترل‌ها ایجاد کند.
تجربه اجرا در سازمان‌های واقعی
نیاز به MedaGRC از یک مسئله واقعی شکل گرفت: سازمان‌ها ابزارهای متعددی در اختیار داشتند، اما برای مشاهده تصویر کامل حاکمیت و ریسک همچنان به فایل‌های پراکنده، گزارش‌های دستی و جلسات متعدد وابسته بودند. تجربه پیاده‌سازی این رویکرد در ۲۰ سازمان نشان داد که یکپارچه‌سازی ریسک، کنترل، شواهد و تصمیم مدیریتی یک نیاز عملیاتی است، نه صرفاً یک پروژه مستندسازی.
MedaGRC؛ نقطه مرکزی GRC سازمان
مدیر سازمان باید بتواند از یک نقطه پاسخ بگیرد: مهم‌ترین ریسک‌های ما کدام‌اند؟ کدام کنترل‌ها ضعیف هستند؟ چه اقداماتی عقب افتاده‌اند؟ کدام عدم انطباق‌ها هنوز باز هستند؟ برای ممیزی چه شواهدی داریم؟ و وضعیت کلی سازمان در چارچوب‌هایی مانند ISO 27001 و COBIT چگونه است؟
این همان جایگاهی است که MedaGRC برای آن طراحی شده است؛ نه جایگزین ابزارهای مدیریت فناوری اطلاعات، بلکه لایه‌ای که داده‌های عملیاتی را به حاکمیت، ریسک و تصمیم مدیریتی متصل می‌کند.
سخن پایانی
اگر سازمان شما ابزارهای عملیاتی قدرتمندی دارد اما هنوز برای پاسخ به پرسش‌های مدیریتی به Excel، فایل‌های پراکنده و جمع‌آوری دستی شواهد وابسته است، مسئله کمبود ابزار نیست؛ مسئله نبود یک لایه GRC یکپارچه است. درخواست دمو MedaGRC می‌تواند نقطه شروع بررسی این معماری در سناریوی واقعی سازمان شما باشد.
