Brecha de seguridad en Uber: Otra vez un tercero (Teqtivity)
Ayer salía a la luz una nueva brecha de seguridad en Uber en la que estaba envuelto un tercero, en esta ocasión, un servicio de gestión de activos, denominado, teqtivity.
En esta ocasión, a diferencia de lo ocurrido en 2016 cuando lo que se filtraron fueron datos de 57 millones de clientes, ahora solo han sido los datos de 77 000 empleados.
Hay más diferencias: En 2016, la brecha se produjo por una mala práctica de Uber, al utilizar datos reales en entornos de prueba sin protección (sin cifrar) y por no proteger adecuadamente los accesos a un servicio externo (Github). En esta ocasión, es muy diferente. Al parecer, según lo que ha trascendido hasta el momento, los atacantes habrían podido acceder a una copia de respaldo de este servicio almacenado en AWS (comunicado público de teqtivity). Es decir, Uber no tendría nada que ver, ni podría haber hecho nada para evitarlo (de hecho, todos los clientes de teqtivity están afectados, así que el titular más correcto habría sido: Una brecha de seguridad en teqtivity afecta, entre otros, a Uber).
Bueno, en realidad algo sí podría haber hecho. Si echamos un vistazo a la página de teqtivity sobre seguridad lo único que encontramos es una declaración que viene a decir que están muy preocupados por la seguridad y que siguen recomendaciones basadas en ISO 27001 y NIST. Punto final. Ningún informe de tercero, ninguna certificación, ninguna calificación, nada.
¿Podría Uber haber hecho algo más?
Sin duda, sí. Básicamente, aplicar la máxima de »confía, pero verifica». Es decir, pedirles algo más que una simple declaración de intenciones.
Este servicio habría tenido que acreditar algunas medidas básicas de seguridad porque tiene la criticidad suficiente (información de todos sus activos TI y empleados) como para no poder ser usado sin demostrar algo más en seguridad.
¿Podría teqtivity haber hecho algo más?
Obviamente. Un proveedor que ofrece a sus clientes un servicio de estas características no puede «sólo» decir que es muy seguro y que se preocupa por la seguridad. Debe demostrar qué nivel de seguridad está implementando y acreditarlo de manera continuada.
Lecciones aprendidas
1. Desde la perspectiva de usuario, incidentes de este tipo refuerzan la necesidad de contar con procesos maduros de gestión de riesgos de terceros que:
-
Clasifique los servicios por criticidad
-
Establezca requisitos de seguridad y de validación en línea con dicha criticidad
-
Se aplique en todo el ciclo de vida (desde la RFP hasta la desinstalación)
2. Y desde la perspectiva de proveedor, ofrecemos algunas pistas (partiendo de la base de nuestro referencial de calificación (disponible completo para descarga aquí):
-
Cifrar el contenido de las copias de respaldo ([RE.01] Cifrado de respaldos)
-
Proteger los accesos mediante sistemas de autenticación robustos ([AC.01] Niveles de garantía)
-
Secularizar los entornos cloud - al igual que los servicios propios ([SO.05] Requerimientos de seguridad para los SSII)
-
Llevar a cabo auditorías internas y externas para demostrar a sus clientes las medidas de seguridad implementadas ([CO.01] Cumplimiento normativo y [CO.02] idem con normas internas)