“أخطر 3 هجمات إلكترونية استهدفت تطبيقات SaaS في 2022”

متابعات-ميكسي نيوز

أخطر 3 هجمات إلكترونية…خلال الأسبوع الأخير من شهر مارس ، أبلغت ثلاث شركات تقنية رئيسية – Microsoft و Okta و HubSpot – عن انتهاكات بيانات كبيرة.

قام Dev-0537 ، المعروف أيضًا باسم Lapsus $ ، بأداء الأولين.

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

وفي الوقت نفسه ، لم يتم الكشف عن المجموعة وراء خرق HubSpot.

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

HubSpot – وصول الموظف

في 21 مارس 2022 ، أبلغت HubSpot عن الانتهاك الذي حدث في 18 مارس. قام الممثلون الخبيثون بتعرض حساب موظف HubSpot الذي استخدمه الموظف لدعم العملاء.

سمح ذلك للجهات الفاعلة الضارة بالقدرة على الوصول إلى بيانات الاتصال وتصديرها باستخدام وصول الموظف إلى العديد من حسابات HubSpot.

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

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

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

تعلم كيف يمكن أن يساعد SSPM في حماية مؤسستك من عمليات سوء التصرف في SaaS

OKTA – عدم وجود أمان للجهاز للمستخدم المميز

تتجسد Okta من الباطن بعض دعم العملاء لمجموعة Sitel. في 21 كانون الثاني (يناير) ، تلقى أحد أعضاء فريق أمن OKTA تنبيهًا بأنه تمت إضافة عامل MFA جديد إلى حساب موظف Sitel Group من موقع جديد.

وكشف التحقيق أن جهاز كمبيوتر مهندس دعم Sitel قد تعرض للخطر باستخدام بروتوكول سطح المكتب عن بُعد.

عادةً ما يتم تعطيل هذا الضعف المعروف إلا عند الحاجة على وجه التحديد-مما ساعد محققي Okta على تضييق الإطار الزمني للهجوم إلى نافذة مدتها خمسة أيام بين 16-21 يناير 2022.

نظرًا لمحدودية مهندسي دعم الوصول إلى نظامهم ، كان التأثير على عملاء OKTA ضئيلًا.

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

في 22 مارس ، Dev-0537 ، والتي تُعرف أكثر باسم Lapsus $ ، تشترك في لقطات الشاشة عبر الإنترنت. ردا على ذلك ، أوكتا أصدر بيان قائلاً: “لا توجد إجراءات تصحيحية يحتاج عملاؤنا إلى اتخاذها.”

في اليوم التالي الشركة تفاصيل مشتركة لتحقيقهاوالتي شملت جدول استجابة مفصل.

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

1. الأمان من الجهاز إلى SaaS – تأمين بيئة SaaS لا يكفي عندما يتعلق الأمر بالحماية من الخرق. يعد تأمين الأجهزة المستخدمة من قبل المستخدمين المتميزين للغاية ذات أهمية قصوى.
2. يجب على المؤسسات مراجعة قائمة المستخدمين ذوي المؤمنين العاليين والتأكد من أن أجهزتهم آمنة. هذا يمكن أن يحد من أضرار الخرق عبر متجه الهجوم الذي واجه Okta.
3. MFA – كانت إضافة MFA هي التي سمحت لأمن Okta باكتشاف الخرق. لا تذهب SSO بعيدًا بما فيه الكفاية ، ويجب أن تشمل المنظمات التي تأخذ أمن SaaS على محمل الجد تدابير أمان MFA.
4. مراقبة الأحداث – تم اكتشاف خرق OKTA عندما رأى موظفو الأمن تغييرًا غير متوقع في سجل مراقبة الأحداث.
5. تعد مراجعة الأحداث مثل التغييرات في MFA ، وإعادة تعيين كلمة المرور ، والتسجيلات المشبوهة ، وأكثر من ذلك ، أمرًا بالغ الأهمية لأمن SaaS ويجب تنفيذه يوميًا.

يرى تحقيق Cloudflare في وسط يناير 2022 OKTA للحصول على مثال جيد على الاستجابة لمثل هذا الخرق.

اكتشف كيف يوفر Adaptive Shield إدارة وضعية نقطة النهاية والتحكم في تكوين SaaS

Microsoft – MFA لجميع المستخدمين المتميزين

في 22 مارس ، أمان Microsoft المعلومات المشتركة فيما يتعلق بهجوم عانى من يد DEV-0537. كان لدى Microsoft حساب واحد للخطر ، مما أدى إلى سرقة رمز المصدر ونشره.

أكدت Microsoft لمستخدميها أن هجوم Lapsus $ لم يضر بأي من معلوماتهم ، وذكرت كذلك أنه لا يوجد خطر على أي من منتجاتهم بسبب الرمز المسروقي.

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

كما قدمت الشركة هذه الاقتراحات لتأمين منصات ضد هذه الهجمات.

1. تعزيز تنفيذ MFA – فجوات MFA هي متجه هجوم رئيسي. يجب أن تتطلب المؤسسات خيارات MFA ، وتقييد الرسائل القصيرة والبريد الإلكتروني قدر الإمكان ، كما هو الحال مع الرموز المميزة للمصادقة أو Fido.
2. تتطلب نقاط نهاية صحية وموثوقة – يجب على المؤسسات تقييم أمن الجهاز بشكل مستمر. تأكد من أن الأجهزة التي تصل إلى منصات SAAS تتوافق مع سياسات الأمان الخاصة بها من خلال تطبيق تكوينات الأجهزة الآمنة مع درجة مخاطر الضعف المنخفضة.
3. الاستفادة من خيارات المصادقة الحديثة ل VPNS – يجب أن تستفيد مصادقة VPN من خيارات المصادقة الحديثة مثل OAUTH أو SAML.
4. تعزيز ومراقبة وضعية الأمان السحابية الخاصة بك – يجب على المؤسسات ، على الأقل ، وضع وصول مشروط للمستخدمين وتكوينات مخاطر الجلسة ، وتتطلب MFA ، ومنع تسجيلات تسجيل الدخول عالية المخاطر.

للحصول على قائمة كاملة بتوصيات Microsoft ، انظر هذا ملحوظة.

الأفكار النهائية

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

لم تعد كلمات المرور القوية وحلول SSO كافية من تلقاء نفسها. تحتاج الشركات إلى تدابير أمان متقدمة ، مثل MFA القوية ، و IP تسمح بالقوائم ، وحظر وصول مهندس الدعم غير الضروري. يمكن أن يساعد الحل الآلي مثل إدارة SaaS Security Sporture Management (SSPM) فرق الأمن على البقاء على رأس هذه القضايا.

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

إن التحدي المتمثل في تأمين SaaS Solutions معقد ويتجاوز الأعباء لإكماله يدويًا. يمكن أن توفر حلول SSPM ، مثل الدرع التكيفي إدارة الموقف الأمنية التلقائي SaaS ، مع التحكم في التكوين ، وإدارة وضعية نقطة النهاية ، والتحكم في تطبيق الطرف الثالث.

هذه المقالة مكتوبة وساهم بها Hananel Livneh ، كبير محللي المنتجات في Adaptive Shield.