يتعامل كثير من المؤسسات مع المصادقة متعددة العوامل على أنها ميزة مفعّلة في التطبيق، فيكتفي بالتأكد من وجودها. أما معيار PCI DSS v4.0 فيتوقع أن تكون هذه الضوابط مُصمَّمة بحيث لا يمكن تجاوزها، وأن يثبت صاحب البيئة ذلك. ولهذا فإن اختبار المصادقة متعددة العوامل PCI DSS v4.0 السعودية ينبغي أن يسبق زيارة المدقق المعتمد، لا أن يحدث أثناءها.
يعرض هذا المقال أربعة سيناريوهات اختبار عملية لضوابط ربط الأجهزة وتوقيع المعاملات في الخدمات المصرفية الرقمية، ويبيّن ما الذي يُعدّ نجاحًا وما الثغرات الشائعة في كل سيناريو.
لماذا لا يكفي التحقق من وجود الضابط
يسأل المدقق عادةً: هل المصادقة متعددة العوامل مطبّقة؟ لكن الاحتيال الفعلي يسأل سؤالًا مختلفًا: ماذا يحدث إذا سيطر المهاجم على أحد العوامل؟ فإذا كان العاملان يعتمدان على قناة واحدة، كرقم الجوال مثلًا، فإن اختراق تلك القناة يُسقط الضابطين معًا.
ولذلك يبدأ الاختبار الجيد من رحلة العميل لا من قائمة المتطلبات. يُحدَّد أين يُستخدم كل عامل، وما الذي يربطه بالهوية، وما الذي يحدث عند الاستثناء أو الاستعادة أو تغيير الجهاز.
التحضير قبل الاختبار
قبل تنفيذ السيناريوهات، أنجزوا الخطوات التالية:
- ارسموا رحلات العميل الحساسة: التسجيل، وربط جهاز جديد، وتغيير بيانات التواصل، والتحويل، وإضافة مستفيد.
- حدّدوا لكل رحلة العوامل المستخدمة، ومصدر كل عامل، ومن يملك صلاحية تجاوزه.
- اتفقوا على بيئة الاختبار. الأفضل بيئة ما قبل الإنتاج، ولا يُلجأ إلى البيئة الفعلية إلا في سيناريوهات آمنة متفق عليها مسبقًا.
- وثّقوا النتائج بالأدلة، لأن المدقق يطلب إثباتًا لا وصفًا.
يجب أن يكون التركيز على ضوابط الاحتيال وسلوك المصادقة، وهذا يختلف عن اختبار الاختراق التقني للتطبيق، وإن كان الاثنان يكمّل أحدهما الآخر.
السيناريو الأول: استبدال الشريحة
الفرضية: يحصل المهاجم على شريحة بديلة برقم الضحية، فتصله رسائل التحقق.
ما يُختبر:
- هل تعتمد أي رحلة حساسة على رمز يصل برسالة نصية وحدها؟
- هل يكشف النظام تغيّر الشريحة أو حدوث نقل رقم حديث قبل السماح بعمليات حساسة؟
- هل يُمنع ربط جهاز جديد بمجرد إدخال رمز نصي؟
- هل يُنبَّه العميل عبر قناة مستقلة عند محاولة الربط؟
الثغرة الشائعة: يُعامَل الرقم الجوال كدليل على الهوية، فيصبح استبدال الشريحة كافيًا لاستعادة الحساب وربط جهاز المهاجم.
النتيجة المقبولة: لا يكفي التحكم بالرقم وحده لإتمام ربط جهاز أو اعتماد عملية عالية الخطورة.
السيناريو الثاني: استنساخ الجهاز
الفرضية: ينسخ المهاجم بيئة التطبيق أو بيانات الربط إلى جهاز آخر، أو يستخدم محاكيًا.
ما يُختبر:
- هل يرتبط الجهاز بمعرّف يصعب نقله، وهل يُتحقق منه عند كل عملية حساسة؟
- هل يرفض النظام الأجهزة المعدّلة أو المحاكاة أو ذات الصلاحيات المرتفعة، أم يكتفي بتسجيل ذلك؟
- هل يُعاد التحقق البيومتري عند تغيّر بصمة الجهاز؟
- هل يرتبط الفحص البيومتري فعلًا بمفتاح محمي على الجهاز، أم يكتفي التطبيق بنتيجة محلية يمكن تزويرها؟
- هل يمكن للعميل رؤية الأجهزة المرتبطة وإلغاؤها؟
الثغرة الشائعة: يكون الفحص البيومتري مجرد شرط في واجهة التطبيق، دون أن يكون جزءًا من توقيع العملية في الخادم.
السيناريو الثالث: اختطاف الجلسة
الفرضية: يحصل المهاجم على رمز جلسة صالح بعد أن أتمّ العميل المصادقة، ثم يستخدمه لتنفيذ عمليات.
ما يُختبر:
- هل تُربط الجلسة بالجهاز وبخصائص الاتصال، وهل تُبطَل عند تغيّرها بشكل مريب؟
- هل تتطلب العمليات الحساسة مصادقة معزّزة داخل الجلسة نفسها، أم تكتفي بالجلسة المفتوحة؟
- هل يُنهى الوصول عند تغيير كلمة المرور أو إلغاء ربط الجهاز؟
- هل مدة الجلسة والخمول مناسبة لحساسية العمليات؟
الثغرة الشائعة: تُمنح الجلسة المصادَق عليها ثقة كاملة، فيمكن للمهاجم إضافة مستفيد وتحويل الأموال دون أي عامل إضافي.
النتيجة المقبولة: لا تُنفَّذ العملية الحساسة إلا بتوقيع مرتبط بتفاصيلها، كالمبلغ والمستفيد، لا بمجرد وجود جلسة.
السيناريو الرابع: اعتراض إشعارات الدفع
الفرضية: يحصل المهاجم على الرمز أو يمنع العميل من رؤية التنبيه، سواء عبر الهندسة الاجتماعية أو برمجيات خبيثة أو إعادة توجيه الرسائل.
ما يُختبر:
- هل يعرض إشعار الاعتماد تفاصيل العملية، أم يكتفي برمز عام؟
- هل يمكن استخدام رمز صادر لعملية معيّنة في عملية أخرى؟
- هل تنتهي صلاحية الرمز سريعًا ولا يُعاد استخدامه؟
- هل يُدفع العميل بسهولة إلى الموافقة على طلبات متكررة؟ هذا هو إرهاق المصادقة.
- هل تصل تنبيهات تغيير الجهاز أو المستفيد عبر قناة لا يتحكم بها المهاجم؟
الثغرة الشائعة: يتيح تصميم الإشعار للعميل الموافقة دون أن يرى ما يوافق عليه، فيصبح ضحية للهندسة الاجتماعية.
ما الذي يعنيه "اجتياز" الاختبار
لا يُقاس النجاح بتنفيذ السيناريو فحسب، بل بما يلي:
- وجود دليل مكتوب على سلوك النظام في كل سيناريو، مع لقطات وسجلات.
- ربط كل ثغرة بالرحلة والعامل المتأثر وبمتطلب الجهة المنظِّمة.
- تحديد من يملك المعالجة وأولويتها وأثرها على تجربة العميل.
وتتقاطع هذه الاختبارات مع متطلبات البنك المركزي السعودي (ساما) في إطار مكافحة الاحتيال المالي وإطار الأمن السيبراني، وهي تتجاوز ما يطلبه PCI DSS وحده، لذا يفيد توحيد الأدلة لتخدم أكثر من تقييم.
الأخطاء التي نراها تتكرر
- افتراض أن مزوّد المصادقة مسؤول عن كل شيء، رغم أن مسؤولية التكامل والاستثناءات تقع على المؤسسة.
- ترك مسارات الاستعادة وخدمة العملاء خارج الاختبار، وهي الباب الخلفي المفضّل للمحتالين.
- اختبار التطبيق دون اختبار الإجراءات البشرية، كتغيير رقم الجوال في الفرع أو مركز الاتصال.
- معالجة الثغرات تقنيًا دون النظر إلى أثرها على تجربة العميل، فتُهمَل لاحقًا.
كيف نساعدكم في ذلك
تغطي خدمتنا في مراجعة ضوابط الاحتيال في الخدمات المصرفية الرقمية والمدفوعات الخدمات المصرفية عبر الجوال والإنترنت، والتحقق الرقمي (نفاذ)، وربط الأجهزة، وتوقيع العمليات، وإشعارات العملاء. تمتد المراجعة عادةً من ٤ إلى ٨ أسابيع، وتسير في أربع مراحل: خريطة رحلات العملاء وضوابطها، ثم نمذجة التهديدات لسيناريوهات الاحتيال في كل خطوة، ثم اختبار الضوابط واستعراض السيناريوهات، ثم توصيات في خارطة طريق مرتبة حسب الأولوية مع أثرها على التجربة.
وتشمل مخرجات المراجعة تقييم الضوابط لكل رحلة، ونتائج اختبار سيناريوهات الاحتيال، وخارطة طريق المعالجة. وبموافقتكم نختبر في بيئة ما قبل الإنتاج، ويقتصر الاختبار على البيئة الفعلية في سيناريوهات آمنة متفق عليها. وهذه الخدمة لا تشمل اختبار الاختراق، فهي تركّز على ضوابط الاحتيال، وتتكامل جيدًا مع خدمة اختبار الاختراق لدينا.
الخلاصة
المدقق المعتمد يقيّم ما يُعرض عليه، أما المحتال فيبحث عمّا لم يُختبر. فإذا اختبرتم استبدال الشريحة واستنساخ الجهاز واختطاف الجلسة واعتراض الإشعارات قبل التقييم، فستصلون إليه بأدلة واضحة وبثغرات سبق إغلاقها. وإن رغبتم في تنفيذ ذلك على رحلاتكم الفعلية، فيسعدنا أن نناقش نطاق مراجعة ضوابط الاحتيال في الخدمات المصرفية الرقمية والمدفوعات معكم.
