ما الذي يجب أن يتضمّنه تقرير اختبار الاختراق

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

هذا هو الهيكل الذي نلتزم به في تقاريرنا، والذي نقترح أن تُدرجوه في طلب تقديم العروض القادم لديكم.

يقرأ التقريرَ الواحد ثلاثةُ قرّاء، ويبدأ كلٌّ منهم من موضعٍ مختلف:

١. النطاق كما اختُبِر فعلاً، لا كما خُطِّط له

ينبغي أن تذكر الصفحة الأولى بدقّة ما كان ضمن النطاق وما جرى تنفيذه فعلاً: أسماء المضيفين، ونطاقات عناوين IP، وإصدارات التطبيقات، وأدوار المستخدمين، والبيئات (الإنتاج، والتجهيز، ونسخة مطابقة)، والتواريخ. وإذا كان نظامٌ ما ضمن النطاق لكن تعذّر اختباره — لأنّ نقطة نهاية كانت متوقّفة، أو لم تصل بيانات الاعتماد قطّ، أو حجب WAF المُختبِر ولم يُعدَّل — فيجب أن يذكر التقرير ذلك. وإلّا كانت «النتيجة النظيفة» لذلك النظام طمأنينةً زائفة.

اطلبوا: قائمة الأصول المُختبَرة مع تاريخ التعامل مع كلٍّ منها، وقائمة الاستثناءات مع أسبابها.

٢. المنهجية والمعيار

سمّوا المنهجية والتزموا بها. فلتطبيقات الويب تكون عادةً دليل OWASP لاختبار أمن الويب (WSTG)، مع معيار التحقّق من أمن التطبيقات (ASVS) لمزيدٍ من العمق؛ ولواجهات API، قائمة OWASP API Security Top 10 والفصول نفسها من ASVS؛ وللبنية التحتية، منهجية PTES أو مراحل NIST 800-115. والقيمة ليست في الاختصار بحدّ ذاته، بل في أنّ قائمة تحقّقٍ مُسمّاة تتيح للقارئ أن يرى ما لم يُكتشَف، لا ما اكتُشِف فقط.

وجدولٌ قصير يربط أقسام المعيار بـ«مُختبَر / غير منطبق / خارج النطاق» هو أكثر صفحةٍ فائدةً تفتقر إليها كثيرٌ من التقارير.

وهذه هي تلك الصفحة لتطبيق ويب، مربوطةً بفئات WSTG الاثنتي عشرة. المهمّة متخيَّلة، وسنتابعها نفسها حتى آخر المقال.

والصفوف التي تقول «لم يُعثَر على شيء» لا تقلّ قيمةً عن الصفوف التي فيها نتائج: فهي ما يُخبر المدقّق بأنّ المجال قد فُحِص فعلاً.

٣. ملخّص تنفيذيّ يستطيع المدير أن يتصرّف بناءً عليه

صفحة واحدة. ما الذي اختُبِر، والمخاطرة الإجمالية في جملةٍ واحدة، وعدد النتائج بحسب الخطورة، والأمران أو الأمور الثلاثة التي يجب أن تحدث هذا الربع. بلا لقطات شاشة، وبلا payloads. فإذا توقّف القارئ هنا، فينبغي أن يعرف هل عليه أن يقلق ومَن يتّصل به.

٤. النتائج، كلٌّ في صفحة، وبقالبٍ ثابت

تحتاج كلّ نتيجة إلى الحقول نفسها وبالترتيب نفسه، حتى يمكن فرز مئة نتيجة وترتيب أولوياتها في فترة بعد ظهرٍ واحدة:

نتيجةٌ نموذجية

إليكم نتيجةً واحدة بهذا القالب، من المهمّة المتخيَّلة نفسها على واجهة API لمتجر:

GET /api/v2/orders/100482 HTTP/1.1
Host: shop.example
Authorization: Bearer eyJ… (test customer A, customer_id 5531)

HTTP/1.1 200 OK
Content-Type: application/json

{"order_id": 100482, "customer_id": 5537, "name": "[redacted]",
 "address": "[redacted]", "items": 3, "total": 1840000}

ملاحظة: احجبوا البيانات الشخصية في الأدلّة، لكن لا تحجبوا أبداً الجزء الذي يُثبت النتيجة. هنا أُخفي الاسم والعنوان وبقي customer_id: فالرقم ٥٥٣٧ ليس رقم المُرسِل ٥٥٣١، وهذا الفرق هو النتيجة نفسها.

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

٥. السلاسل والأثر على العمل

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

مثالٌ من المهمّة نفسها. بدأ المُختبِر بحساب عميلٍ عادي:

النتيجة F-03 وحدها منخفضة (درجة CVSS v4: ٢٫٣): رابط الإحالة الذي يشاركه العميل يحمل معرّفه الداخلي. والنتيجة F-05 وحدها متوسّطة (٦٫٠): نقطة النهاية التي تغيّر بريد العميل تقبل معرّف أيّ عميل، لكنّ المعرّفات لا يمكن تخمينها. ومعاً، يغذّي المعرّفُ المكشوف تغييرَ البريد، ثمّ تذهب إعادة تعيين كلمة المرور إلى عنوان المهاجم، فيُستولى على الحساب: ٨٫٥، مرتفعة، حين تُقيَّم السلسلة كلّها. لم تكن درجة أيٍّ من النتيجتين وحدها لتبلغ الملخّص التنفيذي؛ أمّا السلسلة فتبلغه.

٦. ما جُرِّب ولم يُفلِح

المُختبِر الذي أمضى يوماً على مسار المصادقة ولم يجد شيئاً قد أنتج دليلاً. ومكانه في التقرير قسمٌ قصير من النتائج السلبية: أيّ فئات الهجمات جُرِّبت على أيّ مكوّنات. ودونه لا يستطيع العميل أن يميّز «الآمن» من «ما لم يُنظَر فيه».

٧. شروط إعادة الاختبار

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

وفي المهمّة المتخيَّلة، تبدو صفحة إعادة الاختبار هكذا:

٨. ملاحق توفّر الوقت

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

الأسئلة التي ينبغي طرحها قبل التوقيع

١. هل سيذكر التقرير ما تعذّر اختباره، ولماذا؟ ٢. إلى أيّ معيار ستُربَط التغطية، وهل سأرى ذلك الربط؟ ٣. هل تحمل كلّ نتيجة خطورةً مُقيَّمة مع متّجهها، وسبباً جذرياً، وخطوات إعادة إنتاج؟ ٤. هل توجد إعادة اختبار، وكيف يُبلَّغ عن الحالات؟ ٥. هل سأتسلّم النتائج بصيغةٍ يستطيع نظام التتبّع لديّ استيرادها؟

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