KASEYA يحوّل تأخير اكتشاف الخدمات المُدارة إلى مشكلة مسؤولية تجاه المصب

ملخص

• حوّلت حادثة KASEYA VSA في يوليو 2021 مشكلة المزوّد ومقدم الخدمات المُدارة إلى مشكلة مسؤولية تجاه المصب، نظرًا لاعتماد العديد من الشركات المتأثرة على إخطارات MSP واستعادتها على الرغم من أنها لا تشغّل 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:00 مساءً بالتوقيت الشرقي يوم 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 يوليو؟ ما هي القيود المؤقتة الدقيقة التي تم طلبها أو التوصية بها؟ هل تم دفع واجهات الإدارة خلف VPN أو قواعد جدار حماية مخصصة؟ هل طُلب من العملاء المحليين ذوي المخاطر العالية الإيقاف حتى وصول التصحيح؟ كيف تحققت KASEYA من أن الأنظمة المكشوفة المعروفة قد غيرت حالتها؟ ما هي بيانات التتبع، إن وجدت، التي كانت موجودة لتمييز الإنشاء المشبوه للإجراءات عن عمل الإدارة عن بُعد العادي؟ لا تفترض هذه الأسئلة الإهمال. إنها تحدد الأدلة اللازمة لتقييم ما إذا كانت التحذيرات قبل الاستغلال تتوافق مع نصف قطر تأثير VSA.

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

كشفت نصائح الإيقاف الفجوة المحلية

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

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

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

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

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

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

عدّل مقام المصب الضرر

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

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

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

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

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

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

لم يحل عمل إنفاذ القانون محل أدلة الإصلاح

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

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

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

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

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

لا يزيل أي نجاح لإنفاذ القانون الحاجة إلى هذه الملفات. يمكن القبض على منتسب لبرنامج فدية بينما تفتقر شركة إلى نسخة احتياطية قابلة للاسترداد. يمكن لمزوّد نشر تصحيح بينما لم يصل 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 يمكن أن يفاقم الضرر. نسخ احتياطية ضعيفة من العميل يمكن أن تطيل الاسترداد. على العكس، تحذير من المزوّد وإيقاف من MSP وخطة استمرارية من العميل يمكن أن تقلل الضرر. يجب أن تكون المسؤولية دقيقة بما يكفي لنسب الفضل واللوم إلى الضوابط الصحيحة.

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

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

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

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

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

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

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

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

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

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

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

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