Ciberseguridad y UX, ¿Agua y Aceite?

Esta es la primera parte de la entrevista que La Cocina de Estrategias (Susana y Laura) tuvo con Manuel Nader, un experto en Ciberseguridad, en el marco de la celebración del Día Internacional de la Protección de Datos.

Con más de 10 años de experiencia en ciberseguridad y titulaciones de Grado de Ingeniería Informática y Máster de Ciberseguridad y Privacidad, Manuel se especializa en asegurar el ciclo de vida del desarrollo de software y el manejo de vulnerabilidades. Su habilidad para colaborar con diversos stakeholders, comunicar problemas de seguridad y su compromiso con el aprendizaje continuo le han ayudado en su carrera.

A continuación, la entrevista:

Susana: Hola Manuel. Bienvenido a La Cocina. Gracias por estar aquí hoy.

Manuel: Muchas gracias a ustedes por la invitación. 

Laura: La idea del día de hoy es conversar sobre esta relación tan compleja que tienen la ciberseguridad y el UX. Para comenzar, sabemos que tu trabajo implica encontrar vulnerabilidades, ¿qué es una vulnerabilidad? ¿Y eso cómo se relaciona con la protección de datos?

Manuel: En software una vulnerabilidad es una debilidad, que permite a un atacante realizar algo que no debería. En otras palabras, es una falla que tiene el código, que un atacante podría aprovechar para algún beneficio del atacante o algún daño al sistema. Para imaginar esto en el mundo real, podríamos pensar en una fábrica. Hay fábricas que tardan horas o días en volver a arrancar. 

Por ejemplo, en una petrolera, si tu paras un pozo, son 24 horas perdidas de producción. Entonces una vulnerabilidad podría ser que el ingeniero que diseñó el pozo dejó un botón rojo gigante que dice “No tocar”, porque se apaga el sistema en un lugar donde no hay cámaras, escondido, al lado del baño, y entonces un empleado enojado, alguien que ya no quiera a trabajar o una visita que pasó, lo puede presionar, y eso le va a costar a la empresa 24 horas de producción, que son millones de dólares. 

La vulnerabilidad sería dejar la existencia de ese componente tan importante en un lugar no cuidado. ¿Cómo se mitigaría esto? Hay varias opciones, como que ese botón esté al lado de un guardia o enfrente de una cámara  que lo está grabando, donde la gente igual puede ir a tocarlo, pero ya no es tan fácil hacer una broma ni que suceda un error. 

En el caso de software, hay veces donde una aplicación web, por ejemplo, solamente te pide el nombre del usuario, le puedes poner cualquier nombre, y te da los datos de cualquier usuario. Entonces, ahí es una falla en el software (vulnerabilidad), que no estaba verificando que solamente te puede entregar datos tuyos o de tus subordinados y te da cualquier dato, y eso tendría un impacto directo en la protección de datos.

Laura: Perfecto. O sea, la idea de la seguridad informática es no hacerle la vida fácil a quienes buscan estas vulnerabilidades, ¿verdad?

Manuel: Sí, la idea de la seguridad informática, en general, es proteger los datos e información de las empresas, y protegerlas de las amenazas. Las amenazas pueden venir de todos lados, son internas y externas, entonces es básicamente eso: cuidar que tus datos los tengan solamente quienes los deben de tener.

Susana: Bueno y ya entrando un poquito a tu trabajo como tal, en cuanto a las vulnerabilidades, ¿cómo trabajas? ¿para quién trabajas? ¿Quiénes son tus usuarios? ¿En qué consiste ese proceso?

Manuel: Nosotros nos encargamos de proteger que no haya vulnerabilidades en dos sitios: uno es en el código. Eso implica revisar todo el código que se escribe en la empresa y eso se hace con herramientas automatizadas, que cada que alguien escribe una parte nueva de código y la sube a los servidores, se revisa y se le avisa si detectamos alguna falla de seguridad, o sea, alguna vulnerabilidad. Y también de manera automatizada todas las noches, se revisa todo el código.

Eso por un lado, y por otro lado en la empresa usamos “containers”. Un container es justo un contenedor. Se inspiró el nombre y el enfoque en los contenedores de los barcos, porque hacer el “ship” (envío) de código, antes era cómo mandar cosas en barcos. Antes de los contenedores enviar cosas en barcos era una tarea muy artesanal porque para subir un piano al barco, era literal subir un piano al barco y acomodarlo, y para subir un barril se tenía que subir el barril, y así con cajas y el resto de las cosas. Todo se subía a mano individualmente. Hoy en día todos los barcos lo único que hacen es subir un contenedor. Van apilados y se acabó. 

Hoy en día el código es lo mismo, tú solamente subes un contenedor, que es una versión muy reducida del sistema operativo mínimo necesario para ejecutar tu código, tu aplicación, y ya. Entonces, entre las distintas partes de la empresa, lo único que se mandan es contenedores, como “usa tal contenedor, tal versión” porque enviar código era lo mismo que enviar un piano, que es muy difícil hacer que funcione. En cambio el contenedor solamente le das el comando “run” (correr) y se ejecuta. 

Siguiendo esa lógica, lo segundo que hacemos en la gestión de vulnerabilidades es proteger los contenedores. Revisamos que todos los contenedores que se usan en la empresa no tengan software con vulnerabilidades conocidas. En el mundo de la tecnología existe algo que se llama CVE, que es el “Common Vulnerabilities and Exposures”. Es una lista de información registrada a nivel mundial sobre las vulnerabilidades públicas. Cada vulnerabilidad tiene un número y de esa forma en todo el mundo podemos hablar y referirnos a la misma vulnerabilidad, con el mismo número. Entonces, en los contenedores buscamos si tienen algún CVE conocido, y en el código buscamos vulnerabilidades, que son muy específicas al código que se escribe.

Laura: Entonces en tu caso digamos que tu usuario, por decirlo de alguna manera, son los que hacen el código o son otros grupos dentro de tu propia empresa, ¿verdad?

Manuel: Exacto, sí. Mi usuario son los desarrolladores y sus managers. Ellos al final se mueven como grupo, y como grupo son responsables de la o las aplicaciones que escriben en la empresa.

Laura: Es decir, no es como que trabajes directamente con el usuario final de lo que sea que los desarrolladores están programando, normalmente.

Manuel: Normalmente no.

Laura: Y ¿qué tipos de enfoques hay a esa hora como de implementar la ciberseguridad? Por ejemplo, ¿son enfoques muy rígidos? O sea, por ejemplo, lo del CVE. ¿Ustedes hacen como una lista de chequeo y se la pasan todo el día revisando eso? ¿Le dicen al manager como “tú no has hecho esto, tú no has hecho aquello”? ¿O cómo funciona?

Manuel: No. Justo para nosotros es muy importante pensar en el usuario, pensar en el desarrollador, pensar en qué queremos hacer nosotros, y qué queremos que ellos hagan. También nos enfocamos en cómo queremos presentarnos a ellos.

No les queremos pedir a los equipos cosas que ellos no pueden arreglar. También cuidamos mucho no crear requerimientos que no tengan un elemento de acción claro.

O sea, al final están tratando de simplificarle la vida a estas otras personas. Porque así los demás no tienen que saber todos los detalles. También veo que ustedes hacen un esfuerzo por no interrumpir el flujo de trabajo de esos otros equipos, en la medida de lo posible.

Manuel: Exactamente. Justo lo que buscamos es no interrumpir flujos de trabajo, nunca bloquear a alguien para realizar su trabajo y pedirles la menor cantidad de cosas. Un buen equipo de seguridad debe de pedir poco o nada. El “nada” tal vez es imposible, pero debemos ser cuidadosos sobre qué cosas pedimos. En el ejemplo anterior, puede existir un caso donde el botón se presione de manera automática cuando alguien pasa con cierto smartwatch, porque el fabricante tuvo una falla. Ahí nosotros deberíamos cambiar todos los botones sin que el usuario se entere. De esa forma elevamos el nivel de seguridad, reducimos el riesgo y para el usuario no crea fricción o no empieza a cansarse del equipo de seguridad, porque, en mi experiencia, eso es lo que peor puede suceder: un equipo de seguridad que pide mucho, porque entonces ya nadie te hace caso o eres un estorbo.

También lo que tratamos de hacer mucho es, si le vamos a pedir algo al usuario, tiene que ser concreto y fácil de aplicar, no puede ser un “deberías de mejorar tu código” o “deberían de hacerlo más seguro”. Debemos decirle exactamente, en qué línea, en qué versión, en qué cosas. Por ejemplo, “tú tienes ahorita la versión 2.3 y quiero que tengas la 2.4, si no sabes cómo actualizar da clic aquí” y tenemos un documento donde explicamos paso a paso, cómo actualizar. O sea, la idea es no pedirles nada o si les tenemos que pedir algo que sea lo más puntual y preciso para que cualquier persona del equipo, no importa si lleva 3 años o si lleva 3 semanas, lo pueda realizar.

Sabemos que te quedaste con ganas de saber más, así que espera próximamente la segunda parte de esta entrevista…