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

ملخص

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يصف Have I Been Pwned مجموعة لاحقة تحتوي على معرفات سجلات العملاء وأسماء المستخدمين وعناوين البريد الإلكتروني وكلمات المرور المشفرة والتلميحات، مع تشفير ضعيف لكلمات المرور جعل العديد من كلمات المرور أسهل في الحل. أكد تحليل Troy Hunt العام لمجموعة البيانات أن التلميحات يمكن أن تكشف السر نفسه الذي يهدف نظام كلمة المرور إلى حمايته.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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