The Threat-Modeling Process
Sebbene la procedura di alto livello coinvolga numerosi elementi, molti di questi richiedono poca esperienza nel campo della sicurezza:
1. Define use scenarios.
2. Gather a list of external dependencies.
3. Define security assumptions.
4. Create external security notes.
5. Create one or more DFDs of the application being modeled.
6. Determine threat types.
7. Identify the threats to the system.
8. Determine risk.
9. Plan mitigations.
1. Define use scenarios
A questo punto del progetto saremo in grado di determinare in quale scenario il nostro applicativo lavorerà.
Se, ad esempio, è un’applicazione mobile la quale ha dati sensibili, vorremmo avere qualche sistema di sicurezza se il palmare viene rubato.
2. Gather a list of external dependencies
Le nostre applicazioni non sono autosufficenti (almeno le mie… se fate sistemi operativi, il discorso è diverso :D ), per funzionare hanno bisogno di un sistema operativo, magari un db, un Web server e/o un framework.
E’ importante documentare tutte queste dipendenze.
Esempio, per un’applicazione Web come Pet Shop 4.0:
· Web client: Microsoft Internet Explorer 6 o FireFox 1.5 o successivo.
· Microsoft Windows Server 2003
· Lato server: Microsoft SQL Server 2005
· Lato server: Microsoft Message Queue 2
· Microsoft .NET Framework 2
3. Define security assumptions
Questo è un punto alquanto delicato.
Le securty assumptions sono appunto delle assunzioni che diamo sul sistema dove il nostro applicativo gira.
Se, ad esempio, il nostro sistema è collegato ad internet, assumiamo che un firewall sia attivo (e già questa è una PESSIMA security assumptions in quanto un firewall è facilmente disattivabile) o, se registra chiavi encriptate, e ci basiamo sul sistema operativo per proteggere le chiavi, assumiamo che il sistema operativo le protegga in maniera corretta (definire l’accesso ai files, l’utilizzo dell’applicativo solamente ad alcuni users o ad alcuni gruppi, etc).
4. Create external security notes
Gli utenti ed altri designer che interagiscono con il nostro applicativo possono usare le external security notes per capire quali sono i confini da mantenere per tenere sicura l’applicazione.
Esempio, l’amministratore del sistema è in grado di leggere/modificare/cancellare qualsiasi file del sistema, anche del nostro applicativo. Con le security notes rendiamo quest’informazione pubblica all’utente/designer.
Pet Shop 4.0 External Dependencies
· Clients
o Clients con Internet Explorer 6.0 o sup o FireFox 1.5 o sup
· Servers
o Windows Server 2003 SP1
o Microsoft IIS 6.0
o Microsoft ASP.NET 2.0 e Framework 2.0
o Microsoft SQL Server 2000, Microsoft SQL Server 2005, o Oracle 10g
o Windows Server 2003 Terminal Services
o Microsoft Message Queue 2.0
o Microsoft Distributed Transaction Coordinator (MSDTC)
Pet Shop 4.0 Security Assumptions
· I dati sensibili non risiedono nei pc clients, ma vengono spediti tramite una connessione SSL/TLS e i browser mandano i dati tramite questi protocolli.
· DPAPI è usato nel server per proteggere le stringhe di connessione e le chiavi degli utenti non-amministratori.
· Il database registra le informazioni sulle autenticazioni.
· I dati di autenticazione vengono protetti in maniera adeguata dal database server, usando una tecnologia di autorizazione del server ed encriptando i dati.
· IIS 6 e ASP.NET obbligano l’autenticazione.
· Le configurazioni del Web service sono scritte nel Web.config e può esser modificato solamente dall’amministratore.
· Il programma di setup dell’applicazione server configura correttamente l’ACL per il file Web.config.
· Solamente l’amministratore può amministrare i servizi usando il Terminal Services o accedere al server se necessario.
· Navigare in internet, leggere/scrivere e-mail, usare programmi di peer-to-peer o programmi di messaggistica, nel server è PROIBITO.
· Il database è configurato per usare i suoi protocolli di autenticazione nativi.
· Le informazioni di connessione ai database sono salvate nel file Web.config dell’applicazione e protette usando il Protected Configuration option del DPAPI.
Pet Shop 4.0 External Security Information
Di seguito le external security information che troviamo nel libro per l’esempio di Pet Shop 4.0:
· L’amministratore può cambiare qualsiasi settaggio del sistema, incluso il Web service.
· Le uniche porte aperte sono:
o TCP/3389: per l’amministrazione del sistema, accessibile solo dall’amministratore
o TCP/80: HTTP accessibile da internet
o TCP/443: HTTPS accessibile da Internet
o TCP/1433-1521: porte del database, accessibile solo dal Web server e dall’amministratore del computer
o TCP/3372: MSDTC, accessibile da tutti i pc coinvolti nel processo degli ordini; solitamente solo il Web server e il computer del database.
What is modeled and what do you depend on?
Seguendo l’esempio Pet Shop, dobbiamo iniziare a capire cosa modellare.
In esame quindi abbiamo un’applicazione Web che utilizza delle librerie da noi sviluppate per venirci in aiuto in vari compiti, che utilizzano il Framework 2.0, che viene usato dal Web server, il quale utilizza una porta TCP/IP per dialogare, la quale utilizza i driver di rete, i quali servono a dialogare con la scheda madre... etc :D
|
SampleApp Web Service
|
Da modellare
|
|
SampleCorp Web Service Libray
|
|
ASP.NET 2.0
|
.NET Framework 2.0
|
Dipendiamo
|
|
IIS6
|
|
TCP/IP Stack
|
|
Network Driver
|
|
NIC
|
Semplice... no!? :D
5. Create one or more DFDs of the application being modeled
Ora è l’ora della creazione del DFD. Sbagliare questo passaggio significa sbagliare tutto il threat-modeling.
La spiegazione del DFD viene fatta ad alto livello in quanto esistono varie letture a riguardo e l’argomento è alquanto vasto.
Il livello più alto del DFD è il context diagram, il quale visualizza il sistema che stiamo sviluppando al centro e le entità esterne con il quale interagisce, questo ci fa capire chi interagisce con il nostro applicativo.
DFD Element Type
|
Shape
|
DFD Element Type
|
Description
|
|
Doppio cerchio
|
Processo complesso/Multiprocesso
|
Rappresentazione di un processo che si occupa di più distinte operazioni.
|
|
Cerchio
|
Processo
|
Rappresentazione di un processo che si occupa di un discreto task. In alcune rappresentazioni DFD viene disegnato come un rettangolo con gli angoli smussati.
|
|
Rettangolo
|
Entita esterna
|
Qualcosa o qualcuno che non possiamo controllare ma che può comandare la nostra applicazione.
Un esempio: utenti, eventi asincroni, processi esterni, etc
|
|
Line parallele
|
Data store
|
Database o file, rappresenta anche informazioni cached. Alcuni DFD lo rapprensentano come un rettangolo aperto ai lati con il nome del db o del file tra le due rette.
|
|
Freccia
|
Data flow
|
Rappresenta i dati in movimento da e verso il sistema. Esempio: dati via rete, shared memory etc
|
|
Linea puntata
|
Trust boundary
|
Specifico per il threat modeling, delineano i confini alti e bassi di affidabilità in cui i dati si muovono.
Esempio: confini di un processo dove un utente con bassi privilegi comunica con un utente con alti privilegi.
|
Come si vede nell’immagine, conviene aggiungere delle brevissime descrizioni che ci vengono in aiuto per capire il contesto del task che l’utente può effettuare.
Di seguito sono stati sviluppati anche i DFD per i processi complessi prensenti nel nostro applicativo.
Il primo rappresenta il nostro processo centrale.
Cosa fa a chi interagisce con lui. E lo chiamiamo DFD di livello 0 del nome dato al processo centrale; in questo caso PetShop 4.
Invece questo invece esplodiamo il processo complesso presente nel DFD di livello 0. Ovvero il processo nominato Ordering 4.7.
posted @ sabato 26 gennaio 2008 20:10