چارچوب‌های فعلی ریسک توسعهٔ امنیت سایبری تمام تاکتیک‌هایی که هکرها برای نفوذ به SolarWinds، log4j یا XZ Utils استفاده کردند را پوشش نمی‌دهند، گزارش می‌گوید که یک «کیت شروع» از وظایف بحرانی ارائه می‌دهد.
بدترین حملات زنجیره تامین
رهبران DevOps که امیدوارند چارچوب ریسک یکپارچه‌ای در امنیت سایبری پیدا کنند تا از مواجهه کارشان با انواع نقض‌هایی که منجر به حملات زنجیره تامین می‌شوند جلوگیری کند، طبق یک مقاله تحقیقاتی جدید، با مشکل روبرو خواهند شد.
در مقاله‌ای که به سایت arXiv دانشگاه کورنل برای دست‌نوشته‌های علمی ارسال شده است، شش پژوهشگر — چهار نفر از دانشگاه ایالتی کارولینای شمالی، یک نفر از یاهو و یک نفر بین این دو موقعیت — اعلام کردند که می‌توانند مهم‌ترین وظایفی که تیم‌های توسعه نرم‌افزار باید اجرا کنند تا از نقض‌های احتمالی در کارشان که ممکن است منجر به استفاده از برنامه‌هایشان برای حمله به کاربران شود، رتبه‌بندی کنند.
آنها این کار را با مقایسهٔ ۱۱۴ تکنیک گزارش‌شدهٔ مورد استفاده در نقض سه برنامه حیاتی، SolarWinds Orion، log4J و XZ Utils، با ۷۳ وظیفهٔ پیشنهادی که در ۱۰ چارچوب امنیت نرم‌افزاری فهرست شده است، از جمله چارچوب توسعهٔ نرم‌افزار ایمن NIST ایالات متحده، انجام دادند.
با این حال، پژوهشگران افزودند که سه عامل کاهش خطر از تمام ۱۰ چارچوب غایب بودند. این نشان می‌دهد که هیچ چارچوبی نمی‌تواند تمام حفره‌های بالقوهٔ یک برنامه را بسته کند. سه عنصر مفقود عبارتند از:
- اطمینان از پایداری نرم‌افزار منبع باز؛
- داشتن ابزارهای اسکن محیطی؛
- و اطمینان از اینکه شرکای برنامهٔ کاربردی آسیب‌پذیری‌های خود را گزارش می‌دهند.
یوهانس اولریک، رئیس تحقیقات در مؤسسه SANS با این نظر موافقت کرد.
«هیچ‌یک از [چارچوب‌ها] کامل نیست»، او در ایمیلی گفت، «و این قابل قبول است. زنجیره تامین نرم‌افزار نمی‌تواند به صورت جداگانه امن شود. رهبران DevOps باید با بقیهٔ سازمان گفتگو کنند تا ببینند کجا خلأهایی وجود دارد که باید پر کنند. این چارچوب‌ها نقطهٔ شروعی برای آن بحث هستند.»
«در مورد این سه خلأ، تا حدی به دامنهٔ تلاش امنیتی زنجیره تامین نرم‌افزاری شما بستگی دارد. به عنوان مثال، آنها [پژوهشگران] «نرم‌افزار منبع باز» را به عنوان یک تأمین‌کننده در نظر نمی‌گیرند، چون رابطهٔ قراردادی وجود ندارد. من فکر می‌کنم رابطهٔ قراردادی وجود دارد، حتی اگر اغلب ضعیف باشد، تحت پوشش مجوزهای مختلف منبع باز. من معتقدم این به‌طور اساسی متفاوت از نرم‌افزار تجاری نیست. تأمین‌کنندگان تجاری ممکن است «ناپدید شوند» یا پشتیبانی یک قطعهٔ خاص از نرم‌افزار را در هر زمان متوقف کنند (که گمان می‌کنم منظورشان همین کنترل است).»
ابزارهای اسکن محیطی، یک کاهش خطر دیگر که مفقود است، اغلب بخشی از مدیریت آسیب‌پذیری‌هاست، اوولریچ افزود. اما او گفت، گاهی فعالیت‌های دیگر می‌توانند خلأ را پر کنند. برای مثال، «همکاری پاسخ» اغلب بخشی از چارچوب پاسخگویی به حادثه است و همکاری نیز اغلب بخشی از تحلیل تهدیدات می‌باشد.
«اگر استفاده از چارچوب‌ها را فراتر از آنچه برای آن طراحی شده‌اند گسترش دهید، می‌توانید همیشه خلأهایی پیدا کنید»، او به‌خاتمه رساند، «و دوباره، آنها نیاز به به‌روزرسانی مستمر دارند.»
مقالهٔ بستن زنجیره: چگونه ریسک خود را نسبت به SolarWinds، log4J یا XZ Utils کاهش دهید به سه‌تا از بدترین نقض‌های زنجیره تامین در سال‌های اخیر می‌پردازد.
- Solar Winds: همان‌طور که گزارش دادیم، مایکروسافت معتقد بود که «حداقل ۱٬۰۰۰ مهندس بسیار ماهر و توانمند» بر روی این هک کار کرده‌اند، که شامل درج کد مخرب با نام Sunburst در به‌روزرسانی‌های نرم‌افزاری برای مجموعهٔ مدیریت شبکه Orion شرکت SolarWinds بود. سولارویندز اعلام کرد حدود ۱۸٬۰۰۰ شرکت به‌روزرسانی‌ها را دانلود کردند و از میان آنها، حدود ۱۰۰ مورد تحت تأثیر قرار گرفتند؛
- Log4j: حمله‌کنندگان یک نقص را بهره‌برداری کردند (CVE-2021-44228)، که Log4Shell نام داشت، در ابزار ثبت‌لاگ منبع باز log4j شرکت Apache. این نقص در مقیاس آسیب‌پذیری CVSS نمرهٔ ۱۰ از ۱۰ دریافت کرد و می‌توانست منجر به اجرای کد از راه دور (RCE) بر سرورهای پایه شود. به دلیل گستردگی آن در طیف وسیعی از برنامه‌ها، مشخص نیست چه تعداد شبکهٔ فناوری اطلاعات تحت تأثیر قرار گرفته‌اند؛
- XZ Utils یک ابزار فشرده‌سازی داده است که بخشی از توزیع‌های اصلی لینوکس می‌باشد. نصب یک درب پشتی قبل از این که به خسارت گسترده‌ای منجر شود، شناسایی شد، ما سال گذشته گزارش دادیم.
پژوهشگران می‌خواستند تمام وظایف پیشنهادی در ۱۰ چارچوب امنیت توسعهٔ نرم‌افزار را بر اساس تاکتیک‌های استفاده‌شده توسط عاملان تهدید در این سه حمله اولویت‌بندی کنند، که نشان می‌دهد وظایف فعلی چارچوب‌ها می‌توانستند از این حملات جلوگیری کنند. این کار همچنین خلأهای موجود در چارچوب‌ها که کد را در معرض حملات می‌گذارند، نشان می‌دهد.
آنها ۱۰۶ گزارش اطلاعات تهدید سایبری (CTI) مرتبط با تکنیک‌های استفاده‌شده در این سه حمله را تحلیل کردند و سپس آنها را به ۷۳ وظیفهٔ بهترین روش در چارچوب‌ها که توسعه‌دهندگان باید انجام دهند، نسبت دادند. در نهایت، وظایف اولویت‌دار را که بهترین کاهش خطر برای تکنیک‌های حمله را فراهم می‌کنند، رتبه‌بندی کردند.
در حالی که ۱۱۴ تکنیک حملهٔ یکتا در سه هک وجود داشت، ۱۲ مورد از آنها مشترک بودند، از جمله بهره‌برداری از روابط اعتماد، مخفی‌سازی داده‌ها و تخریب زیرساخت. آنها همچنین یافتند که ۲۷ مورد از ۷۳ روش پیشنهادی می‌توانستند این سه حمله را کاهش دهند.
با این حال، آنها افزودند که سه مورد از ۲۷ وظیفهٔ توصیه‌شده برای کاهش خطر در هیچ یک از چارچوب‌ها گنجانده نشده‌اند؛ این موارد شامل استفاده از نرم‌افزار منبع باز پایدار و استفاده از ابزارهای اسکن محیطی می‌شود.
«به این ترتیب، حتی اگر سازمان‌ها تمام وظایف پیشنهادی را به کار گیرند، محصولات نرم‌افزاری هنوز در معرض حملات زنجیره تامین نرم‌افزاری خواهند بود»، آنها به‌نتیجه رسیدند.
جعبهٔ شروع تدابیر کاهش خطر
کاری که این پژوهش به پژوهشگران امکان داد این بود که «جعبهٔ شروع» شامل ۱۰ تاکتیک دفاعی که توسعه‌دهندگان باید اتخاذ کنند، بر پایهٔ بالاترین امتیازهای کاهش خطر در تحقیقشان ایجاد کنند. این ۱۰ تاکتیک از چارچوب مدیریت پیشگیرانهٔ ریسک زنجیره تامین نرم‌افزار (P-SSCRM) گرفته شده‌اند:
- کنترل دسترسی مبتنی بر نقش
- نظارت مستمر بر سیستم
- نظارت و کنترل ارتباطات در مرز خارجی سیستم و در مرزهای داخلی کلیدی
- نظارت بر تغییرات تنظیمات پیکربندی
- فعالسازی احراز هویت برای کارمندان و پیمانکاران
- به‌روزرسانی وابستگی‌های آسیب‌پذیر زمانی که نسخهٔ اصلاح‌شده در دسترس باشد
- شمارش مسیرهای ممکن تهدید از طریق مدل‌سازی تهدید و تجزیه و تحلیل سطح حمله
- محدود کردن جریان اطلاعات در مرزهای اعتماد به مشارکت‌کنندگان زنجیره تامین
- حفاظت از اطلاعات در حالت استراحت
- رفع آسیب‌پذیری‌ها، با اولویت‌بندی بر اساس ریسک.
این ۱۰ تدبیر کاهش خطر به امنیت کلی نرم‌افزارهای گسترده‌تر اعمال می‌شود تا اینکه خاص امنیت زنجیره تامین نرم‌افزار باشند، پژوهشگران افزودند. «قبل از کاهش خطر حملات زنجیره تامین نرم‌افزار، باید به وظایف رایج امنیت نرم‌افزار پرداخته شود»، آنها تأکید کردند.
در مصاحبه‌ای، هم‌نویسندهٔ گزارش، سیوانا هامر، اذعانه کرد که تمام ۱۰ چارچوب مورد بررسی دارای خلأهایی در تدابیر کاهش خطر هستند که باید برای سه برنامهٔ هک‌شده اعمال می‌شد. او گفت: «هیچ یک از چارچوب‌ها قرار نیست تصویر کاملی از امنیت ارائه دهند.» «همه دارای مفهوم متفاوتی هستند، مانند اینکه برخی بیشتر بر محیط‌های ساخت تمرکز دارند.»
«جعبهٔ شروع» تدابیر کاهش خطر، فهرست وظایف امنیتی است که توسعه‌دهندگان باید آنها را در اولویت قرار دهند، او گفت.
پست های مرتبط
توسعه‌دهندگان: ابتدا این ۱۰ تدبیر را برای جلوگیری از حملات زنجیره تأمین اعمال کنید
توسعه‌دهندگان: ابتدا این ۱۰ تدبیر را برای جلوگیری از حملات زنجیره تأمین اعمال کنید
توسعه‌دهندگان: ابتدا این ۱۰ تدبیر را برای جلوگیری از حملات زنجیره تأمین اعمال کنید