الحماية من الحزم الضارة مفتوحة المصدر: ما الذي ينجح (لا) يعمل

هذه هي الحلقة الثالثة في سلسلة من المقالات حول النوع الأكثر شيوعًا من هجمات سلسلة توريد البرامج: تلك التي تسيء استخدام السجل العام لـ المصدر المفتوح مكونات البرمجيات. بعد التحليل في الحلقة السابقة “تشريح الحزم الضارة: ما هي الاتجاهات؟"كيفية قيام الجهات الفاعلة السيئة بحقن سلوك ضار في المكونات المنشورة الجديدة أو الموجودة، نحن على استعداد لارتداء سترات مكافحة الحرائق لدينا ودراسة كيف يمكننا بنجاح حظر البرامج الضارة التي يتم تسليمها بهذه الطريقة، أو بدلاً من ذلك، التعامل مع حادث سيبراني يحتمل أن يكون خطيرًا لأننا اتخذنا إجراءات النهج الخاطئ.

لدى معظم المتخصصين في مجال الأمن أفكار حول كيفية التعامل مع هذا التهديد. وقد سمعنا مديري الأمن يقولون دون تردد: SCA تُخبرك الأدوات بالفعل متى يكون إصدار الحزمة برمجيًا ضارًا. أو أنها تعتمد على مكونات برمجية معروفة ومراجعة بدقة، حيث يتم اكتشاف أي برمجية خبيثة وإزالتها فورًا. تستخدم هذه الأدوات إصدارات ثانوية/تصحيحات مفتوحة المصدر لإصلاح الثغرات الأمنية تلقائيًا، وهذه هي الطريقة الصحيحة والموصى بها لتقليل مخاطر تبعيات المصادر المفتوحة، باتباع "التصحيح في وقت مبكر ، التصحيح في كثير من الأحيان" المبدأ. 

في هذه الحلقة، سنراجع سبب خطأ هذه الأفكار، وكيف تساهم هذه المفاهيم الخاطئة في زيادة شعبية آلية الهجوم هذه، وفي المخاطر الهائلة التي تواجهها المؤسسات. سننتهي بالحديث عن ما ينجح، وهو الجهد والموارد المستخدمة.

المفاهيم الخاطئة الشائعة

خلال رحلتنا مع أمن البرمجيات، رأينا تقنيات الهجوم تتطور ومجموعة واسعة من الأفكار من الأشخاص المهتمين بالأمن. غالبًا ما تسيء المؤسسات فهم ما يمكن فعله ضد هذا التهديد، لذلك سنفحص أولاً ما لا ينجح، وسنلخصه في قائمة المفاهيم الخاطئة التالية، غير الشاملة.

الاعتقاد الخاطئ رقم 1: SCA الأدوات تقوم بالفعل بالإبلاغ عن المكونات الضارة

في الواقع! ولكن بعد الحقيقة... عندما يكون من المحتمل أن يكون الوقت قد فات إذا تم استخدام العنصر في بناء برنامج، وكان المجرمون السيئون قد اكتسبوا بالفعل موطئ قدم في المطور أو CI/CD ربما تم استخراج الأسرار، أو تنزيل برامج ضارة إضافية وتثبيتها، أو ربما تحرك العدو جانبيًا وتمكن بالفعل من الوصول إلى مكان آخر. 

تحليل تكوين البرمجيات (SCAصُممت أدوات () لتحديد الثغرات الأمنية المعروفة المحتملة. تُؤدي الأدوات الحديثة دورًا رائعًا من خلال زيادة نسبة الإشارة إلى الضوضاء، وتحديد ما إذا كانت الثغرة قابلة للوصول أو الاستغلال بالفعل. لكنها عديمة الفائدة ضد البرامج الضارة الجديدة. تخيّل المكون الخبيث على أنه ثغرة يوم الصفر: فقط عند اكتشاف سلوكه الخبيث، يُبلّغ عن المكون إلى سجل الاحتجاز، والذي بعد مراجعة من قِبل فريق أمني، يُؤكّد أنه خبيث ويُزال من السجل. [1]. 

في تلك المرحلة، العالم (بما في ذلك SCAس) يعلم أن تثبيت أو استخدام المكون (أو بعض إصدارات مكون موجود) ليس بالأمر الجيد. ولكن هذا يحدث عندما لا يكون المكون متاحًا من سجل النظام.إن معرفة وجود ثغرات أمنية في مكونات الطرف الثالث، أو حتى المكونات التي تم تصنيفها على أنها ضارة بواسطة السجل أمر جيد، ولكن للأسف SCA أو أن أدوات التدقيق الشائعة لا تساعد في هذا السياق. ما لم يكن SCAيمكن لأداة التدقيق أن تعرف مسبقًا أن أحد المكونات ضار قبل استخدامه في مؤسستك.

تذكر أن أي حل ضد المكونات الضارة مفتوحة المصدر يجب أن يكتشفها أثناء التنقل، بين وقت نشر المكون في السجل ووقت استخدام المكون (الإصدار) لأول مرة في مؤسستك. وهذا يشمل مكونات متعدية.  

المفهوم الخاطئ رقم 2: التحكم في البرامج النصية للتثبيت في وقت الإنشاء يمنع السلوك الضار من المكونات مفتوحة المصدر

يوفر العديد من مديري الحزم القدرة على تشغيل البرامج النصية (المضمنة في مكون tarball [2]), لأسباب مشروعة، مثل تجميع العناصر المطلوبة على منصات مختلفة، أو إنشاء تعليمات برمجية، أو إجراء اختبارات، ويجب أن نعلم جميعًا أنه يمكن إساءة استخدامها من قبل جهات فاعلة سيئة إذا تم تضمين نصوص برمجية ضارة في كرة القطران، أو إذا كان المهاجم قادرًا على إنشاء برنامج ضار تشغيل البرنامج النصي بدلاً من البرنامج الجيد.

بمعرفة ذلك، يمكننا تكوين مدير الحزم لتجاهل البرامج النصية. على سبيل المثال، مع NPM - تجاهل النصوص العلم (أو خاصية التكوين في ملف .npmrc file) يتخطى البرامج النصية أثناء التثبيت. قد يؤدي هذا إلى بعض المشكلات لأن تشغيل البرامج النصية أمر شائع في العديد من الأنظمة البيئية: بعض مديري الحزم لا يسمحون حتى بتعطيل تنفيذ البرنامج النصي (تلميح: المطالبة "ما مديري الحزم الذين لا يسمحون بتعطيل تنفيذ البرامج النصية للتثبيت؟"في الذكاء الاصطناعي المفضل لديك). لكن هذا لا يوفر الحماية بشكل عام (نحتاج إلى التأكد من أن تكوين تعطيل التخطي موجود في كل مكان). 

وعندما لا يكون السلوك الضار موجودًا في البرامج النصية للتثبيت ولكن في البرنامج المطلوب تنفيذه في وقت التشغيل، فإن هذا الخيار وحده لا يحمينا. 

الاعتقاد الخاطئ رقم 3: يمنع تثبيت الإصدار تثبيت المكونات الضارة

هناك مقايضة بين الترقيع مبكرًا وفي كثير من الأحيان باستخدام الإصدارات المفتوحة (السماح لمدير الحزم بتثبيت التحديثات الجديدة تلقائيًا عند توفرها لإصلاحات الأمان) و تثبيت الإصدار (وجود جميع التبعيات المباشرة والمتعدية للبرنامج في إصدار ثابت). إن المبادئ الأمنية عنيدة ومتناقضة في بعض الأحيان، كما يحدث مع "التصحيح المبكر، والتصحيح المتكرر" و "لا ينبغي الاستخفاف بالترقية". يقوم بعض مديري الحزم بإجراء تحديثات تلقائية لنطاقات الخادم بالطريقة الموصى بها. عظيم إذا كنت تريد أيضًا تلقي التحديثات الضارة! نعم، يجب تحديث المكونات لتلقي الإصلاحات الأمنية التي تعمل على إغلاق الثغرات الأمنية في أسرع وقت ممكن، ولكن... لا تسمح أبدًا لمدير الحزم بالقيام بذلك تلقائيًا.

المفهوم الخاطئ رقم 4: يعد استخدام المكونات الموثوقة أمرًا آمنًا. سيتم العثور على أي إصدار ضار والكشف عنه وإزالته على الفور.

لماذا يعتبر أحد المكونات موثوقًا به؟ ربما لأنه يحظى بشعبية كبيرة، حيث يبحث العديد من الأشخاص عن نقاط الضعف، وعدد كبير من المساهمين في الصيانة، والعديد من صيانين النواة الذين يراجعون جميع المكونات بعناية. pull requestsالواقع مختلف تمامًا. يتم صيانة بعض المكونات الأساسية بواسطة مطور واحد غير مدفوع الأجر. تحتوي الأطر المستخدمة على نطاق واسع على عدد قليل من المساهمين المنتظمين، مع انخفاض عددهم بسرعة commitلكل مشرف (المشاريع الشائعة لها ذيل طويل من المساهمين الذين يقومون ببعض المهام commit ولا تعود أبدا). وتكثر المشاريع الشعبية مع مشرف واحد.

تخيل نفسك تقول "أوه، نحن نستخدم صور Spring Boot / Angular / React / PyTorch / Docker الأساسية، لذا فإن المخاطر التي تتحدث عنها منخفضة جدًا." ربما يكون هذا صحيحًا، فنحن موردي خدمات الأمن نقوم بالترويج للتخويف طوال الوقت، والتدخل في فرق التطوير للتخفيف من المخاطر القابلة للنقاش هو هراء. قد تميل إلى الانتقال إلى فقرة قبول المخاطر (في القسم التالي) وبذلك يتم كل شيء. ولسوء الحظ، فإن المكونات الأكثر شعبية هي أهداف للجهات الفاعلة السيئة، وعلى سبيل المثال، الشعبية تعرضت مكتبة PyTorch للهجوم في الماضي.

"تم العثور عليه والكشف عنه وإزالته على الفور".  وتستغرق إزالة المكون الضار الجديد من السجل العام أيامًا. تتوخى السجلات الحذر بشأن إزالة إصدار المكون، للأبد. وتفيد تجربتنا أنه بمجرد الإبلاغ من جانبنا، فإن متوسط ​​الوقت الذي يستغرقه السجل لإزالة الإصدار المتأثر هو 39 ساعة، أي أكثر من يوم ونصف. توجد مكونات ضارة تظهر بعد أسبوع من الإبلاغ الأولي في السجل قبل الإزالة. وفي بعض الحالات، تتم إزالة المكون فقط بعد قيام الضحية أو شركة الاستجابة للحوادث بالإبلاغ عن حادث يتعلق بالمكون. 

ما الذي لا يعمل ضد المكونات الضارة

وأي نهج غير محدد سوف يفشل فشلا ذريعا. وهذا أمر مؤكد، فأنت لا تقدم تدابير مضادة فعالة للمخاطر المرتبطة بهذا التهديد. 

بناء تقليديا SCA تُخبرك الأدوات عن البرامج الضارة المعروفة، لكن لديها نطاق كشف واسع. ما لم تُجرِ هذه الأدوات كشفًا استباقيًا للبرامج الضارة مع حظرٍ قسريٍّ للمكونات الضارة، فلن تُجدي نفعًا في مواجهة هذا التهديد. 

يمكن أن يساعد تعطيل البرامج النصية للتثبيت ولكن يجب تنفيذه في كل مكان يحتاج فيه المكون إلى التثبيت. نفس الشيء مع تثبيت الإصدار، حيث لا يمكن تثبيت الإصدارات من الحالة الأولية الآمنة إلى الأبد.

إن افتراض أن المكونات الشائعة تحظى باهتمام كافٍ بحيث لا يمكن حقنها بسلوك غير مقصود في هجوم على سلسلة التوريد دون اكتشاف فوري تقريبًا لمنع أي ضرر هو افتراض ساذج ومحفوف بالمخاطر. أنت لا تريد أن تعيش على الحافة، أليس كذلك؟

إذا توقفت عند هذه النقطة، ثم قبول المخاطر الشيء الوحيد الذي يمكنك فعله هو: هذا هوcisأي شيء يجب توثيقه في نموذج التهديد/تقييم المخاطر، بما في ذلك مبررات قبول المخاطر وتداعياتها المحتملة. ساهم في رفع مستوى الوعي من خلال إبلاغ الإدارة والأطراف المعنية الأخرى. طارئ يمكن التخطيط له عند تثبيت مكون ضار أو تضمينه في برنامجك، ولكن هذا أمر صعب لأن المهاجمين لديهم العديد من المسارات التي يجب عليهم اتباعها. ستؤدي تفاصيل هجوم سلسلة التوريد بناءً على استخدام مكون ضار إلى تغيير جذري في الكشف العام عن الحادث، والذي ربما يكون إلزاميًا بموجب الإطار التنظيمي لمؤسستك. يمكنك أيضًا تناول ضوابط التعويض or مخاطر النقل على سبيل المثال مع التأمين.

ومع ذلك، هناك ضوابط تعالج التهديد ويجب أخذها في الاعتبار إذا لم تكن راضيًا عن قبول المخاطر. يرجى القراءة.

ما الذي يعمل ضد الهجمات باستخدام المكونات الضارة؟

التعامل مع النسخة الصلبة

يعد تثبيت الإصدار من خلال تحسينات الإصدار الخاضعة للرقابة والمستنيرة هو الحل الأمثل لتحقيق التوازن بين الحاجة إلى إزالة الثغرات الأمنية دون تلقي برامج ضارة. لكن تذكر المفهوم الخاطئ رقم 3: تثبيت الإصدار وحده لا يكفي لحظر التعليمات البرمجية الضارة القادمة من الإصدارات الجديدة، لأنك ستحتاج في المستقبل إلى تحديث الإصدارات في أي تبعية مباشرة أو غير مباشرة. في تلك اللحظة تحتاج إلى دليل قوي بما فيه الكفاية على أن جميع الإصدارات المعدلة لا تحتوي على برامج ضارة.

الإنذار المبكر

أحد الأساليب المتبعة لحل مشكلة المكونات الضارة هو نظام الإنذار المبكر (المسمى هنا باسم الإنذار المبكر بالبرامج الضارة أو MEW)، حيث يتم تحليل الإصدارات الجديدة المنشورة (للمكونات الجديدة أو الموجودة) بواسطة محرك الكشف، والذي عند العثور على أدلة كافية قد يصنف الإصدار الجديد على أنه يحتمل أن يكون ضارًا. 

تعد الأتمتة أمرًا ضروريًا هنا، حيث أنه من المستحيل مراجعة جميع المكونات الجديدة يدويًا بمعدل النشر الحالي. لذلك يحتاج محرك الكشف إلى الجمع بين مجموعة متنوعة من التقنيات، ربما بما في ذلك التحليل الثابت والديناميكي وتحليل القدرة وسمعة المستخدم والأدلة القادمة من التناقضات بين البيانات التعريفية للمكون ومحتويات كرة القطران، أو بين كرة القطران ومستودع المصدر حيث يُفترض أن المكون يأتي من.

هناك المنطقة المظلمة بين وقت النشر ووقت قيام المحرك بتحليل محتويات المكون، على ألا يتجاوز ذلك بضع دقائق. يمكن تعديل النظام، على سبيل المثال، من خلال انتظار تحليل المكونات الجديدة قبل السماح بتثبيتها واستخدامها في بناء البرنامج pipelineق، أو تحليلها عند الطلب عند الحاجة. أحد المكونات في إصدار معين غير قابل للتغيير [3]لذلك يجب تحليلها مرة واحدة فقط.