مخطط انسيابي لعملية إدارة التصحيحات (اختبار واعتماد ونشر بالحلقات)

ما هي مخطط انسيابي لعملية إدارة التصحيحات (اختبار واعتماد ونشر بالحلقات)؟

إدارة التصحيحات عمل دائم يحوّل نشرة موردّ إلى تحديث يُثبَّت ويُتحقَّق منه ويُوثَّق على كل أصل ينطبق عليه. والمحفّز خارجي: يصدر موردّ إصلاحاً، أو تحمل تغذية أمنية نشرة، أو يبلّغ فحص عن تحديث ناقص، وتبدأ الساعة سواء ناسب التوقيت أم لا. ويؤطّر دليل NIST لتخطيط إدارة التصحيحات في المؤسسات هذا النشاط بأكمله بوصفه صيانة وقائية للتقنية، وهو الوصف الصادق له — عمل روتيني له أجل ملحق. والمخطط أدناه يتتبع نشرة واحدة من البداية إلى النهاية: تُطابَق مع سجل الأصول، وتُقيَّم للتعرّض والأهمية، وتُوجَّه إما إلى المسار الطارئ أو إلى الدورة الشهرية، وتُختبَر مقابل الخدمة التي تمسّها، وتُعتمَد كتغيير، وتُعلَن، وتُنشَر بالحلقات مع مسار تراجع، ثم تُفحَص مجدداً، ويُبلَّغ عنها، وتُغلَق.

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

أربع قرارات تحمل العملية. 'تصحيح طارئ أم دورة روتينية؟' يقع في مسار الأمن لأن من يفهمون التعرّض هم من ينبغي أن يحدّدوا الوتيرة، وهذا ما يمنع تعليق الدورة الروتينية كلما علا صوت نشرة. و«هل يجتاز التصحيح الاختبار؟» و«هل الحلقة التجريبية سليمة؟» كلاهما لدى مالك التطبيق لا لدى مسؤول التصحيحات، لأن الأداة التي تثبّت تحديثاً لا يمكنها إخباركم إن كانت الخدمة لا تزال تعمل بعده. و'هل قبل المالك استثناء المخاطرة؟' مرسوم عمداً كقرار له فرع رفض: فالنظام الذي يتعذّر تصحيحه قرار عمل له مالك وتاريخ انتهاء، لا تذكرة تشيخ بصمت. وخطوة التحقق في النهاية تُغلق الحلقة، لأن تقرير النشر وإعادة الفحص النظيفة ادعاءان مختلفان عن البيئة نفسها.

ما الذي يغطيه هذا المخطط

في هذا القالب

• خمسة مسارات (الأمن / فريق الثغرات، مسؤول التصحيحات، مدير التغيير، مالك التطبيق، ومكتب الخدمة / المستخدمون) عبر ست مراحل: النشرة والنطاق، التقييم وتحديد الأولوية، الاختبار، الاعتماد والجدولة، النشر، والتحقق والتقرير
• استقبال يبدأ بنشرة لا بنتيجة فحص: مسار الأمن يطابق الإصدار مع سجل الأصول ويجيب عن «أصول متأثرة في البيئة؟»، مع طرفية «إغلاق النشرة باعتبارها غير منطبقة» بحيث يُسجَّل الرفض المدروس بدل افتراضه
• تفرّع الأهمية عند قرار 'تصحيح طارئ أم دورة روتينية؟'، الذي يرسل عيباً مُستغَلاً فعلياً إلى مسار مُعجَّل ويجمع كل ما عداه في الدفعة الشهرية، بحيث لا تُعلَّق الدورة المجدولة كلما علا صوت نشرة
• حلقة اختبار لا تستطيع أي أداة اختصارها: يذهب التصحيح إلى بيئة اختبار، ويشغّل مالك التطبيق اختبار الانحدار ويجيب عن «هل يجتاز التصحيح الاختبار؟»، ويصل الإخفاق إلى «هل يُتوقّع إصلاح الموردّ في الوقت المناسب؟» لا إلى إعادة محاولة عمياء
• اعتماد قبل النشر: قرار 'هل التغيير معتمد للنافذة؟' يعيد طلباً ناقصاً ليُستكمل، ومدير التغيير يحجز نافذة الصيانة، ومكتب الخدمة يعلن التوقف قبل تثبيت أي شيء
• نشر بالحلقات بمخرجين: «هل الحلقة التجريبية سليمة؟» يوجّه التراجع إلى «تنفيذ خطة التراجع»، و«هل تؤكد إعادة الفحص تطبيق التصحيح؟» يلاحق الأصول التي فاتت تقرير النشر، ونظام يتعذّر تصحيحه يصل إلى «تسجيل استثناء مخاطرة محدد المدة»

متى تستخدم هذا القالب

• تكتبون إجراء إدارة تصحيحات أو تعيدون كتابته وتحتاجون صورة واحدة لمن يقيّم ومن يختبر ومن يعتمد ومن يتحقق
• التصحيح يستمر في تجاوز موعده النهائي وتحتاجون رؤية هل يتعثر عند الاختبار أم عند لجنة التغيير أم عند نافذة الصيانة
• تهيّئون مجموعات تصحيح وحلقات ونوافذ صيانة في أداة إدارة وتريدون الاتفاق على العملية قبل أن تفرض الأداة عملية عليكم
• تحديث سيئ أسقط خدمة وكان التراجع مرتجلاً، فمحفّز التراجع ومن يملك صلاحية استدعائه يحتاجان الآن أن يكونا على المخطط
• طلب مدقّق أو عميل معرفة كيف تصل تحديثات الأمن إلى أنظمتكم، وكيف تُعتمَد الاستثناءات، وكيف توثّقون أن التصحيحات وصلت فعلاً

كيف تعمل

1. أعيدوا تسمية المسارات لتطابق أدواركم

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

2. دوّنوا محفّز الطوارئ على قرار الفرز

   بجانب 'تصحيح طارئ أم دورة روتينية؟'، دوّنوا ما يجعل تصحيحاً طارئاً بعبارات يستطيع مهندس مناوبة تطبيقها: دليل استغلال فعلي، وأصل مواجه للإنترنت، ولا حل بديل قابل للاستخدام. درجة الخطورة تصف العيب لا تعرّضكم، فسمّوا المدخلات الأخرى التي تستخدمونها — كتالوج CISA للثغرات المُستغَلة المعروفة شائع منها — وحدّدوا من يملك صلاحية القرار خارج ساعات العمل.

3. حدّدوا موعداً نهائياً للمعالجة لكل نطاق خطورة

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

4. وضّحوا ماهية بيئة الاختبار وما يعنيه الاجتياز

   بيّنوا ما تحتويه بيئة الاختبار، ومدى قربها من الإنتاج، وما الذي يتحقق منه مالك التطبيق فعلاً عند «هل يجتاز التصحيح الاختبار؟». سمّوا المعاملات التي يجب أن تظل تكتمل، والواجهات التي يجب أن تظل تُوثِّق، والتقارير التي يجب أن تظل تعمل. فالتصحيح الذي يُثبَّت بسلاسة ويكسر مهمة ليلية قد أخفق الاختبار، ولا يلتقط ذلك سوى فحص محدد بالاسم.

5. عرّفوا الحلقات ومدة النضج والنافذة

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

6. اتفقوا على محفّز التراجع وقاعدة الاستثناء

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

7. اختبروه مقابل نشرتين حقيقيتين

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

الأسئلة الشائعة

ما خطوات عملية إدارة التصحيحات؟

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

ما الفرق بين إدارة التصحيحات وإدارة الثغرات؟

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

ما السرعة التي ينبغي أن تُطبَّق بها التصحيحات الأمنية؟

حدّدوا المواعيد النهائية بحسب نطاق الخطورة والتعرّض، واختاروا أرقاماً يمكنكم الوفاء بها في شهر سيّئ لا أرقاماً طموحة. بعضها محدد لكم مسبقاً. يشترط معيار PCI DSS تثبيت التصحيحات الأمنية الحرجة على الأنظمة المشمولة خلال شهر من إصدارها، مع تطبيق بقية التصحيحات المنطبقة خلال إطار زمني يحدده الكيان ويبرره. وتطلب ضوابط CIS إدارة تصحيحات آلية لأنظمة التشغيل والتطبيقات على أساس شهري أو أكثر تواتراً. وتعمل الوكالات المدنية الاتحادية الأمريكية وفق توجيهات CISA الملزمة بمواعيد أقصر بكثير ومبنية على المخاطر لثغرات كتالوج الثغرات المُستغَلة المعروفة؛ وتلك التوجيهات لا تُلزم المؤسسات الخاصة، لكن الكتالوج مدخل مفيد لترتيب الأولويات لأي جهة. وأياً كانت المواعيد التي تعتمدونها، قيسوا الامتثال من إعادة فحص لا من تقرير نجاح أداة النشر.

ماذا تفعلون حيال الأنظمة التي يتعذّر تصحيحها؟

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

هل إدارة التصحيحات عملية ITIL، ومن يعتمد عملية النشر؟

ليس تحت هذا الاسم. يصف ITIL 4 أربعاً وثلاثين ممارسة إدارية لا عمليات، وإدارة التصحيحات ليست واحدة منها؛ فالعمل يقع عبر تمكين التغيير، وإدارة الإصدارات، وإدارة النشر، مع إدارة أمن المعلومات التي تحدد شهية المخاطرة. وهذه مسألة تسمية لا سبب لإعادة رسم أي شيء. والاعتماد للتثبيت على أنظمة الإنتاج يأتي عادةً عبر تمكين التغيير، وهو ما يمثّله هنا قرار «هل التغيير معتمد للنافذة؟». والترتيب الذي تستقر عليه معظم الفرق نموذج تغيير قياسي معتمد مسبقاً للتصحيح الروتيني المُختبَر الذي يتبع دورة منشورة، وتغيير عادي لكل ما هو غير معتاد أو عالي الأثر، ومسار تغيير طارئ للعيوب المُستغَلة فعلياً، مع تدوين سجل الطوارئ فور ذلك بدل تخطّيه.