Dos síntomas de cómo NO tomamos en serio la seguridad

Hace un par de semanas supimos de graves fallas de seguridad en el Banco de Chile. La peor de ellas permitía a cualquier persona que tuviera una clave de cliente del Chile hacer compras via WebPay cargando el monto a la cuenta de cualquier otro cliente del mismo banco. 😱

Entiendo que los problemas reportados han sido corregidos. Pero si sólo vemos esto como otra “incidencia” que ya fue parchada, perdemos la oportunidad de ver el problema sistémico que tenemos como industria.

Lo más grave de la historia contada por Eduardo no era la compra a nombre de otra persona. Lo más grave es que el equipo que descubrió estos problemas intentó comunicarlos al banco durante meses, y aún así los problemas de fondo persistían.

Porque no nos tomamos en serio la seguridad.

Y para mostrar que no es una afirmación a la ligera, voy a describir dos síntomas que muestran que por mucho comunicado formal, reuniones con gente de apariencia muy seria o las buenas intenciones — nadie realmente quiere cagarla con la seguridad—en la práctica nuestra industria no se toma en serio la seguridad.

Síntoma 1: La Inexistencia de Canales para Reportar Errores

Para no seguir pegándole al Banco de Chile, piensa en cualquier otro banco. Ahora imagina que encontraste un problema grave de seguridad (o supiste de la existencia de él). ¿Cómo les avisarías?

Hice el ejercicio con Banco Santander, BancoEstado, Banco Bci (los otros 3 bancos con gran participación de mercado). Vía los links del pie de página o de google, sólo pude llegar a páginas de “consejos de seguridad”, pero nada más.

La sugerencia genérica que tienen algunas de esas páginas es que uno llame al call center o escriba via redes sociales. Pero no sirve. Los canales de atención al cliente de ese tipo de empresas no están capacitados para entender y responder a estas cosas. Como muestra, mira este hilo en twitter de hace más de 2 años:

Y de nuevo, no se trata de apuntar específicamente a un banco. Yo le escribí a Bci porque es el banco donde tengo mi plata. Pero en esa época casi todos los bancos de la industria local (con una o dos excepciones) tenían el formulario de login en una página no segura.

Quizás crees que se soluciona a través de contactos. “Yo conozco alguien que trabaja en el banco, voy a avisar por ahí del problema de seguridad”. Les cuento que no funciona (intenté esa vía para el bug descrito recién, sin éxito) y que es una mala idea. Porque reportar un problema de seguridad es algo delicado.

Si encuentras un problema de seguridad a una empresa en Chile y quieres reportarla responsablemente, puedes terminar metiéndote en líos. Si encuentras un problema en los servicios de las empresas serias de esos otros productos que tienen un ícono en tu teléfono junto al de tu banco (Google, Facebook, Uber, Netflix, Spotify, etc, etc), googleando encuentras rápido la manera de hacer responsible disclosure. Y además, bajo ciertas condiciones puedes obtener un bug bounty: ¡Te premian con dinero por reportar el problema!

En Chile, sé de al menos un caso donde quien descubrió un problema tuvo que ser muy pero muy cuidadoso para evitar que lo demandaran por reportarlo. O sea, te pueden castigar por advertir a la empresa que se mandó una cagada.

En ese contexto, para quien encuentra un problema de seguridad y no encuentra una manera oficial de reportarlo, lo mas razonable es dejar las cosas como están y no meterse en líos.

Este síntoma es relativamente fácil de resolver. Si quieres tomar la seguridad en serio, existen recomendaciones modernas sobre como entregar canales para reportes de seguridad. No hay que (re)inventar la rueda, sólo implementarla.

Síntoma 2: El Teatro de Seguridad

Quienes trabajamos con bancos u otras instituciones financieras sabemos que el área de seguridad y riesgo tiene gran poder interno. Cuando seguridad o riesgo tienen objeciones a cierto producto, arquitectura o protocolo de comunicación, todo se detiene. Lo que tiene sentido.

Pero gran poder conlleva gran responsabilidad. Me ha pasado más de una vez que me preguntan: “¿Y qué harás si alguien intercepta la comunicación HTTPS y obtiene ese valor secreto?” Donde mi respuesta es: “¡Ni idea! Me encantaría ver ese modelo de ataque y entender como lo solucionas en tus otros canales (ej: la web de tus clientes) para aplicar la misma solución”.

Y me he encontrado con que no hay un modelo de ataque. No hay supuestos de qué capacidades o qué información tiene un atacante, ni un análisis completo de todos los flujos de información. Ni menos de qué formas se mitigan los riesgos en otras soluciones con mismas amenazas. Sin esa información, no se puede co-diseñar un sistema seguro.

Lo que me ha tocado ver es que las áreas de seguridad usan su gran poder para someter tus soluciones a preguntas y observaciones arbitrarias (que no significa que sean malas) pero sin la gran responsabilidad de tener modelos serios detrás. La formalización de los procesos de seguridad se reduce a checklists, no a verdadero conocimiento que se pueda usar para co-diseñar sistemas seguros.

“Security theater refers to security measures that make people feel more secure without doing anything to actually improve their security” — Bruce Schneier

¿Por qué pasa eso? Porque ante la necesidad de que se note tomamos la seguridad en serio, pues hacemos eso: Un proceso que tenga la apariencia de seriedad. Que el área de seguridad tenga veto sobre decisiones tecnológicas parece serio. Pero no basta para ser serios.

Este otro síntoma es más difícil de resolver. Tiene que ver con pensar a seguridad no como el “adversario” que te cuestiona y te manda de vuelta al pizarrón (y te retrasa el proyecto/producto). Se trata de que seguridad sea tu aliado para detectar tempranamente problemas y que en conjunto puedan resolverlos. Y eso requiere que las áreas de seguridad tomen esa responsabilidad.

Porque la seguridad no existe en un mundo paralelo. Ni es un imperativo exclusivo. El sistema más seguro es un sistema desconectado del mundo. Apagado, ojalá. Jamás será vulnerado, pero jamás será útil.