وقتی آسیب‌پذیری‌های جدید در نرم‌افزار کشف می‌شوند، صنعت امنیت مجموعاً ذهن خود را از دست می‌دهد. OpenSSL نیز از این قاعده مستثنی نیست و دو آسیب‌پذیری جدید در اواخر اکتبر و اوایل نوامبر 2022 بر فیدهای خبری غلبه کردند. کشف و افشا تنها آغاز این چرخه آسیب‌پذیری بی‌پایان است. سازمان‌های آسیب‌دیده با اصلاح مواجه هستند که به‌ویژه برای کسانی که در خط مقدم فناوری اطلاعات هستند دردناک است. رهبران امنیتی باید یک استراتژی امنیت سایبری موثر را برای کمک به فیلتر کردن برخی از نویزهای آسیب‌پذیری جدید، شناسایی تأثیرات بر زنجیره‌های تأمین و ایمن سازی دارایی‌های خود حفظ کنند.
حملات زنجیره تامین از بین نمی روند
در مدت تقریباً یک سال، ما از آسیب‌پذیری‌های شدید در مولفه‌ها از جمله آسیب‌پذیری رنج برده‌ایم log4j, چارچوب بهارو OpenSSL را. بهره برداری از آسیب پذیری های قدیمی تر نیز هرگز از پیاده سازی هایی که به اشتباه پیکربندی شده اند یا از وابستگی های آسیب پذیر شناخته شده استفاده می کنند، متوقف نمی شود. در نوامبر 2022، عموم مردم از یک کمپین حمله به شعبه اجرایی غیرنظامی فدرال (FCEB)، قابل انتساب به یک تهدید دولتی تحت حمایت ایران. این نهاد فدرال ایالات متحده زیرساخت VMware Horizon را اجرا می کرد که حاوی آسیب پذیری Log4Shell بود که به عنوان بردار حمله اولیه عمل می کرد. FCEB با یک زنجیره حمله پیچیده که شامل حرکت جانبی، به خطر انداختن اعتبار، به خطر افتادن سیستم، تداوم شبکه، دور زدن حفاظت نقطه پایانی، و cryptojacking بود، ضربه خورد.
سازمان ها ممکن است بپرسند "چرا اصلاً OSS مصرف کنیم؟" پس از حوادث امنیتی از بسته های آسیب پذیر مانند OpenSSL یا Log4j. حملات زنجیره تامین روند صعودی خود را ادامه می دهند زیرا استفاده مجدد از اجزاء برای شرکا و تامین کنندگان "معنای تجاری خوبی" ایجاد می کند. ما سیستم ها را با استفاده مجدد از کدهای موجود به جای ساختن از ابتدا مهندسی می کنیم. این برای کاهش تلاش مهندسی، مقیاس عملیاتی و تحویل سریع است. نرم افزار منبع باز (OSS) به طور کلی به دلیل بررسی های عمومی که دریافت می کند قابل اعتماد در نظر گرفته می شود. با این حال، نرم افزار همیشه در حال تغییر است و مشکلاتی از طریق اشتباهات کدنویسی یا وابستگی های مرتبط به وجود می آیند. مسائل جدید نیز از طریق تکامل تکنیک‌های آزمایش و بهره‌برداری آشکار می‌شوند.
مقابله با آسیب پذیری های زنجیره تامین
سازمان ها برای ایمن سازی طرح های مدرن به ابزار و فرآیند مناسب نیاز دارند. روش‌های سنتی مانند مدیریت آسیب‌پذیری یا ارزیابی‌های لحظه‌ای به تنهایی نمی‌توانند ادامه دهند. مقررات ممکن است همچنان به این رویکردها اجازه دهد، که شکاف بین "ایمن" و "سازگار" را تداوم می بخشد. بیشتر سازمان ها آرزوی به دست آوردن سطحی از بلوغ DevOps را دارند. «پیوسته» و «خودکار» از ویژگی‌های رایج رویه‌های DevOps هستند. فرآیندهای امنیتی نباید متفاوت باشد. رهبران امنیتی باید تمرکز خود را در طول مراحل ساخت، تحویل و زمان اجرا به عنوان بخشی از استراتژی امنیتی خود حفظ کنند:
- اسکن مداوم در CI/CD: سعی کنید خطوط لوله ساخت را ایمن کنید (یعنی شیفت به چپ) اما اذعان کنید که نمی‌توانید همه کدها و کدهای تودرتو را اسکن کنید. موفقیت با رویکردهای شیفت به چپ توسط کارایی اسکنر، همبستگی خروجی اسکنر، اتوماسیون تصمیمات انتشار، و تکمیل اسکنر در پنجره های انتشار محدود می شود. ابزار باید به اولویت بندی خطر یافته ها کمک کند. همه یافته ها قابل اجرا نیستند و آسیب پذیری ها ممکن است در معماری شما قابل استفاده نباشند.
- اسکن مداوم در حین تحویل: سازش مولفه و رانش محیط اتفاق می افتد. برنامه‌ها، زیرساخت‌ها و حجم‌های کاری باید هنگام تحویل اسکن شوند، در صورتی که چیزی در زنجیره تامین دیجیتال در هنگام منبع‌یابی از رجیستری یا مخازن و بوت استرپ در معرض خطر قرار گرفته باشد.
- اسکن مداوم در زمان اجرا: امنیت در زمان اجرا نقطه شروع بسیاری از برنامه های امنیتی است و نظارت بر امنیت زیربنای بیشتر تلاش های امنیت سایبری است. شما به مکانیسم‌هایی نیاز دارید که بتواند تله‌متری را در همه انواع محیط‌ها، از جمله محیط‌های ابر، کانتینر و Kubernetes جمع‌آوری و مرتبط کند. بینش جمع‌آوری‌شده در زمان اجرا باید به مراحل ساخت و تحویل قبلی بازخورد داده شود. تعاملات هویتی و خدماتی
- اولویت بندی آسیب پذیری هایی که در زمان اجرا در معرض دید قرار می گیرند: همه سازمان ها با داشتن زمان و منابع کافی برای اسکن و تعمیر همه چیز دست و پنجه نرم می کنند. اولویت بندی مبتنی بر ریسک برای کار برنامه امنیتی اساسی است. قرار گرفتن در معرض اینترنت تنها یک عامل است. مورد دیگر شدت آسیب‌پذیری است و سازمان‌ها اغلب روی مسائل با شدت بالا و حیاتی تمرکز می‌کنند، زیرا به نظر می‌رسد بیشترین تأثیر را دارند. این رویکرد همچنان می‌تواند چرخه‌های تیم‌های مهندسی و امنیتی را هدر دهد زیرا ممکن است آسیب‌پذیری‌هایی را دنبال کنند که هرگز در زمان اجرا بارگذاری نمی‌شوند و قابل بهره‌برداری نیستند. از هوش زمان اجرا برای بررسی اینکه واقعاً چه بسته‌هایی در برنامه‌ها و زیرساخت‌های در حال اجرا بارگذاری می‌شوند استفاده کنید تا از خطر امنیتی واقعی سازمان خود مطلع شوید.
ما ایجاد کرده ایم راهنمای محصول خاص برای هدایت مشتریان به جنون اخیر OpenSSL.
آخرین آسیب‌پذیری OpenSSL و Log4Shell نیاز به آمادگی امنیت سایبری و استراتژی امنیتی مؤثر را به ما یادآوری می‌کند. باید به خاطر داشته باشیم که CVE-ID ها فقط همان مسائل شناخته شده در نرم افزار یا سخت افزار عمومی هستند. بسیاری از آسیب‌پذیری‌ها گزارش نمی‌شوند، به‌ویژه نقاط ضعف در کدهای داخلی یا پیکربندی‌های نادرست محیطی. استراتژی امنیت سایبری شما باید فناوری توزیع شده و متنوع طراحی های مدرن را در نظر بگیرد. شما به یک برنامه مدیریت آسیب‌پذیری مدرن نیاز دارید که از بینش‌های زمان اجرا برای اولویت‌بندی کارهای اصلاحی برای تیم‌های مهندسی استفاده کند. همچنین برای جلوگیری از غافلگیری به قابلیت‌های تشخیص تهدید و پاسخ نیاز دارید که سیگنال‌ها را در بین محیط‌ها مرتبط می‌کند.
درباره نویسنده
.png?width=690&quality=80&format=webply&disable=upscale "خطرات زنجیره تامین شما را سرکوب کرد؟ آرام باشید و استراتژیک باشید!")
مایکل ایسبیتسکی، مدیر استراتژی امنیت سایبری در Sysdig، بیش از پنج سال در مورد امنیت سایبری تحقیق و مشاوره کرده است. او در امنیت ابری، امنیت کانتینر، امنیت Kubernetes، امنیت API، تست امنیت، امنیت موبایل، حفاظت از برنامه‌ها و تحویل مداوم ایمن مهارت دارد. او سازمان های بی شماری را در سطح جهانی در ابتکارات امنیتی خود و حمایت از کسب و کارشان راهنمایی کرده است.
مایک قبل از تجربه تحقیقاتی و مشاوره ای خود، درس های سخت بسیاری را در خط مقدم IT با بیش از 20 سال تجربه حرفه ای و رهبری با تمرکز بر امنیت برنامه، مدیریت آسیب پذیری، معماری سازمانی و مهندسی سیستم آموخت.
