أصدر المعهد الوطني للمعايير والتكنولوجيا (NIST) المنشور الخاص (SP) 800-18 المراجعة 2، بعنوان تطوير خطط إدارة مخاطر سلسلة توريد الأمن والخصوصية والأمن السيبراني للأنظمة. يمثل هذا التحديث التاريخي نقلة نوعية حديثة في كيفية توثيق وإدارة وترخيص أنظمة المعلومات والتكنولوجيا التشغيلية (OT) من قبل الوكالات الفيدرالية والمقاولين ومشغلي البنية التحتية الحيوية.

الغرض من NIST SP 800-18 Rev. 2

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

• خطط أمن النظام (SSP)

• خطط خصوصية النظام

• خطط إدارة مخاطر سلسلة توريد الأمن السيبراني (C-SCRM)

لماذا كانت المراجعة 2 ضرورية؟

ركز دليل SP 800-18 الأصلي (المراجعة 1) بشكل حصري تقريباً على خطط أمن تكنولوجيا المعلومات المستقلة واعتمد على مصطلحات قديمة وكتلية (مثل "أنظمة الدعم العام" و"التطبيقات الرئيسية"). وفي البيئة التشغيلية اللامركزية اليوم—والتي تتميز بالحوسبة السحابية متعددة المستأجرين، والتكنولوجيا التشغيلية (OT) شديدة الترابط، والاعتماد على برمجيات الطرف الثالث (SaaS/البرمجيات مفتوحة المصدر)، واللوائح الصارمة للخصوصية—أصبحت المراجعة 1 قديمة من الناحية الوظيفية. وتتطلب الأنظمة الحديثة نهجاً يتم فيه تحليل تأثيرات الخصوصية وثغرات سلسلة التوريد جنباً إلى جنب مع الضوابط الأمنية الكلاسيكية.

التحسينات مقارنة بالمراجعة 1

• دمج الخطط الثلاث: دمج اعتبارات الأمن والخصوصية وإدارة مخاطر سلسلة التوريد (C-SCRM) في منظومة مترابطة بدلاً من صوامع معزولة.

• تزامن دورة حياة إطار إدارة المخاطر (RMF): مواءمة مهام تطوير الخطط بشكل مباشر مع خطوات إطار إدارة مخاطر معهد NIST (RMF) وفقاً للمنشور SP 800-37 المراجعة 2.

• إلغاء التصنيفات القديمة: التخلص التدريجي من التصنيفات القديمة لصالح حدود ترخيص واضحة تعكس البيئات السحابية الهجينة والطرفية وبيئات التكنولوجيا التشغيلية (OT).

• التركيز على الأتمتة والتوافق التشغيلي لأنظمة الحوكمة والمخاطر والامتثال (GRC): يدعو بقوة إلى اعتماد صيغ بيانات قابلة للقراءة آلياً (مثل لغة تقييم الضوابط الأمنية المفتوحة - OSCAL) لدعم جمع البيانات في الوقت الفعلي ولوحات المعلومات الديناميكية بدلاً من المستندات الثابتة في لحظة زمنية معينة.

أهم النقاط للمسؤولين التنفيذيين

التفويض التنفيذي: لم تعد خطط الأنظمة مجرد مربعات اختيار للامتثال؛ بل هي المصدر الأساسي للحقيقة لموقف المخاطر التشغيلية للمؤسسة. ويجب على مديري أمن المعلومات (CISOs) ومديري تكنولوجيا المعلومات (CIOs) الاستفادة من المراجعة 2 لتحويل الموارد من الصياغة اليدوية للمستندات إلى التحقق الآلي والمستمر من الضوابط. وإن الفشل في دمج إدارة مخاطر سلسلة التوريد (C-SCRM) والخصوصية مباشرة في وثائق حدود النظام سيؤدي إلى فشل عمليات التدقيق، وتأخير تراخيص التشغيل (ATOs)، وتحمل مسؤوليات غير مخففة تجاه الأطراف الخارجية.

القسم 1 – فهم منشور NIST SP 800-18 Rev. 2

الخلفية والتطور

يمثل منشور NIST SP 800-18 Rev. 2 تطوراً رئيسياً في تخطيط الأنظمة. فبينما كانت المراجعة 1 بمثابة دليل لمديري تكنولوجيا المعلومات الفيدراليين لتوثيق الأسس الفنية، تعمل المراجعة 2 كجسر تشغيلي عبر العديد من أطر عمل NIST المتخصصة. فهي توائم بين التفويضات الأساسية لـ قانون تحديث أمن المعلومات الفيدرالي (FISMA) ومنشور مكتب الإدارة والموازنة A-130 في دورة حياة قابلة للتكرار.

النطاق والجمهور المستهدف

يشمل النطاق جميع أنظمة المعلومات الفيدرالية، والمقاولين الذين يديرون الأنظمة نيابة عن الحكومة، وكيانات البنية التحتية الحيوية التي تتبنى معايير NIST طواعية. ويضم الجمهور الأساسي القيادة العليا (مديري أمن المعلومات، ومديري تكنولوجيا المعلومات، وكبار مسؤولي الوكالات للخصوصية)، والمالكين التشغيليين (مالكي الأنظمة، ومالكي المعلومات)، والمقيمين (مقيّمي الضوابط، والمدققين، والمفتشين العموميين).

العلاقة مع إطار إدارة مخاطر معهد NIST (RMF) وترخيص النظام (ATO)

تعد خطط النظام هي المستندات الأساسية المستخدمة من قبل المسؤول المفوض (AO) لمنح ترخيص التشغيل (ATO). وبموجب المنشور SP 800-18 Rev. 2، تعمل خطة النظام كـ مدخلات ومخرجات طوال دورة حياة إطار إدارة المخاطر (RMF). حيث ترصد قرارات المخاطر أثناء تصميم النظام، وتسجل عمليات تنفيذ الضوابط أثناء النشر، وتعكس التغييرات التشغيلية في الوقت الفعلي أثناء المراقبة المستمرة.

القسم 2 – علاقات المعايير وأطر العمل

لا يحل منشور NIST SP 800-18 Rev. 2 محل مستودعات الضوابط الحالية أو أطر المخاطر؛ بل يوفر معيار التوثيق والتخطيط الذي يربط بينها.

القسم 3 – المكونات الأساسية لخطط النظام

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

1. خطة أمن النظام (SSP)

• الغرض: توثيق البيئة التشغيلية للنظام، وتصنيف الأمان، والضوابط الفنية والتشغيلية والإدارية المطبقة لحماية الأصول.

• المحتوى المطلوب: حدود ترخيص واضحة، وقوائم جرد أصول الأجهزة/البرمجيات، ومخططات طبوغرافية الشبكة، ومخططات تدفق البيانات، وتخصيص ضوابط الأمان، وبيانات التنفيذ التفصيلية.

• أفضل الممارسات: استخدام صيغ قابلة للقراءة آلياً (مثل OSCAL JSON/XML) لربط الضوابط مباشرة بنصوص تقييم التكوين الآلي.

• الأخطاء الشائعة: توثيق بيانات سياسات عامة مكررة (مثل "تفرض المؤسسة كلمات مرور معقدة") بدلاً من تفصيل الآليات الدقيقة على مستوى النظام (مثل "تفرض كائنات نهج المجموعة في الدليل النشط 'Domain_Password_Policy' حداً أدنى يبلغ 14 حرفاً").

2. خطة خصوصية النظام

• الغرض: مواءمة أهداف هندسة الخصوصية (إمكانية التنبؤ، وقابلية الإدارة، وقابلية الفصل) مع البنية الفنية للنظام للتخفيف من المخاطر المرتبطة بالإفراط في جمع البيانات ومعالجتها.

• المحتوى المطلوب: قوائم جرد بيانات معلومات التعريف الشخصية (PII)، والسلطة القانونية الواضحة للجمع، ورسم خرائط البيانات (الدخول، والتخزين، والعبور، والخروج)، وتطبيقات ضوابط الخصوصية.

• أفضل الممارسات: تضمين علامات تتبع تدفق البيانات مباشرة في مخططات البيانات الوصفية لمراقبة حركة معلومات التعريف الشخصية (PII) عبر حدود النظام في الوقت الفعلي تقريباً.

• الأخطاء الشائعة: الخلط بين إشعار "سياسة الخصوصية" لموقع ويب عام وخطة خصوصية على مستوى النظام تفصّل ضوابط المعالجة الفنية.

3. خطة إدارة مخاطر سلسلة توريد الأمن السيبراني (C-SCRM)

• الغرض: تحديد وتخفيف المخاطر المرتبطة بمكونات الطرف الثالث والبرمجيات والأجهزة والتبعيات للخدمات المدمجة ضمن حدود النظام.

• المحتوى المطلوب: قائمة مكونات البرمجيات (SBOM)، وسجلات منشأ مكونات الأجهزة، وشهادات مزودي الخدمات السحابية (CSP) (حزم FedRAMP)، ومستويات مخاطر الموردين.

• أفضل Mمارسات: أتمتة إدخال قائمة مكونات البرمجيات (SBOM) في مسار إدارة الثغرات الأمنية للإشارة الفورية إلى الثغرات والمخاطر المكتشفة حديثاً (CVEs) في حزم المصادر المفتوحة في المنبع.

• الأخطاء الشائعة: الاعتماد على اتفاقيات عدم الإفصاح الأساسية (NDAs) مع الموردين بدلاً من التحقق من سلامة المكونات النشطة على مستوى النظام.

القسم 4 – تدابير وضوابط الامتثال

لتنفيذ توجيهات منشور SP 800-18 Rev. 2 بشكل صحيح، يجب على المؤسسات وضع نموذج حوكمة متعدد الوظائف. ويوضح الجدول أدناه توقعات النشر الصريحة مقابل أفضل ممارسات التنفيذ في الصناعة.

آليات الحدود وتخصيص الضوابط

• حدود الترخيص (توقعات النشر): يجب تحديدها صراحة. فهي تحدد نطاق ما يتم الترخيص بتشغيله. ويجب حساب كل مكون موجود داخل الحدود في جرد الأصول.

• الضوابط المشتركة والهجينة والخاصة بالنظام (توقعات النشر): يجب على المؤسسات تصنيف الضوابط لمنع تكرار العمل:

  • الضوابط المشتركة: توفرها المؤسسة (مثل الأمن المادي، والدليل النشط للشركة) ويرثها النظام.

  • الضوابط الخاصة بالنظام: يتم تنفيذها بالكامل داخل حدود النظام.

  • الضوابط الهجينة: جزء منها موروث من المؤسسة وجزء آخر خاص بالنظام (مثل خطة الاستجابة للحوادث المصممة لمنشأة تكنولوجيا تشغيلية OT محددة).

• التحديثات المستمرة (أفضل ممارسات التنفيذ): الابتعاد عن المراجعات اليدوية السنوية. ووضع محفزات آلية—مثل إصدار برمجيات رئيسي أو تغيير في البنية—لتحفيز التحديثات الآلية لخطة النظام.

القسم 5 – منهجية التقييم

توفر هذه المنهجية المكونة من أربع مراحل لمدققي الحسابات الداخليين ومقيمي الامتثال مخططاً دقيقاً من الناحية الفنية لتقييم مواءمة المؤسسة مع منشور SP 800-18 Rev. 2.

المرحلة 1: التخطيط وتحديد النطاق

1. تحديد حدود ترخيص النظام ومطابقتها مع قاعدة بيانات إدارة أصول المؤسسة.

2. تحديد أصحاب المصلحة الرئيسيين (مالك النظام، مسؤول الخصوصية، رئيس إدارة مخاطر سلسلة التوريد C-SCRM، الأمناء).

3. تحديد السياق التشغيلي وسياق التهديد (مثل تطبيق سحابي متصل بالإنترنت مقابل نظام سكادا SCADA لتصنيع معزول تماماً عن الإنترنت).

المرحلة 2: جمع الأدلة

جمع وتقييم المستندات الإلزامية التالية بشكل منهجي:

• دمج خطط النظام (SSP، الخصوصية، C-SCRM).

• مخططات تدفق البيانات وطبوغرافيا الشبكة.

• قائمة مكونات البرمجيات (SBOM) الحالية وتقييمات مخاطر الموردين.

• تذاكر إدارة التغيير التاريخية والأسس المرجعية لتكوين النظام.

المرحلة 3: التحقق والتأكيد

يجب على المقيمين إجراء التحقق المتبادل من الوثائق مقابل تكوينات النظام الفعلية باستخدام مقياس نضج محدد:

[مستوى النضج 1: مخصص] ---> [مستوى النضج 2: موثق] ---> [مستوى النضج 3: مؤتمت/OSCAL]

• الكمال: التأكد من أن كل ضابط في الأساس المرجعي المخصص يحتوي على بيان تنفيذ صريح.

• التحقق من الدقة: عدم الاكتفاء بقراءة الخطة؛ بل إجراء عمليات تحقق فنية عشوائية. فإذا ذكرت خطة SSP أنه يتم فرض بروتوكول TLS 1.3، فقم بإجراء فحص ثغرات الشبكة للتحقق من تعطيل البروتوكولات القديمة تماماً (مثل TLS 1.0).

المرحلة 4: إعداد التقارير والمعالجة

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

أسئلة المقابلة الفنية للمقيمين

1. "كيف يتم تحديد التبعيات في قائمة مكونات البرمجيات (SBOM) لنظامك والتحليل عند نشر ثغرة أمنية حرجة جديدة في قاعدة البيانات الوطنية للثغرات الأمنية (NVD)؟"

2. "هل يمكنك توضيح الآلية الفنية الدقيقة المستخدمة لفصل أو إلغاء ربط عناصر بيانات معلومات التعريف الشخصية (PII) كما هو موضح في خطة خصوصية النظام الخاص بك؟"

القسم 6 – مؤشرات الأداء الرئيسية (KPIs)

للحفاظ على الرؤية المستمرة، يجب على المؤسسات تنفيذ مقاييس الأداء التالية.

1. تغطية الوثائق القابلة للقراءة آلياً

• التعريف: نسبة الأساس المرجعي لخطة النظام المحولة بالكامل إلى صيغ قابلة للقراءة آلياً (مثل OSCAL).

• مصدر البيانات: مستودع منصة الحوكمة والمخاطر والامتثال (GRC) للمؤسسة.

• وقت حل ثغرات سلسلة التوريد (TTR)

• مصدر البيانات: مسار التكامل المستمر/النشر المستمر (CI/CD) وفاحصات التبعية الآلية.

القسم 7 – نتائج التدقيق الشائعة والمعالجة

1. حدود نظام غير مكتملة وقديمة

• الخطر: مرتفع. يمكن أن تؤدي البنية التحتية لتكنولوجيا المعلومات غير المراقبة (Shadow IT) إلى حركة جانبية غير مكتشفة أثناء حدوث خرق أمني.

• السبب الجذري: يتم إجراء تغييرات في بنية النظام في بيئة الإنتاج دون تحديث مخطط الحدود أو جرد الأصول في أداة GRC.

• توقعات المدقق: تطابق كامل بين فحوصات اكتشاف الشبكة النشطة والمكونات المرخصة المدرجة في خطة SSP.

• المعالجة: تنفيذ مسارات البنية التحتية كبرمجية (IaC) المؤتمتة التي تعيد إنشاء مخططات البنية وتحدث خطط النظام ديناميكياً أثناء النشر.

2. بيانات تنفيذ الضوابط المكررة والنمطية

• الخطر: متوسط إلى مرتفع. يترك تنفيذ الضوابط غامضاً، مما يؤدي إلى انحراف التكوين وعدم اتساق العمليات الأمنية.

• السبب الجذري: الاعتماد على نماذج الامتثال التي تعكس سياسات الشركة عالية المستوى بدلاً من تفصيل الآليات الخاصة بالنظام.

• توقعات المدقق: أوصاف شاملة وخطوة بخطوة تحدد الأدوات والتكوينات والأدوار والتكرارات المحددة المشاركة في تنفيذ الضوابط.

• المعالجة: تدقيق الخطط الحالية ورفض أي بيان يستخدم كلمات مبنية للمجهول مثل "يتوافق النظام مع..." أو "تتطلب السياسة..." دون تحديد كيفية عمل الضابط.

القسم 8 – دراسة حالة عملية

الوضع الأولي

أدارت شركة تصنيع كبرى بيئة تصنيع صناعية مع أرضية إنتاج نشطة. وكانت وثائق الأمان القديمة الخاصة بها تتكون من مستند Word ثابت واحد مكون من 300 صفحة تمت كتابته قبل خمس سنوات بموجب إرشادات منشور SP 800-18 Rev. 1. وأغفل المستند تماماً تبعيات سلسلة توريد البرمجيات (SBOMs) وفشل في حساب منصة إنترنت الأشياء (IoT) للصيانة التنبؤية الجديدة المتصلة بالسحاب والتي عالجت تحليلات سلوك المشغل (PII).

التقييم وتحليل الفجوات

كشف تدقيق داخلي تم إجراؤه وفقاً لمنشور SP 800-18 Rev. 2 عن أوجه قصور خطيرة:

• الفجوة الحرجة 1: فشلت حدود الترخيص في تحديد منطقة التقارب بين التكنولوجيا التشغيلية (OT) ومنصة الصيانة السحابية.

• الفجوة الحرجة 2: عدم وجود أي توثيق لآليات دورة حياة البيانات لمقاييس المشغل، مما ينتهك أهداف الخصوصية الأساسية.

• الفجوة الحرجة 3: عدم وجود تحقق من مكتبات المصادر المفتوحة المستخدمة في البرامج الثابتة المخصصة لنقاط نهاية إنترنت الأشياء (IoT).

خارطة طريق المعالجة وتحسينات مؤشرات الأداء الرئيسية

أعادت شركة Apex هيكلة استراتيجية التخطيط الخاصة بها على مدار 90 يوماً متسارعاً:

• تجزئة الحدود: عزلت رسمياً محيط التكنولوجيا التشغيلية (OT) باستخدام منطقة معزولة (DMZ) تتماشى مع منشور NIST SP 800-82 Rev. 3، مما أدى صراحة إلى إنشاء حدود نظام جديدة.

• إنشاء الخطط الثلاثية: إنشاء وحدات خطط متميزة ولكنها مترابطة للأمن والخصوصية وإدارة مخاطر سلسلة التوريد (C-SCRM) مستضافة داخل منصة GRC للمؤسسة.

• التتبع المؤتمت لقائمة مكونات البرمجيات (SBOM): دمج أداة تحليل تكوين البرمجيات المستمر في بيئة التطوير الخاصة بهم.

النتائج

• تحويل OSCAL: نقل تغطية الوثائق من 0% إلى 90% قابلة للقراءة آلياً.

• وقت دورة التدقيق: تقليل الوقت المطلوب لتجميع وتقديم أدلة التدقيق للتحقق السنوي من ترخيص التشغيل (ATO) بنسبة 65%.

• رؤية الثغرات الأمنية: اكتشاف وتخفيف ثلاث ثغرات أمنية عالية الخطورة مدمجة في مكونات البرامج الثابتة لطرف ثالث خلال الأسبوع الأول من النشر.

القسم 9 – أفضل الممارسات للإدارة المستمرة لدورة الحياة

لتجنب إرهاق الامتثال وضمان بقاء خطط النظام دقيقة، يجب على المؤسسات اعتماد هذه الممارسات التشغيلية الأساسية:

• تبني الأتمتة مبكراً: التوقف عن معاملة خطط النظام كملفات Word أو PDF ثابتة. والاستفادة من أدوات GRC التي تدعم أطر العمل المفتوحة مثل OSCAL بشكل أصلي. ويمكّن هذا فاحصات الثغرات الأمنية الآلية، وأدوات إدارة الرقع، وأنظمة الهوية من إدخال بيانات التكوين مباشرة في الخطة.

• دمج التخطيط في إدارة التغيير: تكوين تدفقات عمل مجلس استشاري التغيير (CAB) بحيث لا يمكن الموافقة على أي تعديل رئيسي في النظام (مثل ترحيل قاعدة بيانات محلية إلى قاعدة بيانات سحابية) دون الإشارة تلقائياً إلى خطة النظام لتحديث الحدود وتدفق البيانات.

• تنسيق المراجعات متعددة الوظائف: جدولة جلسات تزامن ربع سنوية منظمة تجمع بين مالك النظام ومسؤول الخصوصية وفرق المشتريات وإدارة مخاطر سلسلة التوريد (C-SCRM) للمراجعة الجماعية للتغييرات في تبعيات المكونات ومخاطر الموردين وناقلات جمع البيانات.

القسم 10 – الملاحق

قائمة التحقق للمراجعة الشاملة لخطة النظام

• [ ] التحقق من الحدود: هل تم تحديد حدود ترخيص النظام صراحة مع مخططات شبكة ومخططات تدفق بيانات توضح جميع مسارات الدخول والخروج؟

• [ ] سلامة الأصول: هل تشير خطة النظام إلى جرد أصول دقيق وفي الوقت الفعلي يحتوي على جميع الأجهزة والبرمجيات والمكونات الافتراضية؟

• [ ] تكامل الخطط الثلاثية: هل ترتبط اعتبارات تقييم الأثر على الخصوصية وتبعيات إدارة مخاطر سلسلة التوريد (C-SCRM) مباشرة بالأساس الأمني المرجعي، أم أنها تُدار في مستودعات منفصلة؟

• [ ] تخصيص الضوابط: هل تم تصنيف كل ضابط في الأساس المرجعي المخصص صراحة كضابط مشترك أو هجين أو خاص بالنظام؟

• [ ] دقة التنفيذ: هل تتجنب بيانات التنفيذ لغة السياسات العامة وتسمي بوضوح أدوات وتكوينات وأدوار تشغيلية محددة؟

• [ ] رؤية سلسلة التوريد: هل تم إرفاق قائمة مكونات برمجيات (SBOM) حالية، أو الإشارة إليها، أو إدخالها باستمرار لجميع المكونات المخصصة والتجارية؟

• [ ] تحديد المسؤوليات: هل تم تعيين الأدوار الرئيسية (المسؤول المفوض، مالك النظام، مسؤول الخصوصية، مدير C-SCRM) بوضوح مع تحديث تفاصيل الاتصال؟

• [ ] القابلية للقراءة آلياً: هل تمت هيكلة الخطة أو تصديرها بصيغة (مثل OSCAL JSON/XML) يمكن تحليلها بسهولة بواسطة أدوات GRC المؤتمتة وأدوات المراقبة المستمرة؟

المصطلحات والمراجع الرئيسية

• حدود الترخيص: جميع مكونات نظام المعلومات التي سيتم الترخيص بتشغيلها من قبل مسؤول مفوض واستبعادها من الأنظمة الأخرى.

• خطة C-SCRM: وثيقة تأسيسية تحدد الاستراتيجيات والضوابط وممارسات المراقبة المستخدمة لتحديد وتخفيف ثغرات سلسلة التوريد طوال دورة حياة النظام.

• خطط النظام: المصطلح الجماعي الذي تم تقديمه في منشور NIST SP 800-18 Rev. 2 والذي يشمل خطة أمن النظام، وخطة خصوصية النظام، وخطة إدارة مخاطر سلسلة توريد الأمن السيبراني.

• المواد المرجعية لـ NIST: * منشور NIST SP 800-18 Rev. 2 (النشر النهائي)

  • منشور NIST SP 800-37 Rev. 2 (إطار إدارة المخاطر)

  • منشور NIST SP 800-53 Rev. 5 (ضوابط الأمن والخصوصية)

  • منشور NIST SP 800-161 Rev. 1 (إدارة مخاطر سلسلة توريد الأمن السيبراني)

  
  

تواصل معنا اليوم لجدولة استشارتك المجانية واتخاذ الخطوة التالية نحو بيئة تشغيلية أكثر مرونة وحماية.

موارد إضافية:

الدليل الشامل للكشف عن الشبكة والاستجابة لها (NDR) في عام 2026 هنا
قائمة مراجعة الجاهزية لمراقبة أمن الشبكة الداخلية NERC CIP-015 لشركات الكهرباء هنا
قائمة مراجعة الامتثال لمعايير IEC 62443 وNIS2 هنا
نموذج مجاني لسياسة الوسائط القابلة للإزالة لفرق التكنولوجيا التشغيلية وتكنولوجيا المعلومات هنا