Threat Modeling

Paso 1Elige la funcionalidad

Una funcionalidad o servicio que importe este trimestre, no todo el parque.

PRODUCTOEste trimestre toca la redención con partners: los usuarios gastan puntos en tiendas de partners.

ATALAIAEntonces es ese. Se mueve dinero y hay un partner de por medio. Solo ese flujo, hoy.

DEV LEADToca el ledger, la API del partner y la pantalla de redeem.

Sale de la salaFuncionalidad: canjear puntos en tiendas asociadas

Paso 2Dibújalo en equipo

Flujos de datos y límites de confianza en una pizarra, con producto, devs y cyber en la sala.

DEV LEADLa app llama a redeem, debitamos el ledger y luego le pedimos un vale al partner.

ATALAIADibuja una línea discontinua donde empieza la red del partner. Eso es un límite de confianza.

DESARROLLADORY el partner nos llama de vuelta para confirmar. Ese webhook es público.

Sale de la salaTablero: 6 flujos, 2 trust boundaries

Paso 3Encuentra las amenazas

Prompts al estilo STRIDE, historias de atacante y las preguntas que nadie ha hecho todavía.

ATALAIA¿Y si alguien envía redeem dos veces, en el mismo instante?

DESARROLLADORDos débitos compiten. Podrían gastar los mismos puntos dos veces.

CHAMPIONY un webhook falso podría confirmar vales que nadie ha pagado.

PRODUCTOEl doble gasto es lo que el negocio no puede soportar. Ponlo el primero.

Sale de la sala4 amenazas encontradas, 2 de riesgo alto

Paso 4Conviértelos en tickets

Cada amenaza sale como un ticket, un responsable y un test.

DEV LEADClave de idempotencia en redeem. Ese ticket es mío, este sprint.

ATALAIAWebhooks firmados con la clave del partner. QA recibe la race condition como test.

PRODUCTOY el modelo va en el repo. El siguiente lo hacemos sin vosotros.

Sale de la sala4 tickets, 3 tests de abuse case