كيف نجري اختبار الاختراق — كيف ندير العملية على موقعنا المباشر دون انقطاع؟

القاعدة الأهم لمنع الانقطاع هي تحديد معدل سرعة الطلبات (rate limit) لأدوات الفحص. أعطِ فريق الاختبار قاعدة بألا يرسلوا أكثر من 5 إلى 10 طلبات في الثانية. اشترط عليهم أن تكون محاولات الحقن الجماعية، خاصة على نقاط محرك البحث التي تُجري فلترة ثقيلة في قاعدة البيانات، يدوية ومحكومة.

البنود التي يجب أن تتضمنها المواصفات قبل الاختبار: 1) لن تُنفَّذ هجمات DoS/DDoS والقوة الغاشمة على النظام المباشر، 2) لا يمكن حذف أو تعديل بيانات في قاعدة البيانات المباشرة، 3) ستُجرى الاختبارات فقط بين الساعة 01:00 و06:00، 4) عند اكتشاف ثغرة حرجة سيُبلَّغ فورًا دون انتظار تاريخ التقرير.

في اختبار الاختراق الأول لدينا، أثناء قيام خبير الاختبار بمحاولات آلية على نموذج التسجيل، تفعّلت خدمة تأكيد SMS لدينا. أُرسل 14,000 رسالة تحقق في ثلاث ساعات وقفل المشغل خطنا بسبب الاشتباه في البريد المزعج. قبل بدء الاختبار ضعوا خدمات الإشعارات الخارجية والرسائل والدفع في الوضع الوهمي إلزاميًا.

هل يطلب عميلك اختبار اختراق معتمدًا من TSE أم يكفي تقرير شركة حاصلة على شهادات دولية (مثل CREST وOSCP)؟ هذا التمييز يغيّر تمامًا الشركات التي ستطلب منها عروضًا وكذلك الميزانية التي ستدفعها.

أجرينا اختبار صندوق رمادي لمنصتنا B2B ذات الحجم المشابه. استغرقت عملية الاختبار 5 أيام عمل إجمالًا. ظهرت في النظام ثغرتان حرجتان و4 متوسطة. لأن النطاق الزمني الصحيح اختير، لم يتجاوز استخدام المعالج CPU نسبة 40% ولم نشهد أي انقطاع.

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

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

ملاحظة: سُئل هذا أدناه، وكتبت الإجابة في الرسالة الثانية.

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

هناك شيء يجب الانتباه إليه. الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

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

أتمنى أن يفيدك هذا.

أتابع الموضوع.

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

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

مثبت بالتجربة.

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

دعني أتركها كملاحظة، قد تكون مفيدة.

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

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

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

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

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

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

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.