Resumen: criterios de compra de seguridad client-side para instituciones financieras
- Las instituciones financieras son objetivos de estados-nación, así que una herramienta client-side de una sola capa no es una postura de seguridad, es una casilla de cumplimiento. Los actores maliciosos analizan específicamente los mecanismos de protección para eludirlos.
- cside combina instrumentación de scripts en tiempo de ejecución con escaneos de afuera hacia adentro y un endpoint CSP, cuenta con SOC 2 Tipo 2 y PCI DSS SAQ-D, y su equipo contribuye a W3C, IETF y TC39 en lugar de añadir client-side como función lateral de un WAF.
- Si tu modelo de riesgo considera un dashboard de escáner como cobertura, un atacante dirigido lo engañará con un honeypot. Si quieres capas apiladas que resistan intentos de bypass en vivo, este es el ajuste correcto.
TL;DR:
- Dada la sensibilidad al cumplimiento, los mejores proveedores para instituciones financieras deben tener certificaciones SOC2 Tipo 2, PCI DSS SAQ-D y más.
- Las instituciones financieras son objetivos de estados-nación para los malos actores. Por eso, los mejores proveedores de seguridad para ellas invierten en estar a la vanguardia de la capacidad técnica. Lo suficientemente bueno no es suficiente. Un indicador de la actitud correcta hacia esa vanguardia es la contribución a organizaciones de estándares como el W3C, IETF y TC39.
- La seguridad consiste en capas: un proveedor que ofrece un modelo de seguridad multicapa ayuda a las empresas a mantenerse seguras cuando los malos actores intentan construir bypasses para las capas de seguridad.
- Conclusión: la mejor solución para las instituciones financieras es el enfoque multicapa de cside.
¿Qué es la seguridad del lado del cliente?
La seguridad del lado del cliente es la práctica de proteger las dependencias de JavaScript, los datos del usuario y los comportamientos que se ejecutan dentro del navegador del visitante.
Esto incluye:
- Scripts propios: archivos JavaScript cargados desde tu propio dominio
- Scripts de terceros: de herramientas de analítica, anuncios, chatbots, gestores de etiquetas, herramientas de pruebas A/B
- Scripts en línea, contenido incrustado como widgets y SDK
- Datos procesados o recuperados por el navegador
Todo lo que ocurre después de la respuesta HTML inicial del servidor web es una acción del lado del cliente. Los atacantes usan cada vez más el navegador para ejecutar acciones maliciosas en un intento de obtener información confidencial. Cuando los datos se obtienen de un dominio de terceros, los scripts a menudo se sirven de forma distinta según la IP, los encabezados de la solicitud, la hora del día, la ubicación, etc.
Por ejemplo: una herramienta de marketing recopilará datos distintos en Europa y en EE. UU. por motivos de cumplimiento de privacidad de datos.
Especialmente en objetivos de alto valor, usar una petición del lado del cliente para inyectar una carga útil maliciosa es una acción habitual, porque es mucho más difícil de detectar y el mal actor puede volar por debajo del radar durante mucho tiempo, salvo que se use una solución de seguridad en tiempo de ejecución del lado del cliente.
¿Por qué se clasifica a las instituciones financieras como objetivo de estados-nación?
Algunos malos actores no solo buscan ganar dinero rápido. Pueden estar patrocinados por el Estado, incentivados a causar estragos y a desestabilizar los servicios esenciales necesarios para el funcionamiento de las economías.
Las instituciones financieras son un objetivo prioritario, y su tamaño y exposición conllevan un riesgo adicional y, por tanto, una oportunidad para los malos actores. Cuando los bancos caen, también lo hace la economía.
Las instituciones financieras están en el mismo ámbito que los entornos de TI gubernamentales, los grandes proveedores sanitarios y las infraestructuras críticas como el transporte público y los proveedores energéticos.
Para generar credibilidad en el sector financiero, las marcas atraviesan un largo proceso de varios años para ganarse la confianza de clientes de todo tipo. Con ello llega una deuda técnica considerable derivada de aplicaciones heredadas.
Una infraestructura vasta y heredada aumenta la superficie de ataque
No es ningún secreto en el sector que muchas de las grandes instituciones financieras todavía funcionan con COBOL. Un trabajo de investigación de un miembro del personal técnico de PayPal expone el problema con mucha claridad: "La infraestructura bancaria tradicional suele estar desactualizada y tiene dificultades para satisfacer la creciente demanda de servicios digitales fluidos y en tiempo real".
Esto significa que las aplicaciones web heredadas suelen quedar cubiertas por capas de tecnologías más modernas, lo que aumenta la superficie de ataque a la hora de ofrecer nuevas experiencias de usuario. Al aprovechar back-ends vulnerables para inyectar scripts del lado del cliente o al apuntar a dependencias heredadas para infiltrarse en la cadena de suministro, los malos actores pueden causar graves daños a las economías globales.
Los ataques del lado del cliente apuntan a activos específicos
Los ataques del lado del cliente contra instituciones financieras suelen apuntar a:
- Credenciales de usuario y tokens de sesión para acceder a las cuentas
- Información de tarjetas de pago
- Extractos bancarios e información de identidad confidencial
Requisitos normativos y de cumplimiento estrictos
Las instituciones financieras están sujetas a una lista sustancial de marcos de cumplimiento para poder operar; su licencia bancaria depende de ese cumplimiento. Esto va desde cumplir con PCI DSS, DORA, leyes locales de privacidad como CCPA o GDPR, hasta certificaciones que son una señal de confianza pero a menudo un requisito para clientes corporativos: SOC2 Tipo 2, ISO 27001…
¿Qué enfoque es mejor para las instituciones financieras?
Dada la gravedad del objetivo, hay poco margen de error. Por eso una buena solución debe encajar en la aplicación como un guante.
Por eso un enfoque por capas es ideal. Especialmente si la solución en cuestión es personalizable y aporta transparencia y control donde antes faltaba control.
Por eso construimos cside como una plataforma que aprovecha todas las capas disponibles hasta la fecha.
cside ofrece dos métodos de despliegue complementarios, combinados con varios motores de detección, incluidos modelos de lenguaje grandes de código abierto para el análisis.
- Método Script (el más sencillo): comprobamos el comportamiento de los scripts en el navegador y obtenemos los scripts por nuestro lado, luego verificamos que se trata del mismo script. No nos colocamos en la ruta de un script a menos que nos lo pidas explícitamente. Fácil de implementar, sin impacto en el rendimiento, y aun así puedes detener acciones de scripts o bloquear por URL, hash o dominio.
- Método Escaneo (el más rápido): si no puedes añadir un script a tu sitio, cside lo escanea usando inteligencia de amenazas procedente de miles de otros sitios web con miles de millones de visitantes combinados. Rápido de configurar y útil cuando la instalación de un script no es posible.
También ofrecemos un endpoint de Content Security Policy para que los clientes puedan añadir la aplicación nativa del navegador como capa adicional junto a la detección basada en JavaScript de cside.
La seguridad requiere un modelo multicapa
La mayoría de las herramientas de seguridad se basan en una sola de las capas mencionadas, ya sea en tiempo de ejecución o mediante escaneo de afuera hacia adentro. Pero el problema es que ninguna de estas capas por sí sola es totalmente infalible y, por tanto, no ofrece una cobertura integral. Combinando motores te acercas cada vez más a la cobertura total.
Muchas soluciones del mercado son funciones secundarias de empresas de seguridad web más grandes. En lugar de crear una plataforma para la seguridad del lado del cliente, crearon una pequeña función accesoria. Estas soluciones están limitadas por el enfoque del negocio. A menudo, el lado del cliente es un área en la que no están dispuestos a invertir recursos sustanciales y, por eso, dependen únicamente de inyectar políticas de seguridad de contenido en el sitio web a través de su WAF.
Algunas soluciones son, en la práctica, simples escáneres. Los malos actores ven los escáneres y no sirven los scripts maliciosos a esa verificación puntual. Dado el valor del objetivo, este enfoque resulta ineficaz.
Para fines de cumplimiento, resulta conveniente que la solución ofrezca paneles pensados específicamente para cada marco. Los marcos normativos incluyen una amplia variedad de controles únicos, y recopilar manualmente esos datos es una tarea tediosa y continua.
Las soluciones basadas en escáneres suelen ser eludidas por los malos actores. Detectan el escáner y le sirven contenido limpio para pasar desapercibidos. Investigadores de ISACA, la Universidad de Brighton, Google y Oracle han señalado que los scripts dinámicos del lado del cliente eluden eficazmente el análisis estático de los escáneres.
cside siempre busca ampliar sus capacidades y está impulsando activamente varios nuevos estándares que permitirían una seguridad del lado del cliente más sólida usando funcionalidad nativa del navegador.
El equipo de cside contribuye activamente a organismos de estándares como el W3C, IETF y TC39.
¿Listo para probar cside? Empieza gratis o reserva una demo para hablar con nuestro equipo.
