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 مفيدة لأنها تفرض على المؤسسات التساؤل عما إذا كانت خوادم التحليلات موجودة في نفس جرد إدارة الثغرات مثل شبكات VPN وجدران الحماية وموفري الهوية وتطبيقات الويب العامة. إذا لم تكن كذلك، فإن المؤسسة لديها نقطة عمياء في حدود الثقة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مالكو البيانات يحتاجون إلى مقعد في الحادث

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

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

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

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

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

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

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

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

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

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

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

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

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

دليل 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 للتعامل مع حوادث أمن الكمبيوترSP 800-61 Rev 2مفيد هنا لأنه يعامل الكشف والتحليل كعملية، وليس خانة اختيار. جامعو معلومات الحوادث يجمعون المؤشرات، ويحددون النطاق، ويصنفون الحادث، ويحتويون الأنظمة المتأثرة، ويحفظون الأدلة، ويتعلمون من الحدث. في سياق Qlik، يجب أن تشمل هذه العملية أسئلة بيانات الأعمال. قد يؤكد استجابة بنية تحتية بحتة أن الخادم تم تصحيحه وإعادة تشغيله بينما يفتقد ما إذا تم لمس بيانات الاعتماد، أو لوحات المعلومات، أو المستخلصات المخبأة، أو قواعد البيانات المتصلة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

معيار الإصلاح هو الإزالة المُحققة من متناول المهاجم

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

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

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

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

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

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

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

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

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

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

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