Ein Artikel über die Schaffung einer Inhouse-Lösung zur Aufdeckung und Verhinderung betrügerischer Transaktionen im Internet-Banking einer kleinen, aber sehr stolzen Bank in Tatarstan. Sie erfahren aus dem Artikel, warum und wer Betrugsbekämpfung benötigt, warum die interne Entwicklung billiger war als der Kauf einer gebrauchsfertigen Lösung und wozu einige Codezeilen vor dem neuen Jahr führten.
Ein paar Worte zu Ihrer Person - ein Informationssicherheitsspezialist in einem IT-Unternehmen, der sich versehentlich (oder vielleicht nicht sehr) als Product Owner im Anti-Fraud Solution-Team herausgestellt hat. Das IT-Unternehmen selbst ist an der Entwicklung von Internet-Banking-Software beteiligt.
Wie hat alles angefangen?
Für die Bank selbst begann alles damit, dass die Zentralbank der Russischen Föderation einen Entwurf von Änderungen und Ergänzungen der Verordnung Nr. 382-P hochlud, wonach die Bank die Überweisung von Geldern ohne Zustimmung des Kunden verhindern sollte. Darüber hinaus ist die Bank gemäß der Anordnung der Bank von Russland Nr. 2831-U verpflichtet, der Zentralbank alle Vorfälle, einschließlich der Handlungen von Betrügern, zu melden.
Die Geschichte begann für mich mit der Bitte, bei der Bildung von funktionalen Anforderungen und der Untersuchung der Integration mit dem vorhandenen Remote-Banking-Service (im Folgenden: RBS) behilflich zu sein. Und los geht's ...
Daten eingeben
Vor der Entwicklung ist es notwendig, das Thema zu recherchieren, fertige Entwicklungen zu studieren Rechen Stöbern Sie auf dem Markt.
Während des Studiums stellte sich heraus:
- Die gebräuchlichsten Methoden, um Geld von RBS zu stehlen - Social Engineering und Phishing
- Mit Social Engineering hacken sie sich entweder in das Bankensystem ein oder zwingen den Kunden, freiwillig Geld zu überweisen
- Der von Betrügern für das Jahr gestohlene Betrag ist nicht so hoch, die Bank gibt für die Ermittlung und Entschädigung etwa 10% dieses Betrags aus
- Die Kosten für eine vorgefertigte Betrugsbekämpfungslösung übersteigen den Betrugsbetrag um das 5- bis 10-fache (etwa die Kosten für die Integration von Sprache sind noch nicht weg ...).
- Es ist unbedingt erforderlich, sich bei FinCERT zu melden
- Sie können einige sehr häufige und wichtige Fälle hervorheben
Bei der Analyse des Themas Betrugsbekämpfung haben mir Codezombie- Artikel sehr geholfen. Welche 4 Jahre schrieb er über die Betrugsbekämpfung im E-Commerce, über seine Erfahrungen. In meinem Fall waren die Einzelheiten unterschiedlich, aber die Informationen waren sehr wertvoll.
Auf der Grundlage dieser Bedingungen wurde beschlossen, das Projekt dem Entwicklungsteam zu übergeben, das sich mit Integrationen und der Lösung der Probleme anderer Teams befasst, da dieses Team die erfahrensten und coolsten Entwickler umfasste. Leider blieben im Team von 3 Entwicklern im Laufe der Zeit nur zwei übrig. Ich beschäftigte mich mit dem Rückstand, der Bildung von Anforderungen, der Dokumentation und der Organisation von Besprechungen (wir arbeiten an Scrum, aber wie auch immer). Es geschah, dass im Team 4 Hände den Code schrieben und 3 Köpfe das Problem lösten.
Fälle, die gekämpft wurden
Denken Sie nicht, dass die Bank vorher nicht gekämpft hat mit dem Bösen mit Betrügern. Mit erschwinglichen Mitteln gekämpft. Es gab jedoch eine Tendenz, dass die Anzahl der Vorfälle im Zusammenhang mit dem Hacking von RBS zuzunehmen begann. Ein populäres Schema im Jahr 2018 war eine Scheidung in den Avito-Freiflächen - Betrüger erkannten mithilfe von Social-Engineering-Methoden die Kartennummer und im Dialog erkannten sie SMS, um die RB einzugeben. So erhielten sie vollen Zugriff auf das Internet-Banking eines bestimmten Kunden. Im Jahr 2019 begannen Betrüger, Kunden im Namen der Sicherheitsdienste der Bank anzurufen und drohten, ihr gesamtes Geld zu verlieren, die Anmeldedaten herauszufinden oder alle Gelder auf ein „sicheres Konto“ zu überweisen.
Das Hauptziel des Entwicklungsteams bestand darin, einen Mechanismus zu entwickeln, mit dem neue Kundengeräte identifiziert und verdächtige Finanztransaktionen gestoppt werden können. Warum genau neue Geräte? Analysen haben gezeigt, dass sie am häufigsten über ein Smartphone auf das Remote-Banking zugreifen, um Bestätigungscodes über Push-Benachrichtigungen und nicht über SMS-Nachrichten zu erhalten.
Darüber hinaus begann FinCERT, Listen mit Details zu senden, die an betrügerischen Vorgängen beteiligt waren, das heißt, sie mussten gesperrt werden.
Entwicklung und Integration in Antifraud
Wir hatten 2 coole .NET-Programmierer, eine Microservice-Architektur der RBS, eine REST-API, ein Dutzend Blacklists unterschiedlicher Formen und eine Menge Integrationen aller Art und Farben, und es gab keine Tester oder Entwickler. Nicht, dass es eine notwendige Reserve für den Schutz vor allen Betrügern gewesen wäre. Aber wenn Sie es noch tun müssen, werden Sie nicht aufhören. Das einzige, was mich beunruhigte, waren die Fehlalarme. Es gibt nichts Hilfloseres, Verantwortungsloseres und Verwöhnteres als den Betrugsbekämpfer, der in 5 Minuten 20 Tickets flog. Ich wusste, dass wir früher oder später darauf stoßen würden.
Generell war an der Integration nichts auszusetzen. SLA hat ein Limit von 3 Sekunden festgelegt, um auf Anforderungen zu antworten. Momentan beträgt die durchschnittliche Antwortzeit 0,3 Sekunden. Die Microservice-Architektur machte es einfach, sich in die vorhandene Lösung zu integrieren, indem drei Zeilen hinzugefügt wurden, um eine Anfrage an den Microservice für Betrugsbekämpfung zu senden. Die Überprüfung erfolgt vor der Bestätigung per SMS oder PUSH-Benachrichtigung.
Eine kleine Skizze der Lösungsarchitektur:
In der ersten Phase der Entwicklung wurde das Ziel festgelegt, zwei wichtige Bedingungen zu überprüfen. Erstens ist das Gerät, von dem aus die Transaktion versucht wird, für den Client neu oder als vertrauenswürdig eingestuft. Zweitens, ob die Requisiten nicht auf der schwarzen Liste stehen. Diese beiden Bedingungen reichen aus, um 70% der Vorfälle zu blockieren. Im Übrigen sind weitere Informationen erforderlich, z. B., ob Sie sich über Login / Passwort oder Kartennummer anmelden, aus welchem Land Sie den RB eingegeben haben usw.
Um die Überprüfung durchzuführen, benötigen Sie nicht so viele Daten - eine eindeutige Kennung des Kunden, die Kennung seines Geräts (die auf den Kunden selbst erstellt wurde - mobile Anwendungen und JS-Bibliotheken auf der Website), den Umfang der Übertragung, die Übertragungsdetails. Auf der Grundlage dieser Daten wird eine Entscheidung getroffen, die Operation zuzulassen oder zu blockieren. Sobald das gesamte System im industriellen Betrieb einwandfrei funktionierte, ging das Team zur nächsten Stufe über. Es gibt Whitelists und das automatische Laden von Listen aus FinCERT. Momentan wird das Senden von Meldungen zu Vorfällen über die API an FinCERT selbst getestet (dies ist eine separate lange Geschichte).
Gegenwärtig werden im Betrugsbekämpfungssystem folgende Zahlungen verifiziert: P2P-Zahlungen nach Kartennummer, Auffüllung einer Telefonnummer, Übermittlung nach Details, Auffüllung elektronischer Geldbörsen. Betrüger übertragen häufig 2.000-3.000 Rubel auf Telefonnummern oder Geldbörsen. Bei Karten liegen die Beträge in der Regel nahe an der Summe aller verfügbaren Gelder des Kunden. Zusätzlich zu den Überprüfungen wurde eine Seite für Betrugsbekämpfer erstellt. Es ist nicht möglich, ein vollständig autonomes System zu erstellen. Eine Person wird benötigt, um Ereignisse zu überwachen, Vorfälle zu untersuchen, zu blockieren / entsperren und Berichte über das System zu erstellen. Es ist schwierig, eine Site zu erstellen, wenn sich zwei Backend-Entwickler in einem Team befinden. Es ist jedoch nie zu spät zu lernen (es ist cool, wenn T-förmige Spezialisten im Team sind!).
Am Anfang der Planung und Analyse standen viele Überlegungen zur Einführung von maschinellem Lernen, dynamischen Regeln und Antivirenprogrammen im RBS-Client. Nach den Erfahrungen von Anbietern und anderen Banken kann jedoch mehr als die Hälfte der Fälle durch Anwendung statischer Regeln abgeschlossen werden. Alle anderen Methoden erfordern große Ressourcen und sind nicht so effektiv. Aus diesem Grund reicht ein Team aus zwei Entwicklern und einem Analysten (was ich für ausreichend halte), um die Mindestschutzmaßnahmen und die Anforderungen der Aufsichtsbehörden umzusetzen.
Schmerz
Die Grundregel bei der Entwicklung von Betrugsbekämpfung - keinen Schaden anrichten. Änderungen und neue Methoden sollten zuerst im Test und dann im Kampf im Überwachungsmodus getestet werden, um sicherzustellen, dass keine Probleme vorliegen. Fehler können im schlimmsten Fall zu finanziellen Verlusten und zum Verlust der Kundenbindung führen. In unserem Fall hat der Fehler dazu geführt, dass die Bediener das Betrugsbekämpfungssystem untersucht und verwaltet haben.
Es war Abend an Silvester. Das System implementierte die Überprüfung nicht nur mobiler Geräte, sondern auch von Client-Browsern. EverCookie verwenden . Die Entwickler nahmen das Feature auf, testeten es jedoch nicht, da die Bibliothek an den Fronten nicht vorgestellt wurde. Erst am letzten Arbeitstag des Jahres 2019 beschloss der Front-End-Programmierer, den Zweig in das Produkt zu füllen (nun, lassen Sie ihn nicht für das nächste Jahr gleich!). Aus diesem Grund haben die Betrugsbekämpfer am Neujahrswochenende eine Menge Arbeit in Form von Fehlalarmen des Systems angehäuft. Dies kann nicht als kritisch bezeichnet werden, die Bediener bedauern es jedoch ein wenig. Immerhin wurde die Arbeit fünfmal so groß wie vor dem Umbau.
Zusammenfassung
In weniger als einem Jahr implementierte ein sehr kleines Team das Betrugsbekämpfungssystem für das Internetbanking. Leider gibt es noch viel Arbeit. Nach Gesprächen mit Vertretern von Banken und Anbietern auf dem Forum gegen Betrug in Russland wurde deutlich, dass Betrüger jedes Jahr neue Wege finden. In diesem Bereich können Sie sich nicht entspannen.
Wenn es interessant ist, schreibe ich mehr über Softwarelösungen, Marktanalysen und die Implementierung von Scrum in einem Team von 3 Personen.