ويتزايد باستمرار معدل الكشف عن نقاط الضعف الجديدة. ويصل حاليًا إلى متوسط 15,000 مواجهة للتطرف العنيف سنويًا. يبرز عام 2022 مع الإبلاغ عن أكثر من 26,000 مواجهة جديدة للتطرف العنيف. من الواضح أنه ليست كل نقاط الضعف ذات صلة ببرنامجك. لمعرفة ما إذا كانت ثغرة أمنية معينة تمثل مشكلة، تحتاج أولاً إلى معرفة ما إذا كنت تستخدم المكتبة أو المنتج الذي يحتوي على الثغرة الأمنية، ثم معرفة ما إذا كنت تستخدم الإصدار والوحدة النمطية التي بها مشكلات من تلك المكتبة. أخيرًا، تحتاج إلى استشارة فريق التطوير الخاص بك لمعرفة ما إذا كانت هذه الثغرة الأمنية ذات صلة بمنتجك المحدد والطريقة التي استخدمت بها تلك المكتبة أو المنتج الضعيف.
إن عملية اكتشاف كل هذا ليست بسيطة ويمكن أن تستغرق الكثير من الوقت. ويقدر توم ألريش، خبير الأمن السيبراني المعروف، ذلك حوالي 95% من جميع التهديدات والتطرف العنيف الموجودة في منتج برمجي معين غير قابلة للاستغلال. ولكن، إذا كنت مستخدمًا نهائيًا أو شركة على وشك دمج برامج الطرف الثالث في نظامها، فكيف يمكنك تحديد نسبة الـ 5% المسببة للمشكلة بحيث يمكنك طلب العلاج أو التصحيح المناسب؟
ومن هنا جاءت فكرة يأتي تبادل استغلال الثغرات الأمنية (VEX).. الغرض من VEX، كما هو محدد بواسطة توجيه من الإدارة الوطنية الأمريكية للاتصالات والمعلومات (NTIA) في عام 2021، هو "تزويد المستخدمين (على سبيل المثال، المشغلين والمطورين ومقدمي الخدمات) بمعلومات إضافية حول ما إذا كان المنتج متأثرًا بثغرة أمنية معينة في مكون مضمن، وإذا تأثر وما إذا كانت هناك إجراءات موصى بها لعلاجها."
ربما تفكر الآن - فكيف يمكنني الحصول على مستندات VEX هذه والبدء في التحقق من مكوناتي؟ حسنًا، واقع استخدام VEX معقد كالعادة.
اكتشف الغرض من VEX
ببساطة، من المفترض أن يجيب VEX بسرعة وسهولة على السؤال "هل يمكن استغلال الإصدار الخاص بي من هذا البرنامج في هذا؟" وهن؟'.
من المفترض أن تكون الإجابة على هذا السؤال أحد الخيارات الأربعة الرئيسية:
- لم تتأثر: لا يوجد علاج مطلوب فيما يتعلق بهذه الثغرة الأمنية.
- متأثر: يوصى باتخاذ إجراءات لمعالجة هذه الثغرة الأمنية أو معالجتها.
- ثابت: تحتوي إصدارات المنتج هذه على إصلاح للثغرة الأمنية.
- قيد التحقيق: ولم يُعرف بعد ما إذا كانت إصدارات المنتجات هذه قد تأثرت بالثغرة الأمنية. سيتم توفير التحديث في إصدار لاحق.
نظرًا لأنه من المفترض أن يكون VEX قابلاً للقراءة آليًا ويتم إنشاؤه آليًا، فإن الفكرة تتمثل في الحصول على قاعدة بيانات قابلة للبحث عن هذه المستندات في مكان ما حتى يتمكن أي طرف مهتم من الاستعلام عنها والحصول على الإجابة المطلوبة.
نظرًا لأن الافتراض هو أن 95% من الثغرات الأمنية غير قابلة للاستغلال في أي منتج برمجي معين، فإن هذا النظام يهدف إلى تقليص القوائم الضخمة من الثغرات الأمنية الموجودة لكل منتج إلى تلك التي يجب على المستخدم مراقبتها أو طلب علاجها أو تصحيحها فقط. ل.
هناك عدد من الحقائق المثيرة للاهتمام حول تاريخ VEX
مرة أخرى في عام 2020، NTIA (الإدارة الوطنية الأمريكية للاتصالات والمعلومات) بدأ مناقشة فكرة VEX كأداة مصاحبة لـ سبوم (قائمة المواد البرمجية). في سبتمبر 2021، أصدرت NTIA مقدمة من صفحة واحدة وشرحًا لما يفترض أن يفعله VEX.
وفي وقت لاحق، تحركت الجهود المبذولة لتحسين متطلبات الشكل الاستشاري الجديد تحت رعاية CISA - وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية، التي أصدرت تقريرها الخاص وثيقة في أوائل عام 2022، سنتناول المزيد من التفاصيل بالإضافة إلى بعض حالات الاستخدام التي كان من المفترض أن يساعد مستند VEX فيها. حددت الوثيقة، وهي مسودة، الحد الأدنى من الحقول المطلوبة لمستند VEX بنفس الطريقة التي حددت بها NTIA الحد الأدنى من الحقول المطلوبة لـ SBOM.
منذ ذلك الحين كانت هناك محاولتان رئيسيتان لإنشاء تنسيق وثائق VEX يمكن قراءته آليًا:
- إنّ الإطار الاستشاري الأمني المشترك (CSAF) كان التنسيق الأول المتاح. تم إصدار هذا التنسيق في نهاية عام 2022 بواسطة OASIS Open، وهي منظمة دولية غير ربحية مخصصة لإنتاج معايير مفتوحة المصدر للأمن السيبراني، و blockchain، وإنترنت الأشياء، ومجالات أخرى.
- إعصار دي إكس, تنسيق موحد لـ SBOMs تم إطلاقه بواسطة OWASP (مشروع أمان تطبيقات الويب المفتوحة)، والذي تم تكييفه لإنشاء مستندات VEX أيضًا.
يعد CSAF تنسيقًا شاملاً ولكن من أجل استخدامه فعليًا بنجاح، تحتاج إلى تضمين حقول متعددة والكثير من المعلومات الوصفية مما يجعل الاعتماد الفعلي غير محتمل. تعد مبادرة CyclonDX VEX أقل حجمًا بكثير، لذا عند التفكير في معيار VEX الذي سيتم استخدامه على الأرجح بصيغة CyclonDX.
لماذا وصل VEX إلى طريق مسدود - الكشف عن المشكلات التي تخرب نجاحه
تعد VEX فكرة جيدة ويمكن أن توفر قدرة قيمة على التحقق بسرعة مما إذا كانت ثغرة أمنية معينة قابلة للاستغلال في منتج برمجي معين.
ولكن هناك العديد من المشاكل التي تعيق تنفيذه حتى الآن:
- مسؤولية التقديم - من يجب أن يكون مسؤولاً عن تقديم مستندات VEX المطلوبة؟ هل هم منتجي البرمجيات؟ شركات أمنية تابعة لجهة خارجية أو منظمات غير ربحية؟ جهة حكومية؟ ماذا سيحدث إذا قدمت مصادر متعددة معلومات متناقضة؟
- قاعدة بيانات VEX - من أو ما الذي يجب عليه حفظ معلومات VEX وتصنيفها؟ على افتراض أن بعض المستندات ستصف المشكلات القابلة للاستغلال في البرامج، ألا يوجد خطر من وقوع المعلومات في الأيدي الخطأ (الخبيثة)؟
- لا تغطي التنسيقات الحالية بشكل صحيح مسألة الإصدارات، بل وأقل من ذلك مشكلة الإصدارات المدمجة.
تشير إصدارات البرامج/الحزم المدمجة إلى ممارسة تجميع حزم البرامج أو المكونات المتعددة معًا في إصدار واحد أو حزمة تثبيت واحدة.
عندما يتعلق الأمر بتصحيح الثغرات الأمنية، يمكن أن تساعد إصدارات البرامج/الحزمة المدمجة في العملية وتعرقلها. فمن ناحية، يمكن أن يؤدي وجود حزمة تثبيت واحدة تتضمن جميع المكونات الضرورية إلى تبسيط عملية تحديد الثغرات الأمنية وتصحيحها. بدلاً من الحاجة إلى تحديد كل مكون على حدة وتصحيحه يدويًا، يمكنك ببساطة تطبيق التصحيح على الحزمة بأكملها.
ومع ذلك، فإن الجانب الآخر من ذلك هو أنه إذا كان أحد مكونات الحزمة عرضة للخطر، فإن البرنامج بأكمله يكون عرضة للخطر. وهذا يعني أنه حتى لو تم تصحيح بعض المكونات الموجودة داخل الحزمة، فقد تظل الحزمة بأكملها معرضة للخطر في حالة وجود مكون واحد غير مُصحح.
لنفترض أن الإصدار 1 من المكتبة "أ" في برنامجك به ثغرة أمنية. تظهر هذه المشكلة فقط عندما تكون المكتبة "أ" موجودة مع الإصدار 2 من المكتبة "ب". يوجد تصحيح أمني ولكن لم يكن من الممكن أن يقوم الجميع بتثبيته. وهذا يعني أن مستند VEX الخاص بهذه الثغرة الأمنية في برنامجك يحتاج إلى تغطية جميع المجموعات الممكنة للمنتج وإصداراته والمكتبات المضمنة به وإصداراتها والتصحيحات المحتملة التي تم إصدارها. هذه معلومات كثيرة معقدة ليس من السهل التعبير عنها ببساطة.
- كيف يمكن لـ VEX تغطية البرامج المضمنة في الأجهزة مع توفر جميع الإصدارات والتصحيحات الممكنة هناك؟ على من تقع مسؤولية تصحيح هذا البرنامج مع الأخذ في الاعتبار أنه لا يمكنك بسهولة فتح الجهاز وتصحيح الأشياء بنفسك؟
هذه ليست سوى بعض المشكلات التي تحتاج أي أداة تلقائية للتعامل مع VEX إلى فهمها وأخذها في الاعتبار.
ألن يكون الأمر أسهل إذا كان بإمكانك طلب المعلومات والحصول عليها لأي إصدار؟
من المحتمل أن يكون الافتراض بأن أفضل طريقة لمشاركة هذه المعلومات المهمة من خلال مستند هو افتراض خاطئ. يعد إنتاج ما يكفي من مستندات VEX لتغطية كل مجموعة من الإصدارات والتصحيحات والثغرات الأمنية مهمة بالغة الأهمية، ومن المفهوم أنه لا أحد يرغب في القيام بها.
كاتب قامت ببناء منصة لتتبع ومشاركة المعلومات المتعلقة بالأمان لكل إصدار لمشروع أو منتج برمجي معين. وكجزء من ذلك، يقوم كل إصدار بإنشاء SBOM دقيق وقائمة بالثغرات الأمنية التي تم اكتشافها في المنتج.
يمكّن Scribe منتج البرنامج من إضافة نصائح بتنسيق VEX إلى كل من هذه الثغرات الأمنية لملاحظة ما إذا كانت غير قابلة للاستغلال، أو قيد التحقيق، وما إلى ذلك. بمجرد إصدار إصدار، يمكن مشاركة جميع المعلومات الأمنية المتعلقة بهذا الإصدار مع أطراف ثالثة مهتمة، والمستخدمين والمنظمين، وما إلى ذلك. إن تضمين قائمة الثغرات الأمنية بالإضافة إلى قائمة VEX الاستشارية يعني أن المستلم يجب أن يكون قادرًا على النظر فقط إلى نقاط الضعف التي تمثل مشكلة محتملة في هذا المنتج المحدد. إنه يأخذ الكثير من العبء على عاتق كل من منتج البرامج الذي يمكنه "القائمة البيضاء" لمنتجه ومستهلك البرنامج الذي يفهم بالضبط مستوى المخاطرة التي ينطوي عليها منتج برنامج معين.
نظرًا لأن منتج البرامج هو الشخص الوحيد الذي يمكنه أن يقول بشكل قاطع ما إذا كانت ثغرة أمنية معينة ذات صلة بإصدار معين من المنتج، فهو الوحيد الذي يمكنه إضافة وتعديل النصائح المتعلقة بمنتجاته الخاصة. إن حكم منتج البرمجيات في هذا الصدد نهائي وغير قابل للطعن. إن القرار بشأن من سيتم مشاركة هذه المعلومات معه هو من صلاحيات منتج البرامج أيضًا.
نظرًا لأنه يتم حفظ التاريخ الكامل لإصدارات المنتج وSBOMs ومعلومات الأمان بواسطة Scribe، يمكن للمستخدمين بسهولة طلب هذه المعلومات والحصول عليها لأي إصدار قد يستخدمونه طوال دورة حياة البرنامج بأكملها.
وفي الختام
تذكر أن أي فحص لائق لمنتج برمجي هذه الأيام من شأنه أن ينتج مئات إن لم يكن الآلاف من نقاط الضعف المحتملة. معظم الناس لا يستطيعون التعامل مع مثل هذا الرقم. يبدأ إرهاق التنبيه ويصبح عدد نقاط الضعف مجرد رقم.
إن إمكانية تقليل عدد المشكلات المكتشفة إلى قدر يمكن التحكم فيه ستكون بمثابة نعمة لمنتجي البرامج ومستخدميها. الهدف هو التركيز فقط على المشكلات الحقيقية حتى يتمكن منتج البرنامج من تصحيحها ومعالجتها في أسرع وقت ممكن.
الأدوات الآلية، مثل كاتب تقدم طريقة سهلة لرؤية فقط نقاط الضعف ذات الصلة بكل مشروع من مشاريعك وتصميماتك، والمعلومات التي يمكنك مشاركتها بسهولة، مما يجعل جبل الثغرات الأمنية أصغر بكثير وأكثر قابلية للإدارة.
ومع ذلك، هناك تحذير مهم وهو أن هذا المستقبل، حيث يمكننا بسهولة رؤية نقاط الضعف ذات الصلة والاستجابة لها فقط، لن يكون ممكنًا بدون المشاركة النشطة لمجتمع المصادر المفتوحة. تتكون معظم الأكواد البرمجية هذه الأيام من كميات كبيرة من البرامج مفتوحة المصدر، لذا نحتاج إلى القائمين على صيانة هذه المكتبات ومطوريها للمشاركة في اكتشاف ومعالجة الثغرات القابلة للاستغلال التي تعاني منها أكوادهم البرمجية.
إن مشكلة الثغرات الأمنية ذات الصلة والقابلة للاستغلال لن تختفي، لذا يتعين علينا جميعًا أن نجد الطريقة الأكثر كفاءة وفعالية من حيث التكلفة للحصول على إجابة السؤال: "هل نسختي من هذا البرنامج قابلة للاستغلال لهذا الغرض؟" وهن'.
يتم تقديم هذا المحتوى إليك بواسطة Scribe Security، وهي شركة رائدة في مجال توفير حلول أمان سلسلة توريد البرامج الشاملة - حيث توفر أحدث الأمان لعناصر التعليمات البرمجية وعمليات تطوير التعليمات البرمجية وتسليمها عبر سلاسل توريد البرامج. تعرف على المزيد.
الوظائف ذات الصلة
