تعرض رموز GitHub جعل إصلاح Slack اختبارًا لمساءلة نقل التكلفة

ملخص

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

يمكن للرمز أن ينقل الثقة أسرع مما يمكن للعقد أن يفسرها

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

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

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

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

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

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

لم يكن الحادث اختراقًا لـ GitHub

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

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

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

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

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

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

الوصول إلى المستودعات ليس مجرد تعرض للشيفرة المصدرية

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

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

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

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

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

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

نطاق الرمز هو قرار إداري، وليس تفضيل مطور

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

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

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

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

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

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

يجب أن يفصل إشعار العميل بين "لا بيانات" و"لا إجراء"

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

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

يظهر تقرير Cybersecurity Dive بعنوانSlack says employee tokens stolen, GitHub repositories breached، وملخص Wired الأمني،Slack says some private GitHub repositories were accessed، كيف تضغط الملخصات العامة الحوادث بسرعة إلى سرديات أبسط. هذا الضغط مفيد للأخبار، لكن العملاء يحتاجون إلى النسخة التشغيلية المفصلة. "تم الوصول إلى المستودعات" ليس مثل "تم تعرض بيانات العملاء". "لا بيانات عملاء" ليس مثل "لم يتم العثور على بيانات اعتماد من أي نوع". "تم تدوير الرموز" ليس مثل "تمت مراجعة كل تكامل فرعي".

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

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

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

إرشادات البرمجيات الآمنة تحول حادثة الرمز إلى سؤال واجب المزود

إنإطار تطوير البرمجيات الآمنة SP 800-218من NIST ليس تقرير حادثة عن Slack. إنه مفيد لأنه يشرح لماذا يجب على منتجي البرمجيات حماية الأكواد، والتحكم في بيانات الاعتماد، والتحقق من سلامة الإصدار، والاستجابة للثغرات. بيئة مستودع مزود التعاون هي جزء من سلسلة ثقة المنتج. إذا تم الوصول إلى مستودع مصدر من قبل مهاجم، سيسأل العملاء ما إذا كان المنتج الذي يستخدمونه يمكن أن يتأثر.

يوفر NIST SP 800-204D،استراتيجيات دمج أمان سلسلة توريد البرمجيات في خطوط أنابيب DevSecOps CI/CD، مفردات أخرى، على الرغم من أن مقالًا عامًا لا ينبغي أن يبالغ في صلته بحدث Slack المحدد. الدرس المهم هو أن بيانات الاعتماد والتحكم في المصدر وأتمتة البناء وإدارة الاعتماديات وضوابط الإصدار متصلة. يمكن أن تصبح حادثة رمز في التحكم بالمصدر مشكلة مخاطر منتج إذا كانت الأسرار أو سلطة البناء أو وصول توقيع الإصدار قابلة للوصول.

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

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

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

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

يجب أن يثبت سجل الإصلاح الإغلاق، وليس النشاط فقط

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

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

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

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

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

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

ملاحظة حول التيبوغرافيا

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

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

المجهول المتبقي والسؤال المسؤول

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

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

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

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

لماذا يهم تصنيف نقل التكلفة؟

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

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

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

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

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

عملاء المؤسسات يحتاجون إلى سجل مخاطر مورد قابل للاستخدام

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

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

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

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

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

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

يجب أن تكون حوكمة الرموز مرئية لمجلس الإدارة

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

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

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

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

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

ملاءمة التكامل تحمل مساءلة عامة

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

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

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

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

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