→ العودة إلى المدونةProduct Security

مقال متخصص في ⁦mt|medizintechnik⁩ 4.2026: لماذا لا تكتمل صيانة الأجهزة الطبية المتصلة بالشبكة دون الأمن السيبراني

19 أكتوبر 2026

نُشر في , العدد 4.2026

نُشر في ⁦mt|medizintechnik⁩، العدد 4.2026

في مجلة ⁦mt|medizintechnik⁩ المتخصصة يبيّن Valeri Milke لماذا باتت صيانة الأجهزة الطبية المتصلة بالشبكة تشمل اليوم الأمن السيبراني. ويحمل مقاله المنشور بالألمانية عنوان «⁦Instandhaltung vernetzter Medizinprodukte⁩» (صيانة الأجهزة الطبية المتصلة بالشبكة)، ويتصدّره عنوان تمهيدي مفاده أن إدارة الثغرات الأمنية والتصحيحات مسألة تمسّ السلامة. وقد نُشر المقال في العدد 4.2026 الصادر في أغسطس 2026 ضمن محور «الصيانة»، وهي مجلة تصدرها TÜV Media GmbH في كولونيا. الكاتب: Valeri Milke، الرئيس التنفيذي لشركة VamiSec GmbH، ومدقق رئيسي (Lead Auditor) لـ ⁦ISO/IEC 27001⁩ و⁦ISO/IEC 42001⁩. ويرسم المقال، عبر خمسة رسوم توضيحية وجدول، كيف تبني الشركات المصنِّعة والمشغّلون تشغيل الأجهزة المتصلة كعملية متكاملة – من جرد المكوّنات البرمجية مرورًا بتقييم الثغرات الأمنية ومعالجتها وصولًا إلى التزامات الإبلاغ بعد حادث أمني. ويعرض هذا الخبر الأفكار الرئيسية بصياغتنا الخاصة، ويضعها في سياق الوضع التنظيمي كما هو في أكتوبر 2026.

الأطروحة الأساسية: الجهاز الذي يعمل ليس بالضرورة آمنًا

تسير الصيانة التقليدية وفق مواعيد دورية ثابتة، وتتحقق من أن الجهاز يؤدي وظيفته. غير أن هذه النظرة لم تعد كافية للأجهزة الطبية المتصلة بالشبكة: فقد تجتاز مضخة تسريب أو نظام تصوير طبي كل اختبارات الأداء، ومع ذلك تنطوي على خطر غير مقبول – لأن ثغرة منشورة منذ زمن لم تُقيَّم قط مثلًا، أو لأن متسللًا يتحرك في الشبكة دون أن يُكتشف. ويستند المقال إلى مبدأ من الإرشادات الأوروبية ⁦MDCG 2019-16⁩ (المراجعة الأولى، يوليو 2020): مخاطر أمن المعلومات (Security) قد تتحول في البيئة السريرية مباشرةً إلى مخاطر على سلامة المرضى (Safety). ومن الأمثلة النموذجية تغيير معاملات العلاج، أو كتم الإنذارات، أو تزييف نتائج الفحوص. ولهذا ينبغي أن تندرج إدارة الثغرات الأمنية والتصحيحات، وكشف الهجمات أثناء التشغيل، ومراقبة ما بعد التسويق (PMS)، واليقظة في عملية إدارة موحّدة – مع أدوار موزعة بوضوح بين الشركات المصنِّعة والمُدمِجين والمستشفيات.

الشفافية أولًا: معرفة المكوّنات وتقييم الوضع الأمني

من لا يعرف المكتبات وأنظمة التشغيل والبرامج الثابتة الموجودة داخل الجهاز، لا يستطيع أن يحدد ما إذا كانت ثغرة جديدة تمسّه. لذلك تكون نقطة الانطلاق قائمة مكوّنات برمجية (⁦Software Bill of Materials – SBOM⁩) قابلة للقراءة آليًا بصيغة SPDX (⁦ISO/IEC 5962⁩) أو CycloneDX (⁦ECMA-424⁩)، تُحدَّث مع كل إصدار. وتحوّلها بيانات الشركة المصنِّعة حول مدى تأثر المنتج فعليًا (⁦Vulnerability Exploitability eXchange – VEX⁩) والنشرات الأمنية بصيغة ⁦Common Security Advisory Framework (CSAF)⁩ إلى صورة واضحة للوضع يمكن البناء عليها. وتُحدَّد الأولويات من عدة زوايا: الخطورة التقنية وفق نظام تقييم الثغرات الشائع (CVSS)، واحتمال الاستغلال خلال 30 يومًا وفق نظام التنبؤ باستغلال الثغرات (EPSS)، والاستغلال المثبت وفق كتالوج الثغرات المستغَلّة المعروفة (KEV) الصادر عن الوكالة الأمريكية CISA – ثم السياق السريري. فقد تكون ثغرة متوسطة الخطورة في منصة علاجية أكثر إلحاحًا من ثغرة حرجة في جهاز معزول. وتُظهر حادثتا Log4Shell و⁦XZ Utils⁩ مدى سرعة انتقال مخاطر سلسلة التوريد إلى المنتج.

التصحيح بوصفه تغييرًا مضبوطًا – وما العمل ما دام التصحيح غير متوفر

يخفّض التحديث الأمني المخاطر، لكنه قد يغيّر حالات تشغيل جرى التحقق من صحتها وواجهات قائمة. لذلك يتعامل المقال مع إدارة التصحيحات بوصفها عملية تغيير منظَّمة: تحديد المكوّنات المتأثرة عبر الجرد وSBOM، وتقييم آثار التحديث على الأمن والسلامة ضمن إدارة المخاطر وفق ISO 14971، واختباره في بيئة قريبة من الواقع، ثم اعتماده ونشره والتحقق من فعاليته وتوثيقه. ولا ينبغي للمشغّلين تثبيت التحديثات إلا وفق تعليمات صريحة من الشركة المصنِّعة، كما تنص على ذلك إرشادات ⁦MDCG 2019-16⁩ أيضًا. وإذا غاب التصحيح – كما في حالة ثغرة يوم صفر لم تُعالَج بعد – فإن الحل يكمن في إجراءات بديلة مُعدّة مسبقًا: تجزئة الشبكة، وتعطيل الخدمات المعرّضة للخطر، والمراقبة المكثفة، وأنماط تشغيل طارئة متفق عليها سريريًا. وهذه الإجراءات أيضًا يجب تبريرها وتوثيقها. أما التحديثات عن بُعد عبر الهواء (⁦Over-the-Air – OTA⁩) فتتطلب إضافة إلى ذلك حزمًا موقَّعة، وإقلاعًا آمنًا (Secure Boot)، وصورة نظام احتياطية للرجوع إليها، وحماية من إعادة تثبيت إصدارات قديمة، وتوزيعًا تدريجيًا على مراحل.

تلقّي الثغرات المكتشفة من الخارج: الإفصاح المنسَّق وفريق PSIRT

كثير من الثغرات لا تكتشفها الشركات المصنِّعة بنفسها، بل الباحثون الأمنيون ومختبرو الاختراق والمُدمِجون أو المستخدمون. وحتى لا تضيع هذه البلاغات أو تصل إلى العلن بشكل غير منظَّم، يدعو المقال إلى إجراء منظَّم للإفصاح المنسَّق عن الثغرات (⁦Coordinated Vulnerability Disclosure – CVD⁩) لدى كل شركة مصنِّعة. ويقدّم المعيار ⁦ISO/IEC 29147⁩ التوجيه لاستقبال البلاغات ونشر المعلومات، والمعيار ⁦ISO/IEC 30111⁩ للمعالجة الداخلية. وعمليًا يشمل ذلك ملف ⁦security.txt⁩ وفق ⁦RFC 9116⁩، وصندوق بريد للبلاغات يمكن الوصول إليه بشكل مشفّر، وأزمنة استجابة ملتزمًا بها، وجهة ترقيم CVE خاصة بالشركة (⁦CVE Numbering Authority – CNA⁩) أو التعاون مع جهة قائمة، إضافة إلى نشرات أمنية قابلة للقراءة آليًا بصيغة CSAF. ويتولى هذا الإجراء فريق الاستجابة لحوادث أمن المنتجات (⁦Product Security Incident Response Team – PSIRT⁩) لدى الشركة المصنِّعة. وبالنسبة للمستشفيات، يُعدّ نضج هذه العملية معيارًا ملموسًا للاختيار عند الشراء: فدون سجل نشرات أمنية قابل للتتبع يبقى غير واضح مدى سرعة وصول التنبيهات الحرجة إلى المشغّل.

حادث واحد وثلاثة مسارات للإبلاغ: MDR وقانون BSI واللائحة العامة لحماية البيانات

متى يصبح الحدث السيبراني خاضعًا لالتزام الإبلاغ؟ تخضع الشركات المصنِّعة لالتزامات اليقظة في MDR: يجب الإبلاغ عن الحوادث الجسيمة دون تأخير، وفي موعد أقصاه يومان من العلم بها عند وجود تهديد خطير للصحة العامة، و10 أيام في حالة الوفاة أو التدهور الخطير غير المتوقع في الحالة الصحية، و15 يومًا في غير ذلك. أما المستشفيات التي تندرج بوصفها جهات بالغة الأهمية أو جهات مهمة تحت قانون BSI الجديد – الذي ينقل منذ 6 ديسمبر 2025 توجيه NIS2 إلى القانون الألماني – فتبلّغ عن الحوادث الأمنية الكبيرة بإنذار مبكر خلال 24 ساعة، وببلاغ يتضمن تقييمًا أوليًا خلال 72 ساعة، وبتقرير نهائي في موعد أقصاه شهر بعد هذا البلاغ. وإذا تأثرت بيانات شخصية، فإن اللائحة العامة لحماية البيانات تشترط عادةً إبلاغ سلطة الرقابة على حماية البيانات خلال 72 ساعة إن أمكن. وقد يُطلق هجوم واحد المسارات الثلاثة في آن واحد – لدى الشركة المصنِّعة والمستشفى معًا. لذلك يوصي المقال بمهل موثَّقة مسبقًا، ومسؤوليات محسومة، ونماذج إبلاغ جاهزة.

لماذا بات الموضوع مُلحًّا الآن – وما الذي يمكنكم فعله

اقترحت المفوضية الأوروبية في ديسمبر 2025 أن تُضاف إلى MDR وIVDR آلية إبلاغ مستقلة عن الثغرات الأمنية المستغَلّة فعليًا والحوادث الأمنية الجسيمة – عبر Eudamed إلى فرق CSIRT وENISA، في موعد أقصاه 30 يومًا من العلم بها. وفي الوقت نفسه يُفترض أن ترتفع مهلة الإبلاغ عن الحوادث الجسيمة الأخرى من 15 إلى 30 يومًا؛ ولم يُعتمد أيٌّ من الأمرين بعد. ومنذ 11 سبتمبر 2026 تسري كذلك التزامات الإبلاغ التي يفرضها قانون المرونة السيبرانية (Cyber Resilience Act) على الشركات المصنِّعة. وهو يستثني الأجهزة الطبية، لكنه قد يشمل مباشرةً مكوّنات الموردين التي تُطرح في السوق بشكل مستقل بوصفها منتجات ذات عناصر رقمية. وثمة خمس خطوات عملية مقترحة: بناء جرد للأجهزة يتضمن إصدارات البرمجيات وSBOM؛ واشتراط SBOM وVEX ونشرات CSAF تعاقديًا على الموردين؛ واعتماد فرز للثغرات يقيّم العواقب السريرية صراحةً؛ والتدرّب على سيناريوهات ثغرات يوم الصفر بالاشتراك بين تقنية المعلومات في المستشفى والهندسة الطبية والشؤون التنظيمية؛ وأخيرًا دمج مسارات الإبلاغ وفق MDR وقانون BSI واللائحة العامة لحماية البيانات في إجراء واحد منسَّق.

جديد على ⁦vamisec.com⁩: الصفحة المعرفية حول الموضوع

جديد على ⁦vamisec.com⁩: الصفحة المعرفية «صيانة الأجهزة الطبية المتصلة بالشبكة». تتناول الصفحة أطروحات المقال المنشور في المجلة، وتحدّثها وفق الوضع في أكتوبر 2026، وتتعمّق فيها على امتداد عملية الصيانة في الميدان بأكملها – من الجرد وSBOM مرورًا بصورة الوضع والفرز وعملية التصحيح والتحديث عبر الهواء والاستعداد لثغرات يوم الصفر والإفصاح المنسَّق، وصولًا إلى المراقبة ومسارات الإبلاغ المتوازية وتصوّر تشغيلي للوضع المستهدف، مع أسئلة شائعة ومصادر جرى التحقق منها. تجدون الصفحة على https://vamisec.com/ar/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte. ونعرض خدماتنا الاستشارية لمشاريع MDR وللأمن السيبراني للأجهزة الطبية على الصفحة https://vamisec.com/ar/mdr وكذلك على الصفحة https://vamisec.com/ar/medical-device-cybersecurity – أما متطلبات MDR الشاملة فتلخّصها الصفحة https://vamisec.com/ar/wissen/grc/mdr-cybersecurity.

جميع الروابط

العدد 4.2026 من ⁦mt|medizintechnik⁩: https://mt-medizintechnik.de/fokus-auf-instandhaltung/ · الصفحة المعرفية «صيانة الأجهزة الطبية المتصلة بالشبكة»: https://vamisec.com/ar/wissen/secure-software-development/instandhaltung-vernetzter-medizinprodukte · فئة تطوير البرمجيات والمنتجات الآمنة، قسم الأجهزة الطبية: https://vamisec.com/ar/wissen/secure-software-development#medizinprodukte · الأمن السيبراني في MDR في لمحة: https://vamisec.com/ar/wissen/grc/mdr-cybersecurity · إدارة SBOM: https://vamisec.com/ar/wissen/secure-software-development/sbom-management · إدارة الثغرات الأمنية: https://vamisec.com/ar/wissen/it-security/schwachstellenmanagement · استشارات MDR: https://vamisec.com/ar/mdr · الأمن السيبراني للأجهزة الطبية: https://vamisec.com/ar/medical-device-cybersecurity

هل لديكم أسئلة حول أمن تقنية المعلومات في مؤسستكم؟

استشارة أولية مجانية →