La modellazione delle minacce è davvero un'abilità, basata sull'esperienza, dopo aver appreso cosa funziona e cosa no.
Non penso che una scelta di framework renderà le cose molto più facili per te, avrai ancora gli stessi problemi e le stesse difficoltà che hai ora.
Al contrario, consiglierei STRIDE-per-element come il posto migliore per iniziare, e in seguito aggiungeremo ulteriori tecniche appropriate.
Probabilmente è più probabile che tu abbia solo bisogno di alcuni indicatori su come per fare la modellazione delle minacce in modo efficiente, semplicemente cambiare la metodologia non sarebbe il tuo punto debole.
I miei consigli:
- Passare attraverso un'intera minaccia modellando l'esercizio prima con qualcuno esperto, che sa come farlo - questo è davvero il modo migliore per imparare, facendo. Anche se questo significa ottenere un consulente esterno per alcune ore.
- Uno dei motivi per cui i DFD sono consigliati, è perché spesso esistono già. Prova a scoprire se qualcuno ha questi, o anche qualcosa di simile.
- Un altro motivo per i DFD è perché possono essere relativamente semplici. Se dici di rimanere bloccato sulle minuzie, riduci lo zoom e mantieni il DFD al livello 0 o al livello 1, scavando solo occasionalmente nel livello 2 secondo necessità, ma non di più.
- Ricorda che vuoi concentrarti sulla panoramica di alto livello, sui flussi tra i moduli e oltre i limiti di affidabilità. Non dovresti mai dover approfondire l'implementazione (anche se coinvolgere sviluppatori / architetti che capiscono come funziona, puoi aiutarti a scoprire punti interessanti che richiedono mappature aggiuntive.) Non lasciarti trasportare dai dettagli!
- Microsoft ha due diversi strumenti per aiutare con Threat Modeling, TAM e SDL TM. Questi sono basati su diversi punti di vista e sotto-metodologie, uno di loro funziona come un'app "mago" -come-like. Preferisco di gran lunga SDL TM.
- Considera di focalizzare una TM su un modulo / sezione dell'applicazione alla volta, invece di provare ad afferrarla tutta in una volta.
- Ricorda che durante TM non stai cercando soluzioni. Ciò può rapidamente sviare qualsiasi sforzo TM.
- Idealmente, avresti i punti di vista e gli input da tutte le parti interessate (architettura / gestione del prodotto / sviluppo / controllo qualità / operazioni ...), ma realisticamente, in molte organizzazioni che non è possibile, invece, cerca di focalizzare le piccole morsi di tempo con i rappresentanti di ciascuno e porre domande specifiche che contribuiranno a dare forma al tuo modello. Se non ci fosse DFD o altro diagramma, e lo hai creato tu stesso - ottieni il loro feedback, spesso ti ringraziano solo per averlo fornito.
Alcune riflessioni aggiuntive su TM, come per le tue domande extra alla fine:
Indirizzare semplicemente uno scanner di app Web appropriato ai tuoi server sarà più facile . Tuttavia, ritengo che la TM sarebbe molto più efficace e, a lungo termine, sarebbe anche più efficiente (per numerose ragioni, tuttavia, un tema diverso).
Anche se l'app esiste già, vale ancora la pena di tornare indietro e analizzarla - alcune cose saranno più facili (meno congetture), alcune cose potrebbero non essere risolte, ma puoi scoprire quali tipi di difetti sono interessanti . Questo è ciò che può aiutarti a tornare indietro e risolvere problemi specifici, non solo i dettagli tecnici che non si applicano alla tua attività. E, nel peggiore dei casi, tutto ciò che farà è aiutarti a concentrare i tuoi sforzi di test in aree più "interessanti", invece di testare l'intero sistema.
Alcuni link che ho trovato utili in passato quando insegnavo agli altri come fare TM: