آزمایشگاههای F5 و متخصصین در سرتاسر F5 تجربههای دوازده ماههشان را ارائه کرده و بزرگترین دغدغهها در سال 2023 را پیشبینی کردهاند.
مطابق با رسمی هر ساله، جامعه امنیت سایبری همزمان با پایان سال میلادی در تکاپوی پیش بینی مهمترین رویدادهای سال آینده به سر میبرد، رویدادی که به سرتیتر خبرهای سال جدید تبدیل خواهد شد. هر چند به نظر تلخ است، اما تهیه استراتژی برای مقابله با تهدیدات امنیت سایبری به نوعی راهکاری برای حل و فصل مشکلات سال جدید است... اگر هنوز به سمت عادتهای سالم جدید نرفتهاید، بعید است بتوانید صبر کنید تا ساعت به نیمهشب روز 31ام ماه دسامبر برسد و فکر کنید که در آن زمان، آسانتر میتوانید شروع کنید. خیلی بعید است که تهدیدگران تا سال جدید صبر کنند و آن موقع ناگهان تهدیدات جدیدشان را رو کنند، تاکتیکهایشان را به شدت عوض کنند یا هدفهایشان را تغییر دهند. تهدیدها به آرامی پدید میآیند و با کنترلهای امنیتی که همواره بهتر و بهتر میشوند، خودشان را وفق میدهند. با همه این تفاسیر، آزمایشگاههای F5 پیشبینیهای خود را برای سال جدید ارائه کرده تا آنهایی که هشدارها را جدی نگرفتهاند و از ابتدا شروع نکردهاند، بتوانند از این راهکارها استفاده کنند. همچنین، تحلیلهایی نیز از سوی تحلیلگران بدافزار، متخصصین هوش تهدید سایبری (cyber threat) و مهندسین مرکز عملیات امنیت (security operations center) (SOC) در F5 نیز تهیه و ارائه شده است.
محبوبیت واسطهای برنامهنویسی اپلیکیشن (Application programming interfaces) (API) به شدت زیاد شده است. یکپارچهشدن برنامههای موبایلی، استفاده از دادههای مشترک در سازمانهای مختلف و خودکارسازی اپلیکیشنها که همواره بیشتر و بیشتر میشود، باعث شده تا در سال 2021 تعداد 3/1 میلیارد درخواست از طریق ابزار توسعه پستمن (Postman) که با API کار میکند، ارائه شود. اما 48 درصد از مخاطبین در گزارش وضعیت پستمن در خصوص APIها اعتراف کردهاند که دستکم یک بار در ماه با یک رویداد امنیتی در APIها روبرو میشوند.1
درست مثل همه جنبههای دیگر امنیت سایبری، وقتی چیزی را ندانید، نمیتوانید آن را امن کنید. شان باکر (Shahn Baker)، معمار ارشد راهکارها و مشاور ابر و API در F5 میگوید که APIهای سایه همواره با ریسکهای فزایندهای روبرو هستند که احتمالاً منجر به لورفتن دادهها در مقیاس بزرگ میشوند و این، همان چیزی است که سازمانِ قربانی اصلاً خبر هم ندارد که ممکن است این اتفاق برای او رخ دهد.
«بسیاری از سازمانها اساساً موجودی یا انبار درستی از APIهای خود ندارند. این مسأله منجر به یک بردار تهدید جدید میشود که به آن، «API سایه» میگویند. سازمانهایی که یک فرآیند بالغ برای توسعه API دارند، معمولاً یک موجودی دارایی به نام موجودی یا انبار API (API inventory) برای خود نگهداری میکنند. ایدآل آن است که این انبار حاوی اطلاعاتی در خصوص تمام نقاط انتهایی (endpoints) API، جزئیات مرتبط با پارامترهای قابل قبول، اطلاعات مربوط به احراز هویت (authentication) و مجوزها (authorization) و سایر موارد اینچنینی باشد. اما بسیاری از سازمانها چنین موجودی APIای ندارند. سازمانهای دیگر هم APIهایی دارند که در تولید از آنها استفاده میکنند و بهرهبرداری از توسعه مستمر با تعاریف اصلی که در موجودی آمده، بسیار متفاوت است. در نتیجه، در هر دو حالت سازمانها APIهای در معرض خطری دارند که هیچ دیدی بر روی آنها وجود ندارد. این APIها همان APIهای سایه هستند. انتظار آن را دارم که بسیاری از اپلیکیشنها از طریق همین APIهایی که سازمان درک چندانی نسبت به آنها ندارد یا حتی نمیداند که در سازمان وجود دارند، لو بروند و دچار نقض امنیتی شوند.»
F5 در گزارش فیشینگ و کلاهبرداری خود در سال 2020 (2020 Phishing and Fraud report) نشان داده که مهاجمین از پروکسیهای فیشینگ لحظهای (real-time phishing proxies) استفاده کرده و سیستمهای احراز هویت چندعاملی (multi-factor authentication) (MFA) را دور میزنند. هر چند به همه کاربران توصیه میشود که راهکارهای احراز هویت چندعاملی را پیادهسازی کنند، اما باز هم بسیاری از سازمانها نمیتوانند این را متوجه شوند که اگر بازیگر تهدید انگیزههای کافی داشته باشد، عامل دوم در MFA هم چندان به درد آنها نخواهد خورد. در سایتهای جعلی (Fake sites) که از آنها برای بررسی حملات پروکسی فیشینگ لحظهای استفاده شده، مشاهده میشود که مهاجمین کد پین 6-رقمی مرسوم برای احراز هویت چندعاملی (MFA PIN) را به دست آورده و از آن برای احراز هویت خود در وبسایت واقعی هدف استفاده میکنند. با توجه به اینکه حملهها در لحظه اتفاق میافتند، چندان فرقی نمیکند که از چه روشی – مثل پیامک، برنامههای احراز هویت موبایلی یا حتی توکنهای سختافزاری – به عنوان عامل دوم احراز هویت استفاده شود. هیچکدام از این روشها نمیتوانند پروکسیهای فیشینگ لحظهای را دفع کنند. از سال 2020 به بعد هم در گزارشات اشاره شده که روشهای دورزدن MFA، روندی رو به رشد را طی میکند. از جمله این حملات میتوان به حملات استفاده مجدد از نشست (session re-use attacks) تا بدافزارهای موبایلی که میتوانند کدهای MFA را سرقت کنند (malware able to steal MFA codes) اشاره نمود.
در بسیاری از راهکارهای جدید برای کاهش اصطکاک در احراز هویت چندعاملی از اعلان لحظهای (پوش نوتیفیکیشن یا push notification) استفاده میشود. در بسیاری از راهکارهای جدید، زمانی که کاربر تلاش میکند تا به سیستم وارد شود، به جای آنکه برنامه از او بخواهد که کد MFA را به صورت دستی وارد کند، یک اعلان سریع برای شماره تلفن ثبتشده او ارسال میشود و از او میخواهد که ورود به برنامه را تأیید یا رد کند.
رمی کاهن (Remi Cohen) مدیر هوش تهدید سایبری F5 در دفتر CISO میگوید:
«مهندسی اجتماعی از بین نرفته و حملات MFA fatigue که به آنها حملات بمباران MFA (MFA bombing attacks) هم میگویند، همواره بیشتر و اثربخشتر میشوند. در حملات بمباران MFA، درخواستهای بیشماری به سمت قربانی فرستاده میشود تا او را اذیت کند و در نهایت هم کاربر به شکل تصادفی یا به خاطر درماندگی، درخواست اعلان را تأیید کند. این نوع حمله یکی از ریسکهای اساسی برای شرکتها به حساب میآید، زیرا کارکنان آسیبپذیرترین بردار تهدید در برابر حملات مهندسی اجتماعی هستند. علاوه بر این، احراز هویت چندعاملی یکی از کنترلهای امنیتی اساسی است که از آن برای جلوگیری از دسترسی غیرمجاز به داراییهای بحرانی استفاده میشود. در بسیاری از موارد هم شرکتها خیالشان راحت است که کنترلهای جبرانکنندهای مثل MFA دارند و بنابراین، توجهی نسبت به کلمات عبور لورفته نداشته یا الزامات ضروری برای کلمات عبور قوی را رعایت نمیکنند. کیتهای فیشینگ مبتنی بر احراز هویت چندعاملی (MFA-enabled phishing kits) و بمباران احزار هویت چندعاملی (MFA bombing)، کنترلهای جبرانساز را خنثی کرده و باز هم بر اهمیت عبارتهای عبور (passphrases)، دفاع در عمق (defense-in-depth) و حرکت به سمت معماری اعتماد-صفر (zero-trust architecture) تأکید میکنند که در آنها از عوامل دیگری هم برای تأمین امنیت شرکت یا افراد استفاده میشود.
صحنه امنیت سایبری، بیشتر شبیه به یک مچاندازی بین مهاجمین و کسانی است که دفاع میکنند. روشهای احراز هویت هم از این قاعده مستثنی نیستند. کن آرورا (Ken Arora)، مهندس برجسته F5، آینده MFA را به صورت زیر توصیف میکند:
«مهاجمین از روشهای مختلفی مانند تایپواسکواتینگ (typo squatting یا دزدی برند)، اکانت تیکاور (account takeover)، جعل دستگاه MFA (MFA device spoofing) و مهندسی اجتماعی (social engineering) استفاده میکنند تا خود را با راهکارهای MFA سازگار سازند. در نتیجه، کسانی که از اپلیکیشنها و شبکه دفاع میکنند، به آنچه در ادامه اتفاق خواهد افتاد، مینگرند.
در مورد احراز هویت بیومتریک هم شک و شبهه وجود دارد، زیرا مثلاً اگر قرار باشد که اثر انگشت عوض شود، این کار ممکن نیست. اما رفتارهایی مثل رفتار خاص کاربران را سختتر میشود جعل کرد، به خصوص اگر در مقیاس بزرگ باشد. این روش میتواند شامل مصنوعات رفتاری معمولی باشد. در این زمینه میتوانیم از چیزهایی مثل مرورگر مورد استفاده و مکان جغرافیایی، رفتارهای خاص اپلیکیشن (الگوهای ناوبری (navigation patterns) در سایت، مدت زمان ماندن در سایت) و رفتار کاربر (سرعت دابلکلیک، الگوی حرکت ماوس، سرعت تایپ) نام ببریم.
ملیسا مکری (Melissa McRee)، مدیر ارشد تیم گزارش تحلیل تهدیدات ضدکلاهبرداری (TAR) (anti-fraud threat analytics reporting) میگوید:
«از اواسط دهه 2010 میلادی به بعد، از تحلیل الگو و کشف رفتار غیرعادی (anomaly detection) برای رفتار کاربران استفاده شده تا فعالیتهای مشکوک شناسایی شوند. این کار تحت عنوان UBA (تحلیل رفتاری کاربران) (User Behavioral Analytics) انجام شده است. میتوانیم به گونهای حرکت کنیم که یک گام بلند به جلو برداریم و مؤثرتر عمل کنیم، زیرا ظرفیتهای پردازشی که تا به امروز به دست آمده، آنقدر هست که بتوانیم ارزیابیهای پیچیدهتر را در لحظه انجام دهیم.»
در آینده نزدیک، شاید بتوانیم از راهکار امیدوارکننده پروتکل احراز هویت FIDO به عنوان اولین روش واقعی مؤثر برای کاهش حملات مهندسی اجتماعی استفاده کنیم، زیرا کلید رمزیای که کاربران برای احراز هویت در این روش استفاده میکنند، بر اساس آدرس وبسایتی است که از آن دیدن میکنند.2 باید منتظر باشیم و ببینیم که کاربران عادی چه موقع و با چه سرعتی به سمت این فناوری جدید میآیند.
به نظر میرسد که پیشبینی رویدادهای امنیتی با استقرار روی ابر یک کار حتمی و بدیهی باشد، اما با توجه به اینکه موارد نقض امنیتی در اپلیکیشنهای ابری همواره بیشتر و بیشتر میشوند و از آنجا که این موارد نقض میتوانند خیلی زیاد باشند، فکر میکنیم که همواره تکرار خواهند شد. همانطور که در گزارش حفاظت از اپلیکیشنهای سال 2022 (2022 Application Protection report) هم گفتهایم، بیشتر رویدادهای ابری مربوط به پیکربندی نادرست هستند و معمولاً به کنترل دسترسیهای گسترده و بیش از اندازه بر میگردند. بنابراین، هرچند به نظر میرسد که یک کار خیلی ساده را انجام میدهیم، اما نقطهنظرات ارائهشده از سوی مهندسین مرکز عملیات امنیت (SOC) در F5 که همواره سعی دارند تا موارد نقض امنیتی در اپلیکیشنهای ابری را مرتفع کنند، یک دیدگاه منحصر بفرد را در اختیار شما قرار میدهد تا ببینید که چرا این همه مشکل در این زمینه وجود دارد. اتان هنسن (Ethan Hansen)، یکی از مهندسین SOC در F5 که بر روی امنسازی زیرساختهای ابری برای مشتریان کار میکند، تجربهاش را به صورت زیر بیان میکند:
«بسیاری از کاربران ابر، چه به صورت تصادفی و چه زمانی که در حال عیب یابی (troubleshooting) هستند، با پیکربندی صحیح کنترل دسترسی، هم در سطح کاربر و هم در سطح شبکه، مشکل دارند. مرکز عملیات امنیت F5 در سال 2022، موارد بسیاری را مشاهده کرده که در آنها، کاربران سعی میکنند تا کاربران «موقت» برای سرویسها ایجاد کرده و بر اساس خطمشیهای داخلی IAM (مدیریت هویت و دسترسی) یا خطمشیهای درون خطی (inline)، مجوزهای بسیار زیادی را به این کاربران موقت اعطا کنند. این کاربران «موقت» معمولاً به منظور انجام امور مربوط به عیب یابی یا دسترسی به اپلیکیشنهایی که مربوط به یک کاربر خاص یا برگرداندن و اجرا هستند، ایجاد میشوند.
معمولاً پیکربندیهایی را میبینیم که در آنها، این اصلاحات «موقت» به شکل دائمی باقی مانده و برگرداندن تغییرات بسیار دشوارتر شده است. از همه بدتر اینکه اگر به جای اعتبارنامههای (credentials) کوتاهمدت و موقتی از اعتبارنامههای بلندمدت و دائمی استفاده شود، احتمال آنکه این اعتبارنامهها به سرقت رفته یا به نوعی لو بروند، بیشتر میشود.»
درست مثل اقتصاد جهانی که همه ما در آن زندگی میکنیم، نرمافزارها هم روز به روز و بیش از پیش به هم وابسته میشوند. بسیاری از اپلیکیشنها با استفاده از کتابخانههای منبعباز (open-source libraries) تولید میشوند. با این حال، فقط بعضی از سازمانها هستند که میتوانند کتابخانههای مورد استفاده را به شکل دقیق در آورند. با توجه به اینکه مدافعان «محیط پیرامونی» (perimeter) اپلیکیشنها (مثل وباپلیکیشنهایی که در اختیار عموم قرار میگیرد و APIها) را بهبود میبخشند، طبیعتاً عاملان تهدید هم به دنبال بردارهای دیگر خواهند بود. استفاده از کدها، کتابخانهها و سرویسهای موجود در اپلیکیشنها به عنوان بردار ارجح به حساب میآید. تا 78% از کدهای موجود در پایگاه کدهای (codebase) سختافزار و نرمافزارها از کتابخانههای منبعباز استخراج میشوند و در داخل توسعه داده نمیشوند.3 به عنوان یک بازیگر تهدید، اگر این را بدانید که بیشتر از سه چهارم کدهای یک اپلیکیشن در کتابخانههای منبعباز نگهداری میشوند، آنوقت منطقی است که این مخازن کد را هدف قرار دهید.
در سالهای اخیر میبینیم که روشهای زیادی پدید آمدهاند که در آنها، کتابخانههایی وجود دارند که سازمان بر آنها تکیه دارد و ریسکهایی از این منظر بر سازمان وارد میشود:
اکانتهای دولوپرها (توسعه دهندگان) (Developer accounts) معمولاً به خاطر عدم احراز هویت چندعاملی به خطر میافتند و در نتیجه، یک سری کد مخرب به داخل کتابخانههای پراستفاده و افزونههای (extension) مرورگر وب گوگل کروم وارد میشود.
حملات تروجان و تایپواسکواتینگ. در این نوع تهدیدات، بازیگر تهدید ابزاری را توسعه میدهد که مفید به نظر میرسد یا اسمهایی بسیار شبیه به کتابخانههای پراستفاده دارد.
کدهای مخرب به شکل عمدی و توسط نویسنده اصلی کتابخانه، اما به صورت هکتیویسم (hacktivism) یا اعتراض سیاسی تزریق میشوند.
کن آرورا (Ken Arora) توضیح میدهد که این کارها در آینده توسعه اپلیکیشنها چه معنایی دارند:
«بسیاری از اپلیکیشنهای امروزی از نرمافزار به عنوان خدمت (SaaS) (software-as-a-service)، مانند احراز هویت متمرکز (centralized authentication)، پایگاه داده به عنوان خدمت (databases-as-a-service) یا پیشگیری از اتلاف دادهها (DLP) (data leakage prevention) استفاده میکنند. اگر بازیگر تهدید بتواند پایگاه کد نرمافزار منبعباز (OSS) (open source software) یا سرویسهای SaaS که اپلیکیشن از آن استفاده میکند را به خطر بیندازد، جای پای خود را «در درون» نرمافزار باز کرده و دفاعهای پیرامونی موجود مانند فایروالهای وباپلیکیشن (web application firewalls یا WAF) و گیت ویهای API (API gateways) را دور میزند.
سپس، میتواند از همین جای پا برای حرکت جانبی به شکلهای مختلف، مانند شل از راه دور (remote shell)، پایش (monitoring) و سرقت یا دسترسی غیرمجاز به اطلاعات محرمانه (exfilteration) استفاده کند. نتیجه، آن است که دولوپرهای(توسعه دهندگان) نرمافزار دید بیشتری نسبت به اجزای تشکیلدهنده آن نرمافزار خواهند خواست و مهمتر از آن، نیاز به صورت مواد نرمافزار (SBoM) (Software Bill of Materials) که تمام اجزای نرمافزار را تشکیل میدهند، خواهند داشت. در این صورت، اگر یک آسیبپذیری بر روی محصول نرمافزاری مورد نظر اثر بگذارد، مصرفکننده آن محصول میتواند به سرعت و به شکل کارآمد، این آسیبپذیری را تشخیص دهد.»
آرون بریلزفورد (Aaron Brailsford)، مهندس اصلی امنیت در تیم واکنش در برابر رویدادهای امنیتی (SIRT) در F5 معتقد است که صورت مواد نرمافزار (SBoM) قطعاً باید وجود داشته باشد، اما اشاره میکند که وجود این مستندات کار بسیار زیادی را بر روی دوش سازمان میگذارند:
«تصور میکنم که اگر SBoMها بیش از اندازه مطرح شوند، میزان زیادی از بدهی به فناوری در سازمان به وجود میآید. من فکر نمیکنم که اگر این کار انجام نشود، امنیت محصولات یا سیستمها کمتر میشوند، اما قطعاً معتقدم که وجود SBoMها باعث میشود تا نقطهای روشن بر روشهای بیحساب و کتاب برای تولید محصولات در صنعت بتابد. کمکم شرکتها مجبور میشوند که سرمایهگذاریهای زیادی را در داخل سازمان انجام دهند تا سیستمهای قدیمیشان را بهروز کرده و تعداد بسیار زیادی از آسیبپذیریها که در حد هزاران مورد هستند را اصلاح کرده یا کاهش دهند و یک روش تمیز را برای نسل جدید محصولات خود در پیش گیرند. شاید هم باید همه این کارها را با هم انجام دهند. البته، شاید مشتریان هم کمکم یاد بگیرند که باید انتظار تعداد زیادی آسیبپذیری اصلاحنشده را در محصولات منتخب خود داشته باشند، زیرا این موارد بسیار شبیه به هم هستند. من به دنبال تغییرات اساسی هستم و مشتاق این کار هم هستم.»
وقتی از کن (Ken) پرسیده شد که راهکار کاهش ریسکهای ناشی از کتابخانههای شخص ثالث را چه میداند، چنین پاسخ داد:
«در مورد آسیبپذیریهای افشانشده (undisclosed) و روز-صفر (zero-day)، بهترین شانس برای کشف مهاجم آن است که نسبت به ترافیک داخلی «شرقی-غربی» بین اجزای نرمافزار و سرویسهای «درون» اپلیکیشن دید داشته باشید. همچنین، باید بدانید که این اجزا با پلتفرم زیرساختی (IaaS) (Infrastructure-as-a-Service) چه ارتباطی دارند. امروزه این تعاملات از طریق CSPM (زیرساخت)، CWPP (e-w، شرقی-غربی) و ADR (لایه اپلیکیشن) انجام میشوند؛ این بازارهای جدا از یکدیگر باید در کنار هم قرار گیرند تا یک دید جامع به دست آمده و تهدیدات بین اپلیکیشنها (intra-app threats) به تعداد کافی شناسایی شده و تعداد مثبتهای کاذب کمتر شوند.»
اینکه امروز بدافزارهای رمزکننده شایع شدهاند، ادعای عجیبی نیست. اما این، همه آن چیزی نیست که چارچوب MITRE ATT&CK از آن تحت عنوان باجافزار نام میبرد و مربوط به «رمزکردن دادهها برای اثرات منفی» است.4 همین سال گذشته بود که نتایج نشان داد که حتی با در نظر گرفتن گونههای مختلف غیررمزگذاری، باز هم بدافزارها به تنهایی، بزرگترین عامل برای لورفتن داده در سازمانهای ایالات متحده در سال 2021 بودهاند. تمرکز اصلی مهاجمین بر سرقت دادهها(exfiltrating) بوده است. وقتی که مهاجمین دست روی این مسأله میگذارند، روشهای زیادی برای باجخواهی و پول درآوردن خواهند داشت.
آدیتیا سود (Aditya Sood)، مدیر ارشد تحقیقات مرتبط با تهدیدات در دفتر CTO در F5 نیز اخیراً روندی رو به رشد را در خصوص باجافزارهایی مشاهده کرده که مستقیماً دیتابیسها را هدف قرار میدهند:
«جرایم سایبری سازمانیافته و دشمنان یک کشور (nation-state adversaries) همواره روشهای باجافزاری توسعه میدهند و انتظار میرود که زیرساختهای حیاتی را به طور خاص هدف بگیرند. حملات باجافزاری نسبت به دیتابیسهای ابری در سالهای پیشرو به شدت افزایش خواهند یافت، زیرا این دیتابیسها همانجایی هستند که دادههای حیاتی مأموریت برای شرکتها و دولتها در آنها قرار دارند. بر خلاف بدافزارهای سنتی که فایلها را در سطح فایلسیستم (filesystem level) رمز میکنند، باجافزارهای دیتابیس میتوانند دادهها را در داخل خود دیتابیس رمز کنند.»
دیوید آرتور (David Arthur) معمار راهکارهای امنیتی F5 برای منطقه آسیا-اقیانوسیه معتقد است که کلاهبرداریهایی که منجر به آلودگی باجافزاری موفق میشوند، انگیزه اصلی برای جذب فشارهای سیاسی به حساب میآیند:
«مهاجمین همواره سعی میکنند تا از افرادی که به واسطه انواع و اقسام شیادیها و کلاهبرداریهای رو به پایین (مثلاً تقاضای کارتهای اعتباری جدید) دادههای آنها لو رفته و متأثر شدهاند، اخاذی کنند. این روشهای شیادی باورپذیرتر شدهاند و هر چند که حاوی اشتباهات آشکار برای کاربران مطلع هستند، اما با این وجود باز هم موفق میشوند؛ طعم این نوع کلاهبرداری آنقدر برای مهاجم شیرین است که هر چند او را به زحمت میاندازد، اما این زحمت را به جان میخرد. مهاجمین چنین میپندارند که اگر با سرقت اطلاعات شخصی مشتریان نتوانند از سازمان مورد نظر اخاذی کنند (مثلاً نتوانند از سازمان باجخواهی کنند یا او را تهدید کنند که داراییهای معنوی آنها را منتشر میسازند)، آنگاه به سراغ افراد میروند.
سالها است که باجافزارها مشکلات عملیاتی وخیمی را برای شرکتها به وجود آورده و بر حریم خصوصی افراد اثر گذاشتهاند. این در حالی است که تلاش چندانی برای مبارزه با این باجافزارها در سطوح سیاسی صورت نگرفته است. در صورتی که زیرساختهای حیاتی (CI) (critical infrastructure) هدف قرار گیرند، وضعیت فرق میکند. صرفاً مدت کوتاهی پس از حمله خط لوله استعماری در ماه ژوئن سال 2021، رییسجمهور ایالات متحده، جو بایدن گفت که فشار زیادی را بر روی رییس جمهور روسیه، ولادیمیر پوتین وارد کرده تا با گروههای باجافزاری مطابق با قانون رفتار کند. به نظر میرسید که این باجافزارها از سوی روسیه آمده و ظاهراً مصون از مجازات هم بودند. به نظر میرسد که فشارهای جغرافیای سیاسی – و استفاده از رمزارزها که جرایم سایبری را تسهیل میکنند – روشی بسیار اثربخشتر از کنترلهای فنی در مبارزه با این تهدیدات است. در نتیجه، منطقی به نظر میرسد که بگوییم که فشارهای سیاسی تنها در صورتی اعمال میشوند که زیرساختهای حیاتی (CI) یک کشور به شدت و به صورت جدی تحت تأثیر قرار گیرند.
به ندرت پیش میآید که محققین حوزه تهدیدات، روندهایی را در رفتار مهاجمین نشان دهند که بر اساس آنها، CISOها و سایر راهبران امنیت نقطهی تمرکز و اولویتهای خود را به شدت عوض کنند. پیشبینیهای ما برای سال 2023 هم از این قاعده مستثنی نیست. بسیاری از مشاهدات ما از فعالیتهای مخرب حاکی از آن است که مهاجمین تنها در صورتی عملیاتشان را عوض میکنند که مجبور شوند کنترلهای امنیتی مورد استفاده ما مثل احراز هویت چندعاملی را دور بزنند. آنچه از این مطلب بر میآید، آن است که ما نیاز به یک اتفاق اساسی داریم. نه بهبودهای تدریجی و نه فشارهای جغرافیای سیاسی، هیچکدام به تنهایی نمیتوانند تفاوتهای قابل ملاحظهای را در بسیاری از تهدیداتی که با آنها روبرو هستیم و به ویژه آنهایی که مستقیماً کاربر نهایی را هدف میگیرند، به وجود آورند. وقتی که پای پول درآوردن از راه شیادی، کلاهبرداری و سایر روشهای مهندسی اجتماعی در میان باشد، مجرمین به هر شکلی که شده، راههایی را پیدا میکنند تا به نفع خود از آنها استفاده کنند.