23 and me o sobre cómo no gestionar un incidente de seguridad

31 de enero de 2024

Ninguna empresa quiere aparecer en los medios de comunicación por sufrir un incidente de seguridad, aunque, tal y como se repite de forma incansable en nuestra industria, la seguridad al 100% no existe.

Por lo tanto, no se trata de si se va a sufrir un incidente de seguridad (cuya respuesta es, de forma ineludible, afirmativa) sino cómo se prepara la organización para su detección, gestión y respuesta. Básicamente preparar los procedimientos, realizar simulaciones y entrar en un ciclo de mejora continua.

A raíz de lo publicado en medios recientemente parece que la compañía de análisis genéticos 23andme no se preparó de forma demasiado concienzuda para ello, al menos desde el punto de vista de la comunicación, y por ende sfrió un importante descrédito por su gestión, con errores evidentes que han ido enfadando tanto a sus usuarios, con más de 30 denuncias masivas presentadas, como a la comunidad de ciberseguridad.

Cronología del ataque

  • 6 de octubre de 2023: Un actor amenaza con el seudónimo de Golem pone a la venta información personal de 1 millón de personas extraída de la plataforma 23andme.
  • 10 de octubre de 2023: 23andme ha solicitado a la totalidad de sus usuarios que reseteen sus contraseñas como medida de precaución.
  • 17 de octubre de 2023: el mismo actor amenaza publica un nuevo dataset en el foro de la darkweb BreachForums con datos personales de otros 4 millones de personas.
  • 20 de octubre de 2023: 23andme deshabilita la opción de compartir DNA para encontrar potenciales familiares.
  • 6 de noviembre de 2023: 23andme añade 2FA por defecto para sus clientes en un intento de proteger a los usuarios de ataques de credenciales reutilizadas (credential stuffing).
  • 30 de noviembre de 2023: 23andme realiza un cambio en sus términos y condiciones donde define la mediación como mecanismo por defecto de resolución de conflictos.

A continuación, repasamos algunos de los errores cometidos en la gestión de este incidente para tratar de aprender de ellos y que otras organizaciones no los repitan.

Error: minimizar el incidente

Este es un error común de las organizaciones en la gestión de incidentes de seguridad, en primer lugar, se tiende a minimizar el impacto del incidente para restarle importancia y tratar de acallar el ruido generado.

En el caso de 23andme se mencionaba en un primer post en su blog que el incidente solamente afectó a 14.000 clientes, menos del 0,1% de su base de usuarios que es de 14 millones.

Si bien esta afirmación puede ser técnicamente correcta, el atacante solo obtuvo acceso directo a las cuentas esos miles clientes a través de un ataque de reutilización de passwords entre servicios (credential stuffing). De cara al público en general, lo importante es el impacto.

La realidad es que el atacante tuvo acceso a información personal de 6,9 millones de usuarios a través de funcionalidades opcionales que permiten compartir información con otros usuarios para encontrar parientes (DNA relatives feature) y árbol genealógico (Family Tree feature), lo que equivale aproximadamente a la mitad de sus usuarios.

Error: culpar a los usuarios

Tras recibir un buen número de denuncias masivas de usuarios, la sorprendente respuesta de la compañía fue, de alguna manera, revolverse como gato panza arriba y lanzó una carta a algunos de los denunciantes culpando del incidente a los usuarios y su gestión de las contraseñas, según información publicada en TechCrunch este mismo enero.

Este señalamiento con el dedo no tiene sentido. 23andMe sabía o debería haber sabido que muchos clientes usan contraseñas recicladas y, por lo tanto, 23andMe debería haber implementado algunas de las muchas salvaguardas disponibles para proteger contra el credential stuffing, especialmente considerando que 23andMe almacena información personal identificativa, información de salud e información genética en su plataforma.

Error: cambiar los términos y condiciones

De nuevo tras la recepción de más de 30 denuncias respecto al incidente de seguridad sufrido 23andme ha decidido cambiar los términos y condiciones del contrato con sus usuarios según informa stackdiary. Este cambio obligará a sus usuarios a entrar en un arbitraje vinculante, que es un medio para resolver disputas (como una violación de la seguridad) fuera de los tribunales.

En este proceso, ambas partes en desacuerdo presentan sus casos a un árbitro, quien es una tercera parte neutral. El árbitro escucha a ambas partes, revisa las pruebas y decide. El aspecto clave del arbitraje vinculante es que la decisión del árbitro es final, lo que significa que ambas partes deben aceptarla y no pueden apelar a un tribunal ordinario.

Imagen de la comunicación de los nuevos términos y condiciones de 23andme.

En caso de una violación de la seguridad, esto significa que si tienes una disputa con 23andMe, primero debes intentar resolverla con su atención al cliente. Si eso no funciona, irías a arbitraje, no a un juicio.

Esto es lo que 23andme quiere conseguir a la vista de lo sucedido en este incidente y preparando el terreno de su protección a futuro, un movimiento cuando menos partidista.

Para añadir más leña al fuego, este cambio de condiciones es de aplicación automática y cae en las manos de los usuarios negarse al proceso de arbitraje mediante una comunicación directa a un correo electrónico proporcionado por 23andme (arbitrationoptout@23andme.com) en menos de 30 días desde la recepción de la comunicación del cambio de condiciones.

Lógicamente, esto supondrá que un buen porcentaje de usuarios ignorará el mensaje, otro buen porcentaje lo verán, pero no actuarán en consecuencia, y finalmente otro porcentaje, esta vez menor, lo hará fuera de plazo por lo que no será efectivo. Todos esos usuarios acabarán siendo incorporados al proceso de arbitraje.

Aciertos

No todo en la gestión del incidente fue negativo, algunas medidas fueron adecuadas y correctas. Por tanto, es justo también enumerarlas para dar una perspectiva completa del incidente y su gestión.

  1. La investigación interna fue rápida y efectiva, también es cierto que sencilla técnicamente hablando, tratándose de un ataque de credential stuffing. En ocasiones esto se dilata en el tiempo dejando tiempo a los atacantes a maximizar el impacto y a los rumores a dispararse.
  2. Se tomaron medidas preventivas rápidas, como la solicitud de reseteo de la contraseña para todos los usuarios. Aunque se trate de una medida basada en la precaución, con una correcta comunicación, creemos que estos quickwins son importantes y correctos para minimizar el impacto y evidenciar la proactividad de la organización para resolver el problema.
  3. Se desarrolló e incorporó una medida de seguridad a largo plazo, como el 2FA por defecto, para minimizar la reincidencia de este problema a futuro en la plataforma.

Esta es la comunicación oficial de 23andme en su blog sobre el incidente que han ido actualizando de forma continua conforme se tomaban medidas o se hallaba nueva información.

Conclusiones

La gestión de los incidentes de seguridad debe buscar un equilibrio que es cuando menos complejo: Rapidez de actuación versus análisis en profundidad del incidente, medidas preventivas versus medidas a largo plazo, transparencia de información versus sobre exposición, etc.

En el caso particular que hemos analizado del ataque de 23andme, se han cometido una serie de errores, a nuestro entender, fácilmente evitables, que ha generado una polémica mayor de la que el incidente, al menos desde el punto de vista de responsabilidad técnica de seguridad, quizá merecía.

Esto denota que no solamente es importante el impacto directo y la “culpa” inherente de una determinada organización ante un ataque sufrido, sino cómo se gestiona la comunicación asociada y esto moldeará en buena medida la opinión pública y el impacto final en la reputación.

En general, la recomendación para las organizaciones sería que deben establecer procesos claros para la detección y respuesta de incidentes de seguridad. No solamente desde el punto de vista técnico, sino también de la comunicación y legal.

Y lanzar simulaciones que involucren a todas las partes implicadas de la organización para que cuando llegue el día en el que la brecha sea real, que llegará, exista una manera de afrontarla conocida y todas las partes sepan cuál es su rol para poder actuar con diligencia.

Ataque a los sistemas de soporte de Otka: ficheros HAR y tokens de sesión