Security breach

Security breach

El CSO (Chief Security Officer) de Adobe, Brad Arkin, expuso durante el reciente evento “Privacy. Security. Risk. 2015” efectuado en Las Vegas EEUU, acerca de sus experiencias haciendo frente a la masiva brecha de seguridad ocurrida el 2013 en la empresa Adobe.

Para quienes no lo recuerden, ese problema de seguridad tuvo amplia cobertura en la prensa ya que a casi 3 millones de clientes les fueron robados datos personales, ademas de código fuente y otros. Esto terminó impactando a 38 millones de usuarios.

Es interesante este relato para dimensionar el inmenso impacto y desgaste interno que produce un evento de esta naturaleza en una empresa.

Brad Arkin estaba tan estresado en las semanas que siguieron a esta fuga de datos que quebró dos de sus muelas de tanto apretar los dientes durante las reuniones de Respuesta de Incidentes. “No fue una situación divertida” dijo…

Arkin, vice presidente y chief security officer en Adobe Systems Inc., relató lo que le tocó vivir después de ocurrido este evento.

El llevaba en el puesto de CSO solamente unos pocos meses antes de ocurrir la brecha de seguridad. Previamente su puesto era Director Senior de seguridad y privacidad en Adobe, y fue promovido al cargo de CSO en Abril del 2013.

Siete meses después de esta promoción, el 3 de Octubre, Adobe anuncia que descubrió una intrusión no autorizada en uno de sus servidores de base de datos, junto con otros equipos de la red empresarial de la compañía. El resultado neto de esta intrusión, es que ciertos datos fueron copiados y extraídos del servidor, incluyendo números de tarjetas de crédito, passwords de clientes, nombres y emails (no encriptados), además de código fuente de productos Adobe.

En palabras de Arkin “Hubo mucha cobertura de la prensa acerca de este tema y duró un larguísimo tiempo. La realidad es que un incidente de seguridad como éste no es como un accidente en automóvil que ocurre y ya… este tipo de incidente se desarrolla en una forma muy lenta y por mucho tiempo después de ocurrido”.

La investigación forense duró muchas semanas, dijo Arkin, pero eso fue solo una parte de los esfuerzos post-evento. Hubo lo que pareció una serie interminable de reuniones para discutir cómo enfrentar a la prensa, cómo avisarle a los clientes, cómo resolver potenciales problemas legales y finalmente, cómo reforzar la infraestructura, sistemas y procesos de seguridad para evitar que ocurriera esto de nuevo. Algunas de estas reuniones ocurrían cada cuatro horas para actualizaciones forenses y otras diariamente para mantener informado al equipo de trabajo acerca de los últimos acontecimientos.

“Hay muchas piezas en movimiento con diferentes equipos dentro de la compañía, con preocupaciones distintas, a veces compitiendo por prioridad”, dijo Arkin, refiriéndose a ingeniería, prensa, comunicaciones e investigaciones.

Impacto en el robo de Código Fuente

Una de las grandes preocupaciones fue investigar exactamente qué código fuente fue comprometido, y qué impacto podía tener para el futuro de la empresa. Para ello el equipo de Ingeniería tuvo que trabajar intensamente revisando cada detalle, con equipos forenses internos y externos. Esto incluyó interacción con aplicaciones de terceros que se integran con Adobe.

En la medida que se iba sabiendo más, estos ingenieros tuvieron que hacer cambios en varios productos y en procesos de seguridad para asegurar que no hubiera impacto en los clientes.

Arlin dijo que después de este exhaustivo trabajo y reparaciones, quedaron tranquilos de que no existe (a su entender) ningún riesgo para sus clientes como consecuencia del robo de código fuente.

El problema es que esto no detuvo a la opinión pública de seguir especulando. Hubo varios expertos contratados por la prensa que expresaron sus opiniones acerca de los potenciales impactos.

Cuándo y cómo avisar a los clientes?

Desde un punto de visto de negocios, decidimos que lo mejor era notificar al público, sobre todo para que supieran exactamente en qué consistía la brecha, y tranquilizarlos un poco sabiendo que sus números de tarjeta de crédito y passwords fueron robados encriptados.

“Hoy, después de dos años de ocurrido, demostramos que estábamos en lo cierto acerca del no impacto del robo de código fuente. No hemos visto ningún “zero day attack” o ataques de ningún tipo relacionados con las secciones de código robados.” dijo Arkin. Se identificó también que los ataques fueron ocasionados desde el exterior y no por personal interno.

Fue difícil determinar un balance entre avisar oportunamente del hecho aún a riesgo de no tener todos los aspectos investigados a fondo y confundir a los clientes, versus esperar seis meses hasta tener todo clarificado… Por ejemplo, las primeras estimaciones de cuántos clientes fueron imputados eran de alrededor de 3 millones. Varias semanas después subió a 38 millones de cuentas.

Esto también produjo una serie de desacuerdos dentro de la empresa ya que distintos grupos (legal, relaciones públicas, manejo de incidentes, ventas, etc) tenían opiniones muy distintas acerca de cuándo, cómo y qué decir. Lo que puede ser más seguro desde un punto de vista legal puede ser nocivo desde el punto de vista de relaciones de confianza de clientes a largo plazo.

Otra aspecto no menor fue la logística de cómo avisar a millones de involucrados, disponibilizar información en la web, contestar preguntas de la prensa, etc. Algunas veces la prensa publicó comentarios o datos incorrectos, y el clarificar estas publicaciones tomó mucho tiempo, confundiendo a veces más al público.

Demasiados “Chefs en la cocina”?

Otra cosa que aprendió Arkin es el riesgo de manejar simultáneamente tantos equipos de trabajo sin una clara definición de quienes son los que toman las decisiones en caso de conflicto.

Arkin recomienda hacer simulacros de incidentes de seguridad, especialmente para identificar modelos de tomas de decisiones y dejar las cosas en claro para que cuando ocurra un evento real no existan ambigüedades acerca de qué hacer y de quién es responsable.

La vida real no es como las películas donde se obtienen respuestas rápidamente y sin confusiones. En la realidad lo que ocurre es que los investigadores dan una conclusión que parece definitiva, y 4 horas después dicen “No, estábamos en un error, lo que realmente ocurre es esto…”. Para ciertas personas que están acostumbradas a tener claridad esto puede ser muy frustrante.

Las recomendaciones de Adobe para manejar un incidente de este tipo son:

  1. Configurar un equipo centralizado que es el único que maneja las comunicaciones y prensa
  2. Tener un vocero dedicado que tenga experiencia y esté apropiadamente entrenado para esto
  3. Disponer con antelación de un plan de relaciones públicas para lidiar con brechas masivas, para no estar improvisando sobre la marcha

Manejo del stress y de los empleados

Otra aspecto que pudiera ser pasado de alto es el manejo de stress del personal. En el caso ilustrado por Arkin, empleados de Adobe trabajaron durante 3 meses, 7 días a la semana, 18 horas diarias, todo bajo una tremendo nivel de presión sobre Arkin y su equipo.

“Esperan que exista stress y manéjenlo en lugar de tratar de ignorarlo o encapsularlo” es el consejo de Arkin.

Es importante tomar las acciones necesarias para aliviar este stress antes de que la gente empiece a agotar su energía y empiece a cometer costosos errores. Adobe cometió ese error y sólo empezó a implementar medidas ya bien avanzadas las acciones de recuperación. Otra lección aprendida.

Algunas de las medidas tomadas consistieron en:

  • Rotar a miembros del staff frecuentemente
  • Obligar a tomarse unos días fuera de la oficina a algunas personas con evidente sobre-trabajo, sin laptops ni teléfonos
  • Si alguien es imprescindible, la empresa puede proveer otras formas de apoyo a esta persona. Por ejemplo, si un ingeniero de Seattle ha estado viviendo por dos semanas en un hotel en San Francisco, podrían pagarle un pasaje de avión cada fin de semana para que vaya a ver su familia, o llevar a la familia a que lo acompañe
  • Es importante reducir las responsabilidades de quienes están directamente involucrados en resolver la crisis, redirigiendo parte de sus actividades rutinarias a otros empleados
  • Finalmente, hay que intentar que la gente mantenga lo mejor posible rutinas saludables de comida, sueño y ejercicio.

Es muy importante la labor de recursos humanos en los manejos de estas crisis, para apoyar psicológicamente a los empleados.

Limpieza y Partir de Nuevo

Lecciones aprendidas:

En el corto plazo, hay que identificar los sistemas que están comprometidos, redes, equipos, cuentas de acceso y “quemar hasta los cimientos” todo aquello. Si el borrado de sistemas, datos y otros no se hace en forma apropiada, puede ser que los ataques siguen adelante… Esto implica reconfigurar servidores desde cero, borrar intensivamente datos, eliminar (no solo deshabilitar) las cuentas involucradas.

Algo importante es que no se debe volver a recrear todo el ambiente con los mismos procesos, controles, políticas y prácticas de seguridad, para evitar que ocurran brechas similares en el futuro. Por ejemplo, en este caso, la base de datos que los hackers robaron tenía información encriptada de tarjetas de crédito y claves de usuario. Aunque no hay evidencia de que los hackers pudieran desencriptar esta información, el equipo decidió cambiar esta práctica. Ahora mantienen una base de datos de “tokens” en lugar de números de tarjetas, esto quiere decir que almacenan autorizaciones de los proveedores de pagos. Si alguno de esos tokens es robado y usado, el hacker no obtiene nada, ya que en el peor de los casos la transacción envía dinero a Adobe. Por esto, no les interesan esas bases de datos.

Otro aspecto que se reforzó fue el cohesionar varios equipos de seguridad existentes en uno centralizado con mayores atributos, presupuesto y facilidad de implementar políticas que refuercen la visión de seguridad corporativa.

Conclusión

Nos pareció importante detallar las lecciones aprendidas en este incidente para potenciar el hecho de que una brecha masiva de seguridad puede ser una realidad para las empresas, y más vale estar preparados. Hay que considerar no sólo aspectos técnicos de TI, sino que aristas legales, relaciones públicas, recursos humanos y gerenciamiento. Es importante planificar con anticipación, tener simulacros, establecer apropiadamente las responsabilidades de los distintos participantes, involucrar a externos, etc.

Los costos de sumar todos los aspectos incluidos en este artículo son más cuantiosos de lo que pareciera a primera vista, y no fáciles de cuantificar. En diversos estudios se habla de millones de dólares en el caso de empresas medianas a grandes.