چرا CIOها نمی توانند به سه سوال سخت هیئت مدیره پاسخ دهند و چگونه می توان این گزارش ها را اصلاح کرد؟

گزارش‌های امنیتی سنتی، فعالیت بیشتری را نسبت به سطح واقعی ریسک برای سازمان نشان می‌دهند.

جلسه فصلی هیات مدیره دو هفته دیگر برگزار می شود. تیم امنیتی اطلاعات را از خدمات مدیریت هویت، ابزارهای امنیتی ابری، اسکنرهای آسیب‌پذیری، SIEM و EDRها استخراج می‌کند. یک نفر در حال ایجاد فایلی برای مطابقت با این اطلاعات است و شخص دیگری همان داده ها را به اسلایدهای ارائه تبدیل می کند.

سپس یکی از اعضای هیئت مدیره سه سوال مهم می پرسد:

• امنیت کلی سازمان چیست؟
• میزان واقعی قرار گرفتن در معرض ریسک مالی چقدر است؟
• آیا وضعیت امنیتی نسبت به سه ماهه گذشته بهبود یافته است؟

بسیاری از CIOها نمی توانند با اطمینان به هیچ یک از این سوالات پاسخ دهند. مشکل این نیست که داده ها وجود ندارند، بلکه این اطلاعات در ابزارهای مختلفی قرار دارند که ارتباط و زمینه مشترکی بین آنها وجود ندارد.

یک راهنمای جدید برای گزارش‌دهی مطمئن به هیئت‌ها تلاش می‌کند دقیقاً به این مشکل رسیدگی کند. این رویکرد توضیح می دهد که چرا گزارش های امنیتی سنتی موثر نیستند و چگونه می توان مدل بهتری برای ارائه وضعیت امنیتی سازمان ایجاد کرد.

هیئت مدیره دیگر به معیارهای عملکرد اعتماد ندارد

برای سال ها، گزارش های امنیتی بر اساس اعداد و ارقام بوده است. تعداد آسیب‌پذیری‌های شناسایی‌شده، وصله‌های نصب‌شده، هشدارهای بسته و آزمایش‌های موفق فیشینگ.

این اعداد نشان دهنده سطح فعالیت تیم امنیتی است، اما لزوماً نشان دهنده سطح ریسک نیست.

وقتی یکی از اعضای هیئت مدیره می شنود که تیم امنیتی هزاران مشکل امنیتی را در سه ماه گذشته برطرف کرده است، هیچ راهی برای اطلاع از اینکه سازمان واقعاً چقدر امن تر است، ندارد. سوال مهم بعدی این است که چه چیزی و تا چه حد سازمان از امنیت بیشتری برخوردار شده است. سوالی که معمولا پاسخ روشنی ندارد.

هیئت مدیره به سه چیز اصلی نیاز دارد:

• قرار گرفتن در معرض خطر، نه فعالیت: کدام دارایی های سازمانی حیاتی در واقع امروز در دسترس مهاجمان است؟
• فرآیند تغییر، نه یک عکس فوری: آیا قرار گرفتن در معرض خطر نسبت به فصل گذشته کاهش یافته است؟
• پول، نه CVE: اگر از این مسیرهای حمله استفاده شود، چه پیامدهای مالی برای سازمان خواهد داشت؟

مشکل اصلی در فاصله بین ابزارهای امنیتی نهفته است

یک شرکت متوسط ​​یا در حال رشد معمولاً از یک سرویس مدیریت هویت، CSPM یا CNAPP، یک سیستم تشخیص تهدید نقطه پایانی، یک SIEM، یک اسکنر آسیب پذیری و میزبانی از نرم افزار SaaS استفاده می کند.

هر ابزاری اطلاعات مربوط به بخش خود را به درستی ارائه می دهد، اما هیچ کدام به تنهایی نمی توانند رابطه بین این بخش ها را ببینند. مهاجمان هم به این مرزها اهمیت نمی دهند.

برای مثال، یک مسیر حمله واقعی ممکن است به این صورت باشد:

• حساب کاربری یک پیمانکار پس از پایان پروژه همچنان عضو یک گروه است. ابزار مدیریت هویت این را به عنوان کم خطر ارزیابی می کند.
• آن گروه به یک برنامه SaaS دسترسی دارد که از طریق OAuth به ابر متصل است. ابزار امنیتی SaaS این اتصال را بدون درز و عادی تشخیص می دهد.
• این اتصال با یک حساب سرویس با دسترسی ذخیره سازی گسترده اجرا می شود. ابزار امنیت ابری این را به عنوان ریسک متوسط ​​در نظر می گیرد.
• جایی است که اطلاعات مشتری ذخیره می شود. یک ابزار طبقه بندی داده ها می داند که اطلاعات حساس هستند، اما نمی داند چه کسی می تواند به آن دسترسی داشته باشد.

چهار یافته، چهار ابزار و چهار نمره میانگین وجود دارد. اما با هم، اینها می توانند یک مسیر حیاتی از یک حساب فیش پذیر تا حساس ترین داده های یک شرکت ایجاد کنند.

هیچ داشبوردی به تنهایی این مسیر را نشان نمی دهد و در نتیجه ممکن است چنین خطری وارد گزارش داشبورد نشود و تنها پس از وقوع یک حادثه امنیتی کشف شود.

گسترش استفاده از هوش مصنوعی این شکاف را بیشتر کرده است. عوامل هوش مصنوعی، هویت‌های غیر انسانی، حساب‌های خدمات و ابزارهای متصل به MCP به طور فزاینده‌ای به سازمان‌ها اضافه می‌شوند، در حالی که بسیاری از زیرساخت‌های امنیتی برای تعیین مسیر دسترسی آنها طراحی نشده‌اند.

Shadow AI نیز به مجموعه دیگری از مسیرهای دسترسی مخفی تبدیل شده است.

اضافه کردن ابزار دیگری مشکل را حل نمی کند

واکنش معمول سازمان ها خرید ابزاری جدید برای پوشش این شکاف است. اما نتیجه اغلب یک کنسول دیگر، یک خروجی دیگر و یک ستون دیگر در فایل آشتی است.

این اعتراض که «ما قبلاً CSPM داریم» یا «معماری اعتماد صفر داریم» کاملاً منطقی است. این سرمایه گذاری ها مهم هستند، اما هر کدام حوزه خاصی را پوشش می دهند.

سوال مطرح شده توسط هیئت مدیره چندین حوزه را به هم مرتبط می کند. آنچه گم شده لزوماً یک کنترل امنیتی دیگر نیست، بلکه یک زمینه مشترک است که می تواند اطلاعات کنترل های موجود را با هم جمع کند.

این همان ایده ای است که در معماری Cybersecurity Mesh یا CSMA ارائه شده است. مدلی طراحی شده برای اتصال ابزارهای امنیتی توزیع شده از طریق یک لایه اطلاعاتی مشترک.

CSMA به جای جایگزینی ابزارهای موجود، داده‌های آن‌ها را به یکدیگر پیوند می‌دهد تا دیدی یکپارچه از هویت‌ها، دسترسی‌ها، دارایی‌ها و موارد امنیتی ارائه دهد.

چارچوب عملی برای تهیه گزارش های آماده برای ارائه به هیئت مدیره

مدیران امنیتی که می خواهند گزارش های خود را بر اساس مواجهه با ریسک دوباره طراحی کنند، می توانند از این فرآیند استفاده کنند:

1. شناسایی دارایی های حیاتی با همکاری بخش تجاری

ابتدا، دارایی هایی را که نفوذ یا آسیب آنها بیشترین آسیب را به کسب و کار وارد می کند، شناسایی کنید. از جمله مخازن اطلاعات مشتری، سیستم های پرداخت، اطلاعات سلامت، کد منبع و زیرساخت تولید.

این فهرست باید با همکاری صاحبان مشاغل و نه فقط تیم امنیتی تهیه شود. این دارایی ها اساس تمام مراحل بعدی خواهند بود.

2. ابزارهای موجود را به هم متصل کنید

اطلاعات هویت، ابر، نقطه پایانی، SaaS و آسیب‌پذیری را در یک نمای یکپارچه و مرتبط جمع کنید.

هدف حذف داده های اضافی و غنی سازی اطلاعات است نه افزودن حسگرهای جدید. اتصالات مبتنی بر API بدون نیاز به نصب عامل می تواند روند پیاده سازی را تسریع کند و محیط تولید را مختل نکند.

3. مسیرهای حمله واقعی به دارایی های حیاتی را شناسایی کنید

به جای فهرست کردن یافته ها، مسیرها را نمایش دهید. برای هر دارایی حیاتی، مشخص کنید که کدام هویت انسانی و غیر انسانی می‌تواند به آن دسترسی داشته باشد و این دسترسی از چه زنجیره‌ای از مجوزها و پیکربندی‌های نادرست ایجاد شده است.

4. اولویت بندی بر اساس دامنه آسیب

یک پیکربندی نادرست با شدت متوسط ​​که در مسیر داده‌های مشتری قرار می‌گیرد، ممکن است مهم‌تر از یک آسیب‌پذیری حیاتی در یک سرور آزمایشی ایزوله باشد.

اولویت اصلاح باید بر اساس مسیری باشد که می شکند، نه فقط امتیاز مستقل یک آسیب پذیری.

5. قرار گرفتن در معرض ریسک را به زبان مالی ترجمه کنید

هر دارایی حیاتی قابل دسترسی را به یک برآورد تأثیر مالی که با همکاری تیم های مالی و مدیریت ریسک تهیه شده است، پیوند دهید.

در این مورد، گزارش از «تعداد آسیب‌پذیری‌ها» به «میزان سرمایه در معرض خطر» تغییر می‌کند. زبانی که هیئت مدیره قبلاً با آن برای سایر حوزه های ریسک شرکت آشنا است.

6. گزارش تغییرات

نشان دهید که در سه ماهه گذشته چند مسیر حمله دارایی حیاتی وجود داشته است، اکنون چند مسیر باقی مانده است و چه اقدامات اصلاحی آنها را بسته است.

این روش همچنین به سوال بازگشت سرمایه پاسخ می دهد، زیرا تعیین می کند که زیرساخت امنیتی موجود در واقع چقدر ریسک سازمان را کاهش داده است.

در جلسه هیئت مدیره چه تغییری صورت خواهد گرفت؟

وقتی گزارش امنیتی بر اساس مسیرهای حمله است تا تعداد فعالیت ها، سه سؤال اصلی هیئت مدیره پاسخ های دقیق تری دریافت می کنند:

• امنیت سازمان چقدر است؟ اینها مسیرهای باقی مانده به مهم ترین دارایی های سازمان هستند.
• میزان ریسک مالی چقدر است؟ این برآورد خسارتی است که در صورت استفاده از این مسیرها ممکن است ایجاد شود.
• آیا وضعیت امنیتی بهبود یافته است؟ در اینجا تعداد مسیرهایی که از فصل گذشته حذف شده اند و اقداماتی که باعث بسته شدن آنها شده است آورده شده است.

این رویکرد نقش CIO را در جلسه هیئت مدیره از دفاع از مخارج امنیتی به ارائه گزارش قابل اندازه گیری در مورد کاهش ریسک تغییر می دهد.

همچنین به تیم امنیتی لیستی اولویت بندی شده از اقداماتی که با اولویت های مدیران سازمان همخوانی دارد، می دهد.

از کجا شروع کنیم؟

Mesh یک لایه اطلاعاتی یکپارچه برای تیم های امنیتی سازمانی است که در محیط هایی با ابزارهای امنیتی متعدد و بدون زمینه مشترک فعالیت می کنند.

با اتصال به ابزارهای موجود بدون نیاز به نصب یک عامل، این پلتفرم سیگنال‌هایی را از هویت، ابر، SaaS، نقاط پایانی و محیط‌های هوش مصنوعی به یکدیگر متصل می‌کند تا مسیرهای حمله عملی علیه حیاتی‌ترین دارایی‌های سازمان را شناسایی کند.

Mesh با ارائه دیدگاهی یکپارچه از کل سازمان که هیچ ابزار مستقلی نمی تواند به تنهایی ارائه دهد، به تیم های امنیتی کمک می کند تا بحرانی ترین خطرات را اولویت بندی کرده و آنها را سریعتر از طریق فرآیندهای هدایت شده کاهش دهند.

مدیران امنیتی که برای جلسه بعدی هیئت مدیره آماده می شوند، می توانند راهنمای CIO را برای گزارش مطمئن به هیئت مدیره دریافت کنند.