Para NOFRAUD fue un reto hace 10 años diseñar una arquitectura de TI que pudiese procesar grandes cantidades de datos a una altísima velocidad. Cuando se concibió el modelo, se proyectó para que pudiese soportar más de 10 años de operación. Ya pasados todos esos años hemos comprobado que fue exitoso y es por ello que en este artículo les vamos a compartir qué fue lo que diseñamos.
Los encargados de diseñar y desarrollar la arquitectura fueron ingenieros de Red Hat, Arquitectos de Software, Profesionales en Seguridad de la información, Desarrolladores de Software y Expertos Anti-fraude.
Otro reto con el que nos enfrentamos fue el sitio, proveedor o datacenter donde alojaríamos nuestra plataforma, ya que para pagar una granja de servidores debíamos tener muchísimo dinero y NOFRAUD no contaba con ángeles inversionistas, ni fondos de inversión, ni créditos, sólo el dinero corriente en los bolsillos de sus fundadores. Así pues, ésta será la historia de cómo, con muy poco dinero, tuvimos que diseñar e implementar una plataforma que tenía que procesar más datos de los que incluso algunos Bancos procesan.
Sistemas operativos y virtualización
Decidimos que los sistemas operativos tenían que ser basados en UNIX dada nuestra experiencia con Solaris (Sun Microsystems). Escogimos un clon de Red Hat y el sistema de virtualización basado en contenedores OpenVZ, que demostraba ya desde hace mucho tiempo ser el más eficiente en el manejo de los recursos, muy similar al sistema de virtualización de Solaris basado en Zonas, con el que nos sentíamos muy cómodos.
El sistema de almacenamiento debía ser jerárquico, donde tuviéramos espacios de consulta inmediata de datos, con la mayor velocidad posible y otro espacio para la consulta diferida y no inmediata, o por lo menos no con una necesidad de urgencia. Escogimos un hardware que nos proporcionó nuestro proveedor de datacenter en Europa y creamos una capa lógica basada en LVM, que nos permitía expandir y reducir los sistemas de archivos con facilidad, además de automatizar el respaldo a través de Snapshots en caliente.
Centro de datos
En esa época no estaba tan popularizado AWS, Azure o Google Cloud, de hecho, algunos de ellos ni siquiera existían. Debido a que ya teníamos experiencia trabajando con un Datacenter Alemán, decidimos alojar nuestros servidores con ese mismo proveedor que tanta confianza nos había dado años atrás. En este Datacenter, alquilamos un espacio para poner nuestros propios servidores, negociamos un ancho de banda, un consumo energético y una infraestructura de red basada en CISCO para el Firewall.
Durante el primer año de guerra entre Ucrania y Russia, sufrimos el incremento de precios a causa de la escasez generada para el gas en todo el continente Europeo. Sin embargo, la solidez de nuestro proveedor y el incremento en ventas de nuestra compañía hicieron posible superar la crisis.
Esta es una foto real de la ubicación de nuestro centro de datos. Considerado el mejor y más grande en Europa, es el que nos ha acompañado desde hace más de 20 años en el soporte de nuestras tecnologías. Hoy en día tenemos una granja de servidores en colocación, un almacenamiento jerárquico, una granja de procesamiento de redes neuronales, sitios alternos donde la plataforma puede arrancar en caso de desastre y toda la conectividad privada con CISCO.
La capa de almacenamiento lógico
Estaba claro que el almacenamiento físico era bueno, por ser jerárquico, también estaba claro que usando LVM teníamos mucha flexibilidad y seguridad en la gestión de los sistemas de archivos. Ahora lo que necesitábamos era escoger una tecnología lógica, una solución para almacenar grandes cantidades de datos.
El stack Elastic fue el elegido, dada también la experiencia pasada de nuestros ingenieros. Montamos varios cluster de Elasticsearch y encontramos en Logstash el mejor y más eficiente sistema para la ingesta de datos a ese nivel de volumen y velocidad que íbamos a manejar.
Una vez llegados los datos, escogimos a Ruby como lenguaje de programación para que hiciera esa primera gestión de cada dato que llegaba (chequeo, descifrado, organización, preparación, validación) antes de ser enviado al cluster de Elasticsearch. Ningún dato entra a nuestro cluster si previamente no ha superado varias condiciones de seguridad y suficiencia.
El procesamiento de los datos
Una vez que superamos los desafíos técnicos en la ingesta y almacenamiento de los datos, seguía su procesamiento. Como teníamos mucha experiencia en C, C++ y Objective C, diseñamos nuestro propio “procesador de datos” inspirados en la solución ElastAlert, que si bien no la usamos, decidimos que nuestro procesador debería tener un diseño muy similar en cuanto a la generación de alertas basada en los datos que ya previamente se recibían con Logstash y lo organizamos de la siguiente manera:
- AI Fraud Triangle Processor: fue el nombre que le dimos al sistema desarrollado en C que lo que hace es analizar los datos que ya se encuentran en Elasticsearch. Este procesador aplica varios algoritmos y varias capas de inteligencia artificial para generar en última instancia una alerta de un comportamiento sospechoso. Como es de notar, los datos que va ingestando Logstash vienen demasiado rápido, por lo que todo nuestro software tuvo que partir de la base de paralelismo e hilos. Una vez que los datos entren a Elasticsearch, éste procesador va y los analiza con la máxima potencia computacional de la que dispone, de manera automática y periódica.
-
Procesamiento con las IA: este mismo procesador desarrollado en C, aplica varias capas de algoritmos e inteligencia artificial sobre los datos para determinar si se genera una alerta o no. La primera capa que aplica es la de intimidad/privacidad, donde el objetivo es ignorar aquellas alertas que por su contenido estén relacionadas con un tema íntimo de la vida privada del colaborador y que no tenga nada que ver con el aspecto corporativo. La segunda IA que interviene analiza el contexto sentimental. La tercera que interviene analiza la honestidad, la cuarta aplica el algoritmo del triángulo del fraude y la quinta aplica FraudGPT, nuestra IA generativa.
-
Almacenamiento de alertas: si el procesador decide o infiere que debe generar una alerta, después de aplicarse las IA por capas, éstas se almacenan también en el cluster Elasticsearch con información muy rica, para que un dashboard pueda presentarlas de la mejor forma y aplicar sobre ellas la lógica de negocio.
Este proceso de ingesta y procesamiento de los datos ocurre muy rápido y gracias a que el encargado de analizar los datos y generar alertas es un software que hemos diseñado a muy bajo nivel y con milti-hilos, se produce todo en cuestión de segundos.
El dashboard y la lógica de negocio
Las alertas por si solas no dicen mucho. Es necesario construir todo un servicio de valor agregado alrededor de ellas. Sobre estas alertas se pueden crear reportes personalizados, gráficas, agrupaciones, flujos de trabajo, se puede crear un entorno multi-usuario que permita la visualización según los roles, crear los agentes encargados de la recolección de los datos, administrar el backup, etc.
Fue así como diseñamos un dashboard en Javascript, HTML y un poco de PHP (nos gustaba el tema multi-hilos) y fuimos creando una plataforma muy profesional que año tras año ha ido madurando hasta ser hoy en día una plataforma bastante completa para la administración del riesgo de fraude a partir de las alertas que se generan por las IA en capas.
Diseño multi cliente pero isolado
Desde un principio sabíamos que el diseño debía soportar una arquitectura multi cliente, pero al mismo tiempo cada cliente debía estar aislado o isolado de los otros. Esto planteaba varios retos, a los cuales les dimos solución así:
-
Aislamiento: cada cliente iba a tener su propia instancia, es decir, su propio contenedor dentro de OpenVZ. El aislamiento no debería ser solamente a nivel de sistema operativo, sino que para cada cliente quisimos tener una dirección IPv4 dedicada, un enrutamiento privado, certificados independientes y un balanceador de conexiones exclusivo.
-
Administración: cómo hacemos para administrar todos los clientes si son independientes?, pensamos mucho en esto y creamos un sistema de autenticación centralizado implementando nuestro propio generador OTP para darle un grado de seguridad adicional.
Canales de datos y compatibilidad
De dónde vamos a extraer los datos?. Ya sabíamos qué tipo de datos necesitábamos para analizar el comportamiento humano, el semántico, pero no sabíamos como ir por ellos. La solución a este reto fue como se los describo a continuación:
- Vamos al origen: si el dato semántico se genera en la boca o en los dedos de un colaborador, busquemos la manera de capturar la voz o lo que está escribiendo. Fue así como desarrollamos en .NET C# un agente para Windows y creamos una mini inteligencia artificial que fuera capaz de identificar el momento en que el colaborador interactuaba semánticamente con las apps de negocio y así poder capturar los metadatos que nos interesaban: con quien habla, a que horas, de qué habla, en que aplicación, qué está diciendo, qué le están respondiendo. Esto lo hicimos no solamente para Windows, sino para Linux (con lenguaje C), para MacOS (Con Objective C y Swift), para Android (con Java) y para las plantas telefónicas Asterisk (Lenguaje C y AGI). Así pudimos tener una cobertura del 100% sobre las aplicaciones en las que podíamos capturar datos, desde WhatsApp en Android y Windows/Linux/Mac, hasta Outlook.
- Vamos a la fuente: entendimos que no solamente debíamos limitarnos a capturar datos desde el origen, sino que también podíamos ir a la fuente donde residían estos datos, por ejemplo, ir a Microsoft 365 o Google Workspace, fue por ello que desarrollamos los conectores para poder ir por estos datos.
- Permitamos análisis diferidos: varios clientes empezaron a pedirnos el uso de la IA sobre datos diferidos, es decir, sobre correos antiguos, chat de hace muchos años o documentos almacenados hace meses. Esto nos llevó a crear una API que pudiera prestar el servicio de analítica de manera customizada y de aquí en adelante surgieron muchas ideas buenas, como por ejemplo la de desarrollar una aplicación forense para Windows que pudiera analizar PST con nuestra IA.
Monitoreo de la plataforma
El sistema de monitoreo debería ser holístico y fácil de modificar y ajustar a nuestras necesidades. Es por ello que elegimos Zabbix y desarrollamos varios plugins a la medida para que satisfacieran algunas necesidades:
- Plugin para monitoreo de Logstash: hicimos un desarrollo para que monitoreara la calidad de los datos y todo el flujo de comunicación entre él y Elasticsearch, así como la memoria, los hilos y el Garbage Collector.
- Plugin para la salud de The Fraud Explorer: desarrollamos un plugin que monitorea las diferentes capas de las inteligencias artificiales, para asegurarnos que si hay algún fallo en una de ellas, podamos actuar rápidamente.
- Plugin para el monitoreo de la granja de GPUs: desarrollamos un plugin que pudiera monitorear diferentes aspectos de las GPUs, como temperatura, uso y memoria, pero también temas más detallados como las solicitudes de procesamiento de alertas, en donde necesitábamos saber si para cada petición la IA generativa estaba respondiendo de manera adecuada.
- Plugin para el cluster Elasticsearch: tenemos 6 clusters, cada uno conformado entre 10 a 20 instancias, por lo que el monitoreo de la salud de cada cluster debía tener ciertas particularidades, las cuales ajustamos a nuestras necesidades.
Configuramos el flujo de alertas y las separamos por criticidad de forma que dependiendo del tipo de alerta, se redirecciona a un grupo especial de ingeniería.
Seguridad en la plataforma
Desde un inicio, el desarrollo del software y de la arquitectura de TI tuvo la seguridad presente. Los siguientes fueron y son los esfuerzos que aplicamos para la seguridad de la información de todo nuestro negocio:
- Assessment ISO 27k y CIS: contamos con un assessment de todos los controles del Anexo A de la norma ISo27001. Contamos con una política de la seguridad de la información, un plan de continuidad del negocio, de gestión de incidentes y de manejo de datos. Tenemos más de 133 controles de seguridad aplicados a toda la plataforma y anualmente personal certificado re-valida la efectividad de los controles.
- Assessment GDPR: todo el diseño estuvo orientado a cumplir con la regulación de tratamiento de datos del Parlamento Europeo. Aplicamos más de 33 buenas prácticas para el tratamiento de datos personales, dentro de los cuales se encuentra la minimización de los datos, la retención, el enmascaramiento, la auditoría, el borrado seguro, el cifrado, entre otros.
- Auditoría automática al código fuente: usamos el método de hacking-continuo aplicado a nuestro código fuente. Todo el código de The Fraud Explorer cuenta con 57 mil líneas de código y cada vez que hacemos un desarrollo nuevo, una mejora o modificación de un módulo, se pasan los controles del análisis estático y dinámico de código antes de generar el Build de la versión definitiva. A esto le sumamos que con la ayuda e GitHub, tenemos varios puntos de revisión y análisis para que en caso de no detectarse vulnerabilidad en un componente, se detecte en otro.
- Pruebas de aceptación de seguridad: desarrollamos un componente especial de pruebas de unidad y aceptación enfocadas a la seguridad, en donde cada vez que sacamos una nueva versión se corren mas de 432 asserts que verifican toda la lógica de negocio de la plataforma buscando errores.
- Test de penetración y hacking éticos: contamos con tests externos que han realizado las empresas mas reconocidas del mundo a nuestra plataforma y que hacemos cada año. Adicionalmente, tenemos una empresa contratada en Europa que hace pruebas automáticas todos los meses sobre toda nuestra plataforma enfocada en OWASP.
Nuestro servicio de colocación en datacenter tiene contratado una protección contra DDoS (Ataques de denegación de servicio) e internamente en nuestra infraestructura hemos implementado servicios WAF (Web Application Firewall) y de filtros de Geolocalización para el bloqueo de conexiones basados en grandes bases de datos que manejan Rankings de direcciones IP de baja reputación.
Lo que nuestros clientes ven
Nuestros clientes perciben de nosotros unas alertas que contienen los suficientes metadatos para deducir o sospechar que hay algo que está sucediendo y atenta contra la ética y los valores no solo de la organización sino de la sociedad. Nuestros clientes no se tienen que preocupar por toda la arquitectura e ingeniería que hay detrás, de eso nos encargamos nosotros.
Referencias
(The Fraud Explorer, 2024) El software que previene, detecta y pronostica la ocurrencia de actos deshonestos en las organizaciones.
Acerca de NOFRAUD
NOFRAUD es la compañía que desarrolla el software antifraude The Fraud Explorer y apoya a personas y empresas a enfrentar y solucionar sus retos en materia de fraude interno, corrupción y abuso corporativo. NOFRAUD ha creado la base de datos conductual de actos deshonestos más grande del mundo en Español e Inglés, que sirve para que la inteligencia artificial encuentre patrones sospechosos de corrupción al interior de las organizaciones.
Mejoramos la capacidad de las organizaciones incrementando sus beneficios, arrebatándole a los perpetradores la posibilidad de afectar negativamente los ingresos a través del fraude, la corrupción, el abuso corporativo y la generación de ambientes tóxicos.
Contacte conmigo en » jrios@nofraud.la y Visítenos en » www.nofraud.la.
