Risk Analysis
Scrivere un corretto threat modelling, controllato tutti i giorni della settimana può far risparmiare tempo/denaro alla realizzazione di un progetto. La motivazione è semplice, un corretto threat modelling permette di trovare problemi di sicurezza durante il ciclo di vita del progetto.
La seguente tabella è stata stilata da Steve McConnell nel suo libro Code Complete (McConnell 2004) per far capire i costi relativi al fixing di difetti trovati nel codice:
Defect Introduction
Point
Defects Found During Requirements
Defects Found During Architecture
Defects Found During Construction
Defects Found During Test
Defects Found After Release
Requirements
1
3
5-10
10
10-100
Architecture
None
1
10
15
25-100
Construction
None
None
1
10
10-25
 
L’idea che sta dietro il threat modelling è quella di capire i potenziali problemi di sicurezza del sistema, determinarne i rischi e stabilire le appropriate tecniche per attutire i rischi.
In più è un aiuto per tradurre i rischi tecnici con l’impatto economico e viceversa.
Si tende a far notare che il threat modelling non è qualcosa di statico, tutt’oggi in Microsoft stanno studiando su come rendere le tecniche più semplici da approcciare e migliorarne i benefici.
I benefici attuali sono numerosi, tra i quali:
·         Contribuisce al processo di gestione dei rischi
·         Scoprire i threats del sistema prima che il software venga rilasciato.
·         Poter rivalutare l’architettura e il design con il team di sviluppo.
·         Obbligare il team di sviluppo a guardare al design da diversi punti di vista, per capire i componenti ad alto rischio.
·         Aiuta a chiarire la contromisura scelta.
·         Contribuisce a Attack Surface Reduction.
·         Aiuta il processo di review del codice.
·         Guida il processo di penetration testing.
 
Nel libro il termine threat identifica un obbiettivo di utente malintenzionato. In più, il threat è l’attacker o avversario; in questo libro l’aversario è identificato come threat agent.
 
 
Threat-Modeling Artifacts
Il compito principale del processo di threat-modelling è la stesura di un o più documenti che descrivono l’applicazione e definiscono un high-level application model (traturre certe frasi dall’inglese è impossibile J ), spesso usando il data flow diagrams (DFDs); una lista di attività che richiedono protezione; valutazione dei rischi del sistema per threat; e, se si vuole, una lista di mitigazioni.
Altre informazioni rilevanti sono:
·         Use scenarios: Configurazioni e utilizzo del sistema
·         External dependencies: Prodotti, componenti o servizi
·         Security assumptions: Servizi di sicurezza offerti da componenti esterni (firewall etc)
·         External security notes: Informazioni utili per l’utente finale o l’amministratore per operare in maniera sicura con il sistema.
 
Un threat model dovrebbe essere aggiornato almeno ogni 6 mesi, in quanto è probabile la scoperta di nuovi threat.
 
 
Cosa Modello
Gli applicativi sono composti da piccoli moduli, e modellare piccoli moduli è più efficente che modellare l’intero prodotto.  Questo approccio tende a far venire a galla i threats.
Comunque un sistema anche se sicuro al livello di micro moduli, può essere insicuro durante l’intereazione tra questi.
 
Da quì in poi il libro fa riferimento al Pet Shop 4.0, un’applicazione e-commerce, per dimostrare le best practices dello sviluppo Microsoft.
 
 
Sviluppare il Threat Model
Iniziamo con chi lo sviluppa.
Semplicemente la persona che ha più esperienza nella sicurezza; non ha importanza se è un architetto, un pm o un analista.
Il Thread modelling è una parte del processo di design.
Ad alto livello, il processo di model seguie i seguenti punti:
·         Prepare: I progetti del sistema iniziano il processo e viene prodotto il DFDs tramite gli
input che il team di sviluppo può darci.
·         Analyze: Tutti i threats vengono scoperti ed elencati nel documento di threat model. Durante questo processo il numero di persone coinvolte cresce (non eccessivamente), e si discute dei threat non dei processi per ridurne il rischio.
·         Determine mitigations: Solamente quando avremo una lista di threat definita almeno in parte, si potrà iniziare a discutere su come rendere il sistema più sicuro.
 
Il resto di questo processo (che discuteremo nel prossimo post) riguarderà i seguenti punti:
·         The threat-modeling process
·         Mitigation techniques
·         Using a threat model to aid code review
·         Using a threat model to aid testing
 

 

Tags: