جعلت Zendesk بيانات الدعم القديمة اختبارًا لثقة العملاء والمساءلة

ملخص

• تقول الأسئلة الشائعة المحدّثة لـ Zendesk إنها تلقت تنبيهًا في عام 2019 بشأن مسألة أمنية تتعلق بحسابات عملاء Support و Chat التي تم تفعيلها قبل نوفمبر 2016، وأن معلومات حسابات العملاء تم الوصول إليها دون تصريح قبل ذلك التاريخ.
• السؤال المركزي للمساءلة هو: من كان لديه السيطرة العملية على الاحتفاظ بقواعد بيانات الدعم، والتعرض للاعتماديات والرموز، وتوقيت إخطار العملاء، وتجزئة المستأجرين، وإعادة بناء التدقيق، وإثبات أن محتوى التذاكر كان محدودًا؟
• وصفت التقارير العامة المبكرة المجموعة المتضررة بنحو 10,000 حساب من حسابات Support و Chat؛ بينما تحدد الأسئلة الشائعة الأحدث لـ Zendesk حوالي 15,000 حساب وتقول إن معلومات مصادقة معينة تم الوصول إليها لمجموعة تضم حوالي 7,000 حساب عميل.
• كان على العملاء الذين يستخدمون Zendesk للدعم والدردشة ومراكز المساعدة والتكاملات وعمليات العملاء تحديد ما إذا كانت بيانات الدعم القديمة لا تزال قادرة على كشف الوكلاء والمستخدمين النهائيين والتكاملات والشهادات أو ثقة العملاء في المراحل اللاحقة.
• يدعم السجل نتيجة مساءلة عالية الثقة بشأن الاحتفاظ والمصادقة والإخطار وحدود الأدلة. وهو لا يدعم اختلاق حقائق خاصة حول كل مستأجر أو كل تذكرة أو كل اعتماد تطبيق أو كل مفتاح TLS أو كل قرار عميل لاحق.

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

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

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

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

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

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

كان لكل طرف دور، ولكن Zendesk وحدها كانت قادرة على جعل حدود الخرق مرئية من جانب الخدمة.

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

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

تثبت الأسئلة الشائعة المحدّثة لـ Zendesk عدة نقاط ثابتة. قالت الشركة إن طرفًا ثالثًا نبهها بشأن مسألة أمنية قد تكون أثرت على منتجي Support و Chat وحسابات العملاء التي تم تفعيلها قبل نوفمبر 2016. وقالت إن فرق الأمن في Zendesk وخبراء الأدلة الجنائية الخارجيين حققوا في الأمر. وقالت إن معلومات تخص نسبة صغيرة من العملاء تم الوصول إليها قبل نوفمبر 2016. تحدد الأسئلة الشائعة الحالية حوالي 15,000 حساب من حسابات Support و Chat، بما في ذلك حسابات تجريبية منتهية الصلاحية وحسابات لم تعد نشطة، تم الوصول إلى معلوماتها دون تصريح.

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

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

تلتقط التقارير الثانوية الشكل العام الأول للحادث. أفادت CyberScoop و SecurityWeek و BleepingComputer في أكتوبر 2019 أن Zendesk كشفت عن خرق قديم أثر على ما يقرب من 10,000 حساب. هذا الاختلاف في العدد ليس سببًا لاختيار سجل واحد وتجاهل الآخر. إنه سبب لقراءة الحادث على أنه متعدد المراحل. انتقل الفهم العام من تأطير أولي يضم 10,000 حساب إلى أسئلة شائعة لاحقة تحتوي على تفاصيل إضافية عن الحسابات ومواد المصادقة.

عدم تطابق الأعداد العامة هو بحد ذاته دليل مساءلة

يستخدم البيان الخاص بهذه المقالة السجل العام الذي قالت فيه Zendesk في عام 2019 إنها حددت وصولاً غير مصرح به مرتبطًا بما يقرب من 10,000 حساب من حسابات Support و Chat من حادث عام 2016. كان هذا هو التأطير العام المبكر. تقول الأسئلة الشائعة الحالية لـ Zendesk حوالي 15,000 حساب وتحدد أيضًا حوالي 7,000 حساب عميل مع وجود معلومات مصادقة معينة في النطاق. كلا الأمرين مهمان. يُظهر الرقم المبكر ما كان على العملاء والمراسلين التعامل معه أولاً. يُظهر الرقم المحدّث أن السجل العام أصبح لاحقًا أكثر تفصيلاً وأكثر تعقيدًا.

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

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

موضوع الثقة كان علاقة الدعم

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

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

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

الاحتفاظ القديم جعل الحسابات القديمة ذات صلة تشغيلية

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

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

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

تطلبت تجزئات كلمات المرور خطة عمل من العميل

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

عالجت خطة تدوير كلمات المرور من Zendesk فئة المخاطر هذه. تقول الأسئلة الشائعة إن التدوير طُبق على وكلاء ومستخدمين نهائيين معينين تم إنشاؤهم قبل 1 نوفمبر 2016، حيث لم تتمكن Zendesk من تحديد أن المستخدم قد غير كلمة المرور منذ ذلك التاريخ وحيث لم يكن المستخدم يستخدم الدخول الموحد (SSO). أثر التدوير أيضًا على المنتجات التي تشارك المصادقة مع Support، بما في ذلك Guide و Talk و Explore. هذه تفصيلة مساءلة لأنها تخبر العملاء بمن كان عليه التصرف ولماذا.

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

جعلت مواد المصادقة القضية أكبر من مجرد إعادة تعيين كلمات المرور

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

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

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

حولت التطبيقات والتكاملات الدعم إلى نظام متصل

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

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

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

خلقت مواد شهادة TLS عبء إثبات منفصل

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

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

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

محتوى التذكرة كان الحدود التي احتاجها العملاء أكثر

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

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

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

غيرت أدوار المتحكم والمعالج عبء عمل الإخطار

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

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

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

تجزئة المستأجرين كانت طبقة الضمان غير المرئية

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

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

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

إعادة بناء التدقيق كانت جزءًا من الاسترداد، وليس عملاً خلفيًا

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

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

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

سجلات الثقة الحالية هي سياق مفيد، وليس دليلاً بأثر رجعي

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

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

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

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

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

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

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

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

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

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

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

يجب على المشترين السؤال عن بيانات الدعم القديمة قبل التجديد

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

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

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

يجب على مجالس الإدارة معاملة أنظمة الدعم كبنية تحتية لثقة العملاء

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

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

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

يجب أن تتبع لغة العقد أسطح منصة الدعم

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

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

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

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

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

بالنسبة لبيانات التذاكر، يمكنه ذكر أي المخازن تمت مراجعتها وما الدليل الذي يدعم الاستبعاد.

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

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

سؤال التكرار أوسع من Zendesk

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

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

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

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

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

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

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

قرار القارئ

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

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