Integra la seguridad en el proceso de diseño de producto: el threat modeling en la fase de descubrimiento, la colaboración con el equipo de seguridad y las decisiones de producto que protegen a los usuarios sin sacrificar la experiencia.
Cuándo usarlo: Integrar la seguridad en el proceso de diseño de producto desde la fase de descubrimiento.
Herramienta recomendada: Claude
Eres un experto en product security y en la integración de la seguridad en el proceso de diseño de producto. Necesito tu ayuda para incorporar la seguridad en mi proceso de product management desde la fase de descubrimiento, para que las decisiones de seguridad se tomen cuando son más baratas y efectivas (antes de construir) y no como correcciones de emergencia después de un incidente. Mi contexto: - Tipo de producto: [SaaS, app móvil, plataforma, marketplace, etc.] - Tipo de datos que maneja el producto: [datos de usuario, datos financieros, datos de salud, contenido generado por usuario, etc.] - Proceso de discovery y diseño actual: [cómo defines features, quién participa, cuándo se revisa técnicamente] - Relación actual con el equipo de seguridad: [no tenemos equipo de seguridad / colaboramos poco / queremos mejorar] - Incidentes de seguridad previos o vulnerabilidades encontradas: [si las hay] Con ese contexto, dame: 1. POR QUÉ LA SEGURIDAD DE PRODUCTO ES RESPONSABILIDAD DEL PM Explícame el cambio de paradigma de la seguridad como responsabilidad exclusiva de engineering a la seguridad como parte del diseño de producto: el coste exponencialmente mayor de arreglar vulnerabilidades en producción vs. en la fase de diseño, el papel del PM en identificar los riesgos de seguridad durante el discovery, y cómo los mejores productos del mundo (Apple, Stripe, 1Password) han integrado la seguridad en la cultura de producto hasta el punto de que es un argumento de marketing. Por qué ignorar la seguridad en el diseño de producto no es ir más rápido sino endeudarse en seguridad. 2. THREAT MODELING EN LA FASE DE DESCUBRIMIENTO ¿Cómo hago threat modeling como parte del proceso de discovery sin ser un experto en seguridad? Dame el proceso simplificado de threat modeling para PMs: las cuatro preguntas que debo hacerme para cada feature nueva (¿qué puede salir mal?, ¿a quién puede dañar?, ¿cuál es el impacto si ocurre?, ¿cómo lo prevenimos?), el framework STRIDE adaptado a la perspectiva del producto, cómo diagramar los flujos de datos de la feature para identificar los puntos de riesgo, y cuándo escalar al equipo de seguridad porque el riesgo identificado requiere una revisión especializada. 3. DECISIONES DE PRODUCTO QUE TIENEN IMPLICACIONES DE SEGURIDAD ¿Cuáles son las decisiones de diseño de producto que más frecuentemente crean riesgos de seguridad? Dame el top de decisiones de producto con impacto en seguridad: el diseño del modelo de roles y permisos (quién puede ver y hacer qué en el producto), la decisión de almacenar o no datos sensibles del usuario (si no los almacenamos no podemos perderlos), el diseño de las integraciones con terceros (cada integración amplía la superficie de ataque), el diseño de las funciones de exportación de datos (que pueden convertirse en vectores de filtración), y la gestión del ciclo de vida de los datos del usuario (retención, eliminación, exportación bajo RGPD). 4. CÓMO COLABORAR CON EL EQUIPO DE SEGURIDAD DESDE PRODUCTO ¿Cómo trabajo con el equipo de seguridad para que sea un aliado y no un bloqueador? Dame el modelo de colaboración PM-Security: cuándo involucrar al equipo de seguridad en el proceso de discovery (en features con datos sensibles, autenticación, pagos, o acceso a recursos de otros usuarios), cómo presentar una feature al equipo de seguridad para que puedan evaluarla eficientemente, el flujo de security review que no bloquea el sprint, y cómo gestionar las situaciones en las que el equipo de seguridad dice que algo no se puede hacer de la manera que el PM lo ha diseñado. 5. PRIVACIDAD POR DISEÑO (PRIVACY BY DESIGN) EN EL PRODUCTO ¿Cómo aplico los principios de privacy by design en mis decisiones de producto? Dame los siete principios del privacy by design del RGPD aplicados a decisiones concretas de producto: la minimización de datos (pedir solo lo que necesitamos), el propósito limitado (no usar los datos para algo distinto a lo que el usuario aceptó), la privacidad por defecto (la configuración menos invasiva debe ser la predeterminada), y la transparencia con el usuario sobre cómo usamos sus datos. Dame ejemplos de decisiones de producto donde aplicar cada principio. 6. EL SECURITY ROADMAP DEL PRODUCTO ¿Cómo priorizo las iniciativas de seguridad en el roadmap de producto? Dame el framework de priorización de seguridad que equilibra el impacto en seguridad con el esfuerzo de implementación y el coste de no hacerlo: cómo cuantificar el riesgo en términos que la dirección entienda (probabilidad de incidente x impacto económico x daño reputacional), cómo balancear las iniciativas de seguridad preventiva con las de remediación de vulnerabilidades existentes, y cómo comunicar al equipo ejecutivo por qué invertir en seguridad de producto es rentable aunque no genere features nuevas. 7. MÉTRICAS DE PRODUCT SECURITY ¿Cómo mido que la seguridad del producto está mejorando? Dame las métricas de product security que un PM debe monitorizar: el número de vulnerabilidades encontradas por severidad y el tiempo medio de remediación, el porcentaje de features que pasan por threat modeling antes de desarrollarse, el número de incidentes de seguridad por release y la tendencia, el tiempo de detección de vulnerabilidades (cuanto antes se detectan, más barato es arreglarlas), y cómo usar los resultados de bug bounty o pentesting como input para el roadmap de seguridad.