Sebuah artikel tentang pembuatan in-solusi untuk mendeteksi dan mencegah transaksi penipuan yang dilakukan di perbankan Internet dari satu bank kecil, tetapi sangat bangga di Tatarstan. Anda akan belajar dari artikel tentang mengapa dan siapa yang membutuhkan antifraud, mengapa pengembangan internal ternyata lebih murah daripada membeli solusi yang sudah jadi, dan apa yang menyebabkan beberapa baris kode sebelum tahun baru.
Beberapa kata tentang diri Anda - seorang spesialis keamanan informasi di sebuah perusahaan IT yang secara tidak sengaja (atau mungkin tidak terlalu) ternyata menjadi Pemilik Produk di tim Solusi Anti-Penipuan. Perusahaan IT itu sendiri terlibat dalam pengembangan perangkat lunak perbankan Internet.
Bagaimana semuanya dimulai?
Untuk bank itu sendiri, semuanya dimulai dengan fakta bahwa Bank Sentral Federasi Rusia mengunggah draf amandemen dan tambahan ke Peraturan No. 382-P , yang mengatakan bahwa bank harus mencegah transfer dana tanpa persetujuan klien. Selain itu, sesuai dengan urutan Bank Rusia No. 2831-U , bank berkewajiban untuk melaporkan ke Bank Sentral tentang semua insiden, termasuk tindakan penipu.
Bagi saya, cerita dimulai dengan permintaan untuk membantu dengan pembentukan persyaratan fungsional dan studi integrasi dengan layanan perbankan jarak jauh yang ada (selanjutnya - RBS). Dan kita pergi ...
Masukkan data
Sebelum pengembangan, perlu untuk meneliti topik, untuk mempelajari perkembangan yang sudah jadi menyapu telusuri pasar.
Selama penelitian, ternyata:
- cara paling umum untuk mencuri uang dari RBS - rekayasa sosial dan phishing
- menggunakan rekayasa sosial, mereka bisa masuk ke sistem perbankan atau memaksa klien untuk secara sukarela mentransfer uang
- jumlah yang dicuri oleh penipu untuk tahun ini tidak begitu besar, bank membelanjakan investigasi dan kompensasi sekitar 10% dari jumlah ini
- biaya solusi antifraud yang sudah jadi melebihi jumlah yang berpartisipasi dalam penipuan 5-10 kali (tentang biaya mengintegrasikan pidato belum hilang ...)
- perlu melaporkan ke FinCERT, pastikan
- Anda dapat menyoroti beberapa kasus yang sangat sering dan penting
Saat menganalisis topik anti-penipuan, artikel codezombie banyak membantu saya. Yang 4 tahun lalu dia menulis tentang antifraud yang digunakan dalam e-commerce, tentang pengalamannya. Dalam kasus saya, spesifikasinya berbeda, tetapi informasinya sangat berharga.
Berdasarkan kondisi ini, diputuskan untuk memberikan proyek kepada tim pengembangan yang terlibat dalam integrasi dan menyelesaikan masalah tim lain, karena tim ini termasuk pengembang yang paling berpengalaman dan keren. Sayangnya, dalam tim 3 pengembang dari waktu ke waktu, hanya dua yang tersisa. Saya terlibat dalam jaminan simpanan, pembentukan persyaratan, dokumentasi, dan pengaturan pertemuan (kami mengerjakan scrum, tetapi bagaimana lagi). Kebetulan di tim 4 tangan menulis kode, dan 3 kepala memecahkan masalah.
Kasus-kasus yang diperjuangkan
Jangan berpikir bahwa bank tidak bertarung sebelumnya dengan kejahatan dengan scammers. Berjuang dengan cara yang terjangkau. Namun, ada kecenderungan bahwa jumlah insiden terkait peretasan RBS mulai bertambah. Skema populer tahun 2018 adalah perceraian di ruang terbuka Avito - penipu yang menggunakan metode rekayasa sosial mengenali nomor kartu, dan dalam dialog mereka mengenali SMS untuk memasuki RB. Dengan demikian, mereka menerima akses penuh ke perbankan Internet dari klien tertentu. Pada tahun 2019, penipu mulai menelepon pelanggan atas nama layanan keamanan bank, mengancam akan kehilangan semua uang mereka, menemukan rincian login, atau mendesak mereka untuk mentransfer semua dana ke "akun aman".
Tujuan utama tim pengembangan adalah menciptakan mekanisme untuk mengidentifikasi perangkat pelanggan baru dan menghentikan transaksi keuangan yang mencurigakan. Mengapa tepatnya perangkat baru? Analytics telah menunjukkan bahwa paling sering mereka mendapatkan akses ke perbankan jarak jauh melalui smartphone untuk menerima kode konfirmasi melalui pemberitahuan PUSH, daripada pesan SMS.
Selain itu, FinCERT mulai mengirim daftar rincian yang terlibat dalam operasi penipuan, yaitu mereka harus diblokir.
Pengembangan dan integrasi dalam Antifraud
Kami memiliki 2 programmer .NET yang keren, arsitektur microservice dari RBS, REST API, selusin daftar hitam berbagai bentuk dan banyak sekali integrasi dari semua jenis dan warna, dan tidak ada penguji atau insinyur devops. Bukan berarti itu adalah cadangan yang diperlukan untuk perlindungan dari semua scammers. Tetapi jika Anda masih perlu melakukannya, maka Anda tidak akan berhenti. Satu-satunya hal yang membuat saya prihatin adalah positif palsu. Tidak ada yang lebih tak berdaya, tidak bertanggung jawab, dan manja daripada operator antifraud yang menerbangkan 20 tiket dalam 5 menit. Saya tahu bahwa cepat atau lambat kita akan menghadapi ini.
Secara umum, tidak ada yang salah dengan integrasi. SLA telah menetapkan batas 3 detik untuk menanggapi permintaan. Saat ini, waktu respons rata-rata adalah 0,3 detik. Arsitektur microservice membuatnya mudah untuk diintegrasikan dengan solusi yang ada dengan menambahkan tiga baris untuk mengirim permintaan ke layanan mikro antifraud. Verifikasi dilakukan sebelum konfirmasi melalui SMS atau pemberitahuan PUSH.
Sebuah sketsa kecil dari arsitektur solusi:
Pada tahap pertama pengembangan, tujuannya ditetapkan - untuk memeriksa dua kondisi penting. Pertama, perangkat dari mana transaksi dicoba adalah baru bagi klien atau dipercaya. Kedua, apakah alat peraga tidak ada dalam daftar hitam. Kedua kondisi ini cukup untuk memblokir 70% dari insiden, untuk selebihnya, diperlukan lebih banyak informasi, misalnya, apakah ada login dengan login / kata sandi, atau dengan nomor kartu, dari negara mana Anda memasukkan RBS, dll.
Untuk menerapkan verifikasi, Anda tidak perlu begitu banyak data - pengidentifikasi unik klien, pengidentifikasi perangkatnya (dibuat di klien sendiri - aplikasi seluler dan perpustakaan JS di situs), jumlah transfer, detail transfer. Berdasarkan data ini, keputusan dibuat untuk mengizinkan atau memblokir operasi. Segera setelah seluruh sistem bekerja dengan baik dalam operasi industri, tim melanjutkan ke tahap berikutnya. Ada daftar putih dan pemuatan otomatis daftar dari FinCERT. Saat ini, mengirimkan laporan tentang insiden ke FinCERT sendiri melalui API sudah di-debug (ini adalah cerita panjang yang terpisah).
Saat ini, pembayaran berikut telah diverifikasi dalam sistem Antifraud: pembayaran P2P dengan nomor kartu, pengisian nomor telepon, transfer per detail, pengisian dompet elektronik. Penipu sering mentransfer 2.000-3.000 rubel ke nomor telepon atau dompet. Dalam hal kartu, biasanya jumlahnya mendekati jumlah semua dana yang tersedia dari klien. Selain pemeriksaan, halaman dibuat untuk operator Antifraud, tidak mungkin membuat sistem sepenuhnya otonom - seseorang diperlukan untuk memantau peristiwa, menyelidiki insiden, memblokir / membuka blokir, membuat laporan pada sistem. Sulit untuk membuat situs ketika ada dua pengembang backend dalam satu tim. Namun, tidak ada kata terlambat untuk belajar (itu keren ketika spesialis berbentuk T ada di tim!).
Pada awalnya, ketika merencanakan dan menganalisis, ada banyak pemikiran tentang memperkenalkan pembelajaran mesin, aturan dinamis, antivirus di dalam klien RBS. Namun, dilihat dari pengalaman vendor dan bank lain, lebih dari setengah kasus dapat ditutup dengan menerapkan aturan statis. Semua metode lain membutuhkan sumber daya yang besar dan tidak begitu efektif. Itulah sebabnya, tim yang terdiri dari dua pengembang dan satu analis (yang saya anggap sebagai diri saya sendiri) sudah cukup untuk menerapkan langkah-langkah perlindungan minimum dan persyaratan regulator.
Nyeri
Aturan dasar dalam pengembangan Antifraud - tidak membahayakan. Setiap perubahan dan metode baru harus diuji terlebih dahulu pada tes, kemudian pada pertempuran dalam mode pemantauan untuk memastikan bahwa tidak ada masalah. Dalam kasus terburuk, kesalahan dapat menyebabkan kerugian finansial dan hilangnya loyalitas pelanggan. Dalam kasus kami, kesalahan menyebabkan penderitaan operator yang menyelidiki dan mengelola sistem Antifraud.
Itu malam, di Malam Tahun Baru. Sistem menerapkan verifikasi tidak hanya pada perangkat seluler, tetapi juga browser klien. Menggunakan EverCookie . Pengembang menyertakan fitur, tetapi tidak mengujinya, karena perpustakaan tidak diperkenalkan di bagian depan. Hanya pada hari kerja terakhir tahun 2019, programmer front-end memutuskan untuk menuangkan cabang ke dalam prod (well, jangan tinggalkan yang sama untuk tahun berikutnya!). Karena itu, selama akhir pekan Tahun Baru, operator Antifraud menumpuk banyak pekerjaan dalam bentuk positif palsu dari sistem. Ini tidak dapat dikatakan bahwa itu penting, namun, operator sedikit menyesal ... setelah semua, pekerjaan menjadi 5 kali lebih banyak daripada sebelum perubahan dituangkan.
Ringkasan
Dalam waktu kurang dari satu tahun, tim yang sangat kecil menerapkan sistem Antifraud untuk perbankan internet. Sayangnya, masih banyak pekerjaan. Setelah berbicara dengan perwakilan bank dan vendor di forum Antifraud Russia, menjadi jelas bahwa scammer datang dengan cara-cara baru setiap tahun, Anda tidak dapat bersantai di area ini.
Jika itu menarik, saya akan menulis lebih banyak tentang solusi perangkat lunak, analitik pasar dan bagaimana menerapkan Scrum dalam tim yang terdiri dari 3 orang.