أدوبي جعلت شيفرة المصدر وسجلات العملاء اختبارًا مشتركًا للمساءلة عن بيانات الاعتماد

الملخص

• صرحت أدوبي علنًا في أكتوبر 2013 بأن المهاجمين تمكنوا من الوصول إلى معرفات عملاء أدوبي وكلمات المرور المشفرة وحقول معينة لطلبات العملاء وبطاقات الدفع وشيفرة المصدر لعدة منتجات.
• سؤال المساءلة المركزي هو: من كان يمتلك السيطرة العملية على تجزئة كلمات المرور، نطاق بيانات الدفع، الوصول إلى مستودعات الشيفرة المصدرية، توجيهات إعادة تعيين العملاء، توقيت إشعار الاختراق، والدليل على أن الشيفرة المسروقة لم توسع نطاق المخاطر على العملاء؟
• اتسعت السجلات العامة لاحقًا بعد العدد الأولي الذي أعلنته أدوبي للعملاء، حيث أفادت KrebsOnSecurity بتأكيد أدوبي لوجود حوالي 38 مليون مستخدم نشط بكلمات مرور مشفرة صالحة ضمن النطاق، وأدرج موقع Have I Been Pwned 152.4 مليون حساب متأثر في مجموعة بيانات الاختراق.
• اضطر العملاء والمطورون ومديرو المؤسسات وفرق الاستجابة لبطاقات الدفع ومراجعو أمن المنتجات للتصرف دون الاطلاع على سجلات المستودعات الداخلية لأدوبي أو تصميم تخزين كلمات المرور أو أدلة نظام الدفع أو خريطة التعرض لكل عميل على حدة.
• يدعم السجل استنتاجًا للمساءلة بثقة عالية حول واجبات التحكم وفجوات الأدلة. وهو لا يدعم اختلاق حقائق خاصة حول كل نظام داخلي أو خطوة للمهاجمين أو بناء للمنتج أو خسارة للعميل أو تغيير في المستودع.

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

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

إطار المساءلة أضيق من اللوم وأوسع من إشعار الاختراق

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

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

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

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

ما يثبته السجل العام

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

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

تضيف السلطات العامة والسجلات الخارجية طبقات أخرى. حذرت CISA العملاء من مراقبة نشاط الحسابات الاحتيالي. وصف تقرير KrebsOnSecurity الأولي كنزًا من شيفرات المصدر وأورد تصريحات مقابلة أدوبي حول التحقيق، ومجموعة المنتجات المحتملة، ومراجعة سلامة المنتجات. فيما بعد، أفادت KrebsOnSecurity بتأكيد أدوبي أن المهاجمين حصلوا على وصول إلى معرفات أدوبي وكلمات مرور مشفرة صالحة لحوالي 38 مليون مستخدم نشط، مع بيانات حسابات غير نشطة وغير صالحة واختبارية لا تزال قيد المراجعة. أدرج موقع Have I Been Pwned لاحقًا اختراق أدوبي كـ 152.4 مليون حساب متأثر وحدد عناوين البريد الإلكتروني وأسماء المستخدمين وكلمات المرور وتلميحات كلمات المرور.

أعلن المدعون العامون للولايات لاحقًا عن تسوية متعددة الولايات لحل الدعاوى الناشئة عن اختراق 2013.

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

لماذا يهم موضوع الثقة

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

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

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

حول تخزين كلمات المرور هوية العميل إلى أول عبء عملي

كان أول إجراء من أدوبي مواجه للعملاء هو حملة إعادة تعيين كلمات المرور للحسابات المعنية. كان هذا هو النوع الصحيح من الحماية الفورية للعملاء، لكنه كشف أيضًا عن سؤال أعمق: لماذا كان مخزن الاعتمادات موضوعًا لمخاطر قابلة لإعادة الاستخدام بعد السرقة؟ وصف إعلان أدوبي كلمات المرور بأنها مشفرة. ركز التحليل العام اللاحق على المخاطر الناتجة عن نهج تخزين كلمات المرور وتلميحات كلمات المرور بالنص الواضح. يصف موقع Have I Been Pwned مجموعة بيانات لاحقة تحتوي على مُعرّفات سجلات العملاء وأسماء المستخدمين وعناوين البريد الإلكتروني وكلمات المرور المشفرة والتلميحات، مع تشفير ضعيف لكلمات المرور جعل العديد من كلمات المرور أسهل في الحل.

شدد تحليل Troy Hunt العام لمجموعة البيانات على أن التلميحات يمكن أن تكشف السر الذي تهدف آلية كلمة المرور لحمايته.

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

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

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

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

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

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

كانت شيفرة المصدر خطرًا على الثقة بالمنتج، وليس مجرد ملكية فكرية

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

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

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

غيرت ساعة الإشعار ما يمكن للعملاء فعله

سجل التوقيت مهم لأن الإفصاح ينقل العمل. جاء إعلان أدوبي العام الأولي في 3 أكتوبر 2013. دفع تحذير CISA في نفس اليوم الوعي العام إلى العملاء. أعطى الإشعار الأول عددًا أوليًا للعملاء ووصف إعادة تعيين كلمات المرور وإشعارات بنوك الدفع ومراجعة شيفرة المصدر. لاحقًا في أكتوبر، أفادت KrebsOnSecurity بتأكيد أدوبي أن حوالي 38 مليون مستخدم نشط بكلمات مرور مشفرة صالحة تأثروا، بالإضافة إلى بيانات حسابات غير نشطة وغير صالحة واختبارية لا تزال قيد التحقيق. عكس موقع Have I Been Pwned لاحقًا مجموعة بيانات اختراق عامة أكبر بكثير.

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

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

كانت توجيهات إعادة التعيين للعملاء ضرورية ولكنها غير كاملة بالتصميم

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

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

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

واجه مديرو المؤسسات مشكلة مختلفة عن العملاء الأفراد

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

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

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

ظهرت سيادة البيانات ومحليتها من خلال شبكة الإشعارات

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

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

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

غيرت التقارير الثانوية السجل القابل للاستخدام

دور KrebsOnSecurity في سجل أدوبي مهم لأن الفهم العام للاختراق لم يُبن فقط من إعلان أدوبي. وصف تقرير Krebs الأولي اكتشاف كمية كبيرة من شيفرات المصدر وأورد تصريحات مقابلة أدوبي حول التحقيق. فيما بعد، أفاد تقرير Krebs اللاحق بأن أدوبي أكدت أن حوالي 38 مليون مستخدم نشط بكلمات مرور مشفرة صالحة ضمن النطاق وكانت لا تزال تحقق في بيانات الحسابات غير النشطة وغير الصالحة والاختبارية. بعدئذٍ، قدم موقع Have I Been Pwned وTroy Hunt للجمهور نظرة دائمة لبيانات الحسابات وتلميحات كلمات المرور.

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

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

يختلف عبء إثبات شيفرة المصدر عن عبء إثبات الاعتمادات

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

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

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

أبقى الإجراء التنظيمي القضية حية بعد الدورة الإخبارية

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

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

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

ما لا يثبته السجل العام

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

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

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

تطلب التعافي أكثر من مجرد استعادة الحسابات

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

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

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

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

سجل عام أقوى كان سيفصل بين كل سطح متأثر

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

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

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

دروس للاعتماد على الخدمات السحابية

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

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

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

غيرت دورة حياة البرمجيات والارتباط بها من نفوذ التعافي

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

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

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

يجب على المجالس معاملة تصميم الاعتمادات كمسألة حوكمة

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

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

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

يجب على المشترين طلب الأدلة قبل الحدث

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

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

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

يجب أن تتبع لغة العقد السطح المكشوف

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

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

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

مؤشرات تشغيلية تجعل ادعاءات التعافي قابلة للاختبار

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

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

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

سؤال التكرار أوسع من أدوبي

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

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

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

الخلاصة بالنسبة للمساءلة

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

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

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

قرار القارئ

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

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

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