طوفان ذهنی در خصوص اختلال بانکها
**تمام این بحث برپایه فرضیات، تجربه و مفاهیم ISSAP است چون در پروژه ای که خودم درگیر باشم موضوعات رو نمیتونم شفاف و به روز عیان کنم .
از منظر یک متخصص معمار ارشد امنیت سایبری (ISSAP) ، رخداد نفوذ به یک شرکت ارائه‌دهنده خدمات و تأثیر همزمان آن بر چهار بانک، بیش از آنکه یک ضعف فنی باشد ، میتواند نشانه یک نقص در معماری امنیتی باشد. در معماری‌های امن، اصل بر این است که رخنه در یک بخش نباید بتواند کل اکوسیستم را تحت تأثیر قرار دهد. اگر نفوذ به یک تأمین‌کننده باعث اختلال در چند بانک شده باشد، احتمالاً مرزهای اعتماد (Trust Boundaries) به‌درستی تعریف نشده‌اند و سطح جداسازی منطقی میان مشتریان کافی نبوده است.
یکی از دلایل رایج چنین رخدادهایی، استفاده از زیرساخت مدیریتی مشترک، حساب‌های مدیریتی مشترک یا سرویس‌های متمرکز برای چند مشتری است. در این شرایط، مهاجم پس از نفوذ به محیط ارائه‌دهنده خدمات میتواند به سایر سامانه‌ها نیز دسترسی پیدا کند یا باعث اختلال زنجیره‌ای شود. همچنین نبود Network Segmentation، Micro-Segmentation و کنترل‌های Zero Trust میتواند امکان حرکت جانبی (Lateral Movement) را برای مهاجم فراهم کند.
در یک طراحی امنیتی صحیح، هر بانک باید به‌عنوان یک دامنه امنیتی مستقل در نظر گرفته شود؛ به‌گونه‌ای که حتی در صورت رخنه کامل به شرکت ارائه‌دهنده خدمات، دامنه اثر حادثه محدود باقی بماند. بنابراین مهم‌ترین یافته معماری در چنین رخدادی، عدم کنترل Blast Radius و نبود مکانیزم‌های مؤثر برای ایزوله‌سازی مشتریان و سرویس‌های حیاتی است؛ موضوعی که مستقیماً با اصول تاب‌آوری سایبری و معماری امن در ISSAP در ارتباط است.
**تمام این بحث برپایه فرضیات، تجربه و مفاهیم ISSAP است چون در پروژه ای که خودم درگیر باشم موضوعات رو نمیتونم شفاف و به روز عیان کنم .
از منظر یک متخصص معمار ارشد امنیت سایبری (ISSAP) ، رخداد نفوذ به یک شرکت ارائه‌دهنده خدمات و تأثیر همزمان آن بر چهار بانک، بیش از آنکه یک ضعف فنی باشد ، میتواند نشانه یک نقص در معماری امنیتی باشد. در معماری‌های امن، اصل بر این است که رخنه در یک بخش نباید بتواند کل اکوسیستم را تحت تأثیر قرار دهد. اگر نفوذ به یک تأمین‌کننده باعث اختلال در چند بانک شده باشد، احتمالاً مرزهای اعتماد (Trust Boundaries) به‌درستی تعریف نشده‌اند و سطح جداسازی منطقی میان مشتریان کافی نبوده است.
یکی از دلایل رایج چنین رخدادهایی، استفاده از زیرساخت مدیریتی مشترک، حساب‌های مدیریتی مشترک یا سرویس‌های متمرکز برای چند مشتری است. در این شرایط، مهاجم پس از نفوذ به محیط ارائه‌دهنده خدمات میتواند به سایر سامانه‌ها نیز دسترسی پیدا کند یا باعث اختلال زنجیره‌ای شود. همچنین نبود Network Segmentation، Micro-Segmentation و کنترل‌های Zero Trust میتواند امکان حرکت جانبی (Lateral Movement) را برای مهاجم فراهم کند.
در یک طراحی امنیتی صحیح، هر بانک باید به‌عنوان یک دامنه امنیتی مستقل در نظر گرفته شود؛ به‌گونه‌ای که حتی در صورت رخنه کامل به شرکت ارائه‌دهنده خدمات، دامنه اثر حادثه محدود باقی بماند. بنابراین مهم‌ترین یافته معماری در چنین رخدادی، عدم کنترل Blast Radius و نبود مکانیزم‌های مؤثر برای ایزوله‌سازی مشتریان و سرویس‌های حیاتی است؛ موضوعی که مستقیماً با اصول تاب‌آوری سایبری و معماری امن در ISSAP در ارتباط است.
Comments
Be the first to add a comment
Log in to comment