• Home
• Projects
• Whitepapers
• Events and conferences
• Advisories
• About

Web Applications Threat Modelling per un Pen Testing strutturato

Copyright (C) 2007 Antonio "s4tan" Parata <s4tan@ictsc.it>

   Ultimo aggiornamento: 18/03/2007

In questo articolo vedremo come creare un Threat Model per applicazioni web, che permetta di effettuare sessioni di penetration testing ben strutturate.

1. Introduzione
2. Introduzione al Threat Modelling
3. Identificazione del target di analisi
4. Identificazione dei livelli di fiducia
5. Identificare gli Entry Point
6. Identificare gli Assets da proteggere
7. Creare un diagramma ad alto livello dell'applicazione
8. Identificazione delle minacce
9. Identificazione delle vulnerabilita'
10. Conclusioni
11. Riferimenti

1. Introduzione

Il Threat Model non e' altro che un documento creato dall'attivita' di Threat Modelling. All'interno del Threat Model e' presente (tra le altre cose) una lista delle minacce (ing. Threats) identificate. Tale lista prende il nome di Threat Profile.

Perche' creare un Threat Model?
Come vedremo a breve, il threat model e' utile per guidare la maggior parte delle attivita', il cui compito e' quello di aumentare il livello di sicurezza della mia applicazione (si pensi ad esempio alle attivita' di security testing o di code review, oppure al fatto che permetta di poter quantificare se l'applicazione sta' migliorando o peggiorando in termini di sicurezza). Noi ci soffermeremo in particolare sulla creazione del Threat Model come documento guida per l'attivita' di penetration test.
In genere l'attivita' di penetration test e' svolta nel seguente modo, dopo una prima fase di "profiling" dell'applicazione, si passa alla ricerca di vulnerabilita', senza tener conto di una qualsiasi struttura. In pratica, si procede alla cieca nella ricerca di vulnerabilita'. Cio' comporta alcuni svantaggi, tra cui:

• Puo' capitare di concentrarsi su bug poco importanti, ovvero i cosi detti Low-Hanging Fruit (a tal proposito si veda [1]), i quali sono i bug generalmente identificati dagli scanner automatici di vulnerability assessment (per una valutazione sull'effettiva utilita' di tali strumenti si consiglia la lettura di [2]). Si pensi, ad esempio, ad un tester che impiega la maggior parte del suo tempo nel cercare di "exploitare" un bug da XSS, magari tralasciando il fatto che il meccanismo di autenticazione possegga delle falle di sicurezza ben piu' gravi.


• Una volta eseguito il penetration test, non si ha un documento che dimostri quali componenti non sono stati esaminati. In questo modo, in un successivo pen testing, verra' perso tempo ad effettuare test magari gia' fatti.

Il Threat Model, permette di eliminare questi (ed altri) inconvenienti, fornendo una guida strutturata al tester, e permettendo (in caso di non completazione dell'attivita' di pen testing), di avere un'eventuale lista di test che non sono stati effettuati (con il vantaggio che tali test sono quelli con priorita' minore).

Quando inizia e quando finisce l'attivita' di Threat Modelling?
L'attivita' di Threat Modelling e' la prima attivita' che dovra' essere intrapresa in caso di utilizzo all'interno di un penetration test. Per quanto riguarda la sua conclusione il discorso e' un po' piu' complicato. Non esiste un momento preciso in cui finisce, sicuramente la fase di stesura iniziale del Threat Model e' la fase piu' corposa. Quando si raggiunge un punto in cui si crede di aver modellato a sufficienza il Threat Model di puo' passare alla fase vera' e' propria di penetration test. Durante il testing dell'applicazione quasi sicuramente capitera' di accorgersi di aver tralasciato qualcosa all'interno del documento di Threat Model, questo e' un buon momento per riprenderlo in mano, aggiornarlo e rianalizzarlo alla luce delle nuove scoperte effettuate.

Thret Modelling o Risk Assessment?
Purtroppo in letteratura la definizione di Threat Modelling non e' univoca (si guardi ad esempio [2] e [4]). Possiamo identificare come Threat Modelling la sola identificazione delle minacce. Ma spesso una volta identificate le minacce, ci si ritrova in una condizione in cui e' necessario soltanto un piccolo sforzo aggiuntivo in piu' per poterne valutare il rischio associato. Ecco dunque che spesso i due termini vengono usati come sinonimi. Questo articolo non si prefigge lo scopo di dare una netta separazione dei due termini, ci limiteremo a seguire la definizione data in [4], per giusta o sbagliata che sia.
Indice

2. Introduzione al Threat Modelling

Andremo ora a descrivere quali sono le attivita' o fasi, da svolgere per creare un Threat Model. Tra i primi libri (se non il primo) a descrivere un processo per la creazione del Threat Model e' [3]. Nel nostro caso, comunque, prenderemo come modello le fasi suggerite in [4], e faremo le opportune modifiche dove necessario. Prima pero' e' necessario una definizione dei vari termini che utilizzeremo all'interno di questo articolo:

• Threat: per noi una minaccia non e' altro che il raggiungimento di uno scopo da parte di un attaccante. Un esempio di minaccia potrebbe ad esempio essere "Riuscire ad autenticarsi come un altro utente."


• Vulnerability: una vulnerabilita' non e' altro che un bug presente all'interno dell'applicazione che pemette ad una mincaccia di realizzarsi.


• Risk: il concetto di rischio e' a stretto contatto con la valutazione di una vulnerabilita'. Il rischio e' una caratterizzazione di una vulnerabilita'. In seguito accenneremo a diversi modelli per la valutazione del rischio (inteso come vulnerabilita' associata ad una minaccia).

Questi sono fondamentalmente i termini che causano maggiori problemi nelle varie definizioni, ulteriori termini verranno a galla durante la discussione, ma il loro significato e' univoco.

Infine sottolineamo il fatto che l'attivita' di Threat Modelling dovra' essere eseguita guardando l'applicazione da un punto di vista applicativo (ing. Application-level Threat modelling), ovvero come nei piu' puri penetration test di tipo black box, considereremo l'applicazione dall'esterno, raggiungibile soltatnto attraverso la rete e non considerando particolari aspetti implementativi interni. In questo modo si riesce ad impersonificare meglio il punto di vista di un attaccante. Passiamo ora alla descrizione delle varie fasi.
Indice

3. Identificazione del target di analisi

Identificare il Target di analisi e' di fondamentale importanza. Serve al tester per specificare i limiti dell'attivita' di Threat Modelling. In questo modo, si evita di ritrovarsi in situazioni di ambiguita' con il cliente. Se ad esempio non decidete di includere come target l'analisi di vulnerabilita' del web server, avrete un buon motivo per evitare che il vostro cliente vi faccia causa nel caso in cui degli attaccanti fossero penetrati nel suo sistema proprio attraverso un bug presente nel web server.
Indice

4. Identificazione dei livelli di fiducia

I Livelli di fiducia dell'applicazione sono concetti molto semplici. In pratica identifico i ruoli all'interno dell'applicazione. Ad ogni ruolo andro' ad associargli un identificativo univoco e una breve descrizione. I livelli di fiducia servono per meglio identificare le minacce e per fornire una migliore valutazione del rischio associato. Un semplice esempio di elenco di livelli di fiducia e' il seguente:

Nella nostra classificazione non abbiamo distinto sul fatto che un livello di fiducia puo' essere piu' o meno restrittivo. Se volessimo implementare questa caratteristica potremmo identificare i livelli di fiducia secondo una numerazione di tipo gerarchico (cosa molto utile nell'identificazione degli entry point come vedremo in seguito). Il vantaggio che deriva dall'avere una classificazione basata appunto sul livello di diritto, tornera' utile in seguito nel caso in cui i livelli di fiducia siano in numero elevato. Una tabella che adotta questa tipologia di identificazione e' la seguente:

dove si e' sottolineato il fatto che i diritti di un utente remoto autenticato sono minori di quelli dell'aministratore del sito web, ma maggiori di quelli di un utente remoto anonimo. In questo modo possiamo indicare nelle successive tabelle soltanto gli utenti con livello di fiducia minore, sapendo che sono comunque anche presenti tutti i livelli di fiducia con diritti maggiori.
Indice

5. Identificare gli Entry Point

Tra le prime fasi da intraprendere nell'attivita' di Threat Modelling vi e' l'identificazione degli Entry Points dell'applicazione. Per dirla breve gli Entry Points sono i punti di ingresso con cui interagire con l'applicazione. Pensando dal punto di vista dell'attaccante i vari entry point non sono altro che i parametri passati e tutti i vari campi del protocollo HTTP. Qualcuno potrebbe obiettare sul fatto che anche ulteriori porte aperte sul web server rappresentino degli entry points. Cio' e' vero, il tutto sta' nel definire quali sono i limiti che ci si e' posti nella creazione del Threat Model. Ecco perche' abbiamo sottolineato l'importanza dell'identificazione del target.

Pur essendo questo un articolo teorico, non dobbiamo tralasciare l'aspetto pratico. L'identificazione di tutti gli entry points, puo' essere un'operazione decisamente tediosa (dipende dalla dimensione dell'applicazione). Per fortuna ci vengono in aiuto la presenza di svariati strumenti di spidering e web crawling (cercate queste parole sul vostro motore di ricerca preferito). Tramite il loro utilizzo e' possibile ottenere automaticamante la maggior parte degli entry points dell'applicazione (prestate comunque attenzione, questi strumenti non sono del tutto affidabili e potrebbero mancare qualche entry point fondamentale, per cui ricontrollate il tutto una volta finito lo scanning).
Un'altro consiglio e' quello di elencare gli entry points secondo uno schema gerarchico, cio' e' possibile soltanto assegnando ad ogni entry point un identificativo. Facciamo un esempio, supponiamo di avere una pagina chiamata home.php. Da questa e' possibile autenticarsi presso l'applicazione (i dati dell'utente e l'autenticazione vengono fatti sempre da home.php, non e' il massimo del design ma va bene per il nostro esempio), inoltre sempre home.php permette di visualizzare degli articoli passandogli come input un identificativo. A questo punto ho due diversi entry points, uno per il login e uno per la visualizzazione dei prodotti. Questi entry points possono essere classificati utilizzando la seguente numerazione:

In questo modo potremmo associare in modo facile i vari entry points alle minacce che andremo ad identificare. Inoltre la numerazione di tipo strutturato permette di identificare facilmente quali sono le funzionalita' esposte da un pagina web. Si noti come per ogni entry point sia anche stato definito il relativo livello di fiducia, ovvero esso rappresenta il livello di fiducia necessario per poter accedere ad un dato entry point. Volendo avremmo potuto inserire soltanto il livello di fiducia di un utente remoto anonimo, nel caso avessimo utilizzato una numerazione dei livelli di fiducia di tipo gerarchico. Gli entry points (e il livello di fiducia associato) sono necessari per poter in seguito meglio identificare le minacce e le relative vulnerabilita'.
Indice

6. Identificare gli Assets da proteggere

Identificare gli assets da proteggere e' un'altra operazione di fondamentale importanza. Ogni minaccia e' rivolta ad un particolare asset, senza asset da proteggere non esistono minacce. Gli assets possono essere di vario tipo, i primi a venire in mente sono quelli di tipo concreto (perche' i piu' facili da identificare), come ad esempio le credenziali degli utenti, i loro dati personali, o le loro carte di credito. Altrettanto importanti sono gli assets di tipo astratto, ovvero degli asset che non sono concretamente identificabili, ma rappresentano comunque un bene da proteggere per l'azienda. Un tipico esempio di asset astratto e' la credibilita' dell'azienda, si pensi ad esempio all'inpatto che si otterebbe se si venisse a sapere che tutte le carte di credito dei miei clienti sono state trafugate.

Gli assets possono essere elencati all'interno di una tabella e corredati da ulteriori informazioni. Cosi' come fatto per gli entry points, anche per gli assets specificheremo il livello di fiducia che deve essere necessario per poter avere accesso all'asset.
Introduciamo anche una colonna relativa ad una valutazione di tipo qualitativo dell'asset, ad esempio e' sufficiente una valutazione a tre valori: High (H), Medium (M) e Low (L). In questo modo riuschiremo ad identificare in modo piu' preciso la pericolosita' delle varie minacce associate.
Un tipico esempio di tabella e' proposto di seguito (supponiamo di analizzare un sito di e-commerce):

Identificare tutti gli assets non e' un compito semplice. Per ottenere un elenco completo si puo' contare sull'aiuto dei dipendenti dell'azienda.
Indice

7. Creare un diagramma ad alto livello dell'applicazione

In questa fase viene creato un diagramma ad alto livello dell'applicazione. La sua creazione sara' utile in futuro per identificare piu' facilmente le minacce. Il tester tenendo sott'occhio gli assets da proteggere e il seguente diagramma, andra' alla ricerca delle minacce. In questa sezione presenteremo comunque una metodologia che si discosta leggermente da quanto consigliato nei vari articoli sul threat modelling. In [3] e [4] vengono suggeriti i Data Flow Diagrams (DFD) come strumento di modellazione dell'applicazione. I DFD sono molto utili nel caso il Threat Model venga creato secondo una vista Feature-Level, ovvero si crea il Threat Model concentrandosi sulle varie funzionalita' dell'applicazione. Rispetto a quanto da noi fatto, il feature-level Threat Modelling e' un'attivita' di tipo verticale (ci si concentra su una singola funzionalita' dell'applicazione), mentre l'application-level Threat Modelling (quello da noi adottato) e' di tipo orizzontale (ci si concentra sulla totalita' dell'applicazione). A causa della natura black box dell'attivita' di pen testing, non si hanno ha disposizione sufficienti informazioni per creare un DFD che sia di una minima utilita'.
Ecco perche' in questo caso consiglio di utilizzare una Mappa di Navigazione (ing. Navigation Map, per ulteriori informazioni si guardi [5]). Un esempio di mappa di navigazione e' mostrata di seguito (immagine di esempio presa da google):



Una mappa di navigazione permette di creare una mappa che esprime in che modo ci si dovrebbe "muovere" all'interno dell'applicazione, per chi mastica un po' di UML, assomiglia molto ad un diagramma di flusso (ing. flowchart).
I nomi dei vari nodi dovrebbero essere i nomi del file fisici, il loro titolo, oppure un nome significativo. Nel caso in cui il sito risultasse di dimensioni sostenute, conviene scomporre la mappa di navigazione in piu' parti a seconda ad esempio dei casi d'uso. Un'ulteriore miglioria e' quella di includere nei vari link anche eventuali parametri passati all'url o informazioni rilevanti (ad esempio particolare campi HTTP, hidden parameters, cookie, etc...).

La mappa di navigazione non ha lo scopo di dimostrare che il tester ha una buona conoscenza del linguaggio di modellazione UML, ma di fornire un aiuto al tester. Per cui non e' necessario creare un diagramma perfettamente corretto, optate meglio per un diagramma abozzato, che non vi fossilizzi su tale processo di modellazione ma che vi possa essere di aiuto.
Indice

8. Identificazione delle minacce

Siamo finalmente arrivati alla fase principale dell'attivita' di Threat Modelling. L'identificazione delle minacce e' sicuramente la fase piu' difficile di tutto il processo. Arrivati a questo punto abbiamo tutto cio' che ci serve per identificare le minacce. Cosi' come nell'identificazione degli assets anche in questa fase dovremmo far affidamento anche sull'aiuto dei nostri committenti (o sui loro dipendenti) per riuscire ad identificare tutte le minacce possibili. E' di fondamentale importanza che tutte le minacce siano correttamente identificate. Cio' e' importante perche' in seguito andremo ad effettuare i nostri test in base alle minacce identificate. Non solo tutte le minacce devono essre correttamente identificate, ma devono essere identificate il prima possibile. Supponiamo ad esempio di mancarne una e di cominciare a testare la nostra applicazione. Siamo quasi arrivati alla fine del nostro lavoro, quando ci accorgiamo di aver dimenticato di includere nel Threat Profile una minaccia con alta priorita'. Se siamo fortunati, potremo includerla e testarla il prima possibile, ma se il nostro lavoro e quasi al termine, potremmo non avere il tempo necessario ad effettuare il testing, lasciando l'applicazione in uno stato in cui, nonostante i test effettuati e' ancora altamente insicura.
Per cui la parola d'ordine in questa fase del threat modelling e':

Identificare tutte le minacce, e identificarle il prima possibile.

Come sempre andremo ad elencare le minacce con le relative informazioni in un'opportuna tabella. Cosi' come fatto con gli assets, andremo a fornire, per ogni minaccia, una valutazione qualitativa (ad esempio High (H), Medium (M) e Low (L)). Per stimare la priorita' di una miaccia non esistono al momento modelli consolidati (si tenga presenta che i vari modelli come DREAD e compagnia bella servono a valutare il rischio di una vulnerabilita' associata ad una specifica minaccia). Per toglierci dagli impicci, potremmo classificare ogni minaccia con la stessa importanza data al relativo asset associato. Inoltre per comodita' future inseriremo anche un campo che ci indichera' se tale minaccia e' stata testata (e con che esito) oppure no. Vediamo un esempio di tale tabella:

La verifica della minaccia andra' fatta in seguito. Inoltre la descrizione della minaccia puo' essere ricavato o chiedendo informazioni al proprio committente, oppure da una rapida sessione di profiling dell'applicazione. Considerando ad esempio la minaccia T.1, pur non sapendo nulla, possiamo intuire che le query vengono fatte tramite concatenzaione di stringhe, ad esempio perche' da alcuni veloci test abbiamo notato degli errori inserendo il carattere '.

Per quanto riguarda la voce Minacce collegate essa si riferisce ad eventuali collegamenti con altre minacce elencate. Vedremo piu' avanti un esempio. Un'altra nota e' la presenza della voce attack tree. Gli attack tree sono un formalismo espressi per la prima vosta da Bruce Schneier in [6], per ulteriori informazioni sugli attack tree si guardi [7]. Gli attack tree (anche detti threat tree) possono essere visualizzati in forma grafica o in forma testuale. Essi descrivono quali sono i passaggi che possono portare alla realizzazione di una minaccia. Essi non verranno descritti in questo articolo, ma daremo soltanto alcuni suggerimento per un loro proficuo uso. In particolare:

• Create un attack tree solo se pensate che possa esservi veramente utile.
• Non fossilizzatevi sulla loro creazione, limitatevi a creare cio' che secondo voi potra' in seguito tornarvi utile sapere.
• Inizialmente evitate di marcate i nodi come mitigati, ogni nodo dovrebbe essere testato prima di essere marcato come mitigato o impossibile. Il fatto di marcare un nodo come mitigato, permette di decidere in che modo percorrere l'albero. Se ho due nodi, e uno dei due e' marcato come mitigato, e' inutile che lo analizzi, mi concentrero' meglio sul nodo non mitigato.

Per completezza vediamo un'ulteriore esempio di minaccia che utilizza gli attack tree in formato testuale:

  L'attaccante acquisisce le credenziali dell'utente
   AND 1 L'attaccante ottiene un username valido
         OR 1.1 Minaccia T.1
            1.2 L'attaccante utilizza gli errori riportati dall'applicazione per enumerare gli username
       2 L'attaccante ottiene una password valida
         OR 2.1 Minaccia T.1
            2.2 L'attaccante utilizza gli errori riportati dall'applicazione per enumerare le password
            2.3 L'attaccante esegue un attacco di brute force
            2.4 L'attaccante esegue un attacco basato su dizionario

Nella descrizione testuale ogni nodo e' identificato da un numero di sequenza. La parola AND significa che tutte le azioni dello stesso livello devono essere svolte. La parola OR significa che almeno uno delle azioni delle stesso livello deve essere svolta. Riassumiamo il concetto degli attack tree come una possibile guida di come andranno identificate le vulnerabilita'.

Facciamo notare come la definizione delle minacce puo' essere di tipo tecnico oppure piu' legata all'asset. Ad esempio la minaccia T.1 e' di tipo tecnico, infatti interessa piu' assets contemporaneamente, mentre la minaccia T.2 e' piu' indirizzata all'asset, infatti comprende un solo asset. In genere (ma non prendetela come regola) l'utilizzo degli attack tree e' piu' utile nella definizione delle minacce Assets-Related.
Indice

9. Identificazione delle vulnerabilita'

Questa e' la fase piu' divertente, nonche' tra le piu' complicate (seconda solo all'identificazione delle minacce). Arrivati a questo punto non rimane altro che identificare le possibili vulnerabilita' della nostra applicazione. Dal nostro punto di vista identificare le vulnerabilita' in modo teorico guardando soltanto cio' che e' stato fino ad ora prodotto, e' impossibile. Per cui e' ora di sporcarsi le mani sull'applicazione ed iniziare la tanto agognata sessione di penetration test. La scoperta delle vulnerabilita' dipende fortemente dal livello tecnico del tester, e spesso e' meglio affidarsi a professionisti del settore.

L'dentificazione delle vulnerabilita' deve avvenire secondo un preciso ordine. Per prima si analizzano le minacce ad impatto maggiore. Scelta la minaccia da analizzare si comincia ad esaminare le possibili vulnerabilita', se e' presente un attack tree esso puo' tornare utile in questo momento. A differenza delle minacce, per le vulnerabilita' non e' strettamente necessario identificarle tutte immediatamente (si intende vulnerabilita' relative ad una stessa minaccia). Se durante l'analisi di una minaccia vi rendete conto che esiste un'ulteriore possibile vulnerabilita', dovrete per prima cosa aggiornare le informazioni relative alla minaccia (ad esempio l'eventuale attack tree) e in seguito procedere (appena possibile) al testing della vulnerabilita'. Da qui si intuisce il motivo del perche' non e' strettamente fondamentale trovare tutte le vulnerabilita' subito, infatti l'importante e' non mancare di identificare la minaccia, una volta che e' stata identificata e valutata, si puo' agire con piu' serenita', ed eventualmente aggiornarla durante il processo di penetration test.
Come sempre per ogni vulnerabilita' trovata verranno registrate particolari informazioni in una tabella. Un esempio di possibile tabella di vulnerabilita' e' la seguente:

All'interno della descrizione e' eventualmente possibile inserire riferimenti ad ulteriori risorse. Da notare come la valutazione del rischio sia specifica rispetto ad un dato modello (nel nostro esempio abbiamo usato il modello DREAD, per ulteriori modelli vedere [8], [9] e [10]), e' dunque necessario specificare relativamente a quale modello il rischio e' calcolato. Si noti inoltre come per la valutazione del rischio esistono svariati modelli, mentre non esistono modelli consolidati per la valutazione delle minacce o degli assets.
Infine, una volta che la vulnerabilita' e' stata risolta possiamo aggiornare le relative informazioni (come cambiare il valore del campo Mitigata).
Indice

10. Conclusioni

In questo articolo e' stato preso in esame il processo di Threat Modelling (per ulteriori informazioni vedere [11], [12], [13], [14], [15] e [16]) dal punto di vista di un tester che sta' per eseguire una sessione di penetration test.
Nelle fasi iniziali e' necessario identificare quali sono gli Entry Points, i vari Assets da proteggere e la creazione di una Mappa di navigazione. Prendendo in esame questi tre documenti si procede con l'identificazione di tutte le possibili minacce e ad una loro valutazione. Nel passo finale il tester puo' mettersi all'opera e cominciare la sessione di penetration test, basandosi sulle minacce identificate. Per ogni vulnerabilita' scoperta andra' a riempire la relativa riga all'interno della tabella delle vulnerabilita'. La scoperta delle vulnerabilita' sara' guidata dall'ordinamento delle varie minacce.
In questo articolo e' stata presentata la teoria del threat modelling, in un successivo articolo vedremo un esempio concreto dell'applicazione di quanto appena detto.

Concludiamo, sottolineando nuovamente l'importanza di eseguire un'attivita' di penetration testing di tipo strutturato che sia guidato dal rischio, rispetto ad un processo di testing casuale.
Indice

11. Riferimenti

1. Jeremiah Grossman. Low-Hanging Fruit, Non-Sense
2. Gary McGraw. Software Security - Bulding Security In. 2006
3. Michael Howard, Deavid LeBlanc. Writing Secure Code, 2nd Edition. 2003
4. Frank Swiderski, Window Snyder. Threat Modelling. 2004
5. Jim Conallen. Building Web Applications with UML (2nd Edition). 2003
6. Bruce Schneier. Secrets and Lies: Digital Security in a Networked World. 2003
7. Robert J. Ellison. Attack Trees. 2006.
8. (OWASP) OWASP Testing Guide. AoC 2006.
9. Microfost. Microsoft Security Response Center Security Bulletin Severity Rating System. 2002
10. Dana Epp. Secure Software Programming: DREAD is Dead.
11. J.D. Mayer et al. Improving Web Application Security: Threats and Countermeasures. 2003
12. J.D. Meyer et al. At a Glance Web Application Threat Modeling. 2005
13. J.D. Meyer et al. How To Create a Threat Model for a Web Application at Design Time. 2005
14. J.D. Meyer et al. Threat Modeling Web Applications. 2005
15. J.D. Meyer et al. Cheat Sheet Web Application Security Frame. 2005
16. J.D. Meyer et al. Walkthrough Creating a Threat Model for a Web Application. 2005

Indice