Guía Esencial de Seguridad de Datos para Gestores de Producto
¿Has oído hablar de Code Spaces? Era un repositorio de código fuente similar a Github.
Bueno, probablemente nunca hayas oído hablar de ellos porque, a pesar de ser un producto prometedor, desaparecieron casi instantáneamente en junio de 2014 tras una enorme brecha de seguridad. La brecha les hizo perder todos los datos de sus clientes, lo que les obligó a cesar su actividad.
Después de ese incidente, todos en el mundo digital, incluidos los Product Managers, aprendieron una lección que nunca se debe olvidar: los PRODUCTOS TIENEN QUE SER SEGUROS.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
En esta guía, te introduciré en el mundo de la seguridad de productos y te ayudaré a tenerla presente al gestionar tus productos.
Por qué los Product Managers deben preocuparse por la seguridad de los datos
En teoría, tu día a día en gestión de productos debería centrarse solo en la retención, las entrevistas con usuarios y otras cuestiones no técnicas, sin preocuparte por la seguridad.
Sin embargo, vivimos en un mundo con personas malintencionadas deseosas de robar tus datos (para después venderlos en algún lugar), cifrarlos, pedir un rescate por ellos (lo que se conoce como ransomware), o incluso simplemente causar daño por el simple hecho de hacerlo.
Así que, además de preocuparte por la activación y la retención, también debes tener en cuenta el inmenso riesgo empresarial que una seguridad laxa puede suponer para tu producto. Una brecha de seguridad lo suficientemente grave puede dañar tu reputación tanto, que todos los años de trabajo duro de tus equipos de marketing, desarrollo de producto y ventas pueden desaparecer en un solo día.
Además, acabarás enfrentándote a acciones legales por parte de tus socios y clientes cuyos datos no pudiste proteger.
Por eso, en mi opinión, es de suma importancia que los Product Managers sean "conscientes de la seguridad" al construir y hacer crecer sus productos.
Las 4 brechas de seguridad más comunes en el desarrollo de productos
Como Product Manager, realmente no necesitas tener un conocimiento profundo de los métodos de hacking más recientes o de cómo protegerte de ellos. Ese es un trabajo para tus equipos de seguridad e ingeniería.
Sin embargo, necesitas comprender técnicamente de forma básica cómo funcionan algunos de los problemas de seguridad más frecuentes y cómo los atacantes pueden explotarlos. Esto hará que tu proceso de toma de decisiones sea más "consciente de la seguridad".
Vamos a repasar juntos cuatro de estas brechas de seguridad y entender de qué tratan.
1. Inyección SQL
Cuando era un joven PM, decidí aprender un poco de programación e hice un pequeño (y horrible) código PHP que servía como backend de un formulario de contacto de un sitio web. Recibía un mensaje, lo almacenaba en la base de datos y componía un correo electrónico dirigido a mí con su contenido.
Cuando se lo mostré a un amigo desarrollador, aparte de contener a duras penas su diversión (mi código era increíblemente malo), me preguntó si había sanitizado mis entradas. Como supondrás, no tenía ni idea de lo que quería decir, y me explicó que mis bases de datos estaban expuestas a inyección SQL por no sanear las entradas.
La inyección SQL (SQL injection) es el proceso mediante el cual el atacante escribe código SQL especial en vez de texto en tus campos de entrada, logrando así ejecutar este código en tu backend y obteniendo acceso no autorizado a tu producto o robando información de tus bases de datos.
Imagina que LinkedIn usara esta consulta SQL para verificar tu contraseña al iniciar sesión (aclaración: seguramente hacen algo mucho más inteligente que la consulta SQL de aquí).
Si, en teoría, los datos introducidos en la pantalla de inicio de sesión no estuvieran saneados, podrías escribir ' OR '1'='1 en los campos de usuario y contraseña y pulsar Iniciar sesión.
En ese caso, el backend añadiría tu ' OR '1'='1 en la consulta SQL y se convertiría en algo así.
Esta consulta devolverá el valor “true”. Eso significa que podrías iniciar sesión en LinkedIn sin necesidad de un usuario ni contraseña reales.
Como ya mencioné, puedes evitar este problema saneando las entradas de tus formularios. Saneamiento en este contexto significa asegurarse de que todo lo que escribas en los campos de entrada se trate como texto ordinario, incluso si escribes código o una consulta SQL.
Con los datos saneados, LinkedIn intentará buscar un usuario llamado ' OR '1'='1 en la base de datos en vez de ejecutar el código. Al final, no lo encontrará y mostrará un error diciendo que no existe tal persona en LinkedIn.
Protegerse frente a las inyecciones SQL es uno de los pasos básicos que puedes tomar para mantener seguros los datos de tus clientes y evitar fugas de información perjudiciales y accesos no autorizados.
2. Cross-Site Scripting (XSS)
XSS es otra forma común en la que los hackers pueden manipular tu producto y actuar de forma maliciosa sobre él. Para que te hagas una idea de lo frecuente que es XSS, un informe de Positive Technologies estima que aproximadamente el 90% de todas las aplicaciones web existentes son vulnerables a este tipo de ataque.
¿De qué va esto entonces? XSS se parece un poco a la inyección SQL en lo que respecta a hackers manipulando tu sistema para ejecutar código que no estaba previsto. Sin embargo, en este caso, el código malicioso que se ejecuta no está en el backend/bases de datos de tu sistema, sino en el frontend.
Uno de los ejemplos más graciosos e inofensivos de XSS es el emoji de corazón que se autoretuiteaba en Twitter (sí, yo también le sigo llamando Twitter—intenta convencerme de lo contrario). Es gracioso porque nadie esperaba que Twitter la pifiara a ese nivel, y es inofensivo porque lo único que hacía era retuitearse a sí mismo.
Este ataque era simplemente un tuit que contenía el siguiente texto.
Como se puede ver en la imagen, no es texto simple sino un trozo de código (Javascript con jQuery, para ser precisos), junto con un emoji de corazón al final.
Bueno, antes de que Twitter arreglara esta vulnerabilidad de seguridad, si abrías ese tuit en tu navegador, el motor del navegador lo reconocía como un código válido, lo ocultaba al usuario y lo ejecutaba. En vez de ver las dos líneas de código, solo verías un tuit con el emoji de corazón.
Cuando el código se ejecutaba, navegaba por el HTML de la página, encontraba automáticamente el botón de retuitear en tu pantalla y lo pulsaba.
Eso significaba que cualquier persona que viera ese tuit lo retuiteaba automáticamente—lo que llevó a que una enorme parte de los usuarios de Twitter se infectaran con este tuit.
Ahora imagina que no fuera un tuit autoreplicante, sino algo más dañino, como un script que roba información confidencial de tu pantalla y la envía al hacker. O, alternativamente, un código malicioso en tu navegador podría adueñarse de tu aplicación web de banca online y empezar a transferir fondos desde tu cuenta.
¿Ves por dónde voy? XSS sigue siendo muy peligroso, a pesar de que no puede acceder directamente a tus servidores y bases de datos.
¿Pero por qué debería preocuparte como product manager? Bueno, podrías acabar pidiendo a tus ingenieros algunas funcionalidades e integraciones interesantes como permitir que tu sitio web vea el contenido de otras pestañas del navegador del usuario y hacer algo curioso con esa información.
Si lo haces y tu equipo se niega a desarrollar esa función, no te confundas ni te pongas triste, ya que, básicamente, lo que estás pidiendo es ejecutar un ataque XSS contra otros sitios.
XSS es un área fascinante dentro de la ciberseguridad, y hay muchos libros recomendables sobre el tema. Mi favorito es XSS Attacks de Seth Fogie.
3. APIs inseguras
Las interfaces de programación de aplicaciones (también conocidas como APIs) son los medios de comunicación entre tu servidor y el navegador del usuario o la aplicación en su dispositivo móvil/escritorio.
Siempre que sea necesario obtener, guardar o procesar datos en tu servidor, el navegador o la app (es decir, los “clientes”) envían una solicitud al servidor con la información necesaria. Luego el servidor hace el trabajo y envía la respuesta.
Por ejemplo, al iniciar sesión, los clientes enviarán tu nombre de usuario y contraseña y pedirán al servidor que te autentique. En cuanto el servidor complete la solicitud, responderá con un mensaje de “éxito” y el contenido de la página que el usuario debe ver cuando inicie sesión correctamente.
Como las APIs trabajan con datos de los usuarios, también son propensas a vulnerabilidades de seguridad que pueden derivar en manipulación maliciosa de los datos (por ejemplo, pedirle al servidor que realice una transferencia de dinero en nombre del usuario) o en brechas de información (por ejemplo, pedirle al servidor que revele el historial médico del usuario).
Los tipos de vulnerabilidades de API más comunes son:
Sin autenticación: En este caso, la API no exige que el cliente demuestre su identidad antes de proporcionar información confidencial. Para darle una dimensión a esto, imagina que alguien va al banco y pide retirar dinero de la cuenta de Mark Zuckerberk, y la cajera simplemente responde: "Por supuesto, ¿cuánto?"
Sin limitación de tasa: Aquí, las APIs no dejarán de procesar solicitudes, incluso si hay demasiadas—es decir, muchas más de las que se suponía que debía haber—lo que provoca la sobrecarga de tu servidor y su caída. Este tipo de avalancha excesiva de solicitudes ocurre cuando alguien intenta realizar un ataque DDoS en tus servidores.
Exposición excesiva de datos: Esto ocurre cuando las respuestas de tu API contienen información a la que realmente no quieres que la gente acceda. Por ejemplo, al enviar dinero a alguien mediante la banca en línea, supongamos que la notificación de la API que indica que la transacción ha sido exitosa también contiene el saldo de la cuenta del destinatario, lo cual es algo que definitivamente no deberías ver.
Las soluciones para estas tres vulnerabilidades son bastante obvias. Solicita autenticación al servir datos sensibles, añade limitación de tasa y asegúrate de no entregar datos que no deberían estar presentes.
Si quieres profundizar un poco más en la seguridad de las APIs, puedes consultar el libro de Neil Madden sobre el tema.
4. Falta de cifrado
Mi jefe de seguridad siempre repite que una buena estrategia de ciberseguridad en un producto se parece a una cebolla: está compuesta por múltiples capas de seguridad sobre diferentes partes del producto.
Todo lo que hemos discutido hasta ahora son riesgos de seguridad en la capa superficial, cuando el usuario no puede acceder a tus servidores o bases de datos e intenta atacar “desde la superficie”.
Sin embargo, si un hacker logra obtener acceso completo a tus servidores (penetra la primera capa), todavía deberías contar con medidas para proteger tus bases de datos de accesos no autorizados—manteniendo también seguras tus capas internas.
Una de las mejores formas de proteger tus datos, en este caso, es cifrándolos. Esto significa que, incluso si alguien accede a tus bases de datos y descarga esa información, solo verá una serie de caracteres sin sentido, ya que está cifrada.
Solo la empresa o el usuario—las dos partes que tienen la clave de cifrado—podrán descifrar esa información y convertirla en datos útiles. Desafortunadamente, sin embargo, olvidar cifrar los datos en los servidores es algo muy común y ha provocado numerosas filtraciones masivas de datos.
Personalmente, he visto demasiados sitios web y productos que han tentado a la suerte almacenando las contraseñas de sus usuarios en texto plano—algo que se considera un pecado mortal en el software. La mejor práctica en este caso es pasar la contraseña por un algoritmo de hashing, obtener una versión cifrada (llamada hash) y almacenar esa en su lugar.
La ventaja de esto es que tanto el usuario como la empresa tienen la clave para convertir el hash en su forma de texto plano y usar esa contraseña para la autenticación. Pero, si un hacker accede a la base de datos y descarga el hash, convertirlo nuevamente a la contraseña original les llevaría millones de años de cálculos sin la clave. (No es broma, ¡ese es el número real!)
El cifrado es otro campo fascinante dentro de la ciberseguridad que te recomiendo investigar. En particular, puedes comenzar aprendiendo cómo funciona la criptografía de clave pública, ya que es la base sobre la que funciona ahora todo internet.
Integrando la Seguridad de Aplicaciones en el Ciclo de Vida del Producto y el Desarrollo de Software
Con todas estas vulnerabilidades y buenas prácticas en mente, enfoquémonos en una pregunta obvia que podrías tener—¿cómo mantengo mis productos seguros como PM?
¡Pensé que nunca lo preguntarías! Aquí tienes dos prácticas recomendadas de seguridad que pueden ayudarte en esto:
Productos seguros desde el diseño
Este es un enfoque de proceso de desarrollo que indica que debes tener en cuenta los requisitos de seguridad desde el momento en que comienzas a construir tus productos, para que las medidas de seguridad estén integradas de forma nativa en tu código y arquitectura y no sean añadidas después en el SDLC.
Hacerlo después suele ser mucho más costoso y no ofrece el mismo nivel de protección que un software “seguro de forma nativa”.
Así que, como gerente de producto, es tu responsabilidad pedir a tu equipo de desarrollo que siga este enfoque y evitar que se desprioricen elementos que ayuden a construir la seguridad en el producto.
More Articles
- IA en investigación de usuarios: Cómo la inteligencia artificial está transformando la obtención de conocimientos de usuario
- Lanzar Productos Pensados para lo Global sin Dolor de Cabeza: Cómo Integrar la Localización en tu Flujo de Trabajo de Producto
- La IA en la Planificación de Sprints: Cómo la IA Mejora la Eficiencia del Equipo
Auditorías de seguridad regulares
La mayoría de los productos que he gestionado recibían pruebas de seguridad periódicas (normalmente una vez cada seis meses a un año). Evaluábamos todo el panorama de seguridad, e incluía:
- Pruebas de penetración
- Modelado de amenazas
- Revisión de controles de seguridad
- Revisión de la estrategia y las características de seguridad
- Revisión de la cadena de suministro y flujos de trabajo de automatización
- Análisis de código (incluyendo el código open source que usamos y el código obtenido de colaboraciones con terceros)
- Creación de hoja de ruta de seguridad y métricas
- Evaluación de riesgos
- ...¡y mucho más!
Esto es importante porque tu producto está en constante evolución, y podrías romper accidentalmente la seguridad de tu software al agregar algo nuevo. Las auditorías regulares identificarán rápidamente estos problemas y te permitirán solucionarlos y validarlos, antes de que alguien malintencionado los descubra primero.
Como responsable de producto, tu tarea es asignar tiempo y priorizar estas auditorías y las limpiezas de código que se derivan de ellas.
Confía en tu equipo de seguridad
Cualquier función que planees desarrollar y cualquier plan de acción que tengas para lograr tus objetivos de crecimiento, asegúrate siempre de compartir tus ideas con tu equipo de seguridad.
Y escucha: puede que te parezca que el equipo de seguridad quiere que tu producto esté “sobreprotegido”. Sin embargo, la mayoría de las veces, si no les gusta tu idea, deberías considerar hacer cambios en ella. De lo contrario, no vale la pena correr el riesgo.
Y hablando de considerar cosas, considera también suscribirte a nuestro boletín para recibir muchas guías y artículos sobre gestión de productos directamente en tu correo electrónico.
