لدينا أنظمة SCADA في خط الإنتاج — هل اختبار الاختراق ضروري، وما فرقه عن الاختبار العادي؟

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

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

بنود أمنية يجب إضافتها لدفتر الشروط: 1) منع اختبارات حجب الخدمة (DoS) أثناء الإنتاج منعاً باتاً، 2) أخذ نسخ احتياطية فيزيائية لجميع برمجيات PLC وSCADA قبل البدء، 3) حصر عمليات الفحص في فترات الصيانة المتفق عليها، 4) الاكتفاء بمراقبة حركة المرور عبر أدوات الرصد السلبي (Passive Monitoring) في الأيام الأولى.

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

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

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

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

هل سيرفرات الـ SCADA وشبكة الإنتاج عندكم مفصولة حاليًا بتمديدات كابلات مادية عن شبكة المكاتب، ولا بس معزولة بطبقة شبكة افتراضية (VLAN)؟ وهل الأجهزة اللي بخط الإنتاج إلها صلاحية وصول مباشر للإنترنت؟

ملاحظة: كتبت هذا بناءً على تجربتي الشخصية، قد لا ينطبق على الجميع.

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

صححوا لي إن أخطأت.

ملخص سريع للجدد: وقت اكتشاف المشكلة يحدد تكلفتها بشكل مباشر.

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

أكثر نقطة يتم إغفالها في موضوع اختبار اختراق scada هي: إذا لم يكن الإذن والنطاق مكتوبين، فلا تبدأوا الاختبار.

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

موضوع في الوقت المناسب تمامًا.

سمعنا هذا كثيراً، لكنه لم يحدث معنا أبداً. فعل الجميع لشيء ما لا يعني أنه صحيح.

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

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

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

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

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

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

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

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

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

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