هل يجب أن نجري اختبار اختراق، ومتى وفي أي نطاق؟

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

أولاً، إذن كتابي قبل الاختبار. المساس بنظام خارج النطاق يخلق مشاكل تقنية وقانونية. يجب أن تكون نافذة الاختبار، وقناة الاتصال، وإجراء الإيقاف الطارئ مكتوبة.

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

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

اقتراح من فريق المراقبة: أثناء الاختبار، قوموا أيضاً بقدراتكم على الاكتشاف.

هل لاحظ نظام مراقبتكم محاولة المخترق الدخول للنظام؟ كم استغرق من الوقت؟ ومن تلقى التنبيه؟ هذه المعلومة أحياناً أثمن من قائمة الثغرات في التقرير.

طريقة عملية: اطلبوا من المخترق قائمة مؤرخة زمنياً بالإجراءات التي قام بها. ثم قارنوها بسجلاتكم (logs). ستعرفون بالضبط أي خطوة لم تروها.

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

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

اقتراحي هو إضافة بنود السرية ومعالجة البيانات بشكل منفصل في العقد المبرم مع مزود الاختبار، واستخدام بيانات مقنّعة (masked) قدر الإمكان. يجب أيضاً تحديد مدة الاحتفاظ بالتقرير وطريقة إتلافه كتابياً.

سؤال: كم يوم عمل (man-days) مكتوب في العرض الذي يقول "اختبار شامل"؟

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

شكراً، سأجعل هذا الموضوع ملحقاً لعرض الميزانية الخاص بي.

عندما سألت عن عدد أيام العمل، عدّل اثنان من العروض الثلاثة، ولم يرد أحدهم. جدول المقارنة أصبح الآن قابلاً للمقارنة حقاً.

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

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

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

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

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

لم أكن أعلم بهذا. فعل الجميع لشيء ما لا يعني أنه صحيح.

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

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

بالتوفيق.

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

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

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

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

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

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

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

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

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

المسألة ليست الرقم، بل الأساس الذي بُني عليه. مثبت بالتجربة.

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

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

إذا دخلنا في التفاصيل: أكثر ما أهدر وقتنا كان عدم وضوح من يتخذ القرار.

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

إذا دخلنا في التفاصيل: الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

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

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