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: SDL
posted @ domenica 20 gennaio 2008 15:25