la modellazione delle minacce sarebbe sicuramente di aiuto nel determinare i casi di test e dove usare il fuzz, ma la mia domanda è specifica per la scansione del codice. La modellizzazione delle minacce sarebbe di aiuto nella messa a fuoco / priorità o in qualsiasi modo l'analisi del codice statico?
In breve, sì lo farebbe. Ma potresti anche utilizzare un approccio di triage semplice se la modellizzazione delle minacce è eccessiva.
In dettaglio -
L'analisi del codice può essere un'attività che richiede tempo. Anche gli approcci di comando degli strumenti genereranno grandi quantità di output che richiederanno una revisione e una definizione delle priorità umane. Poiché tale approccio alla modellazione delle minacce può aiutare a identificare e triageare tale sforzo. Ciò diventa particolarmente importante nelle revisioni di codice di grandi dimensioni.
Da un punto di vista della modellazione delle minacce vorrei suddividere il codice nelle seguenti aree (in ordine di importanza):
Questo ti darà un approccio prioritario alla revisione del codice e una struttura per assegnare il livello appropriato di rischio a ogni scoperta, ad esempio: un difetto all'interno del codice che gestisce l'input dell'utente da uno spazio non autenticato potrebbe essere visto per presentare una priorità più alta per risolvere quello dello stesso tipo di problema all'interno di un'area limitata e affidabile dell'applicazione.
Come richiesto, questo è ora combinato con la risposta di @ this.josh (questa è una versione modificata, leggi @ this.josh rispondi per il testo completo, vale la pena leggerlo)
Se stai cercando di svolgere un lavoro più approfondito, devi considerare l'esposizione:
Alcuni codici vengono eseguiti più spesso?
Il codice è più facile da trasferire dati in?
Alcuni codici sono più facili da eseguire per il debug per vedere gli effetti di?
A quali risorse si accede dal codice?
Cos'è il codice che protegge? (le risorse)
Quale codice si basa sull'hardware per la protezione?
Quale codice si basa su un altro codice per proteggerlo? (qual è il tuo modello di protezione?)
Quale codice fornisce tolleranza agli errori o ripristino degli errori?
Considerare le minacce, le esposizioni, le risorse e il modello di protezione ti aiuteranno a fare una buona scelta su cosa testare e come testarlo.
Decisamente forse.
I metodi e le tecniche hanno valore quando ti aiutano a svolgere un compito in modo più completo o con meno risorse di un altro approccio.
Quindi stai cercando di fare il lavoro in modo completo o più efficiente?
La modellazione delle minacce può aiutarti a individuare casi di test che anticipano un attacco pratico e ignorano i casi di test, e quindi il codice, che una minaccia non tenterebbe (o non potrebbe) tentare di sfruttare. Questo in contrasto con l'input fuzzing per la maggior parte o tutto il codice accessibile. Ovviamente non ha molto senso controllare il codice a cui un utente malintenzionato non può accedere.
Se stai cercando di svolgere un lavoro più approfondito, devi considerare l'esposizione:
Alcuni codici vengono eseguiti più spesso?
Il codice è più facile da trasferire dati in?
Alcuni codici sono più facili da eseguire per il debug per vedere gli effetti di?
Quindi, come nota @David Stubley, è necessario considerare il valore del codice e ciò che il codice protegge o fornisce l'accesso a.
Quali risorse sono accessibili dal codice?
Cos'è il codice che protegge? (le risorse)
Quale codice si basa sull'hardware per la protezione?
Quale codice si basa su un altro codice per proteggerlo? (qual è il tuo modello di protezione?)
Quale codice fornisce tolleranza di errore o ripristino di errore?
Considerare minacce, esposizioni, risorse e il modello di protezione ti aiutano a fare buone scelte su cosa testare e come testarlo.
this.josh's part
Decisamente forse.
I metodi e le tecniche hanno valore quando ti aiutano a svolgere un compito in modo più completo o con meno risorse di un altro approccio.
Quindi stai cercando di fare il lavoro in modo completo o più efficiente?
La modellazione delle minacce può aiutarti a individuare casi di test che anticipano un attacco pratico e ignorano i casi di test, e quindi il codice, che una minaccia non tenterebbe (o non potrebbe) tentare di sfruttare. Questo in contrasto con l'input fuzzing per la maggior parte o tutto il codice accessibile. Ovviamente non ha molto senso controllare il codice a cui un utente malintenzionato non può accedere.
Se stai cercando di svolgere un lavoro più approfondito, devi considerare l'esposizione:
Alcuni codici vengono eseguiti più spesso?
Il codice è più facile da trasferire dati in?
Alcuni codici sono più facili da eseguire per il debug per vedere gli effetti di?
Quindi, come nota @David Stubley, è necessario considerare il valore del codice e ciò che il codice protegge o fornisce l'accesso a.
Quali risorse sono accessibili dal codice?
Cos'è il codice che protegge? (le risorse)
Quale codice si basa sull'hardware per la protezione?
Quale codice si basa su un altro codice per proteggerlo? (qual è il tuo modello di protezione?)
Quale codice fornisce tolleranza di errore o ripristino di errore?
Considerare le minacce, le esposizioni, le risorse e il modello di protezione ti aiuteranno a fare una buona scelta su cosa testare e come testarlo.
Leggi altre domande sui tag threat-modeling vulnerability-scanners