Un equipo está a punto de construir una nueva funcionalidad de pago. ¿Cuándo y cómo debe hacerse el modelado de amenazas?
Respuesta breve
El modelado de amenazas es más barato y eficaz en la fase de diseño, antes de que el código fije las decisiones: recorre los flujos de datos, enumera amenazas con un marco como STRIDE, integra las mitigaciones y revísalo a medida que el diseño evoluciona. Hacerlo solo tras un incidente o en el pentest anual encuentra los problemas cuando ya son caros de corregir y están expuestos. Y fiarse de «desarrolladores cuidadosos» es una esperanza, no un control repetible y auditable.
Una funcionalidad de pago maneja dinero y datos sensibles — justo el tipo de sistema donde pensar la seguridad en la fase de diseño rinde más. La pregunta evalúa si el candidato entiende cuándo el trabajo de seguridad es barato y eficaz frente a cuándo es caro y reactivo.
Por qué gana el modelado de amenazas en el diseño
El modelado de amenazas es una forma estructurada de preguntar, antes de construir: ¿qué puede salir mal y qué haremos al respecto? En la fase de diseño la arquitectura aún es fluida — puedes mover una frontera de confianza, añadir un control o descartar una dependencia arriesgada por el coste de editar un diagrama, no de refactorizar código ya entregado.
Un flujo práctico:
- Diagrama los flujos de datos de la funcionalidad de pago y marca las fronteras de confianza (navegador → API → procesador de pagos → base de datos).
- Enumera amenazas con un marco como STRIDE — Suplantación, Manipulación, Repudio, Divulgación de información, Denegación de servicio, Elevación de privilegios — en cada frontera.
- Define mitigaciones (autenticación/autorización, validación de entradas, claves de idempotencia, tokenización, registro) y rastréalas como requisitos.
- Revísalo cada vez que el diseño cambie — es una actividad viva, no un acto único.
Por qué las respuestas incorrectas lo son
«Después del lanzamiento, solo si hay un incidente» es el peor momento posible: pagas en brechas, daño al cliente y rehacer de urgencia. «Solo durante el pentest anual» encuentra los problemas tarde, de forma estrecha y después de su salida — un pentest valida un diseño, no sustituye a diseñar con seguridad. «Innecesario si los desarrolladores son cuidadosos» confunde la diligencia individual con un proceso; el cuidado no es repetible, ni auditable, ni resistente a la rotación, y no ofrece cobertura sistemática de las categorías de amenazas.
Qué evalúa el entrevistador
Quiere instinto shift-left: razonamiento de seguridad integrado en el diseño, una metodología con nombre, fronteras de confianza y mitigaciones concretas, y la madurez de tratar el modelo de amenazas como un artefacto vivo que evoluciona con el sistema — no una casilla que marcar al final.
Posibles preguntas de seguimiento
- Repasa STRIDE aplicado a un flujo de pago — da una amenaza por categoría.
- ¿Qué artefactos (diagrama de flujo de datos, fronteras de confianza) necesitas antes de poder modelar amenazas?
- ¿Cómo mantienes vivo un modelo de amenazas en lugar de un documento único que se queda obsoleto?