في 15 مارس 2022، أصدرت الوكالة الأمريكية للأمن السيبراني وأمن البنية التحتية (CISA) في الولايات المتحدة تنبيه تفاصيل هجوم إلكتروني روسي على منظمة غير حكومية (منظمة غير حكومية).
استخدمت الجهة الفاعلة الروسية هجوم تخمين كلمة المرور بالقوة الغاشمة لاختراق حساب مستخدم غير نشط لمنظمة غير حكومية. ثم تمكنت الجهة التخريبية بعد ذلك من تسجيل جهاز جديد في حساب المنظمة غير الحكومية مصادقة متعددة العوامل (MFA)، باستخدام الحساب المخترق. ومن خلال استغلال إعدادات "فشل فتح الحساب"، تمكّن مُنفّذ التهديد من إيقاف تشغيل المصادقة المصدقية المتعددة (MFA) عن طريق فصل الجهاز عن الإنترنت.
في النهاية، ربطت جهة التهديد كلمات المرور الضعيفة معًا، وحساب مستخدم غير نشط، والإعدادات الافتراضية التي فضلت الراحة على الأمان، وثغرة سابقة في نظام ويندوز. وقد مكّنهم ذلك من "الوصول إلى الحسابات السحابية وحسابات البريد الإلكتروني لاستخراج المستندات"، وفقًا لوكالة الاستخبارات الأمنية الدولية.
لا يتعلق منشور المدونة هذا بتقريع مزود آخر. فأنا أعمل مع RSA منذ ما يقرب من 20 عاماً. وخلال تلك الفترة، اختبرت نصيبي من حالات الأمن السيبراني المرتفعة والمنخفضة بشكل مباشر. لذا دعني أخبرك: الشماتة لا تساعد أحداً على الإطلاق.
ما أنا سوف القيام بتفصيل بعض النصائح التي قدمتها RSA للعملاء في أعقاب التنبيه الأخير الصادر عن وكالة أمن المعلومات. سأشرح أيضًا كيف تنطبق هذه النصيحة على جميع حلول MFA.
تنبيه مفسد صغير: كل ميزة أو متطلب مذكور في بقية هذه المقالة هو جزء من RSA.
تعد المصادقة المصغرة أكثر بكثير من مجرد طريقة مصادقة
ولمنع مثل هذه الهجمات، تحتاج المؤسسات إلى إعادة النظر في ماهية المصادقة المصادقة المصغّرة (MFA)، وكيف يجب على المستخدمين التسجيل في المصادقة المصغّرة في البداية وكيف سيحافظون على هذه التسجيلات على مدار دورات حياة المستخدمين.
ضع في اعتبارك دائمًا أن MFA ليس فقط عن وجود كلمة مرور لمرة واحدة رمز (OTP) أو تطبيق مصادقة أو عصا FIDO لتسجيل الدخول. إذا كنت تعتقد أنك آمن لمجرد أنك أو مستخدميك تستخدمون المصادقة البيومترية على هاتف ذكي لتسجيل الدخول إلى تطبيق سحابي، فلدي أخبار سيئة لك: هذا ليس مصادقة متعددة الأطراف.
هذا هو الحد الأدنى فقط. نعم، سيسمح لك ذلك بوضع علامة في خانة الاختيار "استخدام MFA" لتدقيق الامتثال، ولكن من منظور أمني، سيكون ذلك مضيعة للوقت والمال.
تعتمد معظم أدوات المصادقة على بعض بذور التشفير أو المفاتيح للمصادقة. وعادةً ما توفر المصادقات القائمة على الأجهزة مستوى أعلى من الأمان لأنها تحمي تلك البذرة بدرجة أكبر من المصادقات القائمة على البرمجيات. تحتاج الشركات إلى فهم احتياجاتها الأمنية واختيار المصادقة التي توفر مستوى أمان جيد بما فيه الكفاية - يمكن للمصادقات القائمة على الأجهزة أو البرمجيات أن تلبي المتطلبات الفردية.
ومع ذلك، فإن الطريقة نفسها - سواء كانت أجهزة أو برمجيات - تكاد تكون غير ذات صلة إذا فشل تسجيل المصادقات في إنشاء ثقة كافية. حتى لو كانت مؤسستك تستخدم أفضل المصادقين، إذا كنت تديرهم بطريقة خاطئة، فإنهم سيكونون عديمي الفائدة في منع أو إبطاء الهجوم. فكّر في السيارة: لمجرد أنك وضعت محركاً قوياً فيها وطليت بطانات المكابح باللون الأصفر، فهذا لا يعني أنك فجأةً أصبحت خلف مقود سيارة سباق. ستحتاج أيضًا إلى تغيير المكابح ونظام التعليق والإطارات - وتدريب السائق على كيفية المنافسة في سباق حقيقي. هناك الكثير مما يجب أخذه بعين الاعتبار.
من خلال مراجعة دورة حياة الهوية النموذجية، سأشرح لك كيفية تحقيق أقصى استفادة من حل المصادقة المصغّرة (MFA) والتأكد من أنه يؤدي المهمة التي صُمم من أجلها: حماية المستخدمين وتأمين أصولك الرقمية.
التسجيل هو المرحلة الأولى في دورة حياة الهوية: أثناء عملية التسجيل، يتم تعيين مصادق لهوية (مستخدم). ولكن حتى قبل أن تقوم المؤسسة بتسجيل مستخدم معين، يجب أن تأخذ بعين الاعتبار بعض الأسئلة:
- من يمكنه التسجيل في برنامج MFA؟
- كيف يمكن للمستخدم التسجيل في MFA؟
قد تعتقد أن السؤال الأول له إجابة سهلة: يجب على الجميع استخدام MFA!
ومع ذلك، قد يكون هناك مستخدمون أو مجموعات لا ينبغي أو لا يجب تسجيلها. فكّر في الحسابات الموجودة ولكنها غير نشطة - مثل موظف في إجازة والدية، أو الحسابات اليتيمة التي لم يتم تعيينها أو لم تعد مخصصة لمستخدم معين. يجب ألا يسمح فريق الأمان لهذه الحسابات بالتسجيل في المصادقة المصغّرة MFA لأنه من غير المرجح أن يتم ملاحظة أي عمليات تسجيل مصادقة جديدة أو متغيرة تصدر لهذه الحسابات. على سبيل المثال، ستظل رسائل البريد الإلكتروني الخاصة بالإشعارات التي تشير إلى تغيير الإعدادات موجودة في صندوق بريد وارد غير مراقب.
السؤال الثاني أكثر أهمية لأنه يحتاج إلى معالجة من منظورين:
- كيف يمكن أن تصل مؤسستك إلى مستوى الثقة المطلوب؟
- كيف يمكن للتسجيل تلبية مستوى الثقة المطلوب بطريقة ملائمة وفعالة لكل من المستخدم والإدارة/مكتب المساعدة؟
يتم تحديد أي ثقة في المصادق من خلال كيفية تسجيله في البداية: تحدد درجة الأمان التي يتمتع بها المستخدم عند التسجيل سقف الثقة طالما استمر هذا المستخدم في استخدام هذا المصادق.
طريقة أخرى لصياغة الأمر: سواء كنت تستخدم أجهزة أو برمجيات، لا يمكن للمصادقة أن توفر مستوى الثقة اللازم لتسجيل الدخول إلى المصادقة متعددة العوامل أو المصادقة المتدرجة إلا إذا كان التسجيل الأولي قويًا بما فيه الكفاية. إذا وضعت أساسًا هشًا، فسيكون منزلك دائمًا غير مستقر.
هناك الكثير من الطرق لتحديد من يمكنه التسجيل وكيفية إكمال العملية بطريقة توازن بين الأمان والراحة. ولكن مهما كانت الطريقة التي تقررها مؤسستك، تأكد من أنك لا فقط استخدام كلمات المرور للتسجيل.
لم لا؟ كلمات المرور مريحة. يعرف المستخدمون بالفعل بيانات الاعتماد الخاصة بهم، لذلك لا يتعين على المسؤولين القلق بشأن أي شيء آخر غير توجيه حل المصادقة المصغّرة إلى الدليل النشط. أليس كذلك؟
خطأ. في حين أن هذه طريقة سهلة لإكمال التسجيل في المصادقة المصطنعة MFA، إلا أن استخدام كلمات المرور فقط يترك مؤسستك عرضة لجميع أنواع الهجمات. السيناريو الأسوأ هو أن يكون أحد المهاجمين قد اخترق حسابًا بالفعل ثم قام بتسجيل هذا الحساب في المصادقة المصدقية الآلية. تسجيل حساب في المصادقة المصغّرة الذي لا ينبغي أن تكون مسجلاً في MFA هو فعليًا مثل تجاوز MFA تمامًا.
هذا بالضبط ما حدث في الهجوم الناجح على المنظمة غير الحكومية المذكورة في بداية هذا المنشور. على الرغم من وجود خطوات إضافية استخدمها المهاجم لرفع مستوى وصوله، إلا أن التسجيل نفسه كان الخلل القاتل.
هناك طرق أكثر ذكاءً وأماناً لتسجيل المصادقات. تنصح SecurID المؤسسات بشدة بوضع ضوابط تقنية وإجرائية إضافية حول تسجيل المصادقة متعددة الأطراف. في الواقع، التسجيل بكلمة مرور فقط غير ممكن افتراضيًا في SecurID. يجب على العميل أن يبذل جهداً كبيراً لتمكين هذا النوع من التسجيل - ونحن ننصحه بعدم القيام بذلك في كل خطوة على الطريق.
يعتمد تحديد التسجيل المناسب على المصادقات المتاحة، ومستويات الثقة المطلوبة، وقدرات حل MFA الخاص بالمؤسسة والأدوات والإجراءات المتاحة للشركة.
هناك العديد من الضوابط التقنية التي يمكن أن تساعد في تأمين وتبسيط عملية التسجيل دون اللجوء إلى كلمات المرور. فعلى سبيل المثال، يمكن للمؤسسات:
- الاعتماد على رسالة نصية قصيرة أو رسالة صوتية إلى رقم هاتف مسجل مسبقاً قبل التسجيل
- مطالبة المستخدمين بالاتصال بمكتب المساعدة للحصول على رمز التسجيل
- توزيع رمز التسجيل على المستخدم عن طريق البريد الإلكتروني
- طباعة رسائل رقم التعريف الشخصي ومشاركتها لإجبار المستخدمين على استخدام رقم التعريف الشخصي الفريد للتسجيل
- تعيين الرموز المميزة للأجهزة وإرسالها إلى المستخدمين (في هذا السيناريو، يجب على المؤسسات في هذا السيناريو إبقاء الرموز المميزة غير مفعلة والسماح للمستخدم بالاتصال بمكتب المساعدة لتمكين الرمز المميز للأجهزة)
- السماح بالتسجيل من داخل شبكة الشركة فقط
وبالطبع، هناك المزيد من عناصر التحكم المتاحة ومجموعات مختلفة ممكنة أيضاً. ربما ينبغي للمؤسسات التي لديها أعداد كبيرة ومتنوعة من المستخدمين أن تفكر في تقديم أكثر من طريقة واحدة للتسجيل، مما قد يؤدي إلى مستويات ثقة مختلفة اعتماداً على دور المستخدم.
كل هذه الضوابط تضيف طبقات أمنية حول خدمة التسجيل نفسها. وعلى الرغم من أن إنشاء هذه الطبقات يتطلب جهداً لإعدادها وصيانتها، إلا أن هذا الاستثمار له مردود كبير: المصادقات التي يمكن الوثوق بها.
ولكن هذه ليست سوى الخطوة الأولى في تأمين دورة حياة هوية المستخدم. هناك العديد من السيناريوهات الأخرى التي تمنع الجهات الفاعلة في مجال التهديدات من الحصول على فرص كبيرة والعديد من المواقف التي يجب على المؤسسات الاستعداد لها. في الجزء التالي من هذه السلسلة, سنقوم بمراجعة عمليات إعادة التعيين، وعمليات الأمان من الفشل، والنقاط الأخرى في دورة حياة الهوية التي يجب على المؤسسات أن تعطيها الأولوية لحماية نفسها وفرقها.
