تقييم الثغرات مقابل اختبار الاختراق

كثيراً ما تُسعَّر خدمتان تحت اسمٍ واحد، وهذا الالتباس يكلّف المال في الاتجاهين معاً: فرقٌ تشتري اختبار اختراق وهي تحتاج إلى تقييمٍ واسع، أو تشتري فحصاً وهي تحتاج إلى من يخترق النظام فعلاً. والتمييز بينهما ليس نظرياً. فهو يحدّد السعر، والجدول الزمني، وما يمكن للتقرير أن يدّعيه، وما سيقبله المدقّق.

النسخة في جملةٍ واحدة

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

ويُجيب اختبار الاختراق عن السؤال: هل يستطيع مهاجمٌ ذو دافعٍ أن يحقّق هدفاً محدّداً ضدّ هذا الهدف، وكيف؟ وهو ضيّقٌ، يقوم على فرضية، ويؤدّيه شخصٌ، ويُنتج أثراً مُبرهَناً عليه — سلسلةً، لا قائمة.

كيف يختلف العمل فعلاً

أهمّ صفٍّ هو الاستغلال. فالتقييم يؤكّد وجود نقطة ضعف؛ والاختبار يُثبت إلى ماذا تؤدّي. فترويسةٌ أمنية غائبة وخللٌ في التفويض على مستوى الكائن يظهران كلاهما في التقييم بوصفهما نتيجتين. والاختبار وحده يُظهِر أنّ الثانية تكشف سجلّات كلّ العملاء، وهذه هي الجملة التي يحتاجها مجلس الإدارة.

نقطة ضعفٍ واحدة، تقريران

خذوا خلل التفويض على مستوى الكائن ذاك، هذه المرّة في واجهة برمجة التطبيقات (API) لمتجرٍ إلكتروني، وانظروا كيف تُبلِغ عنه كلّ خدمة.

التقييم، بعد أن أشارت الأداة إلى نقطة النهاية وأكّدها شخص:

[High] Object-level authorisation not enforced (verified manually)
Endpoint:  GET /api/v1/orders/{id}   host: api.shop.example
Evidence:  order 10453 belongs to customer B; customer A's session got 200
Fix:       check on the server that the order belongs to the caller

واختبار الاختراق، بهدفٍ مُتّفَقٍ عليه سلفاً («قراءة بيانات عميلٍ آخر دون حسابه») وبحجم عيّنةٍ تسمح به قواعد الاشتباك:

Goal     read another customer's personal data without their account
Step 1   signed in as test customer A; order ids are sequential
Step 2   GET /api/v1/orders/10453 with A's session -> 200, customer B's order
Step 3   each order carries the customer's name, address and phone number
Step 4   50 consecutive ids in the agreed sample -> 50 different customers
Impact   any signed-in customer can read every customer's contact details
Cause    the API checks that a session exists, not who owns the order

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

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

ما الغرض من كلٍّ منهما

اطلبوا تقييماً حين تحتاجون إلى التغطية: نظرةٌ أولى على مجموعة أصول، أو متطلّب امتثالٍ بالفحص الدوري، أو تحقّقٌ بعد دورة ترقيع، أو خطُّ أساسٍ قبل برنامجٍ أكبر. إنّه الأداة المناسبة لـ«لا نعرف ماذا نملك» ولـ«أثبِتوا أنّنا رقّعنا».

اطلبوا اختبار اختراقٍ حين تحتاجون إلى تأكيدٍ بشأن أمرٍ محدّد: تطبيقٌ جديد موجَّهٌ إلى العملاء قبل إطلاقه، أو مسار دفعٍ أو هوية، أو شبكةٌ داخلية بعد عملية اندماج، أو نظامٌ يتعامل مع بياناتٍ خاضعة للتنظيم، أو ادّعاءٌ توشكون أن تقدّموه لعميلٍ أو جهةٍ تنظيمية. إنّه الأداة المناسبة لـ«هل يستطيع أحدٌ الدخول من هنا» ولـ«ماذا سيحصّل».

اطلبوا الاثنين معاً، بالتتابع، حين لم يُنظَر في مجموعة الأصول قطّ. قيّموا أولاً لإصلاح الواضح وتقليل الضجيج؛ ثم اختبروا ثانياً حتى يذهب وقت المُختبِر إلى المنطق والسلاسل، لا إلى خدماتٍ غير مُرقَّعة كانت أداة فحصٍ ستُدرجها بجزءٍ يسير من التكلفة.

ثلاثة أخطاء نراها في الشراء

١. شراء اختبار وتسلّم فحص. إذا كان العرض بلا مُختبِرٍ مُسمّى، وبلا قواعد اشتباك، وبلا بند استغلال، وبسعرٍ ثابتٍ لكلّ مضيف، فهو تقييم. وقد يكون ذلك كافياً — لكن ادفعوا له سعر التقييم. ٢. شراء فحصٍ وتسميته اختباراً. أطر الامتثال التي تشترط «اختبار اختراق» تقصد الاستغلال اليدوي. وتقريرُ أداة فحصٍ بغلافٍ جديد لن ينجو من تدقيقٍ كفؤ. ٣. الاختبار قبل التقييم. مُختبِر اختراقٍ يمضي الأسبوع الأول على رُقَعٍ غائبة إنّما يُجري تقييماً بأسعار الاختبار.

كيف تقرؤون السعر

يُسعَّر التقييم بحسب الاتّساع: عدد المضيفين وعناوين IP والتطبيقات. ويُسعَّر اختبار الاختراق بحسب الوقت: أيام عملٍ لشخصٍ مُسمّى على هدفٍ محدّد. فإن كان عرضُ «اختبار اختراق» مُسعَّراً لكلّ مضيف، أو كان عرضُ «تقييم» مُسعَّراً باليوم وبهدفٍ واحد، فإنّ المورّد يصف الخدمة الأخرى. اطلبوا منه تصحيح التسمية، ثم قارنوا المِثل بالمِثل.

قاعدةٌ لهذا الربع

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