9. Plan Mitigation
Che strategia applicare per ridurre o eliminare i rischi a cui il nostro sistema va incontro:
Non far nulla
Per threat di basso profilo è la scelta migliore. Cmq dovremo tener presente il threat in modo da risolverlo con il prossimo update.
Rimuovere la funzionalità
Se si vuole ridure il rischio di attacchi a zero, questa è l’unica soluzione, sopratutto quando il rischio è elevato e la funzionalità non è utilizzata dal cliente.
Settare la funzionalità inattiva di default
Quando la funzionalità viene utilizzata dal cliente, ma non è fondamentale per tutti gli utenti dell’applicativo, è utile disattivarla di default e renderla attiva solamente per gli utenti che la utilizzano.
Ovviamente ciò comporta uno studio affinchè il threat venga risolto il prima possibile.
Avvertire l’utente
Avvertire l’utente del rischio è una delle strategie più utilizzate.
Importante: dare informazioni non tecniche e dare poche possibilità di scelta.
Contrastare con le nuove tecnologie
La strategia più utilizzata per ridurre i rischi è far affidamento alle nuove tecnologie (authentication, encryption, etc etc).
Le constromisure da prendere sono elencate nella seguente tabella:
|
Threat Type
|
Mitigation Technique
|
|
Spoofing
|
Authentication
|
|
Tampering
|
Integrity
|
|
Repudiation
|
Non-repudiation services
|
|
Information disclosure
|
Confidentiality
|
|
DoS
|
Availability
|
|
EoP
|
Authorization
|
Per ogni Mitigation Technique possiamo usare una o più tecnologie:
|
Mitigation Technique
|
Mitigation Technology
|
|
Authentication
|
Authenticate principals:
· Basic authentication
· Digest authentication
· Cookie authentication
· Windows authentication (NTLM)
· Kerberos authentication
· PKI systems such as SSL/TLS and certificates
· IPSec
· Digitally signed packets
Authenticate code or data:
· Digital signatures
· Message authentication codes
· Hashes
|
|
|
|
|
Integrity
|
· Windows Vista Mandatory Integrity Controls
· ACLs
· Digital signatures
· Message authentication codes
|
|
|
|
|
Non-repudiation services
|
· Strong authentication
· Secure auditing and logging
· Digital signatures
· Secure time-stamps
· Trusted third parties
|
|
|
|
|
Confidentiality
|
· ACLs
· Encryption
|
|
|
|
|
Availability
|
· ACLs
· Filtering
· Quota
· Authorization
|
|
|
|
|
Authorization
|
· ACLs
· Group or role membership
· Privilege ownership
· Permissions
|
Per una lista completa di tutte le Mitigation Technology utilizzabili per ogni Technique, viene consigliato il libro: Viega and McGraw 2001, Ferguson and Schneier 2003, Howard and Le Blanc 2003.
Adesso che abbiamo anche queste informazioni, riferendoci alle informazioni del post precedente, come possiamo applicarle?
Prendiamo ad esempio 3 asset: 1.0->4.2->1.0, 4.7.10, 4.7.1 (fate riferimento al post di prima per capire di cosa stiamo parlando).
1.0->4.2->1.0: Data flow from Pet Shop User to Web Application and Back
Il data flow è soggetto ad attacchi: tampering, information disclosure e DoS.
Questi tipi di attacchi, dove i dati (username, password, numero carta di credito, oggetti acquistati , etc) viaggiono per la rete, utilizzare dei protocolli sicuri è già qualcosa di molto positivo:
· Facile implementazione e buona sicurezza dei dati
· SSL/TLS risolvono il problema sui dati confidenziali perchè vengono encriptati
· SSL/TLS risolve il del tampering usando Message Authentication Codes (MACs)
· SSL/TLS risolve lo spoofing nel Web application tramite i servizi di autenticazione
4.7.10: Audit Log Data Store
Questo tipo di asset è soggetto ad attacchi del tipo: tampering, information disclosure, DoS e repudiation.
Esempio, una attacker effettua un tampering ai nostri log (ovvero li modifica) e cancella le transazioni che ha effettuato.
Per ovviare a questo problema possiamo usare ACLs, hasches, digital signatures o MACs.
Settare in maniera corretta l’ACLs permette solamente al processo di logging ed agli utenti riconosciuti, la possibilità di manipolare i log. In più possiamo usare una signature o un messaggio di autenticazione sul file di log.
4.7.1: Order Processor Process
Il processo può esser soggetto a: spoofing, tampering, information disclosure, DoS e EoP.
Cosa fare con il tampering, l’abbiamo già detto.
Per EoP le soluzioni possibili sono due:
· autorizzare solamente un utente valido per l’accesso al codice
· utilizzare il livello di privilegi più basso per avviare il processo
Gli altri 3 tipi di attacchi non sono specificati nel libro ma posso sbilanciarmi.
Lo spoofing è un tipo di attacco veramente di basso livello e bisogna prendere le giuste precauzioni al seconda del caso.
Information disclosure, per ovviare a questo tipo di attacco possiamo sempre settare in maniera corretta il nostro ACL ed utilizzare SSL/TLS.
Using a Threat Model to Aid Code Review
Tramite il processo di threat-modeling riusciamo ad identificare gli entry points del sistema.
Se guardiamo le immagini dei post di prima, vediamo subito i tre entry points del sistema: accessibile da utenti anonimi, accessibile da utenti registrati, accessibile dall’amministratore.
Così facendo riusciamo a capir meglio dove possiamo riguardare il codice alla ricerca di bug di sicurezza, andando a far review prima su tutto il codice accessibile da remoto.
Using Threat Model to Aid Testing
Avere delle mitigation techniques non sono la soluzione ai nostri threat perchè anche queste possono subire degli attacchi.
Bisogna quindi capire e creare al meglio degli attacchi o test per capire subito eventuali threat che si trovano alla radice del processo.
Questo processo verrà visto più avanti.
Key Success Factors and Metrics
Cosa ci fa capire se il nostro threat-model è un buon threat-model.
A quanto pare è qualcosa molto soggettiva.
In Microsoft hanno stilato una tabella che può aiutarci a capire che tipo di threat-model abbiamo realizzato:
|
Rating
|
Comments
|
|
No threat model (0)
|
· No threat model is in place – this is simply not acceptable because it indicates that no threats are being considered.
|
|
|
|
|
Not acceptable (1)
|
· Threat model is clearly out of date if:
o Current design is significantly different from that defined in the threat model
· - OR –
o Date in document shows that it is older than 12 months
|
|
|
|
|
OK (2)
|
· A data flow diagram or a list of the following exists:
o Assets (processes, data stores, data flows, external entities)
o Users
o Trust boundaries (machine to machine, user to kernel and vice versa, high privilege to low privilege and vice versa)
· At least one threat is detailed for each software asset
· Mitigations are provided for all risk level 1, 2, and 3 threats
· Model is current
|
|
|
|
|
Good (3)
|
· Threat model meets all definitions of “OK” threat models
· Anonymous, authenticated, local, and remote users are all shown on the DFD
· All S,T,I, and E threats have been identified and classified as either mitigated or accepted
|
|
|
|
|
Excellent (4)
|
· Threat model meets all definitions of “Good” threat models
· All STRIDE threats have been identified and have mitigations, external security notes, or dependencies acknowledged
· Mitigations have been identified for each threat
· External security notes include a plan to create customer-facing documents (from the external security notes) that explain how to use the technology safely and what the tradeoffs are
|