A la lliçó anterior vam situar el disseny com la fase de major retorn de l'S-SDLC, i la seva activitat estrella com el modelatge d'amenaces. Ja ho vam anticipar a la lliçó 03-05 (Disseny Insegur), on vam dir que una fallada d'arquitectura no es corregeix amb un pedaç i que la manera d'anticipar-la tenia nom propi, el desenvolupament del qual deixàvem per aquí. Ha arribat el moment. El modelatge d'amenaces és l'exercici estructurat d'imaginar, abans de construir, com un adversari intentaria abusar del sistema, per decidir quines defenses incorporar per disseny. És la disciplina que respon a la pregunta que un pentest només respon tard i car: què pot sortir malament? En aquesta lliçó construïm un threat model complet del checkout de BazarNube.

1. Què és el modelatge d'amenaces i quan fer-lo
2. Les quatre preguntes de Shostack
3. Diagrames de flux de dades (DFD) i límits de confiança
4. STRIDE: un llenguatge de categories d'amenaça
5. Priorització de riscos (DREAD i alternatives)
6. Eines: Threat Dragon i pytm
7. Threat model del checkout de BazarNube
8. Errors comuns i consells
9. Exercicis
10. Conclusió

Modelar amenaces és analitzar un disseny buscant de forma sistemàtica els seus punts febles i les contramesures apropiades. No requereix que el sistema estigui construït: es fa sobre diagrames i decisions, que és precisament el seu avantatge. És un exercici d'equip, no un informe que redacta un expert en solitari; el valor és tant al document resultant com a la conversa que el produeix.

Quan fer-lo?

• En dissenyar una funcionalitat nova amb dades sensibles o diners pel mig.
• Davant d'un canvi d'arquitectura rellevant (nou servei, nova integració externa, nou magatzem de dades).
• De forma periòdica sobre components crítics, perquè el sistema i les amenaces evolucionen.
• No és realista modelar cada commit: es reserva per al que importa, guiat per la classificació de dades que vam fer a la fase de requisits.

Adam Shostack va popularitzar un marc de quatre preguntes que estructura qualsevol sessió de modelatge. OWASP l'adopta com a columna vertebral del procés.

La quarta pregunta tanca el bucle: un threat model no és un artefacte mort, es revisa quan el disseny canvia. Fixem-nos en el paral·lelisme amb l'S-SDLC: la pregunta 3 alimenta requisits ASVS i la pregunta 4 es recolza en verificació (per exemple, ZAP comprovant que una mitigació funciona).

Per respondre "què construïm?" es dibuixa un Diagrama de Flux de Dades (Data Flow Diagram). Un DFD usa un vocabulari deliberadament petit:

• Entitat externa (rectangle): actor fora del nostre control (usuari, passarel·la de pagament).
• Procés (cercle): codi que transforma dades (una API, un servei).
• Magatzem de dades (dues línies paral·leles): base de dades, cau, cua.
• Flux de dades (fletxa): el moviment de dades entre els anteriors.
• Límit de confiança (línia discontínua): la frontera on canvia el nivell de confiança; travessar-la és on neixen la majoria de les amenaces.

Els límits de confiança són el concepte clau. Cada vegada que una dada en travessa un —d'Internet a la nostra API, de la nostra API a la base de dades, del nostre backend a un servei de tercers— hi ha una oportunitat per a l'atacant i una necessitat de validar, autenticar o xifrar. Modelar bé consisteix, en bona mesura, a enfocar l'atenció en aquests encreuaments.

Respondre "què pot sortir malament?" a mà porta a oblits. STRIDE, creat a Microsoft, és una mnemònica que força a considerar sis categories d'amenaça per a cada element del DFD. Cada categoria és la negació d'una propietat de seguretat desitjable.

Una tècnica pràctica és STRIDE-per-element: recórrer cada procés, magatzem i flux del DFD i preguntar-se quines lletres de STRIDE apliquen. No totes apliquen a tots els elements, i això està bé; el valor és la cobertura sistemàtica.

No totes les amenaces mereixen la mateixa atenció. Cal prioritzar per invertir l'esforç on importa. DREAD és un model clàssic que puntua cada amenaça en cinc eixos (típicament 1-3 o 1-10):

• Damage — dany potencial.
• Reproducibility — facilitat de reproduir l'atac.
• Exploitability — esforç per explotar-lo.
• Affected users — quants usuaris afecta.
• Discoverability — facilitat de descobrir la vulnerabilitat.

Se sumen els eixos i s'ordena. DREAD és simple però subjectiu (dues persones puntuen diferent), per la qual cosa molts equips prefereixen alternatives:

Per a BazarNube usarem una simple matriu probabilitat x impacte (Alt/Mitjà/Baix), suficient per prioritzar i fàcil de consensuar en equip.

Modelar es pot fer en una pissarra, però hi ha eines que ajuden a mantenir el model viu i versionat:

• OWASP Threat Dragon: aplicació gràfica (web i escriptori) per dibuixar DFDs i anotar amenaces STRIDE. Guarda el model com a JSON, versionable a Git al costat del codi. Ideal per a equips que prefereixen el visual.
• pytm: framework de threat modeling as code en Python. Es descriu el sistema com a objectes (processos, magatzems, fluxos, límits) en un script i l'eina genera el DFD i un informe d'amenaces. Encaixa amb la filosofia "tot com a codi" que veurem a DevSecOps.

L'eina no substitueix el criteri: és l'equip qui decideix quines amenaces són reals i quines mitigacions apliquen.

Apliquem les quatre preguntes al flux més sensible de BazarNube: el checkout, on convergeixen dades personals, adreces i el pagament.

Els encreuaments de límit de confiança són: client→API (Internet a interna), API→passarel·la i el webhook passarel·la→API (interna a tercer). Aquí concentrem l'anàlisi.

Observem com cada mitigació enllaça amb un control ja estudiat: el threat model no inventa defenses noves, sinó que decideix quines del catàleg Top Ten/ASVS apliquen a aquest disseny. El threat model tradueix riscos genèrics en requisits concrets i verificables. Aquest és exactament el pont cap a la fase de proves, on ZAP i les proves manuals confirmaran que la mitigació funciona.

El Security Champion de l'equip revisa el model, es registren les mitigacions com a requisits d'acceptació (ASVS) al backlog, i es marca el model per a revisió quan canviï la passarel·la o s'afegeixi, per exemple, pagament ajornat. L'amenaça del webhook falsificat es converteix en una història amb la seva prova corresponent.

• Modelar el sistema perfecte, no el real. El DFD ha de reflectir com funciona de veritat, inclosos els dreceres i el servei legacy de Java. Un model idealitzat oculta les amenaces reals.
• Buscar l'exhaustivitat absoluta. És impossible enumerar tota amenaça. Prioritza els encreuaments de límit de confiança i les dades sensibles; un model "prou bo" i revisat supera un de perfecte que mai s'acaba.
• Convertir-lo en un document mort. Si el model no es revisa quan canvia el disseny, caduca. Vincula'l al procés (pregunta 4) i guarda'l versionat al costat del codi.
• Fer-lo en solitari. El valor és a la conversa entre desenvolupament, seguretat i producte. Sense l'equip, es perd el coneixement del sistema real.
• Consell: comença petit. Un DFD en pissarra d'una hora sobre el flux més crític aporta més que un curs teòric. L'habilitat es desenvolupa modelant.

Exercici 1. Al DFD del checkout, un desenvolupador proposa que el frontend enviï el preu total ja calculat "per estalviar una consulta". Identifica la categoria STRIDE del risc i la mitigació correcta.

Exercici 2. Classifica cada amenaça amb la lletra STRIDE adequada: (a) un atacant repeteix un webhook de pagament capturat, (b) un usuari canvia l'order_id de la URL i veu la comanda d'un altre, (c) el log no registra qui va cancel·lar una comanda.

Exercici 3. BazarNube afegirà "iniciar sessió amb Google". Dibuixa mentalment el nou flux i indica un nou límit de confiança i una amenaça STRIDE que apareix amb aquesta integració.

Solució 1. És Tampering (manipulació d'integritat): confiar en un preu enviat pel client permet alterar-lo en trànsit o des del navegador i comprar per menys. La mitigació és no confiar mai en dades del client per a decisions de diners: el servidor recalcula el preu des del catàleg autoritzat. Relaciona amb A04 (Disseny Insegur) i ASVS V5 (validació).

Solució 2.

• (a) Tampering i/o Spoofing (webhook de replay/falsificat); es mitiga amb signatura HMAC i control anti-replay (nonce/timestamp).
• (b) Elevation of privilege / control d'accés trencat (IDOR); autorització per objecte.
• (c) Repudiation; registre íntegre amb identitat i marca temporal.

Solució 3. Apareix un nou límit de confiança amb el proveïdor d'identitat extern (Google) i el flux OAuth/OIDC que travessa a un tercer. Una amenaça típica és Spoofing: acceptar un token d'identitat no validat correctament (signatura, audiència, emissor, expiració) permetria suplantar un usuari. Es mitiga validant el token segons l'estàndard OIDC i lligant el compte local de forma segura. Relaciona amb A07 i ASVS V2/V3.

El modelatge d'amenaces és la pràctica que dona contingut a la fase de disseny de l'S-SDLC: amb un DFD i els seus límits de confiança responem "què construïm", amb STRIDE "què pot sortir malament", amb mitigacions enllaçades al Top Ten i ASVS "què fem", i amb la revisió "ho vam fer bé". A BazarNube hem convertit un flux de checkout en una llista prioritzada de requisits verificables. Però un bon disseny només se sosté si la resta del procés el respecta de forma automàtica i contínua. A la lliçó següent, 07-03, portem aquestes mitigacions al terreny de l'automatització: com DevSecOps converteix aquests controls en comprovacions que el pipeline executa a cada canvi.