اليوم نشارك دليل الممارسين لدمج اثنتين من أهم أطر الأمن OT العالمية في برنامج يمكن أن يصمد بالفعل في الميدان.  

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

لماذا لدينا إطارين ولماذا نستخدمهما معاً؟

خطأ شائع ومفهوم هو اختيار إطار واحد وبناء برنامج حوله حصرياً. غالباً ما يسأل مدراء البرامج: هل معيار IEC 62443 كافٍ بمفرده؟ هل يكفي معيار NIST SP 800-82 وحده؟ الإجابة على كلا السؤالين هي: ليس تماماً، وهذا هو السبب.

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

NIST SP 800-82 مع مراجعته الثالثة الأخيرة (المنشورة في سبتمبر 2023)، هو في الأساس وثيقة توجيهية. إنه وصفي بدلاً من كونه إلزامياً ويخبرك بما يجب أن تأخذه بعين الاعتبار وكيف تفكر في أمان ICS/OT. يرسم خارطة لإطار عمل الأمن السيبراني NIST (CSF 2.0)، مقدماً مستويات التنفيذ، البروفايلات، وتصنيف شامل للتهديدات والضعف والهيكليات OT.

02 فهم كل إطار بعمق

IEC 62443: سلسلة المعايير التي تحتاج إلى معرفتها جيداً

IEC 62443 ليس معياراً واحداً — بل هو عائلة من المعايير منظمة في أربع سلاسل. الممارسون الذين يعاملونها كوثيقة واحدة يرتكبون أخطاء حرجة في التنفيذ. إليك ما تغطيه كل سلسلة ولماذا هي مهمة عملياً:

نموذج مستوى الأمان (SL) هو المساهمة المميزة لـ IEC 62443. لا تعتبر SL1 حتى SL4 مجرد تصنيفات للخطورة — بل تحدد القدرة التي يجب أن تتحملها ضوابطك ضد المهاجمين:

NIST SP 800-82 Rev.3: ما الذي تغير ولماذا يهم

المراجعة الثالثة، التي نشرت في سبتمبر 2023، هي تحديث كبير من المراجعة الثانية (2015). أهم التغييرات للممارسين:

• توافق كامل مع NIST CSF 2.0، بما في ذلك وظيفة الحكم الجديدة. هذا يرفع مستوى الحوكمة السيبرانية في OT إلى المستوى التنظيمي، وليس فقط المستوى الفني.

• تغطية موسعة لOT المتصلة بالسحابة، وIIoT، وهياكل الحوسبة الطرفية التي لم تتناولها المراجعة الثانية — وهو أمر حاسم لبيئات النفط والغاز الحديثة والتصنيع المتطور.

• تحديث مشهد التهديدات ليشمل البرمجيات الخبيثة الموجهة لـICS بعد 2015: TRITON/TRISIS (هجوم SIS)، INDUSTROYER2 (الشبكة الكهربائية)، PIPEDREAM/INCONTROLLER (إطار عمل هجوم ICS متعدد المنصات).

• تحديث هياكل المرجعية بتصميمات DMZ الحديثة، الدفاع على الطبقات لشبكات OT، وإرشادات حول تكامل OT SOC.

• خرائط متقابلة صريحة بين ضوابط SP 800-82 وIEC 62443، NERC CIP، وغيرها من أطر عمل OT — مما يمكن من محاذاة الامتثال بين الأطر المتعددة.

 03 الهندسة التكاملية: جعل كلا الإطارين يعملان معاً

العنصر الأساسي للنجاح في التكامل هو هذا: استخدم NIST SP 800-82 / CSF كأساس لإدارة البرامج، وIEC 62443 كمواصفات التنفيذ الفني. توفر وظائف CSF الستة (الحكم، التعريف، الحماية، الاكتشاف، الاستجابة، الاستعادة) الهيكل العمراني. يملأ IEC 62443 كل وظيفة بمحتوى هندسي خاص بـ OT.

 04 مخزون الأصول وتقييم المخاطر: الأساس الذي لا يمكن التفاوض عليه

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

الخطوة 1: اكتشاف أصول OT - قم بذلك بشكل صحيح

لا تقم قط بتشغيل أدوات الفحص النشط على الشبكات OT الحية. هذا ليس تفضيلاً. بل هو من المتطلبات الأمنية والتشغيليه. ترسل أدوات الفحص النشط النبضات التي يمكنها أن تغمر قدرة المعالجة المحدودة للـ PLCs القديمة، وتفسد الذاكرة على بعض RTUs القديمة، وتؤدي إلى سلوك غير متوقع في الأنظمة الحرجة للسلامة. حدث هذا في بيئات حقيقية. ينبه NIST SP 800-82 Rev.3 §6.2.1 بوضوح ضد الفحص النشط في البيئات ICS الحية دون تأكيد البائع.

النهج الصحيح هو الاكتشاف السلبي للأصول: قم بنشر تاب للشبكة السلبي أو منفذ SPAN على مفاتيح شبكة OT واستخدام أداة رؤية OT مدركة للبروتوكول لتحديد الأجهزة من المرور الملحوظ. يتيح لك هذا النهج، كما هو محدد في IEC 62443-3-2 §4.2، ببناء جرد أصول يتمكن من التقاط نوع الجهاز، البائع، الطراز، إصدار البرامج الثابتة، البروتوكولات المستخدمة، وأنماط الاتصالات — دون إرسال حزمة واحدة إلى شبكة OT.

الخطوة 2: تحديد المنطقة والقناة (IEC 62443-3-2 §4.3)

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

في سياق النفط والغاز، يبدو هيكل المنطقة النموذجي هكذا: طبقة السلامة (أنظمة SIS/ESD، SL3 كحد أدنى) تكون معزولة تماماً وتتواصل مع طبقة التحكم الأساسية في العمليات (DCS، عادة SL2) فقط عبر ثنائي البيانات في الاتجاه الخارج. طبقة التحكم الأساسية تتواصل مع الطبقة الإشرافية (SCADA/المؤرخ، SL2) من خلال قنوات جدار الحماية. الطبقة الإشرافية تتواصل مع الطبقة المؤسسية/IT من خلال DMZ المعزولة بشكل كامل مع التفتيش على مستوى التطبيقات. لا تحتوي أي منطقة على اتصال مباشر يتخطى أي طبقة. هذا ليس سحر هندسي — إنه كيف تمنع إنتشار رانسوموير على لابتوب مؤسسي يعمل Windows من الوصول إلى Rockwell ControlLogix.

الخطوة 3: تقييم المخاطر — الأولوية للتداعيات في OT

يحدد IEC 62443-3-2 منهجية تقييم المخاطر المحددة لـ IACS. الفرق الحرج عن تقييم المخاطر IT هو أن العواقب يجب أن تُقَيّم بمعايير عملياتية وسلامة، وليس فقط بمعايير مالية. قد يمثل خرق يكلف 50,000 دولار لمعالجة في سياق IT خطراً كارثياً في سياق OT إذا كان يتعلق بفقدان الاحتواء، التسريب البيئي، أو تعطيل وظيفة السلامة.

يتماشى NIST SP 800-82 Rev.3 مع هذا من خلال تحديد فئات تداعيات لـ ICS: السلامة (إصابة/وفاة الأفراد)، الإفراج البيئي، تأثير الإنتاج، وضرر المعدات. استخدم تعريفات العواقب من كلا الإطارين لبناء مصفوفة عواقب يمكن لفريق سلامة العمليات لديك التحقق منها — لأنهم خبراء في المعرفة بموضوع ما يعنيه تعديل نقطة إعداد DCS فعلياً لنزاهة العمليات.

05 ضوابط الحماية: حيث يقوم IEC 62443-3-3 FR1–FR7 بالعبء الأكبر

يحدد IEC 62443-3-3 سبعة متطلبات أساسية (FRs) و51 متطلباً للنظام تصف الإمكانيات الأمنية المحددة التي يجب على النظام إظهارها عند كل مستوى أمان. يتوافق NIST SP 800-82 Rev.3 مع فئات التحكم الخاصة به مع هذه المتطلبات الأساسية FRs. إليك كيفية تنفيذها عملياً:

FR1: التحكم في التعريف والمصادقة

يجب تعريف كل مستخدم وجهاز يصل إلى أنظمة OT ومصادقته. في الواقع، هذا يعني: القضاء على الحسابات المشتركة على أنظمة HMI وEWS؛ فرض بيانات اعتماد فريدة لكل مهندس، مشغل، وبائع؛ نشر المصادقة متعددة العوامل على جميع طرق الوصول عن بُعد. بالنسبة للمصادقة على الأجهزة على SL2+، استخدم المصادقة القائمة على الشهادات حيث تدعمها مكونات OT — يدعم OPC-UA المصادقة المتبادلة بناءً على الشهادات ويجب استخدامها كبديل لـ OPC-DA القديم مع مصادقة DCOM. في SL3 (أنظمة SIS)، يتطلب استخدام الرموز المادية أو ما يعادلها من المصادقة القوية لأي وصول إلى المحطات العمل الهندسية التي يمكنها تعديل منطق SIS.

FR2: استخدام التحكم

المصادقة ليست كافية — يجب فرض التفويض. قم بفصل الأدوار إلى: إقرأ فقط (المشغلون يراقبون العملية)، التحكم (المشغلون ينفذون الأوامر)، الهندسة (تعديل المنطق)، الإدارة (تكوين النظام)، والبائع (الوصول المحدود بالوقت والجلسة). الفشل الأكثر شيوعًا في FR2 في بيئات OT هو أن الجميع يستخدمون حساب المسؤول لأن لا أحد أخذ الوقت لبناء مصفوفة أدوار ملائمة. وهذا يعني أن المقاول الذي يحتاج للتحقق من قراءة التشخيص لديه وصول كامل للكتابة إلى تكوين DCS — وهي ميزة غير ضرورية وخطيرة.

فيما يتعلق بالوصول عن بُعد، فرض التفويض المستند إلى الجلسة: كل جلسة وصول للبائع أو للمهندس البعيد تتطلب موافقة صريحة من خلال سير عمل محدد، لها مدة جلسة قصوى، تجرى من خلال سيرفر قفز مع تسجيل الجلسة، وتنهى وتسجل. لا توجد أنفاق VPN دائمة إلى شبكات OT. لا استثناءات.

FR3 وFR4: سلامة البيانات وسريتها

البروتوكولات القديمة في OT — مثل Modbus TCP، وDNP3 (دون المصادقة الأمنية)، OPC-DA الكلاسيكية — صُممت من أجل الموثوقية، وليس الأمان. لا تحتوي على آليات سلامة أو سرية مدمجة. مما يعني أن مهاجمًا لديه وصول إلى الشبكة يمكنه قراءة جميع بيانات العملية، إدخال أوامر كاذبة، وإعادة تشغيل الأوامر الشرعية المستولى عليها. يعالج كلا NIST SP 800-82 Rev.3 §6.2.4 وIEC 62443-3-3 FR3/FR4 هذا الواقع بنفس الإرشادات العملية: حيث لا يمكنك استبدال البروتوكول، عوضه بعناصر التحكم في الشبكة (العزل الصارم للمنطقة، جدران حماية مدركة للتطبيق، اكتشاف الشذوذ)؛ وحيث يمكنك استبدال أو تقديم البروتوكول (OPC-UA، DNP3-SA، أنفاق IPsec)، افعل ذلك.

FR5: تدفق البيانات المقيد

هذا هو النموذج التطبيقي للمناطق والقنوات. يجب السماح بكل طريق اتصال بين المناطق بشكل صريح — وليس العكس. الوضع الافتراضي هو拒 القدوم. يجب أن تكون قوانين جدار الحماية بين مناطق OT محددة بقدر الإمكان: عنوان IP المصدر، عنوان IP الوجهة، المنفذ، والبروتوكول. أي "أي إلى أي" قاعدة في جدار حماية OT هي اكتشاف حرج. لأعلى مسارات العواقب (SIS إلى DCS، على سبيل المثال)، نفذ بوابات الأمان أحادية الاتجاه (ثنائيات البيانات) التي تمنع فعلياً أي حركة من التدفق في اتجاه الأمان العالي. لا يمكن برمجة جدران الحماية البرمجية فقط، بغض النظر عن مدى تكوينها بشكل جيد، بشكل خاطئ أو استغلالها — ثنائيات البيانات المادية لا يمكنها تمرير الحركة في الاتجاه الخاطئ بسبب الفيزياء.

FR6: الاستجابة الفورية للأحداث

لا يمكنك الاستجابة للأحداث التي لا تراها. هذا يتطلب مراقبة أمنية محددة لـ OT. ستولد أدوات SIEM IT بدون الفهم البروتوكولي لـ OT ضوضاء هائلة على الشبكات OT وستفوت المؤشرات الفعلية التي تهدد الأمان. التصميم المثالي هو منصة رؤية OT مضمونة في الوضع السلبي الذي يفهم بروتوكولات ICS، يغذي التنبيهات الموحدة إلى وظيفة المراقبة المركزية (OT SOC)، ويربط الأحداث عبر المناطق. يشمل NIST SP 800-82 Rev.3 §6.2.8 إرشادات تصميمية للمراقبة OT تتماشى مع متطلبات FR6 في IEC 62443.

FR7: توفر الموارد

يجب أن تظل أنظمة OT متاحة — عادةً بشكل أكثر ضرورة مما يجب أن تظل سرية. وهذا يعني أن المتانة والتكرار هما ضوابط أمان، وليس فقط اختيارات تصميم هندسية. لأنظمة OT الحاسمة، تحقق من: تكرار وحدة التحكم (وضع الاستعداد الساخن)، تكرار مسار الشبكة (HSR، PRP، أو RSTP مع فشل سريع)، تكرار الطاقة (UPS مع الدعم بالمولد)، وسلامة النسخ الاحتياطي للتكوين. بشكل حاسم، اختبر الاستعادة — النسخ الاحتياطي الذي لم يتم استعادته أبداً هو فرضية، وليس قدرة. يتطلب كل من NIST SP 800-82 Rev.3 §6.2.7 وIEC 62443-3-3 FR7 قدرة استرداد مجربة، وليس فقط إجراءات موثقة.

6 الاكتشاف، الاستجابة، واستعادة: إكمال الدورة

بناء قدرة اكتشاف OT

تغير مشهد التهديدات في OT بشكل جذري منذ عام 2017. أظهر هجوم TRITON/TRISIS أن المهاجمون المتقدمون يستهدفون أنظمة السلامة المحوسبة — خط الدفاع الأخير قبل أن يصبح العملية الفيزيائية خطرة. أظهر PIPEDREAM/INCONTROLLER، الذي أُعلن عنه في 2022، إطار عمل للهجوم المعياري قادر على استهداف منصات OT الرئيسية مثل Schneider Electric وOMRON باستخدام بروتوكولات ICS الأصلية. هذه التهديدات ليست نظرية — إنها قدرات موثقة في العالم الحقيقي تم نشرها ضد البنية التحتية الحيوية.

يتطلب الاكتشاف في هذا السياق قدرات محددة لـ OT يفتقر إليها أدوات الأمان IT. نظام اكتشاف التسلل على الشبكة الذي لا يفهم رموز الوظائف لـModbus، أو محتوى طبقة التطبيق لـDNP3، أو عمليات الخدمة لـOPC-UA لن يتمكن من اكتشاف تلاعب غير مشروع بالبروتوكول OT — لأن جميع حركة مرور OT تبدو مثل الضوضاء له. الفحص العميق للحزم الواعية للبروتوكول والمصممة خصيصاً لبيئات OT، ليس اختيارياً لبيئات SL2+.

الاستجابة للحوادث في OT: واجهة سلامة العمليات

أكثر جوانب الاستجابة للحوادث في OT التي تم التقليل من شأنها هي الواجهة بين حدث السيبراني وحدث سلامة العمليات. الهجوم السيبراني على DCS لا يظهر مثل حادثة أمان IT — قد يُظهر نفسه في البداية كانحرافات في العملية بدون تفسير، تفاوتات في وضع الصمام، أو قراءات أجهزة تبدو غير طبيعية. كان الهجوم TRITON قد لوحظ لأول مرة من قبل مهندس التحكم في العمليات الذي رأى تصرُّفات غير مألوفة لـ SIS، وليس من قبل محلل أمان.

لذلك يجب أن تتضمن خطة الاستجابة للحوادث OT الخاصة بك: محركات تصعيد صريحة لفريق الاستجابة لحالات الطوارئ الخاصة بـسلامة العمليات؛ أدوار معرفة لفريق PSSR (مراجعة السلامة قبل البدء) إذا كان يجب إعادة النظام OT إلى الخدمة بعد حادثة سيبرانية؛ وسلطة للعمليات لعزل النظام المحدود عن شبكة تحكم العمليات دون انتظار الموافقة من IT/الأمن السيبراني إذا كانت السلامة معرضة لخطر مباشر. يشمل كل من NIST SP 800-82 Rev.3 §6.2.9 وIEC 62443-2-1 §4.3.6 الاستجابة للحوادث، لكن لا يتناول أي منها بشكل كافٍ واجهة السلامة السيبرانية بالتفصيل — يجب على برنامجك أن يملأ هذه الفجوة باستخدام مدخلات HAZOP وتقييم الخطر الخاصة بالموقع.

الاستعادة: الوظيفة المنسية

تتطلب كل من IEC 62443-3-3 FR7 ووظيفة الاستعادة في NIST CSF قدرة استعادة موثوقة ومجربة. في سياقات OT، تكون الاستعادة أكثر تعقيداً بكثير من الاستعادة IT لأنها: قد تتطلب الأنظمة OT إجراءات استعادة خاصة بالبائع؛ يجب أن تتبع تنزيلات المنطق لـPLCs ووحدات تحكم DCS تسلسلات محددة؛ تتطلب إعادة التشغيل بعد انقطاع طويل اعتبار إجراءات السلامة العملية (التطهير، فحص الضغط، تحقق الآلات) التي قد تستغرق أياماً أو أسابيع؛ وقد تنطبق متطلبات التقارير التنظيمية على الحوادث السيبرانية التي تؤثر على أنظمة السلامة العملية.

حدد أهداف وقت الاستعادة (RTOs) لكل منطقة OT بناءً على التحمل العملياتي — وليس بناءً على معايير IT. قد يكون RTO الخاص بـ IT الذي يستمر لـ 24 ساعة لنظام غير حرج جيداً؛ أما RTO الخاص بـ OT الذي يستمر لـ 24 ساعة لنظام SCADA خط أنابيب يعني يوماً من التشغيل الأعمى لنظام نقل مضغوط، مما ليس مقبولاً. يجب أن يتم التحقق من هذه الأهداف RTO من قبل العمليات والهندسة العملية، وليس تم تحديدها من قبل IT.

07 خريطة تنفيذ: برنامج بناء واقعي على مدى 24 شهراً

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

الأشهر 1–3 · المرحلة 1: الأساس

تأسيس الحوكمة والرؤية الأساسية

قبل أي ضوابط تقنية، تحتاج إلى موافقة تنظيمية، تحديد أدوار، وصورة أصول حقيقية. بدون هذه، كل نشاط لاحق يكتنفه الرمال.

•  إعداد وتصديق سياسة الأمن السيبراني OT المتوافقة مع متطلبات CSMS لـ IEC 62443-2-1

•  تحديد أدوار أمان OT (قائد الأمن السيبراني OT، ممثلو أمان OT في الموقع، وظيفة الرقابة البائعية) ورسمها في الأوصاف الوظيفية أو الرصاصي

• نشر اكتشاف أصول OT السلبي عبر جميع المواقع — بناء سجل الأصول النهائي

• إجراء رسم الخرائط الأولي للمناطق والقنوات وفقًا لـIEC 62443-3-2 §4.3

• تأسيس نموذج سجل المخاطر الخاص بـ OT المتوافق مع كل من IEC 62443-3-2 وفئات التداعيات في NIST SP 800-82

• التقويم الحالي لمستوى الأمان المحقق (SL-A) ضد IEC 62443-3-3 FR1–FR7

الأشهر 3–6 · المرحلة 2: تقييم المخاطر

اكمال تقييم المخاطر وتحديد الدولة المستهدفة

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

•       اكمل تقييم المخاطر لـ IEC 62443-3-2 لجميع المناطق؛ تحديد SL-T لكل منطقة

•       حدد والحد من جميع فجوات SL (SL-T ناقص SL-A) — تصبح هذه خلفية تحسين الترميم

•       إجراء نمذجة تهديدات متوافقة مع NIST SP 800-82 Rev.3 تتضمن تهديدات وطرق وتقنيات ICS-specific

•       حدد جميع النتائج الفورية/الحرجة التي تتطلب علاجًا مستقلًا عن مراحل البرنامج المخططة

•       دمج سجل المخاطر في إطار إدارة المخاطر التنظيمية؛ تقديمه للإدارة العليا

•       تحديث أو إعداد متطلبات أمان البائع المتوافقة مع IEC 62443-2-4

الأشهر 6–12 · المرحلة 3: الضوابط الأساسية

تنفيذ ضوابط الحماية ذات الأولوية

عالج الفجوات الحرجة وذات الأولوية العالية. ركز أولاً على بنية الشبكة (الأكثر فعالية مقابل التكلفة في أمان OT) والتحكم في الوصول.

• تنفيذ أو تعديل تقسيم الشبكة: هندسة DMZ بين OT وIT؛ فرض حدود المنطقة باستخدام جدران حماية مناسبة لـ OT

• نشر ثنائيات البيانات على مسارات بيانات SIS-to-DCS حيث يستهدف SL3

• القضاء على بيانات الاعتماد الافتراضية على جميع أجهزة OT؛ تنفيذ التحكم في الوصول استنادًا إلى الأدوار المتوافقة مع FR1–FR2

• نشر سيرفر قفز مع تسجيل الجلسة للوصول عن بعد إلى جميع مناطق OT؛ فرض المصادقة متعددة العوامل على الوصول عن بعد

• تنفيذ فحص الوسائط (حل فحص الوسائط من Shieldworkz أو ما يعادله) لجميع الوسائط القابلة للإزالة التي تدخل بيئات OT

• نشر منصة رؤية OT في وضع المراقبة السلبية؛ تحديد إجراءات تصنيف التنبيهات

• تطوير وممارسة أول تمرين استجابة لحوادث OT يشمل تصعيد الأمن السيبراني إلى السلامة العملية

الأشهر 12–18 · المرحلة 4: نضج الكشف والاستجابة

بناء القدرة المستدامة للكشف والاستجابة

الانتقال من رد الفعل إلى التفكير الاستباقي: المراقبة المستمرة، قدرة اصطياد التهديدات، والإجراءات التي تم تجريبها للاستجابة.

• تأسيس وظيفة SOC في OT (داخلية أو مُدارة) مع حالات استخدام الكشف وكتيبات العمل الخاصة بـ OT

• دمج تنبيهات منصة رؤية OT في SIEM المؤسسي مع قواعد الارتباط المناسبة لـ OT

• تنفيذ عملية إدارة تحديثات OT المتوافقة مع IEC 62443-2-3: تنسيق البائع، اختبار بيئة المرحلة، جدولة نافذة الصيانة

• إجراء تقييم للضعف OT عبر جميع الأنظمة الحرجة باستخدام أساليب التخفيف من التأثير/المنخفضة

• اكمل التخطيط لاستمرارية الأعمال والتعافي من الكوارث في OT؛ اختبار استعادة النسخ الاحتياطي للتكوين

•  إطلاق برنامج توعية الأمن السيبراني في OT للمشغلين والمهندسين والمقاولين

الأشهر 18–24 · المرحلة 5: التحسين المستمر

ترسيخ، قياس، وتحسين

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

•       إعداد تقارير الأداء الأمني الفصلي في OT للإدارة العليا: مؤشرات الأداء الرئيسية بما في ذلك نسبة الامتثال للتحديث، عناصر الخطر المفتوحة، مقاييس الحوادث، اكتمال التدريب

•       دمج مراجعة الأمن السيبراني لـ OT في جميع عمليات إدارة التغيير في OT (MOC)

•       تحديث سنوي لتقييم المخاطر لـ IEC 62443-3-2؛ تحديث SL-T وسجل المخاطر

•       تمرين استجابة لـ OT السنوي (تصعيد من طاولة إلى تدريب حي حيث يكون آمنًا)

•       تحديث معيار المشتريات: تتطلب جميع المشتريات OT الجديدة شهادة مكون SL لـ IEC 62443-4-2 أو دليل SDL المكافئ للبائع

•       تقييم أمان سلسلة التوريد: تقييم البائعين الرئيسيين لـ OT مقابل متطلبات IEC 62443-2-4

08 الحوكمة: الفرق بين البرنامج والمشروع

تتحلل الضوابط الفنية دون الحوكمة. يجب دعم برنامج الأمن السيبراني لـ OT بالآليات التنظيمية التي تتجاوز الأفراد، دورات الميزانية، وتركيز الإدارة. تحدد IEC 62443-2-1 نظام إدارة الأمن السيبراني (CSMS) — النظام التنظيمي الذي يضمن أن الأمن السيبراني هو وظيفة إدارية مستمرة، وليس مشروعًا مؤقتًا.

يجب أن يكون CSMS محددًا لـ OT

أحد أكثر الإخفاقات في الحوكمة شيوعًا هو تطبيق سياسة الأمان IT للمنظمة — أو حتى ISMS IT (ISO 27001) — مباشرة على OT دون تعديل. IT وOT لديهما أولويات أساسية مختلفة، تحمّل المخاطر، وقيود العمليات. سياسة IT التي تطالب بمصادقة متعددة العوامل على كل الوصول إلى النظام صحيحة ومناسبة لـ IT. عند تطبيقها بسذاجة على OT، فإنها ستفرض المصادقة متعددة العوامل لمشغل يحتاج إلى الاعتراف بإنذار عالي الأولوية خلال ثانيتين أو تعرض العملية لخطر التوقف — وهذا هو السبب في أن CSMS لـ OT يجب أن يحدد ضوابط معينة لـ OT بسياق عملياتي.

إدارة التغيير هي التحكم الأمني

كل تغيير في أجهزة OT، برامجها، تكوين الشبكة، أو العملية هو حدث أمني محتمل. يجب أن تتضمن عملية إدارة التغيير (MOC) خطوة مراجعة أمان سيبراني لـ OT إلزامية. هذا يعني: قبل تنفيذ أي تغيير في بيئة OT، تقوم وظيفة أمان OT بمراجعته لتأثير الأمن السيبراني. إتصالات البائع الجديدة، تحديثات البرامج الثابتة، إعادة تكوين الشبكة، الأجهزة الجديدة المضافة إلى شبكة OT — جميعها يجب أن تمر بهذه البوابة. تحدد كل من NIST SP 800-82 Rev.3 §6.2.3 وIEC 62443-2-1 §4.2.3 إدارة التغيير كمتطلبات أساسية لإدارة الأمان.

مخاطر الباعة وسلسلة التوريد

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

تحدد IEC 62443-2-4 متطلبات الأمان التي يمكنك وضعها على مقدمي الخدمات OT تعاقدياً. المتطلبات الدنيا لأي بائع لديه وصول شبكة OT: ممارسات أمنية موثقة؛ استخدام معدات مكرسة ومحسنة من الفيروسات للعمل مع OT؛ الوصول المستند إلى الجلسة فقط (لا اتصالات نشطة دائمًا)؛ قبول تسجيل الجلسات؛ والتزام إشعار الحوادث. تحقق من هذه المتطلبات - لا تكتفي بجمع التعهدات الموقعة.

قياسات تضيف إلى شيء ما

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

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

اتصل بنا لتتعرف على المزيد حول كيفية الارتكاز على IEC 62443 و NIST SP 100-82 لبناء برنامج للأمن السيبراني.

حمل قائمة التحقق الخاصة بنا حول دمج IEC 62443 و NIST SP 100-82، هنا