۱ مقدمه
بانکها مرکز حملات سایبری گستردهای هستند. این حملات منجر به خسارتهای مالی زیادی به بانکها و مشتریان آنها میشود. یکی از اصلیترین استراتژیهای مورداستفاده در مقابل حملات سایبری استراتژی دفاع در عمق است. این استراتژی از یک روش دفاعی قدیمی که به روش قلعه نیز معروف است ایده گرفتهشده است. درگذشته با ایجاد لایههای دفاعی مستقل و پشت سرهم در اطراف قلعه، از داراییهای درون قلعه حفاظت میکردند. دفاع در عمق کمک میکند که حمله را تشخیص و پیشروی آن را به تعویق انداخت و یا مانع پیشروی آن شد. استفاده از این روش در حملات سایبری زمان بیشتری برای مقابله با حمله برای گروه فناوری اطلاعات سازمان فراهم میکند.
در بانکها نیز از استراتژی دفاع در عمق برای حفاظت از شبکه داخلی بانک و هر چه که در پشت فایروال وجود دارد استفاده میشود. این استراتژی در صورت برقراری سه شرط زیر میتواند در مقابله با حملات موفق باشد:
- سرمایههایی که میخواهیم از آنها محافظت کنیم درون سازمان باشد.
- مهاجم خارج از سازمان باشد.
- روشهای دفاعی سازمان برای توقف و مقابله با حملات کافی باشد.
در ساختار بانکهای فعلی دو شرط اول برقرار نیست و به همین دلیل شرط سوم نیز نمیتواند برقرار باشد. دلیل اصلی ناکارآمدی استراتژی دفاع در عمق در بانکها این است که اغلب مرز سازمان را به آنچه در شبکه داخلی و پشت فایروال قرار دارد محدود میکند. درحالیکه سطحی از سازمان که امکان حمله به آن وجود دارد(۱) در بانکها بسیار گستردهتر است. با توجه به اینکه امروزه امکان انجام تراکنشهای مالی در سایتها و برنامههای موبایل در کل دنیا وجود دارد، آنچه در بانکها باید تحت حفاظت باشد تنها شبکه داخلی بانک نیست بلکه کل اینترنت است! بهبیاندیگر برای مقابله با حملات سایبری بانکی باید از تمام مشتریان، وبسایتها و برنامههای کاربردی استفادهکننده از خدمات بانکی، شبکه داخلی، کارمندان و … حفاظت کرد.
در آوریل ۲۰۱۵ شرکت RiskIQ تحقیقات وسیعی روی وبسایتها، منابع وبی(۲) و برنامههای موبایل مربوط به ۳۵ بانک برتر آمریکای شمالی انجام داده است و مسائل و نقاط ضعف امنیتی آنها را بررسی کرده است. حاصل این تحقیقات نشان داده است که حتی قویترین روشهای حفاظتی که در شبکههای داخلی بانک بهکاربرده شده است تنها از بخش کوچکی از حملاتی که علیه برند و مشتریان انجامشده حفاظت میکند.
حملات امنیتی چه باعث خسارت مستقیم مالی شوند و چه باعث تخریب برند بانک شوند تأثیر بسیاری بر منابع و سودآوری بانک خواهند گذاشت. خسارتهای بالقوه در حملات سایبری به صنعتی نظیر بانک، که اعتماد مشتریان و برند سازمان فاکتورهای کلیدی در رشد و بقای سازمان هستند، بسیار زیاد است.
۲ چه چیزی در مخاطره قرار دارد؟
انگیزه قدیمی حمله به سیستمهای بانکی برداشتن سرمایه بانک، خالی کردن حساب کاربران و منحرف کردن تراکنشهای مالی است. امروزه این انگیزهها تنها دلیل حمله سایبری به بانکها نیست. بانکداری آنلاین منابع غیرمالی در اختیار قرار میدهد که ممکن است توسط مهاجمانی که تعدادشان در حال افزایش است به سرقت رود و یا مورد سوءاستفاده قرار بگیرد. این منابع را میتوان به دودسته تقسیم کرد:
- Tangible، اطلاعات شناسایی مشتریان بانک که برای عملیات و گزارشگیریها مورداستفاده قرار میگیرد.
- Intangible، میزان اعتماد مشتریان به بانک.
در زیر نمونههایی از تهدیدات امنیتی که در مطالعات RiskIQ تعیینشده است ذکر میشود:
- خسارت مالی مستقیم ناشی از دزدی.
- ممانعت از سرویس که در آنهمه یا بخشی از سرویس وب یا موبایل بانک از دسترس خارج میشود.
- خسارت به برند و اعتبار بانک.
- هزینههای ناشی از آگاهیرسانی و کمک به مشتریان، مانند گزارش اعتبار و بازیابی شناسه.
- نقض قوانین حریم خصوصی دادهها.
- فرصتهای ازدسترفته تجاری در زمانی که برای پاسخگویی به و مقابله با حملات امنیتی صرف می شود.
در تحقیقات انجام شده توسط RiskIQ تهدیداتی که متوجه سیستم های بانکی است به دو دسته کلی تقسیم شده است:
- سیستم تحویل(۳) خدمات، که برای دستیابی به مشتریان استفاده می شود. برای مثال redirect یا pharming وب سایت ها یا جعل برند از طریق برنامه های غیرمجاز یا ایمیل های جعلی.
منابع آسیب پذیری، مانند آسیب پذیری در نرم افزارها و سیستم های ارتباطی، زبان های اسکریپتی، کتابخانه ها و third party component، خطاهای نرم افزاری و غیره.
۳ تهدیداتی که به منابع وب بانک می شود
تهدیداتی که به وب بانک ها می شود از بردارهای حمله(۴) متفاوتی نشات می گیرد که همه می تواند از خارج فایروال بانک انجام شود. این بردارها شامل موارد زیر هستند:
- استفاده از حفره امنیتی در مولفه های third-party سمت کاربر مانند کتابخانه های جاوا اسکریپت برای انتقال دژافزارها(۵).
- اکسپلویت آسیب پذیری های موجود در سرویس دهندگان میزبان وب سایت بانک به صورت مستقیم و یا از طریق مولفه های آسیب پذیر مانند زبان های اسکریپتی سمت سرویس دهنده، کتابخانه ها، سرویس ها و ابزارهای خارجی مورد استفاده در معماری سایت. زبان های سمت سرویس دهنده مورد استفاده شده در بانک های بررسی شده ۴۹% جاوا، ۴۲% .NET،۱۸% ASP ،۱۳% Coldfusion و کمتر از ۱۰% perl و php بوده است.
- حمله به و یا انحراف ترافیک منتقل شده بین بانک و کاربران، مانند man-in-the-middle یا حمله web pharming از طریق گواهی های SSL افشاشده(۶)، آسیب پذیری در لایه انتقال مانند آسیب پذیری heartbleed در openSSL، تخریب DNS برای انحراف ترافیک یا جعل ایمیل برای فریب کاربران.
- سواستفاده از منابع خارجی وب سایت مانند فایل های pdf، تصاویر یا هر محتوای دیگر. این منابع که در محدوده وسیعی گسترده شده اند نسبت به منابع درون سازمان به سختی قابل ردیابی و حفاظت هستند. در خارج از سازمان منابع معمولا توسط فردثالث در سرویس دهندگانی نگهداری می شوند که امنیت چندانی ندارند.
در تحقیقات انجام شده ۲۶۰۰۰۰منبع وب مورد تحقیق قرار گرفت. از این میان،
- ۶۱% وب سایت ها روی سرویس دهنده های خارج از کنترل گروه IT سازمان قرار داشت. تنها ۳۹% وب سایت ها در سرویس دهندگان درون سازمان قرار داشتند و طبیعتا آسان تر امن شده و گزارشگیری از آن ها انجام می گرفت.
- ۹۴% وب سایت ها از ابزارهای آمارگیری و ردیابی استفاده می کردند که در سایت embed شده و ممکن است دارای ریسک های امنیتی باشد. برای مثال Gigya توسط ارتش الکترونیک سوریه در سال ۲۰۱۴ مورد حمله قرار گرفت. در این حمله از تکنیک انحراف DNS استفاده شد و تعدادی از سایتهای تجاری معروف در این حمله مورد جعل قرار گرفت.
- ۹۴% وب سایت ها یک یا دو کتابخانه جاوااسکریپت داشتند. به طور میانگین برای هر بانک هفت کتابخانه جاوااسکریپت استفاده می شد. استفاده از اینگونه زبان های اسکریپتی سمت کاربر در حملات رایج است. برای مثال jQuery به عنوان رایج ترین کتابخانه جاوااسکریپت بارها مورد حمله قرار گرفته است.
- ۹۷% وب سایت بانک ها حداقل ۱۳ گواهی SSL افشاشده و ۵۷% آن ها بیشتر از ۱۰۰ گواهی افشاشده داشتند. گواهی های SSL افشاشده به مهاجمان امکان حمله های man-in-the-middle و web pharming می دهد.
- ۹۳% آن ها منابعی داشتند که در میزبان های مبتنی بر ابر از نوع (۷)IaaS قرار داشتند، مانند وب سرویس آمازون یا Rackspace. این منابع ممکن است تحت کنترل مستقیم بخش IT بانک قرار نداشته باشد و گاهی ممکن است setup شده و به فراموشی سپرده شوند. حدود ۴۰% این منابع مدیریت نشده رها شده اند.
۴ تهدیداتی که علیه برنامه های موبایل بانک می شود
تحقیقات RiskIQ نشان داده است که بانک ها بسیار بیشتر از حد انتظار با حملات از طریق برنامه های موبایل مواجه می شوند. تهدیدات و آسیب پذیری های برنامه های موبایل شامل موارد زیر است:
- حفره های امنیتی در مولفه ها، کتابخانه ها یا سرویس های موجود در برنامه های موبایل.
- جعل برند بانک در برنامه های موبایل غیرمجاز.
- برنامه های ناامن، وصله نشده و به روزرسانی نشده ای که توسط مراجعی غیر از مراجع معتبر ارائه دهنده برنامه های موبایل ارائه شده اند.
- مجوزهای بیش از اندازه ای که در نصب برنامه های مجاز و third-party مورد نیاز است.
در این تحقیقات لیستی از ۱۷۷۷ برنامه موبایل تهیه شده است که توسط و یا برای ۳۵ بانک مورد مطالعه تولید شده است. از این میان،
- تنها ۶% در مراکز فروش برنامه های موبایل نظیر Google play، Apple App store و یا Amazon App store ارائه می شود. ۹۴% دیگر از طریق سایت های توزیع برنامه ای ارائه می شد که به سختی می توان گفت نسخه به روز و امنی از برنامه را به مشتریان ارائه می دهند.
- ۸۰% برنامه های بررسی شده به تعداد ۱۰ یا بیشتر مجوز مختلف در موقع نصب از کاربر دریافت می کردند. در حالیکه اغلب مجوزها بیشتر از چیزی بود که برنامه برای عملکردش به آن نیاز دارد. این مجوزها اغلب دسترسی های غیرضروری برای برنامه فراهم می کند، مثلا دسترسی به دفترتلفن کاربر یا ابزار ضبط صدا. اگرچه ابزارها لیست مجوزهای مورد نیاز را پیش از نصب ذکر می کنند و باید کاربر به صراحت این مجوزها را به برنامه بدهد، اغلب کاربران به سرعت و بدون بررسی این مجوزها را تایید کرده و برنامه را در موبایل خود نصب می کنند.
۵ در مقابله با تهدیدات جدید چه باید کرد؟
مانند هر سازمانی که مبتنی بر اطلاعات است بانک ها نیز با حملات گسترده ای روبه رو هستند که هرگز نمیتوان در عرض یک شب با آن ها مقابله کرد. جرم های سایبری در اینترنت هر روزه وسعت بیشتری پیدا میکند. آسیب پذیری هایی که در خارج از فایروال بانک قرار دارد فضای زیادی برای حمله مهاجمان به بانک فراهم می کند. در صورتیکه سیستم های امنیتی شبکه داخلی نیز ضعیف باشد شرایط وخیم تر می شود. نظارت دقیق بر شبکه داخلی و به کاربردن تمهیدات امنیتی در وب سایت و برنامه های موبایل بانک درکاهش این مخاطرات کمک کننده است. اولین گام این است که مرزهای سازمان و به بیانی سطح تماس با مهاجمان(۸) را در بانک خود تخمین بزنید. برای این کار باید آسیب پذیری هایی که در پشت فایروال قرار دارد تخمین زده شود.
منبع
(۱) Attack Surface
(۲) Web Assets
(۳) Delivery System
(۴) Attack Vector
(۵) Malware
(۶) Broken
(۷) Information as a service
(۸) Exposure
ثبت ديدگاه