اختبار الاختراق وجد 40 ثغرة — كيف ننظّم إصلاحها دون أن نغرق؟

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

مررنا بعملية مشابهة العام الماضي في تقرير فيه 38 نتيجة. ظنّ الفريق في البداية أنه لن يستطيع كتابة ميزات جديدة لأسابيع. عندما فحصنا وجدنا أن 14 من الـ38 ثغرة أُغلقت تلقائياً بمجرد تحديث تبعيتين قديمتين للحزم. تحديثات الحزم أذابت ثلث عبء العمل في 3 ساعات.

اسألوا شركة الاختبار فوراً عن مدة حق إعادة الاختبار (re-test) في العقد. عادةً ما تتضمن العقود فترة تحقق مجانية للإصلاحات مدتها 30 أو 45 يوماً. إن لم تغلقوا الحرجة والعالية وتحصلوا على تقرير الموافقة قبل انتهاء تلك المدة، ستضطرون لدفع رسوم إضافية للشركة.

قاعدة سعة السبرنت للحفاظ على سير العمل: 1) خصصوا ثلاثين بالمئة من السبرنت القادم للثغرات الحرجة فقط. 2) في السبعين بالمئة المتبقية من السعة واصلوا أعمالكم الأساسية الملتزمين بها تجاه العملاء. 3) انقلوا الثغرات منخفضة الأولوية إلى مجموعة الدين التقني وعالجوها في الدورات اللاحقة.

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

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

هل أعطاكم عميلكم المؤسسي مدة رسمية محددة في العقد للإصلاح (SLA)؟ مثلاً 14 يوم للثغرات الحرجة و30 يوم للعالية، إذا ما فيه بند ملزم من هذا النوع، تقدروا تمددوا الجدول الزمني بالكامل حسب سرعة تطويركم.

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

ملخص سريع للجدد: لا تعتمدوا على إجراء وقائي واحد؛ اتبعوا نهج الطبقات.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

عشنا تقريباً نفس التجربة العام الماضي. ابدأ بتجربة صغيرة، لا تربط كل شيء دفعة واحدة.

لا تعتمدوا على إجراء وقائي واحد؛ اتبعوا نهج الطبقات.

بالضبط، بل إن هذا الجانب غير معروف بشكل كافٍ. كل من يستعجل في عملية إصلاح الثغرات يتعثر في نفس النقطة.

مررت بهذا الطريق، دعني أشرح. إذا لم يكن الإذن والنطاق مكتوبين، فلا تبدأوا الاختبار.

إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

دعني أشارك تجربتي. معظم الحوادث لا تبدأ من ثغرة أمنية، بل من كلمة مرور مسربة.

لا أعتقد أن هذه النصيحة تناسب الجميع. تدوين الملاحظات لمدة أسبوعين يعطي نتائج أفضل من التخمين لمدة ستة أشهر.

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

لم أكن أعلم بهذا.

سأكون ممتنًا لو شاركت النتيجة.

أنا أيضًا متحمس لمعرفة ذلك.

سأجمع الموضوع، لأن هناك عدة إجابات مختلفة. على كل حال أكثر ما أهدر وقتنا كان عدم وضوح من يتخذ القرار.

لا يتم التحقق من تغييرات معلومات الدفع أبداً عبر القناة الواردة منها لكن يعني هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.