Un artículo sobre la creación de una solución interna para detectar y prevenir transacciones fraudulentas realizadas en la banca por Internet de un banco pequeño pero muy orgulloso en Tatarstán. En el artículo aprenderá por qué y quién necesita antifraude, por qué el desarrollo interno resultó ser más barato que comprar una solución preparada y a qué conducen un par de líneas de código antes del año nuevo.
Unas pocas palabras sobre usted: un especialista en seguridad de la información en una empresa de TI que accidentalmente (o quizás no) resultó ser un Propietario del producto en el equipo para el desarrollo de soluciones antifraude. La propia empresa de TI se dedica al desarrollo de software de banca por Internet.
¿Cómo empezó todo?
Para el propio banco, todo comenzó con el hecho de que el Banco Central de la Federación de Rusia cargó un borrador de enmiendas y adiciones al Reglamento N ° 382-P , que decía que el banco debería evitar la transferencia de fondos sin el consentimiento del cliente. Además, de acuerdo con la orden del Banco de Rusia No. 2831-U , el banco está obligado a informar al Banco Central sobre todos los incidentes, incluidas las acciones de los estafadores.
Para mí, la historia comenzó con una solicitud de ayuda para la formación de requisitos funcionales y el estudio de la integración con el servicio de banca remota existente (en adelante, RBS). Y lejos nos vamos ...
Datos de entrada
Antes del desarrollo, es necesario investigar el tema, estudiar desarrollos listos para usar. rastrillo navegar por el mercado.
Durante el estudio, resultó:
- Las formas más comunes de robar dinero de RBS: ingeniería social y phishing
- utilizando la ingeniería social, piratean el sistema bancario u obligan al cliente a transferir dinero voluntariamente
- la cantidad robada por los estafadores durante el año no es tan grande, el banco gasta en la investigación y la compensación de aproximadamente el 10% de esta cantidad
- El costo de una solución antifraude ya preparada excede la cantidad involucrada en el fraude entre 5 y 10 veces (sobre el costo de integrar el discurso aún no ha desaparecido ...)
- es necesario informar a FinCERT, asegúrese
- puedes destacar un par de casos muy frecuentes e importantes
Al analizar el tema del antifraude, los artículos de codezombie me ayudaron mucho. Hace 4 años, escribió sobre el antifraude utilizado en el comercio electrónico, sobre su experiencia. En mi caso, los detalles eran diferentes, pero la información era muy valiosa.
En base a estas condiciones, se decidió entregar el proyecto al equipo de desarrollo involucrado en integraciones y resolución de problemas de otros equipos, ya que este equipo incluía a los desarrolladores más experimentados y geniales. Desafortunadamente, en el equipo de 3 desarrolladores a lo largo del tiempo, solo quedaron dos. Estaba comprometido con el trabajo atrasado, la formación de requisitos, la documentación y la organización de reuniones (trabajamos en scrum, pero de qué otra manera). Dio la casualidad de que en el equipo 4 manos escribieron el código y 3 cabezas resolvieron el problema.
Casos que se pelearon
No pienses que el banco no luchó antes con maldad con estafadores Luchó con medios asequibles. Sin embargo, hubo una tendencia a que el número de incidentes relacionados con la piratería de RBS comenzó a crecer. Un esquema popular de 2018 fue el divorcio en los espacios abiertos de Avito: los estafadores que utilizan métodos de ingeniería social reconocieron el número de tarjeta y, en el diálogo, reconocieron los SMS para ingresar al RB. Por lo tanto, recibieron acceso completo a la banca por Internet de un cliente en particular. En 2019, los estafadores comenzaron a llamar a los clientes en nombre de los servicios de seguridad del banco, amenazando con perder todo el dinero, descubrieron los detalles de inicio de sesión o los instaron a transferir todos los fondos a una "cuenta segura".
El objetivo principal del equipo de desarrollo era crear un mecanismo para identificar nuevos dispositivos de clientes y detener transacciones financieras sospechosas. ¿Por qué exactamente nuevos dispositivos? Los análisis han demostrado que la mayoría de las veces obtienen acceso a la banca remota a través de un teléfono inteligente para recibir códigos de confirmación a través de notificaciones PUSH, en lugar de mensajes SMS.
Además, FinCERT comenzó a enviar listas de detalles involucrados en operaciones fraudulentas, es decir, tuvieron que ser bloqueados.
Desarrollo e integración en antifraude
Teníamos 2 programadores .NET geniales, una arquitectura de microservicio de RBS, una API REST, una docena de listas negras de varias formas y muchas integraciones de todo tipo y colores, y no había probadores ni un ingeniero devops. No es que fuera una reserva necesaria para protegerse de todos los estafadores. Pero si aún necesita hacerlo, no se detendrá. Lo único que me causó preocupación fueron los falsos positivos. No hay nada más indefenso, irresponsable y mimado que el operador antifraude que voló 20 boletos en 5 minutos. Sabía que tarde o temprano nos encontraríamos con esto.
En general, no había nada malo con la integración. SLA ha establecido un límite de 3 segundos para responder a las solicitudes. Por el momento, el tiempo de respuesta promedio es de 0.3 segundos. La arquitectura de microservicios facilitó la integración con la solución existente al agregar tres líneas para enviar una solicitud al microservicio antifraude. La verificación se lleva a cabo antes de la confirmación por SMS o notificación PUSH.
Un pequeño boceto de la arquitectura de la solución:
En la primera etapa de desarrollo, se estableció el objetivo: verificar dos condiciones importantes. En primer lugar, el dispositivo desde el que se intenta la transacción es nuevo para el cliente o es de confianza. En segundo lugar, si los accesorios no están en las listas negras. Estas dos condiciones son suficientes para bloquear el 70% de los incidentes, por lo demás, se requiere más información, por ejemplo, si hubo inicio de sesión por nombre de usuario / contraseña, o por número de tarjeta, desde qué país ingresó el RBS, etc.
Para aplicar la verificación, no necesita tantos datos: un identificador único del cliente, un identificador de su dispositivo (creado en los propios clientes - aplicaciones móviles y bibliotecas JS en el sitio), la cantidad de transferencia, detalles de transferencia. En base a estos datos, se toma la decisión de permitir o bloquear la operación. Tan pronto como todo el sistema funcionó correctamente en la operación industrial, el equipo pasó a la siguiente etapa. Hay listas blancas y carga automática de listas de FinCERT. Por el momento, el envío de informes sobre incidentes al propio FinCERT a través de la API se depura (esta es una larga historia separada).
En la actualidad, se han verificado los siguientes pagos en el sistema antifraude: pagos P2P por número de tarjeta, reposición de un número de teléfono, transferencia por detalles, reposición de billeteras electrónicas. Los estafadores a menudo transfieren 2,000-3,000 rublos a números telefónicos o billeteras. En el caso de las tarjetas, generalmente las cantidades son cercanas a la suma de todos los fondos disponibles del cliente. Además de las comprobaciones, se creó una página para operadores antifraude, es imposible hacer que un sistema sea completamente autónomo: se necesita una persona para monitorear eventos, investigar incidentes, bloquear / desbloquear, crear informes sobre el sistema. Es difícil crear un sitio cuando hay dos desarrolladores de back-end en un equipo. Sin embargo, nunca es demasiado tarde para aprender (¡es genial cuando hay especialistas en forma de T en el equipo!).
Al principio, al planificar y analizar, había muchas ideas sobre la introducción del aprendizaje automático, las reglas dinámicas y los antivirus dentro del cliente RBS. Sin embargo, a juzgar por la experiencia de los proveedores y otros bancos, más de la mitad de los casos pueden cerrarse aplicando reglas estáticas. Todos los demás métodos requieren grandes recursos y no son tan efectivos. Por eso, un equipo de dos desarrolladores y un analista (que considero que soy) es suficiente para implementar las medidas mínimas de protección y los requisitos de los reguladores.
Dolor
La regla básica en el desarrollo de antifraude: no hacer daño. Cualquier cambio y nuevos métodos deben probarse primero en la prueba, luego en la batalla en el modo de monitoreo para asegurarse de que no haya problemas. En el peor de los casos, los errores pueden conducir a pérdidas financieras y pérdida de la lealtad del cliente. En nuestro caso, el error provocó el sufrimiento de los operadores que investigan y administran el sistema antifraude.
Era tarde, en la víspera de Año Nuevo. El sistema implementó la verificación no solo de dispositivos móviles, sino también de navegadores de clientes. Usando EverCookie . Los desarrolladores incluyeron la función, pero no la probaron, ya que la biblioteca no se introdujo en los frentes. Solo el último día hábil de 2019, el programador front-end decidió verter la rama en el producto (bueno, ¡no deje lo mismo para el próximo año!). Debido a esto, durante el fin de semana de Año Nuevo, los operadores antifraude acumularon mucho trabajo en forma de falsos positivos del sistema. Esto no se puede decir que fue crítico, sin embargo, los operadores lamentan un poco ... después de todo, el trabajo se hizo 5 veces más de lo que era antes de que se vertiera el cambio.
Resumen
En menos de un año, un equipo muy pequeño implementó el sistema antifraude para la banca por Internet. Desafortunadamente, todavía hay mucho trabajo. Después de hablar con representantes de bancos y proveedores en el foro Antifraud Russia, quedó claro que los estafadores encuentran nuevas formas cada año, no puede relajarse en esta área.
Si es interesante, escribiré más sobre soluciones de software, análisis de mercado y cómo implementar Scrum en un equipo de 3 personas.