Modelado de amenazas STRIDE

QuickBite está agregando pedidos en línea. Los clientes eligen comida, pagan y esperan a que el restaurante confirme el pedido.

El camino feliz está claro. Un cliente hace un pedido, la cocina lo recibe y la app envía actualizaciones.

Seguridad hace una pregunta distinta: ¿qué podría salir mal antes de que lo construyamos?

Esa pregunta se llama modelado de amenazas. Miras un diseño, imaginas formas en que podría usarse mal y luego decides qué debe prevenir el código.

El modelado de amenazas ocurre antes del reporte de bugs

La revisión de código mira código que ya existe.

El modelado de amenazas mira la funcionalidad mientras todavía es barato cambiarla.

La lista STRIDE

STRIDE es una regla mnemotécnica para seis formas en que un atacante podría meterse con un sistema. Las letras significan:

Letra	Amenaza	Pregunta en simple
S	Spoofing (suplantación)	¿Puede alguien hacerse pasar por otra persona?
T	Tampering (manipulación)	¿Puede alguien cambiar datos que no debería poder cambiar?
R	Repudiation (repudio)	¿Puede alguien negar haber hecho algo porque no existe un registro?
I	Information disclosure (divulgación de información)	¿Puede alguien ver datos que no debería poder ver?
D	Denial of service (denegación de servicio)	¿Puede alguien impedir que la app funcione para otros?
E	Elevation of privilege (elevación de privilegios)	¿Puede alguien hacer más de lo que su rol permite?

La frase del curso es útil: STRIDE te da seis formas en que un atacante podría meterse con tu sistema.

Apliquemos esas seis preguntas a QuickBite.

JunoLa lista STRIDE STRIDE es una lista de verificación para tu imaginación. Te evita quedarte solo con la primera pregunta de seguridad que se te venga a la mente.

Las letras dan menos miedo cuando las conviertes en preguntas simples: ¿alguien puede fingir ser otro, cambiar algo, negar algo, leer algo, bloquear algo, o hacer más de lo que debería?

JunoLa lista STRIDE Usa STRIDE para que la revisión no dependa de quién esté en la sala en ese momento. Seis preguntas, siempre en el mismo orden, en cada funcionalidad.

Lo útil no es el acrónimo. Es la fila que puedes convertir en trabajo concreto: el servidor verifica quién es el dueño del pedido antes de mostrarlo, el monto del pago se calcula en el servidor, y los cambios de pedido quedan registrados con cuenta y hora.

JunoLa lista STRIDE STRIDE surgió del trabajo de modelado de amenazas de Microsoft a fines de los años noventa, lo cual es un buen recordatorio de que lo que perduró no fue la herramienta, sino la lista de preguntas repetibles.

Las letras no son una garantía. Se les escapa el abuso cuando un usuario hace exactamente lo que su rol permite pero a una escala dañina, y tampoco te dicen si deberías haber recolectado esos datos en primer lugar.

Trata STRIDE como un primer análisis disciplinado, no como un certificado de los dioses de la seguridad. Los dioses no están disponibles y la entrega es el viernes.

Recorre QuickBite con STRIDE

Empieza con un solo flujo de funcionalidad:

1. El cliente crea un pedido.
2. El servidor calcula el total.
3. El cliente paga.
4. El restaurante acepta o rechaza el pedido.
5. El cliente recibe actualizaciones.

Ahora hazle las seis preguntas de STRIDE a ese flujo.

Amenaza	Ejemplo en QuickBite	Decisión
Spoofing	Una solicitud dice ser de otro cliente.	Usa la sesión iniciada, no un id de usuario que venga en el cuerpo de la solicitud.
Tampering	El navegador envía un precio más bajo.	Calcula el precio en el servidor a partir de los datos del menú.
Repudiation	Un restaurante dice que nunca rechazó un pedido.	Registra quién cambió el estado del pedido y cuándo.
Information disclosure	Un cliente lee el pedido de otro cliente.	Verifica la propiedad antes de devolver los detalles del pedido.
Denial of service	Un usuario envía miles de pedidos.	Agrega límites de frecuencia y de tamaño de solicitud.
Elevation of privilege	Un cliente llama a un endpoint exclusivo para restaurantes.	Verifica el rol y la pertenencia al restaurante en el servidor.

Esa tabla ya es útil por sí sola. Le dice al equipo qué verificaciones deben existir antes de que la funcionalidad sea lo bastante segura para lanzarse.

Un modelo de amenazas solo importa cuando cada amenaza se convierte en una decisión.

JunoRecorre QuickBite con STRIDE Elige una funcionalidad y recórrela como si fuera una historia. En cada paso, pregúntate qué podría fingir, cambiar, negar, leer, bloquear o hacer sin permiso alguien.

Luego escribe la decisión al lado. Una preocupación se vuelve útil cuando alguien puede construir o probar la respuesta.

JunoRecorre QuickBite con STRIDE La tabla es el artefacto. Mantenla cerca del ticket, no enterrada en un documento aparte que nadie vuelve a abrir después de la planificación.

Redacta las filas como criterios de aceptación siempre que puedas. "El servidor calcula el total a partir de los datos del menú" se puede construir. "Es posible manipular el precio" es una nota con la que todos están de acuerdo y que después olvidan.

JunoRecorre QuickBite con STRIDE El fallo silencioso más común es escribir amenazas sin dueño. Cada fila debería terminar siendo una de tres cosas: arreglar ahora, aceptar con una razón, o postergar con un responsable asignado.

Eso suena burocrático hasta que la revisión de un incidente pregunta por qué el total del pedido confiaba en el navegador. Un riesgo aceptado y con fecha es una decisión. Una columna de decisión vacía es arqueología con peor iluminación.

Modelado de amenazas potenciales

El modelado de amenazas potenciales empieza en grande. En lugar de una sola funcionalidad, miras un sistema completo o una parte grande de él.

Para QuickBite, eso podría significar:

• todo lo que un cliente puede hacer después de iniciar sesión
• todo lo que un dueño de restaurante puede hacer
• todo el flujo de pago
• cada lugar por donde los datos de un pedido salen de la app

Este enfoque es útil cuando heredas una app, lanzas un sistema nuevo o quieres encontrar problemas de diseño antiguos.

El riesgo es que el alcance se te salga de control. "Toda la app" se convierte en una reunión larga y una sala agotada. Elige un límite que la gente pueda señalar con claridad.

Define el alcance antes de empezar

El modelado de amenazas potenciales necesita un alcance fijo y un tiempo fijo.

Sin ambas cosas, el ejercicio se expande hasta que todos dejan de tomar decisiones.

JunoModelado de amenazas potenciales El modelado de amenazas potenciales es la versión amplia. Miras un área completa, como el flujo de pago, y te preguntas qué podría salir mal ahí.

Mantén el borde lo bastante pequeño como para poder verlo. "El flujo de pago" es útil. "Toda la app" suele convertirse en una máquina de niebla.

JunoModelado de amenazas potenciales Usa el modelado de amenazas potenciales cuando la forma general del sistema importa más que una sola funcionalidad. Las acciones del cliente, las acciones del dueño del restaurante, el pago, las subidas de archivos y las herramientas de administración son buenos alcances para trabajar.

Antes de que empiece la reunión, escribe el límite. Si una amenaza queda fuera de él, déjala para después. De lo contrario, la sesión se convierte en un recorrido por todo lo preocupante que tiene el producto.

JunoModelado de amenazas potenciales El barrido amplio rara vez produce trabajo del tamaño de un sprint. Lo que produce son problemas de forma: un flujo de pago con demasiados puntos de entrada, una superficie de administración que comparte la sesión del cliente, una ruta de webhook que nadie tiene a su cargo.

Eso sigue siendo valioso, pero apunta el resultado hacia la planificación. Ordena los hallazgos según lo que cuesta dejarlos sin resolver, y redacta el argumento con suficiente claridad como para que alguien pueda financiarlo más adelante sin tener que reconstruir la reunión de memoria. La memoria es el lugar donde las decisiones de riesgo terminan convirtiéndose en folclore.

Ponlo en práctica

QuickBite agrega una funcionalidad: un cliente puede dejar una reseña en un pedido completado, y el restaurante puede responder.

Recórrela con STRIDE. Para cada letra, nombra algo que podría salir mal y la verificación que lo resuelve.

Compara tus respuestas

Letra	Qué podría salir mal	La verificación
S Spoofing	Alguien publica una reseña haciéndose pasar por otro cliente	El servidor toma al autor de la sesión, nunca del cuerpo de la solicitud
T Tampering	Un restaurante edita el texto o la calificación de una reseña después de publicada	Solo el autor puede editar su propia reseña, y las respuestas son registros aparte
R Repudiation	Un restaurante niega haber publicado una respuesta ofensiva	Registra quién escribió qué y cuándo, junto con el id de la cuenta
I Information disclosure	Una reseña expone el nombre completo o la dirección del cliente	Decide qué es público antes de guardarlo, y devuelve solo esos campos
D Denial of service	Alguien publica miles de reseñas, o una reseña de un megabyte de largo	Un límite de longitud en el texto y un límite de frecuencia en el endpoint
E Elevation of privilege	Un cliente responde como si fuera el restaurante	La ruta de respuesta verifica que la cuenta sea dueña de ese restaurante

Vale la pena notar dos cosas. R es la que la gente suele saltarse, porque nada parece roto hasta que alguien disputa lo que pasó, y para entonces el registro existe o no existe.

Y S tiene una sola solución que la cierra por completo: tomar la identidad desde la sesión, nunca desde un campo que envía quien hace la llamada. Una reseña que trae su propio authorId es una reseña que cualquiera puede firmar con el nombre de otra persona.

Hacia dónde va esto

STRIDE te da las seis preguntas. El siguiente capítulo cambia la escala.

En lugar de barrer un sistema completo, el modelado de amenazas por funcionalidad aplica esas preguntas a una funcionalidad a la vez. Esa es la versión que la mayoría de los desarrolladores puede usar dentro de una planificación normal.