Ciberseguridad fintech: cómo desarrollar de forma segura con código abierto

¿Por qué es importante la ciberseguridad para las empresas fintech?

Las transacciones financieras son un objetivo natural para los hackers que buscan obtener dinero fácilmente. Por esta razón, los bancos tradicionales están sujetos a estrictas regulaciones de ciberseguridad. Sin embargo, las empresas de tecnología financiera (fintech) no están tan reguladas como los bancos y, a menudo, omiten pasos clave del proceso de seguridad, especialmente cuando no hay un requisito claro para proteger por completo las aplicaciones.

Pero las empresas fintech deberían considerar la ciberseguridad como su máxima prioridad por varias razones:

Tipos de datos almacenados

Como las empresas fintech manejan los mismos tipos de datos financieros que los bancos, son un objetivo atractivo para los atacantes. Estos datos confidenciales incluyen información de cuentas, saldos, información sobre flujos de efectivo y presupuestos, además de datos de contacto.

Dado el valor de estos datos, en especial para su análisis en proyectos de IA/ML, las empresas fintech tienen incentivos para almacenar tantos datos específicos y útiles como sea posible. Sin embargo, hay una contrapartida: almacenar grandes volúmenes de datos las convierte en un objetivo más valioso.

Costo de las brechas

Para los bancos tradicionales, el costo de una brecha incluye tanto costos directos como indirectos, por ejemplo, el daño a la reputación y las multas. Una sola brecha también podría hacer que miles de clientes se vayan. Como las empresas fintech manejan el mismo tipo de datos que los bancos, una brecha puede tener un impacto negativo similar. La pérdida de confianza de los clientes y el daño a la reputación pueden ser los aspectos más costosos de una brecha, sobre todo para las startups fintech o las empresas que experimentan un crecimiento acelerado. Las brechas también pueden tener consecuencias legales, como multas y demandas.

Cumplimiento normativo

Las empresas fintech tienen la obligación de cumplir con los requisitos de Conoce a tu cliente (KYC), así como con las regulaciones locales de cada región donde se encuentren sus clientes. Estas regulaciones incluyen:

• Para la UE: El Reglamento General de Protección de Datos (GDPR) regula el tratamiento de datos personales de las personas que residen en la UE, incluso si la organización está fuera de la UE. El Reglamento de Identificación Electrónica y Servicios de Confianza (eIDAS) rige las transacciones digitales transfronterizas y proporciona un marco unificado para las empresas fintech, las organizaciones de clientes, las autoridades reguladoras y los usuarios finales. La Directiva de Servicios de Pago (PSD2) establece requisitos de seguridad para los pagos electrónicos. A menudo, PSD2 se superpone con GDPR, por lo que puede ser necesario consultar a especialistas para garantizar el cumplimiento.

• Para EE. UU.: El Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS), que regula la recopilación, el procesamiento y el uso de datos de las principales tarjetas de crédito.

• Para el estado de California: La Ley de Privacidad del Consumidor de California (CCPA) se parece a GDPR, pero tiene algunas diferencias, por ejemplo, en las definiciones de términos legales. Yodlee, un agregador de datos fintech, enfrentó una demanda colectiva tras presuntamente infringir la CCPA con sus prácticas de recopilación y uso de datos.

¿Qué desafíos de ciberseguridad enfrentan las empresas fintech?

La ciberseguridad debe ser una prioridad máxima para las empresas fintech, pero hay muchos obstáculos para proteger adecuadamente las aplicaciones. Tradicionalmente, la ciberseguridad se ha centrado en proteger el producto final mediante contraseñas, cifrado, autenticación multifactor y lógica segura. La responsabilidad de la seguridad recaía en los equipos de operaciones de TI y seguridad. En su mayoría, las aplicaciones se probaban después de su lanzamiento al entorno de producción, lo que dejaba expuestas a muchas organizaciones. Cuando se detectaba un error o una vulnerabilidad, los equipos de seguridad tenían que volver sobre la aplicación y contactar a los desarrolladores.

Ahora, la mayoría de las empresas también incorporan pruebas de seguridad antes del lanzamiento. El problema es que pueden producirse resultados imprevistos que alargan el ciclo de lanzamiento. ¿Cómo se manejan decenas o posiblemente cientos de vulnerabilidades que podrías descubrir? Corregirlas podría requerir reescribir componentes de software subyacentes de forma significativa, que luego habría que volver a verificar y probar. Además, esto genera fricción entre los equipos de seguridad y los desarrolladores. Es posible que los desarrolladores publiquen software inseguro para llevar más rápido un producto fintech al mercado, pero corregir los problemas más adelante en el ciclo de vida del desarrollo de software (SDLC) resulta muy costoso.

En resumen, estas prácticas de prueba tradicionales quedaron obsoletas. Los tipos de vulnerabilidades han evolucionado, y también cambiaron la forma de desarrollar y entregar software. Como las demandas del mercado exigen entregas rápidas, el desarrollo de aplicaciones convencional adopta un enfoque ágil. Este enfoque de DevOps más moderno incluye dividir los grandes lanzamientos monolíticos en sprints más cortos, publicar nuevas funciones varias veces al día, iterar más rápido e incorporar automatización siempre que sea posible. Las organizaciones que usan un enfoque ágil descubren que las herramientas de seguridad de aplicaciones heredadas, diseñadas para la era previa a la nube, se convierten en un obstáculo para realizar implementaciones rápidas y seguras.

¿Qué riesgos representa el código abierto para las empresas fintech?

La proliferación de bibliotecas y paquetes de código abierto plantea un desafío adicional para la ciberseguridad fintech. Las aplicaciones en la nube suelen integrar numerosas bibliotecas y servicios de código abierto. Esto permite que los desarrolladores aprovechen el trabajo que otras personas ya hicieron, pero también les da a los atacantes una oportunidad para vulnerar las redes.

Estas aplicaciones de código abierto pueden contener vulnerabilidades que lleguen a producción. Si se detectan al final del proceso de compilación o en producción, el resultado son demoras en los proyectos.

Las dependencias transitivas (o dependencias de otras dependencias) representan un riesgo particular, porque crean un árbol de dependencias complejo. Esto facilita que pase inadvertido que tu aplicación usa un paquete con vulnerabilidades. A medida que crece el uso del código abierto, las aplicaciones fintech modernas tienen una superficie de ataque más amplia que el código propietario que desarrollan.

¿Cómo se puede aplicar una cultura DevSecOps en las empresas fintech?

La realidad del desarrollo de software moderno implica que la seguridad debe ser un proceso, no una solución puntual. La seguridad debe integrarse durante todo el ciclo de vida del desarrollo, mediante herramientas de pruebas de seguridad, pruebas de penetración y auditorías.

Este nuevo enfoque de seguridad, conocido como DevSecOps, amplía DevOps al introducir la responsabilidad compartida por la seguridad entre los equipos de desarrollo, seguridad y operaciones. Los equipos de seguridad y DevOps trabajan juntos desde el inicio para integrar la seguridad en el pipeline de CI/CD. El modelado de amenazas se realiza de forma temprana y frecuente. Durante todo el proceso, los desarrolladores usan análisis de composición de software (SCA) para monitorear los componentes de código abierto.

Las funciones y aplicaciones de producción son el resultado de un proceso colaborativo. El equipo de seguridad no tendrá que acudir a los equipos de desarrollo después de los hechos, porque sabrán que la seguridad se integró en el proceso de desarrollo desde el principio. Por eso, integrar la seguridad en los procesos de DevOps les da a los desarrolladores la responsabilidad de la seguridad. Como las vulnerabilidades y los errores se detectan a tiempo, DevSecOps permite entregar software más rápido y de forma más segura, con menores costos.

La transición de DevOps a DevSecOps no es responsabilidad exclusiva de los desarrolladores. Los equipos de seguridad deberían supervisar el proceso de planificación y centrarse en aplicar la seguridad con la mínima interrupción de los flujos de trabajo existentes.

Adoptar una mentalidad de seguridad desde el diseño

DevSecOps busca que el software sea seguro desde el diseño. Esto comienza en las primeras etapas del desarrollo con la seguridad del software, un enfoque proactivo centrado en prevenir problemas en el código, como los desbordamientos de búfer y el manejo inadecuado de excepciones.

Es fundamental hacer bien estas primeras etapas del desarrollo, configurando herramientas y procedimientos para encontrar y corregir errores. Las cadenas de dependencias de las bibliotecas y los paquetes de código abierto son otra área clave, ya que pueden volverse confusas y ocultar vulnerabilidades de las aplicaciones.

Los ciclos de retroalimentación rápidos ayudan a reducir la incidencia de errores, y es importante seleccionar bibliotecas de código abierto según los principios de seguridad desde el diseño.

Aplicar los principios de shift left

Un aspecto clave de la seguridad desde el diseño es shift left security, que incorpora medidas de seguridad de las aplicaciones desde el principio. Shift left permite que los desarrolladores integren la seguridad en los flujos de trabajo existentes, mientras los equipos de seguridad los apoyan y supervisan. Empieza por definir políticas de seguridad y luego evaluar el proceso de creación de software para identificar pequeños pasos que permitan realizar pruebas antes. Es fundamental automatizar la seguridad y dar a los equipos visibilidad constante del proceso.

Crear un SDLC seguro

Un SDLC seguro complementa un enfoque DevSecOps para el desarrollo de software. DevSecOps se centra en crear una responsabilidad compartida sobre la seguridad de las aplicaciones, mientras que un SDLC seguro se centra en integrar la seguridad en el proceso de diseño y desarrollo.

Proteger el SDLC estándar empieza por un cambio de mentalidad en los equipos de desarrollo. El enfoque no debería centrarse solo en la funcionalidad, sino también en la seguridad durante todo el proyecto. El objetivo no es eliminar las verificaciones tradicionales, sino abordar los posibles problemas desde el principio, en lugar de intentar volver sobre el proceso cuando el software ya está en producción.

Los equipos de desarrollo lideran los esfuerzos de seguridad, lo que significa que los expertos en la materia que escriben el software corrigen los problemas. Puede parecer mucho trabajo, pero la mayor parte se automatiza en un entorno de SDLC seguro. El resultado son aplicaciones más seguras en producción y a menor costo.

Cómo Snyk apoya la ciberseguridad fintech

Snyk Open Source es una herramienta de SCA que detecta vulnerabilidades en las dependencias mientras programas en un IDE o en la CLI. Esta herramienta, diseñada para desarrolladores, analiza los pull request antes de que se fusionen y puede impedir que las vulnerabilidades pasen el proceso de compilación. Snyk permite realizar pruebas automatizadas durante todo el CI/CD y analiza continuamente tus aplicaciones para detectar si están expuestas a vulnerabilidades conocidas o recién descubiertas. Otras funciones incluyen monitoreo continuo, reglas de seguridad personalizadas y gestión automatizada del cumplimiento de licencias.

Como empresa fintech que maneja información confidencial y privada, Revolut debe cumplir con estándares específicos. La implementación de Snyk garantiza que la empresa pueda proteger la infraestructura central y mantener el cumplimiento de PCI, entre otros requisitos.

“Nos auditan durante todo el año. Al usar Snyk, podemos afirmar que protegimos nuestro pipeline de código abierto”, comentó Evangelos Deirmentzoglou. “Así que no se trata solo de mejorar nuestra seguridad, sino también de apoyar nuestros esfuerzos de cumplimiento normativo.”

Lee más sobre cómo Revolut usó Snyk para mejorar su ciberseguridad y cumplir con los estándares regulatorios.

Para obtener más información sobre el uso de componentes de código abierto en fintech, mira nuestro webinar a pedido: Buenas prácticas y errores comunes al usar componentes de código abierto en fintech

Preguntas frecuentes sobre ciberseguridad fintech