مقال حول إنشاء حل داخلي لكشف ومنع المعاملات الاحتيالية التي تتم في الخدمات المصرفية عبر الإنترنت لأحد البنوك الصغيرة ، ولكن فخور جداً في تتارستان. سوف تتعلم من المقال حول سبب ومن يحتاج إلى مكافحة الغش ، ولماذا أصبحت التنمية الداخلية أرخص من شراء حل جاهز ، وماذا يؤدي بضعة أسطر من التعليمات البرمجية قبل العام الجديد.
بضع كلمات عن نفسك - أخصائي أمن المعلومات في إحدى شركات تكنولوجيا المعلومات والذي تبين بطريق الخطأ (أو ربما ليس جدًا) أنه مالك منتج في فريق مكافحة الاحتيال. تعمل شركة تكنولوجيا المعلومات نفسها في تطوير برامج الخدمات المصرفية عبر الإنترنت.
كيف بدأ كل شيء؟
بالنسبة للبنك نفسه ، بدأ كل شيء بحقيقة أن البنك المركزي للاتحاد الروسي قام بتحميل مسودة من التعديلات والإضافات على اللائحة رقم 382-P ، والتي تنص على أنه يجب على البنك منع تحويل الأموال دون موافقة العميل. بالإضافة إلى ذلك ، وفقًا لأمر بنك روسيا رقم 2831-U ، فإن البنك ملزم بإبلاغ البنك المركزي بجميع الأحداث ، بما في ذلك تصرفات المحتالين.
بالنسبة لي ، بدأت القصة بطلب للمساعدة في تشكيل المتطلبات الوظيفية ودراسة التكامل مع الخدمة المصرفية عن بعد الموجودة (المشار إليها فيما يلي - RBS). ونذهب بعيدا ...
إدخال البيانات
قبل التطوير ، من الضروري البحث في الموضوع ، لدراسة التطورات الجاهزة أشعل النار تصفح السوق.
خلال الدراسة ، اتضح:
- الطرق الأكثر شيوعًا لسرقة الأموال من RBS - الهندسة الاجتماعية والتصيد الاحتيالي
- باستخدام الهندسة الاجتماعية ، فإنهم إما اختراق النظام المصرفي أو إجبار العميل على تحويل الأموال طواعية
- المبلغ الذي سرقه المحتالون لهذا العام ليس كبيرًا للغاية ، والبنك ينفق على التحقيق والتعويض حوالي 10٪ من هذا المبلغ
- تكلفة حل مكافحة الغش الجاهز تتجاوز المبلغ المتضمن في الاحتيال بمقدار 5-10 مرات (لم تكتمل تكلفة تكامل الكلام حتى الآن ...)
- من الضروري تقديم تقرير إلى FinCERT ، تأكد
- يمكنك تسليط الضوء على بضع حالات متكررة ومهمة للغاية
عند تحليل موضوع مكافحة الغش ، ساعدتني مقالات codezombie كثيرًا. الذي كتب قبل 4 سنوات عن مكافحة الغش المستخدم في التجارة الإلكترونية ، وعن تجربته. في حالتي ، كانت التفاصيل مختلفة ، لكن المعلومات كانت قيمة للغاية.
بناءً على هذه الشروط ، تقرر إعطاء المشروع لفريق التطوير المنخرط في عمليات الدمج وحل مشكلات الفرق الأخرى ، حيث تضمن هذا الفريق المطورين الأكثر خبرة ورائعة. لسوء الحظ ، في فريق من 3 مطورين مع مرور الوقت ، بقي اثنان فقط. كنت منخرطًا في الأعمال المتراكمة ، وتكوين المتطلبات ، والتوثيق وتنظيم الاجتماعات (نحن نعمل على scrum ، ولكن كيف آخر). حدث ذلك أنه في فريق 4 كتب الأيدي رمز ، و 3 رؤساء حل المشكلة.
الحالات التي قاتلوا
لا أعتقد أن البنك لم يقاتل من قبل مع الشر مع المحتالين. قاتل مع وسائل بأسعار معقولة. ومع ذلك ، كان هناك ميل إلى زيادة عدد الحوادث المتعلقة باختراق RBS. كان هناك مخطط شائع لعام 2018 كان الطلاق في المساحات المفتوحة لـ Avito - حيث قام المحتالون الذين يستخدمون أساليب الهندسة الاجتماعية بالتعرف على رقم البطاقة ، وفي الحوار ، تعرفوا على الرسائل القصيرة لدخول المكتب الإقليمي. وهكذا ، حصلوا على حق الوصول الكامل إلى الخدمات المصرفية عبر الإنترنت لعميل معين. في عام 2019 ، بدأ المحتالون في إجراء اتصالات هاتفية مع العملاء نيابة عن خدمات الأمن بالبنك ، وهددوا بخسارة كل أموالهم ، أو اكتشفوا تفاصيل تسجيل الدخول ، أو حثهم على تحويل جميع الأموال إلى "حساب آمن".
كان الهدف الرئيسي لفريق التطوير هو إنشاء آلية لتحديد أجهزة العملاء الجديدة ووقف المعاملات المالية المشبوهة. لماذا بالضبط الأجهزة الجديدة؟ أظهر Analytics أنه في أغلب الأحيان يحصلون على إمكانية الوصول إلى الخدمات المصرفية عن بُعد عبر الهاتف الذكي لتلقي رموز التأكيد من خلال إشعارات PUSH ، بدلاً من رسائل SMS.
بالإضافة إلى ذلك ، بدأت FinCERT في إرسال قوائم بالتفاصيل المتعلقة بالعمليات الاحتيالية ، أي كان لا بد من حظرها.
التنمية والتكامل في مكافحة الاحتيال
كان لدينا 2 مبرمجين .NET بارزين ، وهندسة خدمات microservice من RBS ، و API REST ، وعشرات القوائم السوداء من مختلف الأشكال والكثير من التكامل من جميع الأنواع والألوان ، ولم يكن هناك اختبار أو مهندس devops. ليس أنه احتياطي ضروري للحماية من جميع المحتالين. ولكن إذا كنت لا تزال بحاجة إلى القيام بذلك ، فلن تتوقف. الشيء الوحيد الذي تسبب لي القلق كان ايجابيات كاذبة. لا يوجد شيء أكثر عجزًا وغير مسؤول ومفسد من مشغل مكافحة الاحتيال الذي طار 20 تذكرة في 5 دقائق. كنت أعرف أننا عاجلاً أم آجلاً سنواجه هذا.
بشكل عام ، لم يكن هناك شيء خاطئ في التكامل. حدد جيش تحرير السودان حدًا قدره 3 ثوان للرد على الطلبات. في الوقت الحالي ، يبلغ متوسط وقت الاستجابة 0.3 ثانية. سهلت بنية microservice من الاندماج مع الحل الحالي من خلال إضافة ثلاثة خطوط لإرسال طلب إلى microservice لمكافحة الاحتيال. يتم التحقق قبل التأكيد عن طريق الرسائل القصيرة أو إخطار الدفع.
رسم صغير لهندسة الحلول:
في المرحلة الأولى من التطوير ، تم تحديد الهدف - التحقق من شرطين مهمين. أولاً ، الجهاز الذي تتم محاولة المعاملة منه جديد للعميل أو موثوق به. ثانيا ، ما إذا كانت الدعائم ليست في القوائم السوداء. هذان الشرطان يكفيان لمنع 70٪ من الحوادث ، أما الباقي ، فيجب الحصول على مزيد من المعلومات ، على سبيل المثال ، هل كان هناك تسجيل الدخول عن طريق تسجيل الدخول / كلمة المرور ، أو عن طريق رقم البطاقة ، من أي بلد دخلت RBS ، إلخ.
لتطبيق التحقق ، لا تحتاج إلى الكثير من البيانات - معرف فريد للعميل ، معرف لجهازه (تم إنشاؤه على العملاء أنفسهم - تطبيقات الجوال ومكتبات JS على الموقع) ، ومقدار النقل ، وتفاصيل النقل. بناءً على هذه البيانات ، يتم اتخاذ قرار بالسماح بالعملية أو حظرها. بمجرد أن يعمل النظام بأكمله بشكل صحيح في العملية الصناعية ، انتقل الفريق إلى المرحلة التالية. هناك قوائم بيضاء والتحميل التلقائي للقوائم من FinCERT. في الوقت الحالي ، يتم تصحيح إرسال التقارير عن الحوادث إلى FinCERT نفسها عبر واجهة برمجة التطبيقات (هذه قصة طويلة منفصلة).
في الوقت الحالي ، تم التحقق من الدفعات التالية في نظام مكافحة الاحتيال: مدفوعات P2P عن طريق رقم البطاقة ، وتجديد رقم الهاتف ، ونقل بالتفاصيل ، وتجديد المحافظ الإلكترونية. المحتالين في كثير من الأحيان نقل 2000-3000 روبل إلى أرقام الهواتف أو محافظ. في حالة البطاقات ، عادة ما تكون المبالغ قريبة من مجموع جميع الأموال المتاحة للعميل. بالإضافة إلى عمليات التحقق ، تم إنشاء صفحة لمشغلي مكافحة الاحتيال ، من المستحيل جعل النظام مستقل تمامًا - يلزم وجود شخص لمراقبة الأحداث ، والتحقيق في الحوادث ، وحظر / إلغاء حظر ، وإنشاء تقارير على النظام. من الصعب إنشاء موقع عندما يكون هناك مطوران خلفيان في الفريق. ومع ذلك ، لم يفت الأوان بعد للتعلم (يكون رائعًا عندما يكون هناك متخصصون على شكل حرف T في الفريق!).
في البداية ، عند التخطيط والتحليل ، كان هناك الكثير من الأفكار حول إدخال التعلم الآلي ، والقواعد الديناميكية ، ومضادات الفيروسات داخل عميل RBS. ومع ذلك ، بناءً على تجربة البائعين والبنوك الأخرى ، يمكن إغلاق أكثر من نصف الحالات من خلال تطبيق القواعد الثابتة. تتطلب كل الطرق الأخرى موارد كبيرة وليست فعالة. وهذا هو السبب في أن وجود فريق من اثنين من المطورين ومحلل واحد (والذي أعتبره نفسي) كافٍ لتنفيذ الحد الأدنى من تدابير الحماية ومتطلبات الهيئات التنظيمية.
ألم
القاعدة الأساسية في تطوير مكافحة الغش - لا تضر. يجب اختبار أي تغييرات وطرق جديدة أولاً في الاختبار ، ثم في المعركة في وضع المراقبة للتأكد من عدم وجود مشاكل. في أسوأ الحالات ، يمكن أن تؤدي الأخطاء إلى خسائر مالية وفقدان ولاء العملاء. في حالتنا ، أدى الخطأ إلى معاناة المشغلين الذين يحققون ويديرون نظام مكافحة الاحتيال.
كان المساء ، عشية رأس السنة الجديدة. نفذ النظام التحقق من الأجهزة المحمولة ليس فقط ، ولكن أيضًا متصفحات العملاء. باستخدام EverCookie . قام المطورون بتضمين الميزة ، لكنهم لم يختبروها ، حيث لم يتم تقديم المكتبة على الجبهات. فقط في يوم العمل الأخير من 2019 ، قرر مبرمج الواجهة الأمامية صب الفرع في المنتج (حسنًا ، لا تترك نفس الشيء للعام القادم!). وبسبب هذا ، خلال عطلة نهاية الأسبوع رأس السنة الجديدة ، كد مشغلي مكافحة الاحتيال الكثير من العمل في شكل ايجابيات كاذبة للنظام. لا يمكن القول أنه كان حرجًا ، ومع ذلك ، فإن المشغلين يشعرون بالأسف قليلاً ... بعد كل شيء ، أصبح العمل أكثر بخمس مرات مما كان عليه قبل سكب التغيير.
النتائج
في أقل من عام ، قام فريق صغير جدًا بتنفيذ نظام مكافحة الاحتيال للخدمات المصرفية عبر الإنترنت. لسوء الحظ ، لا يزال هناك الكثير من العمل. بعد التحدث مع ممثلي البنوك والبائعين في منتدى Antifraud Russia ، أصبح من الواضح أن المحتالين يتوصلون إلى طرق جديدة كل عام ، لا يمكنك الاسترخاء في هذا المجال.
إذا كان الأمر ممتعًا ، سأكتب المزيد حول حلول البرامج وتحليلات السوق وكيفية تنفيذ Scrum في فريق مكون من 3 أشخاص.