اختبار الاختراق يقول أصلحوا خلال 30 يومًا: هل مدد إغلاق الثغرات المعتادة واقعية؟

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

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

مدد إغلاق الثغرات المقبولة عمومًا في القطاع هي كالتالي: 1) الثغرات الحرجة خلال 7 إلى 14 يومًا كحد أقصى، 2) الثغرات عالية الخطورة خلال 30 يومًا كحد أقصى، 3) الثغرات متوسطة الخطورة خلال 60 إلى 90 يومًا، 4) الثغرات منخفضة الخطورة تُغلق خلال 180 يومًا أو في فترة صيانة مناسبة.

تعديل: صححت بعض الأخطاء الإملائية.

شركات الاختبار تمارس ضغط "يجب أن ينتهي كل شيء خلال 30 يومًا" حتى لا يتعطل جدولها وتغلق الملف بسرعة. لا يوجد عميل B2B يلغي العقد بسبب ثغرة متوسطة عندما تقدمون مبررًا منطقيًا، لا تكتبوا كودًا خاطئًا بدافع الذعر.

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

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

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

أغلقوا النقاط الحرجة الثلاث فورًا، وأرسلوا للعميل جدولاً زمنيًا لثلاثة أشهر لما تبقى.

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

شكرًا جزيلاً، سأجربها اليوم.

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

شكرًا جزيلاً، سأجربها اليوم. كل من يستعجل في مدد إغلاق الثغرات يتعثر في نفس النقطة.

إذا كانت قناة الإشعارات طويلة، فلن تصل الإشعارات؛ والإشعار غير الواصل يعني حدثًا يُكتشف متأخرًا. صححوا لي إن أخطأت.

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

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

لو كنت مكانك، لسلك هذا المسار.

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

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

تم الحفظ.

سمعنا هذا كثيراً، لكنه لم يحدث معنا أبداً. الحلول التي تنجح على نطاق صغير تنهار عند التوسع، تعلمت هذا متأخراً.

الإجراء المتخذ دون جرد المخزون يترك باباً لا تراه مفتوحاً.

أكتب هذا حتى لا تكرروا نفس الخطأ. إمكانية الوصول إلى النسخة الاحتياطية عبر نفس الشبكة ونفس الهوية تجعلها جزءًا من الهدف.

هذا كل شيء، أرجو المعذرة إذا أطالت.