ATALAIA
Reservar llamada→
  1. Inicio
  2. Recursos
  3. Blog
  4. Threat modeling, en equipo
Diseño · Guía

Threat modeling, en equipo

Por qué los mejores threat models salen con negocio, desarrolladores y ciber en la misma sala, y cómo hacer uno en una hora.

3 min de lecturaEquipo Atalaia

Threat modelingSTRIDEWorkshops

La mayoría de los threat models fallan de una de dos maneras. O los escribe seguridad sola y describen un sistema que nadie del equipo reconoce. O llegan tarde y describen un sistema que ya se ha entregado.

La solución no es una plantilla mejor. Es una sala mejor.

Quién está en la sala

Producto, porque sabe para qué sirve la funcionalidad y qué no querría perder el negocio. El dev lead, porque sabe cómo está construido de verdad. Alguien de seguridad, porque sabe cómo se rompen las cosas. Security champions, si los tienes.

La hora

  1. 10 min · dibújaloUna funcionalidad, una pizarra. Cajas para los componentes, flechas para los datos, líneas discontinuas donde cambia la confianza. Hazlo feo y rápido.
  2. 30 min · rómpeloRecorre cada flecha y pregunta: ¿quién podría falsificar esto, cambiarlo, leerlo, bloquearlo o usarlo para conseguir más acceso del que debería?
  3. 15 min · priorízaloImpacto por probabilidad, a grandes rasgos. Producto decide qué riesgo puede asumir el negocio; seguridad dice lo difícil que es explotar cada uno.
  4. 5 min · ticketCada amenaza que conservas se convierte en un ticket con responsable. Los casos de abuso pasan a QA como ideas de prueba.

Rómpelo, con STRIDE como guía

Las seis letras de STRIDE dan buenas preguntas para cada flecha: suplantación (spoofing), manipulación (tampering), repudio, divulgación de información, denegación de servicio y elevación de privilegios. Escribe todas las respuestas, incluso las tontas. Las tontas suelen esconder el bug real.

Qué cambia

Los desarrolladores dejan de enterarse de la seguridad por primera vez en un informe de pentest. Producto entiende por qué importa un control. Seguridad aprende cómo funciona de verdad el sistema. Y el threat model vive en el repo, junto al código, donde se mantiene al día.

Qué hacer el lunes

  • Elige la siguiente funcionalidad con una nueva entrada externa o un nuevo almacén de datos.
  • Reserva una hora con producto, el dev lead y seguridad.
  • Haz commit de la foto de la pizarra y de la lista de amenazas como docs/threat-model.md.

Dónde encaja en la línea

Threat ModelingRequisitos de seguridad

En la torre (en desarrollo):

Threat model por capas

Seguir leyendo

DiseñoOpiniónMantén tu threat model por capas

Un único documento de threat model se queda obsoleto la semana siguiente al workshop. Divídelo en capas y actualiza cada una cuando esa capa cambie.

4 min de lecturaDiseñoAnálisis a fondoFronteras de confianza que puedes dibujar en una página

Si tu diagrama de arquitectura no puede mostrar dónde cambia la confianza, no puede decirte hacia dónde van los ataques. Así se dibuja uno que sí lo haga.

4 min de lecturaDiseñoGuíaLos casos de abuso van junto a las historias de usuario

Escribe la historia de mal uso en el mismo ticket que la funcionalidad y los requisitos de seguridad dejarán de ser un documento que nadie abre.

4 min de lectura

Habladlo

Una llamada de 30 minutos. Sin diapositivas, sin lista de precios y con un siguiente paso en cualquier caso.

Reservar una llamada →Recorre todas las estaciones