قدّم مورّد برمجيات للرعاية الصحية أحدث تقرير لاختبار الاختراق لديه دليلًا على نضج اختباراته الأمنية. وأظهر التقرير عدم وجود نتائج حرجة ونتيجتين متوسطتي الخطورة، تتعلق كلتاهما بتهيئة TLS على نقطة نهاية في بيئة التجهيز. وعرض فريق الأمن لدى المورّد ذلك دليلًا على أن بيئته قد اختُبرت وثبت أنها آمنة. لكن المراجعة الدقيقة لقسم النطاق في التقرير روت قصة مختلفة. فقد أُجري الاختبار بمنهجية الصندوق الأسود الخارجية، أي محاكاة مهاجم خارجي غير مصادَق عليه، على تطبيق الويب العام فقط. وتضمنت استثناءات النطاق: الشبكة المؤسسية الداخلية، وجميع خوادم قواعد البيانات، وجميع نقاط نهاية API التي تتطلب مصادقة، والبنية التحتية السحابية في AWS التي تستضيف بيانات العملاء، وبيئة التطوير، وأنظمة الوصول الإداري الخاصة بالمورّد. وقد قيّم الاختبار الذي استغرق يومين صفحة تسجيل الدخول، والأجزاء غير المصادَق عليها من API، وبوابة الوثائق العامة. أما البيئات الأكثر صلة بمخاطر العميل، أي API المصادَق عليها حيث تُعالَج البيانات الصحية للعملاء، والبنية التحتية في AWS حيث تُخزَّن، والأنظمة الإدارية التي يصل عبرها موظفو المورّد إليها، فكانت جميعها خارج النطاق. وصف التقرير النظيف محيطًا خارجيًا نظيفًا. ولم تُختبر البيئة الداخلية ولا البنية التحتية السحابية.
ما مشكلة عمق اختبار الضوابط حقًا؟
عمق اختبار الضوابط هو مدى اختبار الأمن للضوابط والأنظمة ومسارات الهجوم الأكثر صلة بنموذج التهديد الفعلي، بدلًا من الضوابط والأنظمة ومسارات الهجوم الأيسر اختبارًا ضمن ميزانية وجدول زمني محددين. وللعمق بُعدان: عمق النطاق، ويشير إلى عدد الأنظمة والبيئات ذات الصلة المدرجة في الاختبار، وعمق التقنيات، ويشير إلى مدى شمولية اختبار الأنظمة المدرجة باستخدام التقنيات التي يستخدمها المهاجمون الفعليون.
محدودية النطاق هي أشد مشكلات عمق الاختبار أثرًا. فاختبارات الاختراق ذات النطاق الضيق، الخارجية فقط أو لتطبيق الويب فقط أو للمسارات غير المصادَق عليها فقط، تنتج نتائج تعكس بدقة أمن النطاق المختبَر بينما لا توفر أي ضمان بشأن الأنظمة غير المختبَرة. وسطح الهجوم الذي يعطيه المهاجمون المتمرسون الأولوية، أي نقاط نهاية API المصادَق عليها، وتهيئة البنية التحتية السحابية، ومسارات الحركة الجانبية الداخلية، وأنظمة الوصول الإداري، كثيرًا ما يكون هو الأنظمة المستبعدة من نطاق اختبار الاختراق لاحتواء التكلفة والتعقيد. والاختبار النظيف لنطاق ضيق ليس دليلًا على بيئة آمنة؛ بل دليل على أن الجزء المختبَر من البيئة لا توجد فيه مشكلات مكتشفة.
مشكلة محدودية التقنيات هي البُعد الثانوي للعمق. فحتى ضمن نطاق محدد، يحدد عمق الاختبار ما يستطيع الاختبار اكتشافه. فالفحص المؤتمت للثغرات يكتشف الثغرات المسجّلة المعروفة وأخطاء التهيئة الشائعة. أما اختبار الاختراق اليدوي الذي يجريه مختبِر متمرس فيمكنه العثور على ثغرات المنطق، وطرق تجاوز المصادقة، ومسارات تصعيد الصلاحيات التي تفوّتها الأدوات المؤتمتة. وثغرات منطق الأعمال، أي فجوات التفويض التي تتيح لعميل الوصول إلى بيانات عميل آخر عبر استدعاءات API تبدو مشروعة، تتطلب فهمًا خاصًا بالتطبيق لا تستطيع الأدوات المؤتمتة توفيره. والاختبارات التي تعتمد أساسًا على الفحص المؤتمت ضمن نطاق محدود ستجد الثغرات التي تكتشفها الأدوات المؤتمتة. وستفوّت فئات الهجوم التي تتطلب خبرة بشرية ومعرفة خاصة بالتطبيق.
- نطاق مقتصر على المحيط الخارجي: استبعاد الشبكة الداخلية والبنية التحتية السحابية والمسارات المصادَق عليها
- عدم اختبار API المصادَق عليها: استبعاد البيئة التي تكون فيها بيانات العملاء أيسر وصولًا من النطاق
- استبعاد البنية التحتية السحابية: عدم تقييم بيئة AWS أو Azure أو GCP التي توجد فيها البيانات
- اختبار الصندوق الأسود فقط: لا اختبار مصادَق عليه ولا اختبار صندوق أبيض للأنظمة الداخلية
- فحص مؤتمت دون اختبار يدوي: عمق تقنيات غير كافٍ لاكتشاف الثغرات المعقدة
لماذا يهم هذا
يكتسب عمق اختبار الضوابط أهمية في TPRM لأن تقارير اختبار الاختراق من أكثر عناصر الأدلة طلبًا وأثقلها وزنًا في تقييمات أمن المورّدين. والنتيجة النظيفة لاختبار اختراق يغطي نطاقًا ضيقًا تعطي إشارة إيجابية قوية في التقييم بينما لا توفر أي ضمان بشأن الأنظمة الأكثر صلة بمخاطر العميل. والعميل الذي يعتمد على تقرير الاختبار لفهم الوضع الأمني للمورّد يعتمد على أدلة حُدِّد نطاقها عمدًا بعيدًا عن الأنظمة الأعلى خطورة.
تكتسب فجوة اختبار API المصادَق عليها أهمية خاصة للمورّدين الذين يعالجون بيانات العملاء عبر واجهات برمجة التطبيقات. فمعظم علاقات معالجة البيانات الحديثة تنطوي على استدعاءات API مصادَق عليها، إذ يستدعي نظام العميل API الخاصة بالمورّد ببيانات اعتماد للمصادقة، فيعالج نظام المورّد الطلب ويعيد البيانات. وضوابط المصادقة والتفويض على نقاط نهاية API هذه هي التي تحدد ما إذا كان العميل (ب) يستطيع الوصول إلى بيانات العميل (أ)، وما إذا كان بإمكان بيانات اعتماد عميل مخترَقة الوصول إلى بيانات أكثر مما هو مقصود، وما إذا كانت ضوابط الوصول إلى البيانات لدى المورّد تعمل كما صُممت. واختبار السطح الخارجي غير المصادَق عليه مع استبعاد نقاط نهاية API المصادَق عليها يصف اختبارًا قيّم القفل على الباب الأمامي ولم يختبر الغرفة التي تُحفظ فيها بيانات العميل.
أين تخطئ معظم الفرق
الإخفاق الأكثر تكرارًا هو مراجعة تقارير اختبار الاختراق من حيث خطورة النتائج دون مراجعة تغطية النطاق. فالتقرير الخالي من النتائج الحرجة في نطاق ضيق يوفر ضمانًا أقل من تقرير ذي نتائج متوسطة في نطاق شامل. النطاق يحدد ما استطاع الاختبار العثور عليه. وخطورة النتائج تصف ما عثر عليه فعلًا ضمن النطاق.
- مراجعة خطورة النتائج دون مراجعة تغطية النطاق
- عدم تقييم استثناءات النطاق: عدم مراجعة قسم النطاق بحثًا عن أنظمة مستبعدة ذات صلة
- عدم تأكيد تغطية API المصادَق عليها
- عدم التحقق من نطاق البنية التحتية السحابية
- عدم تقييم تقنية الاختبار: مؤتمت مقابل يدوي مقابل خاص بالتطبيق
كيف تبدو الممارسة الجيدة
تحدد برامج حوكمة اختبار الاختراق الناضجة متطلبات نطاق تغطي الأنظمة الأكثر صلة بمخاطر العميل، أي بيئات API المصادَق عليها، والبنية التحتية السحابية، ومسارات الحركة الجانبية الداخلية، وتشترط تقنيات اختبار ملائمة لفئات الثغرات المشمولة بالنطاق.
- متطلبات نطاق متوائمة مع نموذج التهديد: إدراج API المصادَق عليها والبنية التحتية السحابية والمسارات الداخلية
- اشتراط الاختبار المصادَق عليه: اختبار الأنظمة التي تتطلب مصادقة، لا المحيط العام فقط
- البنية التحتية السحابية ضمن النطاق: إدراج تقييم تهيئة AWS أو Azure أو GCP
- اشتراط الاختبار اليدوي للأنظمة الحرجة: اختبار منطق الأعمال وتجاوز التفويض على يد مختبِرين متمرسين
- مراجعة تغطية النطاق قبل قبول تقرير الاختبار: التحقق من أن الأنظمة ذات الصلة ضمن النطاق
الأدوات
معايير اختبار الاختراق: PTES، ودليل الاختبار الصادر عن OWASP، وNIST SP 800-115
تحدد معايير منهجيات اختبار الاختراق نطاق الاختبار الشامل وتقنياته. ويتناول دليل الاختبار الصادر عن OWASP تحديدًا اختبار المصادقة والتفويض لتطبيقات الويب وواجهات برمجة التطبيقات، أي عمق التقنيات اللازم لاكتشاف الثغرات التي يفوّتها الفحص السطحي. وبالنسبة لممارسي TPRM، فإن اشتراط أن تتبع اختبارات الاختراق لدى المورّدين منهجية OWASP أو PTES يوفّر خط أساس لعمق التقنيات.
اختبار أمن السحابة: AWS Inspector، وتقييمات Azure Security Center، واختبار اختراق السحابة من طرف ثالث
تغطي التقييمات الأمنية الخاصة بالسحابة سطح هجوم التهيئة الذي تستبعده اختبارات الاختراق التقليدية عادةً، مثل أخطاء تهيئة IAM، وسياسات الوصول إلى التخزين، وإعدادات مجموعات أمن الشبكة، وثغرات المصادقة الأصلية في السحابة. وبالنسبة لممارسي TPRM، فإن اشتراط إجراء تقييمات للبنية التحتية السحابية لدى المورّدين إضافةً إلى اختبار اختراق التطبيقات يوفّر سؤالًا محددًا عن تغطية السحابة.
تحديات الحوكمة
يتمثل تحدي الحوكمة في عمق اختبار الضوابط في المفاضلة بين التكلفة والنطاق. فاختبار الاختراق الشامل الذي يغطي واجهات برمجة التطبيقات المصادَق عليها والبنية التحتية السحابية والشبكات الداخلية وتقنيات اختبار متعددة يكلّف أكثر بكثير من اختبار صندوق أسود خارجي لمدة يومين. والمورّدون الذين يتحكمون في نطاق اختباراتهم سيلجؤون افتراضيًا إلى الحد الأدنى من النطاق الذي يستوفي المتطلب التعاقدي بإجراء اختبار اختراق سنوي. والعملاء الذين يريدون نطاقًا أوسع يحتاجون إلى تحديده، إما في المتطلبات التعاقدية أو في طلبات الأدلة التي تتضمن أسئلة عن تغطية النطاق.
- راجع قسم النطاق قبل خطورة النتائج في أي تقرير لاختبار الاختراق
- اسأل تحديدًا عما إذا كانت نقاط نهاية API المصادَق عليها قد اختُبرت
- اسأل عما إذا كانت البنية التحتية السحابية ضمن النطاق
- اشترط تغطية نطاق تشمل الأنظمة الأكثر صلة ببيانات العملاء
- ميّز منهجية الاختبار: الفحص المؤتمت مقابل الاختبار اليدوي مقابل الاختبار الخاص بالتطبيق
إذا كنت فريقًا صغيرًا
بالنسبة لأحدث تقرير لاختبار الاختراق لدى مورّدك الأعلى خطورة، اقرأ قسم النطاق قبل قراءة النتائج. واسرد الأنظمة والبيئات المدرجة صراحةً والمستبعدة صراحةً. ثم اسأل: هل البيئة التي تُعالَج فيها بيانات مؤسستي وتُخزَّن ضمن النطاق المدرج؟ إذا كانت الإجابة لا أو غير واضحة، فإن نتائج الاختبار، أيًا كانت خطورتها، لا تصف أمن الأنظمة التي تهمك أكثر من غيرها.
- اقرأ قسم النطاق قبل النتائج في أي تقرير لاختبار اختراق لدى المورّد
- تأكد من أن بيئات API المصادَق عليها ضمن النطاق
- تأكد من أن البنية التحتية السحابية ضمن النطاق
- اسأل عن منهجية الاختبار: مؤتمتة أم يدوية
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«بالنسبة لأحدث اختبار اختراق لديكم، هل اقتصر النطاق على الأنظمة المواجهة للخارج، أم شمل نقاط نهاية API المصادَق عليها، وتهيئة البنية التحتية السحابية، ومسارات الشبكة الداخلية؟ وتحديدًا، هل كانت الأنظمة التي تعالج بيانات مؤسستنا وتخزّنها ضمن نطاق الاختبار؟»
ما تتوقعه دليلًا
- توثيق نطاق اختبار الاختراق بما في ذلك الأنظمة داخل النطاق وخارجه
- تأكيد أن بيئات API المصادَق عليها ضمن النطاق
- تأكيد تقييم البنية التحتية السحابية
- وصف منهجية الاختبار: المكوّنات المؤتمتة واليدوية
ينبغي أن يُسأل المورّد الذي يقدّم تقريرًا نظيفًا لاختبار الاختراق تحديدًا عما إذا كانت الأنظمة التي تتعامل مع بيانات العميل ضمن نطاق الاختبار. فالتقرير يصف ما عُثر عليه في الأنظمة المختبَرة. والنطاق يحدد أي الأنظمة اختُبرت.
كيف تُثبت ذلك
- تقييم تغطية النطاق في تقارير اختبار الاختراق لدى المورّدين
- تأكيد اختبار API المصادَق عليها والبنية التحتية السحابية
- سجلات تقييم المنهجية
- متطلبات النطاق في عقود المورّدين
الخلاصة الرئيسية
غياب النتائج الحرجة في نطاق ضيق لا يعني غياب الثغرات الحرجة في البيئة. فلم يعثر اختبار الاختراق على شيء حرج لأن API المصادَق عليها حيث تُعالَج بيانات العملاء، والبنية التحتية في AWS حيث تُخزَّن، والشبكة الداخلية، والأنظمة الإدارية، كانت جميعها خارج النطاق. كان الاختبار نظيفًا. والأنظمة ذات الصلة لم تُختبر. ضمان اختبار الاختراق محدود بنطاقه. وقراءة قسم النطاق قبل قسم النتائج تبيّن ما يستطيع الاختبار إخبارك به عن الوضع الأمني للمورّد. أما قراءة النتائج وحدها فتخبرك بما عُثر عليه في الأنظمة التي اختار المورّد إخضاعها للاختبار.