Qlik حوّلت خوادم التحليلات إلى مشكلة حدود ثقة للبرامج المدارة

ملخص

• أصبحت ثغرات Qlik Sense Enterprise for Windows اختبارًا للمساءلة لأن منصات التحليلات غالبًا ما تركز بيانات الأعمال بينما تقع خارج النموذج الذهني لأنظمة أمن الحافة.
• أصدرت Qlik إصلاحات أمنية رسمية عالية الخطورة وحرجة؛ وربطت سجلات NVD وسياق CISA KEV والباحثون الأمنيون مجموعة الثغرات بإلحاح التصحيح وإدارة التعرض.
• ربطت تقارير المدافعين لاحقًا استغلال ثغرات Qlik Sense بنشاط برنامج الفدية CACTUS، مما جعل القضية أكثر من مجرد ملاحظة تصحيح نظرية.
• المساءلة مشتركة: سيطرت Qlik على النشرات والإصلاحات والتخفيفات وتوجيه المنتج؛ وسيطر العملاء على جرد التعرض ونشر التصحيح والتقسيم والتسجيل وتقييم الاختراق.
• يجب أن يُظهر سجل الإصلاح الموثوق ليس فقط الإصدارات المصححة، ولكن أيضًا أي الخوادم المكشوفة تم العثور عليها، وأيها تم فحصها بحثًا عن الاختراق، وأي مسارات البيانات تمت مراجعتها، وكيف تم إدخال منصات التحليلات في روتين مخاطر البائعين والاستجابة للحوادث.

يمكن أن يكون برنامج التحليلات نظام حافة مقنعًا

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

نشرات Qlik الرسمية هي نقطة البداية. نشرت الشركة إصلاحًا أمنيًا عالي الخطورة لـ Qlik Sense Enterprise for Windows، و إصلاحًا أمنيًا حرجًا، و إصلاحًا أمنيًا عالي الخطورة آخر في نفس مجموعة الثغرات. قدمت هذه النشرات إرشادات الإصدار والعلاج التي يحتاجها العملاء لتفسيرها بسرعة.

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

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

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

سلسلة التصحيح تخلق مسؤولية تسلسلية

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

استجابة التهديد الناشئ من Rapid7، CVE-2023-41266 وCVE-2023-41265 ثغرات Qlik Sense Enterprise، ساعدت المدافعين في تفسير الثغرات ومسار العلاج. نظرة Tenable العامة، ثغرات حرجة في Qlik Sense، ربطت CVEs معًا وأكدت على التصحيح. تحليل الاستغلال التقني من Praetorian أظهر لماذا يحتاج المدافعون إلى فهم السلسلة، وليس فقط تسميات CVE.

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

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

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

الاستغلال غير المخاطرة من نظرية إلى تشغيلية

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

أفادت Arctic Wolf أنها لاحظت برنامج الفدية CACTUS يستغل ثغرات Qlik Sense. غطى SecurityWeek ثغرات Qlik Sense التي استغلتها مجموعة برامج فدية، وأفاد BleepingComputer أن برنامج الفدية CACTUS ادعى استغلال Qlik Sense للوصول الأولي. حولت هذه التقارير القضية من نظافة التصحيح إلى جاهزية الحوادث.

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

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

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

استغلال التطبيقات المواجهة للجمهور هو نمط مألوف

تقنية Exploit Public-Facing Application من MITRE ATT&CK تصف كيف يستغل المهاجمون التطبيقات المكشوفة للوصول الأولي. تناسب Qlik Sense هذا النمط عند نشرها بطريقة قابلة للوصول. هذه التقنية شائعة لأن المؤسسات تعرض تطبيقات الأعمال للمستخدمين بينما تقلل من تقدير سرعة مسح المهاجمين للإصدارات الضعيفة.

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

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

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

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

أصحاب البيانات بحاجة إلى مقعد في الحادث

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

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

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

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

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

إدارة التصحيح تحتاج إلى تحديد أولويات مراعية للتعرض

يوفر NIST SP 800-40 Revision 4، دليل تخطيط إدارة تصحيح المؤسسات، إرشادات عامة لإدارة التصحيح. يوفر Exploit Prediction Scoring System من FIRST سياق احتمالية الاستغلال. هذه الأدوات تساعد، لكن حالة Qlik تظهر لماذا يجب دمج الإشارات العالمية مع التعرض المحلي. درجة CVE أو احتمالية الاستغلال لا تعرف ما إذا كان خادم Qlik الخاص بالمؤسسة قابلاً للوصول من الإنترنت أو متصلًا ببيانات الجواهر التاجية أو مراقبًا.

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

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

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

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

تأطير برامج الفدية يغير مساءلة التنفيذيين

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

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

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

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

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

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

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

ما هو معروف كافٍ لتحديد المساءلة. نشرت Qlik إصلاحات أمنية لثغرات Qlik Sense Enterprise for Windows. وصف سجلات CVE العامة والباحثون الأمنيون سلاسل الاستغلال ومتطلبات التصحيح. ربط تقارير المدافع والصحافة الاستغلال بنشاط برامج الفدية. كان على العملاء الذين يديرون أنظمة Qlik Sense المكشوفة التصحيح والتحقيق وإثبات أن خوادم التحليلات لم تترك كنقاط وصول أولية.

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

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

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

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

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

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

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

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

الكشف يجب أن يشمل إشارات التطبيق والهوية والبيانات

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

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

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

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

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

الخدمة المُدارة لا تمحو واجب العميل في طلب الدليل

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

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

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

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

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

الحوكمة بعد التصحيح يجب أن تغير النموذج التشغيلي

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

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

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

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

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

معيار الإصلاح هو الإزالة المؤكدة من متناول المهاجم

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

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

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

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

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

عمل العميل هو جزء من سطح مخاطر المنتج

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

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

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

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

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