Um artigo sobre a criação de uma solução interna para detectar e impedir transações fraudulentas realizadas no Internet banking de um banco pequeno, mas muito orgulhoso, no Tartaristão. Você aprenderá com o artigo sobre por que e quem precisa de antifraude, por que o desenvolvimento interno acabou por ser mais barato do que comprar uma solução pronta e o que algumas linhas de código levam antes do ano novo.
Algumas palavras sobre você - um especialista em segurança da informação em uma empresa de TI que acidentalmente (ou talvez não muito) acabou por ser um Dono do Produto na equipe de Solução Anti-Fraude. A própria empresa de TI está envolvida no desenvolvimento de software de Internet banking.
Como tudo começou?
Para o próprio banco, tudo começou com o fato de o Banco Central da Federação Russa ter enviado um rascunho de emendas e adições ao Regulamento nº 382-P , que dizia que o banco deveria impedir a transferência de fundos sem o consentimento do cliente. Além disso, de acordo com a ordem do Banco da Rússia nº 2831-U , o banco é obrigado a informar o Banco Central sobre todos os incidentes, incluindo as ações de fraudadores.
Para mim, a história começou com uma solicitação para ajudar na formação de requisitos funcionais e no estudo da integração com o serviço de banco remoto existente (a seguir - RBS). E lá vamos nós ...
Dados de entrada
Antes do desenvolvimento, é necessário pesquisar o tópico, estudar desenvolvimentos prontos ancinho navegar no mercado.
Durante o estudo, verificou-se:
- as maneiras mais comuns de roubar dinheiro do RBS - engenharia social e phishing
- usando engenharia social, eles invadem o sistema bancário ou forçam o cliente a transferir dinheiro voluntariamente
- o valor roubado pelos fraudadores no ano não é tão grande, o banco gasta na investigação e compensação de cerca de 10% desse valor
- o custo de uma solução antifraude pronta excede o valor da participação na fraude de 5 a 10 vezes (o custo da integração da fala ainda não passou ...)
- é necessário relatar ao FinCERT, verifique se
- você pode destacar alguns casos muito frequentes e importantes
Ao analisar o tópico antifraude, os artigos do codezombie me ajudaram bastante. Há quatro anos, ele escreveu sobre o antifraude usado no comércio eletrônico, sobre sua experiência. No meu caso, as especificidades eram diferentes, mas as informações eram muito valiosas.
Com base nessas condições, foi decidido entregar o projeto à equipe de desenvolvimento que lida com integrações e solução de problemas de outras equipes, pois essa equipe incluía os desenvolvedores mais experientes e legais. Infelizmente, na equipe de três desenvolvedores ao longo do tempo, apenas dois permaneceram. Eu estava envolvido no backlog, na formação de requisitos, na documentação e na organização de reuniões (trabalhamos no scrum, mas de que outra forma). Aconteceu que na equipe quatro mãos escreveram o código e três cabeças resolveram o problema.
Casos que foram travados
Não pense que o banco não lutou antes com o mal com golpistas. Lutou com meios acessíveis. No entanto, havia uma tendência de que o número de incidentes relacionados ao hackers do RBS começasse a crescer. Um esquema popular de 2018 foi o divórcio nos espaços abertos do Avito - os fraudadores que usam métodos de engenharia social reconheceram o número do cartão e, no diálogo, reconheceram o SMS para entrar na RB. Assim, eles receberam acesso total ao Internet banking de um determinado cliente. Em 2019, os fraudadores começaram a telefonar para clientes em nome dos serviços de segurança do banco, ameaçando perder todo o seu dinheiro, descobrindo os detalhes de login ou instando-os a transferir todos os fundos para uma "conta segura".
O principal objetivo da equipe de desenvolvimento era criar um mecanismo para identificar novos dispositivos do cliente e interromper transações financeiras suspeitas. Por que exatamente novos dispositivos? O Google Analytics mostrou que, na maioria das vezes, eles obtêm acesso ao banco remoto por meio de um smartphone para receber códigos de confirmação por meio de notificações PUSH, em vez de mensagens SMS.
Além disso, o FinCERT começou a enviar listas de detalhes envolvidos em operações fraudulentas, ou seja, eles tiveram que ser bloqueados.
Desenvolvimento e integração no Antifraud
Tínhamos 2 programadores .NET legais, uma arquitetura de microsserviço do RBS, uma API REST, uma dúzia de listas negras de várias formas e várias integrações de todos os tipos e cores, e não havia testadores ou engenheiro de devops. Não que fosse uma reserva necessária para proteção contra todos os golpistas. Mas se você ainda precisar fazer isso, não irá parar. A única coisa que me preocupou foram os falsos positivos. Não há nada mais impotente, irresponsável e mimado do que o operador antifraude que comprou 20 bilhetes em 5 minutos. Eu sabia que mais cedo ou mais tarde encontraríamos isso.
Em geral, não havia nada errado com a integração. O SLA definiu um limite de 3 segundos para responder às solicitações. No momento, o tempo médio de resposta é de 0,3 segundos. A arquitetura do microsserviço facilitou a integração com a solução existente, adicionando três linhas para enviar uma solicitação ao microsserviço antifraude. A verificação ocorre antes da confirmação por SMS ou notificação PUSH.
Um pequeno esboço da arquitetura da solução:
No primeiro estágio do desenvolvimento, o objetivo foi estabelecido - verificar duas condições importantes. Em primeiro lugar, o dispositivo no qual a transação é tentada é novo para o cliente ou é confiável. Em segundo lugar, se os objetos não estão nas listas negras. Essas duas condições são suficientes para bloquear 70% dos incidentes; quanto ao restante, são necessárias mais informações, por exemplo, houve login por login / senha ou número do cartão, de qual país você entrou no RBS, etc.
Para aplicar a verificação, você não precisa de muitos dados - um identificador exclusivo do cliente, identificador de seu dispositivo (criado nos próprios clientes - aplicativos móveis e bibliotecas JS no site), quantidade de transferência, detalhes da transferência. Com base nesses dados, é tomada uma decisão para permitir ou bloquear a operação. Assim que todo o sistema funcionou corretamente na operação industrial, a equipe passou para a próxima etapa. Existem listas brancas e carregamento automático de listas do FinCERT. No momento, o envio de relatórios de incidentes para o próprio FinCERT por meio da API é depurado (esta é uma história longa separada).
Atualmente, os seguintes pagamentos foram verificados no sistema antifraude: pagamentos P2P por número de cartão, reposição de um número de telefone, transferência por detalhes, reposição de carteiras eletrônicas. Os fraudadores costumam transferir de 2 a 3 mil rublos para números de telefone ou carteiras. No caso de cartões, geralmente os valores são próximos à soma de todos os fundos disponíveis do cliente. Além das verificações, uma página foi criada para os operadores do Antifraud, não é possível criar um sistema totalmente autônomo - é necessário uma pessoa para monitorar eventos, investigar incidentes, bloquear / desbloquear, criar relatórios no sistema. É difícil criar um site quando há dois desenvolvedores de back-end em uma equipe. No entanto, nunca é tarde para aprender (é legal quando especialistas em forma de T estão na equipe!).
No início, ao planejar e analisar, havia muitos pensamentos sobre a introdução de aprendizado de máquina, regras dinâmicas e antivírus dentro do cliente RBS. No entanto, a julgar pela experiência de fornecedores e outros bancos, mais da metade dos casos pode ser encerrada com a aplicação de regras estáticas. Todos os outros métodos requerem grandes recursos e não são tão eficazes. Por isso, uma equipe de dois desenvolvedores e um analista (que eu me considero) é suficiente para implementar as medidas mínimas de proteção e os requisitos dos reguladores.
Dor
A regra básica no desenvolvimento do Antifraud - não faça mal. Quaisquer alterações e novos métodos devem ser testados primeiro no teste e depois na batalha no modo de monitoramento para garantir que não haja problemas. Na pior das hipóteses, erros podem levar a perdas financeiras e perda de fidelidade do cliente. No nosso caso, o erro levou ao sofrimento dos operadores que investigavam e gerenciavam o sistema antifraude.
Era noite, na véspera de ano novo. O sistema implementou a verificação não apenas de dispositivos móveis, mas também de navegadores de clientes. Usando o EverCookie . Os desenvolvedores incluíram o recurso, mas não o testaram, pois a biblioteca não foi apresentada nas frentes. Somente no último dia útil de 2019, o programador front-end decidiu despejar o ramo no produto (bem, não deixe o mesmo para o próximo ano!). Por esse motivo, durante o fim de semana do ano novo, os operadores do Antifraud empilharam muito trabalho na forma de falsos positivos do sistema. Não se pode dizer que isso era crítico, no entanto, os operadores lamentam um pouco ... afinal, o trabalho se tornou 5 vezes mais do que era antes da mudança ser derramada.
Sumário
Em menos de um ano, uma equipe muito pequena implementou o sistema Antifraud para Internet banking. Infelizmente, ainda há muito trabalho. Depois de conversar com representantes de bancos e fornecedores no fórum Antifraud Rússia, ficou claro que os golpistas criam novas maneiras a cada ano, e você não pode relaxar nesta área.
Se for interessante, escreverei mais sobre soluções de software, análises de mercado e como implementar o Scrum em uma equipe de 3 pessoas.