Kaseya حوّل تأخير الكشف في الخدمات المدارة إلى مشكلة مساءلة تنتقل إلى العملاء النهائيين

ملخص

• حوّل حادث Kaseya VSA في يوليو 2021 مشكلة البائع ومزود الخدمات المُدارة إلى مشكلة مساءلة في المراحل النهائية لأن العديد من الشركات المتأثرة اعتمدت على إشعار مزود الخدمة واستعادته على الرغم من أنها لم تكن تشغل VSA مباشرة.
• تظهر الأدلة العامة أن Kaseya كانت تعمل مع DIVD من خلال الإفصاح المنسق قبل الهجوم، وأن العديد من الثغرات قد تمت معالجتها، وأن أنظمة محلية معرضة للخطر كانت لا تزال موجودة عندما استغل مهاجمو REvil VSA في 2 يوليو 2021.
• إجراءات Kaseya بعد التنبيه، بما في ذلك إيقاف تشغيل VSA المستضافة، ونصح العملاء المحليين بإيقاف التشغيل، واستدعاء المستجيبين، والاتصال بالشركاء الحكوميين، وإصدار أداة كشف، كانت مهمة. لكنها لا تجيب على كل سؤال حول تقليل التعرض قبل الاستغلال أو مدى سرعة وصول التوجيهات القابلة للاستخدام إلى العملاء النهائيين.
• مقام الضحية متعدد الطبقات. وصفت Kaseya لاحقًا أقل من 60 عميلًا متأثرًا بشكل مباشر، العديد منهم مزودو خدمات مُدارة، وأقل من 1500 شركة في المراحل النهائية. تصف هذه الأرقام مواقف مختلفة في شجرة الاعتماد ولا ينبغي دمجها في رقم واحد.
• معيار الإصلاح هو قابلية الملاحظة: يجب أن يكون النظام البيئي للخدمات المُدارة قادرًا على إظهار من تعرض ومن حذر ومن أُغلق ومن تم تشفيره ومن تلقى تعليمات الاستعادة وما إذا كان العملاء الذين ليس لديهم سيطرة مباشرة على VSA قادرين على رؤية المخاطر في الوقت المناسب لحماية استمرارية العمل.

انتقل تأخير الكشف عبر سلسلة الخدمات

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

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

قال بيان Kaseya الصحفي في 5 يوليو 2021 إن المصادر الداخلية والخارجية نبهت الشركة إلى هجوم محتمل حوالي الساعة 2 بعد الظهر بالتوقيت الشرقي في 2 يوليو وأن الشركة تحركت في غضون ساعة لإيقاف تشغيل بيئة VSA المستضافة ونصح العملاء المحليين بإيقاف تشغيل خوادمهم. كان هذا الإجراء بعد التنبيه مهمًا. من المحتمل أنه حد من المزيد من الانتشار. لكن تحليل المساءلة في المراحل النهائية يسأل سؤالًا أطول: متى أصبحت المخاطر قابلة للمعرفة في كل طبقة، ومدى سرعة تحرك التحذير من الطبقة الأولى التي عرفت إلى الشركات التي ستفقد أنظمتها؟

نشرت Huntress، التي تلقت تقارير مبكرة من شركاء متأثرين، خلاصة الأحداث والدروس المستفادة. وصف حسابها وصول تقارير MSP في وقت متقارب، وارتباط VSA المشترك، ومراحل الحمولة، وإجراءات التنظيف، والتسليم عبر وظائف الإدارة. نشرت Sophos حسابًا فنيًا معاصرًا من جانب نقطة النهاية والاستجابة. هذه الروايات من المستجيبين ليست أعدادًا عالمية للضحايا، لكنها تظهر لماذا كان تأخير الكشف في هذه الحالة موزعًا. أول شركة لاحظت التشفير لم تكن بالضرورة الطرف المخول بإصلاح VSA.

عزز بيان FBI العام حول هجوم Kaseya تعليمات الإيقاف وحث على الإبلاغ. أصدرت CISA وFBI لاحقًا توجيهات مشتركة من خلال ملف PDF الاستشاري هذا، توصي بأداة الكشف، والمصادقة متعددة العوامل، وتقييد اتصالات الإدارة عن بُعد، وحماية VPN أو جدار الحماية للواجهات الإدارية، والنسخ الاحتياطية المحمية، وأقل صلاحية. هذه إجراءات قوية بعد الاكتشاف. المسألة غير المحلولة هي مقدار التعرض الذي كان يمكن تقليله قبل انتهاء الساعة الجنائية.

لذلك لا يمكن قياس تأخير الكشف داخل Kaseya فقط. يجب قياسه عند النقاط التي يمكن فيها لمزودي الخدمة رؤية سلوك VSA غير الطبيعي، حيث يمكن للشركات النهائية التعرف على أن أداة مزودها كانت المسار، وحيث يمكن للجهات العامة تحويل تقارير الحوادث إلى تحذير أوسع. حوّل الحادث منصة إدارة مركزة إلى مشكلة تتابع.

الإفصاح المنسق واجه موعدًا نهائيًا إجراميًا

سجل ما قبل الاستغلال مهم بشكل غير عادي لأنه يقاوم الإدانة السهلة والغفران السهل. قال الإفصاح المحدود لـ DIVD إن مجموعة البحث غير الربحية بدأت فحص VSA في أبريل 2021 وأبلغت Kaseya في 6 أبريل. ذكرت DIVD أن استجابة Kaseya كانت في الوقت المناسب وتفاعلية، وأن الشركة كانت تعمل مع الباحثين على الإصلاحات. هذا مهم. لا تدعم الأدلة العامة ادعاءً بسيطًا بأن البائع تجاهل التقارير المسؤولة.

يُظهر سجل القضية الذي تحتفظ به DIVD الجانب الآخر من الجدول الزمني. تضمنت القضية ثغرات متعددة. تم إصلاح بعضها قبل يوليو. تلقت البيئة المستضافة لـ Kaseya إصلاحات ذات صلة قبل الهجوم. كانت خوادم VSA المحلية لا تزال بحاجة إلى إجراء عندما بدأ حادث الفدية. نشرت DIVD لاحقًا تفاصيل الثغرات الكاملة، بما في ذلك CVE-2021-30116، ويسجل إدخال CVE-2021-30116 في NVD الآن أنه تم استغلال المشكلة في البرية.

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

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

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

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

كشفت تعليمات الإيقاف عن الانقسام المحلي

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

هذه ليست مجرد إزعاج. كل دقيقة في التتابع كانت مهمة لأن المهاجمين استخدموا وظائف إدارة موثوقة. كان على رسالة Kaseya أن تصل إلى قائد أو مسؤول MSP، وكان على ذلك الشخص أن يفهم أن "إيقاف VSA" يفوق التكلفة العادية لتعطيل إدارة العميل، وكان على MSP التأكيد على أن الإجراءات الضارة لم تكن بالفعل في قائمة الانتظار أو نُفذت. ثم احتاج العملاء النهائيون إلى معرفة ما إذا كانت أنظمتهم آمنة أو مشفرة أو منفصلة أو في انتظار الاستعادة. احتوى التتابع على خطوات فنية وتجارية واتصالات مع العملاء.

أدركت توجيهات CISA-FBI المشتركة أن الإجابة لم تكن مجرد "تطبيق التصحيح". شددت على إيقاف تشغيل خوادم VSA، وتشغيل أداة الكشف، والحفاظ على النسخ الاحتياطية، وتقييد اتصالات الإدارة عن بُعد، واستخدام أقل صلاحية. تحدثت هذه التوجيهات إلى الواقع المحلي: يمكن أن يظل خادم الإدارة المخترق خطيرًا حتى بعد الإشعار العام الأول إذا أعاد المشغلون التشغيل دون مسح الحالة الضارة أو تشديد التعرض.

ذكر تقرير SOC 3 اللاحق لـ Kaseya أنه تأثر 57 عميلًا محليًا. التقرير مفيد كسياق ضمان تقدمه الشركة، لكنه ليس سردًا مستقلاً كاملاً للحادث لكل شركة في المراحل النهائية. ذكرت رويترز، التي نقلتها Investing.com، تقدير الرئيس التنفيذي أن 800 إلى 1500 شركة تأثرت. هذه الأرقام غير قابلة للتبادل. أحدهما يحسب العملاء المباشرين في طبقة واحدة. الآخر يحسب المنظمات في المراحل النهائية في طبقة أخرى.

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

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

غير المقام النهائي الضرر

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

أصبحت سلسلة المتاجر السويدية Coop رمزًا عامًا لفقدان الاستمرارية في المراحل النهائية. نقلت Investing.com تقارير رويترز بأن هجومًا إلكترونيًا ضد مزود خدمات تكنولوجيا معلومات أمريكي أجبر السلسلة السويدية على إغلاق 800 متجر. وصفت تقارير لاحقة شركات متأثرة تواجه استعادة قد تستغرق أسابيع. لا ينبغي التعامل مع هذه الحسابات على أنها قائمة كاملة بالضحايا. تظهر كيف يمكن لاختراق الإدارة عن بُعد أن يصل إلى الخدمات العامة التي يواجهها المستهلكون كأبواب مغلقة أو مدفوعات غير متاحة أو عمليات محلية متقطعة.

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

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

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

أصدرت CISA وNSA وFBI والشركاء الدوليون لاحقًا توجيهات أوسع لحماية علاقات مزودي الخدمات المُدارة والعملاء، أعلنت عنها CISA في هذا الإشعار الاستشاري. تعكس تلك التوجيهات نقطة نظامية: أمن MSP ليس مجرد مشكلة خاصة لـ MSP. إنها قضية استمرارية مشتركة للعملاء الذين يرثون ثقتها.

لم يحل الإجراء القانوني محل أدلة الإصلاح

أنتج حادث Kaseya أيضًا سجلات إنفاذ القانون. أعلنت وزارة العدل في 2021 أنه تم القبض على مواطن أوكراني وتوجيه الاتهام إليه فيما يتعلق بهجوم الفدية. أعلنت Europol أنه تم كشف النقاب عن خمسة عملاء مرتبطين بـ Sodinokibi/REvil. أعلنت وزارة العدل لاحقًا أنه تم الحكم على أحد عملاء Sodinokibi/REvil لدور أوسع في مخطط الفدية. هذه السجلات مهمة لمساءلة المهاجمين.

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

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

يعطي إصدار NIST SP 800-161 Rev. 1 مفردات أوسع لمخاطر سلسلة التوريد. يعامل الموردين والمنتجات والخدمات وضوابط دورة الحياة كجزء من حوكمة الأمن السيبراني. يظهر حادث Kaseya لماذا يجب أن تتضمن هذه المفردات أدلة تشغيلية للخدمات المُدارة. لا يمكن لفريق المشتريات ببساطة أن يسأل عما إذا كان MSP يستخدم منصة إدارة عن بُعد. يجب أن يسأل كيف يتم تعريض تلك المنصة، وكيف يتم مراقبتها، ومن يمكنه تعطيلها، وكيف يعمل تقسيم العملاء، وكيف يتم عزل النسخ الاحتياطية، وكيف يتم الإبلاغ عن الحوادث، وكيف سيتم مشاركة الأدلة.

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

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

قابلية الملاحظة هي معيار الإصلاح

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

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

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

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

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

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

تحتاج سلسلة الإشعار إلى هدف مستوى الخدمة الخاص بها

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

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

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

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

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

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

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

الإيقاف المسبق هو سيطرة حوكمة

كشفت تعليمات Kaseya بإيقاف تشغيل خوادم VSA المحلية عن حقيقة غير مريحة: إجراء آمن أمنيًا يمكن أن يكون إجراءً معطلًا للأعمال. إيقاف منصة الإدارة عن بُعد يمكن أن يقلل من وصول المهاجم، لكنه يمكن أيضًا أن يزيل الطريقة الأساسية لـ MSP لدعم العملاء. إذا لم يسبق لـ MSP تفويض من يمكنه اتخاذ هذا القرار، فقد يتعطل الاستجابة في أسوأ لحظة ممكنة.

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

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

تتفاعل سلطة الإيقاف أيضًا مع النسخ الاحتياطية. يعتمد الاستجابة للفدية على نسخ احتياطية قابلة للاسترداد ومحمية، لكن العديد من مزودي الخدمة يديرون النسخ الاحتياطية من خلال نفس النظام البيئي الإداري الذي يدعم الخدمة الروتينية. إذا كان مستوى التحكم مشبوهًا، يجب أن يعرف المستجيبون ما إذا كانت وحدات تحكم النسخ الاحتياطي وبيانات الاعتماد والتخزين وإجراءات الاستعادة مستقلة. شددت توجيهات CISA-FBI على النسخ الاحتياطية المعزولة أو المحمية بطريقة أخرى لأن اختراق الإدارة يمكن أن يهدد الاستعادة وكذلك الإنتاج.

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

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

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

أدلة المراحل النهائية جزء من سجل المنتج

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

مشكلة الأدلة الأولى هي هوية السلسلة المتأثرة. أي عميل Kaseya قام بتشغيل مثيل VSA المتأثر؟ هل كان ذلك العميل MSP؟ ما هي بيئات العملاء التي أدارها مثيل VSA ذلك؟ أي الوكلاء سجلوا الدخول خلال نافذة التعرض؟ أي الإجراءات نُفذت؟ أي نقاط النهاية تلقت الحمولات؟ أي نقاط النهاية كانت غير متصلة ثم معرضة للخطر عند إعادة الاتصال؟ بدون هذه السلسلة، تصبح الأعداد غامضة وتصبح الاستعادة غير متساوية.

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

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

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

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

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

يجب أن تكشف العقود عن مستوى التحكم الخفي

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

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

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

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

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

ملاحظة طباعية

المجاهيل المتبقية

لا يحدد السجل العام كل طلب استغلال، أو كل MSP متأثر، أو كل تأثير على الأعمال النهائية، أو كل طابع زمني لإشعار العميل. لا يثبت أن المهاجمين عرفوا الثغرات من عملية الإفصاح المنسق. الاكتشاف الموازي محتمل ولا ينبغي تحويله إلى اتهام غير مدعوم. لا يكشف عن كل إجراء مؤقت قبل الهجوم أو كل مشغل تم الاتصال به قبل 2 يوليو. لا يتحقق بشكل مستقل من فعالية كل إجراء لاحق لـ Kaseya أو MSP.

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

السؤال المساءل عملي ومباشر. عندما يكون مستوى تحكم الخدمة المُدارة في خطر، هل يمكن لكل طرف سيتحمل العواقب أن يرى ما يكفي، في الوقت المناسب، للتحرك؟ في يوليو 2021، كانت الإجابة متفاوتة. تحرك بعض اللاعبين بسرعة بمجرد معرفة الهجوم. لا تزال العديد من المنظمات النهائية تعتمد على اكتشاف شخص آخر، وقرار إيقاف شخص آخر، وشرح شخص آخر. هذه هي مشكلة المساءلة النهائية التي جعلها Kaseya مرئية.