يقضي فريقٌ كامل وقته في معالجة ثغرة أمنية مصنفة ضمن معيار CVSS 9.8، والتي عُثر عليها مدفونة في مكتبة لا يستخدمها أي نظام إنتاجي. في المقابل، تبقى ثغرة أخرى مصنفة ضمن معيار CVSS 6.5، موجودة في نقطة نهاية متصلة بالإنترنت، دون معالجة لمدة شهر آخر، لأنها لم تصل إلى أعلى قائمة الأولويات. هذه ليست حالة افتراضية، بل هي النتيجة الحتمية لتحديد أولويات الثغرات الأمنية بناءً على درجة خطورتها فقط، وهو فشل شائع أكثر مما تعترف به معظم برامج الأمن السيبراني.
ما الذي يفترض أن تحققه عملية تحديد أولويات الثغرات الأمنية فعلياً
تُعدّ عملية تحديد أولويات الثغرات الأمنية عمليةً لتحديد أيّ الثغرات يجب إصلاحها أولاً، من قائمةٍ غالباً ما تكون طويلةً جداً بحيث يصعب حصرها بالكامل. وعند تطبيقها بشكلٍ صحيح، فإنها تُجيب على سؤالٍ أضيق وأصعب من سؤال "ما مدى خطورة هذه الثغرة نظرياً؟"، إذ تُجيب على سؤال "إلى أيّ مدى يُقلّل إصلاح هذه الثغرة، الآن، من المخاطر التي تُهدّد هذا النظام تحديداً؟". هذان سؤالان مختلفان، والخلط بينهما هو سبب فشل معظم جهود تحديد أولويات الثغرات الأمنية.
لماذا تفشل درجة الخطورة وحدها؟
لم يُصمم نظام CVSS ليكون نظامًا كاملاً لتحديد الأولويات بمفرده، بل هو مجرد مؤشر لخطورة الثغرة الأمنية، ووصف لمدى خطورتها نظريًا في سياق عام. ولا يُشير إلى أي شيء آخر.
- إمكانية الوصول. سواء تم استدعاء مسار التعليمات البرمجية المعرض للخطر فعليًا في أي مكان في التطبيق، أو بقي معطلاً في تبعية لا يتم استدعاؤها.
- قابلية الاستغلال. سواء كان هناك استغلال عملي موجود في الواقع، أو أن الثغرة الأمنية نظرية خارج بيئة المختبر.
- مكشف. سواء كان المكون المتأثر يواجه الإنترنت أو يقع على بعد ثلاث طبقات خلف خدمة داخلية بدون وصول خارجي.
- السياق التجاري. سواء كان النظام المتأثر يتعامل مع بيانات العملاء أو عمليات الدفع، أو كان أداة داخلية منخفضة القيمة لا يعتمد عليها أحد.
إنّ منهجية تحديد أولويات الثغرات الأمنية التي تعتمد فقط على نظام CVSS تُعامل ثغرة من فئة 9.8 في كود غير قابل للوصول على أنها أكثر إلحاحًا من ثغرة من فئة 6.5 في مسار قابل للوصول إليه عبر الإنترنت مع وجود ثغرة معروفة للاستغلال. هذا الترتيب معكوس، وهو نتيجة مباشرة لتقييم شدة الثغرة مع تجاهل جميع العوامل الأخرى التي تحدد المخاطر الفعلية.
التكلفة الخفية لخطأ تحديد أولويات الثغرات الأمنية
لا تقتصر التكلفة على ساعات العمل الهندسية الضائعة فحسب، مع أن هذا واقعٌ لا يُنكر: إذ تُهدر الفرق جهودها باستمرار على اكتشافات بالغة الخطورة لا تُشكّل أي خطر عملي، بينما تبقى ثغرات قابلة للاستغلال دون حل. أما التكلفة الخفية فهي الثقة. فعندما يُستدعى المطورون مرارًا وتكرارًا من أعمالهم الأساسية لإصلاح ثغرات يتبين أنها غير قابلة للإصلاح أو أنها قد عُولجت بالفعل في مكان آخر، يبدأون في تجاهل التنبيه التالي أيضًا، ويتوقف الهدف الأساسي من تحديد أولويات الثغرات، وهو إصلاح الثغرات الصحيحة أولًا، دون أن يُلاحظ، حتى وإن كان العمل على القائمة يتم بالترتيب الصحيح.
ما الذي يتطلبه تحديد أولويات الثغرات الأمنية بشكل جيد؟
تعتمد عملية تحديد أولويات الثغرات الأمنية الفعالة على وضع عدة مؤشرات فوق مستوى الخطورة، بدلاً من استبدالها بشكل كامل:
- تحليل إمكانية الوصول. تأكد من أن الدالة المعرضة للخطر يتم استدعاؤها فعليًا من كود التطبيق، وليس فقط موجودة في شجرة التبعيات.
- استغلال التوافر. تحقق مما إذا كان هناك استغلال علني أو حملة نشطة تستهدف الثغرة الأمنية المحددة، وليس فقط عائلة CVE.
- إزالة البيانات المكررة عبر الماسحات الضوئية. لا ينبغي اعتبار نفس المشكلة الأساسية التي أبلغت عنها ثلاث أدوات مختلفة بمثابة ثلاثة بنود منفصلة تتنافس على الاهتمام.
- سياق العمل والتعرض. قم بترجيح النتائج بناءً على ما يلامسه الأصل المتأثر فعليًا، وليس فقط بناءً على النتيجة العامة لـ CVE.
- قمع مرئي، وليس قائمة مسطحة. إن القدرة على رؤية عدد النتائج التي تنجو من كل مرشح، بدءًا من كل مشكلة وصولاً إلى ما يمكن استغلاله فعليًا، تجعل عملية تحديد الأولويات قابلة للدفاع عنها بدلاً من كونها صندوقًا أسود.
تُعدّ هذه النقطة الأخيرة أكثر أهمية مما تبدو عليه. فالقائمة المسطحة المصنفة حسب درجة الخطورة لا تُعطي الفريق أي فكرة عن حجم المشكلة: هل 40% من قائمة المهام المتراكمة حقيقية، أم 2% فقط؟ أما عرضها على شكل قمع، بدءًا بجميع النتائج، ثم تلك القابلة للإصلاح، ثم تلك التي يمكن الوصول إليها، ثم تلك التي تحتوي على ثغرة معروفة، ثم تلك التي يمكن استغلالها فعليًا في هذه البيئة، فيُحوّل قائمةً ضخمةً إلى قائمة قصيرة ومُحكمة.
ما الذي يجب البحث عنه في أدوات تحديد أولويات الثغرات الأمنية
لا تقوم جميع المنصات التي تُسوَّق على أساس تحديد أولويات الثغرات الأمنية بالعمل المذكور أعلاه. عند تقييم أدوات تحديد أولويات الثغرات الأمنية، تُساعدك بعض الأسئلة على تجاوز التسويق بسرعة:
- هل يُظهر إمكانية الوصول، أم أنه يُبلغ فقط عن وجود حزمة بيانات معرضة للخطر؟
- هل يقوم هذا البرنامج بإزالة النتائج المكررة عبر الماسحات الضوئية، بما في ذلك أدوات الطرف الثالث المستخدمة بالفعل، أم أن كل مصدر يضيف قائمة منفصلة وغير مترابطة؟
- هل يمكن لمسؤول الأمن أن يرى مسار العملية، وعدد النتائج التي تم تصفيتها ولماذا، أم فقط القائمة النهائية "ذات الأولوية" دون أي رؤية للمنطق الكامن وراءها؟
- هل يأخذ ذلك في الاعتبار مدى توفر الثغرات الأمنية من معلومات التهديدات الحقيقية، أم فقط درجة CVSS الثابتة المنشورة عند الكشف؟
- هل ينطبق تحديد الأولويات بالتساوي على النتائج المستخلصة من الماسحات الضوئية الأصلية والنتائج المستخلصة من أدوات الطرف الثالث، أم فقط على نتائج البائع نفسه؟
هذا السؤال الأخير أكثر أهمية مما يبدو. فالعديد من أدوات تحديد أولويات الثغرات الأمنية لا تعطي الأولوية إلا لما وجدته بنفسها، تاركةً كل ما يتم استيراده من مصادر أخرى. SAST, SCAأو الماسحات الضوئية التابعة لجهات خارجية والموجودة في كومة منفصلة وغير مصنفة.
كيف تتعامل شركة Xygeni مع تحديد أولويات الثغرات الأمنية
زيجيني ASPM تُطبّق هذه العملية مسارًا من أربع مراحل: استيعاب النتائج من الماسحات الضوئية الأصلية وأدوات الطرف الثالث على حد سواء، وبناء رؤية موحدة للمخزون الناتج، ثم ربطها وتحديد أولوياتها باستخدام إزالة التكرارات، وإمكانية الوصول، والسياق المدعوم بالذكاء الاصطناعي، قبل أن تصل النتائج إلى قائمة انتظار المطورين. عمليًا، يُضيّق هذا المسار قائمة النتائج الكاملة من خلال تحديد ما يمكن إصلاحه، وما يمكن الوصول إليه في كود التطبيق، وما توجد به ثغرة معروفة، وأخيرًا ما يمكن استغلاله فعليًا في تلك البيئة المحددة، بحيث تكون القائمة التي يعمل عليها الفريق صغيرة بما يكفي لمعالجتها بالكامل، وليس مجرد فرزها إلى ما لا نهاية.
لأن طبقة تحديد أولويات الثغرات الأمنية هذه تنطبق على النتائج التي يتم جمعها من الماسحات الضوئية التابعة لجهات خارجية بالإضافة إلى الماسحات الضوئية الأصلية الخاصة بشركة Xygeniليس على الفريق أن يقوم بتمزيق أداة موجودة للحصول على رؤية موحدة ومترابطة. يعتمد منطق تحديد الأولويات على ما هو موجود بالفعل، مما يسد الفجوة التي تتركها معظم أدوات تحديد أولويات الثغرات الأمنية مفتوحة عندما تكتفي بترتيب نتائجها الخاصة.
الأسئلة الشائعة
لماذا لا يكفي نظام CVSS وحده لتحديد أولويات الثغرات الأمنية؟
يقيس نظام CVSS الخطورة النظرية، وليس المخاطر الفعلية في بيئة محددة. فهو لا يأخذ في الحسبان إمكانية الوصول إلى الكود المُعرّض للخطر، أو وجود ثغرة أمنية مُستغلة، أو مدى انكشاف النظام المُتأثر، وكلها عوامل تُؤثر بشكل جوهري على ما إذا كان ينبغي إصلاح الثغرة أولاً.
ما الفرق بين الخطورة وقابلية الاستغلال في تحديد أولويات الثغرات الأمنية؟
تُشير درجة الخطورة إلى مدى الضرر الذي قد تُسببه الثغرة الأمنية نظريًا. أما قابلية الاستغلال فتُشير إلى ما إذا كان هذا الضرر قابلًا للتنفيذ فعليًا في الوقت الحالي، في ظل وجود ثغرة فعّالة ومسار برمجي متاح. غالبًا ما تكون الثغرة ذات الخطورة العالية وقابلية الاستغلال المنخفضة أقل إلحاحًا من الثغرة ذات الخطورة المتوسطة وقابلية الاستغلال العالية.
هل تحتاج أدوات تحديد أولويات الثغرات الأمنية إلى تغطية نتائج الماسحات الضوئية التابعة لجهات خارجية أيضًا؟
نعم، وإلا سينتهي الأمر بالفريق إلى عدة قوائم أولويات منفصلة وغير مترابطة، واحدة لكل أداة، بدلاً من رؤية موحدة لما يهم بالفعل عبر المجموعة بأكملها.
إلى أي مدى يمكن لتحليل إمكانية الوصول أن يقلل بشكل واقعي من قائمة النتائج؟
يختلف الأمر باختلاف قاعدة التعليمات البرمجية، ولكن من الشائع أن توجد غالبية الثغرات الأمنية التي تم الإبلاغ عنها في مسارات التعليمات البرمجية التي لا يتم استدعاؤها فعليًا، مما يعني أن إمكانية الوصول وحدها غالبًا ما تستبعد نسبة كبيرة من النتائج من الاعتبار الجاد قبل حتى تقييم إمكانية الاستغلال.
هل تُعدّ القائمة الأصغر ذات الأولوية علامة على تجاهل المخاطر؟
لا، بل العكس. إن قائمة أقصر ناتجة عن تحديد أولويات الثغرات الأمنية بدقة تعني تصفية المعلومات غير المهمة، وليس المخاطر الحقيقية. أما البديل، وهو قائمة طويلة غير مُفلترة لا يمكن لأحد مراجعتها بالكامل، فيؤدي إلى نتائج أسوأ لأن المخاطر الحقيقية تضيع وسط الكم الهائل من المعلومات.
