فحص الثغرات أم اختبار الاختراق؟ ماذا تشتري، ومتى، وكيف تقرأ التقرير

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

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

ثلاث خدمات تُباع تحت اسم واحد

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

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

الفحص الآلي: الطبقة الرخيصة التي يجب أن تعمل دائمًا

فحص الثغرات لا يحتاج خبيرًا لكل جولة، وقيمته في انتظامه لا في عمقه. شرطه الأول ليس الأداة بل الجرد: لا يمكنك فحص ما لا تعرف بوجوده. معظم الاختراقات التي نراها لدى الشركات الصغيرة والمتوسطة لا تأتي من الموقع الرئيسي، بل من نطاق فرعي نُسي، أو خادم تجريبي بقي يعمل بعد انتهاء المشروع، أو لوحة تحكم قاعدة بيانات فُتحت للإنترنت «مؤقتًا». ابدأ بقائمة بكل عنوان IP ونطاق وتطبيق تملكه، وراجعها كل شهر مقابل سجلات DNS وفواتير الاستضافة.

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

اختبار الاختراق: إنسان يربط نقاط الضعف ببعضها

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

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

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

النطاق هو العقد الحقيقي

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

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

كيف تميّز اختبارًا حقيقيًا من فحص بشعار جديد؟

الإشارات واضحة لمن يعرف أين ينظر. إذا لم يسألك المزوّد في عرضه عن أدوار المستخدمين في تطبيقك أو عدد الواجهات البرمجية أو طبيعة البيانات الحساسة، فهو لا يخطط لاختبار منطق التطبيق. وإذا كانت المدة يومًا أو يومين لتطبيق متوسط الحجم، فلا وقت إلا لتشغيل أداة. اطلب نموذج تقرير منقّحًا من عمل سابق قبل التعاقد، وابحث فيه عن ثلاثة أشياء: سرد للهجوم يشرح كيف انتقل المختبر من نقطة إلى أخرى، ودليل استغلال لكل نتيجة مهمة (طلب واستجابة، لقطة شاشة، خطوات إعادة إنتاج) لا مجرد «قد يكون عرضة لـ»، ومنهجية معلنة مثل دليل OWASP لاختبار أمن الويب أو معيار PTES. واسأل من سيجري الاختبار فعلًا وما خبرته، لا عن شهادات الشركة فقط.

درجة الخطورة ليست ترتيب الأولوية

أغلب التقارير ترتّب النتائج بحسب درجة CVSS، وهي درجة تقيس خطورة الثغرة بشكل عام، لا خطورتها في بيئتك أنت. ثغرة «عالية» على خادم داخلي تجريبي لا يحمل بيانات ولا يصل إليه أحد من الخارج قد تنتظر، بينما ثغرة «متوسطة» تتيح لأي عميل مسجّل تنزيل فواتير جميع العملاء الآخرين يجب أن تُصلح اليوم. أعد ترتيب النتائج بثلاثة أسئلة: هل هي مكشوفة للإنترنت أو لمستخدمين غير موثوقين؟ ما البيانات أو العمليات التي تصل إليها؟ وهل تُستغل فعلًا في العالم الآن؟ للسؤال الأخير مصادر مجانية مفيدة، مثل قائمة الثغرات المستغلة المعروفة التي تنشرها وكالة CISA الأمريكية، ونظام EPSS الذي يقدّر احتمال استغلال الثغرة خلال الشهر القادم.

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

الإصلاح وإعادة الاختبار

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

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

إيقاع سنوي لشركة متوسطة

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

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