Durante la modellazione delle minacce, dovresti includere le minacce che un sistema non può mitigare?
Se sì, dove dovresti smettere? Potrebbe essere molto dispendioso in termini di tempo elencare tutte le minacce che non è possibile mitigare.
Durante la modellazione delle minacce, dovresti includere le minacce che un sistema non può mitigare?
Se sì, dove dovresti smettere? Potrebbe essere molto dispendioso in termini di tempo elencare tutte le minacce che non è possibile mitigare.
Dipende dal motivo per cui non puoi mitigarli e da cosa potresti ottenere scrivendoli. Certamente vuoi trovare le categorie, piuttosto che elencare le singole minacce.
Ad esempio, potrebbe non essere possibile difendersi da root. Se continua a salire, annotalo e vai avanti puntandolo quando viene rilevata la prossima variazione. Scriverlo è utile perché ti permette di uscire da ratholes. Vuoi scrivere la categoria ("Root wins" vs "1. root può cambiare questo file di configurazione; 2. root può fermare questo processo ...")
Può darsi che tu abbia una manciata di minacce perché sei dipendente da alcuni rev di (diciamo) Ubuntu che include molta superficie di attacco, nel qual caso scrivendolo potrebbe aiutare qualcuno che può autorizzare a spostarsi Ubuntu ad una distribuzione più piccola.
Un elenco di minacce che non è possibile indirizzare può essere utile come parte della documentazione sulla sicurezza (MSFT lo fa con "10 leggi di sicurezza immutabili") per gestire le relazioni con i clienti e i rilevatori di bug.
Mentre penso che Jonah B abbia trattato bene le cose. Solo per essere più diretto.
Direi "Sì", certamente.
I rischi che non puoi mitigare sono importanti quanto altri rischi.
Il rischio residuo è la misura importante. Questo è il rischio che rimane dopo attenuazione. Prendi in considerazione tutti i rischi residui quando risolvi il rischio complessivo. In assenza di attenuazione, il rischio residuo è uguale al rischio iniziale.
Quindi, come dice Jonah, è necessario avere una discussione aperta all'interno dell'organizzazione sui rischi residui e su ciò che significano per il business. Devi anche capire la propensione al rischio . Quanto rischio vuole l'organizzazione trasportare? Ciò richiede che tutti i rischi organizzativi siano gestiti in modo olistico, naturalmente.
UPDATE: dove dovresti smettere? Quando i rischi sono irrilevanti.
Questo dipende anche da chi stai facendo la modellazione. Le persone senior e di livello C vorranno solo gli articoli di grandi dimensioni che influenzano l'azienda nel suo complesso. I Project Manager vogliono tutto ciò che potrebbe influire sulla consegna dei progetti. I service manager vogliono dei rischi che avranno un impatto sulla live running, sugli SLA ecc.
Se stai modellando una modifica del sistema che migliorerà la bottom line delle organizzazioni di $ 2 milioni all'anno, potresti essere interessato a rischi che potrebbero avere un impatto di qualche centinaio di dollari in un anno, a meno che non abbiano anche altri importanti impatto come la fiducia dei clienti o problemi legali.
Non esiste un'unica soluzione valida per la gestione dei rischi.
Dipende dal contesto, dal pubblico, ecc. In generale, l'ambito è importante, e in ogni ambito particolare dovrebbe esserci una comprensione dell'impatto di significative minacce non mitigate.
A livello dell'azienda o dell'organizzazione, le minacce significative non mitigate possono essere segnali per uscire da una particolare area di pratica, o per ottenere un'assicurazione aziendale aggiuntiva, o per assumere, o per intraprendere qualche altra azione strategica.
A livello di sistemi, significative minacce non mitigate possono suggerire aree di miglioramento architettonico.
A livello di un'applicazione, le minacce significative non limitate all'ambito dell'applicazione dovrebbero generalmente entrare nel backlog.
Le applicazioni cambiano frequentemente, quindi le minacce a quel livello contribuiscono al cambiamento dell'applicazione. I sistemi e le aziende cambiano più lentamente; le minacce a questi livelli non devono essere costantemente rivisitate.
C'è un valore preciso nell'includere le minacce che non puoi mitigare. La mitigazione delle minacce è solo un modo in cui è possibile gestire una minaccia. I rischi posti dalle minacce possono essere:
Per scegliere il modo corretto di gestire il rischio rappresentato dalla minaccia, è necessario conoscere la minaccia (ovvero che esiste) e l'impatto che potrebbe avere sul sistema.
Un altro motivo per cui è importante includere minacce che non possono essere mitigate è perché tali minacce possono potenzialmente essere utilizzate come attivatore di una minaccia diversa per il sistema (che potresti essere in grado di mitigare).
Leggi altre domande sui tag web-application man-in-the-middle threat-modeling threat-mitigation threats