الملخص

  • كشفت JetBrains عن CVE-2023-42793 في سبتمبر 2023؛ وأبلغت CISA وMicrosoft لاحقًا عن نشاط استغلال، بما في ذلك استخدام خوادم TeamCity كنقاط دخول للاختراق النهائي.
  • سؤال المساءلة المركزي هو: من كان لديه السيطرة العملية على تعرض TeamCity، سرعة التصحيح، هوية خادم البناء، تخزين الأسرار، توقيع القطع، مخاطر العملاء النهائيين، وإعادة البناء بعد الاستغلال؟
  • الجذور العملية للقضية ليست تسمية واحدة مثل اختراق أو انقطاع أو ثغرة أو فشل البائع. يركز السجل على ثغرة تجاوز المصادقة، خوادم CI/CD المعرضة للإنترنت، اعتماد التحديثات، تخزين بيانات اعتماد البناء، ثقة الشفرة المصدرية والقطع، استغلال الجهات الخبيثة، والأدلة اللازمة لإثبات سلامة البناء بعد الاختراق.
  • واجهت فرق البرمجيات، والبائعون، والعملاء المؤسسيون، ومستهلكو المصادر المفتوحة، والحسابات السحابية، وفرق الأمن احتمال أن يصبح خادم البناء المخترق مسارًا موثوقًا للتسليم للهجمات اللاحقة.
  • يدعم السجل نتيجة مساءلة عالية الثقة حول واجبات السيطرة وفجوات الأدلة. لا يدعم افتراض حقائق تظل خاصة، مثل كل إدخال سجل، كل تأثير على العملاء، كل قرار داخلي، أو كل خسارة نهائية.

سجل الأدلة وكيفية استخدامه

تتعامل هذه المقالة مع السجل العام كأدلة متعددة الطبقات بدلاً من سرد واحد رئيسي. تُستخدم إشعارات الشركة لما ذكرته JetBrains, s. r. o. أنها وجدته أو غيرته أو نصحت به. تُستخدم مواد الحكومة والجهات التنظيمية والثغرات وبحوث الأمن لتأطير واجبات السيطرة حول الحادثة. يُستخدم التقارير الثانوية فقط حيث تحافظ على البيانات العامة أو التسلسل الزمني أو سياق الأطراف المتأثرة غير المتاحة بشكل آخر في وثيقة أولية مستقرة.

#السجل العامالاستخدام في هذا التحليل
1مدونة JetBrains TeamCity حول CVE-2023-42793إشعار البائع الأساسي المستخدم للثغرة والإصدارات المعدلة وسياق التخفيف.
2صفحة مشكلات الأمان التي تم إصلاحها لدى JetBrainsفهرس مشكلات أمان البائع المستخدم لسياق أمان المنتج.
3إدخال NVD لـ CVE-2023-42793بيانات ومراجع الثغرة العامة.
4كتالوج CISA للثغرات المستغلة لـ CVE-2023-42793سياق حالة الاستغلال المعروف.
5تنبيه CISA حول تحديثات أمان JetBrainsسياق تنبيه حكومي.
6تقرير Microsoft حول استغلال Diamond Sleet وOnyx Sleet لـ TeamCityسياق استخبارات التهديدات للاستغلال والسلوك بعد الاختراق.
7استجابة Rapid7 للتهديدات الناشئةتحليل المدافع لتجاوز المصادقة الحرج.
8تحليل SonarSource لثغرة TeamCityسياق التحليل الفني.
9تحليل Horizon3.ai لثغرة TeamCityسياق الاستغلال الفني.
10نموذج إقرار تطوير البرمجيات الآمنة من CISAسياق ضمان سلسلة توريد البرمجيات.
11إطار تطوير البرمجيات الآمنة من NISTسياق التطوير الآمن وسلامة البناء.
12إطار SLSAسياق مستويات سلسلة التوريد للقطع البرمجية.
13بطاقة أداء OpenSSFسياق تقييم سلسلة توريد البرمجيات.
14ضوابط الأمان الأساسية من CISسياق ضوابط الوصول والتسجيل والمخزون والثغرات.
15إطار الأمن السيبراني من NISTمفردات إدارة المخاطر.
16تقنية MITRE ATT&CK لأدوات نشر البرمجياتسياق تقنية إساءة استخدام أدوات النشر.

الحادثة تتعلق في الحقيقة بالسيطرة

جعلت JetBrains TeamCity خوادم البناء سطح مساءلة لسلسلة توريد البرمجيات لأن الحادثة وضعت السيطرة العملية تحت ضوء أكثر سطوعًا مما فعل العنوان. يبدأ السجل العام بمدونة JetBrains TeamCity حول CVE-2023-42793 ويعززها صفحة مشكلات الأمان التي تم إصلاحها لدى JetBrains و إدخال NVD لـ CVE-2023-42793. هذه السجلات مهمة لأنها تحدد الفرق بين قصة أمان غامضة ومجموعة من الواجبات التشغيلية: العثور على الأنظمة المتضررة، تحديد البيانات أو مواد الثقة التي يمكن الوصول إليها، إخطار الأشخاص الذين يجب أن يتصرفوا، وإثبات أن مسار المخاطر القديم قد أُغلق.

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

بالنسبة لـ JetBrains, s. r. o.، تقع القضية العامة بالتالي في سطح السيطرة: تعرض CI/CD، تجاوز المصادقة، أسرار البناء، ثقة القطع، اعتماد التحديثات، استغلال الجهات الخبيثة، وأدلة إعادة البناء. هذه ليست تفاصيل علاقات عامة. إنها الآلية التي ينمو أو يتقلص بها الضرر. يمكن لاختراق قصير أن ينتج مخاطر هوية طويلة الأمد. يمكن لثغرة قديمة أن تصبح فشل استمرارية حي. يمكن لحساب بائع أن يصبح مشكلة حساب عميل. يمكن لتذكرة دعم منصة أن تحمل مواد أكثر حساسية من خدمة الإنتاج نفسها. تستخدم المقالة هذه العدسة في جميع الأنحاء.

التسلسل الزمني جزء من الأدلة

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

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

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

بيانات الثقة أو كائن الثقة لم يكن عرضيًا

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

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

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

مسؤولية البائع تتبع الضوابط عالية الرافعة

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

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

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

مسؤولية العميل والمشغل لم تختفي

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

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

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

التجزئة هي الحدود بين الحادثة والتسلسل

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

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

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

يجب أن يخبر الإشعار المستلمين بما يمكنهم فعله

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

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

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

سطح الإساءة يمتد إلى ما بعد الاختراق المؤكد

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

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

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

يجب أن تدعم الأدلة الجنائية قرار الثقة

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

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

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

الحوافز الاقتصادية تفسر نقص الاستثمار

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

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

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

يجب أن يبقى سجل الحوكمة بعد دورة الأخبار

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

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

بالنسبة لـ JetBrains, s. r. o.، الدرس الدائم ليس أن كل ضرر محتمل قد حدث. إنها أن الحادثة العامة كشفت عن فئة سيطرة ستتكرر. قد تتضمن الحالة التالية منتجًا أو جغرافيا أو مهاجمًا أو مجموعة بيانات مختلفة. سيكون الاختبار هو نفسه: هل يمكن للمنظمة إظهار من يتحكم في المسار الخطير، وماذا فعلوا، ولماذا يجب على الغرباء الوثوق بالنتيجة؟

ما الذي سيغير التقييم

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

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

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

الأدلة التي يجب على العملاء الحفاظ عليها قبل أن يتلاشى الذاكرة

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

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

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

نافذة إجراء العميل هي واجب قابل للقياس

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

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

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

ادعاءات الإصلاح تحتاج إلى دليل دائم

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

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

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

المزودون المدارون يجلسون داخل سلسلة الواجب

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

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

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

تقليل البيانات يغير نصف قطر الانفجار

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

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

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

يجب أن تطلب رقابة مجلس الإدارة أدلة السيطرة، وليس فقط الحالة

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

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

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

يجب أن تغير الحادثة أسئلة المشتريات المستقبلية

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

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

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

درس المساءلة قابل لإعادة الاستخدام

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

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

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

الاستنتاج في المصلحة العامة

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

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

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

حد أدلة إضافي

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

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

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