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

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

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

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

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

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

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

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

این اعداد میزان فعالیت تیم امنیتی را نشان می‌دهند، اما لزوما میزان ریسک را مشخص نمی‌کنند.

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

هیئت‌مدیره به سه موضوع اصلی نیاز دارد:

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

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

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

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

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

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

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

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

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

هوش مصنوعی سایه نیز به مجموعه دیگری از مسیرهای پنهان دسترسی تبدیل شده است.

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

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

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

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

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

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

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

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

۱. دارایی‌های حیاتی را با همکاری بخش کسب‌وکار مشخص کنید

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

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

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

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

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

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

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

۴. اولویت‌بندی را بر اساس دامنه خسارت انجام دهید

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

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

۵. میزان مواجهه با ریسک را به زبان مالی ترجمه کنید

هر دارایی حیاتی قابل دسترسی را به یک برآورد اثر مالی مرتبط کنید که با همکاری تیم‌های مالی و مدیریت ریسک تهیه شده باشد.

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

۶. روند تغییرات را گزارش کنید

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

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

در جلسه هیئت‌مدیره چه چیزی تغییر می‌کند؟

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

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

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

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

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

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

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

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

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